1

私はさまざまなインフラストラクチャ アプローチを試していますが、次のことに気づいて驚いています。

Solr4.4 で SQL クエリを介して DataImportHandler を使用して、130 万件のドキュメント (すべてのフィールドがインデックス付けされ、保存され、一部がシングル分析された) のインデックスを作成しました。

アプローチ1 : 単一の Solr インスタンス

インデックス作成時間: ~10 分

「index」フォルダのサイズ：1.6GB

アプローチ 2: 2 つのインデックス スライスを持つ SolrCloud。

インデックス作成時間: ~11 分

「インデックス」フォルダのサイズ: 1.6GB + 1.5GB = 3.1GB

各インデックス スライスには約 0.65M のドキュメントがあり、予想される元の合計数に追加されます。

アプローチ3 : 2 つのシャード (リーダー 1 つ + レプリカ 1 つ) を持つ SolrCloud

インデックス作成時間: ~30 分

「インデックス」フォルダのサイズ: リーダー (4.6GB)、レプリカ (3.8GB) = 8.4GB (これは 1.6GB * 2 であると予想されていましたが、~1.6GB*5.25 です)

SolrCloud のチュートリアルに従っています。

スライス (パーティション) やシャーディング (レプリケーション) に関係なく、すべてのインスタンスに存在する必要がある用語辞書などのメタデータ (間違っている場合は修正してください) があることを認識しています。

ただし、アプローチ 2 と 3では、最終的なインデックス サイズが大幅に増加 ( 400% ) します。

洞察を提供してください。

4

1 に答える 1

1

全体的なインデックス サイズから、ドキュメントはかなり小さいと思います。用語辞書の相対的なサイズが大きいのはそのためです。その数のドキュメントではかなり似ているため、2 倍になります。したがって、1.6 は 3.1Gb になります。

アプローチ 3 については、それがクリーンなテストであると確信していますか? トランザクション ログをサイズに含めた可能性はありますか? 最適化するとどうなりますか？インデックス ファイルの拡張子を確認することで、正確に何がサイズに追加されるかを確認できます。ここを参照してください: https://lucene.apache.org/core/4_2_0/core/org/apache/lucene/codecs/lucene42/package-summary.html#file-names

于 2013-10-19T17:44:31.553 に答える