著者：明-YI世界
背景
今日の世界では、すべての人生の歩みは、データ、データの抽出、変換、保存、維持、管理・分析の必要性のこれらの膨大な量の所望の結果を得るためには、日々発生した大量のデータを持っています。これは、これまで、これらの機能を実現する唯一のメカニズムに基づいて、処理ツール、データベース、分散ビッグデータツールを達成するための通常の能力と並列処理アーキテクチャを超えて、すでにあります。上記のようにElasticsearch応答は、ほとんどのデータストレージエンジンユースケースの最も人気のあるオープンソースの一つです。
Elasticsearchは、分散ファイルシステムと検索エンジン、フォールトトレラントおよび高可用性機能です。その検索機能を最大限に活用するためには、Elasticsearchが正しい設定する必要があります。
シンプルなデフォルトの設定では、すべて実際のビジネスシナリオには適していません。戦闘開発運用・保守、独自のビジネスシナリオを達成するためにパーソナライズされたフィットクラスタ構成は、クラスタのパフォーマンスを最適化する唯一の方法です。この記事のコレクション乾貨物構成のパフォーマンスを向上させる集中的なサーチElasticsearchクラスタを強調し、実際のビジネスシナリオ、。
1、インデックスレベルの割り当てを最適化する
5つの主要なインデックスの断片化及びコピー、7.xのバージョン1およびそれ以降のマスタが存在する以前Elasticsearchにおいて、デフォルトでバージョン6.xおよび。この構成では、すべてのビジネスシナリオには適用されません。スライスの構成は、安定性と有効性の指標を維持するために正しく設定する必要があります。
1.1、フラグメントサイズの
フラグメントサイズは、検索クエリのために非常に重要です。
あなたがインデックスにあまりにも多くの断片を割り当てる場合は一方で、Luceneのセグメントが増加し、オーバーヘッドが生じ、非常に小さくなります。複数のクエリが同時に、多くの小さな断片が、スループットを照会する場合も減少します。
一方、あまりにも多くの断片化は、パフォーマンスの低下検索と回復時間が長くなる原因になります。
Elasticsearchの公式は、フラグメントサイズは約20ダオ40ギガバイトする必要があります示唆しました。
たとえば、あなたが計算する場合、インデックスは、インデックスに割り当てられた9-15プライマリスライスすることができ300ギガバイトのデータを格納しています。
クラスタサイズは、クラスタを使用して、均等にクラスタノード間で分散スライスにこのマスタースライスのインデックス10を割り当てるように選択することができ、10個のノードがあると仮定されます。
1.2、シーンデータを書き込んダイナミック持続性
などのクラスタElasticsearchに書き込まれたデータの連続ストリームがある場合：インターネットのリアルタイムデータは、クローラESクラスタ書かれています。時間ベースのインデックスは、より簡単にインデックスを維持するために使用すべきです。
スループットは、データストリームに時間とともに変化する場合、適切に動的インデックス拡張データの構成を変更する必要があります。
だから、どのように異なる時間ベースのインデックスに文書のすべてを照会するには？答えは別名です。その他のインデックスは、別名に配置することができ、およびエイリアス検索クエリは、ちょうど単一のインデックスにしたいと思います。
もちろん、良いバランスを維持する必要があります。ポンダー注：エイリアスに書かれているどのくらいのデータの？あまりにも多くの小さな書き込み性能指数は、別名にマイナスの影響を与えることになります。
たとえば、インデックスの単位で、毎週または毎月のバランスで考慮ビジネスシナリオを組み合わせる必要がありますか？
月次ベースのインデックスは、インデックスがあまりにも多くの負のパフォーマンスの問題につながることがインデックスに週単位で同じデータバインドされているため、最適なパフォーマンスを、推奨されている場合。
1.3、インデックスは、並べ替え
注：インデックスソートメカニズムは6.X版のみの機能です。
新しいインデックスを作成するときElasticsearchは、ソートされた各スライスのセグメントを構成することができます。デフォルトでは、Luceneには、任意の並べ替えを適用しません。index.sort。*各セグメント内の文書をソートするために使用されるべきフィールドを定義します。
使用例：
PUT /twitter
{
"settings" : {
"index" : {
"sort.field" : "date",
"sort.order" : "desc"
}
},
"mappings": {
"properties": {
"date": {
"type": "date"
}
}
}
}目的：インデックス・ソートはElasticsearchの検索性能を最適化するために、1つの非常に重要な方法です。
方言：1つまたは複数のフィールドを指定されたソートを書いている時点でのメカニズムをソートインデックスは、大幅検索のパフォーマンスが向上します。
図2に示すように、スライスレベルの最適化の
基礎となる基本的な読み書きユニットのフラグメンテーション並列に読み書きするように、断片化インデックスの目的は、優れた分割されます。プロセスを書くことは、マスタースライス、スライスマスターコピーの書き込みを書き込み、正常に断片書き込むことができます。
フィルムの分のコピーは、高可用性クラスタと読んでスループットを向上させるために表示されます。
断片化が主要な考慮事項であるどのように多くのノード最適化断片化、断片の大きさ、。フラグメントのコピーは、ハードウェア条件が許すならば、あなたは慎重にスライスコピーの数を増やすことができ、検索のスループットを拡張することが重要です。
フラグメントの理想的な数は、1.5〜3倍の数のノード番号であるノードの数「に依存すべきである：良好な出発点は、「深い理解elasticsearchは」強調」、キャパシティプランニング断片を割り当てることです。
コピーシート分布フラクタル式：MAX（max_failuresに、CEIL（num_nodes /）num_primaries） - 1）。
あなたはmax_failuresにまで対応できるようにしたい場合は、num_nodesクラスタノード、num_primariesの合計主なフラグメントを持っている場合は、ノードに障害が発生し、その後、上記の式の値のコピーのための数：どのように動作します。
総合：シンプルノードと式の数、断片のコピー数以下の通り：
* =（コピー+1の数）フラグメントノードの所望の大きな数。
3、Elasticsearch全体的なレベルの構成
Elasticsearchクラスタを構成する場合、最も重要な検討事項の一つはElasticsearchが熱い領域をインデックス化することができますので、ファイルシステムキャッシュに利用できるメモリの少なくとも半分を確保することであるが、物理メモリ内に残っています。
クラスタの設計でも、物理的な空間使用可能なヒープを検討すべきです。Elasticsearchは割り当てが親指の良いルールで使用可能なヒープ領域の断片化、に基づいて、最大20枚のスライス/ GBでなければなりませんお勧めします。
例えば、30ギガバイト・スタック・ノードは、クラスタの良好な状態を維持するために、600枚のスライスの最大値であるべきです。
以下のように、1つのノードに格納されている表現することができる効率は通常20〜40 GBのクラスタサイズで見ているので、（断片サイズのGB単位）：ノードが= 20（GBヒープサイズ単位）ディスク容量をサポートすることができますスライス間の、ストレージ・スペースの最大16ギガバイト（20であり、最大12 TBのディスク容量ノードヒープ領域に利用可能となるように16 12.8TB 40 =）。
ボーダーの意識は、将来の拡張の優れたデザインと操作の準備に役立ちます。
多くの設定は、実行時と同様に初期の段階で設定することができます。
実行時に変更することができ、必須であるものと改正することはできませんどのような構成を理解するために、より優れた検索パフォーマンスのためにElasticsearchインデックスとクラスタ自体を構築する場合。
3.1動的セット
、1履歴インデックスデータが読み取り専用状態を設定します。
インデックスは、履歴データの書き込み動作が格納されていない場合は、時間の動的インデックスの実行フェーズに基づいて、毎月の指数は、これらのインデックスの検索性能を向上させるために、読み取り専用モードに設定することができます。
6.Xの実際の配置後に読み取り専用インデックス：
PUT /twitter/_settings
{
"index.blocks.read_only_allow_delete": null
}2、読み取り専用状態インデックス、マージセグメント。
インデックスが読み取り専用に設定されている場合、セグメントの数を減らすために、セグメントマージ操作により強制的にすることができます。
各フラグメントは、セグメントの数と大きさに依存しているので、合わせてセグメントの最適化は、より優れた検索パフォーマンスにオーバーヘッドをリードします。
注1：それは非常に大きなセグメント（セグメント当たり>を5Gb）につながるので、読み取りおよび書き込み用のセグメントインデックスをマージしないでください。
注2：これは非常にリソース集中型の操作であるため、この操作は、オフピーク時間の間に実行されなければなりません。
セグメントマージ操作の戦闘モード：
-X POSTカールは"localhost：？9200 / kimchy / _forcemerge only_expunge_deletes =偽＆max_num_segments = 100 =＆trueにフラッシュ"
好みの最適化キャッシュ使用率を使用して3は、
そのようなファイル・システム・キャッシュ、キャッシュ要求またはクエリキャッシュなどの検索性能を、向上させることができ、複数のキャッシュを持っています。
しかし、これらすべてのキャッシュが同じ要求に基づいて、デフォルトのルーティングアルゴリズムとクラスタ連続動作の1つまたは複数のコピーを持っている場合は二回、両方の要求が異なるスライスに行くことを意味し、ノードレベルで維持されています防ぐために、ノード・レベルのキャッシュのコピー。
同様の要求のいずれかによって実行さ検索アプリケーションのユーザが共通しているので、指標部狭いサブセット解析、またはセッション識別子の優先値を使用して、現在のユーザの嗜好を取得するために、例えばキャッシュを最適化するために使用することができます。
好ましい具体例：
GET /_search?preference=xyzabc123
{
"query": {
"match": {
"title": "elasticsearch"
}
}図4は、交換を禁止することは
、安定性を確保するために、各ノードにExchangeを無効にすることができ、そしてすべてが交換をコストで避けるべきです。それは数分ではなく、ミリ秒ガベージコレクションにつながる可能性がある、とさえクラスタから切り離された接続ノードに遅い応答につながる可能性があります。
Elasticsearch分散システムにおいて、終端ノードのオペレーティングシステムをより効率的にするように。Bootstrap.memory_lockはそれを無効にするにはTrueに設定することができます。
Linuxのシステム・レベルの設定：
`sudoをするswapoff -a``
Elasticsearchプロファイルelasticsearch.yml構成：bootstrap.memory_lock: true
図5は、リフレッシュ間隔REFRESH_INTERVAL増加
デフォルトのリフレッシュ間隔は1秒です。これはElasticsearchは毎秒1つのセグメントを作成強制します。実際のサービスでは、リフレッシュ間隔は、例えば、用途に応じて増加する必要があります。30秒に増加しました。
この後、30代が大きく、将来のセグメント圧密圧力を減少させる第2のリフレッシュに比べて、大きなセグメントを生成しました。最終的には、検索クエリの書き込み性能とより安定を強化します。
リフレッシュ間隔戦闘を更新します。
PUT /twitter/_settings
{
"index" : {
"refresh_interval" : "1s"
}
}図6は、max_thread_count提供
index.merge.scheduler.max_thread_countのデフォルト設定である
（1、Math.min（4、Math.max AvailableProcessors（）/ 2）。Runtime.getRuntime（））
が、これはSSDの構成に適用されます。HDDの場合は、1に設定する必要があります。
戦闘：
curl -XPUT 'localhost:9200/_settings' -d '{
"index.merge.scheduler.max_thread_count" : 1
}
図7は、動的割り当ては、断片化を禁止する
時々 、elasticsearchクラスタの断片を再調整します。これは、検索のパフォーマンスが低下することがあります。
生産モードでは、所望であれば、どれにcluster.routing.rebalance.enableリバランスによって提供することができます。
PUT / _cluster /設定
{
"transient" : {
"cluster.routing.allocation.enable" : "none"
}
}典型的なアプリケーションで含むシナリオ：
クラスタの一時的な再起動、削除ノードと、
ノードをアップグレードクラスタ・バイ;あなたはノードをオフにすると、割り当てプロセスは、直ちに、その結果、クラスタ内の他のノードにノード上でスライスをコピーしようとしますIOの多くを無駄にすること。ノードをシャットダウンする前に、このような状況を回避するために割り当てを無効にします。
図8に示すように、おおよその日付キャッシュ使用の完全な効果
マッチングの範囲が変更されているので、通常、日付フィールドにキャッシュされていないクエリは、現在、使用されています。
しかし、ユーザーエクスペリエンスは、一般的に許容可能なおおよその日付に切り替え、クエリキャッシュによってもたらされるメリットをより有効に活用することができます。
次のように戦闘は以下のとおりです。
GET index/_search
{
"query": {
"constant_score": {
"filter": {
"range": {
"my_date": {
"gte": "now-1h/m",
"lte": "now/m"
}
}
}
}
}
}3.2初期設定
検索性能を高めるために、複数のフィールドを持つ1、
よりターゲットを絞っQUERY_STRINGまたはmulti_matchクエリフィールドを取得遅くなります。
フィールドは、単一のフィールドをコピーする指標値である場合、従来技術の複数の検索速度を向上させます。
いくつかのフィールドでは、頻繁に照会し、機能をElasticsearchためにコピーを使用してください。
例えば、車のブランド名、エンジンのバージョン、モデル名と色のフィールドは、命令のマージにコピーすることができます。これは、これらの分野における検索クエリのパフォーマンスを向上します。
PUT movies
{
"mappings": {
"properties": {
"cars_infos": {
"type": "text"
},
"brand_name": {
"type": "text",
"copy_to": "cars_infos"
},
"engine_version": {
"type": "text",
"copy_to": "cars_infos"
},
"model ": {
"type": "text",
"copy_to": "cars_infos"
},
"color": {
"type": "text",
"copy_to": "cars_infos"
}
}
}
}2は、特定のノードに割り当てられたスライス設定し
、実際のビジネス上の問題がしばしば発生したビジネスシナリオを：非平衡分布の断片化を設定する方法を、新しいノード構成があり、過去にかかわら乗算ポイント、非常に高いのですか？
上のシャード配信ノードは、一般的に、ESによって自動的に決定されます。以下の条件は、分配動作トリガ：
1）新しいインデックス生成
インデックス削除）2
3）のCCスライス追加
4）イニシエータノード等化されたデータの減少
ESのパラメータのリストを提供するこのセクションでは、制御ロジックの一つの詳細をそれらは、割り当てられた重みを割り当てる複数のスライスのハードウェアノードを有する異種クラスターの場合。
重みを割り当てるために
cluster.routing.allocation.balance.shard値を設定するには、デフォルト値は0.45fです。
値ノードレベルスライスイコライザやすく大きいです。
戦闘：
PUT _cluster/settings
{
“transient” : {
“cluster.routing.allocation.balance.shard” : 0.60
}
}図3は、サイズヒューズメモリの比調整
クエリ自体は、応答遅れに大きな影響を与えるであろう。、不安定な状態でElasticsearchクラスタ内のクエリと結果の時にヒューズをトリガしないようにするためには
、クエリの複雑さに応じて、あなたのJVMのヒープサイズに合うようにindices.breaker.total.limitされます。この設定のJVMヒープのデフォルト値は70％です。
PUT /_cluster/settings
{
"persistent" : {
"indices.breaker.fielddata.limit" : "60%"
}
}回路遮断器は、好ましくは、比較的保守的なポイント値が設けられています。
著者「弾性ソースコード解析、」チャオはElasticsearch 7.0がindices.breaker.total.use_real_memory設定項目が追加されていること:.」を指摘し、現在のメモリの状態をより正確に分析することができ、この構成は少し性能の損失を追加しますがOOMを防ぐために、時間内に発生しますが、 JVMのメモリ使用量が増加し、ノードの保護を強化する。」ことができます
4、特定の検索シーン、検索スレッドプールの設定を増やし
、デフォルトでは、メインユースケースをelasticsearch検索することです。並行性を取得高めるために必要な場合には、それは、検索設定のためのスレッド・プールを増やすことができ、同時に、あなたはCPUノード上のコアの数に基づいて、インデックスのためにどのくらいの裁量スレッドプールを減らすことができます。
例：プロファイルは、以下を追加しelasticsearch.yml変更：
thread_pool.search.queue_size: 500
#queue_size允许控制没有线程执行它们的挂起请求队列的初始大小。5、オープン適応レプリカの選択は、
適応レプリカの選択をオープンする必要があります。リクエストは、最速の応答ノードにリダイレクトされます。
データの複数のコピーがある場合、あなたはelasticsearchの標準セットを使用することができますフラグメントの応答時間、サービス時間、およびキューサイズのコピーを含む各ノードによるデータの最良のコピーを選択するために、適応型コピーの選択に言及しました。
これは、スループットを向上させ、大規模なアプリケーションのレイテンシのクエリー検索を減らすことができます。
この設定はデフォルトで、オープンな戦闘方法で無効になっています。
PUT /_cluster/settings
{
"transient": {
"cluster.routing.use_adaptive_replica_selection": true
}
}4まとめ
Elasticsearch多くのクラスタ構成設定の応答遅れは、検索性能を向上させることができます。これらは氷山の一角に過ぎません。
この一点のような記事は、サポートへの感謝を覚えておくように、奇妙な交流へようこそ！