ElasticSearch-高いインデックス作成スループット
インデックス作成のスループットを非常に高くするために、ElasticSearchのベンチマークを行っています。
私の現在の目標は、30億（3,000,000,000）文書を数時間で索引付けできるようにすることです。その目的のために、現在16GB RAMと8プロセッサの3つのWindowsサーバーマシンがあります。挿入されるドキュメントは、分析されていない数値フィールド（_all 無効になっています）。
この比較的控えめなリグを使用して、1秒あたり約120,000のインデックスリクエスト（大きなデスクを使用した監視）に到達することができ、スループットをさらに高めることができると確信しています。多数の.net NESTクライアントを使用して、1500のインデックス操作を一括してインデックスバルクリクエストを送信しています。
残念ながら、1秒あたり120kリクエストのスループットはそれほど長く続かず、レートは徐々に低下し、数時間後には約15,000に低下します。
マシンを監視すると、CPUがボトルネックではないことがわかります。ただし、物理ディスク（SSDではない）のアイドル時間はすべてのマシンで低下しており、平均アイドル状態が15％未満になっているようです。
設定refresh_interval 60代まで、300代まで、そして最後に15メートルまでは、あまり役に立たなかったようです。 1つのシャードで1つのトランスログをスパイすると、200 MBに達する前に30分ごとにトランスログがフラッシュされることが示されました。
2つのシャーディング戦略を使用してみました。
- 60個の断片（レプリカなし）を持つ1つのインデックス。
- それぞれ20個のシャードを持つ3つのインデックス（レプリカなし）。
どちらの試みもかなり似たような経験になりますが、シャードの数は同じであるため、理にかなっていると思います。
セグメントを見ると、ほとんどのシャードには約30個のコミット済みセグメントがあり、同様の数の検索可能なセグメントがあることがわかります。セグメントサイズは異なります。かつて、max_num_segments = 1を使用してインデックスを最適化しようとすると、終了してから少し時間が経過しました（長い時間がかかりました）。
使用済みのインデックスを削除して新しいインデックスを作成した後、いつでも取り込みプロセス全体を最初から開始すると、同じ動作になります。最初は高いインデックススループットでしたが、30億ドキュメントという目標を達成するずっと前に、徐々に減少していました。そのときのインデックスサイズは約120GBです。
ElasticSearch 1.4バージョンを使用しています。 XmsおよびXmxは、8192MB、使用可能なメモリの50％用に構成されています。インデックスバッファは30％に設定されます。
私の質問は次のとおりです。
- ディスクが現在このリグのボトルネックであると仮定すると、ディスク使用率が徐々に増加するこの現象は正常な現象ですか？そうでない場合、これらの効果を無効にするために何ができますか？
- インデックスのスループットを向上させるためにできる微調整はありますか？したほうがいい？または単にスケールアウトする必要があります。
要するに、私は5つの仮想linuxマシン、8 cpu、16 GBになり、puppetを使用してelasticsearchをデプロイしました。私の文書は少し大きくなりましたが、スループットレートも（わずかに）大きくなりました。平均して1秒あたり15万件のインデックスリクエストに到達でき、2時間で10億件のドキュメントのインデックスを作成しました。スループットは一定ではなく、以前と同様のスループット動作の低下が見られましたが、程度はそれほどではありませんでした。同じ量のデータに毎日のインデックスを使用するので、これらのパフォーマンスメトリックはほぼ毎日同じになると予想されます。
WindowsマシンからLinuxへの移行は、主にIT規則の利便性とコンプライアンスによるものでした。確かにわかりませんが、Windowsでも同じ結果が得られると思います。
私のいくつかのトライアルでは、Christian Dahlqvistが示唆したように、ドキュメントIDを指定せずにインデックス付けを試みました。結果は驚くべきものでした。 significantスループットの増加を観察し、場合によっては300k以上に達しました。この結論は明らかです。絶対に必要な場合を除き、ドキュメントIDを指定しないでください。
また、マシンごとに使用するシャードが少なくなり、これもスループットの向上に貢献しました。