Predicción de ventajas de la desnormalización de la base de datos

8

Siempre me enseñaron a esforzarme por alcanzar la forma normal más alta de normalización de la base de datos, y nos enseñaron algoritmo de síntesis de Bernstein para lograr 3NF. Todo esto está muy bien y es agradable normalizar su base de datos, sabiendo que los campos se pueden modificar al mismo tiempo que 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 al desnormalizar. De esa manera, puede construir 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 porque es más difícil mantener la coherencia porque debe actualizar varios campos mediante una transacción.

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

    
pregunta Janus Troelsen 13.10.2012 - 17:05

5 respuestas

1

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 determinada (por ejemplo, si decide duplicar datos)

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

Los grandes blobs de datos binarios deben, en cualquier caso, almacenarse en una tabla separada y no copiarse. Por lo general, no se consultan, pero se devuelven como parte del conjunto de resultados finales después de una consulta en algún otro conjunto de tablas.

    
respondido por el soloist 13.10.2012 - 17:24
1

No estoy seguro de que haya ninguna investigación académica sobre cuándo puede ayudar la desnormalización (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 y entradas de blog interesantes sobre esto _ Jeff Atwood habla sobre la normalización en su blog , y hay un " responder " a Él en alta escalabilidad.

Al desnormalizar, te sugiero que prestes atención a

  • el número y el 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 las tablas 4-5, puede ser más rápido mantenerla en una tabla separada en lugar de copiarla tantas veces
  • la cantidad esperada de datos mantenidos en DB; lo que podría funcionar para pequeñas cantidades de datos, puede llevar a un desastre si aumenta el número de registros. Y viceversa (me refiero al principio KISS y no arreglar lo que no está roto).
respondido por el superM 13.10.2012 - 19:40
1
  

Me imagino que des-normalizar 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 te refieres al rendimiento de la consulta, eso es algo que generalmente se puede mejorar y no causa un problema real a menos que tengas un diseño inadecuado, recursos insuficientes, una base de datos extremadamente grande, un número muy grande de transacciones o todas. lo anterior. La mayoría de las aplicaciones que usan las bases de datos actuales rara vez tendrían un problema de rendimiento solo porque la base de datos está Normalizada.

  

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

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

  1. No tiene datos redundantes.

  2. No se debe crear una gran cantidad de enteritis de registro (por ejemplo, con una tabla de 2 millones de clientes: ACTUALIZAR país de conjunto de clientes="EE. UU." DONDE país="EE. UU.")

  3. Se admitirán completamente las consultas SQL. Este punto es muy importante.

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

  5. Fuerza un alto grado de coherencia de los datos a través de la base de datos sin cargar la aplicación.

  6. Comparta las reglas de negocios 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 particular, luego podría determinar, dado su comprensión de su dominio y su aplicación, para des-normalizar algunas de las tablas / columnas como una compensación por la velocidad. Sin embargo, eso sería una decisión consciente en lugar de una supervisión.

  

Dado un conjunto de FN de 3NF y un conjunto de consultas, ¿cómo puedo predecir la aceleración / desaceleración de la des-normalizació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 podrían conducir a un mal rendimiento por diseño. Por ejemplo, puede identificar qué estrategia de índice usar como sigue (pueden existir otras técnicas):

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

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

  3. Considere crear índices en esas columnas.

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

    
respondido por el NoChance 14.10.2012 - 05:17
1

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

Para predecir 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 serán 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, la parte que probablemente aún quedará en la memoria, la sobrecarga de planificación de las consultas complejas, etc. Este es un asunto muy complicado, específico para la implementación, y depende mucho de su base de datos y de su RDBMS. Estas ventajas serán mayores en las cargas de trabajo OLAP y, por lo general, las desventajas serán mayores en las cargas de trabajo OLTP.

Por lo tanto, no veo que haya una única respuesta aquí que no sea ver los planes de consulta y considerar la posibilidad de vistas materializadas para datos desnormalizados. Desde mi punto de vista, el mejor enfoque es tener una base de datos OLTP relativamente normalizada y desnormalizar para propósitos de informes solo cuando sea necesario.

    
respondido por el Chris Travers 24.02.2013 - 03:59
1

Normalmente, den-normaliza su modelo de datos para optimizar el rendimiento de un caso de uso particular . Esto generalmente tendrá un efecto adverso en el desempeño de otros casos de uso. p.ej. la repetición de datos en varias filas puede acelerar el procesamiento de consultas al eliminar una unión, pero el procesamiento de la 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 combinaciones y selecciones particulares, puede haber mejores modelos.

Así que trate la des-normalización como lo haría con cualquier otra optimización. es decir, no lo hagas a menos que realmente tengas un problema de rendimiento, y asegúrate de que tu 'corrección' no cause más problemas de los que resuelve.

    
respondido por el James Anderson 24.02.2013 - 06:13

Lea otras preguntas en las etiquetas