por un tiempo, mi amigo Frank de Jonge me dijo que logró aumentar el rendimiento en una importación de 10:00 para 16 minutos. Según él, los campos involucrados cambios eran demasiado largo que almacenan cadenas pequeñas, el número de índices y llaves foráneas en las tablas. Estamos hablando de al menos 1 millón de registros aquí, y él se preguntaba si era posible tener una importación aún más rápido.
basic
hay varias maneras de importar información a una base de datos. Todo depende del origen y de destino. Un poco más de contexto para una mejor comprensión: puede quitar los datos de una aplicación heredada que exporta datos a CSV para su servidor de base de datos o incluso datos de diferentes servidores.
Si usted está exportando información de una tabla de MySQL a otra tabla de MySQL (teniendo en cuenta que están en distintos servidores), probablemente se utilice el comando de mysqldump.
para exportar una sola tabla:
$ mysqldump-h localhost-u root-p--extended-insert,--quick--no-create-info mydb mitabla | gzip > mytable.sql.gz
descortezar esta línea de comandos:
- – extendido – insert : se asegura de que el comando INSERT tienen más de un registro por línea.
- -rápido: recomendado para descarga de tablas de gran tamaño, porque, por defecto, MySQL lee toda la tabla en memoria y luego escribe volcado a disco. De esta manera, tenemos streaming continuo de datos sin consumir muchos recursos de memoria.
- – no-crear-info: Esto significa que sólo los datos que se está exportando, se suprimen las disposiciones de la tabla crear .
el complejo
mi amigo tuve un problema un poco más complejo. Que necesitaba para generar un volcado de archivo en los archivos tenía un origen en el procesamiento y Análisis de objetos (entonces aconsejó usar el archivo de carga en el futuro), pero como el 90% de su trabajo ya fue hecho, él tenía solamente una pregunta:
¿por qué cuando exporto en bloques de 50 registros a insertar es más rápido que cuando lo hago con 500?
puede ser no hay razones para esto:
- buffer de 500 registros en memoria es menor que 50. Recuerda, Estás leyendo el disco, y siempre será más lento.
- si no se utilizan las transacciones, los índices son recalcula/reconstruida al final de cada INSERT . Para 1 millón de registros con un montón de 50 tendría 20000 INSERT ejecutar, mientras que un montón de registros tendríamos cerca de 500 de carreras 2000. Mi especulación aquí es que como los índices en una tabla con InnoDB BTREE, crear los registros están en pequeños lotes significa que “sabes” donde los valores están en el árbol, lo que es más rápido para encontrar, ordenar y organizar que con 500 artículos de tiempo. Una vez más, esto es sólo una especulación .
consejos
transacciones
mi primera sugerencia fue a envolver todo en una sola transacción. Colocar un START TRANSACTION al principio y al final añadir un COMMIT . De esta manera, el proceso de reconstrucción de los índices y llaves foráneas validación ocurriría solamente en el final de la secuencia de comandos.
reportó una ligera mejora en el rendimiento.
el peligro
sabía que una solución desde el principio que haría su vida más fácil, sin embargo, debido a que el origen de datos no es tan completo como la base de datos, esto puede resultar en datos duplicados, llaves foraneas que falta, es decir, podría terminar en una manera muy trágica.
cuando se utiliza el shell > mysqldump , MySQL por defecto pone esta opción al principio y al final de la secuencia de comandos. Él toma (y de una manera incluso justa) que va importando estos datos a una base de datos vacía, tal modo, no hay problemas con datos de integridad, que no era el caso.
los expedientes fueron manipulados para ser insertado, y el comando que viene por defecto habilitados en secuencias de comandos y recomienda para él era:
SET foreign_key_checks = 0; / * Inserte aquí su script muy cuidadosamente * / SET foreign_key_checks = 1;
las importaciones cayeron de 16 min a 6 min estaba encantado con el resultado:
yo estaba super contento con la importación DB de corte de 16 horas a 10 minutos. Entonces @gabidavila dio consejos apuestas que lo trajo hasta 6 m.
, Frаnk de Jonge (@frankdejonge) 22 de abril de 2016
alguna gente le preguntó cómo hizo que pueda, y este artículo nació. Admito que es divertido ver lo corte por la mitad, pero uso estos comandos cuidadosamente.
archivos de CSV de forma aún más rápida
. sí, es más rápido. Hablando específicamente de TSV , ya tienen comas de una cadena es una ocurrencia común.
para generar un volcado con CSV :
$ mysqldump-h localhost-u root-p--tab = / tmp mydb mitabla
si haces cualquier tipo de manipulación con los datos o utilizando otra fuente que no sea un servidor de base de datos, no olvide usar N a valores NULL .
importación de:
$ mysql-h localhost-u root-p mysql mydb > LOAD DATA INFILE '/tmp/mytable.txt' en la tabla mitabla; Query OK, 881426 filas afectaron (29,30 sec) Records: 881426 eliminado: 0 Skipped: 0 ADVERTENCIAS: 0
los mismos datos con INSERT en bloque tomaron aproximadamente un minuto. Hay variables a considerar cuando se trata con este comando como el tamaño del búfer, compruebe las llaves, entre otros. Así, para alto volumen de información y datos, importando directamente desde un archivo de texto es todavía la mejor opción.
conclusión
como demostré, hacer una rápida importación puede consistir en solamente desactivar la validación claves y restricciones (condiciones?). Sólo hacer esto si estás seguro de que los datos son válidos, sin embargo, otras opciones como net_buffer_length, max_allowed_packet read_buffer_size pueden ayudar a importar grandes archivos SQL. Algo que se debe considerar en una situación como ésta: > integridad de datos rendimiento.
Comments
0 comments
Twitter
RSS