Una de las elecciones fundamentales al desarrollar una aplicación es saber si se debe usar una base de datos SQL o NoSQL para almacenarlos. Las SQL convencionales (es decir, relacionales) son el producto de décadas de evolución tecnológica, buenas prácticas y pruebas de estrés en el mundo real. Están diseñadas para transacciones confiables y consultas ad hoc, los elementos básicos de las aplicaciones de la línea de negocios. Pero también vienen cargadas de restricciones, como un esquema rígido, que las hacen menos adecuadas para otros tipos de aplicaciones.

Las bases de datos NoSQL surgieron en respuesta a esas limitaciones. Los sistemas NoSQL almacenan y gestionan datos de forma que permiten una gran velocidad de funcionamiento y una gran flexibilidad por parte de los desarrolladores. Muchas fueron desarrolladas 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.

Pero las ventajas de NoSQL no vienen sin un costo. En efecto, los sistemas NoSQL generalmente no proporcionan el mismo nivel de coherencia de datos que las bases de datos SQL. De hecho, aunque las SQL tradicionalmente han sacrificado el rendimiento y la escalabilidad de las propiedades ACID detrás de transacciones confiables, las bases de datos NoSQL han abandonado en gran medida esas garantías de ACID para 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 –como cuál elegir para esta aplicación o esa aplicación– son complementarias en el panorama general. Cada uno es adecuado para diferentes casos de uso. La decisión no es tanto un caso de cualquiera de las dos, sino que es una cuestión de qué herramienta es la adecuada para el trabajo.

NoSQL vs. SQL

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

Con las 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 compilarán los datos insertados en la base de datos. Por ejemplo, una columna dada en una tabla puede estar restringida sólo a 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, a través de JOIN.

Con NoSQL, los datos se pueden almacenar de forma libre o sin esquema. Cualquier información puede ser almacenada 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 (p. Ej., CouchDB, MongoDB). Los datos insertados se almacenan en forma de estructuras JSON de forma libre o “documentos”, donde los datos pueden ser cualquier cosa, desde enteros hasta cadenas y texto de forma libre. No existe una necesidad inherente de especificar qué campos, si corresponde, contendrá un documento.
• Tiendas de valores clave (por ejemplo, Redis, Riak). Los valores de forma libre, desde enteros simples o cadenas hasta documentos JSON complejos, se acceden en la base de datos por medio de claves.
• Tiendas de columna ancha (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, diferentes tipos de datos) según sea necesario para consultas o vistas de datos.
• Bases de datos Graph (por ejemplo, Neo4j). Los datos se representan como una red o gráfico de entidades y sus relaciones, con cada nodo en el gráfico como 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 de acceso que las transacciones confiables o la coherencia.
• Está almacenando un gran volumen de datos, y no desea encerrarse en un esquema, ya que cambiar el esquema más tarde podría ser lento y doloroso.
• Está asimilando datos no estructurados de una o más fuentes que los producen, y desea conservar los datos en su forma original para la máxima flexibilidad.
• Desea almacenar datos en una estructura jerárquica, pero desea que esas jerarquías sean descritas por los datos en sí, no en un esquema externo. NoSQL permite que los datos sean casualmente autoreferenciales en formas que son más complejas de emular para las bases de datos SQL.

Consultar bases de datos NoSQL

El lenguaje de consulta estructurada utilizado por las bases de datos tradicionales proporciona una forma uniforme de comunicarse con el servidor cuando almacena y recupera datos. La sintaxis SQL está altamente estandarizada, por lo que, aunque las bases de datos individuales pueden manejar ciertas operaciones de manera diferente (por ejemplo, las 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 gestionar los datos. CouchDB, por ejemplo, utiliza solicitudes en forma de JSON, enviadas a través de HTTP, para crear, o recuperar documentos desde su base de datos. MongoDB envía objetos JSON a través de un protocolo binario, mediante una interfaz de línea de comandos o una biblioteca de idiomas.

Algunos productos NoSQL pueden usar sintaxis similar a SQL para trabajar con datos, pero solo de forma limitada. Por ejemplo, Apache Cassandra, una base de datos de almacenes de columna, tiene su propio lenguaje similar a SQL, el Lenguaje de consulta de Cassandra o CQL. Parte de la sintaxis de CQL proviene directamente del libro de estrategias de SQL, como las palabras clave SELECT o INSERT. Pero no hay forma de realizar un JOIN o subconsulta en Cassandra, y por lo tanto las palabras clave relacionadas no existen en CQL.

Arquitectura de no compartir nada

Una opción de diseño común para los sistemas NoSQL es una arquitectura de “no compartir nada”. En un diseño de este tipo, cada nodo de servidor en el clúster opera independientemente de cada otro nodo. El sistema no tiene que obtener el consenso de cada nodo para devolver un dato a un cliente. Las consultas son rápidas porque pueden devolverse desde el nodo más cercano o más conveniente.

Otra ventaja de no compartir nada es la flexibilidad y la escalabilidad horizontal. Escalar el clúster es tan fácil como hacer girar nuevos nodos en el clúster y esperar que se sincronicen con los demás. Si un nodo NoSQL falla, los otros servidores del clúster seguirán avanzando. Todos los datos permanecen disponibles, incluso si hay menos nodos disponibles para atender las solicitudes.

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

Limitaciones de NoSQL

Si NoSQL ofrece tanta libertad y flexibilidad, ¿por qué no abandonar SQL por completo? La respuesta es simple: muchas aplicaciones aún exigen los tipos de restricciones, consistencia y salvaguardas que proporcionan 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 necesita imponer restricciones 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 no suele hacer eso.

Algunas soluciones NoSQL proporcionan mecanismos opcionales de tipificación y validación de datos. Apache Cassandra, por ejemplo, tiene una gran cantidad de tipos de datos nativos que son una reminiscencia de los que se encuentra en el SQL convencional.

Consistencia eventual: Los sistemas NoSQL intercambian coherencia 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 manejan de manera diferente en la mayoría de los sistemas NoSQL. En lugar de consistencia inmediata en todo el clúster, tiene consistencia eventual, debido al tiempo necesario para copiar las actualizaciones a otros nodos en el clúster. Los datos insertados en el clúster finalmente están disponibles en todas partes, pero no se puede garantizar cuándo.

La semántica de transacción, que en un sistema SQL garantiza que todos los pasos en una transacción (por ejemplo, la ejecución de una venta y la reducción del inventario) se completan o retrotraen, no suelen estar disponibles en NoSQL. Para cualquier sistema donde debe haber una “fuente única de verdad”, como un banco, el enfoque NoSQL no funcionará bien. No deseará que su saldo bancario sea diferente según el cajero automático al que vaya; querrá que ese informe sea el mismo en todas partes.

Algunas bases de datos NoSQL tienen mecanismos parciales para solucionar esto. Por ejemplo, MongoDB tiene garantías de consistencia para las operaciones individuales, pero no para la base de datos como un todo. Microsoft Azure CosmosDB le permite seleccionar un nivel de coherencia por solicitud, para que pueda elegir el comportamiento que se ajuste a su caso de uso. Pero con NoSQL, espere la consistencia eventual como el 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 lo sigue, pero puede convertirse en un obstáculo si cambia los sistemas más adelante.

Si migra desde, digamos, MongoDB a CouchDB (o viceversa), debe hacer más que simplemente 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 volver a escribir las partes de la 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 todavía es bastante grande, el mercado para las habilidades de NoSQL es incipiente.

A modo de referencia, Indeed.com informa que, a partir de finales del 2017, el volumen de listados de trabajo para las bases de datos SQL convencionales (MySQL, Microsoft SQL Server, Oracle Database, etc.) sigue siendo más elevado 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. Ya muchas bases de datos SQL ahora aceptan documentos JSON como un tipo de datos nativo, y pueden realizar consultas en contra de esos datos. Algunos incluso tienen formas nativas de imponer restricciones a los datos JSON, de modo que se maneje 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 otras capacidades de bases de datos SQL tradicionales. Por ejemplo, al menos dos bases de datos de documentos, MarkLogic y RavenDB, prometen ser compatibles con ACID.

Aquí y allá hay indicios de que las futuras generaciones de bases de datos abarcarán los paradigmas y ofrecerán funcionalidad NoSQL y SQL. Azure Cosmos DB de Microsoft, por ejemplo, usa un conjunto de recursos primitivos debajo del capó para reproducir de forma intercambiable los comportamientos de ambos sistemas. Google Cloud Spanner es una base de datos SQL que combina una gran coherencia con la escalabilidad horizontal de los sistemas NoSQL.

Aun así, los sistemas puros de SQL y NoSQL tendrán su lugar por muchos años más. Mire hacia NoSQL para obtener acceso rápido y altamente escalable a datos de forma libre. Esto tiene algunos costos, como la consistencia de las lecturas y otras garantías comunes a las bases de datos SQL. Pero para muchas aplicaciones, esas garantías bien valdrían la pena por lo que ofrece NoSQL.