database - ¿De qué manera la desnormalización mejora el rendimiento de la base de datos?

performance database-design (8)

Escuché mucho acerca de la desnormalización que se hizo para mejorar el rendimiento de ciertas aplicaciones. Pero nunca he tratado de hacer algo relacionado.

Entonces, solo tengo curiosidad, lo que coloca en DB normalizada empeora el rendimiento o, en otras palabras, ¿qué son los principios de desnormalización?

¿Cómo puedo utilizar esta técnica si necesito mejorar el rendimiento?

Considere una base de datos con una relación padre-hijo correctamente normalizada.

Digamos que la cardinalidad es un promedio de 2x1.

Tienes dos tablas, principal, con p filas. Niño con 2x p filas.

Los medios de operación de unión para las filas p primarias, se deben leer 2x p filas secundarias. El número total de filas leídas es p + 2x p .

Considere la desnormalización de esto en una sola tabla con solo las filas secundarias, 2x p . El número de filas leídas es 2x p .

Menos filas == menos E / S física == más rápido.

La desnormalización es una compensación de tiempo y espacio . Los datos normalizados ocupan menos espacio, pero pueden requerir unirse para construir el conjunto de resultados deseado, por lo tanto, más tiempo. Si se desnormaliza, los datos se replican en varios lugares. Luego se necesita más espacio, pero la vista deseada de los datos está disponible.

Hay otras optimizaciones de espacio-tiempo, como

vista desnormalizada
columnas precalculadas

Al igual que con cualquiera de estos enfoques, esto mejora la lectura de los datos (porque están disponibles), pero la actualización de los datos se vuelve más costosa (porque necesita actualizar los datos replicados o precalculados).

La desnormalización generalmente se usa para:

Evite una cierta cantidad de consultas
Eliminar algunas combinaciones

La idea básica de la desnormalización es que agregará datos redundantes, o agrupará algunos, para poder obtener esos datos más fácilmente, a un costo menor; que es mejor para las actuaciones.

Un rápido ejemplos?

Considere una tabla de "Publicaciones" y "Comentarios", para un blog
- Para cada publicación, tendrá varias líneas en la tabla "Comentario"
- Esto significa que para mostrar una lista de publicaciones con la cantidad asociada de comentarios, deberá:
  - Haz una consulta para enumerar las publicaciones
  - Realice una consulta por publicación para contar cuántos comentarios tiene (Sí, pueden fusionarse en una sola, para obtener el número de todas las publicaciones a la vez)
  - Lo que significa varias consultas.
Ahora, si agrega un campo de "número de comentarios" en la tabla Publicaciones:
- Solo necesita una consulta para enumerar las publicaciones
- Y no es necesario consultar la tabla de Comentarios: la cantidad de comentarios ya está des-normalizada en la tabla de Publicaciones.
- Y solo una consulta que devuelve un campo más es mejor que más consultas.

Ahora, hay algunos costos, sí:

En primer lugar, esto cuesta un lugar en el disco y en la memoria, ya que tiene algunas informaciones redundantes:
- La cantidad de comentarios se almacena en la tabla Posts
- Y también puedes encontrar esos números contando en la tabla de Comentarios
En segundo lugar, cada vez que alguien agrega / elimina un comentario, debe:
- Guardar / eliminar el comentario, por supuesto
- Pero también, actualice el número correspondiente en la tabla Publicaciones.
- Pero, si tu blog tiene mucha más gente leyendo que escribiendo comentarios, probablemente esto no sea tan malo.

La palabra "desnormalización" conduce a la confusión de los problemas de diseño. Tratar de obtener una base de datos de alto rendimiento desnormalizando es como tratar de llegar a su destino alejándose de Nueva York. No te dice qué camino tomar.

Lo que necesita es una buena disciplina de diseño, que produzca un diseño simple y sólido, incluso si ese diseño a veces entra en conflicto con las reglas de normalización.

Una de esas disciplinas de diseño es el esquema de estrella. En un esquema en estrella, una sola tabla de hechos sirve como centro de una estrella de tablas. Las otras tablas se llaman tablas de dimensiones, y están en el borde del esquema. Las dimensiones están conectadas a la tabla de hechos por relaciones que se parecen a los radios de una rueda. El esquema de estrella es básicamente una forma de proyectar el diseño multidimensional en una implementación de SQL.

Estrechamente relacionado con el esquema de estrella está el esquema de copo de nieve, que es un poco más complicado.

Si tiene un buen esquema de estrella, podrá obtener una gran variedad de combinaciones de sus datos con solo tres combinaciones, que involucran dos dimensiones y una tabla de hechos. No solo eso, sino que muchas herramientas OLAP podrán descifrar el diseño de su estrella automáticamente, y darle acceso de "apuntar y hacer clic", "profundizar" y de análisis gráfico a sus datos sin más programación.

El diseño del esquema en estrella ocasionalmente infringe las formas normales segunda y tercera, pero da como resultado más velocidad y flexibilidad para los informes y extractos. Se usa con mayor frecuencia en data warehouses, data marts y bases de datos de informes. Por lo general, obtendrás mejores resultados del esquema de estrella o de algún otro diseño orientado a la recuperación que de la "desnormalización" fortuita.

Los problemas críticos en la desnormalización son:

Decidir qué datos duplicar y por qué
Cómo planear cómo mantener los datos sincronizados
Refactorización de las consultas para usar los campos desnormalizados.

Uno de los tipos más sencillos de desnormalización es llenar un campo de identidad en tablas para evitar una unión. Como las identidades nunca deberían cambiar, esto significa que la cuestión de mantener los datos sincronizados rara vez aparece. Por ejemplo, completamos nuestro ID de cliente en varias tablas porque a menudo necesitamos consultarlas por cliente y no necesariamente necesitamos, en las consultas, ninguno de los datos en las tablas que estarían entre la tabla del cliente y la tabla que estamos consultando. si los datos fueron totalmente normalizados Todavía tiene que hacer una combinación para obtener el nombre del cliente, pero es mejor que unirse a 6 tablas principales para obtener el nombre del cliente cuando ese es el único dato que necesita fuera de la tabla que está consultando.

Sin embargo, no habría ningún beneficio a menos que a menudo estuviéramos haciendo consultas donde se necesitaban datos de las tablas intermedias.

Otra desnormalización común podría ser agregar un campo de nombre a otras tablas. Como los nombres son inherentemente modificables, debe asegurarse de que los nombres permanezcan sincronizados con los desencadenantes. Pero si esto le ahorra unirse a 5 tablas en lugar de 2, puede valer la pena el costo de la inserción o actualización un poco más larga.

Según la última sección de este artículo,

https://technet.microsoft.com/en-us/library/aa224786%28v=sql.80%29.aspx

se podría usar la virtualización virtual, donde se crean vistas con algunos datos desnormalizados para ejecutar consultas SQL más simples más rápidamente, mientras que las tablas subyacentes se normalizan para operaciones de adición / actualización más rápidas (siempre que se pueda actualizar las vistas a intervalos regulares) que en tiempo real). Estoy tomando una clase en Bases de datos relacionales pero, por lo que he estado leyendo, este enfoque me parece lógico.

Si tiene ciertos requisitos, como informes, etc., puede ayudar a desnormalizar su base de datos de varias maneras:

introducir cierta duplicación de datos para ahorrarse algunos JOINs (por ejemplo, llenar cierta información en una tabla y estar bien con los datos duplicados, de modo que todos los datos en esa tabla y no necesitan encontrarse uniéndose a otra tabla)
puede calcular previamente ciertos valores y almacenarlos en una columna de tabla, además de calcularlos sobre la marcha, cada vez que consulte la base de datos. Por supuesto, esos valores calculados pueden volverse "obsoletos" con el tiempo y es posible que tenga que volver a calcularlos en algún momento, pero simplemente leer un valor fijo suele ser más económico que calcular algo (por ejemplo, contar filas secundarias).

Sin duda, hay más formas de desnormalizar un esquema de base de datos para mejorar el rendimiento, pero solo debe tener en cuenta que se puede meter en un cierto grado de dificultad para hacerlo. Debes sopesar cuidadosamente los pros y los contras: los beneficios de rendimiento frente a los problemas en los que te encuentras cuando tomes esas decisiones.

Beneficios de la desnormalización sobre la normalización

Básicamente, la des-normalización se usa para DBMS no para RDBMS. Como sabemos, RDBMS funciona con normalización, lo que significa que no se repiten datos una y otra vez. Pero aún repita algunos datos cuando usa una clave externa.

Cuando usa DBMS, entonces hay una necesidad de eliminar la normalización. Para esto, hay una necesidad de repetición. Pero aún así, mejora el rendimiento porque no hay relación entre las tablas y cada tabla tiene una existencia indivisible.