Entradas etiquetadas como Bases de Datos de Nube

El mundo de las bases de datos NoSQL

El escenario de las Bases de Datos

Fuente: The 451 Group

En un post anterior intentaba describir algunas alternativas de Bases de Datos de Nube. Específicamente me enfoqué en bases de datos con el modelo relacional: AmazonRDS, ClearDB, Xeround, Database.com, VoltDB, etc. Sin embargo no comentamos nada acerca del modelo alternativo: el NoSQL. Bajo este concepto se agrupan un buen número de productos de base de datos, con muy diversos modelos conceptuales y soluciones técnicas, cuyo denominador común es que no siguen el modelo de bases de datos relacional. No basan su gestión en el lenguaje SQL.

¿De qué se trata entonces el NoSQL? Bueno, lo que sucede es que estas soluciones han venido a llenar un importante carencia de las bases de datos relacionales en cuanto a la capacidad que estas tienen en escalabilidad, distribución y manejo de datos no estructurados. Estas 3 características resulta que son cada día más relevantes debido precisamente a la Nube; a los múltiples y diversos servicios cuyo crecimiento y replicación distribuida son extremadamente necesarios: ¿cómo estructurar, por ejemplo, la información almacenada por Google o Facebook? ¿cómo asegurar que nuestra información en la Nube siempre estará disponible? ¿cómo manejar el explosivo crecimiento de información y su variabilidad de formatos? En síntesis, ¿cómo manejar el problema de almacenamiento del Big Data?

De hecho, existen muy buenos artículos que detallan con profundidad el problema de las bases de datos relacionales. Recomiendo mucho que lean “NoSQL, NewSQL and Beyond” que presenta concisa pero analíticamente este problema de las bases de datos relacionales acuñando inclusive el término “STRAINED” (torcidas o exprimidas, en español) con las iniciales de cada uno de los problemas que tienen.

El hecho es que, a raíz de esta problemática han surgido los modelos NoSQL (y también, aunque menos conocidos, los NewSQL que se comentan en el artículo mencionado). Entre los principales modelos NoSQL y algunos productos insignia de cada modelo tenemos:

Modelo: Documental
Descripción: Guardan documentos textuales y/o XML, principalmente en formato JSON, con la finalidad de almacenar información con estructura laxa y cambiante. Ideal para servicios que requieren almacenar transacciones o datos enviados desde dispositivos móviles que usen JSON para intercambiar información.
Productos insigne: MongoDB (por mucho la BD NoSQL más usada en el mundo), CouchDB

Modelo: Almacén Llave-Valor (Key-Value Stores)
Descripción: Enfocadas en el almacenamiento de información de configuración o basada en arreglos asociativos (hashes). Su intención es guardar simplemente una gran serie de “llaves” con su valor asociado lo cual da una potente flexibilidad ante datos no estructurados.
Productos insigne: Redis, Amazon DynamoDB

Modelo: Orientadas a almacenamiento de Clusters Distribuidos – Big Tables
Descripción:
Orientadas en el almacenamiento de enormes cantidades de información desestructurada que es almacenada de manera distribuida en cientos o miles de clusters en localizaciones geográficas incluso distintas. Típicamente basadas en almacenamiento en innovadores sistemas de archivos y usando el cada día más relevante algoritmo Map-Reduce.
Productos insigne: Hadoop, HBase, Cassandra

Esos son los principales pero realmente están emergiendo modelos cada día más innovadores enfocados en retos distintos y con diferentes capacidades y orientaciones. De hecho, los modelos y productos descritos arriba tienen fronteras poco claras y por tanto varias características de un producto podrían clasificarlo dentro de otro modelo.

Todos estos modelos aprovechan la tendencia al “relajamiento” de la integridad de la información en beneficio de la replicabilidad y disponibilidad de la información. Por ejemplo, ¿han notado como Facebook en ocasiones no representa exactamente la misma información dependiendo de dónde o cómo accedamos a él? Eso es porque estos servicios “relajan” la integridad la cual hacen “eventualmente” consistente. Pero no siempre consistente en tiempo real.

Ello debido al Teorema de CAP que en esencia nos dice que la información, en un cluster distribuido y replicado, podrá estar siempre disponible o siempre consistente pero no ambas. Pero realmente, ¿a quién le interesa que Facebook o Twitter se tarden unos segundos o un par de minutos en hacer consistente la información? Casi a nadie. Lógicamente en ambientes empresariales la integridad y consistencia es esencial y por eso la gran solidez histórica de las bases relacionales.

Y es precisamente a la última frase del párrafo anterior que las bases de datos relacionales no solo no están muertas sino que son más importantes y relevantes que nunca. Las aplicaciones empresariales internas y estructuradas seguirán requiriendo de la integridad y estructura eficiente que este modelo privilegia. Las bases de datos relacionales seguirán teniendo vigencia, sin duda. Lo que pasa es que el modelo NoSQL viene a solventar otro tipo de necesidades de almacenamiento y recuperación de información que han aparecido en años recientes principalmente debido a los servicios de Internet, la Nube y la problemática del Big Data. En síntesis, ambos modelos pueden perfectamente coexistir y tener validez en los desarrollos de software. Simplemente que los Developers necesitaremos ser bilingües o, mejor dicho, políglotas para poder aplicar el modelo de base de datos correcto dependiendo de la necesidad de negocio específica que tengamos entre manos. El mensaje para el SQL y el NoSQL es “zapatero a tus zapatos”.

¿Y entonces.. con qué debo iniciar si quiero empezar a usar NoSQL? A menos que tu proyecto tenga realmente una problemática grande debido al enorme volumen de datos y distribución en clusters (en cuyo caso Hadoop o Cassandra podrían ser la vía) lo típico es que uno empiece usando el modelo documental (MongoDB es el líder; es el MySQL del mundo NoSQL) o el de Key-Value Stores (con Redis, por ejemplo).

Voilá!

, , , , , ,

3 comentarios

El escenario de las Bases de Datos de Nube

No me queda ninguna duda que el movimiento de Software-as-a-Service (SaaS) ha llegado para quedarse. Dicho de otro modo, que las aplicaciones en la Nube será el nuevo modelo de entrega de aplicaciones tanto de servicios de consumidor (a la manera de Facebook o Gmail) como de sistemas empresariales (a la manera de Salesforce.com). Lógicamente aún falta mucho por hacer y resolver para que todo esto se haga completa realidad en el ambiente empresarial. En particular, los temas de seguridad y accesibilidad (y velocidad) a la red son los principales problemas, al menos en Latinoamérica; aunque en ambos casos son cada día mejores los avances y menores las preocupaciones.

¿Y qué está pasando con el almacenamiento de datos? Mucha oferta e incertidumbre. Pues sí, aún se mantienen modelos y productos de bases datos sólidos y muy probados. MySQL sigue teniendo mucha “momentum” entre los developers como primera opción para el almacenamiento de los datos de sus aplicaciones. Sin embargo, cuando se habla de aplicaciones de Nube éstas deben ir de la mano de productos de bases de datos de Nube (DBaaS, por Database as a Service), que resuelvan principalmente los temas de elasticidad y escalabilidad. ¿Soluciones? Bien, pues básicamente tenemos dos enfoques: SQL y NoSQL. En este post abordaremos las alternativas basadas en el modelo relacional (SQL) y dejaremos para un post posterior el tema interesantísimo de las bases de datos clasificadas como NoSQL.

Importante mencionar que el modelo SQL está mejor orientado a aplicaciones empresariales internas cuyo modelo de datos es más estructurado; tales como las aplicaciones de procesos de negocios: ERP, SCM, CRM, etc. En cambio NoSQL está más asociado con el almacenamiento de datos externos a la empresa, más de tipo social o de analítica de datos externos. Es decir, donde el almacenamiento de información no tiene una estructura tan clara: datos Facebook, aplicaciones integradas a redes sociales o servicios móviles, almacenamiento de servicios de Nube al consumidor y/o de analítica de datos, almacenamiento de documentos JSON, etc. Claro; esto es solo una generalización porque la solución óptima dependerá de cada caso específico.

Bueno, como decíamos, MySQL sigue estando en un lugar de privilegio. Específicamente en cuanto a productos que le dan a MySQL las características de Nube, tenemos tres principales: Amazon RDS, Xeround y ClearDB. Todas ellas promocionadas como el MySQL para la Nube por lo que tienen la ventaja de un modelo probado y conocido pero con características de Nube. Otra buena alternativa desde un producto conocido es la solución provista por Heroku para la base de datos PostgreSQL. Bajo esta se provee de una base de datos PostgreSQL pero con el modelo Nube. Así que los developers que se han visto más cómodos desarrollando en Postgres que en MySQL pueden también hacer uso ya de características propias de Nube utilizando el servicio de Heroku.

También, como comenté en un post anterior, Database.com se presenta como el nuevo modelo de bases de datos para la Nube. Ofrece elasticidad y escalabilidad transparente así como una serie de herramientas para el Developer enfocadas en el desarrollo de servicios de Nube, móviles y sociales. Desventaja importante: no la puedes bajar e instalar en un ambiente local. Aunque esto último no es estrictamente necesario, ni siquiera recomendable en un ambiente de producción Nube, sí resulta conveniente para el Developer en ciertos contextos de desarrollo.

Además, existe un buen número de bases de datos relacionales que ofrecen características de escalabilidad y desempeño. La más interesante de todas es quizá VoltDB, del gurú de bases de datos Mike Stonebraker. Sin embargo, desde mi percepción resulta desventajoso que aún no tenga versión Nube 100% sino que aún maneja únicamente el modelo descargue-instale-use.

¿Qué hacer? Bueno, a diferencia de mis primeras opiniones positivas respecto al uso de Database.com, creo que esta base de datos es la mejor opción únicamente si tu aplicación estará instalado en la plataforma Force.com ó si tendrá interacción fuerte con esta. Particularmente si tienes servicios integrados con Salesforce. De lo contrario, veo desventajoso utilizar una base propietaria que no pueda ser transferida a otros contextos.

Me parece entonces que si eres un developer MySQL, lo mejor será utilizar alguna de las opciones de Nube. En mi opinión Xeround parece tener la mejor oferta técnica aunque habría que analizar con mayor profundidad si ClearDB o Amazon RDS están al mismo nivel. Y sólo recomendaría PostgreSQL si tu aplicación Nube está operando en Heroku. En este caso, lo mejor sería dejar un ambiente compacto completo en Heroku que es la plataforma que tiene una de las ofertas técnicas más sólidas en cuanto a PostgreSQL para la Nube (existen otras como EnterpriseDB, por ejemplo).

Sólo a manera de contexto sobre lo que estamos hablando, aquí un par de videos con un “vis a vis” de Database.com y Xeround (MySQL on the Cloud) :

Difícil, ¿eh? Y esto sólo tomando en cuenta el modelo relacional. Aún falta el modelo NoSQL que es todo un mundo complejo e interesante para el uso de almacenamiento de servicios Nube. En otro post abordaremos este tema.

, , , , , ,

1 comentario