RDBMS (SQL) vs NoSQL; principales diferencias y cuándo elegir una u otra

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 🙂

11 comentarios

  1. First of all I want to say awesome blog! I had a quick question that I’d
    like to ask if you don’t mind. I was interested to know how you center yourself and clear your head prior to
    writing. I’ve had a tough time clearing my thoughts in getting my ideas out.
    I truly do enjoy writing however it just seems like the
    first 10 to 15 minutes are generally wasted just trying to
    figure out how to begin. Any ideas or tips? Cheers!

  2. Hi there! I just wish to offer you a big thumbs up for your great info you have right here on this post. I will be coming back to your web site for more soon.

  3. I must thank you for the efforts you’ve put in penning this blog.
    I’m hoping to view the same high-grade blog posts from you
    in the future as well. In truth, your creative writing abilities has encouraged me to
    get my very own website now 😉

  4. Nice blog here! Also your site quite a bit up very fast! What host are you the use
    of? Can I get your affiliate hyperlink to your host?
    I wish my web site loaded up as fast as yours lol

  5. I’m impressed, I must say. Seldom do I come across a blog that’s
    both equally educative and entertaining, and let me tell you,
    you have hit the nail on the head. The problem is an issue that too few people are speaking intelligently
    about. I’m very happy that I came across this in my search for something relating to this.

  6. Hey there! I know this is kinda off topic but I was wondering if
    you knew where I could find a captcha plugin for my comment form?

    I’m using the same blog platform as yours and I’m having difficulty finding one?
    Thanks a lot!

  7. An impressive share! I’ve just forwarded this onto a co-worker who has been doing a little homework on this. And he in fact ordered me breakfast simply because I discovered it for him… lol. So allow me to reword this…. Thank YOU for the meal!! But yeah, thanks for spending time to talk about this issue here on your website.

  8. Howdy! I could have sworn I’ve visited this blog before but after browsing through a few of the
    articles I realized it’s new to me. Regardless,
    I’m certainly delighted I stumbled upon it and I’ll be bookmarking it and
    checking back frequently!

  9. I am curious to find out what blog system you happen to be utilizing?
    I’m experiencing some small security issues with my latest site and I’d like to find something more
    safe. Do you have any recommendations?

  10. 10mg prednisone daily: http://prednisone1st.store/# prednisone 50 mg prices

  11. Pretty! This was an extremely wonderful post.
    Thanks for providing this info.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

La Ley 34/2002 nos obliga a avisarte de que usamos cookies propias y de terceros con objetivos estadísticos y de sesión y para mostrarte la 'publi' que nos da de comer. Tranquilo, este mensaje solo sale una vez. Más información

Java desde 0 comunica a los usuarios, a través de este aviso, que puede utilizar cookies cuando el usuario navega por las diferentes pantallas y páginas del sitio. Durante el uso de nuestra página Web usted acepta y autoriza expresamente el uso de cookies, de acuerdo con nuestra Política de Privacidad. Este sitio web utiliza las siguientes cookies propias: - Cookies de sesión, para garantizar que los usuarios que escriban comentarios en el blog sean humanos y no aplicaciones automatizadas. De esta forma se combate el spam. Este sitio web utiliza las siguientes cookies de terceros: - Google AdManager y AdSense: Utiliza cookies para mejorar la publicidad. Entre otros fines, suelen utilizarse para segmentarla según el contenido que sea relevante para los usuarios o su ubicación, mejorar los informes de rendimiento de las campañas y evitar mostrar anuncios que los usuarios ya hayan visto. Las cookies no contienen información personal identificable. Consulta cómo utiliza Google la información de sitios web o aplicaciones. y cómo bloquear determinados anuncios. - Google Analytics: Almacena cookies para poder elaborar estadísticas sobre el tráfico y volumen de visitas de esta web. Al utilizar este sitio web está consintiendo el tratamiento de información acerca de usted por Google. Por tanto, el ejercicio de cualquier derecho en este sentido deberá hacerlo comunicando directamente con Google. - Redes sociales: Cada red social utiliza sus propias cookies para que usted pueda pinchar en botones del tipo Me gusta o Compartir.

Cerrar