Uno de los momentos más importantes en la mayoría de los proyectos a los que nos enfrentamos hoy en día es el de decidir dónde y cómo almacenar los datos. De esta elección, acertada o no, dependerá, en gran medida, el éxito de nuestro proyecto.
Actualmente nos encontramos con una gran variedad de Bases de Datos. Contamos con las tradicionales bases de datos SQL, las NoSQL, así como las más modernas, y menos conocidas newSQL, junto a ellas podemos encontrar también las orientadas a objetos, en memoria, híbridas, y un largo etcétera.
No existe una base de datos perfecta para todas las aplicaciones, así que debemos analizar cuál será la mejor para nuestra aplicación, elegir una u otra dependerá de las necesidades del servicio que se desea ofrecer.
En este post nos centraremos en la elección entre SQL o NoSLQ que, de alguna manera, es decidir entre bases de datos relacionales o no relacionales. El resto de las soluciones del mercado, o se basan en el modelo relacional, como las newSQL que tratan de mejorar el rendimiento de las SQL, o se basan en el modelo no relacional, como las orientadas a objetos.
Las siguientes preguntas nos pueden ayudar a enfocar la elección entre SQL o NoSQL: ¿Qué tamaño de datos necesitamos gestionar? ¿Cuál es la naturaleza de los datos? ¿Qué tiempo de respuesta necesitamos? ¿Qué tipos de consultas y servicios debe proveer? ¿Cómo vamos a escalar el aumento de datos y consultas? ¿Necesitamos alta disponibilidad, tolerancia a fallos, integridad de datos?
Veamos las características principales de cada una de ellas para conocer sus ventajas e inconvenientes y poder ir contestando así a las preguntas que nos planteamos.
Principales características de las bases de datos relacionales
- Se basan en modelo entidad-relación.
- Requieren de un esquema conocido y predefinido, lo que las hace ser muy poco flexibles a cambios.
- Usan el leguaje SQL y operaciones JOIN para la consulta de datos.
- Garantizan las propiedades ACID.
- Atomicity: La atomicidad implica que cada transacción sea “todo o nada”. Si alguna parte de la transacción falla, toda la operación falla y la base de datos no sufre cambios.
- Consistency: La consistencia es la propiedad encargada de garantizar la integridad de los datos. Toda inserción, modificación o borrado de datos cambiará la base de datos de un estado válido a otro estado válido. A partir de este nuevo estado todas las consultas nuevas mostrarán los nuevos cambios.
- Isolation: El aislamiento implica que cualquier transacción no pueda afectar a otras. Requiere que las operaciones concurrentes se ejecuten por separado. La mayoría de bases de datos ofrecen distintos niveles de aislamiento para reducir la carga por bloqueos.
- Durability: La durabilidad es la propiedad que garantiza la persistencia de los datos. Una vez confirmada una operación, los cambios aplicados son permanentes, incluso ante caídas de la base de datos.
- Escalabilidad vertical. Se suelen escalar mediante un hardware más potente, lo que puede implicar fuertes inversiones.
- Ante un número muy elevado de peticiones pueden generar cuellos de botella, debido a la consistencia y el aislamiento, ralentizando todo el sistema.
Principales características de las bases de datos no relacionales
- No requieren de un esquema predefinido. Al no estar atadas a un esquema ofrecen mucha flexibilidad.
- No suelen usar SQL como lenguaje para consultas de datos.
- Los datos suelen estar desnormalizados para evitar las operaciones JOIN, operaciones que no suelen ser permitidas.
- No garantizan el modelo ACID, sino que se ajustan más al modelo BASE.
- Basic Availability. El sistema sigue funcionando cuando alguna parte falla gracias a una estructura distribuida y replicación de la información.
- Soft State. No todas las partes tienen que devolver los mismos valores al mismo tiempo.
- Eventual Consistency. La consistencia se produce de forma eventual.
- Escalabilidad horizontal. Están diseñadas para ser escalables a través de múltiples servidores de coste reducido.
- Capaces de almacenar y manejar grandes volúmenes de datos con alto rendimiento y disponibilidad a costa de pérdida de consistencia y aislamiento.
Principales diferencias
La diferencia fundamental es que las bases de datos NoSQL no utilizan el modelo entidad-realción, mientras que las SQL se basan en él.
Las bases de datos relacionales son las más conocidas y usadas. Compuestas por tablas, definidas por campos estructurados y relaciones, son una solución robusta pero poco flexible. Todos sabemos la implicación que tiene cambiar el modelo relacional más las consecuentes modificaciones que habrá que realizar en las aplicaciones que se basan en su estructura conocida de datos.
Por el contrario, las bases de datos NoSQL son una solución más abierta y flexible a diferentes tipos de información, pero la integridad de los datos puede verse comprometida por el poco soporte transaccional, motivo por el que, en general, son menos robustas.
Teorema CAP
Según este teorema un sistema distribuido no puede garantizar de manera simultánea consistencia, disponibilidad y particionado de datos, sino que solamente podrá tener dos de las tres características al mismo tiempo.
- Consistency: La consistencia implica que todos los nodos vean la misma información a la vez.
- Availabilitty: La disponibilidad garantiza que toda petición, tanto de lectura como de escritura, siempre recibe una respuesta.
- Partition Tolerance: El particionado de datos permite que el sistema siga funcionando aunque fallen o se apaguen algunos nodos.
Llevando el teorema a nuestra elección de base de datos tendremos que optar por dos de las tres características que mejor se adapten a las necesidades de nuestro sistema, pudiendo obtener las siguientes combinaciones:
- CA: Consistencia y disponibilidad. El particionado no es un requisito indispensable.
- CP: Consistencia y particionado de datos a costa de disponibilidad.
- AP: Disponibilidad y particionado de datos. La consistencia no es importante.
Las bases de datos SQL son CA. La consistencia la aportan las propiedades ACID y la disponibilidad se puede conseguir mediante un cluster.
En el caso de NoSQL podemos encontrarnos las otras dos posibilidades dependiendo del tipo de base de datos. Los distintos tipos de NoSQL los comentaremos en un nuevo post próximamente.
Conclusiones
Si los datos son siempre estructurados e invariables, debemos asegurar las propiedades ACID, y/o si no requerimos de mucha escalabilidad, la mejor opción será SQL.
Por el contrario, cuando los datos no encajan en un modelo relacional, son muy variables con poca o ninguna estructura, el volumen de información crece muy rápidamente y/o la escalabilidad vertical no es viable en costes, deberíamos plantear una solución NoSQL.
Durante los últimos años, la guerra entre SQL y NoSQL ha estado abierta, aunque algunos consideraban que las NoSQL ganarían la batalla haciendo desaparecer a las SQL, lo cierto es que hoy en día siguen siendo necesarias ambas, cada una para solucionar problemas diferentes, cada una con sus pros y sus contras.
No es de extrañar que cada vez sea más común encontrarnos con aplicaciones donde conviven SQL y NoSQL para dar solución a nuestros proyectos. Es lo que se conoce como Persistencia Políglota, así que quizás llegó el momento de “fumar la pipa de la paz”.
