Past Meetup

Annual RocksDB meetup at Facebook HQ

This Meetup is past

190 people went

Location visible to members

Details

Mark your calendars! Our next annual RocksDB meetup at Facebook HQ will take place on Monday December 4th from 2pm to 6pm.

Register at the building 23 lobby and mention "RocksDB meetup". Self parking and Valet is available. Using lyft/uber is recommended. Those who have provided name/email/company information, will have their badges ready to pick up at the lobby reception (Thank you!).

If you haven't pre-registered, arrive earlier to account for the checkin process.

Agenda

MySQL and RocksDB

MySQL incorporates RocksDB as a storage engine. This talk will present some performance and feature enhancements added to RocksDB in the last year for supporting the OLTP workloads in MySQL.

RocksDB Operational Experiences

RocksDB stores the Facebook social graph for some time now having replaced InnoDB as the storage engine for MySQL. Operations with RocksDB have required many adjustments.

Cassandra on RocksDB

Cassandra is a distributed database, widely used in a lot companies. In Facebook, we make Cassandra's storage engine to be pluggable, and implement a new storage engine based on RocksDB, which reduces the P99 read latency significantly. In this talk, we share our work to support Cassandra features on top of RocksDB.

State Management in Kafka Streams using RocksDB

In the stream processing paradigm, a common question is how to manage processing state that is being continuously updated and queried in real-timed. Apache Kafka's Streams API, which is a stream processing library for users to build their streaming applications to process data store in Kafka, is designed to use local state stores to manage processing state. In this talk I will discuss why Kafka Streams chose local store against remote store, and why we picked RocksDB as our default persistent store engine. Will also cover a few lessons we have learned operating RocksDB for stream processing computational patterns.

Are you a Tortoise or a Hare

Different applications need different performance guarantees. Some applications need fastest possible ingest of a dataset (a hare). Other applications need write rate guarantees for every single record (a tortoise). The choice between the two becomes critical as CPU cores, memory size, and disk throughput decrease to save money on cloud virtual machines / AWS instances. This presentation demonstrates how to convert RocksDB's natural "hare mode" into "tortoise mode" for timing sensitive applications and/or lower cost, lower capability hardware. RocksDB's stalls and stops are explained. Then a new, open source EventListener object is discussed.

Integrating a flash- and multicore-optimized key/value store in RocksDB

In this presentation we discuss the integration of Helium into RocksDB, while addressing the engineering challenges, limitations, and our insight into a successful integration. The result is HeRocks, a RocksDB compatible library that is optimized for latest Flash storage and high-core count servers. HeRocks can improve the read and write performance of RocksDB by up to 15 times, while reducing the write amplification, and improving the scalability with the number of cores. Therefore HeRocks is ideal for datacenter environments that run RocksDB to process extensive key-value sets (billion-plus) in real-time. We discuss the performance of HeRocks stand-alone, in db_bench, and integrated in database systems like MyRocks and MongoDB/MongoRocks.