¿Qué es NoSQL? Modelos de datos, diferencias con SQL y cuándo usarlo

Las bases de datos NoSQL son una familia de bases de datos que utilizan modelos como documentos, pares clave-valor, columnas anchas y grafos en lugar de depender del modelo relacional de tablas. Elija una según la estructura de sus datos y las operaciones que necesita su aplicación; la etiqueta NoSQL por sí sola no garantiza consultas más rápidas ni un diseño más simple.

SQL (Lenguaje de Consulta Estructurado) es un lenguaje para consultar y manipular datos, mientras que NoSQL es una categoría que abarca múltiples modelos. “Not Only SQL” es una forma de explicar el nombre; no significa que todos los productos prohíban SQL. La visión general de NoSQL de AWS describe los diferentes modelos y propósitos.

Los cuatro principales modelos de datos NoSQL

Estas categorías describen cómo se representan los datos. Un producto puede soportar múltiples modelos, y los productos en la misma categoría pueden diferir en capacidades de consulta y operaciones.

Bases de datos clave-valor

Un modelo clave-valor busca un valor usando una clave como session:abc123. Considérelo cuando el acceso sea predecible, como al recuperar una sesión por su ID. Buscar condiciones arbitrarias dentro de los valores requiere verificar las características de indexación y consulta del producto en particular.

Los valores no tienen por qué ser cadenas simples. Redis admite hashes, listas, conjuntos y conjuntos ordenados, además de cadenas, como se describe en su referencia de tipos de datos. Para una caché, decida también dónde se guardan los datos de referencia, cuándo caducan las entradas y qué ocurre cuando falta una entrada en caché.

Bases de datos de documentos

Un documento agrupa los campos, arreglos y objetos anidados de un ítem. JSON (JavaScript Object Notation) es un formato de texto para expresar tales estructuras; MongoDB almacena documentos usando BSON (Binary JSON). Considere los documentos para ítems con diferentes atributos o para datos que comúnmente se leen juntos en una pantalla.

Elija entre incrustar información relacionada en un documento o hacer referencia al identificador de otro documento según la frecuencia de acceso, el tamaño y las actualizaciones. Copiar una dirección en cada pedido puede simplificar las lecturas, pero debe decidir qué significa la copia y cómo se mantiene. La guía de modelado de MongoDB recomienda diseñar según los patrones de acceso.

Bases de datos de columnas anchas

Los modelos de columnas anchas organizan los datos alrededor de claves de fila o partición y columnas. Bigtable utiliza un mapa ordenado por clave de fila y agrupa columnas relacionadas en familias de columnas. Su documentación del modelo de almacenamiento explica filas, columnas y familias.

Un almacén de columnas anchas no debe tratarse como lo mismo que un almacén columnar analítico que agrupa los valores de una columna. Cassandra requiere un diseño de tablas y particiones orientado a consultas y no soporta uniones relacionales. Su introducción al modelado de datos explica por qué primero debe identificar preguntas como “leer los registros de este dispositivo para este período.” Verifique que el candidato soporte las consultas de rango y agregaciones que necesita.

Bases de datos de grafos

Un grafo representa entidades, como personas, productos o servidores, como nodos y sus conexiones como aristas. Considérelo para preguntas que sigan relaciones, como identificar servicios afectados por una falla de un servidor.

Los grafos también pueden almacenar atributos. El modelo de grafo con propiedades de Neo4j permite propiedades tanto en nodos como en relaciones, como se explica en su guía sobre conceptos de grafos. Un modelo de grafo no hace que cada consulta sea rápida; defina la profundidad de recorrido, los tipos de relaciones y las condiciones de los caminos.

¿Cómo se diferencia NoSQL de una base de datos relacional?

Un sistema de gestión de bases de datos relacional (RDBMS) organiza los datos usando tablas, claves y restricciones. Proporciona una base útil para unir registros relacionados y aplicar reglas compartidas. Un producto NoSQL ofrece operaciones apropiadas para su modelo, así que compare cómo cada candidato responde a las preguntas de su aplicación en lugar de copiar un esquema existente sin cambios.

Almacenar JSON no requiere automáticamente NoSQL. PostgreSQL, por ejemplo, ofrece tipos JSON e indexación para jsonb; véase su documentación sobre tipos JSON. Mantener reglas relacionales y transacciones mientras se usan atributos flexibles para parte de los datos también es un diseño candidato.

Un esquema flexible aún necesita diseño

Un esquema define la estructura y las reglas, como los nombres de los campos, tipos y valores requeridos. Incluso si los documentos pueden tener diferentes campos, una aplicación necesita datos predecibles. Este catálogo JSON ficticio ilustra dos productos con atributos diferentes:

[
  {
    "product_id": "book-101",
    "name": "Database Basics",
    "price_krw": 24000,
    "attributes": {
      "author": "Mina Kim",
      "pages": 320
    }
  },
  {
    "product_id": "headphones-201",
    "name": "Wireless Headphones",
    "price_krw": 79000,
    "attributes": {
      "wireless": true,
      "battery_hours": 30
    }
  }
]

Ambos productos comparten product_id, name y price_krw, pero sus objetos attributes anidados difieren. Una estructura de documento expresa esa variación de manera natural. Mezclar números y cadenas en el mismo campo de precio, sin embargo, puede complicar la ordenación y el cálculo, por lo que se deben definir los tipos permitidos y el manejo de valores faltantes.

MongoDB admite reglas de validación para tipos y rangos de valores; su documentación de validación de esquemas explica cómo aplicar reglas donde sea necesario. Por el contrario, CQL (Cassandra Query Language) de Cassandra define columnas y tipos cuando se crea una tabla, como se muestra en su referencia de definición de tablas. Por lo tanto, decir “toda base de datos NoSQL no tiene esquema” es inexacto.

JSON describe una estructura; no es inherentemente un dato no estructurado. Decida por separado si las imágenes y videos pertenecen dentro de una base de datos o en almacenamiento de objetos, con sus ubicaciones y metadatos en una base de datos. El tamaño del archivo, los requisitos de entrega y las necesidades de gestión afectan esa elección.

Verifique las garantías de transacción y consistencia por producto

Soporte de transacciones y alcance

Una transacción trata los cambios como una unidad de trabajo. ACID significa Atomicidad, Consistencia, Aislamiento y Durabilidad. Para los cambios que deben tener éxito o fallar juntos, como crear un pedido y reducir el inventario, primero establezca las garantías necesarias.

NoSQL no implica una ausencia de transacciones. MongoDB admite transacciones de múltiples documentos en conjuntos de réplicas y clusters fragmentados, con garantías afectadas por la configuración de despliegue y de lectura/escritura; consulte su documentación de transacciones. DynamoDB también proporciona API transaccionales (Interfaces de Programación de Aplicaciones), pero tiene restricciones que incluyen los objetivos admitidos y el alcance de la Región. Su referencia de transacciones explica estos límites.

¿Qué puede devolver una lectura justo después de una escritura?

El comportamiento de la replicación también importa. Con lecturas eventualmente consistentes, una escritura recientemente completada puede no aparecer aún en el resultado de una lectura. Defina los requisitos por acción del usuario: ¿puede un pedido estar temporalmente ausente inmediatamente después de que el usuario lo guarde?

Las tablas de DynamoDB y los índices secundarios locales pueden usar lecturas fuertemente consistentes, mientras que las lecturas de índices secundarios globales y flujos son eventualmente consistentes. Consulte su documentación de consistencia de lectura para diferencias según el objetivo de la consulta. La consistencia ACID dentro de una transacción y la consistencia de las lecturas a través de réplicas son preocupaciones diferentes.

La escalabilidad horizontal no garantiza el rendimiento

La escalabilidad horizontal agrega servidores en lugar de reemplazar un servidor por una máquina más grande. El sharding distribuye los datos entre servidores; la replicación mantiene copias. Tener varios servidores por sí solo no garantiza datos equilibrados ni consultas más rápidas. La visión general del sharding en MongoDB describe configuraciones distribuidas por separado.

Una clave mal distribuida puede concentrar las solicitudes en una partición caliente. Por ejemplo, agrupar todos los eventos bajo una clave fija puede perjudicar la distribución de la carga. Considere los patrones de acceso y la distribución de claves juntos, como se explica en la guía de la clave de partición de DynamoDB.

El rendimiento depende del tamaño de los datos, índices, rango de consulta, proporción de lecturas y escrituras, configuración de consistencia y carga de trabajo. Compare la latencia de solicitudes lentas, fallos y comportamiento de recuperación junto con el tiempo de respuesta promedio. Incluya réplicas, copias de seguridad, redes y trabajo operativo en la evaluación de costos; la categoría NoSQL por sí sola no establece un costo más bajo.

¿Cuándo debería considerar NoSQL?

• Caché de clave conocida o acceso a sesión: considere un almacén clave-valor mientras define la expiración, persistencia y sincronización con los datos de referencia.
• Elementos de catálogo con atributos variables: considere documentos mientras diseña la validación de campos compartidos y los índices de búsqueda.
• Eventos consultados por una clave y un período conocidos: considere el almacenamiento en columnas anchas mientras verifica el tamaño de la partición y las consultas por rango.
• Recorrido de relaciones en múltiples pasos: considere un grafo al definir tipos de conexión y la profundidad del recorrido.

Cuando informes variados combinan múltiples tablas o las restricciones entre registros necesitan aplicación centralizada, una base de datos relacional merece una comparación temprana. No decida solo por una etiqueta de la industria o el volumen de datos: examine cómo funcionarían las lecturas y actualizaciones más importantes en cada candidato.

Puede asignar diferentes roles a diferentes almacenes, como usar una base de datos relacional como fuente principal de datos y un almacén de clave-valor como caché. Los almacenes adicionales también hacen que las actualizaciones de copia, la propagación de eliminaciones y la recuperación sean más complejas, por lo que agréguelos solo para un requisito demostrado.

Una secuencia de evaluación práctica

1. Anote las consultas importantes. Especifique filtros y ordenamientos para tareas como la búsqueda de productos por ID, los pedidos recientes de los usuarios o los registros diarios de un dispositivo.
2. Defina los requisitos de corrección. Registre los cambios que deben tener éxito juntos, el manejo de solicitudes duplicadas, las lecturas inmediatas y los valores obsoletos aceptables.
3. Diseñe modelos de candidatos reales. Examine el tamaño del documento, incrustaciones o referencias, índices, claves de partición y rutas de consulta a medida que los datos crecen.
4. Compare implementaciones pequeñas. Use los mismos datos y operaciones para reproducir carga normal, carga concentrada y fallos; registre las versiones del producto y la configuración.
5. Planifique la operación y la migración. Verifique permisos, copia de seguridad y restauración, monitoreo, migración, costo esperado y una ruta de regreso al almacén existente si es necesario.

Comience con las consultas y los requisitos de corrección, luego elija un modelo y un producto que los satisfagan. Si la base de datos que ya usa cumple con esos requisitos, establezca la razón para agregar otro tipo de almacén antes de introducirlo.