Solrの格納フィールドのサイズを最小限に抑える必要がありますか？

Question

私は、ビジネスリスティングウェブサイトの検索にソルを導入することを検討しています。このサイトには約200万レコードがあります。

結果ごとにいくつかの重要なデータが表示される検索結果ページがあります。この要約情報に必要なデータは、1件につき約1KBであると私は信じています。

Solr内の検索に必要なフィールドを単純に索引付けすることができますが、これは、結果ごとに別々のデータベース呼び出しを行い、サマリー情報を取り込むことを意味します。 Solrがこのデータをすべて返すことができれば、〜40回のデータベース往復よりも優れたパフォーマンスが期待できます。

Solrのメモリ使用量が大きすぎる（これはどのように計算すればよいでしょうか）、追加データでは索引付けに時間がかかることが懸念されます。

Answer 1

これらのフィールドを40 db往復と比較してSolrに保存すると、大きなメリットがあります。スキーマの設定でフィールドを「インデックスされていない」（indexed = false）とマークしていることを確認してください（ただし、インデックス化および取得時にCPUを使用します）。

フィールドを「索引付けされていない」とマークすると、索引付け時にフィールドを処理するアナライザは索引付けされたフィールドよりもはるかに高速になります。

Answer 2

これはトレードオフなので、これを自分で分析する必要があります。

Solrのパフォーマンスは、クエリだけでなく、ドキュメント自体のキャッシュに大きく依存します。これらのキャッシュはメモリに依存しており、ドキュメントが大きくなればなるほど一定量のメモリに収まることは少なくなります。

ドキュメントサイズは、インデックスサイズと複製時間にも影響します。マスタースレーブ構成の大きいインデックスの場合、これはインデックスを更新できる速度に影響します。

理想的には、フィールドの有無にかかわらず、キャッシュのヒット率を異なるキャッシュサイズで測定する必要があります。十分なキャッシュヒット率を得るためにメモリを費やすことができる場合は、とのフィールドを使用してください。できない場合は、別のシステムからドキュメントコンテンツを取得する必要があります。

あなたが言及しなかった3つ目の選択肢があります。これは、DBの外に文書を格納することですが、Solrには格納しません。検索結果とできるだけ近い形式で保存する必要があります。索引を作成/更新するコードは、これらの文書も作成/更新できます。これはたくさんの仕事ですが、すべてのもののように、あなたが必要とするパフォーマンスと、それを得るために何をしたいのかが分かります。

EDIT：キャッシュヒット率とスループットを測定するために、現在のクエリログが最適なテストソースであることがわかりました。 1日か2日分のライブ問合せを実行し、さまざまな索引や構成に対して実行して、どれくらい効果的かを確認します。