¿Qué es NoSQL? Bases de datos para un futuro a escala de la nube

Una de las elecciones más fundamentales que se deben tomar al desarrollar una aplicación es si utilizar una base de datos SQL o NoSQL para almacenar los datos. Las bases de datos SQL convencionales (es decir, relacionales) 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 otros tipos 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 empresas 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 no tienen un costo. Los sistemas NoSQL generalmente no brindan el mismo nivel de consistencia de datos que las bases de datos SQL. De hecho, mientras que las bases de datos SQL tradicionalmente han sacrificado el rendimiento y la escalabilidad por las propiedades ACID detrás de transacciones confiables, las bases de datos NoSQL han abandonado en gran medida esas garantías ACID en cuanto a velocidad y escalabilidad.

En resumen, las bases de datos SQL y NoSQL ofrecen diferentes compensaciones. Si bien pueden competir en el contexto de un proyecto específico, por ejemplo, cuál elegir para esta aplicación o esa aplicación, son complementarios en el panorama general. Cada uno se adapta a diferentes casos de uso. La decisión no es tanto un caso de una u otra 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 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 columna determinada de una tabla puede estar restringida a números enteros únicamente. 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, mediante JOIN.

Con NoSQL, los datos se pueden almacenar de forma libre o sin esquema. Cualquier dato se puede almacenar 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:

  1. Bases de datos de documentos (por ejemplo, CouchDB, MongoDB). Los datos insertados se almacenan en forma de estructuras JSON de formato libre 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.
  2. Almacenes de valores clave (por ejemplo, Redis, Riak). Se accede a los valores de forma libre, desde simples enteros o cadenas hasta documentos JSON complejos, en la base de datos mediante claves.
  3. Almacenes de columnas anchas (por ejemplo, HBase, 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, y 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:

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

Consultar bases de datos NoSQL

El lenguaje de consulta estructurado utilizado por las bases de datos tradicionales proporciona una forma uniforme de comunicarse con el servidor al almacenar y recuperar datos. La sintaxis 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, una base de datos de almacenamiento de columnas, tiene su propio lenguaje similar a SQL, Cassandra Query Language o CQL. Parte de la sintaxis de CQL proviene directamente del libro de jugadas de SQL, como las palabras clave SELECT o INSERT. Pero no hay forma 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 todos los demás nodos. El sistema no tiene que obtener el consenso de cada nodo para devolver un dato 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 no compartir nada es la resiliencia y la escalabilidad horizontal. 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 falla, los otros servidores del clúster continuarán funcionando. Todos los datos permanecen disponibles, incluso si hay menos nodos disponibles para atender 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 sin compartir nada, aunque eso normalmente implica sacrificar la coherencia en todo el clúster por el rendimiento.

Limitaciones de NoSQL

Si NoSQL ofrece tanta libertad y flexibilidad, ¿por qué no abandonar SQL por completo? La respuesta simple: muchas aplicaciones aún requieren los tipos de restricciones, consistencia y salvaguardas que brindan las bases de datos SQL. En esos casos, algunas "ventajas" de NoSQL pueden convertirse en desventajas. Otras limitaciones provienen del hecho de que los sistemas NoSQL son relativamente nuevos. 

Sin esquema

Incluso si está tomando datos de forma libre, casi siempre debe imponer restricciones para que sean útiles. Con NoSQL, imponer restricciones implica transferir 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 hace.

Algunas soluciones NoSQL proporcionan mecanismos opcionales de validación y mecanografía de 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 intercambian consistencia fuerte o inmediata para una mejor disponibilidad y rendimiento. Las bases de datos convencionales garantizan que las operaciones sean atómicas (todas las partes de una transacción se realizan correctamente o ninguna), coherentes (todos los usuarios tienen la misma visión 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 manejan de manera diferente en la mayoría de los sistemas NoSQL. En lugar de una coherencia inmediata en todo el clúster, tiene una coherencia eventual , debido al tiempo necesario para copiar las actualizaciones a otros nodos del clúster. Los datos insertados en el clúster eventualmente estarán disponibles en todas partes, pero no puede garantizar cuándo.

La semántica de transacción, 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 reviertan, no suelen estar disponibles en NoSQL. Para cualquier sistema en el que deba haber una “única fuente de la verdad”, como un banco, el enfoque NoSQL no funcionará bien. No desea que su saldo bancario sea diferente según el cajero automático al que vaya; desea que se informe como lo mismo en todas partes.

Algunas bases de datos NoSQL tienen mecanismos parciales para solucionar esto. Por ejemplo, MongoDB tiene garantías de coherencia para operaciones individuales, pero no para la base de datos en su conjunto. Microsoft Azure CosmosDB le permite seleccionar un nivel de coherencia por solicitud, para que pueda elegir el comportamiento que se adapte a su caso de uso. Pero con NoSQL, espere una consistencia eventual como comportamiento predeterminado.

Bloqueo NoSQL

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

Un efecto secundario de eso es un grado potencialmente alto de acoplamiento entre la lógica de la aplicación y la base de datos. Esto no es tan malo si elige un sistema NoSQL y se apega a él, pero puede convertirse en un obstáculo si cambia de sistema en el futuro.

Si migra de, digamos, MongoDB a CouchDB (o viceversa), debe hacer más que solo migrar datos. También debe navegar por las diferencias en el acceso a los 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

Otro inconveniente de NoSQL es la relativa falta de experiencia. Donde el mercado de talento SQL convencional todavía es bastante grande, el mercado de habilidades NoSQL es incipiente.

Como referencia, Indeed.com informa que, a fines de 2017, el volumen de ofertas de trabajo para bases de datos SQL convencionales (MySQL, Microsoft SQL Server, Oracle Database, etc.) sigue siendo mayor en los últimos tres años que el volumen de trabajos. para MongoDB, Couchbase y Cassandra. La demanda de experiencia en NoSQL está creciendo, pero todavía es una fracción del mercado de SQL convencional.

Fusionando 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 los mismos rigores que los datos convencionales de filas y columnas.

Por otro lado, las bases de datos NoSQL no solo están agregando lenguajes de consulta similares a SQL, sino también otras capacidades de las bases de datos SQL tradicionales. Por ejemplo, al menos dos bases de datos de documentos, MarkLogic y RavenDB, prometen cumplir con ACID.

Aquí y hay indicios de que las futuras generaciones de bases de datos estarán a caballo entre los paradigmas y ofrecerán funcionalidad NoSQL y SQL. Azure Cosmos DB de Microsoft, por ejemplo, usa un conjunto de primitivas bajo el capó para reproducir indistintamente los comportamientos de ambos tipos de sistemas. Google Cloud Spanner es una base de datos SQL que combina una gran coherencia 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. Utilice NoSQL para obtener un acceso rápido y altamente escalable a datos de formato libre. Esto conlleva algunos costos, como la coherencia de las lecturas y otras medidas de seguridad comunes a las bases de datos SQL. Pero para muchas aplicaciones, vale la pena intercambiar esas salvaguardas por lo que ofrece NoSQL.