Sobre bases de datos orientadas a columnas

A la sombra del artículo del futuro de DBMS volvemos a cobijarnos. Y todo porque me he leído una serie de artículos sumamente interesantes y todos del mismo blog (ello ha motivado que automáticamente fuera a formar parte del blogroll): Database parallelism choices greatly impact scalability, Disk trends will drive the need for column stores, CPU trends, like disk trends, will favor adoption of column stores y Good things come in small packages: The advantage of compression in column databases. Hablamos en ese post, de tendencias y sobre el posible futuro e identificamos factores que condicionan nuestro futuro más cercano. Y el principal es la cantidad de información que generamos y que podemos almacenar a un coste que decrece cada seis meses. Es interesante que en el mundo del Business Intelligence donde por tradición se había apostado por DBMS basados en filas hayan aparecido (de un pasado no muy lejano) ahora bastantes basados en columnas (y atención muchos de ellos open source, ¿será por la necesidad de innovación frente mercados tan competitivos y crear un un nicho de mercado libre para crear ventaja competitiva?). Entre sus ventajas se enumeran:

• Mejor rendimiento.
• Eficiencia en el almacenamiento.
• Cambios en el esquema tiene menor impacto y por lo tanto el coste de realizarlos es menor.

¿Para qué tipo de servicio pensáis podemos beneficiarnos de este tipo de base de datos?

Nueva sección

Dado que a veces es complicado decidirse por libros para introducirse en los diferentes temas que se tratan en este blog, he decidido crear una nueva sección en la que recomiendo libros en Amazon. En la barra lateral encontrareis el botón de acceso llamado libros recomendados.

Espero que os sea de utilidad.

Las 12 leyes de OLAP

Cuando recordamos la definición de OLAP hace bastante tiempo (tras este largo paréntesis de escribir en el blog por trabajo), teníamos ya en mente hablar en algún momento sobre las 12 leyes que acuñó Edgar F. Codd en 1993. Como ya se ha comentado anteriormente, necesitamos de listas, de leyes o de nociones de orden para movernos por el universo. Estas leyes son las que, en mayor o menor medida, intentan cumplir todos los fabricantes de software:

• Vista conceptual multidimensional: se trabaja a partir de métricas de negocio y sus dimensiones.

• Transparencia: El sistema OLAP debe formar parte de un sistema abierto que soporta fuentes de datos heterogeneas (lo que llamamos actualmente arquitectura orientada a servicios).

• Accesibilidad: Se debe presentar el servicio OLAP al usuario con un único esquema lógico de datos (lo que en definitiva, nos indica que debe presentarse respecto una capa de abstracción directa con el modelo de negocio).

• Rendimiento de reporting consistente: El rendimiento de los informes no debería degradarse cuando el número de dimensiones del modelo se incrementa.

• Arquitectura cliente/servidor: Basado en sistemas modulares y abiertos que permitan la interacción y la colaboración.

• Dimensionalidad Genérica: Capacidad de crear todo tipo de dimensiones y con funcionalidades aplicables de una dimensión a otra.

• Dynamic sparse-matrix handling. La manipulación de datos en los sistemas OLAP debe poder diferenciar valores vacíos de valores nulos y además de poder ignorar las celdas sin datos.

• Soporte Multiusuario.

• Operaciones cruzadas entre dimensiones sin restricciones: No deben existir limitaciones para las operaciones que Similar to rule of generic dimensionality; all dimensions are created equal, and operations across data dimensions should not restrict relationships between cells.

• Manipulación de datos intuitiva: Dado que los usuarios a los que se destinan este tipo de sistemas son frecuentemente análistas y altos ejecutivos, la interacción debe considerarse desde el prisma de la máxima usabilidad de los usuarios.

• Reporting Flexible: Los usuarios deben ser capaces de manipular los resultados que se ajusten a sus necesidades conformando reports. Además, cambios en el modelo de datos deben reflejarse automáticamente en esos reports.

• Niveles de dimensiones y de agregación ilimitados: No deben existir restricciones para construir cubos olap con dimensiones y con niveles de agregación ilimitados.