RocksDB Performance and Reliability Practics
summary
Meta/Facebook runs MyRocks on RocksDB and reports about 60% space savings after migrating large user data, citing LSM space amplification ≈ 1.11 vs InnoDB ≈1.5. Read latency often degrades, so production fixes include JEMalloc and direct I/O, tuning data/index/filter block sizes and level-compression mixes, using prefix bloom filters, bulk-loading into level-max files, and deletion-triggered compactions to mitigate tombstone blowup. Monitoring compaction bytes, L0 stalls and tombstone scan rates and making online column-family config changes prove critical for reliability.
AI-written summary · about
chapters (26)
- 0:00Intro
- 1:51What is RocksDB
- 8:03Leveled Compaction
- 9:40RocksDB Features
- 21:17RocksDB Performance Practices
- 22:52RocksDB file format - data, index and filter
- 24:51Index and Filter size reduction
- 25:38Direct 1/0
- 26:23Hybrid Compression
- 27:11Avoid Compaction if possible
- 28:18Bloom Filter
- 29:28Understand what happens with Delete
- 31:24Scanning too many tombstones degrades read perf
- 33:01Slowdown because of too many point lookups
- 34:32RocksDB Reliability Practices
- 34:55Preventing Write Stall
- 36:28MemTable/Lo Stalls
- 37:20Metrics to watch
- 37:56Most configurations are Dynamic
- 40:191/0 Error Handling in My Rocks
- 42:20Unique Key Constraints
- 43:17Data consistency
- 44:48Recovery on Database Crash
- 46:33Dealing with Snapshot Conflicts
- 48:19InnoDB to MyRocks/RocksDB migration steps
- 49:43Summary
related talks
57mRocksDB
47mLessons Learned from Our Main Database Migrations at Facebook
50mInnoDB to MyRocks Migration in Main MySQL Database
12mMyRocks at Facebook and a Roadmap
51mMyRocks deep dive and production deployment at Facebook
39mLessons Learned from Our Main Database Migrations
27mMyRocks: best practice at Alibaba - MySQL Storage Engine
29mAccelerating Performance: Mastering RocksDB for High Speed Data Processing