MySql INSERT contra PHP file_put_contents

Question

Tengo una aplicación PHP/MySql que crece rápidamente y escribe mucho, inserta nuevas filas a razón de una docena o más por segundo en una tabla INNODB de varios millones de filas.

Empecé a usar las instrucciones INSERT en tiempo real y luego me mudé a PHP_subs_contents para escribir entradas en un archivo y CARGAR DATOS INFILE para obtener los datos en la base de datos. ¿Cuál es el mejor enfoque?

¿Hay alguna alternativa que deba considerar? ¿Cómo puedo esperar que los dos métodos manejen las colisiones y el aumento de la carga en el futuro?

Gracias!

Answer 1

Piense en LOAD DATA INFILE como un método por lotes de inserción de datos. Elimina la sobrecarga de activar una consulta de inserción para cada instrucción, por lo tanto, es mucho más rápido. Sin embargo, pierde parte del control al manejar errores. Es mucho más fácil manejar un error en una sola consulta de inserción en comparación con una fila en el medio de un archivo.

Answer 2

La forma en que tratamos nuestros insertos es enviarlos a un sistema de cola de mensajes como ActiveMQ. A partir de ahí, tenemos una aplicación separada que carga las inserciones utilizando LOAD DATA INFILE en lotes de aproximadamente 5000. El manejo de errores aún puede realizarse con el archivo infile, pero procesa las inserciones mucho más rápido. Si configurar una cola de mensajes está fuera del alcance de su aplicación, no hay ninguna razón para que file_put_contents no sea una opción aceptable, especialmente si ya está implementado y funciona correctamente.

Además, es posible que desee probar la desactivación de índices durante las escrituras para ver si eso mejora el rendimiento.

Answer 3

No parece que deba usar innoDB. De todos modos, una docena de insertos por segundo no debería ser problemático ni siquiera para el hardware defectuoso, a menos que, posiblemente, su modelo de datos sea muy complejo, pero para eso, LOAD DATA INFILE es muy bueno porque, entre otras cosas, reconstruye los índices solo una vez, a diferencia de en cada inserción. Entonces, usar archivos es un enfoque decente, pero asegúrese de abrirlos en el modo de solo agregar.

a largo plazo (1k + de escrituras/s), consulte otras bases de datos, particularmente cassandra para escribir aplicaciones pesadas.

Answer 4

LOAD DATA está inhabilitada en algunos servidores por razones de seguridad:

http://dev.mysql.com/doc/mysql-security-excerpt/5.0/en/load-data-local.html

también no me gusta escribir mis aplicaciones boca abajo para mantener la integridad de la base de datos.

Answer 5

Dependiendo de si puede permitirse que los datos insertados por PHP no estén disponibles al instante en la tabla, entonces INSERT DELAYED podría ser una opción.

MySQL aceptará los datos que se van a insertar y se ocupará de la inserción más adelante, poniéndolo en una cola. Por lo tanto, esto no bloqueará su aplicación PHP, mientras que MySQL asegura que los datos se inserten más adelante.

As it says in the manual:

Otra importante ventaja de usar INSERT DELAYED es que las inserciones de muchos clientes se agrupan y se escriben en un bloque. Esto es mucho más rápido que realizar muchas inserciones por separado.

he utilizado esto para el registro de datos en una pérdida de datos no es fatal, pero si quieres ser protegidos de servidor se bloquea cuando no se habían insertado los datos de INSERT DELAYED, usted podía mirar en replicar los cambios de distancia de una máquina esclava dedicada.

Answer 6

si va por la ruta de inserción sql, ajuste las instrucciones de ejecución de pdo en una transacción. hacerlo acelerará en gran medida el proceso.