コンテンツで検索する必要がある大規模なデータセットに対してNoSQLデータベースを使用することは非現実的ですか？
私は1週間、NoSQLデータベースについて学びました。
NoSQLデータベースの利点と、それらが優れている多くのユースケースを本当に理解しています。
しかし、多くの場合、人々はNoSQLがreplace Relational Databasesであるかのように記事を書きます。そして、私は頭を動かすことができないポイントがあります：
NoSQLデータベースは（多くの場合）キーと値のストアです。
もちろん、（JSONやXMLなどでデータをエンコードすることにより）すべてをKey-Valueストアに保存することは可能ですが、問題は多くのユースケースで、特定の基準に一致するデータをgetする必要があるということです。 NoSQLデータベースでは、効果的に検索できる基準は1つだけです-キー。リレーショナルデータベースは、データ行の値を効果的に検索するように最適化されています。
そのため、NoSQLデータベースは、コンテンツで検索する必要があるデータを永続化するための実際の選択肢ではありません。または私は何かを誤解しましたか？
例：
ウェブショップのユーザーデータを保存する必要があります。
リレーショナルデータベースでは、すべてのユーザーをusersテーブルの行として、ID、名前、国などとともに保存します。
NoSQLデータベースでは、各ユーザーをIDをキーとして、ユーザーのすべてのデータ（JSONなどでエンコード）を値として格納します。
したがって、特定の国からすべてのユーザーを取得する必要がある場合（何らかの理由でマーケティング担当者がそれらについて知る必要がある場合）は、リレーショナルデータベースでは簡単に実行できますが、NoSQLデータベースではあまり効果的ではありません。 geteveryユーザー、データの解析all、およびフィルター。
不可能だとは言いませんが、かなりトリッキーになり、NoSQLエントリのデータを検索する場合はそれほど効果的ではないと思います。
この国に住んでいるすべてのユーザーのキーを格納する国ごとのキーを作成し、この国のキーに保管されているすべてのキーを取得することにより、特定の国のユーザーを取得できます。しかし、この手法は複雑なデータセットをさらに複雑にするものだと思います。実装が難しく、SQLデータベースのクエリほど効果的ではありません。だから、それはあなたが本番で使う方法ではないと思います。またはそれは？
そのようなユースケースを処理するために何かを誤解したり、いくつかの概念やベストプラクティスを見落としたりしたかどうかは、本当にわかりません。たぶん、私の声明を訂正して私の質問に答えることができるでしょう。
NoSQLはすべてのデータベースの問題の万能薬ではないというあなたの前提に同意しますが、1つの重要なポイントを誤解していると思います。
NoSQLデータベースでは、効果的に検索できる基準は1つしかありません-キー。
これは明らかに真実ではありません。
たとえば、MongoDBはインデックスをサポートしています。 （ https://docs.mongodb.org/v3.0/core/indexes-introduction/ から）
インデックスは、MongoDBでのクエリの効率的な実行をサポートします。インデックスがない場合、MongoDBはコレクションスキャンを実行する必要があります。つまり、コレクション内のすべてのドキュメントをスキャンして、クエリステートメントに一致するドキュメントを選択する必要があります。クエリに適切なインデックスが存在する場合、MongoDBはインデックスを使用して、検査する必要のあるドキュメントの数を制限できます。
インデックスは、コレクションのデータセットのごく一部を簡単にトラバースできる形式で格納する特別なデータ構造[1]です。インデックスには、特定のフィールドまたはフィールドセットの値が、フィールドの値順に並べられて格納されます。インデックスエントリの順序は、効率的な等価一致と範囲ベースのクエリ操作をサポートします。さらに、MongoDBはインデックスの順序を使用して、ソートされた結果を返すことができます。
Couchbaseと同様（ http://docs.couchbase.com/admin/admin/Views/views-intro.html から）
Couchbaseビューは、データのインデックス作成とクエリを可能にします。
ビューは、定義された形式と構造に従ってデータにインデックスを作成します。ビューは、Couchbaseのオブジェクトから抽出された特定のフィールドと情報で構成されます。
実際、Key-Valueストアではなく、自身をNoSQLデータベースと呼ぶものは、なんらかの種類のインデックススキーマを実際にサポートする必要があります。
実際、NoSQLを際立たせるのは、多くの場合、これらのインデックススキーマの柔軟性です。私の意見では、NoSQLインデックスの定義に使用される言語は、SQLよりも表現力豊かで自然であることが多く、通常はテーブルの外にあるため、それらをサポートするためにテーブルスキーマを変更する必要はありません。 （SQLで同様のことはできないと言っているのではありませんが、私には、より多くのフープジャンプが含まれているように感じます）。
一般的に言えば、ワークフローがリレーショナルデータベースクエリに完全に一致する場合、リレーショナルデータベースが最も効率的なアプローチであることがわかります。その一種のトートロジーですが、それは本当です。
多くのNoSQL支持者がする主張は、多くのワークフローが実際にリレーショナル形式にマッサージされ、そのようなマッサージの前により効果的だったということです。この主張の妥当性を確認することは複雑です。 SQLクエリで非常によく記述されているジョブがあるのは明らかです。私の経験から言うと、my特定のリレーショナルプログラミングタスクは、NoSQLを使用して、ほぼ同じレベルの効率で、それ以上ではないにせよ、実行できたはずです。ただし、これは狭い経験に基づく非常に主観的な発言です。
私は、NoSQLアプローチの売り上げの大部分が、大規模なデータベースを前提としていると感じています。データベースが大きくなるほど、より大きなデータセットをサポートするためにワークフローを整備する必要があります。 NoSQLは、グルーミング作業のサポートに優れているようです。したがって、データベースが大きくなるほど、NoSQLの機能がより重要になる可能性があります。
この例を使用するには、SQLで国別にusersテーブルにインデックスを付けるように明示的に指定しない限り、国別のクエリはすべてのユーザーのNoSQLスキャンと同じくらい遅くなります。 NoSQLでも同じことができ、インデックスである順序付けされたキーと値のコレクションを作成し（SQLが内部で行うように）、それを維持します。
違い？ SQLエンジンには、テーブルにインデックスを付けるという概念が組み込まれていました。つまり、必要な作業が少なくなります（テーブルにインデックスを追加するだけで済みました）。しかし、それはまた、あなたがより少ないコントロールを持っていたことを意味します。ほとんどの場合、SQLエンジンが代わりに作業を行う代わりに、その制御の喪失は許容されます。ただし、大規模なデータセットでは、通常のSQL ACIDモデルとは異なる整合性モデルが必要になる場合があります。結果整合性をサポートするBASEモデルを使用することもできます。 SQLエンジンはあなたのために仕事をしているので、SQLエンジンのルールによって行われなければならないので、それはSQLでは非常に難しいかもしれません。 NoSQLでは、これらのレイヤーは通常公開されており、ハッキングすることができます。
NoSQLは基本的にリレーショナルではないすべてのデータベースシステムを対象とするため、あいまいな用語です。
あなたが説明しているのは、Key-Value Storeです。これは、データのblobがキーの下に保存され、すばやく確認できるデータベースの一種ですあなたが鍵を知っているならアップ。これらのデータベースは、正確なキーがわかっている場合は非常に高速ですが、自分で言うように、データの複数のプロパティを検索またはフィルタリングする必要がある場合は、速度が遅く、扱いにくくなります。
一般的に、キーバリューストアがリレーショナルデータベースを置き換えることができると主張する人はいないでしょう。ただし、Key-Valueストアが適している特定のユースケースがある場合があります。キーと値のストアは、通常はIDでアイテムをキャッシュするため、キャッシュによく使用されますが、キャッシュに対してアドホッククエリを実行する必要はありません。たとえば、Stackoverflowサイト自体はRedis（キーと値のデータベース） 拡張的に を使用しますが、出力キャッシュにのみ使用します。基礎となる正規データは、まだリレーショナルデータベースに保持されています。
したがって、答えはかなり明白です。単一のキーを使用して格納および検索するだけでよい場合は、Key-Valueストアを使用します。それ以外の場合は、別の種類のデータベースを使用してください。疑問がある場合は、リレーショナルデータベースを使用してください。これは、最も用途の広い種類のデータベースですが、NoSQLデータベースは、非常に特定のユースケースに向けて最適化されることがよくあります。
リレーショナルデータベースに関するアサーションはすべて真実であり、データが大量にあり、そのコピーを単一のサーバーに収めることができなくなるまでは、これが当てはまります。次に、あらゆる種類の興味深い問題が発生し始めます。ほとんどのクエリを単一のサーバーで実行できるように、テーブルをどのように分割しますか？データのコピーをいくつ作成しますか？これらのコピー間の不整合にどのように対処しますか？ユーザーのデータを地理的に比較的近いデータセンターにどのように保持しますか？
これらの目標はしばしば互いに矛盾します。多くのTwitterユーザーが世界中の人々をフォローしています。 Twitterのデータベースは、ツイートを読んだり、書き込んだりするために地理的に最適化する必要がありますか？
この種のスケールに対処すると、ソリューションの発明、冗長性の追加、NoSQLデータベースに非常によく似た制限の適用を開始することがわかります。すべてのデータを1つのボックスに収めることができる場合は、制限が適用されるだけで、メリットは必要ありません。
NoSQLデータベースは、「No SQL」とはほとんど関係がありません。
彼らはあなたがデータベースを持てないことを認めていますスケールで常に一貫していますand複雑なトランザクションをサポートしますand耐久性があります。
通常のリレーショナルデータベースでは、すべてのインデックスがトランザクションのスコープ内で自動的に更新されるため、任意のクエリで使用できます。
NoSQLデータベースでは、プログラマーが多くの索引を保守する責任があり、索引は常に古くなっていると想定されます。
例えば：
- 税番号による人のインデックスには、税の登録プロセスを完了していない人が含まれる場合があります。
- したがって、インデックスを使用するコードは、税金の不完全な登録に対処できなければなりません
- 別のオプションは、税に登録されている人がインデックスに登録されていない場合があります。 （したがって、設計は一貫したデータがないことに対処し、データがどのように一貫しないかを決定する必要があります。）
実際の例として、Amazonは、106台のコンピューターが正しいロックが解除されたことを確認するまでWebページの表示を遅らせるのではなく、古くなった本の説明を表示します。
したがって.....
単一の通常のリレーショナルデータベースがすべてのデータを保持し、ロックによってシステムが有用な作業を停止しないほど十分に速く各トランザクションを処理できる場合、リレーショナルデータベースが最適なオプションです。
しかし、複数のリレーショナルデータベースを使用するか、ロックエラーを回避するためにトランザクションを分割することを考える必要があるとすぐに、「NoSQL」データベースを使用するときに発生する種類の問題に対処する必要がある道を進んでいます。
「NoSQL」データベースはこれらの問題を隠さないので、システムをスケールアップするとき、それらは最良のオプションになるかもしれません。 ただし、Stackoverflowは引き続き、すべてのデータを保存するためにリレーショナルデータベースを使用し、キャッシングレイヤーでのNoSQLの使用は制限されています。そのため、NoSQLを使用してデータを保存するよう強制される前に、非常に大きくする必要があります。 =
リレーショナルデータベースは、データ行の任意の値を効果的に検索するように最適化されています。
行の「すべて」の値と行の「すべて」の値を検索する機能を混同しないでください。これを行う最も効果的な方法は、1つ以上のインデックスを必要とします。インデックスにすべてのフィールドを含めることもできますが、その場合、インデックスの変更（挿入、更新、削除）を必要とする変更を加えることができなくなります。あなた（またはあなたのDBA）は、データ、使用法、ボトルネックなどを理解する必要があります。