3

現在、約 5,000 万のドキュメントを持つ Solr インスタンスがあります。ゼロlongの標準longフィールド タイプを使用して、よく並べ替えるフィールドがあります。precisionStep

<fieldType name="long" class="solr.TrieLongField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/>
<field name="row" type="long" indexed="true" stored="true" />

並べ替えを行う場合、インデックスをメモリにロードする必要があります。私たちの場合、値の範囲が広いrowため、並べ替えを行うには 500m から 1g のヒープが必要です。

このメモリ使用量の要件を何らかの方法で削減できるかどうか疑問に思っています。

フィールドの を大きくするprecisionSteprow、インデックスのサイズが小さくなり、ソートに必要なメモリの量が減りますか? ソート速度に対してこれを行う場合、トレードオフはありますか? そして、より高い精度のステップで並べ替えは完全に正しいでしょうか (行の値は厳密に正しい順序である必要があります)?

現在、1GB のヒープはかなり許容範囲ですが、より多くのrow値を持つドキュメントをさらに追加すると、メモリ要件が高くなりすぎるのではないかと少し心配です。


(jpountzの回答後に追加)

これは現在メモリに収まっていますが、今後数か月で追加されると予想されるドキュメントの数に合わせて拡張することはできません. おそらく、Solr から結果をソートせずに取得し、ディスクベースのjava-merge-sortを使用してクライアント側でソートします。

4

1 に答える 1

2

パラメータは、precisionStep範囲クエリにのみ関連します。並べ替えを実行するには、Lucene は にフィールド値をロードする必要がありますfield cache。long は 8 バイトなので、フィールドのフィールド キャッシュには約 8B * 50M ~ 400 MB が必要です。このフィールドに本当に long が必要な場合、メモリ使用量を削減する方法はありません (一方、代わりに int を使用すると、~200MB しか必要ありません)。

于 2012-07-14T17:15:37.563 に答える