Estoy luchando con la importación masiva de una tabla InnoDB bastante grande que consta de aproximadamente 10 millones de filas (o 7 GB) (que para mí es la tabla más grande con la que he trabajado hasta ahora).
Investigué un poco sobre cómo mejorar la velocidad de importación de Inno y por el momento mi configuración se ve así:
/etc/mysql/my.cnf/
[...]
innodb_buffer_pool_size = 7446915072 # ~90% of memory
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 5000
innodb_thread_concurrency=0
innodb_doublewrite = 0
innodb_log_file_size = 1G
log-bin = ""
innodb_autoinc_lock_mode = 2
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit=2
innodb_buffer_pool_instances=8
import is done via bash script, here is the mysql code:
SET GLOBAL sync_binlog = 1;
SET sql_log_bin = 0;
SET FOREIGN_KEY_CHECKS = 0;
SET UNIQUE_CHECKS = 0;
SET AUTOCOMMIT = 0;
SET SESSION tx_isolation='READ-UNCOMMITTED';
LOAD DATA LOCAL INFILE '$filepath' INTO TABLE monster
COMMIT;
Los datos se proporcionan en un CSV
archivo.
Actualmente pruebo mi configuración con 'volcados de prueba' más pequeños con 2 millones, 3 millones, ... filas cada uno y uso time import_script.sh
para comparar el rendimiento.
El inconveniente es que solo obtengo un tiempo de ejecución general, así que tengo que esperar a que termine la importación completa para obtener un resultado.
Mis resultados hasta ahora:
- 10 000 filas: <1 segundo
- 100 000 filas: 10 segundos
- 300 000 filas: 40 segundos
- 2 millones de filas: 18 minutos
- 3 millones de filas: 26 minutos
- 4 millones de filas: (cancelado después de 2 horas)
Parece que no hay una solución de 'libro de cocina' y uno tiene que descubrir la combinación óptima de configuraciones por su cuenta.
Además de las sugerencias sobre qué cambiar en mi configuración, también agradecería más información sobre cómo podría comparar mejor el proceso de importación / obtener más información sobre lo que está sucediendo y dónde podría estar el cuello de botella.
Traté de leer la documentación de la configuración que estoy cambiando, pero, una vez más, no estoy al tanto de ningún efecto secundario y si incluso podría disminuir el rendimiento con un valor mal elegido.
Por el momento, me gustaría probar una sugerencia de chat para usar MyISAM
durante la importación y cambiar el motor de la tabla después.
Me gustaría probar esto, pero por el momento mi DROP TABLE
consulta también tarda horas en terminar. (Lo que parece otro indicador de que mi configuración es menos que óptima).
Información adicional:
La máquina que estoy usando actualmente tiene 8 GB de RAM y un disco duro híbrido de estado sólido con 5400 RPM.
Si bien también apuntamos a eliminar datos obsoletos de la tabla en cuestión, todavía necesito una importación algo rápida para
a) probar automatic data cleanup feature
durante el desarrollo
yb) en caso de que nuestro servidor se bloquee, nos gustaría usar nuestro segundo servidor como reemplazo (que necesita datos actualizados, la última importación tardó más de 24 horas)
mysql> SHOW CREATE TABLE monster\G
*************************** 1. row ***************************
Table: monster
Create Table: CREATE TABLE `monster` (
`monster_id` int(11) NOT NULL AUTO_INCREMENT,
`ext_monster_id` int(11) NOT NULL DEFAULT '0',
`some_id` int(11) NOT NULL DEFAULT '0',
`email` varchar(250) NOT NULL,
`name` varchar(100) NOT NULL,
`address` varchar(100) NOT NULL,
`postcode` varchar(20) NOT NULL,
`city` varchar(100) NOT NULL,
`country` int(11) NOT NULL DEFAULT '0',
`address_hash` varchar(250) NOT NULL,
`lon` float(10,6) NOT NULL,
`lat` float(10,6) NOT NULL,
`ip_address` varchar(40) NOT NULL,
`cookie` int(11) NOT NULL DEFAULT '0',
`party_id` int(11) NOT NULL,
`status` int(11) NOT NULL DEFAULT '2',
`creation_date` datetime NOT NULL,
`someflag` tinyint(1) NOT NULL DEFAULT '0',
`someflag2` tinyint(4) NOT NULL,
`upload_id` int(11) NOT NULL DEFAULT '0',
`news1` tinyint(4) NOT NULL DEFAULT '0',
`news2` tinyint(4) NOT NULL,
`someother_id` int(11) NOT NULL DEFAULT '0',
`note` varchar(2500) NOT NULL,
`referer` text NOT NULL,
`subscription` int(11) DEFAULT '0',
`hash` varchar(32) DEFAULT NULL,
`thumbs1` int(11) NOT NULL DEFAULT '0',
`thumbs2` int(11) NOT NULL DEFAULT '0',
`thumbs3` int(11) NOT NULL DEFAULT '0',
`neighbours` tinyint(4) NOT NULL DEFAULT '0',
`relevance` int(11) NOT NULL,
PRIMARY KEY (`monster_id`),
KEY `party_id` (`party_id`),
KEY `creation_date` (`creation_date`),
KEY `email` (`email`(4)),
KEY `hash` (`hash`(8)),
KEY `address_hash` (`address_hash`(8)),
KEY `thumbs3` (`thumbs3`),
KEY `ext_monster_id` (`ext_monster_id`),
KEY `status` (`status`),
KEY `note` (`note`(4)),
KEY `postcode` (`postcode`),
KEY `some_id` (`some_id`),
KEY `cookie` (`cookie`),
KEY `party_id_2` (`party_id`,`status`)
) ENGINE=InnoDB AUTO_INCREMENT=13763891 DEFAULT CHARSET=utf8
SHOW CREATE TABLE yourtable\G
para mostrarnos la estructura de la tabla de esta tabla de 10 millones de filas.
innodb_doublewrite = 0
), su instalación de MySQL no es segura: si tiene una falla de energía (no un bloqueo de MySQL), sus datos podrían corromperse silenciosamente.