Elasticsearch 8.9 では、動的なプルーニングをサポートするカーディナリティ集約アクセラレーションが導入されています。この最適化を効果的に行うには、特定の条件を満たす必要がありますが、一度実装されると、多くの場合素晴らしい結果が得られます。この変更により、一部のカーディナリティ集計が 1,000 倍高速に実行されることが観察されました。
たとえば、Elastic Kubernetes 統合によって監視される Kubernetes デプロイメントの一意の値の数をカウントすると、この最適化のメリットが得られる可能性があります。
POST metrics-*/_search
{
"query": { // giving an example query, but any query would work
"bool": {
"filter": [
{ "range": { "@timestamp": { "gte": "now-1d/h" } } },
{ "match": { "data_stream.dataset": "kubernetes.pod" } }
]
}
},
"size": 0,
"track_total_hits": false,
"aggs": {
"deployment_count": {
"cardinality": {
"field": "kubernetes.deployment.name"
}
}
}
}
どのように機能するのでしょうか?
動的プルーニングは、インデックス構造を使用して、クエリの実行時に評価する必要がある一致のセットを動的に減らすプロセスです。たとえば、タイムスタンプの降順で並べ替えられた上位 10 件のイベントをクエリし、一致の評価を開始し、過去 1 時間以内のタイムスタンプを持つ 10 件のヒットを見つけた場合、タイムスタンプ フィールドにフィルターを動的に導入して、1 時間あたりのイベントを無視することができます。 ago: 彼らにはトップ 10 に入るチャンスはありません。
カーディナリティ集計の最適化も同様の考え方に従います。つまり、一度値を確認すると、そのフィールドの一意の値の数に影響を与えないため、後で再度確認する必要はありません。したがって、クエリの評価中に、カーディナリティの統合により、これまでに表示されていない値のみに一致する選言クエリにフィルターが自動的に導入されます。新しい値を持つドキュメントが収集されると、それらの値は抽出から削除されます。
たとえば、a と b という 2 つの一意の値を持つフィールドのカーディナリティを計算するとします。次の表は、クエリ内のすべての一致をリストします。最初の列にはクエリと一致する Lucene ドキュメント ID、2 番目の列にはこのドキュメント ID に関連付けられた値が表示されます。
| ドキュメントID | 価値 |
| 3 | b |
| 10 | b |
| 12 | ある |
| 19 | b |
| 30 | ある |
クエリの評価を開始すると、Elasticsearch はa OR bのフィルターをメインクエリに暗黙的に追加します。最初の一致であるドキュメント ID 3 を確認した後は、値 b を再度確認する必要はないため、フィルターは値 a のみに一致する、より選択的なフィルターに変わります。これにより、値として b を持つドキュメント ID 10 の評価が保存され、値として a を持つ次のドキュメント (ドキュメント ID 12) に直接ジャンプできます。この時点で、 a はフィルターから削除されており、Elasticsearch はフィールドの一意の値をすべて確認したため、これ以上一致を評価しても意味がないと認識します。これは、評価ドキュメント ID 19 と 30 を保存するのに役立ちます。
この最適化の最初の段階 (フィルターを動的に導入する) はすでに、クエリで評価する必要があるドキュメントの数を大幅に削減するのに役立ち、クエリの評価を高速化します。ただし、2 番目のフェーズでは、すべての一意の値が見つかったときにクエリが終了するときに、インデックスのほとんどのドキュメントをスキップするのに役立つため、最も劇的な速度向上が引き起こされます。クエリによっては、第 2 段階が常に発生するとは限らないことに注意してください。一部の値は、クエリに一致しないドキュメントにのみ存在する可能性があります。
いつから有効になりますか?
選言クエリは句の数に応じて適切に調整できないため、この最適化の主な制限は、カーディナリティが比較的小さいフィールドでのみ機能することです。したがって、Elasticsearch は、一意の値が 1,024 個以下のセグメントに対してのみこの最適化を有効にします。
また、この最適化ではキー フィールドのみがサポートされており、転置インデックスを使用してインデックスが付けられ、そのドキュメント値からセグメントごとの一意の値の数が得られるという事実を利用します。
最後に、カーディナリティ集約が唯一の集約であり、集約ツリーの最上位になければなりません。
結論は
この最適化は Elastic Kubernetes に統合されたダッシュボードに対して評価されており、特に大量のデータを処理する場合に、ダッシュボードの読み込み時間が大幅に短縮されます。特に、このブログの紹介で共有したサンプル クエリのレイテンシは 90% 削減されました。ぜひ加速感を楽しんでください！
Elastic 8.9 のその他の新機能は何ですか? 詳細については、8.9 のお知らせ投稿を確認してください。