7つの原則、簡単に楽しいESを使用してelasticsearch
蟻の兄弟2019年5月20日夜02時46分33秒インターネット
まず、ハードウェア環境を選択
条件であれば、可能な限りSSDハードドライブ、良いCPUの使用。一般的な、好ましいノード64Gメモリマシンのコンフィギュレーションメモリ、;大幅にスピードとESのパフォーマンスを改善するIOを増強する;強力は、ES ESの特性は、それ自体とLuceneのアーキテクチャを分散することです。
第二に、システムトポロジの設計
マスターノード、およびノードウォームホットノード：ESクラスタトポロジーアーキテクチャでは、一般的にホットウォーム・アーキテクチャー・パターンを使用して、すなわち、三つの異なるノードのタイプを提供しました。
マスターノードの設定：通常、最高の柔軟性、スケーラビリティを提供するために、3つの専用ザ・マスターノードを提供します。もちろん、注意しなければなりません
方程式セットを使用してスプリットブレインの問題を防止するために、discovery.zen.minimum_master_nodesプロパティを設定：N / 2 + 1（Nは、マスタ候補ノードです）。マスターノードがクエリに参加していないため、インデックス操作、クラスタ管理のための唯一の責任なので、CPU、メモリ、ディスク構成、データノードよりもはるかに低くすることができる;偽：node.data：ノードが残っています。
ホットノードの設定：iノード（ノードを書き込み）、指数の最近の頻繁な使用を維持したまま。IOとCPU集約型の動作として、SSDディスクタイプ、良好な筆記性能を推奨し、ノードの数は、一般に3つ以上配置されています。ホットノードセットのタイプ：
node.attr.box_type：ホット
インデックスのために、設定することにより、
index.routing.allocation.require.box_type：ホットあなたが熱い書き込みにインデックスノードを設定することができます。
暖かいノードの設定：アクセス頻度の低いため、読み取り専用インデックス。彼らは頻繁に訪問していないので、あなたは一般的に通常のディスクを使用することができます。メモリは、CPUは、ホットノードと一致するように配置され、ノードの数は、一般に、3つ以上です。
インデックスは、もはやによって頻繁に問い合わせない場合
index.routing.allocation.require.box_type：暖かい、温かいとしてインデックスマークインデックスが賢明ホットノードなので、SSDディスクリソースを書き込まれないことを確認するように。一度ESが自動的に暖かいインデックスノードに組み込まれ、このプロパティを設定します。同時に、elasticsearch.yml index.codecで提供することができる：圧縮best_compressionは暖かいノード構成を保証します。
ノードの調整：分散各スライスの後、作るか、またはデータ統合ノードリターンを返すように調整におけるコーディネータ・ノード。ESクラスタでは、すべてのノードがコーディネータノードである可能性が高い、しかし、node.master設定することができ、node.data、特別なコーディネートノードが偽に設定する必要がありnode.ingest。より良いCPUと高いメモリが必要。
三、ESのメモリ設定
LuceneをベースとESの構築、および高速なクエリパフォーマンスを提供するために、インデックスデータをキャッシュするために、オペレーティング・システム・メモリを有効に利用することができLuceneのLuceneの設計のパワー以来。Luceneインデックスファイルを1つのファイルにsegements、およびOSのための不変のストレージ、素早くアクセスするためのキャッシュに残るインデックスファイルに非常に友好的であることができますので、我々が物理メモリの半分を残す必要がありますLuceneのに、物理メモリのES（JVMのヒープ）の残りの半分を残します。だから、ESのメモリ設定の面では、次の原則に従うことができます。
マシンのメモリが64G未満の場合1、50％左のLuceneに50％をES、一般的な規則に従います。
2.マシンのメモリが64Gよりも大きい場合には、次のガイドラインに従ってください。
。Aメイン使用シナリオは、フルテキスト検索である場合、それは4〜32Gのメモリを割り当てるESヒープに推奨され、使用のLucene（セグメントキャッシュ）のためのオペレーティングシステム用に予約他のメモリ、より高速なクエリパフォーマンスを提供します。
主な使用シナリオは、高分子またはソートされているとした場合、B。ほとんどの数値、日付、geo_pointsおよび他のオペレーティングシステムのメモリに記憶ESヒープ4〜32Gを割り当てるための割り当てのために推奨さnot_analyzed文字の種類は、luceneの放置します（DOC値キャッシュ）を使用し、パフォーマンスを並べ替え、迅速なドキュメントベースのクラスタリングを提供します。
シーンが重合を並べ替えたりするために使用され、分析された文字データに基づいている場合は、C。、それはより多くの時間ヒープサイズを必要とする、複数のインスタンスのESマシンを実行しているお勧めし、各インスタンスは、提供ESヒープの50％以下に残っていない（ただし、 32G、32G以下ヒープメモリの設定、スペースを節約するために、オブジェクトインデックスの圧縮技術を使用してJVM）、50％以上の左のLucene超えます。
3.致命的なパフォーマンスの問題が発生します、一度許可され、スワップメモリとディスクを交換しないでください。
中elasticsearch.ymlでbootstrap.memory_lockで：真、JVMのメモリロックを維持するために、ESのパフォーマンスを確保します。
4. GCの設定の原則：
。GCは、既存の設定を維持するために、デフォルトの設定は次のとおりです。並行マークとスイープ（CMS）は、現在のG1ので、多くのバグがあり、G1GCを交換しないでください。
。Bは現在、ES 1.Xは、最適化の設定を超えていた、あなたは現状を維持することができ、スレッドプールをスレッドプールの既存の設定を維持し、CPUコアの数に等しいデフォルトスレッドプールサイズ。あなたが変更する必要がある場合は、式（（CPUコア* 3）/ 2）+ 1セットに従って、CPUコアのせいぜい2倍の数、デフォルトの設定を変更することは推奨されません、そうでない場合はCPUはあざが発生します。
第四に、クラスタの断片化が提供されています
インデックスが作成されるとESは、あなたが設定の断片化を調整することはできませんが、ESには、実際には、スライスがLuceneインデックスに対応し、読み書きLuceneインデックスは、システムリソースの多くを取るでしょう、したがって、フラグメントの数を設定することはできません大きすぎる;あなたは、インデックスを作成するときに、したがって、フラグメントの数の合理的な配分は非常に重要です。一般的に、我々はいくつかのガイドラインに従ってください。
1つのコントロール各スライスのスタックのハードディスク容量が最大ES JVMが（JVMを設定する上記の原理に参加するために、32Gよりも一般的に配置された複数しない）が設けられているよりも多くのスペースを占有しないため、約500Gの全容量の指標であれば、ポイントこと約16までの用紙サイズ;もちろん、考慮に好ましくは2の原則を取ります。
ノードの数よりはるかに高い、あまりにも多くの断片の数は、ノード障害後のノード上の複数のスライスにつながる可能性がある場合2.ノードの数を考慮し、ノードが時々あっても、一般的に単一の物理マシンであります同じの複数のコピーを維持することは、データの損失につながる可能性があり、クラスタを回復することはできません。したがって、フラグメントの一般設定数は、ノードの回以上の数ではありません。
五、マッピングモデル
1.ネストされたか、親/子の使用は避け、実行することはできません。ネストされたクエリが遅い、親/子問合せ遅く、ネストされたクエリよりも百倍遅く、マッピングすることは（または、テーブル設計が大きな幅の比較を使用する設計段階で取得することが可能ですスマートデータ構造）、マッピング親子関係を使用しないでください。
2.フィールドを確保するために、ネストされたフィールド、ネストされたフィールドを使用する必要がある場合は、あまりにも多くのことができない、現在のESのデフォルトの制限は50です。参考：
index.mapping.nested_fields.limit：50
文書のために、ネストされた各フィールドには、ドキュメントの数の劇的な増加を可能にする、クエリの効率に影響を与え、特に効率が参加する別のドキュメントを生成しますので。
同様に、フィールドの数を制御する必要、フィールドサービスは使用しないではなく、インデックスを行う; 3.クラスタの崩壊につながる、動的マッピングを増加させる、（キー）フィールドの動的な値を使用しないでください。インデックスフィールド、深さマッピングタイプ、インデックスフィールド、ESのパフォーマンスの最適化が最も重要であるの数を制御します。以下は、デフォルトの設定のいくつかの深さをマッピングし、フィールドの数のESです。
index.mapping.nested_objects.limit：10000
index.mapping.total_fields.limit：1000
index.mapping.depth.limit：20
第六に、インデックスの最適化設定
number_of_replicasはコピーが書き込み性能を向上させるために提供されていない一方で、リフレッシュ間隔の期間を閉じることで、0に設定しながら、1 REFRESH_INTERVALは、-1に設定します。
2. index_buffer_size設定がパーセンテージとして設定することができる変更し、また、試験のサイズがクラスタのサイズに応じて異なる設定を行うことができ、特定のサイズに設定することができます。
indices.memory.index_buffer_size：10％（默认）
indices.memory.min_index_buffer_size：48メガバイト（默认）
indices.memory.max_index_buffer_size
3.トランスログ関連の設定を変更します。
。メモリからの制御データの動作周波数のハードドライブに、ディスクIOを低減します。sync_interval時間を大きく設定することができます。
index.translog.sync_interval：5S（デフォルト）
データブロックのサイズを制御tranlogに含まB.は、閾値の大きさに達し、Luceneインデックスファイルにフラッシュであろう。
index.translog.flush_threshold_size：512メガバイト（默认）
使用の4 _idフィールドは、IDのためのバージョン管理を避けるために、可能な限りのカスタム_idとして避けるべきである; ESは、主キーを行うために使用するデフォルトのID生成戦略やデジタルIDのタイプをお勧めします。
取得されていない場合は、元の文書の内容に格納_source、; 5. _allフィールドと_sourceフィールドを使用し、シーンや必要性に注意を払う必要があり、_allフィールドは、フルテキスト検索を行うのは簡単、インデックスフィールドのすべてが含まれていないこのような要求ならば、あなたは無効にすることができます原稿データを求め、設定_sourceフィールドにプロパティを除外し、含むことによって定義することができます。
6.ビジネスによると、分析し、not_analyzed合理的な設定のインデックスプロパティの使用に関係なくかどうかの単語や単語の、フィールドをコントロールする必要があります。not_analyzed設定する場合GROUPBYフィールドは、クエリまたはクラスタリングの効率を向上させるために、必要です。
七、クエリの最適化
クエリ1. QUERY_STRING以上またはクエリのフィールドをmulti_match、遅くなります。マッピング段階では問い合わせの新しい分野で、新しいフィールド、multi_matchに複数列のインデックスのcopy_toプロパティ値を使用することができます。
2.特に、実際には、クエリの日付フィールドは、今でクエリキャッシュを存在していないので、あなたは、ビジネスの観点から、それは本当に必要な今、結局のところ、大幅にクエリの効率を向上させることができ、クエリキャッシュの使用がある使用することができます。
3.クエリの結果セットのサイズは任意に大きな途方もなく値を設定することができない内部のESは、サイズ指定されたデータの結果セットを置くためにデータ構造を作成する必要があるため、query.setSize Integer.MAX_VALUEのように設定することはできません。
4.無痛＆experssionsエンジンを選択し、使用したい場合は、最後の手段として、スクリプトを使用しないようにしてください。限り、現在のスクリプトとして実行されるスクリプトが実行されていないスクリプトを使用してクエリが、タイムアウトのES制御がないため、無限ループ（次のエラーの例を）持っていないが、制御が戻るに注意を払う必要があります一度、クエリがブロックされています。
5.メモリ、CPUの消費につながる集計クエリ、によってレベル深すぎグループ、あまりにも深いレベルを避け、それはプログラムを通じて、ビジネスサービス層を組み立てることが推奨され、パイプラインの方法も最適化することができます。
6.性能を改善するために、多重化前のインデックスデータAGGの方法を：別の範囲集計などの用語集計によって、年齢グループの目標に従ってグループ化されるようである：若年（14歳未満）ユース（14-28）、中年（29から50 ）古い（51以上）は、事前にデータを分類し、フィールドインデックスAGE_GROUP時に提供されてもよいです。だから、上のAGE_GROUPフィールドで、年齢の範囲の集計によるといたしません。
7.キャッシュのセットアップおよび使用：
a.QueryCache：ESクエリは、クエリキャッシュを使用してフィルタクエリを使用して、ビジネスシーンよりフィルタリングクエリあれば、検索を高速化するために、大きく設定querycacheお勧めします。
indices.queries.cache.size：10％（デフォルト）は、パーセンテージとして提供することができる、それは、256メガバイトのように、特定の値に設定してもよいです。
falseに設定する：もちろん、あなたがクエリキャッシュを無効にすることができindex.queries.cache.enabledにより、（デフォルトで有効になっています）。
b.FieldDataCache：ソートやクラスタリング場合、フィールド・データ・キャッシュは、頻繁に使用され、したがって、フィールド・データ・キャッシュのサイズでは、複数のクラスタまたは順序付けシナリオの場合に必要である、によって
indices.fielddata.cache.size 30％または10ギガバイトの特定の値セット。シーンやデータが頻繁に変更された場合でも、キャッシュローダーのオーバーヘッドが特に大きいため、キャッシュは、良いアイデアではありませんし。
c.ShardRequestCacheは：照会要求を開始した後、各スライスは、コーディネータノードによって積分結果、連携ノード（調整ノード）に結果を返します。
需要があれば、あなたが開くように設定することができます。設定することによって、
index.requests.cache.enable：真がオープンします。
しかし、シャード要求キャッシュキャッシュのみhits.total、集計、データの提案の種類、およびヒットのコンテンツをキャッシュしません。また、設定することができます
indices.requests.cache.size :. 1％ （デフォルト）キャッシュ領域のサイズを制御します。