43

MongoDB、CouchDB、SimpleDB などのスキーマレス (多くの場合、分散型) データベース システムについての話をよく耳にします。

それらが何らかの目的で価値があることは理解できますが、ほとんどのアプリケーションでは、特定のタイプの特定の数のフィールドを持つオブジェクトを永続化しようとしており、リレーショナル モデルで自動的に考えます。私は常に、一意の整数 ID、null/not null フィールド、SQL データ型、選択クエリを使用してセットを検索する行の観点から考えています。

私はこれらの新しいシステムの分散型の性質と簡単な JSON/RESTful インターフェイスに惹かれていますが、緩く型付けされたキー/値ハッシュが開発にどのように役立つかはわかりません。型が緩く、スキーマのないシステムが、クリーンなデータ セットを維持するのに適しているのはなぜでしょうか? たとえば、日付がない可能性があるときに、x と y の間の日付を持つすべてのアイテムを見つけるにはどうすればよいですか? 結合の概念はありますか?

多くのシステムには独自の違いと長所があることは理解していますが、パラダイムの違いについて疑問に思っています。これは自由回答形式の質問だと思いますが、おそらくコミュニティの回答と、これらのシステムの利点を個人的に見たコミュニティの方法は、私や他の人がいつこれらの (確かにもっとヒップな) システムを使用したいのかを理解するのに役立つでしょう。従来の RDBMS。

4

6 に答える 6

33

一般的な理由を 1 つか 2 つだけ挙げます (エッセイの回答を書いている人もいると思います)。

  1. 高度に分散されたシステムでは、任意のデータ セットが複数のサーバーに分散している可能性があります。その場合、DB エンジンが保証できる関係制約は大幅に減少します。参照整合性の一部は、アプリケーション コードで処理する必要があります。そうすることで、いくつかの問題点がすぐに見つかります。

    • ロジックが複数のレイヤー (アプリとデータベース) に分散している
    • ロジックが複数の言語に分散されている (SQL と選択したアプリ言語)

    その結果、ロジックのカプセル化が少なくなり、移植性が低くなり、変更のコストが大幅に高くなります。多くの開発者は、アプリケーション コードでより多くのロジックを記述し、データベースでより少ないロジックを記述していることに気付きます。極端にいえば、データベース スキーマは無意味になります。

  2. 特にダウンタイムが許されないシステムでは、スキーマ管理は困難です。スキーマの複雑さを軽減すると、その困難が軽減されます。

  3. ACID は、分散システム ( BASE、CAPなど)ではうまく機能しません。SQL 言語 (およびある程度のリレーショナル モデル全体) は、トランザクション ACID の世界向けに最適化されています。そのため、SQL 言語の機能とベスト プラクティスには役に立たないものもあれば、実際に有害なものもあります。一部の開発者は、「規則に反する」ことに不快感を覚え、SQL を完全に削除して、要件に合わせてゼロから設計された言語を使用することを好みます。

  4. コスト: ほとんどの RDBMS システムは無料ではありません。スケーリングのリーダー (Oracle、Sybase、SQL Server) はすべて商用製品です。大規模な (「Web スケール」) システムを扱う場合、データベースのライセンス コストは、ハードウェアのコストと同等またはそれ以上になる可能性があります。OSS 製品の上にカスタム ソリューションを構築するために、通常の構築/購入の考慮事項を大幅に変更するには、コストが十分に高くなります (すべての重要な NOSQL 製品は OSS です)。

于 2010-10-04T14:55:25.013 に答える
7

主な関心事は、データをどうする必要があるかということです。膨大なデータ セットがあり、従来の RDBMS がボトルネックになっていることがわかっている場合は、スキーマレスまたはNOSQLソリューションを試すことができます。

私が認識しているNOSQLソリューションの使用環境のほとんどは、何らかの形または方法で RDBMS ソリューションも使用しています。RDBMS ベースのソリューションは、データの整合性が非常に重要であり、ACID トランザクションが必要な標準です。ただし、システムが高度なトランザクション ベースではなく、すぐにスケール アップまたはスケール アウトする必要がある場合は、NOSQLソリューションが望ましい場合があります。

于 2010-10-13T20:38:42.597 に答える
4

私は MongoDB で遊んだことしかありませんが、私が本当に興味を持ったことの 1 つは、ドキュメントをネストする方法でした。MongoDB では、ドキュメントは基本的にレコードのようなものです。従来、RDBMS では、「Person」レコードをプルして、関連する住所、雇用者情報などを取得する必要がある場合、複数のテーブルに移動し、それらを結合し、複数のデータベースを作成する必要があったため、これは非常に便利です。呼び出します。MongoDB のような NoSQL ソリューションでは、関連するレコード (ドキュメント) をネストするだけでよく、外部キー、結合、複数のデータベース呼び出しをいじる必要はありません。その 1 つのレコードに関連付けられているすべてがプルされます。

これは、オブジェクトを扱うときに特に便利です。多くの場合、オブジェクトを一連のネストされたドキュメントとして保存できます。

于 2010-10-04T14:45:53.347 に答える
3

NoSQL データベースはスキーマレスではありません。スキーマはデータに埋め込まれています。それらは適切に半構造化と呼ばれます。ただし、一部の KV データ ストアでは、スキーマがコードに埋め込まれている場合もあります。半構造化アプローチの利点は 2 つあります。列が行の一部であるという柔軟性 (ある行には 5 つの列があり、別の行には 5 つの異なる列がある可能性があります)、および列の特性の柔軟性 (可変長など) です。

于 2014-01-15T02:41:58.193 に答える
-8

通常、魅力はスネーク オイルの魅力です。それらを好んでいるほとんどの人は、関係定理についての手がかりがなく、専門家を吐き出すレベルで SQL を話します。ACID条件が何であるかわかりません。それらは重要です。

彼らが有効な用途を持っていないと言っているわけではありません.... ほとんどの魅力は、知っておくべきことを知らず、ばかげた結論を出す人々です。繰り返しますが、すべての人がそうであるわけではありませんが、それらを好む開発者のほとんどは、データベース システムが実際に何を担当しているのかをよく理解していません。

于 2010-10-04T14:48:38.953 に答える