Как рассчитать размер экземпляра AWS RDS из дампа MySQL?

Как рассчитать размер экземпляра AWS RDS из дампа MySQL?

Мы импортируем большую историческую базу данных в RDS из mysqldump

Размер сжатого SQL-файла составил 3 ГБ, размер несжатого SQL-файла — 18 ГБ.

Мы создали экземпляр AWS RDS объемом 30 ГБ и импортировали файл... на экземпляре RDS закончилось место.

Мы создали экземпляр AWS RDS объемом 50 ГБ, импортировали файл... на экземпляре RDS закончилось место.

Как рассчитать размер экземпляра AWS RDS, необходимого для импорта этого дампа?

Чтобы попытаться заранее ответить на любые вопросы...

  • У нас нет доступа к машине, с которой поступил этот сброс, чтобы попытаться определить его размер таким образом.
  • Я думал, что это, возможно, двоичные журналы RDS или медленные журналы занимают место, но, посмотрев на фактический размер базы данных ранее, я понял, что на самом деле все это находится в базе данных...
    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) с большим количеством уникальных комбинаций (высокая кардинальность) займет больше места для хранения, чем столбец с низкой кардинальностью для того же размера таблицы, потому что ключи в карте занимают больше места для хранения, чем указатели данных в карте.

ОБНОВЛЕНИЕ: спасибо Майклу ниже. Мне, конечно, следовало сказать, что мое утверждение о мощности и размере хранилища зависит от подсистемы хранения.

Например, база данных с двумя таблицами InnoDB, обе с 2176 строками по 3 столбца и одним индексом по столбцу VARCHAR(32). Единственное различие в данных для двух таблиц заключается в том, что tt1 имеет 2176 уникальных значений для столбца VARCHAR, а tt2 имеет идентичное значение для столбца VARCHAR.

Вы увидите, что размер индекса отличается всего на 16 КБ:

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 компонентов: словаря данных, который по умолчанию хранится в файле глобального табличного пространства ibdata1 в каталоге данных mysql, и табличных данных, которые хранятся в файлах .frm в подкаталоге каталога данных.

Вот почему, Майкл, вы не видите разницы в размере хранилища файлов .frm. Если бы вы перезапустили MySQL с помощью директивы innodb_file_per_table=1, вы бы увидели эту разницу, отраженную в файлах табличного пространства:

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

Надеюсь, это немного прояснит ситуацию.

Связанный контент