Performance tuning can improve the system performance and thus enable the reduction of cloud computing resources needed to support an application. Due to the ever increasing number of parameters and complexity of systems, there is a necessity to automate performance tuning for the complicated systems in the cloud. The state-of-the-art tuning methods are adopting either the experience-driven tuning approach or the data-driven one. Data-driven tuning is attracting increasing attentions, as it has wider applicability. But existing data-driven methods cannot fully address the challenges of sample scarcity and high dimensionality simultaneously. We present ClassyTune, a data-driven automatic configuration tuning tool for cloud systems. ClassyTune exploits the machine learning model ofclassification for auto-tuning. This exploitation enables the induction ofmoretraining sampleswithoutincreasing the input dimension. Experiments on seven popular systems in the cloud show that ClassyTune can effectively tune system performance to seven times higher for high-dimensional configuration space, outperforming expert tuning and the state-of-the-art auto-tuning solutions. We also describe a use case in which performance tuning enables the reduction of 33 percent computing resources needed to run an online stateless service.

Fast in-memory key value stores are the keys to building large-scale Internet services. The state-of-the-art solutions mainly focus on optimizing the performance for read-intensive workloads. Nevertheless, a wide range of applications demonstrate a significant amount of updates and range queries, which scale poorly with the current implementations. In this paper, we present BiloKey, a highly scalable in-memory key value store on multi-core machines, significantly outperforming Redis and Memcached for a variety of mixed read and write workloads. To achieve this, BiloKey leverages a fast bi-index comprised by a Hash Table index and a SkipList index, where the former supports feature rich operations including GET, UPDATE and DELETE with O(1) complexity, while the latter supports SCAN with O(log N) complexity. Furthermore, to make the bi-index design scale well, BiloKey adopts three techniques: lazy synchronization for reducing the overhead of maintaining index consistency, lock-free data structure for supporting multi-writers, and locality-aware data parallel processing for preserving the data locality of requests. Compared with two popular in-memory KV stores (i.e., Redis and Memcached), experimental results show that: (1) for write-intensive workloads, BiloKey outperforms Redis and Memcached by 7.8x and 3.7x on average (up to 11.5x and 4.8x), respectively; (2) for scan-intensive workloads, BiloKey achieves an average speedup of 2.3x against Redis; (3) for read-intensive workloads, BiloKey also outperforms Redis and Memcached by 1.2x and 1.8x on average.

An ever increasing number of configuration parameters are provided to system users. But many users have used one configuration setting across different workloads, leaving untapped the performance potential of systems. A good configuration setting can greatly improve the performance of a deployed system under certain workloads. But with tens or hundreds of parameters, it becomes a highly costly task to decide which configuration setting leads to the best performance. While such task requires the strong expertise in both the system and the application, users commonly lack such expertise.

Distributed transaction can enable not only large-scale transacting business in highly scalable datastores, but also fast information extraction from big data through materialized view maintenance and incremental processing. Atomic commitment is key to the correctness of transaction processing. While two-phase commit (2PC) is widely used for distributed transaction commitment even in modern large-scale datastores, it is costly in performance. Even though variants of 2PC can improve performance, they are blocking on server failures, impairing data availability. Existent non-blocking atomic commitment protocols are too costly for practical usage. This work presents Pronto, a non-blocking one-phase commit protocol for distributed transactions over replicated data. Pronto removes the prepare phase of 2PC, reducing communication and logging costs. Without transaction client failure, Pronto can commit a transaction in one communication roundtrip; and, client failures cannot block transaction processing. Pronto can also tolerate server failures. Pronto is compared to state-of-art commitment protocols. Pronto outperforms other commitment protocols in workloads with varying numbers of participants. When a transaction has many participants, Pronto can commit in one fifth of the time 2PC does.

Transaction and high availability are both important to applications. While data partition, distribution and replication are the three key mechanisms to guarantee high availability, a coordination to reach consensuses on replica state transitions, transaction operation orders and commit decisions is required for transaction processing. This coordination impairs transaction processing performance. In classic transactional approaches, lock granularity is exploited to trade off consistency for performance under weaker isolation levels. We question whether transaction processing performance can be similarly improved under weaker isolation levels by consensus reduction. To carry out consensus reduction, we categorize transactions based on their scopes of consensus, as well as their requirements on consensus. A transaction in one category can be reduced to multiple transactions in other categories with smaller consensus scope and weaker consensus requirement. We theoretically analyze what anomalies the reduction can lead to. We thus find and define eight isolation levels by anomaly sets. We experiment to find out how these weaker isolation levels can improve transaction processing performance. Interesting results show that three weak isolation levels improve performance, while the weakest isolation level has the worst performance. Results in this paper enable users to actively choose the appropriate isolation levels for their applications.

Guaranteeing transaction semantics in a highly available and fault tolerant manner is desirable to application developers. Besides, it is a very valuable feature for database-backed applications. In this paper, we propose SHAFT to support transactions with serializability in highly-available datastores, which partition, distribute and replicate data across datacenters. SHAFT is a transactional replication protocol guaranteeing Serializability, High Availability and Fault Tolerance simultaneously for transactions. Laying its basis on the Paxos algorithm, SHAFT guarantees serializability by a two-phase locking procedure in a fault-tolerant manner. Different from other transactional replication protocols like MDCC, SHAFT allows a client to actively abort a transaction. SHAFT also allows flexible data partition, replication and distribution, a proper combination of which can reduce costs and improve performance. SHAFT performs well even under failures. Our experiments show that SHAFT outperforms MDCC, which outperforms other synchronous transactional replication protocols, e.g. Megastore.

As architecture, systems, and data management communities pay greater attention to innovative big data systems and architecture, the pressure of benchmarking and evaluating these systems rises. However, the complexity, diversity, frequently changed workloads, and rapid evolution of big data systems raise great challenges in big data benchmarking. Considering the broad use of big data systems, for the sake of fairness, big data benchmarks must include diversity of data and workloads, which is the prerequisite for evaluating big data systems and architecture. Most of the state-of-the-art big data benchmarking efforts target evaluating specific types of applications or system software stacks, and hence they are not qualified for serving the purposes mentioned above. This paper presents our joint research efforts on this issue with several industrial partners. Our big data benchmark suite-BigDataBench not only covers broad application scenarios, but also includes diverse and representative data sets. Currently, we choose 19 big data benchmarks from dimensions of application scenarios, operations/ algorithms, data types, data sources, software stacks, and application types, and they are comprehensive for fairly measuring and evaluating big data systems and architecture. BigDataBench is publicly available from the project home page http://prof.ict.ac.cn/BigDataBench. Also, we comprehensively characterize 19 big data workloads included in BigDataBench with varying data inputs. On a typical state-of-practice processor, Intel Xeon E5645, we have the following observations: First, in comparison with the traditional benchmarks: including PARSEC, HPCC, and SPECCPU, big data applications have very low operation intensity, which measures the ratio of the total number of instructions divided by the total byte number of memory accesses; Second, the volume of data input has non-negligible impact on micro-architecture characteristics, which may impose challenges for simulation-based big data architecture research; Last but not least, corroborating the observations in CloudSuite and DCBench (which use smaller data inputs), we find that the numbers of L1 instruction cache (L1I) misses per 1000 instructions (in short, MPKI) of the big data applications are higher than in the traditional benchmarks; also, we find that L3 caches are effective for the big data applications, corroborating the observation in DCBench.

Replication is critical to the scalability, availability and reliability of large-scale systems. The trade-off of replica consistency vs. response latency has been widely understood for large-scale stores with replication. The weak consistency guaranteed by existing large-scale stores complicates application development, while the strong consistency hurts application performance. It is desirable that the best consistency be guaranteed for a tolerable response latency, but none of existing large-scale stores supports maximized replica consistency within a given latency constraint. In this demonstration, we showcase RECODS (REplica Consistency-On-Demand Store), a NoSQL store implementation that can finely control the trade-off on an operation basis and thus facilitate application development with on-demand replica consistency. With RECODS, developers can specify the tolerable latency for each read/write operation. Within the specified latency constraint, a response will be returned and the replica consistency be maximized. RECODS implementation is based on Cassandra, an open source NoSQL store, but with a different operation execution process, replication process and in-memory storage hierarchy.

The challenge of managing intensive unstructured data provides a good opportunity for both academy and industry in data management area. In this paper, we analyze the five basic requirements in constructing a data management system for unstructured data. We then introduce our tentative implementation of an unstructured data management system developed according to the requirements. A dedicated performance test framework is proposed in conjunction, and preliminary experiments demonstrate the key traits of our system. We discuss about our position adopted in our implementation. We claim that simple user and programming interface, data centric approach, customizable data consistency, extensible architecture, real-time and batch processing integration are very important properties of unstructured data management systems that satisfy the five basic requirements.