Almacenamiento de datos: ajuste
Un almacén de datos sigue evolucionando y es impredecible qué consulta va a publicar el usuario en el futuro. Por lo tanto, se vuelve más difícil ajustar un sistema de almacenamiento de datos. En este capítulo, discutiremos cómo ajustar los diferentes aspectos de un almacén de datos, como el rendimiento, la carga de datos, las consultas, etc.
Dificultades en el ajuste del almacén de datos
Ajustar un almacén de datos es un procedimiento difícil debido a las siguientes razones:
El almacén de datos es dinámico; nunca permanece constante.
Es muy difícil predecir qué consulta va a publicar el usuario en el futuro.
Los requisitos comerciales cambian con el tiempo.
Los usuarios y sus perfiles siguen cambiando.
El usuario puede cambiar de un grupo a otro.
La carga de datos en el almacén también cambia con el tiempo.
Note - Es muy importante tener un conocimiento completo del almacén de datos.
Evaluación del desempeño
Aquí hay una lista de medidas objetivas de desempeño:
- Tiempo medio de respuesta a consultas
- Tasas de escaneo
- Consulta de tiempo utilizado por día
- Uso de memoria por proceso
- Tasas de rendimiento de E / S
Los siguientes son los puntos para recordar.
Es necesario especificar las medidas en el acuerdo de nivel de servicio (SLA).
De nada sirve intentar ajustar el tiempo de respuesta, si ya son mejores que los requeridos.
Es fundamental tener expectativas realistas al realizar la evaluación del desempeño.
También es fundamental que los usuarios tengan expectativas viables.
Para ocultar la complejidad del sistema al usuario, se deben utilizar agregaciones y vistas.
También es posible que el usuario pueda escribir una consulta para la que no estaba sintonizado.
Ajuste de carga de datos
La carga de datos es una parte fundamental del procesamiento nocturno. Nada más se puede ejecutar hasta que se complete la carga de datos. Este es el punto de entrada al sistema.
Note- Si hay un retraso en la transferencia de los datos, o en la llegada de los datos, todo el sistema se ve gravemente afectado. Por lo tanto, es muy importante ajustar primero la carga de datos.
Hay varios enfoques para ajustar la carga de datos que se analizan a continuación:
El enfoque más común es insertar datos utilizando el SQL Layer. En este enfoque, es necesario realizar comprobaciones y restricciones normales. Cuando los datos se insertan en la tabla, el código se ejecutará para comprobar si hay suficiente espacio para insertar los datos. Si no hay suficiente espacio disponible, es posible que deba asignarse más espacio a estas tablas. Estas comprobaciones toman tiempo y son costosas para la CPU.
El segundo enfoque es eludir todas estas comprobaciones y restricciones y colocar los datos directamente en los bloques preformateados. Estos bloques se escriben posteriormente en la base de datos. Es más rápido que el primer enfoque, pero solo puede funcionar con bloques completos de datos. Esto puede provocar un desperdicio de espacio.
El tercer enfoque es que mientras cargamos los datos en la tabla que ya contiene la tabla, podemos mantener índices.
El cuarto enfoque dice que para cargar los datos en tablas que ya contienen datos, drop the indexes & recreate themcuando se completa la carga de datos. La elección entre el tercer y cuarto enfoque depende de la cantidad de datos que ya se hayan cargado y de la cantidad de índices que se necesiten reconstruir.
Verificaciones de integridad
La verificación de la integridad afecta en gran medida el rendimiento de la carga. Los siguientes son los puntos para recordar:
Las comprobaciones de integridad deben limitarse porque requieren una gran potencia de procesamiento.
Deben aplicarse controles de integridad en el sistema de origen para evitar la degradación del rendimiento de la carga de datos.
Consultas de ajuste
Tenemos dos tipos de consultas en el almacén de datos:
- Consultas fijas
- Consultas ad hoc
Consultas fijas
Las consultas fijas están bien definidas. A continuación se muestran ejemplos de consultas fijas:
- informes regulares
- Consultas enlatadas
- Agregaciones comunes
Ajustar las consultas fijas en un almacén de datos es igual que en un sistema de base de datos relacional. La única diferencia es que la cantidad de datos a consultar puede ser diferente. Es bueno almacenar el plan de ejecución más exitoso mientras se prueban consultas fijas. El almacenamiento de estos planes de ejecución nos permitirá detectar cambios en el tamaño de los datos y la desviación de los datos, ya que hará que el plan de ejecución cambie.
Note - No podemos hacer más en la tabla de hechos, pero al tratar con tablas de dimensiones o agregaciones, se puede utilizar la colección habitual de ajustes de SQL, mecanismo de almacenamiento y métodos de acceso para ajustar estas consultas.
Consultas ad hoc
Para comprender las consultas ad hoc, es importante conocer a los usuarios ad hoc del almacén de datos. Para cada usuario o grupo de usuarios, necesita saber lo siguiente:
- El número de usuarios del grupo.
- Si utilizan consultas ad hoc a intervalos regulares de tiempo.
- Si utilizan consultas ad hoc con frecuencia
- Si utilizan consultas ad hoc ocasionalmente a intervalos desconocidos.
- El tamaño máximo de consulta que suelen ejecutar.
- El tamaño medio de consulta que suelen ejecutar.
- Si requieren acceso detallado a los datos base
- El tiempo de inicio de sesión transcurrido por día
- La hora pico de uso diario
- La cantidad de consultas que ejecutan por hora pico.
Points to Note
Es importante realizar un seguimiento de los perfiles de los usuarios e identificar las consultas que se ejecutan de forma regular.
También es importante que el ajuste realizado no afecte al rendimiento.
Identifique consultas similares y ad hoc que se ejecutan con frecuencia.
Si se identifican estas consultas, la base de datos cambiará y se pueden agregar nuevos índices para esas consultas.
Si se identifican estas consultas, se pueden crear nuevas agregaciones específicamente para aquellas consultas que resultarían en su ejecución eficiente.