3

SQL Server リレーショナル DB に基づく Web ショップ ソリューションがある場合、NoSQL ストレージに移行する理由は何ですか? リレーションに大きく依存するデータストアを NoSQL に移行することは理にかなっていますか? ゼロから始める場合、Web ショップ プロジェクトのリレーショナル ソリューションではなく NoSQL ソリューションを選択しますか?しばらくすると、記事、分類、税率、価格表などのテーブルの束と、それらの間の関係の大きさになります。 ?

.NET (4.0) での MongoDB のサポート、または MongoDB の .NET 4.0 のサポートはどのようなものですか? MongoDB 用の EF ウィザード、L2SQL ウィザードなどに似た豊富なコード生成ツールを当てにできますか?

これまで読んできたように、NoSQL は主にドキュメント ストレージ、より単純なオブジェクト モデルに適しています。

この質問に対するあなたの回答は、適切なインフラストラクチャ設計の決定を下すのに役立ちます。

更新: ASP.NET MVC を中心にソリューションを開発していて、Model クラスに大きく依存している場合、DB4o を選択してオブジェクトをデータストアとの間で単純にシリアル化および逆シリアル化するのが最も簡単な方法でしょうか?

4

2 に答える 2

8

かなり自由回答形式の質問です。

既存のソフトウェアの NoSQL データストアへの移行

多くの場合、既存のリレーショナル テクノロジには多くの経験と知識があります。アプリケーションが正常に動作しているときは、おそらく努力する価値はありません。ただし、現在のソリューションで解決できない問題がある場合は、オプションです。

リレーションに大きく依存するデータストアを NoSQL に移行することは理にかなっていますか?

3 つのテクノロジ (Document-DB、RDBMS、Object Database) は互いに大きく異なることを考慮する必要があります。

  • リレーショナルの世界では、データを正規化し、実行時に結合します。データサイズが大きくない限り、これは問題なく機能します。多くの場合、ここで問題が発生します。正規化されたデータが多数ある場合、多くの結合を行う必要があり、パフォーマンスが大幅に低下します。もちろん、オブジェクトとテーブルの間のマッピングは非常に難しい場合があります。
  • オブジェクト データベースでは、各オブジェクトは個別に保存され、「関係」はポインターの形式で保存されます。したがって、オブジェクト A がオブジェクト B への参照を持っている場合、オブジェクト データベースはこの参照を格納します。したがって、「関係」を取得するために結合操作は必要ありません。したがって、「関係」は安価です。結論として、オブジェクト データベースはリレーションの処理に非常に優れています。
  • MongoDB のようなドキュメント データベースでは、完全なオブジェクト グラフがドキュメントとして保存されます。ドキュメント データベースは、ドキュメント レベルで動作します。したがって、ここには本当の「関係」はありません。通常、ドキュメントを保存/ロードするだけです。そのため、ほとんどの操作が 1 つのドキュメントに対してのみ機能するようにシナリオをモデル化できれば、非常に効率的で簡単になります。

これは、MongoDB (ドキュメント データベース) と db4o (オブジェクト データベース) の設計の違いを比較する優れたブログ投稿です。

最終的に、モデルはデータベースに適合するはずです。たとえば、リレーション データベースのモデルを使用してドキュメント データベースに 1 対 1 で格納しようとしないでください。object-database のモデリングに関する Ayende のブログも参照してください。

.NET (4.0) での MongoDB のサポート、または MongoDB の .NET 4.0 のサポートはどのようなものですか?

Gates VP は、MongoDB について既にこれに回答しています。db4o の .NET 4.0 バージョンは開発中です。一方、3.5 バージョンも 4.0 フレームワークで正常に動作します。

MongoDB 用の EF ウィザード、L2SQL ウィザードなどに似た豊富なコード生成ツールを当てにできますか?

MongoDB と db4o の両方で、コードを生成する必要はありません。あなたのクラスはスキーマです。オブジェクトを保存するだけで、あとはデータベースが処理します。Gates VPの回答も参照してください

これまで読んできたように、NoSQL は主にドキュメント ストレージ、より単純なオブジェクト モデルに適しています。

まあ、範囲はかなり広いです。非常に単純なキー値ストアから、より高度なドキュメント データベース、列指向データベース、グラフ データベース、オブジェクト データベースまで。

もちろん、ドキュメントに似たデータ (ブログ ソフトウェアなど) を保存している場合、ドキュメント データベースは優れた機能を発揮します。一方、グラフ データベースとオブジェクト データベースは、非常に複雑なデータ構造の処理に適しています。

于 2010-05-26T20:02:20.950 に答える
3

わかりました、それはたくさんの質問です。私が実際に対処できるものを見てみましょう.

既存のリレーショナル データストアを移行することは理にかなっていますか?

本当に大きなパフォーマンスの問題がない限り、そうではありません。「Web スケール」のパフォーマンスの問題は通常、非正規化によって解決されます。MongoDB は本質的に非正規化されたデータベースです。

ゼロから始める場合、ウェブショップ プロジェクトにリレーショナル ソリューションではなく NoSQL ソリューションを選択しますか...

はい。MongoDB は、典型的な Web ベースのプロジェクトに非常に自然に適合します。ただし、SQL の経験が豊富な場合は、レポートが少しぎこちなく感じるかもしれません。

.NET 4.0 のサポート? MongoDB 用の EF ウィザード、L2SQL ウィザードなどに似た豊富なコード生成ツールを当てにできますか?

Mongo には、.NET で使用できるドライバーがあります。

Mongo 用の L2SQL または EF ウィザードはありませんが、存在するべきではありません。正直なところ、おそらく最も見逃してしまうのは、DB を分析するための Enterprise Manager です。

MongoDB では、EF ウィザードは実際には必要ありません。EF は、DB とオブジェクト間の「インピーダンスの不一致」に対する MS のソリューションです。MongoDB には「インピーダンスの不一致」はありません。オブジェクトを DB に詰め込むだけです。同じことが L2SQL にも当てはまります。人々はいくつかのLinqサポートを構築しました（簡単なグーグル）が、結合などは機能しません.b / c Mongoは結合を行いません.

「データ オブジェクト」の観点からは、Mongo に必要なのは非常に軽量なフレームワークだけです。正直なところ、プロパティを DB に詰め込むのと同じくらい簡単です。「列を追加」したい場合は、プロパティをオブジェクトに追加するだけで、DB への保存が開始されます。そのため、L2SQL などは本当に不要になり始めています。

誤解しないでください。別のクエリ パラダイムの余地がありますが、その点で、あなたは新しい領域にいます。(すべてのキー値およびドキュメント指向のストアに対応します)。

于 2010-05-26T19:31:18.093 に答える