私は、毎日約 100,000 件の検索に対応するアプリケーションの開発に取り組んでいます。データベースには毎日ほぼ同じ数の更新/挿入/削除があると想定できます。現在のアプリケーションはネイティブ SQL を使用しており、Hibernate に移行して Hibernate Search を使用する予定です。
データベース レコードには継続的な変更があるため、自動インデックス作成を有効にする必要があります。経営陣は、自動インデックス作成がパフォーマンスに与える影響について懸念しています。
レコードの変更が変更されるとすぐに検索できるようにする必要があるため、スケジュールされたバッチ インデックス作成を行うことはできません。
ある種のパフォーマンス統計を探すために検索しましたが、何も見つかりませんでした。
すでに Hibernate Search に取り組んでおり、同様の状況に直面した人は、考えを共有できますか?
助けてくれてありがとう。
よろしく、
シャードゥル。
うまくいくかもしれませんが、ベースラインがないと推測するのは困難です。1 日あたりさらに多くの検索を行った経験があり、微調整を行った後はうまく機能しますが、試してみないとシナリオに当てはまるかどうかを知ることは不可能です。通常のチューニングが失敗し、NRT が十分な速さで証明できない場合は、いつでもインデックスをシャーディングし、マルチマスター構成を使用して、Infinispan などの分散型第 2 レベル キャッシュをプラグインできます。それをセットアップする時間と合理的なハードウェア。
どのようなハードウェアが必要になるかはわかりませんが、ネイティブ SQL ソリューションよりも効率的であることは間違いありません。POC を作成して、1 つのノードでどこまで到達できるかを確認することをお勧めします。使用しているクエリの種類が Lucene に適している場合、複数のサーバーは必要ないかもしれません。Lucene は更新よりもクエリの方がはるかに高速であることに注意してください。したがって、同じ量の書き込みと検索があると推定されるため、問題は 1 秒あたりの検索数ではなく、1 秒あたりの書き込み (更新) である可能性があります。および合計データ（インデックス）サイズ。最新の Hibernate Search では、このようなユース ケースに適した NRT インデックス マネージャーが導入されました。