Elegir una base de datos: relacional, documental, clave-valor, de columnas, de grafos y de series temporales

Por qué la elección merece atención

Una base de datos es uno de los componentes más difíciles de sustituir. Las aplicaciones se reescriben en torno a sus datos, no al revés; migrar terabytes de datos vivos mientras el negocio sigue funcionando puede llevar un año. Por eso, la elección del almacén es una puerta de un solo sentido que merece una decisión explícita, mientras que muchos equipos la toman por costumbre o por moda.

El Capítulo 0 presentó las bases de datos relacionales y las cuatro familias NoSQL. Esta sección va más allá: en qué es realmente buena cada familia, las categorías más recientes (series temporales, búsqueda, vectoriales y SQL distribuido), cómo elegir a partir de pruebas y no del entusiasmo, y cuánto cuesta operar varios tipos a la vez. La respuesta rara vez es una sola base de datos para todo, y casi nunca una base de datos distinta para cada servicio.

Relacional: sigue siendo la opción por defecto, por buenas razones

Una base de datos relacional almacena los datos en tablas con tipos, claves y restricciones declarados, y responde a consultas SQL declarativas, una idea del artículo de Edgar Codd de 1970. Cincuenta años después sigue siendo la opción por defecto sensata para los datos de negocio, por cuatro razones. Primera, las transacciones y las restricciones: la propia base de datos garantiza que un pago y sus asientos en el libro mayor se confirman juntos y que ningún pedido apunta a un cliente inexistente, así que estas reglas no tienen que reimplementarse, de forma imperfecta, en cada servicio. Segunda, la flexibilidad de las consultas: no necesitas conocer todas las preguntas futuras cuando diseñas el esquema; un nuevo informe es una nueva consulta, no una nueva tabla. Tercera, la madurez: décadas de herramientas para copias de seguridad, replicación, monitorización, migración y diagnóstico de rendimiento, e ingenieros que ya la conocen. Cuarta, la amplitud: los sistemas relacionales modernos almacenan e indexan JSON (el jsonb de PostgreSQL) y admiten búsqueda de texto completo, datos geoespaciales (PostGIS), particionado por tiempo y similitud vectorial (la extensión pgvector), así que una sola base de datos bien gestionada puede cubrir muchas necesidades a escala moderada.

Los límites reales son concretos. Las escrituras en un único primario están limitadas por una sola máquina; las tablas muy grandes necesitan un particionamiento cuidadoso; los cambios de esquema en tablas enormes requieren técnica (evolución de esquemas); y algunos patrones de acceso, como los recorridos profundos de grafos o la búsqueda de texto ordenada por relevancia, los resuelven mucho mejor motores especializados. Un solo servidor moderno con unidades de estado sólido rápidas puede atender miles de transacciones por segundo y terabytes de datos, lo que cubre las necesidades de la mayoría de las organizaciones.

Las familias no relacionales

Una base de datos documental almacena cada registro como un documento autocontenido, normalmente JSON o una forma binaria de JSON. Encaja con los agregados en el sentido del diseño guiado por el dominio: cosas que se leen y se escriben como un todo, como la carta de un restaurante con sus secciones, platos y grupos de opciones. Leer un documento es una sola búsqueda, sin joins. El compromiso aparece cuando hay que consultar los mismos datos con otra forma (todos los platos que contienen maní (cacahuete) en todas las cartas) o cambiarlos en muchos documentos a la vez; los productos modernos tienen joins y transacciones entre varios documentos, pero son más costosos y menos naturales que en SQL.

Un almacén clave-valor es un diccionario distribuido: guardas un valor bajo una clave y lo recuperas. Como el almacén nunca mira dentro de los valores, puede ser extremadamente rápido y fácil de particionar. Redis y su bifurcación de código abierto Valkey mantienen los datos en memoria con persistencia opcional y añaden estructuras de datos (conjuntos ordenados, flujos, índices geoespaciales) y caducidad; Amazon DynamoDB es un almacén gestionado y particionado clave-valor y documental. Encajan para sesiones, carritos, contadores de limitación de tasa, feature flags, cachés y la última posición de cada repartidor.

Un almacén de columnas anchas (Bigtable, Apache Cassandra, ScyllaDB, HBase) agrupa las filas por una clave de partición y las almacena ordenadas por una clave de agrupación (clustering key) dentro de cada partición. Está diseñado para volúmenes masivos de escritura repartidos entre muchos nodos y centros de datos. La disciplina que exige es el modelado a partir de las consultas: diseñas una tabla por consulta, duplicando datos libremente, porque las consultas que no parten de la clave de partición son caras o imposibles. Cassandra desciende en parte del artículo de Amazon sobre Dynamo, de 2007, cuyas ideas de replicación aparecen en dos secciones más adelante.

Una base de datos de grafos almacena los nodos y las relaciones como registros de primera clase y responde a consultas de recorrido como clientes a tres saltos o menos de esta red de fraude sin los joins en cascada que hacen lentas esas consultas en SQL. Cypher, de Neo4j, es el lenguaje de consulta más conocido, e ISO publicó en 2024 un lenguaje estándar de consulta de grafos, GQL (ISO/IEC 39075). Los grafos son excelentes para la detección de fraude, las recomendaciones y el análisis de redes, y suelen ser un mal almacén principal para los datos transaccionales de negocio.

Almacenes de series temporales, de búsqueda y vectoriales

Una base de datos de series temporales está optimizada para mediciones con marca de tiempo que llegan en orden y rara vez se actualizan: métricas, lecturas de sensores, precios, historial de ubicaciones. Comprime mucho, particiona por tiempo, reduce la resolución de los datos antiguos (conservar cada punto durante una semana y promedios por minuto durante un año) y elimina a bajo costo los datos caducados descartando particiones de tiempo enteras. Algunos ejemplos son InfluxDB, Prometheus (para la monitorización) y TimescaleDB, que es una extensión de PostgreSQL y muestra con qué frecuencia una base de datos relacional puede estirarse para encajar.

Un motor de búsqueda como Elasticsearch, OpenSearch o Apache Solr (todos construidos sobre la biblioteca Apache Lucene) mantiene un índice invertido de las palabras a los documentos que las contienen, con análisis de texto (lematización, sinónimos, tolerancia a erratas) y ordenación por relevancia. Responde a ramen vegano cerca de mí en milisegundos. Casi nunca debe ser un sistema de registro: los índices se actualizan casi en tiempo real en lugar de forma transaccional, y el diseño habitual alimenta el motor de búsqueda desde la base de datos propietaria y reconstruye el índice a partir de ella cuando hace falta.

Una base de datos vectorial almacena embeddings, listas de números que representan el significado de textos, imágenes o productos, y encuentra los elementos más cercanos a un vector de consulta. La búsqueda exacta compara la consulta con cada vector, así que estos almacenes usan índices de búsqueda aproximada de vecinos más cercanos, como los grafos HNSW, que sacrifican un poco de exhaustividad (recall) a cambio de velocidad. Impulsan la búsqueda semántica, las recomendaciones y la recuperación para modelos de lenguaje grandes, que se tratan en generación aumentada por recuperación. Existen productos dedicados (Milvus, Qdrant, Pinecone, Weaviate), pero para millones de vectores, y no miles de millones, suele bastar con una extensión de una base de datos existente, como pgvector.

SQL distribuido

Las bases de datos de SQL distribuido, a veces llamadas NewSQL (un término acuñado por el analista Matthew Aslett en 2011), mantienen el modelo relacional, SQL y las transacciones ACID, pero particionan y replican los datos automáticamente entre muchos nodos, a menudo entre regiones. Google Spanner, descrito en un artículo de OSDI de 2012, usa relojes estrechamente sincronizados (su API TrueTime, respaldada por GPS y relojes atómicos) para ofrecer transacciones globalmente consistentes. CockroachDB, YugabyteDB y TiDB ofrecen modelos similares sobre hardware corriente; CockroachDB usa por defecto el aislamiento serializable.

El precio lo ponen la física y la operación. Una transacción que deben acordar réplicas en varias regiones espera un viaje de ida y vuelta de consenso, así que las escrituras de una sola fila tardan de milisegundos a decenas o cientos de milisegundos, en lugar de muy por debajo de un milisegundo. La planificación de consultas entre particiones es más sutil, los costos son más altos y menos ingenieros conocen sus modos de fallo. El SQL distribuido es la herramienta adecuada cuando de verdad necesitas transacciones relacionales más allá de la capacidad de un servidor o entre regiones (un libro mayor de pagos global, un banco multirregión), y una herramienta cara cuando bastaría con un único primario PostgreSQL con réplicas.

Elegir: los criterios que importan

Elige por conjunto de datos, no por sistema. Para cada conjunto de datos importante, reúne pruebas sobre seis criterios y deja constancia de la decisión en un ADR.

Forma de los datos. ¿Son tabulares por naturaleza, con muchas relaciones, un agregado autocontenido, una red, una serie temporal, texto libre o vectores? Patrones de acceso. ¿Qué consultas se ejecutan, con qué frecuencia, con qué objetivos de latencia y cuántas son ad hoc? ¿Predominan las lecturas o las escrituras? ¿Siempre por clave o por muchos atributos? Necesidades de consistencia. ¿Necesitan los datos transacciones de varios elementos y restricciones (saldos, existencias, reservas), o unos segundos de desactualización son inofensivos (me gusta, recomendaciones)? Consulta los modelos de consistencia. Escala. Tamaño de los datos, escrituras por segundo y crecimiento, actuales y previstos, medidos y no adivinados; un almacén que escala a petabytes no es ninguna ventaja para 50 gigabytes. Operación. ¿Quién lo va a operar: copias de seguridad, actualizaciones, failover, monitorización, parches de seguridad? ¿Hay un servicio gestionado en tu nube y cuánto cuesta con tus volúmenes? Conocimientos del equipo. ¿Qué conoce ya el equipo lo bastante bien como para depurarlo a las 3 de la madrugada? Una tecnología desconocida trae modos de fallo desconocidos.

Dos hábitos mejoran la elección. Anota las cinco o diez consultas más importantes con sus latencias objetivo antes de elegir, y prueba el candidato con volúmenes de datos realistas; muchas decepciones vienen de un almacén que se evaluó en un portátil con mil filas. Y separa el sistema de registro de los almacenes derivados: el sistema de registro necesita las garantías más sólidas y la tecnología más conservadora, mientras que los almacenes derivados (índices de búsqueda, cachés, modelos de lectura) pueden ser especializados precisamente porque pueden reconstruirse.

La persistencia políglota y su costo

La persistencia políglota consiste en usar distintas tecnologías de almacenamiento para distintos datos dentro de un mismo sistema, elegidas según cómo se usan los datos. Martin Fowler popularizó el término en 2011, y atribuyó su primer uso a Scott Leberknight. Se deriva de forma natural de la base de datos por servicio: cada propietario puede elegir la herramienta adecuada.

El costo es fácil de subestimar. Cada tipo adicional de base de datos necesita sus propios conocimientos especializados, procedimientos de copia de seguridad y restauración, monitorización, planificación de capacidad, refuerzo de la seguridad, ciclo de actualizaciones y conocimientos para las guardias. Ahora los datos se mueven entre almacenes, así que necesitas pipelines (CDC, eventos) y debes razonar sobre el retardo y los fallos de cada uno. La consistencia entre almacenes es, como mucho, eventual. Para un equipo pequeño, cinco bases de datos pueden consumir más esfuerzo que el producto. Una regla razonable es justificar cada nuevo almacén con un requisito que los existentes demostrablemente no pueden cumplir, y preferir servicios gestionados para los especializados.

Errores comunes

Elecciones para engordar el currículum: elegir un almacén porque es nuevo o porque lo usa una gran empresa, sin el requisito que lo justificaba allí. Elegir para una escala imaginaria: diseñar para mil millones de usuarios con un producto que tiene mil, pagando el impuesto de la complejidad desde el primer día. Usar un almacén derivado como sistema de registro: un índice de búsqueda o una caché que se convierte en la única copia de los datos, con una durabilidad más débil de lo que nadie suponía. Ignorar el lado de las consultas: elegir un almacén clave-valor o de columnas anchas y descubrir después que el negocio necesita informes ad hoc y filtros que no puede atender. Subestimar la operación: olvidar que alguien tiene que restaurarlo desde una copia de seguridad, actualizarlo sin tiempo de inactividad y diagnosticarlo bajo carga. Por último, tratar la elección como una verdad permanente: deja constancia de los supuestos (volúmenes, consultas, conocimientos del equipo) para poder revisar la decisión cuando cambien.