考虑到持久性键/值存储的以下要求：
考虑到这种使用模式：
根据要求，最佳的磁盘数据结构/算法是什么？
自定义实现是否可以超过基于LSM（Log Structured Merge）实现（即leveldb，rocksdb）的性能？
这些要求的高性能自定义实现在实现中是否也会相当简单？
答案 0 :(得分：4)
虽然可能有更好的性能自定义实现满足您的要求，但配置良好的RocksDB应该能够胜过大多数此类自定义实现。以下是我将配置RocksDB的内容：
首先，由于您没有更新和删除，因此最好将所有数据压缩到RocksDB中的大文件。因为RocksDB以可自定义的顺序对这些键进行排序，所以拥有一些大文件可以提高读取性能，因为跨一些大文件的二进制搜索比跨多个小文件更快。通常，拥有大文件会损害压缩的性能 - 重新组织RocksDB中的大部分数据的过程，以便1.合并与单个密钥相关的多个更新; 2.执行删除以释放磁盘空间; 3.保持数据排序。但是，由于您没有更新和删除，因此使用大文件可以提供快速的读写性能。
其次，为bloom过滤器指定大位，这样，当您可能发出一些ROCKDB中不存在密钥的查询时，可以避免大多数IO。
所以读取请求是这样的。首先，它将查询键与这些大文件的键范围进行比较，以确定查询键可能位于哪个文件中。然后，一旦密钥范围覆盖查询密钥的文件，它将计算查询密钥的bloom位以查看查询密钥是否可能存在于那些文件中。如果是这样，那么将触发每个文件内的二进制搜索以识别匹配的数据。
对于扫描操作，由于RocksDB在内部按用户自定义顺序对数据进行排序，因此可以使用RocksDB的迭代器非常有效地进行扫描。
有关RocksDB基础知识的更多信息，请参阅here。