4

私のシナリオは、複雑なクエリを処理する必要があるため、SQL Server のようなリレーショナル データベース ストレージ システムにとどまることを好みます。

そして、一部の計算は時間外に実行し、結果を Redis や従来の NoSQL ソリューションなどに保存する方がよいためです。

それが私が考えたポイントです:そして、NHibernate の二次キャッシュはどうなったのでしょうか? .

私は非常に小さな調査を行い、Redis の第 2 レベルのキャッシュ プロバイダーがあることを発見しましたが、今では「混乱」しています。

つまり、NHibernate の第 2 レベルのキャッシュを使用すると、ほとんどのオブジェクト アクセスは非常に高速になるはずです。これは、データベース ラウンドトリップが発生しないためです。したがって、アクセスされるほとんどのオブジェクトは、メモリ内の Redis ストアから取得されます。

Redis を直接使用するだけでなく、これを検討しているのはなぜですか? ソリューションのドメイン内で実際のアトミック トランザクションが必要だからです。

わかりました、質問ですか？

リレーショナルでスキーマのない世界を最大限に活用するために、NHibernate の二次キャッシュ Redis プロバイダーに依存することは良い考えですか?

あなたのアドバイスは何ですか？

4

1 に答える 1

8

あなたの見解の要約として、2つの異なることがわかります。

  1. NHB の上の 2 番目のレベルのキャッシュとして redis を使用します。SLC はオブジェクトのフィールドを分離して格納し、redis はキー/値ストアであるため、これは完全に理にかなっています。私が覚えているように、SLC にはスカラー クエリの結果、またはマップおよびフェッチされたオブジェクトが含まれますが、重要なのは、実行されたクエリからデータが取得 (キャッシュ) されることです。

    この方法で redis を使用する場合、キャッシュされた値はすべて NHB クエリの結果である必要があります。これにより、ある種のトランザクションの原子性がもたらされますが、すでに説明した方法ですが、私の知る限り、SCL が古いデータまたはコミットされていないトランザクションからのデータを返したときに、いくつかのバグが見つかりました。

    このアプローチは、誰か (NHB) がまだ RDBMS と Redis の間のビジネス トランザクションを何らかの方法で保証する必要があることを示していることに注意してください。これは単純ではなく、バグもあります。

    また、SLC 自体はそれほど高速なパターンではないことに注意してください。SLC にはオブジェクト自体ではなく、オブジェクトのフィールドが含まれているため、ヒットするたびに新しいオブジェクトが作成されます。そのため、実行された SQL クエリから取得された結果セットではなく、Redis からデータを取得しています。したがって、準備済みステートメントを使用し、RDBMS が通常キャッシュを作成する場合、これによってパフォーマンスが大幅に向上するわけではないことがわかります。

  2. 独立したビジネス ストアとしての Redis。自分でデータを完全に管理し、ネイティブ (C#) コード内で計算を行うことができます (SQL クエリやマップされたオブジェクトとは対照的です)。新しいデータと何らかのトランザクション アプローチを保証する必要があります。

私は何を選びますか？分離された redis。なんで？

  1. 2 次キャッシュとマッピングにより、クエリまたはマップされたオブジェクトからコンテンツが生成されるため、ある程度の契約が得られます。自分で Redis を管理または使用することはできません。特に、キャッシュされたデータは、一部の API (インターフェイス) やある種のサービス (私が設計するように) ではなく、これらのクエリに結合/タイトです。
  2. 独自のコードでデータの計算を行うことができます。
  3. SLC のアプローチは私にはバグがあるように見え、多くの場合、これらのバグを見つけるのは非常に困難でした。
于 2013-09-25T10:59:29.333 に答える