MySQL 덤프에서 AWS RDS 인스턴스의 크기를 어떻게 계산합니까?

MySQL 덤프에서 AWS RDS 인스턴스의 크기를 어떻게 계산합니까?

mysqldump에서 대규모 기록 데이터베이스를 RDS로 가져오고 있습니다.

gzip으로 압축된 sql 파일은 3GB, 압축되지 않은 sql 파일은 18GB입니다.

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 덕분에 카디널리티 및 스토리지 크기에 대한 내 주장은 스토리지 엔진에 따라 다르다고 말했어야 했습니다.

예를 들어 3개의 열로 구성된 2176개의 행과 VARCHAR(32) 열에 하나의 인덱스가 있는 두 개의 InnoDB 테이블이 있는 데이터베이스를 예로 들 수 있습니다. 두 테이블의 데이터에서 유일한 차이점은 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 데이터 저장소에는 2가지 구성 요소가 있습니다. 기본적으로 mysql 데이터 디렉터리의 전역 테이블 공간 파일인 ibdata1에 저장되는 데이터 사전과 데이터 디렉터리의 하위 디렉터리에 있는 .frm 파일에 저장되는 테이블 데이터입니다. .

이것이 바로 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

이것이 좀 더 설명되기를 바랍니다.

관련 정보