プレビューの制限事項
Amazon Redshift との ゼロ ETL 統合には、以下の制限が適用されます。
-
ターゲット Amazon Redshift データウェアハウスは、次の前提条件を満たす必要があります。
-
Amazon Redshift Serverless または RA3 ノードタイプを実行している。
-
暗号化されている (プロビジョニングされたクラスターを使用している場合)
-
大文字と小文字の区別が有効になっている。
-
-
Amazon Redshift データウェアハウスの承認済み統合ソースであるソースを削除すると、関連するすべての統合が
FAILED
状態になります。以前にレプリケートされたデータは Amazon Redshift データベースに残っており、クエリを実行できます。 -
デスティネーションデータベースは読み取り専用です。デスティネーションデータベースにテーブル、ビュー、またはマテリアライズドビューを作成することはできません。ただし、ターゲットデータウェアハウスのその他のテーブルでもマテリアライズドビューを使用できます。
-
マテリアライズドビューは、クロスデータベースクエリで使用される場合にサポートされます。ゼロ ETL 統合を介してレプリケートされたデータを使用してマテリアライズドビューを作成する方法の詳細については、「レプリケートしたデータのマテリアライズドビューでのクエリ」を参照してください。
-
デフォルトでは、クエリできるのは、
Synced
状態のターゲットデータウェアハウスのテーブルのみです。別の状態のテーブルをクエリするには、データベースパラメータQUERY_ALL_STATES
をTRUE
に設定します。QUERY_ALL_STATES
の設定の詳細については、「Amazon Redshift データベースデベロッパーガイド」の「CREATE DATABASE」と「ALTER DATABASE」を参照してください。データベースの状態の詳細については、「Amazon Redshift データベースデベロッパーガイド」の「SVV_INTEGRATION_TABLE_STATE」を参照してください。 -
Amazon Redshift では UTF-8 文字のみを使用できるため、ソースで定義された照合順序に従わない場合があります。ソートルールと比較ルールは異なる場合があり、それによって最終的にクエリ結果が変わる可能性があります。
-
ゼロ ETL 統合は、Amazon Redshift データウェアハウスのターゲットごとに 50 に制限されています。
-
統合ソースのテーブルにはプライマリキーが必要です。それ以外の場合は、Amazon Redshift でターゲットのデータウェアハウスにテーブルが複製されません。
Amazon Aurora PostgreSQL にプライマリキーを追加する方法については、AWS データベースブログの「Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift
」を参照してください。Amazon Aurora MySQL または RDS for MySQL にプライマリキーを追加する方法については、AWS データベースブログの「Amazon Aurora MySQL または Amazon RDS for MySQL と Amazon Redshift とのゼロ ETL 統合を作成する際にプライマリキーがないテーブルを処理する 」を参照してください。 -
Aurora ゼロ ETL 統合でのデータフィルタリングを使用して、ソースの Aurora DB クラスターからターゲットの Amazon Redshift データウェアハウスへのレプリケーションの範囲を定義できます。すべてのデータをターゲットにレプリケートするのではなく、単一または複数のフィルターを定義して、特定のテーブルを選択的にレプリケーションの対象に含めたり除外したりできます。詳細については、「Amazon Aurora ユーザーガイド」の「Amazon Redshift との Aurora のゼロ ETL 統合向けのデータフィルタリング」を参照してください。
-
Aurora PostgreSQL と Amazon Redshift のゼロ ETL 統合では、Amazon Redshift は Aurora PostgreSQL から最大 100 個のデータベースをサポートします。各データベースは、ソースからターゲットに個別にレプリケートされます。
-
ゼロ ETL 統合は、トランザクションデータストアから Amazon Redshift にデータをレプリケートする際の変換をサポートしていません。データはソースデータベースからそのままレプリケートされます。ただし、Amazon Redshift でレプリケートしたデータに変換を適用することはできます。
-
ゼロ ETL 統合は、並列接続を使用して Amazon Redshift で実行します。この実行には、統合からデータベースを作成したユーザーの認証情報を使用します。クエリを実行しても、同期 (書き込み) 中は、これらの接続に対して同時実行スケーリングが開始されません。同時実行スケーリングの読み取り (Amazon Redshift クライアントから) は、同期されたオブジェクトにおいて機能します。
-
Amazon Redshift へのデータレプリケーションの頻度を制御するため、ゼロ ETL 統合の
REFRESH_INTERVAL
を設定できます。詳細については、「Amazon Redshift データベースデベロッパーガイド」の「CREATE DATABASE」および「ALTER DATABASE」を参照してください。
ターゲットで履歴モードを使用する場合の考慮事項
ターゲットデータベースで履歴モードを使用する場合、次の考慮事項が適用されます。詳細については、「履歴モード」を参照してください。
-
ソースのテーブルを削除すると、ターゲットのテーブルは削除されず、
DroppedSource
状態に変更されます。Amazon Redshift データベースからテーブルを削除したり、名前を変更したりすることができます。 -
ソースのテーブルを切り捨てると、ターゲットテーブルで削除が実行されます。例えば、ソースですべてのレコードが切り捨てられると、ターゲット列
_record_is_active
の対応するレコードがfalse
に変更されます。 -
ターゲットテーブルで TRUNCATE table の SQL を実行すると、アクティブな履歴行は非アクティブとマークされ、対応するタイムスタンプが追加されます。
-
テーブル内の行が非アクティブに設定されると、短い 遅延後 (約 10 分後) に削除できるようになります。非アクティブな行を削除するには、クエリエディタ v2 などの SQL クライアントを使用して、ゼロ ETL データベースに接続します。
-
非アクティブな行が削除できるのは、履歴モードがオンになっているテーブルからのみです。例えば、次のような SQL コマンドは、非アクティブな行のみを削除します。
delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56'
これは、次のとおりの SQL コマンドと同等です。
delete from schema.user_table where _record_delete_time <= '2024-09-10 12:34:56' and _record_is_active = False
-
テーブルの履歴モードをオフにすると、すべての履歴データは
<schema>.<table-name>_historical_<timestamp>
という名前のテーブルに保存され、元の<schema>.<table-name>
という名前のテーブルは更新されます。 -
履歴モードがオンになっているテーブルがテーブルフィルターを使用してレプリケーションから除外されると、すべての行が非アクティブに設定され、
DroppedSource
状態に変更されます。テーブルフィルターの詳細については、「Amazon Aurora ユーザーガイド」の「Amazon Redshift との Aurora ゼロ ETL 統合でのデータフィルタリング」を参照してください。 -
履歴モードを
true
またはfalse
に切り替えられるのは、Synced
状態のテーブルに対してのみです。
ゼロ ETL 統合ソースが Aurora または Amazon RDS である場合の考慮事項
Amazon Redshift との Aurora と Amazon RDS ゼロ ETL 統合には、以下の制限が適用されます。
-
Aurora と RDS for MySQL ゼロ ETL 統合でのデータフィルタリングを使用して、ソースの DB クラスターからターゲットの Amazon Redshift データウェアハウスへのレプリケーションの範囲を定義できます。すべてのデータをターゲットにレプリケートするのではなく、単一または複数のフィルターを定義して、特定のテーブルを選択的にレプリケーションの対象に含めたり除外したりできます。詳細については、「Amazon Aurora ユーザーガイド」の「Amazon Redshift との Aurora のゼロ ETL 統合向けのデータフィルタリング」を参照してください。
-
統合ソースのテーブルにはプライマリキーが必要です。それ以外の場合は、Amazon Redshift でターゲットのデータウェアハウスにテーブルが複製されません。
Amazon Aurora PostgreSQL にプライマリキーを追加する方法については、AWS データベースブログの「Handle tables without primary keys while creating Amazon Aurora PostgreSQL zero-ETL integrations with Amazon Redshift
」を参照してください。Amazon Aurora MySQL または RDS for MySQL にプライマリキーを追加する方法については、AWS データベースブログの「Amazon Aurora MySQL または Amazon RDS for MySQL と Amazon Redshift とのゼロ ETL 統合を作成する際にプライマリキーがないテーブルを処理する 」を参照してください。 -
Amazon Redshift VARCHAR データ型の最大長は 65,535 バイトです。ソースのコンテンツがこの制限に収まらない場合、レプリケーションは実行されず、テーブルのステータスは失敗になります。データベースパラメータ
TRUNCATECOLUMNS
をTRUE
に設定すると、列に収まるようにコンテンツを切り捨てることができます。TRUNCATECOLUMNS
の設定の詳細については、「Amazon Redshift データベースデベロッパーガイド」の「CREATE DATABASE」と「ALTER DATABASE」を参照してください。ゼロ ETL 統合ソースと Amazon Redshift データベース間のデータ型の違いの詳細については、「Amazon Aurora ユーザーガイド」の「Aurora と Amazon Redshift 間のデータ型の違い」を参照してください。
Aurora のソースについては、「Amazon Aurora ユーザーガイド」の「制限」も参照してください。
Amazon RDS のソースについては、「Amazon RDS ユーザーガイド」の「制限」も参照してください。
ゼロ ETL 統合ソースが DynamoDB である場合の考慮事項
Amazon Redshift との DynamoDB ゼロ ETL 統合には、以下の制限が適用されます。
-
DynamoDB のテーブル名が 127 文字を超えるとサポートされません。
-
DynamoDB ゼロ ETL 統合からのデータは、Amazon Redshift の SUPER データ型列にマッピングされます。
-
127 文字を超えるパーティションキーまたはソートキーの列名はサポートされていません。
-
DynamoDB からのゼロ ETL 統合は、1 つの Amazon Redshift データベースにのみマッピングできます。
-
パーティションキーとソートキーの場合、精度とスケールの最大値は (38,18) です。DynamoDB の数値データ型は、最大 38 の精度をサポートしています。Amazon Redshift も最大 38 の精度をサポートしていますが、Amazon Redshift のデフォルトの 10 進精度/スケールは (38,10) です。つまり、値のスケール値は切り捨てられる場合があります。
-
ゼロ ETL 統合を正常に実行するには、DynamoDB 項目内の個々の属性 (名前と値で構成) が 64 KB を超えることはできません。
-
有効化すると、ゼロ ETL 統合により、DynamoDB テーブル全体を Amazon Redshift データベースにエクスポートします。この初期プロセスが完了するまでにかかる時間は、DynamoDB テーブルのサイズによって異なります。ゼロ ETL 統合により、その後は DynamoDB から Amazon Redshift への更新が、DynamoDB の増分エクスポートを使用して段階的にレプリケートされます。つまり、Amazon Redshift にレプリケートされる DynamoDB データは、自動的に最新に保たれます。
現在、DynamoDB ゼロ ETL 統合の最小レイテンシーは 15 分です。ゼロ ETL 統合にゼロ以外の
REFRESH_INTERVAL
を設定することにより、さらに増やすことができます。詳細については、「Amazon Redshift データベースデベロッパーガイド」の「CREATE DATABASE」および「ALTER DATABASE」を参照してください。
Amazon DynamoDB ソースについては、「Amazon DynamoDB デベロッパーガイド」の「前提条件と制限」も参照してください。
ゼロ ETL 統合のソースが Salesforce、SAP、ServiceNow、Zendesk などのアプリケーションである場合の考慮事項
Amazon Redshift との統合のソースが Salesforce、SAP、ServiceNow、Zendesk などのアプリケーションである場合は、次の点を考慮してください。
-
アプリケーションソースからのテーブル名と列名が 127 文字を上回る場合、これらの名前はサポートされません。
-
Amazon Redshift VARCHAR データ型の最大長は 65,535 バイトです。ソースのコンテンツがこの制限に収まらない場合、レプリケーションは実行されず、テーブルのステータスは失敗になります。データベースパラメータ
TRUNCATECOLUMNS
をTRUE
に設定すると、列に収まるようにコンテンツを切り捨てることができます。TRUNCATECOLUMNS
の設定の詳細については、「Amazon Redshift データベースデベロッパーガイド」の「CREATE DATABASE」と「ALTER DATABASE」を参照してください。ゼロ ETL 統合のアプリケーションソースと Amazon Redshift データベース間のデータ型の違いの詳細については、「AWS Glue デベロッパーガイド」の「ゼロ ETL 統合」を参照してください。
-
アプリケーションとのゼロ ETL 統合の最小レイテンシーは 1 時間です。ゼロ ETL 統合にゼロ以外の
REFRESH_INTERVAL
を設定することにより、さらに増やすことができます。詳細については、「Amazon Redshift データベースデベロッパーガイド」の「CREATE DATABASE」および「ALTER DATABASE」を参照してください。
アプリケーションとのゼロ ETL 統合のソースについては、「AWS Glue デベロッパーガイド」の「ゼロ ETL 統合」も参照してください。