DUICUO

現在の場所： ホーム > 記事 > ElasticSearch の 43 個の使用ヒントを一気に読んでください

ElasticSearch の 43 個の使用ヒントを一気に読んでください

I. はじめに

この記事では、私の実務経験に基づいて、ElasticSearch の使い方に関する提案をいくつかご紹介します。他の記事は結論ばかりに重点を置きがちですが、この記事では提案の背後にある原理を説明し、使用例も紹介することで、「何」だけ知っていて「なぜ」を理解できないような表面的な理解を避けます。ご意見・ご指摘があれば、ぜひお聞かせください。

II. クエリ関連情報

キャッシュを最大限に活用する

  • シャードリクエストキャッシュ

Elasticsearch (ES) レイヤーのキャッシュ実装は、`IndicesRequestCache` クラスにカプセル化されています。キャッシュキーはクライアントリクエスト全体であり、キャッシュされたコンテンツは単一のシャードのクエリ結果です。主な機能は集計をキャッシュすることです。クエリ結果のキャッシュされたコンテンツには、主に集計、Hits.total、Suggestions などが含まれます。

シャードレベルのクエリはすべてキャッシュされるわけではありません。クライアントリクエストのサイズが0のクエリのみがキャッシュされます。キャッシュが妨げられるその他の条件としては、スクロール、Profile属性の設定、QUERY_THEN_FETCH以外のクエリタイプ、requestCache=falseの設定などがあります。さらに、「Now」を含む範囲クエリ（ミリ秒単位のためキャッシュは無意味）など、不確定要素を含むクエリや、スクリプトクエリでMath.random()などの関数を使用するクエリもキャッシュされません。

新しいセグメントがシャードに書き込まれると、以前にキャッシュされた結果ではシャード全体のクエリ結果を表現できなくなるため、キャッシュは無効になります。そのため、シャードの更新ごとにキャッシュはクリアされます。

  • ノードクエリキャッシュ/フィルターキャッシュ

Luceneレベルのキャッシュ実装はLRUQueryCacheクラスにカプセル化されており、デフォルトで有効になっています。このクラスは、セグメントのフィルターのサブクエリステートメントのクエリ結果をキャッシュします。

すべてのフィルタークエリがキャッシュされるわけではありません。小さなセグメントはすぐにマージされるため、クエリキャッシュは作成されません。セグメントがキャッシュされるには、10,000件以上のドキュメントを含み、かつシャード全体の3%以上を占めている必要があります（「キャッシュ」を参照）。

セグメントが結合されると、削除されたセグメントに関連付けられたキャッシュは無効になります。

01. クエリ コンテキストの代わりにフィルター コンテキストを使用します。

  • Filter ではスコアリングは実行されませんが、Must では実行されます。
  • フィルター クエリをキャッシュできるため、クエリのパフォーマンスが向上します。

肯定的な例:

 // 创建BoolQueryBuilder BoolQueryBuilder boolQuery = QueryBuilders.boolQuery(); // 构建过滤器上下文boolQuery.filter(QueryBuilders.termQuery("field", "value"));

反例:

 // 创建BoolQueryBuilder BoolQueryBuilder boolQuery = QueryBuilders.boolQuery(); // 构建查询上下文boolQuery.must(QueryBuilders.termQuery("field1", "value1"));

02. ドキュメントの詳細ではなく集計結果のみに焦点を当てる場合は、サイズを 0 に設定すると、シャードされたクエリ キャッシュが使用されます。

参考例:

 SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); // 添加聚合查询sourceBuilder.aggregation( AggregationBuilders.terms("term_agg").field("field") .subAggregation(AggregationBuilders.sum("sum_agg").field("field")) ); // 设置size为0，只返回聚合结果而不返回文档sourceBuilder.size(0);

03. 日付範囲クエリでは絶対時刻値が使用されます。

日付フィールドで「Now」を使用すると、一致する時刻は常に変化するため、通常はキャッシュされません。したがって、ビジネスの観点から「Now」が本当に必要かどうかを検討してください。可能な限り絶対時刻値を使用することで、相対時刻表現の解析を回避し、クエリキャッシュを活用してクエリ効率を向上させることができます。例えば、時間範囲クエリで「Now/h」を使用し、時間単位を指定すると、キャッシュされたデータに1時間以内にアクセスできます。

肯定的な例:

 SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); // 获取当前日期并格式化为绝对时间值LocalDateTime now = LocalDateTime.now(); DateTimeFormatter formatter = DateTimeFormatter.ISO_DATE; String currentDate = now.format(formatter); // 创建日期范围查询sourceBuilder.query(QueryBuilders.rangeQuery("date_field") .gte("2022-01-01") .lte(currentDate));
反例： SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); // 创建日期范围查询，使用相对时间值sourceBuilder.query(QueryBuilders.rangeQuery("date_field") .gte("now-7d") .lte("now"));

集計クエリ

04. 複数レベルのネストされた集計クエリを避けます。

集計クエリの中間結果と最終結果はメモリに保存されます。ネストが多すぎるとメモリ不足につながる可能性があります。

のように：

 SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); // 创建主要查询sourceBuilder.query(QueryBuilders.matchAllQuery()); // 创建第一层聚合TermsAggregationBuilder termAggBuilder1 = AggregationBuilders.terms("term_agg1").field("field_name1"); // 创建第二层聚合TermsAggregationBuilder termAggBuilder2 = AggregationBuilders.terms("term_agg2").field("field_name2"); termAggBuilder1.subAggregation(termAggBuilder2); // 创建第三层聚合TermsAggregationBuilder termAggBuilder3 = AggregationBuilders.terms("term_agg3").field("field_name3"); termAggBuilder2.subAggregation(termAggBuilder3); sourceBuilder.aggregation(termAggBuilder1);

05. ネストされたクエリの場合は、複合集計クエリ方式を使用することをお勧めします。

A、B、Cのような一般的な多次元Groupbyクエリでは、ネストされた集計はパフォーマンスが低下します。ネストされた集計は各バケット内のメトリクスを計算するように設計されているため、フラットなGroupbyでは多くの冗長な計算が発生します。さらに、Metaフィールドのシリアライズとデシリアライズのコストも非常に高くなります。このタイプのGroupbyをCompositeに置き換えることで、クエリ速度を約2倍向上させることができます。

肯定的な例:

 // 创建Composite Aggregation构建器CompositeAggregationBuilder compositeAggregationBuilder = AggregationBuilders .composite("group_by_A_B_C") .sources( AggregationBuilders.terms("group_by_A").field("fieldA.keyword"), AggregationBuilders.terms("group_by_B").field("fieldB.keyword"), AggregationBuilders.terms("group_by_C").field("fieldC.keyword") ); // 创建查询条件SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder() .query(QueryBuilders.matchAllQuery()) .aggregation(compositeAggregationBuilder) .size(0);

反例:

 // 创建Terms Aggregation构建器，按照字段A分组TermsAggregationBuilder termsAggregationA = AggregationBuilders.terms("group_by_A").field("fieldA.keyword"); // 在字段A的基础上创建Terms Aggregation构建器，按照字段B分组TermsAggregationBuilder termsAggregationB = AggregationBuilders.terms("group_by_B").field("fieldB.keyword"); // 在字段B的基础上创建Terms Aggregation构建器，按照字段C分组TermsAggregationBuilder termsAggregationC = AggregationBuilders.terms("group_by_C").field("fieldC.keyword"); // 将字段C的聚合添加到字段B的聚合中termsAggregationB.subAggregation(termsAggregationC); // 将字段B的聚合添加到字段A的聚合中termsAggregationA.subAggregation(termsAggregationB); // 创建查询条件SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder() .query(QueryBuilders.matchAllQuery()) .aggregation(termsAggregationA) .size(0);

06. 大規模な集計クエリを避ける。

集計クエリの中間結果と最終結果は両方ともメモリ内で処理されるため、大量のデータがあるとメモリ不足につながる可能性があります。

07. 高カーディナリティのシナリオでのネストされた集計クエリでは、BFS 検索を使用することをお勧めします。

集計はElasticsearchメモリ内で実行されます。集計操作にネストされた集計操作が含まれる場合、各ネストされた集計操作は、前のレベルの集計操作で構築されたバケットを入力として使用し、それぞれの集計条件に従ってバケットをさらにグループ化します。これにより、ネストのレベルごとに新しい集計バケットセットが動的に構築されます。高カーディナリティのシナリオでは、ネストされた集計操作により、ネストレベルに応じて集計バケットの数が指数関数的に増加し、最終的にはElasticsearchメモリを大量に消費し、OutOfMemoryError（OOM）が発生します。

Elasticsearchはデフォルトで深さ優先探索（DFS）を使用します。DFSはまず完全なツリーを構築し、不要なノードを削除します。幅優先探索（BFS）はまず最初のレベルの集約を実行し、その後、次のレベルの集約に進む前に不要なノードを削除します。

集計クエリにおいて、幅優先探索アルゴリズムを使用するには、各バケットレベルでドキュメントデータをキャッシュし、プルーニングフェーズ後にこれらのドキュメントをサブ集計に再読み込みする必要があります。そのため、幅優先探索アルゴリズムのメモリ消費量は、各バケット内のドキュメント数に依存します。多くの集計クエリでは、各バケット内のドキュメント数が非常に多く、集計には数千から数十万のドキュメントが含まれる場合があります。

しかし、バケット数は多いものの、バケットあたりのドキュメント数が比較的少ない場合、幅優先探索はメモリリソースをより効率的に利用し、より複雑な集計クエリを構築できます。バケット数は多くても、バケットあたりのドキュメント数が比較的少ないため、幅優先探索はメモリ効率に優れています。

参考例:

 searchSourceBuilder.aggregation( AggregationBuilders.terms("brandIds") .collectMode(Aggregator.SubAggCollectionMode.BREADTH_FIRST) .field("brandId") .size(2000) .order(BucketOrder.key(true)) );

08. テキスト フィールド タイプでは集計クエリを使用しないでください。

  • テキストのフィールドデータはメモリ使用量を増加させます。テキストを使用する必要がある場合は、代わりにキーワードを使用することをお勧めします。

09. 集約されたディープ ページネーション クエリに bucket_sort を使用することはお勧めしません。

Elasticsearch の高カーディナリティ集約クエリはメモリを大量に消費します。100 万カーディナリティを超える集約は、ノード メモリ不足や OutOfMemoryError (OOM) につながる可能性が高くなります。

bucket_sortはバケットソートアルゴリズムを使用します。このアルゴリズムのパフォーマンス上の問題は、ソートとページ区切りを実行する前に、すべてのドキュメントをキャッシュし、バケットをメモリに集約する必要があることに主に起因します。ドキュメント数とページ区切りの深さが増加すると、深いページ区切りの問題によりパフォーマンスが徐々に低下します。バケットソートはすべてのドキュメントを完全にソートする必要があるため、その時間計算量はO(NlogN)です（Nはドキュメントの総数）。

現在、Elasticsearchはページ区切りの集計において、複合集計（スクロール集計）のみをサポートしています。スクロールの仕組みはSearchAfterに似ています。集計時に複合キーが指定され、各シャードはこのキーに従ってソートされ、集計されます。すべてのドキュメントとバケットをメモリにキャッシュする必要はなく、一度に1ページのデータを返すことができます。

反例: ディープ ページネーションに bucket_sort を使用すると、応答時間 (RT) が 5000 ミリ秒以上になりました。

 SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder(); BoolQueryBuilder boolQuery = QueryBuilders.boolQuery(); boolQuery.filter(QueryBuilders.termQuery(EsNewApplyDocumentFields.IS_DEL, 0)); TermsAggregationBuilder termsAggregationBuilder = AggregationBuilders.terms("spuIdAgg").field("spuId").order(BucketOrder.key(false)).size(pageNum*pageSize); termsAggregationBuilder.subAggregation(new BucketSortPipelineAggregationBuilder("spuBucket",null).from((pageNum-1)*pageSize).size(pageSize)); searchSourceBuilder.query(boolQuery).aggregation(termsAggregationBuilder).size(0);

良い例: 複合集約を使用して最適化されたディープページネーションクエリ: 423 ミリ秒

SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder(); BoolQueryBuilder boolQuery = QueryBuilders.boolQuery(); boolQuery.filter(QueryBuilders.termQuery(EsNewApplyDocumentFields.IS_DEL, 0)); CompositeAggregationBuilder compositeBuilder = new CompositeAggregationBuilder( "spuIdAgg", Collections.singletonList(new TermsValuesSourceBuilder("spuId").field("spuId").order("desc")) ).aggregateAfter(ImmutableMap.of("spuId", "603030")).size(20); searchSourceBuilder.query(boolQuery).aggregation(compositeBuilder).aggregation(totalAgg).size(0);

ページネーション

10. from+size メソッドの使用は避けてください。

Elasticsearchでは、ディープページネーションのコストはページネーションの深度に応じて指数関数的に増加し、ページネーションされた検索は個別にキャッシュされません。各ページネーションリクエストは、最初の検索から結果を取得するのではなく、新たな検索プロセスとして実行されます。データが非常に大きい場合、CPUとメモリの消費量が膨大になり、OutOfMemoryError（OOM）が発生する可能性があります。

11. リアルタイム要件が高く、結果セットが大きいシナリオでは、Scroll メソッドを使用しないでください。

スナップショットベースのコンテキスト。リアルタイムアプリケーションには推奨されません。結果セットが大きい場合、多数のスクロールコンテキストが生成され、メモリ消費が過剰になる可能性があります。そのため、SnapshotAfterメソッドの使用をお勧めします。

考えてみましょう：ScrollとSearchAfterのどちらを選ぶべきでしょうか？それぞれどのようなシナリオに適していますか？SearchAfterはScrollを完全に置き換えることができますか？

Scroll は現在のインデックスセグメントのスナップショットを保持します。これは、フルデータクエリの非リアルタイムスクロールに適していますが、多数のコンテキストによるヒープメモリ消費量の増大が顕著です。バージョン7.10では、新機能の Search After + PIT が導入されました。この機能では、クエリは基本的に前のページのソート済みリストを使用して次のページを照合するため、データの一貫性が確保されます。バージョン8.10の公式ドキュメントでは、Scroll API を使用したディープページネーションは推奨されなくなったことが明記されています。ページネーションが上位10,000件を超える場合は、PIT + Search After が推奨されます。

12. インデックス内の SearchAfter ページネーション/スクロール ID/データ トラバーサルでは、ソート フィールドが一意である必要があることを指定します。そうでない場合、ページネーション/トラバーサル データが不完全または重複することになります。

13. デフォルトのスコアリング ソートを使用する代わりに、ビジネス フィールドのソートを指定することをお勧めします。

Elasticsearch (ES) は、デフォルトで「_score」フィールドを使用してスコアでソートします。Scroll API を使用してデータを取得する際、特別なソート要件がない場合は、「sort":"_doc"」を使用してヒットしたドキュメントをインデックス順に返すことをお勧めします。これにより、ソートのオーバーヘッドを削減できます。その理由は次のとおりです。

  • ドキュメントID以外のソート方法を使用すると、Elasticsearchは各クエリごとに各シャードで返された最後のドキュメントを記憶しておく必要があります。後続のクエリでは、コーディネータノードでソート処理が実行されるため、以前に返されたドキュメントは除外されます。ドキュメントIDソートは、このオーバーヘッドを排除します。
  • Elasticsearch はドキュメント ID のソートに特別な最適化を実装しており、パフォーマンスが向上しています。

14. スクロール ルックアップでは、clearScroll() メソッドを明示的に呼び出すことによって、スクロール ID がクリアされることが保証されます。

そうしないと、Elasticsearch は有効期限前にスクロール結果セットが占有しているメモリリソースを解放できず、デフォルトの 3000 個のスクロール クエリの容量も占有してしまい、スクロール ID が多すぎるためにクエリ拒否エラーが発生し、業務に影響を及ぼします。

他の

15. Must と Should が同じステートメント内に表示される場合、Should は無効になることに注意してください。また、Must と Should が同じレベルの同じブールクエリ内に表示される場合、Should クエリは無効になることに注意してください。

肯定的な例:

 {"query":{ "bool":{ "must":[ {"bool":{ "must":[ { "term":{ "status.keyword":"1" } }]}}, {"bool":{ "should":[ {"term":{ "tag.keyword":"1" } } ] }}]}}}

反例:

 {"query":{ "bool":{ "must":[ { "term":{ "status.keyword":"1" }}], "should":[ { "term":{ "tag.keyword":"1" } }]}}}
 16. 避免查询indexName-*。

Elasticsearch のインデックス名はグローバルに表示されるため、すべてのインデックスをクエリすることでクラスター内のすべてのインデックス名を列挙できます。Elasticsearch 設定ファイルで `action.destructive_requires_name` パラメータを設定することで、indexName-* のクエリを無効にすることができます。

17. インライン スクリプトの代わりに保存されたスクリプトを使用します。

固定構造のスクリプトの場合、Stored メソッドを使用して Kibana 経由で Elasticsearch クラスターにスクリプトを保存し、スクリプトを繰り返しコンパイルすることによって発生するパフォーマンスの低下を軽減します。

肯定的な例:

第1步：通过stored方式，建script模版： POST _script/activity_discount_price { "script":{ "lang":"painless", "source":"doc.xxx.value * params.discount" } }第2步：调用script脚本模版：cal_activity_discount GET index/_search { "script_fields": { "discount_price": { "script": { "id": "activity_discount_price", "params":{ "discount": 0.8 } }}}}

反例:

 //直接inline方式，请求中传入脚本： GET index/_search { "script_fields": { "activity_discount_price": { "script": { "source":"doc.xxx.value * 0.8" } } } }

18. _all フィールドの使用は避けてください。

`_all` フィールドには、インデックス付けされたすべてのフィールドが含まれます。元のドキュメントデータを取得する必要がない場合は、`Includes` 属性と `Excludes` 属性を設定することで、`_source` に含めるフィールドを定義できます。デフォルトでは、`_all` は書き込まれたフィールドを大きな文字列に連結し、そのフィールドに対してトークン化を実行して、ドキュメント全体の全文検索をサポートします。`_all` フィールドは、クエリ中に CPU とディスクストレージの消費量を増加させます。デフォルトでは「false」に設定されており、このフィールドを有効にしたり使用したりすることは推奨されません。

19. 検索クエリを GET クエリに置き換えることをお勧めします。

GET/MGETは、ドキュメントIDに基づいて前方インデックスから直接コンテンツを取得します。_idを指定せずに検索を実行すると、キーワードに基づいて転置インデックスからコンテンツが取得されます。

20. 複数のインデックス クエリを実行しないでください。

反例:

 GET /index1,index2,index3/_search { "query": { "match_all": {} } }

21. 一度に大量のデータを呼び出さないようにするには、_source_includes および _source_excludes パラメータを使用してフィールドを含めたり除外したりすることをお勧めします。

これは、部分的なフィールド取得によってネットワークのオーバーヘッドを節約できるため、大規模なドキュメントの場合に特に便利です。

参考例:

 // 创建SearchSourceBuilder，并设置查询条件SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); sourceBuilder.query(QueryBuilders.matchAllQuery()); // 设置要包含的字段String[] includes = {"field1", "field2"}; sourceBuilder.fetchSource(includes, Strings.EMPTY_ARRAY); // 设置要排除的字段String[] excludes = {"field3"}; sourceBuilder.fetchSource(Strings.EMPTY_ARRAY, excludes);

22. 中置あいまい検索ではワイルドカードを使用しないでください。

Elasticsearchの公式ドキュメントでは、中置曖昧クエリにワイルドカードを使用することは推奨されていません。これは、Elasticsearchが入力文字列パターンから決定性有限オートマトン（DFA）を内部的に構築し、ワイルドカードを使ったクエリを高速化するためです。ワイルドカードパターンから構築されるDFAは非常に複雑で、コストが高くなる可能性があります。

ES 7.9で正式に導入されたワイルドカードフィールドタイプの使用をお勧めします。これは、あいまい検索の速度低下に対処するためです。テキストフィールドと比較すると、ワイルドカードフィールドはテキストを句読点で区切られた単語の集合として扱いません。また、キーワードフィールドと比較すると、インフィックス検索シナリオにおいて比類のないクエリ速度を実現し、入力サイズ制限もありません。これはキーワードタイプでは実現できないものです。

23. スクリプトの使用は避けてください。

Painlessスクリプト言語は、比較的シンプルな構文、高い柔軟性、高いセキュリティ、そして高いパフォーマンス（他のスクリプト言語と比較して、DSLよりは劣る）を備えています。複雑でないビジネスロジックには適していません。DSLは一般的にほとんどの問題を解決でき、Painlessのようなスクリプト言語はそれらを処理できます。主なパフォーマンスへの影響は次のとおりです。単一のクエリまたは更新にかかる時間の増加。スクリプト実行前に字句解析、構文解析、コードコンパイルなどの前処理作業が必要となるため、スクリプトの実行時間は他のクエリおよび更新操作よりも長くなる可能性があります。

24. 動的フィールドを計算するためにスクリプトクエリを使用することは避けてください。インデックス作成時にフィールドを計算し、ドキュメントに追加することをお勧めします。

例えば、大量のユーザー情報を含むインデックスがあり、名前が「1234」で始まるすべてのユーザーをクエリする必要がある場合、「source":"doc['num'].value.startsWith('1234')"」のようなクエリを実行するスクリプトを実行すると、リソースを大量に消費します。インデックスを作成する際は、キーワードフィールド「num_prefix」を追加し、「name_prefix":"1234"」のようにクエリすることを検討してください。

III. 関連情報の記述

25. コード内で直接、または手動で更新操作を実行しないでください。

システムが更新アクションを実行できるように、インデックス設定/Refresh_Interval を適切に設定します。

26. 個々のドキュメントが大きくなりすぎないようにします。

デフォルトの http.max_content_length が 100 MB に設定されている場合、Elasticsearch はその値より大きいドキュメントのインデックス作成を拒否します。

27. データを書き込むときに Doc_ID を指定しないでください。Elasticsearch によって自動的に生成されます。

インデックスに明示的なIDを持つドキュメントが含まれている場合、Elasticsearchは書き込みプロセス中に、同じシャード内に同じIDを持つドキュメントが既に存在するかどうかをチェックする追加ステップを実行します。この処理は、インデックスが大きくなるにつれてコストが増加します。

28. バッチ書き込みには Bulk API を活用します。

バルクは大量のデータ書き込みに使用できますが、応答時間が長くなり、接続が切断されてもElasticsearchクラスターは実行を継続します。高速で大量のデータ書き込みを行うと、クラスターの動作が遅くなったり、一時的にフリーズしたように見える場合があります。

  • 最適な数はパフォーマンス テストを通じて決定できます。公式の推奨値は約 5 ～ 15 MB です。
  • タイムアウト期間は十分に長くする必要があり、できれば 60 秒以上にする必要があります。
  • 書き込み側は、異なるノードにデータをポーリングしようとする必要があります。

29. スクリプトが大量のデータを書き込む場合、書き込み前にレプリカシャードを0に設定することは推奨されません。書き込みが完了したら、レプリカシャードを0に戻してください。

レプリカシャードをノードに再追加すると、セカンダリシャードのリカバリプロセスがトリガーされます。シャードのサイズが大きい場合、クラスターのパフォーマンスに影響します。

IV. インデックスの作成

断片

30. レプリカ シャードの数は 1 以上です。

高可用性が保証されます。レプリカ数を増やすと検索パフォーマンスはある程度向上しますが、書き込みパフォーマンスは低下します。プライマリシャード1つにつき、1～2個のレプリカシャードを割り当てることをお勧めします。

31. 公式の推奨事項では、シャードあたりのデータエントリの最大数を 2^32 - 1 以下に制限します。

32. インデックスのプライマリ シャードの数をあまり大きく設定しないでください。

Elasticsearch でインデックスが作成されると、プライマリ シャードの数は通常は動的に調整されません。

各シャードは本質的に Lucene インデックスであるため、対応するファイル ハンドル、メモリ、および CPU リソースを消費します。

Elasticsearchは関連性を計算するために単語の頻度統計を使用します。もちろん、これらの統計は複数のシャードに分散されます。少量のデータが多数のシャードに分散されている場合、最終的なドキュメントの関連性は低くなります。

一般的に言えば、私たちはいくつかの原則に従います:

  • 読み取りシナリオが多数ある場合は、設定できるパラメータの数を少なくし、書き込みシナリオが多数ある場合は、設定できるパラメータの数を多くします。
  • 各シャードが占有するディスク領域が Elasticsearch の最大 JVM ヒープ領域設定 (32G) を超えないようにするには、インデックスの合計サイズが約 200G の場合、シャード サイズは約 7 ～ 8 にする必要があります。
  • ノード数を考慮してください。一般的に、1ノードは1台の物理マシンに対応します。シャード数がノード数を大幅に上回る場合、1つのノードに複数のシャードが存在することになります。そのノードに障害が発生した場合、複数のレプリカが維持されていてもデータ損失が発生し、クラスターが回復不能になる可能性があります。そのため、シャード数は通常、ノード数の3倍以下に設定されます。

33. 単一のデータフラグメントのサイズは 50 GB を超えてはなりません。

単一のインデックスのサイズは1TB未満、単一のシャードのサイズは30～50GB、ドキュメントの数は10億未満に抑える必要があります。これらの制限を超える場合は、ロールオーバーをお勧めします。

マッピングデザイン

34. フィールドの動的マッピング機能は使用しないでください。特定のフィールドタイプ、サブタイプ（必要な場合）、トークナイザー（特に特定のシナリオで必要な場合）を指定してください。

35. トークン化を必要としない文字列フィールドの場合は、テキスト タイプではなくキーワード タイプを使用します。

36. Elasticsearch のフィールドのデフォルトの最大数は 1000 です。100 を超えないようにすることをお勧めします。

単一ドキュメントのインデックス作成における計算の複雑さは、ドキュメントのバイトサイズや特定のフィールド値の長さではなく、主にフィールド数によって決まります。例えば、同じマッピングを使用したフルロード書き込みストレステストでは、フィールド数が10でサイズが200バイトのドキュメントの場合、一部のフィールド値の長さを500バイトに増やしても、Elasticsearchへの書き込み速度はわずかに低下するだけです。しかし、フィールド数が20に増えると、ドキュメント全体のバイトサイズが大幅に増加しなくても、書き込み速度は半分になります。

37. インデックスが作成されていないフィールドの場合、Index プロパティは False に設定されます。

以下の例では、「Title」フィールドの「Index」プロパティがFalseに設定されており、このフィールドはインデックスに含まれないことを示しています。一方、「Content」フィールドの「Index」プロパティはデフォルトでTrueに設定されており、このフィールドはインデックスに含まれることを意味します。なお、IndexプロパティがFalseに設定されている場合でも、フィールドはドキュメントに保存され、クエリや集計が可能です。

参考例:

 { "mappings": { "properties": { "title": { "type": "text", "index": false }, "content": { "type": "text" } } } }

38. ネストや親/子の使用は避けてください。

ネストされたクエリは遅く、親子クエリはさらに遅くなります。単一のドキュメントに対して、ネストされた各フィールドは個別のドキュメントを生成するため、ドキュメント数が大幅に増加し、クエリ効率、特にJOIN効率に影響を与えます。したがって、マッピング設計段階では、可能な限り親子マッピングの使用を避けてください（幅の広いテーブル設計やよりスマートなデータ構造を使用）。ネストされたフィールドを使用する必要がある場合は、過度にならないようにしてください。Elasticsearchのデフォルトの制限は `Index.mapping.nested_fields.limit=50` です。ネストされたクエリは一般的に推奨されません。では、ElasticsearchがJOINを実行できない問題にどのように対処すればよいでしょうか？主な実装方法はいくつかあります。

  • ドキュメント モデリングでは、設計段階でビジネス情報を関連するドキュメント形式に変換し、フラットなドキュメント モデルを使用します。
  • 独立したインデックス ストレージ。実際のビジネス ロジックは複数のリクエストを通じて実装されます。
  • ワイドテーブル冗長ストレージを使用して結合を回避します。
  • それ以外の点では、ネストストレージと親子ストレージはどちらもパフォーマンスに多少の影響を及ぼします。ネストストレージは子ドキュメントの更新時にドキュメント全体のインデックス再作成が必要となるため、書き込みパフォーマンスへの影響が大きく、1対n（nが小さい）のシナリオに適しています。親子ストレージはネストストレージと同じタイプで、書き込みパフォーマンスはネストストレージよりも高く、1対n（nが大きい）のシナリオに適していますが、クエリ速度はネストストレージよりも遅く、公式サイトによると5～10倍ほど遅いとのことです。

39. 規範の使用を避けます。

Normはインデックスのスコアリング係数です。ドキュメントをスコアで並べ替えたくない場合は、「False」に設定してください。

参考例:

 "title": {"type": "string","norms": {"enabled": false}}

テキスト タイプのフィールドでは、デフォルトで規範が有効になっていますが、キーワード タイプのフィールドでは、デフォルトで規範が無効になっています。

ノルムを有効にすると、各ドキュメントの各フィールドにノルムを格納するために1バイトが必要になります。テキスト型フィールドではノルムがデフォルトで有効になっているため、スコアリングを必要としないテキスト型フィールドでは無効にすることができます。

40. 集計/並べ替えを必要としないフィールドの列ストアDoc_Valuesを無効にします。

この列指向のストレージ方式は、主に並べ替え、集計、スクリプトからのフィールド値へのアクセスといったデータアクセスシナリオで使用されます。分析が必要な文字列フィールドを除き、ほぼすべてのフィールドタイプがDoc_Valuesをサポートしています。この機能は、Doc_Valuesをサポートするすべてのフィールドでデフォルトで有効になっています。フィールドの並べ替えや集計、あるいはスクリプトからのフィールド値へのアクセスが不要と判断した場合は、この機能を無効にして冗長なストレージコストを削減できます。

キーワードと数値の選択

キーワード型の主な欠点は、集計時にグローバル序数を構築する必要があることです。一方、数値型ではそうする必要はありません。しかし、カーディナリティの低い数値フィールドは、性別など、多数の結果セットにヒットすることが多く、Numeric型を使用すると、ビットセットの構築に高いコストがかかります。

要約すると、タイプを選択する際には次の原則を参照できます。

  • クエリのみの場合は、範囲クエリが必要な場合は Numeric を使用し、それ以外の場合は Keyword を使用します。
  • 集計のみのシナリオでは、フィールドのカーディナリティが明示的に低い場合は、Execution_hint:map でキーワードを使用し、それ以外の場合は数値を使用します。
  • 残りのTermクエリ＋集約シナリオについては、数値型Termクエリ用にBitSetを構築する方がコストが高いのか、それともキーワード型クエリ用にグローバル序数を構築する方がコストが高いのかを総合的に検討する必要があります。実際のシナリオによって異なりますが、現時点でわかっている最悪のケースでは、BitSetの構築によってCPUがフル稼働する可能性があります。グローバル序数の構築における主な問題は、クエリのレイテンシの増加であり、これもJVMに一定の負荷をかけます。

41. 範囲クエリであまり使用されない数値の場合は、キーワード型を使用します。

すべての数値データを数値フィールドのデータ型にマッピングする必要はありません。Elasticsearchは、Integerやlongなどの数値フィールドをクエリに最適化します。範囲検索が不要な場合、TermクエリではIntegerよりもKeywordの方がパフォーマンスが向上します。

42. 頻繁に使用され、比較的固定されている範囲クエリ フィールドの場合は、キーワード タイプの事前インデックス フィールドを追加します。

フィールドに対するほとんどのクエリが固定範囲内で範囲集計を実行する場合は、キーワード フィールドを追加して、範囲をインデックスに「事前インデックス付け」し、用語集計を使用することで、集計を高速化できます。

43. 集計クエリを必要とする高カーディナリティ キーワード フィールドに対して Eager_Global_Ordinals を有効にします。

参考：eager_global_ordinals

序数（ordinals）は、キーワードフィールドで用語の集計を行うために使用されます。序数は自動増分する数値で表されます。Elasticsearchは、この自動増分する数値と実際の値とのマッピングを維持し、各値にバケットを割り当てます。このマッピングはセグメントレベルで行われます。

しかし、集計操作を実行する際には、複数のセグメントの結果を結合する必要があることがよくあります。各セグメントの序数マッピング関係は一貫していないため、ESは各シャードにグローバル序数構造（グローバルに統一されたマッピング）を作成し、グローバル序数と各セグメントの序数間のマッピング関係を維持します。

デフォルトでは、グローバル序数はクエリが最初に使用する場合（例えばTerm Aggregationなど）のみ、遅延して構築されます。これは、ElasticsearchがTerm Aggregationに使用されるフィールドと使用されないフィールドを認識できないためです。カーディナリティの高いフィールドの場合、構築コストは大きくなります。

`eagerly_global_ordinals` を有効にすると、Elasticsearch はシャード構築時にグローバル序数テーブルを事前計算できるため、クエリ時の読み込みと使用が高速化されます。ただし、`eagerly_global_ordinals` を有効にすると、更新操作ごとにグローバル序数テーブルも構築されるため、検索時に発生する構築コストが書き込み操作にシフトされます。そのため、書き込み効率に影響を与える可能性があります。この機能は、インデックスの更新間隔を長くすることと併用することをお勧めします。

参考例:

 PUT index { "mappings": { "type": { "properties": { "foo": { "type": "keyword", "eager_global_ordinals" : true } } } } }

V. 要約

最近十年，Elasticsearch 已经成为了最受欢迎的开源检索引擎，并沉淀了大量的实践案例及优化总结。在本文中，我们尽可能全面地总结了Elasticsearch 日常开发中的一些重要实践&避坑指南，希望能为大家提供Elasticsearch 使用上的一些借鉴点，欢迎讨论！

参考文献:

1.《Elasticsearch 源码解析与优化实战》

2.《Elasticsearch权威指南》

3.https://www.easyice.cn/archives/367

4.https://www.elastic.co/guide/en/elasticsearch/guide/current/filter-caching.html#_independent_query_caching

5.https://www.elastic.co/guide/cn/elasticsearch/guide/current/_preventing_combinatorial_explosions.html

6.https://www.elastic.co/guide/en/elasticsearch/reference/current/eager-global-ordinals.html

ラベル

関連するおすすめ記事

ランダムにおすすめされた記事

人気のタグ