Database Systems Labs
Modelos sin reunión en el servidor: el agregado como frontera de consistencia, cuando incrustar y que se pierde en una caché.
4 clases · 13 horas · 16 conceptos · 9 fuentes
Esta parte se apoya en lo trabajado antes. Si vienes de fuera del programa, revisa al menos el vocabulario de:
La primera salida del relacional, y se hace por la puerta correcta: no por la moda, sino por una idea con nombre propio. El agregado es el conjunto de datos que se lee, se escribe y se mantiene consistente como una unidad, y en los motores documentales la frontera transaccional coincide con él. Diseñar el agregado es, por tanto, decidir dónde termina la garantía del motor y empieza el trabajo de tu aplicación.
Las cuatro clases desarrollan esa idea. La primera la establece. La segunda la aplica a la decisión central del modelado documental —incrustar o referenciar— con sus dos criterios: si el dato se lee siempre junto, y si puede crecer sin techo. La tercera enseña a consultar e indexar lo modelado, con la regla que más rendimiento decide en una canalización de agregación. La cuarta trata el clave- valor y la caché diciendo con precisión qué se pierde: la consulta por contenido, la integridad declarada y, según la configuración, parte de la durabilidad.
Nada aquí sugiere abandonar el relacional. Sugiere saber qué se está comprando y con qué moneda se paga.
| # | Clase | Nivel | Horas | Fuentes |
|---|---|---|---|---|
| 034 | El agregado como unidad de consistencia | Intermedio | 3 | 3 |
| 035 | Modelado documental: incrustar o referenciar | Intermedio | 4 | 3 |
| 036 | Consultas, índices y agregación sobre documentos | Intermedio | 3 | 3 |
| 037 | Clave-valor, caché y expiración: qué se pierde exactamente | Intermedio | 3 | 3 |
El agregado como unidad de lectura, escritura y consistencia, y la consecuencia que ordena toda la parte: en los motores documentales la frontera transaccional coincide con el agregado. Diseñar el agregado es, por tanto, decidir dónde termina la garantía del motor y empieza el trabajo de la aplicación.
agregado frontera transaccional entidad actividad
La decisión central del modelado documental —incrustar o referenciar— con sus dos criterios: si el dato se lee siempre junto y si puede crecer sin techo. Presenta el crecimiento no acotado como el fallo característico del modelo documental y los patrones de extensión que lo evitan.
incrustación referencia crecimiento no acotado patrón de extensión
Cómo se consulta e indexa lo que se modeló en la clase anterior: índices compuestos y multiclave, cobertura, y la canalización de agregación con la regla que más rendimiento decide —poner `$match` al principio para que el índice sirva, no después.
índice compuesto canalización de agregación índice multiclave cobertura
Qué se gana y qué se pierde exactamente al poner una caché delante. Trata el TTL como política de retención, la invalidación como el problema difícil que es, la estampida como fallo predecible, y la durabilidad configurable de Redis como una decisión de negocio que hay que escribir en segundos de pérdida aceptable.
TTL invalidación estampida de caché durabilidad configurable
Cada uno de estos es una creencia habitual y su corrección.
Los 16 términos que esta parte introduce. Todos están también en el glosario del programa con sus términos relacionados.
| Término | Qué significa | Se trabaja en |
|---|---|---|
| actividad | Hecho que ocurre en un instante y relaciona entidades: un pedido, un pago, una inscripción. Su volumen crece sin límite con el tiempo, lo que la convierte en la candidata natural a tabla de hechos o a flujo de eventos, y en la mala candidata a incrustarse dentro de una entidad. | 034 |
| agregado | Conjunto de datos que se trata como una unidad para leer, escribir y garantizar consistencia: un pedido con sus líneas. Sadalage y Fowler lo toman del diseño dirigido por el dominio y lo convierten en el criterio que separa a los motores NoSQL del relacional. (En la clase 027 la palabra se usa en su otro sentido: el resultado de una función de agregación como `SUM` o `COUNT`.) | 034 |
| canalización de agregación | Secuencia de etapas (`$match`, `$group`, `$sort`, `$lookup`) por las que pasan los documentos en MongoDB. El orden importa de verdad: poner `$match` al principio permite usar el índice, ponerlo después obliga a recorrer la colección entera. | 036 |
| cobertura | Que el índice contenga todas las columnas que la consulta necesita, de modo que el motor responda sin tocar la tabla. Es la diferencia entre una lectura y dos, y suele ser la optimización con mejor relación entre esfuerzo y resultado. | 036 |
| crecimiento no acotado | Un arreglo incrustado que puede crecer indefinidamente —los comentarios de una publicación viral, el histórico de un sensor—. Acaba chocando con el límite de tamaño del documento y degrada cada lectura, aunque solo se quería un campo. Es la señal de que ese arreglo debía ser una colección aparte. | 035 |
| durabilidad configurable | Poder elegir cuánta pérdida se acepta a cambio de latencia: Redis ofrece desde ninguna persistencia hasta `appendfsync always`, pasando por instantáneas periódicas. La decisión es de negocio, y hay que escribirla: «se pueden perder hasta N segundos de escrituras». | 037 |
| entidad | Cosa del dominio con identidad propia que persiste a lo largo del tiempo: un cliente, un producto, una cuenta. Se distingue de la actividad en que existe aunque no pase nada, y suele ser la raíz de un agregado. | 034 |
| estampida de caché | Cuando una clave muy consultada expira y miles de peticiones van a la vez a la base de datos a recalcularla. Se mitiga con expiraciones escalonadas, recálculo anticipado o un cerrojo que deja pasar a uno solo. | 037 |
| frontera transaccional | El límite dentro del cual el motor garantiza atomicidad y aislamiento. En los motores de agregado coincide con el agregado: una escritura sobre un documento es atómica, dos sobre documentos distintos ya no. Diseñar el agregado es, por tanto, diseñar dónde termina la garantía. | 034 |
| incrustación | Guardar los datos relacionados dentro del propio documento. Una sola lectura devuelve todo y la escritura es atómica, a cambio de duplicar el dato si otro documento también lo necesita y de arriesgar un documento que crece sin techo. | 035 |
| invalidación | Borrar o marcar como obsoleta una entrada de caché cuando cambia el dato de origen. Es el problema difícil de las cachés porque exige que quien escribe en la base sepa qué claves quedaron mentirosas —y normalmente no lo sabe. | 037 |
| patrón de extensión | Familia de soluciones para el crecimiento no acotado: partir el arreglo en cubos de tamaño fijo, guardar solo los N últimos elementos incrustados y el resto en otra colección, o separar los campos grandes en un documento satélite. | 035 |
| referencia | Guardar el identificador del documento relacionado en lugar de su contenido. Evita la duplicación y el crecimiento no acotado, a cambio de una segunda consulta —o de un `$lookup`— que el motor no optimiza como un `JOIN` relacional. | 035 |
| TTL | Tiempo de vida tras el cual la clave expira y desaparece. Es la política de retención más simple que existe y la que convierte a una caché en caché: sin TTL, un almacén clave-valor es solo una base de datos en memoria que crece hasta llenarla. | 037 |
| índice compuesto | Índice sobre varias claves en un orden concreto. Sirve para las consultas que filtran por un prefijo de esa lista, no para cualquier subconjunto: `(a, b, c)` acelera filtrar por `a` o por `a, b`, pero no por `b` a secas. | 036 |
| índice multiclave | Índice sobre un campo que contiene un arreglo: MongoDB crea una entrada por elemento. Permite buscar dentro del arreglo, y explica por qué el índice de una colección puede tener muchas más entradas que documentos. | 036 |
9 obras distintas sostienen lo que se afirma en estas 4 clases.