ハイブリッドテーブルのベストプラクティス¶

このトピックでは、ハイブリッド・テーブルを使用する際のベスト・プラクティスと重要な考慮事項について説明します。ハイブリッド・テーブルで最適なパフォーマンスを実現するには、以下のベスト・プラクティスに従って導入してください。このガイドでは、本番ワークロードのパフォーマンスを最大化するための具体的な構成、設計、および演算子について概説します。

一般的なベストプラクティス：
パフォーマンスを最適化するためのベストプラクティス：
ハイブリッドテーブルの運用と監視のベストプラクティス：

Snowsightのクエリパフォーマンスとドライバーベースのアクセスの比較¶

注意

Snowsight で報告されるパフォーマンス統計は、ドライバーベースのワークロードのクエリパフォーマンスを示すものではありません。

Snowsight は、クエリプラン、データ統計、クエリ履歴、その他の詳細情報への豊富なアクセスを提供し、インタラクティブなクエリプロトタイピング、デバッグ、調査、モニタリングなどのアクティビティに役立ちます。リッチなインタラクティブエクスペリエンスを提供することは、Snowflakeクエリエンジンにオーバーヘッドを追加します。そのため、 Snowsight を介して実行される短時間のクエリの待機時間は、プログラムドライバーで達成できるパフォーマンスを示すものではありません。コードベースまたはドライバーベースのソリューションで実行されるクエリは、 Snowsight を介して実行されるクエリよりも低待機時間と変数で実行されます。

注釈

簡単なパフォーマンステストを実行し、シナリオのパフォーマンスを検証します。

ハイブリッドテーブル用のクライアントドライバー¶

ハイブリッドテーブルにアクセスするには、次のいずれかのドライバーバージョンを使用する必要があります。

ドライバー

最小バージョン

Go

1.6.25

JDBC

3.13.31

.Net

2.1.2

Node.js

1.9.0

ODBC

3.0.2

PHP

2.0.0

Pythonコネクタ

3.1.0

Snowflake CLI

3.10.0

SnowSQL

1.2.28

注釈

以前のドライバーバージョンを使用すると、ハイブリッド・テーブルにアクセスできない場合があります。

ドライバー	最小バージョン
Go	1.6.25
JDBC	3.13.31
.Net	2.1.2
Node.js	1.9.0
ODBC	3.0.2
PHP	2.0.0
Pythonコネクタ	3.1.0
Snowflake CLI	3.10.0
SnowSQL	1.2.28

ハイブリッドテーブルで最適なパフォーマンスを得るためには、選択したドライバーの最新バージョンを必ず使用してください。

Snowflake SQL API を使用してハイブリッドテーブルにアクセスすることもできます。しかし、この API は最適な待機時間を必要とするユースケースにはお勧めできません。

クライアントの構成とアクセス方法¶

接続管理はパフォーマンスとスケーラビリティに直接影響します。ハイブリッド・テーブルを含むデータベースに接続する場合、良好なパフォーマンスを実現するために以下のベスト・プラクティスを考慮してください。

新しい接続を繰り返し確立するオーバーヘッドをなくすために、寿命の長い接続で接続プーリングを使用します。Snowflakeに接続するほとんどのクライアントフレームワークは、アクセスを効率的に管理するために接続プーリングメカニズムを提供します。
ネットワークの近接性はエンドツーエンドの待機時間に大きく影響するため、クライアントソフトウェアはSnowflakeアカウントと同じクラウドリージョンに配置してください。
クエリプランナーが以前に作成したクエリ計画を再利用できるように、パラメーターを束ねたステートメントを使用してください。
最適な待機時間ーを実現するには、 Snowsight ではなく、サポートされているプログラマティック・クライアント・ドライバーを使用してください。ハイブリッドテーブル用のクライアントドライバーをご参照ください。

インデックスの設計と使用¶

インデックスの作成と使用は、ハイブリッドテーブルの最適パフォーマンスを実現するためのキーコンポーネントです。以下の推奨事項をご検討ください：

頻繁に使用される述語のためにセカンダリインデックスを作成します。
完全なクエリパターンにマッチする複合インデックスを設計します。
同じ序列の列で複数のインデックスを使用することは避けてください。
インデックスを作成する前に、データのカーディナリティを理解してください。単一の、低いカーディナリティの列で構築されたインデックスの利点は限られています。異なる値の数の推定をご参照ください。
インデックスは、書き込みのオーバーヘッドとストレージの要件を追加します。低待機時間の書き込み操作を必要とするアプリケーションでは、読み取りパフォーマンスと書き込みパフォーマンスのバランスに注意してください。

適切に設計されたインデックスは、効率的なデータアクセスパスをプロバイダーとして提供することで、クエリのパフォーマンスを大幅に向上させます。可能であれば、複雑さを最小限に抑えつつ、最適な選択性を持つプライマリキーを選択します。場合によっては、複雑な複合インデックスよりも、計算キーや代理キーの値を持つ列を追加した方がパフォーマンスが向上することもあります。セカンダリインデックスは、頻繁にアクセスされる列のパフォーマンスを劇的に向上させます。

明確に定義されたクエリの場合、テーブルの作成時に INCLUDE キーワードを使用してインデックスに列を追加すると、レイテンシがさらに短縮される可能性があります。INCLUDE列をご参照ください。

注意

ハイブリッドテーブルに作成するインデックスに注意してください。非選択的なインデックス・スキャンは、最適なパフォーマンス、スロットリング、およびコスト増につながります。

インデックス使用の対象となるクエリ¶

ハイブリッドテーブル・インデックスは、クエリが以下の条件のいずれかを使用する場合にアクセスされる可能性があります：

<column_reference> {=, >, >=, <, <=}<constant_value>
<column_reference> IN <constant_in_list>
<column_reference> BETWEEN <constant_value> AND <constant_value>

式は論理演算子を使って連結することができます。

例:

CREATE OR REPLACE HYBRID TABLE icecream_orders (
  id NUMBER PRIMARY KEY AUTOINCREMENT START 1 INCREMENT 1 ORDER,
  store_id NUMBER NOT NULL,
  flavor VARCHAR(20) NOT NULL,
  order_ts TIMESTAMP_NTZ,
  num_scoops NUMERIC,
  INDEX idx_icecream_order_store (store_id, order_ts),
  INDEX idx_icecream_timestamp (order_ts)
  );

-- Generate sample data for testing

INSERT INTO icecream_orders (store_id, flavor, order_ts, num_scoops)
  SELECT
    UNIFORM(1, 10, RANDOM()),
    ARRAY_CONSTRUCT('CHOCOLATE', 'VANILLA', 'STRAWBERRY', 'LEMON')[UNIFORM(0, 3, RANDOM())],
    DATEADD(SECOND, UNIFORM(0, 86400, RANDOM()), DATEADD(DAY, UNIFORM(-90, 0, RANDOM()), CURRENT_DATE())),
    UNIFORM(1, 3, RANDOM())
  FROM TABLE(GENERATOR(ROWCOUNT => 10000))
  ;

-- Use idx_icecream_order_store (first column)

  SELECT *
    FROM icecream_orders
    WHERE store_id = 5;

-- Use idx_icecream_order_store (both columns)

  SELECT *
    FROM icecream_orders
    WHERE store_id IN (1,2,3) AND order_ts > DATEADD(DAY, -7, CURRENT_DATE());

-- Use idx_icecream_timestamp

  SELECT *
    FROM icecream_orders
    WHERE order_ts BETWEEN DATEADD(DAY, -2, CURRENT_DATE()) AND DATEADD(DAY, -2, CURRENT_DATE());

Copy

データの一括ロード¶

ハイブリッドテーブルにデータをロード中、いくつかの最適化とベストプラクティスを使用できます。

空のテーブルを作成してすぐにロードするには、 CREATE TABLE ... AS SELECT （CTAS とも呼ばれる）を使用します。
クエリ・プロファイルで最適化されたバルクロードの使用を確認してください。
初期データのロード中は、単一のバルクトランザクションを優先します。

ハイブリッドテーブルは、最適化されたバルク・ロード・パスを提供し、標準的なロード方法よりも最大10倍速いロード・パフォーマンスを実現します。この最適化された一括ロードパスは、 CTAS (CREATE TABLE AS SELECT)、 COPY INTO、 INSERT INTO SELECT コマンドを使用して空のテーブルにデータをロードする際に自動的に適用されます。(空のテーブルとは、一度もデータを含んだことのないテーブルのことです)。

Number of rows inserted ではなく Number of rows bulk loaded として行が報告されるクエリプロファイルの統計セクションを確認することで、最適化が使用されていることを確認することができます。

注釈

CTAS 操作は FOREIGN KEY 制約をサポートしていません。外部キーが必要なテーブルの場合は、代わりに COPY または INSERT INTO SELECT を使用する必要があります。

すでにデータのあるテーブルでは、最適化されたバルク・ロード・パスは現在使用できません。このような場合、演算子は1分間に約100万の記録を処理できますが、これは記録サイズ、テーブル構造、インデックスの数によって異なります。

ウェアハウスの最適化¶

X-Smallサイズのウェアハウスは、多くの運用ワークロードには十分です。短期間で実行される運用クエリで高い同時実行性とスループットを達成するには、ウェアハウスの規模を大きくしてコンピュートリソースを増やすのではなく、マルチクラスターウェアハウスを使用してコンピュートノード数を増やします。

ワークロードのスループットパターンが変動する場合は、自動スケーリングを有効にして、需要が低いときに消費量を抑えることができます。高スループットまたは低待機時間ーを必要とするワークロードで最高のパフォーマンスと効率を得るには、スケーリングポリシーを Economy ではなく Standard にセットします。詳細については、マルチクラスターウェアハウスのスケーリングポリシーの設定をご参照ください。

場合によっては、独立したスケーリングを可能にするために、ワークロードを別々のウェアハウスに分離することが有益な場合もあります。演算子と分析コンポーネントが混在するハイブリッドワークロードの場合、演算子と分析コンポーネントを別のウェアハウスに分離することが有益です。これらを分離できず、同じウェアハウス上で一緒に実行する必要がある場合は、分析クエリの待機時間要件に基づいてウェアハウスのサイズを選択し、ワークロードのスループットをサポートするために必要なノード数に基づいてマルチクラスターノード数を選択します。

キャッシュとウォームアップ¶

新しく開始されたウェアハウスに最初に発行されたハイブリッドテーブルクエリは、クエリ計画、インデックス選択、データの読み込み中I/O、キャッシュ決定、そしてもちろんクエリ実行などのアクティビティをトリガーします。クエリエンジンはクエリのメモリとストレージの最適化を続けます。この期間を「ウォームアップ」期間と呼びます。クエリの待機時間は、エンジンが定常状態の待機時間に収束するまで低下します。

キャッシュの干渉を避けるため、ハイブリッド・テーブル・ワークロードには専用のウェアハウスを使用します。
定常状態の待機時間に達するには、キャッシュがウォームアップするにつれて、数秒から2-3分かかることを理解してください。
自動一時停止と自動スケーリングを構成して、効率とキャッシュウォームネスのバランスをとります。

ハイブリッド・テーブルは、パフォーマンスを最適化するために複数のキャッシュ・アプローチを利用します。プランキャッシュは、頻繁に使用されるクエリプランを格納することで、コンパイルのオーバーヘッドを削減します。列ストアデータキャッシュは頻繁にアクセスされるデータをメモリに保持し、メタデータキャッシュはテーブルとインデックス情報への迅速なアクセスを提供します。ハイブリッドテーブルは結果キャッシュを使用しません。

これらのキャッシュは、ワークロードパターンに合わせて最適化するのに時間がかかります。ハイブリッドテーブルのワークロードに専用のウェアハウスを使用することで、他のワークロードからのキャッシュ干渉を防ぐことができます。コールドスタート後の最初のクエリは、キャッシュにデータが入るまで待機時間が長くなります。ワークロードのスループットパターンが変数である場合、自動スケーリングと自動サスペンドを有効にして消費量を削減したり、需要が低いときにウェアハウスを一時停止したりできます。ウェアハウスが再起動したり、新しいクラスターを追加するために自動スケールしたりすると、キャッシュのリハイドレートが必要になります。最高のパフォーマンスを得るためには、スケーリングポリシーを Economy ではなく Standard にセットしてください。マルチクラスターウェアハウスをご参照ください。

ストアドプロシージャとハイブリッドテーブル¶

ストアドプロシージャはハイブリッドテーブルでもサポートされていますが、 AUTOCOMMIT を有効にしてトランザクションを実行するか、マルチステートメントトランザクションを実行すると、ストアドプロシージャを呼び出すよりもパフォーマンスと効率が良くなります。

サーバーレスタスクとハイブリッドテーブル¶

サーバーレスタスクはサポートされていますが、ハイブリッドテーブルを使用するワークロードでは最適なパフォーマンスや効率が得られない可能性があることに注意してください。

パフォーマンス・モニタリング¶

ハイブリッド・テーブルのパフォーマンス監視に使用する推奨のビューは、 AGGREGATE_QUERY_HISTORY ビューです。この表示には、短期間に集約されたクエリ実行の詳細が含まれます。

たとえば、ハイブリッドテーブル・リクエストに対応するウェアハウスの過去24時間の平均デフォルト・インターバル・パフォーマンスを取得するには、次のようにします。

SELECT *
  FROM SNOWFLAKE.ACCOUNT_USAGE.AGGREGATE_QUERY_HISTORY
  WHERE warehouse_name = 'HYBRID_TABLES_WAREHOUSE'
  AND query_type = 'SELECT'
  AND interval_start_time >= DATEADD(hour, -24, CURRENT_TIMESTAMP());

Copy

その他の例については、 AGGREGATE_QUERY_HISTORY ビューをご参照ください。

クォータとスロットルの監視¶

ハイブリッドテーブルでは、ハイブリッドストレージとハイブリッドテーブルのリクエストスループットの両方に対して、データベースレベルでクォータ制御が実装されています。これらのクォータは、すべてのユーザーに対して一貫したパフォーマンスを確保します。ほとんどの初期導入においてはデフォルトのクォータで十分ですが、ワークロードの増加に応じて調整が必要になる場合があります。

AGGREGATE_QUERY_HISTORY ビューを使用して、ハイブリッドテーブルのリクエストクォータをモニターします。
STORAGE_USAGE ビューを使用してハイブリッドストレージのクォータをモニターします。
クエリプロファイルでスロットリングのパーセンテージが高い場合は、スループットの限界に近づいていることを示しています。どちらかのクォータの70％以上を常に使用している場合は、Snowflakeサポートを通じて積極的に増額リクエストを行ってください。

ハイブリッドテーブルのパフォーマンスは、仮想ウェアハウスのコンピュート使用率が高くない場合でも、スロットリングの対象となります。使用状況を監視し、ハイブリッドテーブルがスロットルされているかどうかを判断するには、 AGGREGATE_QUERY_HISTORY ビューの例を参照してください。HYBRID_TABLE_REQUESTS_THROTTLED_COUNT 列から、スロットルされたハイブリッドテーブルリクエスト数を取得することもできます。

詳細については、クォータとスロットリングをご参照ください。

パフォーマンス問題のトラブルシューティング¶

これらのベストプラクティスを実施しても期待したパフォーマンスが得られない場合、Snowflakeサポートが分析し、実装を最適化するお手伝いをいたします。サポートケースを作成する際には、迅速な解決を可能にするため、以下の情報を含めてください。

クエリ IDs (UUIDs): パフォーマンスが最適でない代表的なクエリ。
仕事量の特徴：
- 典型的なクエリパターン
- 予想される待機時間と実際の待機時間
- 同時実行要件
- データストレージ容量
- クエリ・レスポンスの行サイズ
- 列カーディナリティの推定値
テーブルスキーマ、インデックス、作業負荷パターンに最近変更があった場合
クエリ・プロファイルからのスロットリング指標
コールドウェアハウスとウォームウェアハウスのパフォーマンスの違い

可能であれば、類似クエリの速い例と遅い例の両方を含めると、最適化の機会を特定しやすくなります。この比較は、サポートチームが構成や設計の改善の可能性を迅速に特定するのに役立ちます。