Anteriormente tuvimos el gusto de analizar un versus de PostgreSQL vs SQL Server, y en esta ocasión veremos una comparativa entre dos motores de base de datos muy populares, uno Relacional y uno Documental. Hablamos de un versus entre PostgreSQL vs MongoDB.
Hoy analizaremos cuando te conviene utilizar SQL y cuando noSQL, cual es mas rápido para que tareas y sus principales diferencias. Y nos focalizaremos también en una comparativa entre PostgreSQL y MongoDB.
Contenido
¿Relacional o basada en Documentos?
Desde el surgimiento de las bases de datos no relacionales (Basada en Documentos) ha existido la duda de cuándo debemos utilizar una u otra. Incluso, hay quienes plantean migrar sus base de datos SQL a NoSQL.
Estos dos tipos son muy diferentes y elegir uno de ellos depende de varios factores de nuestro proyecto. No por ser una nueva tecnología es mejor, simplemente es diferente y funciona mejor en algunos casos.
SQL
SQL son las bases de datos relacionales, estas manejan una estructura de datos ordenada. En este caso todos los grupos de datos tienen que ser iguales. Por ejemplo, que todos los objetos de tipo usuario tenga un nombre, apellido, fecha de nacimiento y estén relacionados con 1 o mas intereses. Por supuesto podemos dejar campos vacios, aunque no es lo ideal.
Las Bases de Datos SQL tienen muchas ventajas, si bien son mas rigidas y no tan faciles de escalar. Estas son mas consistentes y robustas, su gran trayectoria nos da seguridad en la permanencia de los datos.
Gracias a su antigüedad también tenemos más herramientas para trabajar con este tipo de datos. Por consecuencia, mas información al respecto y mas personas especializadas en la materia.
Como una ventaja y a su vez desventaja tenemos la propiedad de la atomicidad, está lo que nos dice es que si la operación a la base de datos no se completa entonces se realiza un rollback. ¿Por qué es una desventaja? Porque lleva a que consuma mas recursos del servidor.
NoSQL
NoSQL (Not Only SQL) utiliza un modelo no relacional, donde los esquemas son flexibles. Esto hace que sean mas fáciles de diseñar, ya que no es necesario desarrollar un modelo con precisión como en el caso de las Bases de Datos relacionales.
Como ya sabemos los datos se almacenan en documentos con formato similar a Json. En los cuales no se tiene un identificador que relacione los datos, algo muy útil cuando no tenemos un esquema exacto.
Otra ventaja de este modelo de datos es que nos permite escalar horizontalmente, permitiendo almacenar la base de datos en un clúster. Incluso hay varios proveedores que ofrecen este servicio completamente administrado.
Con las Base de Datos NoSQL podemos obtener un alto rendimiento, especialmente para los modelos de datos para los cuales fueron diseñadas. Por supuesto esta diferencia se nota mas cuando trabajamos a gran escala, en proyectos pequeños no notaremos la diferencia de performance respecto a las BDs Relacionales.
¿Cuando es mejor utilizar una u otra?
| SQL | NoSQL | |
|---|---|---|
| Carga de trabajo | Son optimas para el procesamiento de transacciones online, cuando se necesita que las aplicaciones sean coherentes y transaccionales. Y para el procesamiento analítico online. | Permiten el uso de varios patrones de acceso a los datos, siendo ideales para aplicaciones de baja latencia. Están pensadas para el análisis sobre datos semi-estructurados. |
| Modelo de datos | Las bases de datos SQL normalizan los datos en tablas con filas y columnas, definiendo los indices y las relaciones entre tablas. Ideal para modelos rígidos. | Existen varios modelos de datos NoSQL, como Documentos, Clave-valor, Gráficos, etc. Los cuales están optimizados para ser escalables y ofrecer el mejor rendimiento. |
| Rendimiento | Para lograr un buen rendimiento es necesario optimizar consultas, estructura de tablas e indices. Es mas eficiente en la escritura. | Por lo general ofrecen un optimo rendimiento para la lectura de datos. No es tan eficiente en la escritura. |
| Escalado | Se escalan de forma vertical, aumentando el hardware en un servidor. También se pueden realizar replicas para la lectura de datos. | Los datos se pueden particionar y dividir geográficamente. De igual manera, el escalado horizontal es super sencillo de realizar. |
| API | La comunicación es mediante consultas en lenguaje SQL. Esté se encuentra estandarizado hace varios años y es el mismo lenguaje para todas las BDs Relacionales. | Existen APIs basadas en objetos para la interacción con la base de datos. Aun no existen estándares en este tipo de BDs. |
En resumen, a la hora de elegir el tipo de base de datos debemos tener en cuenta como va a ser nuestro esquema, que tipo de información vamos a almacenar. Hay que considerar también el crecimiento a futuro que va a tener nuestro proyecto, si preferimos la consistencia de los datos o una baja latencia.
Un ejemplo donde es mejor una baja latencia a la consistencia de los datos es una red social. En este caso nos interesa que la información se publique y muestre en distintos puntos de forma casi inmediata. Por tanto, no es ta importante la información almacenada.
PostgreSQL vs MongoDB
Cuando elegimos un motor de Base de Datos es importante tener en cuenta varios factores, como la performance y fiabilidad. Con PostgreSQL tenemos una base de datos relacional que nos garantiza la consistencia de los datos. Por otra parte, con MongoDB tenemos una base de datos no relacional con una menor latencia.
PostgreSQL
Como ya sabemos PostgreSQL es un motor de base de datos relacional, y por cierto uno de los mas populares. Este maneja sus consultas con el lenguaje SQL, aunque en realidad tienen su propia variante. Postgre utiliza PL/pgSQL (procedural language/postgreSQL), este permite realizar consultas mas complejas y las diferencias de sintaxis con SQL son mínimas.
También nos permite almacenar Json en nuestra base de datos, super util cuando no es posible normalizar algunos datos. Lo que permite obtener todos los beneficios de las base de datos relacionales, con un toque de flexibilidad.
Es multiplataforma, podemos utilizarlo tanto en Windows como GNU/Linux, MacOS, BSD y otras. Además es compatible con varios lenguajes de programación como c, c++, Java, Perl, PHP, Python, Ruby y más.
Otra de sus ventajas es que sigue los principios ACID de Atomicidad, Consistencia, Aislamiento (Isolation) y Durabilidad. Estos principios son fundamentales para la asegurar la fiabilidad de la información.
Cabe destacar que es Software libre, por lo que podemos utilizarlo sin ningún tipo de limitante. Esté no pertenece a una empresa como sí pasa con MySQL. Los encargados de actualizar y mantener Postgre son la comunidad PGDG (PostgreSQL Global Development Group).
MongoDB
MongoDB es la base de datos no-relacional mas utilizada. Está es de código abierto y se encuentra bajo la licencia GNU AGPL v3.0. Fue desarrollada por MongoDB Inc y sigue siendo mantenida por esta misma compañía.
Al igual que Postgre este es compatible con varios lenguajes como JavaScript, Python, Java, PHP, Go, C++, C, Ruby y Perl. Esta almacena la información en BSON un formato binario de Json. BSON no es una formato que se pueda leer como Json, sino que luego es traducido a Json para su lectura.
Gracias a que es basado en documentos podemos modificar la estructura de la base de datos sin problema. Cada documentos es una instancia diferente, por lo que se puede modificar su estructura, claves y demás. Esto es posible dado que las claves no están fuertemente relacionadas, sino que son una referencia.
Las bases de datos NoSQL no cumplen los principios ACID, ya que están mas centradas en la alta performance para grandes cantidades de datos. Utilizan lo que se llama Consistencia Eventual (Eventual Consistency). Este se basa en que la información no este disponible para todos al mismo tiempo, sino que lo estará de forma eventual, de ahí el nombre. Este periodo de propagación se utiliza para realiza la resolución de conflictos en caso de existir alguno.
La consistencia eventual ofrece baja latencia, alta disponibilidad, alta escalabilidad y alta tolerancia a fallos. Por lo que es ideal para las bases de datos NoSQL. Por el contrario, en el caso de MongoDB se inclina mas por los principios ACID, aunque no los sigue de una manera exacta ya que son demasiado rígidos para este tipo de bases de datos.
¿PostgreSQL o MongoDB? Conclusión
Como en todas las comparativas que hemos visto, el elegir una u otra siempre va a depender de nuestro proyecto. Es fundamental tener en cuenta las prioridades del mismo, el tipo de información que vamos a almacenar y si es mejor priorizar la lectura o la escritura.
No hay que dejarse llevar por las nuevas tecnologías o la idea de un esquema flexible solo por simplificarnos el trabajo. A lo que debemos darle mas importancia es si necesitamos fuertemente los principios ACID o si la Consistencia Eventual va mejor con nuestro proyecto.
Y tu ¿Ya has utilizado alguna de estas Bases de Datos?