☰

Como calcular o tamanho de uma instância AWS RDS a partir de um dump MySQL?

tag-icon • tag-icon amazon-web-services mysql amazon-rds
Como calcular o tamanho de uma instância AWS RDS a partir de um dump MySQL?

Estamos importando um grande banco de dados histórico para o RDS a partir de um mysqldump

O arquivo sql gzipado tinha 3 GB, o arquivo sql descompactado tinha 18 GB.

Criamos uma instância AWS RDS de 30 GB e importamos o arquivo... a instância RDS ficou sem espaço.

Criamos uma instância AWS RDS de 50 GB, importamos o arquivo... a instância RDS ficou sem espaço.

Como calculo o tamanho da instância do AWS RDS necessária para importar esse dump?

Para tentar responder previamente a quaisquer perguntas...

  • Não temos acesso à máquina de onde veio o despejo para tentar dimensioná-lo dessa forma.
  • Achei que talvez fossem logs binários RDS ou logs lentos que estavam ocupando espaço, mas observar o tamanho real do banco de dados anteriormente mostrou que estava tudo no banco de dados ... 
    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)

Responder1

Não é possível estimar o armazenamento necessário para o banco de dados ativo sem saber nada sobre os índices em uso. Cada índice é essencialmente um mapa e quanto mais "chaves" houver no mapa, mais espaço de armazenamento será necessário para esse mapa.

A cardinalidade do índice (a "forma" dos dados, essencialmente o número de "chaves" exclusivas e como elas são mapeadas para as linhas que contêm essa chave) também se torna importante se o tipo de dados da coluna indexada for algo maior que um bigint. Uma coluna indexada de varchar(60) com muitas combinações únicas (alta cardinalidade) ocupará mais espaço de armazenamento do que uma com baixa cardinalidade para o mesmo tamanho de tabela porque as chaves no mapa ocupam mais espaço de armazenamento do que os ponteiros de dados no mapa.

ATUALIZAÇÃO: graças a Michael abaixo, eu deveria ter dito que minha afirmação sobre cardinalidade e tamanho de armazenamento depende do mecanismo de armazenamento.

Por exemplo, um banco de dados com duas tabelas InnoDB, ambas com 2.176 linhas de 3 colunas e um índice em uma coluna VARCHAR(32). A única diferença nos dados das 2 tabelas é que tt1 possui 2.176 valores exclusivos para a coluna VARCHAR e tt2 possui um valor idêntico para a coluna VARCHAR.

Você verá que o tamanho do índice difere em apenas 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 |
+------------+------------+-------------+--------------+

Observe que o armazenamento de dados InnoDB possui 2 componentes: um dicionário de dados que é armazenado por padrão no arquivo de espaço de tabela global, ibdata1, no diretório de dados mysql, e os dados da tabela que são armazenados em arquivos .frm em um subdiretório do diretório de dados .

É por isso, Michael, que você não vê diferença no tamanho de armazenamento dos arquivos .frm. Se você reiniciasse o MySQL usando a diretiva innodb_file_per_table=1 você veria esta diferença refletida nos arquivos do espaço de tabela:

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

O armazenamento InnoDB é único porque os dados da tabela são efetivamente um índice do dicionário de dados, trazendo alguns benefícios de desempenho para algumas operações. Portanto, o efeito da cardinalidade nos requisitos de armazenamento (cerca de 10% neste caso) é muito diferente de um 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

Espero que isso explique um pouco mais.

informação relacionada