このトピックでは、各DBSインスタンスタイプのパフォーマンスをよりよく理解するために、データベースバックアップ (DBS) バックアップスケジュールのバックアップおよび復元機能のパフォーマンステストについて説明します。
テスト結果は、インスタンスタイプ選択のガイドとして使用することを目的としており、サービスレベル契約の成果を評価するために使用することはできません。
テストの結果は、ビジネスシナリオによって異なります。
論理的なバックアップと復元
テスト手順
ApsaraDB RDS for MySQLインスタンスを準備します。
DBSコンソールで論理バックアップスケジュールを作成し、完全バックアップおよび増分バックアップタスクを開始して、ApsaraDB RDS for MySQLインスタンスからDBSにデータをバックアップします。
次に、バックアップデータをApsaraDB RDS for MySQLインスタンスに復元します。 この期間中のデータのバックアップと復元のパフォーマンスを確認してください。
テスト環境
項目 | 設定 |
データベースタイプ | 汎用ApsaraDB RDS for MySQL |
メモリ | 2,400M |
CPU | 8 vCPU |
IOPS | 1,200 |
テストデータ
テストデータ | 説明 | 例 |
データベースサイズ | テストデータベースの合計サイズ。 (単位：GB) | 102 GB |
エントリの総数 | テストデータベースのすべてのテーブルのエントリの総数。 | 0.15億 |
単一レコードサイズ | テストデータベース内の1つのレコードのサイズ。 (単位：KB) | 1〜100 KB |
フィールドの数 | テストデータベースのレコード内のフィールドまたは列の数。 | 3から22列 |
フィールドタイプ | テストデータベースのレコードのフィールドタイプ。 INT、VARCHAR、DATATIMEなどの基本的なMySQLフィールドタイプが含まれます。 | 基本的なMySQLフィールドタイプをオーバーライドします。 |
テスト結果
完全なデータバックアップ
インスタンスタイプ | RPS | Mbit/s |
大きい | 42,855.7 | 15.3 |
medium | 33,122.2 | 11.8 |
small | 9,569.3 | 3.4 |
マイクロ | 6,756.2 | 1.9 |
ソースデータベースに多数のテーブルが含まれている場合、バックアップおよび復元中にテーブルの初期化に時間がかかります。 10,000個以下のテーブルを含むソースデータベースを指定することを推奨します。
ソースデータベース内のテーブルにプライマリキーがない場合、テーブルのプライマリキーがString型である場合、またはテーブルが複合プライマリキーを使用している場合も、バックアッププロセスに時間がかかります。
増分バックアップ
インスタンスタイプ | Mbit/s |
大きい | 46.1 |
medium | 29.8 |
small | 14.9 |
マイクロ | 5.0 |
完全な修復
インスタンスタイプ | RPS |
大きい | 34,190.5 |
medium | 19,740.9 |
small | 9,949.4 |
マイクロ | 4,320.2 |
増分修復
インスタンスタイプ | インスタンスタイプ |
大きい | 35,546.9 |
medium | 21,331.4 |
small | 10,061.5 |
マイクロ | 4,972.1 |
物理的なバックアップと復元
テスト手順
自己管理型MySQLデータベースを準備します。
DBSコンソールで物理バックアップスケジュールを作成し、完全バックアップタスクを開始してデータベースからDBSにデータをバックアップします。
バックアップデータを指定したディレクトリにリストアします。 この期間中のデータのバックアップと復元のパフォーマンスを確認してください。
DBSは、ストリーミングモードでMySQLデータベースの物理ファイルを読み取り、複数のストリームを使用して内蔵ストレージにバックアップデータを同時に書き込みます。 DBSを使用すると、DBSの仕様に基づいて同時バックアップストリームの数を調整できます。 より高い仕様はより速いバックアップ速度を提供します。 圧縮アルゴリズムgzipとLZ4がサポートされています。 gzipはより高い圧縮率を提供し、LZ4はより速いバックアップ速度を提供します。
テストデータ
テストデータ | 説明 | 例 |
データベースサイズ | テストデータベースの合計サイズ。 (単位：GB) | 40.3 GB |
エントリの総数 | テストデータベースのすべてのテーブルのエントリの総数。 | 20 億 |
テーブル数 | テストデータベース内のテーブルの数。 | 160 |
単一レコードサイズ | テストデータベース内の1つのレコードのサイズ。 (単位：KB) | 0.2 KB |
テスト結果
完全なデータバックアップ
インスタンスタイプと圧縮形式 | 消費時間 | バックアップ速度 | 圧縮ファイルのサイズ |
小さい (4スレッド) gzip | 636s | 63 MB/s | 21.1 GB |
大きい (8スレッド) gzip | 341s | 118 MB/s | 21.1 GB |
xlarge (16スレッド) gzip | 204s | 197 MB/s | 21.1 GB |
小さい (4スレッド) LZ4 | 268s | 150 MB/s | 31.1 GB |
large (8スレッド) LZ4 | 119s | 338 MB/s | 31.1 GB |
xlarge (16スレッド) LZ4 | 104s | 387 MB/s | 31.1 GB |
完全な修復
インスタンスタイプと圧縮形式 | 圧缩データ量 | 消費時間 | 復元速度 (元のデータ量に対する相対) |
小さい (4スレッド) gzip | 21.1 GB | 320s | 126 MB/s |
大きい (8スレッド) gzip | 21.1 GB | 161s | 250 MB/s |
xlarge (16スレッド) gzip | 21.1 GB | 86s | 468 MB/s |
小さい (4スレッド) LZ4 | 31.1 GB | 408s | 99 MB/s |
large (8スレッド) LZ4 | 31.1 GB | 208s | 194 MB/s |
xlarge (16スレッド) LZ4 | 31.1 GB | 108s | 373 MB/s |