arXiv subjects

David Lomet

Publications and source records attributed to David Lomet.

6 recordsLinked to original sources

arXiv2026

Avoiding Thread Stalls and Switches in Key-Value Stores: New Latch-Free Techniques and More

A significant impediment to high performance in key-value stores is the high cost of thread switching or stalls. While there are many sources for this, a major one is the contention for resources. And this cost increases with load as conflicting operations more frequently try to access data concurrently. Traditional latch-based approaches usually handle these situations by blocking one or more contending threads. Latch-free techniques can avoid this behavior. But the payoff may be limited if latch-free techniques require executing wasted work. In this paper, we show how latch-free techniques exploit delta record updating and can significantly reduce wasted work by using notices, a new latch-free approach. This paper explains how notices work and can solve B-tree index maintenance problems, while avoiding thread switches or stalls. Other opportunities for avoiding thread switches or stalls are also discussed.

cs.DB↗

arXiv2025

Deuteronomy 2.0: Record Caching and Latch Freedom

The Deuteronomy transactional key-value store is unique architecturally in providing separation between transaction functionality -- its Transactional Component (TC) and data management -- its Data Component (DC). It is unique in technology by (1) supporting record caching, a smaller unit than the traditional page; and (2) protecting resources during concurrent execution using a latch-free approach. Both technologies are enabled by delta updating. This paper explains how record caching improves cache cost/performance. It also shows how a new latch-free approach makes implementation easier and improves performance.

cs.DB↗

arXiv2020

Efficiently Reclaiming Space in a Log Structured Store

A log structured store uses a single write I/O for a number of diverse and non-contiguous pages within a large buffer instead of using a write I/O for each page separately. This requires that pages be relocated on every write, because pages are never updated in place. Instead, pages are dynamically remapped on every write. Log structuring was invented for and used initially in file systems. Today, a form of log structuring is used in SSD controllers because an SSD requires the erasure of a large block of pages before flash storage can be reused. No update-in-place requires that the storage for out-of-date pages be reclaimed (garbage collected or "cleaned"). We analyze cleaning performance and introduce a cleaning strategy that uses a new way to prioritize the order in which stale pages are garbage collected. Our cleaning strategy approximates an "optimal cleaning strategy". Simulation studies confirm the results of the analysis. This strategy is a significant improvement over previous cleaning strategies.

cs.DB↗

arXiv2019

ALEX: An Updatable Adaptive Learned Index

Recent work on "learned indexes" has changed the way we look at the decades-old field of DBMS indexing. The key idea is that indexes can be thought of as "models" that predict the position of a key in a dataset. Indexes can, thus, be learned. The original work by Kraska et al. shows that a learned index beats a B+Tree by a factor of up to three in search time and by an order of magnitude in memory footprint. However, it is limited to static, read-only workloads. In this paper, we present a new learned index called ALEX which addresses practical issues that arise when implementing learned indexes for workloads that contain a mix of point lookups, short range queries, inserts, updates, and deletes. ALEX effectively combines the core insights from learned indexes with proven storage and indexing techniques to achieve high performance and low memory footprint. On read-only workloads, ALEX beats the learned index from Kraska et al. by up to 2.2X on performance with up to 15X smaller index size. Across the spectrum of read-write workloads, ALEX beats B+Trees by up to 4.1X while never performing worse, with up to 2000X smaller index size. We believe ALEX presents a key step towards making learned indexes practical for a broader class of database workloads with dynamic updates.

cs.DB↗

arXiv2011

Implementing Performance Competitive Logical Recovery

New hardware platforms, e.g. cloud, multi-core, etc., have led to a reconsideration of database system architecture. Our Deuteronomy project separates transactional functionality from data management functionality, enabling a flexible response to exploiting new platforms. This separation requires, however, that recovery is described logically. In this paper, we extend current recovery methods to work in this logical setting. While this is straightforward in principle, performance is an issue. We show how ARIES style recovery optimizations can work for logical recovery where page information is not captured on the log. In side-by-side performance experiments using a common log, we compare logical recovery with a state-of-the art ARIES style recovery implementation and show that logical redo performance can be competitive.

cs.DB↗

arXiv2009

Unbundling Transaction Services in the Cloud

The traditional architecture for a DBMS engine has the recovery, concurrency control and access method code tightly bound together in a storage engine for records. We propose a different approach, where the storage engine is factored into two layers (each of which might have multiple heterogeneous instances). A Transactional Component (TC) works at a logical level only: it knows about transactions and their "logical" concurrency control and undo/redo recovery, but it does not know about page layout, B-trees etc. A Data Component (DC) knows about the physical storage structure. It supports a record oriented interface that provides atomic operations, but it does not know about transactions. Providing atomic record operations may itself involve DC-local concurrency control and recovery, which can be implemented using system transactions. The interaction of the mechanisms in TC and DC leads to multi-level redo (unlike the repeat history paradigm for redo in integrated engines). This refactoring of the system architecture could allow easier deployment of application-specific physical structures and may also be helpful to exploit multi-core hardware. Particularly promising is its potential to enable flexible transactions in cloud database deployments. We describe the necessary principles for unbundled recovery, and discuss implementation issues.

cs.DB↗