Los cuatro modelos NoSQL

Las bases de datos NoSQL se clasifican habitualmente según el modelo de información con el que trabajan, es decir, según qué forma tiene la unidad que guardan. Hay cuatro modelos vigentes: documentos, familia de columnas, clave-valor y grafos.

Se citan a veces otros dos, las bases de datos orientadas a objetos y las orientadas a XML. No son modelos NoSQL: son anteriores, y como productos de mercado quedaron en nicho. Sus conceptos (el OID, ODMG y OQL) se estudian en el subtema «SGBD relacionales y de objetos», porque el programa oficial los nombra.

Los tres primeros modelos comparten una idea de fondo: guardan agregados, unidades que se leen y se escriben enteras y que no se relacionan entre sí dentro de la base. El de grafos es el contrario: lo valioso son precisamente las relaciones, y por eso se estudia aparte.

Cuatro modelos vigentes: documentos, familia de columnas, clave-valor y grafos. Objetos y XML se consideran obsoletos.

Una base documental guarda colecciones de documentos, y el producto de referencia es MongoDB. Un documento es un objeto con formato JSON: campos, valores, y la posibilidad de anidar objetos y listas dentro. La colección es el equivalente aproximado de una tabla, pero sin esquema declarado.

No hace falta definir nada antes de insertar. Dos documentos de la misma colección pueden tener campos distintos y no pasa nada: si a partir de mañana los cursos llevan un campo nuevo, se escriben con él y los antiguos siguen siendo válidos. Al insertar, el motor asocia automáticamente un identificador único al documento, el campo _id, si no se ha indicado uno.

Internamente MongoDB no guarda texto JSON sino BSON, una codificación binaria de JSON que añade tipos que el JSON de texto no tiene, como fechas o enteros de 64 bits, y que es más rápida de recorrer. De cara a quien consulta, la diferencia es invisible.

El motor indexa por el identificador de forma nativa y permite crear índices sobre cualquier campo, incluidos campos anidados. Para datos binarios grandes, como vídeos o imágenes, MongoDB ofrece GridFS, que trocea el fichero y lo reparte en documentos; también es habitual dejar el binario en un gestor documental externo y guardar en la base solo la referencia.

Lo que define al modelo documental es que la base entiende el interior del documento: por eso puede filtrar e indexar por campos internos, y no solo por la clave.

El modelo clave-valor es el más sencillo de todos: se comporta como una gran tabla hash distribuida. Se guarda un valor bajo una clave y se recupera por esa clave. La base no mira lo que hay dentro del valor, así que no se puede consultar por su contenido.

Esa simplicidad es su ventaja: el acceso es directo y muy rápido, y por eso se emplean sobre todo como almacén auxiliar colocado delante de un sistema más lento, haciendo de caché de primer nivel. También son la opción natural para sesiones de usuario, contadores y datos temporales.

Redis es el producto más conocido de la familia y va un paso más allá: trabaja en memoria y cada clave no guarda un valor opaco cualquiera, sino un valor de un tipo concreto, con operaciones propias de ese tipo. Los cuatro tipos básicos son cadenas, listas, conjuntos y hashes; las operaciones se ven en el subtema de consultas.

La frontera con el modelo documental está en si la base entiende el valor. En clave-valor puro no lo entiende, y solo se puede pedir por clave.

En este modelo, la fila no tiene un juego fijo de columnas: cada fila puede tener las suyas. Añadir una columna a un registro no obliga a añadirla a los demás ni a reservar espacio para ella, así que el modelo admite bien datos dispersos, con muchos huecos. Es un modelo pensado para trabajar desnormalizado: se repiten datos a propósito para que cada consulta se resuelva leyendo de un sitio.

Cada columna lleva asociada su propia marca de tiempo, generada por el producto en el momento de escribirla. Ese timestamp no es decorativo: es lo que permite decidir qué valor gana cuando dos réplicas han recibido escrituras distintas sobre el mismo dato, y es la pieza que hace viable la consistencia eventual en estos sistemas.

La organización tiene cuatro dimensiones, y conviene memorizarlas en orden porque se pregunta así: Keyspace, Column Family, Rowkey y Column.

1. 1Keyspace: el contenedor mayor, comparable a una base de datos. Es donde se configura la replicación.
2. 2Column Family: el agrupador de filas, comparable a una tabla.
3. 3Rowkey: la clave que identifica una fila dentro de la familia y decide en qué nodo se guarda.
4. 4Column: cada par de nombre y valor dentro de la fila, con su marca de tiempo.

Keyspace, Column Family, Rowkey y Column: de fuera hacia dentro, como base de datos, tabla, fila y celda, pero con columnas libres por fila y un timestamp en cada una.

Una base de datos de grafos guarda la información en nodos y aristas. Los nodos, también llamados vértices, representan entidades: una persona, una parada de metro, una cuenta bancaria. Las aristas representan las relaciones entre ellas, tienen sentido y tipo, y son objetos de primera clase: se guardan, se consultan y se recorren igual que los nodos. Tanto los nodos como las aristas pueden llevar propiedades, que son pares de nombre y valor con información añadida.

La diferencia con un relacional no está en poder representar relaciones, que también puede, sino en el coste de recorrerlas. En un relacional, seguir una relación es una unión de tablas, y encadenar seis saltos son seis uniones que empeoran deprisa. En un grafo, cada nodo apunta directamente a sus vecinos, así que recorrer un salto cuesta lo mismo tenga la base mil nodos o mil millones.

Por eso se usan donde la pregunta es de recorrido: cálculo de rutas de transporte, análisis forense y de fraude, redes sociales, recomendaciones y trazabilidad de dependencias.

Estos productos traen implementados los algoritmos clásicos de teoría de grafos, y los tres que más se citan son estos.

• PageRank: mide la influencia de un nodo teniendo en cuenta no solo cuántos apuntan a él, sino la importancia de quienes lo hacen. Es influencia transitiva.
• Shortest Path (camino más corto): con el algoritmo de Dijkstra, que explora por coste creciente y no admite pesos negativos, o con A*, que es Dijkstra más una heurística que orienta la búsqueda hacia el destino y por eso llega antes.
• Strongly Connected Components (componentes fuertemente conexas): grupos de nodos en los que desde cualquiera se puede llegar a cualquier otro siguiendo el sentido de las aristas. Se calculan con el algoritmo de Tarjan.

Nodos son vértices; relaciones son aristas. Es un cambio de nombre que se confunde a menudo, y las dos partes pueden llevar propiedades.

Al estudiar las listas de productos llama la atención que algunos nombres se repitan en columnas distintas. No es un error de la clasificación: son bases multimodelo, motores que soportan varios modelos de datos sobre el mismo almacenamiento y el mismo lenguaje de consulta.

• OrientDB: documentos, grafos y clave-valor en el mismo motor.
• ArangoDB: documentos, grafos y clave-valor, con un único lenguaje de consulta para los tres.
• DynamoDB, el servicio gestionado de Amazon, que se describe a la vez como clave-valor y como documental porque admite atributos anidados.

La lectura práctica es que la frontera entre clave-valor y documental es gradual, no una pared: depende de cuánto entienda la base del contenido del valor. Y que en una pregunta de examen sobre a qué familia pertenece un producto, los candidatos ambiguos suelen ser justo estos.