AKARA: A Flexible Clustering Protocol for Demanding Transactional Workloads

Abstract

Shared-nothing clusters are a well known and cost-effective approach to database server scalability, in particular, with highly intensive read-only workloads typical of many 3-tier web-based applications. The common reliance on a centralized component and a simplistic propagation strategy employed by mainstream solutions however conduct to poor scalability with traditional on-line transaction processing (OLTP), where the update ratio is high. Such approaches also pose an additional obstacle to high availability while introducing a single point of failure. More recently, database replication protocols based on group communication have been shown to overcome such limitations, expanding the applicability of shared-nothing clusters to more demanding transactional workloads. These take simultaneous advantage of total order multicast and transactional semantics to improve on mainstream solutions. However, none has already been widely deployed in a general purpose database management system. In this paper, we argue that a major hurdle for their acceptance is that these proposals have disappointing performance with specific subsets of realworld workloads. Such limitations are deep-rooted and working around them requires in-depth understanding of protocols and changes to applications. We address this issue with a novel protocol that combines multiple transaction execution mechanisms and replication techniques and then show how it avoids the identified pitfalls. Experimental results are obtained with a workload based on the industry standard TPC-C benchmark.

AJITTS: Adaptive Just-In-Time Transaction Scheduling

“…In replicated database systems [1][2][3], it allows concurrent transactions to execute at different sites regardless of possible conflicts. Conflict detection and resolution are performed at commit time, before the changes are applied to the database.…”

“…Also, any transaction is vulnerable to being aborted by other transactions from the moment it starts to execute until is is certified: the longer it takes to execute and certify a given transaction, the more vulnerable it is. This is the caveat of most optimistic concurrency control strategies: when loaded, latency increases and fairness is compromised, particularly for long-running transactions [1].…”

“…The queues are used to serialize transactions that access the same data partitions. The performance penalty imposed by the conservative strategy depends on the grain considered for concurrency control: if the grain is too fine, conflict detection will result in a delay before transaction execution; on the other hand, if the grain is too coarse, transactions that would not otherwise conflict are unnecessarily prevented from executing concurrently [1].…”

“…However, if appropriate conflict classes cannot be used to ensure no conflicts occur during re-execution, the system will quickly be prevented from exploting optimism [1]. Moreover, although most optimistic concurrency control protocols execute transactions as soon as these are submitted [2,3], it has been pointed out that the worst scenarios for optimistic concurrency control can be mitigated by limiting the number of transactions executing concurrently [1]. Transaction scheduling on non-distributed settings using queue-theoretic models for automatically adjusting the maximum parallelism level has been studied [9].…”

Evaluating Throughput Stability of Protocols for Distributed Middleware

“…Instead of relying solely on the underlying shared database management system to enforce consistency across different servers, updates are propagated and implicitly ordered using group communication. Another example is consistent database replication [8]. This allows concurrent conflicting updates to be processed by different replicas without fine synchronization thus enabling high performance.…”