> For the complete documentation index, see [llms.txt](https://sorodriguezz.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sorodriguezz.gitbook.io/docs/system-design/fundamentos-de-bases-de-datos/sql-vs-nosql.md). # SQL vs NoSQL Una de las decisiones más importantes que tomamos al diseñar un sistema es **elegir entre una base de datos relacional (SQL) o no relacional (NoSQL).** Ambos tienen sus fortalezas y casos de uso, pero difieren significativamente en su enfoque del **almacenamiento** y **recuperación** de datos . Este artículo explorará **siete diferencias clave** entre las bases de datos SQL y NoSQL para ayudarlo a comprender cuál podría ser la más adecuada para sus necesidades específicas. ## 1. Modelo de datos El **modelo de datos** de una base de datos define cómo se almacenan, organizan y relacionan los datos. ### **SQL** **Las bases de datos SQL** utilizan un **modelo de datos relacionales** donde los datos se almacenan en **tablas (** a menudo denominadas relaciones **).** Cada tabla tiene **filas** (tuplas) que representan registros individuales y **columnas** que representan atributos de esos registros. La **clave principal** identifica de forma única cada registro, mientras que **las claves externas** vinculan tablas entre sí, lo que permite realizar consultas relacionales. **Ejemplo:** Consideremos un **sistema de gestión de usuarios** con dos tablas: `Users` y `Orders`. La `Users` tabla contiene los detalles de los usuarios y la `Orders` tabla almacena los detalles de los pedidos vinculados a usuarios específicos.
El **UserID** en la `Orders` tabla es una **clave externa** que hace referencia a la `Users` tabla, estableciendo una relación entre los usuarios y sus pedidos. Este enfoque estructurado es ideal para aplicaciones que requieren **consultas complejas** y **uniones** entre tablas. ### **NoSQL** Las bases de datos NoSQL utilizan modelos de datos **flexibles** y **no relacionales** , lo que permite diversas formas de almacenar y gestionar datos. **a) Modelo clave-valor (por ejemplo, Redis)** El modelo clave-valor es el modelo NoSQL más simple, donde los datos se almacenan como pares **clave-valor** . Este modelo es ideal para aplicaciones que requieren **búsquedas rápidas** mediante una clave única. Para el mismo **sistema de gestión de usuarios** , los datos del usuario se pueden almacenar como pares clave-valor, donde la clave es `UserID`y el valor es la información del usuario asociada. ```shell Key: 1 Value: { "name": "John", "email": "john@email.com", "age": 28 } Key: 2 Value: { "name": "Mike", "email": "mike@email.com", "age": 31 } ``` Este modelo es muy eficiente para **búsquedas simples** , pero no admite consultas complejas ni relaciones entre datos. **b) Modelo de documento (por ejemplo, MongoDB)** En el modelo de documento, los datos se almacenan como **documentos** en formatos como **JSON** o **BSON** . Cada documento contiene un **identificador único (clave)** y un conjunto de **pares clave-valor** **(atributos)** . Los documentos pueden tener diversas estructuras, lo que hace que el modelo de documento sea flexible o no requiera esquemas. Modelemos el mismo **sistema de gestión de usuarios** utilizando una base de datos de documentos. ```json { "_id": 1, "name": "John", "email": "john@email.com", "age": 28, "orders": [ { "orderId": 101, "product": "Laptop", "price": 1200 }, { "orderId": 104, "product": "Smartphone", "price": 800 } ] } ``` En este modelo de documento, cada documento de usuario contiene una matriz integrada de pedidos, lo que permite el almacenamiento jerárquico dentro de un solo documento. **c) Modelo de familia de columnas (por ejemplo, Cassandra)** En el modelo de familia de columnas, los datos se organizan en filas y columnas, pero a diferencia del modelo relacional, cada fila puede tener un **número variable de columnas.** Está optimizado para **consultas rápidas** y **almacenamiento distribuido a gran escala** . **Ejemplo:** Supongamos que estamos construyendo un **sistema de seguimiento de la actividad del usuario** que almacena las acciones que los usuarios realizan en un sitio web, como páginas vistas y compras. Cada usuario tiene un `UserID`, y su actividad (visitas de página y compras) se almacena en una familia de columnas. | **Clave de fila (ID de usuario)** | **Página 1** | **Página 2** | **Compra1** | **Compra2** | | --------------------------------- | ----------------------- | ------------------ | ---------------------------- | ------------------------- | | 1 | Visto: Página de inicio | Vistos: Productos | Producto: Laptop ($1200) | Producto: Teléfono ($800) | | 2 | Visto: Página de inicio | Visto: Contáctenos | Producto: TV ($1500) | - | | 3 | Vistos: Productos | - | Producto: Auriculares ($150) | - | **Clave de fila (ID de usuario)** : el identificador único para cada usuario. **Página1, Página2, Compra1, Compra2** : columnas que representan la actividad del usuario, que puede variar de una fila a otra. * En la **fila 1** , el usuario 1 ha visto dos páginas y realizado dos compras. * En la **fila 2** , el usuario 2 ha visto dos páginas y ha realizado una compra. * En la **fila 3** , el usuario 3 vio una página y realizó una compra. Cada usuario (fila) puede tener una **cantidad variable de columnas** y diferentes usuarios pueden tener diferentes actividades almacenadas en cada fila. **No** se requiere un esquema predefinido, lo que significa que se pueden agregar nuevas columnas (como visitas a páginas adicionales o compras) de forma dinámica para cada usuario. Este modelo permite un alto rendimiento de escritura y almacenamiento distribuido, pero no impone relaciones estrictas como el modelo relacional de SQL. **d) Modelo gráfico (por ejemplo, Neo4j)** En el modelo gráfico, los datos se almacenan como **nodos** , **aristas** y **propiedades** . Este modelo es ideal para aplicaciones donde las relaciones entre datos son complejas y están altamente interconectadas (p. ej., redes sociales). En nuestro **sistema de gestión de usuarios** , los usuarios pueden representarse como nodos y las relaciones entre ellos (por ejemplo, amistades o pedidos) pueden representarse como bordes. **Representación gráfica** : * Nodos: `Users`, `Orders` * Bordes: `PLACED_ORDER` ```shell (John) --PLACED_ORDER--> (Laptop) (Mike) --PLACED_ORDER--> (Smartphone) (Ron) --PLACED_ORDER--> (Headphones) ``` En este modelo, consultar relaciones (por ejemplo, encontrar todos los pedidos realizados por un usuario) es muy eficiente, especialmente para aplicaciones con datos interconectados complejos. ## 2. Esquema ### SQL En las bases de datos SQL, el esquema debe **definirse previamente** antes de insertar cualquier dato. Cada tabla tiene un conjunto específico de columnas con tipos de datos, restricciones y relaciones definidos. La base de datos aplica este esquema, garantizando que cada fila se ajuste a la estructura predefinida. Esta **aplicación de esquema** garantiza la integridad de los datos, lo que hace que las bases de datos SQL sean ideales para aplicaciones donde la consistencia y la precisión son fundamentales. Sin embargo, esta rigidez puede dificultar la adaptación a requisitos cambiantes. **Ejemplo: Tablas de usuarios y pedidos en SQL** Tomemos como ejemplo un **sistema de gestión de usuarios** . En SQL, primero definimos la estructura (esquema) de las tablas `Users` y `Orders` antes de agregar datos. ```sql CREATE TABLE Users ( UserID INT PRIMARY KEY, Name VARCHAR(100), Email VARCHAR(100), Age INT ); CREATE TABLE Orders ( OrderID INT PRIMARY KEY, UserID INT, Product VARCHAR(100), Price DECIMAL(10, 2), FOREIGN KEY (UserID) REFERENCES Users(UserID) ); ``` En este esquema: * La `Users` tabla tiene columnas fijas: `UserID`, `Name`, `Email`, y `Age`. * La `Orders` tabla tiene columnas fijas: `OrderID`, `UserID`, `Product`, y `Price`. * **Las claves externas** se utilizan para establecer relaciones entre tablas. En las bases de datos SQL, cambiar el esquema puede ser un proceso complejo. Si necesita agregar una nueva columna, modificar un tipo de datos o cambiar relaciones, a menudo se requieren **migraciones de esquema** . Esto puede provocar **tiempos de inactividad** o una planificación cuidadosa en los sistemas de producción para evitar interrupciones. **Ejemplo: Agregar una nueva columna en SQL** `ALTER TABLE Users ADD COLUMN Address VARCHAR(255);` Esta operación modifica el esquema para incluir un `Address` campo. Es necesario actualizar cada registro y podrían necesitarse valores predeterminados para los datos existentes. ### **NoSQL** En las bases de datos NoSQL, no existe **un esquema fijo** que deba definirse de antemano. Esto permite estructuras de datos flexibles y dinámicas, donde diferentes registros pueden tener diferentes atributos. Esta flexibilidad hace que las bases de datos NoSQL sean adecuadas para aplicaciones donde los formatos de datos pueden evolucionar con el tiempo. En las bases de datos NoSQL, los cambios de esquema son mucho más sencillos porque el esquema es **dinámico** . Se pueden agregar nuevos campos a registros individuales sin afectar a otros registros ni requerir una migración del esquema. **Ejemplo: Usuario y pedidos en una base de datos de documentos (por ejemplo, MongoDB)** En una base de datos NoSQL basada en documentos, como MongoDB, se almacenan datos de usuarios y pedidos en un solo documento. ```json { "_id": 1, "name": "John", "email": "john@email.com", "age": 28, "orders": [ { "orderId": 101, "product": "Laptop", "price": 1200 }, { "orderId": 104, "product": "Smartphone", "price": 800 } ] } ``` En otro documento la estructura puede diferir: ```json { "_id": 3, "name": "Ron", "email": "ron@email.com", "age": 26, "orders": [ { "orderId": 103, "product": "Headphones", "price": 150 } ], "loyaltyPoints": 500 } ``` En este esquema flexible: * El primer documento contiene detalles del usuario junto con dos pedidos. * El segundo documento tiene detalles de usuario, un pedido y un atributo adicional ( `loyaltyPoints`), que no está presente en el primer documento. ## 3. Escalabilidad ### **SQL** **Las bases de datos SQL** generalmente están diseñadas para escalar **verticalmente** (también conocido como **escalamiento ascendente** ).
Esto significa mejorar el rendimiento y la capacidad agregando **más potencia** (por ejemplo, CPU, RAM o almacenamiento) a un solo servidor. Este enfoque funciona bien para cargas moderadas, pero se vuelve limitante cuando la aplicación escala a altos niveles de tráfico o crecimiento de datos. Las bases de datos SQL dependen del mantenimiento de propiedades **ACID** (atomicidad, consistencia, aislamiento, durabilidad), lo que dificulta el escalamiento horizontal debido a la complejidad de las transacciones y uniones distribuidas. ### **NoSQL** **Las bases de datos NoSQL** están diseñadas para escalar **horizontalmente** (también conocido como **escalamiento horizontal** ).
Esto significa aumentar la capacidad agregando **más servidores** o nodos a un sistema distribuido. Esta arquitectura distribuida permite que las bases de datos NoSQL manejen volúmenes masivos de datos y cargas de tráfico elevadas de manera más eficiente. Cada nodo maneja una parte de los datos, lo que permite una mejor distribución de la carga y tolerancia a fallas. ## 4. Lenguaje de consulta Una de las diferencias más significativas entre las bases de datos SQL y NoSQL es el **lenguaje de consulta** utilizado para interactuar con los datos. ### **SQL** **SQL (lenguaje de consulta estructurado)** es el lenguaje estándar de facto utilizado para interactuar con bases de datos relacionales para realizar operaciones como **recuperación** , **inserción** , **actualización** y **eliminación** de datos . Es **declarativo** , lo que significa que usted especifica qué datos desea y el motor de base de datos determina cómo recuperarlos. SQL permite la recuperación, agregación, filtrado y manipulación de datos de gran alcance, lo que lo hace ideal para manejar relaciones complejas entre tablas en una base de datos relacional. **Ejemplo:** **Obtener usuarios mayores de 25 años y sus pedidos** ```sql SELECT Users.Name, Users.Email, Orders.Product, Orders.Price FROM Users JOIN Orders ON Users.UserID = Orders.UserID WHERE Users.Age > 25; ``` En esta consulta: * La `JOIN` operación combina las tablas `Users` y `Orders` en función del `UserID`. * La `WHERE` cláusula filtra a los usuarios cuya edad sea menor de 25 años. * El resultado es una lista de usuarios y sus pedidos correspondientes. ### **NoSQL** Las bases de datos NoSQL no tienen un lenguaje de consulta estándar. Cada base de datos NoSQL puede tener su propia sintaxis de consulta o API, dependiendo de su modelo de datos. Si bien esto puede proporcionar más flexibilidad, también implica una curva de aprendizaje más pronunciada y posibles limitaciones en las capacidades de consulta. **Ejemplo:** En una base de datos NoSQL basada en documentos como **MongoDB** , los datos se almacenan en **documentos tipo JSON** . MongoDB proporciona su propio lenguaje de consulta, que utiliza la sintaxis JSON para consultar los documentos. Las consultas en MongoDB permiten un filtrado, una clasificación y una agregación potentes, pero funcionan en el nivel de documento individual en lugar de en múltiples tablas. En MongoDB, los usuarios y sus pedidos se almacenan juntos en un solo documento. **Ejemplo:** **Obtener usuarios mayores de 25 años y sus pedidos** ```typescript db.Users.find( { "age": { $gt: 25 } }, { "name": 1, "email": 1, "orders.product": 1, "orders.price": 1 } ); ``` En esta consulta de MongoDB: * La `find` operación busca documentos donde la edad del usuario sea mayor a 25 años. * El segundo parámetro es una proyección que especifica qué campos devolver: el nombre del usuario, el correo electrónico y el `product` de `price` sus pedidos. La misma consulta en una **base de datos gráfica** podría verse así: ```shellscript MATCH (u:User)-[:PLACED_ORDER]->(o:Order) WHERE u.age > 25 RETURN u.name, o.product, o.price; ``` ## **5. Soporte de transacciones** **Las transacciones** en bases de datos garantizan que una serie de operaciones se ejecuten de manera confiable y consistente. Las transacciones son particularmente importantes en aplicaciones donde se deben completar múltiples operaciones juntas, como transferir dinero entre cuentas bancarias o garantizar que un grupo de actualizaciones de bases de datos tengan éxito o fallen todas. ### **SQL** **Las bases de datos SQL** son conocidas por su sólido soporte de **transacciones ACID** . * **Atomicidad** : Una transacción se considera una unidad única e indivisible. Todas las operaciones de la transacción se ejecutan correctamente o ninguna se aplica (todo o nada). * **Consistencia** : las transacciones llevan la base de datos de un estado válido a otro, manteniendo todas las reglas predefinidas, como restricciones, desencadenadores y tipos de datos. * **Aislamiento** : pueden ocurrir múltiples transacciones simultáneamente sin interferir entre sí, lo que garantiza que el estado intermedio de una transacción no sea visible para otras transacciones. * **Durabilidad** : una vez que se confirma una transacción, se garantiza que sus resultados persistirán, incluso en el caso de una falla del sistema. Esto hace que las bases de datos SQL sean ideales para aplicaciones donde **la integridad** y **la consistencia** de los datos son fundamentales, como los sistemas financieros. **Ejemplo:** **Transferencia bancaria en SQL** Considere un sistema bancario donde necesita transferir $500 de la cuenta del Usuario A a la cuenta del Usuario B. Esta operación requiere dos pasos: debitar la cuenta del usuario A y acreditar la cuenta del usuario B. Ambos pasos deben tener éxito o fracasar juntos para garantizar que el sistema permanezca consistente. ```sql START TRANSACTION; -- Debit User A's account UPDATE Accounts SET balance = balance - 500 WHERE user_id = 'A'; -- Credit User B's account UPDATE Accounts SET balance = balance + 500 WHERE user_id = 'B'; COMMIT; ``` Si falla la operación de débito o crédito (por ejemplo, fondos insuficientes), se revertirá toda la transacción, dejando ambas cuentas sin cambios. ### **NoSQL** **Las bases de datos NoSQL** generalmente no priorizan las transacciones ACID completas debido a la necesidad de alta **disponibilidad** y **escalabilidad** en entornos distribuidos. En cambio, muchas bases de datos NoSQL siguen el modelo **BASE** : * **Básicamente disponible** : el sistema garantiza la disponibilidad, lo que significa que los datos siempre se pueden leer o escribir, incluso si algunos nodos en el sistema distribuido no están disponibles. * **Estado blando** : el sistema puede estar en un estado temporalmente inconsistente, pero con el tiempo se alcanzará una consistencia final. * **Consistencia eventual** : Con el tiempo, el sistema alcanzará la consistencia, aunque puede que no sea inmediata. Esto compensa la consistencia inmediata con una mayor disponibilidad. El modelo BASE está diseñado para escenarios donde no se requiere una consistencia estricta y **el rendimiento** y **la disponibilidad** son más importantes, como análisis de datos en tiempo real, plataformas de redes sociales o aplicaciones distribuidas a gran escala. Si bien algunas bases de datos NoSQL ofrecen características similares a ACID, generalmente son menos sólidas que las de las bases de datos SQL. **Ejemplo:** **Actualización condicional de Cassandra (transacción ligera):** Cassandra no admite transacciones ACID completas en varias filas o tablas. En su lugar, ofrece **transacciones ligeras** para operaciones que requieren una consistencia limitada. ```sql BEGIN TRANSACTION; UPDATE Users SET balance = balance - 500 WHERE user_id = 'A' IF balance >= 500; UPDATE Users SET balance = balance + 500 WHERE user_id = 'B'; APPLY BATCH; ``` Cassandra garantiza la atomicidad de un lote de actualizaciones, pero no admite transacciones complejas de múltiples tablas como las bases de datos SQL. ## 6. Rendimiento ### **SQL** Las bases de datos SQL están optimizadas para manejar **consultas complejas** que involucran **múltiples uniones** , **agregaciones** y **transacciones** . Para **conjuntos de datos pequeños** , las bases de datos SQL funcionan bien, ya que el optimizador de consultas puede ejecutar uniones y filtrar datos de manera eficiente. A medida que crece el conjunto de datos, **el rendimiento puede degradarse** debido a la complejidad de unir tablas grandes, especialmente si **la indexación** no está optimizada. Su rendimiento puede ser excelente para **aplicaciones de lectura intensiva** con esquemas bien definidos y donde la integridad de los datos es primordial. Sin embargo, pueden tener dificultades con operaciones **de escritura intensiva** a escala sin **una indexación** y **optimización** adecuadas . **La sobrecarga de transacciones** también puede reducir el rendimiento cuando se ejecutan múltiples consultas en una sola transacción. ### **NoSQL** Las bases de datos NoSQL están optimizadas para ofrecer un alto rendimiento a escala, especialmente para **grandes volúmenes de datos no estructurados o semiestructurados** . Priorizan **la escalabilidad horizontal** y están optimizados para **operaciones de lectura/escritura de alto rendimiento** , lo que los hace ideales para aplicaciones en tiempo real, big data y sistemas distribuidos a gran escala. Para **conjuntos de datos grandes** , el rendimiento sigue siendo alto a medida que se agregan nodos adicionales al clúster, distribuyendo la carga de trabajo. Las bases de datos NoSQL generalmente tienen **un rendimiento de escritura más rápido** en comparación con SQL porque: * **Consistencia eventual** : en sistemas NoSQL distribuidos, los datos no tienen que ser inmediatamente consistentes en todos los nodos, lo que reduce la necesidad de bloqueos y aumenta la velocidad de escritura. * **Modelo de datos desnormalizado** : las bases de datos NoSQL a menudo almacenan datos relacionados juntos en un solo documento, lo que significa menos operaciones de escritura en comparación con el modelo SQL normalizado. ## 7. Casos de uso La elección entre bases de datos SQL y NoSQL a menudo depende del caso de uso específico, ya que cada tipo de base de datos se destaca en diferentes escenarios. ### **SQL** Las bases de datos SQL son ideales para aplicaciones que requieren: * **Datos estructurados** con esquemas predefinidos. * **Consultas complejas** que involucran uniones, agregaciones y transacciones. * **Fuerte consistencia** y propiedades **ACID (atomicidad, consistencia, aislamiento, durabilidad).** * **Datos relacionales** donde las relaciones entre tablas son importantes. Se utilizan comúnmente en industrias como finanzas, atención médica y gobierno, donde la integridad de los datos y las estructuras relacionales son primordiales. ### **NoSQL** Las bases de datos NoSQL son ideales para casos de uso que requieren: * **Escalabilidad horizontal** para manejar grandes cantidades de datos distribuidos. * **Lecturas y escrituras de alto rendimiento** para aplicaciones en tiempo real. * **Esquema flexible** para almacenar datos no estructurados o semiestructurados. * **Consistencia eventual** y alta disponibilidad en sistemas distribuidos. Son populares en industrias como las redes sociales, la IoT y el análisis de big data, donde la flexibilidad y la escalabilidad son más importantes que la consistencia estricta. ## 8. Conclusión A continuación se muestra una tabla final que compara las bases de datos **SQL** y **NoSQL** en diferentes aspectos clave:
En resumen, tanto las bases de datos SQL como NoSQL tienen sus fortalezas y debilidades, y la elección entre ellas depende de las necesidades específicas de su aplicación. Si su aplicación requiere datos estructurados, consultas complejas y gestión de transacciones, una base de datos SQL es probablemente la mejor opción. Sin embargo, si su aplicación exige escalabilidad, flexibilidad y la capacidad de manejar datos no estructurados, una base de datos NoSQL puede ser más adecuada.