Llegamos a ustedes gracias a:



Reportajes y análisis

SQL vs NoSQL: Cuál elegir

[01/08/2022] Al desarrollar una aplicación, una de las decisiones más fundamentales que se deben tomar es si usted debería usar una base de datos SQL o NoSQL para almacenar los datos. Las bases de datos convencionales, es decir, las bases de datos relacionales que usan SQL (lenguaje de consulta estructurado) para las consultas, son el producto de décadas de evolución tecnológica, buenas prácticas y pruebas de estrés reales. Están diseñadas para transacciones confiables y consultas ad hoc, los elementos básicos de las aplicaciones de línea de negocios. Pero también vienen cargadas de restricciones, como esquemas rígidos, que las hacen menos adecuadas para otro tipo de aplicaciones.

Las bases de datos NoSQL surgieron en respuesta a esas limitaciones. La manera en que los sistemas NoSQL almacenan y administran datos permite que los desarrolladores dispongan de una alta velocidad operativa y una gran flexibilidad. Muchas fueron desarrolladas por compañías como Google, Amazon, Yahoo y Facebook, que buscaban mejores formas de almacenar contenido o procesar datos para páginas web masivas. A diferencia de las bases de datos SQL, muchas bases de datos NoSQL pueden adaptar su escala horizontalmente en cientos o miles de servidores.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

Sin embargo, las ventajas de NoSQL tienen un costo. Los sistemas NoSQL favorecen la velocidad, así como la adaptabilidad de escala, por encima de las propiedades ACID de las transacciones confiables respaldadas por las bases de datos SQL. Asimismo, en comparación con las décadas de conocimiento institucional acumulado en torno a SQL, las metáforas utilizadas para trabajar con datos en sistemas NoSQL también son relativamente nuevas.

Las bases de datos SQL y NoSQL ofrecen diferentes compensaciones. Si bien pueden competir en el contexto de un proyecto específico, como en cuál elegir para esta aplicación o aquella aplicación, son complementarios en el panorama general. Cada uno es adecuado para diferentes casos de uso. La decisión no es tanto un caso de uno u otro, sino sobre qué herramienta es la adecuada para el trabajo.

NoSQL frente a SQL

La diferencia fundamental entre SQL y NoSQL no es tan complicada. Cada uno tiene una filosofía diferente sobre cómo se deben almacenar y recuperar los datos.

Con las bases de datos SQL, todos los datos tienen una estructura inherente. Una base de datos convencional, como Microsoft SQL Server, MySQL, PostgreSQL u Oracle Database, utiliza un esquema, una definición formal de cómo se compondrán los datos insertados en la base de datos. Por ejemplo, una determinada columna en una tabla puede estar restringida solo a números enteros. Como resultado, los datos registrados en la columna tendrán un alto grado de normalización. El esquema rígido de una base de datos SQL también hace que sea relativamente fácil realizar agregaciones en los datos, por ejemplo, combinando datos de dos tablas mediante el comando SQL JOIN.

Con NoSQL, los datos se pueden almacenar sin esquema o de forma libre. Cualquier dato puede almacenarse en cualquier registro. Entre las bases de datos NoSQL, encontrará cuatro modelos comunes para almacenar datos, los cuales conducen a cuatro tipos comunes de sistemas NoSQL:

  1. Bases de datos de documentos (por ejemplo, MongoDB). Los datos insertados se almacenan en forma de estructuras JSON sin esquema, o "documentos, donde los datos pueden ser cualquier cosa, desde números enteros hasta cadenas y texto de formato libre. No hay una necesidad inherente de especificar qué campos, si los hay, contendrá un documento JSON.
  2. Almacenes de clave-valor (por ejemplo, Redis). Se accede a los valores de forma libre, desde enteros simples o cadenas hasta documentos JSON complejos, en la base de datos mediante claves, como cadenas.
  3. Almacenes de columnas anchas (por ejemplo, Cassandra). Los datos se almacenan en columnas, en lugar de filas, como en un sistema SQL convencional. Se puede agrupar o agregar cualquier cantidad de columnas (y, por lo tanto, muchos tipos diferentes de datos) según sea necesario para consultas o vistas de datos.
  4. Bases de datos de gráficos (por ejemplo, Neo4j). Los datos se representan como una red o gráfico de entidades y sus relaciones, donde cada nodo del gráfico es un fragmento de datos de forma libre.

El almacenamiento de datos sin esquema es útil en los siguientes contextos:

  • Desea un acceso rápido a los datos y le preocupa más la velocidad y la simplicidad del acceso que las transacciones confiables o la consistencia.
  • Está almacenando un gran volumen de datos y no quiere encerrarse en un esquema, ya que cambiar el esquema más tarde podría ser lento y doloroso.
  • Está tomando datos no estructurados de una o más fuentes y desea mantener los datos en su forma original para obtener la máxima flexibilidad.
  • Quiere almacenar datos en una estructura jerárquica, pero quiere que esas jerarquías sean descritas por los datos mismos, no por un esquema externo. NoSQL permite que los datos sean casualmente autorreferenciales en formas que son más complejas de emular para las bases de datos SQL.

Consultar bases de datos NoSQL

El lenguaje de consulta estructurado que utilizan las bases de datos relacionales proporciona una forma uniforme de comunicarse con el servidor al almacenar y recuperar datos. La sintaxis de SQL está altamente estandarizada, por lo que, si bien las bases de datos individuales pueden manejar ciertas operaciones de manera diferente (por ejemplo, funciones de ventana), los conceptos básicos siguen siendo los mismos.

Por el contrario, cada base de datos NoSQL tiende a tener su propia sintaxis para consultar y administrar los datos. CouchDB, por ejemplo, utiliza solicitudes en forma de JSON, enviadas a través de HTTP, para crear o recuperar documentos de su base de datos. MongoDB envía objetos JSON a través de un protocolo binario, a través de una interfaz de línea de comandos o una biblioteca de idiomas.

Algunos productos NoSQL pueden usar una sintaxis similar a SQL para trabajar con datos, pero solo de forma limitada. Por ejemplo, Apache Cassandra, un almacén de columnas anchas, tiene su propio lenguaje similar a SQL, Cassandra Query Language o CQL. Parte de la sintaxis de CQL proviene directamente del manual de SQL, como las palabras clave SELECT o INSERT. Pero no existe una forma nativa de realizar un JOIN o una subconsulta en Cassandra y, por lo tanto, las palabras clave relacionadas no existen en CQL.

Arquitectura de nada compartido

Una opción de diseño común a los sistemas NoSQL es una arquitectura de "nada compartido. En un diseño de nada compartido, cada nodo de servidor en el clúster funciona independientemente de los demás nodos. El sistema no tiene que obtener el consenso de otros nodos para devolverle datos a un cliente. Las consultas son rápidas porque se pueden devolver desde el nodo más cercano o conveniente.

Otra ventaja de un sistema de nada compartido es la resistencia y la expansión de escala. Adaptar horizontalmente la escala del clústeres tan fácil como activar nuevos nodos en el clúster y esperar a que se sincronicen con los demás. Si un nodo NoSQL deja de funcionar, los otros servidores del clúster seguirán funcionando. Todos los datos permanecen disponibles, incluso si hay menos nodos disponibles para atender las solicitudes.

Tenga en cuenta que un diseño de nada compartido no es exclusivo de las bases de datos NoSQL. Muchos sistemas SQL convencionales se pueden configurar para no compartir nada, como MySQL, aunque eso generalmente implica sacrificar la coherencia, en todo el clúster, a favor del rendimiento.

Limitaciones de NoSQL

Si NoSQL proporciona tanta libertad y flexibilidad, ¿por qué no abandonar SQL por completo? La respuesta simple es que muchas aplicaciones aún requieren los tipos de restricciones, consistencia y protección que brindan las bases de datos SQL. En esos casos, algunas "ventajas de NoSQL pueden convertirse en desventajas. Otras limitaciones se derivan del hecho de que los sistemas NoSQL carecen de ciertas características que se dan por sentadas en el espacio SQL.

Sin esquema: incluso si está tomando datos de forma libre, casi siempre necesita imponer restricciones a los datos para que sean útiles. Con NoSQL, imponer restricciones implica trasladar la responsabilidad de la base de datos al desarrollador de la aplicación. Por ejemplo, el desarrollador podría imponer una estructura a través de un sistema de mapeo relacional de objetos u ORM (por sus siglas en inglés). Pero si desea que el esquema viva con los datos en sí, NoSQL normalmente no lo soporta.

Algunas soluciones NoSQL proporcionan tipificación de datos y mecanismos de validación opcionales para los datos. Apache Cassandra, por ejemplo, tiene una gran cantidad de tipos de datos nativos que recuerdan a los que se encuentran en SQL convencional.

Coherencia eventual: Los sistemas NoSQL ofrecen la opción de operar con consistencia fuerte o inmediata para una mejor disponibilidad y rendimiento. Las bases de datos convencionales aseguran que las operaciones sean atómicas (todas las partes de una transacción tienen éxito o ninguna), consistentes (todos los usuarios tienen la misma vista de los datos), aisladas (las transacciones no compiten) y duraderas (una vez completadas, sobrevivirán a una falla del servidor).

Estas cuatro propiedades, denominadas colectivamente ACID, se pueden manejar de manera diferente en los sistemas NoSQL. En lugar de exigir una gran coherencia en todo el clúster, lo que necesariamente retrasaría las respuestas a las solicitudes, puede optar por una coherencia eventual, que permite atender las solicitudes sin esperar a que se copien las últimas escrituras en otros nodos del clúster. Los datos insertados en el clúster finalmente estarán disponibles en todas partes, pero no se puede garantizar cuándo.

Para algunos sistemas NoSQL, usted puede elegir uno de varios compromisos entre consistencia y velocidad, aunque lo que está disponible variará dependiendo de los productos. Azure Cosmos DB de Microsoft, por ejemplo, le permite seleccionar un nivel de consistencia por solicitud, para que pueda elegir el comportamiento que se ajuste a las necesidades de su caso de uso. La semántica de transacciones, que en un sistema SQL garantiza que todos los pasos de una transacción (por ejemplo, ejecutar una venta y reducir el inventario) se completen o retrocedan, está disponible en algunos sistemas NoSQL, como MongoDB.

Quedar atado en NoSQL: La mayoría de los sistemas NoSQL son conceptualmente similares, pero se implementan de manera diferente. Cada uno tiende a tener sus propias metáforas y mecanismos sobre cómo se consultan y administran los datos.

Un efecto secundario de esto es un grado potencialmente alto de acoplamiento entre la lógica de la aplicación y la base de datos. Este acoplamiento no es tan malo si elige un sistema NoSQL y lo mantiene, pero puede convertirse en un obstáculo si cambia de sistema en el futuro.

Si migra, por ejemplo, de MongoDB a CouchDB (o viceversa), debe hacer más que solo migrar datos. También debe navegar por las diferencias en el acceso a datos y las metáforas programáticas. En otras palabras, debe reescribir las partes de su aplicación que acceden a la base de datos.

Habilidades NoSQL: Otra desventaja de NoSQL es la relativa falta de experiencia. Donde el mercado para el talento de SQL convencional es bastante grande, el mercado para las habilidades de NoSQL es incipiente.

Como referencia, Indeed.com informa que, a partir del 2022, el volumen de ofertas de trabajo para bases de datos SQL convencionales (MySQL, Microsoft SQL Server, Oracle Database, etc.) sigue siendo más alto que el volumen de trabajos para MongoDB, Couchbase y Cassandra. La demanda de experiencia en NoSQL sigue siendo una parte del mercado de habilidades en SQL.

Fusionar SQL y NoSQL

Podemos esperar que algunas de las diferencias entre los sistemas SQL y NoSQL desaparezcan con el tiempo. Muchas bases de datos SQL ya aceptan documentos JSON como un tipo de datos nativo y pueden realizar consultas contra esos datos. Algunos incluso tienen formas nativas de imponer restricciones a los datos JSON, de modo que se manejen con el mismo rigor que los datos convencionales de filas y columnas.

Por otro lado, las bases de datos NoSQL están agregando no solo lenguajes de consulta similares a SQL, sino también otras características de las bases de datos SQL tradicionales, como las propiedades ACID de MongoDB.

Un camino probable es que las futuras generaciones de bases de datos, así como las futuras versiones de los sistemas de bases de datos actuales, abarquen los paradigmas y ofrezcan funcionalidad SQL y NoSQL, lo que ayudará a que el mundo de las bases de datos esté menos fragmentado. Por ejemplo, Azure Cosmos DB de Microsoft utiliza un conjunto de primitivas para reproducir de forma intercambiable los comportamientos de ambos tipos de sistemas. Google Cloud Spanner combina SQL y una sólida consistencia con la adaptabilidad de escala horizontal de los sistemas NoSQL.

Aun así, los sistemas SQL puro y NoSQL puro tendrán su lugar durante muchos años. Mire a NoSQL en escenarios donde la flexibilidad de diseño, la adaptabilidad de escala horizontal y la alta disponibilidad son consideraciones más importantes que una sólida consistencia de lectura y otras medidas de seguridad comunes a las bases de datos SQL. Para muchas aplicaciones, podría valer la pena cambiar esas medidas de seguridad por lo que ofrece NoSQL.

Puede ver también:

Primer Contacto

Más »

Casos de éxito

Más »