クエリの制限

適用対象: ✅Microsoft Fabric✅Azure データ エクスプローラー✅Azure Monitor✅Microsoft Sentinel

Kusto は、大規模なデータセットをホストし、関連するすべてのデータをメモリに保持することでクエリを満たそうとするアドホック クエリ エンジンです。 クエリによってサービス リソースが境界なしで独占されるという固有のリスクがあります。 Kusto には、既定のクエリ制限という形でいくつかの組み込みの保護が用意されています。 これらの制限を削除することを検討している場合は、まず、その結果として実際に何かメリットがあるかどうかを判断してください。

要求の同時実行に対する制限

要求のコンカレンシー は、同時に実行される複数の要求に対する制限です。

• 制限の既定値は、データベースが実行されている SKU によって異なり、 Cores-Per-Node x 10として計算されます。
  • たとえば、各マシンに 16 個の仮想コアがある D14v2 SKU に設定されているデータベースの場合、既定の制限は 16 cores x10 = 160。
• 既定値は、default ワークロード グループの要求レート制限ポリシーを構成することで変更できます。
  • さまざまな要因が、データベースで同時に実行できる要求の実際の数に影響します。 最も重要な要因は、データベース SKU、データベースの使用可能なリソース、および使用パターンです。 運用環境に似た使用パターンで実行されるロード テストに基づいてポリシーを構成します。

結果セット サイズに対する制限 (結果の切り捨て)

結果の切り捨ては 、クエリによって返される結果セットの既定の制限です。 Kusto では、クライアントに返されるレコード数が 500,000 に制限され、そのレコードの全体的なデータ サイズは 64 MB に制限されています。 これらの制限を超えた場合、クエリは "部分的なクエリ エラー" で失敗します。 全体的なデータ サイズを超えると、次のメッセージで例外が生成されます。

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal data size limit 67108864 (E_QUERY_RESULT_SET_TOO_LARGE).'

レコードの数を超えると、次の例外が発生して失敗します。

The Kusto DataEngine has failed to execute a query: 'Query result set has exceeded the internal record count limit 500000 (E_QUERY_RESULT_SET_TOO_LARGE).'

このエラーを解決するには、いくつかの方法を使用できます。

• 必要なデータのみを返すようにクエリを変更することで、結果セットのサイズを小さくします。 この戦略は、最初に失敗したクエリが "広範" である場合に役立ちます。 たとえば、不要なデータ列がクエリに反映されていない場合です。
• 集計など、クエリ後の処理をクエリ自体に移動することで、結果セットのサイズを小さくします。 この戦略は、クエリの出力が別の処理システムに供給され、そのシステムが他の集計を実行するシナリオで役立ちます。
• サービスから大量のデータ セットをエクスポートする場合は、クエリからデータのエクスポートの使用に切り替えます。
• 次のセクションに示す set ステートメントまたは クライアント要求プロパティのフラグを使用して、このクエリ制限を抑制するようにサービスに指示します。

クエリによって生成される結果セットのサイズを小さくするには、次のような方法があります。

• summarize 演算子を使用して、クエリ出力内の類似レコードをグループ化して集計します。 take_any 集計関数を使用して、いくつかの列をサンプリングすることもできます。
• take 演算子を使用してクエリ出力をサンプリングします。
• substring 関数を使用して、幅の広いフリーテキスト列をトリミングします。
• project 演算子を使用して、結果セットから不要な列を削除します。

notruncation 要求オプションを使用して、結果の切り捨てを無効にすることができます。 ただし、何らかの形式の制限を設定しておくことをお勧めします。

次に例を示します。

set notruncation;
MyTable | take 1000000

また、 truncationmaxsize (最大データ サイズ (既定では 64 MB) と truncationmaxrecords (レコードの最大数、既定値は 500,000) の値を設定することで、結果の切り捨てを細かく制御することもできます。 たとえば、次のクエリでは、1,105 件のレコードまたは 1 MB のいずれかを超えたときに結果の切り捨てが発生するように設定されます。

set truncationmaxsize=1048576;
set truncationmaxrecords=1105;
MyTable | where User=="UserId1"

結果の切り捨て制限を削除することは、大量のデータが Kusto から移動されることを意味します。

結果の切り捨て制限を削除できるのは、.export コマンドを使用してエクスポートする目的がある場合、または後で集計する場合です。 後で集計する場合は、Kusto を使用して集計することを検討してください。

Kusto には、呼び出し元にストリーミングすることで "無限に大きい" 結果を処理できる多くのクライアント ライブラリが用意されています。 このようなライブラリのいずれかを使用して、ストリーミング モードに構成します。 たとえば、.NET Framework クライアント (Microsoft.Azure.Kusto.Data) を使用して、接続文字列のストリーミング プロパティを true に設定するか、ExecuteQueryV2Async() の呼び出しを使用して常に結果をストリーミングするようにします。 ExecuteQueryV2Async() の使用方法の例については、HelloKustoV2 アプリケーションを参照してください。

C# ストリーミング インジェスト サンプル アプリケーションも役立つ場合があります。

結果の切り捨ては、クライアントに返される結果のストリームだけでなく、既定で適用されます。

複数の結果の切り捨てプロパティの設定

set ステートメントを使用する場合、またはクライアント要求プロパティでフラグを指定する場合は、次の規則が適用されます。

• notruncation設定したが、truncationmaxsize、truncationmaxrecords、またはquery_take_max_recordsも設定した場合、サービスはnotruncationを無視します。
• truncationmaxsize、truncationmaxrecords、またはquery_take_max_recordsを複数回設定した場合、サービスは各プロパティの小さい値を使用します。

クエリ演算子によって消費されるメモリの制限

反復子あたりの最大メモリ消費量 の上限は、各クエリ演算子がノードごとに消費するメモリの量を制御するように構成できます。 joinやsummarizeなどの一部のクエリ演算子は、メモリ内の重要なデータを保持します。 要求オプション maxmemoryconsumptionperiteratorの既定値を増やすことで、演算子ごとに必要なメモリを増やすクエリを実行できます。

この要求オプションでサポートされる最大値は、32212254720 (30 GB) です。 クライアント要求プロパティと set ステートメントの両方でmaxmemoryconsumptionperiteratorを複数回設定した場合は、小さい値が適用されます。

クエリがオペレーターごとの構成済みメモリの制限に達すると、部分的なクエリエラー メッセージが表示され、テキスト E_RUNAWAY_QUERYが含まれます。

次に例を示します。

The ClusterBy operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The HashJoin operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

The Sort operator has exceeded the memory budget during evaluation. Results might be incorrect or incomplete (E_RUNAWAY_QUERY).

たとえば、このクエリでは、反復子あたりの最大メモリ消費量を 15 GB に設定します。

set maxmemoryconsumptionperiterator=16106127360;
MyTable | summarize count() by Use

E_RUNAWAY_QUERY部分的なクエリエラーを引き起こす可能性があるもう 1 つの制限は、1 つの演算子によって保持される文字列の最大累積サイズです。 上記の要求オプションでは、この制限をオーバーライドできません。

Runaway query (E_RUNAWAY_QUERY). Aggregation over string column exceeded the memory budget of 8GB during evaluation.

この制限を超えた場合、最も可能性の高いクエリ演算子は、 join、 summarize、または make-seriesです。

この制限を回避するには、 シャッフル クエリ戦略を使用するようにクエリを変更します。 この変更により、クエリのパフォーマンスが向上する可能性もあります。

E_RUNAWAY_QUERYのすべての場合、追加のオプション (要求オプションを設定し、シャッフル戦略を使用するようにクエリを変更することによって制限を増やす以外) は、サンプリングに切り替えることです。 サンプリングにより、クエリによって処理されるデータの量が減るため、クエリ演算子のメモリ負荷が軽減されます。

これら 2 つのクエリは、サンプリングの実行方法を示しています。 1 つ目のクエリは、乱数ジェネレーターを使用した統計サンプリングです。 2 番目のクエリは確定的なサンプリングであり、データセットからいくつかの列 (通常は一部の ID) をハッシュすることによって実行されます。

T | where rand() < 0.1 | ...

T | where hash(UserId, 10) == 1 | ...

summarizeとjoinの両方に hint.shufflekey などのメカニズムを使用する方法の詳細については、「Kusto クエリ言語クエリのベスト プラクティス」を参照してください。

ノードあたりのメモリに対する制限

ノードあたりのクエリあたりの最大メモリは、"暴走" クエリから保護するために使用されるもう 1 つの制限です。 この制限は要求オプション max_memory_consumption_per_query_per_node で表され、特定のクエリに対して 1 つノードで使用できるメモリ量の上限が設定されます。

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

max_memory_consumption_per_query_per_node が複数回設定されている場合 (たとえばクライアント要求のプロパティと set ステートメントの両方を使用)、低い方の値が適用されます。

クエリで summarize、join、または make-series 演算子が使用されている場合は、クエリのシャッフル戦略を使用して、1 台のコンピューターのメモリの負荷を軽減できます。

実行タイムアウトの制限

サーバー タイムアウトは、すべての要求に適用されるサービス側のタイムアウトです。 実行中の要求 (クエリと管理コマンド) のタイムアウトは、Kusto 内の複数のポイントで適用されます。

• クライアント ライブラリ (使用されている場合)
• 要求を受け入れるサービス エンドポイント
• 要求を処理するサービス エンジン

既定では、クエリの場合はタイムアウトが 4 分、管理コマンドの場合は 10 分に設定されます。 この値は、必要に応じて増やすことができます (上限は 1 時間)。

• さまざまなクライアント ツールで、グローバルな設定または接続ごとの設定の一部として、タイムアウトの変更がサポートされています。 たとえば、Kusto.Explorer で、[ツール]>[オプション]* >[接続]>[クエリ サーバーのタイムアウト] を使用します。
• SDK は、プログラムによって servertimeout プロパティによるタイムアウトの設定をサポートします。 たとえば、.NET SDK では、クライアント要求のプロパティで、System.TimeSpan 型の値を設定してサポートされます。

タイムアウトに関する注意事項

• クライアント側では、作成された要求から応答がクライアントに到着し始めるまでのタイムアウトが適用されます。 クライアントでペイロードの読み取りにかかる時間は、タイムアウトの一部として扱われません。 これは、呼び出し元がストリームからデータをプルする速度によって変わります。
• また、クライアント側では、使用される実際のタイムアウト値は、ユーザーが要求したサーバー タイムアウト値よりもわずかに高くなります。 ネットワークの待機時間を考慮に入れるために、この差があります。
• 最大許容要求タイムアウトを自動的に使用するには、クライアント要求プロパティ norequesttimeout を true に設定します。

クエリの CPU リソース使用率に対する制限

Kusto を使用すると、クエリを実行し、データベースに含まれる使用可能なすべての CPU リソースを使用できます。 複数のクエリが実行されている場合は、クエリ間で公平なラウンド ロビンが試行されます。 このメソッドは、クエリ定義関数に最適なパフォーマンスを実現します。 また、特定のクエリに使用される CPU リソースを制限することもできます。 たとえば、"バックグラウンド ジョブ" を実行すると、同時実行インライン クエリの優先度が高くなるように、待機時間が長くなる可能性があります。

Kusto では、クエリの実行時に 2 つのrequest プロパティの指定がサポートされています。 そのプロパティは、query_fanout_threads_percent と query_fanout_nodes_percent です。 どちらのプロパティも既定値は最大値 (100) の整数ですが、クエリによっては他の値に減らすこともできます。

1 つ目 query_fanout_threads_percent を使用すると、スレッドの使用に対するファンアウト係数を制御できます。 このプロパティを 100%設定すると、すべての CPU が各ノードに割り当てられます。 たとえば、Azure D14 ノードにデプロイされた 16 個の CPU などです。 このプロパティを 50%に設定すると、CPU の半分が使用されます。 数値は CPU 全体に切り上げられるため、プロパティ値を 0 に設定しても問題ありません。

2 つ目の query_fanout_nodes_percentでは、サブクエリ分散操作ごとに使用するクエリ ノードの数を制御します。 機能は同様です。

query_fanout_nodes_percent または query_fanout_threads_percent が複数回設定されている場合 (たとえばクライアント要求のプロパティと set ステートメントの両方を使用)、各プロパティの低い方の値が適用されます。

クエリの複雑さに対する制限

クエリの実行時に、クエリ テキストはクエリを表す関係演算子のツリーに変換されます。 ツリーの深さが内部しきい値を超えた場合、クエリは処理が複雑すぎると見なされ、エラー コードで失敗します。 このエラーは、関係演算子ツリーが制限を超えていることを示します。

次の例は、クエリがこの制限を超えて失敗する可能性がある一般的なクエリ パターンを示しています。

• 一緒に連結される二項演算子の長いリスト。 次に例を示します。

T
| where Column == "value1" or
        Column == "value2" or
        .... or
        Column == "valueN"

この特定のケースでは、in() 演算子を使用してクエリを書き直してください。

T
| where Column in ("value1", "value2".... "valueN")

• 非常に広いスキーマ分析を実行している共用体演算子を持つクエリ。特に、共用体の既定のフレーバーは "外部" 共用体スキーマを返すということです (つまり、出力には基になるテーブルのすべての列が含まれます)。

この場合、クエリを見直し、クエリで使用されている列を減らすことをお勧めします。

関連するコンテンツ

• クエリのベスト プラクティス