Bases de datos NoSQL

Publicado por Norberto Herz el
Durante estos días, estoy teniendo bastante trabajo (por eso la ausencia de posts por aquí). Uno de los proyectos con los que estoy trabajando, utiliza para la persistencia de datos un enfoque Schemaless/NoSQL aplicado sobre tecnología DB2 pureXML. De esto trata este POST.

Primero, una aclaración respecto del término NoSQL. En un principio, surgió el término como forma de diferenciar AMPLIAMENTE una base de datos relacional (consultada mediante SQL) de una que no lo era. Luego, el término quedó como una forma simpática de abreviar Not Only SQL, indicando que las bases híbridas, pueden ser consideradas dentro del grupo de las NoSQL.

Pero lo realmente importante, escapa al nombre e incluso a como funciona, y el foco debe realmente ser puesto en primer lugar en ¿Por qué y para qué querríamos abandonar nuestro ya conocido, probado, confiable y robusto esquema relacional?

En mi caso la respuesta comienza siendo sencilla. Durante al menos los últimos 6 años de mi carrera, me he encontrado con requerimientos (en el límite de lo funcional y lo no funcional) que exigían representar entidades heterogeneas, configurables, flexibles y adaptables. Exacto, nadie dice qué tan flexibles deben ser estas entidades, pero todos afirman que deben serlo. Entonces, antes de cualquier análisis costo-beneficio, alguien siempre "salta" con el típico diseño de flexibilidad sobre un esquema relacional: "Una tabla con 2 campos. CLAVE - VALOR". Quizas algún campo más que indique a que entidad corresponden las claves y en otra tabla, una relación conteniendo el valor.

Ahora bien, esta solución, intenta romper el principal paradigma de una base de datos relacional (con estructura de tablas y relaciones): "Las entidades son tipadas". Esto quiere decir que una entidad se define como un conjunto de campos de un tipo específico, y cada fila de la tabla representa esa entidad y ninguna otra. Este efecto, es la principal ventaja de una base de datos schemaless.

Entonces, relacionando los conceptos: La mayoría de los proyectos, de un tiempo a esta parte, necesitan estructuras dinámicas; las bases de datos relacionales persisten estructuras estáticas; Las bases de datos NoSql/Schemaless persisten estructuras dinámicas. ==> Las bases de datos NoSql/Schemaless se adaptan mejor a la mayoría de los proyectos de un tiempo a esta parte.

Sumado a esto, el diseño presentado se vuelve muy ineficiente al intentar ejecutar consultas que filtren alguna entidad dinámica por un grupo de valores (consulta trivial en una entidad estática).

Habiendo expuesto de esta manera el "por y para qué", indaguemos brevemente en como funciona, para luego dejar algunos links de utilidad a diferentes implementaciones tales como CoachDB, DB2 pureXML, Google BigTable.

Supongamos un ejemplo sencillo en el cual debamos almacenar los datos de una persona: Nombre, Apellido, Fecha de nacimiento, y Teléfonos (si, más de uno).

Un esquema posible para una base de datos relacional sería:
Este mismo diseño representado en una estructura schemaless, podría explicarse en una tabla con un solo campo: PERSONA (claramente, no es necesario que se halle en una tabla, puede ser un archivo de texto en un filesystem, o cualquier tipo de almacenamiento). Luego, este store, deberá poder representar la estructura de manera flexible.
Una buena estrategia para lograrlo es representar los datos utilizando una nomenclatura que al tiempo que describe su estructura, representa la información. Una "lenguaje" que cumple con estas características es XML. Por lo tanto, en un enfoque schemaless, un store debería almacenar la siguiente estructura (por cada entidad persistida):


<persona id="xx">
<nombre>xxxx</nombre>
<apellido>xxxx</apellido>
<fechaNacimiento>xx/xx/xxxx</fechaNacimiento>
<telefonos>
<telefono id="xx" descripcion="xxxxxx">
 <codigoPais>xx</codigoPais>
 <codigoArea>xx</codigoArea>
 <numero>xxxxx</numero>
</telefono>
<telefono id="xx" descripcion="xxxxxx">
 <codigoPais>xx</codigoPais>
 <codigoArea>xx</codigoArea>
 <numero>xxxxx</numero>
</telefono>
</telefonos>
</persona>


Nótese que para lograr ser autodescriptivo, XML almacena la estructura en su contenido (repitiendo esta información gran cantidad de veces. Anotemos esto del lado de los bemoles de este enfoque).

La flexibilidad comienza cuando el mismo store, puede almacenar un XML diferente:

<persona id="xx" tipo="proveedor" >
 <nombre>xxxx</nombre>
<apellido>xxxx</apellido>
<fechaNacimiento>xx/xx/xxxx</fechaNacimiento>
     <CUIT>xxxx</CUIT>
<telefonos>
<telefono id="xx" descripcion="xxxxxx">
 <codigoPais>xx</codigoPais>
 <codigoArea>xx</codigoArea>
 <numero>xxxxx</numero>
</telefono>
<telefono id="xx" descripcion="xxxxxx">
 <codigoPais>xx</codigoPais>
 <codigoArea>xx</codigoArea>
 <numero>xxxxx</numero>
</telefono>
</telefonos>
</persona>

Ahora bien, ¿Cómo logramos obtener un dato dentro de esta estructura?
Para el caso de XML, existe un standard (definido por la W3C) conocido como XPath. Este standard, permite recorrer y extraer una parte específica dentro de un XML. Por ejemplo: /persona/nombre -> retorna 
<nombre>xxxxx</nombre>
. Para redoblar la apuesta, W3C también definió como parte standard XQuery, que permite realizar operaciones más complejas sobre un XML (Ej: FLWOR).

Una base de datos que soporte estas tecnologías, podría considerarse una base NoSQL.

Cabe aclarar que XML no es el único "lenguaje" que permite representar estructuras dinámicas. Otro ejemplo de esto es JSON (JavaScript Object Notation), preferido por ejemplo por Google BigTable.

A continuación una serie de links útiles para conocer distintas tecnologías aplicadas a NoSQL.
Espero les interese el tema y lo investiguen. Queda pendiente combinar estos conceptos con algo de almacenamiento distrubuido, teorema CAP, escalabilidad y performance, pero creo que es mucho para un solo POST.