XStore : Fast RDMA-Based Ordered Key-Value Store Using Remote Learned Cache

Abstract

RDMA ( Remote Direct Memory Access ) has gained considerable interests in network-attached in-memory key-value stores. However, traversing the remote tree-based index in ordered key-value stores with RDMA becomes a critical obstacle, causing an order-of-magnitude slowdown and limited scalability due to multiple round trips. Using index cache with conventional wisdom—caching partial data and traversing them locally—usually leads to limited effect because of unavoidable capacity misses, massive random accesses, and costly cache invalidations. We argue that the machine learning (ML) model is a perfect cache structure for the tree-based index, termed learned cache . Based on it, we design and implement XStore , an RDMA-based ordered key-value store with a new hybrid architecture that retains a tree-based index at the server to perform dynamic workloads (e.g., inserts) and leverages a learned cache at the client to perform static workloads (e.g., gets and scans). The key idea is to decouple ML model retraining from index updating by maintaining a layer of indirection from logical to actual positions of key-value pairs. It allows a stale learned cache to continue predicting a correct position for a lookup key. XStore ensures correctness using a validation mechanism with a fallback path and further uses speculative execution to minimize the cost of cache misses. Evaluations with YCSB benchmarks and production workloads show that a single XStore server can achieve over 80 million read-only requests per second. This number outperforms state-of-the-art RDMA-based ordered key-value stores (namely, DrTM-Tree, Cell, and eRPC+Masstree) by up to 5.9× (from 3.7×). For workloads with inserts, XStore still provides up to 3.5× (from 2.7×) throughput speedup, achieving 53M reqs/s. The learned cache can also reduce client-side memory usage and further provides an efficient memory-performance tradeoff, e.g., saving 99% memory at the cost of 20% peak throughput.

Direct Telemetry Access

“…Our goal is to reduce the CPU utilization of collectors to scale with the large number of telemetry reports from many switches. RDMA is a natural solution that has been already used in the past to boost the performance of consensus protocols [38], reads in key-value stores [49,72], and data replication [64]. Similarly, we could build a strawman solution where switches write their reports directly in collectors' memory with RDMA calls without any CPU involvement.…”

KRCORE: a microsecond-scale RDMA control plane for elastic computing

“…The high-level interfaces of LITE follows a simple execution flow (e.g., a synchronous remote memory read), which simplifies sharing QPs between different applications. However, it is inflexible to apply RDMA-aware optimizations widely adopted in the literature [59,49,13,50,22,23], e.g., sending different read/write requests within a batch asynchronously. These optimizations can significantly improve the performance of RDMA-enabled systems, but they are tailed to the RDMA's low-level programming model ( §2.1).…”

“…These requests occupy send queue entries but don't generate poll events: their entries are freed until a later signaled request is polled. As unsignaled request [22] is an important RDMA-aware optimization [49,59,52,22,21], KRCORE still preserves it in our low-level API. To this end, we inspect user requests during data path operations, selectively signal them and voluntarily polls the comp_queue to prevent overflow.…”

“…RDMA-enabled applications. KRCORE continues the line of research on better leveraging RDMA to computer systems, from key-value stores [33,49,59,22,12,34], farmemory data structures [39,6], RPC frameworks [43,24,9,25], replication systems [5,36,48], distributed transactions [51,41,13,10,50], graph systems [42,53] and dis-tributed file systems [58,29,54], just to name a few. Most of these systems do not target elastic computing, but we believe there are opportunities for applying them in such a setting.…”

“…Second, caching all RDMA connections to all nodes is resource inefficient (e.g., taking several GBs of memory), especially when a production RDMA-capable cluster has reached a scale of more than 10,000 nodes [30]. Finally, sharing RDMA connection complicates the preservation of its low-level interfaces, which is important to apply the broadly-explored RDMA-aware optimizations [59,49,13,50,22,23]. LITE only provides a high-level RDMA-based network interface.…”