Las bases de datos SQL tienen restricciones sobre los tipos de datos y la consistencia. NoSQL los elimina por el bien de la velocidad, la flexibilidad y la escala.
por Serdar Yegulalp
Una de las decisiones más fundamentales que se deben tomar al desarrollar una aplicación es si 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 del mundo real. Están diseñados para transacciones confiables y consultas ad hoc, los elementos básicos de las aplicaciones de línea de negocios. Pero también vienen cargados de restricciones, como esquemas rígidos, que los hacen menos adecuados para otro tipo de aplicaciones.
Las bases de datos NoSQL surgieron en respuesta a esas limitaciones. Los sistemas NoSQL almacenan y administran datos de manera que permiten una alta velocidad operativa y una gran flexibilidad por parte de los desarrolladores. Muchos fueron desarrollados por compañías como Google, Amazon, Yahoo y Facebook que buscaban mejores formas de almacenar contenido o procesar datos para sitios web masivos. A diferencia de las bases de datos SQL, muchas bases de datos NoSQL se pueden escalar horizontalmente en cientos o miles de servidores.
Sin embargo, las ventajas de NoSQL tienen un costo. Los sistemas NoSQL favorecen la velocidad y la escalabilidad sobre las propiedades ACID detrás de las transacciones confiables prometidas por las bases de datos SQL. Y las metáforas utilizadas para trabajar con datos en sistemas NoSQL también son relativamente nuevas, en comparación con las décadas de conocimiento institucional acumulado en torno a SQL.
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 como una cuestión de 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 JOIN comando SQL.
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, que conducen a cuatro tipos comunes de sistemas NoSQL:
- 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.
- 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.
- Tiendas de columna ancha (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.
- 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 escenarios:
- 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.
- Desea almacenar datos en una estructura jerárquica, pero desea que esas jerarquías sean descritas por los propios datos, 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 aunque 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, una tienda 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 SELECTo INSERT. Pero no existe una forma nativa de realizar una JOINsubconsulta o 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 devolver datos a un cliente. Las consultas son rápidas porque se pueden devolver desde el nodo más cercano o más conveniente.
Otra ventaja de un sistema de nada compartido es la resiliencia y la expansión escalable. Escalar horizontalmente el clúster es 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 de manera que no compartan nada, como MySQL, aunque eso generalmente implica sacrificar la coherencia en todo el clúster por el 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. Pero si desea que el esquema viva con los datos en sí , NoSQL normalmente no lo admite.
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.
Consistencia eventual
Los sistemas NoSQL ofrecen la opción de negociar una 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 ). 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, puede elegir uno de varios compromisos entre consistencia y velocidad, aunque lo que está disponible variará entre 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 su caso de uso. La semántica de transacciones, que en un sistema SQL garantiza que todos los pasos de una transacción (p. ej., ejecutar una venta y reducir el inventario) se completen o retrocedan, está disponible en algunos sistemas NoSQL, como MongoDB .
Bloqueo de 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 de 2022, el volumen de ofertas de trabajo para bases de datos SQL convencionales (MySQL, Microsoft SQL Server, Oracle Database, etc.) sigue siendo mayor que el volumen de trabajos para MongoDB, Couchbase y Cassandra. La demanda de experiencia en NoSQL sigue siendo una fracción del mercado de habilidades en SQL.
Fusión de 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 tanto SQL como 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 bajo el capó para reproducir de forma intercambiable los comportamientos de ambos tipos de sistemas. Google Cloud Spanner combina SQL y una sólida consistencia con la escalabilidad horizontal de los sistemas NoSQL.
Aún 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 escalabilidad 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, bien puede valer la pena cambiar esas medidas de seguridad por lo que ofrece NoSQL.
Fuente: https://www.infoworld.com/article/3240644/what-is-nosql-databases-for-a-cloud-scale-future.html
