Del SQL y NoSQL hasta las más modernas bases de datos NewSQL

Introducción

A lo largo de los últimos años estamos viendo cómo el mundo de las bases de datos y las tecnologías encargadas de su ingesta, almacenamiento, procesado, consulta y análisis avanzan a una velocidad de vértigo, todavía más acelerada por la aparición y uso extendido de las ventajas del cloud, en búsqueda de soluciones integrales capaces de combinar lo mejor de las tecnologías SQL, NoSQL y analytics.

El objetivo es crear sistemas capaces de hacer frente a interacciones masivas con datos heterogéneos procedentes de múltiples fuentes desde la fase inicial de recepción o ingesta a la fase final de consulta, presentación y análisis. Todo ello en tiempo real o con el menor desfase posible en escenarios de alta concurrencia, disponibilidad, escalabilidad, consistencia, múltiples geografías, etc.

Este artículo muestra un breve resumen, con perspectiva histórica, de esta auténtica jungla de tecnologías con foco en SQL, NoSQL y NewSQL, junto con el origen, ventajas, desventajas y escenarios en los que mejor encajan.

^{Bases de Datos SQL, Sistemas OLTP y OLAP}

Durante varias décadas la gran mayoría de sistemas de almacenamiento de datos eran de tipo relacional, usando SQL (Structured Query Language) como lenguaje principal. Todavía hoy SQL es un lenguaje altamente utilizado y potente tanto en ámbitos relacionales como de data scientist o data analytics. A veces es infravalorado o considerado como legacy por interpretaciones bastante sesgadas que no consideran todos los escenarios posibles donde aplicar sus ventajas. En la actualidad, como servidores de bases de datos SQL podemos nombrar Microsoft SQL Server, Oracle Database, IBM Db2, MySQL, PostgreSQL, etc.

De forma extendida y durante décadas, los sistemas de las compañías incluían bases de datos relacionales para soportar consultas y operativas transaccionales en el día a día con esquemas de almacenamiento estructurados y altamente tipados. Estos sistemas eran (o son) conocidos como OLTP (On Line Transactional Processing). La mayor ventaja de OLTP es que proporcionan transacciones tipo ACID (Atomicity, Consistency, Isolation, Durability). Explicado de forma simple significa que o se completan todas las operaciones o ninguna (commit/rollback), se asegura la consistencia final de datos en todas las entidades relacionadas (constraints, checks, foreign keys, etc.), unas transacciones no interfieren con otras en especial en operaciones concurrentes de escritura (isolation levels, locks) y los datos persisten en el sistema.

Los sistemas OLTP planteaban múltiples problemas cuando los requerimientos de entrada/salida exigían alto volumen, variedad y velocidad de interacción con datos (3 V del Big Data) junto con escenarios de alta concurrencia y disponibilidad. Esto era mayoritariamente debido al uso de la misma instancia de base de datos para gestionar transacciones y consultas. La mayor desventaja de los sistemas OLTP es la falta de escalabilidad horizontal o posibilidad de uso de múltiples instancias para particionar y replicar datos.

Para solventar los problemas generados de la ejecución de transacciones y consultas en la misma base de datos aparecen los sistemas OLAP (On Line Analytical Process). Así, las nuevas bases de datos OLAP serían las encargadas de almacenar datos ya procesados, calculados y consolidados a medida, a modo de datawarehouses o bases de datos multidimensionales integradas con herramientas de business intelligence o analytics, para independizar toda la parte de consultas complejas o analíticas de la operativa transaccional del día a día, la cual ya estaba cubierta por los sistemas OLTP. Las compañías que adoptaron este tipo de solución se vieron en la necesidad de crear sus sistemas ETL (Extraction, Transform and Load) para extraer, transformar y cargar los datos desde los sistemas OLTP corporativos a las bases de datos OLAP, todo ello intentando que dichas ejecuciones se produjeran con la máxima frecuencia y en el menor tiempo posible. A menudo estos procesos eran lanzados de noche para tenerlos disponibles al día siguiente.

La combinación de sistemas OLTP y OLAP dio origen a sistemas mucho más potentes, pero seguían planteando múltiples problemas en los escenarios con más demanda de necesidades:

• Falta de escalabilidad horizontal. Las bases de datos o no tenían posibilidad de este tipo de escalado o simplemente proporcionaban escalados para operaciones de lectura en instancias limitadas. Las escrituras se realizaban en una única instancia que replicaba estas actualizaciones en el resto de las instancias de lectura con el consiguiente problema en las ingestas masivas de datos.
• Costes asociados al escalado vertical. Sin escalado horizontal, no quedaba otra opción que usar el escalado vertical, esto es, hardware más potente, lo cual era exponencialmente costoso.
• Dificultad en almacenar y consumir datos cada vez más voluminosos y heterogéneos procedentes de múltiples fuentes.
• La ejecución de las ETL podía convertirse en un proceso muy costoso (horas o incluso días) con la dificultad de proporcionar analítica del dato en tiempo real. En los sistemas OLAP más complejos el volumen de datos podía llegar a cientos de terabytes o incluso petabytes debido a la exigencia de almacenar todo tipo de snapshots con datos desnormalizados y consolidados. Y unido con esto, más coste.

^NoSQL

Como se anticipó en el apartado anterior, nuevos sistemas con esquemas más flexibles de almacenamiento, más veloces en la ingesta de datos, más especializados o adaptados a escenarios particulares, con opciones de consulta o APIs más variadas y, sobre todo, con mayores prestaciones en la escalabilidad horizontal eran necesarios. La aparición del cloud como nuevo actor principal en el desarrollo de aplicaciones no ha hecho sino acelerar todo este tipo de escenarios. Aparecen de esta forma un conjunto de herramientas no relacionales, que son englobadas de forma común en el término NoSQL[MJA1]  (Not Only SQL). NoSQL se caracteriza por cubrir escenarios particulares de un modo muy eficiente respecto al uso de sistemas relacionales, con foco en la alta disponibilidad, la mejora del escalado horizontal y la flexibilidad en las estructuras internas de almacenamiento para soportar entornos masivos de datos tipo Big Data. En la actualidad bases de datos NoSQL muy conocidas son MongoDB, Apache Cassandra, CouchDB, Redis, Neo4j, etc.

Garantizar más disponibilidad y escalabilidad horizontal no sale gratis (CAP Theorem) ya que requiere relajar las exigencias de consistencia de datos entre instancias, principalmente adoptando una filosofía tipo Eventual Consistency: al final los datos serán consistentes, pero se asume como válido un intervalo de tiempo en el cual los datos no están completamente sincronizados. La principal desventaja de NoSQL es que no soporta transacciones tipo ACID y consultas complejas de tipo analítico pueden ser realmente ineficientes.

Existen varias categorías de bases de datos NoSQL como key-value, wide-column, documents o graphs. La elección de un tipo u otro según el escenario es clave. Cada tipo de base de datos NoSQL es diferente en términos de flexibilidad, eficiencia de ingesta y consultas, tipos de APIs, analítica de datos y escalabilidad. No es el objeto de este artículo entrar en el detalle de cada tipo de base de datos NoSQL.

NoSQL ha resuelto la problemática de muchos escenarios concretos aportando escalabilidad, disponibilidad, almacenamiento flexible, velocidad de ingesta de datos y soporte a entornos Big Data. No obstante, todavía tiene carencias, en particular en lo que a capacidades transaccionales ACID y consultas analíticas complejas se refiere. NoSQL no soluciona todos los escenarios como solución global y en ocasiones solo puede considerarse como un complemento a los sistemas OLTP y OLAP. En cualquier caso, estas carencias han empujado al mundo de las bases de datos a seguir evolucionando hacia herramientas capaces de combinar lo mejor de NoSQL con bases de datos relacionales más evolucionadas.

^{SQL vs NoSQL}

Llegados aquí, es de obligado cumplimiento plantear la siguiente pregunta: ¿Qué bases de datos son mejores, SQL o NoSQL? Pues de forma mayoritariamente aceptada, la respuesta es que depende del escenario.

• A favor de NoSQL: rápida ingesta (velocidad) de datos masivos (volumen) procedentes de múltiples fuentes (variedad), escalabilidad, esquemas flexibles (para ficheros, streaming, etc.), consultas por partición y claves muy rápidas y, costes inferiores respecto a mismos volúmenes de datos en entornos relacionales.
• En contra de NoSQL: no soporta transacciones tipo ACID, falta de consistencia temporal de datos, soporte integrado con funciones de fiabilidad e integridad inexistente o limitado, procesado ineficiente de consultas analíticas complejas que requieren relacionar datos de múltiples tablas, particiones o propiedades e imposibilidad de uso de SQL como lenguaje de consulta.
  

^{Buscando lo mejor de SQL y NoSQL: New SQL}

En los últimos años un nuevo tipo de tecnologías han surgido para proporcionar soluciones más integrales y eficientes en materia de bases de datos modernas: las tecnologías NewSQL.

NewSQL busca principalmente proporcionar herramientas con la escalabilidad y disponibilidad de NoSQL y, la fiabilidad, consistencia y usabilidad de SQL asegurando las propiedades ACID de los sistemas OLTP. Conseguir herramientas de este tipo no se antoja tarea fácil pues asegurar propiedades ACID en entornos con alta escalabilidad y disponibilidad sobre múltiples instancias con tolerancia a fallos transitorios es complejo (CAP Theorem). Pero no solamente esto. Resulta que también pretenden proporcionar capacidades OLAP a los sistemas OLTP para disponer de análisis en tiempo real sin necesidad de uso de ETLs (ver HTAP) con soporte a consultas potentes y sencillas.

La combinación de nuevas arquitecturas internas, nuevos motores SQL optimizados, técnicas de hibridación entre motores NoSQL, SQL o analytics y técnicas de replicación, particionado o sharding online son los elementos principales encargados de dar soporte a estas tecnologías. Entre este tipo de bases de datos tenemos Google Spanner, SingleStore, Apache Trafodion, Clustrix, CockroachDB, Couchbase o NuoDB.

¿Realmente son capaces de solventar todos estos desafíos? Más información sobre estas herramientas en posteriores artículos. Hasta entonces, espero que éste les haya sido de utilidad.

Autor del artículo:

José Antonio Muro

IT Solution Architect en Deloitte Consulting