Bases de datos en la nube

El problema de las 2 a.m. que resuelve una base de datos administrada

Una base de datos se cae a las 2 de la mañana. Alguien tiene que notarlo, diagnosticar si fue un parche defectuoso, una falla de disco o una consulta descontrolada, y traerla de vuelta sin perder datos. Correr una base de datos tú mismo, aunque sea en una máquina virtual en la nube, significa que ese alguien eres tú. Un servicio de base de datos administrado existe para que ese alguien sea el proveedor en su lugar, para todo excepto las partes que solo tú puedes responder, como qué consultas corre en realidad tu aplicación.

Qué asume en realidad "administrado"

Amazon RDS es el modelo de una base de datos relacional administrada, y su propia documentación es específica sobre el reparto. Compara correr una base de datos on-premises, en una máquina virtual EC2 plana y en RDS.

Pasar de on-premises a EC2 entrega el hardware físico. Pasar de EC2 a RDS entrega casi todo lo relacionado con correr el motor de base de datos en sí, parcheo, respaldos, escalado, detección y recuperación de fallas. Lo que se queda contigo en cada columna es el ajuste de consultas, porque depende por completo de tu aplicación específica, tus consultas específicas y tus datos específicos, un trabajo que ningún servicio administrado puede hacer en tu nombre.

Bases de datos relacionales: filas que se relacionan con otras filas

Imagina la tabla Pedidos de una tienda en línea. Cada fila necesita un customer_id que apunte a una fila real en una tabla Clientes separada, y un product_id que apunte a una fila real en Inventario. Esa relación forzada, un pedido que no puede existir sin un cliente y un producto que coincidan, es el rasgo distintivo de una base de datos relacional: datos organizados en tablas con filas y columnas, consultados con SQL, y conectados entre tablas mediante claves. Amazon RDS soporta 6 motores bajo este modelo: MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database e IBM Db2, todos consultables con el mismo modelo relacional aunque los motores subyacentes sean distintos.

Esa estructura es justo lo que necesita un pedido. Si un pago falla a la mitad del checkout, la base de datos no debe dejar un pedido apuntando a una fila de cliente o inventario que ya no tenga sentido, y las bases de datos relacionales están construidas para forzar justo ese tipo de consistencia.

Bases de datos NoSQL: búsquedas rápidas sin las relaciones

Ahora imagina una tabla de posiciones para un juego con 10 millones de jugadores concurrentes, o un carrito de compras que se lee y se reescribe en cada clic. Ninguno de los 2 necesita unirse con otra tabla, y ninguno se beneficia del costo de forzar relaciones entre tablas. Las bases de datos NoSQL, modeladas según Amazon DynamoDB, abandonan el modelo de tablas y uniones a favor de elementos recuperados directamente por una clave, con una estructura flexible que puede variar de un elemento a otro. DynamoDB anuncia rendimiento de milisegundos de un solo dígito ya sea que una aplicación atienda a decenas de miles o a cientos de millones de usuarios concurrentes, porque todo el diseño cambia las relaciones entre elementos por ese tipo de escala.

El límite: emparejar el modelo con el patrón de acceso

Ejemplo trabajado: 1 plataforma, 2 bases de datos

La misma plataforma de e-commerce de la lección anterior necesita ambos modelos a la vez, no una elección única entre ellos. Pedidos, clientes e inventario van en una base de datos relacional, porque un pedido que referencia a un cliente inexistente o una fila de inventario que no existe es un error, y el modelo relacional es lo que lo evita. El contenido del carrito de compras y los datos de sesión van en una base de datos NoSQL, porque esos datos cambian constantemente, se leen en casi cada carga de página, y nunca necesitan unirse con la tabla de Pedidos para cumplir su función. Correr ambas lado a lado, en vez de forzar cada tipo de dato por un solo modelo, es arquitectura normal, no una concesión.

El error de concepto: más nuevo no significa universalmente mejor

Es tentador tratar a NoSQL como la actualización moderna y a lo relacional como la opción heredada. Ese enfoque pasa por alto lo que cada uno en realidad sacrifica. NoSQL escala a una carga concurrente enorme justo porque no fuerza relaciones entre elementos, la misma garantía de la que depende un sistema de pedidos e inventario. Una aplicación bien construida no elige un bando una sola vez, coloca cada tipo de dato en el modelo construido para su patrón de acceso, que es la razón por la que los sistemas reales suelen correr bases de datos relacionales y NoSQL lado a lado en vez de elegir una para todo.

Dónde te deja esto

Un servicio de base de datos administrado se encarga del parcheo, los respaldos y la recuperación de fallas para que te concentres en las consultas y el esquema que solo tú entiendes. Recurre a una base de datos relacional cuando los registros deban mantenerse consistentes entre sí a través de tablas, y recurre a NoSQL cuando la carga sea una búsqueda simple de alto volumen que no necesite esas relaciones. La siguiente lección cubre cómo llega en realidad el tráfico hasta estas bases de datos y el cómputo frente a ellas: las redes en la nube.