Skip to content

Details

Let's kick off the first-ever virtual RocksDB community meetup, being live-streamed from Rockset in San Mateo, CA.

The Livestream Link (via Zoom):
Join Zoom Meeting
https://us02web.zoom.us/j/84378824637?pwd=Njd3WmN4Vk9NazJuMWVhdkFUbDlyZz09
Meeting ID: 843 7882 4637
Passcode: rockset

Social Link (via Gather)
https://gather.town/app/cUXT2mdBaCQY2bFw/rocksdb_meetup

We have three fantastic talks for you:
[5:00-5:15 pm] Networking
[5:15 - 5:50 PM] SplinterDB: Closing the Bandwidth Gap for NVMe Key-Value Stores (VMWare Research)
[5:55 - 6:30 PM] Remote compaction on RocksDB (Rockset)
[6:35 - 7:10 PM] A practical and near-optimal static Bloom alternative for RocksDB (Facebook)
[7:10-7:30 pm] Networking

Talk Abstracts

  1. SplinterDB, a key-value store designed to fully utilize the performance of modern storage, such as NVMe and Optane devices, even on challenging workloads, such as those with small key-value pairs and/or very low CPU and memory footprints. We find that one of the keys to fully utilizing fast, solid-state storage, is to maintain a high degree of CPU and I/O parallelism. SplinterDB contains design elements which address both types of parallelism. Insertions in SplinterDB with small key-value pairs are about 7x faster than RocksDB on an Optane NVMe storage device, and queries are 50% to 2x faster. (USENIX 2020 Technical Conference Paper)

Abhishek Gupta, Alex Conway, Rob Johnson, Rick Spillane (VMWare)

Alex’s Bio (VMware)

Alex is a researcher at VMware Research Group, where he works on theoretical and practical aspects of storage systems. His work includes results on key-value stores, file systems, and filters.

  1. Supporting Remote Compactions in RocksDB: In a typical RocksDB-based system, compaction occurs on CPUs that are local on the server that hosts the storage as well. In this case, compute and storage are not disaggregated. And this means that if your write rate increases but the total size of your database remains the same, you would have to dynamically provision more servers, spread your data into all those servers and then leverage the additional compute on these servers to keep up with the compaction load. To solve this problem, we extended the base RocksDB API with two new methods that make the compaction engine in RocksDB externally pluggable. This allows compaction to be delegated to remote compute nodes that are stateless and can be scaled up or down very quickly on demand. We describe the APIs that we have implemented and present results of remote compaction on Rockset’s realtime indexing database service.

Hieu Pham (Rockset)

Hieu is a software engineer at Rockset, where he works on the ingest performance of the platform as well as RocksDB-Cloud. Before that, Hieu worked at Facebook in various different teams, such as Search Infrastructure, Monitoring and Alerting, and Realtime Analytics.

  1. A practical and near-optimal static Bloom alternative for RocksDB: RocksDB SST Bloom filters are very fast but offer no additional space savings when willing to spend more CPU. The quest for a worthy complement to the static Bloom filter seems to be ending, with a Bloom alternative based on Walzer & Dietzfelbinger's SGauss. It offers space savings near the optimal of 1/3 vs. Bloom filter, construction time near integer sorting speeds, local O(1) queries near Bloom speeds and great configurability / flexibility / adaptability. This talk gives an overview of the technology and what to expect soon in RocksDB.

Peter Dillinger (Facebook)

Peter Dillinger advanced the science and practice of Bloom filters and alternatives back in graduate school and joined the RocksDB team at Facebook in 2019, aiming this time to advance and optimize static filters to their practical limits. Also interested in software correctness, Peter worked on Coverity Static Analysis from 2009 - 2017. Peter lives and works in Seattle.

You may also like