hosting

July 15, 2019
61764

SQL vs NoSQL: diferencias, ventajas y mitos

Durante más de cuatro décadas, las bases de datos SQL o relacionales han sido un mecanismo primario de almacenamiento de datos, pero no fue hasta finales de los años 90, con el auge de las aplicaciones web y las opciones de código abierto como MySQL, PostgreSQL y SQLite cuando comenzó a utilizarse de forma mucho más asidua. 

A estas bases de datos tradicionales les salió un nuevo competidor, las bases de datos NoSQL o no relacionales, ya que,  gracias a opciones populares como MongoDB, CouchDB, Redis y Apache Cassandra, éstas bases de datos han ido ganando terreno dentro del sector IT. 

Seguramente te habrás dado cuenta de que cuando comienzas un proyecto que requiere el uso de BBDD podemos optar por SQL, por NoSQL o por una mezcla de las dos (o más). Y seguro, te preguntarás ¿cuál es mejor? Ni una ni otra es mejor sino que poseen una evolución diferente, todo dependerá del proyecto. Por lo que cada desarrollador deberá conocer qué casos son los más recomendables para optar por una o por otra. 

Desde Ilimit, conocemos de primera mano las diferencias existentes y las ventajas que ofrece una base de datos relacional y una base de datos no relacional, por ello, queremos acercaros un poco más la necesidad de tomar la mejor decisión en base al análisis de sus diferencias. Pero,  primero de todo destaparemos algunos de los mitos que encontramos alrededor de estas dos bases de datos. 

Mitos SQL y NoSQL

¿Sabías que alrededor de ambas circulan una serie de mitos que pueden llevar a generar una guerra entre algunos especialistas? Queremos dar a conocer los mitos más comunes para que tu empresa o tu departamento IT no caiga en la trampa de las leyendas que circulan por Internet. 

NoSQL sustituye a SQL

Esto sería como decir que los ordenadores sustituyeron a los televisores porque son tecnologías más modernas. SQL y NoSQL realizan la misma función: almacenar datos, pero cada uno lo hace con diferentes enfoques, que pueden ayudar u obstaculizar el proyecto. Por tanto, a pesar de que NoSQL es menos longevo y muchos desarrolladores han optado por migrar sus proyectos a dicho modelo por ser la ‘novedad’, no sustituye de ninguna manera a SQL, es decir, es una alternativa más. 

NoSQL es mejor/peor que SQL

Cabe la posibilidad de que algunos de los proyectos seguramente se adapten mejor al uso de una base de datos SQL y otros a una base de datos NoSQL e, incluso, existen proyectos que podrían optar por ambas bases de datos. Por lo que, no podemos englobar uno u otro en el sentido de mejor o peor, ya que, dependerá de las necesidades de cada proyecto en cuestión. 

SQL vs NoSQL es una distinción clara

Esto no es del todo cierto, ya que, algunas bases de datos SQL han comenzado a adoptar características de NoSQL y viceversa. Al final la tecnología se acaba adaptando a las necesidades de los usuarios.                                                                          

El lenguaje/framework determina la base de datos

Podemos utilizar una base de datos MongoDB NoSQL en un proyecto PHP o.NET o conectar a MySQL o SQL Server en Node.js. Es decir, los requerimientos del producto acabarán marcando el tipo de base de datos que se adapta mejor y no el lenguaje como tal. 

Después de conocer los mitos más comunes veámos cuáles son las diferencias de cada una de las bases de datos para conocer qué es lo que más nos puede llegar a interesar. 

Diferencias entre SQL y NoSQL

Cuando hacemos referencia a SQL nos estamos refiriendo a Structured Query Language o lenguaje de consulta estructurado. A través de las bases de datos relacionales tenemos la oportunidad de consultar, modificar, añadir y borrar datos de bases de datos relacionales. Aquí podemos encontrarnos con dos características clave: 

  1. Los datos son almacenados siguiendo el esquema estrictamente fijado 
  2. Estos volúmenes de datos terminan almacenados en unas tablas que se conectan a través de la relaciones. De ahí, que sean conocidas como bases de datos relacionales. 
  3. Un ejemplo de consulta SQL sería:  Consultar el listado de marca-modelo de los vehículos de una cartera de clientes : “Clientes” (tabla1)  “tienen” (relación) “Coches” (tabla2)

Captura de pantalla 2019-07-15 a las 8.38.21

Podemos observar, como se relacionarían estas dos tablas:

En otro sentido, cuando hablamos de NoSQL nos referimos a bases de datos no relacionales, no hay esquemas fijados y no existen relaciones. ¿Qué ocurre entonces? Son bases de datos que no tienen una tabla fija y los datos se almacenan en documentos que en conjunto generan colecciones, como ocurre con MongoDB. 

Es una forma de almacenamiento no estructurado, por lo que, al no regirse por una tabla fija la escalabilidad aumenta considerablemente sus prestaciones respecto al paradigma relacional. Pese a esto, no debemos pasar por alto que los datos almacenados en una misma colección tengan relación entre sí y aporten información sobre un mismo objetivo. 

Captura de pantalla 2019-07-15 a las 8.38.33

Por ejemplo, en una misma colección de pólizas de seguros podríamos obtener datos referentes a distintas familias (o tablas) como los datos de la póliza, del cliente, económicos, fechas de vencimiento, franquicias, del vehículo etc. en un mismo documento. En cambio, volviendo a un modelo clásico – base de datos relacional - la información concreta de cada familia de datos la encontraríamos contenida en diferentes tablas (tabla de pólizas, tabla de clientes, tabla de coberturas etc) por lo que, sería necesario hacer uso de las entidades relacionales para poder acceder a la información. 

De esta manera para conocer los datos del cliente de una póliza concreta deberíamos acceder a la tabla de pólizas, obtener el número de cliente (variables que relaciona ambas tablas) para poder posteriormente obtener los datos del cliente. 

Mientras que, NoSQL opta por un esquema más dinámico para datos no estructurados, es decir, los datos puede orientarse a documentos, columnas, basados en gráficos y organizados como en un almacén. La flexibilidad que ofrece se debe a que no es necesaria una estructura definida previamente. 

Otra de sus diferencias la encontramos en la escalabilidad, donde las bases de datos relacionales son escalables verticalmente, esto significa que puede aumentar la carga en un único servidor, lo que supone, el incremento en RAM, CPU o espacio en disco. 

En cambio, las bases de datos no relacionales son horizontalmente escalables, por lo que, es posible agregar más servidores en los que la base de datos se tiene que distribuir. 

A pesar de ello, cabe señalar que no todo es blanco o negro, es decir, aunque normalmente referimos la escalabilidad vertical a las bases de datos SQL y la escalabilidad horizontal a las bases de datos NoSQL, es posible encontrar excepciones. Ya que, en ocasiones, las NoSQL no escalan siempre de forma horizontal y las SQL pueden escalar de forma horizontal hasta un cierto punto. 

Por otro lado, SQL sigue las propiedades de ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), mientras que, NoSQL sigue el teorema Brewers CAP (Consistencia, Disponibilidad y Tolerancia de Partición). 

Ya conocemos las diferencias, pero ¿cuál escojo? 

Como ya hemos avanzado siempre estará ligado dentro del proyecto en el que estemos inmersos. Y es que tanto las bases de datos relacionales como las no relacionales son aptas, es decir, no gana ni una ni otra, sino que poseen distintos enfoques según el problema que se necesite resolver. 

Seguramente, necesites conocer qué ventajas y desventajas pueden ofrecernos para tener una idea más clara por la que decantarse. Te dejamos las principales: 

Ventajas

  • SQL 
  • Dentro del diseño, se contempla la necesidad de la no duplicidad de datos debido al uso de relaciones entre las tablas
  • Facilita un esquema definido y la integridad de los datos                                     
  • NoSQL
  • Existe una mayor flexibilidad porque no se rige por un esquema estricto

Desventajas

  • SQL 
  • No posee tanta flexibilidad, ya que, es necesario planificar con tiempo de antelación el esquema y posteriormente esto hace más difícil su actualización. 
  • Utilizar relaciones puede dar consultas JOIN demasiado complejas
  • NoSQL
  • Se puede dar el caso de que se produzcan duplicidades de datos
  • La flexibilidad con la que cuenta puede llevar a posponer decisiones de estructura importantes

Casos reales con SQL y NoSQL

Cuando nos encontramos ante el dilema de las bases de datos, en muchas ocasiones, no sabemos qué tipo escoger o cuál sería la base de datos que necesitamos. En Ilimit conocemos y analizamos los casos de cada cliente y les ofrecemos las mejores soluciones como en los siguientes ejemplos: 

AVUXI

Startup que facilita de manera rápida y eficaz la localización de un buen lugar para comer, alojarse, comprar, pasear o visitar los entornos urbanos más famosos en cualquier destino de vacaciones de todo el mundo. 

Esta startup recopila información de varias fuentes y son almacenadas en un sistema SQL tradicional para su procesado y tratamiento. Una vez se han realizado estos pasos, para obtener un menor tiempo de respuesta y agilidad en las consultas, estos datos son reformateados y traspasados a una base de datos NoSQL. Además, los datos de usuario cómo preferencias son directamente almacenadas en otra base de datos no relacional                   

¿Por qué hemos optado por un modelo de combinación? Porque así obtenemos un mayor rendimiento y seguridad. 

SÓNAR

Festival de música de carácter internacional que se celebra en Barcelona y que combina lo lúdico con lo artístico y tecnológico a través de las nuevas corrientes musicales electrónicas. El festival cuenta con una BBDD relacional donde almacena toda la información de los festivales, artistas y eventos relacionados, donde los datos siempre se rigen por un patrón, por ejemplo, todos los eventos siempre tienen una fecha y ubicación, además cada uno de ellos puede contar con la actuación de uno o más artistas, y estos a la vez, pueden participar en más de un evento a lo largo del año.                                                                                

La clave está en adaptarse a las necesidades de los clientes y escoger lo que mejor les convenga según el proyecto. ¿Quieres saber más? ¿te has quedado con ganas de conocer los servicios que puede ofrecer las distintas bases de datos? En Ilimit estaremos encantados de ayudarte con cualquier duda y/o respuesta que necesites. 

CTA ebook cloud computing

Cloudflare, la protección e impulso que necesita tu negocio