¿Cargando Big Data? Para más velocidad, clasificación previa y carga masiva
Encontrar más velocidad al cargar big data es un desafío en ETL, reorg y el índice de base de datos muy grande (VLDB) operaciones de llenado. Una forma de cargar grandes cantidades de datos más rápido es clasificándolos previamente, de modo que la base de datos no tenga que clasificarse. IBM y otros proveedores de bases de datos de mainframe han dado ese consejo durante décadas, y sigue siendo cierto en las bases de datos relacionales que se usan en Unix y otros "sistemas abiertos" en la actualidad, incluidos Oracle, DB2, Sybase y SQL Server.
Los puntos de referencia en esta área muestran mejoras sobre las cargas no clasificadas según el volumen, pero los proveedores de clasificación como IRI afirman que el rendimiento de la carga ha mejorado entre dos y diez veces. En el informe de TUSC Consulting "Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle", solo una prueba de inserción de índice único de 100 000 filas mostró que los datos preordenados se cargaron un 58 % más rápido y requirieron un 49 % menos de espacio:
- La carga en orden ordenado tuvo un 42 % menos de filas sostenidas/tasa de carga por segundo
- Las inserciones sin ordenar en los índices obligan a realizar más trabajo interno de la base de datos (administración de bloques y reorganización del espacio)
- En los índices ordenados por carga, el factor de agrupación estará cerca del número de bloques de hoja
- El orden de los datos cargados es fundamental para el rendimiento de la carga.
Muchos años después, en el capítulo 13 de su guía "Administración experta de Oracle Database 11g", Sam R. Alapati (Miro Consulting) recomendó la clasificación previa junto con las cargas de rutas directas como la forma más rápida de cargar Oracle en masa (frente a las inserciones):
“La carga de ruta directa la opción no usa la instrucción SQL INSERT para poner datos en tablas; más bien, formatea bloques de datos de Oracle y los escribe directamente en los archivos de la base de datos. Este proceso de escritura directa elimina gran parte de la sobrecarga involucrada en la ejecución de sentencias SQL para cargar tablas. Dado que el método de carga de ruta directa no compite por los recursos de la base de datos, cargará datos mucho más rápido que una carga de datos convencional. Para cargas de datos más grandes, el método de carga de ruta directa es el mejor y puede ser el único método viable para cargar datos en tablas por la sencilla razón de que una carga convencional puede requerir más tiempo del disponible".
Para los administradores de VLDB de hoy, aquí es donde entra CoSort, ya que:
“Además de las ventajas obvias de un tiempo de carga más corto, la carga directa también lo ayuda a reconstruir índices y clasificar previamente los datos de la tabla”.
CoSort se usa tradicionalmente en la clasificación previa externa de un archivo plano que será importado a una carga especificando "directo =verdadero" y esta opción:
“ÍNDICES ORDENADOS:El parámetro SORTED_INDEXES indica a SQL*Loader que los datos están ordenados en un índice específico, lo que mejora el rendimiento de la carga.”
De manera similar, la documentación de Microsoft SQL Server especifica la clasificación previa de archivos como uno de los "Métodos para optimizar la importación masiva":
De forma predeterminada, una operación de importación masiva asume que un archivo de datos no está ordenado. Si la tabla tiene un índice agrupado, el bcp La utilidad, la instrucción BULK INSERT y la función OPENROWSET(BULK…) (Transact-SQL) le permiten especificar cómo se ordenan los datos en el archivo de datos durante una operación de importación masiva. Es opcional que los datos del archivo de datos se clasifiquen en el mismo orden que la tabla. Sin embargo, puede mejorar el rendimiento de la operación de importación masiva si especifica el mismo orden para el archivo de datos que para la tabla.
El campo /KEY en una secuencia de comandos CoSort SortCL normalmente sería la clave de índice (principal) más larga de la tabla, pero no tiene por qué serlo. Según TUSC, para columnas similares:
- Es preferible un número menor de índices largos a índices más cortos
- La columna principal determina el costo de carga del índice
Tenga en cuenta también que:
- Para Vertica y otros manuales básicos de RDBMS, mantener las columnas ordenadas optimiza el rendimiento de las consultas. Incluso el antiguo consejo de la Guía Rdb/VMS para el mantenimiento y el rendimiento de la base de datos de DEC sigue siendo cierto:
“Ordene previamente los registros que planea almacenar en una tabla por valor de clave principal antes de cargarlos en la base de datos. Cuando se carguen los registros, estarán físicamente adyacentes entre sí, o agrupados, hasta que se almacenen registros adicionales en la base de datos. Mantener este arreglo beneficia a las consultas que seleccionan filas en función de un rango de valores o que unen muchas filas de una tabla con filas en la misma tabla”.
- La clasificación previa de datos en tablas también puede ahorrar tiempo en las vistas. Según "Oracle Database 10g:The Complete Reference" de Kevin Loney:
“Tener los datos ordenados en la vista puede simplificar el desarrollo de su aplicación. Por ejemplo, si su código pasa por un conjunto de registros, tener esos registros preordenados puede simplificar el procesamiento y la verificación de errores. En el desarrollo de su aplicación, sabrá que los datos siempre le serán devueltos de forma ordenada.”
- Sr. Alapati advierte a los administradores de bases de datos sobre una limitación de las cargas de rutas directas:
“Nota:en una carga directa, no puede usar ninguna función SQL. Si necesita realizar una gran carga de datos y también transformar los datos durante la carga, tienes un problema. La carga de datos convencional le permitirá usar funciones SQL para transformar datos, pero el método es muy lento en comparación con la carga directa. Por lo tanto, para grandes cargas de datos, es posible que desee considerar el uso de una de las técnicas de carga/transformación más nuevas, como tablas externas o funciones de tabla”.
Sin embargo, el programa SortCL de CoSort puede transformar los datos de carga durante la clasificación previa; es decir, combinando el mismo tipo de funciones SQL en el mismo script de trabajo y paso de E/S, que incluyen:uniones, agregaciones, cálculos cruzados, búsquedas, funciones de selección/filtro, subcadena e instring, y muchos objetivos de reformateo y de informes personalizados — en esa misma operación de clasificación previa.
- La nueva utilidad de reorganización fuera de línea en IRI Workbench (GUI de Eclipse) usa IRI FACT (Extracción rápida) para descargar datos de tablas rápidamente a través de OCI, usa CoSort para clasificar previamente la clave principal y escribe y ejecuta SQL*Loader directamente cargas de ruta para optimizar y combinar cada uno de estos pasos.
