文書指向データベースは、オブジェクトを永続化するためにリレーショナルデータベースよりも適していますか?

database document-oriented-db orm
文書指向データベースは、オブジェクトを永続化するためにリレーショナルデータベースよりも適していますか?

データベースの使用に関しては、過去10年間は​​ORMの時代であり、何百人もがオブジェクトグラフを単純な昔ながらのRMDBSで永続化しようと競い合いました。 現在、ドキュメント指向データベースの時代の到来を目の当たりにしているようです。 http://couchdb.apache.org/ [これら] databasesは、スキーマフリーのドキュメント用に高度に最適化されていますが、スケールアウトする能力も非常に魅力的です。クラスターを並行してクエリします。

ドキュメント指向のデータベースは、オブジェクト指向の設計でデータモデルを永続化するために、RDBMSを上回るいくつかの利点も備えています。 テーブルはスキーマフリーであるため、継承階層の異なるクラスに属するオブジェクトを並べて保存できます。 また、ドメインモデルの変更に伴い、コードが古いバージョンのドメインクラスからオブジェクトを取り戻すことができる限り、変更のたびにデータベース全体を移行する必要がなくなります。

一方、ドキュメント指向データベースのパフォーマンス上の利点は、より深いドキュメントを保存するときに主に生じるようです。 オブジェクト指向の用語で、他のクラス、たとえばブログ投稿とそのコメントで構成されるクラス。 ブログのように、これのほとんどの例では、読み取りアクセスの増加は、新しいコメントが追加されるたびにブログの投稿「ドキュメント」全体を書かなければならないというペナルティによって相殺されるように見えます。追加されました。

データの読み取りと書き込みの方法に最適化された深いグラフでオブジェクトを整理することに細心の注意を払うと、ドキュメント指向データベースがオブジェクト指向システムに大きなメリットをもたらすように思えますが、これはユースケースを知ることを意味しますフロント。 現実の世界では、プロファイリングできる実際の実装が実際に行われるまでわからないことがよくあります。

リレーショナルvs. 文書指向データベースはスイングとラウンドアバウトの1つですか? 特にドキュメント指向のデータベースに重要なアプリケーションを構築した人がいる場合、私は人々の意見やアドバイスに興味があります。

  3  0


ベストアンサー

まあ、それはあなたのデータがどのように構造化されているか、そしてデータアクセスパターンに依存します。

ドキュメントデータベースはドキュメントを保存および取得し、基本的なアトミックストアユニットはドキュメントです。 先ほど述べたように、スマートドキュメントモデルを作成するには、データアクセスパターン/ユースケースについて考える必要があります。 ドメインモデルをいくつかのドキュメントに分割およびパーティション分割できる場合、ドキュメントデータベースは魅力のように機能します。 たとえば、ブログソフトウェア、CMS、またはwikiソフトウェアの場合、document-dbは非常にうまく機能します。 データをドキュメントに圧縮する良い方法を見つけることができれば、問題はありません。 ただし、http://ayende.com/Blog/archive/2010/04/20/that-no-sql-thing-the-relational-modeling-anti-pattern-in.aspxを試さないでください。文書データベースへのモデル化]。 データアクセスパターンがリレーションで多くの「ナビゲーション」を使用するとすぐに、グラフまたはオブジェクトデータベースがより自然な選択になります。

もう1つは、読み取り/書き込みパフォーマンスのトレードオフについてです。 たとえば、ブログソフトウェア。 過渡的なRDBMSデータモデルでは、データは正規化されます。 これは、異なるテーブルから読み取り、結合などの関係を計算してブログ投稿を読むため、データの読み取りに費用がかかることを意味します。 引き換えに、タグの変更は安価です。 対照的に、ドキュメントデータベースでは、ブログ投稿を読むのは安価です。なぜなら、投稿ドキュメントを読み込むだけだからです。 ただし、ドキュメント全体を保存する必要があるため、更新はおそらくより高価です。 さらに悪いことに、多くのドキュメントを調べて何かを変更します(タグシナリオの名前を変更します)。 ほとんどのシステムでは、読むことは書くことよりもはるかに重要です。 したがって、実際には再正規化されたデータストアを使用するのが理にかなっています。

大規模なデータベースでは、スキーマフリー設計には利点があると思います。 RDBMSでは、スキーマをアップグレードする必要がありますが、これは非常に苦痛なプロセスです。 特に、既存のデータを新しいスキーマに変換します。 スキーマフリーのデータベースでは、アプリケーションはそれに対処する必要があり、これにより柔軟性が高まります。 たとえば、古いドキュメントにアクセスしているときに、その場でスキーマをアップグレードできます。 このようにして、アプリケーションがその場で古いバージョンを処理しながら、巨大なデータベースを稼働させ続けることができます。

5


タイトルとURLをコピーしました