캐시 정책(핫 및 콜드 캐시)

Azure Data Explorer 수집된 데이터를 실제 처리(예: Azure Compute) 노드에서 멀리 떨어진 신뢰할 수 있는 스토리지(가장 일반적으로 Azure Blob Storage)에 저장합니다. 해당 데이터에 대한 쿼리 속도를 높이기 위해 Azure Data Explorer 처리 노드, SSD 또는 RAM에서 캐시합니다. Azure Data Explorer 캐시할 데이터 개체를 지능적으로 결정하도록 설계된 정교한 캐시 메커니즘을 포함합니다. 캐시를 사용하면 Azure Data Explorer 사용하는 데이터 아티팩트 설명이 가능하므로 더 중요한 데이터가 우선 순위를 지정할 수 있습니다. 예를 들어 열 인덱스 및 열 데이터 분할된 데이터베이스입니다.

수집된 모든 데이터가 캐시될 때 최상의 쿼리 성능이 달성됩니다. 경우에 따라 특정 데이터는 로컬 SSD 스토리지에서 "웜"을 유지하는 비용을 정당화하지 않습니다. 예를 들어 많은 팀에서는 오래된 로그 레코드에 거의 액세스하지 않는 것이 덜 중요하다고 간주합니다. 항상 따뜻하게 유지하기 위해 비용을 지불하는 대신 이 데이터를 쿼리할 때 성능이 저하되는 것을 선호합니다.

Azure Data Explorer 캐시는 고객이 핫 데이터 캐시와 콜드 데이터 캐시를 구분하는 데 사용할 수 있는 세분화된 캐시 정책을 제공합니다. Azure Data Explorer 캐시는 로컬 SSD 디스크의 95%를 사용하여 핫 데이터 캐시 범주에 속하는 모든 데이터를 유지합니다. 캐시 정책에 사용 가능한 로컬 SSD 디스크보다 더 많은 디스크 공간이 필요한 경우 가장 최근의 데이터는 우선적으로 캐시에 유지됩니다. 로컬 SSD 공간의 나머지 5%는 핫으로 분류되지 않은 데이터를 보관하는 데 사용됩니다.

이 디자인의 한 가지 유용한 의미는 신뢰할 수 있는 스토리지에서 많은 콜드 데이터를 로드하는 쿼리가 핫 데이터 캐시에서 데이터를 제거하지 않는다는 것입니다. 이러한 쿼리는 핫 데이터 캐시의 데이터와 관련된 다른 쿼리에 큰 영향을 주지 않습니다.

핫 캐시 정책 설정의 주요 의미는 다음과 같습니다.

  • 비용: 신뢰할 수 있는 스토리지 비용은 로컬 SSD보다 훨씬 낮을 수 있습니다. 현재 Azure에서 약 45배 저렴합니다.
  • 성능: 데이터가 로컬 SSD에 있을 때, 특히 많은 양의 데이터를 검색하는 범위 쿼리에 대해 더 빠르게 쿼리됩니다.

캐시 정책 명령을 사용하여 캐시 정책을 관리합니다.

Azure Data Explorer 클러스터의 총 RAM에 맞는 중간 결과 집합이 있는 임시 쿼리용으로 설계되었습니다. SSD와 같은 영구 스토리지에 중간 결과를 저장하려는 map-reduce와 같은 대규모 작업의 경우 연속 내보내기 기능을 사용합니다. 이 기능을 사용하면 HDInsight 또는 Azure Databricks와 같은 서비스를 사용하여 장기 실행 일괄 처리 쿼리를 수행할 수 있습니다.

캐시 정책 적용 방법

데이터가 Azure Data Explorer 수집되는 경우 시스템은 수집 날짜와 시간 및 생성된 범위를 추적합니다. 익스텐트의 수집 날짜 및 시간 값(또는 익스텐트를 여러 기존 익스텐트에서 빌드한 경우 최대값)은 캐시 정책을 평가하는 데 사용됩니다.

참고

수집 속성을 creationTime사용하여 수집 날짜 및 시간에 대한 값을 지정할 수 있습니다. 이렇게 할 때 테이블의 유효 익스텐트 병합 정책의 속성이 설정한 creationTime값과 일치하는지 확인 Lookback 합니다.

기본적으로 유효 정책은 null모든 데이터가 으로 간주됨을 의미합니다. null 테이블 수준의 정책은 정책이 데이터베이스에서 상속됨을 의미합니다. null 테이블 수준 이외의 정책은 데이터베이스 수준 정책을 재정의합니다.

핫 캐시에 대한 쿼리 범위 지정

Kusto는 핫 캐시 데이터로만 범위가 지정된 쿼리를 지원합니다.

참고

데이터 범위 지정은 테이블 및 구체화된 뷰와 같은 캐싱 정책을 지원하는 엔터티에만 적용됩니다. 행 저장소의 외부 테이블 및 데이터와 같은 다른 엔터티에 대해서는 무시됩니다.

몇 가지 쿼리 가능성이 있습니다.

  • 쿼리에 호출 query_datascope 된 클라이언트 요청 속성을 추가합니다. 가능한 값: default, allhotcache.
  • set 쿼리 텍스트set query_datascope='...'에 다음 문을 사용합니다. 가능한 값은 클라이언트 요청 속성과 동일합니다.
  • 쿼리 본문에서 datascope=... 테이블 참조 바로 뒤의 텍스트를 추가합니다. 가능한 값은 allhotcache입니다.

이 값은 default 쿼리가 모든 데이터를 포함해야 한다고 결정하는 클러스터 기본 설정의 사용을 나타냅니다.

다른 메서드 set 간에 불일치가 있는 경우 클라이언트 요청 속성보다 우선합니다. 테이블 참조에 대한 값을 지정하는 것이 둘 다보다 우선합니다.

예를 들어 다음 쿼리에서 모든 테이블 참조는 모든 데이터로 범위가 지정된 "T"에 대한 두 번째 참조를 제외하고 핫 캐시 데이터만 사용합니다.

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

캐시 정책 및 보존 정책

캐시 정책은 보존 정책과 독립적입니다.

  • 캐시 정책은 리소스의 우선 순위를 지정하는 방법을 정의합니다. 중요한 데이터에 대한 쿼리는 더 빠릅니다.
  • 보존 정책은 테이블/데이터베이스(특히 SoftDeletePeriod)에서 쿼리 가능한 데이터의 범위를 정의합니다.

예상된 쿼리 패턴에 따라 비용과 성능 간의 최적 균형을 달성하도록 이 정책을 구성합니다.

예제:

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

이 예제에서 데이터의 마지막 28일은 클러스터 SSD에 있고 추가 28일의 데이터는 Azure Blob Storage에 저장됩니다. 전체 56일 동안의 데이터에서 쿼리를 실행할 수 있습니다.

추가 정보