1.ハードウェア環境の選択
可能な場合は、SSDハードドライブをできるだけ使用し、適切なCPUを使用してください。ESのパワーは、ES自体の分散アーキテクチャとluceneの特性にあります。IOの改善により、ESの速度とパフォーマンスが大幅に向上します。メモリ構成の点では、通常、64Gメモリのマシンノードの方が優れています。
第二に、システムトポロジー設計
ESクラスターがトポロジー的に構造化されている場合、一般的にホットウォームアーキテクチャモードが採用されます。つまり、マスターノード、ホットノード、ウォームノードの3種類のノードが設定されます。
マスターノードの設定：通常、3つの専用マストノードがセットアップされ、最適な弾性拡張機能が提供されます。もちろん注意が必要です
スプリットブレインの問題を防ぐためのdiscovery.zen.minimum_master_nodesプロパティの設定は、次の式の設定を使用します：N / 2 + 1（Nは候補マスターノードの数）。ノードは残ります：node.data：false;マスターノードはクエリとインデックス操作に参加せず、クラスター管理のみを担当するため、CPU、メモリ、およびディスク構成はデータノードよりもはるかに低くなる可能性があります。
ホットノード設定：最近頻繁に使用されるインデックスを維持しながら、インデックスノード（書き込みノード）。これはIOとCPUを集中的に使用する操作です。良好な書き込みパフォーマンスを維持するには、SSDディスクタイプを使用することをお勧めします。通常、ノード数は3以上に設定されます。ノードをホットタイプに設定します。
node.attr.box_type：hot
インデックス用、設定により
index.routing.allocation.require.box_type：hotを設定して、ホットノードにインデックスを書き込むことができます。
ウォームノード設定：頻繁にアクセスされない読み取り専用インデックス用。アクセス頻度が低いため、通常は通常のディスクを使用してください。メモリとCPUの構成は、ホットノードと一致している必要があります。ノードの数は通常3以上です。
インデックスが頻繁に照会されなくなったら、次を渡すことができます
index.routing.allocation.require.box_type：ウォーム、インデックスがウォームとしてマークされ、ホットノードにインデックスが書き込まれないようにします。これにより、SSDディスクリソースがブレードで使用されます。このプロパティが設定されると、ESは自動的にインデックスをウォームノードにマージします。同時に、elasticsearch.ymlでindex.codec：best_compressionを設定して、ウォームノードの圧縮構成を確認することもできます。
調整ノード：調整ノードはディストリビューションでの調整に使用され、各シャードまたはノードから返されたデータが統合されて返されます。ESクラスターでは、すべてのノードが調整ノードである場合がありますが、node.master、node.data、およびnode.ingestをfalseに設定することで、特別な調整ノードを設定できます。より良いCPUとより高いメモリが必要です。
3、ESメモリ設定
ESビルドはluceneに基づいているため、luceneの強力な設計は、luceneがオペレーティングシステムのメモリをうまく活用してインデックスデータをキャッシュし、高速なクエリパフォーマンスを提供できることです。Luceneのインデックスファイルは単一のファイルに保存され、不変です。OSの場合、インデックスファイルをキャッシュに保存しておくと、すばやくアクセスできるため、物理メモリの半分を残しておく必要があります。 Luceneにとって、物理メモリの残りの半分はES（JVMヒープ）用に予約されています。したがって、ESメモリ設定に関しては、次の原則に従うことができます。
1.マシンのメモリが64G未満の場合は、ESが50％、ルセンが50％の一般原則に従います。
2.マシンのメモリが64Gを超える場合は、次の原則に従ってください。
a。主な使用シナリオが全文検索の場合、4〜32GのメモリをESヒープに割り当てることをお勧めします。他のメモリは、高速なクエリパフォーマンスを提供するためにLucene（セグメントキャッシュ）が使用するオペレーティングシステム用に予約されています。
b。主な使用シナリオが集計または並べ替えであり、それらのほとんどが数値、日付、geo_points、not_analyzed文字タイプの場合、4〜32GのメモリをESヒープに割り当て、他のメモリをオペレーティングシステムに残してLuceneにすることをお勧めします（ドキュメント値キャッシュ）を使用して、ドキュメントベースの高速なクラスタリングとソートのパフォーマンスを提供します。
c。使用シナリオが集計または並べ替えであり、すべて分析された文字データに基づいている場合は、現時点でより多くのヒープサイズが必要です。マシンで複数のESインスタンスを実行することをお勧めします。各インスタンスは50％以下のESヒープ設定を維持する必要があります（ただし、 32Gを超え、ヒープメモリが32G未満に設定されている場合、JVMはオブジェクトインデックス圧縮技術を使用してスペースを節約し、50％以上がLuceneに予約されます。
3.スワップを禁止します。メモリとディスクの交換が許可されると、致命的なパフォーマンスの問題が発生します。
ESのパフォーマンスを確保するために、JVMのロックされたメモリを維持するには、elasticsearch.ymlのbootstrap.memory_lock：trueを使用します。
4. GC設定の原則：
a。GCの現在の設定を維持します。デフォルト設定はConcurrent-Mark and Sweep（CMS）です。G1にはまだ多くのバグがあるため、G1GCに変更しないでください。
b。スレッドプールの現在の設定を維持する現在のESスレッドプールには1.Xよりも最適化された設定があり、現状を維持するだけで、デフォルトのスレッドプールサイズはCPUコアの数と同じです。変更する必要がある場合は、式（（CPUコア数* 3）/ 2）+ 1に従って設定します。CPUコア数の2倍を超えることはできません。ただし、デフォルトの構成を変更することはお勧めしません。変更すると、CPUに大きな損傷を与えます。
4番目に、クラスターのシャーディング設定
ESがインデックスを作成すると、シャードの設定を調整できなくなります。ESでは、シャードは実際にはluceneインデックスに対応しており、luceneインデックスの読み取りと書き込みは多くのシステムリソースを消費します。大きすぎるため、インデックスを作成するときは、断片の数を適切に構成することが非常に重要です。一般的に、私たちはいくつかの原則に従います：
1.各シャードが占有するハードディスク容量を、ESの最大JVMのヒープスペース設定を超えないように制御します（通常、32Gを超えないように設定され、上記のJVM設定原則に参加します）。したがって、インデックスの合計容量が約500Gの場合、そのポイントフィルムのサイズは約16ですが、原則として原則2を同時に検討することをお勧めします。
2.ノードの数を検討します。通常、ノードは物理マシンである場合があります。シャードが多すぎてノードの数を大幅に超える場合は、ノードに複数のシャードが発生する可能性があります。ノードに障害が発生すると、複数のコピーを保持すると、データが失われる可能性があり、クラスターを回復できません。したがって、シャードの数はノードの数の3倍を超えないように設定されています。
V.マッピングモデリング
1.ネストされたクエリまたは親/子の使用はできるだけ避けてください。ネストされたクエリは遅くなり、親/子のクエリは遅くなり、ネストされたクエリより数百倍遅くなります。そのため、マッピング設計段階（大規模なテーブルの設計または比較）で実行できます。スマートデータ構造）、親子マッピングを使用しないでください。
2.ネストされたフィールドを使用する必要がある場合は、ネストされたフィールドが多すぎないことを確認してください。現在のESのデフォルトの制限は50です。参照：
index.mapping.nested_fields.limit：50
ドキュメントの場合、ネストされた各フィールドは独立したドキュメントを生成するため、ドキュメントの数が増加し、クエリの効率、特にJOINの効率に影響します。
3.動的な値をキーとして使用しないでください。動的に増加するマッピングにより、クラスターがクラッシュします。同様に、フィールドの数も制御する必要があります。ビジネスで使用されていないフィールドにインデックスを付けないでください。インデックス付きフィールドの数、マッピングの深さ、およびインデックス付きフィールドのタイプを制御することは、ESパフォーマンスの最適化にとって最優先事項です。以下は、フィールド数とマッピング深度に関するESのデフォルト設定の一部です。
index.mapping.nested_objects.limit：10000
index.mapping.total_fields.limit：1000
index.mapping.depth.limit：20
6番目に、インデックスの最適化設定
1. refresh_intervalを-1に設定し、同時にnumber_of_replicasを0に設定します。コピーを設定せずに更新間隔の期間をオフにして、書き込みパフォーマンスを向上させます。
2. index_buffer_size設定を変更します。これは、パーセンテージまたは特定のサイズとして設定でき、サイズはクラスターのサイズに応じて設定およびテストできます。
indices.memory.index_buffer_size：10％（认）
indices.memory.min_index_buffer_size：48mb（デフォルト）
indices.memory.max_index_buffer_size
3.トランスログに関連する設定を変更します。
a。メモリからハードディスクへのデータの動作周波数を制御して、ハードディスクIOを削減します。sync_intervalの時間を大きく設定できます。
index.translog.sync_interval：5s（デフォルト）
b。トランログデータブロックのサイズを制御するしきい値のサイズに達すると、Luceneインデックスファイルにフラッシュされます。
index.translog.flush_threshold_size：512mb（认）
4. _idフィールドを使用する場合、IDのバージョン管理を回避するために_idをできるだけカスタマイズしないでください。ESのデフォルトのID生成戦略を使用するか、数値IDを主キーとして使用することをお勧めします。
5. _allフィールドと_sourceフィールドの使用は、シーンとニーズに注意を払う必要があります。_allフィールドには、全文検索を容易にするためのすべてのインデックスフィールドが含まれます。そのような要件がない場合は、無効にすることができます。元のドキュメントデータの要件は、includes属性とexcludes属性を設定することで定義できます。
6.適切な構成では、分析されたnot_analyzedインデックス属性を使用し、ビジネス要件に従ってフィールドをセグメント化するかどうかを制御します。クエリまたはクラスタリングの効率を向上させるために、設定時にgroupbyで必要なフィールドのみがnot_analyzedに設定されます。
7、クエリの最適化
1. query_stringまたはmulti_matchのクエリフィールドが多いほど、クエリが遅くなります。copy_to属性を使用して、マッピング段階で複数のフィールドの値に新しいフィールドのインデックスを作成できます。multi_matchの場合は、新しいフィールドを使用してクエリを実行します。
2.日付フィールドのクエリ、特にnowを使用するクエリには実際にはキャッシュがないため、ビジネスの観点から今すぐ使用する必要があるかどうかを検討できます。結局のところ、クエリキャッシュを使用すると、クエリの効率が大幅に向上します。
3.指定されたサイズの結果セットデータを置くためにESがデータ構造を確立する必要があるため、query.setSizeをInteger.MAX_VALUEに設定できないなど、クエリ結果セットのサイズを法外な値に設定することはできません。
4.スクリプトをできるだけ使用しないようにし、必要に応じて無痛＆拡張エンジンを選択します。スクリプトクエリを使用したら、コントロールの戻りに注意する必要があります。また、ESにはスクリプトを実行するためのタイムアウトコントロールがないため、現在のスクリプトが実行されない限り、クエリは常にブロックされます。
5.過度に深い階層集約クエリを回避するために、深すぎるgroup byはメモリとCPUの消費につながります。サービスレイヤーでプログラムを介してビジネスを組み立てるか、パイプラインで最適化することをお勧めします。
6. AGGのパフォーマンスを向上させるために事前にインデックス付けされたデータを多重化する：範囲の集計を用語の集計で置き換える、年齢に応じてグループ化するなど、グループ化の目標は次のとおりです：若年（14歳未満）青年（14-28）中年（29-50 ）高齢者（51歳以上）の場合、インデックス作成時にage_groupフィールドを設定して、データを事前に分類できます。したがって、範囲を集約するために範囲を押す代わりに、age_groupフィールドを渡すだけで十分です。
7.キャッシュの設定と使用：
a.QueryCache：ESをクエリする場合、フィルタークエリはクエリキャッシュを使用します。ビジネスシナリオでフィルタークエリが多数ある場合は、クエリキャッシュを大きく設定してクエリの速度を上げることをお勧めします。
indices.queries.cache.size：10％（デフォルト）。これは、パーセンテージまたは256mbなどの特定の値として設定できます。
もちろん、クエリキャッシュは無効にすることもできます（デフォルトで有効になっています）。index.queries.cache.enabled：falseで設定します。
b.FieldDataCache：クラスタリングやソートを行う場合、フィールドデータキャッシュを多用するため、クラスタリングやソートシーンが多い場合は、フィールドデータキャッシュのサイズを設定する必要があります。
indices.fielddata.cache.size：30％または設定する特定の値10GB。ただし、シーンまたはデータが頻繁に変更される場合は、キャッシュのロードのオーバーヘッドも非常に大きいため、キャッシュを設定することはお勧めできません。
c。ShardRequestCache：クエリ要求が開始された後、各シャードは結果を調整ノード（調整ノード）に返し、調整ノードは結果を統合します。
要求がある場合は、オンに設定できます。
index.requests.cache.enable：有効にする場合はtrue。
ただし、シャードリクエストキャッシュは、hits.total、集計、提案のみをキャッシュし、ヒットはキャッシュしません。または設定することにより
indices.requests.cache.size：キャッシュスペースのサイズを制御する1％（デフォルト）。