どのキー/値ストアが最も有望/安定していますか？
いくつかのサイドプロジェクト（主に学習体験として）にキー/値ストアを使い始めたいと思っていますが、最近多くの人がポップアップしたので、どこから始めればよいかわかりません。メモリからリストするだけで、次のことが考えられます。
- CouchDB
- MongoDB
- リアック
- Redis
- 東京キャビネット
- バークレーDB
- Cassandra
- MemcacheDB
そして、私の検索の努力をすり抜けてきたものがもっとたくさんあると確信しています。そこにすべての情報があるので、競合他社のすべての間で確実な比較を見つけることは困難です。私の基準と質問は次のとおりです。
- （最も重要）どちらを推奨しますか、なぜ？
- どちらが最速ですか？
- どちらが最も安定していますか？
- セットアップとインストールが最も簡単なのはどれですか。
- Pythonおよび/またはRubyのバインディングがあるのはどれですか？
編集：
これまでのところ、Redisが最良のソリューションであるように見えますが、それは（ardsrkから）確実な応答が1つ得られたからです。彼のようなより多くの答えを探しています。なぜなら、それらは私に有用で定量的な情報の方向を示しているからです。どのKey-Valueストアでyoを使用し、-whyを使用しますか？
編集2：
CouchDB、Riak、またはMongoDBの経験をお持ちの方がいらっしゃったら、ぜひそれらの経験をお聞かせください（さらに、いくつかの比較分析を提供できる場合はさらに参考にしてください）。
あなたはどちらを勧めますか、そしてその理由は？
Redisをお勧めします。どうして？読み続けて！！
どちらが最速ですか？
最速かどうかはわかりません。しかし、Redisは fast です。すべてのデータをRAMに保持するため、高速です。最近、仮想メモリ機能が追加されましたが、すべてのキーはメインメモリに残り、ほとんど使用されない値のみがディスクにスワップされます。
どちらが最も安定していますか？
繰り返しますが、私は他のKey-Valueストアを直接経験していないので、比較できません。ただし、Redisは GitHub や Instagram などの多くのWebアプリケーションで本番環境で使用されています。
セットアップとインストールが最も簡単なのはどれですか。
Redisのセットアップはかなり簡単です。 source を取得し、Linuxボックスでmake installを実行します。これにより、redis-serverバイナリが生成され、パスに配置して開始できます。
redis-serverはデフォルトでポート6379にバインドします。ソースに付属するredis.confを見て、より多くの構成およびセットアップオプションを入手してください。
Pythonおよび/またはRubyのバインディングがあるのはどれですか？
Redisには、優れた Ruby および Python サポートがあります。
以下の Xorlevのコメント への対応：Memcachedは単純なKey-Valueストアです。 Redisは、リスト、セット、ソート済みセットのような複雑な データタイプ をサポートすると同時に、これらのデータタイプに シンプルインターフェース を提供します。
64ビットマシンでも、すべてのポインタのサイズを32ビットのみにするmake 32bitもあります。これにより、RAMが4GB未満のマシンのメモリが大幅に節約されます。
最新のNoSQL現象とは何かを理解する必要があります。
Key-Valueストレージについてではありません。それらは何十年もの間利用可能でした（例えば、BerkeleyDB）。なぜ今すべての大騒ぎ？
派手なドキュメントやオブジェクト指向のスキーマについてではなく、「インピーダンスの不一致」を克服するためのものではありません。これらの機能の支持者は何年もの間それらを売り込んできました、そして、彼らはどこにも行きませんでした。
それは、3つの技術的な問題に対処することです。自動（メンテナー向け）と透過（アプリケーション開発者向け）のフェイルオーバー、シャーディング、レプリケーションです。したがって、この面で提供されない流行の製品は無視する必要があります。これらには、Redis、MongoDB、CouchDBなどが含まれます。また、cassandra、riakなどの真に分散されたソリューションに集中してください。
そうしないと、SQLが提供するすべての優れた機能（アドホッククエリ、上司のためのCrystal Reports、サードパーティのツールおよびライブラリ）が失われ、何も返されません。
今年のPyConで、RedditのJeremy Edbergが講演しました：
http://pycon.blip.tv/file/3257303/
彼は、RedditがPostGresをKey-Valueストアとして使用し、おそらく単純な2列のテーブルを使用すると述べました。彼の話によると、それは彼らが試した他のどのキーバリューストアよりも速くベンチマークした。そしてもちろん、それは非常に成熟しています。
最終的に、OverClockedは正しいです。ユースケースが最適なストアを決定します。しかし、RDMBSはキーバリューストアとして長い間（ab）使用されており、非常に高速になることもあります。
私はMongoDBを使用してきましたが、これは私のアプリケーションに最適なものの1つです。複雑なマップ/リストをデータベースに直接保存できることです。各値がリストである大きなマップがあります。さまざまなキーとリスト値をすべて知らなくても、それを書き込んで取得するためだけに特別なことをする必要はありません。他のオプションについてはあまり知りませんが、スピードとその能力により、Mongoは私のアプリケーションに最適です。さらに、Javaドライバーは非常に簡単に使用できます。
それらはすべて異なる機能を備えています。そして、忘れないでください Project Voldemort これは、各リリースの前に本番環境でLinkedInによって実際に使用/テストされています。
比較するのは難しいです。必要なものを自問する必要があります。パーティション化しますか？もしそうなら、CouchDBのようなそれらのいくつかはそれをサポートしません。イレイジャーコーディングが必要ですか？そして、それらのほとんどはそれを持っていません。等。
Berkeley DBは非常に基本的な低レベルのストレージエンジンであり、おそらくこの議論から免除される可能性があります。その上にいくつかのキーバリューシステムが構築され、レプリケーション、バージョン管理、コーディングなどの追加機能を提供します。
また、アプリケーションには何が必要ですか？いくつかのソリューションには、必要ではないかもしれない複雑さが含まれています。例えば。変更されない静的データのみを保存する場合は、データのSHA-1コンテンツハッシュの下に保存できます（つまり、コンテンツハッシュをキーとして使用します）。この場合、鮮度、同期、バージョン管理について心配する必要はなく、多くの複雑さを取り除くことができます。
あなたがしなければならない1つの違いは、DBを何のために使うのですか？トレンディだからといって、飛び乗ってはいけません。キーバリューストアが必要ですか？または、ドキュメントベースのストアが必要ですか？あなたのメモリフットプリント要件は何ですか？小さなVMまたは別のもので実行していますか？
まず要件をリストしてから、要件と重複するものを確認することをお勧めします。
そうは言っても、私はCouchDB/MongoDBを使用しており、セットアップが簡単で、mysqlスタイルのクエリからの移行が最適なMongoDBを使用することを好みます。動的スキーマ（移行ファイルなし！）とより優れたデータモデリング（配列、ハッシュ）のため、sqlではなくmongodbを選択しました。スケーラビリティに基づく評価は行いませんでした。
MongoMapperは、Rubyの優れたMongoDB ormマッパーであり、すでに機能しているRails 3フォークがあります。
筆記用スライドでmongodbを選んだ理由の詳細をいくつかリストしました http://tommy.chheng.com/index.php/2010/02/mongodb-for-natural-development/
誰もがmemcachedとmemcachedbを混同していることに気づきました。彼らは2つの異なるシステムです。 opはmemcachedbについて尋ねました。
memcachedはメモリストレージです。 memcachedbはデータストアとしてBerkeley DBを使用します。
私はBerkeley DBの経験しかないので、私が気に入っている点について触れておきます。
- 速い
- とても成熟していて安定しています
- 優れたドキュメントがあります
- C、C++、Java、C＃のバインディングがそのまま使用できます。他の言語バインディングも利用できます。 Pythonには「バッテリー」の一部としてバインディングが付属していると思います。
私が遭遇した唯一の欠点は、C＃バインディングが新しく、すべての機能をサポートしているわけではないことです。
Zodbもあります。
どのキーバリューストアが最も有望で安定していますか？
G-WAN KVストア 見栄えが良い有望：
DB engine Traversal
----------- ----------------------------
SQLite 0.261 ms (b-tree)
Tokyo-Cabinet (TC) 4.188 ms (hash table)
TC-FIXED 0.103 ms (fixed-size array)
G-WAN KV 0.010 ms (unamed)
また、G-WANウェブサーバーによって内部的に使用され、高い同時実行性のパフォーマンスで知られています（これは安定性質問用です）。
私は個人的にmemcachedが本当に好きです。
私はいくつかのサイトで使用しており、シンプルで高速、そして簡単です。それは本当に信じられないほど簡単に使用でき、APIは使いやすいです。ディスクには何も保存しないため、memcachedという名前なので、永続的なストレージエンジンを探している場合は不便です。
Pythonにはpython-memcachedがあります。
私はRubyクライアントを使用していませんが、簡単なGoogle検索で明らかになりますRMemCache
キャッシュエンジンだけが必要な場合は、memcachedが適しています。それは開発されており、安定しており、高速です。 LiveJournalがそれを作り、Facebookがそれを開発した理由があります。それは大きな効果を発揮するためにいくつかの最大のサイトで使用されています。それは非常によくスケーリングします。
Cassandra は人気があるようです。
Cassandraは、Digg、Facebook、Twitter、Reddit、Rackspace、Cloudkick、Cisco、SimpleGeo、Ooyala、OpenXなど、大規模でアクティブなデータセットを持つ企業で使用されています。最大の本番クラスターには、150以上のマシンに100以上のTB=のデータがあります。
他の人が言ったように、それは常にあなたのニーズに依存します。たとえば、自分のアプリケーションに最も適したものが好きです。
最初にmemcachedを使用して、読み取り/書き込みアクセスを高速化しました。 Java APIとしてSpyMemcachedを使用しました。データの書き込みと読み取りに使用できる非常に簡単なインターフェースが付属しています。メモリリークのため（RAMはもうありません）、別のものを探す必要がありました。解決策、私は適切にスケーリングできませんでした、単一のプロセスのメモリを増やすだけでは良い成果ではないようです。
いくつか見直した後、couchbaseを見たところ、レプリケーション、クラスタリング、自動フェイルオーバー、コミュニティエディション（MS Windows、MacO、Linux）が付属しています。 JavaクライアントはSpyMemcachedも実装しているため、サーバーをセットアップし、データストアとしてmemcachedの代わりにcouchbaseを使用することはほとんど何もありませんでした。 、私のデータは永続化され、レプリケートされ、インデックスが作成されました。erlangでドキュメントビューのマップ削減関数を作成するためのWebコンソールが付属しています。
Python、Ruby、.Netなどをサポートし、webconsoleとclient-toolsから簡単に設定できます。安定して動作します。いくつかのテストで、200〜400バイトのレコードに対して毎秒約10kを書き込むことができました。ただし、読み取りパフォーマンスははるかに高かった（両方ともローカルでテストされた）。あなたの決断をするのがとても楽しいです。
リストを完成させるためだけに、Dreamcacheもあります。 Memcachedと互換性があり（プロトコルの観点から、Memcached用に作成された任意のクライアントライブラリを使用できます）、速度が向上します。
MongoDB、memchache、およびredisの経験があるだけです。以下は、それらとcouchDBの間の 比較 です。
MongoDBが最も人気があるようです。シャーディングとレプリケーションをサポートし、最終的には一貫していますが、Ruby（mongoid）で十分にサポートされています。また、他の2つよりも豊富な機能セットを備えています。mongo、redis、およびmemchacheのすべてがキーを保存できますメモリ内の値ですが、redisははるかに高速であるようです この投稿 によると、redisはmongoよりも書き込みが2倍、読み取りが3倍高速です。データ構造がよりよく設計され、より「軽量」になっています。
Megochacheとredisはキャッシュやログを格納するのに適していますが、mongoDBはおそらく大規模なデータセットとドキュメントのストレージに適しています。