2

消費者がキーワードを入力して製品を検索できる E コマース サイトを構築しているとします。最大で 200,000 個の製品があり、何百万人もの消費者がシステムを使用しているとします。product テーブルがかなり頻繁に更新されるとしましょう。製品の数はそれほど多くないため、製品テーブル全体をメモリに保存して、データベースにアクセスする代わりに検索できる可能性があります。同じデータを格納するが異なるサーバーに存在する分散キャッシュを作成したいと考えています (高可用性とパフォーマンス上の理由から)。これらのキャッシュ間でデータを同期し、製品テーブルが変更されたときにキャッシュを無効にする必要があります。

私たちのアプリケーションは、ASP.NET MVC と NHibernate を使用して構築されています。NHibernate のレベル 2 キャッシングが私の状況に役立つかどうかを理解しようとしています。皆さんがこれに光を当てることができれば、本当に感謝しています。

レベル 2 キャッシュがクエリ結果のキャッシュに役立つことを理解しています。そのため、2 人の異なるユーザーが同じキーワードを使用して検索している場合、L2 キャッシュはデータベースではなくキャッシュから結果を提供します。しかし、製品テーブルが頻繁に更新され、キャッシュされた結果が古くなるため、あまり役に立ちません。私の質問は、L2 キャッシングを正しく理解しているか、キャッシュを希望どおりに管理するのに役立つものが存在するかどうかです (複数のキャッシュ、同じデータ、キャッシュ間の同期とキャッシュの無効化)。どんな考えでも大歓迎です。

4

3 に答える 3

2

第 2 レベルのキャッシュが役立つかどうかは、キャッシュ ヒットに関連して製品テーブルが更新される正確な頻度によって異なります。1 時間に 100 個の新製品を追加しても、1 時間に 10,000 件のクエリを受け取る場合、10% のキャッシュ ヒット率でも大きな違いが生じます。レートが逆転すると、二次キャッシュはほとんど価値がなくなります。

本番環境に近いストレス テスト環境をセットアップし、さまざまな 2 次キャッシュ プロバイダーでベンチマークを実行することをお勧めします。

また、DB が更新の多いシナリオに対して適切に構成されていることも確認してください。

于 2010-02-11T17:05:42.290 に答える
2

2 番目のレベルのキャッシュ (memcached プロバイダーを使用) と NHibernate.Search アドオンの両方を使用したので、両方から恩恵を受けることができるように思えます。

NHibernate.Search コンポーネントは Lucene.Net に依存しており、キーワード検索はデータベース自体から切り離されています。マッピングされたクラスごとに異なるインデックス ファイルが作成され、属性を使用してプロパティ レベルで最適化を設定できるため、さらに詳細な粒度が得られます。さらに、ベスト マッチと命題を実装することもできます (Lucene in Action および/または Hibernate Search in action を確認してください)。注意として、インデックスを維持する必要はありません (インデックスの再構築を明示的に要求しない限り)。必要に応じてインデックスを操作できますが、実装はバックグラウンドですべてを管理します。そのため、製品を追加/削除/更新すると、対応するインデックスが自動的に更新されます。

2 番目のレベルのキャッシュでは、パフォーマンスが即座に向上します。約 200 万行のデータ セットを使用したテスト環境では、リクエスト数が非常に少ない場合でも 20% 以上の改善が見られました。要求数が増加するにつれて、パフォーマンスの向上は徐々に大きくなります。アプリケーションは最初に第 2 レベルのキャッシュにヒットし、それが見つからない場合は DB にヒットして必要な行をフェッチし、将来のクエリのためにそれらをキャッシュに挿入します。ここでも、キャッシュ期間やその他の構成設定などを管理したり、必要に応じてキャッシュ (すべて、一部、または特定のエントリ) を明示的にクリアしたりできます。キャッシュの状態は、保存/更新/削除中にアプリケーションによって管理されることに注意してください。

スケーラビリティのため * 第 2 レベルのキャッシュはプロバイダーによって異なります (つまり、memcached はパフォーマンスとスケーラビリティが高く、分散インスタンスをサポートします)。* Lucene.Net/NHibernate.Search の場合、インデックスが存在する特定の場所を設定する必要があり、その場所はすべての Web アプリケーション インスタンスから読み取り/書き込みのためにアクセスできる必要があります。ここで、重要なリンクは I/O とファイルの競合であることに注意してください。そのため、軽量ファイル システムよりも高速なマシンをセットアップすると、それが発生しなくなります (私は、1 秒あたり何千もの検索要求があるシナリオについて話しているのです)。

補足として、NHibernate.Search を強くお勧めします。これは、LIKE クエリよりも非常に高速であり、アプリケーション内に SQL-Server の全文検索を実装するよりも使いやすいためです (私はこれを実行しました)。

于 2010-02-13T12:05:44.283 に答える
1

Lucene でNHibernate.Searchを使用することをお勧めします。2 次キャッシュと連携します。Lucene は、洗練されたテキスト検索を高速に実行してから、エンティティ キーを NHibernate に戻し、エンティティ全体を第 2 レベルのキャッシュから引き出すことができます。NHibernate.Search 拡張機能は、Lucene インデックスの同期を維持する作業を行います。

TekPubは、製品の説明を検索する正確なシナリオに関する最近のエピソードを行いました。このエピソードでは、NHibernate クエリ、SQL フルテキスト インデックス作成、および NHibernate.Search を使用した Lucene を比較します。

于 2010-02-11T17:09:57.040 に答える