¿Puede ofrecer algunos consejos sobre cómo mejorar el rendimiento del almacén de datos? Nos gustaría acelerar nuestra carga y consulta de datos …
rendimiento de procesamiento.
Me complace darle algunas sugerencias, pero tenga en cuenta que cualquier consultor que se precie examinaría los problemas específicos de una empresa determinada antes de sugerir cambios en sus sistemas de almacenamiento de datos, y yo no sé nada sobre su empresa. Aún así, aquí están mis seis consejos principales para mejorar el rendimiento de los almacenes de datos:
- Antes incluso de pensar en la optimización del rendimiento, asegúrese de haber identificado los cuellos de botella existentes. Si el rendimiento de las consultas depende de la CPU, comprar discos más rápidos es una completa pérdida de dinero.
- Conozca su motor de base de datos. El rendimiento a menudo se ve comprometido cuando los usuarios no conocen los entresijos de su base de datos en particular. Por ejemplo, he visto personas que usan una declaración SQL INSERT cuando la utilidad de carga masiva hubiera sido más efectiva.
También he visto a personas usar DELETE * para vaciar una mesa. Eso puede ser dolorosamente lento en comparación con DROP y CREATE, que a su vez es mucho más lento que TRUNCATE. Pero, por supuesto, es posible que el software de su base de datos no sea compatible con TRUNCATE, por lo que necesita saber cómo funciona. Si no tiene un buen administrador de base de datos, puede valer la pena contratar uno solo desde el punto de vista de la optimización del rendimiento.
- En términos de consultas, piense en estructurar los datos como un cubo MOLAP (es decir, uno de procesamiento analítico en línea multidimensional) y aumentar la agregación hasta que el rendimiento de su consulta vuele. Eso puede consumir espacio en disco y tiempo de procesamiento de datos, pero puede marcar una gran diferencia.
- Piense en utilizar unidades de estado sólido (SSD). Pueden ser increíblemente rentables para problemas de velocidad vinculados al disco. Recientemente, estaba trabajando con un cliente que tenía un cubo OLAP de 35 GB que funcionaba lentamente, tanto en términos de tiempo de agregación como de respuesta a consultas. Les recomendé que lo probaran en un SSD. Dio la casualidad de que había una PC nueva con un SSD de 70 GB en el banco de pruebas. (Se estaba construyendo para un vendedor que se quejaba de los tiempos de arranque lentos).
La máquina se “apropió”, el RDBMS se instaló en el disco duro y se creó una copia del cubo OLAP en el SSD. El cubo se agregó mucho, mucho más rápido, pero fue en la consulta donde se observaron las mejoras más dramáticas. Algunas de las consultas se ejecutaron 20 veces más rápido con el mismo nivel de agregación. El costo del SSD fue completamente trivial (alrededor de $ 200) en comparación con la mejora.
La gente piensa en los SSD en términos de portátiles. (Yo mismo lo hago: tengo uno de 250 GB en el portátil en el que estoy escribiendo estas palabras). Pero también son increíblemente aplicables a aplicaciones de uso intensivo de disco.
- Si es posible, realice el procesamiento de extracción, transformación y carga (ETL) en la memoria. En un trabajo ETL largo, puede ser beneficioso almacenar en caché en el disco (en caso de que el proceso falle), pero intente mantener los datos en la RAM durante las transformaciones. Y almacenar en caché en un SSD, no en un disco duro.
- Indexe sus estructuras analíticas para el análisis, no para las transacciones. Sé que suena obvio, pero he visto innumerables esquemas en estrella OLAP relacionales donde la estrategia de indexación se basaba claramente en una larga experiencia con sistemas transaccionales y poca familiaridad con los analíticos.
Por ejemplo, de forma predeterminada, muchos motores RDBMS indexarán la clave principal de una tabla. Eso tiene mucho sentido en una estructura transaccional, donde muchas de las consultas usarán esos índices, pero muy poco sentido en un esquema en estrella, donde es bastante común que las consultas no, none, zero, nada usen los índices de clave primaria. Por otro lado, es muy probable que se realicen búsquedas en todas las columnas analíticas de las tablas de dimensiones y, sin embargo, a menudo carecen por completo de índices.
