En este caso, aunque he hablado en otras ocasiones de CouchDB, de Cassandra, etc. me ha llamado la atención MongoDB. Esta base de datos realizada en C++, que cuenta, entre sus principales características con ser una base de datos de esquema libre, de alto rendimiento y orientada a documentos.

Coincide que ayer se liberó la versión 2.0.1, aunque no comentaré las nuevas mejoras, sino en sí, lo que hace MongoDB.

Acceso a Datos

El sistema de MongoDB es de esquema libre. Esto quiere decir que no requiere de una definición previa de datos, es decir, de hecho, los datos que se almacenan en sus colecciones son heterogéneos completamente.

Mientras que una base de datos relacional, con tablas, se estructura en base de datos, tablas, tuplas y campos, una base de datos, como MongoDB, se estructura en base de datos, colección y datos. Esto quiere decir que, dentro de una colección podría poner el dato:

{ a: 1, b: 2, c: 3 }

Y acto seguido, agregar otro dato a la colección que sea:

{ a:2, [ {nombre: 'Manuel', apellido: 'Rubio', web: 'http://bosqueviejo.net'} ] }

Lo que sí es conveniente respetar, al menos, es el primer dato, ya que así las búsquedas son más fáciles, tanto para el sistema como para el usuario (o programador que realiza las consultas).

NoSQL… vale, ¿entonces qué?

En este tipo de base de datos, que son NoSQL, se emplean muchas técnicas para realizar búsquedas, pero MongoDB ha optado, quizás, por la más simple, que es integrar un lenguaje para esta tarea. Por lo que es posible realizar consultas estructurando la información que se pasa a nivel de criterio de búsqueda en…. ¡JavaScript!

Alguien me dijo que JavaScript era el lenguaje del futuro y, parece que al fin, ese futuro llegó, puesto que hay JavaScript en la programación web, como servidor a través de NodeJS, para el dialplan de FreeSwitch incluso… y ahora como lenguaje de consulta a una base de datos.

Entonces, vale, aceptamos JavaScript. Esto hace que las consultas se estructuren en hash (objetos realmente), de la siguiente forma:

db.cosas.find({'a': 2})

La estructura sigue el orden de db (como base de datos) y cosas (como colección de datos). Cada base de datos es un objeto que tiene como atributos sus colecciones y cada colección tiene a su vez una serie de métodos que le permiten realizar acciones con su conjunto de datos.

Buscar o Encontrar

Aunque hay otras base de datos NoSQL que solo sirven para encontrar (se debe de acceder por un identificador primario o el sistema debe de recorrer todo el conjunto de datos haciendo criba de los registros), MongoDB tiene mecanismos bastante buenos que le permiten realizar búsquedas bastante óptimas sobre el conjunto de datos heterogéneo. Algo tan simple como: la creación de índices.

Podemos crear índices sobre un campo que sepamos que seguramente estará en la mayoría del conjunto de datos (como por ejemplo a en el ejemplo expuesto) y así acelerar las búsquedas en este sentido.

Así mismo, el sistema en JavaScript permite realizar búsquedas basadas en rangos, o incluso con listas de inclusión de la siguiente forma:

db.cosas.find({ $or: [{ 'a': 1}, { 'a': 2}]});
db.cosas.find( {'a': { $gt: 0, $lte: 1 }});

Ambas consultas, por forma sacarían los dos registros que expusimos de ejemplo arriba, ya que en el primer caso, a puede tomar los valores 1 ó 2, y en el segundo caso a puede tomar valores mayores que cero y menores o iguales que uno.

Hay mucha, pero mucha, más información de esto en el manual oficial de MongoDB en su propia página.

Desde otros lenguajes

El sistema, realmente es una joya para la gente que programe en JavaScript y se haya lanzado a cosas como NodeJS y JavaScript MVC, ya que tendrán la posibilidad de realizar la búsqueda en JavaScript igualmente, y la integración con este lenguaje es la más clara de las que he podido ver (a nivel de envío de datos) ya que se estructura en base a la misma estructura que tiene JavaScript.

Por otro lado, hay implementaciones para PHP (la cual he podido ver más de cerca), C, C++, Erlang, Haskell, Java, JavaScript, .NET (C#, F#, PowerShell, etc), Perl, Python, Ruby y Scala, de los que da soporte directo MongoDB, y otros soportados por la comunidad como: ActionScript3, Clojure, ColdFusion, D, Delphi, Factor, Fantom, Go, Groovy, Lisp, Lua, MatLab, Objetive C, Prolog, R, Racket y Smalltalk.

Conclusiones

Me ha impresionado muy positivamente esta base de datos, las pruebas que he realizado, de cara a rendimiento y uso a través de objetos han sido muy fáciles y la integración muy clara y sencilla. Es una muy buena opción para la toma de datos heterogéneos, sin duda, pero también como base de datos escalable en el tiempo y de alto rendimiento.

Actualización 16/09/2011: se me olvidó comentar que SPOF significa, según sus siglas, Single Point Of Failure, algo así como el punto único de fallo. Se refiere a cuando un sistema, aún teniendo bastante redundancia, tiene un punto único, en la red, en el software o en alguna parte del sistema que, fallando, deja sin servicio a todo.

Como la mayoría de software realizado por empresas y que se adentran en el software libre, Riak tiene dos versiones, una Open Source (que es completa y funcional) y otra Enterprise (que agrega commodities -o facilidades- tales como una interfaz de administración).

La base de datos Riak está basada en el documento escrito por Amazon sobre el sistema de almacenamiento Dynamo, el cual se basa en un sistema de alta disponibilidad, con estructura de almacenamiento del par clave-valor y distribuido. Este documento ha sido seguido, además, por Cassandra (la base de datos de Facebook, liberada y acogida en el seno de la Fundación Apache, y que ha sido implementada desde entonces por Digg, Twitter, Reddit, Rackspace, etc.) y por Voldemort (la base de datos de LinkedIn).

Características principales

Riak, además de seguir las bases de Dynamo, ha agregado otras características propias a la lista, quedando (visto en su página web oficial) la siguiente lista de características a destacar:

• Escalabilidad: la escalabilidad con Riak es lineal, predecible y de coste efectivo. Agregar nuevas máquinas no significa tener una avalancha de de peticiones que ponga en peligro la efectividad del sistema. Se pueden ir agregando o eliminando máquinas sin mayor problema, y sin que suponga una carga excesiva para el sistema base.
• Tolerancia a fallos: el cluster soporta o admite fallos en nodos aislados, o incluso en partes del cluster, está preparado para no perder datos ante este tipo de fallos. El sistema ha sido diseñado con fallos de máquinas e interrupciones de servicio de red como norma, no como excepción.
• Alta disponibilidad: para alta disponibilidad el sistema debe de estar disponible, no solo para lecturas, sino también para escrituras. La arquitectura de share-nothing (nada compartido) hace que cada nodo en el cluster esté habilitado para realizar lecturas y escrituras, por lo que, la alta disponibilidad está garantizada.
• Replicación: dependiendo de las necesidades, Riak se puede configurar para replicar entre múltiples clusters iguales o diseñar uno o más clusters como solo-lectura o backup. Cada nodo en el cluster puede responder a las peticiones de lecutra/escritura, y el evento de replicación asegura que todos los clusters sean actualizados. Los algoritmos se ejecutan en cada nodo asegurando la consistencia de datos.

En base al teorema CAP del Dr. Eric Brewer, las tres propiedades deseadas de un sistema distribuido son: consistencia, disponibilidad y partición (tolerancia a fallos). El teorema establece que puedes solo puedes tener dos de las tres propiedades en cada momento. Riak se enfoca en Disponibilidad y Partición. Esta elección pone a Riak en el campo de la consistencia eventual. Sin embargo, la ventana para consistencia eventual es en términos de milisegundos, lo que es suficiente para la mayoría de aplicaciones.

¿Cómo funciona?

No me quiero extender mucho, ya que esta información está disponible (aunque en inglés) en la propia web de Riak, en Concepts, así que resumiré un poco.

El almacén de datos se realiza en base a el par clave-valor, es lo que podríamos llamar una base de datos hash. No obstante, la clave se compone de bucket y key, que son como en Erlang el módulo y la función, o en Java el paquete y la clase. El conjunto bucket/key es la unidad de organización única que puede emplearse.

El sistema admite también el uso de enlaces (links). Esto quiere decir que el contenido de un bucket/key, puede ser un contenido o un enlace a otro bucket/key que tenga su propio contenido. Algo así como el enlace simbólico en los sistemas de ficheros de Unix/Linux/BSD/…

Además, el contenido, puede ir estructurado en forma de metadatos, es decir, como las cabeceras de los mensajes HTTP, para disponer de arrays asociativos (hash) dentro del contenido.

Uso de diferentes backends. En la versión 0.12, Bitcask se estableció como backend para Riak, pero hay más, aquí ponemos un listado de los disponibles:

• Bitcask: simple pero potente almacenaje de pares clave-valor. Es de baja latencia y alto rendimiento.
• DETS / ETS: tablas incorporadas en Erlang para el almacenamiento de información.
• Erlang Balanced Trees (gb_trees): sistema de árbol balanceado. Rápido para leer, pero algo lento para escribir.
• Innostore: basado en el engine InnoDB de MySQL. Debido a restricciones de licencia, se proporciona por separado.

Cada cluster que se configura de Riak, consta de los siguientes elementos:

• Nodos: nodos físicos, o máquinas, de las que se compone el cluster.
• Nodos Virtuales: nodos virtuales (o vnodes) que corren en cada máquina. Cada máquina física puede contener uno o varios nodos virtuales.
• Particiones: cada cluster Riak tiene un entero de 160-bits dividido en particiones ecuánimes. Cada vnode reclamará una partición del anillo.

Cada nodo en el cluster es responsable del 1/(número total de nodos físicos) del anillo. Puedes determinar el número de vnodes en cada nodo calculando el (número de particiones)/(número de nodos). Por ejemplo, un anillo con 32 particiones, compuesto por cuatro nodos físicos, tendrá aproximadamente ocho vnodos por nodo. Esta configuración es representada por el siguiente diagrama:

Riak está diseñado para ser un sistema distribuido, cuantos más nodos haya en el sistema, más rápido funcionará.

No hay nodo maestro, todos los nodos en Riak son iguales. Cada nodo es completamente capaz de servir cualquier petición de cliente. Esto es posible debido a la forma en la que Riak usa la consistencia de hash para distribuir datos a través del cluster, que se realiza a través de un gossip protocol.

Sobre la replicación

Riak controla tantas réplicas como datos son mantenidos a través de una configuración llamada n-valor. Este valor tiene una configuración por defecto en cada nodo pero puede ser sobreescrito por cada bucket. Los objetos de Riak heredan el n-valor de su bucket padre. Todos los nodos en el mismo cluster deben de acordar y usar el mismo n-valor.

Por ejemplo, aquí hay una representación de que sucede cuando n-valor es 3 (esta es la configuración por defecto). Cuando almacenas el dato en el bucket con un n-valor de tres, el dato se replicará a tres particiones separadas del anillo.

Y cuando un nodo falla o se agrega otro nodo, ¿qué sucede?

Riak usa una técnica llamada hinted handoff, para compensar el cluster en el momento que un nodo falla. Los vecinos del nodo fallido tomarán relevo y realizarán el trabajo de ese nodo permitiendo al cluster trabajar de forma normal. Esto puede considerarse una forma de auto-curación.

Si se agrega un nodo nuevo, en cambio, se rebalancean los datos.

Algunas pegas… siempre las hay

Primero, los buckets que usan un conjunto de propiedades no estandar forzarán a Riak a enviar vía gossip más datos a través del cluster. Los datos adicionales pueden ralentizar el proceso. Segundo, algunos backends, como Innostore, almacenan cada bucket como una entidad separada. Esto puede causar que nos quedemos sin recursos tales como manejadores de ficheros. Estas restricciones de recursos pueden no impactar al rendimiento, pero representarán otro límite en el máximo número de buckets a gestionar.

Conclusiones

A nivel teórico, todo bien, parece. Habrá que realizar un banco de pruebas y ver qué tal va el sistema. De momento, me he quedado sin tiempo (del que había planificado) para escribir este artículo, por lo que, dejo las pruebas para la siguiente parte… que entraremos de lleno en la práctica.

Leyendo el blog de dos ideas con referencia a un artículo que publicaron llamado NoSQL: el movimiento en contra de las bases de datos, se comenta una conferencia en la que grandes profesionales del sector de los sistemas, con necesidades de escalabilidad y alta capacidad de almacenaje, mencionaban sus soluciones NoSQL.

Entre ellos, representantes de empresas como Google, Amazon, Facebook, Twitter, LinkedIn, … pusieron en conocimiento de todos los asistentes sus soluciones ya desarrolladas y en funcionamiento para suplir las carencias que las bases de datos tradicionales no podían cubrir.

Las ventajas de NoSQL

Las ventajas de estos sistemas de almacenamiento (hay muchos integrantes de este movimiento que consideran una aberración llamarlos bases de datos) son las siguientes:

• Pueden manejar enormes cantidades de datos: esto es debido a su propia estructura distribuida. Por ejemplo, HyperTable, una implementación de código abierto basada en BigTable (de Google), puede escribir 1000 millones de celdas de datos por día. Al igual que BigTable, con MapReduce, es capaz de manejar 20 petabytes diarios.
• Se ejecutan en clusters de máquinas baratas: estos sistemas no requieren de apenas computación, en comparación con los sitemas gestores de base de datos tradicionales y basados en SQL, por lo que se pueden montar en máquinas de un coste más reducido y en mayor número, gracias a su nivel de escalabilidad.
• No generan cuellos de botella: el problema de fondo de los sistemas SQL, es que deben de transcribir cada sentencia para poder ser ejecutada y, cada sentencia compleja requiere, además de un nivel de ejecución más concreto para poderse llevar a cabo, por lo que constituye un punto de entrada común, único y conflictivo en base a rendimiento.
• Solo lo estrictamente necesario: son sistemas simples que no tienen un sistema de consulta complejo ni con capacidad declarativa para en una sola línea realizar una cantidad interna de operaciones desorbitada.

Las desventajas

Bueno, y después de poner estos sistemas por las nubes… ahora toca pegar un poco los pies al suelo y darse de cara con la realidad. Quiero decir que, sí, hay desventajas, esto no es una panacea que sirva para paliar la necesidad del almacenaje de datos para todos los casos. En entornos de sistemas de información, en gestión de cuentas, y entornos en los que es preferible que los datos puedan tener algo más de inteligencia, en lugar de algo más de rapidez, estos sistemas no son aconsejables, ya que la única, pero mayor desventaja de estos es que no respetan ACID.

Conclusiones

En mi caso particular, trabajando en un área de sistemas relacionado con la telefonía en el que premia más la velocidad de tratamiento de datos, así como la capacidad para poder manejar gran cantidad de los mismos, y en el que la integridad referencial es algo que ni se usa ni se tiene en cuenta, sí, es una solución real, una forma de ahorrarse gran cantidad de código y dolores de cabeza con respecto a la escalabilidad y concurrencia de la información dentro de la plataforma tecnológica.

Ahora, si mi trabajo fuese desarrollar sistemas CRM, ERP o similares, que dependen más de la integridad de los datos, así como su relación y unas reglas de negocio establecidas y programadas, es innegable que las bases de datos con soporte SQL agregan mucho valor en este sentido.

Por lo que, podemos concluir en que, para programación de sistemas son un recurso muy útil y que puede facilitar y paliar problemáticas relacionadas con el almacenaje de información, así como el tratamiento in-situ de la misma con cara a la lógica del servicio, y por otro lado, si lo que premia más es tener una lógica de negocio bien definida, en ese caso, quizás es mejor seguir usando los sistemas SQL.