Cómo elegir una base de datos en la nube

Las bases de datos transaccionales en la nube vienen en todas las formas y tamaños, desde simples almacenes de valores clave hasta bases de datos relacionales distribuidas a escala planetaria. A continuación, le mostramos cómo elegir la base de datos en la nube adecuada para su aplicación.

por Martin Heller

Las bases de datos han recorrido un largo camino desde principios de la década de 1980, cuando solo se ejecutaban en mainframes y su elección era entre bases de datos CODASYL y bases de datos relacionales. Las bases de datos CODASYL tendían a ser dos veces más rápidas que las bases de datos relacionales, pero eventualmente las mejoras en el hardware informático y la conveniencia de las consultas SQL (en comparación con la escritura de código de base de datos de navegación) llevaron a que las bases de datos relacionales dominaran el mercado.

Ahora hay bases de datos para ejecutar en cualquier lugar, desde su teléfono inteligente, a servidores en su centro de datos, a bases de datos en la nube distribuidas geográficamente. Además de las bases de datos tabulares relacionales, existen bases de datos para series de tiempo, gráficos, espaciales, de texto, procesamiento analítico en línea (OLAP), XML y datos JSON. Algunas bases de datos se especializan en un solo tipo de datos; algunos ofrecen una variedad de tipos de datos, pero solo uno a la vez; algunos permiten que varios tipos de datos coexistan en la misma instancia de base de datos. Algunas bases de datos se especializan en procesamiento de transacciones en línea (OLTP), algunas en análisis (OLAP) y algunas funcionan bien con cargas de trabajo de análisis y transacciones combinadas.

En este artículo, nos concentraremos en las cargas de trabajo transaccionales que se ejecutan en la nube y dejaremos los almacenes de datos en la nube para otro artículo. Algunas de las bases de datos que analizaremos también pueden ejecutarse localmente; algunos tienen soporte especializado en la nube pero son compatibles con bases de datos locales; y algunos son “nativos de la nube”, lo que significa que solo están disponibles a través de un proveedor de servicios en la nube.

Determinar los requisitos de la base de datos

Una base de datos casi nunca es una cosa en sí misma. En cambio, una base de datos es generalmente el back-end o la capa de almacenamiento de una aplicación.

---

El teorema de CAP en pocas palabras

El teorema de CAP (Brewer et al., 1998) establece que cualquier sistema de datos compartidos en red puede tener como máximo dos de tres propiedades deseables:

• Coherencia (C) equivalente a tener una única copia actualizada de los datos;
• Disponibilidad (A) de esos datos (para actualizaciones); y
• Tolerancia a las particiones de la red (P).

Las propiedades ideales de una base de datos están determinadas por las necesidades de la aplicación a la que sirve. Si la aplicación muestra un catálogo, entonces la velocidad de lectura y la latencia de la base de datos son importantes; una base de datos de documentos podría ser ideal, pero las bases de datos relacionales y de columnas anchas también funcionarían. Si la aplicación maneja transacciones financieras, entonces las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad) de la base de datos son importantes y una base de datos relacional podría ser ideal.

Como se explica en un documento de seguimiento de 2012, la formulación dos de tres resultó ser una simplificación excesiva. En las arquitecturas de bases de datos distribuidas modernas, los fallos de los nodos y las particiones de red se mitigan mediante grupos de consenso que utilizan algoritmos Paxos o Raft. Básicamente, cuando un nodo sale de un clúster, el clúster continúa funcionando mientras tenga quórum. Además, las particiones son raras dentro de las redes privadas, como las que se encuentran en los principales proveedores de nube, que utilizan fibras redundantes entre los centros de datos y no transmiten tráfico interno a través de la Internet pública.

Lo que esto significa es que, si bien ninguna base de datos puede eludir técnicamente el teorema CAP, en la práctica, las mejores bases de datos en la nube tienen una disponibilidad superior a cinco nueves (99,999%). De manera que , de manera efectiva , estas bases de datos pueden sortear el teorema de CAP y ser consistentes y disponibles.

---

Si la aplicación es un videojuego multijugador mundial, entonces la latencia de lectura y escritura son importantes y la base de datos probablemente deba distribuirse, aunque no necesariamente de forma relacional, y no necesariamente con una gran consistencia; una base de datos de valores-clave podría ser ideal. Si la aplicación registra y monitorea las salidas de los sensores de las válvulas, la base de datos debería poder escribir grandes cantidades de datos de series de tiempo rápidamente.

¿Cuántos datos generarás? ¿Y qué tan rápido?

Casi cualquier base de datos en la nube puede manejar pequeñas cantidades de datos, medidas en gigabytes o menos, y algunas pueden manejar estos datos en la memoria. Muchas bases de datos en la nube pueden manejar terabytes (miles de gigabytes); solo unos pocos pueden acomodar petabytes (millones de gigabytes). Tenga en cuenta que la mayoría de las bases de datos en la nube le cobran por el almacenamiento mensualmente y le cobran más por el almacenamiento SSD que por el almacenamiento en disco.

La velocidad a la que llegan los datos puede estresar otras métricas, como la velocidad de escritura de la base de datos y la capacidad de la red. Si llegan muchos datos en una ráfaga, es posible que la base de datos o un programa de interfaz de usuario deba almacenarlos en la memoria RAM mientras escribe en el almacenamiento permanente, para evitar la pérdida de datos. A menudo se menciona a Redis como capaz de almacenar en búfer grandes ráfagas de datos para otras bases de datos.

¿Conoce su esquema de antemano?

Si el esquema de su base de datos (la estructura de los datos) está predeterminado y es poco probable que cambie significativamente con el tiempo, y desea que la mayoría de los campos tengan tipos consistentes de un registro a otro, las bases de datos SQL serían una buena opción para usted. De lo contrario, las bases de datos NoSQL , algunas de las cuales ni siquiera admiten esquemas, podrían ser mejores para su aplicación.

Sin embargo, existen excepciones. Por ejemplo, Rockset , una base de datos operativa, permite consultas SQL sin imponer un esquema fijo o tipos consistentes en los datos que importa.

¿Qué tipo de forma se adapta naturalmente a sus datos?

Las bases de datos SQL relacionales, como Microsoft SQL Server , PostgreSQL y MySQL , almacenan datos fuertemente tipados en tablas rectangulares con filas y columnas. Se basan en relaciones definidas entre tablas, usan índices para acelerar las consultas seleccionadas y usan JOINS para consultar varias tablas a la vez. Muchas bases de datos relacionales modernas, incluida Oracle Database, también admiten otras formas.

Las bases de datos de documentos , como MongoDB y Couchbase , suelen almacenar JSON de tipo débil (texto o binario) que pueden incluir matrices y documentos anidados. Las bases de datos de gráficos almacenan vértices y bordes con propiedades, por ejemplo , Neo4j , o triples RDF, por ejemplo, AllegroGraph. Independientemente de la implementación, las bases de datos de gráficos enfatizan las conexiones entre entidades. Otras categorías de bases de datos NoSQL incluyen clave-valor, como RocksDB, y almacenes de columnas, como Cassandra.

A veces, los datos se capturan en una forma que también funcionará para el análisis; a veces no lo es, y será necesaria una transformación. A veces, un tipo de base de datos se construye sobre otro. Por ejemplo, los almacenes de clave-valor pueden ser la base de casi cualquier tipo de base de datos.

¿Cuáles son sus requisitos de latencia?

La latencia se refiere tanto al tiempo de respuesta de la base de datos como al tiempo de respuesta de un extremo a otro de la aplicación. Idealmente, cada acción del usuario tendrá un tiempo de respuesta inferior a un segundo; que a menudo se traduce en la necesidad de que la base de datos responda en menos de 100 milisegundos por cada transacción simple. Las consultas analíticas a menudo pueden tardar segundos o minutos. Las aplicaciones pueden preservar el tiempo de respuesta al ejecutar consultas complicadas en segundo plano.

La ejecución de la base de datos en la nube complica la medición de la latencia. Hay múltiples factores en juego aquí. La consideración más simple es que la latencia entre el cliente y la base de datos se suma a la latencia debido a la respuesta a la consulta de la base de datos. Una consideración más complicada es que la confirmación de transacciones en una base de datos distribuida puede implicar la espera de escrituras en regiones distribuidas geográficamente, especialmente si la base de datos mantiene una coherencia sólida.

¿Necesita una base de datos agrupada?

Las bases de datos agrupadas pueden ofrecer varias ventajas sobre las bases de datos de un solo nodo, a un costo y complejidad mayores. Entre otros beneficios, los clústeres pueden presentar mayor disponibilidad, mayor rendimiento y, en algunos casos, menor latencia.

Para el tipo de clúster en el que cada nodo tiene una copia de toda la base de datos, obtiene una redundancia significativa y una mayor disponibilidad. Dependiendo de la política, es posible que solo se necesite un nodo para una lectura o, de lo contrario, es posible que un quórum de los nodos del clúster tenga que acordar el valor que se devolverá.

El uso de un clúster con varios nodos hace que haya más CPU disponible para la base de datos, lo que aumenta la duración y puede aumentar la tasa de transacciones. Con una política de lectura que permite que el nodo más cercano devuelva un valor, la latencia de lectura suele disminuir. Por otro lado, una política de escritura o transacción que debe esperar a que todos los nodos se comprometan a veces puede aumentar la latencia de escritura.

El uso de grupos de consenso ayuda a reducir la latencia. Si tiene un clúster de tres nodos y un nodo está cargado, los otros dos nodos pueden aprobar una transacción de consenso y actualizar el tercer nodo cuando esté disponible.

La fragmentación es una forma de manejar más datos dividiendo la base de datos. Si bien la fragmentación manual puede ser un dolor de cabeza que consume mucho tiempo, muchas bases de datos son capaces de fragmentar automáticamente.

¿Necesita una base de datos distribuida?

La agrupación en clústeres no es la mejor forma de expandir una base de datos, pero es un primer paso. El siguiente paso es una base de datos distribuida, lo que generalmente significa que hay clústeres en múltiples regiones. Algunas bases de datos permiten réplicas de lectura distribuidas y una instancia o clúster maestro de lectura y escritura. Otras bases de datos permiten instancias o clústeres de lectura-escritura distribuidos y tienen mecanismos de sincronización.

Las bases de datos distribuidas a menudo pueden ofrecer una latencia más baja y un mayor rendimiento para los usuarios remotos. Los usuarios de Tokio pueden ver una latencia de 260 milisegundos en un servidor en Barcelona , pero si hubiera una copia de la base de datos en Japón, su latencia de lectura promedio podría ser de tan solo 10 milisegundos. Las implicaciones de esto para las escrituras y transacciones dependen de los requisitos de coherencia de la base de datos y de cómo se configuran los clústeres remotos.

Las primeras bases de datos distribuidas eran bases de datos NoSQL con consistencia eventual. La coherencia eventual significa que no se garantiza que las lecturas después de las escrituras en una ubicación remota devuelvan información actual, pero se actualizarán con el tiempo. La coherencia eventual relaja los requisitos para que se completen las escrituras y las transacciones, lo que da como resultado una latencia más baja.

Recientemente, algunas bases de datos distribuidas han implementado una fuerte coherencia con la ayuda de estructuras de datos, grupos de consenso y sincronización de tiempo. Ejemplos de esto incluyen Google Cloud Spanner y CockroachDB .

¿Cuál es su presupuesto de base de datos?

Si bien la mayoría de las bases de datos tienen una versión de “comunidad” o de “desarrollo / prueba” que es gratuita, es posible que carezcan de soporte aparte de los foros comunitarios en línea. Las versiones de código abierto y de comunidad también pueden carecer de algunas de las optimizaciones de rendimiento que se ofrecen en las compilaciones comerciales. Si su empresa va a depender de la base de datos, debe invertir en una licencia y soporte.

Si está ejecutando una base de datos en la nube, como mínimo deberá pagar por sus recursos en la nube. Para una base de datos comercial, también necesitará una licencia de base de datos, que puede ser una licencia a largo plazo del proveedor o una licencia de pago por uso comprada a través del proveedor de la nube.

Productos clave de bases de datos en la nube

Había 373 sistemas en la clasificación de DB-Engines la última vez que miré, aunque muchos de estos productos no son explícitamente bases de datos en la nube. Elegí 12 proveedores de servicios en la nube y bases de datos en la nube para esta lista como ejemplos, y los enumeré alfabéticamente. Tenga en cuenta que la inclusión en esta lista no es una recomendación y la exclusión no es una condena.

Servicios web de Amazon ofrece al menos 15 bases de datos en su nube, aunque varias de ellas son almacenes de datos y algunas otras han quedado obsoletas. Aurora es su servicio de base de datos relacional de alto rendimiento y alta disponibilidad, que admite tanto MySQL como PostgreSQL. RDS es su servicio de base de datos relacional de rendimiento estándar, que admite cinco motores: MariaDB, MySQL, Oracle Database, PostgreSQL y Microsoft SQL Server. DynamoDB es su servicio de base de datos de valor clave de alto tráfico. ElastiCache es su servicio en memoria, con compatibilidad Memcached y Redis. DocumentDB es un servicio de base de datos de documentos compatible con MongoDB. Keyspaces es un servicio de base de datos de columna ancha compatible con Cassandra. Neptune es un servicio de base de datos de gráficos que admite modelos de gráficos de propiedades y RDF. Timestream es un servicio de base de datos de series de tiempo. QLDB es un servicio de base de datos contable.

CockroachDB es una base de datos de múltiples modelos distribuida, horizontalmente escalable, dinámicamente fragmentada, relacional que implementa PostgreSQL en la parte superior de un almacén de valor clave; tiene una gran consistencia y una increíble capacidad de supervivencia. CockroachDB Core es gratuito y de código abierto; CockroachDB Enterprise es una versión comercial con características adicionales; CockroachCloud es una base de datos de múltiples nubes administrada por proveedores como un servicio basado en CockroachDB Enterprise y Kubernetes; CockroachCloud Free es una versión siempre gratuita de CockroachCloud con funcionalidad reducida y un límite de 1 vCPU y 5 GB de almacenamiento por clúster gratuito. CockroachDB agregó almacenamiento e indexación de datos espaciales a fines de 2020.

Couchbase Server es una base de datos de documentos JSON distribuida, flexible y con prioridad en la memoria que es muy coherente dentro de un clúster local. Couchbase Lite es una versión móvil que puede ejecutarse localmente y también puede sincronizarse con el servidor cuando está conectado. Couchbase Cloud es una base de datos NoSQL totalmente administrada como servicio para aplicaciones de misión crítica que automatiza la implementación y administración de Couchbase Server en su entorno de nube en AWS o Microsoft Azure.

DataStax Enterprise es una versión mejorada nativa de la nube de la base de datos de código abierto y columna ancha Apache Cassandra. DataStax Astra es un DBaaS multinube, sin servidor, escalable y multirregión nativo de la nube construido sobre Apache Cassandra / DataStax Enterprise. La indexación adjunta al almacenamiento brinda capacidades de consulta de Astra en claves no primarias, que aún no está disponible en ninguna otra versión de Cassandra.

Google Cloud aloja más de una docena de tipos de bases de datos. Las bases de datos relacionales incluyen Bare Metal Solution para Oracle Database; Cloud SQL para MySQL, PostgreSQL y Microsoft SQL Server; y Google Cloud Spanner, que es nativo de la nube con escalabilidad ilimitada, consistencia y disponibilidad del 99,999%. Google Cloud Bigtable es una tienda de columnas anchas similar a Cassandra o HBase. Firestore y Firebase Realtime Database son bases de datos de documentos. Memorystore es compatible con las API de Redis y Memcached. Los servicios para socios de Google Cloud admiten ofertas administradas de MongoDB, DataStax, Redis Labs y Neo4j.

IBM ofrece alrededor de 10 tipos de bases de datos en su nube. Los servicios de bases de datos relacionales incluyen PostgreSQL, EnterpriseDB (una extensión comercial de PostgreSQL) e IBM Db2. Los servicios de base de datos NoSQL incluyen IBM Cloudant (una base de datos de documentos), MongoDB (también una base de datos de documentos), DataStax (una extensión comercial de Cassandra de columna ancha) y Redis (un almacén de estructura de datos en memoria, utilizado como base de datos, caché, y corredor de mensajes). IBM aloja PostgreSQL y MongoDB en entornos de hiperprotección, que están cifrados de extremo a extremo.

Microsoft Azure admite ocho bases de datos transaccionales en la nube. Azure SQL es la versión nativa de la nube de SQL Server, una base de datos relacional de múltiples modelos; Las instancias de Azure SQL son similares, pero ofrecen la máxima compatibilidad con el último motor de SQL Server. También puede ejecutar SQL Server en máquinas virtuales. Azure Database admite MariaDB, MySQL y PostgreSQL. Cosmos DB es un servicio de base de datos de alta disponibilidad, multimodelo y multirregión que ofrece modelos de documentos, columnas anchas, valores clave y gráficos, aunque un modelo por instancia. Azure Cache es compatible con Redis. Azure Managed Instance para Cassandra es una base de datos administrada de columna ancha que se puede sincronizar con clústeres de Cassandra locales.

MongoDB Atlas es un servicio de base de datos de documentos de múltiples nubes disponible en AWS, Google Cloud y Microsoft Azure. MongoDB en sí está disponible como un servicio administrado o en máquinas virtuales en prácticamente todos los proveedores de servicios en la nube.

MySQL , MariaDB , Vitess , PlanetScale y SkySQL son bases de datos derivadas de MySQL disponibles como servicio en la nube. MySQL es una base de datos relacional multimodelo de código abierto, disponible como un servicio administrado en AWS, Google Cloud, Microsoft Azure y Oracle Cloud, y en máquinas virtuales en prácticamente todos los proveedores de servicios en la nube. MariaDB es una bifurcación de MySQL de los desarrolladores originales. Vitess es un sistema de agrupación de bases de datos para el escalado horizontal de MySQL, con fragmentación automática. PlanetScale es una plataforma de base de datos sin servidor compatible con MySQL impulsada por Vitess. SkySQL es un servicio MariaDB disponible en AWS y Google Cloud.

Neo4j es una base de datos de gráficos de propiedades compatible con ACID con muchas características de agrupación. Neo4j Aura es una base de datos gráfica de Neo4j rápida, confiable, escalable y completamente automatizada, proporcionada como un servicio en la nube. Los niveles gratuitos y profesionales de Aura solo están disponibles en Google Cloud. El nivel empresarial está disponible tanto en AWS como en Google Cloud.

Oracle Database fue la primera base de datos relacional comercial y sigue siendo una base de datos relacional multimodelo líder. Está disponible en Oracle Cloud como servicio en múltiples formas y tamaños; MySQL también está disponible en Oracle Cloud como servicio. Oracle Database también está disponible para implementación local y en las nubes de AWS y Google.

Redis es un almacén de estructura de datos en memoria NoSQL que puede persistir en el disco. Puede funcionar como base de datos, caché y agente de mensajes. Proporciona alta disponibilidad a través de Redis Sentinel y partición automática con Redis Cluster. Redis Enterprise agrega características para mayor velocidad, confiabilidad y flexibilidad, y está disponible como una base de datos en la nube como servicio. Redis on Flash es una función de Redis Enterprise que puede reducir drásticamente el costo del hardware de Redis. Las instancias de Redis Enterprise Cloud están disponibles en AWS, Google Cloud y Microsoft Azure; puede elegir su propia región o regiones. También puede ejecutar Redis en máquinas virtuales en la nube, Kubernetes o contenedores.

Independientemente de la base de datos o bases de datos que elija para su aplicación, no olvide ejecutar una prueba de concepto antes de comprometerse y una prueba de carga antes de entrar en producción. Muchas bases de datos en la nube se pueden ampliar y ampliar según sea necesario, pero no todas pueden hacerlo sin transferir datos a una nueva instancia y luego cerrar la instancia anterior.

Una vez que su base de datos esté en producción, configure un monitoreo continuo con alertas para condiciones fuera de rango y esté preparado para enfrentar emergencias. Tenga en cuenta que algunas bases de datos requerirán ajustes y cambios en sus índices a medida que cambie su carga; otros se sintonizarán automáticamente.

DOCUMENTOS TÉCNICOS RECOMENDADOS

Fuente: https://www.infoworld.com/article/3627792/how-to-choose-a-cloud-database.html