NoSQLデータストアを使用して、どのようなスケーラビリティの問題が発生しましたか？
NoSQLは、リレーショナルデータベースの履歴とACIDの保証に違反する非リレーショナルデータストアを指します。人気のあるオープンソースのNoSQLデータストアには次のものがあります。
- Cassandra （Javaで記述された表形式、Cisco、WebEx、Digg、Facebook、IBM、Mahalo、Rackspace、Reddit、Twitterで使用）
- CouchDB （BBCとEngine Yardが使用する、Erlangで書かれたドキュメント）
- ダイノマイト （Key-Value、Erlangで記述、Powersetで使用）
- HBase （Javaで記述され、Bingで使用されるKey-Value）
- Hypertable （C++で記述された表、Baiduで使用）
- Kai （Key-Value、Erlangで記述）
- MemcacheDB （Key-Value、Cで記述、Redditで使用）
- MongoDB （C++で書かれ、Electronic Arts、Github、NY TimesおよびSourceforgeで使用されるドキュメント）
- Neo4j （Javaで書かれたグラフで、スウェーデンのいくつかの大学で使用されています）
- Project Voldemort （Javaで記述され、LinkedInで使用されるKey-Value）
- Redis （Cで記述され、Craigslist、Engine Yard、およびGithubで使用されるKey-Value）
- Riak （Erlangで記述され、ComcastおよびMochi Mediaで使用されるKey-Value）
- Ringo （key-value、Erlangで記述され、Nokiaが使用）
- Scalaris （Key-Value、Erlangで記述、OnScaleで使用）
- Terrastore （Javaで書かれたドキュメント）
- ThruDB （JunkDepot.comが使用するC++で書かれたドキュメント）
- Tokyo Cabinet/Tokyo Tyrant （Mixi.jp（日本のソーシャルネットワーキングサイト）が使用するCで記述されたKey-Value）
SOリーダー-データストアと使用したNoSQLデータストアを使用して解決した特定の問題について知りたいです。
質問：
- NoSQLデータストアを使用して解決したスケーラビリティの問題
- どのNoSQLデータストアを使用しましたか？
- NoSQLデータストアに切り替える前にどのデータベースを使用しましたか？
私は直接の経験を探しているので、それがない限り答えないでください。
負荷を処理できるように、小さなサブプロジェクトをMySQLからCouchDBに切り替えました。結果は素晴らしかった。
約2年前、私たちは http://www.ubuntuusers.de/ （おそらく最大のドイツLinuxコミュニティWebサイト）で自作ソフトウェアをリリースしました。このサイトはPythonで書かれており、すべての例外をキャッチしてMySQLを使用する別の小さなWebサイトに送信できるWSGIミドルウェアを追加しました。発生回数と最後の発生も保存しました。
残念ながら、リリース後間もなく、traceback-logger Webサイトは応答しなくなりました。メインサイトの本番データベースにはロックの問題があり、ほとんどすべてのリクエストが例外をスローしていましたが、テスト段階ではまだ調査していなかった他のバグもいくつかありました。メインサイトのサーバークラスターは、トレースバックロガーの送信ページと呼ばれ、1秒あたり数回kです。そして、それは、トレースバックロガーをホストする小さなサーバーには大きすぎました（既に古いサーバーであり、開発目的でのみ使用されていました）。
現時点ではCouchDBはかなり人気があったため、試してみて、小さなトレースバックロガーを作成することにしました。新しいロガーは、単一のpythonファイルのみで構成されていました。このファイルは、並べ替えおよびフィルターオプションと送信ページを含むバグリストを提供しました。バックグラウンドでCouchDBプロセスを開始しました。すべてのリクエストに非常に迅速に対応し、大量の自動バグレポートを表示することができました。
1つの興味深い点は、以前のソリューションは古い専用サーバーで実行されていましたが、新しいCouchDBベースのサイトは非常に限られたリソースの共有xenインスタンスでのみ実行されていたことです。また、Key-Valueストアの強度を使用して水平方向にスケーリングすることもしていません。 CouchDB/Erlang OTPが何もロックせずに同時リクエストを処理する能力は、すでにニーズを満たすのに十分でした。
現在、迅速に記述されたCouchDB-tracebackロガーはまだ実行されており、メインWebサイトのバグを調べるのに役立ちます。とにかく、月に1回程度、データベースが大きくなりすぎて、CouchDBプロセスが強制終了されます。しかし、その後、CouchDBのcompact-dbコマンドは、サイズを数GBから数KBに再び縮小し、データベースが再び稼働します（そこにcronjobを追加することを検討する必要があります... 0o）。
要約すると、CouchDBはこのサブプロジェクトにとって間違いなく最良の選択（または少なくともMySQLよりも良い選択）であり、その仕事はうまくいきます。
実際に私の現在のプロジェクト。
正規化された構造で18,000個のオブジェクトを保存：8つの異なるテーブルに90,000行。それらを取得して、Javaオブジェクトモデルにマップし、すべてが正しくインデックス付けされるなど）するのに1分かかりました。
軽量テキスト表現を使用してキー/値のペアとして保存します。1つのテーブル、18,000行、3秒ですべてを取得し、Javaオブジェクトを再構築します。
ビジネス用語：最初のオプションは実行不可能でした。 2番目のオプションは、アプリが機能することを意味します。
技術の詳細：SQLとNoSQLの両方でMySQLを実行しています！優れたトランザクションサポート、パフォーマンス、およびデータを破損しないための実績、実績のあるスケーリング、クラスタリングのサポートなどのためにMySQLにこだわります。
MySQLのデータモデルは、キーフィールド（整数）と大きな「値」フィールドになりました。基本的には大きなTEXTフィールドです。
新しいプレーヤー（CouchDB、Cassandra、MongoDBなど）は使用しませんでした。それぞれが優れた機能/パフォーマンスを提供しますが、私たちの状況には常に欠点がありました（例：missing/immature Javaサポート）。
MySQLを（ab）使用することの追加の利点-doがリレーショナルに機能するモデルの一部は、キー/値ストアデータに簡単にリンクできます。
更新：これは、上司が私を撃ったときの実際のビジネスドメイン（「製品」では動作しません）ではなく、テキストコンテンツを表す方法の例ですが、再帰的な側面（ここでは1つのエンティティ、他の「を含む」製品）。うまくいけば、正規化された構造では、これがかなりの数のテーブルになる可能性があることが明らかです。他の製品が含まれるフレーバーの範囲に製品を結合するなど
Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={Nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]
Todd Hoffの highscalability.com には、いくつかのケーススタディを含め、NoSQLについて多くの素晴らしい記事があります。
商用の Vertica カラムナーDBMSは（SQLをサポートしているとしても）目的に合うかもしれません：分析クエリの従来のリレーショナルDBMSと比較して非常に高速です。 Stonebraker等の 最近のCACM論文 Verticaとmap-reduceの対比を参照してください。
更新：そして Twitterが選択したCassandra HBase、Voldemort、MongoDB、MemcacheDB、Redis、HyperTableを含む他のいくつかのものよりも。
更新2：Rick Cattellは High Performance Data Stores でいくつかのNoSQLシステムの比較を公開しました。また、リックの論文に対するhighscalability.comの見解は こちら です。
データの一部をmysqlからmongodbに移動しました。スケーラビリティのためではなく、ファイルや非表形式のデータにより適しているためです。
生産では、現在以下を保存します。
- 25,000ファイル（60GB）
- 他の1億3000万件の「ドキュメント」（350GB）
毎日の売り上げは約10 GBです。
データベースは、mongodb python api（pymongo）を使用して、Apache/wsgi/pythonクライアントで2つのノード（6x450GB sas raid10）に「ペア」構成でデプロイされます。ディスクセットアップはおそらく過剰ですが、これがmysqlに使用するものです。
Pymongoスレッドプールのいくつかの問題とmongodbサーバーのブロッキングの性質は別として、それは良い経験でした。
私は直接の経験がないので、あなたの大胆なテキストに反して申し訳ありませんが、このブログ投稿のセットはCouchDBの問題を解決する良い例です。
基本的に、 textme アプリケーションはCouchDBを使用して爆発的なデータ問題に対処しました。彼らは、SQLが大量のアーカイブデータを処理するには遅すぎることを発見し、CouchDBに移行しました。これは素晴らしい読み物であり、CouchDBがどのような問題を解決できるのか、そしてそれらがどのように解決するのかを解明するプロセス全体について説明しています。
PostgresqlおよびMemcachedに保存するために使用したデータの一部を Redis に移動しました。キー値ストアは、階層オブジェクトデータの保存に適しています。 ORBを使用してBlobをRDBMSにマッピングするよりも、Blobデータをはるかに高速に、開発時間と労力を大幅に削減して保存できます。
open source c＃redis client があり、1行のPOCOオブジェクトを保存および取得できます。
var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });
また、新しいサーバーを追加し、負荷を均等に分割して新しいサーバーを含めることができるため、キーバリューストアは「スケールアウト」がはるかに簡単です。重要なのは、スケーラビリティを制限する中央サーバーがないことです。 （リクエストを配信するには、一貫したハッシュのための戦略が必要です）。
Redisはステロイドの「管理されたテキストファイル」であり、複数のクライアントに高速、同時、アトミックアクセスを提供すると考えているため、テキストファイルまたは埋め込みデータベースを使用していたものはすべてRedisを使用しています。例えばすべてのサービスのリアルタイムの統合ローリングエラーログを取得すること（これは私たちにとって困難な作業であったことで有名です）は、Redisサーバー側のリストにエラーを追加するだけで数行で完了します。リストをトリミングして、最後の1000個だけが保持されるようにします。例：
var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);
直接的な経験はありませんが、 this ブログエントリは非常に興味深いものでした。
ソフトウェアドメインオブジェクト（例：aSalesOrder、aCustomer ...）を2次元リレーショナルデータベース（行と列）にマップする作業は、複数のテーブルからドメインオブジェクトインスタンスを保存/更新してからインスタンス化するのに多くのコードを必要とします。これらすべての結合、すべてのディスク読み取りのパフォーマンスヒットは言うまでもありません...販売注文や顧客レコードなどのドメインオブジェクトを表示/操作するだけです。
オブジェクトデータベース管理システム（ODBMS）に切り替えました。これらは、リストされているnoSQLシステムの機能を超えています。 GemStone/S（Smalltalk用）はそのような例です。多くの言語用のドライバーを持つ他のODBMSソリューションがあります。開発者の主な利点は、クラス階層が自動的にデータベーススキーマ、サブクラス、その他すべてになることです。オブジェクト指向言語を使用して、オブジェクトをデータベースに永続化するだけです。 ODBMSシステムはACIDレベルのトランザクション整合性を提供するため、金融システムでも機能します。
私はMySQL（InnoDB）からcassandraに切り替えました。これは基本的に各デバイスのセンサーの時系列を保存します。各データは（device_id、date）および（device_id、type_of_sensor 、date）。MySQLバージョンには2000万行が含まれていました。
MySQL：
- マスター-マスター同期でセットアップします。 同期の喪失の周りにいくつかの問題が現れました。それはストレスが多く、特に最初は修正に数時間かかることがありました。
- 挿入時間は問題ではありませんでしたが、データが大きくなるにつれてクエリを実行するとより多くのメモリが必要になりました。問題は、インデックスが全体として考慮されることです。私の場合、メモリに読み込むのに必要なインデックスの非常に薄い部分のみを使用していました（デバイスの数パーセントのみが頻繁に監視され、最新のデータ上にありました）。
- バックアップが困難でした。 Rsyncは、大きなInnoDBテーブルファイルの高速バックアップを実行できません。
- 重いテーブルスキーマを更新することができませんでしたであることがすぐに明らかになりました。時間がかかりすぎたためです（時間）。
- データのインポートには数時間かかりました（インデックス作成が最後に行われた場合でも）。最善の救助計画は、データベースのいくつかのコピー（データファイル+ログ）を常に保持することでした。
- 移動あるホスティング会社から別の会社へ本当に大したことでした。レプリケーションは非常に慎重に処理する必要がありました。
カサンドラ：
- MySQLよりも簡単にインストールできます。
- 大量のRAMが必要です。 2GBインスタンスは最初のバージョンでは実行できませんでした。1GBインスタンスで動作するようになりましたが、それは考えられません（データフラッシュが多すぎる）。私たちの場合は8GBで十分でした。
- データの整理方法を理解したら、保存は簡単です。要求はもう少し複雑です。しかし、いったん回避すると、非常に高速になります（本当にしたくない限り、間違いを犯すことはできません）。
- 前のステップが正しく行われていれば、それは非常に高速です。
- データはバックアップされるように整理されているようです。すべての新しいデータは新しいファイルとして追加されます。私は個人的には良いことではありませんが、毎晩、シャットダウンする前に（通常はアップグレードのために）データをフラッシュします。これにより、読み取るログが少なくなるため、復元にかかる時間が短縮されます。圧縮されているため、多くのファイルは作成されません。
- データのインポートは非常に高速です。また、ホストが多いほど高速になります。ギガバイトのデータのエクスポートとインポートはもう問題ではありません。
- スキーマを持たないことは非常に興味深いことです。なぜなら、ニーズに合わせてデータを進化させることができるからです。これは、同じ列ファミリで同時に異なるバージョンのデータを持つことを意味する場合があります。
- ホストの追加は簡単ですが（高速ではありません）、複数のデータセンターのセットアップでは行っていません。
注： elasticsearch （luceneに基づいたドキュメント指向）も使用しましたが、NoSQLデータベースと見なすべきだと思います。分散されており、信頼性が高く、多くの場合高速です（一部の複雑なクエリは非常にパフォーマンスが悪い場合があります）。
しません。私は、インプロセスで呼び出すことができるシンプルで無料のキーバリューストアを使用したいと思いますが、そのようなものはWindowsプラットフォームには存在しません。今はSqliteを使用していますが、東京キャビネットのようなものを使用したいと思います。 BerkeleyDBにはライセンスの「問題」があります。
ただし、Windows OSを使用する場合、NoSQLデータベースの選択は制限されます。また、C＃プロバイダーが常にあるとは限りません
MongoDBを試してみましたが、Sqliteよりも40倍高速だったので、使用する必要があるかもしれません。しかし、私はまだ簡単なインプロセスソリューションを望んでいます。
Redisを使用して、マシン間でログメッセージを保存しました。実装は非常に簡単で、非常に便利でした。 Redisは本当に素晴らしい
PostgresデータベースをCouchDBドキュメントデータベースに置き換えました。これは、固定スキーマを持たないことが大きな利点だったためです。各ドキュメントには、そのドキュメントへのアクセスに使用される可変数のインデックスがあります。
3.0がリリースされた今、Couchbaseをもう一度試してみてください。スターターには200以上の新機能があります。 Couchbase Serverのパフォーマンス、可用性、スケーラビリティ、および簡単な管理機能により、非常に柔軟で可用性の高いデータベースが実現します。管理UIが組み込まれており、APIがクラスターノードを自動的に検出するため、アプリケーションからDBへのロードバランサーは必要ありません。現時点ではマネージドサービスはありませんが、AWS、RedHat Gears、Cloudera、Rackspace、CloudSoftなどのDocker Containersなどでcouchbaseを実行できます。リバランスに関しては、具体的には何を参照しているかによって異なりますが、Couchbaseは設計どおりにノード障害後に自動的にリバランスしませんが、管理者は最初のノード障害に対して自動フェイルオーバーを設定でき、APIを使用してアクセスすることもできますレプリカvbucketsをアクティブにする前に読み込むか、RestAPIを使用して、監視ツールによってフェールオーバーを実施できます。これは特殊なケースですが、実行することは可能です。
ノードが完全にオフラインになり、戻ってこないか、新しいノードが自動的にバランス調整される準備ができていない限り、ほとんどのモードでバランスを再調整しない傾向があります。最も高性能なNoSQLデータベースの1つが何であるかを知りたい人に役立つガイドをいくつか紹介します。
最後に、分散クエリのN1QLを確認することもお勧めします。
読んでくれてありがとう、もっと助けが必要かどうかを私や他の人に知らせてください！
オースティン
私は過去にCouchbaseを使用しましたが、リバランスの問題や他の問題のホストに遭遇しました。現在、私はいくつかの生産プロジェクトでRedisを使用しています。 redislabs.com を使用しています。これは、Redisクラスターのスケーリングを処理するRedisのマネージドサービスです。 http://thomasjaeger.wordpress.com のブログでオブジェクトの永続性に関するビデオを公開しました。これは、プロバイダーモデルでRedisを使用する方法と、RedisにC＃オブジェクトを保存する方法を示しています。ご覧ください。
私は過去にVerticaを使用しました。これは、カラムナー圧縮に依存し、ディスク読み取りを促進し、ハードウェアを最大限に活用するためにストレージのニーズを下げます。データの読み込みが高速で同時実行性が高いため、最小限のレイテンシでより多くのユーザーに分析データを提供できます。
以前は、数十億のレコードを持つOracleデータベースを照会していましたが、パフォーマンスは非常に最適ではありませんでした。 SSDで最適化した後でも、クエリの実行には8〜12秒かかりました。したがって、より高速な読み取り最適化された分析指向のデータベースを使用する必要性を感じました。リーンサービスレイヤーの背後にあるVerticaクラスターを使用すると、1秒未満のパフォーマンスでAPIを実行できます。
Verticaは、クエリの実行を最適化する形式でデータをプロジェクションに保存します。マテリアライズドビューと同様に、プロジェクションはクエリで使用されるたびに結果セットを計算するのではなく、ディスクOR SSDに結果セットを格納します。プロジェクションには次の利点があります。
- データを圧縮およびエンコードして、ストレージスペースを削減します。
- データベースクラスタ全体の分散を簡素化します。
- 高可用性と回復を提供します。
Verticaは、セグメンテーションを使用してクラスター全体にデータを分散することにより、データベースを最適化します。
- セグメンテーションは、データの一部をノードに配置します。
- すべてのノードでデータを均等に分散します。したがって、各ノードはクエリ処理の一部を実行します。
- クエリはクラスターで実行され、すべてのノードがクエリプランを受け取ります。
- クエリの結果は集約され、出力の作成に使用されます。
詳細については、Verticaのドキュメントを参照してください@ https://www.vertica.com/knowledgebase/