なぜリレーショナルデータベースの代わりにドキュメントベースのデータベースを使用する必要があるのですか?


187

リレーショナルデータベースを使用する代わりに、CouchDBなどのドキュメントベースのデータベースを使用する必要があるのはなぜですか。リレーショナルデータベースよりもドキュメントベースのデータベースの方が適している典型的な種類のアプリケーションまたはドメインはありますか?


おそらく、ドキュメント指向のデータベースは、いくつかの点で「エンティティ属性値」(EAV)データベースに似ている可能性があります。
ChrisW、2009年

回答:


167

おそらくあなたはすべきではない:-)

2番目に明白な答えは、データがリレーショナルでない場合に使用する必要があるということです。これは通常、データを列のセットとして説明する簡単な方法がないことを示しています。良い例は、オフィスのメールをスキャンするなどして、紙のドキュメントを実際に保存するデータベースです。データはスキャンされたPDFであり、常に存在する(スキャンされた、スキャンされた、ドキュメントのタイプ)いくつかのメタデータと、いつか存在する可能性のある多くのメタデータフィールド(顧客番号、サプライヤー番号、注文番号、保持されるまで、 OCRedフルテキストなど)。通常、2年以内にどのメタデータフィールドを追加するかは事前にわかりません。CouchDBのようなものは、リレーショナルデータベースよりもこの種のデータに適しています。

また、現在ほとんどすべてのプログラミング言語に含まれているHTTPクライアントを除いて、CouchDBのクライアントライブラリが必要ないことも個人的に気に入っています。

おそらく最も明白でない答え:RDBMSを使用して苦痛を感じない場合は、そのままにしてください。仕事を終わらせるために常にRDBMSを回避する必要がある場合、ドキュメント指向のデータベースは一見の価値があります。

より詳細なリストについては、このRichard Jonesの投稿を確認してください。


1
私は2年間でデータベーススキーマを最初の元のスキーマに似たものを見たことがありません。これはかなり誤解を招く名前だと思います...
ᆼᆺᆼ

2
@ int3データを列のセットとして記述できない場合、そのデータに対してインテリジェントなクエリをどのように書くと思いますか?
クレイスミス

46

CouchDB(ウェブサイトから)

  • RESTful JSON APIを介してアクセス可能なドキュメントデータベースサーバー。一般に、リレーショナルデータベースはRESTサービスを介してアクセスされるだけではなく、はるかに複雑なSQL APIを必要とします。多くの場合、これらのAPI(JDBC、ODBCなど)は非常に複雑です。RESTは非常に単純です。

  • アドホックでスキーマフリーで、アドレス空間はフラットです。リレーショナルデータベースには、複雑な固定スキーマがあります。テーブル、列、インデックス、シーケンス、ビューなどを定義します。Couchは、このレベルの複雑で高価で壊れやすい高度な計画を必要としません。

  • 分散型で、双方向の競合検出と管理を備えた堅牢な増分レプリケーションを特徴としています。一部のSQL商用製品はこれを提供しています。SQL APIと固定スキーマのため、これは複雑で難しく、費用がかかります。カウチにとって、それはシンプルで安価に見えます。

  • クエリとインデックスが可能で、JavaScript言語をクエリ言語として使用するテーブル指向のレポートエンジンが特徴です。SQLとリレーショナルデータベースも同様です。ここで新しいことはありません。

そう。CouchDBを選ぶ理由

  • RESTはJDBCまたはODBCよりも単純です。
  • スキーマはスキーマよりも単純です。
  • シンプルで安価な方法で配布されます。

12
私はNoSQLデータベースの大ファンですが、最初の主張(RESTはJDBCより単純です)は非常に疑わしいです。
ᆼᆺᆼ

2
RESTプロトコルは、それが単なるHTTPであるため、私にはかなり単純なように見えます。ステートレス、いくつかのメソッドなどです。JDBCは(内部では)おそらく単純です。単にステートフルであることに基づいて、それが単純であるようには見えません。
S.Lott、2012年

5
@ S.Lott答えは、CouchDbのみを対象とするのではなく、より「一般的」にすべきではありませんか?
パセリエ2012

「壊れやすい高度な計画」対何ですか?私の経験では、代替案は計画外であり、気まぐれに変更されたスパゲッティデータ構造につながります。
Tejay Cardon

26

他のサーバーのデータを愚かに保存して提供するため。

ここ数週間、フィード(delicious、flickr、github、twitter ...)をポーリングしてcouchdbに保存するライフストリームアプリで遊んでいます。couchdbの優れている点は、元のデータをオーバーヘッドなしで元の構造に維持できることです。各ドキュメントに「クラス」フィールドを追加し、ソースサーバーを格納し、各ソースのJavaScriptレンダリングクラスを記述しました。

一般化すると、サーバーが別のサーバーと通信するときは常に、スキーマを制御できないため、スキーマのないストレージが最適です。おまけとして、couchdbはサーバーとクライアントのネイティブプロトコルを使用します-表現にはJSON、トランスポートにはHTTP REST。


ファイルに保存したり、フィードごとのファイルに保存したりしないのはなぜですか?
j_random_hacker

6
couchdbでは、map / reduceを使用して興味深いビューを作成することもできるためです。たとえば、データソースに基づいてビューを作成したり、各ソースの合計を計算したりできます。
daonb

4
これは素晴らしい点です...データを消費していて、受信データスキーマを制御できない場合は、ドキュメントストアを使用してください。
ジョシュアロビンソン

1
これは、NoSQLデータベースの価値について私が聞いた最初の本当に説得力のある議論です
Caleb McNevin

19

迅速なアプリケーション開発が思い浮かびます。

スキーマを常に進化させていると、MySQL / SQLiteでスキーマを維持しなければならないことに常に不満を感じます。私はまだCouchDBを使いすぎていませんが、RADプロセス中にスキーマを進化させることがいかに簡単であるかが好きです。

非リレーショナルデータベースを使用したくない場合は、多対多の関係が多数ある場合です。特に結合関係にメタデータが必要な場合は、これらの種類の関係の周りに優れたMapReduce関数を作成する方法について、まだ頭を悩ませています。確かではありませんが、CouchDBのMap関数がデータベースに対して独自のクエリを呼び出すことができないと思います。無限ループを引き起こす可能性があるためです。


優れた点。ドキュメント(およびその他のスキーマレス)データストアは、迅速な初期開発に最適です。ただし、同じ理由で初期段階のプロトタイピングに適しているため、堅牢な生産アプリケーションには問題があります。
Tejay Cardon

6

各レコードのサイズが均一なフィールドを持つテーブルにデータを格納する必要がない場合は、ドキュメントベースのデータベースを使用します。代わりに、特定の特性を持つドキュメントとして各レコードを保存する必要があります。任意の長さのフィールドをいくつでも、最初に「テーブルを変更」する必要なく、いつでも動的にドキュメントに追加できます。ドキュメントベースのフィールドには、複数のデータを含めることもできます。


1

smdelfinについて詳しく説明すると、柔軟性です。データは任意の構造(非構造化およびすべて)で保存でき、すべてのドキュメントは完全に異なる可能性があります。「ビュー」インデックスを使用すると、特定のドキュメントをフィルターで除外し、データベースのサブセットが必要なときにそのビューのみをクエリできるため、CouchDBは特に便利です。

JSON形式でデータを保存するドキュメントデータベースの最大の勝利点:これはJavaScriptのネイティブ形式です。したがって、JavaScript WebアプリケーションはCouchDBと非常にうまく連携します。私は最近、CouchDBを利用するWebアプリを作成しました。これは高速でありながら、常に変化するデータ構造を処理できます。


0

ドキュメントベースのデータベースは、データを入力する前にスキーマを事前に定義する必要がないため、リレーショナルデータベースよりも大きな利点があります。

また、データがリレーショナルでなく、テーブルに格納できないが、一連の画像、たとえば新聞記事である場合は、ドキュメントデータベースを使用する必要があります。

もう1つの利点は、Web開発でのドキュメントベースのデータベースの使いやすさです。より詳細なNoSQLデータベースモデルの比較については、次のソースを確認してください。 https

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.