このガイドは、Microsoft Fabric のミラー化された BigQuery の既存の制限事項の詳細を学習するのに役立ちます。
Important
現在、オンプレミス データ ゲートウェイ (OPDG) 用の Google BigQuery のミラーリングがサポートされています。 バージョン 3000.286.6 以降を利用する
データベース レベルの制限事項
主キーを使用せずにテーブルをミラーリングする場合は、挿入のみの変更のみを実行して、データの精度を確保できます。 非挿入の変更が見つかった場合、テーブルは自動的に再シードされます（テーブル全体が再ミラーリングされます）。 その最初の再シードの後に複数の非挿入変更が発生した場合、ミラーリングは一定期間バックオフ状態になります。バックオフ状態は、コストを抑え、不要なテーブル全体のレプリケーションを制限するのに役立ちます。 バックオフ期間が経過すると、テーブルはミラーリングの通常の状態 (継続的なデータ レプリケーション) に戻ります。
パフォーマンスの制限事項
大きなテーブルのほとんどのデータを変更する場合は、ミラーリングを停止して再起動する方が効率的です。 何十億ものレコードを挿入または更新する場合、時間がかかる場合があります。
通常、ミラー化されたデータは 、BigQuery の変更データ キャプチャ (CDC) アーキテクチャによる 10 ~ 15 分の遅延による変更を反映します。 変更が検出されない場合、レプリケーション エンジンはバックオフ モードに入り、ポーリング間隔を最大 1 時間まで増やします。
サポートされているリージョンの制限事項
データベース ミラーリングは、すべての Microsoft Fabric リージョンで使用できます。 詳細については、「Fabric が使用できるリージョン」を参照してください。
アクセス許可の制限事項
Google BigQuery のミラーリングの編集アクセス許可を有効にすることをためらっているお客様もいると理解しています。 ミラーリングにより、OneLake における BigQuery データのライブツイン、すなわち編集可能な消費レプリカが作成されます。 Google BigQuery のミラーリングをサポートするには、レプリケーション エンジンで次の手順を実行する必要があります。
- BigQuery テーブルからデータにアクセスしてエクスポートする
- 変更データ キャプチャ (CDC) を使用して変更を追跡する
- レプリケーション用の一時データセットとジョブを作成する
- ステージングとインジェストのために Google Cloud Storage と対話する
リシードの制限
Google の CDC テクノロジを使用して BigQuery テーブルの変更の追跡を可能にする CHANGES 関数には、ミラーリング ソリューションを実装する際にユーザーが考慮する必要があるいくつかの重要な再シード制限が適用されます。
- タイム トラベル制限: CHANGES 関数は、テーブルの構成されたタイム トラベル ウィンドウ内のデータのみを返します。 標準テーブルの場合、これは通常 7 日間ですが、構成が異なる場合は短くなる可能性があります。 このウィンドウ外の変更にはアクセスできません。
- タイムスタンプの制限: CHANGES TVF の変更履歴の時間枠が最大許容時間を超えています。
start_timestampからend_timestampまでの最大許容範囲は 1 日です。 これにより、より長い履歴ウィンドウのバッチ処理が制限され、より広範な範囲で複数のクエリが必要になる場合があります。
-Change History Limitation: CHANGES 関数では、使用する前にテーブルに対して変更履歴の追跡を有効にする必要があります。 有効になっていない場合は、差分変更を照会できません。 - 複数ステートメントの制限: CHANGES 関数は、複数ステートメント トランザクション内では使用できません。 また、要求された時間枠内で複数ステートメント トランザクションがコミットされたテーブルに対してクエリを実行することもできません。
詳細については、 Google の BigQuery の変更制限に関するドキュメントを参照してください。