1台のマシン上の構造化データについて、RDBMSよりもNoSQLにREALの利点はありますか？
したがって、私は、NoSQLが自動シャーディングとUNSTRUCTUREDデータの処理以外に多くの価値をもたらしているかどうかを理解するために懸命に努力してきました。
STRUCTUREDデータを1台のマシンに収めることができると仮定すると、ORにはSQLの効果的な「自動シャーディング」機能がありますが、NoSQLオプションにはどのような利点がありますか？以下を決定しました。
ドキュメントベース（MongoDB、Couchbaseなど）-「自動シャーディング」機能の外では、利点がどこにあるのかを理解するのに苦労しています。リンクされたオブジェクトはSQL結合に非常に似ていますが、埋め込みオブジェクトはドキュメントサイズを大幅に膨らませ、レプリケーションに関する問題を引き起こします（コメントは投稿とユーザーの両方に属している可能性があるため、データは冗長になります）。また、ACIDとトランザクションの損失は大きな欠点です。
Key-Valueベース（Redis、Memcachedなど）-異なるユースケースを提供します。キャッシングには理想的ですが、複雑なクエリには適していません
Columnar（Cassandra、HBaseなど）-ここでの大きな利点は、データがディスクに保存される方法であり、一般的な使用ではなく集計に最も役立つようです
グラフ（Neo4j、OrientDBなど）-最も興味深いのは、エッジとノードの両方を使用することで興味深い価値提案ができることですが、ほとんどの場合、一般的な使用ではなく非常に複雑なリレーショナルデータに役立ちます。
特定のユースケース（キャッシング、ソーシャルネットワーク関係マッピング、集計）のKey-Value、Columnar、およびGraph DBの利点を確認できますが、構造化されたデータのMongoDBのようなものを 'auto-シャーディング機能。
SQLに同様の「自動シャーディング」機能がある場合、SQLは構造化データにとって非常に簡単でしょうか？それは私には思えるが、コミュニティの意見が欲しい...
注：これは、ソーシャルネットワーク、eコマースサイト、CMSなどの一般的なCRUDアプリケーションに関するものです。
単一のサーバーから始める場合は、NoSQLの多くの利点が出てきます。最も一般的なNoSQLの最大の利点は、ダウンタイムの少ない高可用性です。結果整合性の要件は、パフォーマンスの向上にもつながります。それは本当にあなたのニーズに依存します。
ドキュメントベース-データが少数の小さなデータバケットにうまく収まる場合は、ドキュメント指向のデータベースです。たとえば、クラシファイドサイトでは、コアデータとしてユーザー、アカウント、およびリスティングがあります。検索および表示操作の大部分は、リストのみに対するものです。従来のデータベースでは、1つのリストのデータを取得するために、40近くの結合操作を実行する必要があります。 NoSQLでは、これは単一のクエリです。 NoSQLを使用すると、ネストされたデータに対してインデックスを作成することもできます。この場合も、Joinを使用せずにクエリを実行します。この場合、実際には、検索と表示のためにSQLからMongoDBにデータをミラーリングしています（他の理由があります）。現在、より長期の移行戦略に取り組んでいます。 ElasticSearch、RethinkDBなどは、優れたデータベースでもあります。 RethinkDBは実際にはデータに対して非常に保守的なアプローチを採用しており、ElasticSearchの独創的なインデックス付けは誰にも負けません。
Key-Valueストア-キャッシュはここで優れたユースケースです。データがほとんど読み取られる中〜大容量のWebサイトを実行している場合、優れたキャッシュ戦略だけでも、1台のサーバーで処理されるユーザーの4〜5倍の効果があります。 Key-Valueストア（RocksDB、LevelDB、Redisなど）も、グラフデータの非常に優れたオプションです。個別のマッピングは、上位のグラフ作成オプションで非常に高速なサブジェクト述語ターゲット値で保持できるためです。
Columnar-Cassandra特に、単一値のルックアップであっても、大量の負荷を分散するために使用できます。Cassandraのスケーリングは、使用中のサーバー数に非常に比例します。大量の読み取りおよび書き込みシナリオに最適です。これは、ライブ検索ではあまり価値がありませんが、[〜＃〜]非常に良い場合に最適です〜 ＃〜]高負荷で分散する必要があります。計画にはかなり時間がかかり、ニーズに合わない可能性があります。CAPのニーズに合わせて設定を微調整したり、ボックス。注：ほとんどのアプリケーションは強調して[〜＃〜] [〜＃〜]このレベルの使用を必要としません。ElasticSearchは、HBaseを検討するほとんどのシナリオに適しています。/HadoopまたはCassandra for。
Graph-私はグラフデータベースに精通していないため、ここではコメントできません（基になるオプションとしてKey-Valueストアを使用する以外）。
次に、MongoDBとSQLを具体的に比較してSQLについてコメントします。特にPostgreSQLは、PLV8などから得られるパワーは言うまでもなく、無制限のデータ（JSON/JSONBタイプ）を使用できるようにするという点で多くの進歩を遂げました。 NoSQLの利点を備えたドキュメントストア。フォールダウンが発生するのは、レプリケーション、シャーディング、フェイルオーバーがソリューションではなく、ボックスに組み込まれているためです。
中小規模の負荷の場合、シャーディングは実際には最善のアプローチではありません。ほとんどのシナリオは主に読み取られるため、追加の読み取りノードがあるレプリカセットを使用すると、通常3〜5台のサーバーがある場合に適しています。 MongoDBはこのシナリオで優れており、マスターノードが自動的に選択され、フェイルオーバーはかなり高速です。私が見た唯一の奇妙な点は、Azureが2014年後半にダウンしたときで、サーバーの1つだけが最初に起動し、他の2つはほぼ40分後に起動しました。レプリケーションを使用すると、特定の読み取り要求を1台のサーバーで全体的に処理できます。データ構造がシンプルになり、データ損失の可能性が減少します。
上の私の例でも、中規模のクラシファイドサイトの場合、データの大部分は単一のコレクションに属しています...検索され、そのコレクションから表示されます。この使用例では、ドキュメントストアは構造化/正規化されたデータよりも優れています。オブジェクトの格納方法は、アプリケーションでの表現に非常に近くなっています。認知的断絶は少なく、それは単に機能します。
実際、SQL JOIN操作は、特にそれらの結合間でデータを集約するときに、パフォーマンスを低下させます。 1人のユーザーが1つのクエリを実行する場合は、何十人でも問題ありません。数千の同時ユーザーによる数十の結合に到達すると、バラバラになり始めます。この時点でいくつかの選択肢があります...
Caching-キャッシュは常に優れたアプローチであり、データの変更頻度が少ないほど、アプローチは優れています。これは、memcache/redisインスタンスのセットから、MongoDB、RethinkDB、ElasticSearchなどを使用して複合レコードを保持するものまで、さまざまです。ここでの課題は、キャッシュされたデータを更新または無効にすることです。
移行-ニーズをより適切に表すデータストアにデータを移行することも良いアイデアです。大規模な書き込み、または非常に大規模な読み取りシナリオを処理する必要がある場合、SQLデータベースは対応できません。 SQLでFacebookやTwitterのようなものを[〜＃〜]決して[〜＃〜]処理することはできません。
間にあるもの-スケーリングする必要があるので、それはあなたが何をしているのか、そしてあなたにとっての一番の解決策はどこにあるのかというあなたの問題点に依存します与えられた状況。多くの開発者や管理者は、データが複数の場所に分割されることを恐れていますが、これが多くの場合最良の答えです。あなたの分析データは本当にコアの運用データと同じ場所にある必要がありますか？そのためには、ログインを密結合する必要がありますか？相関クエリをたくさん行っていますか？それは本当に依存します。
今後の個人的な意見
私にとって、SQLが提供するセーフティネットが好きです。それをコアデータの中央ストアとして持つことが、私の最初の選択肢です。私はRDBMSをダムストレージとして扱う傾向があり、特定のプラットフォームに縛られるのは好きではありません。多くの人がデータを過度に正規化しようとしているように感じます。多くの場合、XMLまたはJSONフィールドをテーブルに追加して、スキームが肥大化することなく、特にクエリされる可能性が低い場合に、追加のデータを保存できるようにします...次に、アプリケーションコードのオブジェクトにプロパティを設定します。それらのフィールドに格納します。良い例は支払いかもしれません...現在1つのシステムまたは複数のシステム（1つはCC、Paypal、Google、Amazonなど）を使用している場合、トランザクションの詳細は実際にはレコードに影響しません。この詳細なデータを保存する5つ以上のテーブル。プライマリストレージにJSONを使用し、そのJSONから派生および永続化された計算列を使用して、必要に応じてクエリ機能を拡張し、インデックスを作成することもできます。 postgresqlやmysql（iirc）などのデータベースは、JSONデータに対する直接インデックス作成も提供します。
データがドキュメントストアに自然に適合する場合、私はそれを行うと言います...クエリの大部分が単一のレコードまたはコレクションによりよく適合するものに対するものである場合、非正規化します。これをプライマリデータのミラーとして使用するのは素晴らしいことです。
書き込みが多いデータの場合は、複数のシステムを使用する必要があります...これは、ここでのニーズに大きく依存します...高速なホットクエリパフォーマンスが必要ですか？ ElasticSearchを使用してください。絶対に大規模な水平スケール、HBaseまたはCassandraが必要ですか。
ここでの重要なポイントは、混同することを恐れないことです...実際にすべてに適合する1つのサイズはありません。余談ですが、PostgreSQLがレプリケーション（自動化されたフェイルオーバー）のためだけの（オープンソースバージョンの）ボックス内の優れたソリューションを思いついた場合、それらはその時点で最も優れた位置にあると私は感じています。
私は実際には入りませんでしたが、ハイブリッドSQLシステムを提供するSaaSソリューションおよび他のプロバイダーが多数あることを言及する必要があります。MySQL/ MariaDBに対してローカルで開発し、 SQLが分散ストレージクラスターの上にあるシステムです。HBaseまたはElasticSearchの方がロギングと分析データに適していると感じていますが、SQL on topソリューションも魅力的です。
スキーマレスストレージ（またはスキーマフリー）。ストレージの「宣言された」スキーマを変更せずに、ストレージを変更する機能（基本的にレコードに新しいフィールドを追加）。 RDBMSでは、「フィールド」を明示的に宣言する必要があり、新しい「フィールド」を保存する前にスキーマを明示的に変更する必要があります。スキーマフリーのストレージエンジンを使用すると、アプリケーションをすばやく変更できます。追加のフィールドを保存するようにアプリのコードを変更するか、フィールドの名前を変更するか、フィールドをドロップして実行します。
従来のRDBMSの人々は、スキーマフリーのa disadvantageを考えています。長期的には、ストレージにクエリを実行し、異種レコードを処理する必要があるためです（一部には一部のフィールドがあり、一部には他のフィールドがある）と、難しい処理します。しかし、最初の段階では、スキーマのないことは圧倒的に魅力的です。なぜなら、高速な反復と市場投入までの時間がすべての問題だからです（そして多くの場合はそうです）。
ORデータベースには効果的な自動シャーディング機能があるので、どちらのデータも1台のマシンに収まると想定してください。
SQLデータに自動シャーディング機能があるという想定に沿って、つまり、クラスターの実行について話していることになります。マシンのクラスターを実行しているときはいつでも、フォールトトレランスについて心配する必要があります。
たとえば、アプリケーション関数ごとにデータをシャーディングする最も簡単な方法を使用していて、すべてのユーザーアカウントデータをサーバーAに保存し、製品カタログをサーバーBに保存しているとします。
サーバーAがダウンし、どのユーザーもログインできない場合、あなたのビジネスは受け入れられますか？
サーバーBがダウンし、誰も物を買えなくなった場合、あなたのビジネスは受け入れられますか？
そうでない場合は、データ複製と高可用性フェイルオーバーの設定について心配する必要があります。 SQLデータベースでは実行可能ですが、快適ではありません。他のタイプのシャーディング戦略（キー、ルックアップサービスなど）にも同じ課題があります。
多くのNoSQLデータベースは、レプリケーションとフェイルオーバーを自動的に処理します。ほんの少しの設定で、箱から出してそれを行う人もいます。これは、運用上の観点から大きなメリットです。
完全な開示：私はFoundationDBのエンジニアです。NoSQLデータベース 自動的に は、シャーディング、レプリケーション、フェイルオーバーを処理します設定はほとんどありません。 SQLレイヤー もあるので、構造化データをあきらめる必要はありません。