データモデルは、いわゆる「NoSQL」データベースのスケーラビリティとパフォーマンスにどの程度影響しますか？

CAP定理（整合性、可用性、パーティション：2つを選択）を持たない限り、いわゆる "NoSQL"データベースについて話すことはできません。MongoDB（Partition、Consistency）とCouchDB（Availability、Partition）の間で言う必要がある場合、最初に考える必要があるのは「正しいデータが必要ですか、それとも常時アクセスする必要がありますか？」です。

これらの新しいデータベースは、パーティション分割されるように作成されました。しかし、私がそうしないとどうなりますか？リレーショナルデータベースではなく、キー/値、列、ドキュメントなどのデータベースを持ち、サーバーインスタンスを1つだけ作成し、決してシャードしないのが非常にクールだと思ったらどうでしょうか。その場合、可用性と一貫性の両方はありませんか？MongoDBは何も複製する必要がないため、利用可能になります。また、CouchDBにはデータのソースが1つしかないため、かなり一貫性があります。

それで、その場合、MongoDBとCouchDBはユースケースの用語にほとんど違いがないことを意味しますか？もちろん、パフォーマンス、API、およびその他は除きますが、基本的に異なる2つの要件セットを持つよりも、PostgreSQLとMySQLを選択することに似ています。

私はここにいますか？複数のインスタンスを作成しないことで、APまたはCPデータベースをACデータベースに変更できますか？それとも私が行方不明になっているものがありますか？

逆に質問してみましょう。リレーショナルデータベースを使用し、MySQLを使用して、それをマスター/スレーブ構成にするとどうなりますか。ACIDトランザクションを使用しません書き込みをすぐにスレーブに同期する必要がある場合、それをCPデータベースにしませんか？そして、事前に定義された間隔で同期するとどうなりますか。クライアントがスレーブから古いデータを読み取っても問題はありません。それがAPデータベースになりませんか？これは、ACIDコンプライアンスを放棄しても、パーティション分割されたデータベースにリレーショナルモデルを使用できるという意味ではないでしょうか。

本質的には、基になるデータモデルよりも、CAP定理で放棄する準備ができているものについてのスケーラビリティですか？列、ドキュメント、キーバリューなど、リレーショナルモデルよりもスケーラビリティを高めるものはありますか？パーティショントレランスのためにゼロから設計されたリレーショナルデータベースを設計できますか？（たぶんそれはすでに存在します）。NoSQLデータベースをACIDに準拠させることはできますか？

申し訳ありませんが、多くの質問がありますが、最近NoSQLデータベースについて多くのことを読みました。それらを使用することの最大の利点は、パーティションCAPだけでなく、データの「形状」により良くフィットすることですACIDコンプライアンスを放棄します。結局のところ、誰もがデータを分割するのに必要なほど多くのデータを持っているわけではありません。データのパーティション分割について考える前に、リレーショナルモデルを使用しないことでパフォーマンス/スケーラビリティの利点がありますか？

NoSQLデータベースを使用すると、データを分割していない場合でもスケーラビリティが向上しますか？スケーラビリティを定義しましょう。データベース/バックエンドシステムが関係しているのでスケーラビリティについて言及している場合、水平スケーリングがデータをシャーディングしている垂直スケーリングと水平スケーリングがある場合、答えは絶対にないため、これは簡単な質問になります。垂直スケーリング（つまり、より良いハードウェアの取得）です。ただし、アプリケーションの柔軟性、データの価値などを指す広い意味でのスケーラビリティについて話している場合...それは、いくつかの答えがある完全に異なる質問です。そして、あなたが述べたように、それはしばしばあなたがデータで何をしているのか、そしてそれがどのように保存されるべきかということになります。ここですべてを序文にしましょう。ほとんどの場合、RDBMSを使用する必要があり、NoSQLはニッチを埋めるはずです。以下は、特定の要件がある場合にNoSQLデータベースがより有益であり、水平スケーリングを無視できる特定のインスタンスの説明です。

たとえば、Googleドライブ、Dropbox、またはボックスに似たクラウドファイルストレージシステムを作成しているが、実際のファイルシステムを使用する代わりに、ファイルシステムを仮想化する方が有益であると判断したとします。データモデルが突然RDBMSで恐ろしく非効率になりそうなツリー構造であるため、問題が発生しました（それがすべてのインデックス付け方法であるという事実にもかかわらず）。というのも、Name、User、Parentの3列のテーブルがあるからです。ユーザーは、ユーザーテーブルへの外部キーであり、親は、nullを許可する自己参照外部キーです（ルートディレクトリに親がないため、nullは許可されます）。それでは、主キーは何ですか？この例では、すべての列にまたがる複合キーです...これは、突然、Parentを最悪の敵にします。

代わりに、それを何らかの形式のドキュメントストアにどのように配置するかを考えますか？データを処理する代わりに、データを操作してツリー構造として保存することで、開発時間を短縮し、メンテナンスコストを削減できます。コストを削減している場合、異なる種類のスケーラビリティが可能になりませんか？さらにこの例では、システムを最初から正しく作成しているため、アプリケーション自体の柔軟性が向上します。現在、MongoDBを使用して単一のサーバーでこれを実行しています。これは、説明したように、MySQLまたはPostgresの違いを見る場合とほとんど変わらない、利用可能な一貫性のあるモデルを提供します。

少なくともMongoDBを使用すると、クエリが成功するために通信する必要があるサーバーの数を定義できるため、すべてのクエリにすべてのサーバーインスタンスと通信するよう指示する場合、一貫性のある利用可能なモデルに変換できます。

したがって、データの保存方法に大きなメリットがあるという点で、あなたにはその権利があると思います。他のモデルにうまく適合するリレーショナルモデルにうまく収まらないものがあります（別の簡単な例として、Amazonは製品の推奨エンジンに何らかの形式のグラフデータベースを使用しています）。

あなたの質問を正しく理解しましたか？

編集：より多くのデータが遅くなりますか？はい。どれくらい遅くなりますか？正直なところ、適切な答えを出すのに十分な経験がありません。キー/値：基本的に、ルックアップキーに関連付けられた大量のデータを含むルックアップテーブル。キーでしか調べることができないため、これは非常に高速になります。列/ファミリー：本質的にはるかに構造化されたキー/値ストア。Columnに基づいてクエリを実行できるので、これも非常に高速です。ドキュメント：集計スタイルのスキーマ。ここでは、同様のデータを一緒に集約する必要があります。この種のデータベースでは、非正規化は問題ありません。多くの書き込みまたは読み取りを行っているかどうかに応じて、複数のシャードに分散して書き込みまたは読み取りを分散するようにデータを整理できます（両方に適したハイブリッドアプローチを作成できますが、一般的にはどちらか一方の最適化を選択する必要があります）グラフ：このグラフの強みは、リレーションシップを非常に迅速に作成および破棄できることです。データ間で変更する必要がある関係があるデータがある場合（何らかの推奨エンジンを考えてください）、これを使用する必要があります。

これらのデータベースにデータを保存する方法は、パフォーマンスに影響します（一部のRDBMSにデータを誤って保存すると、パフォーマンスに影響するという事実に似ています）。したがって、これをより明確にするために、使用するデータベースシステムと、そのデータベースシステムにデータを保存する方法を知る必要があります。