ElasticSearchの理想的なバルクサイズの式は何ですか？
ElasticSearchでバルクインデックスサイズを計算する式が必要だと思います。おそらく以下はそのような式の変数です。
- ノードの数
- シャード/インデックスの数
- ドキュメントサイズ
- RAM
- ディスクの書き込み速度
- LAN速度
誰かが数式を知っているか、使用しているのだろうか。そうでない場合、人々はどのようにバルクサイズを決定しますか？試行錯誤で？
これには黄金のルールはありません。ドキュメントからの抜粋：
1回の一括呼び出しで実行する「正しい」数のアクションはありません。特定のワークロードに最適なサイズを見つけるには、さまざまな設定を試してみる必要があります。
この情報はJava APIのBulkProcessorクラスから取得しました。デフォルトは1000アクションまたは5MBで、フラッシュ間隔を設定することもできますが、これはデフォルトでは設定されていません。使用しているだけです。デフォルト設定。
Java APIを使用している場合は、BulkProcessorを使用することをお勧めします。
ReadESbulk API doc慎重に： https：/ /www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html#_using_and_sizing_bulk_requests
- 1 KiBで試して、20 KiBで試してから、10 KiBで試してください、...二分法
- ドキュメント数ではなく、KiB（または同等のもの）のバルクサイズを使用してください！
- データをまとめて送信し（ストリーミングなし）、可能であれば冗長な情報APIURLを渡します
- 可能であれば、データ内の余分な空白を削除してください
- 検索インデックスの更新を無効にし、後で再度アクティブにします
- すべてのデータノードにわたるラウンドロビン
私はそれについて探していました、そして私はあなたの質問を見つけました:)私はこれをエラスティックで見つけました ドキュメント ..それで私は私のドキュメントのサイズを調査します。
一括リクエストの物理的なサイズを監視しておくと便利なことがよくあります。 1000個の1KBドキュメントは、1000個の1MBドキュメントとは大きく異なります。遊び始めるのに適したバルクサイズは、サイズが約5〜15MBです。
私の場合、一度に挿入できるレコードは100,000を超えることはできませんでした。 1,300万から始まり、50万まで減少し、成功しなかった後、反対側から始まり、1,000、次に10,000、次に100,000、私の最大値です。
インデックス作成の速度に影響を与えるハードウェア以外にも多くの要因があるため、試行錯誤（つまり従来のエンジニアリングプロセス）よりも良い方法は見つかりませんでした：インデックスの構造/複雑さ（複雑なマッピング、フィルター、アナライザー）、データ型、ワークロードがI/OまたはCPUにバインドされているかどうかにかかわらず、 およびsoon 。
いずれにせよ、それがどれほど可変であるかを示すために、ここに投稿されたほとんどのものとは異なるように見えるので、私の経験を共有することができます：
16GB RAM、4 vCPU、および検索中の平均150 MB/sのSSDを備えた単一のvServerで実行される10GBヒープを備えたElastic5.6。
10kドキュメントのバッチサイズ（20k行、25MBから79MBのファイルサイズ）を使用して、httpバルクAPI（curl）を介して、さまざまなサイズのドキュメントに正常にインデックスを付けることができます。各バッチには約90秒かかります。 index.refresh_intervalは、インデックス作成中に-1に設定されますが、これが私が行った唯一の「調整」であり、他のすべての構成がデフォルトです。これは主に、インデックス自体がそれほど複雑ではないという事実によるものだと思います。
VServerのCPUは約50％、SSDの平均は40 MB/s、4GB RAM空き）なので、2つのファイルを並行して送信することで、おそらく高速化できます（単純に増やしてみました）バッチサイズは50％増加しましたが、エラーが発生し始めました）が、その後は別のAPIを検討するか、単にクラスター全体に負荷を分散する方が理にかなっています。