클러스터링 키 및 클러스터링된 테이블¶
일반적으로 Snowflake는 테이블에 잘 클러스터된 데이터를 생성합니다. 그러나 시간이 지남에 따라 특히 DML이 매우 큰 테이블에서 발생하므로(행 수가 아니라 테이블의 데이터 양으로 정의됨) 일부 테이블 행의 데이터는 더 이상 원하는 차원에서 최적으로 클러스터링되지 않을 수 있습니다.
기본 테이블 마이크로 파티션의 클러스터링을 개선하기 위해 항상 키 테이블 열의 행을 수동으로 정렬하고 테이블에 다시 삽입할 수 있습니다. 그러나 이러한 작업을 수행하는 것은 번거롭고 비용이 많이 들 수 있습니다.
대신 Snowflake는 하나 이상의 테이블 열/식을 테이블의 클러스터링 키 로 지정하여 이러한 작업의 자동화를 지원합니다. 클러스터링 키가 정의된 테이블은 클러스터링된 것으로 간주됩니다.
테이블뿐만 아니라 구체화된 뷰 를 클러스터링할 수도 있습니다. 클러스터링 테이블 및 구체화된 뷰에 대한 규칙은 일반적으로 동일합니다. 구체화된 뷰와 관련된 몇 가지 추가 팁은 구체화된 뷰 및 클러스터링 및 구체화된 뷰의 모범 사례 를 참조하십시오.
주의
초기에 데이터를 클러스터링하고 클러스터링을 유지 관리하는 비용으로 인해 클러스터링 키를 모든 테이블에 사용할 수 있는 것은 아닙니다. 클러스터링은 다음과 같은 경우에 최적입니다.
비용에 관계없이 가능한 한 가장 빠른 응답 시간이 필요할 때.
향상된 쿼리 성능이 테이블의 클러스터링과 유지 관리에 필요한 크레딧을 상쇄할 때.
클러스터링할 테이블의 선택에 대한 자세한 내용은 테이블에 대한 클러스터링 선택 시 고려 사항 섹션을 참조하십시오.
이 항목의 내용:
클러스터링 키란 무엇입니까?¶
클러스터링 키는 동일한 마이크로 파티션 에서 테이블의 데이터를 같은 위치에 배치하도록 명시적으로 지정된 테이블(또는 테이블의 식)에 있는 열의 하위 세트입니다. 이는 순서가 이상적이지 않거나(데이터의 삽입/로드 시점에) 대규모 DML로 인해 테이블의 자연스러운 클러스터링 성능이 저하된 매우 큰 테이블에 유용합니다.
테이블에 대한 클러스터링 키를 정의할지 여부를 결정하기 위해 유용한 몇 가지 일반 지표는 다음과 같습니다.
테이블의 쿼리가 예상보다 느리게 실행되거나 시간이 지남에 따라 대폭 저하됩니다.
테이블의 클러스터링 깊이 가 큽니다.
클러스터링 키는 테이블을 생성할 때(CREATE TABLE 명령 사용) 또는 나중에(ALTER TABLE 명령 사용) 정의할 수 있습니다. 테이블의 클러스터링 키도 언제든지 변경하거나 삭제할 수 있습니다.
주의
하이브리드 테이블 에는 클러스터링 키를 정의할 수 없습니다. 하이브리드 테이블에서 데이터는 항상 기본 키를 기준으로 정렬됩니다.
클러스터링 키 정의의 이점(매우 큰 테이블의 경우)¶
클러스터링 키를 사용하여 동일한 마이크로 파티션에서 유사한 행을 함께 배치하는 경우 매우 큰 테이블과 관련하여 얻을 수 있는 여러 이점은 다음과 같습니다.
필터링 조건자와 일치하지 않는 데이터를 건너뛰어 쿼리의 스캔 효율성이 향상됩니다.
클러스터링이 없는 테이블에 비해 열의 압축이 향상됩니다. 이러한 향상은 클러스터링 키를 구성하는 열과 다른 열의 상관 관계가 높은 경우 특히 유용합니다.
테이블에 키를 정의한 후에는 키를 삭제하거나 수정하는 경우를 제외하고 추가적인 관리가 필요하지 않습니다. 최적의 클러스터링을 보장하기 위해 테이블의 행에 대한 모든 향후 유지 관리는 Snowflake에서 자동으로 수행됩니다.
클러스터링은 성능을 크게 향상시키고 일부 쿼리 비용을 줄일 수 있지만 클러스터링을 수행하는 데 사용되는 컴퓨팅 리소스는 크레딧을 소모합니다. 따라서 쿼리가 클러스터링을 통해 상당한 이점을 얻을 때만 클러스터링해야 합니다.
일반적으로 쿼리는 쿼리가 테이블의 클러스터링 키를 필터링하거나 정렬할 때 클러스터링의 이점을 얻습니다. 정렬은 일반적으로 ORDER BY
연산, GROUP BY
연산 및 일부 조인에 대해 수행됩니다. 예를 들어 다음 조인으로 인해 Snowflake가 정렬 작업을 수행할 수 있습니다.
SELECT ... FROM my_table INNER JOIN my_materialized_view ON my_materialized_view.col1 = my_table.col1 ...
이 의사 예에서 Snowflake는 my_materialized_view.col1
또는 my_table.col1
의 값을 정렬할 가능성이 높습니다. 예를 들어, my_table.col1
의 값이 정렬된 경우 구체화된 뷰가 스캔될 때 Snowflake는 my_table
에서 해당 행을 빠르게 찾을 수 있습니다.
테이블을 더 자주 쿼리할수록 클러스터링의 이점이 증가합니다. 그러나 테이블이 더 자주 변경될수록 클러스터를 유지하기 위해서는 더 많은 비용이 소요됩니다. 그러므로 클러스터링은 일반적으로 자주 쿼리되고 자주 변경되지 않는 테이블에서 가장 비용 대비 효율적입니다.
테이블에 대한 클러스터링 선택 시 고려 사항¶
더 빠른 응답 시간을 원하든 전체 비용 절감을 원하든, 클러스터링은 다음 기준을 모두 충족하는 테이블에 가장 적합합니다.
이 테이블에는 많은 수의 마이크로 파티션 이 포함됩니다. 일반적으로, 이는 테이블에 수 테라바이트(TB)의 데이터가 있다는 뜻입니다.
쿼리는 클러스터링을 이용할 수 있습니다. 일반적으로 이는 다음 중 하나 또는 둘 모두가 적용된다는 뜻입니다.
쿼리가 선택적입니다. 즉, 쿼리가 테이블에 있는 행 중 작은 비율(따라서 보통은 마이크로 파티션의 작은 비율)의 행만 읽으면 됩니다.
쿼리가 데이터를 정렬합니다. (예를 들어 쿼리가 테이블에 대한 ORDER BY 절을 포함합니다.)
쿼리 중 높은 비율의 쿼리가 동일한 클러스터링 키의 이점을 얻을 수 있습니다. 다시 말해, 많은/대부분의 쿼리가 동일한 소수의 열에서 선택하거나 정렬합니다.
주로 전체 비용을 줄이는 것이 목표라면 클러스터링된 각 테이블에 DML 작업(INSERT/UPDATE/DELETE)에 대해 높은 비율의 쿼리가 있어야 합니다. 이는 일반적으로 테이블이 자주 쿼리되고 업데이트는 드물게 이루어진다는 뜻입니다. 다수의 DML이 발생하는 테이블을 클러스터링하려면 DML 문을 큰 배치로 묶어 드물게만 그룹화해 보십시오.
또한, 테이블 클러스터링을 선택하기 전, Snowflake는 테이블에서 대표적인 쿼리 세트를 테스트하여 몇 가지 성능 기준을 설정할 것을 적극 권장합니다.
클러스터링 키 선택 전략¶
단일 클러스터링 키에는 1개 이상의 열 또는 식이 포함될 수 있습니다. 대부분의 테이블에 대해 Snowflake는 키당 최대 3개 또는 4개의 열(또는 식)을 권장합니다. 3~4개 이상의 열을 추가하면 이익보다 비용이 더 많이 증가하는 경향이 있습니다.
클러스터링 키에 대해 올바른 열/식을 선택하면 쿼리 성능에 큰 영향을 줄 수 있습니다. 워크로드를 분석하면 일반적으로 우수한 클러스터링 키 후보를 얻을 수 있습니다.
Snowflake는 아래 순서대로 키의 우선 순위를 지정할 것을 권장합니다.
선택적 필터에서 가장 자주 사용되는 클러스터 열입니다. 날짜 기반 쿼리와 관련된 많은 정보 테이블(예: “WHERE 송장_날짜 > x AND 송장 날짜 <= y”)의 경우 날짜 열을 선택하는 것이 좋습니다. 이벤트 테이블의 경우 다양한 이벤트 타입이 있는 경우 이벤트 타입을 선택하는 것이 좋습니다. (테이블에 소수의 다른 이벤트 타입만 있는 경우 클러스터링 키를 사용하여 이벤트 열을 선택하기 전 아래 카디널리티에 대한 설명을 참조하십시오.)
추가 클러스터 키를 위한 공간이 있는 경우 조인 조건자에서 자주 사용되는 열을 고려하십시오(예: “FROM 테이블1 JOIN 테이블2 ON 테이블2.열_A = 테이블1.열_B”).
일반적으로 2개의 차원(예: application_id
및 user_status
열)으로 쿼리를 필터링하는 경우 두 열에 대한 클러스터링을 통해 성능을 향상할 수 있습니다.
열/식의 고유 값(즉, 카디널리티) 수는 클러스터링 키를 사용하여 선택할 때 중요한 측면입니다. 다음이 포함된 클러스터링 키를 선택하는 것이 중요합니다.
테이블에서 효과적으로 정리를 수행하기 위해 충분한 수의 고유 값.
Snowflake가 동일한 마이크로 파티션에서 행을 효과적으로 그룹화할 수 있도록 충분히 적은 수의 고유 값.
카디널리티가 매우 낮은 열은 부울 값만 포함하는 IS_NEW_CUSTOMER
라는 열과 같이 최소한의 잘라내기 효과만 낼 수 있습니다. 다른 극단적인 예로, 카디널리티가 매우 높은 열도 일반적으로 클러스터링 키로 직접 사용하기에 좋은 후보가 아닙니다. 예를 들어 나노초 타임스탬프 값을 포함하는 열에서는 좋은 클러스터링 키가 생성되지 않습니다.
팁
일반적으로 열(또는 식)의 카디널리티가 높으면 해당 열에서 클러스터링을 유지 관리하기 위한 비용이 더 많이 소요됩니다.
특히 포인트 조회가 해당 테이블의 기본 사용 사례가 아닌 경우 고유 키에 대한 클러스터링 비용이 해당 키에 대한 클러스터링의 이점보다 클 수 있습니다.
카디널리티가 매우 높은 열을 클러스터링 키로 사용하려는 경우, Snowflake는 고유한 값의 수를 줄이기 위해 열에서 직접 키를 정의하는 대신 열에 대한 식으로 키를 정의하는 것을 권장합니다. 각 파티션의 최소값과 최대값이 정리에서 사용될 수 있도록 식에서는 열의 원래 순서가 유지되어야 합니다.
예를 들어, 정보 테이블에 TIMESTAMP 열 c_timestamp
이 포함된 여러 개별 값(테이블의 마이크로 파티션 수보다 많음)이 있는 경우 값을 타임스탬프 대신 날짜로 캐스팅하여 열에 클러스터링 키를 정의할 수 있습니다(예: to_date(c_timestamp)
). 이를 통해 카디널리티가 전체 일수로 감소하여 일반적으로 정리 결과가 대폭 향상될 수 있습니다.
다른 예로, TRUNC
함수와 음수 값을 사용하여 숫자를 더 적은 유효 자릿수로 자를 수 있습니다(예: TRUNC(123456789, -5)
).
팁
테이블에 대한 다중 열 클러스터링 키를 정의하는 경우에는 CLUSTER BY
절에서 열이 지정되는 순서가 중요합니다. 일반적으로 Snowflake는 열을 최저 카디널리티에서 최고 카디널리티로 정렬할 것을 권장합니다. 더 낮은 카디널리티 열 앞에 더 높은 카디널리티 열을 배치하면 일반적으로 후자 열에서 클러스터링의 효율성이 감소합니다.
팁
텍스트 필드에서 클러스터링할 때 클러스터 키 메타데이터는 처음 몇 바이트만 추적합니다(보통 5~6바이트 정도). 멀티바이트 문자 세트의 경우 이는 5 자 보다 적을 수 있습니다.
경우에 따라 GROUP BY
또는 ORDER BY
절에 사용된 열에 대한 클러스터링이 도움이 될 수 있습니다. 그러나 이러한 열에 대한 클러스터링은 일반적으로 필터 또는 JOIN
작업에 많이 사용되는 열에 대한 클러스터링보다 덜 유용합니다. 필터/조인 작업에 많이 사용되는 일부 열과 ORDER BY
또는 GROUP BY
작업에서 사용되는 다른 열이 있는 경우에는 필터 및 조인 작업에 사용되는 열을 사용하는 것이 좋습니다.
재클러스터링¶
클러스터링된 테이블에서 DML 연산(INSERT, UPDATE, DELETE, MERGE, COPY)을 수행하면 테이블의 데이터 클러스터링이 감소할 수 있습니다. 최적의 클러스터링을 유지하려면 테이블을 주기적/정기적으로 재클러스터링해야 합니다.
재클러스터링 중에 Snowflake는 클러스터링된 테이블에 대한 클러스터링 키를 사용하여 열 데이터를 재구성하므로 관련 레코드가 동일한 마이크로 파티션으로 재배치됩니다. 이 DML 작업은 영향을 받는 레코드를 삭제하고 클러스터링 키에 따라 그룹화하여 다시 삽입합니다.
참고
Snowflake에서 재클러스터링은 자동으로 수행되며, 유지 관리가 필요하지 않습니다. 자세한 내용은 자동 클러스터링 섹션을 참조하십시오.
그러나 특정 계정의 경우 수동 재클러스터링이 더 이상 사용되지 않지만 수행하는 것이 가능합니다. 자세한 내용은 수동 재클러스터링 을 참조하십시오.
재클러스터링의 크레딧 및 저장소 영향¶
Snowflake의 모든 DML 작업과 마찬가지로 재클러스터링은 크레딧을 소모합니다. 소비된 크레딧 수는 테이블 크기와 재클러스터링해야 하는 데이터 양에 따라 다릅니다.
재클러스터링하면 저장소 비용도 발생하게 됩니다. 데이터가 재클러스터링될 때마다 행은 테이블의 클러스터링 키에 따라 물리적으로 그룹화되어 Snowflake가 테이블에 대한 새 마이크로 파티션을 생성합니다. 테이블에 적은 수의 행을 추가해도 해당 값을 포함하는 모든 마이크로 파티션이 다시 생성될 수 있습니다.
이 프로세스는 원본 마이크로 파티션이 삭제된 것으로 표시되지만 Time Travel 및 Fail-safe를 활성화하기 위해 시스템에 유지되기 때문에 높은 데이터 회전율이 나타날 수 있습니다. 원래 마이크로 파티션은 Time Travel 보존 기간과 이후의 Fail-safe 기간이 모두 경과된 이후에만 제거됩니다(즉, Snowflake Enterprise Edition 이상 사용 시 확장된 Time Travel의 경우 최소 8일 및 최대 97일). 일반적으로는 이를 통해 저장소 비용이 증가하게 됩니다. 자세한 내용은 Snowflake Time Travel & Fail-safe 섹션을 참조하십시오.
중요
테이블에 대한 클러스터링 키를 정의하기 전 관련 크레딧 및 저장소 비용을 고려해야 합니다.
재클러스터링 예¶
이전 항목의 클러스터링 다이어그램 을 기반으로 하는 이 다이어그램은 테이블 재클러스터링을 통해 마이크로 파티션 스캔을 감소되어 쿼리 성능을 향상되는 방법을 보여줍니다.
시작하려면, 테이블
t1
이 마이크로 파티션 1~4에서date
를 기준으로 자연스럽게 클러스터링됩니다.쿼리(다이어그램에서)는 마이크로 파티션 1, 2, 3을 스캔해야 합니다.
date
및type
는 클러스터링 키로 정의됩니다. 테이블이 재클러스터링되면 새 마이크로 파티션(5~8)이 생성됩니다.재클러스터링 후 동일한 쿼리는 마이크로 파티션 5만 스캔합니다.
또한 재클러스터링 후:
마이크로 파티션 5는 일정한 상태 (즉, 재클러스터링을 통해 향상할 수 없음)에 도달했으므로 향후 유지 관리를 위해 깊이와 겹침을 계산할 때 제외됩니다. 우수하게 클러스터링된 대규모 테이블에서 대부분의 마이크로 파티션은 이 카테고리에 속합니다.
원래 마이크로 파티션(1~4)은 삭제된 것으로 표시되지만 시스템에서 제거되지는 않으며, Time Travel 및 Fail-safe 를 위해 유지됩니다.
참고
이 예는 매우 작은 규모에서 재클러스터링의 영향을 보여줍니다. 매우 큰 테이블(예: 수백만 개 이상의 마이크로 파티션으로 구성)로 추정되는 재클러스터링은 검색 및 쿼리 성능에 상당한 영향을 미칠 수 있습니다.
클러스터링된 테이블 정의하기¶
테이블에 대한 클러스터링 정보 계산하기¶
시스템 함수 SYSTEM$CLUSTERING_INFORMATION 를 사용하여 주어진 테이블에 대한 클러스터링 깊이를 포함한 클러스터링 세부 정보를 계산합니다. 이 함수는 테이블에 명시적 클러스터링 키가 있는지 여부에 관계없이 모든 테이블의 모든 열에서 실행할 수 있습니다.
테이블에 명시적 클러스터링 키가 있는 경우 함수에는 테이블 이름 이외의 입력 인자가 필요하지 않습니다.
테이블에 명시적 클러스터링 키가 없는 경우(또는 테이블에 클러스터링 키가 있지만 테이블의 다른 열에 대한 비율을 계산하려는 경우) 함수는 원하는 열을 추가 입력 인자로 사용합니다.
테이블에 대한 클러스터링 키 정의하기¶
클러스터링 키는 CREATE TABLE 에 CLUSTER BY
절을 추가하여 테이블을 생성할 때 정의할 수 있습니다.
CREATE TABLE <name> ... CLUSTER BY ( <expr1> [ , <expr2> ... ] )
각 클러스터링 키는 모든 데이터 타입이 될 수 있는 하나 이상의 테이블 열/식으로 구성되지만, 단, GEOGRAPHY, VARIANT, OBJECT 또는 ARRAY 타입은 제외됩니다. 클러스터링 키는 다음 중 하나를 포함할 수 있습니다.
기본 열
기본 열의 식입니다.
VARIANT 열의 경로에 대한 식입니다.
예:
-- cluster by base columns CREATE OR REPLACE TABLE t1 (c1 DATE, c2 STRING, c3 NUMBER) CLUSTER BY (c1, c2); SHOW TABLES LIKE 't1'; +-------------------------------+------+---------------+-------------+-------+---------+----------------+------+-------+----------+----------------+----------------------+ | created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | automatic_clustering | |-------------------------------+------+---------------+-------------+-------+---------+----------------+------+-------+----------+----------------+----------------------| | 2019-06-20 12:06:07.517 -0700 | T1 | TESTDB | PUBLIC | TABLE | | LINEAR(C1, C2) | 0 | 0 | SYSADMIN | 1 | ON | +-------------------------------+------+---------------+-------------+-------+---------+----------------+------+-------+----------+----------------+----------------------+ -- cluster by expressions CREATE OR REPLACE TABLE t2 (c1 timestamp, c2 STRING, c3 NUMBER) CLUSTER BY (TO_DATE(C1), substring(c2, 0, 10)); SHOW TABLES LIKE 't2'; +-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------+------+-------+----------+----------------+----------------------+ | created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | automatic_clustering | |-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------+------+-------+----------+----------------+----------------------| | 2019-06-20 12:07:51.307 -0700 | T2 | TESTDB | PUBLIC | TABLE | | LINEAR(CAST(C1 AS DATE), SUBSTRING(C2, 0, 10)) | 0 | 0 | SYSADMIN | 1 | ON | +-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------+------+-------+----------+----------------+----------------------+ -- cluster by paths in variant columns CREATE OR REPLACE TABLE T3 (t timestamp, v variant) cluster by (v:"Data":id::number); SHOW TABLES LIKE 'T3'; +-------------------------------+------+---------------+-------------+-------+---------+-------------------------------------------+------+-------+----------+----------------+----------------------+ | created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | automatic_clustering | |-------------------------------+------+---------------+-------------+-------+---------+-------------------------------------------+------+-------+----------+----------------+----------------------| | 2019-06-20 16:30:11.330 -0700 | T3 | TESTDB | PUBLIC | TABLE | | LINEAR(TO_NUMBER(GET_PATH(V, 'Data.id'))) | 0 | 0 | SYSADMIN | 1 | ON | +-------------------------------+------+---------------+-------------+-------+---------+-------------------------------------------+------+-------+----------+----------------+----------------------+
중요한 사용법 노트¶
각 VARCHAR 열에 대해 클러스터링의 현재 구현에서는 처음 5바이트만 사용합니다.
처음 N개의 문자가 모든 행에 대해 동일하거나 충분한 카디널리티를 제공하지 않을 경우, 동일하고 최적의 카디널리티를 가진 문자 다음에 시작하는 부분 문자열에서 클러스터링을 고려하십시오. (최적의 카디널리티에 대한 자세한 내용은 클러스터링 키 선택 전략 섹션을 참조하십시오.) 예:
create or replace table t3 (vc varchar) cluster by (SUBSTRING(vc, 5, 5));
두 개 이상의 열/식을 테이블의 클러스터링 키로 정의하는 경우 순서는 마이크로 파티션에서 데이터가 클러스터링되는 방식에 영향을 미칩니다.
자세한 내용은 이 항목의 클러스터링 키 선택 전략 섹션을 참조하십시오.
CREATE TABLE … CLONE을 사용하여 테이블을 생성할 때 기존 클러스터링 키를 복사합니다. 하지만 자동 클러스터링은 복제된 테이블에 대해 일시 중단되었는데 재개해야 합니다.
기존 클러스터링 키는 CREATE TABLE … AS SELECT를 사용하여 테이블을 생성할 때 지원되지 않지만, 테이블이 생성된 후에 클러스터링 키를 정의할 수 있습니다.
VARIANT 열 위에 직접 클러스터링 키를 정의하는 것은 지원되지 않지만, 경로와 대상 타입으로 구성된 식을 제공하면 클러스터링 키에 VARIANT 열을 지정할 수 있습니다.
테이블에 대한 클러스터링 키 변경하기¶
언제든지 ALTER TABLE 을 사용하여 기존 테이블에 클러스터링 키를 추가하거나 테이블의 기존 클러스터링 키를 변경할 수 있습니다.
ALTER TABLE <name> CLUSTER BY ( <expr1> [ , <expr2> ... ] )
예:
-- cluster by base columns ALTER TABLE t1 CLUSTER BY (c1, c3); SHOW TABLES LIKE 't1'; +-------------------------------+------+---------------+-------------+-------+---------+----------------+------+-------+----------+----------------+----------------------+ | created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | automatic_clustering | |-------------------------------+------+---------------+-------------+-------+---------+----------------+------+-------+----------+----------------+----------------------| | 2019-06-20 12:06:07.517 -0700 | T1 | TESTDB | PUBLIC | TABLE | | LINEAR(C1, C3) | 0 | 0 | SYSADMIN | 1 | ON | +-------------------------------+------+---------------+-------------+-------+---------+----------------+------+-------+----------+----------------+----------------------+ -- cluster by expressions ALTER TABLE T2 CLUSTER BY (SUBSTRING(C2, 5, 15), TO_DATE(C1)); SHOW TABLES LIKE 't2'; +-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------+------+-------+----------+----------------+----------------------+ | created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | automatic_clustering | |-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------+------+-------+----------+----------------+----------------------| | 2019-06-20 12:07:51.307 -0700 | T2 | TESTDB | PUBLIC | TABLE | | LINEAR(SUBSTRING(C2, 5, 15), CAST(C1 AS DATE)) | 0 | 0 | SYSADMIN | 1 | ON | +-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------+------+-------+----------+----------------+----------------------+ -- cluster by paths in variant columns ALTER TABLE T3 CLUSTER BY (v:"Data":name::string, v:"Data":id::number); SHOW TABLES LIKE 'T3'; +-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------------------------------------+------+-------+----------+----------------+----------------------+ | created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | automatic_clustering | |-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------------------------------------+------+-------+----------+----------------+----------------------| | 2019-06-20 16:30:11.330 -0700 | T3 | TESTDB | PUBLIC | TABLE | | LINEAR(TO_CHAR(GET_PATH(V, 'Data.name')), TO_NUMBER(GET_PATH(V, 'Data.id'))) | 0 | 0 | SYSADMIN | 1 | ON | +-------------------------------+------+---------------+-------------+-------+---------+------------------------------------------------------------------------------+------+-------+----------+----------------+----------------------+
중요한 사용법 노트¶
이미 데이터가 채워진 테이블에 클러스터링 키를 추가할 때 키에 모든 식을 지정할 수 있는 것은 아닙니다. SHOW FUNCTIONS 를 사용하여 특정 기능이 지원되는지 확인할 수 있습니다.
show functions like 'function_name';
출력에는 출력 끝에
valid_for_clustering
열이 포함됩니다. 이 열은 채워진 테이블의 클러스터링 키에서 함수를 사용할 수 있는지 여부를 표시합니다.테이블의 클러스터링 키를 변경해도 Snowflake에서 테이블을 다시 클러스터링할 때까지는 테이블의 기존 레코드에 영향을 주지 않습니다.
테이블에 대한 클러스터링 키 삭제하기¶
언제든지 ALTER TABLE 을 사용하여 테이블의 클러스터링 키를 삭제할 수 있습니다.
ALTER TABLE <name> DROP CLUSTERING KEY
예:
ALTER TABLE t1 DROP CLUSTERING KEY; SHOW TABLES LIKE 't1'; +-------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+----------+----------------+----------------------+ | created_on | name | database_name | schema_name | kind | comment | cluster_by | rows | bytes | owner | retention_time | automatic_clustering | |-------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+----------+----------------+----------------------| | 2019-06-20 12:06:07.517 -0700 | T1 | TESTDB | PUBLIC | TABLE | | | 0 | 0 | SYSADMIN | 1 | OFF | +-------------------------------+------+---------------+-------------+-------+---------+------------+------+-------+----------+----------------+----------------------+