Suena excitante, pero…

¿Cómo funciona esto?

Referenciado en el RFC 4122 del IETF, el UUID se puede definir como un número de 16 bytes (128-bits) que se representa por 32 dígitos hexadecimales, mostrados en cinco grupos separados por guiones:

12345678-abcd-1b3d-a2c4-0123456789ab

Cada uno de los cinco grupos identifica un dato específico para garantizar su carácter único. En principio, se toma el timestamp de la hora actual con precisión de 100 nanosegundos y en formato UTC desde el 15 de octubre de 1582 (la fecha de la reforma gregoriana para el calendario cristiano) de la siguiente forma:

• time_low el campo bajo del timestamp, este ocupa los primeros 32 bits.
• time_mid el campo medio del timestamp, ocupa los siguientes 16 bits.
• time_high la última parte del timestamp, este no ocupa todo el grupo, sino solo los bits de menor peso, los primeros 12 bits.

Para llegar a los primeros 64 bits nos faltan 4, esto es porque estos se emplean para identificar la versión de UUID que se emplea, según el RFC4122, de momento se contemplan 5:

1. Versión basada en tiempo. Especificada en el RFC4122.
2. Versión de Seguridad DCE con UIDs POSIX embebidos.
3. Versión basada en nombre que usa MD5 (también se especifica en el RFC4122).
4. Versión aleatoria o pseudo-aleatoria de generación (también se especifica en el RFC4122).
5. Versión basada en nombre que usa SHA-1 (también se especifica en el RFC4122).

El 4º campo se divide en dos, pero para un mismo concepto, que es la secuencia de reloj. Se escribe con datos de 8 bits especificando el de mayor y menor peso, quedando en este orden almacenados en el cuarto grupo. Aunque el grupo ocupa 16 bits, las versiones 3, 4 y 5 lo emplean como un dato de 14 bits, siendo en las versiones 3 y 5 una secuencia de reloj construida desde un nombre, y en la versión 4 una secuencia de reloj aleatoria o pseudo-aleatoria.

El 5º grupo es denominado el nodo. Ocupa 48 bits. En la versión 1 de UUID este dato se corresponde con la dirección MAC (dirección física de una interfaz de red) definida en el IEEE 802. Para equipos sin interfaz de red, se emplea un dato aleatorio o pseudo-aleatorio. Para las versiones 3 y 5 de UUID, este dato cambio construyéndose a través de una elección de nombre y codificándola con MD5 o SHA-1. Para la versión 4, este dato se construye a través de un número aleatorio o pseudo-aleatorio.

Conclusiones

Los UUID son identificadores únicos y muy difíciles de que se produzcan dos iguales dados los parámetros que se emplean para su generación. Al igual que los datos que se emplean para la generación del conference ID de la comunicación de H.323, este dato puede ser empleado como identificador de tablas y estar seguro que, aunque la tabla esté fraccionada y después se mezcle en una, los datos no colisionarán nunca.

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.

Según vemos en la página oficial del proyecto, NewSQL dispone a día de hoy de dos posibles gramáticas a implementar. Una de ellas está basada en la Java Database (JDB) y otra sería la evolución propia de SQL (SQL II, o S2). Aún no se ha decidido qué versión será la empleada como newSQL, por lo que, podemos decir que es un proyecto a futuro y no hay implementación real de momento.

Implementación JDB

La sintaxis que se desea implementar al estilo JDB tendría esta forma en comparación con el SQL actual:

La sintaxis puede parecer bastante clara y limpia, sobre todo para los que programan con lenguajes del estilo de Java, C++, PHP y de sintaxis derivada. No obstante, si tenemos en cuenta que esto sustituye a SQL, pero no a la forma de enviar las consultas, generar una cadena de texto de este estilo para enviarla al Sistema Gestor de Base de Datos, puede resultar bastante tedioso igualmente.

Hay bastantes dudas sobre, por ejemplo el INSERT, ya que, ahí nos muestran una inserción completa, pero, ¿y si queremos que haya datos por defecto y solo declarar algunos? … igualmente, en la cadena de búsqueda, da la sensación de haber empleado XPath para seleccionar las tuplas… ¿cómo se haría si se busca por un criterio en lugar de un ID? … al final puede quedar algo difícil de entender, realmente.

SQL II (S2)

La otra opción, es una versión evolucionada de SQL (o simplificada, según se mire), que tiene la siguiente forma:

Revisándolo, se ve claro que no aporta mucho, realmente, a lo que se usa de hoy en día. Es más, se intenta introducir de forma fija el uso del operador “==” en lugar de “=”, lo cual resulta extraño e inapropiado, desde mi punto de vista, ya que, en todo caso, cambiaría mejor el “=” del UPDATE por un “<-”.

Conclusiones

Desde mi punto de vista, más que centrarse en cómo escribir “mejor” los sistemas SQL, deberían de centrarse en agregar dichas sentencias para que se mezclasen con el código, algo como SQLJ, de cara a integración con los lenguajes, y de cara al mejor uso de SQL, hacer estándares del uso de las fechas (que cada sistema los usa a su forma), así como los LIMIT, funciones básicas y tipos de datos, entre otras muchas cosas, para que los SGBD fuesen más compatibles entre ellos.

No obstante, la historia quiso que MySQL AB, la empresa que se creó para comercializar la idea de la base de datos rápida para webs, fuese finalmente adquirida por Sun Microsystems, para dar un supuesto impulso a su integración con el mundo de Java. A lo que respondió otro de los grandes del sector, finalmente, comprando a la propia Sun Microsystems.

En el momento en el que MySQL pasó a ser de Sun, comenzaron las tiranteces, de forma que, Monty, uno de los fundadores y responsable del desarrollo inicial de MySQL, que comentó que el nombre, precisamente, provenía de una de sus hijas (llamada My), hizo un fork, dándole el nombre de MariaDB (otra de sus hijas).

El caso es que, por ética profesional y propia, al final, he decidido abandonar definitivamente MySQL para usar única y exclusivamente MariaDB en lo que concierne a base de datos tipo MySQL… ya que, también hay otras como PostgreSQL que siguen siendo una muy buena opción a considerar, según el caso que se dé.

Migrando

Lo primero, veo que en la propia página de Monty dedicada a MariaDB, hay un configurador bastante bueno de elegir la distribución, la versión de MariaDB a instalar y el mirror más cercano. Con esto tenemos que la instalación en mi Debian Squeeze, por ejemplo, se basa en poner los repositorios correspondientes y hacer el apt-get install para mariadb-server-5.3 (por ejemplo).

Tanto si se instala de forma automática, como de forma manual, si tenemos corriendo un MySQL 5.1 (por ejemplo), el sistema se encarga de desinstalarlo, poner en su lugar MariaDB y ejecutar un script llamado mysql_upgrade (que en caso de la instalación desde apt-get install se realizará de forma automática).

El servidor se levanta de forma rápida y tenemos un MySQL completamente funcional con la base de datos instalada y funcionando. El corte casi que ni se nota.

No obstante, siempre es deseable tener una copia de seguridad por lo que pudiera pasar. Está el caso de éxito de SpamExperts que migraron cerca de 300 servidores en más o menos tres horas y sin complicaciones.

Las ramas de MariaDB

Actualmente hay disponibles tres ramas de MariaDB, la versión 5.1, la versión 5.2 y la versión 5.3.

• La versión 5.1 es una versión prácticamente igual que la versión 5.1 de MySQL, solo que con muchas correcciones de errores realizadas.
• La versión 5.2 es la siguiente evolución, que consta con muchas de las características que querrían haber introducido sus creadores en la versión anterior, pero no pudieron por falta de tiempo.
• La versión 5.3 es la actual, que integra muchas mejoras y cosas que en MySQL solo están en la versión comercial.

La versión 5.3, que es la última y la más avanzada, tiene cosas como:

• Optimizaciones en subconsultas, de siempre en SQL, el hecho de realizar subconsultas es algo que da un poco de miedo, porque, además de que puede ser lioso el hecho de construir una gran consulta con subconsultas dentro, tiene penalización en rendimiento. Pues bien, esta versión está optimizada para el uso de subconsultas de modo que, con respecto a MySQL (la versión normal) mejora el rendimiento sustancialmente.
• Interfaz NoSQL… bueno, realmente, sigue siendo SQL, pero permite redefinir y aumentar la base de datos de forma fácil en cada UPDATE e INSERT. Un ejemplo puede verse en esta página.
• Nuevos engines (realmente esto es de la 5.2), permite usar OQGRAPH, que es un engine preparado para el almacenamiento de elementos jerárquicos y grafos; y SphinxSE que integra un sistema de búsqueda de texto muy parecida al FTS de PostgreSQL enlazando con el servidor de Sphinx.
• Autenticación por plugins: permite tener autenticación vía PAM, LDAP, etc.

Conclusiones

MariaDB se mueve en un entorno ágil con mucha gente que lo mantiene desde su comunidad, y sobretodo, con el apoyo y liderazgo de quien comenzó en su día MySQL, por lo que, es más que posible que dentro de unos cuantos meses o años, se comience a escuchar hablar más de MariaDB que de MySQL. Además, migrar ahora es fácil, ya que las versiones 5.1 en ambos elementos son muy parecidos (son casi iguales), pero ya con la versión 5.5 de MySQL (han saltado de la 5.1 a la 5.5 directamente) y la 5.3 de MariaDB, cada vez se irán distanciando más.

Mi consejo: ¡actualiza ya!

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.

Fuente: documentación oficial de PostgreSQL 9.0.

El concepto de FTS

La búsqueda de texto completa (Full Text Searching o FTS) proporciona la capacidad de identificar documentos de lenguaje natural que satisfacen una consulta y, opcionalmente, ordenarlos por relevancia a la consulta. El tipo más común de búsqueda es buscar todos los documentos que contengan los términos de la consulta y los retorna en orden de similitud. Los conceptos de consulta y similitud son muy flexibles y dependen de la aplicación específica. La búsqueda más simple considera una consulta como un conjunto de palabras y su similitud con la frecuencia de aparición de las mismas en el documento.

¿Qué es un documento?

Un documento es la unidad de búsqueda en un sistema FTS; por ejemplo, un artículo de una revista o un mensaje de email. El motor de búsqueda de texto debe estar preparado para analizar documentos y almacenar asociaciones de lexemas (palabras clave) con su documento padre. Después, estas asociaciones son usadas para buscar documentos que contengan esas palabras clave.

Para PostgreSQL un documento es, normalmente, un campo de texto, o una concatenación de varios campos de texto almacenados en una o varias tablas, o un texto obtenido de forma dinámica. En otras palabras, un documento puede ser construido de diferentes formas y puede no estar almacenado en ningún sitio. Por ejemplo:

SELECT title || ' ' || author || ' ' || abstract || ' ' || body AS document
FROM messages
WHERE mid = 12;

Búsqueda de texto básica

El FTS en PostgreSQL está basada en el operador @@, el cual retorna true si un tsvector (documento) coincide con una tsquery (consulta). No importa el orden en el que se pongan:

SELECT 'tres tristes tigres comieron trigo de un trigal'::tsvector @@ 'tristes & tigres'::tsquery;

Búsqueda de Resultados por Ránking

Ránking intenta medir como de relevantes son los documentos para una consulta en particular, así que cuando hay muchas coincidencias, la más relevante se muestra primero. PostgreSQL proporciona dos funciones de ránking predefinidas, las cuales tienen en cuenta el léxico, proximidad y estructura de la información. Esto es, que consideran como aparecen de frecuentes los términos en el documento, como de juntos están en el documento y como de importante es la parte de el documento donde aparecen. Sin embargo, el concepto de relevancia es vago y muy específico de la aplicación. Aplicaciones diferentes pueden requerir información adicional para el ránking. Las funciones construidas para ránking son solo ejemplos. Puedes escribir tus propias funciones de ránking y/o combinar sus resultados con factores adicionales para ajustarlas a tus necesidades específicas.

Aquí hay un ejemplo que, selecciona solo las diez coincidencias más altas en el ránking:

SELECT title, ts_rank_cd(textsearch, query) AS rank
FROM apod, to_tsquery('neutrino|(dark & matter)') query
WHERE query @@ textsearch
ORDER BY rank DESC
LIMIT 10;

El resultado:

                     title                     |   rank
-----------------------------------------------+----------
 Neutrinos in the Sun                          |      3.1
 The Sudbury Neutrino Detector                 |      2.4
 A MACHO View of Galactic Dark Matter          |  2.01317
 Hot Gas and Dark Matter                       |  1.91171
 The Virgo Cluster: Hot Plasma and Dark Matter |  1.90953
 Rafting for Solar Neutrinos                   |      1.9
 NGC 4650A: Strange Galaxy and Dark Matter     |  1.85774
 Hot Gas and Dark Matter                       |   1.6123
 Ice Fishing for Cosmic Neutrinos              |      1.6
 Weak Lensing Distorts the Universe            | 0.818218

La misma usando un ranking normalizado:

SELECT title, ts_rank_cd(textsearch, query, 32 /* rank/(rank+1) */ ) AS rank
FROM apod, to_tsquery('neutrino|(dark & matter)') query
WHERE  query @@ textsearch
ORDER BY rank DESC
LIMIT 10;

Y su resultado:

                     title                     |        rank
-----------------------------------------------+-------------------
 Neutrinos in the Sun                          | 0.756097569485493
 The Sudbury Neutrino Detector                 | 0.705882361190954
 A MACHO View of Galactic Dark Matter          | 0.668123210574724
 Hot Gas and Dark Matter                       |  0.65655958650282
 The Virgo Cluster: Hot Plasma and Dark Matter | 0.656301290640973
 Rafting for Solar Neutrinos                   | 0.655172410958162
 NGC 4650A: Strange Galaxy and Dark Matter     | 0.650072921219637
 Hot Gas and Dark Matter                       | 0.617195790024749
 Ice Fishing for Cosmic Neutrinos              | 0.615384618911517
 Weak Lensing Distorts the Universe            | 0.450010798361481

¿Hay más?

Pues claaaaaro que sí. Pero de momento lo dejo aquí, en previsión de hacer una segunda entrega con cosas como resultados resaltados (highlighting results) y sobretodo, la personalización de los analizadores, plantillas, configuraciones y diccionarios.

En postgresql, por ejemplo, el sistema de lenguajes que se pueden usar e implementar para la creación de funciones: PL/pgSQL, PL/Tcl, PL/Python, PL/Perl, PL/PHP, PL/Java, PL/Ruby, …; todos ellos se pueden ver en la página de documentación de PostgreSQL.

Esto quiere decir que, en una llamada a una función SQL se puede emplear una función específica programada en cualquiera de estos lenguajes, así como el lanzamiento de un trigger, puede ser compuesto por una serie de llamadas a estos procedimientos.

No obstante, la gente suele tener bastante miedo a usar estos sistemas para lógica de negocio por varios motivos, pero principalmente porque el despliegue es complejo.

Sí, en ciertos SGBD, un despliegue y mantenimiento resulta algo complejo, el hecho de mantener unas versiones y saber exactamente qué hay en producción y qué no hay, así como el hecho de que un cambio pueda hacerse en cualquier momento y pueda desvirtuar lo que haya en el repositorio en sí.

No obstante, puede solventarse con el uso de sistemas como migrations de rails, o similares. Es decir, no cargar nada directamente desde una interfaz abierta o desde la consola, sino desde una herramienta que permita controlar las subidas en forma de versiones.

En sí, el sistema de CHECK de PostgreSQL permite y da ventajas al usuario de desarrollar parte de la lógica de negocio. Allá donde no llegan los mecanismos típicos, es donde se puede comenzar a tirar de las funciones desarrolladas en cualquier lenguaje, con la potencia de que estas pueden ser lanzadas como CONSTRAINT, TRIGGERS o de forma inmediata en una consulta SQL.

En mi opinión, el uso de PostgreSQL como capa de datos, y además como capa de negocio, es una opción tan válida como extraer esa lógica a otros sistemas externos. La única nota negativa, es la interconexión, que obliga a que se haga con el conector de base de datos mientras que desarrollando la capa de negocio en otro tipo de framework, este acceso podría bien ser por mecanismos más orientados a RPC como SOAP o REST.

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.