Enabling low tail latency on multicore key-value stores

Lersch, Lucas; Schreter, Ivan; Oukid, Ismail; Lehner, Wolfgang

doi:10.14778/3384345.3384356

Cited by 18 publications

(6 citation statements)

References 21 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Similarly, the latest state-of-the-art, key-value stores from academia, such as [18][19][20][31][32][33], either concentrate on a single-node setup or -like the industry ones above-use hash functions to determine where to place data. This kind of placement does not take into account the delay distribution of the host cluster they are working on or the access pattern of the data to store, which is crucial to optimize the access latency.…”

Section: Popular Key-value Storesmentioning

confidence: 99%

State Management for Cloud-Native Applications

2021

View full text Add to dashboard Cite

The stateless cloud-native design improves the elasticity and reliability of applications running in the cloud. The design decouples the life-cycle of application states from that of application instances; states are written to and read from cloud databases, and deployed close to the application code to ensure low latency bounds on state access. However, the scalability of applications brings the well-known limitations of distributed databases, in which the states are stored. In this paper, we propose a full-fledged state layer that supports the stateless cloud application design. In order to minimize the inter-host communication due to state externalization, we propose, on the one hand, a system design jointly with a data placement algorithm that places functions’ states across the hosts of a data center. On the other hand, we design a dynamic replication module that decides the proper number of copies for each state to ensure a sweet spot in short state-access time and low network traffic. We evaluate the proposed methods across realistic scenarios. We show that our solution yields state-access delays close to the optimal, and ensures fast replica placement decisions in large-scale settings.

show abstract

Section: Popular Key-value Storesmentioning

confidence: 99%

State Management for Cloud-Native Applications

2021

View full text Add to dashboard Cite

show abstract

“…Specially crafted real-time databases [27], novel scheduling algorithms in scheduling/routing queries [24,25,45], transactional concepts [5], or query evaluation strategies [19,51], work from inside the database. Careful tailoring of the whole software stack from OS kernel to DB engine [30,33], or crafting dedicated operating systems [4,[20][21][22]36,37] to leverage the advantages of modern hardware in database system engineering (e.g., [15,29]), contribute to solutions from below the database.…”

Section: Related Workmentioning

confidence: 99%

“…It has been reported that database-internal garbage collection [2,29] can also cause latency spikes, which might however be seen as part of productive operation. Our work considers the effects of garbage collection inside the test harness, rather than the database engine.…”

Section: Related Workmentioning

confidence: 99%

“…Measuring performance is an essential ingredient of evaluating and optimising database systems, and a large fraction of published research (e.g., [2,16,18,19,24,25,29,33,45]) is driven by guidance from the collection of benchmarks provided by the Transaction Processing Performance Council (TPC) [50], or commercial de-facto standards like the Yahoo! Cloud Serving Benchmark (YCSB) [9].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Tell-Tale Tail Latencies: Pitfalls and Perils in Database Benchmarking

Fruth¹,

Scherzinger²,

Mauerer³

et al. 2021

Preprint

View full text Add to dashboard Cite

The performance of database systems is usually characterised by their average-case (i.e., throughput) behaviour in standardised or defacto standard benchmarks like TPC-X or YCSB. While tails of the latency (i.e., response time) distribution receive considerably less attention, they have been identified as a threat to the overall system performance: In large-scale systems, even a fraction of requests delayed can build up into delays perceivable by end users. To eradicate large tail latencies from database systems, the ability to faithfully record them, and likewise pinpoint them to the root causes, is imminently required. In this paper, we address the challenge of measuring tail latencies using standard benchmarks, and identify subtle perils and pitfalls. In particular, we demonstrate how Java-based benchmarking approaches can substantially distort tail latency observations, and discuss how the discovery of such problems is inhibited by the common focus on throughput performance. We make a case for purposefully re-designing database benchmarking harnesses based on these observations to arrive at faithful characterisations of database performance from multiple important angles.

show abstract

“…As soon as the volatile part is full and compaction to an SSTable starts, the PMem replication is used for concurrent queries. A recent proposal for a modern key-value store is RStore [20]. It can be summarized as log-structured storage plus index.…”

Section: Pmem-aware Storage Enginesmentioning

confidence: 99%

Designing an Event Store for a Modern Three-layer Storage Hierarchy

et al. 2020

View full text Add to dashboard Cite

Event stores face the difficult challenge of continuously ingesting massive temporal data streams while satisfying demanding query and recovery requirements. Many of today’s systems deal with multiple hardware-based trade-offs. For instance, long-term storage solutions balance keeping data in cheap secondary media (SSDs, HDDs) and performance-oriented main-memory caches. As an alternative, in-memory systems focus on performance, while sacrificing monetary costs, and, to some degree, recovery guarantees. The advent of persistent memory (PMem) led to a multitude of novel research proposals aiming to alleviate those trade-offs in various fields. So far, however, there is no proposal for a PMem-powered specialized event store. Based on ChronicleDB, we will present several complementary approaches for a three-layer architecture featuring main memory, PMem, and secondary storage. We enhance some of ChronicleDB’s components with PMem for better insertion and query performance as well as better recovery guarantees. At the same time, the three-layer architecture aims to keep the overall dollar cost of a system low. The limitations and opportunities of a PMem-enhanced event store serve as important groundwork for comprehensive system design exploiting a modern storage hierarchy.

show abstract

Enabling low tail latency on multicore key-value stores

Cited by 18 publications

References 21 publications

State Management for Cloud-Native Applications

State Management for Cloud-Native Applications

Tell-Tale Tail Latencies: Pitfalls and Perils in Database Benchmarking

Designing an Event Store for a Modern Three-layer Storage Hierarchy

Contact Info

Product

Resources

About