MongoDB vs. Cassandra vs.リアルタイム広告プラットフォームのMySQL
私は、パフォーマンスを重視したリアルタイム広告プラットフォームに取り組んでいます。私は常にMySQLで開発を行ってきましたが、MongoDBやCassandraなどの新しい方法を試してみてください。大幅な速度向上を達成できる場合。両方とも急速に開発されており、多くの情報はやや時代遅れに見えます。
格納される主なデータは、クリックごとのエントリ、ビューの増分行、各キャンペーンの情報（基本設定など）です。速度の向上は、クリックの挿入、ビューの合計の更新、リアルタイムの統計レポートの生成で見つける必要があります。プラットフォームはPHPで開発されています。
または多分これらのどれも？
リストされているすべてのテクノロジーでこれを実現するには、いくつかの方法があります。それをどのように使用するかという問題です。理想的なソリューションでは、これらの組み合わせを使用する場合がありますが、使用パターンを考慮してください。プレイ中のコンセプトは非常に基本的なものであるため、そこにある情報は時代遅れだとは感じません。新しいNoSQLデータベースと既存のデータベースの修正がありますが、質問は主にアーキテクチャに関するものです。
MongoDBやCassandraなどのNoSQLソリューションは、挿入パフォーマンスについて多くの注目を集めています。人々は、リレーショナルデータベースの更新/挿入パフォーマンスについて不満を言う傾向がありますが、これらの問題を軽減する方法があります。
MySQLから開始して、O'Reillyの High Performance MySQL を確認し、スキーマを最適化して、おそらくメモリを追加して、アプリの他の部分とは異なるハードウェアで実行します（そのためにMySQLを使用した場合）、またはパーティション/ shardデータ。考慮すべきもう1つの領域は、アプリケーションです。データベースに挿入する前に、アプリケーションレベルで挿入と更新をキューに入れることができますか？これにより柔軟性が得られ、すべての場合におそらく役立つでしょう。最終的なスキーマの外観に応じて、MySQLは、SQLに慣れている限り、データの抽出を支援します。これは、サードパーティのレポートツールなどを使用する必要がある場合に便利です。
MongoDBとCassandraは異なるビーストです。後者にノードを追加する方が簡単だったと思いますが、MongoDBにはレプリケーションなどが組み込まれているため、これは変更されました。リレーショナルデータベースと同じ方法で制約されます。データの取り出しも非常に迅速であり、データ形式の変更に大きな柔軟性があります。トレードオフは、SQLを使用できないことです（一部の利点）。これらのプラットフォームのいずれかでデータを収集し、それをさらに分析するためにMySQLデータベースにインポートすることを止めるものは何もありません。
要件に基づいて、 Flume などのNoSQLデータベース以外のツールを確認する必要があります。これらは、分析に広く使用されているHadoopプラットフォームを利用しています。これらは、あなたがしていることに関して、データベースよりも柔軟性があるかもしれません。 Hadoop World からのコンテンツがいくつかあります。
このタスクでは、NosqlソリューションはMysql、postgresql、その他のrdbms技術よりも優れています。 Hbase/Hadoopで時間を無駄にしないでください。それを使用するには宇宙飛行士にならなければなりません。 MongoDBとCassandraをお勧めします。 Mongoは小さなデータセットに適しています（データがRAMの最大10倍の場合、そうでない場合はシャードし、より多くのマシンを必要とし、レプリカセットを使用する必要があります）。ビッグデータの場合; cassandraが最適です。Mongodbには、cassandraよりも多くのクエリオプションと他の機能がありますが、mongoには64ビットマシンが必要です。両側にアトミックカウンターがあります。両方とも適切にスケーリングできますが、cassandra=はスケーリングと高可用性においてはるかに優れています。両方ともphpクライアントを持ち、両方とも良いサポートとコミュニティを持っています（mongoコミュニティはより大きい）。
Cassandra分析プロジェクトのサンプル：Rainbird http://www.slideshare.net/kevinweil/rainbird-realtime-analytics-at-Twitter-strata-2011
mongoサンプル： http://www.slideshare.net/jrosoff/scalable-event-analytics-with-mongodb-Ruby-on-Rails
http://axonflux.com/how-superfeedr-built-analytics-using-mongodb
doubleclick開発者がmongoを開発 http://www.informationweek.com/news/software/info_management/224200878
MySQLの特徴：
- データベースのロック（金融取引では非常に簡単）
- 一貫性/セキュリティ（上記のように、たとえば、銀行口座の残高を読んでから更新するまでの間に変更が発生しないことを保証できます）。
- データの整理/リファクタリング（どこでもデータを整理できますが、MySQLは「タイプ」または「コンポーネント」を表すテーブルの方が優れており、それらをクエリに結合します-これは正規化と呼ばれます）。
Cassandraの特徴：
- 速度
- 可用性（100％「正しい」に関係なく、データは常に使用可能です）
- オプションのフィールド（メタテーブルなどを使用してMySQLで実行できますが、Cassandraでは無料です）
Cassandraはキー値またはドキュメントベースのストレージです。それが何を意味するか考えてください。通常、Cassandra ONE KEYとONE DATASETを取得します。そこから分岐できますが、それは基本的に何が起こっているかです。静的ファイルにアクセスするようなものです。インデックス、カウンタフィールドなどがありますが、私は一般化しています。Cassandraの由来です。
MySQLとSQLはグループ/セット理論に基づいています-データセット間の任意の関係を結合する方法があります。 MySQLクエリを取得し、クエリを「キー」、レスポンスを「値」にして、Cassandra（例make Cassandra=キャッシュ）これはトレードオフの説明にも役立つかもしれませんが、MySQLを使用すると、異なるクエリを記述するだけで、データテーブルとデータセット間の関係を常に再配置できます。Cassandraそれほど多くありません。 Cassandraは、これらの機能の一部を提供する機能を提供するかもしれませんが、それが構築されたものではありません。
MongoDBとCouchDBは、これらの両極端の中間に位置しています。 MySQLは少し冗長で、特にオプションのフィールドを扱うときや、優れたモデルやツールがない場合の移行を扱うのは面倒です。また、スケーラビリティに関しては、MySQLデータベースをスケーリングするための優れたテクノロジーがあると確信していますが、Cassandraは、その機能セットの制限により、常に容易にスケーリングします。MySQLはもう少し制限がありません。ただし、NoSQLとCassandra donotは、結合を可能にするSQLの重要な機能の1つです。 1つのクエリで複数のテーブルを使用するため、Cassandraでは複雑なリレーショナルクエリは拡張されません。
Cassandra対MongoDB CassandraまたはMongoDBを次のプロジェクトのデータストアとして検討していますか？2つのデータベースを比較しますか？CassandraとMongoDBは両方の「NoSQL」データベースですが、実際にはそれらは非常に異なっています。それらは非常に異なる長所と価値命題を持っているので、比較は微妙なものでなければなりません。初期要件から始めましょう…これらのデータベースはどちらもRDBMSを置き換えませんしたがって、正規化と一貫性が主要な要件であるトランザクションワークロードがある場合、これらのデータベースはどちらも機能しません。MySQL、PostGres、Oracleなどの従来のリレーショナルデータベースを使用したほうがよいでしょう。リレーショナルデータベースがあるので、決定を下すのに役立つCassandraとMongoDBの主な違いについて考えてみましょう。この投稿では、特定の機能については説明しませんが、いくつかを高レベルの戦略的差異により、選択を支援します。
- 表現力豊かなオブジェクトモデルMongoDBは、豊かで表現力豊かなオブジェクトモデルをサポートしています。オブジェクトはプロパティを持つことができ、オブジェクトは互いにネストできます（複数レベルの場合）。このモデルは非常に「オブジェクト指向」であり、ドメイン内のオブジェクト構造を簡単に表すことができます。また、階層の任意のレベルで任意のオブジェクトのプロパティにインデックスを付けることができます-これは驚くほど強力です！一方、Cassandraは、行と列を含むかなり伝統的なテーブル構造を提供します。データはより構造化されており、各列には作成中に指定できる特定のタイプがあります。
判定：問題のあるドメインに豊富なデータモデルが必要な場合は、MongoDBが適しています。
- セカンダリインデックスセカンダリインデックスは、MongoDBのファーストクラスの構成要素です。これにより、MongoDBに格納されているオブジェクトがネストされていても、そのプロパティを簡単にインデックス付けできます。これにより、これらのセカンダリインデックスに基づいたクエリが非常に簡単になります。 Cassandraは、セカンダリインデックスのカーソルサポートのみを提供します。セカンダリインデックスは、単一列と等価比較に制限されます。主キーでクエリする場合は、Cassandraはあなたに適しています。
判定：アプリケーションにセカンダリインデックスが必要で、クエリモデルに柔軟性が必要な場合、MongoDBが適しています。
- 高可用性MongoDBは、「シングルマスター」モデルをサポートしています。これは、マスターノードと複数のスレーブノードがあることを意味します。マスターがダウンした場合、スレーブの1つがマスターとして選択されます。このプロセスは自動的に行われますが、通常10〜40秒かかります。この新しいリーダーの選出中、レプリカセットはダウンしており、書き込みを取得できません。これはほとんどのアプリケーションで機能しますが、最終的にはニーズに依存します。 Cassandraは「マルチマスター」モデルをサポートします。単一ノードの損失は、クラスターが書き込みを実行する能力に影響しません。したがって、書き込みの100％のアップタイムを達成できます。
判定：100％のアップタイムが必要な場合Cassandraが最適です。
- 書き込みスケーラビリティMongoDBの「シングルマスター」モデルは、プライマリでのみ書き込みを行うことができます。セカンダリサーバーは読み取りにのみ使用できます。したがって、本質的に3つのノードのレプリカセットがある場合、マスターのみが書き込みを行い、他の2つのノードは読み取りのみに使用されます。これにより、書き込みのスケーラビリティが大幅に制限されます。複数のシャードをデプロイできますが、基本的にデータノードの1/3のみが書き込みを取得できます。 Cassandra「マルチマスター」モデルを使用すると、任意のサーバーで書き込みを行うことができます。基本的に、クラスター内のサーバーの数によって書き込みのスケーラビリティが制限されます。スケーラビリティが向上します。
判定：書き込みのスケーラビリティが重要な場合、Cassandraの方が適しています。
- クエリ言語のサポートCassandraは、SQLに非常によく似たCQLクエリ言語をサポートします。データアナリストのチームが既にある場合は、SQLスキルの大部分を移植できます。ただし、CQLは完全なANSI SQLではありません。いくつかの制限があります（結合サポートなし、OR句）など）。この時点でMongoDBはクエリ言語をサポートしていません。クエリはJSONフラグメントとして構造化されます。
判定：クエリ言語のサポートが必要な場合は、Cassandraが最適です。
パフォーマンスのベンチマークパフォーマンスについてお話しましょう。この時点で、おそらくデータベースのパフォーマンスベンチマーク比較が期待されています。私は意図的にパフォーマンスベンチマークを比較に含めていません。いずれの比較においても、りんごごとの比較を行っていることを確認する必要があります。
データベースモデル-テスト対象のアプリケーションのデータベースモデル/スキーマは大きな違いをもたらします。一部のスキーマはMongoDBに非常に適しており、一部のスキーマはCassandraに非常に適しています。したがって、データベースを比較するときは、両方のデータベースで適切に機能するモデルを使用することが重要です。
- 負荷特性–ベンチマーク負荷の特性は非常に重要です。例えば。書き込みが多いベンチマークでは、Cassandra= MongoDBを吸うと予想します。ただし、読み取りが多いベンチマークでは、MongoDBとCassandraのパフォーマンスが似ているはずです。
- 一貫性の要件-これは扱いにくいものです。指定された読み取り/書き込み一貫性要件が両方のデータベースで同一であり、1人の参加者に偏っていないことを確認する必要があります。多くの「マーケティング」ベンチマークでは、多くの場合、ノブは反対側に不利になるように調整されています。したがって、一貫性の設定には細心の注意を払ってください。
最後に留意すべきことは、ベンチマークの負荷がアプリケーションのパフォーマンスを反映する場合としない場合があることです。そのため、ベンチマークを有効にするには、アプリケーションのパフォーマンス特性を反映したベンチマーク負荷を見つけることが非常に重要です。あなたが見たいと思うかもしれないいくつかのベンチマークがあります：-NoSQLパフォーマンスベンチマーク-Cassandra vs. MongoDB vs. Couchbase vs. HBase
- 使いやすさ数年前にこの質問をしたことがあれば、MongoDBが勝者になります。 MongoDBを起動して実行するのは非常に簡単なタスクです。しかし、ここ数年でCassandraは製品のこの面で大きな進歩を遂げました。Cassandraの主要なインターフェースとしてCQLを採用することで、これはさらに一歩前進しました–多くのSQLプログラマーがCassandra=を非常に簡単に使用できるように非常に簡単になりました。
評決：どちらも非常に使いやすく、強化されています。
ネイティブの集約MongoDBには、ETLパイプラインを実行してデータベースに格納されているデータを変換する組み込みの集約フレームワークがあります。これは、小規模から中規模のジョブには適していますが、データ処理のニーズが複雑になると、集計フレームワークのデバッグが難しくなります。 Cassandraには集約フレームワークが組み込まれていません。これにはHadoopなどの外部ツール、Sparkが使用されます。
スキーマレスモデルMongoDBでは、ドキュメントにスキーマを適用しないことを選択できます。これは、以前のバージョンでは新しいバージョンのデフォルトでしたが、ドキュメントにスキーマを適用するオプションがあります。 MongoDBの各ドキュメントは異なる構造にすることができ、データを解釈するのはアプリケーション次第です。これはほとんどのアプリケーションには関係ありませんが、場合によっては追加の柔軟性が重要です。 Cassandra新しいバージョン（デフォルト言語としてCQLを使用）では静的型付けを提供します。列の型を事前に定義する必要があります。
Membase（www.couchbase.com）をこのリストに追加したいと思います。
製品として、Membaseは多くの広告代理店（AOL Advertising、Chango、Delta Projectsなど）で展開されています。これらの企業がMembaseをどのようにうまく利用したかについて、多くの公的な事例研究と例があります。
議論の余地は確かにありますが、Membaseは他のソリューションよりも優れたパフォーマンスとスケーラビリティを提供することがわかりました。インデックス作成/クエリで不足していることは、新しい永続性バックエンドとしてのCouchDBの統合で補う以上のものを計画しています。
企業として、Couchbase（Membaseのメーカー）は、広告/ターゲティング企業のニーズに特化した豊富な知識と経験を持っています。
Membaseが適切であるかどうかを確認するために、この特定のユースケースであなたと確実に関わりたいと思います。
メール（perry -at- couchbase -dot- com）を撮影するか、フォーラムにアクセスしてください： http://www.couchbase.org/forums/
ペリー・クリュッグ
同様のワークロードの例として、New Relicを検討します。彼らは1日に2,000億を超えるデータポイントをディスクにキャプチャし、バックエンドとしてMySQL 5.6（Percona）を使用しています。
ブログ投稿はこちらから入手できます： http://blog.newrelic.com/2014/06/13/store-200-billion-data-points-day-disk/