Comprender las necesidades de las bases de datos NoSQL como MongoDB, DynamoDB y Cassandra.
Una revisión rápida sobre SQL básico
La base de datos SQL (lenguaje de consulta estructurado), también conocida como base de datos relacional, es un sistema de gestión de bases de datos (DBMS) basado en el modelo relacional. Organiza y almacena datos de forma estructurada, utilizando tablas con filas y columnas para representar entidades y sus relaciones.
Las bases de datos SQL utilizan un lenguaje de consulta estructurado llamado SQL para interactuar con la base de datos. SQL proporciona un conjunto de comandos y sintaxis para definir, manipular y recuperar datos en una base de datos. Con SQL, puede crear tablas, definir relaciones entre tablas utilizando claves primarias y externas, insertar y actualizar datos y consultar la base de datos para recuperar información específica.
Algunos sistemas de bases de datos SQL populares incluyen:
1. MySQL → Un sistema de gestión de bases de datos relacionales de código abierto ampliamente utilizado en aplicaciones web. 2. PostgreSQL → Una base de datos relacional orientada a objetos de código abierto conocida por su escalabilidad y funciones avanzadas. 3. Microsoft SQL Server → Un RDBMS comercial desarrollado por Microsoft y comúnmente utilizado en entornos basados en Windows.
Una revisión rápida sobre NoSQL básico
La base de datos NoSQL, también conocida como base de datos no relacional, es un tipo de sistema de gestión de bases de datos que es diferente de la base de datos SQL (lenguaje de consulta estructurado) tradicional.
Las bases de datos NoSQL populares incluyen:
1. MongoDB → Una base de datos NoSQL orientada a documentos que proporciona escalabilidad, flexibilidad y ricas capacidades de consulta. 2. Cassandra → Una base de datos NoSQL distribuida y altamente escalable diseñada para manejar grandes cantidades de datos en múltiples servidores de uso general. 3. Redis → Una base de datos NoSQL en memoria que admite el almacenamiento de datos de valores clave y proporciona acceso a datos de alta velocidad. 4. Amazon DynamoDB → Un servicio de base de datos NoSQL totalmente administrado proporcionado por Amazon Web Services (AWS) que proporciona escalabilidad, alta disponibilidad y rendimiento de baja latencia.
Las bases de datos NoSQL se utilizan normalmente en situaciones en las que es necesario procesar grandes cantidades de datos que cambian rápidamente, como plataformas de redes sociales, aplicaciones de IoT, etc.
A través de este artículo, entenderemos cómo las bases de datos escalan y no escalan. Veremos algunos de los problemas con las bases de datos SQL tradicionales y cómo los resuelve la introducción de las bases de datos NoSQL. Cubriremos situaciones que son adecuadas para ser resueltas por bases de datos SQL, así como situaciones que se adaptan mejor a bases de datos NoSQL.
Preguntas sobre bases de datos relacionales
Las bases de datos relacionales son adecuadas para una variedad de casos de uso y, a menudo, son la opción predeterminada para muchos desarrolladores cuando desarrollan aplicaciones. Además, las bases de datos relacionales cuentan con SQL , lo que permite manejar nuevos patrones de acceso así como patrones OLTP y OLAP en una sola base de datos.
OLTP → Significa procesamiento de transacciones en línea. Se refiere a una clase de sistemas y aplicaciones informáticas que admiten cargas de trabajo orientadas a transacciones en tiempo real. Los sistemas OLTP están diseñados para facilitar y gestionar las actividades operativas diarias de una organización mediante el procesamiento de grandes cantidades de transacciones de bases de datos breves y rápidas.
OLAP → Significa procesamiento analítico en línea. Se refiere a una clase de sistemas y aplicaciones informáticas que respaldan tareas complejas de análisis de datos, informes y toma de decisiones. Los sistemas OLAP están diseñados para procesar grandes cantidades de datos y proporcionar vistas multidimensionales para análisis interactivos y ad hoc.
OLTP vs OLAP [1] ← Este es un buen artículo que explica claramente el significado de OLAP y OLTP y sus diferencias y proporciona una comparación concisa entre los dos. Si quieres saber más, compruébalo.
Sin embargo, para proporcionar estas funciones, las bases de datos relacionales suelen encontrar los siguientes problemas:
1. Imprevisibilidad del rendimiento de las consultas 2. Problemas de conexión 3. Instancias de base de datos que son difíciles de escalar horizontalmente
Imprevisibilidad del rendimiento de las consultas.
Durante las pruebas y las primeras etapas de desarrollo y lanzamiento del ciclo de vida de la aplicación, su aplicación generalmente tiene respuestas rápidas a las consultas.
**Almacenamiento de datos RDBMS con 5 GB de datos
Expresión de almacenamiento**
Sin embargo, a medida que crece el tamaño de la tabla, estas operaciones se vuelven cada vez más lentas. El rendimiento también se ve afectado por otras consultas que se ejecutan simultáneamente. Al mismo tiempo, la situación se complica si los analistas de datos de la empresa realizan operaciones analíticas en las mismas tablas en producción.
Representación del almacén de datos RDBMS con 500 GB de datos
Esto lleva al segundo problema.
Problemas con todas las conexiones famosas.
Las uniones en SQL pueden afectar la velocidad por varias razones:
Conjunto de resultados grande → Al realizar una operación de unión, el conjunto de resultados puede crecer significativamente si hay muchas filas coincidentes entre las tablas unidas. Esto puede dar lugar a conjuntos de resultados intermedios más grandes que deben procesarse, transferirse y almacenarse, lo que genera un mayor consumo de memoria y tiempos de ejecución de consultas más prolongados.
Falta de uso de índices → Las operaciones de unión eficientes a menudo dependen del uso de índices apropiados en las columnas de unión. Si faltan los índices y claves externas necesarios o están mal definidos, es posible que la base de datos deba realizar un escaneo completo de la tabla u operaciones extensas de E/S del disco para localizar filas coincidentes, lo que resulta en un rendimiento más lento.
Planes de consultas complejos → El optimizador de la base de datos debe determinar la forma más eficiente de ejecutar consultas de combinación. En algunos casos, es posible que el optimizador de consultas deba considerar múltiples rutas de unión, métodos de acceso a tablas y algoritmos de unión posibles. Este proceso puede volverse complejo y llevar mucho tiempo, especialmente para consultas con múltiples conexiones, lo que podría generar planes de consulta subóptimos y una ejecución más lenta.
Selectividad insuficiente → Las condiciones de unión que incluyen predicados no selectivos (condiciones que coinciden con la mayoría de los datos) pueden obstaculizar el rendimiento. Las condiciones de unión no selectiva pueden generar conjuntos de resultados intermedios más grandes y una ejecución de consultas más lenta porque la base de datos necesita procesar grandes cantidades de datos para recuperar los resultados requeridos.
Para resolver estos problemas, es posible que desee ampliar la base de datos, lo que lleva al siguiente problema.
Problemas de expansión horizontal de instancias de base de datos.
Hay dos formas de ampliar la base de datos:
• Escalado vertical → aumentando la CPU o RAM de las máquinas de bases de datos existentes. • Escalado horizontal → agregando máquinas adicionales al clúster de la base de datos, cada máquina procesa un subconjunto de los datos totales.
Sin embargo, eventualmente se alcanzan los límites del escalamiento vertical. En este punto, es posible que desees considerar el escalado horizontal. Sin embargo, esto introduce su propio conjunto de desafíos.
• Distribución y fragmentación de datos → Al escalar horizontalmente, distribuir los datos en varios nodos es fundamental. En una base de datos SQL, los datos suelen estar estructurados en tablas con relaciones y dependencias. Dividir y distribuir dichos datos interconectados puede resultar complejo, ya que mantener la integridad referencial y garantizar datos coherentes entre los nodos se convierte en un desafío. La fragmentación se utiliza a menudo para dividir datos entre nodos, pero requiere una planificación cuidadosa y puede introducir una complejidad adicional. • Coordinación de consultas y uniones → La base de datos SQL admite operaciones JOIN complejas para recuperar datos de múltiples tablas. Cuando los datos se distribuyen entre nodos, realizar operaciones JOIN se vuelve más desafiante. Las conexiones pueden requerir coordinación entre nodos, transferencia de datos de red y mayor latencia de la red, lo que podría afectar el rendimiento y la escalabilidad. • Índices y optimización de consultas → Las bases de datos SQL dependen en gran medida de índices para una recuperación eficiente de datos. A medida que escala horizontalmente, los índices se vuelven más complejos porque deben distribuirse y mantenerse entre nodos. Las técnicas de optimización de consultas también se vuelven más desafiantes debido a la naturaleza distribuida de los datos, lo que potencialmente afecta el rendimiento de las consultas.
El escalado horizontal funciona mejor cuando puede particionarlo de tal manera que una sola solicitud pueda ser manejada por una sola máquina/nodo.
A través de soluciones de bases de datos NoSQL
Las bases de datos NoSQL intentan resolver estos principales problemas planteados por las bases de datos relacionales.
1. Problemas con todas las conexiones famosas 2. Imprevisibilidad del rendimiento de las consultas 3. Dificultades de escalamiento horizontal para instancias de base de datos
Resolver conexión
Entendamos rápidamente qué está tratando de resolver NoSQL aquí.
SQL se basa en la normalización para el modelado de datos.
La normalización es un proceso en el diseño de bases de datos mediante el cual los datos se organizan y estructuran para minimizar la redundancia y mejorar la integridad de los datos.
rendimiento y optimizar la eficiencia de la base de datos. Implica dividir los datos en entidades (tablas) más pequeñas y manejables y establecer relaciones entre ellas.
Está diseñado para eliminar la redundancia almacenando cada dato en un solo lugar. Esto nos beneficia de las siguientes maneras:
1. Consulta flexible → unirse le permite volver a ensamblar los datos requeridos de diferentes tablas en una sola operación. Con la flexibilidad de las uniones y otros azúcares sintácticos de SQL, no es necesario pensar en cómo acceder a los datos. Modela entidades de acuerdo con principios normalizados y luego escribe consultas para satisfacer sus necesidades. 2. Mejorar la integridad de los datos → La normalización ayuda a hacer cumplir las reglas de integridad de los datos al definir restricciones y relaciones entre tablas. Las claves primarias y externas se utilizan para establecer relaciones y hacer cumplir la integridad referencial, evitando inconsistencias de datos y garantizando la integridad de los datos. 3. Mejorar la eficiencia del almacenamiento → Datos redundantes, es decir, la misma información se almacena en varios lugares, lo que puede provocar inconsistencia y desperdicio de espacio de almacenamiento . Almacenar cada dato en un solo lugar reduce la posibilidad de que se produzcan inconsistencias en los datos y aumenta la precisión de los mismos.
Sin embargo, todo esto tiene un costo. Los costos de CPU y memoria suelen ser elevados.
NoSQL adopta un enfoque para resolver todos estos problemas.
1. **Abordar consultas flexibles** Las bases de datos NoSQL evitan la necesidad de flexibilidad en el acceso a los datos al exigirle que calcule todos los patrones principales de acceso a los datos por adelantado y diseñe la base de datos para manejarlos. En lugar de resumir los datos a medida que se leen, se almacena una versión preunida de los datos de manera que se presenta de la forma en que se leen. 2.**Abordar la integridad de los datos**Las bases de datos NoSQL trasladan la responsabilidad de la integridad de los datos a la aplicación. Debe desnormalizar y copiar los datos en la base de datos. Cuando se producen cambios, es posible que sea necesario actualizar varios registros que contengan los mismos datos. 3. **Abordar la eficiencia del almacenamiento** La eficiencia del almacenamiento de las bases de datos NoSQL no es tan alta como la de sus contrapartes relacionadas. Sin embargo, al diseñar un RDBMS, el almacenamiento es muy costoso en relación con la computación. En comparación con la situación actual, los precios del almacenamiento han bajado significativamente y la informática se ha convertido en la primera opción. Por lo tanto, tiene mucho sentido modelar sus datos optimizando la computación en lugar del almacenamiento.
Ejemplo de almacenamiento de datos en una base de datos SQL.
Convierta este modelo de datos a una base de datos NoSQL como DynamoDB, luego se verá como se muestra a continuación.
Ejemplo de almacenamiento de datos correspondiente de una base de datos NoSQL (DynamoDB)
Resolver expansión horizontal
La razón principal por la que las bases de datos relacionales son difíciles de escalar horizontalmente es la flexibilidad de la sintaxis de consulta. Debido a la flexibilidad de los patrones de acceso a los datos, el sistema no sabe qué datos se recuperarán antes de que se ejecute realmente la consulta. Por lo tanto, para evitar llamadas de red entre máquinas al ejecutar consultas, todos los datos deben permanecer locales, es decir, en el mismo nodo.
Las bases de datos NoSQL emplean escalado horizontal al requerir que los datos se dividan en segmentos más pequeños y que todas las consultas se ejecuten en uno de estos segmentos.
Para entender esto mejor, tomemos user_id como clave de partición y rastreémoslo en el gráfico.
Durante las operaciones de lectura y escritura, todas las consultas deben incluir la clave de partición para acceder directamente al nodo relevante.
Resolver la imprevisibilidad en el rendimiento de las consultas
En las bases de datos SQL, las operaciones se vuelven cada vez más lentas a medida que crece el tamaño de la tabla. El rendimiento también se ve afectado por otras consultas que se ejecutan simultáneamente.
Para operaciones de lectura en bases de datos NoSQL, todas las consultas deben incluir la clave de partición. Cuando se realiza una operación de escritura, esta operación se puede enviar al nodo responsable del bloque de datos sin perturbar a otros nodos del clúster. A medida que aumenta la cantidad de datos, se pueden agregar nodos adicionales según sea necesario. Cada operación afecta solo a un nodo del clúster. Habrá poca diferencia en el rendimiento de las consultas en comparación con los entornos de prueba y producción en SQL Database, ya que cada operación solo afecta a un nodo.
Conclusión
Finalizando este artículo aquí. Espero sinceramente haber hecho que este artículo valga la pena y que hayas aprendido mucho de él.
Link de referencia
[1] OLTP frente a OLAP : https://aws.amazon.com/compare/the-difference-between-olap-and-oltp/