弾性検索：そう

Question

我々は時折、時間の90％は非常に軽く使用されていることを弾性検索バックエンドとのNodeJSアプリケーションを持って、そしてきた影響はありません読み書き重い操作を最適化する方法を理解するには、絶対にファックです。例えば、典型的な基準では、1時間に50-100の読取り要求を受け取ることができ、1-2の書込み要求を受け取ることができる。ピーク時には、50,000の読み取り要求と30,000の書き込み要求を受け取ることがあります。

我々はその再インデックス非常に多くの書き込み要求、などがある状況に実行しているこれらのピーク時間の間に、読み取り要求がクロールされることさえあります。ウェブサイトが応答しなくなります。このタイプの負荷を処理するには、どういうわけかElastic Searchを最適化するか、アプリケーションを再構築する必要があります。そのためには、どのように最適な方法を見つけようとしています。私はよりよく理解したいのですがどのような

は次のとおりです。

1）すべてを殺すように見える、そしてどのような最適化またはそれをスピードアップするために利用可能である書き込み操作に何が起こっていますか？

2）私は速く一括操作を使用して複数のレコードを挿入することができ、コードの観点から言うことができますが、弾性検索がこれをインデックス付けない方法は、実際にシステムにあまり効率的である場合、私は思ったんだけど。バルクインサートを取り除くか、少なくともインサートのサイズを小さくすると、パフォーマンス（特に物事の読み込み側）が大幅に改善されるはずですか？この変化が物事にどのように影響するかを理解するのに役立つものはどれも参考になります。

3）書き込み操作がバックアップされている場合でも、読み取り操作がまだ動作し続けるように、読み取り/書き込み操作を分割するためにとにかくはありますか？

私は直接Elastic Searchのインサートを使うのではなく、メッセージのキューを使うことを考えていましたが、質問2に戻って、読み込み操作のためにこれを最適化する方法は肯定的ではありません。

読み込みとは別のクラスタに挿入を行い、データをマージする方法はありますか？これは多かれ少なかれ効率的でしょうか。

ありがとうございました。

Answer 1

1. thread poolsをご確認ください。インデックス、検索、一括検索などがあります。これらの考え方は、一括してクエリをブロックすべきでないということです。
2. バルクリクエストを使用すると、ネットワークのオーバーヘッドを大幅に削減できます。しかし、optimal size for your scenarioを見つけるためのベンチマーク。上記のように、適切なリフレッシュ間隔を見つけることもできますが、データが検索可能になるまでにどれくらい時間がかかります。
3. 時間ベースのデータがある場合は、異なるノードタイプを試すことができます。しかし、すべてのあなたの書き込みと読書が同じ指標になるなら、あなたは運がない。現在、同じインデックスの読み取りノードと書き込みノードに分割する方法はありません。
4. 非常に不安定な負荷を持つことは、キューの良いユースケースかもしれませんが、動く部品と複雑さが増します。状況に応じて、適切な選択肢かもしれません。またはピーク負荷のためにElasticsearchクラスターを単純にオーバープロビジョニングするほうが安いかもしれません。
5. インデックスとシャードの数を正しく取得してください。これはすべてのクラスタに適用されますが、一般的な苦労点です。

PS：調整候補が見つかった場合は、それらがElasticsearchバージョンに適用されていることを確認してください。一部の設定は時間の経過と共に変更されたか、完全に削除されました。最新のマイナーバージョンを使用していない場合は、一般的にElasticsearchのバージョンが改善されます