There are basically two things which I majorly like about using MyRocks, 1. LSM Advantage – smaller space & lower write amplification<\/em> and 2. Best of MySQL like replication, storage engine centric database infrastructure operations and MySQL orchestration tools.<\/em> Facebook built RocksDB as an embeddable and persistent key-value store with lower amplification factor () compared to InnoDB. Let me explain a scenario were InnoDB proves less efficient compared to RocksDB in SSD:
\nWe know\u00a0InnoDB is constrained by a fixed compressed page size. Alignment during fragmentation and compression causes extra unused space because the leaf nodes are not full. Let’s consider a InnoDB\u00a0table with a compressed page size of 8KB. A 16KB in-memory page compressed to 5KB still uses 8KB on storage. Adding to this,\u00a0each entry in the primary key index has 13 bytes of metadata (6 byte transaction id + 7 byte rollback pointer), and the metadata is not compressed, making the space overhead significant for small rows. Typically flash devices are limited by the WRITE endurance, In a typical scenario were index values are stored in leaf nodes and sorted by key, the often operational database may not fit in memory and keys get updated in an random platform leading to higher write amplification.\u00a0In the worst case, updating one row requires a number of page reads, makes several pages dirty, and forces many dirty pages to be written back to storage.<\/p>\n

Sow now what I really love about MyRocks?<\/strong><\/p>\n

It’s all about much lower write amplification factor of RocksDB compared to InnoDB is what I am very much impressed about.\u00a0On pure flash, reducing write volume (write amplification) is important because flash burns out if writing too much data. Reducing write volume also helps to improve overall throughput on flash.\u00a0InnoDB adopts “update in place” architecture. Even though updating just 1 record, an entire page where the row belongs becomes dirty, and the dirty page has to be written back to storage.\u00a0On typical OLTP systems, modification unit (row) size is much smaller than I\/O unit (page) size. This makes write amplification very high. I have published performance benchmarking of InnoDB, RocksDB and TokuDB, You can read about it here<\/a><\/span><\/p>\n