검색 최적화 서비스 사용하기¶
검색 최적화 서비스는 필터링을 위해 광범위한 조건자 세트를 사용하는 특정 유형의 조회 및 분석 쿼리의 성능을 크게 개선할 수 있습니다.
검색 최적화의 유무에 따른 실행 시간을 비교하는 자습서부터 시작하려면 검색 최적화 시작하기 로 이동하십시오.
이 항목의 내용:
검색 최적화 서비스 이해하기¶
검색 최적화 서비스의 목적은 다음을 포함하여 테이블에 대한 특정 유형의 쿼리 성능을 대폭 향상하는 것입니다.
테이블에 대한 선택적 포인트 조회 쿼리. 포인트 조회 쿼리에서는 1개 또는 몇 개의 고유 행만 반환합니다. 사용 사례의 예는 다음과 같습니다.
매우 선택적인 필터를 사용하여 중요한 대시보드에서 신속하게 응답을 수신해야 하는 비즈니스 사용자.
대용량 데이터를 탐색하고 데이터의 특정 하위 세트를 살펴보는 데이터 과학자.
광범위한 필터링 조건자 세트을 기반으로 작은 결과 세트를 검색하는 데이터 애플리케이션.
특정 유형의 조건자(같음 조건자, IN 조건자, ARRAY_CONTAINS 및 ARRAYS_OVERLAP 을 사용하는 조건자, NULL 값이 있는지 검사하는 조건자)를 사용하는 VARIANT, OBJECT 및 ARRAY 열의 필드에 대한 쿼리.
GEOGRAPHY 값과 함께 선택한 지리 공간 함수를 사용하는 쿼리.
검색 최적화 서비스의 이점을 활용할 수 있는 쿼리를 식별하면 해당 쿼리에 사용되는 열과 테이블에 대한 검색 최적화를 구성할 수 있습니다.
검색 최적화 서비스는 어떻게 작동합니까?¶
포인트 조회 성능을 향상하기 위해 검색 최적화 서비스에서는 최적화된 검색 액세스 경로의 역할을 하는 영구 데이터 구조를 사용합니다.
백그라운드에서 실행되는 유지관리 서비스는 검색 액세스 경로를 생성한 후 유지관리를 수행합니다.
테이블의 검색 최적화를 구성하면, 유지관리 서비스가 조회를 수행하기 위해 필요한 데이터를 사용하여 검색 액세스 경로를 생성한 후 채웁니다.
데이터를 채우는 프로세스에는 시간이 걸릴 수 있으며, 테이블 크기에 다릅니다. 이 서비스는 백그라운드에서 이러한 작업을 수행하며 테이블에서 동시 작업을 차단하지 않습니다.
테이블의 데이터가 업데이트되면(예: 새 데이터 세트 로드 또는 DML 작업을 통해) 유지관리 서비스는 검색 액세스 경로를 자동으로 업데이트하여 데이터 변경 사항을 적용합니다.
검색 액세스 경로가 아직 업데이트되지 않은 상태에서 쿼리를 실행하면, 쿼리의 실행 속도가 느릴 수 있지만 항상 최신 결과가 반환됩니다.
이러한 검색 액세스 경로 및 유지관리 서비스는 사용자에게 투명하게 제공됩니다. 사용자는 검색 액세스 경로 유지관리 서비스에서 사용할 웨어하우스를 생성할 필요가 없습니다.
그러나 이 서비스를 위한 저장소 및 컴퓨팅 리소스의 비용이 발생한다는 점에 유의하십시오. 자세한 내용은 이 항목의 검색 최적화 서비스의 비용 관리하기 섹션을 참조하십시오.
쿼리 성능을 최적화하기 위해 다른 솔루션 고려하기¶
검색 최적화 서비스는 쿼리 성능을 최적화하기 위한 여러 방법 중 하나입니다. 관련 기술은 다음과 같습니다.
테이블 클러스터링.
1개 이상의 구체화된 뷰 만들기(클러스터형 또는 비클러스터형).
다음 표에서 보듯이, 이들은 각각 서로 다른 장점이 있습니다.
특징 |
지원되는 쿼리 유형 |
기타 사용 사례 |
---|---|---|
검색 최적화 서비스 |
검색 최적화 서비스는 지원되는 데이터 타입 에 대해 이러한 유형의 검색 성능을 개선할 수 있습니다. |
|
구체화된 뷰 |
참고: 구체화된 뷰에 포함된 행 및 열의 하위 세트에 대해서만 성능을 개선할 수 있습니다. |
또한, 구체화된 뷰는 동일한 소스 테이블(또는 해당 테이블의 하위 세트)에서 서로 다른 클러스터링 키를 정의하거나 평면화 JSON/베리언트 데이터 결합과 함께 사용할 수도 있습니다. |
테이블 클러스터링 |
참고: 테이블은 단일 키(1개 이상의 열 또는 식이 포함될 수 있음)에만 클러스터링될 수 있습니다. |
다음 테이블은 이러한 세 가지 최적화에서의 저장소 또는 컴퓨팅 요금의 발생 여부를 보여줍니다.
저장소 요금 |
컴퓨팅 요금 |
|
---|---|---|
검색 최적화 서비스 |
✔ |
✔ |
구체화된 뷰 |
✔ |
✔ |
테이블 클러스터링 |
✔ 1 |
✔ |
- 1
재클러스터링 프로세스에서는 기존 파티션을 새 파티션으로 다시 쓰므로 Fail-safe 저장소의 크기가 증가할 수 있습니다. (이 프로세스에서는 새 행을 도입하지 않습니다. 기존 행을 다시 구성할 뿐입니다.) 자세한 내용은 재클러스터링의 크레딧 및 저장소 영향 섹션을 참조하십시오.
검색 최적화 서비스에 필요한 액세스 제어 권한은 무엇입니까?¶
테이블에 대한 검색 최적화를 추가하거나 구성하거나 제거하기 위해 필요한 권한은 다음과 같습니다.
테이블에 대한 OWNERSHIP 권한이 있어야 합니다.
테이블이 포함된 스키마에 대한 ADD SEARCH OPTIMIZATION 권한이 있어야 합니다.
GRANT ADD SEARCH OPTIMIZATION ON SCHEMA <schema_name> TO ROLE <role>
쿼리에서 검색 최적화 서비스를 사용하려면 테이블에 대한 SELECT 권한만 있으면 됩니다.
추가 권한은 필요하지 않습니다. SEARCH OPTIMIZATION은 테이블 속성이므로, 테이블을 쿼리할 때 자동으로 감지되어 사용(해당되는 경우)됩니다.
검색 최적화의 이점을 누리는 테이블과 열 식별하기¶
검색 최적화는 테이블에서 기본 클러스터 키가 아닌 열에 대한 쿼리가 자주 수행될 때 쿼리 성능을 개선하는 데 가장 효과적입니다.
검색 최적화 서비스는 현재 다음 데이터 타입에 대해 특정 유형의 쿼리 를 지원합니다.
고정 소수점 숫자(예: INTEGER, NUMERIC)
DATE, TIME, TIMESTAMP
VARCHAR.
BINARY.
VARIANT, OBJECT, ARRAY (이것은 미리 보기 기능입니다.)
GEOGRAPHY. (이것은 미리 보기 기능입니다.)
현재 검색 최적화 서비스에서는 부동 소수점 데이터 타입, GEOMETRY 또는 위에 나열되지 않은 기타 데이터 타입을 지원하지 않습니다. Snowflake는 향후 더 많은 데이터 타입에 대한 지원을 추가할 수 있습니다.
또한, 검색 최적화 서비스는 데이터 정렬도 지원하지 않습니다.
검색 최적화의 이점을 활용할 수 있는 쿼리 식별하기¶
검색 최적화는 다음 유형의 쿼리 성능을 향상하는 데 매우 적합합니다.
(검색 최적화를 적용하기 전에) 일반적으로 몇 초 이상 실행되는 쿼리. 대부분의 경우 실행 시간이 1초 미만인 쿼리의 성능은 검색 최적화로도 크게 향상되지 않습니다.
쿼리 필터 작업을 통해 액세스하는 열 중 1개 이상에 100,000~200,000개 이상의 고유 값이 있는 쿼리.
고유 값의 수를 결정하려면, 다음 중 하나를 사용할 수 있습니다.
APPROX_COUNT_DISTINCT
를 사용하여 고유 값의 대략적인 수를 구합니다.select approx_count_distinct(column1) from table1;
COUNT(DISTINCT <열_이름>)
을 사용하여 실제 고유 값 수를 구합니다.select count(distinct c1), count (distinct c2) from test_table;
대략적인 고유 값 수만 필요하므로,
APPROX_COUNT_DISTINCT
를 사용하는 것이 좋습니다. 일반적으로COUNT(DISTINCT <열_이름>)
에 비해 속도가 빠르고 비용이 적게 발생합니다.
검색 최적화로 이러한 유형의 쿼리 성능을 개선할 수 있습니다.
같음 또는 IN 조건자¶
검색 최적화 서비스는 다음을 사용하는 쿼리의 성능을 개선할 수 있습니다.
하위 문자열 및 정규식¶
검색 최적화 서비스는 하위 문자열을 검색하거나 정규식을 사용하는 조건자로 쿼리의 성능을 개선할 수 있습니다. 여기에는 다음을 사용하는 조건자가 포함됩니다.
SPLIT_PART (같음 조건자에서)
참고
ALTER TABLE … ADD SEARCH OPTIMIZATION 명령에서 ON 절을 사용하여 특정 열에 대해 이 기능을 활성화해야 합니다. 예:
ALTER TABLE mytable ADD SEARCH OPTIMIZATION ON SUBSTRING(mycol);
ON 절을 생략하면 하위 문자열 검색이 개선되지 않습니다.
검색 최적화 서비스는 5자 이상의 하위 문자열을 검색할 때 성능을 개선할 수 있습니다. (선택적 하위 문자열이 많을수록 성능을 향상할 수 있습니다.)
대조적으로, 하위 문자열이 5자보다 짧으므로 검색 최적화 서비스에서는 다음 조건자에 대해 검색 액세스 경로를 사용하지 않습니다.
LIKE '%TEST%'
다음 조건자의 경우 검색 최적화 서비스는 이 쿼리를 최적화하여 검색 액세스 경로를 사용해 SEARCH
및 OPTIMIZED
에 대한 하위 문자열을 검색할 수 있습니다. 하지만 하위 문자열이 5자보다 짧으므로 IS
에는 검색 액세스 경로가 사용되지 않습니다.
LIKE '%SEARCH%IS%OPTIMIZED%'
RLIKE, REGEXP, REGEXP_LIKE를 사용하는 쿼리의 경우:
subject
인자는 검색 최적화가 활성화된 테이블의 TEXT 열이어야 합니다.pattern
인자는 문자열 상수여야 합니다.
정규식의 경우 검색 최적화 서비스는 다음과 같은 때에 가장 효과적입니다.
패턴에 길이가 5자 이상인 하위 문자열 리터럴이 하나 이상 포함됩니다.
패턴은 하위 문자열이 한 번 이상 나타나야 하는 것으로 지정합니다.
예를 들어, 다음 패턴은 string
이 제목에 한 번 이상 나타나야 하는 것으로 지정합니다.
RLIKE '(string)+'
각 조건자가 5자 이상의 하위 문자열이 한 번 이상 나타나야 한다고 지정하므로 검색 최적화 서비스는 다음 패턴을 사용해 쿼리 성능을 개선할 수 있습니다. (첫 번째 예에서는 백슬래시 문자를 이스케이프하지 않도록 달러 인용 기호로 묶인 문자열 상수 를 사용합니다.)
RLIKE $$.*email=[\w\.]+@snowflake\.com.*$$RLIKE '.*country=(Germany|France|Spain).*'RLIKE '.*phone=[0-9]{3}-?[0-9]{3}-?[0-9]{4}.*'
반대로, 검색 최적화 서비스는 다음 패턴의 쿼리에 대해 검색 액세스 경로를 사용하지 않습니다.
부분 문자열이 없는 패턴:
RLIKE '.*[0-9]{3}-?[0-9]{3}-?[0-9]{4}.*'
5자 미만의 하위 문자열만 포함하는 패턴:
RLIKE '.*tel=[0-9]{3}-?[0-9]{3}-?[0-9]{4}.*'
한 옵션이 5자 미만의 하위 문자열인 대체 연산자를 사용하는 패턴:
RLIKE '.*(option1|option2|opt3).*'
하위 문자열이 선택 사항인 패턴:
RLIKE '.*[a-zA-z]+(string)?[0-9]+.*'
하위 문자열 리터럴이 5자 미만일 때도 정규식을 확장하여 5자 이상의 하위 문자열 리터럴을 생성할 경우 검색 최적화 서비스는 쿼리 성능을 계속 개선할 수 있습니다.
예를 들어 다음 패턴을 생각해 보십시오.
.*st=(CA|AZ|NV).*(-->){2,4}.*
이 예에서는 다음과 같습니다.
하위 문자열 리터럴(예:
st=
,CA
등)이 5자 미만이지만, 검색 최적화 서비스는 하위 문자열st=CA
,st=AZ
또는st=NV
(각각의 길이는 5자)가 텍스트에 나타나야 함을 인식합니다.마찬가지로, 하위 문자열 리터럴
-->
이 5자 미만이더라도 검색 최적화 서비스는 (5자보다 긴) 하위 문자열-->-->
이 텍스트에 나타나야 한다고 결정합니다.
검색 최적화 서비스는 검색 액세스 경로를 사용하여 이러한 하위 문자열을 일치시킬 수 있으며, 이를 통해 쿼리 성능을 개선할 수 있습니다.
VARIANT 열의 필드¶
검색 최적화 서비스는 Snowflake 테이블의 반정형 데이터(VARIANT, OBJECT 및 ARRAY 열 의 데이터)에 대한 포인트 조회 쿼리의 성능을 개선할 수 있습니다.
검색 최적화 서비스에 대한 VARIANT 지원이 테이블의 열에 대해 구성된 경우 검색 최적화 서비스는 검색 액세스 경로에 VARIANT, OBJECT 및 ARRAY 열을 자동으로 포함합니다. 이는 구조가 깊이 중첩되고 자주 변경되는 열에도 적용됩니다.
참고
ALTER TABLE … ADD SEARCH OPTIMIZATION 명령에서 ON 절을 사용하여 특정 열 또는 열의 필드에 대해 이 기능을 활성화해야 합니다. 예:
ALTER TABLE mytable ADD SEARCH OPTIMIZATION ON EQUALITY(myvariantcol);
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c4:user:uuid);
ON 절을 생략하면 VARIANT 열에 대한 쿼리가 개선되지 않습니다.
다음 섹션에서는 이 지원에 대한 자세한 내용을 제공합니다.
VARIANT 타입에 대한 조건자의 상수와 캐스트를 위해 지원되는 데이터 타입¶
검색 최적화 서비스는 요소에 대해 상수와 암시적 또는 명시적 캐스트 에 다음 타입이 사용되는 반정형 데이터의 쿼리 성능을 개선할 수 있습니다.
FIXED(유효한 전체 자릿수와 소수 자릿수를 지정하는 캐스트 포함)
INTEGER
TEXT
DATE(소수 자릿수를 지정하는 캐스트 포함)
TIME(소수 자릿수를 지정하는 캐스트 포함)
TIMESTAMP, TIMESTAMP_LTZ, TIMESTAMP_NTZ, TIMESTAMP_TZ(소수 자릿수를 지정하는 캐스트 포함)
검색 최적화 서비스는 다음을 사용하여 타입의 캐스팅을 지원합니다.
TEXT로 캐스팅된 VARIANT 값 지원¶
또한 검색 최적화 서비스는 VARIANT 열이 TEXT로 캐스팅되고 TEXT로 캐스팅된 상수와 비교되는 쿼리의 성능을 개선할 수도 있습니다.
예를 들어, src
가 VARIANT로 변환된 부울, 날짜 및 시간 값을 포함하는 VARIANT 열이라고 가정합니다.
create or replace TABLE test_table
(
ID INTEGER,
SRC VARIANT
);
insert into test_table select 1, to_variant('true'::boolean); -- BOOLEAN
insert into test_table select 2, to_variant('2020-01-09'::date); -- DATE
insert into test_table select 3, to_variant('01:02:03.899213'::time); -- TIME
이 테이블의 경우 검색 최적화 서비스는 VARIANT 열을 TEXT로 캐스팅하고 열을 문자열 상수와 비교하는 다음 쿼리를 개선할 수 있습니다.
select * from test_table where src::TEXT = 'true';
select * from test_table where src::TEXT = '2020-01-09';
select * from test_table where src::TEXT = '01:02:03.899213';
VARIANT 타입에 대해 지원되는 조건자¶
검색 최적화 서비스는 아래에 나열된 조건자의 유형으로 쿼리를 개선할 수 있습니다. 아래 예에서 src
는 VARIANT 열이고 path_to_variant_field
는 VARIANT 열의 필드에 대한 경로 입니다.
다음 형식의 같음 조건자:
where path_to_variant_field[::target_data_type] = constant
target_data_type
(지정된 경우) 및constant
의 데이터 타입은 위에 나열된 지원 타입 중 하나여야 합니다.::
는 값을 특정 타입으로 캐스팅하는 지원 방식 중 하나의 예일 뿐입니다.예를 들어, 검색 최적화 서비스는 다음을 지원합니다.
요소를 명시적으로 캐스팅하지 않고 NUMBER 상수에 대해 요소 일치시키기.
where src:person.age = 42;
지정된 전체 자릿수와 소수 자릿수로 요소를 NUMBER로 명시적으로 캐스팅하기.
where src:location.temperature::NUMBER(8, 6) = 23.456789;
요소를 명시적으로 캐스팅하지 않고 TEXT 상수에 대해 요소 일치시키기.
where src:sender_info.ip_address = '123.123.123.123';
요소를 TEXT로 명시적으로 캐스팅하기.
where src:salesperson.name::TEXT = 'John Appleseed';
요소를 DATE로 명시적으로 캐스팅하기.
where src:events.date::DATE = '2021-03-26';
지정된 소수 자릿수로 요소를 TIME으로 명시적으로 캐스팅하기.
where src:events.time_info::TIME(6) = '01:02:03.456789';
지정된 소수 자릿수로 요소를 TIMESTAMP로 명시적으로 캐스팅하기.
where src:event_logs.exceptions.timestamp_info(3) = '2021-03-26 15:00:00.123 -0800';
다음과 같은 ARRAY 함수를 사용하는 조건자:
where ARRAY_CONTAINS(constant::VARIANT, path_to_variant_field)
constant
는 NULL이 아니어야 하며constant
의 데이터 타입은 위에 나열된 지원 타입 중 하나여야 합니다.::
는 값을 특정 타입으로 캐스팅하는 지원 방식 중 하나의 예일 뿐입니다.예:
where ARRAY_CONTAINS('77.146.211.88'::VARIANT, src:logs.ip_addresses)
where ARRAYS_OVERLAP(ARRAY_CONSTRUCT(constant_1, constant_2, .., constant_N), path_to_variant_field)
각 상수의 데이터 타입(
constant_1
,constant_2
등)은 위에 나열된 지원 타입 중 하나여야 합니다. 생성된 ARRAY는 NULL 상수를 포함할 수 있습니다.예:
where ARRAYS_OVERLAP( ARRAY_CONSTRUCT('122.63.45.75', '89.206.83.107'), src:senders.ip_addresses)
다음 조건자는 NULL 값 여부를 검사합니다.
where IS_NULL_VALUE(path_to_variant_field)
IS_NULL_VALUE 는 SQL NULL 값이 아닌 JSON null 값에 적용됩니다.
where path_to_variant_field IS NOT NULL
where variant_column IS NULL
여기서
variant_column
은 반정형 데이터의 요소에 대한 경로가 아니라 열을 나타냅니다.예를 들어, 검색 최적화 서비스는 VARIANT 열
src
사용을 지원하지만 해당 VARIANT 열의 필드src:person:age
에 대한 경로는 지원하지 않습니다.
VARIANT 타입의 지원에서 현재 제한 사항¶
현재, 검색 최적화 서비스의 VARIANT 타입 지원에는 다음과 같은 제한 사항이 있습니다.
XMLGET 를 사용하는 조건자는 지원되지 않습니다.
variant_field IS NULL
형식의 조건자는 지원되지 않습니다.상수가 스칼라 하위 쿼리의 결과인 조건자는 지원되지 않습니다.
하위 요소를 포함하는 요소에 대한 경로를 지정하는 조건자는 지원되지 않습니다.
이 기능에는 검색 최적화 서비스의 현재 제한 사항 도 적용됩니다.
지리 공간 함수¶
검색 최적화 서비스는 GEOGRAPHY 오브젝트와 함께 지리 공간 함수를 사용하는 조건자로 쿼리의 성능을 개선할 수 있습니다.
참고
ALTER TABLE … ADD SEARCH OPTIMIZATION 명령에서 ON 절을 사용하여 특정 열에 대해 이 기능을 활성화해야 합니다. 예:
ALTER TABLE mytable ADD SEARCH OPTIMIZATION ON GEO(mygeocol);
ON 절을 생략하면 지리 공간 함수를 사용하는 쿼리가 개선되지 않습니다.
다음 섹션에서 더 자세히 설명합니다.
참고
GEOMETRY 오브젝트는 아직 지원되지 않습니다.
지리 공간 함수와 함께 지원되는 조건자¶
다음 함수를 사용하는 조건자가 있는 쿼리의 경우:
다음과 같은 경우에 검색 최적화 서비스는 성능을 개선할 수 있습니다.
한 입력식은 테이블의 GEOGRAPHY 열이며,
다른 입력식은 (변환 또는 생성자 함수 를 통해 생성됨) GEOGRAPHY 상수입니다.
ST_DWITHIN의 경우 거리 인자는 음이 아닌 REAL 상수입니다.
이 기능에는 검색 최적화 서비스에 적용되는 것과 동일한 제한 사항 이 있습니다.
기타 성능 고려 사항¶
검색 최적화 서비스는 선택의 자유도가 매우 높은 조건자를 위해 설계되었고 조건자는 지리 공간 오브젝트 간의 근접성을 기준으로 필터링하므로, 테이블의 근접성을 기준으로 지리 공간 오브젝트를 클러스터링하면 성능이 향상될 수 있습니다. 기본 테이블이 자주 변경되는지 여부에 따라 데이터를 로드할 때 정렬 순서를 지정하거나 자동 클러스터링을 사용하여 데이터를 클러스터링할 수 있습니다.
- 사전 정렬된 데이터 로드하기
기본 테이블의 데이터가 자주 변경되지 않는 경우 데이터를 로드할 때 정렬 순서를 지정할 수 있습니다. 그런 다음 GEOGRAPHY 열에서 검색 최적화를 활성화할 수 있습니다. 예:
CREATE TABLE new_table AS SELECT * FROM source_table ORDER BY st_geohash(geom); ALTER TABLE new_table ADD SEARCH OPTIMIZATION ON GEO(geom);
기본 데이터에 큰 변화가 있을 때마다 데이터를 수동으로 다시 정렬할 수 있습니다.
- 자동 클러스터링
기본 테이블이 자주 업데이트되는 경우 ALTER TABLE … CLUSTER BY … 명령을 사용하여 자동 클러스터링 을 활성화하여 테이블이 변경될 때 자동으로 다시 클러스터링되도록 할 수 있습니다.
다음 예에서는 VARCHAR 유형의 새 열
geom_geohash
를 추가하고 그 열에 GEOGRAPHY 열geom
의 H3 인덱스 또는 지오해시를 저장합니다. 그런 다음 새 열을 클러스터 키로 삼아 자동 클러스터링을 활성화합니다. 이 접근 방식에서는 테이블에서 변경되는 부분이 자동으로 다시 클러스터링됩니다.CREATE TABLE new_table AS SELECT *, ST_GEOHASH(geom) AS geom_geohash FROM source_table; ALTER TABLE new_table CLUSTER BY (geom_geohash); ALTER TABLE new_table ADD SEARCH OPTIMIZATION ON GEO(geom);
지리 공간 함수를 사용하는 예¶
다음 문을 실행하면 이 섹션의 예에 사용된 테이블을 만들고 구성할 수 있습니다. 마지막 문에서는 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령에 ON 절을 사용하여 g1
GEOGRAPHY 열에 대한 검색 최적화를 추가합니다.
CREATE OR REPLACE TABLE geospatial_table (id NUMBER, g1 GEOGRAPHY);
INSERT INTO geospatial_table VALUES
(1, 'POINT(-122.35 37.55)'),
(2, 'LINESTRING(-124.20 42.00, -120.01 41.99)'),
(3, 'POLYGON((0 0, 2 0, 2 2, 0 2, 0 0))');
ALTER TABLE geospatial_table ADD SEARCH OPTIMIZATION ON GEO(g1);
지원되는 조건자의 예¶
다음 쿼리는 검색 최적화 서비스에서 지원하는 쿼리의 예입니다. 검색 최적화 서비스는 검색 액세스 경로를 사용하여 이 쿼리의 성능을 개선할 수 있습니다.
SELECT id FROM geospatial_table WHERE
ST_INTERSECTS(
g1,
TO_GEOGRAPHY('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'));
다음은 검색 최적화 서비스에서 지원하는 추가 조건자의 예입니다.
...
ST_INTERSECTS(
TO_GEOGRAPHY('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'),
g1)
...
ST_CONTAINS(
TO_GEOGRAPHY('POLYGON((-74.17 40.64, -74.1796875 40.58, -74.09 40.58, -74.09 40.64, -74.17 40.64))'),
g1)
...
ST_CONTAINS(
g1,
TO_GEOGRAPHY('MULTIPOINT((0 0), (1 1))'))
...
ST_WITHIN(
TO_GEOGRAPHY('{"type" : "MultiPoint","coordinates" : [[-122.30, 37.55], [-122.20, 47.61]]}'),
g1)
...
ST_WITHIN(
g1,
TO_GEOGRAPHY('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'))
...
ST_COVERS(
TO_GEOGRAPHY('POLYGON((-1 -1, -1 4, 4 4, 4 -1, -1 -1))'),
g1)
...
ST_COVERS(
g1,
TO_GEOGRAPHY('POINT(0 0)'))
...
ST_COVEREDBY(
TO_GEOGRAPHY('POLYGON((1 1, 2 1, 2 2, 1 2, 1 1))'),
g1)
...
ST_COVEREDBY(
g1,
TO_GEOGRAPHY('POINT(-122.35 37.55)'))
...
ST_DWITHIN(
TO_GEOGRAPHY('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'),
g1,
100000)
...
ST_DWITHIN(
g1,
TO_GEOGRAPHY('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'),
100000)
GEOGRAPHY 상수 생성의 예¶
다음은 GEOGRAPHY 상수에 대해 다양한 변환 및 생성자 함수 를 사용하는 조건자의 예입니다.
...
ST_INTERSECTS(
g1,
ST_GEOGRAPHYFROMWKT('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'))
...
ST_INTERSECTS(
ST_GEOGFROMTEXT('POLYGON((0 0, 1 0, 1 1, 0 1, 0 0))'),
g1)
...
ST_CONTAINS(
ST_GEOGRAPHYFROMEWKT('POLYGON((-74.17 40.64, -74.1796875 40.58, -74.09 40.58, -74.09 40.64, -74.17 40.64))'),
g1)
...
ST_WITHIN(
ST_GEOGRAPHYFROMWKB('01010000006666666666965EC06666666666C64240'),
g1)
...
ST_COVERS(
g1,
ST_MAKEPOINT(0.2, 0.8))
...
ST_INTERSECTS(
g1,
ST_MAKELINE(
TO_GEOGRAPHY('MULTIPOINT((0 0), (1 1))'),
TO_GEOGRAPHY('POINT(0.8 0.2)')))
...
ST_INTERSECTS(
ST_POLYGON(
TO_GEOGRAPHY('SRID=4326;LINESTRING(0.0 0.0, 1.0 0.0, 1.0 2.0, 0.0 2.0, 0.0 0.0)')),
g1)
...
ST_WITHIN(
g1,
TRY_TO_GEOGRAPHY('POLYGON((-1 -1, -1 4, 4 4, 4 -1, -1 -1))'))
...
ST_COVERS(
g1,
ST_GEOGPOINTFROMGEOHASH('s00'))
지원되는 조건자의 논리곱(AND)¶
조건자의 논리곱(즉, AND)을 사용하는 쿼리의 경우 조건자 중 1개 이상이 위의 조건을 충족하면 검색 최적화를 통해 쿼리 성능을 향상할 수 있습니다.
예를 들어, 쿼리에 다음이 포함되어 있다고 가정해 보겠습니다.
where condition_x and condition_y
두 조건 중 하나가 개별적으로 몇 개의 행을 반환(즉, condition_x
가 몇 개의 행을 반환 하거나 condition_y
가 몇 개의 행을 반환)하는 경우 검색 최적화를 통해 성능을 향상할 수 있습니다
condition_x
는 몇 개의 행을 반환하지만 condition_y
는 많은 행을 반환하는 경우, 검색 최적화를 통해 쿼리 성능을 향상할 수 있습니다.
이러한 추가 예 를 참조하십시오.
지원되는 조건자의 논리합(OR)¶
조건자의 논리곱(즉, OR)를 사용하는 쿼리의 경우 모든 조건자가 위의 조건을 충족하면 검색 최적화를 통해 쿼리 성능을 향상할 수 있습니다.
예를 들어, 쿼리에 다음이 포함되어 있다고 가정해 보겠습니다.
where condition_x or condition_y
각 조건이 개별적으로 몇 개의 행을 반환(즉, condition_x
가 몇 개의 행을 반환 하며 condition_y
가 몇 개의 행을 반환)하는 경우 검색 최적화를 통해 성능을 향상할 수 있습니다
condition_x
는 몇 개의 행을 반환하지만 condition_y
는 많은 행을 반환하는 경우, 검색 최적화를 통해 쿼리 성능을 향상할 수 없습니다.
논리합의 경우 분리된 각 조건자는 쿼리에서 결정적이지 않습니다. 다른 조건자를 평가한 후 검색 최적화를 통해 성능을 향상할 수 있는지 결정해야 합니다.
조인¶
검색 최적화 서비스는 조인의 성능을 직접적으로 향상하지 않습니다. 그러나 테이블에 검색 최적화가 활성화되어 있고 조건자 사용 여부를 선택할 수 있는 경우 조인하기 전 두 테이블의 행 필터링 성능을 향상할 수 있습니다.
두 테이블 모두에서 검색 최적화를 활성화할 필요가 없습니다. 검색 최적화 사용 여부에 대한 결정은 각 테이블에서 독립적입니다.
뷰¶
검색 최적화 서비스는 뷰(보안 뷰 포함)의 성능을 간접적으로 향상할 수 있습니다. 뷰의 기본 테이블에 검색 최적화가 활성화되어 있고 쿼리가 해당 테이블에 대해 선택적 조건자를 사용하는 경우 검색 최적화 서비스는 행을 필터링할 때 성능을 향상할 수 있습니다.
보기의 모든 테이블에서 검색 최적화가 활성화되지 않아도 됩니다. 검색 최적화는 각 테이블에서 독립적으로 수행됩니다.
마스킹 정책과 행 액세스 정책을 사용하는 테이블¶
검색 최적화 서비스는 마스킹 정책과 행 액세스 정책을 사용하는 테이블에 대한 쿼리 성능을 향상할 수 있습니다.
참고
검색 최적화가 활성화되면 마스킹 정책 또는 행 액세스 정책으로 인해 값을 볼 수 없는 사용자는 해당 값이 존재하는지 더 확실하게 추론할 수 있습니다. 검색 최적화의 사용 여부와는 무관하게, 쿼리 대기 시간의 차이를 통해 정책으로 제한되는 데이터의 존재 여부를 엿볼 수 있지만, 어떤 상황에서는 검색 최적화로 이 효과가 확대될 수 있습니다.
예를 들어, 행 액세스 정책에 따라 사용자가 country = US
가 있는 행에는 액세스할 수 없지만 country = US
이 있는 행이 데이터에 포함되어 있지 않다고 가정해 보십시오. 이제는 검색 최적화가 country
열에 대해 활성화되고 사용자가 WHERE country = US
가 있는 쿼리를 실행한다고 가정해 보십시오. 이 쿼리는 예상대로 빈 결과를 반환하지만 검색 최적화를 사용할 때가 사용하지 않을 때보다 더 빠르게 실행될 수 있습니다. 이 경우 사용자는 쿼리를 실행하는 데 걸린 시간을 기준으로 country = US
인 행이 데이터에 포함되어 있지 않다고 추론할 수 있습니다.
검색 최적화 서비스에서 지원되지 않는 쿼리¶
검색 최적화 서비스는 다음을 지원하지 않습니다.
외부 테이블.
구체화된 뷰.
COLLATE 절 을 사용하여 정의된 열.
열 연결.
분석 식.
테이블 열에 대한 캐스트(문자열로 캐스트되는 고정 소수점 숫자 제외).
검색 최적화는 상수 값에 대한 암시적 및 명시적 캐스트가 포함된 조건자를 지원하지만, 실제 테이블 열의 값을 캐스트하는 조건자는 지원하지 않습니다(INTEGER 및 NUMBER에서 VARCHAR로의 캐스트 제외).
예를 들어, 다음 조건자는 상수 값(테이블 열의 값이 아님)에 대한 암시적 및 명시적 캐스트를 사용하므로 지원됩니다.
-- Supported predicate -- (where the string '2020-01-01' is implicitly cast to a date) WHERE timestamp1 = '2020-01-01'; -- Supported predicate -- (where the string '2020-01-01' is explicitly cast to a date) WHERE timestamp1 = '2020-01-01'::date;
다음 조건자는 테이블 열의 값에 대한 캐스트를 사용하므로 지원되지 않습니다.
-- Unsupported predicate -- (where values in a VARCHAR column are cast to DATE) WHERE to_date(varchar_column) = '2020-01-01';
검색 최적화 서비스에서는 캐스트 이후의 값이 아닌 원래 열 값이 사용됩니다. 결과적으로, 이러한 조건자가 포함된 쿼리에서는 검색 최적화 서비스를 사용할 수 없습니다.
앞에서 설명한 바와 같이, 이 규칙의 예외는 테이블 열에서 NUMBER 또는 INTEGER 값을 VARCHAR 값으로 캐스팅하는 것입니다. 검색 최적화 서비스에서 지원되는 조건자의 타입은 다음과 같습니다.
-- Supported predicate -- (where values in a numeric column are cast to a string) WHERE cast(numeric_column as varchar) = '2'
검색 최적화는 활성 데이터에서만 작동하므로 검색 최적화는 Time Travel을 사용하는 쿼리의 성능을 향상하지 않습니다.
Query Acceleration Service 는 검색 최적화 서비스가 활성화된 테이블에 대한 쿼리를 가속하지 않습니다.
테이블의 검색 최적화 구성하기¶
참고
큰 테이블(테라바이트(TB) 이상의 데이터가 포함된 테이블)에 검색 최적화를 추가하면 짧은 시간 내에 크레딧 사용이 즉시 증가할 수 있습니다.
테이블에 검색 최적화를 추가하면 유지 관리 서비스가 즉시 백그라운드에서 테이블에 대한 검색 액세스 경로를 구축합니다. 테이블이 크면 유지 관리 서비스에서 이 작업을 대규모로 병렬 처리하므로 짧은 시간 내에 비용이 증가할 수 있습니다.
큰 테이블에 검색 최적화를 추가하기 전, 비용 예상하기 를 수행하여 예상 비용을 확인할 수 있습니다.
테이블에 검색 최적화를 추가하려면 ON 절을 포함하거나 포함하지 않은 채로 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령을 사용하십시오.
ON 절 없이 명령을 사용하면 지원되는 데이터 타입 을 사용하는 모든 열에 대해 EQUALITY 검색 방법을 사용하여 쿼리의 성능을 개선하도록 검색 액세스 경로가 설정됩니다.
검색 최적화를 위해 구성되는 열에 대해 더 많은 제어 권한이 필요하거나 EQUALITY 외에 다른 검색 방법을 사용하려면 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령에서 ON 절 을 사용하십시오.
ADD SEARCH OPTIMIZATION의 ON 절에서 검색 최적화를 위해 활성화해야 하는 열을 지정합니다. 지정된 열에 대해 검색 최적화를 활성화할 때 검색 방법도 지정할 수 있습니다(예: 같음 및 IN 검색의 경우 EQUALITY, GEOGRAPHY 검색의 경우 GEO, 하위 문자열 검색의 경우 SUBSTRING).
검색 최적화 비용을 관리하려면 검색 최적화가 필요하지 않은 특정 열에서 검색 최적화를 제거할 수 있습니다.
다음 섹션에서는 테이블에 대한 검색 최적화 구성 방법을 설명합니다.
특정 열의 검색 최적화 구성하기¶
특정 열에 대한 검색 최적화를 구성하려면 ON 절과 함께 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령을 사용하십시오.
참고
이 명령을 실행할 때 테이블에 검색 최적화를 추가할 수 있는 권한 이 있는 역할을 사용합니다.
ON 절은 특정 열에 대한 검색 최적화를 구성하도록 지정합니다. 구문에 대한 자세한 내용은 ALTER TABLE … ADD SEARCH OPTIMIZATION에 관한 섹션 을 참조하십시오.
참고
테이블의 적용 가능한 모든 열에 같음 조건자와 IN 조건자에 대한 검색 최적화만 적용하려면 전체 테이블에 대한 검색 최적화 추가 및 유지 관리하기 섹션을 참조하십시오.
이 명령을 실행한 후 검색 최적화를 위해 열이 구성되었는지 확인 할 수 있습니다.
다음 섹션에는 검색 최적화를 위한 구성을 지정하는 방법을 보여주는 예가 포함됩니다.
예: 특정 열에 대해 같음 조건자와 IN 조건자 지원¶
테이블 t1
의 열 c1
, c2
, c3
에 대한 같음 조건자로 검색을 최적화하려면 다음 문을 실행하십시오.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2, c3);
ON 절에서 동일한 검색 방법을 두 번 이상 지정할 수도 있습니다.
-- This statement is equivalent to the previous statement.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1), EQUALITY(c2, c3);
예: 적용 가능한 모든 열에 대해 같음 조건자와 IN 조건자 지원¶
테이블의 적용 가능한 모든 열에 대한 같음 조건자로 검색을 최적화하려면 다음 문을 실행하십시오.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(*);
다음 사항을 참고하십시오.
검색 방법 및 대상에 대한 구문의 설명 에서 기술한 바와 같이, 주어진 방법에 대해 별표와 특정 열을 지정할 수 없습니다.
ON 절을 생략하면 테이블에서 적용 가능한 모든 열에서 같음 조건자와 IN 조건자에 대한 검색 최적화도 구성되지만, ON 절의 지정과 생략 사이에는 차이점이 있습니다. 전체 테이블에 대한 검색 최적화 추가 및 유지 관리하기 섹션을 참조하십시오.
예: 다양한 유형의 조건자 지원¶
열 c1
과 c2
열에 대한 같음 조건자를 사용한 검색과 열 c3
에 대한 하위 문자열 검색을 최적화하려면 다음 문을 실행하십시오.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2), SUBSTRING(c3);
예: VARIANT의 필드에 대해 같음 조건자와 IN 조건자 지원¶
VARIANT 열 c4
의 필드 user
에 중첩된 VARIANT 필드 uuid
에 대한 같음 조건자로 검색을 최적화하려면 다음 문을 실행하십시오.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c4:user:uuid);
예: 지리 공간 함수 지원¶
c1
열의 GEOGRAPHY 오브젝트와 함께 지리 공간 함수를 사용하는 조건자로 검색을 최적화하려면 다음 문을 실행하십시오.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON GEO(c1);
전체 테이블에 대한 검색 최적화 추가 및 유지 관리하기¶
지원되는 데이터 타입(VARIANT 및 GEOGRAPHY 제외)의 모든 열에 대해 EQUALITY만 지정하려는 경우 ON 절 없이 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령을 사용하십시오.
참고
이 명령을 실행할 때 테이블에 검색 최적화를 추가할 수 있는 권한 이 있는 역할을 사용합니다.
예:
alter table test_table add search optimization;
구문에 대한 자세한 내용은 ALTER TABLE에서의 검색 최적화 섹션 을 참조하십시오.
이 명령을 실행한 후 검색 최적화를 위해 열이 구성되었는지 확인 할 수 있습니다.
이후에 추가되는 열에 미치는 영향¶
ON 절 없이 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령을 실행하면 이후에 테이블에 추가되는 열도 전부 EQUALITY에 대해 구성됩니다.
하지만 같은 테이블에서 ON 절이 있는 ALTER TABLE … { ADD | DROP } SEARCH OPTIMIZATION을 실행하면 이후에 테이블에 추가되는 열은 EQUALITY에 대해 자동으로 구성되지 않습니다. EQUALITY에 대해 이처럼 새로 추가된 열을 구성하려면 ALTER TABLE … ADD SEARCH OPTIMIZATION ON …을 실행해야 합니다.
테이블이 검색 최적화를 위해 구성되었는지 확인하기¶
테이블과 그 열이 검색 최적화를 위해 구성되었는지 확인하는 방법:
테이블과 해당 열에 대한 검색 최적화 구성을 표시합니다.
SHOW TABLES 명령을 실행하여 검색 최적화가 추가되었는지 확인하고 테이블의 최적화 정도를 확인합니다.
예:
SHOW TABLES LIKE '%test_table%';
다음 명령의 출력에서:
SEARCH_OPTIMIZATION이
ON
인지 확인합니다. 이는 검색 최적화가 추가되었음을 나타냅니다.SEARCH_OPTIMIZATION_PROGRESS의 값을 확인합니다. 이는 현재까지 최적화된 테이블의 백분율을 지정합니다.
검색 최적화가 처음으로 테이블에 추가되면 성능상의 이점이 즉시 나타나지 않습니다. 검색 최적화 서비스가 백그라운드에서 데이터 채우기를 시작합니다. 유지관리가 테이블의 현재 상태에 근접할 수록 더 많은 이점이 점점 나타납니다.
검색 최적화가 작동하는지 확인하기 위해 쿼리를 실행하기 전, 테이블이 완전히 최적화되었음이 표시될 때까지 대기합니다.
쿼리를 실행하여 검색 최적화가 작동하는지 확인합니다.
Snowflake 최적화 프로그램은 특정 쿼리에서의 검색 최적화 서비스를 사용 시점을 자동으로 선택합니다. 사용자는 검색 최적화가 사용되는 쿼리를 제어할 수 없습니다.
검색 최적화 서비스가 최적화를 수행할 수 있도록 설계된 쿼리를 선택합니다. 검색 최적화의 이점을 누리는 테이블과 열 식별하기 섹션을 참조하십시오.
웹 UI에서 이 쿼리에 대한 쿼리 계획을 확인하고 쿼리 노드 《검색 최적화 액세스》가 쿼리 계획의 일부에 해당하는지 확인합니다.
테이블에 대한 검색 최적화 구성 표시하기¶
테이블에 대한 검색 최적화 구성을 표시하려면 DESCRIBE SEARCH OPTIMIZATION 명령을 사용하십시오.
예를 들어, 다음 문을 실행하여 열에 대한 검색 최적화를 구성한다고 가정하겠습니다.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1);
DESCRIBE SEARCH OPTIMIZATION을 실행하면 다음 출력이 생성됩니다.
DESCRIBE SEARCH OPTIMIZATION ON t1;
+---------------+----------+--------+------------------+--------+
| expression_id | method | target | target_data_type | active |
+---------------+----------+--------+------------------+--------+
| 1 | EQUALITY | C1 | NUMBER(38,0) | true |
+---------------+----------+--------+------------------+--------+
검색에 최적화된 테이블 관련 작업하기¶
검색 최적화를 사용하는 테이블과 관련한 작업을 하는 경우에는 검색 최적화 서비스에 미치는 영향을 이해해야 합니다.
테이블 수정하기¶
열의 기본값이 변경되면 검색 액세스 경로가 무효화됩니다.
검색 액세스 경로가 무효화된 후 검색 최적화를 다시 사용하려면 SEARCH OPTIMIZATION 속성을 삭제 하고 SEARCH OPTIMIZATION 속성을 테이블에 다시 추가 해야 합니다.
열을 추가 또는 삭제하거나 이름을 변경하면 검색 액세스 경로가 계속 유효합니다.
특정 열을 지정하지 않고 전체 테이블에 대해 검색 최적화를 활성화한 다음 테이블에 열을 추가하면 검색 액세스 경로에 새 열이 자동으로 추가됩니다. 하지만 열에 대한 검색 최적화를 활성화할 때 ON 절을 사용한 경우 새 열이 자동으로 추가되지 않습니다.
테이블에서 열을 삭제하면 삭제된 열이 검색 액세스 경로에서 자동으로 제거됩니다.
열 이름을 변경하는 경우에는 검색 액세스 경로를 변경할 필요가 없습니다.
테이블을 삭제하면 SEARCH OPTIMIZATION 속성 및 검색 액세스 경로도 함께 삭제됩니다. 참고:
테이블 삭제를 즉시 취소하면 검색 최적화가 테이블의 속성으로 다시 설정됩니다.
테이블을 삭제할 때 검색 액세스 경로의 데이터 보존 기간은 테이블과 동일합니다.
테이블에서 SEARCH OPTIMIZATION 속성을 삭제 하면 검색 액세스 경로가 제거됩니다. SEARCH OPTIMIZATION 속성을 테이블에 다시 추가 할 때 유지관리 서비스는 검색 액세스 경로를 다시 생성해야 합니다. (속성을 삭제할 수 있는 방법 없음)
테이블, 스키마 또는 데이터베이스 복제하기¶
테이블, 스키마 또는 데이터베이스를 복제하면 각 테이블의 SEARCH OPTIMIZATION 속성과 검색 액세스 경로도 함께 복제됩니다. (테이블, 스키마 또는 데이터베이스를 복제하면 각 테이블과 해당 검색 액세스 경로의 복사를 수행하지 않는 복제 가 생성됩니다.)
CREATE TABLE … LIKE를 사용하여 원래 테이블과 열이 동일한 비어 있는 새 테이블을 생성하면 SEARCH OPTIMIZATION 속성이 새 테이블에 복사되지 않습니다.
보조 데이터베이스(데이터베이스 복제 지원)에서 테이블 관련 작업하기¶
기본 데이터베이스의 테이블에 SEARCH OPTIMIZATION 속성이 활성화되어 있으면 해당 속성은 보조 데이터베이스의 해당 테이블에 복제됩니다.
보조 데이터베이스의 검색 액세스 경로는 복제되지 않으며 자동으로 다시 작성됩니다. 이 프로세스에서는 검색 최적화 서비스의 비용 관리하기 의 설명과 같은 종류의 비용이 발생한다는 점에 유의하십시오.
테이블 공유하기¶
데이터 공급자는 Secure Data Sharing 를 사용하여 검색 최적화가 활성화된 테이블을 공유할 수 있습니다.
공유 테이블을 쿼리할 때 데이터 컨슈머는 검색 최적화 서비스의 성능 향상을 통해 이점을 활용할 수 있습니다.
검색 최적화 서비스의 비용 관리하기¶
검색 최적화 서비스는 저장소 및 컴퓨팅 리소스 모두의 비용 영향을 줍니다.
저장소 리소스: 검색 최적화 서비스는 검색 최적화가 활성화된 각 테이블에 대한 공간이 필요한 검색 액세스 경로 데이터 구조를 생성합니다. 검색 액세스 경로의 저장 비용은 여러 요인에 따라 달라지며, 그러한 요인은 다음과 같습니다.
테이블의 고유 값 수(NDVs). 모든 열에 검색 액세스 경로를 사용하는 데이터 타입을 있고 각 열의 모든 데이터 값이 고유한 매우 예외적인 경우, 원래 테이블의 크기에 해당하는 저장소 공간이 필요할 수 있습니다.
그러나 일반적으로 크기는 원래 테이블 크기의 약 1/4입니다.
컴퓨팅 리소스:
테이블에 검색 최적화를 추가하면 최초 빌드 단계에서 리소스가 소비됩니다.
검색 최적화 서비스를 유지관리하려면 리소스도 필요합니다. 변동성이 높은 경우(즉, 테이블의 데이터가 대량으로 변경되는 경우) 더 많은 리소스가 소비됩니다. 이러한 비용은 수집(추가 또는 변경)된 데이터의 양에 대략적으로 비례합니다. 삭제의 경우에도 약간의 비용이 소비됩니다.
자동 클러스터링 은 검색 최적화로 테이블의 쿼리 대기 시간을 개선하는 동시에 검색 최적화의 유지 관리 비용을 더욱 늘릴 수 있습니다. 테이블의 이탈률이 높은 경우 테이블에 대해 자동 클러스터링을 활성화하고 검색 최적화를 구성하면 테이블이 단지 검색 최적화를 위해 구성된 경우보다 유지 관리 비용이 더 많아질 수 있습니다.
Snowflake는 사용된 실제 리소스에 대해서만 계정에 요금을 청구하여 크레딧 사용이 효율적이 될 수 있도록 합니다. 청구는 1초 증분으로 계산됩니다.
컴퓨팅 시간당 요금에 대해서는 Snowflake 서비스 사용 테이블 의 《서버리스 기능 크레딧 테이블》을 참조하십시오.
검색 최적화 서비스를 활성화하면 서비스 이용에 따른 비용을 확인 할 수 있습니다.
팁
Snowflake는 이 기능을 서서히 시작하고(즉, 처음에는 몇 개의 테이블에만 검색 최적화를 추가) 비용과 이점을 면밀히 살펴볼 것을 권장합니다.
비용 예상하기¶
테이블에 검색 최적화를 추가하고 검색 최적화를 위해 특정 열을 구성하는 비용을 예상하려면 SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 함수를 사용하십시오.
일반적으로 비용은 다음에 비례합니다.
기능이 활성화된 테이블 수 및 해당 테이블의 고유 값 수.
이 테이블에서 변경된 데이터의 수량.
중요
SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 함수에서 반환되는 값은 테이블의 부분 데이터 세트 샘플링을 기반으로 한 최선의 추정치입니다. 예상 비용은 실제 실현 비용과 크게 다를 수 있습니다(최대 50% 또는 드물긴 하지만 몇 배나 차이가 날 수도 있음).
비용 줄이기¶
검색 최적화를 활성화할 테이블과 열을 신중하게 선택하여 검색 최적화 서비스 비용을 관리할 수 있습니다.
또한, 검색 최적화 서비스 비용을 줄이려면:
Snowflake는 테이블에서 DML 연산을 일괄 처리하는 것을 권장합니다.
DELETE
: 테이블이 가장 최근 기간(예: 가장 최근 날짜, 주 또는 월)에 해당하는 데이터를 저장하는 경우 이전 데이터를 삭제하여 테이블을 자르면 검색 최적화 서비스를 업데이트해야 합니다. 일부 경우에는 삭제 빈도를 줄여(예: 1시간마다가 아닌 매일) 비용을 절약할 수 있습니다.INSERT
,UPDATE
및MERGE
: 이러한 타입의 DML 문을 테이블에서 일괄 처리하면 검색 최적화 서비스의 유지관리 비용을 줄일 수 있습니다.
전체 테이블을 재클러스터링하는 경우에는 재클러스터링을 하기 전에 해당 테이블에 대한 SEARCH OPTIMIZATION 속성을 삭제 한 다음, 재클러스터링 후 SEARCH OPTIMIZATION 속성을 테이블에 다시 추가 해 보십시오.
하위 문자열 검색(
ON SUBSTRING(col)
) 또는 VARIANTs(ON EQUALITY(variant_col)
)에 대한 검색 최적화를 활성화하기 전에 SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 를 호출하여 비용을 추정하십시오. 이러한 검색 방법의 최초 빌드와 유지 관리에 매우 많은 계산이 필요할 수 있으므로 성능과 비용 사이의 균형을 평가해야 합니다.
특정 열 또는 전체 테이블에서 검색 최적화 제거하기¶
특정 열에 대한 검색 최적화 구성을 제거하거나 전체 테이블에서 SEARCH OPTIMIZATION 속성을 제거할 수 있습니다.
특정 열의 검색 최적화 삭제하기¶
특정 열에 대한 검색 최적화 구성을 삭제하려면 ON 절과 함께 ALTER TABLE … DROP SEARCH OPTIMIZATION 명령을 사용하십시오.
예를 들어, DESCRIBE SEARCH OPTIMIZATION 명령을 실행하면 다음 식이 인쇄된다고 가정하겠습니다.
DESCRIBE SEARCH OPTIMIZATION ON t1;
+---------------+-----------+-----------+-------------------+--------+
| expression_id | method | target | target_data_type | active |
+---------------+-----------+-----------+-------------------+--------+
| 1 | EQUALITY | C1 | NUMBER(38,0) | true |
| 2 | EQUALITY | C2 | VARCHAR(16777216) | true |
| 3 | EQUALITY | C4 | NUMBER(38,0) | true |
| 4 | EQUALITY | C5 | VARCHAR(16777216) | true |
| 5 | EQUALITY | V1 | VARIANT | true |
| 6 | SUBSTRING | C2 | VARCHAR(16777216) | true |
| 7 | SUBSTRING | C5 | VARCHAR(16777216) | true |
| 8 | GEO | G1 | GEOGRAPHY | true |
| 9 | EQUALITY | V1:"key1" | VARIANT | true |
| 10 | EQUALITY | V1:"key2" | VARIANT | true |
+---------------+-----------+-----------+-------------------+--------+
열 c2
의 하위 문자열에 대한 검색 최적화를 삭제하려면 다음 문을 실행하십시오.
ALTER TABLE t1 DROP SEARCH OPTIMIZATION ON SUBSTRING(c2);
열 c5
의 모든 메서드에 대한 검색 최적화를 삭제하려면 다음 문을 실행하십시오.
ALTER TABLE t1 DROP SEARCH OPTIMIZATION ON c5;
열 c5
는 같음 검색과 하위 문자열 검색을 최적화하도록 구성되어 있으므로 위의 문은 c5
에 대한 같음 검색과 하위 문자열 검색을 위한 구성을 삭제합니다.
열 c1
에서 같음 검색 최적화를 삭제하고 식 ID 6
및 8
로 지정된 구성을 삭제하려면 다음 문을 실행하십시오.
ALTER TABLE t1 DROP SEARCH OPTIMIZATION ON EQUALITY(c1), 6, 8;
구문에 대한 자세한 내용은 ALTER TABLE … DROP SEARCH OPTIMIZATION에 대한 섹션 을 참조하십시오.
테이블에서 검색 최적화 제거하기¶
테이블에서 SEARCH OPTIMIZATION 속성을 제거하는 방법:
테이블에서 검색 최적화를 제거할 수 있는 권한 이 있는 역할로 전환합니다.
ON 절 없이 ALTER TABLE … DROP SEARCH OPTIMIZATION 명령을 실행합니다.
ALTER TABLE [IF EXISTS] <table_name> DROP SEARCH OPTIMIZATION;
예:
alter table test_table drop search optimization;
자세한 내용은 ALTER TABLE … DROP SEARCH OPTIMIZATION에 대한 섹션 을 참조하십시오.
예¶
다음 코드는 검색 최적화 서비스의 생성 및 사용을 보여줍니다.
데이터가 포함된 테이블을 생성합니다.
create or replace table test_table (id int, c1 int, c2 string, c3 date) as select * from values (1, 3, '4', '1985-05-11'), (2, 4, '3', '1996-12-20'), (3, 2, '1', '1974-02-03'), (4, 1, '2', '2004-03-09'), (5, null, null, null);SEARCH OPTIMIZATION 속성을 테이블에 추가합니다.
alter table test_table add search optimization;검색 최적화 서비스를 사용할 수 있는 쿼리는 다음과 같습니다.
select * from test_table where id = 2;select * from test_table where c2 = '1';select * from test_table where c3 = '1985-05-11';select * from test_table where c1 is null;select * from test_table where c1 = 4 and c3 = '1996-12-20';암시적 캐스트는 열이 아닌 상수에서 수행되므로 다음 쿼리에서는 검색 최적화 서비스를 사용할 수 있습니다.
select * from test_table where c2 = 2;캐스트가 테이블의 열에서 수행되므로 다음에서는 검색 최적화 서비스를 사용할 수 없습니다.
select * from test_table where cast(c2 as number) = 2;IN 절은 검색 최적화 서비스에서 지원됩니다.
select id, c1, c2, c3 from test_table where id IN (2, 3) order by id;조건자가 검색 최적화 서비스에서 개별적으로 지원되는 경우에는 논리곱
AND
로 조인될 수 있으며 여전히 검색 최적화 서비스에서 지원됩니다.select id, c1, c2, c3 from test_table where c1 = 1 and c3 = TO_DATE('2004-03-09') order by id;DELETE 및 UPDATE(및 MERGE)에서도 검색 최적화 서비스를 사용할 수 있습니다.
delete from test_table where id = 3;update test_table set c1 = 99 where id = 4;