Griffin: Fast Transactional Database Index with Hash and B+-Tree

TL;DR

A hybrid index architecture, Griffin, which transparently provides linearizable operations and an interface of a single database index, and achieves up to 3.1x higher throughput in a point operation dominant workload, and up to 5.4x higher throughput in a range operation dominant workload.

Abstract

Index access is one of the dominant performance factors in transactional database systems. Many systems use a B+-tree or one of its variants to handle point and range operations. This access pattern has room for performance improvement. Firstly, point operations can potentially be processed in $O(1)$ with a hash table. Secondly, to ensure serializability of transactions, range operations incur overhead from phantom avoidance techniques that involve additional processing or synchronization, such as an extra traversal of the B+-tree. To address these issues, we propose a hybrid index architecture, Griffin. For point operations, Griffin has a hash table that provides access paths in $O(1)$ time, along with a B+-tree. For phantom avoidance, Griffin employs a precision locking method, which does not involve additional traversal of the B+-tree. Despite its hybrid architecture, Griffin transparently provides linearizable operations and an interface of a single database index. We built a Griffin index combining a hash table and BwTree. Compared to a baseline index that is composed of a BwTree only, it achieves up to 3.1x higher throughput in a point operation dominant workload, and up to 5.4x higher throughput in a range operation dominant workload.

Figures (10)

• Figure 1: Griffin index architecture.
• Figure 2: Data structure and control flow of Griffin. Griffin has an always up-to-date hash table and an asynchronously updated B+-tree. For phantom avoidance, Griffin validates Inserted and Deleted keys and Scanned key ranges, according to precision locking DBLP:journals/cacm/EswarranGLT76.
• Figure 3: Precision locking design. Each $L_u$ entry has an Inserted or Deleted key, along with the status of the transaction that issued it (used by sync manager, as will be explained in Sec. \ref{['subsec:sync_manager']}). Each $L_p$ entry has a Scanned key range and the transaction status.
• Figure 4: Example cases of transaction aborts in Griffin. Horizontal axis represents elapsed time. Each box in $L_u$ or $L_p$ denotes the existence of a precision locking entry.
• Figure 5: YCSB-A throughput.