En la actualidad y conforme va pasando el tiempo, cada vez aumenta más y más la necesidad de almacenar datos. Muestra de ello, es que desde la aparición de la unidad mínima de programación el byte, las unidades de medida de almacenamiento que usamos hasta en los entornos domésticos y profesionales van aumentando cada día más y más: KB, MB, GB, TB, PB…

Estas necesidades de almacenar tantos datos, también se traduce en un aumento de la demanda de peticiones de algunos de esos datos por partes de los usuarios/apis que interactúan con un software. Y tienen como consecuencia que: necesitamos mejores servidores, unidades de almacenamiento más grandes y más veloces, mejores velocidades de transferencias, etc.

En este artículo hablaremos sobre dos de los tipos de BBDD:

  • Las SGBDR (o Sistema de Gestión de Bases de Datos Relacionales) que también son conocidas bajo el termino en inglés RDBMS (Relational Database Management System). El lenguaje que usamos en las RDBMS es conocido bajo el nombre de «SQL».
    • Algunos ejemplos de SGBDR o RDBMS que usan SQL son: Oracle, Microsoft SQL Server, MySQL, MySQL Workbench, PostgreSQL, etc.

SQL = Structured Query Language

Un ejemplo de diagrama de este tipo de BBDD podría ser:

Y un ejemplo de una tabla de SQL, podría ser:

  • Las NoSQL, también conocidas como «No solo SQL» o incluso algunos afirman que no «NoREL NoSQL» sería un nombre que se adapta mejor a su uso.
    • Algunos ejemplos de NoSQL son: Cassandra, Redis, HBase, MongoDB, CouchDB, etc.

NoSQL = Not Only SQL

Un ejemplo de documento de una BBDD NoSQL, basándonos en la misma tabla anterior, podría ser:

Diferencias entre NoSQL vs SQL

Si nos fijamos, ambas maneras nos permitirán almacenar la misma información sobre una base de datos (BBDD). Pero, aunque existen multitud de diferencias entre ambas BBDD, si observamos las dos tablas:


Podremos observar que la principal diferencia entre ambas radica en cómo se estructuran/almacenan los datos.

Aunque con esta diferencia solamente acabamos de «abrir el melón» desvelando la principal entre ambas BBDD, existen muchas más sobre las que vamos a entrar en detalle sobre la gran mayoría de las diferencias que tienen las SGBDR/RDBMS vs NoSQL con el fin de poder escoger la mejor para cada uno de nuestros proyectos.

Escoger una tecnología u otra será determinante a la hora de poder escalar (escalar = capacidad de un sistema de crecer en magnitud) el rendimiento de nuestra BBDD. Y por ello, es necesario analizar al detalle las necesidades que creamos que tengamos actualmente y en el futuro para escoger un tipo de database u otra.

Hay que matizar que, si hacemos un proyecto personal a pequeña escala, no notaremos gran diferencia entre utilizar una u otra debido a que ante un proyecto a pequeña escala cualquiera de las dos BBDD será muy rápida debido a que sus bajas dimensiones y su bajo uso. En cambio, las diferencias entre dos sistemas de bases de datos se agravan cuando tenemos un proyecto medio o de grandes dimensiones debido a que la demanda de datos tanto de lectura y escritura como la complejidad de la BBDD suele ser mayor.

SQL vs NoSQL ¿Qué tipo de BBDD es mejor?

No existe un tipo de bases de datos que sea mejor o peor que otro, más bien, como ya hemos visto un poco más arriba ambas BBDD son diferentes pero en ambas hemos podido almacenar los mismos datos de formas diferentes. Las dos BBDD son alternativas totalmente rápidas que ofrecen rendimientos diferentes en función de los objetivos de nuestro proyecto. Ambas databases almacenan datos, en el ejemplo:

Seremos nosotros los encargados de buscar cual nos va mejor analizando al detalle las necesidades y los pros y los contras de ambos tipos de BBDD. Por ello, vamos a profundizar de una vez por todas en sus diferencias.

Diferencias entre SQL vs NoSQL:

  • La estructura/modelo (structure/model):
    • Las BBDD SQL son relacionales y tienen esquemas fijos, en cambio, las NoSQL no requieren un sistema de esquema fijo son más dinámicas. Por lo que las SQL, se pueden unir mediante a un JOIN, en cambio, las NoSQL «no permiten el uso de JOINs» o están muy limitados (de ahí su nombre lo que hemos hablando antes que algunos las llegan a llamar NoREL NoSQL de no relacionales).
    • Las BBDD SQL se estructuran en tablas, en cambio, las NoSQL, pueden ser basadas en: documentos, clave valor (key-value), gráficos (graph) o columnas anchas (también conocidos como almacenes de familias de columnas) procede del término del inglés wide-column stores.

  • Lenguaje (language):
    • Las BBDD SQL definen y utilizan un lenguaje de consulta estructurado (SQL) que es tremendamente poderoso. Convirtiéndolo en el candidato perfecto y una opción segura especialmente cuando las consultas son grandes y complejas. Aunque a su vez, este lenguaje por otra parte puede ser bastante restrictivo. Además, SQL requiere que usen esquemas predefinidos (definidos previamente) para determinar la estructura de sus datos antes de trabajar con ellos. Todos sus datos deben seguir la misma estructura. Esto como ya hemos hablado anteriormente en su estructura (esquma estático), puede requerir invertir mucho tiempo en su fase inicial en la preparación y análisis de los requisitos a la hora de realizar la BBDD, ya que un cambio en la estructura sería difícil y perjudicial para todo el sistema.
    • Una base de datos NoSQL tiene un esquema dinámico para datos no estructurados. Los datos se almacenan de muchas formas (orientados a documentos, a columnas, a gráficos u organizados como un almacén de KeyValue) esta flexibilidad significa que los documentos se pueden crear sin tener una estructura definida primero. Además, cada documento puede tener su propia estructura única. La sintaxis varía de una base de datos a otra, y puede agregar campos sobre la marcha. Es decir, que se pueden agregar/añadir campos nuevos a un documento ya definido sin problema alguno.
    • Las SQL son ideales para consultas complejas, en cambio, las NoSQL no son tan buenas para consultas complejas. Pero sí que son ideales para consultas sencillas.
    • Por tanto, las SQL tienen los estándares bien definidos, en cambio, las NoSQL no.

  • La escalabilidad (scalability): 
    • Las BBDD SQL ante un aumento de peticiones, se escalan verticalmente (mejorar la potencia de nuestro servidor para obtener mejores resultados) en cambio, las BBDD NoSQL se escalan horizontalmente (añadir/distribuir la BBDD en más servidores para obtener mejores resultados). Para entender mejor el concepto de escalabilidad vamos a ver la siguiente imagen:

    • Fragmentando más tráfico mediante a escalabilidad horizontal, podemos añadir de una forma más sencilla servidores que mejorando el servidor con hardware nuevo. Un ejemplo claro es, suponiendo que los servidores son edificios, si hablamos sobre una necesidad de más personas en dicho bloque será mucho más sencillo añadir pisos encima (escalabilidad horizontal) que crear un bloque de pisos más grande (escalabilidad vertical).  Este tema es bastante importante debido a que, si se incrementan las peticiones, la escalabilidad en una BBDD, se traduce en un coste económico y la escalabilidad horizontal siempre será más sencilla de hacer y más económica. Por tanto, el mantenimiento de los servidores es más barato en las NoSQL. Y siempre será mejor instalar nuevos nodos operativos (servidores) para que balanceen la carga de trabajo (crecimiento horizontal) que utilizar el vertical ya que será menos costoso de escalar.

  • Madurez y soporte:
    • Las BBDD SQL y herramientas de RDBMS son comparativamente más maduras que las NoSQL. Además, los proveedores de BBDD SQL suelen brindar un gran soporte. También hay que destacar que disponemos de gran cantidad de recursos para solventar nuestras dudas ya que muchos de esos problemas al ser unas BBDD que llevan más tiempo con nosotros, ya han sido resueltos por la comunidad.
    • En cambio, las BBDD NoSQL, al ser una BBDD menos maduras, no ofrecen tanta fiabilidad y por ello, aún no ofrecen suficientes garantías ni confianza para que la comunidad de desarrolladores confíe plenamente en ellas.  Además, al ser unas BBDD más recientes, existen menos expertos en este tipo de BBDD principalmente si se trata de implementar una BBDD NoSQL a gran escala.
    • Las NoSQL suelen ser OpenSource, en cambio, algunas SQL suelen ser medio open-source y otras incluso de código cerrado (un ejemplo de ello es Oracle).
    • Esta imagen que habla sobre el uso empresarial de las BBDD SQL vs las NoSQL y aunque no sé de qué año trata la imagen ni en sobre qué datos se basa. Narra a la perfección lo que acabamos de comentar de que madurez es confianza a nivel empresarial. Aunque grandes empresas como Google, Instagram, Facebook están cambiando esta tendencia.

  • Rendimiento (performace) y seguridad (security):
    • Como hemos visto en puntos anteriores, al evitar las uniones al máximo, las BBDD NoSQL, tienen menos relaciones, y no unas JOINs. En cambio, las SQL tienen que «coser» los datos de varias tablas al hacer consultas. Por lo que son más veloces, las NoSQL.
    • Otro concepto que afecta directamente al performace y sobre que el que es imprescindible detenerse para entender mejor la diferencia de rendimientos entre ambas BBDD es el concepto del Teorema de CAP.

Si nos fijamos en este teorema encontramos 3 círculos. Vamos a explicarlos:

      • Consistencia (consistency): significa que los clientes ven la misma versión de los datos.
      • Disponibilidad (Availibility): todos los clientes pueden acceder a alguna versión de los datos.
      • Tolerancia (Partition Tolerance): Los datos pueden estar particionados en varios servidores y si alguno cae sigue funcionando el sistema.

CAP = Consistency, Availibility and Partition Tolerance

En este teorema existe un concepto llamado «Pick two» que nos quiere decir que tendremos que escoger 2 de los 3 protagonistas lo que conlleva siempre renunciar a algo. Es decir, en el caso de las NoSQL escogen entre:

      • Tolerancia y Disponibilidad: Cassandra, CouchDB, Dynamo, Voldermort, etc
      • Tolerancia y Consistencia: MongoDB, Redis, Hbase, Big table, etc.

En el caso de las BBDD SQL escogen:

      • Consistencia y Disponibilidad: Oracle, MySQL, PostgreSQL, SQL Server, etc.

En esta imagen, podemos ver donde se sitúan de una forma más visual las RDBMS y las NoSQL:

Otro concepto sobre el que es imprescincible deternerse para entender mejor su performarce es el de ACID vs BASE vs CAP:

      • ACID: tiene como objetivo garantizar las transacciones, aunque esto suponga un menor rendimiento. Es el usando los las RDBMS (SQL).
    • ACID = Atomicity, Consistency, Isolation and Durability = Atomicidad, Consistencia, Aislamiento, Durabilidad

Un ejemplo de ACID podría ser una transferencia bancaría que requiere varias operaciones y que no puede fallar. En el caso de que falle, se tendrán que deshacer todas las operaciones realizadas desde su inicio.

 

Las NoSQL no son adecuadas para realizar transacciones complejas. Ya que no admiten transacciones ACID en varios documentos. Es decir, tienen una mayor tolerancia a los fallos que las SQL que por su parte son más seguras ya que sí que se centran/priorizan en que las transacciones sean  ACID.

      • BASE: las transacciones ACID garantizan la transacción, aunque esto tiene un precio que las BBDD NoSQL no están dispuestas a asumir. Es el coste que asumen a cambio de tener una mayor escalabilidad y una mayor velocidad. Por lo que son menos exigentes con estás garantias en las transacciones a cambio de ser más veloces, más resistentes y más fáciles de escalar.

BASE = Basically, Available, Soft State, Eventually Consistent

¿Qué tipo de base de datos utilizar? ¿SQL o NoSQL?

Bueno, ya hemos visto bastantes diferencias entre ambas bases de datos. Ahora vamos a ver una imagen que define para que es más optimo utilizar un tipo de database u otro.

  • Las NoSQL: son ideales para manejar grandes volumenes de datos que se generan rápidamente como pueden ser: juegos, Big data, redes sociales como instagram, Facebook, etc. Este tipo de empresas pueden asumir la perdida de datos a cambio de velocidad.
  • Las SQL: Son ideales para el entorno empresarial, que requiere grandes BBDD con tablas relacionadas entre si y con transacciones garantizadas, aunque esto suponga una pérdida de velocidad y una escalabilidad más costosa.

Para acabar un breve resumen

Vamos a ver una comparativa con los diferentes tipos de BBDD que nos podemos encontrar:

Las principales diferencias entre SQL y no SQL son:

SQL

NoSQL

Estándar en BBDD relacionales. Mayor capacidad de manejo de datos.
Lenguaje de alto nivel para datos estructurados. El mantenimiento de los servidores es más barato.
Soporta fácilmente consultas muy estructuradas. No hay esquema o modelo de datos fijos.
Garantía de seguridad y una mejor integridad. No hay esquema o modelo de datos fijos.

Además, os adjunto una gráfica comparativa entre ambas BBDD que me ha parecido bastante interesante:

Espero que os haya gustado el artículo, y espero que os haya familiarizado un poco con las diferencias entre ambas BBDD. Ahora os toca elegir a vosotros o bien sino deshojar la margarita como si de un me quiere o no me quiere se tratará y a ver que sale SQL o NoSQL. Un saludo 🙂