☰

¿Cómo calcular el tamaño de una instancia de AWS RDS a partir de un volcado de MySQL?

tag-icon • tag-icon amazon-web-services mysql amazon-rds
¿Cómo calcular el tamaño de una instancia de AWS RDS a partir de un volcado de MySQL?

Estamos importando una gran base de datos histórica a RDS desde un mysqldump

El archivo SQL comprimido con gzip tenía 3 GB, el archivo SQL sin comprimir tiene 18 GB.

Creamos una instancia de AWS RDS de 30 GB e importamos el archivo... la instancia de RDS se quedó sin espacio.

Creamos una instancia de AWS RDS de 50 GB, importamos el archivo... la instancia de RDS se quedó sin espacio.

¿Cómo calculo el tamaño de la instancia de AWS RDS que necesito para importar este volcado?

Para intentar responder previamente cualquier duda...

  • No tenemos acceso a la máquina de donde vino el volcado para intentar dimensionarlo de esa manera.
  • Pensé que tal vez eran registros binarios de RDS o registros lentos los que estaban ocupando espacio, pero al observar el tamaño real de la base de datos antes se demostró que todo estaba realmente en la base de datos... 
    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)

Respuesta1

No es posible estimar el almacenamiento requerido para la base de datos activa sin saber nada sobre los índices en uso. Cada índice es esencialmente un mapa, y cuantas más "claves" tenga el mapa, más espacio de almacenamiento se necesitará para ese mapa.

La cardinalidad del índice (la "forma" de los datos, esencialmente el número de "claves" únicas y cómo se asignan a las filas que contienen esa clave) también se vuelve importante si el tipo de datos de la columna indexada es algo mayor que un bigint. Una columna indexada de varchar(60) con muchas combinaciones únicas (alta cardinalidad) ocupará más espacio de almacenamiento que una con baja cardinalidad para el mismo tamaño de tabla porque las claves en el mapa ocupan más espacio de almacenamiento que los punteros de datos en el mapa.

ACTUALIZACIÓN: gracias a Michael a continuación, por supuesto debería haber dicho que mi afirmación sobre la cardinalidad y el tamaño de almacenamiento depende del motor de almacenamiento.

Por ejemplo, una base de datos con dos tablas InnoDB, ambas con 2176 filas de 3 columnas y un índice en una columna VARCHAR(32). La única diferencia en los datos de las 2 tablas es que tt1 tiene 2176 valores únicos para la columna VARCHAR y tt2 tiene un valor idéntico para la columna VARCHAR.

Verá que el tamaño del índice difiere en aproximadamente solo 16 kb:

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 |
+------------+------------+-------------+--------------+

Tenga en cuenta que el almacenamiento de datos InnoDB tiene 2 componentes: un diccionario de datos que se almacena de forma predeterminada en el archivo de espacio de tabla global, ibdata1, en el directorio de datos mysql, y los datos de la tabla que se almacenan en archivos .frm en un subdirectorio del directorio de datos. .

Por eso, Michael, no ves ninguna diferencia en el tamaño de almacenamiento de los archivos .frm. Si reiniciara MySQL usando la directiva innodb_file_per_table=1, vería esta diferencia reflejada en los archivos del espacio de tabla:

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

El almacenamiento InnoDB es único en el sentido de que los datos de la tabla son efectivamente un índice del diccionario de datos, lo que brinda algunos beneficios de rendimiento para algunas operaciones. Por lo tanto, el efecto de la cardinalidad en los requisitos de almacenamiento (alrededor del 10% en este caso) es muy diferente al de 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 esto lo explique un poco más.

información relacionada