40

I need a fast, reliable and memory-efficient key--value database for Linux. My keys are about 128 bytes, and the maximum value size can be 128K or 256K. The database subsystem shouldn't use more than about 1 MB of RAM. The total database size is 20G (!), but only a small random fraction of the data is accessed at a time. If necessary, I can move some data blobs out of the database (to regular files), so the size gets down to 2 GB maximum. The database must survive a system crash without any loss in recently unmodified data. I'll have about 100 times more reads than writes. It is a plus if it can use a block device (without a filesystem) as storage. I don't need client-server functionality, just a library. I need Python bindings (but I can implement them if they are not available).

Which solutions should I consider, and which one do you recommend?

Candidates I know of which could work:

  • Tokyo Cabinet (Python bindings are pytc, see also pytc example code, supports hashes and B+trees, transaction log files and more, the size of the bucket array is fixed at database creation time; the writer must close the file to give others a chance; lots of small writes with reopening the file for each of them are very slow; the Tyrant server can help with the lots of small writes; speed comparison between Tokyo Cabinet, Tokyo Tyrant and Berkeley DB)
  • VSDB (safe even on NFS, without locking; what about barriers?; updates are very slow, but not as slow as in cdb; last version in 2003)
  • BerkeleyDB (provides crash recovery; provides transactions; the bsddb Python module provides bindings)
  • Samba's TDB (with transactions and Python bindings, some users experienced corruption, sometimes mmap()s the whole file, the repack operation sometimes doubles the file size, produces mysterious failures if the database is larger than 2G (even on 64-bit systems), cluster implementation (CTDB) also available; file grows too large after lots of modifications; file becomes too slow after lots of hash contention; no built-in way to rebuild the file; very fast parallel updates by locking individual hash buckets)
  • aodbm (append-only so survives a system crash, with Python bindings)
  • hamsterdb (with Python bindings)
  • C-tree (mature, versatile commercial solution with high performance, has a free edition with reduced functionality)
  • the old TDB (from 2001)
  • bitcask (log-structured, written in Erlang)
  • various other DBM implementations (such as GDBM, NDBM, QDBM,, Perl's SDBM or Ruby's; probably they don't have proper crash recovery)

I won't use these:

  • MemcacheDB (client-server, uses BereleleyDB as a backend)
  • cdb (needs to regenerate the whole database upon each write)
  • http://www.wildsparx.com/apbcdb/ (ditto)
  • Redis (keeps the whole database in memory)
  • SQLite (it becomes very slow without periodic vacuuming, see autocompletion in the in the location bar in Firefox 3.0, even though versions 3.1 and later of sqlite allow auto_vacuuming; beware: small writing transactions can be very slow; beware: if a busy process is doing many transactions, other processes starve, and they can never get the lock)
  • MongoDB (too heavy-weight, treats values as objects with internal structure)
  • Firebird (SQL-based RDBMS, too heavy-weight)

FYI, a recent article about key--value databases in the Linux magazine.

FYI, an older software list

FYI, a speed comparison of MemcacheDB, Redis and Tokyo Cabinet Tyrant

Related questions on StackOverflow:

4

10 に答える 10

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 はインメモリのみの DB であるため、1MB の RAM 要件には役に立ちません。)

LMDB は Python でも十分にサポートされており、いくつかの異なるバインディングが利用可能です。 https://github.com/dw/py-lmdb/ https://github.com/tspurway/pymdb-lightning

免責事項 - 私は LMDB の作成者です。しかし、これらは文書化された事実です。LMDB は、世界で最も小さく、最も効率的で、最も信頼性の高いキー/バリュー ストアであり、それに匹敵するものは他にありません。

于 2014-08-04T17:02:36.010 に答える
2

Tokyo Cabinet/pytc ソリューションでうまくいきました。読み取りと書き込みの両方で非常に高速です (私の実装で anydbm を使用して shelve モジュールを使用するよりも少し高速です) (ただし、私もはるかに多くの読み取りを行います)。私にとっての問題は、Pythonバインディングに関する質素なドキュメントでしたが、必要なことを行う方法を理解するのに十分なサンプルコードがあります。さらに、tokyo Cabinet はインストールが非常に簡単で (Python バインディングと同様)、サーバーを必要とせず (あなたが言及したように)、積極的にサポートされているようです(安定していますが、アクティブな開発は行われていません)。同時アクセスを許可する読み取り専用モードでファイルを開くか、他のプロセスがデータベースにアクセスできないようにする読み取り/書き込みモードでファイルを開くことができます。

夏の間、さまざまなオプションを検討していましたが、そのときに得たアドバイスは次のとおりです。さまざまなオプションを試して、自分に最適なものを見つけてください. 単に「最良の」オプションがあればいいのですが、誰もがわずかに異なる機能を求めており、さまざまなトレードオフを喜んで行っています。あなたが一番よく知っています。

（そうは言っても、最終的に何があなたにとって最も効果的であったか、そして他の解決策よりもその解決策を選択した理由を共有すると、他の人にとって役に立ちます！）

于 2009-11-18T18:51:30.843 に答える
2

cdb は 4 GB までの任意のデータベースを処理できるため、手元にある 20 GB の問題には小さすぎます。

于 2009-12-01T01:03:03.860 に答える
1

もう 1 つの提案は、 TDB (Samba プロジェクトの一部) です。私はtdbモジュールを介して使用しましたが、クラッシュ時の信頼性をテストしたとは言えません。私が使用したプロジェクトにはそのような要件がなく、関連するドキュメントが見つかりません。

于 2009-11-18T23:56:55.867 に答える
0

how about a SQLite?

于 2009-11-06T21:34:39.597 に答える
0

I've used bsddb.hashlib() with Python, it worked pretty good.

于 2009-11-06T21:35:51.900 に答える
0

クロスプラットフォームの ISAM スタイルのデータベース (類似) に関する私のクエリでは、FirebirdとGLibの組み込みバージョンに関する提案も受け取りました。

于 2009-12-01T00:42:06.210 に答える
0

あなたが言及したプロパティを持つdjbのcdbが好きかもしれません。

于 2009-11-06T21:37:01.277 に答える