Este es un extracto del Capítulo 15 del libro. NoSQL para simples mortales por Dan Sullivan, consultor y autor independiente de bases de datos. En el capítulo, Sullivan analiza los cuatro tipos principales de bases de datos NoSQL (valor clave, documentos, familias de columnas y bases de datos de gráficos) y proporciona información sobre qué aplicaciones son las más adecuadas para cada una de ellas. También analiza las diferencias entre el diseño de bases de datos relacionales y NoSQL, y la necesidad de coexistencia entre tecnologías relacionales y NoSQL en muchas organizaciones.
En el diseño de bases de datos relacionales, la estructura y las relaciones de las entidades impulsan el diseño, no así en el diseño de bases de datos NoSQL. Por supuesto, modelará entidades y relaciones, pero el rendimiento es más importante que preservar el modelo relacional.
El modelo relacional surgió por razones pragmáticas, es decir, anomalías en los datos y dificultad para reutilizar las bases de datos existentes para nuevas aplicaciones. Las bases de datos NoSQL también surgieron por razones pragmáticas, específicamente, la incapacidad de escalar para satisfacer las crecientes demandas de grandes volúmenes de operaciones de lectura y escritura.
A cambio de un mejor rendimiento de lectura y escritura, puede perder otras características de las bases de datos relacionales, como la coherencia inmediata y las transacciones ACID (aunque no siempre es así).
A lo largo de este libro, las consultas han impulsado el diseño de modelos de datos. Este es el caso porque las consultas describen cómo se utilizarán los datos. Las consultas también son un buen punto de partida para comprender qué tan bien las distintas bases de datos NoSQL satisfarán sus necesidades. También deberá comprender otros factores, como:
- El volumen de lecturas y escrituras.
- Tolerancia a datos inconsistentes en réplicas
- La naturaleza de las relaciones entre entidades y cómo eso afecta a los patrones de consulta.
- Requisitos de disponibilidad y recuperación ante desastres
- La necesidad de flexibilidad en los modelos de datos
- Requisitos de latencia
Las siguientes secciones proporcionan algunos casos de uso de muestra y algunos criterios para hacer coincidir diferentes modelos de base de datos NoSQL con diferentes requisitos.
Criterios para seleccionar bases de datos de valores-clave
Las bases de datos de valores clave son adecuadas para aplicaciones que tienen lecturas y escrituras pequeñas frecuentes junto con modelos de datos simples. Los valores almacenados en las bases de datos de clave-valor pueden ser valores escalares simples, como enteros o booleanos, pero pueden ser tipos de datos estructurados, como listas y estructuras JSON.
Las bases de datos de clave-valor generalmente tienen facilidades de consulta simples que le permiten buscar un valor por su clave. Algunas bases de datos de valores clave admiten funciones de búsqueda que brindan algo más de flexibilidad. Los desarrolladores pueden usar trucos, como claves enumeradas, para implementar consultas de rango, pero estas bases de datos generalmente carecen de las capacidades de consulta de las bases de datos de documentos, familias de columnas y gráficos.
Las bases de datos de valores clave se utilizan en una amplia gama de aplicaciones, como las siguientes:
- Almacenamiento en caché de datos de bases de datos relacionales para mejorar el rendimiento
- Seguimiento de atributos transitorios en una aplicación web, como un carrito de compras
- Almacenamiento de información de datos de usuario y configuración para aplicaciones móviles
- Almacenamiento de objetos grandes, como imágenes y archivos de audio
Casos de uso y criterios para seleccionar bases de datos de documentos
Las bases de datos de documentos están diseñadas para ofrecer flexibilidad. Si una aplicación requiere la capacidad de almacenar diversos atributos junto con grandes cantidades de datos, las bases de datos de documentos son una buena opción. Por ejemplo, para representar productos en una base de datos relacional, un modelador puede usar una tabla para atributos comunes y tablas adicionales para cada subtipo de producto para almacenar atributos usados solo en el subtipo de producto. Las bases de datos de documentos pueden manejar esta situación fácilmente.
Las bases de datos de documentos proporcionan documentos incrustados, que son útiles para desnormalizar. En lugar de almacenar datos en diferentes tablas, los datos que se consultan juntos con frecuencia se almacenan juntos en el mismo documento.
Además, las bases de datos de documentos mejoran las capacidades de consulta de las bases de datos de valores clave con indexación y la capacidad de filtrar documentos según los atributos del documento.
Las bases de datos de documentos son probablemente las más populares de las bases de datos NoSQL debido a su flexibilidad, rendimiento y facilidad de uso.
Estas bases de datos se adaptan bien a una serie de casos de uso, que incluyen:
- Soporte de back-end para sitios web con grandes volúmenes de lecturas y escrituras
- Administrar tipos de datos con atributos variables, como productos
- Seguimiento de tipos de variables de metadatos
- Aplicaciones que utilizan estructuras de datos JSON
- Aplicaciones que se benefician de la desnormalización al incrustar estructuras dentro de estructuras
Las bases de datos de documentos también están disponibles en servicios en la nube como Microsoft Azure Document y la base de datos de Cloudant.
Casos de uso y criterios para seleccionar bases de datos de familias de columnas
Las bases de datos de la familia de columnas están diseñadas para grandes volúmenes de datos, rendimiento de lectura y escritura y alta disponibilidad. Google presentó Bigtable para abordar las necesidades de sus servicios. Facebook desarrolló Cassandra para respaldar su servicio de búsqueda en la bandeja de entrada.
Estos sistemas de administración de bases de datos se ejecutan en grupos de múltiples servidores. Si sus datos son lo suficientemente pequeños como para ejecutarse con un solo servidor, entonces una base de datos de familias de columnas probablemente sea más de lo que necesita; en su lugar, considere un documento o una base de datos de valores clave.
Las bases de datos de familias de columnas son adecuadas para su uso con:
- Aplicaciones que requieren la capacidad de escribir siempre en la base de datos
- Aplicaciones que están distribuidas geográficamente en varios centros de datos.
- Aplicaciones que pueden tolerar algunas inconsistencias a corto plazo en las réplicas
- Aplicaciones con campos dinámicos
- Aplicaciones con potencial para volúmenes de datos realmente grandes, como cientos de terabytes
Google demostró las capacidades de Cassandra ejecutando Google Compute Engine. Los ingenieros de Google implementaron:
- 330 máquinas virtuales de Google Compute Engine
- 300 volúmenes de disco persistente de 1 TB
- Debian Linux
- Datastax Cassandra 2.2
- Los datos se escribieron en dos nodos (confirmación de quórum de 2)
- 30 máquinas virtuales para generar 3 mil millones de registros de 170 bytes cada una
Con esta configuración, el clúster de Cassandra alcanzó 1 millón de escrituras por segundo, y el 95% se completó en menos de 23 milisegundos. Cuando se perdió un tercio de los nodos, se mantuvo el millón de escrituras, pero con mayor latencia.
Varias áreas pueden utilizar este tipo de capacidad de procesamiento de big data, como:
- Análisis de seguridad utilizando el tráfico de red y el modo de datos de registro
- Big Science, como la bioinformática utilizando datos genéticos y proteómicos
- Análisis del mercado de valores utilizando datos comerciales
- Aplicaciones a escala web como la búsqueda
- Servicios de redes sociales
Las bases de datos de familias de columnas, documentos y valores-clave son adecuadas para una amplia gama de aplicaciones. Las bases de datos de gráficos, sin embargo, se adaptan mejor a un tipo particular de problema.
Casos de uso y criterios para seleccionar bases de datos de gráficos
Los dominios de problemas que se prestan a representaciones como redes de entidades conectadas son adecuados para bases de datos de gráficos. Una forma de evaluar la utilidad de una base de datos de grafos es determinar si las instancias de entidades tienen relaciones con otras instancias de entidades.
Por ejemplo, dos pedidos en una aplicación de comercio electrónico probablemente no tengan conexión entre sí. Pueden ser pedidos por el mismo cliente, pero ese es un atributo compartido, no una conexión.
De manera similar, la configuración y el estado del juego de un jugador tienen poco que ver con las configuraciones de otros jugadores. Entidades como estas se modelan fácilmente con bases de datos de valores clave, documentos o relacionales.
Ahora, considere los ejemplos mencionados en la discusión de bases de datos de gráficos, como carreteras que conectan ciudades, proteínas que interactúan con otras proteínas y empleados que trabajan con otros empleados. En todos estos casos, existe algún tipo de conexión, vínculo o relación directa entre dos instancias de entidades.
Estos son los tipos de dominios de problemas que se adaptan bien a las bases de datos de gráficos. Otros ejemplos de estos tipos de dominios de problemas incluyen:
- Gestión de redes e infraestructura de TI
- Gestión de identidades y accesos
- Gestión de Procesos de Negocio
- Recomendar productos y servicios
- Redes sociales
A partir de estos ejemplos, queda claro que cuando existe la necesidad de modelar relaciones explícitas entre entidades y recorrer rápidamente rutas entre entidades, las bases de datos gráficas son una buena opción de base de datos.
El procesamiento de gráficos a gran escala, como ocurre con las grandes redes sociales, puede utilizar bases de datos de familias de columnas para el almacenamiento y la recuperación. Las operaciones gráficas se basan en el sistema de gestión de la base de datos. La plataforma de análisis y base de datos de grafos Titan adopta este enfoque.
Las bases de datos de valores-clave, documentos, familias de columnas y gráficos satisfacen diferentes tipos de necesidades. A diferencia de las bases de datos relacionales que esencialmente desplazaron a sus predecesoras, estas bases de datos NoSQL continuarán coexistiendo entre sí y con bases de datos relacionales porque existe una creciente necesidad de diferentes tipos de aplicaciones con requisitos variables y demandas competitivas.