The Bw-Tree: A B-tree for new hardware platforms

Levandoski, Justin J.; Lomet, David; Sengupta, Sudipta

doi:10.1109/icde.2013.6544834

Cited by 242 publications

(119 citation statements)

References 14 publications

Supporting

Mentioning

119

Contrasting

Order By: Relevance

“…Such systems have been marketed by major vendors for many years, including IBM solidDB [43] and Oracle TimesTen [37], however, only now are they becoming mainstream. Modern multicore optimized main-memory transaction processing systems, such as Hekaton, Silo, and Foedus, use multiversioned latch-free data structures and optimistic concurrency control mechanisms to achieve good scalability by reducing the number of critical sections and their duration [33,39,40,67]. Yet, a recent study shows that none of the current concurrency control mechanisms scales to 1000 cores and suggests that extending hardware support is a promising way for overcoming this obstacle [71].…”

Section: Shared-everything Database Deploymentsmentioning

confidence: 99%

Characterization of the Impact of Hardware Islands on OLTP

Porobic

Pandis

Branco³

et al. 2015

The VLDB Journal

View full text Add to dashboard Cite

Modern hardware is abundantly parallel and increasingly heterogeneous. The numerous processing cores have non-uniform access latencies to the main memory and processor caches, which causes variability in the communication costs. Unfortunately, database systems mostly assume that all processing cores are the same and that microarchitecture differences are not significant enough to appear in critical database execution paths. As we demonstrate in this paper, however, non-uniform core topology does appear in the critical path and conventional database architectures achieve suboptimal and even worse, unpredictable performance. We perform a detailed performance analysis of OLTP deployments in servers with multiple cores per CPU (multicore) and multiple CPUs per server (multisocket). We compare different database deployment strategies where we vary the number and size of independent database instances running on a single server, from a single shared-everything instance to fine-grained shared-nothing configurations. We quantify the impact of non-uniform hardware on various deployments by (a) examining how efficiently each deployment uses the available hardware resources and (b) measuring the impact of distributed transactions and skewed requests on different workloads. We show that no strategy is optimal for all cases and that the best choice depends on the combination of hardware topology and workload characteristics. Finally, we argue that transaction processing systems must be aware of the hardware topology in order to achieve predictably high performance.

show abstract

Section: Shared-everything Database Deploymentsmentioning

confidence: 99%

Characterization of the Impact of Hardware Islands on OLTP

Porobic

Pandis

Branco³

et al. 2015

The VLDB Journal

View full text Add to dashboard Cite

show abstract

“…The latch-free part of never blocking is to use latch-free data structures that employ "compare and swap" (CAS) instructions to make state changes to shared data. This led to the incorporation of the latch-free Bw-tree as Hekaton's key-ordered index [5].…”

Section: The Sql Hekaton Approachmentioning

confidence: 99%

Microsoft SQL server's integrated database approach for modern applications and hardware

Lomet

2013

Proc. VLDB Endow.

View full text Add to dashboard Cite

Recently, there has been much renewed interest in re-architecting database systems to exploit new hardware. While some efforts have suggested that one needs specialized engines ("one size does not fit all"), the approach pursued by Microsoft's SQL Server has been to integrate multiple elements into a common architecture. This brings customers what they want by reducing data impedance mismatches between database systems that they are using for multiple purposes. This integration is, of course, more easily said than done. But this is, in fact, precisely what the SQL Server team has done.

show abstract

“…Database concurrency theory [4], an old age problem, has recently been revived by industry [7,17,18] and academia [25,33,6,32,29,14,16,34] due to hardware trends (e.g., multi-cores and large main memory) and application requirements (e.g., millions of transactions per second in algorithmic trading).…”

Section: Related Workmentioning

confidence: 99%

“…A naive (and rather common) approach is to deal with this limitation by relaxing the consistency model and settling for transactioninconsistent answers to queries, or by relying on an existing multiversion concurrency model (MVCC) such as [4,1,12,17,18]. In this work, we address these limitations, namely, the clashes of both short and long running transactions, and our contributions are as follows.…”

Section: Introductionmentioning

confidence: 99%

Reducing database locking contention through multi-version concurrency

Sadoghi¹,

Canim²,

Bhattacharjee³

et al. 2014

Proc. VLDB Endow.

View full text Add to dashboard Cite

In multi-version databases, updates and deletions of records by transactions require appending a new record to tables rather than performing in-place updates. This mechanism incurs non-negligible performance overhead in the presence of multiple indexes on a table, where changes need to be propagated to all indexes. Additionally, an uncommitted record update will block other active transactions from using the index to fetch the most recently committed values for the updated record. In general, in order to support snapshot isolation and/or multi-version concurrency, either each active transaction is forced to search a database temporary area (e.g., rollback segments) to fetch old values of desired records, or each transaction is forced to scan the entire table to find the older versions of the record in a multi-version database (in the absence of specialized temporal indexes).In this work, we describe a novel kV-Indirection structure to enable efficient (parallelizable) optimistic and pessimistic multi-version concurrency control by utilizing the old versions of records (at most two versions of each record) to provide direct access to the recent changes of records without the need of temporal indexes. As a result, our technique results in higher degree of concurrency by reducing the clashes between readers and writers of data and avoiding extended lock delays. We have a working prototype of our concurrency model and kV-Indirection structure in a commercial database and conducted an extensive evaluation to demonstrate the benefits of our multi-version concurrency control, and we obtained orders of magnitude speed up over the single-version concurrency control.

show abstract

The Bw-Tree: A B-tree for new hardware platforms

Cited by 242 publications

References 14 publications

Characterization of the Impact of Hardware Islands on OLTP

Characterization of the Impact of Hardware Islands on OLTP

Microsoft SQL server's integrated database approach for modern applications and hardware

Reducing database locking contention through multi-version concurrency

Contact Info

Product

Resources

About