仮定のシナリオ:ユーザーの友達のチェックイン、投稿などの詳細を含むJSONをFacebookからダウンロードするとします。これらはアクティビティごとに友達ごとに1つのドキュメントとして提供されるため、8つのアクティビティがある場合、300人の友達を持つユーザーがシステムにFacebookに2400のリクエストを行い、2400のJSONドキュメントをダウンロードします。
これらの2400のドキュメントをマージして、アクティビティをdate_createdの降順で並べ替え、それらを一種の疑似ニュースフィードでページ送りしたいとします。このようにFacebookのニュースフィードを再作成する知恵についてコメントしないでください。
また、Facebookによって変更されたことが通知されたときに、このデータをすべて再ダウンロードしたいとします。 (FBには、アプリのユーザー向けにサブスクライブできる更新サービスがあります)。議論のために、すべてのデータを5分ごとに更新する必要があると仮定します。さらに、1,000人の同時ユーザーをサポートできるようにしたいとし、JSONドキュメントの平均サイズは25kbであると仮定します。
リレーショナルデータベースへの取り込み時にJSONを解析するよりもNoSQLの手法の方が優れているかどうか知りたいのですが。私には、map/reduceはparse/aggregateの同義語であり、両方のアプローチで同じことが発生する必要があるように見えます。 NoSQLを使用するとどのような利点がありますか?
NoSQLを使用するとどのような利点がありますか?
NoSQLは、ユーザー数が増えるにつれてより適切にスケーリングします。
従来のRDBMSは、実際には十分に拡張できません。あなたができることはすべて、問題により大きなマシンを投げることです。それらは分散システム(クラウドなど)にはあまり適していません。
NoSQLは(特定の状況下で)ドキュメント/ JSONのような階層構造の処理に優れています
理解しておくべき重要な点は、これらのストレージメカニズムはキーと値に基づいているため、「単に関連する」( RDBMSの目的)。
つまり、たとえば、特定のユーザーのすべてのレコードを非常に高速に簡単に取得できます。従来のリレーショナルデータベースでは、パフォーマンスを向上させるためにスキーマを非正規化するか、スキーマをクリーンに保つ必要がありますが、結合や大量の集計によってパフォーマンスが低下する可能性があります。
このように見てください:なぜハッシュマップ(キーバリューストア)は速いのですか?ハッシュはメモリアドレスに直接変換されるため、ほぼO(1)でハッシュマップからアイテムを取得できます(簡略化)。これとは対照的にバイナリインデックスを検索すると、O(log( n));
あなたの場合、すでにJSONに基づいているので、MongoDBまたはCouchDBが良い解決策になるかもしれません。
私の意見では、ここでNoSQLソリューションを使用することをお勧めします。ユーザーのすべてのアクティビティをフィードとして取得するとします。それらがデータストレージに適切に書き込まれている場合、理論的には、NoSQLは、何も結合したり、適切なインデックスについて心配したりすることなく、これで優れています。 @Earlzは、NoSQLデータベースに対してACID保証がないことも述べました。これによりNoSQLが高速になり、アプリケーションにACIDプロパティが必要なくなる可能性があります。試してみる!
さらに、この件について Martin Fowlerからの良い記事 があります。彼は私が本当に好きな素敵な図を作った:
Go 彼のページをチェックしてください NoSQLについての深い考えを読んでください。
まず、NoSQLデータベースは、SQLインターフェースを使用しないデータベースです。すべてのNoSQLデータベースに共通しているのは、SQLインターフェースを使用しないことです。私は自分自身を繰り返しましたか?はい。しかし、NoSQLデータベースについてグループとして言えることは他にありません。インターネット上のNoSQLデータベースについて他に言われていることは、グループの一部のメンバーにとっては間違っているか、新しいデータベースのリリースや既存のデータベースの機能のアップグレードにより、将来的にそうなる可能性があります。
NoSQLデータベースが特定のジョブに適しているかどうかを尋ねることは、異なるNoSQLデータベースには非常に異なる特性があるため、実際には答えられない質問であると言っています。
最大の問題を説明するシナリオでは、毎秒8000のHTTPリクエストでFacebookに打撃を与えることは間違いありませんが、それを無視して、大量の小さなデータ片があるという非常に一般的な問題に焦点を当てましょう。
他のすべてのものが等しい場合、データベースから8バイト文字列と16バイト文字列をフェッチする場合のパフォーマンスの違いは何ですか?これは重要ではなく、SQLかどうかにかかわらず、どのデータベースにも当てはまるあいまいな反例を除いて、リクエストで発生する他のすべてのオーバーヘッドによって、さらに8バイトをコピーするのにかかる時間が短縮されます。データベースを介してデータを高速でシフトしたい場合、ユースケースに適合する大きなブロックにデータをソートすることは、実行できる最も重要なことの1つであり、多くの場合、使用するデータベースソフトウェアよりもはるかに重要です。
もちろん、データの大きなチャンクを使用するのに適さない場合もあります。場合によっては、元の分割形式とチャンクの両方でデータを保持するキャッシュ戦略がうまく機能することもありますが、それ以外のことはあまりありません細かい部分は分けておいてください。
データベースが遅い、つまり、一般的なプログラムでデータ操作関数を実装する場合(たとえば、多数の小さな文字列を取得してそれらを1つに結合する場合)、データベースリクエストを介して同様の機能を実装すると、データベースバージョンは通常、操作の実行には100〜1000倍の時間がかかります。もちろん、正確な数値はデータベースによって異なります。一部のデータベースではそれができないため、すべてのデータをフェッチして操作を実行し、結果をデータベースに書き込むプログラムを作成する必要があります。また、かなり遅い方法です。
一般に、データベースに書き込む前にデータに対して合理的に実行できることをデータベースで実行しないでください。
これらの考慮事項をすべて終えたら、データベースのどの要件を残しましたか?一部のデータベースで提供されているファンシー/スロー機能を必要としない構造を思いついたのですか?そうした場合、SQLデータベースは鈍い刃のあるスイスのナイフのようなもので、多くのクールな機能がありますが、必要なものには特に優れていません。一部のNoSQLデータベースは、単純な機能のみが必要な場合に、より高速で優れているものもあれば、SQLデータベースと同じくらいうまく機能しないものもあります。
この投稿の最後に書かれているにもかかわらず、私が述べた他のすべての質問の前に質問する必要があります。実際にデータベースが必要ですか?
かなりの量のデータを処理する場合は、データベースを使用する必要があるというのはかなり一般的な仮定です。しかし、現代のコンピュータでは、数ギガバイトのデータをアプリケーションメモリに格納できます。これにより、すばやく簡単にアクセスでき、操作のための優れたツールがすぐに利用できます。それがあなたに与えない一つのことは持続性です、そこのプログラムクラッシュが停電があるならば、データは失われます。ただし、完全に許容できる多くの場合、例には5分の寿命のデータがあり、永続性は必要ありません。データベースは必要ありません。