検索最適化サービスの使用¶

検索最適化サービスが機能する方法¶

ポイントルックアップのパフォーマンスを向上させるために、検索最適化サービスは、最適化された検索アクセスパスとして機能する永続的なデータ構造に依存しています。

バックグラウンドで実行されるメンテナンスサービスが、検索アクセスパスの作成と保守を担当します。

• テーブルに検索最適化を構成すると、メンテナンスサービスにより、検索を実行するために必要なデータが検索アクセスパスに作成され、入力されます。

  テーブルのサイズによっては、データの入力プロセスに時間がかかる場合があります。サービスはこれをバックグラウンドで実行し、テーブルにおけるいずれの同時操作も阻害しません。

• テーブル内のデータが更新されると（たとえば、新しいデータセットのロードや DML 操作によって）、メンテナンスサービスは自動的に検索アクセスパスを更新し、データへの変更を反映します。

  検索アクセスパスがまだ更新されていないときにクエリを実行すると、クエリの実行が遅くなる可能性がありますが、常に最新の結果が返されます。

この検索アクセスパスとメンテナンスサービスは、ユーザーに対して透過的です。検索アクセスパスを維持するサービスのウェアハウスを作成する必要はありません。

ただし、このサービスのストレージおよびコンピューティングリソースにはコストがかかることに注意してください。詳細については、 検索最適化サービスのコストの管理 （このトピック内）をご参照ください。

クエリのパフォーマンスを最適化するための他のソリューションの検討¶

検索最適化サービスは、クエリのパフォーマンスを最適化するさまざまな方法の1つです。関連するテクニックは次のとおりです。

• テーブルのクラスタリング。

• 1つ以上のマテリアライズドビュー（クラスター化または非クラスター化）を作成します。

次のテーブルに示すように、これらにはそれぞれ異なる利点があります。

次の表は、これらの3つの最適化のうちどれがストレージまたはコンピューティングコストを持つかを示しています。

1

再クラスタリングのプロセスでは、既存のパーティションが新しいパーティションに書き換えられるため、 Fail-safe ストレージのサイズが増加する可能性があります。（このプロセスでは、新しい行は導入されないことに注意してください。これは既存の行を再編成するだけです。）詳細については、 再クラスタリングのクレジットおよびストレージへの影響 をご参照ください。

検索最適化サービスに必要なアクセス制御権限¶

テーブルの検索最適化を追加、構成、または削除するには、次の権限が必要です。

• テーブルに対する OWNERSHIP 権限が必要。

• テーブルを含むスキーマに対する ADD SEARCH OPTIMIZATION 権限が必要。

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

  Copy

クエリに検索最適化サービスを使用するには、テーブルに対する SELECT 権限が必要。

その他の追加の権限は必要ありません。SEARCH OPTIMIZATION はテーブルプロパティであるため、テーブルのクエリ時に自動的に検出され、（適切な場合は）使用されます。

等価または IN 述語¶

検索最適化サービスにより、この型の結合のパフォーマンスを向上させることができます。

• 等価述語（たとえば、 <列名> = <定数>）。

• IN を使用する述語（ 例 を参照）。

部分文字列および正規表現¶

検索最適化サービスにより、部分文字列を検索する述語や正規表現を使用する述語を使用して、クエリのパフォーマンスを向上させることができます。これには、以下を使用する述部が含まれます。

• LIKE

• LIKE ANY

• LIKE ALL

• ILIKE

• ILIKE ANY

• CONTAINS

• ENDSWITH

• STARTSWITH

• SPLIT_PART （等価述語内）

• RLIKE

• REGEXP

• REGEXP_LIKE

ALTER TABLE mytable ADD SEARCH OPTIMIZATION ON SUBSTRING(mycol);

検索最適化サービスにより、5文字以上の長さの部分文字列を検索する際のパフォーマンスを向上させることができます。（部分文字列をより選択的にすると、パフォーマンスが向上する可能性があります。）

これに対し、検索最適化サービスは次の述語に対して検索アクセスパスを 使用しません。部分文字列が5文字より短いためです。

LIKE '%TEST%'

Copy

次の述語の場合、検索最適化サービスにより、検索アクセスパスを使用して SEARCH と OPTIMIZED の部分文字列を検索し、このクエリを最適化できます。ただし、部分文字列が5文字より短いため、 IS には検索アクセスパスは使用されません。

LIKE '%SEARCH%IS%OPTIMIZED%'

Copy

RLIKE、 REGEXP、および REGEXP_LIKE を使用するクエリの場合、

• subject 引数は、検索最適化が有効になっているテーブルの TEXT 列にする必要があります。

• pattern 引数は文字列定数にする必要があります。

正規表現の場合、検索最適化サービスは次のときに最適に機能します。

• パターンには、5文字以上の部分文字列リテラルが少なくとも1つ含まれている。

• パターンは、部分文字列が少なくとも1回出現する必要があることを指定する。

たとえば、次のパターンは、 string が件名に1回以上出現する必要があることを指定します。

RLIKE '(string)+'

Copy

検索最適化サービスにより、次のパターンを使用するクエリのパフォーマンスを向上させることができます。これは、各述語が、5文字以上の部分文字列が少なくとも1回出現する必要があることを指定しているためです。（最初の例では、バックスラッシュ文字のエスケープを避けるために、 ドル引用符の文字列定数 を使用していることに注意してください。）

RLIKE $$.*email=[\w\.]+@snowflake\.com.*$$

Copy

RLIKE '.*country=(Germany|France|Spain).*'

Copy

RLIKE '.*phone=[0-9]{3}-?[0-9]{3}-?[0-9]{4}.*'

Copy

対照的に、検索最適化サービスは、次のパターンのクエリに対して検索アクセスパスを使用しません。

• 部分文字列のないパターン:

  RLIKE '.*[0-9]{3}-?[0-9]{3}-?[0-9]{4}.*'
  

  Copy

• 5文字より短い部分文字列のみを含むパターン:

  RLIKE '.*tel=[0-9]{3}-?[0-9]{3}-?[0-9]{4}.*'
  

  Copy

• 1つのオプションが5文字より短い部分文字列である代替演算子を使用するパターン:

  RLIKE '.*(option1|option2|opt3).*'
  

  Copy

• 部分文字列がオプションであるパターン:

  RLIKE '.*[a-zA-z]+(string)?[0-9]+.*'
  

  Copy

部分文字列リテラルが5文字より短くても、正規表現を展開すると5文字以上の部分文字列リテラルが生成される場合には、検索最適化サービスによりクエリのパフォーマンスを向上させることができます。

たとえば、次のパターンを考慮します。

.*st=(CA|AZ|NV).*(-->){2,4}.*

Copy

この例では、

• 部分文字列リテラル（例: st=、 CA など）は5文字より短いものの、検索最適化サービスは、部分文字列 st=CA、 st=AZ、または st=NV （それぞれ5文字の長さ）がテキストに出現する必要があることを認識します。

• 同様に、部分文字列リテラル --> が5文字より短い場合でも、検索最適化サービスは、部分文字列 -->--> （5文字より長い）をテキストに出現する必要があると判断します。

検索最適化サービスは、検索アクセスパスを使用してこれらの部分文字列を照合できるため、クエリのパフォーマンスを向上させることができます。

VARIANT 列のフィールド¶

検索最適化サービスにより、Snowflakeテーブルの半構造化データ（VARIANT、 OBJECT、および ARRAY 列 のデータ）に対するポイントルックアップクエリのパフォーマンスを向上させることができます。

検索最適化サービスの VARIANT サポートがテーブル内の列に対して構成されている場合、検索最適化サービスは自動的に VARIANT、 OBJECT、および ARRAY 列を検索アクセスパスに含めます。これは、構造が深くネストされ、構造が頻繁に変更される列にも当てはまります。

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

次のセクションでは、このサポートについて詳しく説明します。

• VARIANT 型の述語の定数およびキャストでサポートされるデータ型

• VARIANT 値キャストを TEXT としてサポート

• 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 オブジェクトで地理空間関数を使用する述語を使用するクエリのパフォーマンスを向上させることができます。

ALTER TABLE mytable ADD SEARCH OPTIMIZATION ON GEO(mygeocol);

次のセクションで詳細を説明します。

• 地理空間関数でサポートされている述語

• その他のパフォーマンスの考慮事項

• 地理空間関数を使用する例

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)

...
  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）を使用するクエリでは、いずれかの述語が上記の条件に準拠している場合、検索最適化によってクエリのパフォーマンスが改善します。

たとえば、クエリに次のようなものがあるとします。

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;
  

  Copy

  次の述語は、テーブル列の値に対するキャストを使用するため、サポートされていません。

  -- Unsupported predicate
  -- (where values in a VARCHAR column are cast to DATE)
  WHERE to_date(varchar_column) = '2020-01-01';
  

  Copy

  検索最適化サービスは、キャスト後の値ではなく、元の列の値を考慮します。その結果、検索最適化サービスは、これらの述語を持つクエリには使用されません。

前述のように、このルールの例外は、テーブル列の NUMBER または INTEGER 値を VARCHAR 値にキャストする場合です。検索最適化サービスは、このタイプの述語をサポートします。

-- Supported predicate
-- (where values in a numeric column are cast to a string)
WHERE cast(numeric_column as varchar) = '2'

Copy

検索最適化はアクティブなデータに対してのみ機能するため、Time Travelを使用するクエリのパフォーマンスは、検索最適化によっては向上しません。

Query Acceleration Service は、検索最適化サービスが有効になっているテーブルのクエリは高速化しません。

特定の列に対する検索最適化の構成¶

特定の列の検索最適化を構成するには、 ALTER TABLE ... ADD SEARCH OPTIMIZATION コマンドを ON 句と合わせて使用します。

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

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 にある検索最適化のセクション をご参照ください。

このコマンドを実行すると、 列が検索最適化用に構成されていることを確認できます。

テーブルが検索最適化用に構成されていることの確認¶

テーブルとその列が検索最適化用に構成されていることを確認するには、

1. テーブルとその列の 検索最適化構成を表示 します。

2. SHOW TABLES コマンドを実行して、検索最適化が追加されていることを確認し、テーブルがどの程度最適化されているかを判断します。

   例:

   SHOW TABLES LIKE '%test_table%';
   

   Copy

   このコマンドの出力により、

   • SEARCH_OPTIMIZATION が ON であることを確認します。これは、検索最適化が追加されたことを示しています。

   • SEARCH_OPTIMIZATION_PROGRESS の値を確認します。これは、これまでに最適化されたテーブルの割合を指定します。

     検索最適化が最初にテーブルに追加されたとき、パフォーマンスの利点はすぐには現れません。検索最適化サービスは、バックグラウンドでデータの入力を開始します。メンテナンスがテーブルの現在の状態に追いつくにつれて、利点の増加が明らかになります。

     クエリを実行して検索最適化が機能していることを確認する前に、テーブルが完全に最適化されたことを示すまで待ちます。

3. クエリを実行して、検索最適化が機能していることを確認します。

   Snowflakeオプティマイザーは、特定のクエリに対して検索最適化サービスをいつ使用するかを自動的に選択することに注意してください。ユーザーは、どのクエリ検索最適化を使用するかについては制御できません。

   検索最適化サービスが最適化するように設計されているクエリを選択します。 検索最適化から恩恵を受けるテーブルおよび列の特定 をご参照ください。

4. ウェブ UI で、このクエリのクエリプランを表示し、クエリノード「検索最適化アクセス」がクエリプランの一部であることを確認します。

テーブルの変更¶

列のデフォルト値を変更すると、検索アクセスパスが無効になります。

検索アクセスパスが無効になった後に再度検索の最適化を使用するには、 SEARCH OPTIMIZATION プロパティをドロップ し、テーブルに SEARCH OPTIMIZATION プロパティを追加 しなおす必要があります。

列を追加、ドロップ、または名前変更した場合、検索アクセスパスは引き続き有効です。

• 特定の列を指定せずに、テーブル全体の検索最適化を有効にした場合、テーブルに列を追加すると、新しい列は検索アクセスパスに自動的に追加されます。ただし、列の検索最適化を有効にするときに ON 句を使用した場合、新しい列は自動的に追加されません。

• テーブルから列をドロップすると、ドロップされた列は検索アクセスパスから自動的に削除されます。

• 列の名前を変更する場合、検索アクセスパスを変更する必要はありません。

テーブルをドロップすると、 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時間ごとではなく1日ごと）。

  • INSERT、 UPDATE、および MERGE ：これらのタイプの DML ステートメントをテーブルでバッチ処理すると、検索最適化サービスにより、メンテナンスのコストを削減できます。

• テーブル全体を再クラスタリングする場合は、再クラスタリングの前にそのテーブルの SEARCH OPTIMIZATION プロパティをドロップ し、再クラスタリング後、テーブルに SEARCH OPTIMIZATION プロパティを追加 しなおすことを検討してください。

• 部分文字列検索（ON SUBSTRING(col)）または VARIANTs（ON EQUALITY(variant_col)）の検索最適化を有効にする前に、 SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS を呼び出してコストを見積もります。これらの検索方法の最初のビルドとメンテナンスは計算集約型になる可能性があるため、パフォーマンスとコストの間のトレードオフを評価する必要があります。

特定の列に対する検索最適化のドロップ¶

特定の列の検索最適化構成をドロップするには、 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 の等価性に対する検索最適化をドロップし、式 IDs 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;
   

   Copy

   例:

   alter table test_table drop search optimization;
   

   Copy

   詳細については、 ALTER TABLE ... DROP SEARCH OPTIMIZATION のセクション をご参照ください。