変換の制限

Elastic transform 機能の 8.15.2 リリースに適用される制限と既知の問題は以下の通りです。制限は以下のカテゴリに分類されます：

  • 設定の制限 は変換の設定プロセスに適用されます。
  • 運用上の制限 は実行中の変換の動作に影響を与えます。
  • Kibana の制限 はユーザーインターフェースを介して管理される変換にのみ適用されます。

設定の制限

アンダースコアで始まるフィールド名は最新の変換から省略されます

latest タイプの変換を使用し、ソースインデックスにアンダースコア (_) 文字で始まるフィールド名がある場合、それらは内部フィールドと見なされます。これらのフィールドは、宛先インデックスのドキュメントから省略されます。

リモートクラスターが適切に構成されている場合、変換はクロスクラスター検索をサポートします

クロスクラスター検索を使用する場合、リモートクラスターは変換で使用する検索および集約をサポートしている必要があります。変換はその設定を検証します。クロスクラスター検索を使用し、検証が失敗した場合は、リモートクラスターが使用するクエリおよび集約をサポートしていることを確認してください。

変換でのスクリプトの使用

変換は、集約がそれをサポートするすべてのケースでスクリプティングをサポートします。ただし、変換でスクリプトを使用する際に考慮すべき特定の要因があります：

  • フィールドがスクリプトによって作成される場合、変換は出力フィールドのインデックスマッピングを推測できません。この場合、変換を作成する前に宛先インデックスのマッピングを自分で作成することをお勧めします。
  • スクリプトフィールドは、変換の実行時間を増加させる可能性があります。
  • group_by で定義されたすべてのグループ化にスクリプトを使用する場合、変換はクエリを最適化できません。この方法でスクリプトを使用すると、警告メッセージが表示されます。

変換における Painless スクリプトの非推奨警告

変換に非推奨の構文を使用する Painless スクリプトが含まれている場合、変換がプレビューまたは開始されるときに非推奨警告が表示されます。ただし、必要なクエリを実行することがリソース集約的なプロセスであるため、すべての変換に対して一括アクションとして非推奨警告を確認することはできません。したがって、非推奨の Painless 構文による非推奨警告は、Upgrade Assistant では利用できません。

変換はインデックスフィールドでより良いパフォーマンスを発揮します

変換は、ユーザー定義の時間フィールドによってデータをソートします。この時間フィールドは頻繁にアクセスされます。時間フィールドが runtime field の場合、クエリ時にフィールド値を計算することによるパフォーマンスへの影響が変換を著しく遅くする可能性があります。変換を使用する際は、時間フィールドとしてインデックスフィールドを使用してください。

継続的な変換スケジューリングの制限

継続的な変換は、ソースデータの変更を定期的にチェックします。スケジューラの機能は、現在 frequency の範囲内で 1 秒から 1 時間の基本的な周期タイマーに制限されています。デフォルトは 1 分です。これは、少しずつ頻繁に実行されるように設計されています。このタイマーの frequency を選択する際は、インジェストレートと、変換の検索/インデックス操作がクラスター内の他のユーザーに与える影響を考慮してください。また、リトライは frequency の間隔で発生することに注意してください。

運用上の制限

集約応答は宛先インデックスのマッピングと互換性がない場合があります

ピボット変換が最初に開始されると、宛先インデックスに必要なマッピングが推測されます。このプロセスは、ソースインデックスのフィールドタイプと使用される集約に基づいています。フィールドが scripted_metrics または bucket_scripts から派生している場合、dynamic mappings が使用されます。場合によっては、推測されたマッピングが実際のデータと互換性がないことがあります。たとえば、数値オーバーフローが発生する可能性があるか、動的にマッピングされたフィールドに数値と文字列の両方が含まれる可能性があります。これが発生したと思われる場合は、Elasticsearch のログを確認してください。

推測されたマッピングは、preview transform API を使用して表示できます。API 応答の generated_dest_index オブジェクトを参照してください。

必要な場合は、create index API を使用してカスタム宛先インデックスを作成することにより、変換を開始する前にカスタムマッピングを定義できます。推測されたマッピングはインデックステンプレートによって上書きできないため、カスタムマッピングを定義するには create index API を使用してください。インデックステンプレートは、動的マッピングを使用するスクリプトから派生したフィールドにのみ適用されます。

バッチ変換は変更されたドキュメントを考慮しない場合があります

バッチ変換は、すべてのバケットを効率的にページングすることを可能にする composite aggregation を使用します。コンポジット集約はまだ検索コンテキストをサポートしていないため、バッチデータフレームが進行中の間にソースデータが変更された場合（削除、更新、追加）、結果にこれらの変更が含まれない可能性があります。

継続的な変換の整合性は削除または更新されたドキュメントを考慮しません

変換のプロセスは、新しいデータがインジェストされる際に変換を継続的に再計算することを可能にしますが、いくつかの制限もあります。

変更されたエンティティは、その時間フィールドが更新され、変更をチェックするアクションの範囲内にある場合にのみ特定されます。これは、インジェスト時のタイムスタンプが新しいデータに付与されるユースケースに原則として設計されています。

ソースインデックスパターンの範囲内にあるインデックスが削除されると、たとえば、履歴の時間ベースのインデックスを削除する場合、連続したチェックポイント処理で実行されるコンポジット集約は異なるソースデータを検索し、削除されたインデックスにのみ存在したエンティティはデータフレームの宛先インデックスから削除されません。

ユースケースに応じて、削除後に変換を完全に再作成することを検討するか、履歴アーカイブに耐性がある場合は、集約に最大インジェストタイムスタンプを含めることを検討してください。これにより、宛先インデックスを表示する際に最近更新されていない結果を除外できます。

変換を削除しても宛先インデックスや Kibana インデックスパターンは削除されません

DELETE _transform/index を使用して変換を削除する際、宛先インデックスや作成された場合の Kibana インデックスパターンは削除されません。これらのオブジェクトは別々に削除する必要があります。

集約ページサイズの動的調整の処理

変換の開発中は、パフォーマンスよりも制御が重視されました。設計上の考慮事項では、変換がバックグラウンドで静かに完了するのに時間がかかる方が、迅速に完了してリソース消費に優先するよりも好まれます。

コンポジット集約は、高いカーディナリティデータに適しており、結果をページングすることができます。コンポジット集約検索を実行中に circuit breaker メモリエクセプションが発生した場合、要求されたバケットの数を減らして再試行します。このサーキットブレーカーは、変換からのアクティビティだけでなく、クラスター内のすべてのアクティビティに基づいて計算されるため、一時的なリソースの可用性の問題である可能性があります。

バッチ変換の場合、要求されたバケットの数は常に減少します。値の低下は、変換チェックポイントの完了にかかる時間が長くなる可能性があります。継続的な変換の場合、要求されたバケットの数は各チェックポイントの開始時にデフォルトにリセットされ、Elasticsearch のログでサーキットブレーカーの例外が繰り返し発生する可能性があります。

変換はバッチでデータを取得するため、複数のバケットを同時に計算します。デフォルトでは、検索/インデックス操作ごとに 500 バケットです。デフォルトは max_page_search_size を使用して変更でき、最小値は 10 です。要求されたバケットの数が最小値に減少しても失敗が続く場合、変換は失敗状態に設定されます。

多くの用語の動的調整の処理

各チェックポイントでは、前回チェックが行われてから変更されたエンティティが特定されます。この変更されたエンティティのリストは、変換コンポジット集約に terms query として提供され、1 ページずつ処理されます。その後、各ページのエンティティに対して宛先インデックスに更新が適用されます。

ページ size は max_page_search_size によって定義され、これはコンポジット集約検索によって返されるバケットの数を定義するためにも使用されます。デフォルト値は 500 で、最小値は 10 です。

インデックス設定 index.max_terms_count は、terms query で使用できる最大の用語数を定義します。デフォルト値は 65536 です。max_page_search_size が index.max_terms_count を超えると、変換は失敗します。

max_page_search_size に小さい値を使用すると、変換チェックポイントの完了にかかる時間が長くなる可能性があります。

失敗した変換の処理

失敗した変換は永続的なタスクとして残り、適切に処理する必要があります。削除するか、失敗の根本原因を解決して再起動します。

API を使用して失敗した変換を削除する場合は、まず _stop?force=true を使用して停止し、その後削除します。

継続的な変換は、ドキュメントがまだ検索可能でない場合に不正確な結果を返す可能性があります

ドキュメントがインデックスされると、検索可能になるまでに非常に短い遅延があります。

継続的な変換は、最後にチェックした時点から now から sync.time.delay を引いた時間の間に変更されたエンティティを定期的にチェックします。この時間ウィンドウは重複せずに移動します。最近インデックスされたドキュメントのタイムスタンプがこの時間ウィンドウ内にあるが、このドキュメントがまだ検索可能でない場合、このエンティティは更新されません。

データインジェスト時間を表す sync.time.field を使用し、ゼロ秒または非常に小さい sync.time.delay を使用する場合、この問題が発生する可能性が高くなります。

日付ナノ秒データ型のサポート

データが date nanosecond data type を使用している場合、集約はそれでもミリ秒解像度で行われます。この制限は、変換内の集約にも影響します。

データストリームを宛先インデックスとして使用することはサポートされていません

変換は宛先インデックス内のデータを更新し、宛先に書き込む必要があります。データストリーム は追加専用に設計されているため、データストリームに直接更新または削除リクエストを送信することはできません。このため、データストリームは変換の宛先インデックスとしてサポートされていません。

ILM を宛先インデックスとして使用すると、重複したドキュメントが発生する可能性があります

ILM を変換の宛先インデックスとして使用することは推奨されません。変換は現在の宛先内のドキュメントを更新し、ILM によって以前に使用されたインデックス内のドキュメントを削除することはできません。これにより、ロールオーバー時に変換と ILM を組み合わせて使用する場合に重複したドキュメントが発生する可能性があります。

ILM を使用して時間ベースのインデックスを持つ場合は、代わりに Date index name を使用することを検討してください。変換に group_by が date_histogram に基づいている場合、プロセッサは重複したドキュメントなしで動作します。

Kibana の制限

変換はすべての Kibana スペースで表示されます

Spaces を使用すると、Kibana でソースおよび宛先インデックスやその他の保存されたオブジェクトを整理し、スペースに属するオブジェクトのみを表示できます。ただし、変換はクラスター レベルで管理される長時間実行されるタスクであるため、特定のスペースに限定されません。データビューに対してスペースの認識を実装することができ、Stack Management > Kibana の下で変換の宛先インデックスに対する権限を許可します。

Kibana には最大 1,000 の変換がリストされます

Kibana の変換管理ページには、最大 1000 の変換がリストされます。

Kibana はすべての変換設定オプションをサポートしていない場合があります

変換 API を介して利用可能な設定オプションが Kibana でサポートされていない場合があります。設定オプションの完全なリストについては、documentation を参照してください。