BerkeleyDB also has well-documented corruption issues, as does Bitcask. (And bitcask is an in-memory-only DB anyway, so useless for your 1MB RAM requirement.)
Disclaimer - I am the author of LMDB. But these are documented facts: LMDB is the smallest, most efficient, and most reliable key/value store in the world and nothing else comes anywhere close.
I've had good luck with the Tokyo Cabinet/pytc solution. It's very fast (a bit faster than using the shelve module using anydbm in my implementation), both for reading and writing (though I too do far more reading). The problem for me was the spartan documentation on the python bindings, but there's enough example code around to figure out how to do what you need to do. Additionally, tokyo cabinet is quite easy to install (as are the python bindings), doesn't require a server (as you mention) and seems to be actively supported (stable but no longer under active development). You can open files in read-only mode, allowing concurrent access, or read/write mode, preventing other processes from accessing the database.
I was looking at various options over the summer, and the advice I got then was this: try out the different options and see what works best for you. It'd be nice if there were simply a "best" option, but everyone is looking for slightly different features and are willing to make different trade-offs. You know best.
(That said, it'd be useful to others if you shared what ended up working the best for you, and why you chose that solution over others!)
Another suggestion is TDB (a part of the Samba project). I've used it through the tdb module, however I can't say I've tested its reliability on crashes; the projects I used it in didn't have such requirements, and I can't find relevant documentation.
发布评论
评论（10）
LMDB 是内存效率最高的数据库
http://symas.com/mdb/inmem/
并且也被证明是最可靠的 - 完全防撞。
http://wisdom.cs.wisc.edu/workshops/spring -14/talks/Thanu.pdf
在你提到的那些中，东京内阁记录了腐败问题
https://www.google.com/search?q=cfengine+tokyo +cabinet+corruption
BerkeleyDB 也存在有据可查的腐败问题，Bitcask 也是如此。 （无论如何，bitcask 都是内存中的数据库，因此对于您的 1MB RAM 要求来说毫无用处。）
LMDB 在 Python 中也得到了很好的支持，有几个不同的可用绑定。
https://github.com/dw/py-lmdb/
https://github.com/tspurway/pymdb-lightning
免责声明 - 我是 LMDB 的作者。但这些都是有据可查的事实：LMDB 是世界上最小、最高效、最可靠的键/值存储，没有其他任何东西可以与之相媲美。
LMDB is the most memory-efficient database around
http://symas.com/mdb/inmem/
and also proven to be the most reliable - completely crash-proof.
http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf
Of the ones you've mentioned, Tokyo Cabinet has documented corruption issues
https://www.google.com/search?q=cfengine+tokyo+cabinet+corruption
BerkeleyDB also has well-documented corruption issues, as does Bitcask. (And bitcask is an in-memory-only DB anyway, so useless for your 1MB RAM requirement.)
LMDB is also well-supported in Python, with a couple different bindings available.
https://github.com/dw/py-lmdb/
https://github.com/tspurway/pymdb-lightning
Disclaimer - I am the author of LMDB. But these are documented facts: LMDB is the smallest, most efficient, and most reliable key/value store in the world and nothing else comes anywhere close.
我对东京内阁/pytc 解决方案很幸运。它非常快（比在我的实现中使用anydbm使用shelve模块快一点），无论是读取还是写入（尽管我也做了更多的阅读）。对我来说，问题是关于 python 绑定的斯巴达文档，但是有足够的示例代码来弄清楚如何做你需要做的事情。此外，tokyo Cabinet 非常容易安装（Python 绑定也是如此），不需要服务器（正如您提到的）
并且似乎得到了积极支持（稳定但不再处于积极开发中） 。您可以以只读模式打开文件，允许并发访问，也可以以读/写模式打开文件，以防止其他进程访问数据库。整个夏天我一直在考虑各种选择，当时我得到的建议是：尝试不同的选择，看看什么最适合你。如果只有一个“最佳”选择，那就太好了，但每个人都在寻找略有不同的功能，并愿意做出不同的权衡。你最了解。
（也就是说，如果您分享最终最适合您的方法以及为什么您选择该解决方案而不是其他解决方案，这对其他人会很有用！）
I've had good luck with the Tokyo Cabinet/pytc solution. It's very fast (a bit faster than using the shelve module using anydbm in my implementation), both for reading and writing (though I too do far more reading). The problem for me was the spartan documentation on the python bindings, but there's enough example code around to figure out how to do what you need to do. Additionally, tokyo cabinet is quite easy to install (as are the python bindings), doesn't require a server (as you mention)
and seems to be actively supported(stable but no longer under active development). You can open files in read-only mode, allowing concurrent access, or read/write mode, preventing other processes from accessing the database.I was looking at various options over the summer, and the advice I got then was this: try out the different options and see what works best for you. It'd be nice if there were simply a "best" option, but everyone is looking for slightly different features and are willing to make different trade-offs. You know best.
(That said, it'd be useful to others if you shared what ended up working the best for you, and why you chose that solution over others!)
cdb 可以处理最大 4 GB 的任何数据库，这对于手头的 20GB 数据来说太小了。
cdb can handle any database up to 4 GB, making it too small for the 20GB matter at hand.
Riak在Linux上运行，并允许您动态添加节点
Riak runs on Linux, and allows you to dynamically add nodes
Python 3.0 的 dbm.ndbm 怎么样？
how about Python 3.0's dbm.ndbm ?
另一个建议是TDB（Samba 项目的一部分）。我已经通过 tdb 模块使用了它，但是我不能说我'测试了其在碰撞时的可靠性；我用的项目没有这样的要求，也找不到相关文档。
Another suggestion is TDB (a part of the Samba project). I've used it through the tdb module, however I can't say I've tested its reliability on crashes; the projects I used it in didn't have such requirements, and I can't find relevant documentation.
SQLite 怎么样？
how about a SQLite?
我在 Python 中使用了 bsddb.hashlib() ，效果非常好。
I've used bsddb.hashlib() with Python, it worked pretty good.
您可能会喜欢 djb 的 cdb，它具有您提到的属性。
You might like djb's cdb, which has the properties you mention.
在 我的交叉查询-platform ISAM 风格的数据库（类似），我还收到了关于 Firebird 和 GLib。
In my query for a cross-platform ISAM-style database (similar), I also received suggestions for the embedded version of Firebird and GLib.