Elasticsearchの基礎認識と最適化の提案
5741 ワード
最近インデックス関連の最適化テストをしています.ついでにテストと効果を記録します.
1:最適化mappingは主にdoc_を含むvalues,index,norms,typeのkeywordとtext//効果は明らかです
doc_valuesプロパティは、データをディスクにシーケンス化し、インデックス構造をより緊密にするために使用されます.
デフォルトはtrue、binaryタイプはfalse
欠点:追加ディスク消費の発生
indexプロパティは、データインデックスの有無、不要なデータのインデックス取得に使用されます.
デフォルトはtrue
欠点:インデックスなしのオブジェクトに対して条件フィルタとクエリーを使用できません.
normsプロパティ
集約する必要のないプロパティはfalseに設定できます
keywordとtextはStringの拡張で、5 X後にこの2つの属性を使用します
keyword属性は、データに対して逆組みをしない従来のString:{"index":"not_analyzed"}であり、textはデータに対して分詞逆組みを行う
効果:ディスク容量を大幅に削減
2:クエリーの_を無効にするall,合理的なshardスライス数を設定し,segment段落を用いて//効果を明らかにする
_allデフォルトで開くと、すべてのフィールドがここにコピーされ、ディスクの使用とクエリーのパフォーマンスに影響します.
インデックス作成時に「_all」:{「enabled」:false}を追加
shard
ShardはLuceneインスタンスであり、完全な検索エンジンです.
スライス数が多すぎると、検索時に比較的多くのファイルが開き、複数のサーバ間の通信コストが増加します.
スライス数が少なすぎると、単一のスライスインデックスが大きすぎるため、検索速度も遅くなります.
単一スライスは最大10 G-20 G程度のインデックスデータを格納することを推奨し、各インスタンスのインデックススライス数は1-2個程度を推奨し、できるだけクラスタのすべてのノード
いずれもスライス数が一致し、スライス数が異なることによるインスタンスの負荷が大きすぎず、マージを待つ時間が長くなる.
shardコピー
レプリカの使用の利点:データバックアップにより、大きなインデックスのクエリー効率が向上し、レプリカが1～2個程度であることを推奨します.レプリカが多すぎると、マージ時間が遅延し、ディスクの使用率が向上し、価格比が高くなりません.
segments
各スライスには複数のsegmentが含まれ、各segmentは逆インデックスである.クエリーの場合、すべてのsegmentクエリー結果がまとめられ、最も最終的なスライスクエリー結果が返されます.segmentが多ければ多いほど、メモリにロードされるsegmentが多ければ多いほど、segment memoryを占有するほど、クエリーのパフォーマンスが低下する可能性があります.そのため、小さなsegmentを統合し、segment数を減らし、検索するsegment数を高めてクエリーの効率を高めるべきです.
インデックスを作成するとき、elasticsearchはドキュメント情報をメモリbugfferに書き込み、elasticsearchは定期的にflush操作を実行し、segmentをディスクに永続化し、インデックスが大きいほどsegmentが多くなり、クエリー効率が低下します.segment作成はキャッシュに書き込むだけなので、この時期はシステムが異常にデータを失いやすく、手動で実行することができます.flushは段落の持続化を実現する
----索引段落文のマージ
curl -XPOST 'http://localhost:9200/{_index}/_forcemerge?max_num_segments=1'
----各esインスタンスは32 Gのjvmメモリを超えないでください
----------------------以上のポリシーは、多くのクエリー効率を向上させることができます.
3:メモリ交換を避けるbootstrap.mlockallをtrueに設定して実装//意味は大きくありません.テストデータセット1000 wが大きくないのか、実装できません.
ここにいるよymlに追加
bootstrap.memory_lock: true
1./etc/security/limits.confは、Esがユーザ(例えばxxx)を起動するmemlock xxxソフトウェアmemlock unlimited xxx hard memlock unlimited 2を制限しない.変更:/etc/sysctl.conf
vm.swappiness=0
------更新時間を遅延または無効にするcurl-XGET'localhost:9200/novehicle-new/settings' -d '{"refresh_interval": -1}'
4:queryの最適化、クエリーのqueryは必要なフィールドを返し、使用しないフィールドは戻り値のサイズを小さくする
5:ログ出力レベルを最適化し、tranceをinfo//に変更するとあまり効果がないようです
6:ルーティング最適化//まだテスト中
ESでいうルーティングはIPネットワークとは異なり,Tagに似たものである.ドキュメントを作成するときは、フィールドを使用してドキュメントにルーティング属性のTagを追加できます.ESの内在的なメカニズムは,同じルーティング属性を持つ文書を決定し,主スライスでもレプリカでも必ず同じスライスに割り当てられる.これにより、クエリ中に関心のあるルーティング属性が指定されると、ESは、複雑な分散型協同作業を回避し、対応するスライスが存在するマシン上で直接検索することができ、ESのパフォーマンスが向上する.これと同時に、機器1にルーティング属性Aの文書が存在し、機器2にルーティング属性Bの文書が存在すると仮定すると、私が照会する際にターゲットルーティング属性Aを指定すると、機器2が故障して麻痺しても機器1に大きな影響を及ぼさないため、災害時の照会にも解決策が提案される.ルーティングとは本質的にバケツ操作である.もちろん、クエリーでは複数のルーティング属性を指定することもできますが、メカニズムは大きく異なります.
7:クエリーキャッシュの追加、およびクエリー//テストの前処理
8:ディスクキャッシュによる取得の向上
ディスクの検索速度が遅すぎて、リアルタイム性の高いシーンではディスクの検索を使用できません.インデックス処理では、インデックスファイルのリフレッシュをキャッシュにロードする必要があります.Elasticsearchはデフォルトで1 sの間隔です.つまり、リアルタイムで検索することに相当し、Elasticsearchも個別の/_を提供します.reflushインタフェースは、ユーザーが1 s間隔に満足していない場合は、検索が表示されることを保証するためにインタフェースをアクティブに呼び出すことができます.
POST/{_index}/_refresh
一般的には/_を通りますsettingsインタフェースまたはtemplateをカスタマイズする方法で、refresh_を大きくします.intervalパラメータ:
9:translogの制御
refreshがファイルシステムキャッシュに書かれているだけである以上、最後のステップが実際のディスクに書き込まれるのは何によって制御されるのでしょうか.その間にホストエラー、ハードディスク(HDD)障害などの異常が発生した場合、データは失われませんか?ここで、実際にはElasticsearchは別のメカニズムを提供して制御します.Elasticsearchもメモリbufferにデータを書き込むとともに、treanslogのログを別途記録しています.すなわち、メモリデータがbufferに入ると、translogレコードが別途記録される.
10:不要なインデックスを動的に閉じる//あまり意味がなさそう
インデックスのデフォルトはopen状態で、open状態のインデックスはメモリを消費します.不要なインデックスに対してcloseを使用できます.
curl -XPOST 'http://localhost:9200/{_index}/_close'
11:索引削除の注意点//テスト中
ドキュメントが更新されると、古いバージョンのドキュメントは削除としてマークされ、新しいバージョンのドキュメントは新しいセグメントにインデックスされます.ドキュメントの異なるバージョンはクエリーに一致するかもしれませんが、古いバージョンは結果から削除されます.
クエリーに参加するか、検索効率に影響します.
削除ドキュメントはes時にすぐに削除するのではなく、先に生成する.delファイル、esは検索時にファイルが削除されたかどうかを判断してフィルタリングするので、検索効率が低下し、手動でドキュメントの削除を実行できます
curl -XPOST 'http://localhost:9200/{_index}/_forcemerge?only_expunge_deletes=true'
12:大量のデータをインポートする場合、レプリカを0に設定し、その後、動的にレプリカを追加//効率が高い
大量のインデックスをインポートすると、レプリカの数が設定され、esはレプリカの同期を同時に開き、システムリソースを消費し、プライマリとセカンダリ間の通信を追加する必要があります.
新規インデックスYesコピーを0に設定
----コピー数の設定
curl -XPOST 'http://localhost:9200/{_index}/_settings' -d
'{"index":{"number_of_replicas":1}}'
13:使用可能なメモリの少なくとも半分をファイルシステムにキャッシュする.
14:リンクを回避し、ネストするとクエリーが数倍遅くなり、直接関係するとクエリーが数百倍遅くなるので、同じ質問がリンクのない非規範的な回答で速度を上げることができます.
15:最小で十分な数値タイプを使用
byte,short,integer,long
half_float,float,double
16:インデックス・バッファ・サイズ
17:esのスレッドプールの最適化
threadpool.index.type: fixed
threadpool.index.size: 100
threadpool.index.queue_size: 500
18:デフォルトCMSの代わりにG 1ゴミ回収機構を採用
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"
19:無駄なキャッシュをクリア
#キャッシュタイプはSoft Referenceに設定されており、メモリが不足している場合にのみ回収されます
index.cache.field.max_size: 50000
index.cache.field.expire: 10m
index.cache.field.type: soft
1:最適化mappingは主にdoc_を含むvalues,index,norms,typeのkeywordとtext//効果は明らかです
doc_valuesプロパティは、データをディスクにシーケンス化し、インデックス構造をより緊密にするために使用されます.
デフォルトはtrue、binaryタイプはfalse
欠点:追加ディスク消費の発生
indexプロパティは、データインデックスの有無、不要なデータのインデックス取得に使用されます.
デフォルトはtrue
欠点:インデックスなしのオブジェクトに対して条件フィルタとクエリーを使用できません.
normsプロパティ
集約する必要のないプロパティはfalseに設定できます
keywordとtextはStringの拡張で、5 X後にこの2つの属性を使用します
keyword属性は、データに対して逆組みをしない従来のString:{"index":"not_analyzed"}であり、textはデータに対して分詞逆組みを行う
効果:ディスク容量を大幅に削減
2:クエリーの_を無効にするall,合理的なshardスライス数を設定し,segment段落を用いて//効果を明らかにする
_allデフォルトで開くと、すべてのフィールドがここにコピーされ、ディスクの使用とクエリーのパフォーマンスに影響します.
インデックス作成時に「_all」:{「enabled」:false}を追加
shard
ShardはLuceneインスタンスであり、完全な検索エンジンです.
スライス数が多すぎると、検索時に比較的多くのファイルが開き、複数のサーバ間の通信コストが増加します.
スライス数が少なすぎると、単一のスライスインデックスが大きすぎるため、検索速度も遅くなります.
単一スライスは最大10 G-20 G程度のインデックスデータを格納することを推奨し、各インスタンスのインデックススライス数は1-2個程度を推奨し、できるだけクラスタのすべてのノード
いずれもスライス数が一致し、スライス数が異なることによるインスタンスの負荷が大きすぎず、マージを待つ時間が長くなる.
shardコピー
レプリカの使用の利点:データバックアップにより、大きなインデックスのクエリー効率が向上し、レプリカが1～2個程度であることを推奨します.レプリカが多すぎると、マージ時間が遅延し、ディスクの使用率が向上し、価格比が高くなりません.
segments
各スライスには複数のsegmentが含まれ、各segmentは逆インデックスである.クエリーの場合、すべてのsegmentクエリー結果がまとめられ、最も最終的なスライスクエリー結果が返されます.segmentが多ければ多いほど、メモリにロードされるsegmentが多ければ多いほど、segment memoryを占有するほど、クエリーのパフォーマンスが低下する可能性があります.そのため、小さなsegmentを統合し、segment数を減らし、検索するsegment数を高めてクエリーの効率を高めるべきです.
インデックスを作成するとき、elasticsearchはドキュメント情報をメモリbugfferに書き込み、elasticsearchは定期的にflush操作を実行し、segmentをディスクに永続化し、インデックスが大きいほどsegmentが多くなり、クエリー効率が低下します.segment作成はキャッシュに書き込むだけなので、この時期はシステムが異常にデータを失いやすく、手動で実行することができます.flushは段落の持続化を実現する
----索引段落文のマージ
curl -XPOST 'http://localhost:9200/{_index}/_forcemerge?max_num_segments=1'
----各esインスタンスは32 Gのjvmメモリを超えないでください
----------------------以上のポリシーは、多くのクエリー効率を向上させることができます.
3:メモリ交換を避けるbootstrap.mlockallをtrueに設定して実装//意味は大きくありません.テストデータセット1000 wが大きくないのか、実装できません.
ここにいるよymlに追加
bootstrap.memory_lock: true
1./etc/security/limits.confは、Esがユーザ(例えばxxx)を起動するmemlock xxxソフトウェアmemlock unlimited xxx hard memlock unlimited 2を制限しない.変更:/etc/sysctl.conf
vm.swappiness=0
------更新時間を遅延または無効にするcurl-XGET'localhost:9200/novehicle-new/settings' -d '{"refresh_interval": -1}'
4:queryの最適化、クエリーのqueryは必要なフィールドを返し、使用しないフィールドは戻り値のサイズを小さくする
5:ログ出力レベルを最適化し、tranceをinfo//に変更するとあまり効果がないようです
6:ルーティング最適化//まだテスト中
ESでいうルーティングはIPネットワークとは異なり,Tagに似たものである.ドキュメントを作成するときは、フィールドを使用してドキュメントにルーティング属性のTagを追加できます.ESの内在的なメカニズムは,同じルーティング属性を持つ文書を決定し,主スライスでもレプリカでも必ず同じスライスに割り当てられる.これにより、クエリ中に関心のあるルーティング属性が指定されると、ESは、複雑な分散型協同作業を回避し、対応するスライスが存在するマシン上で直接検索することができ、ESのパフォーマンスが向上する.これと同時に、機器1にルーティング属性Aの文書が存在し、機器2にルーティング属性Bの文書が存在すると仮定すると、私が照会する際にターゲットルーティング属性Aを指定すると、機器2が故障して麻痺しても機器1に大きな影響を及ぼさないため、災害時の照会にも解決策が提案される.ルーティングとは本質的にバケツ操作である.もちろん、クエリーでは複数のルーティング属性を指定することもできますが、メカニズムは大きく異なります.
7:クエリーキャッシュの追加、およびクエリー//テストの前処理
8:ディスクキャッシュによる取得の向上
ディスクの検索速度が遅すぎて、リアルタイム性の高いシーンではディスクの検索を使用できません.インデックス処理では、インデックスファイルのリフレッシュをキャッシュにロードする必要があります.Elasticsearchはデフォルトで1 sの間隔です.つまり、リアルタイムで検索することに相当し、Elasticsearchも個別の/_を提供します.reflushインタフェースは、ユーザーが1 s間隔に満足していない場合は、検索が表示されることを保証するためにインタフェースをアクティブに呼び出すことができます.
---POST /_refresh---
POST/{_index}/_refresh
一般的には/_を通りますsettingsインタフェースまたはtemplateをカスタマイズする方法で、refresh_を大きくします.intervalパラメータ:
--- refreshPUT /{_index}/_settings{ "refresh_interval": -1 }---PUT /{_index}/_settings{ "refresh_interval": "1s" }
9:translogの制御
refreshがファイルシステムキャッシュに書かれているだけである以上、最後のステップが実際のディスクに書き込まれるのは何によって制御されるのでしょうか.その間にホストエラー、ハードディスク(HDD)障害などの異常が発生した場合、データは失われませんか?ここで、実際にはElasticsearchは別のメカニズムを提供して制御します.Elasticsearchもメモリbufferにデータを書き込むとともに、treanslogのログを別途記録しています.すなわち、メモリデータがbufferに入ると、translogレコードが別途記録される.
10:不要なインデックスを動的に閉じる//あまり意味がなさそう
インデックスのデフォルトはopen状態で、open状態のインデックスはメモリを消費します.不要なインデックスに対してcloseを使用できます.
curl -XPOST 'http://localhost:9200/{_index}/_close'
11:索引削除の注意点//テスト中
ドキュメントが更新されると、古いバージョンのドキュメントは削除としてマークされ、新しいバージョンのドキュメントは新しいセグメントにインデックスされます.ドキュメントの異なるバージョンはクエリーに一致するかもしれませんが、古いバージョンは結果から削除されます.
クエリーに参加するか、検索効率に影響します.
削除ドキュメントはes時にすぐに削除するのではなく、先に生成する.delファイル、esは検索時にファイルが削除されたかどうかを判断してフィルタリングするので、検索効率が低下し、手動でドキュメントの削除を実行できます
curl -XPOST 'http://localhost:9200/{_index}/_forcemerge?only_expunge_deletes=true'
12:大量のデータをインポートする場合、レプリカを0に設定し、その後、動的にレプリカを追加//効率が高い
大量のインデックスをインポートすると、レプリカの数が設定され、esはレプリカの同期を同時に開き、システムリソースを消費し、プライマリとセカンダリ間の通信を追加する必要があります.
新規インデックスYesコピーを0に設定
----コピー数の設定
curl -XPOST 'http://localhost:9200/{_index}/_settings' -d
'{"index":{"number_of_replicas":1}}'
13:使用可能なメモリの少なくとも半分をファイルシステムにキャッシュする.
14:リンクを回避し、ネストするとクエリーが数倍遅くなり、直接関係するとクエリーが数百倍遅くなるので、同じ質問がリンクのない非規範的な回答で速度を上げることができます.
15:最小で十分な数値タイプを使用
byte,short,integer,long
half_float,float,double
16:インデックス・バッファ・サイズ
indices.memory.index_buffer_sizeは通常、JVMの0.1であり、512 MBまでのインデックスを処理するのに十分であることを保証します.17:esのスレッドプールの最適化
threadpool.index.type: fixed
threadpool.index.size: 100
threadpool.index.queue_size: 500
18:デフォルトCMSの代わりにG 1ゴミ回収機構を採用
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"
19:無駄なキャッシュをクリア
#キャッシュタイプはSoft Referenceに設定されており、メモリが不足している場合にのみ回収されます
index.cache.field.max_size: 50000
index.cache.field.expire: 10m
index.cache.field.type: soft