# Una base de datos es la memoria del sistema Curso exprés sobre bases de datos y almacenes de datos. 20 conceptos — Relational, SQL, Transactions, Document, Key-value, Wide-column, Graph, Time-series, Search, Vector, Object storage, ACID, BASE, CAP, Index, Replication, Sharding, Normalization, Polyglot persistence — cada uno con su nombre en inglés, un diagrama y una ficha con un ejemplo y su coste. Al final, una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~35 minutos de lectura - **Published:** 2026-06-02 - **Source:** https://fedorthinks.com/es/learn/databases-express --- ## 1. Para qué sirve una base de datos Una base de datos es la memoria de largo plazo de tu sistema. El código se reescribe; los datos, y la forma que elegiste para ellos, suelen sobrevivir a todo lo que los rodea. ### Los datos sobreviven al código > Una casa se repinta, se reamuebla, hasta se le rehace el techo a lo largo de décadas — pero los cimientos que se vertieron el primer día se quedan, porque reemplazarlos significa levantar la casa entera. Los lenguajes cambian, los frameworks se intercambian, la UI se redibuja diez veces. **Los datos y su estructura normalmente se quedan**, porque cambiarlos en un sistema vivo lleno de registros reales es lento y riesgoso. Así que la base de datos es lo primero en lo que hay que pensar a fondo, y lo último que conviene apurar. ### Una base de datos responde dos preguntas > Elegir dónde guardar las cosas plantea dos cuestiones: qué forma tienen las cosas — ¿libros en estantes, o herramientas raras en ganchos? — y qué tan seguras deben estar — ¿una bóveda, o un cajón a mano? Todo almacén se define por dos cosas. Primero, su **modelo de datos**: cómo le da forma a los datos — tablas rígidas, documentos flexibles, un grafo de enlaces. Segundo, sus **garantías**: corrección estricta, o velocidad y disponibilidad con promesas más laxas. Casi toda elección de base de datos es una respuesta distinta a esas dos — y el resto de este curso es el menú. ### Access pattern — elegí por cómo leés y escribís > Un archivador, un fichero de catálogo y una cinta transportadora son todos «almacenamiento» — pero elegís por cómo vas a buscar las cosas, no por cuál parece más nuevo. No hay una mejor base de datos. Un almacén perfecto para búsquedas rápidas por clave es el equivocado para consultas de relaciones profundas; uno construido para escrituras enormes es el equivocado para transacciones bancarias estrictas. La pregunta correcta es tu **patrón de acceso** (access pattern): qué leés, qué escribís, con qué frecuencia, y cómo debe comportarse cuando las cosas salen mal. ### El mapa: 20 conceptos en seis grupos > Un mapa de metro: primero ves las líneas enteras, después viajás estación por estación. Los conceptos de este curso se dividen en seis grupos: el núcleo relacional, la familia NoSQL, los almacenes especializados, las garantías, las técnicas de escalado y cómo combinarlo todo. _Diagram: Seis grupos de conceptos — los capítulos 2–7 los siguen._ Cada concepto de abajo recibe el mismo trato: su **nombre en inglés** (el término con el que vas a buscar en los docs), una imagen de la vida real, un **diagrama** y una **ficha** con los campos: _problema_, _idea_, _ejemplo_, _coste_, _cuándo usarlo_ y _relaciones_. Al final te espera una hoja de referencia de una página. > **Antes de elegir un almacén:** «¿Qué forma tienen mis datos, cómo los voy a consultar, y qué tan estrictas deben ser las garantías?» > El código es fácil de cambiar. Los datos no. Elegí el almacén como una decisión con la que vas a vivir durante años — porque así será. ## 2. El default relacional Para la mayoría de los sistemas el default es la base de datos relacional — y se gana ese default. Empezá acá, y salí solo con una razón. ### Relational Database — tablas, filas y relaciones > Una hoja de cálculo bien hecha: cada hoja es un tipo de cosa (clientes, pedidos), cada fila un registro, y los pedidos apuntan de vuelta al cliente al que pertenecen. Esta es la **base de datos relacional** (relational database). Guarda los datos en **tablas** con un **esquema** fijo, y enlaza tablas por referencia — una fila de pedido contiene el id de su cliente. Esa referencia se llama **clave foránea** (foreign key). El esquema es una promesa sobre la forma: cada pedido tiene las columnas que debería, verificadas al entrar. **Estructura por adelantado, a cambio de cordura más tarde.** _Diagram: Dos tablas: un pedido contiene customer_id — una clave foránea que apunta a su cliente._ #### Relational Database (RDBMS) - **Problema:** Datos con estructura y relaciones a los que les vas a hacer muchas preguntas. - **Idea:** Tablas con un esquema fijo; tablas enlazadas mediante claves foráneas. - **Ejemplo:** Postgres, MySQL: tablas `customers` y `orders`, cada pedido tiene un `customer_id`. - **Coste:** El esquema hay que pensarlo por adelantado; cambiarlo con datos vivos da trabajo. - **Cuándo usarlo:** **Casi siempre, como punto de partida.** Salí solo con una razón. - **Relaciones:** Habla **SQL**, da **Transactions** y **ACID**. ### SQL — pedí lo que querés, no cómo conseguirlo > Le decís a un bibliotecario «cada novela de autores franceses publicada después de 1950, ordenada por año» — y él se las arregla para encontrarlas. Describís el resultado, no la búsqueda. **SQL (Structured Query Language)** es un **lenguaje de consultas declarativo**: enunciás la respuesta que querés y la base de datos planifica cómo obtenerla, incluida la unión de tablas (**JOIN**). Ese plan lo arma el **planificador de consultas** (query planner). `SELECT ... JOIN ... WHERE ...` puede responder preguntas que nunca anticipaste al diseñar — uno de los superpoderes silenciosos del modelo relacional. _Diagram: Vos escribís QUÉ querés; el planificador de la base de datos decide CÓMO obtenerlo._ #### SQL (lenguaje de consultas) - **Problema:** Necesitás hacerle preguntas a los datos sin programar a mano cada búsqueda. - **Idea:** Describí el resultado; la base de datos elige el plan (índices, joins, ordenamiento). - **Ejemplo:** `SELECT title FROM books JOIN authors ... WHERE country = 'FR' AND year > 1950 ORDER BY year`. - **Coste:** Las consultas complejas hay que leerlas con cuidado, y verificar cómo las ejecuta realmente la base de datos. - **Cuándo usarlo:** Dondequiera que haya una base de datos relacional — es su lengua nativa. - **Relaciones:** El lenguaje de una **Relational Database**; se vuelve rápido gracias a un **Index**. ### Transactions — todo o nada > Una transferencia de dinero son dos escrituras — menos acá, más allá — pero una sola intención. O pasan las dos o ninguna; una transferencia a medias es un desastre. Esta es la **transacción** (transaction): un grupo de cambios que o se **confirma** (commit) por completo o se **revierte** (rollback) por completo, aislado de los demás, y que sobrevive a una caída una vez confirmado. El conjunto de esas promesas se llama **ACID** (más en el capítulo 5). Por eso bancos, pedidos e inventarios viven en SQL — **cuando la corrección importa más que la velocidad cruda, querés esta promesa.** _Diagram: Una transferencia: el débito y el crédito son una sola transacción. O las dos hacen COMMIT o las dos hacen ROLLBACK._ #### Transaction (unidad de todo o nada) - **Problema:** Una acción son varias escrituras; una caída a la mitad deja basura. - **Idea:** Envolvé las escrituras en `BEGIN … COMMIT`: se guardan todas, o ninguna. - **Ejemplo:** Una transferencia: `A − 100` y `B + 100` en una sola transacción. - **Coste:** Algo de velocidad, y un escalado más difícil entre máquinas. - **Cuándo usarlo:** Dinero, pedidos, inventario — donde un número equivocado es inaceptable. - **Relaciones:** Las propiedades de una transacción son **ACID**. ### Por qué es el default correcto > Una buena herramienta de uso general: no es la más rápida en ninguna tarea concreta, pero es la que agarrás hasta que una tarea exige otra cosa. Datos estructurados, relaciones reales, consultas ad hoc, garantías fuertes — la base de datos relacional hace todo eso bien, y el Postgres moderno también maneja JSON, búsqueda de texto completo e incluso vectores. **Empezá todo proyecto acá;** buscá otra cosa solo cuando un dolor concreto — escala, forma o patrón de acceso — te empuje a salir. > **La pregunta relacional:** «¿Mis datos tienen una estructura clara y relaciones que voy a consultar de maneras que todavía no puedo predecir del todo?» > Empezá con Postgres. La pregunta no es «por qué SQL» — es si tenés una razón real para no usarlo. ## 3. Cuando una tabla no es la forma A veces la tabla rígida es la forma equivocada. «NoSQL» es en realidad una familia de almacenes, cada uno doblando las reglas en una dirección distinta para un trabajo distinto. ### Document Store — un documento JSON por cosa > Una carpeta de formularios completados, donde cada formulario puede tener campos un poco distintos — sin una plantilla central que obligue a todos a coincidir. Este es el **almacén documental** (document store). Guarda los registros como **documentos tipo JSON** flexibles, anidados y **sin esquema** (schema-less), así que dos registros de una misma **colección** (collection) pueden ser distintos. Es genial cuando las formas varían o evolucionan rápido, y una cosa entera — un producto, un perfil — vive como un solo documento que traés en una única lectura. _Diagram: Dos productos en una colección con campos distintos; el producto entero vuelve en una sola lectura._ #### Document Store (base de datos documental) - **Problema:** Las formas de los registros difieren o cambian rápido; la tabla estorba. - **Idea:** Cada cosa es un documento JSON anidado, sin un esquema rígido compartido. - **Ejemplo:** MongoDB: un catálogo de productos, perfiles de usuario. - **Coste:** Menos garantías y consultas entre documentos más difíciles que en SQL. - **Cuándo usarlo:** Una cosa se lee entera, y distintos registros tienen distintos campos. - **Relaciones:** Postgres también maneja documentos (**JSONB**); a menudo vive bajo las reglas de **BASE**. ### Key-Value Store — un hash map gigante > Un guardarropa — entregás un número de ticket, te devuelven exactamente tu abrigo. Sin buscar, sin preguntas, al instante. Este es el **almacén clave-valor** (key-value store) — la forma más simple: **entra una clave, sale un valor**, a una velocidad endiablada. Perfecto para caché, sesiones, contadores de **rate-limit** y todo lo que se trae por un id conocido. _Diagram: Si sabés la clave, obtenés el valor al instante. Preguntar por los valores no es posible._ #### Key-Value Store (clave → valor) - **Problema:** Necesitás recuperar datos muy rápido por un id conocido. - **Idea:** Clave → valor, como un hash map gigante. - **Ejemplo:** Redis, DynamoDB: `session:42`, una caché de páginas, un contador de rate-limit. - **Coste:** Solo podés buscar por clave — sin consultas ricas sobre los valores. - **Cuándo usarlo:** Caché, sesiones, contadores — todo donde el id se conoce de antemano. - **Relaciones:** El típico «ayudante rápido» junto a la base de datos principal en **Polyglot persistence**. ### Wide-Column Store — hecho para escrituras enormes > Un depósito inmenso con pasillos idénticos sin fin, dispuesto para que mil montacargas llenen estantes a la vez sin chocarse. Este es el **almacén wide-column**. Reparte los datos entre muchas máquinas según una **clave de partición** (partition key) para lograr un **rendimiento y una escala de escritura masivos**, a cambio de consultas ricas y consistencia estricta, para poder absorber una manguera de datos. Potente — y más trabajo operativo para hacerlo andar bien. _Diagram: La clave de partición reparte las escrituras entre muchas máquinas; las filas son anchas, no hay joins._ #### Wide-Column Store (column-family store) - **Problema:** Tantas escrituras que una sola máquina SQL se doblaría. - **Idea:** Repartí los datos entre muchos nodos por clave de partición; escribí en paralelo. - **Ejemplo:** Cassandra: logs de eventos, telemetría, feeds a escala. - **Coste:** Sin consultas ricas ni consistencia estricta; más difícil de operar. - **Cuándo usarlo:** Una manguera de escrituras, con consultas conocidas de antemano y simples. - **Relaciones:** Básicamente **Sharding** incorporado; normalmente vive bajo **BASE**. ### Graph Database — cuando los vínculos son lo importante > El tablero de un detective — fotos conectadas con hilo. El valor no está en ninguna foto; está en la red de quién se ata con quién. Esta es la **base de datos de grafos** (graph database). Modela los datos como **nodos** y las **aristas** (edges) entre ellos, y hace que las consultas de relaciones — «amigos de amigos a los que les gusta esto», «el camino entre estas dos cuentas» — sean naturales y rápidas, donde SQL necesitaría dolorosos joins de muchos niveles. **Recurrí a ella cuando las conexiones importan más que los registros.** _Diagram: “Amigos de amigos a los que les gusta X”: solo se recorren las aristas Ann → Bob → Cara → Jazz club._ #### Graph Database (graph store) - **Problema:** Las preguntas principales son sobre vínculos, y en SQL se vuelven JOINs de muchos pisos. - **Idea:** Nodos y aristas son datos de primera clase; una consulta recorre las aristas. - **Ejemplo:** Neo4j: grafos sociales, recomendaciones, detección de fraude. - **Coste:** Un nicho estrecho; incómoda para registros y reportes ordinarios. - **Cuándo usarlo:** Las conexiones importan más que los registros. - **Relaciones:** Una alternativa a la **Relational Database** cuando los JOINs se vuelven el dolor. > **La pregunta NoSQL:** «¿La forma relacional realmente me está estorbando — documentos variados, puras búsquedas por clave, una manguera de escrituras, o una red de relaciones?» > NoSQL no es «un SQL más nuevo». Cada almacén suelta una garantía para ganar algo concreto — sabé cuál estás cambiando. ## 4. Almacenes especializados Más allá de los almacenes generales hay bases de datos hechas para un solo trabajo, donde un motor diseñado a propósito le gana por mucho a uno general. ### Time-Series Database — datos marcados por el reloj > La cinta de un monitor cardíaco — una tira interminable de lecturas, cada una atada a un momento, donde casi siempre preguntás «¿qué pasó entre estas dos horas?» Esta es la **base de datos de series temporales** (time-series database). Está afinada para **datos que llegan en orden temporal y se consultan por tiempo** — métricas, lecturas de sensores, precios. Ingiere flujos enormes y responde rápido «promedio por minuto de la última semana», con expiración integrada de los datos viejos (**retention**). _Diagram: Los puntos llegan en orden temporal; una consulta es una ventana de t1 a t2; los datos viejos expiran por retención._ #### Time-Series Database (TSDB) - **Problema:** Un flujo enorme de lecturas, y cada pregunta es «qué pasó en este período». - **Idea:** Guardá e indexá por tiempo; agregá ventanas rápido. - **Ejemplo:** InfluxDB, TimescaleDB: métricas de servidores, sensores, precios. - **Coste:** Un almacén más que operar; mala opción para datos de negocio ordinarios. - **Cuándo usarlo:** Todo tiene una marca de tiempo, y el tiempo es el eje principal. - **Relaciones:** TimescaleDB es una extensión de Postgres — ver **Postgres first**. ### Search Engine — texto completo y relevancia > Un cuadro de búsqueda que perdona los errores de tipeo, pone primero las mejores coincidencias, y encuentra «corriendo» cuando escribiste «correr» — como un bibliotecario que sabe lo que quisiste decir. Este es el **motor de búsqueda** (search engine). Construye un **índice invertido** (inverted index) — «palabra → documentos» — para una **búsqueda de texto completo rápida, con ranking, coincidencia aproximada y filtros**: lo que un `LIKE '%palabra%'` de SQL hace lento y mal. Suele correr junto a tu base de datos principal, mantenido en sincronía, y alimenta la barra de búsqueda y la exploración de logs. _Diagram: Los datos se copian de Postgres a un índice de búsqueda; una consulta con un error de tipeo devuelve una lista ordenada._ #### Search Engine (búsqueda de texto completo) - **Problema:** `LIKE '%palabra%'` es lento, no perdona errores de tipeo y no ordena por relevancia. - **Idea:** Un índice invertido de palabras, más una puntuación de relevancia. - **Ejemplo:** Elasticsearch, OpenSearch: la barra de búsqueda de un sitio, exploración de logs. - **Coste:** Hay que mantenerlo en sincronía con la base de datos principal. - **Cuándo usarlo:** Los usuarios buscan por texto y esperan una búsqueda «inteligente». - **Relaciones:** **No es la fuente de verdad** — una lente rápida sobre ella; parte de **Polyglot persistence**. ### Vector Database — búsqueda por significado > En vez de coincidir con palabras exactas, preguntás «buscame cosas que se sientan como esta» — y devuelve vecinos por similitud, no por palabra clave. Esta es la **base de datos vectorial** (vector database). Guarda **embeddings** — huellas numéricas del significado — y encuentra los **vecinos más cercanos** (nearest neighbours), así que podés buscar por similitud en vez de por texto exacto. Es el motor debajo de la **búsqueda semántica** y de **RAG**, donde una app de IA recupera los fragmentos más relevantes para responder. _Diagram: El texto se vuelve un vector; los puntos más cercanos son los textos más próximos en significado._ #### Vector Database (vector store) - **Problema:** Necesitás cosas parecidas en significado, pero las palabras pueden no coincidir. - **Idea:** Guardá embeddings y buscá los vecinos más cercanos. - **Ejemplo:** pgvector, Pinecone: la consulta «política de reembolso» encuentra «devoluciones» y «dinero de vuelta». - **Coste:** Necesita un modelo de embeddings, y sincronizarse con los datos de origen. - **Cuándo usarlo:** Búsqueda semántica y RAG — el nuevo almacén esencial de la era de la IA. - **Relaciones:** pgvector es una extensión de Postgres; una copia de los datos, como un **Search Engine**. ### Object Storage — adonde van los archivos grandes > Un guardamuebles — no para fichas, sino para los muebles: cosas voluminosas que guardás con una etiqueta y sacás enteras. Este es el **almacenamiento de objetos** (object storage). No es una base de datos, pero es donde viven los **blobs grandes** — imágenes, video, backups, documentos — direccionados por una **clave** dentro de un **bucket** y servidos barato a escala. El patrón es casi universal: guardá el archivo en el almacenamiento de objetos, guardá en tu base de datos una fila que apunte a él. **Los registros en la base de datos, las cargas en el bucket.** _Diagram: La fila de Postgres guarda solo la clave; el archivo en sí vive en un bucket de S3._ #### Object Storage (S3, blob storage) - **Problema:** Los archivos grandes dentro de la base de datos la inflan y son caros de servir. - **Idea:** El archivo va a un bucket por clave; la base de datos guarda solo una fila con esa clave. - **Ejemplo:** S3 y sus parientes: fotos, video, backups, documentos. - **Coste:** No es una base de datos: sin consultas sobre el contenido, solo «put/get por clave». - **Cuándo usarlo:** Cualquier archivo grande. - **Relaciones:** Con la forma de un **Key-Value Store**, pero para cosas voluminosas. > **La pregunta especializada:** «¿Es esto un trabajo — tiempo, texto, similitud, archivos grandes — donde un almacén hecho a propósito aplasta a uno general?» > No fuerces a tu base de datos principal a ser un motor de búsqueda o un servidor de archivos. Poné el trabajo especializado en el almacén hecho para eso. ## 5. Las garantías La elección más profunda de una base de datos no es su forma — es lo que promete cuando las cosas salen mal. Una pequeña sopa de letras nombra ese intercambio. ### ACID — pesimista, correcto, cuidadoso > Un cajero de banco que revisa dos veces cada asiento y no sigue hasta que los libros cuadran — más lento, pero nunca se equivoca. **ACID** es la **promesa estricta** que hacen las bases de datos relacionales sobre las transacciones: toda transacción deja los datos correctos y completos, o no ocurre en absoluto. Cuatro letras: **Atomicity** (todo o nada), **Consistency** (las reglas de los datos siempre se cumplen), **Isolation** (las transacciones concurrentes no se estorban), **Durability** (lo confirmado sobrevive a una caída). **Para dinero, pedidos y todo donde un número equivocado es inaceptable, este es el intercambio que querés.** _Diagram: Las cuatro letras de ACID y lo que promete cada una._ #### ACID (Atomicity, Consistency, Isolation, Durability) - **Promesa:** Toda transacción es totalmente correcta, o no ocurrió en absoluto. - **Ejemplo:** Una transferencia bancaria, hacer un pedido, sacar stock del inventario. - **Coste:** Algo de velocidad, y un escalado más difícil entre máquinas. - **Cuándo usarlo:** Un número equivocado es inaceptable. - **Relaciones:** Las propiedades de una **Transaction**; la postura opuesta es **BASE**. ### BASE — optimista, disponible, correcto con el tiempo > Un negocio concurrido que deja que todos sigan comprando incluso mientras se actualizan las etiquetas de precio — los números se ponen al día en un momento, y está bien. Muchos sistemas NoSQL toman la postura opuesta: **BASE** (Basically Available, Soft state, Eventually consistent). Se mantienen **rápidos y disponibles** y aceptan que las copias de los datos pueden discrepar brevemente antes de converger. Esto se llama **consistencia eventual** (eventual consistency). _Diagram: La escritura llega al nodo A de inmediato, y a B y C un poco después. Un momento de desacuerdo, y después todos coinciden._ #### BASE (Basically Available, Soft state, Eventually consistent) - **Promesa:** El sistema siempre responde; las copias convergen «con el tiempo». - **Ejemplo:** Un contador de likes, un feed, un contador de vistas. - **Coste:** Puede que veas brevemente un valor desactualizado. - **Cuándo usarlo:** La disponibilidad pesa más que la precisión instantánea, y un segundo de desactualización no cuesta nada. - **Relaciones:** Lo opuesto a **ACID**; la elección «A» en **CAP**. ### CAP Theorem — elegí cuando la red se rompe > Un equipo partido por una línea telefónica caída: cada mitad puede seguir trabajando sola (pero van a divergir), o dejar las herramientas hasta reconectarse (pero se paran). No se puede tener las dos cosas. El **teorema CAP** dice que cuando una **partición de red** (network partition) separa las máquinas de tu base de datos, tenés que elegir **Consistency** (rechazar escrituras, seguir siendo correcto) o **Availability** (seguir sirviendo, arriesgando desacuerdo) — no podés tener las dos durante la separación. Toda base de datos distribuida toma esta decisión. **Saber cuál elige tu almacén te dice cómo se comporta en su peor día.** _Diagram: La red se rompió: o CP (rechaza, pero sigue correcto) o AP (sigue trabajando, pero puede divergir)._ #### CAP Theorem (Consistency, Availability, Partition tolerance) - **Dice:** Durante una separación de red no podés ser a la vez correcto y disponible. - **Ejemplo:** Dos nodos pierden contacto: rechazar la escritura (CP), o aceptarla en los dos y reconciliar después (AP). - **Coste:** CP — caída del servicio; AP — datos desactualizados o en conflicto. - **Cuándo pensarlo:** Apenas tus datos viven en más de una máquina. - **Relaciones:** Lo plantean **Replication** y **Sharding**; el lado AP es **BASE**. > **La pregunta de las garantías:** «Cuando dos copias pueden discrepar, ¿necesito corrección aunque eso signifique caída — o disponibilidad aunque eso signifique datos desactualizados?» > ACID para el dinero, BASE para los likes. La garantía que necesitás la fija el costo de equivocarte por un rato. ## 6. Rápido y confiable a escala Un puñado de técnicas convierte una base de datos de una caja única y frágil en algo rápido y capaz de sobrevivir. Las vas a conocer todas. ### Index — el índice de un libro, para los datos > Para encontrar una palabra en un libro de 900 páginas no leés cada página — vas al índice del final y saltás directo. Un **índice** (index) es una estructura auxiliar que convierte un **escaneo completo de la tabla** (full table scan) en una búsqueda directa — la **mayor palanca sobre la velocidad de lectura.** La trampa: cada índice cuesta almacenamiento y hace más lentas las escrituras (cada insert también tiene que actualizarlo). _Diagram: Sin índice la base de datos lee cada fila; con uno salta por una lista ordenada directo a la fila correcta._ #### Index (B-tree index) - **Problema:** Una consulta lee toda la tabla, y se vuelve más lenta a medida que crecen los datos. - **Idea:** Una estructura auxiliar ordenada sobre una columna → una búsqueda directa de la fila. - **Ejemplo:** Un índice sobre `email`: encontrar un usuario sin escanear toda la tabla. - **Coste:** Espacio en disco, y cada escritura se vuelve más lenta. - **Cuándo usarlo:** En las columnas por las que realmente filtrás y ordenás — no en todas, por las dudas. - **Relaciones:** Acelera **SQL**; un motor de búsqueda es un índice especial sobre texto. ### Replication — guardá copias, sobreviví a las fallas > Un documento guardado en tres cajas fuertes en tres edificios — si uno se incendia, los otros lo conservan, y tres personas pueden leerlo a la vez. La **replicación** (replication) mantiene **copias de los datos en varias máquinas**. Todas las escrituras van al **líder** (leader), y los **seguidores (réplicas)** reciben una copia y sirven lecturas. Si el líder muere, un seguidor toma su lugar (**failover**). La trampa es el **retraso de replicación** (replication lag): un seguidor puede ir un momento atrasado, así que un valor que acabás de escribir puede no aparecer todavía en una réplica. _Diagram: El líder recibe las escrituras y envía copias; los seguidores sirven lecturas y toman el mando si el líder cae._ #### Replication (líder–seguidor) - **Problema:** Una máquina es un punto único de falla y un único techo para las lecturas. - **Idea:** Los mismos datos en varias máquinas: el líder escribe, los seguidores leen. - **Ejemplo:** Postgres con dos réplicas de lectura; si el líder cae, una réplica pasa a ser líder. - **Coste:** Retraso: una escritura reciente puede no haber llegado todavía a la réplica. - **Cuándo usarlo:** Necesitás confiabilidad, o más lecturas de las que una máquina puede servir. - **Relaciones:** Copia **los mismos** datos; **Sharding** divide datos **distintos**. Ambos llevan a **CAP**. ### Sharding — dividí cuando una caja no alcanza > Un archivador desbordado se vuelve A–M en un archivador y N–Z en otro. Más lugar — pero ahora tenés que saber en qué archivador vive cada nombre. Cuando los datos o la carga de escritura superan a una sola máquina, el **sharding** **divide los datos entre muchas** — los usuarios A–M acá, N–Z allá. Cada parte es un **shard**, y el campo por el que dividís es la **clave de sharding** (shard key). Abre una escala casi ilimitada, pero la **clave de sharding es una elección difícil y casi permanente:** si elegís mal, tenés **hotspots**, o consultas que tienen que tocar todos los shards. _Diagram: El router lee la clave: “Ann” va al shard 1, “Zoe” al shard 2. Cada shard guarda datos distintos._ #### Sharding (particionado horizontal) - **Problema:** Los datos o el flujo de escritura no caben en una sola máquina. - **Idea:** Dividí los datos por una clave entre muchas máquinas. - **Ejemplo:** Usuarios A–M en el shard 1, N–Z en el shard 2. - **Coste:** La clave es casi permanente; una mala clave → hotspots, o consultas a través de todos los shards. - **Cuándo usarlo:** Al final: después de los índices y las réplicas. - **Relaciones:** Incorporado en un **Wide-Column Store**; junto con **Replication** lleva a **CAP**. ### Normalization / Denormalization — un dato en un lugar, o copias por velocidad > Una lista maestra de direcciones a la que todos se refieren (sin contradicciones) frente a engrapar una copia de la dirección en cada pedido (más rápido de leer, pero ahora hay copias que mantener honestas). La **normalización** (normalization) guarda cada dato en exactamente un lugar — limpio, sin contradicciones, el default relacional. La **desnormalización** (denormalization) duplica datos a propósito para que las lecturas sean más rápidas y necesiten menos joins. Las dos son válidas; la regla es hacerlo **de forma consciente**, y saber siempre cuál copia es la **fuente de verdad** y cuál es solo un duplicado rápido. (La misma lección que con una caché.) _Diagram: Izquierda: cada pedido apunta a una única dirección. Derecha: la dirección se copia dentro de cada pedido._ #### Normalization / Denormalization (un lugar vs copias rápidas) - **Problema:** El mismo dato en varios lugares se desincroniza; pero los joins hacen más lentas las lecturas. - **Idea:** Normalizá por defecto; desnormalizá a propósito donde las lecturas importan más. - **Ejemplo:** Una dirección en una tabla `addresses` vs una copia de ella en cada pedido. - **Coste:** Normalización — más JOINs; desnormalización — copias que hay que mantener sincronizadas. - **Cuándo usarlo:** Desnormalizá cuando lecturas medidas como lentas lo exijan. - **Relaciones:** La misma idea de «fuente de verdad + copias rápidas» que **Polyglot persistence**. > **La pregunta de la escala:** «¿Mi problema real es la velocidad de lectura (índices, réplicas), la supervivencia (replicación) o el tamaño puro (sharding) — y estoy resolviendo el que de verdad tengo?» > Agregá un índice antes que un servidor, una réplica antes que un shard. El escalado más barato es el que no tenés que operar. ## 7. Elegir bien No elegís una base de datos y metés todo en ella a la fuerza. Los sistemas reales usan unas pocas, cada una para el trabajo en el que es mejor. ### Polyglot Persistence — varios almacenes, a propósito > Una cocina tiene heladera, freezer y alacena — no una sola caja obligada a hacer las tres cosas. Cada una guarda lo que le corresponde. Este es el patrón de **persistencia políglota** (polyglot persistence). Los sistemas maduros suelen usar varios almacenes: Postgres como fuente de verdad, Redis para caché y sesiones, un índice de búsqueda para la barra de búsqueda, quizás un almacén vectorial para las funciones de IA y almacenamiento de objetos para los archivos. Cada almacén hace lo que mejor sabe. La disciplina es tener claro **cuál guarda la verdad**, con los demás como copias rápidas mantenidas en sincronía. _Diagram: Cinco almacenes, cada uno para su trabajo. La verdad vive en Postgres; el resto son copias._ #### Polyglot Persistence (varios almacenes en un sistema) - **Problema:** Ninguna base de datos puede ser la mejor en todo. - **Idea:** Cada trabajo tiene su propio almacén; una fuente de verdad explícita. - **Ejemplo:** Postgres + Redis + un índice de búsqueda + un almacén vectorial + S3. - **Coste:** Cada almacén hay que operarlo, respaldarlo y mantenerlo consistente. - **Cuándo usarlo:** Cuando un dolor real exige otro almacén — no «por las dudas». - **Relaciones:** Parte de **Postgres first**; une casi todos los almacenes del curso. ### Postgres First — empezá con Postgres, salí de él a propósito > Una navaja suiza resuelve una cantidad sorprendente de cosas antes de que necesites la caja de herramientas completa. Esta es la práctica de **Postgres first**. El Postgres moderno es asombrosamente capaz — núcleo relacional, documentos JSON, búsqueda de texto completo, vectores, incluso una cola de trabajos que funciona. **La mayoría de los productos deberían empezar solo con Postgres** y agregar un almacén especializado únicamente cuando un dolor real y medido lo exija. Cada base de datos extra es una cosa más que operar, respaldar y mantener consistente. El almacén más barato es el que no agregaste. _Diagram: Un solo Postgres cubre tablas, documentos, búsqueda, vectores y una cola. Un almacén nuevo solo ante un dolor real._ #### Postgres First (empezá con Postgres) - **Problema:** Los equipos agregan bases de datos antes de que aparezca el dolor. - **Idea:** Un Postgres, hasta que un problema medido exija más. - **Ejemplo:** JSONB en vez de un almacén documental aparte, pgvector en vez de una base de datos vectorial aparte. - **Coste:** A escalas muy grandes un motor especializado igual va a ganar. - **Cuándo usarlo:** Al comienzo de casi cualquier producto. - **Relaciones:** El primer paso hacia **Polyglot persistence** — una vez que el «por ahora» terminó. ### Cómo se conecta todo > Un mapa del barrio después de una larga caminata: ahora ves qué calles llevan adónde. Los conceptos de este curso no viven solos. La base de datos relacional es la **fuente de verdad** con garantías **ACID**; un **índice** acelera sus lecturas; el motor de búsqueda y la base de datos vectorial son **copias** alimentadas desde ella; el almacenamiento de objetos guarda los archivos a los que apuntan sus filas. Cuando una máquina no alcanza, llegan la **replicación y el sharding** — y con ellos la elección de **CAP**. La familia NoSQL suele elegir **BASE** — lo opuesto a ACID. _Diagram: Los vínculos principales entre los conceptos del curso: la fuente de verdad está en el centro._ #### Antes de elegir una base de datos - **Qué forma tienen los datos** — ¿tablas, documentos, clave-valor, un grafo? - **Cómo los voy a consultar** — ¿por id, por relaciones, por texto, por similitud, por tiempo? - **Qué garantías necesito** — ¿ACID estricto, o la consistencia eventual alcanza? - **Cuál es el equilibrio lectura/escritura** y la escala aproximada. - **Podría Postgres ya hacer esto** antes de que agregue otro almacén. - **Qué almacén guarda la fuente de verdad**, y cuáles son solo copias. #### Señales de que elegiste mal - Usás `LIKE '%...%'` para buscar en vez de un motor de búsqueda. - Un **almacén clave-valor** donde constantemente necesitás consultar por los valores. - **Cinco bases de datos** para un producto que mantienen dos personas. - Elegiste **MongoDB para evitar esquemas**, y de todos modos reconstruiste la validación a mano. - **Sin una fuente de verdad clara** — dos almacenes que se dicen autoritativos. #### Señales de que elegiste bien - La **consulta que más ejecutás** es en la que el almacén es más rápido. - La **garantía coincide con lo que está en juego** — estricta para el dinero, relajada para los likes. - Podés nombrar la **fuente de verdad** de cada dato importante. - Agregaste cada almacén para resolver un **dolor real y sentido**, no uno hipotético. - Podrías **explicar el modelo de datos** a un ingeniero nuevo en pocos minutos. ## Hoja de referencia: los 20 conceptos ### El núcleo relacional - **Relational Database** (RDBMS): Tablas con un esquema fijo, enlazadas por claves foráneas. El default. - **SQL** (lenguaje de consultas): Describí lo que querés; la base de datos decide cómo obtenerlo. - **Transaction** (todo o nada): Varias escrituras como una unidad: COMMIT de todas o ROLLBACK de todas. ### La familia NoSQL - **Document Store** (base de datos documental): Documentos JSON flexibles; una cosa se lee entera. - **Key-Value Store** (clave → valor): Clave → valor, al instante. Caché, sesiones, contadores. - **Wide-Column Store** (column-family): Datos repartidos entre muchas máquinas para absorber una manguera de escrituras. - **Graph Database** (graph store): Nodos y aristas; consultas de relaciones sin JOINs dolorosos. ### Almacenes especializados - **Time-Series Database** (TSDB): Lecturas por tiempo; consultas por ventana, los datos viejos expiran. - **Search Engine** (búsqueda de texto completo): Búsqueda de texto completo con ranking y tolerancia a errores de tipeo. Una copia, no la verdad. - **Vector Database** (vector store): Embeddings y búsqueda del más cercano por significado. La base de RAG. - **Object Storage** (S3): Archivos grandes por clave en un bucket; la base de datos guarda solo un puntero. ### Garantías - **ACID** (la promesa estricta): Una transacción es totalmente correcta o no ocurrió. Para el dinero. - **BASE** (consistencia eventual): Siempre disponible, las copias convergen con el tiempo. Para los likes. - **CAP Theorem** (elegí C o A): Durante una separación de red — o corrección o disponibilidad. ### Escala - **Index** (B-tree index): Un puntero para lecturas rápidas; el coste es espacio y escrituras más lentas. - **Replication** (líder–seguidor): Los mismos datos en muchas máquinas: confiabilidad y lecturas. Hay retraso. - **Sharding** (particionado horizontal): Datos distintos en máquinas distintas según una clave. La clave es casi permanente. - **Normalization / Denormalization** (un lugar vs copias): Un dato en un lugar — o copias deliberadas por velocidad. ### Elegir - **Polyglot Persistence** (varios almacenes): Cada trabajo su propio almacén, una fuente de verdad. - **Postgres First** (empezá con Postgres): Un Postgres, hasta que un dolor real exija más. > La mejor decisión de base de datos suele ser «Postgres, por ahora» — más la sabiduría para saber exactamente cuándo ese «por ahora» terminó. Fin del curso exprés · 7 capítulos · 20 conceptos Lo que sigue es la profundidad: _Designing Data-Intensive Applications_ de Martin Kleppmann es el único libro para leer, junto a los docs de Postgres y el manual propio de tu almacén. Pero antes del fondo profundo — imaginá cómo se van a leer, escribir y confiar tus datos. La base de datos es donde tu sistema recuerda; elegí cómo recuerda antes de elegir con qué está construido.