文書指向のデータベースは、リレーショナルデータベースを置き換えることを意図していますか？

Question

最近、私は少し一緒に働いています mongodb そして、私はそれが本当に好きだと言わざるを得ません。ただし、それはまったく異なるタイプのデータベースであり、その後使用されます。特定の種類のデータに対しては間違いなく優れていることに気付きましたが、正規化されたデータベースでは最良の選択ではないかもしれません。

しかし、私には、あなたが持っているかもしれないほぼすべての関係データベースの代わりに完全に取っておくことができ、ほとんどの場合、パフォーマンスが向上しているように見えます。これにより、いくつかの質問をするようになります。

1. ドキュメント指向のデータベースは、次世代のデータベースになり、基本的にリレーショナルデータベースを完全に置き換えるように開発されていますか？
2. ドキュメント指向のデータベースとリレーショナルデータベースの両方を、どちらか一方に適したさまざまなデータに対して並んでプロジェクトを使用する方が良いでしょうか？
3. ドキュメント指向のデータベースがリレーショナルデータベースを置き換えることを意図していない場合、リレーショナルデータベース（またはその逆）で絶対に良くなるデータベース構造の例がありますか？

Answer 1

ドキュメント指向のデータベースは、次世代のデータベースになり、基本的にリレーショナルデータベースを完全に置き換えるように開発されていますか？

いいえ。ドキュメント指向のデータベース（MongoDBなど）は、最新のWebサイト（個々のアイテムまたは小さなアイテムセットの速い検索）で通常見られるタスクのタイプに非常に優れています。

しかし、彼らはリレーショナルシステムといくつかの大きなトレードオフをします。酸コンプライアンスのようなものがなければ、特定のRDBMを交換することはできません。また、MongoDBのようなシステムを見ると、酸のコンプライアンスの欠如が非常に速い大きな理由です。

ドキュメント指向のデータベースとリレーショナルデータベースの両方を、どちらか一方に適したさまざまなデータに対して並んでプロジェクトを使用する方が良いでしょうか？

はい。実際、私は両方を使用する非常に大きな制作Webサイトを実行しています。システムはMySQLで開始されましたが、その一部をMongodbに移行しました。B/Cは、キー価値ストアが必要であり、MySQLは150mのレコードで1つのアイテムを見つけるのはあまり得意ではありません。

ドキュメント指向のデータベースがリレーショナルデータベースを置き換えることを意図していない場合、リレーショナルデータベース（またはその逆）で絶対に良くなるデータベース構造の例がありますか？

ドキュメント指向のデータベース 「キーバリュー」とシンプルで線形の「親子」関係に簡単に含まれる優れた保存データです。ここでの簡単な例は、ブログやウィキなどです。

でも、 リレーショナルデータベース 「セットベース」になる傾向があるレポートのようなものには、まだ強い足があります。

正直なところ、ほとんどのデータがドキュメント指向のデータベースによって「処理」される世界を見ることができますが、Map-Reduceのジョブによって更新されるリレーショナルデータベースでレポートが行われます。

Answer 2

これは本当に目的のためのフィットネスの問題です。

いくつかのテーブルを一緒に結合して、フィルタリングされた結果のセットを返すことができる場合は、リレーショナルデータベースでのみそれを行うことができます。心を曲げるパフォーマンスが必要で、信じられないほどのデータが必要な場合、それは列と家庭またはドキュメント指向のデータベースが独自に登場するときです。

これは古典的なトレードオフです。リレーショナルデータベースは、パフォーマンスコストが伴う一連の機能を提供します。参加、インデックス、スキャン、または機能の全体のリストをまったく実行できなかった場合、すべてのデータに対してビューを使用する必要があるため、深刻なデータをクランチするために必要なパフォーマンスと配布が得られます。

また、このトピックについてAyende Rahienのブログをフォローすることをお勧めします。

http://ayende.com/blog/

Answer 3

@Sohneeはスポットです。そのリレーショナルデータベースを追加するかもしれません

• 予期しない組み合わせで情報を取得するのに最適です。たとえそれが、別のデータウェアハウスではなく、時間に敏感な生産システムで広範なレポートが実行されるという悪い考えにつながることがある場合でも。
• スタッフを簡単に見つけることができる成熟した技術であり、あらゆる問題（リレーショナルモデルの制限、およびSQLである不完全な実装を含む）のスタッフや十分にテストされたソリューションを簡単に見つけることができます。

あなたが何をしたいのか、そして何をしてください 資質 あなたにとって重要です。シェルスクリプトですべてのプログラミングに関連するプログラミングを行うことができます。あなたは＿＿したいですか？

Answer 4

私は同じ質問をし続けます。それがここに私を上陸させました。私はMySQLとMongoDBの両方を使用しています（現在はタンデムではありませんが、アイデアです）。私は正直に言って、私は二度とmysqlに触れないことをとてもうれしく思います。確かに「酸」コンプライアンスがありますが、MySQLでテーブルを修復する必要性に遭遇したことがありますか？破損したデータベースを持っていたことがありますか？それは起こります。 MySQLに他に問題がありましたか？ロックの内容やデッドロックはありますか？クラスタリングに問題はありますか？セットアップと構成はどれくらい簡単でしたか？

Mongodb ...あなたはそれをオンにして、それは完了です....それはそれが自動監視です。信じられないほどシンプルで、信じられないほど速いです。だからそれについて考えてください。あなたの時間。

いいえ、彼らは参加していませんが、データ管理のニーズの99％以上を割引すると言うのは完全に誤った声明です。 Mongodbを説明しようとするとき、私はしばしば反対を受けます。それに直面しましょう。人々は新しいことを学びたくないし、彼らが知っていることは彼らが必要とするすべてだと思う。確かに、あなたはあなたの人生の残りの部分をMySQLを使用して逃げて、あなたのウェブサイトを構築することができます。それは機能し、私たちはそれが機能することを知っています。また、失敗することもわかっています。そうでなければ、あなたは質問をすることは決してなく、おそらくそれほど多くのドキュメント指向データベースが表示されないでしょう。はい、スケーリングすることはわかっていますが、それをスケーリングするのは後部の痛みです。

また、写真からトラフィックとスケーリングを排除しましょう。セットアップを取り出します。それでは、使用に焦点を当てましょう。 MySQLを使用する際の経験はどうですか？ MySQLアーキテクチャと効率的なクエリを作成するのはどれくらい良いですか？説明でクエリを調べるのにどれくらいの時間を費やしますか？スキーマ図を作るのにどれくらいの時間に費やしますか？ ...私はその時間を取り戻すと言います。他の場所で過ごした方が良いです。

それが私の2セントです。私は本当にMongodbが大好きで、MySQLを二度と使用しないことを望んでおり、私が構築するWebサイトの種類については、必要ではない可能性があります。私はまだMongodbを介してMySQLを使用したいのかをまだ見つけようとしていますが、できる限りではなく（それに直面して、データを保存し、おめでとうございます、大量のXMLファイルも書くことができますが、それは良い考えではありません） 、しかし、どちらか一方を使用することが利益になる場合。それまでの間、私はMongodbで仕事をしに行き、頭痛が少なくなります。

Answer 5

マルチオブジェクトトランザクションを必要としない限り、MongoDBは、特にWebアプリケーションのコンテキストで、RDMBの好ましい代替品になる可能性があります。スピード、スキーマレス、ドキュメントモデリングはすべてこのドメインに役立ちます。

Answer 6

私の意見では、ドキュメント指向のデータベースは適しています

1. データベース階層（ツリー）モデルを使用してよりよく表現されるデータ。これは、Webサイトデータベースでは一般的ではありません。
2. FacebookやAmazonデータベースなどの膨大なデータを持つデータベース。この場合、リレーショナルモデルの利点を犠牲にする必要があります。

Answer 7

AFAIK、ドキュメントデータベースには参加していません。これは、データ管理のニーズの99％以上のショーストッパーです。

Matthew Flaschenがコメントで指摘しているように、デスクトップでさえ、SQLiteなどのデータベースは、従来のProprietyファイル形式またはXMLを使用していた領域にSQLセマンティクスを導入しています。