검색 최적화 서비스 사용하기

검색 최적화 서비스는 필터링을 위해 광범위한 조건자 세트를 사용하는 특정 유형의 조회 및 분석 쿼리의 성능을 크게 개선할 수 있습니다.

이 항목의 내용:

검색 최적화 서비스 이해하기

검색 최적화 서비스의 목적은 다음을 포함하여 테이블에 대한 특정 유형의 쿼리 성능을 대폭 향상하는 것입니다.

  • 테이블에 대한 선택적 포인트 조회 쿼리. 포인트 조회 쿼리에서는 1개 또는 몇 개의 고유 행만 반환합니다. 사용 사례의 예는 다음과 같습니다.

    • 매우 선택적인 필터를 사용하여 중요한 대시보드에서 신속하게 응답을 수신해야 하는 비즈니스 사용자.

    • 대용량 데이터를 탐색하고 데이터의 특정 하위 세트를 살펴보는 데이터 과학자.

    • 광범위한 필터링 조건자 세트을 기반으로 작은 결과 세트를 검색하는 데이터 애플리케이션.

  • 하위 문자열 및 정규식 검색(예: LIKE, ILIKE, RLIKE 등).

  • 특정 유형의 조건자(같음 조건자, IN 조건자, ARRAY_CONTAINSARRAYS_OVERLAP 을 사용하는 조건자, NULL 값이 있는지 검사하는 조건자)를 사용하는 VARIANT, OBJECT 및 ARRAY 열의 필드에 대한 쿼리.

  • GEOGRAPHY 값과 함께 선택한 지리 공간 함수를 사용하는 쿼리.

검색 최적화 서비스의 이점을 활용할 수 있는 쿼리를 식별하면 해당 쿼리에 사용되는 열과 테이블에 대한 검색 최적화를 구성할 수 있습니다.

검색 최적화 서비스는 어떻게 작동합니까?

포인트 조회 성능을 향상하기 위해 검색 최적화 서비스에서는 최적화된 검색 액세스 경로의 역할을 하는 영구 데이터 구조를 사용합니다.

백그라운드에서 실행되는 유지관리 서비스는 검색 액세스 경로를 생성한 후 유지관리를 수행합니다.

  • 테이블의 검색 최적화를 구성하면, 유지관리 서비스가 조회를 수행하기 위해 필요한 데이터를 사용하여 검색 액세스 경로를 생성한 후 채웁니다.

    데이터를 채우는 프로세스에는 시간이 걸릴 수 있으며, 테이블 크기에 다릅니다. 이 서비스는 백그라운드에서 이러한 작업을 수행하며 테이블에서 동시 작업을 차단하지 않습니다.

  • 테이블의 데이터가 업데이트되면(예: 새 데이터 세트 로드 또는 DML 작업을 통해) 유지관리 서비스는 검색 액세스 경로를 자동으로 업데이트하여 데이터 변경 사항을 적용합니다.

    검색 액세스 경로가 아직 업데이트되지 않은 상태에서 쿼리를 실행하면, 쿼리의 실행 속도가 느릴 수 있지만 항상 최신 결과가 반환됩니다.

이러한 검색 액세스 경로 및 유지관리 서비스는 사용자에게 투명하게 제공됩니다. 사용자는 검색 액세스 경로 유지관리 서비스에서 사용할 웨어하우스를 생성할 필요가 없습니다.

그러나 이 서비스를 위한 저장소 및 컴퓨팅 리소스의 비용이 발생한다는 점에 유의하십시오. 자세한 내용은 이 항목의 검색 최적화 서비스의 비용 관리하기 섹션을 참조하십시오.

쿼리 성능을 최적화하기 위해 다른 솔루션 고려하기

검색 최적화 서비스는 쿼리 성능을 최적화하기 위한 여러 방법 중 하나입니다. 관련 기술은 다음과 같습니다.

  • 테이블 클러스터링.

  • 1개 이상의 구체화된 뷰 만들기(클러스터형 또는 비클러스터형).

이러한 각 기술은 이점이 다릅니다.

  • 클러스터링 키에 있지 않은 경우를 제외하고, 테이블을 클러스터링하면 다음 작업의 성능을 개선할 수 있습니다.

    • 범위 검색.

    • 같음 검색.

    그러나 테이블은 단일 키(1개 이상의 열 또는 식이 포함될 수 있음)에만 클러스터링될 수 있습니다.

  • 검색 최적화 서비스는 지원되는 데이터 타입 에 대해 같음 검색의 성능뿐 아니라 다른 유형의 검색 성능도 개선할 수 있습니다.

  • 구체화된 뷰는 같음 검색과 범위 검색, 일부 정렬 작업 모두의 성능을 개선할 수 있지만, 구체화된 뷰에 포함된 행과 열의 하위 세트에서만 사용할 수 있습니다. 또한, 구체화된 뷰는 동일한 소스 테이블(또는 해당 테이블의 하위 세트)에서 서로 다른 클러스터링 키를 정의하거나 평면화 JSON/베리언트 데이터 결합과 함께 사용할 수도 있습니다.

다음 테이블은 이러한 세 가지 최적화에서의 저장소 또는 컴퓨팅 요금의 발생 여부를 보여줍니다.

저장소 요금

컴퓨팅 요금

검색 최적화 서비스

구체화된 뷰

테이블 클러스터링

검색 최적화 서비스에 필요한 액세스 제어 권한은 무엇입니까?

테이블에 대한 검색 최적화를 추가하거나 구성하거나 제거하기 위해 필요한 권한은 다음과 같습니다.

  • 테이블에 대한 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. (이것은 미리 보기 기능입니다.)

현재 검색 최적화 서비스에서는 부동 소수점 데이터 타입 또는 위에 나열되지 않은 기타 데이터 타입을 지원하지 않습니다. Snowflake는 향후 더 많은 데이터 타입에 대한 지원을 추가할 수 있습니다.

또한, 검색 최적화 서비스는 데이터 정렬도 지원하지 않습니다.

검색 최적화의 이점을 활용할 수 있는 쿼리 식별하기

검색 최적화는 다음 유형의 쿼리 성능을 향상하는 데 매우 적합합니다.

  • 일반적으로 몇 초 이상 실행되는 쿼리.

  • 쿼리 필터 작업을 통해 액세스하는 열 중 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 조건자

검색 최적화 서비스는 다음을 사용하는 쿼리의 성능을 개선할 수 있습니다.

  • 같음 조건자(예: <열_이름> = <상수>).

  • IN 을 사용하는 조건자( 참조).

하위 문자열 및 정규식

검색 최적화 서비스는 하위 문자열을 검색하거나 정규식을 사용하는 조건자로 쿼리의 성능을 개선할 수 있습니다. 여기에는 다음을 사용하는 조건자가 포함됩니다.

검색 최적화 서비스는 5자 이상의 하위 문자열을 검색할 때 성능을 개선할 수 있습니다. (선택적 하위 문자열이 많을수록 성능을 향상할 수 있습니다.)

예를 들어, 하위 문자열이 5자보다 짧으므로 검색 최적화 서비스에서는 다음 조건자에 대해 검색 액세스 경로를 사용하지 않습니다.

LIKE '%TEST%'

다음 조건자의 경우 검색 최적화 서비스는 이 쿼리를 최적화하여 검색 액세스 경로를 사용해 SEARCHOPTIMIZED 에 대한 하위 문자열을 검색할 수 있습니다.

LIKE '%SEARCH%IS%OPTIMIZED%'

이 예에서, 하위 문자열이 5자보다 짧으므로 검색 최적화 서비스에서는 IS 에 대해 검색 액세스 경로를 사용하지 않습니다.

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 열을 자동으로 포함합니다. 이는 구조가 깊이 중첩되고 자주 변경되는 열에도 적용됩니다.

다음 섹션에서는 이 지원에 대한 자세한 내용을 제공합니다.

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_fieldVARIANT 열의 필드에 대한 경로 입니다.

  • 다음 형식의 같음 조건자:

    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 오브젝트와 함께 지리 공간 함수를 사용하는 조건자로 쿼리의 성능을 개선할 수 있습니다. 다음 섹션에서 더 자세히 설명합니다.

참고

GEOMETRY 오브젝트는 아직 지원되지 않습니다.

지리 공간 함수와 함께 지원되는 조건자

다음 함수를 사용하는 조건자가 있는 쿼리의 경우:

다음과 같은 경우에 검색 최적화 서비스는 성능을 개선할 수 있습니다.

  • 한 입력식은 테이블의 GEOGRAPHY 열이며,

  • 다른 입력식은 (변환 또는 생성자 함수 를 통해 생성됨) GEOGRAPHY 상수입니다.

  • ST_DWITHIN의 경우 거리 인자는 음이 아닌 REAL 상수입니다.

검색 최적화 서비스는 선택의 자유도가 매우 높은 조건자를 위해 설계되었고 조건자는 지리 공간 오브젝트 간의 근접성을 기준으로 필터링하므로, 테이블의 근접성을 기준으로 지리 공간 오브젝트를 클러스터링하면 성능이 향상될 수 있습니다. 예를 들어, GEOGRAPHY 값을 ST_GEOHASH 값으로 클러스터링하거나 오브젝트의 도심 또는 경계 상자 좌표의 조합으로 클러스터링할 수 있습니다.

이 기능에는 검색 최적화 서비스에 적용되는 것과 동일한 제한 사항 이 있습니다.

지리 공간 함수를 사용하는 예

다음 문을 실행하면 이 섹션의 예에 사용된 테이블을 만들고 구성할 수 있습니다.

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;
지원되는 조건자의 예

다음 쿼리는 검색 최적화 서비스에서 지원하는 쿼리의 예입니다. 검색 최적화 서비스는 검색 액세스 경로를 사용하여 이 쿼리의 성능을 개선할 수 있습니다.

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 는 많은 행을 반환하는 경우, 검색 최적화를 통해 쿼리 성능을 향상할 수 없습니다.

논리합의 경우 분리된 각 조건자는 쿼리에서 결정적이지 않습니다. 다른 조건자를 평가한 후 검색 최적화를 통해 성능을 향상할 수 있는지 결정해야 합니다.

조인

검색 최적화 서비스는 작은 테이블을 큰 테이블과 조인하는 쿼리의 성능을 개선할 수 있습니다. 자세한 내용은 검색 최적화 서비스를 활성화하여 조인 성능 향상하기 섹션을 참조하십시오.

검색 최적화 서비스는 뷰(보안 뷰 포함)의 성능을 간접적으로 향상할 수 있습니다. 뷰의 기본 테이블에 검색 최적화가 활성화되어 있고 쿼리가 해당 테이블에 대해 선택적 조건자를 사용하는 경우 검색 최적화 서비스는 행을 필터링할 때 성능을 향상할 수 있습니다.

보기의 모든 테이블에서 검색 최적화가 활성화되지 않아도 됩니다. 검색 최적화는 각 테이블에서 독립적으로 수행됩니다.

마스킹 정책과 행 액세스 정책을 사용하는 테이블

검색 최적화 서비스는 마스킹 정책과 행 액세스 정책을 사용하는 테이블에 대한 쿼리 성능을 향상할 수 있습니다.

행 액세스 정책이 검색 최적화 서비스에서 지원하지 않는 필터를 사용하는 경우 검색 최적화 서비스는 잘라내기에 이 필터를 사용하지 않지만, 잘라내기를 위한 쿼리에서는 지원되는 다른 필터를 사용합니다. 이와 같은 경우, 쿼리가 행 액세스 정책으로 인해 아무런 결과도 반환하지 않더라도, 이 잘라내기의 효과를 보면 쿼리 필터에 지정된 값이 존재함을 알 수 있습니다.

검색 최적화 서비스에서 지원되지 않는 쿼리

검색 최적화 서비스는 다음을 지원하지 않습니다.

  • 외부 테이블.

  • 구체화된 뷰.

  • 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) 이상의 데이터가 포함된 테이블)에 검색 최적화를 추가하면 짧은 시간 내에 크레딧 사용이 즉시 증가할 수 있습니다.

테이블에 검색 최적화를 추가하면 유지 관리 서비스가 즉시 백그라운드에서 테이블에 대한 검색 액세스 경로를 구축합니다. 테이블이 크면 유지 관리 서비스에서 이 작업을 대규모로 병렬 처리하므로 짧은 시간 내에 비용이 증가할 수 있습니다.

큰 테이블에 검색 최적화를 추가하기 전, 비용 예상하기 를 수행하여 예상 비용을 확인할 수 있습니다.

테이블에 검색 최적화를 추가하려면 ALTER TABLEADD SEARCH OPTIMIZATION 명령을 사용합니다. 그러면 지원되는 데이터 타입 을 사용하는 모든 열에 대해 같음 조건자 쿼리와 IN 조건자 쿼리의 성능을 개선하기 위해 검색 액세스 경로가 설정됩니다.

다른 유형의 쿼리에 대한 성능을 개선하고 싶거나 검색 최적화를 위해 구성되는 열에 대해 더 많은 제어 권한이 필요한 경우 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령에서 ON 절 을 사용하십시오.

ADD SEARCH OPTIMIZATION의 ON 절에서 검색 최적화를 위해 활성화해야 하는 열을 지정합니다. 주어진 열에 대해 검색 최적화를 활성화할 때 쿼리 방법(예: 같음 및 IN 검색 등)을 지정할 수도 있습니다.

검색 최적화 비용을 관리하려면 검색 최적화가 필요하지 않은 특정 열에서 검색 최적화를 제거할 수 있습니다.

마지막으로, 검색 최적화 서비스가 추가 유형의 조건자와 데이터 타입(예: 하위 문자열 및 정규식, GEOGRAPHY, 필드, VARIANTs 등에 있음)을 지원하므로 이 지원을 활용하기 위해 구성해야 하는 열을 지정할 수 있습니다.

다음 섹션에서는 테이블에 대한 검색 최적화 구성 방법을 설명합니다.

특정 열의 검색 최적화 구성하기

특정 열에 대한 검색 최적화를 구성하려면 ON 절과 함께 ALTER TABLEADD 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(*);

다음 사항을 참고하십시오.

예: 다양한 유형의 조건자 지원

c1c2 열에 대한 같음 조건자를 사용한 검색과 열 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);

전체 테이블에 대한 검색 최적화 추가하기

지원되는 데이터 타입(VARIANT 제외)의 모든 열에 대해 EQUALITY만 지정하려는 경우 ON 절 없이 ALTER TABLEADD SEARCH OPTIMIZATION 명령을 사용하십시오.

참고

이 명령을 실행할 때 테이블에 검색 최적화를 추가할 수 있는 권한 이 있는 역할을 사용합니다.

예:

alter table test_table add search optimization;

구문에 대한 자세한 내용은 ALTER TABLE에서의 검색 최적화 섹션 을 참조하십시오.

이 명령을 실행한 후 검색 최적화를 위해 열이 구성되었는지 확인 할 수 있습니다.

다음 사항을 참고하십시오.

  • 이 명령을 실행하면 이후에 테이블에 추가되는 모든 열도 EQUALITY에 대해 구성됩니다.

  • 같은 테이블에서 ON 절이 있는 ALTER TABLE … { ADD | DROP } SEARCH OPTIMIZATION을 실행하면 이후에 테이블에 추가되는 열은 EQUALITY에 대해 자동으로 구성되지 않습니다.

    EQUALITY에 대해 이처럼 새로 추가된 열을 구성하려면 ALTER TABLE … ADD SEARCH OPTIMIZATION ON …을 실행해야 합니다.

테이블이 검색 최적화를 위해 구성되었는지 확인하기

테이블과 그 열이 검색 최적화를 위해 구성되었는지 확인하는 방법:

  1. 테이블과 해당 열에 대한 검색 최적화 구성을 인쇄합니다.

  2. SHOW TABLES 명령을 실행하여 검색 최적화가 추가되었는지 확인하고 테이블의 최적화 정도를 확인합니다.

    예:

    SHOW TABLES LIKE '%test_table%';
    

    다음 명령의 출력에서:

    • SEARCH_OPTIMIZATION이 ON 인지 확인합니다. 이는 검색 최적화가 추가되었음을 나타냅니다.

    • SEARCH_OPTIMIZATION_PROGRESS의 값을 확인합니다. 이는 현재까지 최적화된 테이블의 백분율을 지정합니다.

      검색 최적화가 처음으로 테이블에 추가되면 성능상의 이점이 즉시 나타나지 않습니다. 검색 최적화 서비스가 백그라운드에서 데이터 채우기를 시작합니다. 유지관리가 테이블의 현재 상태에 근접할 수록 더 많은 이점이 점점 나타납니다.

      검색 최적화가 작동하는지 확인하기 위해 쿼리를 실행하기 전, 테이블이 완전히 최적화되었음이 표시될 때까지 대기합니다.

  3. 쿼리를 실행하여 검색 최적화가 작동하는지 확인합니다.

    Snowflake 최적화 프로그램은 특정 쿼리에서의 검색 최적화 서비스를 사용 시점을 자동으로 선택합니다. 사용자는 검색 최적화가 사용되는 쿼리를 제어할 수 없습니다.

    검색 최적화 서비스가 최적화를 수행할 수 있도록 설계된 쿼리를 선택합니다. 검색 최적화의 이점을 제공하는 테이블 식별하기 섹션을 참조하십시오.

  4. 웹 UI에서 이 쿼리에 대한 쿼리 계획을 확인하고 쿼리 노드 《검색 최적화 액세스》가 쿼리 계획의 일부에 해당하는지 확인합니다.

검색 최적화 서비스를 활성화하여 조인 성능 향상하기

참고

이 기능은 다양한 리전에 걸쳐 출시되고 있습니다. 이 기능이 활성화된 리전의 목록은 기능 출시: 검색 최적화 서비스의 조인 지원 을 참조하십시오.

검색 최적화 서비스는 큰 테이블을 하나 이상의 작은 테이블(예: 팩트 테이블과 여러 차원 테이블)과 조인하는 쿼리의 성능을 개선할 수 있습니다.

예를 들어, product 가 각 제품에 대한 행을 포함한 테이블이고 sales 가 제품의 각 판매에 대한 행을 포함한 테이블이라고 가정합니다. product 는 더 적은 수의 행을 포함하고 있고 sales 보다 작습니다. 특정 제품의 모든 판매를 찾으려면 sales 테이블(큰 테이블)을 product 테이블(작은 테이블)과 조인합니다. 검색 최적화 서비스로 이러한 조인 유형의 성능을 개선할 수 있습니다.

참고

데이터 웨어하우징에서 큰 테이블을 종종 팩트 테이블 이라고 합니다. 작은 테이블을 차원 테이블 이라고 합니다. 이 항목의 나머지 부분에서는 조인에서 큰 테이블과 작은 테이블을 참조할 때 이러한 용어를 사용합니다.

검색 최적화 서비스가 조인 성능을 개선할 수 있도록 하려면 팩트 테이블(두 테이블 중 큰 테이블)에 검색 최적화 를 추가하십시오.

검색 최적화를 활용하려면 차원 테이블(두 테이블 중 작은 테이블)에 고유한 값이 거의 없어야 합니다. 쿼리의 검색 최적화 비용은 팩트 테이블에서 조회해야 하는 고유한 값의 수에 비례합니다. 차원 테이블에서 고유한 값 수가 너무 많으면 Snowflake가 검색 액세스 경로를 사용하지 않고 일반 테이블 액세스 경로를 대신 사용하도록 결정할 수 있습니다.

지원되는 조인 조건자

검색 최적화 서비스는 다음 유형의 조인 조건자로 쿼리 성능을 개선할 수 있습니다.

  • dimension_table.column = fact_table.column 형태의 같음 조건자.

  • 차원이 있는 조건자 측의 변환(예: 문자열 연결, 추가 등).

  • 여러 같음 조건자의 접속사(AND).

조인으로 지원되는 쿼리의 예

이 섹션에서는 조인을 사용한 검색 최적화의 이점을 누릴 수 있는 쿼리의 예가 나와 있습니다.

예: 조인 조건자로 사용되는 단순한 같음 조건자

다음은 단순한 같음 조건자를 조인 조건자로 사용하는 지원 쿼리의 예입니다. 이 쿼리는 sales 라는 팩트 테이블을 product 라는 차원 테이블과 조인합니다. 팩트 테이블은 크고 검색 최적화가 활성화되어 있습니다. category 열의 선택적 필터로 인해 차원 테이블의 입력이 작습니다.

SELECT sales.date, product.name
FROM sales JOIN product ON (sales.product_id = product.id)
WHERE product.category = 'Cutlery';

예: 차원이 있는 측에서 변환된 조인 조건자

차원(예: 곱하기)이 있는 조건자 측을 변환하는 쿼리도 검색 최적화의 이점을 얻을 수 있습니다.

SELECT sales.date, product.name
FROM sales JOIN product ON (sales.product_id = product.old_id * 100)
WHERE product.category = 'Cutlery';

예: 여러 열에 걸쳐 있는 조인 조건자

조인 조건자가 여러 열에 걸쳐 있는 쿼리도 지원됩니다.

SELECT sales.date, product.name
FROM sales JOIN product ON (sales.product_id = product.id and sales.location = product.place_of_production)
WHERE product.category = 'Cutlery';

예: 포인트 조회 필터와 조인 조건자를 사용하는 쿼리

일반적인 포인트 조회 필터와 조인 조건자를 모두 사용하는 쿼리에서는 검색 최적화 서비스로 둘 모두의 성능을 개선할 수 있습니다. 다음 쿼리에서 검색 최적화 서비스는 sales.location 포인트 조회 조건자뿐 아니라 product_id 조인 조건자도 개선합니다.

SELECT sales.date, product.name
FROM sales JOIN product ON (sales.product_id = product.id)
WHERE product.category = 'Cutlery'
AND sales.location = 'Buenos Aires';

조인 지원의 제한 사항

  • 조인 조건자의 논리합(OR)은 현재 지원되지 않습니다.

  • LIKE/ILIKE/RLIKE 조인 조건자는 현재 지원되지 않습니다.

  • 베리언트 열에 대한 조인 조건자는 현재 지원되지 않습니다.

  • EQUAL_NULL 같음 조건자는 지원되지 않을 것입니다.

  • 이 기능에는 검색 최적화 서비스의 현재 제한 사항 도 적용됩니다.

테이블에 대한 검색 최적화 구성 표시하기

테이블에 대한 검색 최적화 구성을 표시하려면 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   |
+---------------+----------+--------+------------------+--------+

검색 최적화 서비스의 비용 관리하기

검색 최적화 서비스는 저장소 및 컴퓨팅 리소스 모두의 비용 영향을 줍니다.

  • 저장소 리소스: 검색 최적화 서비스는 검색 최적화가 활성화된 각 테이블에 대한 공간이 필요한 검색 액세스 경로 데이터 구조를 생성합니다. 검색 액세스 경로의 저장 비용은 여러 요인에 따라 달라지며, 그러한 요인은 다음과 같습니다.

    • 테이블의 고유 값 수(NDVs). 모든 열에 검색 액세스 경로를 사용하는 데이터 타입을 있고 각 열의 모든 데이터 값이 고유한 매우 예외적인 경우, 원래 테이블의 크기에 해당하는 저장소 공간이 필요할 수 있습니다.

      그러나 일반적으로 크기는 원래 테이블 크기의 약 1/4입니다.

  • 컴퓨팅 리소스:

    • 테이블에 검색 최적화를 추가하면 리소스가 소비됩니다.

    • 검색 최적화 서비스를 유지관리하려면 리소스도 필요합니다. 변동성이 높은 경우(즉, 테이블의 데이터가 대량으로 변경되는 경우) 더 많은 리소스가 소비됩니다. 이러한 비용은 수집(추가 또는 변경)된 데이터의 양에 대략적으로 비례합니다. 삭제의 경우에도 약간의 비용이 소비됩니다.

      자동 클러스터링 은 검색 최적화로 테이블의 쿼리 대기 시간을 개선하는 동시에 검색 최적화의 유지 관리 비용을 더욱 늘릴 수 있습니다. 테이블의 이탈률이 높은 경우 테이블에 대해 자동 클러스터링을 활성화하고 검색 최적화를 구성하면 테이블이 단지 검색 최적화를 위해 구성된 경우보다 유지 관리 비용이 더 많아질 수 있습니다.

      Snowflake는 사용된 실제 리소스에 대해서만 계정에 요금을 청구하여 크레딧 사용이 효율적이 될 수 있도록 합니다. 청구는 1초 증분으로 계산됩니다.

      컴퓨팅 시간당 요금에 대해서는 Snowflake 서비스 사용 테이블 의 《서버리스 기능 크레딧 테이블》을 참조하십시오.

      검색 최적화 서비스를 활성화하면 서비스 이용에 따른 비용을 확인 할 수 있습니다.

Snowflake는 이 기능을 서서히 시작하고(즉, 처음에는 몇 개의 테이블에만 검색 최적화를 추가) 비용과 이점을 면밀히 살펴볼 것을 권장합니다.

비용 예상하기

테이블에 검색 최적화를 추가하고 검색 최적화를 위해 특정 열을 구성하는 비용을 예상하려면 SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 함수를 사용하십시오.

일반적으로 비용은 다음에 비례합니다.

  • 기능이 활성화된 테이블 수 및 해당 테이블의 고유 값 수.

  • 이 테이블에서 변경된 데이터의 수량.

비용 보기

웹 인터페이스 또는 SQL을 사용하여 검색 최적화 서비스에 대한 요금을 확인할 수 있습니다. 컴퓨팅 비용 탐색 섹션을 참조하십시오.

비용 줄이기

검색 최적화를 활성화할 테이블을 신중하게 선택하여 검색 최적화 서비스 비용을 관리할 수 있습니다.

또한, 검색 최적화 서비스 비용을 줄이려면:

  • Snowflake는 테이블에서 DML 연산을 일괄 처리하는 것을 권장합니다.

    • DELETE: 테이블이 가장 최근 기간(예: 가장 최근 날짜, 주 또는 월)에 해당하는 데이터를 저장하는 경우 이전 데이터를 삭제하여 테이블을 자르면 검색 최적화 서비스를 업데이트해야 합니다. 일부 경우에는 삭제 빈도를 줄여(예: 1시간마다가 아닌 매일) 비용을 절약할 수 있습니다.

    • INSERT, UPDATEMERGE: 이러한 타입의 DML 문을 테이블에서 일괄 처리하면 검색 최적화 서비스의 유지관리 비용을 줄일 수 있습니다.

  • 전체 테이블을 재클러스터링하는 경우에는 재클러스터링을 하기 전에 해당 테이블에 대한 SEARCH OPTIMIZATION 속성을 삭제 한 다음, 재클러스터링 후 SEARCH OPTIMIZATION 속성을 테이블에 다시 추가 해 보십시오.

특정 열 또는 전체 테이블에서 검색 최적화 제거하기

특정 열에 대한 검색 최적화 구성을 제거하거나 전체 테이블에서 SEARCH OPTIMIZATION 속성을 제거할 수 있습니다.

특정 열의 검색 최적화 삭제하기

특정 열에 대한 검색 최적화 구성을 삭제하려면 ON 절과 함께 ALTER TABLEDROP 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 68 로 지정된 구성을 삭제하려면 다음 문을 실행하십시오.

ALTER TABLE t1 DROP SEARCH OPTIMIZATION ON EQUALITY(c1), 6, 8;

구문에 대한 자세한 내용은 ALTER TABLE … DROP SEARCH OPTIMIZATION에 대한 섹션 을 참조하십시오.

테이블에서 검색 최적화 제거하기

테이블에서 SEARCH OPTIMIZATION 속성을 제거하는 방법:

  1. 테이블에서 검색 최적화를 제거할 수 있는 권한 이 있는 역할로 전환합니다.

  2. ON 절 없이 ALTER TABLEDROP 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;
맨 위로 이동