Veo mucha confusión sobre el lugar y el propósito de las muchas nuevas soluciones de bases de datos («bases de datos NoSQL») en comparación con las soluciones de bases de datos relacionales que han existido durante muchos años. Así que voy a tratar de explicar las diferencias y los mejores casos de uso para cada uno.
Primero vamos a aclarar estas soluciones de bases de datos en dos grupos:
1) Bases de datos relacionales, que también pueden ser llamados sistemas de gestión de bases de datos relacionales (RDBMS) o bases de datos SQL. Las más populares son Microsoft SQL Server, Oracle Database, MySQL e IBM DB2. Estos RDBMS se utilizan principalmente en escenarios de grandes empresas, con la excepción de MySQL, que se utiliza principalmente para almacenar datos para aplicaciones web, normalmente como parte de la popular pila LAMP (Linux, Apache, MySQL, PHP/ Python/ Perl).
2) Bases de datos no relacionales, también llamadas bases de datos NoSQL, siendo las más populares MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis y Neo4j. Estas bases de datos suelen agruparse en cuatro categorías: Almacenes de valores clave, almacenes de gráficos, almacenes de columnas y almacenes de documentos (véase Tipos de bases de datos NoSQL).
Todas las bases de datos relacionales pueden utilizarse para gestionar aplicaciones orientadas a las transacciones (OLTP), y la mayoría de las bases de datos no relacionales que se encuentran en las categorías Almacenes de documentos y Almacenes de columnas también pueden utilizarse para OLTP, lo que aumenta la confusión. Las bases de datos OLTP pueden considerarse como bases de datos «operacionales», caracterizadas por transacciones frecuentes y cortas que incluyen actualizaciones y que tocan una pequeña cantidad de datos y donde la concurrencia de miles de transacciones es muy importante (los ejemplos incluyen aplicaciones bancarias y reservas en línea). La integridad de los datos es muy importante, por lo que soportan transacciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad). Esto se opone a los almacenes de datos, que se consideran bases de datos «analíticas» caracterizadas por consultas largas y complejas que tocan una gran cantidad de datos y requieren muchos recursos. Las actualizaciones son poco frecuentes. Un ejemplo es el análisis de las ventas del último año.
Las bases de datos relacionales suelen trabajar con datos estructurados, mientras que las bases de datos no relacionales suelen trabajar con datos semiestructurados (es decir, XML, JSON).
Veamos cada grupo con más detalle:
Bases de datos relacionales
Una base de datos relacional se organiza en base al modelo relacional de datos, propuesto por E.F. Codd en 1970. Este modelo organiza los datos en una o más tablas (o «relaciones») de filas y columnas, con una clave única para cada fila. En general, cada tipo de entidad que se describe en una base de datos tiene su propia tabla con las filas que representan instancias de ese tipo de entidad y las columnas que representan valores atribuidos a esa instancia. Dado que cada fila de una tabla tiene su propia clave única, las filas de una tabla pueden vincularse a filas de otras tablas almacenando la clave única de la fila a la que debe vincularse (donde dicha clave única se conoce como «clave ajena»). Codd demostró que las relaciones de datos de complejidad arbitraria pueden representarse utilizando este sencillo conjunto de conceptos.
Casi todos los sistemas de bases de datos relacionales utilizan SQL (Structured Query Language) como lenguaje para consultar y mantener la base de datos.
Las razones del dominio de las bases de datos relacionales son: simplicidad, robustez, flexibilidad, rendimiento, escalabilidad y compatibilidad en la gestión de datos genéricos.
Pero para ofrecer todo esto, las bases de datos relacionales tienen que ser increíblemente complejas internamente. Por ejemplo, una sentencia SELECT relativamente sencilla podría tener docenas de posibles rutas de ejecución de consultas, que un optimizador de consultas evaluaría en tiempo de ejecución. Todo esto está oculto para los usuarios, pero bajo el capó, el RDBMS determina el mejor «plan de ejecución» para responder a las solicitudes utilizando cosas como algoritmos basados en el coste.
Para las grandes bases de datos, especialmente las utilizadas para aplicaciones web, la principal preocupación es la escalabilidad. A medida que se crean más y más aplicaciones en entornos que tienen cargas de trabajo masivas (es decir, Amazon), sus requisitos de escalabilidad pueden cambiar muy rápidamente y crecer mucho. Las bases de datos relacionales escalan bien, pero normalmente sólo cuando ese escalado se produce en un único servidor («scale-up»). Cuando se alcanza la capacidad de ese único servidor, hay que «escalar» y distribuir esa carga entre varios servidores, pasando a la llamada computación distribuida. Es entonces cuando la complejidad de las bases de datos relacionales empieza a causar problemas con su potencial de escalado. Si se intenta escalar a cientos o miles de servidores, la complejidad se vuelve abrumadora. Las características que hacen que las bases de datos relacionales sean tan atractivas son las mismas que también reducen drásticamente su viabilidad como plataformas para grandes sistemas distribuidos.
Bases de datos no relacionales
Una base de datos NoSQL proporciona un mecanismo para el almacenamiento y la recuperación de datos que se modela en medios distintos a las relaciones tabulares utilizadas en las bases de datos relacionales.
Las motivaciones para este enfoque incluyen:
- Simplicidad de diseño. No tener que lidiar con el «desajuste de impedancia» entre el enfoque orientado a objetos para escribir aplicaciones y las tablas y filas basadas en el esquema de una base de datos relacional. Por ejemplo, almacenar toda la información de los pedidos de los clientes en un solo documento en lugar de tener que unir muchas tablas, lo que se traduce en menos código que escribir, depurar y mantener
- Un mejor escalado «horizontal» a clusters de máquinas, que resuelve el problema cuando el número de usuarios concurrentes se dispara para las aplicaciones que son accesibles a través de la web y los dispositivos móviles. El uso de documentos hace que sea mucho más fácil escalar, ya que toda la información de ese pedido del cliente está contenida en un solo lugar en lugar de estar dispersa en múltiples tablas. Las bases de datos NoSQL distribuyen automáticamente los datos entre los servidores sin necesidad de realizar cambios en la aplicación (auto-sharding), lo que significa que distribuyen los datos de forma nativa y automática entre un número arbitrario de servidores, sin necesidad de que la aplicación conozca la composición del conjunto de servidores. Los datos y la carga de las consultas se equilibran automáticamente entre los servidores, y cuando un servidor se cae, puede ser sustituido de forma rápida y transparente sin que la aplicación se vea afectada
- Un mayor control sobre la disponibilidad. Los servidores pueden añadirse o eliminarse sin que la aplicación deje de funcionar. La mayoría de las bases de datos NoSQL soportan la replicación de datos, almacenando múltiples copias de datos a través del clúster o incluso a través de los centros de datos, para asegurar una alta disponibilidad y recuperación de desastres
- Para capturar fácilmente todo tipo de datos «Big Data» que incluyen datos no estructurados y semi-estructurados. Permitir una base de datos flexible que pueda acomodar fácil y rápidamente cualquier nuevo tipo de datos y que no se vea interrumpida por cambios en la estructura del contenido. Esto se debe a que las bases de datos de documentos no tienen esquema, lo que permite añadir libremente campos a los documentos JSON sin tener que definir primero los cambios (esquema en lectura en lugar de esquema en escritura). Se pueden tener documentos con un número de campos diferente al de otros documentos. Por ejemplo, un registro de paciente que puede contener o no campos que enumeran alergias
- Velocidad. Las estructuras de datos utilizadas por las bases de datos NoSQL (es decir, los documentos JSON) difieren de las utilizadas por defecto en las bases de datos relacionales, lo que hace que muchas operaciones sean más rápidas en NoSQL que en las bases de datos relacionales al no tener que unir tablas (a costa de un mayor espacio de almacenamiento debido a la duplicación de datos, pero el espacio de almacenamiento es tan barato hoy en día que esto no suele ser un problema). De hecho, la mayoría de las bases de datos NoSQL ni siquiera admiten uniones
- Coste. Las bases de datos NoSQL suelen utilizar clusters de servidores baratos, mientras que los RDBMS tienden a depender de costosos servidores y sistemas de almacenamiento propietarios. Además, las licencias de los sistemas RDBMS pueden ser bastante caras, mientras que muchas bases de datos NoSQL son de código abierto y, por tanto, gratuitas
La idoneidad particular de una determinada base de datos NoSQL depende del problema que deba resolver.
Las bases de datos NoSQL se utilizan cada vez más en aplicaciones web de big data y en tiempo real. Se hicieron populares con la introducción de la web, cuando las bases de datos pasaron de un máximo de unos cientos de usuarios en una aplicación interna de la empresa a miles o millones de usuarios en una aplicación web. Los sistemas NoSQL también se denominan «No sólo SQL» para destacar que también pueden soportar lenguajes de consulta similares a SQL.
Muchos almacenes NoSQL comprometen la consistencia (en el sentido del teorema CAP) en favor de la disponibilidad y la tolerancia a las particiones. Algunas de las razones que bloquean la adopción de los almacenes NoSQL son el uso de lenguajes de consulta de bajo nivel, la falta de interfaces estandarizadas y las enormes inversiones en el SQL existente. Además, la mayoría de los almacenes NoSQL carecen de verdaderas transacciones ACID o sólo admiten transacciones en determinadas circunstancias y a ciertos niveles (por ejemplo, a nivel de documento). Por último, los RDBMS suelen ser mucho más sencillos de utilizar, ya que cuentan con interfaces gráficas de usuario, mientras que muchas soluciones NoSQL utilizan una interfaz de línea de comandos.
Comparando las dos
Una de las limitaciones más severas de las bases de datos relacionales es que cada elemento sólo puede contener un atributo. Si utilizamos el ejemplo de un banco, cada aspecto de la relación de un cliente con un banco se almacena como elementos de fila separados en tablas separadas. Así, los datos maestros del cliente están en una tabla, los datos de la cuenta están en otra tabla, los datos del préstamo en otra, las inversiones en otra tabla, etc. Todas estas tablas están vinculadas entre sí mediante el uso de relaciones como claves primarias y claves foráneas.
Las bases de datos no relacionales, concretamente los almacenes de clave-valor de una base de datos o pares clave-valor, son radicalmente diferentes de este modelo. Los pares clave-valor permiten almacenar varios elementos relacionados en una «fila» de datos en la misma tabla. Ponemos la palabra «fila» entre comillas porque una fila aquí no es realmente lo mismo que la fila de una tabla relacional. Por ejemplo, en una tabla no relacional del mismo banco, cada fila contendría los datos del cliente, así como los de su cuenta, préstamo e inversión. Todos los datos relativos a un cliente estarían convenientemente almacenados juntos como un solo registro.
Este parece un método obviamente superior de almacenamiento de datos, pero tiene un inconveniente importante: los almacenes de valor-clave, a diferencia de las bases de datos relacionales, no pueden reforzar las relaciones entre los elementos de datos. Por ejemplo, en nuestra base de datos de valores clave, los detalles del cliente (nombre, seguridad social, dirección, número de cuenta, número de tramitación del préstamo, etc.) se almacenarían todos como un solo registro de datos (en lugar de almacenarse en varias tablas, como en el modelo relacional). Las transacciones del cliente (retiros de la cuenta, depósitos en la cuenta, reembolsos de préstamos, gastos bancarios, etc.) también se almacenarían como otro registro de datos único.
En el modelo relacional, hay un método incorporado e infalible para asegurar y hacer cumplir la lógica y las reglas de negocio en la capa de la base de datos, por ejemplo, que un retiro se cargue a la cuenta bancaria correcta, a través de claves primarias y claves externas. En los almacenes de valores clave, esta responsabilidad recae directamente en la lógica de la aplicación y mucha gente se siente muy incómoda dejando esta responsabilidad crucial sólo en manos de la aplicación. Esta es una de las razones por las que las bases de datos relacionales seguirán utilizándose.
Sin embargo, cuando se trata de aplicaciones basadas en la web que utilizan bases de datos, el aspecto de aplicar rigurosamente la lógica de negocio no suele ser una de las principales prioridades. La mayor prioridad es la capacidad de dar servicio a un gran número de peticiones de los usuarios, que suelen ser consultas de sólo lectura. Por ejemplo, en un sitio como eBay, la mayoría de los usuarios simplemente navegan y miran los artículos publicados (operaciones de sólo lectura). Sólo una parte de estos usuarios puja o reserva los artículos (operaciones de lectura y escritura). Y recuerde que estamos hablando de millones, a veces miles de millones, de páginas vistas al día. Los administradores del sitio de eBay están más interesados en un tiempo de respuesta rápido para garantizar una carga más rápida de la página para los usuarios del sitio, en lugar de las prioridades tradicionales de hacer cumplir las reglas de negocio o garantizar un equilibrio entre lecturas y escrituras.
Las bases de datos de modelo relacional pueden ajustarse y configurarse para ejecutar operaciones de sólo lectura a gran escala a través de almacenes de datos, y así servir potencialmente a una gran cantidad de usuarios que consultan una gran cantidad de datos, especialmente cuando se utilizan arquitecturas MPP relacionales como Analytics Platform System, Teradata, Oracle Exadata o IBM Netezza, que admiten el escalado. Como ya se ha mencionado, los almacenes de datos se diferencian de las bases de datos típicas en que se utilizan para un análisis más complejo de los datos. Esto difiere de la base de datos transaccional (OLTP), cuyo uso principal es dar soporte a los sistemas operativos y ofrecer informes diarios a pequeña escala.
Sin embargo, el verdadero reto es la falta de escalabilidad del modelo relacional cuando se trata de aplicaciones OLTP, o cualquier solución con muchas escrituras individuales, que es el dominio de las arquitecturas relacionales SMP. Aquí es donde los modelos no relacionales pueden brillar realmente. Pueden distribuir fácilmente sus cargas de datos entre docenas, cientos y, en casos extremos (piense en la búsqueda de Google) incluso miles de servidores. Como cada servidor maneja sólo un pequeño porcentaje del total de solicitudes de los usuarios, el tiempo de respuesta es muy bueno para cada usuario individual. Aunque este modelo de computación distribuida puede construirse para bases de datos relacionales, es un verdadero dolor de cabeza a la hora de implementarlo, especialmente cuando hay muchas escrituras (es decir, OLTP), requiriendo técnicas como la fragmentación, que normalmente requiere una codificación significativa fuera de la lógica de negocio de la aplicación. Esto se debe a que el modelo relacional insiste en la integridad de los datos en todos los niveles, que debe mantenerse, incluso cuando los datos son accedidos y modificados por varios servidores diferentes. Esta es la razón por la que el modelo no relacional es la arquitectura elegida para aplicaciones web como la computación en la nube y las redes sociales.
Así que, en resumen, los RDBMS no tienen escalado horizontal para altas cargas de transacciones (millones de lecturas-escrituras), mientras que las bases de datos NoSQL resuelven las altas cargas de transacciones pero a costa de la integridad de los datos y las uniones.
Tenga en cuenta que muchas soluciones utilizarán una combinación de bases de datos relacionales y no relacionales (vea ¿Qué es la persistencia políglota?).
También hay que tener en cuenta que es posible que no se necesite el rendimiento de una base de datos no relacional y que, en su lugar, baste con almacenar archivos en HDFS y utilizar Apache Hive (Apache Hive es una infraestructura de almacén de datos construida sobre Hadoop para proporcionar resumen, consulta y análisis de datos que proporciona a través de un lenguaje similar a SQL llamado HiveQL).
Y para terminar con una nota que aumenta la confusión, tenemos otra categoría que se está formando llamada NewSQL: NewSQL es una clase de RDBMS modernos que pretenden ofrecer el mismo rendimiento escalable de los sistemas NoSQL para cargas de trabajo de lectura y escritura OLTP, al tiempo que mantienen las garantías ACID de un sistema de base de datos relacional tradicional. Las desventajas son que no sirven para consultas de tipo OLAP y que son inapropiados para bases de datos de más de unos pocos terabytes. Algunos ejemplos son VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix y Altibase.
Una imagen que muestra las categorías en las que encajan muchos de los productos:
Un excelente gráfico que muestra cómo encajan todas las tecnologías en la nube de Azure es de Understanding NoSQL on Microsoft Azure:
La conclusión para usar una solución NoSQL es si tienes una aplicación OLTP que tiene miles de usuarios y tiene una base de datos muy grande que requiere una solución scale-out y/o está usando datos JSON, en particular si estos datos JSON tienen varias estructuras. También se obtiene el beneficio de la alta disponibilidad, ya que las soluciones NoSQL almacenan múltiples copias de los datos. Sólo hay que tener en cuenta que por el rendimiento se puede sacrificar la consistencia de los datos, así como la capacidad de unirse a los datos, utilizar SQL, y hacer actualizaciones masivas rápidas.
Más información:
MySQL vs MongoDB
MySQL vs. MongoDB. MongoDB: Mirando a las bases de datos relacionales y no relacionales
10 cosas que debes saber sobre las bases de datos NoSQL
Introducción a las bases de datos
Diferencia entre SQL y NoSQL : Comparación
Diferencias entre las bases de datos SQL y NoSQL explicadas con pocos ejemplos de DB
NoSQL, NewSQL, o RDBMS: Cómo elegir
NewSQL – RDBMS en esteroides
Bases de datos NoSQL vs NewSQL Elija la herramienta correcta para el trabajo correcto
SQL vs NoSQL: sí quieres tener un almacenamiento relacional por defecto
Oracle defiende las BD relacionales frente a los competidores NoSQL
Entendiendo NoSQL en Microsoft Azure
Conoce la vanguardia de las nuevas bases de datos relacionales
¿SQL o NoSQL? Esa es la cuestión de las bases de datos
Teorema CAP: Revisited
¿Qué hay de nuevo en NewSQL?
MongoDB vs MySQL: Un estudio comparativo sobre bases de datos
Características y diferencias de las bases de datos SQL y NoSQL