EC2サーバー上のMongoDBまたはAWS SimpleDB？

Question

どのシナリオがより理にかなっていますか？MongoDBがインストールされた複数のEC2インスタンスをホストしますか、それともAmazon SimpleDB Webサービスを使用しますか？

MongoDBで複数のEC2インスタンスを使用している場合、自分でインスタンスを設定する問題があります。

SimpleDBを使用すると、Amazonのデータ構造にロックされてしまうという問題がありますか？

開発に関してはどのような違いがありますか？ MongoDBまたはAWS SimpleDBに書き込むために、サービスレイヤーのDAOを切り替えるだけでよいのではないですか？

sirmak · Accepted Answer

SimpleDBには、いくつかのスケーラビリティの制限があります。シャーディングによってのみスケーリングでき、mongodbやcassandraよりもレイテンシが高く、スループットの制限があり、他のオプションよりも価格が高くなっています。スケーラビリティは手動です（シャーディングする必要があります）。

より広いクエリオプションが必要で、読み取り率が高く、データがあまりない場合は、mongodbの方が適しています。ただし、耐久性を確保するには、少なくとも2つのmongodbサーバーインスタンスをマスター/スレーブとして使用する必要があります。そうしないと、データの最後の分を失う可能性があります。スケーラビリティは手動です。 simpledbよりもはるかに高速です。自動シャーディングは1.6バージョンで実装されています。

Cassandraには弱いクエリオプションがありますが、postgresqlと同じくらい耐久性があります。 mongoと同じくらい高速で、データサイズが大きいほど高速です。書き込み操作は、cassandraでの読み取り操作よりも高速です。 ec2インスタンスを起動することで自動的にスケーリングできますが、設定ファイルを少し変更する必要があります（私が正しく覚えている場合）。テラバイトのデータがある場合cassandraが最善の策です。データをシャーディングする必要はありません。1日目から配布されるように設計されています。すべてのデータのコピーをいくつでも持つことができます。一部のサーバーは停止しています。稼働中のサーバーの結果を自動的に返し、停止したサーバーのデータを他のサーバーに配布します。フォールトトレラント性が高いです。インスタンスをいくつでも含めることができ、他のオプションよりもはるかに簡単にスケーリングできます。強力な.netとJavaクライアントオプション。接続オプション、ロードバランシング、停止したサーバーのマーキングなど...

もう1つのオプションはビッグデータ用のhadoopですが、他のオプションほどリアルタイムではありません。データウェアハウジングにhadoopを使用できます。 cassandraまたはmongoにはトランザクションがないため、トランザクションが必要な場合はpostgresqlが適しています。別のオプションはAmazon RDSですが、パフォーマンスが低く、価格が高くなります。データベースを使用する場合、またはsimpledbデータキャッシュも必要になる場合があります（例：memcached）。

Webアプリの場合、データが小さい場合は、mongoをお勧めします。大きい場合は、cassandraの方が良いです。mongoやcassandraのキャッシュレイヤーは必要ありません。すでに高速です。私はそうではありません。 simpledbはお勧めしません。また、あなたが言ったようにAmazonにロックされます。

C＃を使用している場合は、Javaまたはscalaインターフェースを記述して、mongo、mysql、cassandraまたはデータアクセスレイヤーの何か。動的言語（rub、python、phpなど）のほうが簡単です。必要に応じて2つのプロバイダーを作成し、構成の変更だけで実行時にストレージを変更できます。「すべて可能です。mongo、cassandra、simpledbを使用した開発は、データベースよりも簡単で、スキーマを使用しません。また、使用しているクライアントライブラリ/コネクタにも依存します。最も単純なものはmongoです。インデックスは1つだけです。 cassandraのテーブルなので、他のインデックスを自分で管理する必要がありますが、0.7リリースのcassandraセカンダリインデックスは私が知っているように可能です。それらのいずれかで開始して置き換えることもできます。あなたがしなければならない場合、将来的に。

Gates VP · Answer

時間と速度の両方の問題があると思います。

MongoDB/Cassandraははるかに高速になりますが、それらを実行するには$$$を投資する必要があります。これは、すべてのサーバーインスタンスを実行/セットアップする必要があることを意味します。それらがどのように機能するかを調べます。

一方、「トランザクションごと」のコストごとに直接支払う必要はありません。大規模なサービスではおそらくより効率的なハードウェアの料金を支払うだけです。

Cassandra/MongoDBの戦いでは、ここにあなたが見つけるものがあります（過去数日間に私が個人的に行ったテストに基づいています）。

カサンドラ：

スケーリング/冗長性は非常に重要です
構成は非常に激しい場合があります
レポートを作成するには、map-reduceが必要です。そのためには、hadoopレイヤーを実行する必要があります。これは構成するのが面倒で、パフォーマンスを上げるのがもっと面倒でした。

MongoDB：

構成は比較的簡単です（今週の新しいシャーディングでも）
冗長性はまだ「そこにある」
Map-reduceは組み込みで、データを簡単に取り出すことができます。

正直なところ、数十GBのデータに必要な構成時間を考慮して、MongoDBを使用しました。「これらを実行する必要がある」場合にSimpleDBを使用することを想像できます。しかし、MongoDBを実行するようにノードを構成するのは、途方もなく単純なので、「SimpleDB」ルートをスキップする価値があるかもしれません。

DAOに関しては、Mongo用のライブラリがすでにたくさんあります。 CassandraのThriftフレームワークは十分にサポートされています。接続を抽象化するための簡単なロジックを書くことができます。しかし、単純なCRUDよりも複雑なものを抽象化することは難しいでしょう。

Salvador Dali · Answer

5年後の今、どのOSでもMongoをセットアップするのは難しくありません。 Documentation は簡単に理解できるため、Mongoの設定が問題になるとは思いません。他の回答はスケーラビリティの問題に対処したので、開発者の視点からの質問に対処しようとします（各システムにどのような制限があるか）。

SimpleDBにはSを、MongoにはMを使用します。

MはC++で書かれ、SはErlangで書かれています（最速の言語ではありません）
Mはオープンソースであり、どこにでもインストールされ、Sは独自仕様であり、Amazon AWSでのみ実行できます。また、Sに対しては、スタッフ全体に対して支払う必要があります
Sには奇妙な制限がたくさんあります。 M limitations の方がはるかに合理的です。最も奇妙な制限は次のとおりです。
- ドメイン（テーブル）の最大サイズは10 GB
- 属性値の長さ（フィールドのサイズ）は1024バイト
- selectレスポンスの最大アイテム-2500
- selectの最大応答サイズ（Sが返すことができるデータの最大量）-1Mb
S supports only a few languages (Java, php, python, Ruby, .net), M supports way more
どちらもRESTをサポート
Sのクエリ構文はSQLとよく似ています（ただし、強力ではありません）。 Mでは、jsonのような新しい構文を学ぶ必要があります（基本を学ぶのも簡単です）
mでは、データベースの構築方法を学習する必要があります。スキーマレスとは、データベースにジャンクを投げて簡単に抽出できると多くの人が考えているため、ジャンクイン、ジャンクアウトの格言が機能することに驚かれる可能性があります。 Sも同じだと思いますが、確実に主張できません。
どちらも大文字と小文字を区別しない検索を許可しません。 Mでは、正規表現を使用して、小文字のフィールド/アプリケーションロジックを追加せずに、何らかの方法で（醜い/インデックスなし）この制限を克服できます。
sでのソートは、1つのフィールドでのみ実行できます
5秒のため、Sの時間制限カウントは奇妙な動作をする可能性があります。 5秒経過してもクエリが終了しない場合は、部分的な数値と、クエリを続行できるトークンが表示されます。アプリケーションロジックは、このすべてのデータをまとめて収集する責任があります。
すべてがUTF-8文字列であるため、Sで文字列以外の値（数値、日付など）を処理するのは難しいです。タイプのサポートは way richer です。
どちらにもトランザクションと結合はありません
Mは compression をサポートします。これは、同じフィールド名がもう一度保存されるnosqlストアに非常に役立ちます。
Sは単一のインデックスのみをサポートし、M は単一、複合、マルチキー、地理空間などを持ちます。
どちらもレプリケーションとシャーディングをサポートしています

考慮すべき最も重要なことの1つは、SimpleDBには非常に初歩的なクエリ言語があることです。 group by、sum average、distinctなどの基本的なものやデータ操作はサポートされていないため、機能はRedis/Memcachedよりもはるかに豊富ではありません。一方、Mongoは豊富なクエリ言語をサポートしています。