6

I'm looking for a key value store that can be used from an EC2 instance.

  • item is just an unstructured string, no indexing required
  • item size up to ~5MB but usually below 10kB
  • lots of writes
  • reading doesn't need to be fast, memcache can be put in front that caches frequently needed reads
  • data is too big to fit into memory
  • Eventual Consistency is fine
  • daemon that can be accessed from multiple machines is required

Ideally something AWS hosted would be perfect but:

  • S3 doesn't fit because of too many writes
  • SimpleDB/DynamoDb don't fit because of item size limits and indexing is not required

As there are a lot of key value stores on the market it's hard to choose the best one. Which one would you recommend?

4

4 に答える 4

6

私のユースケースに最適なソリューションを見つけました：memcachedb

派手なドキュメント/インデックス作成は行わず、単なるキー値ストアです。

ただし、パフォーマンステストはまだ行っていません。

編集：

レプリケーションの問題のため、memcachedbを削除しました。代わりに、mongodbを実行します。Mongodbは、より多くのディスクスペースと、一般的にはより多くのリソースを必要とします。ただし、レプリカセットは非常に信頼性が高く、セットアップも簡単です。

于 2012-11-21T10:26:36.210 に答える
2

たぶんあなたはmongodbを試してみるべきです：
http ：//www.mongodb.org/display/DOCS/Amazon+EC2

クイックスタート：
http ：//www.mongodb.org/display/DOCS/Amazon+EC2+Quickstart

10genの無料コースとビデオプレゼンテーション：
http ：//www.10gen.com/presentations/nyc-meetup-group/mongodb-and-ec2-a-love-story

その他のKey-Valueストレージ：http：
//google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html

Riakとそのストレージ、特にbitcaskとinnostoreに関するコメント：http：
//basho.com/blog/technical/2011/07/01/Leveling-the-Field/

RaptorDB：b + treeまたはMurMurハッシュインデックスを使用した、非常に小さいサイズで高速に埋め込まれたnoSqlの永続化された辞書データベース。これは主にJSONデータを格納するように設計されています（私のfastJSON実装を参照）が、指定した任意のタイプのデータを格納できます。

HamsterDB：C ++で記述された楽しいエンジンで、インデックス作成にAaronsWattersコードを使用しているときの速度に大きな感銘を受けました。（RaptorDBは今それを生きたまま食べています...ええと！）64ビット版では600KBとかなり大きいです。

Esent PersistentDictionary：組み込みのWindowsesentデータストレージエンジンにマネージラッパーを実装する別のプロジェクトの一部であるCodePlex上のプロジェクト。ディクショナリのパフォーマンスは、40,000アイテムのインデックスが作成された後、指数関数的に低下し、インデックスファイルはGUIDキーで大きくなります。どうやらプロジェクトの所有者と話し合った後、それは現時点で既知の問題です。

東京/京都内閣：非常に高速なキーストアのC++実装。東京キャビネットはb+ツリーインデクサーであり、京都キャビネットはMurMur2ハッシュインデクサーです。

4aTech Dictionary：これはCodeProjectに関する別の記事で、同じことを行います。Webサイトの商用バージョンは巨大（450KB）であり、50,000アイテムのインデックスが作成された後、GUIDキーのパフォーマンスが低下します。

BerkeleyDB：Oracleが所有し、C ++キーストア、Javaキーストア、XMLデータベースの3つのフレーバーで提供されるすべてのデータベースの祖父。

（引用元： http： //www.codeproject.com/Articles/190504/RaptorDB）

于 2012-11-20T22:08:15.440 に答える
2

HBaseの完璧なユースケースのようです。特に挿入キーがややランダムである場合は、書き込みスループットが向上します。HBaseは通常K/Vストアとしてアドバタイズされませんが、問題なく動作するはずです。AWSのドキュメントには、詳しく調べたいと思われるいくつかのユースケースが示されています。欠点は、HBaseがK / Vだけでなく多くのことを実行できることです。そのため、必要なものよりも複雑（および複雑）になる可能性があります。

于 2012-11-27T19:41:29.567 に答える
1

Couchbaseはあなたのニーズにぴったりのように聞こえます。これは、ディスクストレージでmemcachedを使用するのとよく似ています。

長所：

  • これは、キー/値データベースです。必要なバイナリブロブを保存できます。バージョン2.0以降、データをjsonとして保存し、いくつかのクエリを実行してマップ/リデュースすることがサポートされています。ただし、それが必要ない場合は、キー/値として使用すると効果的です。

  • 私が試したすべてのNoSQLデータベースの中で、これが最速です。これは、書き込みがすぐにディスクにコミットされていないことが原因である可能性があります。代わりに、書き込みがクラスターに複製されると、確認応答を受け取ります。データは非同期でディスクに書き込まれます。したがって、潜在的な欠点の1つは、すべてのノードが同時にクラッシュした場合（たとえば、データセンターの電源が切れた場合）、データが失われる可能性があることです。アプリケーションによっては、これが問題になる場合とそうでない場合があります（クラスター全体がダウンした場合は、おそらくより大きな問題が発生します）。

  • 私の経験では、それは信頼できました。ノードがダウンしても、クラスターは機能し続け、フェイルオーバーを実行するのは非常に簡単です。新しいノードの追加も非常に簡単です。

  • データはメモリに収まる必要はありません。ディスクに保存され、必要に応じてページインおよびページアウトされます。

  • 管理インターフェースはとてもとても素敵です。クラスターを監視するための気の利いたライブグラフがあります。

  • memcachedプロトコルとの下位互換性があります。memcachedを使用するコードがすでにある場合は、代わりにCouchbaseを使用するのは非常に簡単です。

短所：

  • 製品はまだやや若いため、ドキュメントとサポートツールがやや不足しています。これは時々少し面倒かもしれません。
于 2012-11-27T21:20:52.780 に答える