La ventaja de Cassandra es su capacidad de escalar a través de una configuración de anillo en un cluster. La información de la base de datos se distribuye entre todos los nodos configurados y puede ser accedida desde cualquiera de ellos. En este caso, la distribución es muy parecida a Riak, incluso emplean el mismo protocolo para intercomunicación entre nodos: Gossip; además, se requiere de generar un token especial balanceado para la configuración de cada nodo de Cassandra. En esta página hay un código escrito en Python para poder hacer esta tarea.

El acceso a la base de datos se realiza mediante RPC y usando Thrift, que representa otra de las 7 tecnologías clave de Facebook, y también liberada como software libre. Como Thrift es multi-lenguaje, está implementado en muchos de los lenguajes existentes, no hay problemas de implementación, ya sea en Python, Perl, PHP, Java, Erlang, etc.

¿Es NoSQL?

En un principio, usando la base de Thirft y las funciones estándar que podemos ver en cualquier documentación, podríamos decir que sí es NoSQL. Nos proveen de funciones para realizar un CRUD básico a través de la inserción, actualización, eliminación y obtención de datos desde la base de datos. No obstante, la búsqueda queda un poco en el aire, ya que para poder buscar por cualquiera de las columnas creadas, hay que prefijar un índice.

Vamos al principio para entenderlo mejor. Haciendo una similitud con el modelo relacional, podemos ver que Cassandra dispone de los siguientes elementos:

• Keyspace: debe de crearse un keyspace para almacenar la información y, a la hora de conectar, hay que indicar que keyspace se quiere utilizar. Esto es similar a lo que en las bases de datos tradicionales es la base de datos en sí.
• Column Family: la información se guarda en columnas dentro de la keyspace, pero se agrupan en familias para identificar la separación entre un conjunto de datos y otro. Por lo tanto, dentro de las keyspace debemos de crear column families, lo que en las bases de datos tradicionales serían las tablas.
• Columnas: son cada una de las columnas que se agrupan bajo una familia, que se declaran con un tipo (para validación del dato) y con un nombre. Si se establece un índice sobre la misma, entonces se da la posibilidad de poder buscar utilizándola.

Llegados a este punto, vemos diferencias con otras NoSQL, como por ejemplo Riak. Riak tiene buckets donde Cassandra tiene keyspaces. En Riak cada bucket almacena claves a las que se les asigna un valor… en Cassandra esto no existe, ya que la clave de Cassandra está un nivel más abajo, cuando ya se han definido las familias de columnas. Esto deja a Cassandra entre dos mundos.

Entre SQL y NoSQL… CQL

Para confirmarlo, Cassandra dispone de un lenguaje de consulta que hace posible el empleo del mismo para realizar búsquedas entre sus familias de columnas, sobre las columnas que se hayan definido (con índice, claro). Este lenguaje provee de las órdenes básicas para realizar inserciones, actualizaciones, eliminaciones y obtención de datos.

Es más, el lenguaje en sí es llamado CQL y, viendo su sintaxis se sabe el porqué de la similitud con SQL. Por ejemplo, si tenemos creada la familia de columnas contactos, con una columna llamada nombre, y otra telefono, podemos realizar la siguiente consulta:

SELECT nombre, telefono FROM contactos

En las nuevas versiones de Cassandra, además, se puede emplear, en lugar de cassandra-cli el nuevo cqlsh, que permite emplear los comandos en formato CQL para manejar el cluster y hacer consultas al mismo. Esto hace pensar que Cassandra se comienza a desplazar cada vez más hacia el modelo relacional, dejando el paradigma de clave-valor muy atrás.

No obstante, facilita el acceso a este tipo de base de datos, a sistemas tan potentes, como para mantener un conjunto de máquinas en activo, en un anillo balanceando peticiones y en modo maestro-maestro con cada nodo.

Conclusiones

Después de darle bastantes vueltas y emplearlo para un par de desarrollos, he encontrado Cassandra bastante potente para el desarrollo de aplicaciones en las que la información se mantiene estática y se puede capturar de forma fácil a través de sus claves. Es muy rápido dando la información y él mismo balancea entre los nodos que tenga configurado.

Una nota negativa puede ser el hecho de que la búsqueda de información se hace bastante dificultosa debido a que, los datos de las columnas tienen que estar prefijados y muchos datos, en el enlace con Thrift, no funcionan bien. Así mismo, el filtrado por cualquier campo obliga a crear un índice sobre ese campo, lo que conlleva más ocupación de espacio y ralentizar un poco las inserciones, modificaciones y eliminaciones.

En definitiva, es una base de datos con capacidad fácil para montarse en forma de cluster, que permite una rápida ingesta de datos (siempre que tengan un formato prefijado), y una consulta también rápida de los mismos. No es indicado para sistemas en los que las consultas se puedan complicar, ya que requiere en ese caso de la creación de muchos índices e incluso muchas tablas intermedias para no perder la pista de la información. Al final, la mayoría de código hay que ejecutarlo del lado del cliente, por lo que cuanto más difícil sea el esquema de datos, más lento se volverá.

En principio, como revisé solo los conceptos en los que se basa y no el funcionamiento a nivel de usuario, de programador, no sabía si era una interfaz amigable para realizar consultas o búsquedas, y la forma de realizar las cargas, inserciones y demás. Tengo que decir que, al menos el acceso y la comunicación con el servidor resulta muy cómoda y sencilla, ya que se basa en REST.

A través de peticiones HTTP muy sencillas y que se pueden generar incluso desde la línea de comandos con herramientas como curl, podemos realizar peticiones a la base de datos.

Mensajes hacia Riak

En principio, Riak se basa en REST, esto quiere decir que cada URI especifica un recurso dentro de la base de datos, y sobre ese recurso podemos realizar las acciones HTTP que se relacionan a cualquiera de las acciones básicas de una petición:

• GET equivale a tomar datos, sería la R del CRUD (retrieve) o el SELECT del SQL.
• PUT equivale a insertar datos nuevos, sería la C del CRUD (create) o el INSERT del SQL.
• POST equivale a una modificación o actualización de datos, sería la U del CRUD (update) o el UPDATE de SQL.
• DELETE equivale a una eliminación del dato, sería la D (delete) o el DELETE de SQL.

Esto permite muchas ventajas, como el uso, en el GET, de la cabecera If-Modified-Since, que nos dará la posibilidad de comprobar si un elemento pesado (imagen, vídeo o similar) es nuevo o no, para volver a descargarlo. Riak nos retornará el objeto con el mensaje 200 para indicar que hay uno nuevo, o solo la cabecera 304 (Not Modified) para indicarnos de que es el mismo que ya tenemos, por lo que no hace falta volver a transmitirlo.

Ante una petición de POST, o una de PUT en el que no exista el registro, se retornará el mensaje 201 (Created), y ante una operación de DELETE, si ha salido bien recibiremos un 204 (No Content) o 404 (Not Found).

Composición de la URI

La URI para localizar recursos dentro de Riak se puede establecer como sigue:

/riak/BUCKET/RESOURCE

NOTA: la palabra clave riak ha sido modificada en nuevas versiones por buckets, pero se mantiene riak por compatibilidad hacia atrás. Por lo que, si estás instalando una versión nueva tomada de la parte de descargas de Riak, puedes usar en lugar de riak la palabra buckets.

Riak configura su URI de modo que la primera palabra clave es precisamente riak, seguida por el bucket donde se almacenarán los recursos que se indique a continuación en la URI. El bucket es un bolsillo en el que se puede almacenar lo que se desee. Además, el bucket se puede configurar a través del paso de algunos parámetros de configuración específicos. Esto se sale un poco del objetivo del artículo, por lo que si tienes curiosidad de lo que se puede configurar puedes echarle un vistazo a este enlace.

Volviendo al tema, tenemos recursos. Estos recursos son un espacio en el que podemos guardar la información que necesitemos. Puede ser un texto normal, codificado como YAML, como JSON, como XML, o incluso una imagen o un vídeo… o incluso una imagen ISO (comprobado con una ISO de Sabayon de 700 MB aproximadamente).

Por lo que, podemos probar a hacer algunas prácticas. Lanzamos Riak. Si lo tenemos en ejecución en el puerto 8098 (es el de por defecto cuando se instala el paquete deb), podemos hacer lo siguiente:

curl -v -X PUT -H "Content-type: image/jpeg" --data-binary @imagen.jpg http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Nota: asegúrate de que la localización de la imagen es correcta, a una imagen de tu disco válida, y no olvidas poner la arroba (@) justo antes de esa ruta (sin espacios).

La comprobación más simple es a través del cualquier navegador que tengas instalado en esa misma máquina:

http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Con esto ya tendríamos la primera pureba satisfactoria de nuestro sistema de clave-valor para el almacenamiento de datos. Ahora, si lo que queremos es eliminarla, podemos hacerlo así:

curl -v -X DELETE http://127.0.0.1:8098/riak/pruebas/imagen.jpg

Si recargamos el navegador con la URL anterior, veremos que nos responde not found.

Búsquedas en Riak

En caso de que tengamos información formateada en JSON dentro de cada clave y queramos hacer una búsqueda de esta información para extraer únicamente las claves que nos sean útiles, tendremos que emplear el sistema conocido como map-reduce, para realizar una búsqueda a través de todas las claves de un bucket.

Voy a basarme en lo explicado en la documentación oficial de Riak, para no tener que inventar datos. En principio, si descargamos los dos siguientes ficheros y los ejecutamos:

• goog.csv, datos a insertar en Riak (en formato CSV).
• load_data, script en Erlang que insertará los datos, convirtiéndolos en un formato JSON. Hay que editar el scirpt y cambiar la URL para que tenga el puerto correcto, en mi caso puse 8098.

Esto nos da un bucket bastante grande en el que poder practicar.

Como decíamos antes, vamos a dar un repaso al sistema de MapReduce, el cual fue popularizado por Google. Este se basa en el algoritmo de divide y vencerás, realmente, ya que realiza un lanzamiento sobre cada elemento individual (map) tomando un resultado y, después, la parte de reduce, se encarga de analizar y unificarlo todo en un solo resultado.

Por lo tanto, tenemos que enviar mediante POST, a una URI concreta, un formato JSON de dato que será el siguiente:

{"inputs": "goog", "query": [
    {"map": {
        "language":"javascript",
        "source": "function(value, keyData, arg) { var data = Riak.mapValuesJson(value)[0]; if(data.High && parseFloat(data.High) > 600.00) return [value.key]; else return []; }",
        "keep": true
    }}
]}

Si guardamos esto en un fichero, podemos lanzarlo con el siguiente comando:

curl -X POST http://127.0.0.1:8098/mapred -H "Content-type: application/json" -d @mapred.json

En este caso, la función de map es la siguiente:

function(value, keyData, arg) {
  var data = Riak.mapValuesJson(value)[0];
  if(data.High && data.High > 600.00)
    return [value.key];
  else
    return [];
}

Esto quiere decir que se toma el contenido de cada clave, se parsea con una función especial de Riak para convertir de JSON y retornar la primera línea para que sea almacenada en data. Se comprueba que tenga campo High y que High sea mayor de 600.

Es un filtro como se puede hacer con cualquier función map en cualquier lenguaje (que disponga de ella, claro).

Ahora, para emplear tanto map, como reduce, imagina que lo que queremos, de esta información, es econtrar la máxima varianza diaria del precio por mes. Para eso, en el map sacaríamos la varianza diaria, y en el reduce tomaríamos solo la máxima varianza por mes, las funciones serían así:

/* Map calcula la varianza diaria y asigna la clave por mes */
function(value, keyData, arg){
  var data = Riak.mapValuesJson(value)[0];
  var month = value.key.split('-').slice(0,2).join('-');
  var obj = {};
  obj[month] = data.High - data.Low;
  return [ obj ];
}
 
/* Reduce encuentra la varianza máxima por mes */
function(values, arg){
  return [ values.reduce(function(acc, item){
             for(var month in item){
                 if(acc[month]) { acc[month] = (acc[month] < item[month]) ? item[month] : acc[month]; }
                 else { acc[month] = item[month]; }
             }
             return acc;
            })
         ];
}

Codificado para enviarlo en el fichero mapred.json, lo anterior quedaría así:

{"inputs":"goog",
 "query":[{"map":{"language":"javascript",
                  "source":"function(value, keyData, arg){ var data = Riak.mapValuesJson(value)[0]; var month = value.key.split('-').slice(0,2).join('-'); var obj = {}; obj[month] = data.High - data.Low; return [ obj ];}"}},
         {"reduce":{"language":"javascript",
                    "source":"function(values, arg){ return [ values.reduce(function(acc, item){ for(var month in item){ if(acc[month]) { acc[month] = (acc[month] < item[month]) ? item[month] : acc[month]; } else { acc[month] = item[month]; } } return acc;  }) ];}",
                    "keep":true}}
         ]
}

NOTA: el parámetro keep es el que nos dice qué es lo que se retorna. Si agregamos este mismo parámetro en las dos secciones (map y reduce), nos encontramos que el retorno de la búsqueda es tanto de uno como de otro.

Otras cosas

Otra de las cosas que han agregado es la posibilidad de enlazar recursos, de modo que, asignando un enlace y una etiqueta (con el nombre del tipo de enlace), podamos tener relacionado un recurso con otro. Esto da un abanico de posibilidades tan grande como el que se consigue con las bases de datos relacionales, ya que es posible tener en un bucket contactos, en otro datos específicos de un servicio y relacionar el contacto con esos datos agregando una etiqueta al mismo, e incluso que el enlace sea bidireccional agregando las etiquetas en los dos sentidos, cambiando la etiqueta para que sea semántica.

Una imagen de lo que se puede conseguir:

Las partes de administración (para ajustar las variables del teorema CAP) y configuración de otros nodos es algo que dejamos a revisar de la documentación oficial.

Conclusiones

Como puede verse, Riak solventa con su paradigma de NoSQL, basado en el almacenamiento por clave-valor y búsquedas por MapReduce, la mayoría de necesidades que se pueden encontrar a la hora de emplear este tipo de sistemas. Lo único que queda un poco en el aire, o hay que realizar con llamadas sucesivas, son las actualizaciones y eliminaciones masivas, pero realmente, puede ser un mal menor, si estas no son empleadas en el esquema que se vaya a implementar Riak.

Hay que tener presente que Riak es una muy buena base de datos, que fundamenta sus potencias en la posibilidad de contar con un cluster, lecturas rápidas con caché, y búsquedas artificiosas con MapReduce, pero puede haber otros usos en los que las consultas de modificación y eliminación masivas sean lo más importante y esto ya sería mejor abarcarlo con otra base de datos de otro tipo.

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.