MongoDB / Cassandra / Redis / CouchDBを選択する必要がありますか？

Question

私たちは本当に大きなプロジェクトを開発していますが、どのDBバックエンドを選択すべきかについて、誰かがアドバイスをくれないかと思っていました。

私たちのシステムは、中央サーバーに信号を送信する1100個の電子デバイスと複合しており、サーバーは信号情報を保存します（信号の長さは約35バイトです）。これらのデバイスはそれぞれ1分間に約3つの信号を送信します。したがって、数値を計算すると、データベースで1日あたり4.752.000の新しいレコード、1か月で合計142.560.000の新しいレコードになります。

高速で信頼性の高いDBバックエンドが必要です。もちろん、そのDBで複雑なデータマイニングを行う必要があります。私たちはMongoDB/Cassandra/Redis/CouchDBの調査を行っていますが、ドキュメントのWebサイトはまだ初期段階です。

何か助け？アイデア？

どうもありがとう！

user359996 · Answer

空間スケール（1000以上のデバイス）が計算スケールやストレージスケールに関して誤解を招かないようにしてください。 1秒間に数ダースの35バイトの挿入は、低価格のハードウェアで実行されている場合でも、主流のDBMSにとって些細な作業負荷です。同様に、1か月あたり1億4,200万件のレコードは、インデックスを含む圧縮なしで、1か月あたり1〜10ギガバイト程度のストレージです。

あなたの質問のコメントで、あなたは言った：

「信頼性、スケーラビリティ、速度がすべてです。より多くのノードを投入するだけでソリューションを簡単に拡張できること（MongoDB自動シャーディング？）は非常に重要です。速度も非常に重要です。

信頼性？主流のDBMSはこれを保証できます（データが破損しないこと、およびクラッシュしないことを意味すると仮定します。この答えの最後にあるCAP定理の説明を参照してください）。速度？ 1台のマシンでも、このワークロードの10〜100倍は問題になりません。スケーラビリティ？現在のレートでは、圧縮されていない、完全にインデックス化された1年分のデータは、100ギガバイトのディスク領域に簡単に収まります（同様に、挿入レートは問題ではないことをすでに確立しています）。

そのため、NoSQLのようなエキゾチックなソリューションや、分散データベース（MySQLのようなプレーンで古いリレーショナルデータベース）でさえ、明確な必要性はないと思います。フェイルオーバーが心配な場合は、マスタースレーブ構成でバックアップサーバーをセットアップするだけです。現在のスケールの100倍または1000倍の話をしている場合、データ収集デバイスのIDに基づいていくつかのインスタンスを水平方向にパーティション分割するだけです（ie{partition index} = {デバイスID}モジュロ{パーティションの数}）。

リレーショナルデータベースの世界の安全で快適な範囲を残すことは、その表現モデルとその豊富なツールセットの両方を放棄することを意味することに留意してください。これにより、「複雑なデータマイニング」がはるかに困難になります。データをデータベースに入れるだけでなく、取り出す必要もあります。

そうは言っても、MongoDBとCouchDBはデプロイと操作が非常に簡単です。また、非常に楽しく、多くの人々（プログラマーだけでなく、役員も）にとって魅力的です。

一般的な知恵は、あなたが提案した3つのNoSQLソリューションのうち、Cassandra=は大量の挿入に最適です（もちろん、比較的言えば、私はあなたとは思いませんhave挿入量が多い-これはFacebook）が使用するように設計されています;これは、作業がより困難になることで相殺されます。あなたが言及しなかった奇妙な要件、私はあなたのユースケースのために、それに対してお勧めします。

NoSQL展開に積極的に取り組んでいる場合は、CAP定理を検討することをお勧めします。これは、MongoDBとCouchDBを決定するのに役立ちます。ここに良いリンクがあります： http://blog.nahurst.com/visual-guide-to-nosql-systems 。すべては「信頼性」の意味に帰着します：MongoDBは可用性を一貫性と交換しますが、CouchDBは一貫性を可用性と交換します。（Cassandraでは、書き込み/読み取りを成功させるために書き込み/読み取りが必要なサーバーの数を指定することで、クエリごとにこのトレードオフを細かく処理できます。更新：今、CouchDBでも BigCouch ！ ...）

プロジェクトの幸運を祈ります。

Theo · Answer

回答の多くは、収集後に何をしたいかによって異なります。大量のデータを保存するのは簡単です。ログファイルに保存するだけで、データベースは不要です。一方、複雑な分析とデータマイニングを実行する場合は、データベースが役立ちます。

次の質問は、どのような分析を行うかです。特定のプロパティを持つデータのサブセット（過去1時間、1日、1週間、1か月のみ）で実行されますか？データを集計するか、何らかの形で事前に計算できますか？つまり、収集された形式でデータセット全体にアクセスする必要がありますか？古くなって面白くないデータをアーカイブできますか？データを集約し、集約に対して分析を実行できますか？

広告分析（広告露出に関する数十億のデータポイントを収集）の作業からの私の経験では、集約が重要です。生データを収集し、サニタイズしてから、MongoDB、Cassandra、または更新やクエリを実行できるMySQLのようなデータベースに入れます。その後、定期的にデータを集約し、データベースから削除します（ただし、生データをアーカイブします。後で必要になる場合があります）。

集約は基本的に、データについて尋ねたいすべての質問を求め、特定の質問に対する答えを簡単に取得できる形式で保存します。 Xが最も多い曜日を知りたいとします。これの単純な実装は、記録されたすべての信号を巨大なテーブルに保持し、Xを持つすべての行を合計するクエリを実行することです。シグナルが大きくなると、このクエリに時間がかかります。これに役立つインデックス作成、シャーディング、または最適化はありません。代わりに、毎日/時間/分（正確なユースケースとレポートの必要性に応じて）記録した新しい信号を確認し、Xごとに数を追跡するカウンターをインクリメントしますX月曜日、月曜日の場合は火曜日、火曜日の場合は火曜日など。そうすれば、後で各曜日のカウントを取得して比較できます。回答できるようにしたいすべての質問に対してこれを行い、データベースからシグナルを削除します（ただし、生データを保持します）。

集約を記録するデータベースの種類は、着信信号を保存するデータベースの種類と同じでもかまいませんが、それほど凝ったものである必要はありません。特定の回答を表すキーと、通常は単なる数値である値を保存します。

古い学校のデータウェアハウスでは、着信信号を保存するデータベースはOLTP（オンライントランザクション処理用）と呼ばれ、集計を保存するデータベースはOLAP（オンライン分析処理用）OLTPは挿入用に最適化され、OLAPはクエリ用に最適化されます。用語は古く、人々は、SQLやstarchemasなどをすぐに考える傾向があると聞きますが、多分私はそれらを使うべきではありませんが、便利な用語です。

とにかく、for OLTPデータの挿入が速いだけでなく、データのインデックス付けと物事の検索をサポートするものが必要です。集約は、作業の半分を行うデータベースによって大いに助けられます最大値と最小値を合計し、見つけます。設定と操作が非常に簡単なので、MongoDBが本当に好きです。扱うデータは乱雑になる傾向があり、すべてのアイテムに同じプロパティセットがあるわけではありません。一方、データはより均一に聞こえるので、Mongoはおそらくそれほどメリットをもたらさないでしょう。しかし、まだ古き良きリレーショナルデータベースを見落とさないでください。そのため、SQLは優れています。それがSQLの目的です。

OLAPはるかに単純なものであれば、キーと値のストアがあれば十分です。Redisを使用するのも、作業とセットアップが非常に簡単であるためです。多くの場合、値は実際にはリストまたはハッシュであり、そのような値をエンコードする必要がありますが、Redisはネイティブに処理します。Redisの欠点は、クエリを実行できないことです。（「Yにこの値を持つすべての行を表示」のように）、自分でデータのインデックスを保持する必要があります。一方、すべての質問に対する答えが事前に計算されているため、インデックスはあまり必要ありません。あなたがする必要があるのは、質問で定義されたキーで答えを調べることです。上記の質問では、曜日が最も多いXは、月曜日、火曜日などのXの仕事の数を調べます'X：monday、X：tuesdayなどとして保存しました。

結論として：MongoDBとRedisは私にとって素晴らしい仕事です。 MongoDBはあなたのユースケースにはあまり適していないと思いますが、代わりに、実際には従来のSQLデータベースからより多くの恩恵を受ける可能性があると思います（ただし、データが本当に単純な場合は、Redisをすべて使用できるかもしれません）。最も重要なことは、1つのデータベースにデータを保持し、永久に保持する必要があると勘違いしないことです。集約と古いデータの破棄が重要です。