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

  • 아티클

Azure Data Explorer 다중 계층 데이터 캐시 시스템을 사용하여 빠른 쿼리 성능을 보장합니다. 데이터는 Azure Blob Storage 같은 신뢰할 수 있는 스토리지에 저장되지만, 그 중 일부는 더 빠른 액세스를 위해 노드, SSD 또는 RAM에서 캐시됩니다.

Real-Time Analytics는 다중 계층 데이터 캐시 시스템을 사용하여 빠른 쿼리 성능을 보장합니다. 데이터는 OneLake와 같은 신뢰할 수 있는 스토리지에 저장되지만, 그 중 일부는 더 빠른 액세스를 위해 처리 노드, SSD 또는 RAM에 캐시됩니다.

캐싱 정책을 사용하면 캐시할 데이터를 선택할 수 있습니다. 핫 데이터에 대한 캐싱 정책을 설정하여 핫 데이터 캐시와 콜드 데이터 캐시를 구분할 수 있습니다. 핫 데이터는 더 빠른 쿼리 성능을 위해 로컬 SSD 스토리지에 유지되고 콜드 데이터는 신뢰할 수 있는 스토리지에 저장되며, 이 스토리지는 저렴하지만 액세스 속도가 느립니다.

캐시는 핫 데이터에 로컬 SSD 디스크의 95%를 사용합니다. 공간이 충분하지 않은 경우 가장 최근의 데이터는 우선적으로 캐시에 보관됩니다. 나머지 5%는 핫으로 분류되지 않은 데이터에 사용됩니다. 이 디자인은 많은 콜드 데이터를 로드하는 쿼리가 캐시에서 핫 데이터를 제거하지 않도록 합니다.

수집된 모든 데이터가 캐시될 때 최상의 쿼리 성능이 달성됩니다. 그러나 특정 데이터는 핫 캐시에 보관되는 비용을 보증하지 않을 수 있습니다. instance 경우 자주 액세스하지 않는 이전 로그 레코드는 덜 중요한 것으로 간주될 수 있습니다. 이러한 경우 팀은 데이터를 따뜻하게 유지하기 위해 지불보다 낮은 쿼리 성능을 선택하는 경우가 많습니다.

관리 명령을 사용하여 데이터베이스, 테이블 또는 구체화된 뷰 수준에서 캐싱 정책을 변경합니다.

관리 명령을 사용하여 클러스터, 데이터베이스, 테이블 또는 구체화된 뷰 수준에서 캐싱 정책을 변경합니다.

팁

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

캐싱 정책이 적용되는 방법

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

참고

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

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

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

쿼리를 실행할 때 핫 캐시의 데이터만 쿼리하도록 scope 제한할 수 있습니다.

참고

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

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

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

값은 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일 동안의 데이터에서 쿼리를 실행할 수 있습니다.

관련 콘텐츠