MySQL, índices y cintas de video
La mayoría de la gente que trabaja con MySQL (ójala fueran todos), sabe que los índices son una parte importantísima del rendimiento en las consultas a base de datos. Para los no conocedores del tema, se pueden crear índices (y se deben…) para que cuando queremos obtener un conjunto de registros, segmentados por algún tipo de condición, estos sean devueltos con un mínimo de rapidez. La regla suele ser que por cada campo de un WHERE se debe tener un índice. Luego se puede estudiar el comportamiento y optimizar estos índices con la maravillosa instrucción EXPLAIN.
A mi juicio, esto tiene una excepción, y son las consultas de texto completo en las que es mejor usar una herramienta externa de consulta de índices de texto completo (fulltext).
No quiero entrar en todo el tema de teoría de índices y demás, pero básicamente se puede resumir en que se reduce un poco el rendimiento de una inserción o actualización en base de datos en pro de la rapidez en consulta.
Generalmente se trabaja con tablas en las que se escribe esporádicamente y se lee muy a menudo de manera que es muy importante mantener esos índices. Hoy me he encontrado el único caso en el que es muchísimo mejor no tener índice alguno en las tablas a utilizar y, aunque es un caso muy particular, no es imposible que ocurra.
Se basa en las siguientes premisas:
- Se debe llebar una o varias tablas con una cantidad de registros muy alta (varios millones)
- Se llenan de seguido, no esporádicamente. No sufren lecturas (SELECT) durante el tiempo de inserción
- Son tablas de caracter transitorio: un script lee una fuente de datos (ficheros) las rellena y cuando ha acabado, serán consultadas y borradas.
En este caso, es imprescindible para el rendimiento que las tablas donde se va a realizar la inserción no tengan índices ( aparte de la clave primaria claro) para que se hagan lo más rápido posible. Una vez finalizado el proceso de inserción, se construyen los índices necesarios, se ejecutan las consultas pertinentes y posteriormente se borran las tablas.
Si medimos el tiempo de ejecución del modelo clásico en fragmentos de 10.000 inserciones se verá que el tiempo para ejecutar esos mismo fragmentos aumenta mucho segun va pasando el tiempo y llenandose la tabla. Sin embargo el modelo de “patada a la teoría” mantiene una buena tasa de inserción constante. Posteriormente el tiempo de creación de índices es despreciable comparado con lo que tardaba la manera original con índices.
He intentado reproducir lo que me ha ocurrido hoy en una máquina de desarrollo y ha pasado en varios órdenes de magnitud menor pero aún así se consigue el mismo objetivo en la mitad de tiempo. 1 millon de inserciones (de las cuales la mitad derivan en una insercion adicional) en 250 segundos frente a 600 segundos por el mismo trabajo. Posteriormente la creación de los índices no supera los 60 segundos.
Conclusión: picardía y ganas de enredar acaban en beneficio para el rendimiento.
Mayo 23rd, 2007 at 8:19 am
A mi me parece un pasote cuando me paro a pensar en estas velocidades, que se pueda leer un fichero de texto (pongamos línea a línea), parsear la información, construir una instrucción SQL con esta información, enviarla al servidor, que este parsee tu instrucción, y que finalmente guarde esos datos con la estructura de la bbdd … en 0,00025 segundos por consulta (de media) … y luego le dices que abra el Media Player y se queda pensando unos segundos