DigitalABOUTSERVICECASENEWSSPECIALISTRECRUITSPECIALIST多様な専門性を持つNRIデジタル社員のコラム、インタビューやインサイトをご紹介します。勇太2022.12.15クラウド技術検証Azure分析用DBこんにちは、NRIデジタルの湯川です。Analyticsを使ったストリーム処理を作り込む方式がリファレンスアーキテクチャとして提示されています。したアプローチは業務システムか分析システムのどちらかで、もともとストリーム処理を扱っているのであれば、特に問題なく採用できるのだと思いますが、リアルタイム化のためだけに新たにストリーム処理を設計しなければならない場合には比較的重いデータ連携手法になると思います。SQLを実案件で使っていく上での課題を整理してみたので共有したいと思います。※に対して、間にETLツール等を挟まずにデータ同期することができる機能です。通常のレプリケーションとは異なり、Synapse側にデータ元にはないインデックスを持たせることが可能になります。Analyticsで提供されているいわゆるDWです。Analyticsのサービスラインナップとその内容についてはこちらを参照してください。connectionを選択します。リンクサービスを作ります。DBに繋ぐためのプライベートエンドポイントを作ります。同期対象とするとテーブルを選択します。宛先の専用プールを選択します。同期頻度と同期処理に割り当てるリソースを選択します。同期を発行すると、同期が始まります。DBのセカンダリレプリカをソースにすることはできません。Linkの設定の最後で、読み取り専用DBをソースにできないというエラーがでます。環境リソースはすべて東日本リージョンで構成しました。簡単に準備ができるので、今回はsys.objectsを増幅させてテストデータとしました。以下がテーブル定義です。同期はスナップショットを取得後、トランザクションの連携が開始される流れになっています。100件だけ入れてスナップショットにかかる時間をみてみます。ステータスの推移をみると3分30秒で同期完了したようです。同じ条件で1000件に増やして試してみます。今回も3分30秒でした。最後に1000万件で試してみます。3分23秒で完了しましたが、SynapseのDWUを100や1000と比べて大きく消費していました。スナップショットの時間が100~1000万で大きく差が出ず、3分半前後で収まるのは内部的に存在しているその他の処理にかかる時間の影響の方が、この程度のデータ量だと多いということなのではないかと思われます。ソース側のDBがBCなので、性能的に十分すぎるということなのか、ソース側には負荷がかかりにくいデータの取得方法が内部的に行われているのかは分かりませんが、ソース側のDBにかかる負荷は特に変動しているように見えませんでした。一方でSynapse側の負荷は大きく変動しました。どちらかというと、Synapse側のリソースに与える影響の方が大きい同期方式なのではないかと思います。スナップショット後の同期遅延時間スナップショット後の同期にかかる時間をみてみます。以下のクエリで1件更新した場合です。10000000modify_dateの値をみてみると、以下のようになっています。Synapse側の同期ステータスをみると、以下のように表示されました。3秒程度で反映されたということのようです。今度は100万件で試してみます。10000008秒程度で反映されました。DWを41ほど消費しています。今度は1000万件で試してみます。10000000キャプチャを取る時に日本時間にしなかったので分かりにくいですが、1分18秒かかりました。DWは91消費しています。100万件が8秒で同期されるなら、1000万件まで滞留することはあまりないのだろうと思いますが、バッチ等でデータの洗い替えをするようなテーブルの場合は同期が分単位で遅延することは発生しそうです。ネットワーク公式にはマネージド仮想ネットワークを利用できないと記載されています。サポートはされないのかもしれませんが、実際は構成することが可能でした。可用性Synapseの専用プールはコスト削減のために、使わない時には停止することができます。Linkを構成した状態で停止を行うとどうなるのでしょうか。Linkを構成した状態でも停止はできます。専用プールを停止しただけではLinkもエラーになりません。ソース側で更新を発生させてみます。更新は問題なく成功します。10000000数分後に同期状態がエラーになってしまいました。詳細のところをみると、以下のようなスタックトレースが表示されました。このメッセージからDataflowが内部で利用されていることが分かりますね。照合順序の制限おそらく多くの方が最初に遭遇すると思われるのが照合順序の制限です。照合順序でSynapseがまだサポートしていないものをソース側で利用していると同期がエラーになります。Japanese_XJIS_140_CS_AS_KS_WSを試してみます。(N’いいいい’);この場合、Linkの構成をすることはできるのですが、同期はエラーになります。Japanese_XJIS_100_CS_AS_KS_WSであればSynapseでサポートされているので同期してくれます。(N’いいいい’);TRUNCATEができない同期中のテーブルはTRUNCATEできません。Captureが有効になっているか、レプリケーション対象として発行されているので、TRUNCATEはできないというエラーになります。[dbo].[test_data_10]列追加ができない同期中のテーブルは列の追加はできません。feedが有効だとスキーマ変更はできないというエラーになります。BIGINT主キーがないテーブルは同期対象にできない主キーがないテーブルは同期対象にできません。同期中のテーブルであってもINDEXの追加はできました。test_data_10000000_idx_pkey(type_desc)計算列は無視される計算列はPERSISTEDであっても無視されます。エラーにはなりません。以下のようにSynapseには反映されません。その他:実機検証はしていないが公式に記載があるもの制約、制限事項は以下に記載されています。Analyticsここでは特に注意を要するものをピックアップしておきます。Linkが有効にできない以下、GAになった時にはなくなっていてくれないと恐ろしい制限です。制限事項として列挙したもの以外で、注意を要すると思われる仕様に以下があります。SQLはまだプレビューの段階です。今後改善される部分もあるのだと思いますが、実際に本番環境で利用するのは辛いなと感じたのは以下の部分です。DBのデータを専用プールに同期できる方法だということも言えると思います。照合順序以外はトランザクションレプリケーションに似たような制約があるので、トランザクションレプリケーションを利用できるようなシーンでは、この機能を活用していけるのではないでしょうか。