NoSQLデータストアを使用してどのようなスケーラビリティの問題が発生しましたか？[閉まっている]

NoSQLは、リレーショナルデータベースの履歴とACIDの保証で壊れる非リレーショナルデータストアを指します。人気のあるオープンソースのNoSQLデータストアには次のものがあります。

• Cassandra（表形式、Javaで記述、Cisco、WebEx、Digg、Facebook、IBM、Mahalo、Rackspace、Reddit、Twitterで使用）
• CouchDB（Erlangで記述されたドキュメント、BBCおよびEngine Yardで使用）
• Dynomite（Erlangで記述されたKey-Value、Powersetで使用）
• HBase（Key-Value、Javaで記述、Bingで使用）
• ハイパーテーブル（表形式、C ++で記述、Baiduで使用）
• Kai（Key-Value、Erlangで記述）
• MemcacheDB（Key-Value、Cで記述、Redditで使用）
• MongoDB（C ++で記述されたドキュメント、Electronic Arts、Github、NY Times、Sourceforgeで使用）
• Neo4j（Javaで書かれたグラフ、いくつかのスウェーデンの大学で使用）
• プロジェクトヴォルデモート（Key-Value、Javaで記述、LinkedInで使用）
• Redis（Cで記述されたKey-Value、Craigslist、Engine Yard、Githubで使用）
• リアック（Erlangで記述されたKey-Value、ComcastおよびMochi Mediaで使用）
• Ringo（Key-Value、Erlangで記述、Nokiaで使用）
• Scalaris（Erlangで記述されたKey-Value、OnScaleで使用）
• Terrastore（ドキュメント、Javaで記述）
• ThruDB（C ++で記述されたドキュメント、JunkDepot.comで使用）
• 東京キャビネット/東京暴君（Cで書かれたKey-Value、Mixi.jp（日本のソーシャルネットワークサイト）で使用）

あなた（SOリーダー）がデータストアを使用して解決した特定の問題と、使用したNoSQLデータストアについて知りたいのですが。

質問：

• NoSQLデータストアを使用して解決したスケーラビリティの問題は何ですか？
• どのNoSQLデータストアを使用しましたか？
• NoSQLデータストアに切り替える前にどのデータベースを使用しましたか？

直接の体験を探していますので、それがない限り答えないでください。

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

約2年前、http：//www.ubuntuusers.de/で自己作成ソフトウェアをリリースしました（おそらくドイツ最大のLinuxコミュニティWebサイト）で。サイトはPythonで記述されており、すべての例外をキャッチして別の小さなMySQLベースのWebサイトに送信できるWSGIミドルウェアを追加しました。この小さなWebサイトでは、ハッシュを使用してさまざまなバグを特定し、発生回数と最後の発生回数も保存しました。

残念ながら、リリース後間もなく、トレースバックロガーのWebサイトは応答しなくなりました。メインサイトの本番データベースにロックの問題があり、ほぼすべてのリクエストで例外が発生していました。また、テスト段階では調査していない他のいくつかのバグもありました。トレースバックロガー送信ページと呼ばれるメインサイトのサーバークラスターは、1秒あたり数k回です。そして、それは、トレースバックロガーをホストする小さなサーバーにとっては、やり過ぎでした（すでに古いサーバーであり、開発目的でのみ使用されていました）。

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

興味深い点の1つは、以前のソリューションが古い専用サーバーで実行されていた一方で、新しいCouchDBベースのサイトは、リソースが非常に制限された共有Xenインスタンスでのみ実行されていたことです。また、Key-Valueストアの強みを使って水平方向にスケーリングすることもしていません。何もロックせずに同時リクエストを処理するCouchDB / Erlang OTPの機能は、ニーズを満たすのに十分です。

現在、すばやく作成されたCouchDBトレースバックロガーはまだ実行中であり、メイン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など）は使用しませんでした。それぞれ独自の優れた機能/パフォーマンスを備えていますが、状況によっては常に欠点（Javaのサポートが不足している/未熟など）があったためです。

MySQLを使用して（AB）の余分な利益-我々のモデルのビットん作品はリレーショナルに簡単に私たちのキー/値のデータを格納するためにリンクすることができます。

更新：上司が私を撃つときの実際のビジネスドメイン（「製品」ではありません）ではなく、テキストコンテンツの表現方法の例を次に示しますが、再帰的な側面（1つのエンティティ、ここでは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、et al。の最近のCACM論文を参照してください。Vertica とmap-reduceを対比しています。

更新：そして、Twitterが選んだCassandraが、HBase、Voldemort、MongoDB、MemcacheDB、Redis、HyperTableなど、他のいくつかのものよりも優れています。

更新2：Rick CattellがいくつかのNoSQLシステムの比較をHigh Performance Data Storesで公開しました。そして、リックの論文に対するhighscalability.comの見解はこちらです。

データの一部をmysqlからmongodbに移動しました。スケーラビリティのためではなく、ファイルや非表形式のデータにより適しているためです。

本番環境で現在保管しているもの：

• 25,000ファイル（60GB）
• 1億3千万の「ドキュメント」（350GB）

毎日の売上高は約10GBです。

データベースは、mongodb python api（pymongo）を使用するapache / wsgi / pythonクライアントを備えた2つのノード（6x450GB sas raid10）の「ペア」構成でデプロイされます。ディスクのセットアップはおそらくやり過ぎですが、それをmysqlに使用しています。

pymongoスレッドプールのいくつかの問題とmongodbサーバーのブロックの性質は別として、それは良い経験でした。

私は直接の経験がないので、太字のテキストに反して申し訳ありませんが、この一連のブログ投稿はCouchDBの問題を解決する良い例です。

CouchDB：ケーススタディ

基本的に、textmeアプリケーションはCouchDBを使用して、爆発するデータの問題に対処しました。彼らは、SQLが遅すぎて大量のアーカイブデータを処理できないことを発見し、それをCouchDBに移動しました。これは優れた資料であり、CouchDBが解決できる問題と、それらがどのようにして解決したかを理解するプロセス全体について説明しています。

PostgresqlとMemcachedに格納するために使用していたデータの一部をRedisに移動しました。キー値ストアは、階層オブジェクトデータを格納するのに非常に適しています。ORMを使用してBLOBをRDBMSにマップするよりもはるかに高速で、少ない開発時間と労力でBLOBデータを格納できます。

私が持っているオープンソースのC＃のRedisクライアントあなたはどのPOCOは、1行でオブジェクトを格納および取得することができます：

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);

直接の経験はありませんが、このブログエントリは非常に興味深いものでした。

ソフトウェアドメインオブジェクト（aSalesOrder、aCustomer ...など）を2次元のリレーショナルデータベース（行と列）にマッピングする作業には、保存/更新に多くのコードが必要で、複数のテーブルからドメインオブジェクトインスタンスをインスタンス化するのに時間がかかる。これらすべての結合、すべてのディスク読み取りのパフォーマンスへの影響は言うまでもありません。単に、注文や顧客レコードなどのドメインオブジェクトを表示/操作するためです。

オブジェクトデータベース管理システム（ODBMS）に切り替えました。リストされているnoSQLシステムの機能を超えています。GemStone / S（Smalltalk用）はそのような例です。他のODBMSソリューションには、多くの言語用のドライバーがあります。開発者にとっての主な利点は、クラス階層が自動的にデータベーススキーマ、サブクラスなどになることです。オブジェクト指向言語を使用して、オブジェクトをデータベースに永続化します。ODBMSシステムはACIDレベルのトランザクション整合性を提供するため、金融システムでも機能します。

MySQL（InnoDB）から、基本的に各デバイスのセンサーの時系列を保存するM2Mシステムのcassandraに切り替えました。各データには、（device_id、date）および（device_id、type_of_sensor、date）によってインデックスが付けられます。MySQLバージョンには2000万行が含まれていました。

MySQL：

• マスターとマスターの同期のセットアップ。同期の喪失に関連する問題はほとんどありません。それはストレスがたまり、特に最初は修正するのに何時間もかかる可能性がありました。
• 挿入時間は問題ではありませんでしたが、クエリにはますます多くのメモリが必要でした、データが増加するにつれて。問題は、インデックスが全体として考慮されていることです。私の場合、メモリにロードするために必要なインデックスの非常に薄い部分のみを使用していました（デバイスの数パーセントのみが頻繁に監視され、最新のデータに関するものでした）。
• バックアップが大変でした。Rsyncは大きなInnoDBテーブルファイルで高速バックアップを実行できません。
• 時間がかかりすぎたため、重いテーブルスキーマを更新できないことがすぐにわかりました。
• データのインポートには数時間かかりました（インデックス作成が最後に行われた場合でも）。最善の救済策は、常にデータベースのいくつかのコピー（データファイル+ログ）を保持することでした。
• あるホスティング会社から別のホスティング会社への移行は、本当に大変なことでした。複製は非常に注意深く処理する必要がありました。

カサンドラ：

• MySQLよりもインストールが簡単です。
• 大量のRAMが必要です。2GBのインスタンスは最初のバージョンでは実行できませんでしたが、1GBのインスタンスで動作できるようになりましたが、あまり考えられません（データのフラッシュが多すぎるため）。私たちの場合は、8GBで十分です。
• データの編成方法を理解したら、保存は簡単です。リクエストはもう少し複雑です。しかし、それを回避すると、それは本当に高速です（本当にやりたくない限り、間違いを犯すことはできません）。
• 前のステップが正しく行われた場合、それは超高速です。
• バックアップするようにデータが整理されているように見えます。新しいデータはすべて新しいファイルとして追加されます。私は個人的には良いことではありませんが、毎晩シャットダウンする前に（通常はアップグレードのために）データをフラッシュし、読み取るログが少ないため、復元にかか​​る時間を短縮します。圧縮されていれば、あまりファイルを作成しません。
• データのインポートは非​​常に高速です。そして、あなたが持っているより多くのホストはより高速です。ギガバイトのデータのエクスポートとインポートは、もはや問題ではありません。
• スキーマを持たないことは、データを進化させてニーズに従うことができるので、非常に興味深いことです。これは、同じ列ファミリーで同時に異なるバージョンのデータを持つことを意味する場合があります。
• ホストの追加は簡単でしたが（高速ではありません）、マルチデータセンターのセットアップでは行っていません。

注：また、elasticsearch（luceneに基づくドキュメント指向）も使用しており、NoSQLデータベースと見なす必要があると思います。分散型で、信頼性が高く、高速であることが多い（複雑なクエリの中には、かなりうまく機能しないものもある）。

私はしません。プロセスで呼び出すことができるシンプルで無料のKey-Valueストアを使用したいのですが、Windowsプラットフォームではそのようなものは存在しません。今はSqliteを使っていますが、東京キャビネットのようなものを使いたいです。BerkeleyDBには「課題」のライセンスがあります。

ただし、Windows OSを使用する場合、選択できるNoSQLデータベースは限られています。そして、常にC＃プロバイダーがあるわけではありません

私はMongoDBを試してみましたが、Sqliteより40倍高速だったので、多分それを使用する必要があります。しかし、私はまだシンプルなインプロセスソリューションを望んでいます。

マシン間でロギングメッセージを保存するためにredisを使用しました。実装は非常に簡単で、非常に便利でした。Redisは本当に素晴らしい

postgresデータベースをCouchDBドキュメントデータベースに置き換えました。固定スキーマがないことは私たちにとって大きな利点でした。各ドキュメントには、そのドキュメントへのアクセスに使用される可変数のインデックスがあります。

私は過去にCouchbaseを使用したことがあり、リバランスの問題や他の多くの問題に遭遇しました。現在、いくつかの制作プロジェクトでRedisを使用しています。Redisクラスターのスケーリングを処理するRedisのマネージドサービスであるredislabs.comを使用しています。オブジェクトの永続性に関するビデオをブログ（http://thomasjaeger.wordpress.com）に公開しました。プロバイダーモデルでRedisを使用する方法と、C＃オブジェクトをRedisに保存する方法を示しています。見てください。

これを読んでいる人には、3.0が公開された今、もう一度Couchbaseを試すことをお勧めします。初心者向けの200を超える新機能があります。Couchbase Serverのパフォーマンス、可用性、スケーラビリティ、および簡単な管理機能により、非常に柔軟で可用性の高いデータベースが実現します。管理UIが組み込まれており、APIがクラスターノードを自動的に検出するため、アプリケーションからDBへのロードバランサーは必要ありません。現在、マネージドサービスはありませんが、AWS、RedHat Gears、Cloudera、Rackspace、CloudSoftなどのDockerコンテナなどでcouchbaseを実行できます。リバランスに関しては、具体的には何を参照しているかによって異なりますが、Couchbaseは設計どおり、ノード障害の後で自動的にリバランスしません。ただし、管理者は最初のノードの障害に対して自動フェイルオーバーを設定できます。APIを使用すると、レプリカvbucketにアクセスして読み取りを行うか、RestAPIを使用してモニタリングツールでフェイルオーバーを強制できます。これは特殊なケースですが、実行することは可能です。

ノードが完全にオフラインで決して戻らないか、新しいノードが自動的にバランスをとる準備ができていない限り、ほとんどどのモードでもリバランスを行わない傾向があります。以下は、最もパフォーマンスの高いNoSQLデータベースの1つが何であるかを知りたい人に役立つガイドのカップルです。

1. Couchbase Server 3.0
2. 管理ガイド
3. REST API
4. 開発者ガイド

最後に、分散クエリのN1QLを確認することもお勧めします。

1. N1QLチュートリアル
2. N1QLガイド

お読みいただきありがとうございます。さらにサポートが必要な場合は、私または他の人にお知らせください！

オースティン

私は過去にVerticaを使用しました。これは、列圧縮に依存し、ディスクの読み取りを高速化し、ハードウェアを最大限に活用するために必要なストレージを減らします。より高速なデータロードと高い同時実行性により、最小限のレイテンシで分析データをより多くのユーザーに提供できます。

以前は、何十億ものレコードを持つOracleデータベースにクエリを実行していましたが、パフォーマンスは非常に最適ではありませんでした。SSDで最適化した後でも、クエリの実行に8〜12秒かかりました。したがって、読み取りを最適化した、分析指向の高速なデータベースを使用する必要があると感じました。リーンサービスレイヤーの背後にあるVerticaクラスターにより、APIを1秒未満のパフォーマンスで実行できました。

Verticaは、クエリの実行を最適化する形式でプロジェクションにデータを保存します。マテリアライズドビューと同様に、プロジェクションは結果セットをクエリで使用するたびに計算するのではなく、ディスクまたはSSDに保存します。プロジェクションには次の利点があります。

1. データを圧縮およびエンコードして、ストレージスペースを削減します。
2. データベースクラスタ全体の分散を簡素化します。
3. 高可用性とリカバリを提供します。

Verticaは、セグメンテーションを使用してクラスター全体にデータを分散することにより、データベースを最適化します。

1. セグメンテーションは、データの一部をノードに配置します。
2. すべてのノードにデータを均等に分散します。したがって、各ノードはクエリ処理の一部を実行します。
3. クエリはクラスターで実行され、すべてのノードがクエリプランを受け取ります。
4. クエリの結果は集計され、出力の作成に使用されます。

詳細については、https： //www.vertica.com/knowledgebase/のVerticaドキュメントを参照してください。