Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

設定
お問い合わせ
フィードバック
AWS Documentation
今すぐ無料サインアップ »
Amazon Redshift でのデータ共有に関する考慮事項 - Amazon Redshift
クラスター暗号化管理クラスター内およびクラスター間のデータ共有読み取り専用とマルチウェアハウス書き込みのデータ共有の比較データ共有の読み取りに関する制限事項マルチウェアハウス書き込みに関する制限事項データレイクテーブルに関する制限事項データ共有に付与できるアクセス許可データ共有コンシューマー向けにサポートされている SQL ステートメント

Amazon Redshift でのデータ共有に関する考慮事項

PDFRSS

Amazon Redshift のデータ共有を操作する際の考慮事項は次のとおりです。

  • リージョン間のデータ共有には、リージョン間のデータ転送料金が追加されます。これらのデータ転送料金は、同じリージョン内では適用されず、リージョン間の場合にのみ適用されます。詳細については、「クロスリージョンでのデータ共有でコスト管理を行う」を参照してください。

  • データ共有からデータを読み取ると、ローカルクラスターデータベースに接続したままになります。データ共有から作成されたデータベースの設定と読み取りの詳細については、「データ共有オブジェクトのクエリ」および「Amazon Redshift Spectrum の外部データレイクテーブルのマテリアライズドビュー」を参照してください。

  • プロデューサーのデータをクエリするために必要なすべてのコンピューティング料金とリージョン間のデータ転送料金は、コンシューマーに請求されます。プロデューサーは、プロビジョニングされたクラスターまたはサーバーレス名前空間のデータの基本ストレージに対して課金されます。

  • 共有データに対するクエリのパフォーマンスは、コンシューマークラスターの計算能力によって異なります。

データ共有でのクラスター暗号化管理

AWS アカウント間でデータを共有するには、プロデューサークラスターとコンシューマークラスターの両方が暗号化されている必要があります。

Amazon Redshift では、クラスターに対してデータベースの暗号化を有効にして、保管中のデータを保護できます。クラスターに対して暗号化を有効にすると、クラスターとそのスナップショットのデータブロックとシステムメタデータが暗号化されます。クラスターの起動時に暗号化を有効にすることも、暗号化されていないクラスターを AWS Key Management Service (AWS KMS) 暗号化を使用するように変更することもできます。

Amazon Redshift データベースの暗号化の詳細については、「Amazon Redshift 管理ガイド」の「Amazon Redshift データベースの暗号化」を参照してください。

転送中のデータを保護するために、すべてのデータは、プロデューサークラスターの暗号化スキーマを介して転送中に暗号化されます。この暗号化スキーマは、データのロード時にコンシューマークラスターにより導入されます。この後、コンシューマークラスターは、通常の暗号化クラスタとして動作します。プロデューサとコンシューマー間の通信も、共有されたキースキーマを使用して暗号化されます。転送時の暗号化の詳細については、「送信中の暗号化」を参照してください。

クラスター内およびクラスター間のデータ共有

データ共有は、異なる Amazon Redshift のプロビジョニングされたクラスター間またはサーバーレスワークグループでデータを共有する場合にのみ必要です。同じクラスター内で、他のデータベース内のオブジェクトに対して必要なアクセス許可を持っている限り、単純な 3 つの部分からなる表記 database.schema.table を使用して別のデータベースにクエリを実行できます。

読み取り専用とマルチウェアハウス書き込みのデータ共有の比較

以前は、データ共有内のオブジェクトはどのような状況でも読み取り専用でした。データ共有内のオブジェクトへの書き込みは新機能です。データ共有内のオブジェクトは、プロデューサーがデータ共有へのオブジェクトに対する INSERT や CREATE などの書き込み権限を明示的に付与した場合にのみ、書き込み可能になります。さらに、アカウント間の共有の場合、プロデューサーは書き込み用のデータ共有を承認し、コンシューマーは書き込み用に特定のクラスターとワークグループを関連付ける必要があります。

データ共有の読み取りに関する制限事項

Amazon Redshift でデータ共有の読み取りを処理する場合の制限事項は、以下のとおりです。

  • データ共有は、プロビジョニングされたすべての RA3 クラスタータイプおよび Amazon Redshift Serverless でサポートされています。他のクラスタータイプではサポートされていません。

  • プロデューサークラスターとコンシューマークラスターの両方とサーバーレス名前空間が同じアカウントにある場合は、同じ暗号化タイプ (両方とも暗号化されていない、または両方とも暗号化されている) である必要があります。Lake Formation のマネージドデータ共有を含む他のすべての場合、コンシューマーとプロデューサーの両方を暗号化する必要があります。これはセキュリティ上の目的です。ただし、同じ暗号キーを共有する必要はありません。

  • SQL UDF はデータ共有を通じてのみ共有できます。Python と Lambda UDF はサポートされていません。

  • プロデューサデータベースに特定の照合順序がある場合は、コンシューマーデータベースでも同様な照合順序設定を使用します。

  • Amazon Redshift は、プロデューサークラスターでネストされたユーザー定義の SQL 関数をサポートしません。

  • Amazon Redshift では、インターリーブされたソートキーを持つテーブルと、インターリーブされたソートキーを持つテーブルを参照するビューの共有はサポートされていません。

  • コンシューマーは、データ共有オブジェクトを別のデータ共有に追加することはできません。さらに、コンシューマーはデータ共有オブジェクトを参照するビューを別のデータ共有に追加することはできません。

  • Amazon Redshift は、アクセスの準備と実行の間に同時に DDL が発生した、データ共有オブジェクトへのアクセスをサポートしていません。

  • Amazon Redshift は、データ共有によるストアドプロシージャの共有をサポートしていません。

  • Amazon Redshift は、メタデータシステムビューとシステムテーブルの共有をサポートしていません。

マルチウェアハウス書き込みに関する制限事項

注記

データ共有を使用した Amazon Redshift のマルチウェアハウス書き込みは、Amazon Redshift パッチ 186 でのみサポートされています。プロビジョニング済みクラスターについては最新トラックバージョン 1.0.78881 以降、Amazon Redshift Serverless ワークグループについてはバージョン 1.0.78890 以降が対象です。

Amazon Redshift でデータ共有の書き込みを処理する場合の制限事項は、以下のとおりです。

  • 接続ｘ – データ共有データベースに書き込むには、データ共有データベースに直接接続するか、USE コマンドを実行する必要があります。3 部分構成の表記を使用することもできます。USE コマンドは、外部テーブルに対しては使用できません。

  • コンピューティングタイプ - この機能を使用するには、Serverless ワークグループ、ra3.xlplus クラスター、ra3.4xl クラスター、または ra3.16xl クラスターを使用する必要があります。

  • メタデータの検出 — Redshift JDBC、ODBC、または Python ドライバーを介してデータ共有データベースに直接接続しているコンシューマーの場合、以下の方法でカタログデータを表示できます。

  • アクセス許可の表示 – コンシューマーは、データ共有に対して付与されているアクセス許可を SHOW GRANTS SQL コマンドで確認できます。

  • 暗号化 – アカウント間のデータ共有の場合、プロデューサクラスターとコンシューマークラスターの両方を暗号化する必要があります。

  • 分離レベル – 他の Serverless ワークグループやプロビジョニング済みクラスターからデータベースへの書き込みを許可するには、データベースの分離レベルをスナップショット分離にする必要があります。

  • 自動操作 – コンシューマーがデータ共有オブジェクトに書き込みを行っても、自動分析操作はトリガーされません。そのため、プロデューサーはテーブルにデータを挿入した後に、手動で分析を実行してテーブル統計を更新する必要があります。このようにしないと、クエリプランが最適にならない可能性があります。

  • マルチステートメントのクエリとトランザクション — トランザクションブロック外のマルチステートメントのクエリは、現在サポートされていません。そのため、dbeaver のようなクエリエディターを使用していて、書き込みクエリが複数ある場合は、クエリを明示的な BEGIN... END トランザクションステートメントでラップする必要があります。

    マルチコマンドのステートメントがトランザクションの外部で使用されていて、その最初のコマンドがプロデューサーデータベースへの書き込みである場合、ステートメント内の後続の書き込みコマンドは、そのプロデューサーデータベースに対してのみ許可されます。最初のコマンドが読み取りの場合、後続の書き込みコマンドは、使用対象のデータベースが設定されている場合はそのデータベース、未指定の場合はローカルデータベースに対してのみ許可されます。1 件のトランザクションに含まれる複数の書き込みは、単一のデータベースに対してのみ実行できます。

  • コンシューマーサイズ – データ共有を使用して書き込みを実行するには、コンシューマークラスターに少なくとも 64 以上のスライスが必要です。

  • ビューとマテリアライズドビュー – データ共有のデータベースのビューまたはマテリアライズドビューを作成、更新、変更することはできません。

  • セキュリティ – 列レベル (CLS)、行レベル (RLS)、動的データマスキング (DDM) などのセキュリティポリシーをデータ共有オブジェクトにアタッチまたは削除することはできません。

  • 管理可能性 – コンシューマーウェアハウスは、データ共有オブジェクトや、データ共有オブジェクトを参照するビューを別のデータ共有に追加することはできません。コンシューマーは、既存のデータ共有を変更または削除することもできません。

  • Truncate オペレーション – データ共有書き込みは、リモートテーブルのトランザクションの切り捨てをサポートします。これは、自動コミットであるクラスターでローカルに実行する切り捨てとは異なります。SQL コマンドの詳細については、「TRUNCATE」を参照してください。

データレイクテーブルに関する制限事項

Amazon Redshift でデータレイクテーブルを操作する場合の制限事項は、以下のとおりです。

  • データレイクテーブルのデータ共有では、Amazon S3 バケットの暗号化にカスタマー管理の AWS KMS keys は使用できません。暗号化には AWS マネージドキー を使用できます。詳細については、「Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3)」を参照してください。

  • 暗号化された AWS Glue カタログからデータレイクテーブルのデータを共有するには、「Data Catalog の暗号化」の手順に従って、AWS KMS オペレーションを IAM ロールに委任する必要があります。

データ共有に付与できるアクセス許可

データ共有コンテキストにおける、さまざまなオブジェクトタイプと、それらに付与できるさまざまなアクセス許可は、以下のとおりです。

スキーマ:

  • CREATE

  • USAGE

  • ALTER

  • DROP

テーブル:

  • SELECT

  • INSERT

  • UPDATE

  • DELETE

  • TRUNCATE

  • DROP

  • ALTER

  • REFERENCES

関数:

  • EXECUTE

データベース:

  • CREATE

  • USAGE

  • ALTER

  • DROP

データ共有コンシューマー向けにサポートされている SQL ステートメント

書き込みによるデータ共有では、次のデータ定義言語 (DDL) ステートメントがサポートされています。

  • ALTER TABLE RENAME TO

  • ALTER TABLE RENAME COLUMN TO

  • ALTER TABLE ADD/DROP COLUMN

  • ALTER SCHEMA RENAME TO

  • { CREATE | DROP } SCHEMA

  • { CREATE | DROP | SHOW } TABLE

  • CREATE TABLE table_name AS

  • BEGIN | START TRANSACTION

  • END | COMMIT | ROLLBACK

  • TRUNCATE

書き込みによるデータ共有では、次のデータ操作言語 (DML) ステートメントがサポートされています。

  • SELECT

  • INSERT

  • INSERT INTO SELECT

  • UPDATE

  • DELETE

  • MERGE

  • COPY without COMPUPDATE

書き込みを伴うデータ共有では、以下の分析ステートメントがサポートされています。

  • ANALYZE。コンシューマーは USER ANALYZE を実行して、統計をプロデューサーに送信します。

  • コンシューマーで実行されている CTAS/COPY がアクティブ化する分析。これには、小規模コンシューマー向けの多重化などがあります。

  • COPY 後にプロデューサーで自動分析が実行されます。

書き込みを伴うデータ共有では、以下の許可ステートメントがサポートされています。

  • { GRANT | REVOKE } privilege_name ON OBJECT_TYPE object_name TO consumer_user

  • SHOW GRANTS。詳細については、「SHOW GRANTS」を参照してください。

サポートされていないステートメントタイプ — 以下はサポートされていません。

  • プロデューサーに書き込む際のコンシューマーウェアハウスへのマルチステートメントクエリ。

  • 別のデータベースにあるコンシューマーウェアハウスへのマルチステートメントクエリ (前のコマンドが読み取りステートメントである場合)。

  • 1 ドット表記や 2 ドット表記など、3 ドット表記以外のオブジェクト参照 (共有データベースに接続していない場合)。

  • コンシューマーからプロデューサーへのクエリの書き込みについての同時実行スケーリング。

  • コンシューマーからプロデューサーへのジョブの書き込みの自動コピー。

  • コンシューマーからプロデューサーへのジョブの書き込みのストリーミング。

  • コンシューマーによる、プロデューサークラスター上での ゼロ ETL 統合テーブルの作成。ゼロ ETL 統合の詳細については、「ゼロ ETL 統合の開始方法」を参照してください。

  • データ共有を通じた、インタリーブソートキーを持つテーブルへの書き込み。

  • データ共有を通じた、ストアドプロシージャへの書き込み。

  • データ共有を通じた、SQL ユーザー定義関数 (UDF) への書き込み。ネストされた UDF、Python UDF、Lambda UDF が該当します。

  • コンピューティングスライスの数がプロデューサーよりも多いコンシューマーウェアハウスを対象とした、ID 列の UPDATE、INSERT、または COPY ステートメント。

  • コンシューマーウェアハウスを対象とした、非 RMS 外部テーブルに対する MERGE ステートメント (プロデューサーへの書き込み時)。

  • 以下に該当する CREATE TABLE ステートメント。

    • DEFAULT 式でデータ型が VARBYTE に設定されている。VARBYTE データ型は、暗黙的に他のデータ型に変換できません。詳細については、「CAST 関数」を参照してください。

    • コンシューマーウェアハウスに対する AS OF SELECT ステートメントで NULL パラメータが指定されている (プロデューサーへの書き込み時)。

    • コンシューマーウェアハウスに対する LIKE パラメータが指定されている (プロデューサーへの書き込み時)。

前のトピック:

データ共有

ヘルプが必要ですか?

プライバシーサイト規約Cookie の設定
© 2025, Amazon Web Services, Inc. or its affiliates.All rights reserved.