すべての情報をメモリにロードする必要さえあるとしたら、私は信じられないほど驚くでしょう。これは、一例として、現在 (さまざまな理由で) 多数のページに数千のレコードをロードする Web アプリケーションに取り組んでいるためです。これは PHP + MySQL です。それでも、100 ミリ秒をはるかに下回る時間でページをレンダリングできます。
このルートを下る前に、そうしなければならないことを確認してください。まず、データベースを可能な限りパフォーマンスの高いものにします。明らかに、これには適切なインデックスの作成やデータベースの調整などが含まれますが、カートの前に馬を置いています。
何よりもまず、適切なリレーショナル データ モデル、つまりパフォーマンスの高いクエリに適したモデルを用意する必要があります。これは科学であると同時に芸術でもあります。
また、NHibernate が好きかもしれませんが、ORM が常に最良の選択であるとは限りません。たとえば、手動でコーディングされた SQL が非常に優れている場合など、いくつかのまれなケースがあります。
適切なデータ モデルがあり、インデックスとデータベース パラメーターを最適化し、NHibernate を適切に構成したと仮定すると、パフォーマンスがまだ問題である場合にのみ、データをメモリに保存することを検討する必要があります。
これを大局的に見ると、これを行う必要があったのは、1 日に何百万ものトランザクションを実行する必要があるシステム上だけでした。
インメモリ キャッシュを避ける理由の 1 つは、複雑さが増すためです。キャッシュの有効期限、基礎となるデータ ストアへの独立した更新、同期または非同期の更新を使用するかどうか、データの一貫した (最新ではない場合) ビューをクライアントに提供する方法、対処方法などの問題に対処する必要があります。フェイルオーバーやレプリケーションなどで。支払わなければならない巨大な複雑なコストがあります。
上記のすべてを実行してもまだ必要であると仮定すると、必要なのはキャッシュまたはグリッド ソリューションのように思えます。ここではJava グリッド/クラスター ソリューションの概要を説明しますが、それらの多く (Coherence、memcached など) は .Net にも適用されます。.Net のもう 1 つの選択肢はVelocityです。
NHibernate のようなものは、外部からデータベースを更新するものがなく、NHibernate 対応のプロセスが 1 つだけある場合 (クラスター化されたソリューションを除く) にのみ一貫性があることを指摘し、強調する必要があります。2 台の異なる PC 上の 2 つのデスクトップ アプリが両方とも NHibernate を使用して同じデータベースを更新している場合、キャッシュは単純に機能しません。これは、永続化ユニットが他方の変更を認識しないためです。