Although your application domain and data specifications are not clear; RocksDB, which is a recent solution for embedded persistent key-value storage, seems a fit for you. Benchmarks by Facebook show that it has better performance than LevelDB for server workloads and especially with data larger than RAM capacity. Also it is open-sourced under BSD license. You can find RocksDB C++ examples and more detail from here.
If we are strict, none of the suggested mainstream options are hash-maps. Such structures are rarely used for persistent storage because a good hash function would route to different buckets, even for similar keys. Similar keys generally imply related data that is often accessed together, so you want to avoid putting them on remote parts of the disk. Random read latency may be too high.
发布评论
评论（4）
最近有几个选项，它们都提供了 byte[] -> byte[] 映射，原子批量更新，并获得 BSD 许可：
来自 Google 的 Leveldb。
Facebook 的 RocksDB，它基于 Leveldb 的一个分支，并声称可以在 SSD 支持的存储上提供更高的性能。
There have been a couple of recent options, both of which provide a byte[] -> byte[] map, atomic batch updates, and are BSD licensed:
Leveldb from Google.
RocksDB from Facebook, which is based on a fork of Leveldb, and claims to provide higher performance on SSD backed storage.
虽然你的应用领域和数据规范不明确； RocksDB 是一种最新的嵌入式持久键值存储解决方案，似乎适合您。 Facebook 的基准测试表明，对于服务器工作负载，尤其是大于 RAM 容量的数据，它的性能优于 LevelDB。它也是在 BSD 许可下开源的。您可以从这里找到 RocksDB C++ 示例和更多详细信息。
Although your application domain and data specifications are not clear; RocksDB, which is a recent solution for embedded persistent key-value storage, seems a fit for you. Benchmarks by Facebook show that it has better performance than LevelDB for server workloads and especially with data larger than RAM capacity. Also it is open-sourced under BSD license. You can find RocksDB C++ examples and more detail from here.
*dbm 库怎么样？
dbm ndbm gdbm sdbm tdbm 和朋友们
有很多可供选择。
How about the *dbm libraries?
dbm ndbm gdbm sdbm tdbm and friends
Plenty to choose from.
如果我们严格来说，建议的主流选项都不是哈希映射。这种结构很少用于持久存储，因为好的哈希函数会路由到不同的存储桶，即使对于相似的键也是如此。相似的键通常意味着经常一起访问的相关数据，因此您希望避免将它们放在磁盘的远程部分。随机读取延迟可能太高。
最著名的匹配实现是来自 Microsoft 的 FASTER。
If we are strict, none of the suggested mainstream options are hash-maps. Such structures are rarely used for persistent storage because a good hash function would route to different buckets, even for similar keys. Similar keys generally imply related data that is often accessed together, so you want to avoid putting them on remote parts of the disk. Random read latency may be too high.
The most famous matching implementation would be FASTER from Microsoft.