データベースの複製の考慮事項

このトピックでは、セカンダリデータベース内における特定のSnowflake機能の動作について説明し、複製されたオブジェクトとデータを操作するための一般的なガイダンスを提供します。

このトピックの内容:

このセクションでは、セカンダリデータベースの特定のSnowflake機能の動作について説明し、複製されたオブジェクトとデータを操作するための一般的なガイダンスを提供します。

複製と自動クラスタリング

プライマリデータベースでは、Snowflakeは 自動クラスタリング を使用してクラスター化されたテーブルを監視し、必要に応じてそれらを再クラスター化します。更新操作の一部として、クラスター化されたテーブルは、テーブルのマイクロパーティションの現在の並べ替えを使用してセカンダリデータベースに複製されます。そのため、セカンダリデータベース内のクラスター化されたテーブルで再クラスタリングが再度実行されることは ありません 。これは冗長です。

セカンダリデータベースにクラスター化されたテーブルが含まれており、データベースがプライマリデータベースになると、Snowflakeはこのデータベースのテーブルの自動クラスタリングを開始すると同時に、以前のプライマリデータベースのクラスター化テーブルの監視を一時停止します。

マテリアライズドビューの自動クラスタリングの詳細については、このトピックの 複製とマテリアライズドビュー をご参照ください。

複製とマテリアライズドビュー

プライマリデータベースでは、Snowflakeはマテリアライズドビューの自動バックグラウンドメンテナンスを実行します。ベーステーブルが変更されると、テーブルで定義されているすべてのマテリアライズドビューは、Snowflakeが提供する計算リソースを使用するバックグラウンドサービスによって更新されます。さらに、マテリアライズドビューに対して自動クラスタリングが有効になっている場合、ビューはプライマリデータベースで必要に応じて監視および再クラスター化されます。

更新操作は、マテリアライズドビュー 定義 をセカンダリデータベースに複製します。ただし、マテリアライズドビュー データ は複製されないため、マテリアライズドビューのデータの一部またはすべてが古くなる可能性があります。

セカンダリデータベースのマテリアライズドビューの自動バックグラウンドメンテナンスを実行するには、セカンダリデータベースを作成する( CREATE DATABASE ... AS REPLICA OF を使用)とき、またはその後( ALTER DATABASE を使用)、セカンダリデータベースに明示的に AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE を設定します。プライマリデータベースのマテリアライズドビューに対して自動クラスタリングが有効になっている場合、セカンダリデータベースで AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = TRUE を設定すると、セカンダリデータベースのマテリアライズドビューの自動モニターと再クラスタリングも有効になります。

別のデータベース内のオブジェクトへの参照 もご参照ください(このトピック内)。

注釈

マテリアライズドビューのメンテナンス料金は、セカンダリデータベースに対して AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY パラメーターが有効になっているアカウントに請求されます。

複製およびマスキングポリシー

次のいずれかの条件に該当する場合は、最初の複製操作または後続の更新操作に失敗します。

  • プライマリデータベースは、Enterprise(またはそれ以上)のアカウントにあり、マスキングポリシーを含んでいますが、下位エディションには、複製が承認された1つ以上のアカウントがあります。

  • プライマリデータベースに含まれるマスキングポリシーは、別のデータベースのテーブルまたはビューの列に適用されるか、その逆です。

Time Travel

Time Travel を使用してセカンダリデータベースのテーブルとビューをクエリすると、プライマリデータベースで同じクエリを実行した場合とは異なる結果が生成される可能性があります。

履歴データ

Time Travelを使用してプライマリデータベースでクエリできる履歴データは、セカンダリデータベースに複製されません。

例えば、Snowpipeを使用してデータが10分ごとにテーブルに継続的にロードされ、セカンダリデータベースが1時間ごとに更新されるとします。更新操作では、テーブルの最新バージョンのみが複製されます。保持期間内のテーブルの1時間ごとのバージョンは、Time Travelを使用したクエリで使用できますが、1時間以内の反復バージョン(個々のSnowpipeロード)は使用できません。

データ保持期間

セカンダリデータベース内のテーブルのデータ保持期間は、プライマリデータベース内のテーブルに書き込まれた DML 操作(つまり、データの変更または削除)でセカンダリデータベースが更新されると始まります。

複製と大規模でチャーン率の高いテーブル

テーブルの1つ以上の行が更新または削除されると、このデータをプライマリデータベースに保存する、影響を受けるすべてのマイクロパーティションが再作成され、セカンダリデータベースと同期する必要があります。大規模でチャーン率の高いディメンションテーブルの場合、複製コストがかなり高くなる可能性があります。

大幅な複製コストが発生する大規模でチャーン率の高いディメンションテーブルの場合、次の軽減策を利用できます。

  • このようなテーブルを保存するプライマリデータベースをより低い頻度で複製します。

  • データモデルを変更して、チャーン率を減らします。

詳細については、 大規模でチャーンの大きいテーブルのコスト管理 をご参照ください。

複製とクローニング

クローンオブジェクトは、論理的にセカンダリデータベースに複製されるのではなく、物理的に複製されます。つまり、クローンに対する DML 操作が既存のデータに追加または変更しない限り、標準データベース内のクローンテーブルは全体的なデータストレージに寄与しません。ただし、クローンテーブルをセカンダリデータベースに複製すると、物理データも複製されるため、アカウントのデータストレージの使用量が増加します。

別のデータベース内のオブジェクトへの参照

プライマリデータベースのビューまたはテーブル制約が別のデータベースを参照しているかどうかを慎重に分析します。

ビュー
  • このタイプの参照は名前ベースであるため、別のデータベース内のオブジェクトを参照する非マテリアライズドビュー(例:テーブル列、他のビュー、 UDFs、またはステージ)を複製できます。名前ベースの参照によって複製が失敗することはありません。ただし、他のデータベースが同じ地域に複製されていない場合、セカンダリデータベースのビューに対するクエリは失敗します。

    たとえば、データベース d1 のビュー v1 が、データベース d1d2 のテーブル t1t2 をそれぞれ参照するとします。セカンダリデータベース d1 のビューV1を正常にクエリするには、セカンダリデータベース d2 もアカウントに存在する必要があります(例:別のセカンダリデータベースとして)。さらに、プライマリデータベースとの一貫したクエリ結果を得るには、セカンダリデータベース d1d2 を同時に更新する必要があります。

  • 現在、別のデータベース内のオブジェクトを参照するマテリアライズドビューは、複製または更新操作の失敗を引き起こします。これは、マテリアライズドビューがオブジェクトを名前ではなく ID で参照するためです。データベーススナップショットは、データベース外部のオブジェクトへの ID ベースの参照を解決できません。

制約

現在、外部キーをダングリングすると、複製に失敗します。この状況は、プライマリデータベースの外部キーが別のデータベースのプライマリキーを参照する場合、またはその逆の場合に発生します。これは、制約参照が ID ベースであるためです。データベーススナップショットは、独自のデータベース外にあるオブジェクトへの ID ベースの参照を解決できません。

アカウントの外部キー参照を表示するには、情報スキーマまたは ACCOUNT_USAGE スキーマの TABLE_CONSTRAINTS ビューをクエリします。

複製とアクセス制御

セカンダリデータベースは読み取り専用です。ただし、データベース所有者(つまり、セカンダリデータベースに対して OWNERSHIP 権限を持つロール)は、 GRANT <権限> ... TO ROLE を使用して、データベースオブジェクト(つまり、スキーマ、テーブル、ビューなど)に対する権限を他のロールに付与できます。

履歴使用データ

プライマリデータベースのアクティビティの履歴使用データは、セカンダリデータベースに複製されません。各アカウントには、独自のクエリ履歴、ログイン履歴などがあります。

履歴使用データには、次の 情報スキーマ 表関数または アカウントの使用 ビューによって返されたクエリデータが含まれます。

  • COPY_HISTORY

  • LOGIN_HISTORY

  • QUERY_HISTORY

  • など。