Differentiating Between MongoDB Storage Engines: RocksDB
Differentiating Between MongoDB Storage Engines: RocksDBIn this series of posts, we discussed what a storage engine is, and how you can determine the characteristics of one versus the other:
“A database storage engine is the underlying software that a DBMS uses to create, read, update and delete data from a database. The storage engine should be thought of as a “bolt on” to the database (server daemon), which controls the database’s interaction with memory and storage subsystems.”
Generally speaking, it’s important to understand what type of work environment the database is going to interact with, and to select a storage engine that is tailored to that environment.
The first post looked at MMAPv1, the original default engine for MongoDB (through release 3.0). The second post examined WiredTiger, the new default MongoDB engine.
This post will cover RocksDB. RocksDB builds on LevelDB, Google’s open source key value database library. It was designed to address several scenarios:
- Scale to run on servers with many CPU cores.
- Use fast storage efficiently.
- Be flexible to allow for innovation.
- Support IO-bound, in-memory, and write-once workloads.
RocksDB
Find it in: Percona Builds
RocksDB, designed originally at Facebook, uses LSM trees to store data, unlike most other storage engines which are using B-Trees.
LSM trees are designed to amortize the cost of writes: data is written to log files that are sequentially written to disk and never modified. Then a background thread merges the log files (compaction) into a tree like structure. With this design a single I/O can flush to disk tens or hundreds of write operations.
The tradeoff is that reading a document is more complex and therefore slower than for a B-Tree; because we don’t know in advance in which log file the latest version of the data is stored, we may need to read multiple files to perform a single read. RocksDB uses bloom filters and fractional cascading to minimize the impact of these issues.
As far as workload fit, RocksDB can provide very good insert and query performance while providing compression ratios that are typically better than wiredTiger and slightly worse than PerconaFT. Also, RocksDB is theoretically better than PerconaFT at keeping up with the frequent and heavy delete workloads that accompany TTL indexes in high insert workloads.
Percona is excited to offer enterprise support for RocksDB! RocksDB as part of our MongoDB support options: https://www.percona.com/services/support/rocksdb-support.
Conclusion
Most people don’t know that they have a choice when it comes to storage engines, and that the choice should be based on what the database workload will look like. Percona’s Vadim Tkachenko performed an excellent benchmark test comparing the performances of, PerconaFT and WiredTiger to help specifically differentiate between these engines.
In Part Four of this blog series, we’ll take a closer look at Percona’s MongoDB storage engine: PerconaFT.
What’s a bloom filter and how is it used in RocksDB to help with read impacts?
Matthew, here is a quick link: https://github.com/facebook/rocksdb/wiki/RocksDB-Bloom-Filter. Ping us again if you have more questions!