mysqldumpから大規模な履歴データベースをRDSにインポートしています
gzip 圧縮された SQL ファイルは 3 GB で、非圧縮の SQL ファイルは 18 GB です。
30GB の AWS RDS インスタンスを作成し、ファイルをインポートしましたが、RDS インスタンスの容量が不足しました。
50GB の AWS RDS インスタンスを作成し、ファイルをインポートしましたが、RDS インスタンスの容量が不足しました。
このダンプをインポートするために必要な AWS RDS インスタンスのサイズを計算するにはどうすればよいですか?
質問に事前に答えるために...
- ダンプが作成されたマシンにアクセスできないため、そのようにサイズを決定できません。
- スペースを占有しているのは RDS バイナリ ログまたはスロー ログかもしれないと思いましたが、実際のデータベース サイズを確認すると、実際にはすべて DB 内にあることがわかりました...
mysql> SELECT table_schema "Database Name", sum( data_length + index_length ) / 1024 / 1024 "Database Size in MB" FROM information_schema.TABLES GROUP BY table_schema ; +--------------------+----------------------+ | Database Name | Database Size in MB | +--------------------+----------------------+ | xxxxxxxxxx | 41658.15374756 | | information_schema | 0.00976563 | | mysql | 5.96341228 | | performance_schema | 0.00000000 | +--------------------+----------------------+ 4 rows in set (28.39 sec)
答え1
使用中のインデックスについて何も知らなければ、ライブ データベースに必要なストレージを見積もることはできません。各インデックスは基本的にマップであり、マップの「キー」が増えるほど、そのマップに必要なストレージ スペースも増えます。
インデックスのカーディナリティ (データの「形状」、本質的には一意の「キー」の数と、そのキーを含む行にマップする方法) も、インデックス列のデータ型が bigint より大きい場合は重要になります。一意の組み合わせが多数ある (カーディナリティが高い) varchar(60) のインデックス列は、同じテーブル サイズの場合、カーディナリティが低い列よりも多くのストレージ スペースを占有します。これは、マップ内のキーがマップ内のデータ ポインターよりも多くのストレージ スペースを占有するためです。
更新: 下記の Michael に感謝します。カーディナリティとストレージ サイズに関する私の主張はストレージ エンジンに依存するということを当然言うべきでした。
たとえば、2 つの InnoDB テーブルを持つデータベースがあり、どちらも 3 列の 2176 行と、VARCHAR(32) 列の 1 つのインデックスがあるとします。2 つのテーブルのデータの唯一の違いは、tt1 には VARCHAR 列に 2176 個の一意の値があり、tt2 には VARCHAR 列に同一の値があることです。
インデックスのサイズが約 16kb しか違わないことがわかります。
mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_idb1';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1 | 2031 | 180224 | 147456 |
| tt2 | 2031 | 180224 | 131072 |
+------------+------------+-------------+--------------+
InnoDB データ ストレージには、デフォルトで mysql データ ディレクトリのグローバル テーブル スペース ファイル ibdata1 に保存されるデータ ディクショナリと、データ ディレクトリのサブディレクトリの .frm ファイルに保存されるテーブル データの 2 つのコンポーネントがあることに注意してください。
そのため、Michael さん、.frm ファイルのストレージ サイズに違いが見られません。innodb_file_per_table=1 ディレクティブを使用して MySQL を再起動すると、この違いがテーブル スペース ファイルに反映されます。
drwx------. 2 mysql mysql 4096 Dec 19 10:52 .
drwxr-xr-x. 4 mysql mysql 4096 Dec 19 10:52 ..
-rw-rw----. 1 mysql mysql 65 Dec 19 10:52 db.opt
-rw-rw----. 1 mysql mysql 8610 Dec 19 10:52 tt1.frm
-rw-rw----. 1 mysql mysql 393216 Dec 19 10:52 tt1.ibd
-rw-rw----. 1 mysql mysql 8610 Dec 19 10:52 tt2.frm
-rw-rw----. 1 mysql mysql 376832 Dec 19 10:52 tt2.ibd
InnoDB ストレージは、テーブル データが実質的にデータ ディクショナリのインデックスであり、一部の操作でパフォーマンス上の利点をもたらすという点で独特です。したがって、カーディナリティがストレージ要件に与える影響 (この例では約 10%) は、MyISAM とは大きく異なります。
mysql> select TABLE_NAME, TABLE_ROWS, DATA_LENGTH, INDEX_LENGTH from TABLES where TABLE_SCHEMA='t_msm';
+------------+------------+-------------+--------------+
| TABLE_NAME | TABLE_ROWS | DATA_LENGTH | INDEX_LENGTH |
+------------+------------+-------------+--------------+
| tt1 | 2126 | 85040 | 87040 |
| tt2 | 2126 | 85040 | 7168 |
+------------+------------+-------------+--------------+
drwx------. 2 mysql mysql 4096 Dec 19 09:50 .
drwxr-xr-x. 13 mysql mysql 4096 Dec 19 10:29 ..
-rw-rw----. 1 mysql mysql 65 Dec 19 09:28 db.opt
-rw-rw----. 1 mysql mysql 8610 Dec 19 09:31 tt1.frm
-rw-rw----. 1 mysql mysql 85040 Dec 19 09:48 tt1.MYD
-rw-rw----. 1 mysql mysql 87040 Dec 19 09:48 tt1.MYI
-rw-rw----. 1 mysql mysql 8610 Dec 19 09:50 tt2.frm
-rw-rw----. 1 mysql mysql 85040 Dec 19 09:51 tt2.MYD
-rw-rw----. 1 mysql mysql 7168 Dec 19 09:51 tt2.MYI
これでもう少し説明が深まったと思います。