検索最適化のメリットがあるクエリの特定¶
検索最適化により、多くのクエリのパフォーマンスを向上させることができます。このトピックでは、検索最適化の恩恵を最も受けるクエリの種類と、逆に 恩恵を受けない クエリの種類の特徴について説明します。
一般的なクエリの特徴¶
検索最適化は、次の特性を持つクエリのパフォーマンスを向上させるのに最適です。
クエリには、主クラスターキー以外の列が含まれます。
通常、数秒以上実行されるクエリ (検索最適化の適用前)。ほとんどの場合、検索最適化によって、実行時間が1秒未満のクエリのパフォーマンスが大幅に向上することはありません。
クエリフィルター操作によってアクセスされる列の少なくとも1つは、100,000個以上の異なる値を持ちます。
個別の値の数を決定するには、次のいずれかを使用できます。
APPROX_COUNT_DISTINCT
を使用して、個別の値の概算数を取得します。SELECT APPROX_COUNT_DISTINCT(column1) FROM table1;
COUNT(DISTINCT <列名>)
を使用して、個別の値における実際の数を取得します。SELECT COUNT(DISTINCT c1), COUNT(DISTINCT c2) FROM test_table;
個別の値の概算数のみが必要なため、
COUNT(DISTINCT <列名>)
より高速で安価なAPPROX_COUNT_DISTINCT
の使用を検討してください。
サポートされているデータ型¶
検索最適化サービスは現在、次のデータ型をサポートしています。
固定小数点数のデータ型 (例えば、 INTEGER や NUMERIC)
文字列およびバイナリデータ型 (例えば、 VARCHAR や BINARY)
日付と時刻のデータ型 (例えば、 DATE、 TIME、 TIMESTAMP)。
半構造化データ型 (例えば、 VARIANT、 OBJECT、 ARRAY)。
他のデータタイプの値(例えば、 FLOAT や GEOMETRY)を含むクエリは、恩恵を受けません。
サポートされる述語タイプ¶
検索最適化は、この種の述語を使ったクエリのパフォーマンスを向上させることができます。
等号と IN を使用したポイントルックアップクエリ。
SEARCH および SEARCH_IP 関数 を使った文字データ(テキスト)クエリ。
照合のサポート¶
検索最適化により、 COLLATE 句 で定義された列に対するクエリのパフォーマンスを、検索方法に応じて向上させることができます。
EQUALITY
検索メソッドを使用して列で検索最適化が 有効になっている 場合、どの照合順序指定もサポートされます。FULL_TEXT
またはSUBSTRING
検索メソッドを使用して列の検索最適化が有効になっている場合、'utf8'
または'bin'
照合順序指定がサポートされます。
検索方法の詳細については、 ALTER TABLE ... ADD SEARCH OPTIMIZATION をご参照ください。
検索最適化は、 COLLATE 関数を使用して列の照合順序指定を変更する述語をサポートしていません。
例えば、照合順序を指定した列を持つテーブルを作成し、行を挿入します。
CREATE OR REPLACE TABLE search_optimization_collation_demo (
en_ci_col VARCHAR COLLATE 'en-ci',
utf_8_col VARCHAR COLLATE 'utf8');
INSERT INTO search_optimization_collation_demo VALUES (
'test_collation_1',
'test_collation_2');
テーブルの両列に対する等式述語の検索最適化を有効にします。
ALTER TABLE search_optimization_collation_demo
ADD SEARCH OPTIMIZATION ON EQUALITY(en_ci_col, utf_8_col);
以下のクエリは検索最適化のメリットがあります:
SELECT *
FROM search_optimization_collation_demo
WHERE utf_8_col = 'test_collation_2';
以下のクエリは、 COLLATE 関数を使用して、 utf_8_col
列の照合順序指定を変更しているため、検索最適化の恩恵を受けることができません:
SELECT *
FROM search_optimization_collation_demo
WHERE utf_8_col COLLATE 'de-ci' = 'test_collation_2';
次のクエリも検索最適化の恩恵を受けることはできません。 優先の照合順序ルール に基づいて、クエリは COLLATE 関数を使用して utf_8_col
列に 'de-ci'
照合順序指定を適用します。
SELECT *
FROM search_optimization_collation_demo
WHERE utf_8_col = 'test_collation_2' COLLATE 'de-ci';
Apache Iceberg™ テーブルのサポート¶
検索最適化により、 Apache Iceberg™ テーブルに対するクエリのパフォーマンスを向上させることができます。Iceberg テーブルの検索最適化の構成情報については、 ALTER ICEBERG TABLE をご参照ください。
Iceberg テーブルの検索最適化サポートには、次の制限が適用されます。
Icebergテーブルがサポートしていないデータタイプ(半構造化、 地理空間 データタイプなど)を持つ列には検索最適化を追加できません。詳細については、 Apache Iceberg™ テーブルのデータ型 をご参照ください。
検索最適化サービスは、 構造化データタイプ を持つ列をサポートしていません。
Apache Parquet™のファイルが大容量(例えば、数百メガバイトの圧縮)である場合、シナリオによってはクエリが検索最適化サービスの恩恵を十分に受けられないことがあります。
Snowflakeテーブルの検索最適化に適用されるその他の制限は、Icebergテーブルにも適用されます。詳細については、 検索最適化のメリットがないクエリ をご参照ください。
ビューの改善の可能性¶
検索最適化サービスにより、ビュー(セキュアビューを含む)のパフォーマンスを間接的に改善できます。ビューのベーステーブルで検索最適化が有効になっていて、クエリがそのテーブルに選択的述語を使用している場合、検索最適化サービスは、行をフィルタリングするときのパフォーマンスを改善できます。 サポートされる述語タイプ をご参照ください。
ビュー内のすべてのテーブルで検索最適化を有効にする必要はありません。検索の最適化は、各テーブルで個別に実行されます。
検索最適化のメリットがないクエリ¶
現在、検索最適化サービスは、浮動小数点データ型、 GEOMETRY 、またはまだ説明されていないその他のデータ型をサポートしていません。Snowflakeには、将来さらに多くのデータ型のサポートが追加される可能性があります。
また、検索最適化サービスでは、次をサポートしていません。
外部テーブル。
マテリアライズドビュー。
列の連結。
分析表現。
テーブル列にキャストします(文字列にキャストされる固定小数点数を除く)。
検索最適化は、定数値に対する暗黙的および明示的キャストを使用した述部をサポートしていますが、実際のテーブル列に値をキャストする述部はサポートしていません(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 を使用するクエリのパフォーマンスは、検索最適化によっては向上しません。