3

私は、スキーマのないデータの保存/取得を含む一連の特定の要件を解決する手段として、多数の NoSQL 実装 (現時点では RavenDB と MongoDB) を評価しています。NoSQL が私が検討すべき方向であるかどうか、または他の (より単純な可能性がある) オプションがあるかどうかについて、フィードバックを得たいと考えています。

基本的に、(とりわけ) いくつかの関連するエンティティで構成される基本的なドメイン モデルを定義するソフトウェア製品があり、それぞれがいくつかの属性 (キー/値) を持っています。お客様にリリースするときに、お客様と協力して属性と値を設定します。これは基本的にシステムの構成です。これは非常に簡単で、設計が事前にわかっているため、これを実現して実行するために動的なものは必要ありません (RDBMS を使用します)。属性は前もって知られていませんが、システムのこの部分はほとんど属性モデルを中心に展開しているため、これも問題ではありません。

問題は、さまざまな顧客にとって、コードをコンパイルしてリリースしたとき (および、顧客）。基本的には、格納できる属性マップからデータを生成し (構造は前もってわかりません)、格納されたデータを後で予測できない方法でクエリする必要があります。現在考えていることは、処理中にヒットするフックを作成し、データを作成して保存するライブラリを (おそらく MEF 経由で) プラグインできるようにし、後で必要に応じてクエリを実行できるようにすることです (レポート用ではありません)。通常、追加のデータ/属性を作成します)。

(フックとプラグイン ライブラリの作成は別の問題であり、この質問の一部になることを意図していないことに注意してください。)

一般的なシナリオは、「過去 10 日間に xxx が発生した回数を知りたい」です。そこで、xxx が発生したことを認識するプラグインを作成し、それを日付/時刻とともにデータ ストアに書き込みます。次に、クエリを実行する別のプラグイン (おそらく同じ DLL 内) を作成し、「CountOfxxxInLast10Days」というモデルに属性を追加します。もう 1 つのシナリオは、構成可能なルックアップを作成することです。そのため、起動時に実行して、ある属性値を別の属性値に変換できるルックアップ データのテーブルを作成/更新するプラグイン、または (より可能性が高い) ルックアップ値に変換する値の範囲を作成するプラグインを用意する場合があります。そのため、変換プラグインは、bottom_value、top_value、乗数の列を持つテーブルを追加し、クエリ プラグインは、"

場合によっては、指定した期間が経過すると古いデータが消去されることがあります。上記の最初のシナリオでは、ストア/キャッシュから 10 日より古いデータを削除することが望ましい場合があります。

上記の 2 番目のシナリオのように、データを永続的に保持する必要がある場合もあります。このデータは、永続的なストアに保持されるのではなく、起動時に単純に再作成される可能性があります。

追加要件:

  • オンライン中にデータストア/キャッシュをバックアップおよび復元できます
  • クラッシュの場合、最後のバックアップから置き換え/回復可能
  • データは、マシンの再起動などのイベントに耐えます
  • 実証済み/生産テスト済みのテクノロジー

現時点では、.Net プラットフォームにかなり力を入れているため、どのオプションも確実な .Net クライアント/API を備えている必要があります。

4

1 に答える 1

7

3 つの選択肢があり、それぞれに長所と短所があります。

RDBMS を再利用する

既にエンティティをリレーショナル データベースに格納しています。未定義の属性を追加のテーブルに格納できます。このテーブルには、KeyandValue列とEntityId、属性が属するエンティティを参照する列があります。基本的に、データベースの一部をキー値ストアとして使用します。

利点:

  • すべてのデータは単一のデータベースに保存されます。つまり、次のことを意味します。
    • 単一のクエリでエンティティとそのすべての属性を取得できます。
    • 単一のデータベースと対話するだけでよいため、アプリケーションはそれほど複雑ではありません。
  • リレーショナル データベースのすべての ACID の利点が得られます。

短所:

  • リレーショナル データベースはキー値ストアとして構築されていないため、パフォーマンスの問題が発生する可能性があります。ただし、非常に大量の属性を保存する予定がない限り、パフォーマンスへの影響は最小限に抑えられると思います。

キー値ストアを使用する

RedisやRiak、またはより高度なApache Cassandraなどのキーと値のストアは、キーと値のペアを格納するために最適化されています (当然のことですが...)。エンティティを RDBMS に保持しながら、RDBMS の隣にある属性の格納専用のキー値ストアを使用できます。

利点:

  • 特に大量のデータでは、RDBMS よりも優れたパフォーマンスが得られます。
  • ACID プロパティによる制約を受けないため、スケールアウトが容易です。

短所:

  • 保証された ACID プロパティはありませんが、いわゆる結果整合性は保証されます。つまり、保存されたデータはサーバー間で常に整合性があるとは限りません。ただし、スケールアウトする場合にのみ、これに対処する必要があります。また、ほとんどのキー値ストアでは、一貫性に関する厳密さを調整して、この問題を克服することができます。
  • アプリケーションは 2 つの別個のデータベースで実行されるため、アプリケーションの複雑さが増します。

ドキュメント データベースを使用する

ドキュメント データベースを使用して、属性だけを格納できます。しかし、思い切って、エンティティを含むすべてをドキュメント データベースに格納することもできます。

利点:

  • すべてのデータは単一のデータベースに保存されます。つまり、次のことを意味します。
    • 属性を含むエンティティ全体を 1 つのドキュメントに格納する場合と同様に、エンティティとそのすべての属性を 1 回の操作で取得できます。
    • 単一のデータベースと対話するだけでよいため、アプリケーションはそれほど複雑ではありません。
  • ACID プロパティによる制約を受けないため、スケールアウトが容易です。
  • ドキュメント データベースはキーと値だけに制限されていないため、より複雑な属性を格納する必要がある場合でも、すぐに使用できます。

短所:

  • キー値ストアと同様に、ACID 保証はありません。ただし、ほとんどのドキュメント データベースは、一貫性の問題を克服するように調整できます。
  • RDBMS のようにエンティティ間の関係を理解し​​ていない。リレーショナル モデルは正規化されていますが、ドキュメントは非正規化されており、多くの関係を持つことを克服しています。これは、正確なドメイン モデルに応じて、大きな欠点になる場合とそうでない場合があります。

成熟した文書データベース技術

Apache CouchDBには、それを使用するアプリケーションのかなりのリストがあり、スタック オーバーフロー コミュニティから肯定的なフィードバックを受けています。.NET 用のドライバーがいくつかありますが、これらのドライバーがどれほど成熟しているかはわかりません。

MongoDB には、非常に印象的な生産雇用のリストがあります。利用可能な.NET 用の3 つの主要なドライバーがあり、どれも高品質のようです。

RavenDB は .NET プラットフォーム用に設計されているため、.NET の優れたサポートを備えています。ただし、RavenDB で実行されている大規模な運用環境の例を見つけることができませんでした。それでも、それは間違いなく探求する価値があると思います。

実稼働環境で実際に使用した経験があまりないため、バックアップ/復元がどれほど簡単かは正確にはわかりません. しかし、これらの NoSQL システムは RDBMS システムほど厳格ではないという事実を考えると、RDBMS システムよりもダウンタイムなしでバックアップ/復元が容易なはずだと思います。

于 2010-08-13T18:47:48.803 に答える