Portada » Hoja de trucos para la selección de bases de datos: ¿SQL o NoSQL?

Hoja de trucos para la selección de bases de datos: ¿SQL o NoSQL?

by Donal Sandro Noblejas Huaman

Hola mi nombre es donal Sandro Noblejas Huamán de Lima Perú 🇵🇪 hoy vengo con otro artículo de  Bases de Datos y como siempre y en cada uno de ellos completamente solo y me agrada porque se aprende, y como siempre sin empresas, personas, familiares, ni el estado ni ningún tipo de ayuda cuidado con los estafadores solo en mis tiempos libres redactando jejeje, bueno ahí vamos.

No hablaré sobre los orígenes profundos de estas tecnologías, no analizaré cada detalle, sino que me centraré en cómo presentar correctamente estas tecnologías a una entrevista y elegir el camino correcto y más corto que convenza al entrevistado. que has tomado la mejor decisión en tus situaciones particulares.

Este tema me pareció relevante porque este tipo de tareas se pueden encontrar tanto en el trabajo como en una entrevista para el diseño del sistema y tendrás que elegir entre estos dos tipos de DBMS. Me sumergí en este tema y les diré qué y cómo. Qué es mejor en cada caso, cuáles son las ventajas y desventajas de estos sistemas y cuál elegir, te lo mostraré con varios ejemplos al final del artículo.

Para comprender el tema, es necesario profundizar un poco en la estructura de estas bases de datos.

Diferencias de alto nivel entre SQL y NoSQL

Almacenamiento:

SQL almacena datos en tablas donde cada fila representa una entidad y cada columna representa información sobre esa entidad.

 Las bases de datos SQL más populares son PostgreSQL (lo más probable es que la elijas en una entrevista en el 80% de los casos, porque es una de las más comunes y fáciles de aprender), Microsoft SQL, Oracle Database (ambas son ideales para sistemas de grandes empresas). , como los bancos) y MySQL.

NoSQL tiene diferentes modelos de almacenamiento de datos, como clave-valor, gráfico, documento, columnas, etc.

El NoSQL más popular por tipo de almacenamiento que probablemente elijas en una entrevista y sobre el que deberías leer al menos un par de artículos:

Valor-clave: Redis y Amazon DynamoDB.

Orientado a documentos: MongoDB.

Gráfico: Neo4j, GraphDB

En columnas: Apache HBase, Apache Cassandra

Lo más probable es que la entrevista tenga una tarea en la que tendrá que elegir los primeros 2 tipos (a menos, por supuesto, que la preferencia sea NoSQL), por lo que debería estudiarlos con más detalle y escribir algún pequeño proyecto utilizando, por ejemplo, Redis y MongoDB.

Diferentes métricas para diferentes bases de datos no relacionales

Esquema:

Un esquema en una base de datos SQL se refiere a la organización o estructura de los datos en la base de datos. Define las tablas, campos, relaciones y restricciones que componen la base de datos y sirve como modelo de cómo se deben organizar y almacenar los datos. Los esquemas se pueden utilizar para hacer cumplir la integridad y coherencia de los datos y también pueden ayudar a gestionar el acceso a los datos al definir qué usuarios o roles tienen permiso para realizar determinadas acciones.

En una base de datos NoSQL, el concepto de esquema suele ser menos rígido y estructurado en comparación con una base de datos SQL. Las bases de datos NoSQL pueden no tener esquemas, lo que significa que la estructura de los datos que se almacenan puede cambiar dinámicamente y no es necesario definirla por adelantado.

Sin embargo, algunas bases de datos NoSQL tienen forma de esquema, pero pueden ser más flexibles y dinámicos que las bases de datos SQL. Por ejemplo, en una base de datos NoSQL orientada a documentos como MongoDB, cada documento puede tener su propio conjunto único de campos y la estructura de datos puede cambiar de un documento a otro. En un almacén clave-valor como Redis, cada par clave-valor puede tener un tipo de datos diferente, por lo que la estructura de los datos es implícita y no es necesario definirla explícitamente.

El esquema específico de una base de datos NoSQL depende del tipo de base de datos y de las elecciones de diseño realizadas por el desarrollador o arquitecto.

Consultas:

Para consultas a bases de datos SQL, respectivamente, se usa el lenguaje SQL con varias modificaciones por parte de los desarrolladores de bases de datos, para una vinculación conveniente de los lenguajes de programación con bases de datos SQL, se usa ORM, en el caso de Java, esto es Hibernate, Spring Data

No existe un lenguaje específico para consultas en la base de datos NoSQL, todo depende del tipo de base de datos que se describió anteriormente, utilizando API especializadas, consultas estructuradas declarativas y consultas por ejemplo.

En esta consulta, buscamos contactos que tengan al menos un número de teléfono del trabajo o que hayan sido contratados después de una fecha determinada. Nuevamente vemos que el equivalente de MongoDB es bastante simple.

Tenga en cuenta el uso de signos de dólar en los nombres de los operadores (“$or”, “$gt”) como azúcar sintáctico. También tenga en cuenta que en ambos ejemplos es importante utilizar una fecha real en nuestra comparación, no una cadena.

Escalabilidad:

En la mayoría de los casos, las bases de datos SQL son verticales y esto puede resultar costoso para el presupuesto. Puede escalar dichas bases de datos horizontalmente, pero esto requiere cierta habilidad, conocimiento y detalles específicos de la base de datos con la que trabaja; de lo contrario, existe el riesgo de perder datos. En esta ocasión, puedes leer en detalle sobre fragmentación, particionamiento y replicación.

Pero con las bases de datos NoSQL el escalado horizontal funciona mejor. Las bases de datos NoSQL escalan horizontalmente, lo que significa que podemos agregar fácilmente servidores adicionales a nuestra infraestructura de base de datos NoSQL para manejar un gran tráfico.

Muchas tecnologías NoSQL también distribuyen datos automáticamente entre servidores. ¿Por qué NoSQL es más fácil de escalar? Porque no hay ninguna operación JOIN. Por lo tanto, las operaciones JOIN escalan mal, y este es el problema fundamental del enfoque relacional. Sin embargo, esto (en la mayoría de los casos) también carece de propiedades ACID, lo que puede provocar pérdida de datos, inconsistencias y otras desventajas de los sistemas que no son ACID.

Fiabilidad:

La mayoría de las bases de datos relacionales utilizan propiedades ACID. Esto significa que cuando se trata de integridad de datos y confiabilidad de transacciones, las bases de datos son la mejor opción.

Por otro lado, las bases de datos no relacionales sacrifican ACID en aras de un escalamiento rápido y un alto rendimiento, por lo que dichas bases de datos deben usarse en lugares donde la seguridad de los datos y la transaccionalidad no deben ser del 99,9%.

Resumamos qué y cuándo usar.

SQL si necesita:

– Datos estructurados con esquema estricto.

– Datos relacionales

– La necesidad de uniones complejas (uso de subconsultas, uniones)

– Transacciones

– Búsqueda por índice

NoSQL si necesita:

– Esquema dinámico o flexible

– Datos no relacionales

– No se necesitan conexiones de datos complejas

– Trabajo de alta intensidad con datos.

– Alto rendimiento para IOPS (IOPS estándar)

4 ejemplos de lo que es óptimo elegir en diferentes condiciones del problema

Ejemplo 1: sistema de gestión de biblioteca

Imagine que está creando un sistema de gestión de biblioteca en el que necesita realizar un seguimiento de los libros, los autores y los miembros de la biblioteca, así como de los retiros, las devoluciones y las multas. En este caso, sería más apropiado utilizar una base de datos SQL porque:

Estructura de datos:

  • Los datos se pueden estructurar fácilmente en tablas para libros, autores, miembros de la biblioteca, préstamos prestados, devoluciones y multas, con relaciones entre ellos.
  • Los libros, autores y miembros de la biblioteca se pueden representar en tablas con columnas para la información relevante. Por ejemplo, la tabla de libros podría tener columnas para el título del libro, ISBN, autor y fecha de publicación.
  • Las relaciones entre las tablas se pueden establecer mediante claves foráneas. Por ejemplo, la tabla de libros podría tener una clave externa para la tabla de autores, que vincularía cada libro con su autor.
  • Los pagos, devoluciones y multas también se pueden representar en tablas con columnas para la información relevante. Por ejemplo, la tabla de préstamo podría tener columnas para el miembro de la biblioteca, el libro y la fecha de préstamo.

Consistencia y precisión de los datos:

  • La coherencia y precisión de los datos son importantes, ya que la biblioteca necesita realizar un seguimiento de la información precisa sobre sus libros, autores y miembros, así como sobre los retiros, devoluciones y multas. Las bases de datos SQL proporcionan transacciones ACID para garantizar que todas las actualizaciones de la base de datos se completen correctamente o se reviertan.
  • Las transacciones ACID garantizan que todas las actualizaciones de la base de datos se completen exitosamente o se reviertan en caso de falla. Esto significa que el sistema de gestión de la biblioteca puede manejar múltiples solicitudes para sacar el mismo libro al mismo tiempo sin pérdida ni corrupción de datos.

Consultas complejas:

  • Las bases de datos SQL proporcionan un lenguaje de consulta rico, lo que permite al sistema de gestión de bibliotecas generar informes y analizar datos. Por ejemplo, el sistema de gestión de la biblioteca puede generar un informe de todos los préstamos de un autor en particular durante el año pasado mediante una consulta como:

SELECT books.title, checkouts.checkout_date

FROM books

JOIN checkouts

ON books.book_id = checkouts.book_id

WHERE books.author = “Maria Quispe”

AND checkouts.checkout_date >= DATE_SUB(NOW(), INTERVAL 1 YEAR)

Integridad de los datos:

  • La integridad de los datos es crucial y el sistema debe hacer cumplir reglas para garantizar que cada préstamo se registre en el libro correcto y que cada multa se registre en el miembro correcto de la biblioteca. Las bases de datos SQL tienen restricciones y desencadenantes que pueden hacer cumplir estas reglas.
  • Se pueden utilizar restricciones y activadores para hacer cumplir las reglas y garantizar que los datos se ingresen correctamente. Por ejemplo, se puede utilizar una restricción para garantizar que un miembro de la biblioteca no pueda sacar en préstamo más de 5 libros a la vez. Se puede utilizar un activador para actualizar automáticamente la tabla de multas cada vez que un pago se devuelve tarde.

Volumen moderado de escrituras y lecturas:

  • El sistema de gestión de bibliotecas debe manejar un volumen moderado de escrituras y lecturas, y las bases de datos SQL son adecuadas para manejar este tipo de carga de trabajo.
  • Las bases de datos SQL son adecuadas para manejar un volumen moderado de escrituras y lecturas. El sistema de gestión de la biblioteca puede manejar múltiples solicitudes para sacar y devolver libros, así como generar informes, sin ningún problema de rendimiento.

En conclusión, en este escenario, una base de datos SQL como MySQL o PostgreSQL proporcionaría una solución robusta, escalable y flexible para el sistema de gestión de bibliotecas.

Ejemplo 2: aplicación de redes sociales

Imagine que está creando una aplicación de redes sociales donde los usuarios pueden publicar actualizaciones, comentar publicaciones y dar me gusta a las publicaciones. En este caso sería más apropiado utilizar un NoSQL, ampliemos el ejemplo para ver cómo funcionaría una base de datos NoSQL:

Estructura de datos:

  • Los datos de cada usuario, publicación, comentario y me gusta se pueden almacenar como documentos separados. Por ejemplo, el documento de publicación podría contener el texto de la publicación, el usuario que la publicó y la fecha y hora en que se publicó. El documento de comentario podría contener el texto del comentario, el usuario que hizo el comentario y la fecha y hora en que se realizó. El documento Me gusta podría contener el usuario al que le gustó la publicación y la fecha y hora en que le gustó.
  • Las relaciones entre las publicaciones, comentarios y me gusta pueden almacenarse como referencias o incrustarse en los documentos. Por ejemplo, el documento de la publicación podría contener una serie de referencias a los comentarios y me gusta asociados con esa publicación.

Consistencia y precisión de los datos:

  • La base de datos NoSQL puede manejar una eventual coherencia, lo que significa que los datos pueden tardar algún tiempo en actualizarse en todos los nodos del clúster. Esto es aceptable en una aplicación de redes sociales, donde la coherencia de los datos en tiempo real no es crítica.

Consultas complejas:

  • Es posible que las bases de datos NoSQL no tengan un lenguaje de consulta tan rico como las bases de datos SQL, pero están diseñadas para una recuperación rápida de datos. Por ejemplo, la aplicación de redes sociales puede recuperar todas las publicaciones de un usuario en particular con una consulta como:

db.posts.find({user: “Maria Quispe”}) 

  • Las bases de datos NoSQL también pueden utilizar MapReduce para análisis y procesamiento de datos complejos.

Integridad de los datos:

  • Es posible que las bases de datos NoSQL no tengan el mismo nivel de cumplimiento de la integridad de los datos que las bases de datos SQL, pero aún así pueden imponer restricciones de datos a través del código y la lógica de la aplicación. Por ejemplo, la aplicación de redes sociales puede imponer una regla según la cual a un usuario no le puede gustar su propia publicación verificando la identificación del usuario en el documento similar antes de permitir que se guarde.

Alto volumen de escrituras y lecturas:

  • Las bases de datos NoSQL están optimizadas para manejar un gran volumen de escrituras y lecturas, lo que las convierte en una buena opción para aplicaciones de redes sociales. La aplicación de redes sociales puede manejar múltiples actualizaciones, comentarios y me gusta en tiempo real sin ningún problema de rendimiento.

Escalabilidad:

  • Las bases de datos NoSQL están diseñadas para escalamiento horizontal, lo que permite que la aplicación agregue más nodos según sea necesario para manejar la carga creciente. La aplicación de redes sociales puede manejar un número cada vez mayor de usuarios y publicaciones sin ninguna degradación del rendimiento.

En conclusión, en este escenario, una base de datos NoSQL como MongoDB, Cassandra, Redis o Aerospike proporcionaría una solución escalable, rápida y flexible para la aplicación de redes sociales.

Ejemplo 3: sistema de gestión de registros

Imagine que está creando un sistema de gestión de registros en el que necesita recopilar y procesar grandes volúmenes de datos de registros de diversas fuentes. En este caso, sería más apropiado utilizar una base de datos NoSQL porque:

  1. Los datos no están estructurados y pueden cambiar con frecuencia, a medida que se agregan nuevas fuentes de registro o cambian los formatos de datos de registro. Las bases de datos NoSQL tienen un esquema flexible que puede adaptarse fácilmente a estos cambios.
  2. El sistema necesita manejar un gran volumen de escrituras, ya que los datos de registro se generan continuamente. Las bases de datos NoSQL están diseñadas para manejar altas cargas de escritura.
  3. El sistema debe ser escalable para adaptarse a volúmenes crecientes de datos de registro, y las bases de datos NoSQL pueden escalarse horizontalmente fácilmente agregando más nodos al clúster.

Un sistema de gestión de registros podría utilizar una base de datos NoSQL como Apache Cassandra o Apache HBase, ambos diseñados para manejar cargas de escritura elevadas y tienen un esquema flexible para adaptarse a los formatos cambiantes de datos de registro.

Ejemplo 4: sistema bancario

Imagine que está creando un sistema bancario en el que necesita realizar un seguimiento de las cuentas, transacciones y préstamos de los clientes. En este caso, sería más apropiado utilizar una base de datos SQL porque:

  1. Los datos se estructuran fácilmente en tablas para clientes, cuentas, transacciones y préstamos, con relaciones entre ellos.
  2. La coherencia y precisión de los datos son importantes, ya que las transacciones financieras deben registrarse correctamente. Las bases de datos SQL proporcionan transacciones ACID para garantizar que todas las actualizaciones de la base de datos se completen correctamente o se reviertan.
  3. El sistema debe admitir consultas complejas para generar informes o analizar datos. Por ejemplo, es posible que desee generar un informe de todas las transacciones de un cliente en particular durante el año pasado.
  4. La integridad de los datos es crucial y el sistema debe hacer cumplir reglas para garantizar que cada transacción se registre en la cuenta correcta del cliente.

En este escenario, una base de datos SQL como Oracle o PostgreSQL sería una buena opción, ya que se utilizan ampliamente y están bien establecidas para gestionar datos estructurados con relaciones complejas.

Autor Donal Sandro Noblejas Huamán

Lima Perú 🇵🇪 

Whatsapp:51924118897 – 51939416004

Sitio web verlista.com/blog

verlista.com

https://pe.linkedin.com/in/donal-sandro-noblejas-huaman

You may also like

Leave a Comment

Are you sure want to unlock this post?
Unlock left : 0
Are you sure want to cancel subscription?
-
00:00
00:00
Update Required Flash plugin
-
00:00
00:00