适用于Linux的可靠高效的键值数据库?

pts*_*pts 39 python database store key-value embedded-database

我需要一个快速,可靠且内存有效的Linux键值数据库.我的密钥大约是128个字节,最大值大小可以是128K或256K.数据库子系统不应使用超过大约1 MB的RAM.总数据库大小为20G(!),但一次只访问一小部分数据.如果有必要,我可以将一些数据blob从数据库中移出(到常规文件),因此大小最多可降至2 GB.数据库必须在系统崩溃后继续存在,而不会丢失最近未修改的数据.我的读取次数比写入次数多100倍.如果它可以使用块设备(没有文件系统)作为存储,那么这是一个加分.我不需要客户端 - 服务器功能,只需要一个库.我需要Python绑定(但如果它们不可用,我可以实现它们).

我应该考虑哪些解决方案,您建议使用哪种解决方案?

我知道哪些候选人可以工作:

  • Tokyo Cabinet(Python绑定是pytc,另见pytc示例代码,支持哈希和B +树,事务日志文件等等,桶数组的大小在数据库创建时固定; 编写器必须关闭文件以给其他人一个很多小写,重新打开每个文件都很慢; Tyrant服务器可以帮助处理大量的小写; 东京内阁,东京暴君和伯克利数据库之间的速度比较)
  • VSDB(即使在NFS上也是安全的,没有锁定;那么障碍呢?;更新非常慢,但不像cdb那么慢; 2003年的最新版本)
  • BerkeleyDB(提供崩溃恢复;提供事务; bsddbPython模块提供绑定)
  • Samba的TDB(使用事务和Python绑定,一些用户经历了损坏,有时mmap()是整个文件,repack操作有时会使文件大小翻倍,如果数据库大于2G(即使在64位系统上)也会产生神秘的故障,集群实现(CTDB也可用;文件经过大量修改后变得太大;文件在大量哈希争用后变得太慢;没有内置方法来重建文件;通过锁定单个哈希桶来实现非常快速的并行更新)
  • aodbm(仅附加,因此系统崩溃,使用Python绑定)
  • hamsterdb(使用Python绑定)
  • C-tree(具有高性能的成熟,多功能商业解决方案,具有功能减少的免费版本)
  • TDB(自2001年起)
  • bitcask(日志结构,用Erlang编写)
  • 各种其他DBM实现(例如GDBM,NDBM,QDBM,Perl的SDBM或Ruby;可能他们没有适当的崩溃恢复)

我不会用这些:

  • MemcacheDB(客户端 - 服务器,使用BereleleyDB作为后端)
  • cdb(需要在每次写入时重新生成整个数据库)
  • http://www.wildsparx.com/apbcdb/(同上)
  • Redis(将整个数据库保存在内存中)
  • SQLite(它没有定期抽真空就变得非常慢,请参阅Firefox 3.0中位置栏中的自动完成,即使版本3.1及更高版本的sqlite允许auto_vacuum;注意:小写入事务可能非常慢;注意:如果繁忙的过程是做很多交易,其他流程都饿了,他们永远无法获得锁定)
  • MongoDB(太重了,将值视为具有内部结构的对象)
  • Firebird(基于SQL的RDBMS,太重了)

仅供参考,最近一篇关于 Linux杂志中关键值数据库的文章.

仅供参考,一个较旧的软件列表

仅供参考,MemcacheDB,Redis和Tokyo Cabinet Tyrant速度比较

有关StackOverflow的相关问题:

hyc*_*hyc 9

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

与Bitcask一样,BerkeleyDB也有充分记录的腐败问题.(而bitcask无论如何都只是一个内存中的数据库,因此对你的1MB RAM要求毫无用处.)

LMDB在Python中也得到了很好的支持,可以使用几种不同的绑定. https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

免责声明 - 我是LMDB的作者.但这些都是记录在案的事实:LMDB是世界上最小,最有效,最可靠的键/值存储,没有其他任何东西可以接近.


Noa*_*oah 2

我对东京内阁/pytc 解决方案很幸运。它非常快(比在我的实现中使用anydbm使用shelve模块快一点),无论是读取还是写入(尽管我也做了更多的阅读)。对我来说,问题是关于 python 绑定的斯巴达文档,但是有足够的示例代码来弄清楚如何做你需要做的事情。此外,tokyo Cabinet 非常容易安装(Python 绑定也是如此),不需要服务器(正如您提到的)并且似乎受到积极支持(稳定但不再处于积极开发状态)。您可以以只读模式打开文件,允许并发访问,也可以以读/写模式打开文件,以防止其他进程访问数据库。

整个夏天我一直在考虑各种选择,当时我得到的建议是:尝试不同的选择,看看什么最适合你。如果只有一个“最佳”选择,那就太好了,但每个人都在寻找略有不同的功能,并愿意做出不同的权衡。你最了解。

(也就是说,如果您分享最终最适合您的方法以及为什么您选择该解决方案而不是其他解决方案,这对其他人会很有用!)