Qué es NoSQL

El modelo relacional lleva medio siglo funcionando bien, así que la pregunta correcta no es qué tiene de malo, sino qué le pidieron que no sabía dar. Se lo pidieron los servicios que crecieron en la primera década de los dos mil: catálogos con millones de artículos, redes sociales, registros de actividad, sistemas donde el dato llega sin parar y no siempre con la misma forma.

NoSQL no significa «sin SQL», sino «no solo SQL»: es un conjunto de bases de datos que renuncian a alguna pieza del modelo relacional (el esquema fijo, las uniones, las transacciones sobre todo el conjunto) a cambio de repartirse entre muchas máquinas y de admitir datos cuya estructura cambia con el tiempo.

La clave está en cómo se crece. Escalar en vertical es poner una máquina más grande: más procesadores, más memoria, más disco. Es lo más cómodo, pero tiene un techo físico y un precio que sube mucho más deprisa que la capacidad. Escalar en horizontal es poner más máquinas iguales y repartir el trabajo entre ellas: no tiene techo, pero obliga a que el sistema sepa vivir partido.

Ahí está el problema del relacional. Sus dos garantías más valiosas, las uniones entre tablas y las transacciones, dan por hecho que todos los datos implicados están al alcance de la misma máquina. En cuanto los repartes, cada unión y cada transacción se convierte en una coordinación por red. Los sistemas NoSQL evitan esa coordinación guardando juntos los datos que se consultan juntos, aunque eso obligue a repetirlos.

NoSQL nace para escalar en horizontal. Casi todo lo que gana y todo lo que pierde se deduce de esa decisión.

Las ventajas se agrupan en dos bloques: las que afectan a quien programa y las que afectan a quien opera el sistema.

En desarrollo se gana productividad. El esquema es flexible: no hay que declarar de antemano todas las columnas ni migrar la tabla entera cuando aparece un campo nuevo, así que el modelo de datos puede cambiar al ritmo del producto. Y el ajuste con el código es mejor: un documento se parece a un objeto del lenguaje mucho más de lo que se le parece una fila repartida entre cinco tablas. La otra pieza es la agregación: los datos que se leen juntos se guardan juntos, en una sola unidad, y una lectura no necesita reconstruir nada.

En explotación se gana volumen. Son sistemas pensados para estar altamente distribuidos, para escalar añadiendo nodos y para dar un rendimiento alto en las operaciones sencillas, que son la inmensa mayoría de las que atiende una aplicación real: leer por clave y escribir.

Esquema flexible y agregación son la misma idea vista dos veces: se guarda la unidad de información completa, no repartida.

Muchos sistemas NoSQL incorporan sharding, que es el particionamiento horizontal de la información. Horizontal quiere decir que se parte por filas o por registros, no por columnas: cada máquina se queda con un subconjunto completo de los datos, no con un trozo de cada dato.

Para repartir hace falta un criterio, que se llama clave de partición o shard key. Puede ser un valor del propio dato, o el resultado de aplicarle una función hash. Por ejemplo, en una plataforma de cursos se puede repartir la actividad de los alumnos por el hash del identificador de alumno: cada nodo se queda con una parte de los alumnos y con toda su actividad.

Lo importante en examen es la consecuencia: una vez fijado el criterio, cambiarlo es complicado. No es una opción de configuración, es una redistribución de todos los datos ya almacenados mientras el sistema sigue en producción.

Conviene no confundir sharding con replicación, porque suelen ir juntos y resuelven cosas distintas. El sharding parte los datos: cada nodo guarda una porción diferente, y sirve para que quepan y para repartir la carga de escritura. La replicación copia los mismos datos en varios nodos, y sirve para tolerar caídas y para repartir la carga de lectura. Un despliegue serio hace las dos: parte en fragmentos y replica cada fragmento.

Una mala clave de partición se reconoce por dos síntomas. Si concentra la actividad en un solo nodo se produce un punto caliente, y ese nodo se satura mientras los demás están ociosos: pasa, por ejemplo, si se reparte por fecha y todo lo que se escribe hoy cae en el mismo sitio. Y si las consultas habituales no incluyen la clave, cada consulta tiene que preguntar a todos los nodos y esperar al más lento.

Sharding reparte datos distintos entre nodos. Replicación repite los mismos datos en varios nodos. No son alternativas: son capas complementarias.

El primer inconveniente es de garantías: estos sistemas, en general, no aseguran del todo las propiedades ACID de una transacción clásica. Lo habitual es ofrecer consistencia eventual, porque la información está repartida y tarda un intervalo en consolidarse en todas las copias. Ese modelo se resume con las siglas BASE, y se ve en el subtema siguiente.

El segundo es de madurez del ecosistema. Frente a un mundo relacional donde SQL es un estándar y cualquier herramienta habla con cualquier motor, en NoSQL no hay un lenguaje ni una interfaz comunes: cada producto tiene el suyo. Eso significa menos experiencia acumulada, menos compatibilidad entre productos y una dependencia real del proveedor elegido, porque migrar de un motor a otro no es cambiar una cadena de conexión, es reescribir la capa de acceso a datos.

Hay un tercer coste que se deduce del diseño: como los datos se guardan agregados y repetidos, mantener coherentes esas copias es trabajo de la aplicación, y las consultas que nadie previó al modelar salen caras o directamente no salen.

La falta de estándar es el inconveniente que más se olvida y el que más cuesta a largo plazo: en NoSQL el modelo de datos y el producto se eligen a la vez.