現在、私は学校図書館の個人執筆プラットフォームを担当しています。基本的なビジネス モデルは完成しましたが、プロジェクトはまだ高同時実行環境で最適化されていません。
各学生は、本を読んだ後に書評を書いたりメモを取ることができます。書評は公開され、メモは非公開となります。現在の慣例によれば、すべてのスチューデント操作はクエリのためにデータベースにアクセスするため、将来的には間違いなくパフォーマンスのボトルネックが発生します。
おそらく ehcache の関連チュートリアルを参照しましたが、良い解決策はありません。 主な理由は、キャッシュが無効であるかどうかを判断できないことです。たとえば、頻度の高い生徒からの一定数のノートをキャッシュに保存し、特定のタイムアウトを 5 分に設定した場合、この 5 分以内に新しいノートが追加または変更された場合はどうすればよいでしょうか。
たとえば、mybatis の SQL ステートメントselect * from commentscondition に対応して、ehcache を通じてメモリ キャッシュを作成できますが、
comments が新しいレコードを追加または更新すると、 ehcache に最後に追加されたキャッシュを正常に更新できます。
キャッシュであるため、データの有効性を許容できる必要があります。そうでない場合、リアルタイム データを厳密に制御したい場合は、クエリのためにデータベースにアクセスすることしかできません。
質問者が説明したビジネスシナリオによると、一般的な解決策は、外部インデックス(もちろんインデックスは完全にリアルタイムではありません)を通じて本と本のレビューの関係を維持し、次にkvキャッシュ(redis、ehcache、マップなど) を使用して、書評の特定のコンテンツをキャッシュします。
データを更新する場合、通常は最初にデータベースが更新され、次にキャッシュが更新されます。インデックスを更新する必要はありません。
データが更新(挿入)された場合、更新に基づいて対応するリレーションシップをインデックスに追加する必要があります。
単純な外部インデックスの場合、データベースに (書籍-書籍レビュー) リレーショナル テーブルを追加してインデックスを構築し、書籍レビューをクエリするときに、最初にリレーショナル テーブルをクエリ (ページ化されたクエリ) してから、特定の書籍レビューをクエリします。書籍レビューの主キーを介して情報を取得する場合 (単一の書籍レビュー情報にキャッシュが追加されます)、クエリを 2 回実行してメモリ内でデータを組み立て、テーブル結合クエリを使用しないことをお勧めします (データベースのパフォーマンスに影響します)。リレーショナル テーブル データのキャッシュを作成する必要はありません。書評情報のキャッシュを増やすだけで済みます。