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. To help users tap the performance potential of systems, we present BestConfig, a system for automatically finding a best configuration setting within a resource limit for a deployed system under a given application workload. BestConfig is designed with an extensible architecture to automate the configuration tuning for general systems. To tune system configurations within a resource limit, we propose the divide-and-diverge sampling method and the recursive bound-and-search algorithm. BestConfig can improve the throughput of Tomcat by 75%, that of Cassandra by 63%, that of MySQL by 430%, and reduce the running time of Hive join job by about 50% and that of Spark join job by about 80%, solely by configuration adjustment.
To support the variety of Big Data use cases, many Big Data related systems expose a large number of user-specifiable configuration parameters. Highlighted in our experiments, a MySQL deployment with well-tuned configuration parameters achieves a pea
k throughput as 12 times much as one with the default setting. However, finding the best setting for the tens or hundreds of configuration parameters is mission impossible for ordinary users. Worse still, many Big Data applications require the support of multiple systems co-deployed in the same cluster. As these co-deployed systems can interact to affect the overall performance, they must be tuned together. Automatic configuration tuning with scalability guarantees (ACTS) is in need to help system users. Solutions to ACTS must scale to various systems, workloads, deployments, parameters and resource limits. Proposing and implementing an ACTS solution, we demonstrate that ACTS can benefit users not only in improving system performance and resource utilization, but also in saving costs and enabling fairer benchmarking.
This document outlines the approach to supporting cross-node transactions over a Redis cluster.
Although ACID is the previous golden rule for transaction support, durability is now not a basic requirement for data storage. Rather, high availability is becoming the first-class property required by online applications. We show that high availabil
ity of data is almost surely a stronger property than durability. We thus propose ACIA (Atomicity, Consistency, Isolation, Availability) as the new standard for transaction support. Essentially, the shift from ACID to ACIA is due to the change of assumed conditions for data management. Four major condition changes exist. With ACIA transactions, more diverse requirements can be flexibly supported for applications through the specification of consistency levels, isolation levels and fault tolerance levels. Clarifying the ACIA properties enables the exploitation of techniques used for ACID transactions, as well as bringing about new challenges for research.
