No existe una solución genérica que sea la mejor para todo tipo de situación. Cada escenario, cada situación tiene su propia solución más efectiva.
Hallar esa solución requiere una combinación de conocimiento, análisis y destreza a la hora de identificar los detalles del escenario y cuál de las posibles soluciones se adapta mejor a ese caso.
Para ilustrar esto, vamos a centrarnos en un problema concreto: la inserción registros en una tabla de una base de datos.
Definición del escenario
Nuestro objetivo es insertar registros en una tabla de base de datos.
Ante estos requerimientos debemos analizar con más detalle el escenario. Deberíamos plantearnos cuestiones como:
- ¿De cuántos registros estamos hablando?
- ¿De cuánto tiempo disponemos para realizar esa inserción?
Es evidente que insertar 1 registro o 50 millones es importante a la hora de definir el escenario.
En el caso de la inserción de un solo registro, el rendimiento (en la mayoría de procesos) no va a ser crítico, ya que la diferencia de ejecución de las diferentes alternativas de inserción posiblemente será imperceptible por el usuario.
Sin embargo, si el número de registros es elevado, una pequeña diferencia de tiempo por registro puede convertirse en una gran diferencia al final del proceso. Si la ventana para la realización de la inserción es corta, elegir la alternativa más lenta podría ser fatal para el proceso o sus procesos dependientes.
Conocimiento de la tecnología y los procesos
Supongamos que nuestra base de datos es Oracle. Esta tecnología tiene dos maneras diferentes de realizar inserciones:
- La inserción registro a registro
- La inserción multi-registro (bulk insert)
La inserción registro a registro inserta 1 único registro cada vez que se ejecuta. Su sintaxis en Oracle es:
INSERT INTO tabla (columna_1, columna_2, …) VALUES (valor_1, valor_2, …);
Cada una de estas inserciones se divide en dos tareas. La primera se ocupa de encontrar la posición dentro de la tabla dónde vamos a insertar esa fila. La segunda tarea se ocupa de insertar los datos en esa posición.
Por otra parte, al ejecutar un bulk insert, una sola instrucción insertará un número de registros que puede ser superior a 1.
Las instrucciones que utilizan bulk insert son:
INSERT INTO tabla (columna_1, columna_2, …) SELECT ...
CREATE TABLE tabla AS SELECT ...
SQL*Loader
Ante la necesidad de insertar potencialmente más de una fila, la búsqueda de una ubicación para los registros carece de sentido. Si fuese así, la inserción tendría un alto coste debido a la repetición de la primera tarea de la inserción para cada uno de los registros de la consulta. En este caso, lo que el motor de base de datos lleva a cabo es la inserción de todos los registros implicados, a partir de la última posición de la tabla.
Implicaciones de los dos métodos de inserción
La inserción registro a registro permite aprovechar mejor el espacio ocupado por la tabla, al ocupar espacio libre dentro de ésta (producido por la eliminación de registros de la tabla). Es decir, tenemos una mayor densidad de registros por espacio de disco (throughput). Este mejor aprovechamiento del espacio supone que, en un acceso secuencial a la tabla, el espacio de disco a escanear tiende a ser óptimo. Esto supone un mejor rendimiento en las consultas donde esta tabla sea accedida en modo secuencial. Sin embargo, la operación de inserción añade un sobrecoste debido a la búsqueda de un espacio libre en la tabla en cada instrucción (es decir, para cada registro insertado).
La inserción multi-registro tan solo realiza la acción de añadir filas a la tabla (sin buscar un espacio libre para cada registro insertado). Esto se realiza añadiendo los registros a partir de la última posición en la tabla a la cual podemos acceder mediante un puntero, . Al hacer esto, el sobrecoste de encontrar un espacio libre en la tabla desaparece. Sin embargo, el hecho de añadir registros siempre al final de la tabla significa que está crecerá cada vez que ejecutemos una inserción de este tipo. La consecuencia es que, en el caso de acceder a todos los registros de la tabla en una consulta, estaremos accediendo a una cantidad cada vez mayor de espacio en disco. En este caso, el throughput disminuirá progresivamente en la tabla a medida que vayamos realizando inserciones multi-registro.
Conclusión
Tal y como he comentado al inicio de este artículo, no existe una solución que se comporte siempre de manera óptima en todos los casos.
Es necesario identificar los detalles específicos de cada escenario que decantarán la decisión de utilizar una u otra solución.
El análisis previo al diseño de la solución nos aportará la información que necesitamos para poder elegir el diseño más adecuado en cada caso.
El conocimiento de la tecnología nos permitirá identificar las diferentes alternativas de diseño con sus beneficios e inconvenientes.
Y finalmente, la destreza a la hora de combinar toda la información disponible nos permitirá elegir la mejor solución dentro de toda la gama de grises disponible.
