Characterizing, Modeling, and Benchmarking RocksDB Key-Value Workloads at Facebook

这是一篇对于Fackbook使用的RocksDB的KV负载的测试文章，作者对RocksDB的三个用例

• 1）UDB
• 2）ZippyDB
• 3）UP2X
  进行了测试。这三个用例分别作为1）SQL数据库的存储引擎，2）分布式KV-store的存储引擎，以及3）人工智能/机器学习（AI/ML）服务的持久存储。
  文章中做了大量测试，这里只给出部分细节。

key-value size

AVG代表的是平均值，SD代表的是标准差。

• UDB
  • 平均Key大小在16到30字节之间，但Assoc_2ry除外，它的平均Key大小为64字节。Assoc_2ry中的键由4字节MySQL表索引、两个对象ID、对象类型和其他信息组成。因此，Assoc_2ry的密钥大小通常大于50字节，并且具有长尾分布。极少数KV对的Key大小大于1 KB。
  • 对象的值大小从16字节到10 KB不等，超过20%的值大小大于1 KB。对象中KV对的平均值大小约为1 KB，中值约为235B。
• ZippyDB
  • Key是由ObjStorage元数据组成的，所以键的大小相对较大。几乎所有的Key大小都在两个大小范围内：[48，53]和[90，91]。
  • Value大小是从Put查询中收集的，值大小分布有一个非常长的尾巴：大约1%的值大小大于400字节。大约0.05%的值大小超过1 KB。有些值的大小甚至大于100 KB。然而，大多数KV对的值很小。超过90%的值大小小于34字节，甚至小于Key大小。
• UP2X
  • UP2X与前两者不同，up2x的key没有什么明显的分布，主要的key大小是9B，同时不怎么put。
  • Value大小可以大于100KB，但是主要还是与Key一起按照64B对齐存放

局部性分析

UDB

• Get
  • 超过60%的Key只被Get一次
• Put
  • 超过75%的Key只被Put一次，只有大概2%的key会被写10次
• Iterator_seek
  • 只有不到1%的Key会被多次写

ZippyDB

如上图所示

• Get
  • 对于80%以上的kV对，Get只发生一次。大约1%的KV对显示超过100个Get请求，这些KV对的Get约占显示强局部性的Get总数的50%
• Put
  • 相比之下，约73%的KV对仅Put一次，不到0.001%的KV对Put10次以上。
• Iterator_seek
  • 大约55%的KV对被用作Iterator_seek的开始键1次，6%的KV对11次，11%的KV对12次，5%的KV对13次，10%的KV对23次，10%的KV对46次。

UP2X

定义访问10次以上为热数据
如上图所示

• Get
  • 热数据约为50%
• Put
  • 热数据占比非常小
• Merge
  • 热数据约为25%

UDB热点数据访问图

UDB的热点数据分布图，get和put的数据热点相近，经常get的key同时也会经常put，X轴是对象编号按照时间递增，纵轴是访问次数 Assoc_count 代表 the number of associations of each object.