Ventajas de predicción de la desnormalización de bases de datos

Siempre me enseñaron a luchar por la forma normal más alta de normalización de la base de datos, y nos enseñaron el algoritmo de síntesis de Bernstein para lograr 3NF. Todo esto está muy bien y se siente bien normalizar su base de datos, sabiendo que los campos pueden modificarse mientras se mantiene la consistencia.

Sin embargo, el rendimiento puede sufrir. Es por eso que me pregunto si hay alguna forma de predecir la aceleración / desaceleración cuando se desnormaliza. De esa manera, puede crear su lista de FD con 3NF y luego desnormalizar lo menos posible. Me imagino que desnormalizar demasiado desperdiciaría espacio y tiempo, porque, por ejemplo, los blobs gigantes se duplican o porque es más difícil mantener la coherencia porque hay que actualizar varios campos mediante una transacción.

Resumen: Dado un conjunto de FD de 3NF y un conjunto de consultas, ¿cómo puedo predecir la aceleración / desaceleración de la desnormalización? Enlace a documentos apreciados también.

Debería conocer los flujos de datos entre las tablas para poder ver cómo funciona el modelo DB. Una vez que tenga eso, puede calcular el cambio en el rendimiento para una desnormalización dada (por ejemplo, si decide duplicar datos)

Algunas estimaciones aproximadas se pueden deducir por la cantidad de nuevos índices que necesitaría después de los pasos de desnormalización. Cada nuevo índice debe actualizarse y consultarse por separado, lo que generará un impacto de rendimiento proporcional al número de nuevos índices.

Grandes bloques de datos binarios deben, en cualquier caso, almacenarse en una tabla separada y no copiarse. No se consultan (generalmente) sino que se devuelven como parte del conjunto de resultados final después de una consulta en algún otro conjunto de tablas.

No estoy seguro de que haya alguna investigación académica sobre cuándo la desnormalización puede ayudar (en mi humilde opinión, hay una gran diferencia entre lo que se enseña sobre la normalización de DB y cómo funciona en la práctica).

Sin embargo, hay varios artículos interesantes y entradas de blog sobre esto _ Jeff Atwood habla sobre la normalización en su blog , y hay una "respuesta" para él con una gran escalabilidad.

Al desnormalizar, le sugiero que preste atención a

• el número y tipo de consultas por unidad de tiempo; Si usa insertar y / o actualizar más que leer, la desnormalización no sería de mucha ayuda.
• con qué frecuencia se actualizará la información duplicada
• Las características del DBMS que utilizará
• cuántas veces se duplica la información; Si tiene la misma información en 4-5 tablas, podría ser más rápido mantenerla en una tabla separada en lugar de copiarla tantas veces
• la cantidad esperada de datos guardados en DB; lo que podría funcionar para pequeñas cantidades de datos, puede conducir a un desastre si aumenta el número de registros. Y viceversa (quiero decir el principio KISS y no arreglar lo que no está roto).

Me imagino que desnormalizar demasiado desperdiciaría espacio y tiempo

El espacio no es motivo de preocupación en la mayoría de las aplicaciones OLTP de línea de negocio de tamaño mediano. Así que deja el espacio a un lado. Tiempo, y por tiempo supongo que se refiere al rendimiento de la consulta, eso es algo que generalmente se puede mejorar y no causa un problema real a menos que tenga un mal diseño, recursos insuficientes, una base de datos extremadamente grande, una gran cantidad de transacciones o todas lo anterior. La mayoría de las aplicaciones que utilizan las bases de datos actuales rara vez tendrían un problema de rendimiento solo porque la base de datos está Normalizada.

los blobs gigantes se duplican o porque es más difícil mantener la coherencia porque tienes que actualizar varios campos usando una transacción.

La normalización de su base de datos le asegura que su diseño:

1. No tener datos redundantes.

2. No causa que se cree una gran cantidad de enteritis de registro (por ejemplo, con una tabla de 2 millones de clientes: ACTUALIZAR el conjunto de clientes Country = "USA" WHERE Country = "US")

3. Ser totalmente compatible con consultas SQL. Este punto es muy importante.

4. Conducirá código de aplicación limpio.

5. Fuerce un alto grado de consistencia de datos a través de la base de datos sin sobrecargar la aplicación.

6. Comparta las reglas de negocio definidas en la base de datos por diferentes aplicaciones sin codificar el mismo código en diferentes aplicaciones.

Dicho esto, la Normalización produce una estructura óptima para todas las columnas y tablas. Es posible que esto no siempre lo necesite en su aplicación en particular, luego podría determinar, dada su comprensión de su dominio y su aplicación, desnormalizar algunas de las tablas / columnas como una compensación por la velocidad. Sin embargo, esa sería una decisión consciente más que un descuido.

Dado un conjunto de FD de 3NF y un conjunto de consultas, ¿cómo puedo predecir la aceleración / desaceleración de la desnormalización?

No puede predecir el rendimiento con precisión sin realizar pruebas (lo que puede hacer antes de escribir el código de la aplicación). Sin embargo, puede eliminar y detectar factores que conducirían a un mal rendimiento por diseño. Por ejemplo, puede identificar qué estrategia de índice usar de la siguiente manera (pueden existir otras técnicas):

1. Cree una matriz de consultas y columnas afectadas por esas consultas.

2. Encuentra las columnas que más se usan.

3. Considere construir índices en esas columnas.

Este es principalmente un trabajo en el que su DBA podría ayudarlo. Hay más en el rendimiento que la normalización. Hay aspectos de la distribución de datos sobre volúmenes de disco, división vertical de tablas, particionamiento, tipos de índice y almacenamiento en búfer de índice, por nombrar algunos. Todas estas técnicas deben abordarse en los libros y la documentación del proveedor en los temas "Diseño de la base de datos" y "Ajuste del rendimiento de la base de datos". Toda la discusión anterior supone que su aplicación es una aplicación OLTP.

Una de las principales razones para normalizar es que se optimiza para casos de uso general, mientras que la desnormalización tiende a optimizar el rendimiento para casos de uso especializados (con penalizaciones significativas para otros casos de uso). Esta es una de las razones por las cuales las cargas de trabajo OLTP se benefician principalmente de la normalización (hay excepciones aquí, pero son raras).

Para predecir las ventajas, lo que realmente debe saber es qué es exactamente lo que está desnormalizando y para qué flujos de trabajo. También hay preguntas sobre el tamaño de su conjunto de datos y cuáles son los impactos del almacenamiento en caché. Por lo tanto, es probable que la respuesta dependa de una gran cantidad de cosas, incluido el tamaño de la base de datos, qué porción es probable que aún esté en la memoria, la planificación general de consultas complejas y similares. Este es un asunto muy complicado, específico de implementación, y depende mucho de su base de datos y su RDBMS. Estas ventajas serán mayores en las cargas de trabajo OLAP, y típicamente las desventajas serán mayores en las cargas de trabajo OLTP.

Por lo tanto, no veo que haya una sola respuesta aquí aparte de mirar los planes de consulta y considerar la posibilidad de vistas materializadas para datos desnormalizados. En mi opinión, el mejor enfoque es tener una base de datos OLTP relativamente normalizada y desnormalizar con fines informativos solo según sea necesario.

Normalmente, des-normaliza su modelo de datos para optimizar el rendimiento para un caso de uso particular . Esto generalmente tendrá un efecto adverso en el rendimiento de otros casos de uso. por ejemplo, la repetición de datos en varias filas puede acelerar el procesamiento de consultas al eliminar una unión, pero el proceso de actualización se ralentizará.

En efecto, 3NF ofrece un rendimiento óptimo para cualquier número de accesos arbitrarios a su base de datos, pero, para uniones y selecciones particulares, puede haber mejores modelos.

Así que trate la desnormalización como lo haría con cualquier otra optimización. es decir, no lo haga a menos que realmente tenga un problema de rendimiento y asegúrese de que su "solución" no cause más problemas de los que resuelve.