次の方法で共有

クエリの制限

[ バージョン ] ドロップダウン リストを使用してサービスを切り替えます。 ナビゲーションの詳細を確認します。
適用対象: ✅ Microsoft Fabric ✅ Azure Data Explorer ✅ Azure Monitor ✅ Microsoft Sentinel

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

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

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

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

詳細については、「Azure Data Explorer を使用した高いコンカレンシーの最適化」を参照してください。

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

結果の切り捨ては 、クエリによって返される結果セットの既定の制限です。 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# ストリーミング インジェスト サンプル アプリケーションも役立つ場合があります。

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

また、既定で、あるクラスターから別のクラスターにクロスクラスター クエリで発行されるサブクエリにも適用され、同様の効果があります。

また、既定では、ある Eventhouse がクロスイベントハウス クエリの別の Eventhouse に発行するサブクエリにも、同様の効果が適用されます。

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

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

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

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

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

この要求オプションでサポートされる最大値は 32,212,254,720 (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のすべての場合において、もう 1 つのオプション (要求オプションを設定し、シャッフル戦略を使用するようにクエリを変更することで制限を増やす以外) は、サンプリングに切り替えることです。 サンプリングにより、クエリによって処理されるデータの量が減るため、クエリ演算子のメモリ負荷が軽減されます。

これら 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 | ...

クライアント要求プロパティと set ステートメントの両方など、max_memory_consumption_per_query_per_nodeを複数回設定した場合は、小さい値が適用されます。

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

実行タイムアウトの制限

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

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

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

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

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

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

Note

Azure Data Explorer Web UI、Kusto.Explorer、Kusto.Cli、Power BI でタイムアウトを設定する方法と SDK を使用する場合の詳細なガイドについては、「 設定タイムアウト制限 を参照してください。

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

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

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

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

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

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

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

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

クエリの複雑さを超えました

クエリが複雑すぎてエンジンがコンパイルできません。 この複雑さは、通常、クエリ プランの構築で消費されるリソースが多すぎる場合に発生します。 一般的な原因には、次のようなものがあります。

  • 大規模なデータベースでの union * の使用など、多数のテーブルにわたる大規模な共用体。
  • 深く入れ子になったサブクエリ。
  • 相互に参照する let ステートメントの多くのレベル。

クエリ プランのサイズまたは複雑さが設定された制限を超えています

クエリによって、処理するには大きすぎるクエリ プランが生成されます。 一般的な原因には、次のようなものがあります。

  • ブロードキャスト結合の左側では、生成されるデータが多すぎます。
  • toscalar()によって返される結果が大きすぎます。
  • in()式内の結果が大きすぎます。 たとえば、サブクエリが返す値が多すぎる in (subquery) です。

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

  • 連結される二項演算子の長いリスト。 次に例を示します。
T
| where Column == "value1" or
        Column == "value2" or
        .... or
        Column == "valueN"

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

T
| where Column in ("value1", "value2".... "valueN")
  • 共用体演算子を使用し、スキーマ分析の幅が広すぎるクエリ。 この問題は、共用体の既定のフレーバーから "外部" 共用体スキーマが返されるために発生します。 このスキーマは、基になるテーブルのすべての列が出力に含まれていることを意味します。

クエリを確認し、クエリで使用する列の数を減らします。

関連するコンテンツ

  • Last updated on