0

H2 データベースには、最大 1,200 万行の比較的大きなテーブルがあります。テーブルには、ユーザーが Web インターフェイスで表示する必要があるステータス情報が含まれています。ユーザーは主に、過去数百または数千のエントリ、または過去 n 日間のエントリのみに関心があります。もちろん、すべてのエントリを照会する必要がある場合もありますが、これはめったに発生せず、時間がかかる可能性があると想定できます。現在、私たちの主な問題は、ターゲットプラットフォームとして本格的なサーバーではなく、より組み込みのソリューションを使用していることです。そのサイズのテーブルでは、組み込みシステムが応答するのに数秒かかり、Web UI (ajax など) が感じられます。遅い。

クエリを高速化するために、既にインデックス、max_row_memory、およびキャッシュを追加しています。これにより、クエリは驚くほど高速になりますが、まだ目標の範囲内ではありません。私が理解しているように、テーブルで INSERT / UPDATE / DELETE が実行されると、H2 はテーブルのキャッシュをフラッシュします。アプリケーションの大部分は最後の n 行に依存しており、これらの n 行を常にキャッシュに保持する方法を探しています。これにより、最後の n 行を取得する SELECT クエリが呼び出された場合、前の INSERT の後でも、行はキャッシュから収集されます。H2 で直接解決策を見つけられなかったので、最初のアプローチは、アプリケーション内の第 2 レベルとしてキャッシュを実装することです。解決策は問題ありませんが、設計の観点からは、H2 内に配置する方が魅力的です。H2でこれを解決する方法を知っている人はいますか?

4

1 に答える 1