这个问题来自于 OSDI 2020 Twitter 的工作[1],这篇文章中提到他们发现在 Twitter 内部的内存键值缓存集群的工作负载上发现在键上存在类似命名空间的切分使用情况,举例,键值对为"ns1:ns2:ns3, value1"。
但因为数据脱敏的原因,无从得知这样的特征是从何而来。
直观上,容易觉得这个特征就是命名空间,比如不同的应用使用的时候,设置属于自己的前缀。但从他们的公开数据集来看,层级高度很集中,键的分布也并不是树的生长方式(即越下层越多不同的 sub key )。
后来发现也有可能是某些应用是构建在键值存储引擎之上,如 MyRocks 使用 RocksDB 代替了 MySQL 中的 InnoDB,在一个键内保存了表存储的表索引、主键等信息。类似的还有 MongwoRocks, Azure Cosmos DB 。
但举的这些 DB 的例子都是构建在非缓存的键值存储系统( LSM Tree...)上,和前面提到的 Twitter 的场景不太匹配。。
我的问题就是,大家有没有见过类似的切分了一个键存多个数据的例子呢?
ref: