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

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

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

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

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

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

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

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

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

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

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

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

• 테이블 클러스터링.

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

다음 표에서 보듯이, 이들은 각각 서로 다른 장점이 있습니다.

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

1

재클러스터링 프로세스에서는 기존 파티션을 새 파티션으로 다시 쓰므로 Fail-safe 저장소의 크기가 증가할 수 있습니다. (이 프로세스에서는 새 행을 도입하지 않습니다. 기존 행을 다시 구성할 뿐입니다.) 자세한 내용은 재클러스터링의 크레딧 및 저장소 영향 섹션을 참조하십시오.

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

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

• 테이블에 대한 OWNERSHIP 권한이 있어야 합니다.

• 테이블이 포함된 스키마에 대한 ADD SEARCH OPTIMIZATION 권한이 있어야 합니다.

  GRANT ADD SEARCH OPTIMIZATION ON SCHEMA <schema_name> TO ROLE <role>
  

쿼리에서 검색 최적화 서비스를 사용하려면 테이블에 대한 SELECT 권한만 있으면 됩니다.

추가 권한은 필요하지 않습니다. SEARCH OPTIMIZATION은 테이블 속성이므로, 테이블을 쿼리할 때 자동으로 감지되어 사용(해당되는 경우)됩니다.

같음 또는 IN 조건자¶

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

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

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

하위 문자열 및 정규식¶

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

• LIKE

• LIKE ANY

• LIKE ALL

• ILIKE

• ILIKE ANY

• CONTAINS

• ENDSWITH

• STARTSWITH

• SPLIT_PART (같음 조건자에서)

• RLIKE

• REGEXP

• REGEXP_LIKE

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

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

• VARIANT 타입에 대한 조건자의 상수와 캐스트를 위해 지원되는 데이터 타입

• TEXT로 캐스팅된 VARIANT 값 지원

• 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

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';

지리 공간 함수¶

검색 최적화 서비스는 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;

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)

...
  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 는 검색 최적화 서비스가 활성화된 테이블에 대한 쿼리를 가속하지 않습니다.

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

특정 열에 대한 검색 최적화를 구성하려면 ON 절과 함께 ALTER TABLE … ADD SEARCH OPTIMIZATION 명령을 사용하십시오.

ON 절은 특정 열에 대한 검색 최적화를 구성하도록 지정합니다. 구문에 대한 자세한 내용은 ALTER TABLE … ADD SEARCH OPTIMIZATION에 관한 섹션 을 참조하십시오.

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

다음 섹션에는 검색 최적화를 위한 구성을 지정하는 방법을 보여주는 예가 포함됩니다.

• 예: 특정 열에 대해 같음 조건자와 IN 조건자 지원

• 예: 적용 가능한 모든 열에 대해 같음 조건자와 IN 조건자 지원

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

• 예: VARIANT의 필드에 대해 같음 조건자와 IN 조건자 지원

ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2, c3);

-- This statement is equivalent to the previous statement.
ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1), EQUALITY(c2, c3);

ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(*);

ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c1, c2), SUBSTRING(c3);

ALTER TABLE t1 ADD SEARCH OPTIMIZATION ON EQUALITY(c4:user:uuid);

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

지원되는 데이터 타입(VARIANT 제외)의 모든 열에 대해 EQUALITY만 지정하려는 경우 ON 절 없이 ALTER TABLE … ADD 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에서 이 쿼리에 대한 쿼리 계획을 확인하고 쿼리 노드 《검색 최적화 액세스》가 쿼리 계획의 일부에 해당하는지 확인합니다.

테이블 수정하기¶

열의 기본값이 변경되면 검색 액세스 경로가 무효화됩니다.

검색 액세스 경로가 무효화된 후 검색 최적화를 다시 사용하려면 SEARCH OPTIMIZATION 속성을 삭제 하고 SEARCH OPTIMIZATION 속성을 테이블에 다시 추가 해야 합니다.

열을 추가 또는 삭제하거나 이름을 변경하면 검색 액세스 경로가 계속 유효합니다.

• 테이블에 열을 추가하면 자동으로 검색 액세스 경로에 새로운 열이 추가됩니다.

• 테이블에서 열을 삭제하면 삭제된 열이 검색 액세스 경로에서 자동으로 제거됩니다.

• 열 이름을 변경하는 경우에는 검색 액세스 경로를 변경할 필요가 없습니다.

테이블을 삭제하면 SEARCH OPTIMIZATION 속성 및 검색 액세스 경로도 함께 삭제됩니다. 참고:

• 테이블 삭제를 즉시 취소하면 검색 최적화가 테이블의 속성으로 다시 설정됩니다.

• 테이블을 삭제할 때 검색 액세스 경로의 데이터 보존 기간은 테이블과 동일합니다.

테이블에서 SEARCH OPTIMIZATION 속성을 삭제 하면 검색 액세스 경로가 제거됩니다. SEARCH OPTIMIZATION 속성을 테이블에 다시 추가 할 때 유지관리 서비스는 검색 액세스 경로를 다시 생성해야 합니다. (속성을 삭제할 수 있는 방법 없음)

테이블, 스키마 또는 데이터베이스 복제하기¶

테이블, 스키마 또는 데이터베이스를 복제하면 각 테이블의 SEARCH OPTIMIZATION 속성과 검색 액세스 경로도 함께 복제됩니다. (테이블, 스키마 또는 데이터베이스를 복제하면 각 테이블과 해당 검색 액세스 경로의 복사를 수행하지 않는 복제 가 생성됩니다.)

CREATE TABLE … LIKE를 사용하여 원래 테이블과 열이 동일한 비어 있는 새 테이블을 생성하면 SEARCH OPTIMIZATION 속성이 새 테이블에 복사되지 않습니다.

보조 데이터베이스(데이터베이스 복제 지원)에서 테이블 관련 작업하기¶

기본 데이터베이스의 테이블에 SEARCH OPTIMIZATION 속성이 활성화되어 있으면 해당 속성은 보조 데이터베이스의 해당 테이블에 복제됩니다.

보조 데이터베이스의 검색 액세스 경로는 복제되지 않으며 자동으로 다시 작성됩니다. 이 프로세스에서는 검색 최적화 서비스의 비용 관리하기 의 설명과 같은 종류의 비용이 발생한다는 점에 유의하십시오.

테이블 공유하기¶

데이터 공급자는 Secure Data Sharing 를 사용하여 검색 최적화가 활성화된 테이블을 공유할 수 있습니다.

공유 테이블을 쿼리할 때 데이터 컨슈머는 검색 최적화 서비스의 성능 향상을 통해 이점을 활용할 수 있습니다.

비용 예상하기¶

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

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

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

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

비용 보기¶

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

비용 줄이기¶

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

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

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

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

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

• 전체 테이블을 재클러스터링하는 경우에는 재클러스터링을 하기 전에 해당 테이블에 대한 SEARCH OPTIMIZATION 속성을 삭제 한 다음, 재클러스터링 후 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 속성을 제거하는 방법:

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

2. 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에 대한 섹션 을 참조하십시오.