하이브리드 테이블 모범 사례¶

Snowsight의 쿼리 성능과 드라이버 기반 액세스 비교¶

Snowsight 는 쿼리 계획, 데이터 통계, 쿼리 기록 및 대화형 쿼리 프로토타이핑, 디버깅, 조사, 모니터링 및 기타 활동에 유용한 기타 세부 정보에 대한 풍부한 액세스를 제공합니다. 이러한 풍부한 대화형 경험을 제공하면 Snowflake 쿼리 엔진에 오버헤드가 추가됩니다. 따라서 Snowsight 를 통해 실행되는 단기 실행 쿼리의 지연 시간은 프로그래밍 방식 드라이버로 달성할 수 있는 성능을 나타내지 않습니다. 코드 기반 또는 드라이버 기반 솔루션을 통해 실행되는 쿼리는 Snowsight 를 통해 실행되는 쿼리보다 지연 시간과 변수가 더 낮게 실행됩니다.

하이브리드 테이블용 클라이언트 드라이버¶

하이브리드 테이블에 액세스하려면 다음 드라이버 버전 중 하나를 사용해야 합니다.

드라이버	최소 버전
Go	1.6.25
JDBC	3.13.31
.Net	2.1.2
Node.js	1.9.0
ODBC	3.0.2
PHP	2.0.0
Python Connector	3.1.0
SnowSQL	1.2.28

참고

이전 드라이버 버전을 사용하는 경우 하이브리드 테이블에 액세스하지 못할 수 있습니다.

하이브리드 테이블의 성능을 최적화하려면 선택한 드라이버의 최신 버전을 사용해야 합니다.

Snowflake SQL API 를 사용하여 하이브리드 테이블에 액세스할 수도 있지만, 지연 시간이 최적화되어야 하는 사용 사례에는 이 API 를 사용하지 않는 것이 좋습니다.

클라이언트 구성 및 액세스 방법¶

연결 관리는 성능과 확장성에 직접적인 영향을 미칩니다. 하이브리드 테이블이 포함된 데이터베이스에 연결할 때 좋은 성능을 얻으려면 다음 모범 사례를 고려하십시오.

• 수명이 긴 연결과 함께 연결 풀링을 사용하면 새 연결을 반복적으로 설정하는 데 따른 오버헤드를 없앨 수 있습니다. Snowflake에 연결하는 대부분의 클라이언트 프레임워크는 액세스를 효율적으로 관리하기 위해 연결 풀링 메커니즘을 제공합니다.

• 네트워크 근접성은 엔드투엔드 지연 시간에 큰 영향을 미치므로 클라이언트 소프트웨어를 Snowflake 계정과 동일한 클라우드 리전에 코로케이션하십시오.

• 쿼리 플래너가 이전에 생성한 쿼리 계획을 재사용할 수 있도록 매개 변수가 바인딩된 준비된 문을 사용하십시오.

• 지연 시간을 최적화하려면 Snowsight 가 아닌 지원되는 프로그래밍 방식 클라이언트 드라이버를 사용하십시오. 하이브리드 테이블용 클라이언트 드라이버 섹션을 참조하십시오.

인덱스 디자인 및 사용법¶

인덱스 생성 및 사용은 하이브리드 테이블의 성능을 최적화하기 위한 핵심 요소입니다. 다음 권장 사항을 고려하십시오.

• 자주 사용하는 조건자에 대한 보조 인덱스를 생성합니다.

• 완전한 쿼리 패턴에 맞는 복합 인덱스를 설계하십시오.

• 열이 같은 서수 위치에 있는 인덱스를 여러 개 사용하지 마십시오.

• 인덱스를 생성하기 전에 데이터의 카디널리티를 이해하십시오. 카디널리티가 낮은 단일 열로 구축된 인덱스는 이점이 제한적입니다. 고유 값 개수 추정하기 섹션을 참조하십시오.

• 인덱스는 쓰기 오버헤드 및 저장소 요구 사항을 추가합니다. 지연 시간이 짧은 쓰기 작업이 필요한 애플리케이션의 경우 읽기 성능과 쓰기 성능의 균형에 주의하십시오.

적절하게 설계된 인덱스는 효율적인 데이터 액세스 경로를 제공함으로써 쿼리 성능을 크게 향상시킵니다. 가능하면 복잡성을 최소화하면서 선택성을 최적화할 수 있는 기본 키를 선택하십시오. 경우에 따라 계산된 키 또는 대체 키 값을 가진 열을 추가하면 복잡한 복합 인덱스보다 더 나은 성능을 제공합니다. 보조 인덱스는 자주 액세스하는 열의 성능을 획기적으로 개선합니다.

잘 정의된 쿼리의 경우 테이블을 생성할 때 INCLUDE 키워드를 사용하여 인덱스에 열을 추가하면 지연 시간을 더욱 줄일 수 있습니다. INCLUDE 열이 있는 보조 인덱스 만들기 섹션을 참조하십시오.

CREATE OR REPLACE HYBRID TABLE icecream_orders (
  id NUMBER PRIMARY KEY AUTOINCREMENT START 1 INCREMENT 1 ORDER,
  store_id NUMBER NOT NULL,
  flavor VARCHAR(20) NOT NULL,
  order_ts TIMESTAMP_NTZ,
  num_scoops NUMERIC,
  INDEX idx_icecream_order_store (store_id, order_ts),
  INDEX idx_icecream_timestamp (order_ts)
  );

-- Generate sample data for testing

INSERT INTO icecream_orders (store_id, flavor, order_ts, num_scoops)
  SELECT
    UNIFORM(1, 10, RANDOM()),
    ARRAY_CONSTRUCT('CHOCOLATE', 'VANILLA', 'STRAWBERRY', 'LEMON')[UNIFORM(0, 3, RANDOM())],
    DATEADD(SECOND, UNIFORM(0, 86400, RANDOM()), DATEADD(DAY, UNIFORM(-90, 0, RANDOM()), CURRENT_DATE())),
    UNIFORM(1, 3, RANDOM())
  FROM TABLE(GENERATOR(ROWCOUNT => 10000))
  ;

-- Use idx_icecream_order_store (first column)

  SELECT *
    FROM icecream_orders
    WHERE store_id = 5;

-- Use idx_icecream_order_store (both columns)

  SELECT *
    FROM icecream_orders
    WHERE store_id IN (1,2,3) AND order_ts > DATEADD(DAY, -7, CURRENT_DATE());

-- Use idx_icecream_timestamp

  SELECT *
    FROM icecream_orders
    WHERE order_ts BETWEEN DATEADD(DAY, -2, CURRENT_DATE()) AND DATEADD(DAY, -2, CURRENT_DATE());

데이터 대량 로딩 중¶

하이브리드 테이블에 데이터를 로딩할 때 몇 가지 최적화 및 모범 사례를 사용할 수 있습니다.

• 빈 테이블을 생성하고 즉시 로드하려면 CREATE TABLE … AS SELECT(CTAS라고도 함) 를 사용하십시오.

• 쿼리 프로필에서 최적화된 대량 로딩을 사용하는지 확인합니다.

• 초기 데이터 로딩을 단일 대량 트랜잭션으로 선호합니다.

하이브리드 테이블은 최적화된 대량 로딩 경로를 제공하여 표준 로딩 방식보다 최대 10배 빠른 로딩 성능을 제공합니다. 이 최적화된 대량 로딩 경로는 CTAS (CREATE TABLE AS SELECT), COPY INTO 또는 INSERT INTO SELECT 명령을 사용하여 빈 테이블에 데이터를 로드할 때 자동으로 적용됩니다. (빈 테이블은 데이터를 포함하지 않은 테이블입니다.)

쿼리 프로필의 통계 섹션에서 행이 Number of rows inserted 가 아닌 Number of rows bulk loaded 로 보고되는 것을 확인하여 최적화가 사용 중인지 확인할 수 있습니다.

이미 데이터가 포함된 테이블의 경우 현재 최적화된 대량 로딩 경로를 사용할 수 없습니다. 이 경우 로딩 작업은 레코드 크기, 테이블 구조, 인덱스 수에 따라 다르지만 분당 약 1백만 개의 레코드를 처리할 수 있습니다.

웨어하우스 최적화¶

X-Small 크기의 웨어하우스는 많은 작업 워크로드에 충분합니다. 단기 실행 작업 쿼리의 동시성과 처리량을 높이려면 더 큰 웨어하우스로 컴퓨팅 리소스를 늘리기보다는 멀티 클러스터 웨어하우스 를 사용하여 컴퓨팅 노드 수를 늘리십시오.

워크로드에 가변 처리량 패턴이 있는 경우 자동 크기 조정을 활성화하여 수요가 낮을 때 소비를 줄일 수 있습니다. 높은 처리량 또는 짧은 지연 시간이 요구되는 워크로드에서 최상의 성능과 효율성을 얻으려면 확장 정책을 Economy 대신 Standard 로 설정하십시오. 자세한 내용은 멀티 클러스터 웨어하우스에 대한 크기 조정 정책 설정하기 섹션을 참조하십시오.

경우에 따라 워크로드를 별도의 웨어하우스에 격리하는 것이 독립적인 확장을 가능하게 하는 데 도움이 될 수 있습니다. 작업 및 분석 구성 요소가 혼합된 하이브리드 워크로드가 있는 경우, 작업 구성 요소와 분석 구성 요소를 서로 다른 웨어하우스에 분리하는 것이 좋습니다. 분리할 수 없고 동일한 웨어하우스에서 함께 실행해야 하는 경우, 분석 쿼리 지연 시간 필수 권한을 기준으로 웨어하우스 크기를 선택하고 워크로드의 처리량을 지원하는 데 필요한 멀티클러스터 노드 수를 선택하십시오.

캐시 및 워밍업¶

새로 시작된 데이터 웨어하우스에 처음으로 발행된 하이브리드 테이블 쿼리는 쿼리 계획, 인덱스 선택, 데이터 로딩을 위한 I/O, 캐시 결정 및 쿼리 실행과 같은 활동을 트리거합니다. 쿼리 엔진은 쿼리에 대한 메모리와 저장소를 계속 최적화합니다. 이 기간을 “워밍업” 기간이라고 합니다. 엔진이 정상 상태 지연 시간에 수렴할 때까지 쿼리 지연 시간이 감소합니다.

• 캐시 간섭을 피하려면 하이브리드 테이블 워크로드에 전용 웨어하우스를 사용하십시오.

• 캐시가 예열되면서 정상 상태 지연 시간에 도달하는 데 몇 초에서 2~3분 정도 걸립니다.

• 자동 일시 중단 및 자동 크기 조정을 구성하여 효율성과 캐시 온도의 균형을 맞출 수 있습니다.

하이브리드 테이블은 여러 캐시 접근법을 활용하여 성능을 최적화합니다. 계획 캐시는 자주 사용하는 쿼리 계획을 저장하여 컴파일 오버헤드를 줄여줍니다. 컬럼 저장소 데이터 캐시는 자주 액세스하는 데이터를 메모리에 유지하고, 메타데이터 캐시는 테이블 및 인덱스 정보에 빠르게 액세스할 수 있도록 합니다. 하이브리드 테이블은 결과 캐시를 사용하지 않습니다.

이러한 캐시는 워크로드 패턴에 최적화하는 데 약간의 시간이 필요합니다. 하이브리드 테이블 워크로드에 전용 웨어하우스를 사용하면 다른 워크로드로부터 캐시 간섭을 방지할 수 있습니다. 콜드 스타트 후 초기 쿼리는 캐시가 채워질 때까지 지연 시간이 더 길어집니다. 워크로드의 처리량 패턴이 가변적인 경우 자동 확장 및 자동 일시 중단을 활성화하여 사용량을 줄이거나 수요가 적을 때 웨어하우스를 일시 중단할 수 있습니다. 웨어하우스가 다시 시작되거나 오토스케일이 수행되어 새 클러스터가 추가되면 캐시가 재수화되어야 합니다. 최상의 성능을 위해 확장 정책을 Economy 가 아닌 Standard 로 설정하십시오. 멀티 클러스터 웨어하우스 섹션을 참조하십시오.

저장 프로시저 및 하이브리드 테이블¶

하이브리드 테이블에 대해 저장 프로시저가 지원되지만, AUTOCOMMIT 이 활성화된 트랜잭션이나 다중 문 트랜잭션을 실행하면 저장 프로시저를 호출하는 것보다 성능과 효율성이 더 좋습니다.

서버리스 작업 및 하이브리드 테이블¶

서버리스 작업이 지원되지만 하이브리드 테이블을 사용하는 워크로드에서는 최적의 성능이나 효율성을 경험하지 못할 수 있다는 점에 유의하십시오.

성능 모니터링¶

하이브리드 테이블 성능 모니터링에 사용하는 것이 권장되는 뷰는 AGGREGATE_QUERY_HISTORY 뷰 입니다. 이 뷰에는 짧은 기간 동안 집계된 쿼리 실행 세부 정보가 포함되어 있습니다.

예를 들어, 하이브리드 테이블 요청을 서비스하는 웨어하우스에 대한 지난 24시간 동안의 평균 기본 간격 성능을 검색할 수 있습니다.

SELECT *
  FROM SNOWFLAKE.ACCOUNT_USAGE.AGGREGATE_QUERY_HISTORY
  WHERE warehouse_name = 'HYBRID_TABLES_WAREHOUSE'
  AND query_type = 'SELECT'
  AND interval_start_time >= DATEADD(hour, -24, CURRENT_TIMESTAMP());

자세한 예제는 AGGREGATE_QUERY_HISTORY 뷰 섹션을 참조하십시오.

쿼터 및 스로틀링 모니터링¶

하이브리드 테이블은 하이브리드 저장소 및 하이브리드 테이블 요청 처리량 모두에 대해 계정 수준에서 할당량 제어를 구현합니다. 이러한 할당량은 모든 사용자에게 일관된 성능을 보장합니다. 기본 할당량은 대부분의 초기 구현에 충분하지만 워크로드가 증가함에 따라 조정이 필요할 수 있습니다.

• AGGREGATE_QUERY_HISTORY 뷰 를 사용하여 하이브리드 테이블 요청 할당량을 모니터링합니다.

• STORAGE_USAGE 뷰 를 사용하여 하이브리드 저장소 할당량을 모니터링합니다.

• 쿼리 프로필의 스로틀링 비율이 높으면 처리량 제한에 가까워지고 있음을 의미합니다. 두 할당량의 70% 이상을 지속적으로 사용하는 경우 Snowflake 지원을 통해 적극적으로 증량을 요청하십시오.

하이브리드 테이블의 성능은 가상 웨어하우스 컴퓨팅 사용량이 많지 않은 경우에도 스로틀링될 수 있습니다. 사용량을 모니터링하고 하이브리드 테이블이 제한되고 있는지 확인하려면 AGGREGATE_QUERY_HISTORY 뷰 의 예를 참조하십시오. HYBRID_TABLE_REQUESTS_THROTTLED_COUNT 열에서 제한된 하이브리드 테이블 요청 수를 검색할 수도 있습니다.

자세한 내용은 할당량 및 제한 섹션을 참조하십시오.

성능 문제 해결하기¶

이러한 모범 사례를 구현한 후에도 기대한 성능을 얻지 못하는 경우 Snowflake 지원팀에서 구현을 분석하고 최적화하는 데 도움을 받을 수 있습니다. 지원 케이스를 만들 때 신속한 해결을 위해 다음 정보를 포함하십시오.

• IDs (UUIDs)에서 차선책 성능을 보여주는 대표 쿼리를 확인하십시오

• 워크로드 특성:

  • 일반적인 쿼리 패턴

  • 예상 지연 시간과 실제 지연 시간 비교

  • 동시성 요구 사항

  • 데이터 저장소 용량

  • 쿼리 응답 행 크기

  • 열 카디널리티 추정

• 테이블 스키마, 인덱스 또는 워크로드 패턴에 대한 최근 변경 사항

• 쿼리 프로필의 메트릭 스로틀링

• 저온 웨어하우스와 고온 웨어하우스의 성능 차이점

가능한 경우 유사한 쿼리의 빠른 예와 느린 예를 모두 포함하여 최적화 기회를 식별할 수 있도록 합니다. 이 비교를 통해 지원팀은 잠재적인 구성 또는 디자인 개선 사항을 신속하게 식별할 수 있습니다.