Bases de Datos ideadas para gestionar grandes volumenes

16 replies [Último envío]
Imagen de carlos
Offline
Joined: 28/12/2005
Puntos: 1620

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.

AdjuntoTamaño
bigtable-osdi06.pdf216.03 KB
Hypertable-vs-Oracle.pdf317.72 KB
Imagen de Crono
Offline
Joined: 21/06/2009
Puntos: 123

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...

Imagen de carlos
Offline
Joined: 28/12/2005
Puntos: 1620

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".

Imagen de Crono
Offline
Joined: 21/06/2009
Puntos: 123

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)... :-)

 

picanteverde (no verificado)

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

 

Imagen de carlos
Offline
Joined: 28/12/2005
Puntos: 1620

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.

picanteverde (no verificado)

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

Imagen de carlos
Offline
Joined: 28/12/2005
Puntos: 1620

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..

Imagen de Oscar_paredes
Offline
Joined: 23/07/2006
Puntos: 136

Enhorabuena por el artículo, muy muy interesante!

Lo estudiaremos con cariño!

Oscar

Imagen de carlos
Offline
Joined: 28/12/2005
Puntos: 1620

Enlazo un interesante resumen comparativo entre bases de datos NOSQL: Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison

Joined: 18/05/2018
Puntos: 3

Para quienes se inician en el uso de MongoDB comparto con ustedes el vínculo del video tutorial MongoDB en 20 minutos https://www.youtube.com/watch?v=c8n6JsQuX2A

En este se explica desde su descarga, instalación, configuración, ejecución y uso. Es importante no solo instalarlo sino crear las carpetas data y db en el directorio raíz para empezar a operar, ya que esta es una omisión que puede hacer que no se avance cuando se está utilizando por primera vez (ver minuto 1:20)

Además de procedimientos prácticos incluye teoría clara y precisa. Se abordan los temas: crear bases de datos, crear colecciones, insertar documentos, eliminar colecciones, eliminar bases de datos, editar documentos, eliminar documentos, realizar consultas generales y específicas.

Offline
Joined: 26/05/2010
Puntos: 14

¡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?

Imagen de carlos
Offline
Joined: 28/12/2005
Puntos: 1620

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.

Imagen de ibett
Offline
Joined: 27/10/2015
Puntos: 1

hola buenas noches:

es muy interesenta todo este tema, sobre todos de los manejadores de BD, para tal cantidad de informacion, me intriga un parte de MongoDB, he escuchado muchas ventajas y bondades sobre ella, pero me surge la duda y que desventajas puede tener con la implantacion? otro tema que tengo duda he leido en articulos que las consultas suelen ser muy lentas .... al no tener Joins en MongoDB no existe ninguna posibilidad de que Joins como en una base de datos relacional. Esto significa que cuando se necesita este tipo de funcionalidad, es necesario hacer varias consultas y unirse a los datos de forma manual dentro de su código (que puede conducir a reducir la velocidad, el código disfuncional, y la reducción de la flexibilidad, cuando los cambios en la estructura)...

alguien puede compartirme mas sobre el tema? 

 

Héctor Alarcón (no verificado)

Desventajas de MongoDB

  • Uso de la memoria. Como MongoDB almacena el nombre de la clave junto con cada documento, naturalmente consume más memoria. Además, como las consultas y uniones lentas no son posibles porque es necesario realizar una combinación dentro del código, a menudo debe tratar con datos duplicados.
  • No usa joins. Al igual que una base de datos relacional, las uniones simplemente no son posibles en MongoDB. Sin embargo, existe una alternativa que es $lookup
  • Es tecnología nueva. MongoDB no está tan ampliamente documentado o probado y también carece de la disponibilidad de soporte y expertos.
  • Seguridad. Falta de seguridad y regularidad. No ofrece integridad de la información

Respecto a tu comentario sobre los join, las bases de datos orientadas a documentos como MongoDB están diseñadas para almacenar datos desnormalizados. Idealmente, no debería haber relación entre colecciones. Si la misma información es requerida en dos o más documentos, debe repetirse. MongoDB 3.2 introduce el operador $lookup que puede realizar una operación parecida a un LEFT OUTER JOIN en dos o más colecciones.

$lookup solo se permite en operaciones de agregación, que son atributos adicionales para filtrar y agrupar un resultado. MongoDB $lookup no es un sustituto de la cláusula JOIN más poderosa que se ofrece en SQL. Tampoco MongoDB ofrece restricciones de integridad referencial.

Encontré este documento donde se comparan tiempos de ejecución entre Oracle (SQL) y MongoDB (NOSQL).
La base de datos NoSQL es más rápida que la base de datos SQL al actualizar y eliminar registros, es más flexible y puede almacenar grandes cantidades de datos con facilidad aunque también tiene sus desventajas.

 

Joined: 18/05/2018
Puntos: 3

Dentro de las alternativas de bases de datos podemos clasificarlas en bases de datos estructuradas o bases de datos SQL y bases de datos no estructuradas o bases de datos NoSQL.

Una base de datos estructurada puede definirse como:

Una colección de elementos de datos organizados en un conjunto de tablas formalmente descritas desde la que se puede acceder a los datos […] es un conjunto de tablas que contienen datos provistos en categorías predefinidas. Cada tabla (que a veces se llaman ‘relación’) contiene una o más categorías de datos en columnas. Cada fila contiene una instancia única de datos para las categorías definidas por las columnas. (TechTarget, 2015)

Las bases de datos no estructuradas también se denominan bases de datos NoSQL:

Las bases de datos NoSQL son sistemas de almacenamiento de información que no cumplen con el esquema entidad–relación. Tampoco utilizan una estructura de datos en forma de tabla donde se van almacenando los datos sino que para el almacenamiento hacen uso de otros formatos como clave–valor, mapeo de columnas o grafos. (Acens, s.f.)

Referencias:

Acens. (s.f.). Bases de datos NoSQL: qué son y tipos que nos podemos encontrar. Recuperado de https://www.acens.com/wp-content/images/2014/02/bbdd-nosql-wp-acens.pdf

TechTarget. (Enero de 2015). Base de datos relacional. Recuperado de https://searchdatacenter.techtarget.com/es/definicion/Base-de-datos-rela...

Joined: 18/05/2018
Puntos: 3

Ampliando las referencias de bases de datos estructuradas y no estructuradas anexo dos tablas con alternativas comerciales y libres actuales:

Referencias:

Castillo Zúñiga, I. (s.f. a). Data Warehousing e Inteligencia de Negocios: Unidad I. Introducción a los sistemas de gestión de base de datos [Apuntes de curso]. Universidad Cuauhtémoc Aguascalientes.

Castillo Zúñiga, I. (s.f. b). Data Warehousing e Inteligencia de Negocios: Unidad II. Bases de Datos NoSQL [Apuntes de curso]. Universidad Cuauhtémoc Aguascalientes.

 



 

  BI   |    CRM     |    CMS    |    Tendencias en software empresarial    |    Cloud computing  |    Software libre    |   Internet    |    Movilidad y apps