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

Question

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

O arquivo sql gziped tem 3GB, o arquivo sql descompactado tem 18GB.

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

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

Como faço para calcular o tamanho da instância do AWS RDS de que preciso para importar esse despejo?

Para tentar responder a perguntas anteriores ...

• Não temos acesso à máquina da qual o despejo veio para tentar dimensionar dessa maneira.
• Eu pensei que talvez os logs binários do RDS ou logs lentos que estavam ocupando o espaço, mas olhando para o tamanho real do banco de dados anteriormente, mostrassem que tudo estava realmente 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)
  

Answer 1

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" do mapa, mais espaço de armazenamento é 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 linhas contendo essa chave) também se torna importante se o tipo de dados para a coluna indexada for maior que bigint. Uma coluna indexada de varchar (60) com muitas combinações exclusivas (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 que os ponteiros de dados no mapa. mapa.

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

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

Você verá que o tamanho do índice é diferente 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 |
+------------+------------+-------------+--------------+

Note 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 de o diretório de dados.

É por isso que, Michael, você não vê diferença no tamanho do armazenamento dos arquivos .frm. Se você fosse reiniciar o MySQL usando a diretiva innodb_file_per_table = 1, veria essa 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 do InnoDB é único, pois 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 (em torno 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.