30

私は、NoSql ムーブメントの台頭とそれに伴う mongodb、ravendb などのドキュメント データベースの人気の高まりを見てきました。好きなところは結構ありますが、何か重要なことを理解していないように感じます。

店舗アプリケーションを実装していて、データベースに商品を保存したいとしましょう。商品はすべて、単一の一意のカテゴリを持っています。リレーショナル データベースでは、これは製品テーブルとカテゴリ テーブルの 2 つのテーブルを持つことで実現されます。製品テーブルには、正しいカテゴリ エントリを保持するカテゴリ テーブルの行を参照するフィールド (おそらく「category_id」と呼ばれる) があります。これには、データの非反復など、いくつかの利点があります。

また、たとえば、カテゴリ名のつづりを間違えた場合、値が存在する唯一の場所であるため、カテゴリ テーブルを更新して修正することもできます。

ただし、文書データベースでは、これは機能しません。完全に非正規化します。つまり、「製品」ドキュメントでは、実際のカテゴリ文字列を保持する値が実際にあり、データの繰り返しが多くなり、エラーを修正するのがはるかに難しくなります。さらに考えてみると、「このカテゴリの商品をすべて教えてください」などのクエリを実行すると、整合性のない結果になる可能性があるということでもありませんか。

もちろん、これを回避する方法は、ドキュメント データベースの「category_id」全体を再実装することですが、その点に到達すると、リレーショナル データベースを再実装するのではなく、リレーショナル データベースをそのまま使用する必要があることに気付きます。

これにより、文書データベースに関するいくつかの重要なポイントが欠けていると思われ、この間違った道にたどり着きます。それで、スタックオーバーフローに入れたかったのですが、何が欠けていますか?

4

4 に答える 4

18

完全に非正規化します。つまり、「製品」ドキュメントでは、実際のカテゴリ文字列を保持する値が実際にあり、多くのデータの繰り返しが発生します [...]

確かに、非正規化とは、追加のデータを格納することを意味します。また、コレクション (SQL のテーブル) が少なくなるため、データ間の関係が少なくなります。各ドキュメントには、複数の SQL テーブルから得られる情報を含めることができます。

現在、データベースが複数のサーバーに分散されている場合は、複数のサーバーではなく単一のサーバーにクエリを実行する方が効率的です。ドキュメント データベースの構造が非正規化されているため、単一のサーバーにクエリを実行するだけで、必要なすべてのデータを取得できる可能性が高くなります。SQL データベースでは、関連するデータが複数のサーバーに分散され、クエリが非常に非効率になる可能性があります。

[...] そして、エラーは修正するのがはるかに困難です。

また、そうです。ほとんどの NoSQL ソリューションは、SQL データベースに共通する参照整合性などを保証しません。その結果、アプリケーションはデータ間の関係を維持する責任があります。ただし、ドキュメント データベース内のリレーションの量は非常に少ないため、思ったほど難しくはありません。

ドキュメント データベースの利点の 1 つは、スキーマがないことです。ドキュメントの内容はいつでも完全に自由に定義できます。SQL データベースの場合のように、定義済みの一連のテーブルと列に縛られることはありません。

実際の例

SQL データベースの上に CMS を構築している場合は、CMS コンテンツ タイプごとに個別のテーブルを作成するか、すべてのタイプのコンテンツを格納する一般的な列を含む 1 つのテーブルを作成します。別々のテーブルを使用すると、多くのテーブルができます。各コンテンツ タイプのタグやコメントなどに必要なすべての結合テーブルについて考えてみてください。単一の汎用テーブルを使用すると、アプリケーションはすべてのデータを正しく管理する必要があります。また、データベース内の生データは更新が難しく、CMS アプリケーションの外ではまったく意味がありません。

ドキュメント データベースを使用すると、各ドキュメント内で厳密に定義された構造を維持しながら、各タイプの CMS コンテンツを 1 つのコレクションに格納できます。また、すべてのタグとコメントをドキュメント内に保存して、データの取得を非常に効率的にすることもできます。この効率性と柔軟性には代償が伴います。アプリケーションは、データの整合性を管理する責任がより大きくなります。一方、ドキュメント データベースのスケールアウトのコストは、SQL データベースに比べてはるかに安価です。

アドバイス

ご覧のとおり、SQL ソリューションと NoSQL ソリューションの両方に長所と短所があります。Davidがすでに指摘したように、各タイプには用途があります。要件を分析し、SQL ソリューション用とドキュメント データベース用の 2 つのデータ モデルを作成することをお勧めします。次に、スケーラビリティを考慮して、最適なソリューションを選択してください。

于 2010-08-10T07:47:32.200 に答える
9

（少なくとも投稿の内容に基づいて）あなたが見落としている一番のことは、ドキュメントデータベースがリレーショナルデータベースに取って代わることを意図していないということです。実際、あなたが提供する例は、リレーショナルデータベースで非常にうまく機能します。おそらくそこにとどまるはずです。ドキュメントデータベースは、別の方法でタスクを実行するための単なる別のツールであり、すべてのタスクに適しているわけではありません。

ドキュメントデータベースは、（逆に見て）リレーショナルデータベースがすべての問題を解決するための最良の方法ではないという問題に対処するために作成されました。どちらのデザインにも用途があり、どちらも本質的に他のデザインよりも優れています。

MongoDB Webサイトのユースケースをご覧ください：http ：//www.mongodb.org/display/DOCS/Use+Cases

于 2010-08-09T13:21:41.667 に答える
4

ドキュメントデータベースは、開始時に自由な感覚を与えます。テーブルの作成やテーブルの変更スクリプトを作成する必要がなくなりました。マスターの「レコード」に詳細を埋め込むだけです。

しかし、しばらくすると、別の方法でロックされていることに気付きます。データを保存したときに必要とは思わなかった方法でデータを結合または集約することは簡単ではなくなります。データマイニング/ビジネスインテリジェンス（未知のものの検索）はより困難になります。

つまり、アプリがデータをデータベースに正しい方法で保存したかどうかを確認することも困難です。

たとえば、それぞれ約10000の「レコード」を持つ2つのコレクションがあります。ここで、「テーブル」Bに存在しないIDが「テーブル」Aに存在するかどうかを知りたいと思います。

SQLでは些細なことですが、MongoDBでははるかに困難です。

しかし、私はMongoDBが好きです!!

于 2010-08-12T21:32:27.070 に答える
0

たとえば、 OrientDBは、スキーマレス、スキーマフル、または混合モードをサポートします。コンテキストによっては、制約や検証などが必要ですが、スキーマに触れることなくフィールドを追加できる柔軟性が必要になります。これはスキーマ混合モードです。

例：

{'@rid'：10：3​​、'@class'：'Customer'、'@ver'：3、'name'：'Jay'、'surname'：'Miner'、'invented'：['Amiga' ]}

この例では、フィールド「name」と「surname」は必須です（スキーマで定義することにより）が、フィールド「invented」はこのドキュメントに対してのみ作成されています。すべてのアプリはそれについて知る必要はありませんが、それに対してクエリを実行できます。

発明された顧客からの選択はNULLではありません

「invented」フィールドのドキュメントのみが返されます。

于 2010-08-12T15:59:55.143 に答える