Bases de Datos ideadas para gestionar grandes volumenes

Con el crecimiento de internet, y de los proyectos web de mayor éxito, cada vez es más necesaria la utilización de bases de datos escalables y que sean capaces de gestionar con agilidad ingentes volúmenes de información.

Muchas veces las bases de datos tradicionales no cumplen con los requisitos de estos sistemas, o al menos no cumplen con un coste razonable, y así entran en juego proyectos de bases de datos open source especificamente orientadas a cubrir este vacío.

Un caso que ya hemos comentado es el de Cassandra DB, una base de datos distribuida de software libre que ya utilizan Digg, Facebook y Twitter.

Ahora acabo de encontrarme con otro proyecto que también promete bastante. Se trata de Hypertable, otro sistema de almacenamiento de datos Open Source y distribuido que anuncia un máximo rendimiento y escalabilidad para tratar grandes cantidades de datos. Tiene soporte comercial en www.hypertable.com y allí nos cuentan que ya lo utilizan buscadores como Baidu, Rediff.com o Zvents

Parece ser que el diseño de estos sistemas se inspira en el proyecto Bigtable, que creó Google para poder gestionar la gran cantidad de datos que mueven las aplicaciones y proyectos que van creando. Adjunto un pdf que proporciona Google con información sobre este proyecto.

Alguien ha probado Hypertable, o sabe algún caso más de utilización de este sistema de almacenamiento? Conocéis otras bases de datos o sistemas similares?

Adjunto también un documento de un test de rendimiento realizado por unos laboratorios de temas energéticos que se planteaban la sustitución de Oracle por Hypertable, y donde también se hace mención de Bigtable y GFS.

Qué interesante. Espero encontrar el momento para leer el adjunto, lo he mirado por encima y sin duda que merece una lectura detallada...

 

Respecto este tipo de base de datos, creo que su necesidad surge no tanto por los requerimientos de volumetría y escalabilidad como por el tipo de consultas que se realizan. Es decir, el tipo de queries que lanza Google, Facebook, Twitter o Digg son muy particulares, y no se asemejan a las consultas OLPT o las consultas OLAP a las que estamos habituados.... Por este motivo, nos necesarias estas bases de datos tan particulaes... Creo...

En respuesta a por Crono

Pues yo sigo pensando que la razón principal es poder obtener un buen rendimiento con grandes volúmenes de datos. Creo que el tipo de consultas, seguramente más simples, y sin necesidad de control transaccional es lo que permite desarrollar este tipo de soluciones orientadas a la eficiencia en las consultas sobre grandes volúmenes de datos. Por algo el proyecto de Google se llama Bigtable, no?

Yo veo en este sistema similitudes con los antiguos sistemas de almacenamiento en ficheros, antes de que aparecieran las bases de datos relacionales, y también con las estructuras OLAP. Son estructuras desnormalizadas, que se ordenan alfabéticamente por un campo clave para permitir el particionamiento físico de los datos, la distribución y las consultas eficientes, y que además incluyen un campo de fecha.

A mi me recuerdan mucho a una tabla de hechos de un Data Warehouse, y la siguiente pregunta que me viene a la cabeza es ¿qué pasaría si utilizáramos estos sistemas para soportar estructuras de DWH? Uno de los principales problemas que nos encontramos con gran parte de los proyectos de Business Intelligence, o al menos con los más grandes, es poder controlar el crecimiento de las tablas de hechos, y la escalabilidad suele estar limitada a la capacidad de los clústers que podamos crear en un CPD. Está claro que una solución distribuída de este tipo ampliaría mucho los límites físicos que nos hemos encontrado siempre en cuanto a volumetría.

¿Alguien sabe si ya se está haciendo? ¿Puede ser este tipo de arquitectura la que hay detrás de los sistemas Saas de Business Intelligence que van apareciendo?

 

Dejo una captura de la tabla que incluye el pdf con las características de algunas tablas de Bigtable que Google utilizaba en producción para varios de sus proyectos en el 2006. Las cifras ya eran impresionantes, y lo que habrán aumentado en 4 años de crecimiento..

Volumetría de Objetos Bigtable que soportan proyectos de Google en producción

 

Me parecen impresionantes también los datos que aportan en el apartado 7 sobre la evaluación de rendimiento que hicieron antes de poner el sistema en producción. Para el test utilizaron la friolera de 1786 máquinas con GFS, más los servidores del cluster de Bigtable:

 "We set up a Bigtable cluster with N tablet servers to measure the performance and scalability of Bigtable as N is varied. The tablet servers were configured to use 1 GB of memory and to write to a GFS cell consisting of 1786 machines with two 400 GB IDE hard drives each".

En respuesta a por Carlos

Ya he hecho la primera lectura del documento (y sin duda es necesario releerlo varias veces para entenderlo bien)...

 

Es evidente que el tamaño y los elevados requerimientos de rendimiento justifican por si solo una estructura de datos tan particular. Sin embargo, también el tipo de aplicación es muy particular, y no se trata de una solución de almacenamiento "multipropósito"..

 

Para empezar, se renuncia a la transaccionalidad, y admiten que sistemas tan distribuidos son vulnerables a muchos tipos de fallos (que serian fatales en otro tipo de aplicaciones...). A Google, por ejemplo, no debe importarle demasiado que se "pierdan" un porcentaje de sus rastreos (o de la sesiones de Google anlytics, o...). Otra desventaja evidente es sólo se puede acceder a la información a través del API (ni SQL ni nada parecido...), lo que dificultaría la ejecución de consultas ad-hoc tan habituales en sistemas BI....

 

Los tipos de consultas también son muy particulaes, aunque he de reconocer que el modelo de datos y el tipo de consulta de Google analytics no parece nada particular. Es decir, ¿Se podrían obtener resultados similares con DWH de Google Analytics más ortodoxo? Yo creo que sí (200Tb no son tantas... ¿no?)...

 

Respecto el modelo de datos, me quedo con la idea de que la BigTable no consiste en filas y columnas como estamos acostumbrados, sino que cada fila contiene información estructurada de un "hecho"... Es decir, cada celda puede contener listas de valores o estructuras más complejas (se parece, como dices, a los antiguos sistemas de almacenamiento en ficheros, tipo COBOL, o los más modernos XML...). De esta manera, por ejemplo, el registro de Google que contiene este comentario que estoy escribiendo contiene también todos los enlaces salientes y entrantes de esta páginas, y muy cerca están todas las páginas de DATAPRIX, y toda la información relativa a este dominio... En un sistema relacional clásico, esto no seria ni mucho menos así...

 

Preguntabas si estructuras parecidas se podrían emplear en DWH conveniconales, y evitaré contestarte porque me da la sensación que ya he especulado bastante en este comentario (mucho más que lo que me permite mi conocimiento sobre el tema)... :-)

 

Buenas, que bueno leer sobre NO-SQL esto en mi blog favorito de BI, para resumir BI es mi trabajo, y NO-SQL ues mi hobbie. Personalmente pienso que hay mucho potencial en las plataformas NO-SQL o bbdd orientadas a documentos. Entre los proyectos que revisé, además de CassandraDB pude ver que hay mucho desarrollo al rededor de couchDB y mongoDB.

  • Creo que el que mejores oportunidades ofrece es mongoDB ya que estube haciendo algunas pruebas y dejenme comentarles los mejores puntos:
  • Orientado a documentos: la orientación a documentos permite desarrollos rápidos, flexibles, y rápidamente adaptables a distintas situaciones. Está es claramente una ventaja para los desarrolladores en estas plataformas, que puede inclinar la balanza de manera importante frente a nuevos desarrollos.
  • Facilidad de uso: a 4 horas de haber leido el nombre en google, tenía un sharding (de maquinas virtuales) corriendo una base de datos en muchos shards al mismo tiempo.
  • Alta, alta, escalabilidad: la arquitectura de mongoDB esta pensada para no tener ningun cuello de botella.
  • Procesamiento distribuido: uno está más en control del procesamiento distribuido, gracias a la implementación de map reduce, en javascript
  • Lenguaje, y Objetos: basado en JavaScript (the world most popular lenguage) y orientado a objetos, es facil de aprender y de conceptos claros y solidos, muy aparejados a conceptos del mundo de la programación, lo que facilita su aprendisaje y compreension.

Realmente les recomiendo que le den una chance

Saludos

 

En respuesta a por picanteverde (no verificado)

Ya tenemos dos nuevas base de datos NO-SQL para examinar, gracias por tu aportación.

He echado un vistazo a mongoDB y la sensación es lo que comentas, que es fácil comenzar a trabajar con él. Me ha encantado el tutorial intereactivo que se han montado, te va explicando lo básico paso a paso, y debajo mismo de cada explicación puedes probar directamente en la misma linea de comandos, sencillo y eficiente.

Tutorial web por linea de comandos de MongoDB

Lo que estaría bien saber es si hay algún proyecto importante que lo esté utilizando, los casos de éxito siempre son una buena manera de hacerte una idea del alcance de los productos de software.

 

Aprovecho para añadir otra base de datos más a la lista. Se trata de HBase, otra base de datos open source distribuída y orientada a columnas que surgió inspirándose en la Bigtable de Google.

De hecho está dentro del proyecto Hadoop de la Apache Software Foundation, y se apoya en HDFS (Hadoop Distributed File System), el sistema de ficheros que se ha desarrollado en este proyecto ideado para sistemas que han de manejar grandes cantidades de información, y que también está inspirado en el GFS de Google.

En respuesta a por Carlos

Carlos revisando la página de casos de exito de mongo encontré que entre los más conocidos se pueden destacar:

sourceforge: estaría usando mongo db como solución completa de almacenamiento y no solamente para un sistema aislado

github: Muy conocida dentro del entorno de desarrolladores open source. estarían utilizandolo en una app de reportes.

EA y The New York Times: estarían haciendo pruebas en algunos sistemas aislados con grandes requerimientos de datos y estructuras no definidas.

 

Lo cual por pequeño que parezca tenemos que considerar que el sistema lleva solamente un año de desarrollo y su primer version estable lista para producción fue lanzada el 25 de marzo de 2010, asi es!!! 2010!!!.

Por lo que podemos esperar un rapido desarrollo y una comunidad altamente activa en torno al mismo.

Te comento que hice algunas pruebas con hadoop y terminaron en .... nada me fue realmente complicado levantar hadoop en una estructura de maq virtuales. por el contrario tuve un shard de mongodb de 6 maquinas corriendo en 4hrs

 

Saludos

En respuesta a por picanteverde (no verificado)

No había visto esta página. Realmente la lista es larga, y con nombres importantes, un buen comienzo si hace tan poco tiempo que se ha lanzado la primera versión estable.

Habrá que estar atentos a su evolución, seguro que dará mucho que hablar.

Y eso de que lo hayas montado en tan poco tiempo me está empezando a picar. Si encuentro el momento (o más bien las horas) a lo mejor hago algún intento..

¡Herejes! Frank Codd se tiene que estar revolviendo en su tumba. ^_^

Me parece muy interesante el artículo, había oido hablar de este tipo de almacenamiento de información pero no había leído nada. No obstante, me da la impresión de que al final es como tener un gran tabla con toda la información desnormalizada que está organizada de manera jerárquica como las estructuras de inodos de los sistemas UNIX.

Hablo desde mi casi total desconocimiento de este tipo de repositorios que conste, he mirado MongoDb a raíz de los enlaces que habéis propuesto.

Lo tiene muy difícil contra el "Standard" Query Language, a parte de que las herramientas de explotación de datos tendrán que ser a medida claro. Con lo que la pasta que se ahorra uno en una licencia de un RDMS y en la herramienta de reporting se emplea en crear una herramienta de explotación de información desde cero, ¿me equivoco?

En respuesta a por cmateos

No creo que la intención de estos sistemas sea la de sustituir totalmente a los Gestores de Bases de datos Relacionales. Son una solución más adecuada bajo determinadas circunstancias, y su principal ventaja es la escalabilidad para soportar la gestión de muy grandes cantidades de datos.

El caso más claro es el de las grandes redes sociales, que están moviendo cada segundo cantidades de información que marean, y siguen creciendo.. Soportar esa escalabilidad con motores relacionales con licencia de pago puede llegar a salir muy caro, mucho más de lo que cuesta un desarrollo a medida.

Bajo mi punto de vista la discusión estaría en si en un entorno empresarial que mueva una cantidad importante de datos, pero no del nivel de redes sociales como Facebook o Twitter merece la pena optar por este tipo de soluciones NOSQL. 

Y aquí, respondiendo en parte a lo que comentas sobre herramientas, vemos que el Business Intelligence ya comienza a 'fijarse' en las plataformas de gestión de big data para soportar soluciones de BI. Pongo como ejemplo el caso de Pentaho de quienes justo hace unos días Stratebi publicaba en Dataprix el post Recursos sobre Pentaho y su integración con Apache Hadoop.

Si alguien conoce algún ejemplo más, que lo comparta, porque seguro que es un tema en el que vamos a ver muchas novedades a lo largo de este año.