MapDB对比RocksDB、LMDB：内置HTree/BTree实现优势咨询

MapDB双索引实现的场景优势 #

MapDB原生提供HTree、BTree两种开箱即用的存储访问实现，确实在特定场景下有明确优势，但优势边界很清晰：

• HTree是持久化哈希索引结构，单点读写时间复杂度稳定在O(1)，不需要维护Key的有序关系，适合纯点查、无范围扫描需求、追求极致写入/单点查询吞吐的场景，比如持久化缓存、会话信息存储、去重标记存储等。
• BTree是持久化B+树实现，天然支持Key有序遍历、范围查询、前缀匹配，适合需要做范围扫描、有序迭代的业务场景。
• 这两种实现是引擎层直接内置的，用户只需要在初始化DB时指定对应实现即可，不需要在上层做额外的索引封装、一致性校验、持久化逻辑开发，单引擎就能覆盖两类差异极大的访问模式需求，在多场景适配的开发效率上有明显优势。但要注意这个优势不是绝对性能优势：如果在上层为其他KV引擎封装适配同类型索引结构，性能并不会弱于MapDB的原生实现，只是需要额外的开发工作量。

RocksDB、LMDB的同类实现机制 #

两款产品并不是没有对应能力，只是没有像MapDB一样把两类实现作为并列的开箱默认选项直接暴露：

• LMDB的核心原生存储结构是Copy-On-Write实现的B+树，和MapDB的BTree实现能力完全对齐，原生支持有序范围扫描、事务ACID特性。但官方版本没有内置开箱即用的哈希索引实现，用户如果需要HTree类的纯点查优化，可以基于它提供的多命名空间、MDB_DUPSORT等基础接口，在上层自行封装持久化哈希结构。
• RocksDB默认使用LSM树作为核心存储结构，天然支持有序范围扫描，覆盖了BTree类实现的所有访问能力；同时它内置了可配置的PlainTable存储格式，搭配内置哈希索引，专门针对纯内存、低延迟点查场景优化，定位和MapDB的HTree完全一致，只需要在初始化时修改配置即可开启，不需要额外开发。除此之外RocksDB还开放了自定义表格式的扩展接口，用户可以自行实现任意结构的索引逻辑，灵活度更高。

做基准测试时需要注意：不同索引结构的设计目标存在本质差异，不要跨结构直接横比性能，需要对齐场景、配置对应结构后再做对照测试，否则测试结果不具备参考价值。

内容的提问来源于stack exchange，提问作者Awdsa