database - Desnormalización: ¿cuánto es demasiado?

database-design cassandra (3)

Diseñar un esquema para cassandra es muy diferente a diseñar un esquema para una base de datos sql. Con una base de datos sql, sus datos caben en una máquina, la base de datos mantendrá los índices por usted, puede realizar combinaciones, y puede realizar consultas complejas con sql. Todos estos hacen que la normalización de datos sea práctica.

En cassandra, sus datos no caben en una máquina, por lo que no puede realizar uniones, la única consulta que puede hacer de manera eficiente es obtener un rango de columnas en una clave, y cassandra solo mantendrá índices limitados para usted. Esto hace que la normalización de sus datos sea poco práctica.

En cassandra, normalmente diseña su esquema para atender las consultas que va a realizar, y se desnormaliza para hacerlo. Mi ejemplo favorito de esto es lo que Twitter hace por sus estadísticas para rainbird, como se explica en esta publicación ,

For example, say someone clicks on a t.co link to blog.example.com/foo at 11:41am on 1st Feb. Rainbird would increment counters for: t.co click: com (all time) t.co click: com.example (all time) t.co click: com.example.blog (all time) t.co click: com.example.blog /foo (all time) t.co click: com (1st Feb 2011) t.co click: com.example (1st Feb 2011) t.co click: com.example.blog (1st Feb 2011) t.co click: com.example.blog /foo (1st Feb 2011) t.co click: com (11am-12 on 1st Feb) t.co click: com.example (11am-12 on 1st Feb) t.co click: com.example.blog (11am-12 on 1st Feb) t.co click: com.example.blog /foo (11am-12 on 1st Feb) t.co click: com (11:41-42 on 1st Feb) t.co click: com.example (11:41-42 on 1st Feb) t.co click: com.example.blog (11:41-42 on 1st Feb) t.co click: com.example.blog /foo (11:41-42 on 1st Feb)

Este 1 clic se copia 16 veces para satisfacer las 16 consultas que se pueden hacer.

Esta es una buena presentación sobre cómo hacer indexación en Casandra .

He diseñado la base de datos para la aplicación web que estoy construyendo "por el libro". Es decir, he:

Creó un diagrama ER que contiene las entidades, los atributos y las relaciones de la aplicación
Traducido al diagrama de ER en un esquema
Se tradujo el esquema en una forma "sin esquema" para modelar la base de datos con (la base de datos es una base de datos Cassandra (NoSQL)).

Todo va bien (hasta ahora). Me he desnormalizado antes con excelentes resultados, y actualmente estoy implementando una parte de la aplicación que utilizará datos que aún no se han desnormalizado. Al hacerlo, para esta parte en particular, pronostico, aumentará el rendimiento de forma sustancial (leyendo de 1 Column_Family ("tabla" en el mundo relacional) en lugar de 7).

Sin embargo, me temo que puedo estar desnormalizando demasiado. Si tuviera que hacerlo para la parte en cuestión, reduciría en gran medida el conteo de Column_Family / table en mi aplicación en un 20%, y tener esa gran parte de mi base de datos desnormalizada me pone nervioso por alguna razón.

Si la aplicación termina siendo lo suficientemente exitosa como para poder incorporar a un diseñador o administrador de bases de datos, me gustaría que él determine que la desnormalización que estoy realizando es necesaria para el rendimiento que estoy buscando (el mejor caso) o al menos no dañino (el peor de los casos).

¿Hay cosas específicas que debería tener en cuenta al tomar decisiones de desnormalización que pueden indicar si hacerlo sería malo o siempre se reduce a la velocidad frente a la capacidad de mantenimiento?

En general, quiere tanta normalización como pueda tolerar, especialmente con relación a las tablas que cree que serán más grandes. Me he salteado la normalización de conjuntos de datos muy pequeños o datos directamente relacionados, pero nunca para mejorar los motivos de rendimiento (para eso sirven los servidores de informes y ETL); Considero que el esfuerzo adicional en el diseño y el reingreso a mesas muy pequeñas, directamente relacionadas y que rara vez cambian, es una pérdida de tiempo desde una perspectiva de desarrollo.

Mi mayor preocupación con la desnormalización es la integridad de los datos y el desperdicio de espacio (en el disco y la memoria) en ese orden.

Mi única preocupación con la normalización es la mantenibilidad; hacer que algo muy simple sea mucho más complejo de lo que realmente debe ser, en general es infructuoso. La normalización por el bien de la normalización es fanática en lo que a mí respecta y solo los Sith tratan en términos absolutos.

La desnormalización en aras del rendimiento no es algo malo. Lo que debe considerar son los objetivos de su aplicación / base de datos, y cómo la normalización puede ayudarlo a alcanzarlos.

En primer lugar, poner una tabla en 1NF implica eliminar datos redundantes o (Coronel, Rob 2009) "grupos de repetición". La eliminación de datos en múltiples ubicaciones (ya sean otras tablas o filas) es algo bueno, y ayuda con el mantenimiento, la integridad de los datos y el rendimiento.

Llegar a 2NF implica eliminar dependencias parciales. Existen dependencias parciales cuando tiene una clave compuesta (clave principal compuesta de múltiples campos clave) y campos cuyo valor está determinado por solo una o parte de la clave. Normalmente, la eliminación de dependencias parciales es cuando comienza a ver tablas puente creadas para manejar relaciones de muchos a muchos.

3NF es un paso más, ya que elimina todas las dependencias transitivas, o campos que dependen del valor de los campos que no son clave. Este paso es uno que a menudo es negociable en nombre del rendimiento. Dependiendo del tamaño o la varianza de los valores de los campos transitivos, querrá ponderar los desafíos de mantener esos valores en la tabla, frente a la frecuencia con la que tendrá que INSCRIBIRSE para obtenerlos.

El resultado final, la eliminación de datos redundantes y los datos dependientes (parciales y transitivos) es algo bueno. Pero no dejes que te impida hacer lo que tiene sentido para tu aplicación.

C. Coronel, P. Rob (2009), "Sistemas de bases de datos: implementación y gestión del diseño", Course Technology, Boston, MA (Capítulo 5)