[解決済み] NoSQLデータストアを使用して、どのようなスケーラビリティの問題が発生しましたか？[クローズド］

質問内容

NoSQLとは、リレーショナルデータベースやACID保証の歴史と決別した非リレーショナルデータストアのことである。人気のあるオープンソースのNoSQLデータストアは以下の通りです。

• カサンドラ (表形式、Javaで記述、Cisco、WebEx、Digg、Facebook、IBM、Mahalo、Rackspace、Reddit、Twitterで使用されている)
• CouchDB (ドキュメント、Erlangで書かれており、BBCとEngine Yardで使用されている)
• ダイノマイト (キー・バリュー、Erlangで記述、Powersetで使用)
• HBase (キーバリュー、Javaで記述、Bingで使用）。
• ハイパーテーブル (表形式、C++で記述、Baiduで使用)
• Kai (キー・バリュー、Erlangで書かれています)
• MemcacheDB (キー・バリュー、Cで書かれており、Redditで使用されている)
• モンゴDB (ドキュメント、C++で記述、Electronic Arts、Github、NY Times、Sourceforgeで使用)
• Neo4j (グラフ、Javaで書かれ、スウェーデンのいくつかの大学で使用されている)
• プロジェクトVoldemort (キー・バリュー、Javaで記述、LinkedInで使用）。
• レディス (キーバリュー、Cで書かれており、Craigslist、Engine Yard、Githubで使用されている)
• Riak (キーバリュー、Erlangで書かれており、ComcastとMochi Mediaが使用している)
• リンゴ (キー・バリュー、Erlangで記述、Nokiaが使用)
• スカラリス (キー・バリュー、Erlangで記述、OnScaleで使用)
• テラストア (ドキュメント、Javaで書かれています)
• スルーDB (ドキュメント、C++で記述、JunkDepot.comで使用)
• 東京内閣/東京タイラント (Mixi.jpで使用されているC言語で書かれたキー・バリューです。

SOの読者の皆さんがデータストアを利用して解決した具体的な問題や、どのようなNoSQLデータストアを利用したかについて教えてください。

質問内容

• NoSQLデータストアを使用して、どのようなスケーラビリティの問題を解決しましたか？
• どのようなNoSQLデータストアを使用しましたか？
• NoSQLデータストアに変更する前に使用していたデータベースを教えてください。

実体験が欲しいので、それがない限り回答はご遠慮ください。

解決方法は？

私は負荷を扱うことができるように、MySQLからCouchDBに小さなサブプロジェクトを切り替えました。結果は驚くべきものでした。

2年ほど前に、自作ソフトを http://www.ubuntuusers.de/ (おそらくドイツ最大の Linux コミュニティのウェブサイト）。このサイトは Python で書かれており、すべての例外をキャッチして MySQL を使用する別の小さな Web サイトに送信する WSGI ミドルウェアが追加されています。この小さなウェブサイトは、異なるバグを決定するためにハッシュを使用し、発生回数と最後の発生も保存しました。

残念ながら、リリース直後からtraceback-loggerのウェブサイトが反応しなくなってしまいました。私たちのメインサイトの本番用データベースには、ほぼすべてのリクエストで例外をスローするロックの問題があり、また、テスト段階では調査していなかった他のいくつかのバグもありました。メインサイトのサーバークラスタが、トレースバック・ロガーのサブミット・ページを1秒間に数千回呼び出したのです。これは、トレースバック・ロガーをホストしている小さなサーバー（すでに古いサーバーで、開発目的にのみ使用されていました）には多すぎました。

この時点でCouchDBはむしろ人気があったので、私はそれを試してみて、それを使用して小さなトレースバック-ロガーを書くことにしました。新しいロガーは、ソートやフィルタオプションと送信ページとバグリストを提供し、単一のPythonファイルで構成されていました。そして、バックグラウンドで私はCouchDBプロセスを開始しました。新しいソフトウェアは、すべてのリクエストに非常に迅速に応答し、我々は自動バグレポートの膨大な量を表示することができました。

一つ興味深いのは、以前のソリューションは、古い専用サーバー上で実行されていた一方で、新しいCouchDBベースのサイトは、非常に限られたリソースで共有xenインスタンス上で実行されていたことです。そして、私も水平方向に拡張するためのキー値ストアの強みを使用していない。CouchDB / Erlang OTPの能力は、何もロックせずに同時リクエストを処理するために、すでにニーズを満たすのに十分であった。

さて、すぐに書かれたCouchDB-トレースバックロガーはまだ実行されており、メインウェブサイト上のバグを探索するのに便利な方法です。とにかく、約一ヶ月に一度、データベースがあまりにも大きくなり、CouchDBプロセスが殺される。しかし、その後、CouchDBのコンパクト-dbコマンドは、再びいくつかのKBに数GBからサイズを減らし、データベースが再び稼働しています（多分私はそこにcronjobを追加することを検討する必要があります...0o）。

要約すると、CouchDBは確かにこのサブプロジェクトのための最良の選択（または少なくともMySQLよりも良い選択）であり、それはよくその仕事をしています。