本日、Microsoft Fabric の Mirroing Databases の機能が Public Preview で提供されました。
- Announcing the Public Preview of Mirroring in Microsoft Fabric
- Public Preview: Azure SQL Database Mirroring in Microsoft Fabric
Mirroring については、What is Mirroring in Fabric? のドキュメントツリーから確認することができます。
Mirroring は SQL Database だけでなく Cosmos DB / Snowflake からも同期することができ、面白そうな機能ですね。
- Mirroring Azure SQL Database (Preview)
- Mirroring Azure Cosmos DB (Preview)
- Mirroring Snowflake (Preview)
基本的な内容についてはドキュメントを確認すれば把握できますが、SQL Database からの連携について、実際に設定しながら試してみて気づいた内容を残しておきたいと思います。
Contents
Synapse Link との違い
Mirroring の比較対象としては Synapse Link for SQL になるのではないでしょうか。
現状の Synapse Link の制限事項については、次のドキュメントに記載されています。
Fabric の SQL Database に対しての Mirroring の制限については、次のドキュメントに記載されています。
制限については、データベース レベルの制限事項 に記載されていますが Synapse Link との併用はできないため、Synapse Link と、Fabric Mirroring のどちらを使用するかは決めておく必要があります。
制限事項
Mirroring で改善された制限事項
厳密な比較については比較表を作るのが良いかと思いますが、制限事項の変化は大きいのではないでしょうか。
- 列の追加 / 削除をサポート
- Fabric でも列の定義 / 名前変更はできないが追加 / 削除はサポートされる
- 列の追加 / 削除を実行した場合は、該当テーブルが再シードされるため初期スナップの再生成が発生するかと
- When there is DDL change, a complete data snapshot is restarted for the changed table, and data is reseeded.
- テーブルの列数
- Synapse Link ではテーブルの列数の最大数は 1,020 という制限がありましたが Mirroring ではこの制限の記載がありませんでした
- 実際に試してはいないので、1,024 列のような SQL Sever でサポートする最大列数のテーブルを連携できるようになったのかまでは確認していません
- Synapse Link ではテーブルの列数の最大数は 1,020 という制限がありましたが Mirroring ではこの制限の記載がありませんでした
Mirroring でも引き続き発生する制限事項
Mirroring でも Synapse Link と同様に引き続き発生する制限事項があります。
- varchar / nvarchar の max の取り扱いには制限がある
- SQL Database で varchar(max) / nvarchar(max) の列については Latin1_General_100_BIN2_UTF8 の照合順序が使用された varchar(8000) として連携されていました
- UTF-8 の照合順序が使用されているため日本語の格納も問題はありませんが、連携できるテキストデータ長には制限があります
- Synapse Link と同様に Mirroring 対象として設定したテーブルについては、「max text repl size (B)」の制限を受けるようになりますので、「1,048,576 byte 以上の文字列」に更新ができなくなります。
- 初期スナップショットの段階では長い文字列のデータは 1MB まで切り捨てが行われるため、初期同時では問題は発生しません
- SQL Database では max text repl size は変更できないため、初期同期後、長い文字列を格納する想定の列 (max) に対して 、設定値以上の文字に変更しようとして UPDATE を行うとエラーとなります
- 同期対象となるソーステーブルには主キーが必要
- これについては Mirroring でも同様の制限があります
- テーブル構造としては、クラスター化列ストアインデックスが Mirroring ではサポートされていなくなっているようですので、列ストアインデックスが設定されているテーブルを同期対象として指定したい場合は注意が必要そうですね
Synapse Link との違い
- SQL Server 認証がサポートされない
- Synapse Link の同期先である Dedicated SQL Pool は、SQL Server 認証によるアクセスがサポートされますが、Fabric の SQL エンドポイントに対しては SQL Server 認証用のログインを作成することができないため、接続方法は Entra ID 認証に制限されるかと思います。
- SQL エンドポイントの活用方法の違い
- Synapse Link の Dedicated SQL Pool に対しての同期は、フル機能の Dedicated SQL Pool に対してデータの同期を行っているため、同期対象のテーブル以外にも任意のテーブルを作成してデータの分析を行うことができます。
- Fabric Mirroring では、Mirroring の設定時に指定した名称でデータベースが作成されますが、そのデータベースは同期対象のテーブルのみが含まれる読み取り用のデータベースとなるため、任意のテーブルを作成することはできません。
- 任意のテーブルを作成し、そのテーブルと JOIN をしたいという場合には、Fabric 上に新しく Warehouse を作成し、そのデータベース上に任意のテーブルを作成して、Mirroring のテーブルと JOIN を行うというような考慮が必要となります。
- 一時停止操作が無い
- Synapse Link では一時停止という状態があり、一時停止後の再開については初期スナップショットによる同期は行われず、途中からの再開となっていたかと思います
- Mirroring については、開始 / 停止の操作のみが許可されており一時停止はありません。停止後の開始については Synapse Link と同様に、初期スナップショット取得による再同期となるため、大量データを連携している場合の同期の一時的な停止方法については気を付けておく必要があります。
- Mirroring を解除して DB を使用し続けることができない
- Synapse Link は、既存の Dedicated SQL Pool に対して、データベースの継続的な同期を実施するため、同期を解除してもそれまで同期されたデータについては Dedicated SQL Pool に残った状態となります。
- Mirroring については、Mirroring による同期設定した環境を SQL エンドポイントとしてアクセスを可能にするため、Mirroring の設定を解除すると同期されているデータにアクセスができなくなります。
- コンピューティングコストが発生しない
- Synapse Link ではデータ同期を実施している最中は同期プロセスのためのコンピューティングコストが発生しました。
- 仮想コア時間あたり \37.897 = 仮想コア / 月あたり \27,664.81
- プレビュー時点では、Mirroring についてはデータ同期のためのコンピューティングコストが発生しないことが Cost Management に記載されています。
- コストについては Announcing the Public Preview of Mirroring in Microsoft Fabric にも記載されていますが、コンピューティングのコストは発生せず、ストレージコスト (一部無料枠あり) が大きなコストとなりそうですので、Synapse Link よりコストを抑えてデータの同期はできそうな雰囲気があります
- Microsoft Fabric の価格 にも記載が追加されました。
- Fabric の SKU に応じて、Mirroring 用の無料ストレージが提供されており、最小の F2 でも 2TB のストレージが提供されます。
- Fabric を一時停止している場合は、Mirroring のストレージのコストは発生するようなのですが、常時起動している場合は通常のコストの中に含まれているという考え方でよいのではないでしょうか。
- データ格納先が OneLake となったことで同期設定がシンプルになった
- Synapse Link は Dedicated SQL Pool に対してデータの同期を行うため、テーブルの構造 (ヒープ / 列ストア / 分散方式) を意識する必要がありましたが、Mirroring は OneLake への格納となるため、テーブルの構造を意識する必要がなくなりました
データ同期に関しての技術的要素
ざっと確認した感じではありますが、データ同期に関しての技術的要素については、Synapse Link と類似の仕組みとなっていそうでした。
select * from sys.databases where database_id = db_id(); select * from sys.tables where is_replicated = 1; select * from sys.dm_change_feed_log_scan_sessions order by start_time desc; select * from sys.dm_change_feed_errors; EXECUTE sys.sp_help_change_feed; select * from sys.dm_exec_requests outer apply sys.dm_exec_query_statistics_xml(session_id) WHERE command LIKE 'SYNAPSE%' order by command ASC; select * from sys.dm_exec_sessions where login_name = '<mirroring の接続で使用しているユーザー名>';
Mirroring を有効ににすると、データベースの設定としては 「is_change_feed_enabled」「is_data_lake_replication_enabled」が「1」に設定され、Mirroring によるデータ同期が行われているデータベースとして設定が行われます。
(Synapse Link の場合は is_change_feed_enabled = 1 となっており、Mirroring 向けの列が追加されたようです)
同期対象として指定されているテーブルについては「is_replicated = 1」として設定が行われ、トランザクションログから同期に必要となるログレコードの取得ができるようになります。
データの同期状況については、sys.dm_change_feed_log_scan_sessions / sys.dm_change_feed_errors から取得することができ、設定については、sp_help_change_feed で取得することができますが、これは Synapse Link と同様となっています。
Mirroring を有効にすると Command として 「SYNAPSE」で始まるセッションが常駐し、変更やスナップショット取得が制御されていましたので、Landing Zone までデータを連携する仕組みについては Synapse Link 相当の仕組みが使用されているような雰囲気がありました。
そのため、Azure Synapse Link for SQL Server と Azure SQL Database の管理 に記載されている内容についても参考になるかと思います。
Synapse Link では「changefeed」というスキーマが作成され、changefeed.change_feed_settings / changefeed.change_feed_table_groups / changefeed.change_feed_tables が格納されていましたが、Mirroring ではこれらの情報は sys スキーマ内に格納されるようになったようで、情報がユーザーからは隠蔽されるようになっていました。
Mirroring の評価環境
Mirroring の評価については、以下の環境で実施することができました。
SQL Database については、Tier and purchasing model support に記載されているのですが実行できる環境に制限があり、DTU の Basic / Standard 100 DTU 未満の環境では、データソースとして指定することができません。
SQL Database の無料プランについては vCore の Serverless で実行されており、Mirroring のデータソースとして指定することが可能となっていますので、コストを抑えて基本的な動作を確認しようと思った場合には、Fabric の試用版と SQL Database の無料プランを使ってみるとよいのではないでしょうか。
あとで思い返せるように残しておきたいと思った情報はこのような内容でしょうか。
Mirroring は分析基盤へのデータ同期を容易な設定により実現することができますので、大規模データ分析では活用できるシーンは多そうですね。