쿼리 제한

적용 대상: ✅Microsoft Fabric✅Azure Data Explorer✅Azure Monitor✅Microsoft Sentinel

Kusto는 대용량 데이터 세트를 호스트하고 모든 관련 데이터를 메모리에 보관하여 쿼리를 충족하려고 시도하는 임시 쿼리 엔진입니다. 쿼리가 범위 없이 서비스 리소스를 독점할 수 있는 내재된 위험이 있습니다. Kusto는 기본 쿼리 제한의 형태로 몇 가지 기본 제공 보호를 제공합니다. 이러한 제한을 제거하는 것을 고려하는 경우 먼저 실제로 값을 얻을 수 있는지 여부를 결정합니다.

요청 동시성 제한

요청 동시성은 동시에 실행되는 여러 요청에 적용되는 제한입니다.

• 제한의 기본값은 데이터베이스가 실행 중인 SKU에 따라 달라지고 다음과 Cores-Per-Node x 10같이 계산됩니다.
  • 예를 들어 각 컴퓨터에 16개의 vCore가 있는 D14v2 SKU에 설정된 데이터베이스의 경우 기본 제한은 다음과 같습니다 16 cores x10 = 160.
• 워크로드 그룹의 요청 속도 제한 정책을 구성하여 기본값을 default 변경할 수 있습니다.
  • 데이터베이스에서 동시에 실행할 수 있는 실제 요청 수는 다양한 요인에 따라 달라집니다. 가장 중요한 요소는 데이터베이스 SKU, 데이터베이스의 사용 가능한 리소스 및 사용 패턴입니다. 프로덕션과 유사한 사용 패턴에서 수행되는 부하 테스트에 따라 정책을 구성할 수 있습니다.

결과 집합 크기 제한(결과 잘림)

결과 잘림 은 쿼리에서 반환된 결과 집합에 대해 기본적으로 설정된 제한입니다. Kusto는 클라이언트에 반환되는 레코드 수를 500,000개로 제한하고 해당 레코드의 전체 데이터 크기를 64MB로 제한합니다. 두 제한 중 하나라도 초과하면 "부분 쿼리 오류"와 함께 쿼리가 실패합니다. 전체 데이터 크기를 초과하면 다음과 같은 메시지와 함께 예외가 생성됩니다.

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 함수를 사용하여 넓은 자유 텍스트 열을 자릅니다.
• 프로젝트 연산자를 사용하여 결과 집합에서 무관심한 열을 삭제합니다.

요청 옵션을 사용하여 결과 잘림을 notruncation 사용하지 않도록 설정할 수 있습니다. 어떤 형태의 제한 사항은 여전히 적용하는 것이 좋습니다.

예시:

set notruncation;
MyTable | take 1000000

또한 값(최대 데이터 크기(바이트), 기본값 64MB) 및 truncationmaxrecords (최대 레코드 수, 기본값: 500,000)의 값을 truncationmaxsize 설정하여 결과 잘림을 보다 세밀하게 제어할 수 있습니다. 예를 들어 다음 쿼리는 레코드 1,105개 또는 1MB 제한 중 하나를 초과할 때 결과 잘림이 발생하도록 설정합니다.

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이 무시됩니다.
• 및/또는 query_take_max_records 여러 번 설정된 경우 truncationmaxsize각 속성에 대한 더 낮은 값이 적용됩니다. truncationmaxrecords

쿼리 연산자가 사용하는 메모리 제한(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).

클라이언트 요청 속성과 set 문을 사용할 때 maxmemoryconsumptionperiterator가 여러 번 설정된 경우 더 낮은 값이 적용됩니다.

부분 쿼리 실패를 E_RUNAWAY_QUERY 트리거할 수 있는 추가 제한은 단일 연산자가 보유한 최대 누적 문자열 크기에 대한 제한입니다. 이 제한은 위의 요청 옵션으로 재정의할 수 없습니다.

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

이 제한을 초과하면 관련 쿼리 연산자가 < summarizea0join/> 또는 make-series.입니다. 제한을 해결하려면 쿼리 순서 섞기 전략을 사용하도록 쿼리를 수정해야 합니다. (쿼리의 성능도 향상될 수 있습니다.)

모든 경우 E_RUNAWAY_QUERY에서 추가 옵션(요청 옵션을 설정하고 순서 섞기 전략을 사용하도록 쿼리를 변경하여 제한을 늘리는 것 이상)은 샘플링으로 전환하는 것입니다. 아래 두 쿼리는 샘플링을 수행하는 방법을 보여 줍니다. 첫 번째 쿼리는 난수 생성기를 사용하는 통계 샘플링입니다. 두 번째 쿼리는 결정적 샘플링이며, 데이터 세트에서 일부 열(일반적으로 일부 ID)을 해시하여 수행합니다.

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

클라이언트 요청 속성과 set 문을 사용할 때 max_memory_consumption_per_query_per_node가 여러 번 설정된 경우 더 낮은 값이 적용됩니다.

쿼리에서 summarize, join 또는 make-series 연산자를 사용하는 경우 셔플 쿼리 전략을 사용하여 단일 머신에서 메모리 압력을 줄일 수 있습니다.

실행 제한 시간 제한

서버 시간 제한 은 모든 요청에 적용되는 서비스 쪽 시간 제한입니다. 실행 중인 요청(쿼리 및 관리 명령)에 대한 시간 제한은 Kusto의 여러 지점에서 적용됩니다.

• 클라이언트 라이브러리(사용되는 경우)
• 요청을 수락하는 서비스 엔드포인트
• 요청을 처리하는 서비스 엔진

기본적으로 시간 제한은 쿼리의 경우 4분, 관리 명령의 경우 10분으로 설정됩니다. 필요한 경우 이 값을 늘릴 수 있습니다(1시간으로 제한).

• 다양한 클라이언트 도구는 전역 또는 연결별 설정의 일부로 시간 제한을 변경할 수 있도록 지원합니다. 예를 들어 Kusto.Explorer에서 도구>옵션*> 연결>쿼리 서버 시간 제한을 사용합니다.
• 프로그래밍 방식으로 SDK는 속성 전체 servertimeout 의 시간 제한 설정을 지원합니다. 예를 들어 .NET SDK에서 이 작업은 형식의 값을 설정하여 클라이언트 요청 속성을 통해 수행됩니다System.TimeSpan.

시간 제한에 대한 참고 사항

• 클라이언트 쪽에서는 응답이 클라이언트에 도착하기 시작할 때까지 생성되는 요청에서 시간 제한이 적용됩니다. 클라이언트에서 페이로드를 읽는 데 걸리는 시간은 시간 제한에 포함되지 않습니다. 이 시간은 호출자가 스트림에서 데이터를 가져오는 속도에 따라 달라집니다.
• 또한 클라이언트 쪽에서 사용되는 실제 시간 제한 값은 사용자가 요청한 서버 제한 시간 값보다 약간 높습니다. 이러한 차이점은 네트워크 대기 시간을 허용하는 것입니다.
• 허용되는 최대 요청 시간 제한을 자동으로 사용하려면 클라이언트 요청 속성을 norequesttimeout true.로 설정합니다.

쿼리 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 하위 쿼리 배포 작업당 사용할 쿼리 노드 수를 제어합니다. 비슷한 방식으로 작동합니다.

예를 들어 클라이언트 요청 속성과 문 사용 set 모두에서 여러 번 설정되거나 query_fanout_threads_percent 설정된 경우 query_fanout_nodes_percent 각 속성에 대한 더 낮은 값이 적용됩니다.

쿼리 복잡성 제한

쿼리를 실행하는 동안 쿼리 텍스트는 쿼리를 나타내는 관계형 연산자 트리로 변환됩니다. 트리 깊이가 내부 임계값을 초과하면 처리하기에 너무 복잡한 쿼리로 간주되고 오류 코드와 함께 쿼리가 실패합니다. 이 오류는 관계형 연산자 트리가 해당 제한을 초과했음을 나타냅니다.

다음 예에서는 쿼리가 이 제한을 초과하여 실패할 수 있는 일반적인 쿼리 패턴을 보여줍니다.

• 함께 연결된 이진 연산자의 긴 목록입니다. 예시:

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

이 특정 사례의 경우 연산자를 사용하여 쿼리를 다시 작성합니다 in() .

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

• 너무 넓은 스키마 분석을 실행하는 공용 구조체 연산자가 있는 쿼리입니다. 특히 공용 구조체의 기본 맛은 "외부" 공용 구조체 스키마를 반환하는 것입니다(즉, 출력에 기본 테이블의 모든 열이 포함됨).

이 경우 쿼리를 검토하고 쿼리에서 사용되는 열을 줄이는 것이 제안됩니다.

관련 콘텐츠

• 쿼리 모범 사례