《Evolution of Development Priorities in Key-value Stores ServingLarge-scale Applications: The RocksDB Experience》FAST’20

这篇文章是讲述Facebook大规模部署RocksDB的经验，主要是RocksDB优化目标的演变。

RocksDB应用比较广，除了作为KV产品服务业务，也在很多其他系统中作为存储组件。

• Streaming Processing: Flink, Kafaka Stream, Samba, Facebook’s Stylus.
• Logging/Queuing Service: Facebook’s LogDevicem, Uber’s Cherami, Iron.io
• Index Service: Facebook’s Dragon, Rocket
• Caching On SSD: Netflix’s EVCache, Pika

!http://loopjump.com/wp-content/uploads/2022/02/image-20220226191433740.png

优化目标的演变

Write Amplification

主要是针对SSD擦写寿命问题，InnoDB的写方法比较严重。

Space Amplification

相比InnoDB，RocksDB空间节省效果比较明显。

CPU utilization

Adapting to newer technologies

Main Data Structure Revisited

Lessons on serving large-scale systems

resource management

per-instance，per-host资源限制，inter-instance资源倾斜

论文中没有提到的是，资源管理困难之一是资源调度均衡问题本身确实很难做到比较好的适应性策略，但另一方面也应看到，大规模独立部署实例遇到的资源管理问题，实际上是share-nothing架构下的子问题，且该场景下无内置统一的资源管理服务，这也会增加问题的解决难度。

WAL treatment

RocksDB如果作为其他系统内嵌的存储组件，如果有其他paxos log等组件，那么RocksDB的WAL的意义可能就不大了。WAL可配置化是比较重要的，比如sync policy、buffer IO、disable wal。

Rate-limited file deletion

文件删除TRIM可能涉及burst IO，因此要做限速。

Data format compatibility

Managing configurations

选项的校对等问题，还有涉及兼容性的参数。

Replication and backup support

Lessons on failure handing

略

Lessons on the key-value interface

略

RocksDB Feature Timeline

!http://loopjump.com/wp-content/uploads/2022/02/image-20220226200930700-776x1024.png

由图可知，过程是业务问题驱动式，缺那么一点顶层设计。

一点总结

文章略水。