FloDB

Balmau, Oana; Guerraoui, Rachid; Trigonakis, Vasileios; Zablotchi, Igor

doi:10.1145/3064176.3064193

Cited by 41 publications

(6 citation statements)

References 21 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…FloDB [7] and TeksDB [28] both augment the in-memory skip list by integrating it with a hash data structure. More specifically, FloDB places a small hash table in front of the sorted skip list, and TeksDB uses both the hash table and the skip list at the same level that both point to the same value.…”

Section: Kvs Optimizationmentioning

confidence: 99%

See 1 more Smart Citation

JellyFish

Yeon

Kim

Han

et al. 2020

Proceedings of the 21st International Middleware Conference

View full text Add to dashboard Cite

Section: Kvs Optimizationmentioning

confidence: 99%

“…In doing so, they achieve fast response time for point accesses, while enjoying the benefit of sorted data retrievals. However, FloDB [7] unfortunately does not support MVCC, while TeksDB [28] incurs overhead in synchronizing the two complementary data structures.…”

Section: Kvs Optimizationmentioning

confidence: 99%

JellyFish

Yeon

Kim

Han

et al. 2020

Proceedings of the 21st International Middleware Conference

View full text Add to dashboard Cite

“…However the use of buffers incurs an additional overhead for lookups. Similarly, FloDB uses a hash table as a buffer ahead of a skip list in LevelDB to service write requests, which can remove the expensive skip-list insertion out of the critical path [2]. FloDB's hash table needs to be fully flushed upon serving a range operation, which can impose long delays for range queries.…”

Section: Related Workmentioning

confidence: 99%

Wormhole

Jiang

2019

Proceedings of the Fourteenth EuroSys Conference 2019

View full text Add to dashboard Cite

In-memory data management systems, such as key-value stores, have become an essential infrastructure in today's bigdata processing and cloud computing. They rely on efficient index structures to access data. While unordered indexes, such as hash tables, can perform point search with O(1) time, they cannot be used in many scenarios where range queries must be supported. Many ordered indexes, such as B+ tree and skip list, have a O(log N) lookup cost, where N is number of keys in an index. For an ordered index hosting billions of keys, it may take more than 30 key-comparisons in a lookup, which is an order of magnitude more expensive than that on a hash table. With availability of large memory and fast network in today's data centers, this O(log N) time is taking a heavy toll on applications that rely on ordered indexes. In this paper we introduce a new ordered index structure, named Wormhole, that takes O(log L) worst-case time for looking up a key with a length of L. The low cost is achieved by simultaneously leveraging strengths of three indexing structures, namely hash table, prefix tree, and B+ tree, to orchestrate a single fast ordered index. Wormhole's range operations can be performed by a linear scan of a list after an initial lookup. This improvement of access efficiency does not come at a price of compromised space efficiency. Instead, Wormhole's index space is comparable to those of B+ tree and skip list. Experiment results show that Wormhole outperforms skip list, B+ tree, ART, and Masstree by up to 8.4×, 4.9×, 4.3×, and 6.6× in terms of key lookup throughput, respectively.

show abstract

“…For I/O‐intensive workloads, the KV stores based on log‐structured merge‐trees (LSM‐trees) 10 have been extensively research and widely deployed 2,8,11‐15 . The main advantage of the LSM‐trees over other indexing structures (such as B‐trees) is that they can deliver high performance for sequential (batch KV pairs) write access patterns on either solid‐state drives (SSDs) or hard‐disk drives 16 by maintaining the ordered keys and values for compaction at different levels in background.…”

Section: Introductionmentioning

confidence: 99%

“…Both WiscKey 16 and LSM‐trie 17 focus on minimizing the I/O amplification and the disk‐level improvement 15W i…”

Section: Introductionmentioning

confidence: 99%

Improving LSM‐trie performance by parallel search

et al. 2020

View full text Add to dashboard Cite

Summary LSM‐trie‐based key‐value (KV) store is often used to manage an ultralarge dataset in reality by introducing a number of sublevels at each level, its linear growth pattern can fairly reduce the write amplification in store operations. Although this design is effective for the write operation, the last level holds a large proportion of KV items, leading to the extreme imbalance of data distribution. Therefore, to support efficient read, we need to carefully consider this imbalance. On the other hand, to ensure that acquired data is latest, the LSM‐trie needs to search the dataset at different levels one by one, and this search method may take a lot of unnecessary time. When the number of items is ultralarge, the random lookup performance may be poor due to the imbalance data distribution. To address this issue, we improve the read performance of the LSM‐trie by changing its serial search to parallel search, using two threads to simultaneously search at the last level and other levels, respectively. Our experiment results show that the read performance of the LSM‐trie can be improved up to 98.35% and on average 71.55%.

show abstract

FloDB

Cited by 41 publications

References 21 publications

JellyFish

JellyFish

Wormhole

Improving LSM‐trie performance by parallel search

Contact Info

Product

Resources

About