共用方式為

查詢限制

適用於：✅Microsoft網狀架構✅✅

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 的任何子查詢，其效果類似。

設定多個結果截斷屬性

當你在客戶端請求屬性中使用set語句或指定旗標時，會適用以下規則。

  • 如果你設定 notruncation ，但同時設定 truncationmaxsize、 truncationmaxrecords或 query_take_max_records，服務會 notruncation忽略 。
  • 如果你設定 truncationmaxsize、 或truncationmaxrecordsquery_take_max_records多次，服務會使用每個屬性的較低值。

查詢運算子所佔用的記憶體限制

每個迭代器的最大記憶體使用 限制可設定為控制每個查詢運算元在每個節點所消耗的記憶體量。 有些查詢運算子，如 join 和 summarize，會保留大量資料在記憶體中。 透過提高請求選項 maxmemoryconsumptionperiterator的預設值，你可以執行需要每個運算元更多記憶體的查詢。

此要求選項的最大支援值為 32212254720 （30 GB）。 如果你多次設定 maxmemoryconsumptionperiterator ，例如同時在客戶請求屬性和使用 set 語句時，較低的值會適用。

當查詢達到設定的每位運算子記憶體上限時，會顯示部分查詢失敗訊息，並包含文字 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 部分查詢失敗的限制是單一運算符所持有字串的最大累積大小。 上述請求選項無法覆蓋這個限制。

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 | ...

關於使用 hint.shufflekey 等機制來處理 summarize 和 join的更多資訊，請參見 Kusto 查詢語言查詢的最佳實務。

每個節點的記憶體限制

每個節點 每個查詢的記憶體上限是用來防止「失控」查詢的另一個限制。 這個限制，以要求選項 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")
  • 查詢中有一個 union 運算子執行過於寬泛的結構分析，尤其是 union 的預設版本是回傳「外部」union 架構（也就是說——該輸出包含底層資料表的所有欄位）。

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

相關內容

  • Last updated on