共用方式為

查詢限制

  • 發行項

適用於：✅Microsoft網狀架構✅Azure 數據✅總管 Azure 監視器✅Microsoft Sentinel

Kusto 是一個臨機操作查詢引擎，裝載大型數據集，並嘗試藉由在記憶體中存放所有相關數據來滿足查詢。 查詢會在沒有界限的情況下壟斷服務資源有固有的風險。 Kusto 會以預設查詢限制的形式提供數個內建保護。 如果您考慮移除這些限制，請先藉由這麼做來判斷您是否實際取得任何值。

要求並行限制

要求並行 存取是同時對數個同時執行的要求施加的限制。

  • 限制的預設值取決於資料庫執行中的 SKU，並計算為： Cores-Per-Node x 10。
    • 例如，針對在 D14v2 SKU 上設定的資料庫，其中每部電腦都有 16 個虛擬核心，預設限制為 16 cores x10 = 160。
  • 您可以藉由設定工作負載群組的要求速率限制原則default來變更預設值。
    • 可以同時在資料庫上執行的要求數目取決於各種因素。 最重要的因素是資料庫 SKU、資料庫的可用資源和使用模式。 原則可以根據在類似生產環境的使用模式上執行的負載測試來設定。

如需詳細資訊，請參閱 使用 Azure 數據總管優化高並行。

結果集大小的限制（結果截斷）

結果截斷 是查詢所傳回結果集預設所設定的限制。 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下列語句或用戶端要求屬性中的旗標來隱藏此查詢限制。

減少查詢所產生的結果集大小的方法包括：

您可以使用要求選項來停用結果截斷 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 問題至另一個 Eventhouse 的任何子查詢，其效果類似。

設定多個結果截斷屬性

在用戶端要求屬性中指定旗標時，下列適用於 using set 語句和/或 。

  • 如果 notruncation 已設定，而且也會設定、 或 query_take_max_records 的任何 truncationmaxsizetruncationmaxrecords一個 ，notruncation則會忽略 。
  • 如果 truncationmaxsize為 ， truncationmaxrecords 且/或 query_take_max_records 已設定多次 ， 則會套用每個屬性的較低 值。

查詢運算子所耗用的記憶體限制 （E_RUNAWAY_QUERY）

Kusto 會限制每個查詢運算符可以取用的記憶體，以防止「失控」查詢。 某些查詢運算符，例如 join 和 summarize，可以藉由在記憶體中儲存大量數據來達到此限制。 根據預設，限制為5GB（每個節點），而且可以藉由設定要求選項 maxmemoryconsumptionperiterator來增加：

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

達到此限制時，會發出部分查詢失敗，並顯示包含文字 E_RUNAWAY_QUERY的訊息。

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

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

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

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

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

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

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

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

如果 maxmemoryconsumptionperiterator 設定多次，例如，在用戶端要求屬性和使用 set 語句中，則會套用較低的值。

可能會觸發 E_RUNAWAY_QUERY 部分查詢失敗的額外限制，是單一運算符所保存字串最大累積大小的限制。 上述要求選項無法覆寫此限制：

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

超過此限制時，最可能相關的查詢運算子是 join、 summarize或 make-series。 若要解決限制，應該修改查詢以使用 隨機查詢 策略。 （這也可能會改善查詢的效能。

在所有 情況下 E_RUNAWAY_QUERY，除了設定要求選項和變更查詢以使用隨機策略來增加限制之外，其他選項是切換至取樣。 下列兩個查詢示範如何進行取樣。 第一個查詢是使用隨機數產生器進行統計取樣。 第二個查詢是具決定性的取樣，方法是從數據集哈希某些數據行，通常是一些標識符。

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

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

每個節點的記憶體限制

每個節點 每個查詢的記憶體上限是用來防止「失控」查詢的另一個限制。 這個限制，以要求選項 max_memory_consumption_per_query_per_node表示，會設定可在單一節點上用於特定查詢的記憶體數量上限。

set max_memory_consumption_per_query_per_node=68719476736;
MyTable | ...

如果 max_memory_consumption_per_query_per_node 設定多次，例如，在用戶端要求屬性和使用 set 語句中，則會套用較低的值。

如果查詢使用 summarize、 join或 make-series 運算子，您可以使用 隨機查詢 策略來降低單一計算機上的記憶體壓力。

限制執行逾時

伺服器逾時 是套用至所有要求的服務端逾時。 執行要求逾時（查詢和管理命令）會在 Kusto 中的多個點強制執行：

  • 用戶端連結庫 （如果使用）
  • 接受要求的服務端點
  • 處理要求的服務引擎

根據預設，查詢的逾時會設定為四分鐘，而管理命令則設定為10分鐘。 如有需要，此值可以增加（上限為一小時）。

  • 各種用戶端工具支援變更逾時，作為其全域或每個連線設定的一部分。 例如，在 Kusto.Explorer 中，使用 [工具>選項] *> [連線>查詢伺服器逾時]。
  • 以程序設計方式，SDK 支援透過 servertimeout 屬性設定逾時。 例如，在 .NET SDK 中，這會透過 用戶端要求屬性來完成，方法是設定 類型的 System.TimeSpan值。

逾時注意事項

  • 在用戶端上，系統會從所建立的要求套用逾時，直到響應開始抵達客戶端為止。 在用戶端上讀取承載所需的時間不會被視為逾時的一部分。 這取決於呼叫端從數據流提取數據的速度。
  • 此外，在用戶端上，所使用的實際逾時值略高於使用者所要求的伺服器逾時值。 這項差異是允許網路等待時間。
  • 若要自動使用允許的要求逾時上限，請將用戶端要求屬性 norequesttimeout 設定為 true。

注意

如需如何在 Azure 數據總管 Web UI、Kusto.Explorer、Kusto.Cli、Power BI 和使用 SDK 時設定逾時，請參閱 設定逾時限制 。

查詢 CPU 資源使用量的限制

Kusto 可讓您執行查詢，並使用資料庫擁有的所有可用 CPU 資源。 如果執行多個查詢，它會嘗試在查詢之間執行一個公平的迴圈配置資源。 此方法會產生查詢定義函式的最佳效能。 在其他時候，您可能想要限制用於特定查詢的 CPU 資源。 例如，如果您執行「背景作業」，系統可能會容許較高的延遲，以提供並行內嵌查詢高優先順序。

Kusto 支援在執行查詢時指定兩 個要求屬性 。 屬性是 query_fanout_threads_percent 和 query_fanout_nodes_percent。 這兩個屬性都是預設值為最大值的整數（100），但特定查詢可能會縮減為一些其他值。

第一個 query_fanout_threads_percent控制線程使用的扇出因數。 當此屬性設定為 100%時，所有 CPU 都會在每個節點上指派。 例如，部署在 Azure D14 節點上的 16 個 CPU。 當此屬性設定為 50%，則會使用一半的 CPU 等等。 數位會四捨五入為整個CPU，因此將屬性值設定為0是安全的。

第二個 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")
  • 具有聯集運算子的查詢，其執行範圍太廣的架構分析，特別是聯集的默認類別是傳回「外部」等位架構（也就是說，輸出會包含基礎表的所有數據行）。

在此情況下，建議檢閱查詢，並減少查詢所使用的數據行。

相關內容