HCIP学習ノート-データベースサービス計画-5

1. データベースサービスの概要

1.1 データベースの開発動向

画像.png

  • データの規模は爆発的に増大しており、データの活用形態は常に充実しています。クラウド コンピューティングの大規模な適用により、従来のビジネス モデルは変化しました。

1.2 クラウドデータベースのメリット

画像.png

  • 従来のデータベースと比較して、クラウド データベースには一般に次の利点があります。
    • 使いやすさ: クラウド データベースは通常、クラウド サービスとして提供され、他のクラウド サービスと同様に、迅速に展開して実行でき、通常は運用とメンテナンスの必要がありません。
    • 高い拡張性: オープン アーキテクチャとクラウド コンピューティングとストレージが分離された環境に基づいてクラウド環境向けに設計されており、拡張性がより強力です。
    • 低コスト: 従来の旧式のデータベースと比較して、ソフトウェアとハ​​ードウェアのコストが低く、従量制のクラウド サービスやオンデマンドのアンチブロードキャスティングなどの他の機能により、総所有コストも低くなります。

1.3 データベースの分類: SQL と NoSQL

画像.png

  • リレーショナル データベース: リレーショナル モデルを使用してデータを編成するデータベース。リレーショナル モデルは 2 次元のテーブル モデルを指し、リレーショナル データベースは 2 次元のテーブルとそれらの間の接続で構成されるデータ組織です。
  • 非リレーショナル データベース: 非リレーショナルで分散型のデータ ストレージ システムを指し、一般に ACID 原則への準拠を保証しません。
  • 一般的な製品:
    • リレーショナル データベース: SQL Server、MySQL、PostgreSQL。
    • 非リレーショナル データベース: Redis、Memcached、MongoDB。

1.4 HUAWEI CLOUD データベースのパノラマ

画像.png

  • データベースは、リレーショナル データベースと非リレーショナル データベースに分けられます。
  • リレーショナル データベース: RDS for MySQL、RDS for PostgreSQL、RDS for SQL Server、GaussDB (openGauss 用)、GaussDB (MySQL 用)。
  • 非リレーショナル データベース: GaussDB (Mongo 用)、GaussDB (Cassandra 用)、GaussDB (Redis 用)、GaussDB (Influx 用)、DDS、DCS。
  • データベース エコロジカル サービスには主に、DDM、DRS、UGO が含まれます。分散データベース ミドルウェア DDM 分散データベース ミドルウェア (略して DDM) は、分散データベース拡張の問題の解決に焦点を当て、従来のデータベースの容量とパフォーマンスのボトルネックを打破し、大量のデータへの高い同時アクセスを実現します。
  • DDMは、HUAWEI CLOUDが独自に開発したクラウドネイティブの分散データベースミドルウェアで、ストレージコンピューティング分離アーキテクチャを採用し、サブデータベースとサブテーブル、読み書き分離、柔軟な拡張などの機能を提供し、安定性と信頼性を備えています。拡張性が高く、継続的な運用と保守が可能です。サーバー クラスタの管理はユーザーに対して完全に透過的であり、ユーザーは DDM 管理コンソールを通じてデータベースの運用とメンテナンス、データの読み取りと書き込みを実行でき、従来のスタンドアロン データベースと同様のエクスペリエンスを提供します。
  • 製品の利点: データベースとテーブルの自動分割、読み取りと書き込みの分離、柔軟な拡張。

2. クラウド上のデータベースサービスの比較と選択

2.1 リレーショナルデータベースサービス

2.1.1 クラウド上の SQL 設計原則

画像.png

  • シーン紹介:
    • 小規模システム、周辺アプリケーション: 100,000 レベルの QPS、小規模 OLTP、データ量数十から数百 GB。
    • エンタープライズレベルのアプリケーション: 百万レベルのQPS、中規模のOLTP、TB〜数十TBのデータ量。
    • コアの高同時実行ビジネス システム: 超大規模 OLTP、混合負荷、ネイティブ分散、10 TB 以上。

2.1.1.1 RDS 用の ApsaraDB

画像.png

  • 安全性:
    • ApsaraDB for RDS インスタンスは、テナントから独立した仮想プライベート クラウドで実行されるため、ApsaraDB for RDS インスタンスのセキュリティが向上します。ユーザーは、サブネットとセキュリティ グループの構成を包括的に使用して、RDS インスタンスの ApsaraDB の分離を完了できます。
  • アクセス制御:
    • ApsaraDB for RDS インスタンスを作成するとき、ApsaraDB for RDS サービスはテナントのデータベース マスター アカウントを同期的に作成し、必要に応じてデータベース インスタンスとデータベース サブアカウントを作成し、データベース オブジェクトをデータベース サブアカウントに割り当てます。これにより、権限を分離する目的。
  • 送信暗号化:
    • サービス コンソールからダウンロードした CA ルート証明書を使用し、データベースに接続するときに証明書を提供してデータベース サーバーを認証し、暗号化された送信の目的を達成します。
  • ストレージの暗号化:
    • ApsaraDB for RDS サービスは、データベースに保存されたデータの暗号化されたストレージをサポートしており、暗号化キーはデータ ゼロ暗号化サービスの KMS によって管理されます。
  • データの削除:
    • 安全な削除には、データベース インスタンスに接続されているディスクだけでなく、自動バックアップ データ用のストレージ領域も含まれます。削除されたインスタンスは、保持されている手動バックアップを通じてインスタンス データを復元するか、ごみ箱の保持期間内にインスタンスを使用して、インスタンスを再構築してデータを復元します。

2.1.1.2 RDS サービスでサポートされるエンジン

画像.png

  • MySQL 用 RDS:
    • このアーキテクチャは成熟していて安定しており、一般的なアプリケーションをサポートし、複数の分野や業界に適しており、低コストでさまざまな WEB アプリケーションをサポートしており、中小企業にとっての最初の選択肢です。
    • 管理コンソールは、使いやすく、管理が柔軟で、可視化および制御可能な包括的な監視情報を提供します。
    • ビジネス状況に応じて必要なリソースをいつでも柔軟に拡張および縮小し、オンデマンドで支出し、オーダーメイドで対応します。
  • RDS for PostgreSQL
    • postgis プラグインをサポートし、優れた空間アプリケーションを実現します。
    • 豊富なアプリケーションシナリオと低コストで、ビジネス状況に応じて必要なリソースをいつでも柔軟に拡張でき、オンデマンドでhw35802903を開いてカスタマイズできます。
  • SQL サーバー用 RDS:
    • ApsaraDB for RDS for SQL Server は、安定性、信頼性、安全な操作、柔軟なスケーリング、容易な管理、経済的で実用的な機能という特徴を備えています。高可用性アーキテクチャ、データのセキュリティ保証、障害時の第 2 レベルのリカバリ機能を備え、柔軟なバックアップ ソリューションを提供します。

2.1.2 RDS for MySQL の ApsaraDB

画像.png

  • データベースの種類とバージョン: MySQL 5.6、5.7、8.0。
  • データ セキュリティ: 複数のセキュリティ ポリシーがデータベースとユーザーのプライバシーを保護します。
  • 高いデータ信頼性: データベース ストレージは 3 つ以上のコピーをサポートします。
  • データベース データの信頼性は 99.9999999% (9 9 秒) と高く、バックアップ データの信頼性も 99.999999999% (11 9 秒) と高くなります。
  • サービスの高可用性 (同じ都市での災害復旧): プライマリ インスタンスとバックアップ インスタンスは、99.95% 以上の高いサービス可用性により、AZ 内または AZ 間での展開をサポートします。
  • インスタンス アクセス: イントラネット IP アクセス、パブリック ネットワーク IP アクセス、VPN アクセスなどの複数のアクセス方法
  • インスタンス管理: インスタンスの追加、削除、変更、確認、再起動などのライフサイクル管理をサポートします。
  • 柔軟なスケーリング: 水平スケーリング、読み取り専用インスタンス (最大 5 つ) の追加と削除、垂直スケーリング、インスタンス仕様の変更、ストレージ容量の拡張 (最大 10 TB)。
  • バックアップとリカバリ: バックアップ、自動バックアップ、手動バックアップ、完全バックアップ、増分バックアップ、バックアップ ファイルの追加、削除、コピー、その他のライフサイクル管理。リカバリ、バックアップ保持期間内の任意の時点へのリカバリ (PITR と呼ばれるポイントインタイム リカバリ) / 完全バックアップ時点へのリカバリ、新しいインスタンス / 元のインスタンスへのリカバリ。バックアップの保持期間は最大 732 日です。

2.1.2.1 クロス AZ 高可用性

画像.png

  • データベースを作成するとき、ユーザーはアクティブ/スタンバイ モードでインスタンス タイプを選択できます。メイン データベースに障害が発生すると、自動的にスタンバイ データベースに切り替わり、外部サービスの提供を継続します。スタンバイ データベースにも障害が発生すると、別のアベイラビリティ ゾーンにあるプライマリ データベースとスタンバイ データベースに自動的にアクセスして、外部サービスを提供します。
  • DDM と組み合わせると、RDS は最大 5 つの読み取り専用レプリカの作成をサポートできます。マスターとバックアップはデータの書き込みを完了し、読み取り専用レプリカはデータの読み取りのみを完了して、自動トラフィック セグメンテーションを実現します。
  • アクティブ/スタンバイ モードは、VIP (仮想 IP) を外部に提供します。VIP がデータベース 1 にバインドされている場合、データベースはメイン データベースです。メイン データベースに障害が発生すると、VIP はスタンバイ データベースにフローティングされ、スタンバイ データベースはスタンバイ データベースに移動します。データベースはこの時点で新しいものになります。メインライブラリ。VIP の内部ドリフトは数秒で完了でき、サービスは常に外部から提供されます。ユーザー側はまったく気づいていません。
  • 制限事項: ユーザーはデータベースを購入した後、読み取り専用レプリカのみを作成できます。

2.1.2.2 読み取りと書き込みの分離

画像.png

  • 読み取り専用レプリカを作成した後、データベースが外部サービスを提供する場合、まずユーザー側からのリクエストを区別して、リクエストの種類がデータの書き込みであるかデータの読み取りであるかを判断します。データを書き込む場合、リクエストをルーティングするマスター データベースとスタンバイ データベースはデータ書き込み操作を完了します。読み取りデータの場合は、要求を読み取り専用レプリカにルーティングして、データの読み取りを完了します。

2.1.2.3 高いデータセキュリティ

画像.png

  • この自動バックアップを保持するためのカスタム構成をサポートする日数 (つまり、バックアップ保持期間、値は 0 ~ 732)

2.1.2.4 カーネルの最適化

画像.png

2.1.2.5 ケース

画像.png

2.1.3 PostgreSQL 用 RDS 用の ApsaraDB

画像.png

  • データベース: 9.5/9.6/10.0/11/12 バージョンのサポートを提供します。
  • セキュリティ: 複数のセキュリティ ポリシーがデータベースとユーザーのプライバシーを保護します。
  • データ移行: クラウドオン/クラウド間、クラウド間のオンライン移行とオフライン移行をサポートします。
  • 高可用性: プライマリ データベース インスタンスのデータをスタンバイ データベース インスタンスにコピーします。プライマリ データベース インスタンスに障害が発生して使用できなくなった場合は、短時間でスタンバイ データベース インスタンスに切り替えることができます。
  • モニタリング: コンピューティング/メモリ/ストレージ容量の使用状況、I/O アクティビティ、データベース接続数、QPS/TPS、バッファ プール、読み取り/書き込みアクティビティなどを含む、データベース インスタンスとデータベース エンジンの主要パフォーマンス指標のモニタリングをサポートします。
  • 柔軟なスケーリング: ビジネスを中断することなく、水平スケーリング、読み取り専用インスタンスの追加と削除 (データベース クラスターあたり最大 5 つの読み取り専用インスタンス)、垂直スケーリング、データベース インスタンス仕様の変更、ワンクリックの拡張。
  • バックアップと復元: バックアップ、自動バックアップのサポート、手動データ バックアップ、復元、バックアップ ファイル ポイントへの復元のサポート。

2.1.3.1 高信頼性と高可用性

画像.png

  • PG はクロス AZ 高可用性をサポートします。メイン ライブラリに障害が発生した場合、3 回障害検出を開始してプルアップします。プルアップできない場合は、自動的にフェイルオーバーします。メイン ライブラリはスタンバイ ライブラリに切り替わります。新しいメイン ライブラリに自動的にリンクされ、この切り替えは第 2 レベルで行われます。
  • HUAWEI CLOUD データベースは、データのバックアップと復元機能を提供します。ユーザーは自動バックアップ ポリシーを設定し、毎日の自動バックアップをサポートできます。バックアップ サイクルは最大 732 日です。同時に、データの信頼性を確保するために、増分バックアップが 5 分ごとに実行されます。
  • データに異常がある場合や誤って削除された場合など、データベースを以前の時点に復元することができます。
  • バックアップ ファイルは OBS に保存されますが、OBS 自体にはオンラインにする能力がないため、9 段階中 11 のデータ信頼性が提供されます。

2.1.4 データベースの選択

画像.png

2.1.5 データベースの比較

画像.png

  • 説明: 色の類似性は適合度を表します。ここでは青が使用されており、pg と mysql がほとんどのシナリオで使用できることを示しています。
    • 一部のゲーム会社やインターネット会社など、データベースの使用度やアーキテクチャ設計の習慣により、データベースをデータ ストレージ ツール 5 としてのみ捉えており、これは「軽いデータベースと重いアプリケーション モード」です。この場合、PG は両方ともMySQL も利用可能ですが、データベースの特性に依存する機能が多いため、PG を使用することを推奨します データベースミドルウェアは基本的なソフトウェアであり、安定性と信頼性が高く、オープンソースデータベースは自律的で制御可能であるため、PG を選択するのが合理的ですそのような基本的なソフトウェアに依存すること
    • 純粋にトランザクションのみを行うビジネスですか、それともトランザクション分析と混合するビジネスですか? 前者の場合は会社本来の習慣に従い、後者の場合は PG の使用をお勧めします。PG の分析機能は非常に優れています。
    • 多くのストアド プロシージャを使用する場合は、PG を使用することをお勧めします。それ以外の場合は、会社の習慣に従ってください。
    • 異種データベースへのアクセスが必要な場合は、PG を使用することをお勧めします。PG は、ユーザーが SQL を介して PG の外部のデータにアクセスできるようにする、Foreign DataWrapper を提供します。
    • 複雑な型を使用する場合は、PG を使用することをお勧めします。PG 配列、空間データ型、ネットワーク データ型 JSON、XML などは非常に成熟しており、カスタマイズをサポートしています
  • 地理情報、空間、異種データベース アクセス、機械学習、テキスト検索、画像、時系列、多次元、単語セグメンテーションなどの要件があり、新しい特殊なデータベースを導入したくない場合は、PG をお勧めします。

2.1.6 ケース

画像.png

2.1.7 GaussDB 用 ApsaraDB (MySQL 用)

画像.png

  • 共有 DFV ストレージ:
    • 保存されるコピーは 1 つだけです。読み取り専用ノードを追加する場合、コンピューティング ノードを追加するだけでよく、追加のストレージを購入する必要はありません。読み取り専用ノードの数が増えると、より多くのストレージ コストを節約できます。
  • アクティブ-アクティブ アーキテクチャ:
    • スタンバイ データベースはなくなり、すべての読み取り専用データベースがアクティブ状態になり、読み取りトラフィックが発生するため、リソースの使用率が高くなります。
  • データ アーキテクチャとしてのログ:
    • ページを更新する必要はなくなり、すべての更新操作はログに記録されるだけで、二重書き込みも必要なくなりました。貴重なネットワーク帯域幅が減少します。

2.1.7.1 並列実行

画像.png

  • 100G データ量の 32 コア 256GB テスト TPCH クエリ ステートメント。16 スレッドの同時シナリオでパフォーマンスが 8 倍向上

2.1.7.2 水平方向の拡張

画像.png

  • GaussDB (MySQL 用) の読み取りおよび書き込みパフォーマンスの線形拡張:
    • ノード数を増やした場合、最下層でDFV分散ストレージを使用するため、新たに追加したノード用にストレージを再分割し、他のノードと共有する必要がありません。ブロックストレージ

2.1.7.3 効率的なバックアップ

画像.png

  • 従来のデータベース障害復旧と比較して、GaussDB (MySQL 用) は一部のデータを段階的に復元し、すべてのデータが復元されるまでデータ復元時に外部サービスを提供します。ただし、従来のデータベースは、すべてが復元された後でのみ外部サービスを提供します。

2.1.7.4 ケース

画像.png

2.1.8 GaussDB 用 ApsaraDB (openGauss 用)

画像.png

  • 高いセキュリティ:
    • GaussDB (openGauss 用) には、データの動的感度解除 TDE 透過暗号化、行レベルのアクセス制御、暗号化コンピューティングなど、トップレベルの商用データベース セキュリティ機能があります。政府、企業、金融顧客の中核となるセキュリティ要件を満たすことができます。
  • サウンドツールとサービス機能:
    • GaussDB (openGauss 用) には、HUAWEI CLOUD Stack の商用サービス展開機能である HUAWEI CLOUD がすでに組み込まれており、DAS、wUGO、DRS などのエコロジー ツールも備えています。開発、運用保守、最適化、監視、移行などのユーザーの日常業務ニーズを効果的に保証します。
  • フルスタックの自社開発:
    • GaussDB (openGauss 用) は Peng エコロジーに基づいており、現在フルスタックの独立した制御性を実現できる唯一の国内ブランドであると同時に、GaussDB (openGauss 用) はハードウェアの利点に基づいて最下層を継続的に最適化し、改善を図ることができます。製品の全体的なパフォーマンス。
  • オープンソースのエコロジー:
    • GaussDB (openGauss 用) はすでにオープン ソース コミュニティをサポートしており、メイン バージョンとバックアップ バージョンのダウンロードを提供しています。

2.1.8.1 主要な役割

画像.png

  • etcd: 整合性コンポーネント
  • CMS: クラスタ管理、アクティブおよびスタンバイ切り替え制御、高可用性関連

2.1.8.2 高性能 - 分散並列実行フレームワーク

画像.png

2.1.9 高性能 - 分散トランザクション処理パフォーマンス、GTM-Lite テクノロジー

画像.png

2.1.9.1 事例: GaussDB はスマートなビジネス運営を支援します

画像.png

2.2 非リレーショナル データベース サービス

2.2.1 クラウド上の NoSQL 設計原則

画像.png

2.2.2 文書データベースサービスDDS

画像.png

  • データベースの種類とバージョン: MongoDB 4.0/4.2 バージョンと互換性があります。
  • データ セキュリティ: 複数のセキュリティ ポリシーがデータベースとユーザーのプライバシーを保護します。高いデータ信頼性: データベース ストレージは 3 つ以上のコピーをサポートし、データベース データの信頼性は 99.9999999% (9 ナイン) に達し、バックアップ データの永続性は 99.9999999999% (12 ナイン) と高くなります。
  • サービスの高可用性 (同じ都市での災害復旧): クラスター/レプリカ セット インスタンスは、AZ 内または 3 AZ にわたる展開をサポートしており、サービスの可用性は 99.95% 以上です。
  • インスタンスの監視: コンピューティング/メモリ/ストレージ容量の使用率、I/O アクティビティ、データベース接続などを含む、データベース インスタンス OS と DB エンジンの主要パフォーマンス指標の監視をサポートします。
  • 柔軟なスケーリング: 水平スケーリング、シャード フラグメントの追加と削除 (最大 32)、7 ノードのレプリカ セットのサポート、読み取り専用ノードのサポート、垂直スケーリング、インスタンス仕様の変更、ストレージ スペースの拡張 (最大 32*2TB)。
  • バックアップとリカバリ: バックアップ、自動バックアップ、手動バックアップ、完全バックアップ、増分バックアップ、バックアップ ファイルの追加、削除、コピーおよびその他のライフ サイクル管理、リカバリ、バックアップ保持期間 (Point-ln -Time) の任意の時点へのリカバリのサポートリカバリ、PITR)/完全バックアップ時点、新しいインスタンス/元のインスタンスへの復元。バックアップの保持期間は最大 732 日です。

2.2.3 高い信頼性 - 中断のないオンライン拡張、ストレージの 3 つのコピー

画像.png

2.2.4 高い信頼性 - データのアーカイブ、バックアップ、リカバリ

画像.png

2.2.5 クロスアベイラビリティーゾーンのバックアップ - バックアップはリージョン間でレプリケートされ、異なる場所に復元できます。

画像.png

2.2.6 クロスアベイラビリティゾーンディザスタリカバリ - クロスリージョンのリアルタイムディザスタリカバリとリアルタイムデータ同期

画像.png

2.2.7 事例: ゲーム業界の支援

画像.png

  • ゲームシーン
  • ゲーム アプリケーションでは、ゲーム プレーヤーのアクティビティのピーク時に、ユーザー機器やユーザー ポイントなどの一部のユーザー情報を DDS データベースに保存できますが、これには高い同時実行機能が必要です。DDS クラスター タイプを使用して、同時実行性の高いシナリオに対処できます。 。DDS レプリカ セットとクラスター アーキテクチャの高可用性機能により、同時実行性の高いシナリオでのゲームの継続的かつ安定した動作に対応できます。
  • さらに、DDS は MongoDB と互換性があり、No-Schema 方式を採用しているため、ゲーム プレイの変更時にテーブル構造を変更する手間を回避でき、柔軟で変更可能なゲーム ビジネス ニーズに非常に適しています。ユーザーは、固定スキーマの構造化データをクラウド データベース RDS に保存し、柔軟なスキーマを使用してビジネスを DDS に保存し、高熱データを GaussDB (Redis 用) に保存することで、ビジネス データへの効率的なアクセスを実現し、保存の入力コストを削減できます。データ。

2.2.8 GaussDB 用 ApsaraDB (NoSQL 用)

画像.png

  • 互換性のある Cassandra インターフェイス:
    • ワイドカラムデータモデルをサポート
    • 優れた書き込みパフォーマンス。IoT、金融不正行為検出、その他のシナリオに適しています。
  • MongoDB インターフェイスとの互換性:
    • ドキュメントデータモデルをサポートします。
    • 読み取りおよび書き込みのパフォーマンス、感度、信頼性において優れた利点があります。
  • Redis インターフェースとの互換性:
    • コンピューティングとストレージを分離するクラウド上初の Redis データベース製品。
    • データの信頼性、拡張性、コストパフォーマンスの面で優れた利点を持っています。
  • InfluxDBインターフェースと互換性があります。
    • 時系列データ用に設計されたクラスター アーキテクチャとデータ レイアウト
    • 高い書き込みパフォーマンスと高い圧縮率。

2.2.9 GaussDB 用 ApsaraDB (Redis 用)

画像.png

  • GaussDB (Redis 用) は、高いコストパフォーマンス、柔軟なスケーリング、ホットとコールドの分離という特徴を備えています。
  • 費用対効果が高い:
    • 共有ストレージをベースに、十分なパフォーマンスを提供することを前提として、大量のデータに Redis を使用するコストを大幅に削減します。
    • すべてのデータをディスクに格納し、ホットとコールドの分離を実現し、キャッシュ(キャッシュ)とデータベース(DB)間の対話型アクセスの問題を解決し、プログラムの可読性と操作効率を向上させます。
  • ロスレスの弾性スケーリング:
    • RocksDB の詳細なカスタマイズ、第 2 レベルの分割エラスティック拡張。
    • データを再配置することなく、拡大縮小と縮小が高速かつスムーズに行えます。
    • プロキシ エージェントを介すると、上位層のビジネスは、拡張および縮小プロセス中にデータ移行を処理するカーネルを認識できなくなります。
  • ホットとコールドの分離:
    • ホット データはメモリに常駐し、コールド データは完全に永続的に保存され、Redis+MySQL のホットとコールドの分離アーキテクチャを置き換えます。0 はホット データとコールド データの自動交換を実現し、ユーザーは手動でデータを交換する必要がなく、コード開発がより簡潔になります。

2.2.10 事例: エネルギー産業の支援

画像.png

  • GaussDB (Redis 用) は Redis インターフェイスと互換性がある一方で、大容量、低コスト、信頼性の高いデータ ストレージ機能も提供し、このような永続ストレージ シナリオの理想的なソリューションとして使用できます。

2.2.11 クラウドデータベース GaussDB (Mongo用)

画像.png

2.2.12 事例: ゲーム業界の支援

画像.png

  • ゲームシーン。
    • MongoDB プロトコルと互換性のあるゲーム アプリケーションは、ユーザーの機器、ユーザー ポイントなどの一部のゲーム データをその中に保存できます。ゲーム プレーヤーのアクティビティのピーク時には同時実行性の要件が高くなりますが、同時実行性の高いゲームに対処するためにコンピューティング ノードを迅速かつ柔軟に追加できます。

3. データベース移行計画

  • HUAWEI CLOUDデータベース移行総合ソリューション

画像.png

  • データベースの移行方法
  • データベースの移行は通常、UGO+DRS の組み合わせの形式で実装されます。ユーザーがデータベースをオフクラウドまたは他のクラウドベンダーからHUAWEI CLOUDに移行する場合、まずUGOツールを使用してソースデータベースを分析し、実際のシナリオに基づいてデータベースの移行を開始し、UGOツールが提供するソリューションを参照します。データレプリケーションサービスDRSは、フルデータ+増分マイグレーションの技術により、ソースデータベースからターゲットデータベースへのデータ移行を実現します。

3.1 データレプリケーションサービス DRS

画像.png

  • 操作が簡単:
    • 従来のシナリオでは、専門的な技術的背景が必要であり、手順が複雑で、技術的な敷居が比較的高い
  • 短いサイクル
    • 従来のシナリオでは、数日から先週または先月までの範囲で手動での展開が必要です
  • 低価格:
    • 従来のシナリオでは、投資が高額であり、ビジネスに対する需要に応じて柔軟に支払うことができません
  • リスクが低い
    • 従来のシナリオでは、業務の中断と手動による移行が必要であり、移行が失敗するとデータが失われるリスクがあります。

3.1.1 ライブマイグレーション

画像.png

  • リアルタイム移行は、パブリック ネットワーク、VPC ネットワーク、VPN ネットワーク、さまざまなネットワーク リンクを介したプライベート ネットワークなどの複数のネットワーク移行方法をサポートしており、クロスクラウド プラットフォームのデータベース移行、クラウドまたはクラウドへのオフクラウド データベースの移行を迅速に実現できます。データベース移行などのさまざまなビジネス シナリオのクロスリージョン移行

3.1.2 バックアップの移行

画像.png

3.1.3 リアルタイム同期

画像.png

3.1.4 データのサブスクリプション

画像.png

3.1.5 リアルタイムの災害復旧

画像.png

3.1.6 事例: 自動車産業の支援

画像.png

3.2 データベース移行ツール UGO

画像.png

  • このサービスは現在商用段階にあり、中国南部-広州およびアジア太平洋-シンガポール地域でのみ展開されています。

3.2.1 源库画像

画像.png

  • UGO コア コンピタンスのソース ライブラリのイメージ:
    • ソースライブラリプロファイルは、膨大なビジネスシナリオをサンプルとし、主要なデータベース指標を特性としてトレーニングを実施し、データベース情報の全体像を抽象化し、ソースライブラリのアプリケーションシナリオやユーザーの操作習慣などの重要な情報をより正確かつ迅速に分析します。十分なデータベース。

3.2.2 ターゲットタイプの選択と仕様

画像.png

  • UGO コア機能のターゲットの選択と仕様:
    • ソース ライブラリのイメージ入力、包括的な互換性、パフォーマンス、オブジェクトの複雑さ、使用シナリオなどに応じて、適切なターゲット ライブラリの種類の選択と優先順位、およびさまざまな選択の下での仕様とコストをインテリジェントに推奨します。

3.2.3 互換性分析

画像.png

  • UGOコアコンピタンスの互換性分析
    • ソース ライブラリのイメージを入力として受け取り、UGO カーネルからターゲット ライブラリへの変換率を使用して、14 のコア オブジェクト タイプの互換性分析を実行します。互換性分析には、ネイティブ サポート、UGO サポート、および非サポートが含まれます。過去数年間のカーネルの継続的な構築により、UGO は数億のサンプルを使用したトレーニングに基づいて高い文法変換率を達成することができました。

3.2.4 作業負荷の評価

画像.png

  • UGO コア コンピテンシーのワークロード評価:
    • 大規模なビジネス シナリオにおける実際の人的移行コストに基づいて、評価ベースラインとして、多数のビジネス シナリオの自動移行プロセスに基づいて、累積的な移行ワークロードが入力として使用され、コード量、変換率、およびデータと組み合わせられます。互換性のない機能変換の難易度など、移行ワークロードの評価を総合的に出力します。

3.2.5 データベース構造の移行

画像.png

  • UGO コア コンピタンスのデータベース構造の移行:
    • 構造的移行は、移行前の評価を入力およびプログラム ガイダンスとして受け取り、ユーザーが変換前に移行オブジェクトをカスタマイズおよびフィルタリングできるようにサポートします。変換後、変換に失敗したオブジェクトと失敗の理由をマークします。ユーザーは失敗の理由に従ってオブジェクトを修正し、後で検証テストを実行できます。検証に失敗したオブジェクトは修正ステップに戻って再修正され、すべてのオブジェクトが正常に検証され、移行実装プロセス全体が終了するまで検証のために送信され続けます。

3.2.6 SQL移行の適用

画像.png

3.2.7 事例: 通信業界の支援

画像.png

考える質問

画像.png
画像.png
画像.png

開花を終える

おすすめ

転載: blog.csdn.net/GoNewWay/article/details/130907209