Data Transmission Service (DTS) は、さまざまなシナリオでデータ移行、変更追跡、およびデータ同期をサポートします。
ダウンタイムを最小限に抑えたデータ移行
送信モード: データ移行
従来のデータ転送シナリオでは、データの一貫性を確保するために、データ移行中にソースデータベースへのデータの書き込みを停止する必要があります。 データ移行プロセスが完了するまでに数時間または数日かかる場合があります。 データの量とネットワークの状態によって異なります。 この時間のかかるプロセスは、ビジネスに大きな影響を与える可能性があります。
DTSは、データ移行中のダウンタイムを最小限に抑えます。 このプロセスでは、アプリケーションを引き続き使用できます。 ダウンタイムは、アプリケーションをターゲットデータベースに切り替えたときにのみ発生します。 切り替え時間は数分に短縮できます。 次の図は、DTSでの完全なデータ移行プロセスを示しています。
完全なデータ移行プロセスは、スキーマ移行、完全データ移行、および増分データ移行で構成されます。 増分データ移行中、ソースデータベースの変更はリアルタイムでターゲットデータベースに同期されます。 データ移行が完了したら、移行先データベースに移行されたデータとスキーマがアプリケーションと完全に互換性があるかどうかを確認できます。 互換性検証が成功した場合、サービスを中断することなく、アプリケーションをターゲットデータベースに切り替えることができます。
ジオディザスタリカバリ
送信モード: データ同期
アプリケーションが単一のリージョン内にデプロイされている場合、停電やネットワーク障害などの不可抗力要因によりサービスが中断される可能性があります。
その場合、別のリージョンにディザスタリカバリセンターを設定して、サービスの可用性を向上させることができます。 DTSは、2つのリージョン間でデータとレプリカを同期します。 アプリケーションのプライマリリージョンで障害が発生した場合は、ディザスタリカバリリージョンの機能を利用してユーザーリクエストを処理できます。
アクティブなgeo冗長性
ビジネスが成長するにつれて、ビジネスを単一のリージョンに展開すると、次の問題が発生する可能性があります。
- ユーザは、広範囲の地理的位置にわたって分散され、遠隔ユーザは、高いアクセス待ち時間を有する。 これは、ユーザ体験を損なう。
- ビジネススケーラビリティは、電源やネットワーク帯域幅など、単一のリージョンのインフラストラクチャの容量によって制限されます。
これらの問題を解決するには、同じ都市または異なる都市に複数のビジネスユニットを構築します。 DTSは、ビジネスユニット間の双方向リアルタイムデータ同期を可能にし、グローバルデータの一貫性を確保します。 ビジネスユニットで障害が発生した場合は、別のビジネスユニットに切り替えることができます。 この方法で、サービスは数秒以内に回復できます。 これにより、サービスの高可用性を確保できます。
特定のディメンションに基づいて、ビジネスユニット全体にトラフィックを分散することもできます。 たとえば、ユーザーが最も近いノードにアクセスできるように、各ビジネスユニットのトラフィックをリージョンごとに再スケジュールできます。 これにより、ネットワーク遅延が削減され、ユーザーエクスペリエンスが向上します。 さらに、ビジネスユニットは異なるリージョンに分散されているため、ビジネススケーラビリティは単一のリージョンのインフラストラクチャの容量によって制限されなくなりました。
簡単に構築されたカスタムBIシステム
送信モード: データ同期
自己管理型のビジネスインテリジェンス (BI) システムは、リアルタイム機能の要件の増加を満たすことができません。 Alibaba Cloudは包括的なBIシステムを提供します。 DTSを使用すると、自己管理データベースからMaxComputeなどのBI分析をサポートするAlibaba Cloudストレージシステムにデータをリアルタイムで同期できます。. これにより、Alibaba Cloudでのビジネス要件を満たすカスタムBIシステムを迅速に構築できます。
リアルタイムデータ分析
伝送モード: 変更トラッキング
データ分析により、企業はビジネスに関する洞察を得て、ユーザーエクスペリエンスを向上させます。 リアルタイムデータ分析により、企業は変化する市場動向や顧客の要求に応じてマーケティング戦略を調整できます。
DTSは変更追跡機能を提供します。 オンラインビジネスに影響を与えることなく、アプリケーションの増分データをリアルタイムで追跡できます。 さらに、DTS SDKを使用して、追跡された増分データを分析システムに同期させ、リアルタイム分析することもできます。
軽量キャッシュ更新ポリシー
伝送モード: 変更トラッキング
アクセスを高速化し、同時読み取りパフォーマンスを向上させるために、ビジネスアーキテクチャではすべての読み取り要求を受け取るようにキャッシュ層が設計されています。 キャッシュ層のメモリ読み出し機構は、読み出し性能を改善することができる。 キャッシュメモリ内のデータは永続的ではない。 キャッシュメモリに障害が発生すると、キャッシュメモリのデータ損失が発生する。
DTSは変更追跡機能を提供します。 この機能は、データベース内の増分データを非同期で追跡し、キャッシュされたデータを更新するのに役立ちます。 これにより、軽量キャッシュ更新ポリシーを実装できます。
このアーキテクチャには次の利点があります。
- 低レイテンシでのクイックアップデート
データの更新が完了すると、更新されたデータが返されます。 このため、キャッシュの無効化プロセスを考慮する必要はありません。 更新プロセス全体は、低遅延で迅速です。
- 簡単に実装
DTSを使用してこのアーキテクチャを実装する場合、ダブルライトロジックは必要ありません。 増分データを追跡し、キャッシュされたデータを更新するには、非同期スレッドを起動するだけです。
- パフォーマンス低下のないキャッシュデータ更新
DTSは、データベース内の増分ログを解析して増分データを追跡します。 これは、ビジネスやデータベースには影響しません。
ビジネスデカップリング
伝送モード: 変更トラッキング
電子商取引業界には、注文、在庫、物流など、多くの種類のビジネスロジックが含まれています。 これらすべてのタイプのビジネスロジックが注文プロセスに含まれている場合、ビジネスロジックのすべての変更が完了するまで注文結果は返されません。 その結果、以下のような問題が発生する可能性があります。
- 注文プロセスには長い時間がかかり、ユーザーエクスペリエンスが低下します。
- 各ダウンストリーム障害がサービス可用性に影響するため、ビジネスシステムは不安定です。
ユーザーエクスペリエンスとサービスパフォーマンスを向上させるために、DTSの変更追跡機能を使用して、さまざまな種類のビジネスロジックを分離できます。 これは、リアルタイムの通知と、異なるタイプのビジネスロジック間の非同期通信によって実現されます。 これにより、ビジネスロジックがシンプルで信頼できるものになります。 次の図は、ビジネスデカップリングのアーキテクチャを示しています。
このシナリオでは、注文システムは、買い手が注文を出した後に結果を返す。 下層は、変更追跡機能を使用することによって、注文システムで生成されたデータ変更をリアルタイムで取得します。 DTS SDKを使用して、これらのデータ変更を追跡し、在庫やロジスティクスなどのさまざまなタイプの下流ビジネスロジックをトリガーできます。 これにより、ビジネスシステム全体がシンプルで信頼できるものになります。
このシナリオは、Alibaba Groupの幅広いビジネスに適用されています。 淘宝網注文システムの何万もの下流企業が、変更追跡機能を使用してリアルタイムのデータ変更を追跡し、ビジネスロジックをトリガーしています。
スケーラブルな読み取り機能
送信モード: データ同期
単一のデータベースインスタンスには、多数の読み取り要求を処理するのに十分なリソースがない場合があります。 DTSのリアルタイムデータ同期機能を使用して、読み取り専用インスタンスを作成し、これらの読み取り専用インスタンスに読み取り要求を分散できます。 これにより、読み取り機能をスケールアウトし、プライマリデータベースインスタンスの負荷を軽減できます。
データウェアハウスのタスクスケジューリング
送信モード: データ移行
大量のトランザクションデータを毎日処理する大規模なオンラインアプリケーションがある場合は、定期的にデータをデータウェアハウスに移行することをお勧めします。 たとえば、オフピーク時にデータ移行を実行して、前日のトランザクションデータをデータウェアハウスに移行することができます。 この場合、DTSのデータ移行機能を使用できます。これは、このシナリオに最適です。