コンテンツで検索する必要がある大規模なデータセットでは、NoSQLデータベースの使用は非実用的ですか？

1週間、NoSQLデータベースについて学んでいます。

NoSQLデータベースの利点と、それらが優れている多くのユースケースを本当に理解しています。

しかし、多くの場合、NoSQLがリレーショナルデータベースを置き換えることができるかのように記事を書きます。そして、頭を動かせない点があります。

NoSQLデータベースは（多くの場合）キーと値のストアです。

もちろん、（JSON、XMLなどでデータをエンコードすることで）すべてをキーと値のストアに保存することは可能ですが、多くの場合、特定の基準に一致するデータを取得する必要があるという問題がありますユースケース。NoSQLデータベースでは、効果的に検索できるキーは1つだけです。リレーショナルデータベースは、データ行の任意の値を効果的に検索するように最適化されています。

そのため、NoSQLデータベースは、コンテンツで検索する必要がある永続的なデータには実際には選択できません。または、私は何かを誤解しましたか？

例：

Webショップのユーザーデータを保存する必要があります。

リレーショナルデータベースでは、すべてのユーザーをusersテーブルの行として、ID、名前、国などとともに保存します。

NoSQLデータベースでは、各ユーザーを自分のIDをキーとして、すべてのデータ（JSONなどでエンコードされた）を値として保存します。

したがって、特定の国からすべてのユーザーを取得する必要がある場合（何らかの理由でマーケティング担当者が彼らについて何かを知る必要があります）、リレーショナルデータベースでは簡単に行えますが、NoSQLデータベースではあまり効果的ではありません。すべてのユーザーを取得し、すべてのデータを解析してフィルターします。

私はそれが不可能だとは言いませんが、それははるかにトリッキーになり、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/admin/Views/views-intro.htmlから）

Couchbaseビューは、データのインデックス作成とクエリを可能にします。

ビューは、定義された形式と構造に従ってデータにインデックスを作成します。ビューは、Couchbaseのオブジェクトから抽出された特定のフィールドと情報で構成されています。

実際、キーバリューストアではなくNoSQL データベースと呼ばれるものはすべて、何らかのインデックススキームを実際にサポートする必要があります。

実際、多くの場合、これらのインデックススキームの柔軟性がNoSQLを輝かせています。私の意見では、NoSQLインデックスの定義に使用される言語は、SQLよりも表現力が高いか自然であることが多く、通常はテーブルの外側にあるため、それらをサポートするためにテーブルスキーマを変更する必要はありません。（SQLで同様のことができないと言うわけではありませんが、私にはもっと多くのフープジャンプが関係しているように感じます）。

一般的に、ワークフローがリレーショナルデータベースクエリに完全に一致する場合、リレーショナルデータベースが最も効率的なアプローチであることがわかります。その種類のトートロジーですが、本当です。

多くのNoSQL支持者が行う主張は、多くのワークフローが実際にリレーショナル形式にマッサージされており、そのようなマッサージの前にはより効果的だったということです。この主張の有効性を確認するのは複雑です。明らかに、SQLクエリで非常によく記述されているジョブがあります。私の経験から言えば、特定のリレーショナルプログラミングタスクは、NoSQLを使用してほぼ同じレベルの効率で実行できたはずです。しかし、それは狭い経験に基づいた非常に主観的な声明です。

NoSQLアプローチの売り上げの大部分は、大規模なデータベースを想定しているためだと感じています。データベースが大きいほど、より大きなデータセットをサポートするためにワークフローをグルーミングする必要があります。NoSQLは、そのグルーミング作業をサポートするのに優れているようです。したがって、データベースが大きいほど、NoSQLの機能はより重要になる可能性があります。

この例を使用すると、users国によるテーブルのインデックス作成を明示的にSQLに指示しない限り、SQLでの国によるクエリはすべてのユーザーのNoSQLスキャンと同じくらい遅くなります。NoSQLは同じことを行うことができ、インデックスである順序付けられたキーと値のコレクションを作成し（SQLが内部で行うように）、それを維持します。

違い？SQLエンジンには、テーブルにインデックスを作成するという概念が組み込まれていました。つまり、実行する作業が少なくなりました（テーブルにインデックスを追加するだけで済みました）。しかし、それはまた、あなたがコントロールできなかったことを意味します。ほとんどの場合、SQLエンジンが代わりに作業を行うのと引き換えに、その制御の喪失は許容されます。ただし、大規模なデータセットでは、一般的なSQL ACIDモデルとは異なる整合性モデルが必要になる場合があります。最終的な整合性をサポートするBASEモデルを使用できます。SQLエンジンはあなたのために仕事をしているので、それはSQLエンジンのルールによって行われなければならないので、それはSQLでは非常に難しいかもしれません。NoSQLでは、これらのレイヤーは通常公開されており、ハッキングすることができます。

NoSQLは、基本的にリレーショナルではないすべてのデータベースシステムを対象とするため、かなり曖昧な用語です。

説明するのは、キーと値のストアです。これは、データのBLOBがキーの下に格納される一種のデータベースであり、キーを知っている場合はすばやく検索できます。正確なキーを知っている場合、これらのデータベースは非常に高速ですが、あなたが言うように、データの複数のプロパティを検索またはフィルタリングする必要がある場合、それは遅くて面倒です。

彼らの正しい考えの誰も、キーバリューストアが一般にリレーショナルデータベースを置き換えることができると主張しません。ただし、キーバリューストアが適している特定のユースケースがあります。通常はIDでアイテムをキャッシュしますが、キャッシュを介してアドホッククエリを実行する必要がないため、キー値ストアはキャッシュによく使用されます。たとえば、Stackoverflowサイト自体はRedis（キーと値のデータベース）を広範囲に使用しますが、出力キャッシュのみに使用します。基になる標準データは、リレーショナルデータベースに保持されます。

したがって、答えは非常に明白です。単一のキーを使用して格納および検索する必要がある場合は、キーと値のストアを使用します。それ以外の場合は、異なる種類のデータベースを使用します。疑問がある場合は、リレーショナルデータベースを使用してください。これは最も汎用性の高い種類のデータベースであり、NoSQLデータベースは非常に特定のユースケース向けに最適化されていることが多いためです。

リレーショナルデータベースに関するあなたの主張はすべて真実であり、データのコピーが単一のサーバーに収まらないほど多くのデータを持っている時点までです。次に、あらゆる種類の興味深い問題に遭遇し始めます。ほとんどのクエリを単一のサーバーで実行できるように、テーブルをどのように分割しますか？データのコピーをいくつ作成しますか？それらのコピー間の不一致にどのように対処しますか？地理的に比較的近いデータセンターにユーザーのデータをどのように保管しますか？

これらの目標はしばしば相反します。多くのtwitterユーザーは世界中の人々をフォローしています。twitterのデータベースは、ツイートを読んだり、ツイートを書いたりするために地理的に最適化すべきですか？

そのような規模に対処するとき、ソリューションの発明、冗長性の追加、およびNoSQLデータベースに非常に似た制限の追加を開始します。すべてのデータを1つのボックスに収めることができる場合、制限を受けるだけで、メリットは必要ありません。

NoSQLデータベースは、「No SQL」とはほとんど関係がありません。

常に一貫性があり、複雑なトランザクションをサポートし、耐久性があるデータベースを大規模にできないことを認めています。

通常のリレーショナルデータベースでは、すべてのインデックスはトランザクションのスコープ内で自動的に更新されるため、どのクエリにも使用できます。

NoSQLデータベースでは、プログラマーは多くのインデックスを維持する責任があり、インデックスは常に古くなると想定されています。

例えば：

• 税番号による人のインデックスには、税の登録プロセスを完了しない人が含まれる場合があります。
• したがって、インデックスを使用するコードは、税の不完全な登録に対処できる必要があります
• 別のオプションは、税務に登録されている人がインデックスに登録されていない場合があります。（したがって、設計は一貫したデータを持たないことに対処し、データが一貫しない方法を決定する必要があります。）

実際の例として、Amazonは、106台のコンピューターが正しいロックが解除されたことを確認するのを待つことで、Webページの表示を遅らせるよりも、本の古い説明を表示したいです。

したがって.....

単一の通常のリレーショナルデータベースがすべてのデータを保持し、各トランザクションを迅速に処理してロックがシステムの有用な作業を妨げることがない場合、リレーショナルデータベースが最適なオプションです。

ただし、複数のリレーショナルデータベースを使用すること、またはロックエラーを回避するためにトランザクションを分割することを考え始めるとすぐに、「NoSQL」データベースを使用するときに発生するある種の問題に対処する必要があります。

「NoSQL」データベースはこれらの問題を隠さないため、システムをスケールアップするときに最適なオプションになる可能性があります。 ただし、Stackoverflowはすべてのデータを格納するためにリレーショナルデータベースを使用し、キャッシングレイヤーでのNoSQLの使用が制限されていることを忘れないでください。

リレーショナルデータベースは、データ行の任意の値を効果的に検索するように最適化されています。

行の「すべて」の値を検索する機能と、行の「すべて」の値を混同しないでください。これを行う最も効果的な方法には、1つ以上のインデックスが必要です。インデックスにすべてのフィールドを含めることもできますが、インデックスの変更（挿入、更新、削除）を必要とする変更を加えることができなくなるだけです。あなた（またはDBA）は、データ、使用法、ボトルネックなどを理解する必要があります。

すでに多くの答えがありますが、要約を追加したかっただけです。

明らかにNoSQLの概念は、ディスク上、メモリ内のデータを整理し、クエリ言語を介してデータを公開するさまざまなアプローチをカバーしています（一部はSQLのようなものです！）。私の見解では、この多様なシステムの強みが発揮されるため、仕事に最適なツールを選択できます。ただし、数十の異なるシステムを管理したくない場合でも、数十の異なるソリューションで数十の異なるニーズに対応できることを願っています。

リレーショナルデータベースは非常に優れた実績のあるテクノロジですが、データベースと同様に、各プロジェクトのニーズに基づいてプログラミング言語を選択することもできます（ただし、チームの経験も考慮します）。

私はcouchdbを2年間使用しています。主にコンテンツの管理と構成に使用されます。

階層関係の場合、視覚化できると管理がはるかに簡単になります。ほとんどが読み取り専用のデータの場合、多くの場合、UPDATEステートメントを記述するよりもJSONを編集する方が簡単です。実際、プログラマーがJSONを編集する必要はありません。また、SQLは行と列を提供しますが、これらは何らかのオブジェクト構造にマッピングする必要があります。

また、複雑なクエリで10〜20個のテーブルを結合しないため、パフォーマンスが向上します。Couchdbビューは、基になるjavascriptがクエリ時に実行されないため、非常に高速です。

ほとんどのプログラマーはJavascriptを理解しており、ほとんどのプログラマーは時折SQLと格闘しています。

Couchdbでは、ビューはJSONドキュメントの抽象と考えることができます。ビューデータの構造はユーザー次第です（元の階層に制約されません）。

高度なトランザクションデータにはCouchdbを使用しませんが、パーツ爆発タイプの構造を持つ半静的データの場合、SQLよりも作業がはるかに簡単です。

ただし、適用できる明確な「正規化」はなく（データの重複を避けることは価値のある目標ですが）、基本的に楽観的なロックに似た「楽観的な」更新戦略があります。