5

大きすぎたり分散したりしない、ディスク上のキー値ストアが必要です。ユースケースは次のとおりです。

  • 完全な DB のサイズは数 GB になります
  • キーと値の両方が一定のサイズです
  • その一定のデータベース。データベース全体が書き込まれたら、それ以上エントリを書き込む必要はありません (または非常にまれにしか書き込みません)。
  • キーは予​​測できない順序でアクセスされます
  • 複数のプロセスによる同時読み取りのサポートは必須です。
  • リーダーはタイトなループで数百万のキーにアクセスするため、非常に高速である必要があります。したがって、連想配列をループするのと同じくらいパフォーマンスにできるだけ近づける必要があります（STL's std::mapたとえば）
  • 理想的には、使用する RAM の量を設定できるようにする必要があります。通常は、数百 Mb を使用する必要があります。
  • C または C++ で書かれています。既存の python 拡張機能は大きなプラスになりますが、自分で追加できます

良い選択肢のようcdbにgdbm見えますが、もっと適切な選択肢があるかどうかを知りたいだけです。関連するベンチマークまたは関連する逸話的な証拠へのポインタも高く評価されます。

4

3 に答える 3

4

最終的にどのデータベースを使用しましたか?

cdb が好きで 4 GB 以上のデータベースが必要な場合は、mcdb をご覧ください。これはもともと cdb に基づいており、いくつかのパフォーマンス強化と 4 GB 以上の定数データベースのサポートが追加されています。

https://github.com/gstrauss/mcdb/

Python、Perl、Lua、および Ruby 拡張機能が提供されています。mcdb は C で書かれており、内部で mmap を使用しているため、スレッド間およびプロセス間でロックフリーの同時読み取りを簡単にサポートできます。メモリ マップ ファイルによってバックアップされるため、ページは必要に応じてディスクからマップされ、データベースにアクセスするプロセスの数が増加しても、メモリは実質的に一定です。

于 2012-11-16T04:59:43.283 に答える
0

あなたはbdbを見ましたか？BDBをうまく利用しているようです。

于 2012-06-22T02:58:56.823 に答える
0

私はそれを書いたのでhamsterdbが好きです:)

http://www.hamsterdb.com

  • 数 GB のデータベース サイズで頻繁に使用される
  • キー/値は任意のサイズにすることができます
  • ランダム アクセス + 方向アクセス (カーソルあり)
  • 同時読み取り: hamsterdb はスレッド セーフですが、まだ同時ではありません。私はこれに取り組んでいます。
  • キャッシュが十分に大きい場合、アクセスは非常に高速になります (キャッシュ サイズを指定できます)。
  • C++ で書かれた
  • python 拡張機能が利用可能ですが、ひどく時代遅れです。修正が必要になります

hamsterdb を評価して助けが必要な場合は、お気軽にメールをお送りください。

于 2012-06-22T14:07:01.010 に答える