Anatomía del Motor WiredTiger: B+Trees sin Locks, Hazard Pointers, Eviction Threads y Checkpoints

1. Representación Dual: Páginas en Memoria vs. Bloques Comprimidos en Disco

A diferencia de las bases relacionales que mantienen páginas de $8\text{ KB}$ idénticas en RAM y disco, WiredTiger separa el formato de memoria del formato de almacenamiento: - En Disco (On-Disk Format): Bloques serializados y comprimidos con Zstandard (zstd) o Snappy ($32\text{ KB}$ por defecto para datos y $4\text{ KB}$ para índices con prefix compression). - En Memoria (In-Memory Cache): Árboles B+ descomprimidos optimizados para recorrido por punteros de CPU, acompañados de listas Update/Modify SkipLists por registro para soportar MVCC (Multi-Version Concurrency Control) sin bloqueos de tabla ni colección.

flowchart LR
    WR["Write Op (insert/update)"] --> MEM["WiredTiger In-Memory B+Tree + Update SkipList (MVCC)"]
    WR --> WAL["Write-Ahead Log (Journal comprimido cada 100ms o WriteConcern j:true)"]
    MEM -->|"Dirty Cache > 20%"| EVICT["Eviction Server Threads"]
    MEM -->|"Cada 60s"| CHK["Snapshot Checkpoint Atómico CoW hacia Disco (zstd)"]

2. Presión de Caché y Umbrales Críticos de Evicción (Dirty Cache Stalls)

Por defecto, WiredTiger asigna el $50\%$ de (RAM - 1 GB) a su caché interna: - eviction_dirty_trigger = 5%: Los hilos de evicción en segundo plano comienzan a escribir páginas sucias a disco. - eviction_dirty_target = 20%: Si las páginas modificadas superan el $20\%$ de la caché (o la caché total supera el $80\%$), los hilos de las aplicaciones cliente son forzados a realizar evicción síncrona, disparando la latencia p99 de $2\text{ ms}$ a $> 500\text{ ms}$.

Especificación Binaria BSON: Prefijos de Longitud O(1), Tipos IEEE/Decimal128 y Optimización de Claves

1. Por Qué BSON Precede Cada Objeto y String con su Longitud en Bytes Int32

En JSON texto plano, saltar al quinto campo de un documento anidado exige escanear carácter por carácter contando llaves y comillas ($\mathcal{O}(L)$). En BSON (Binary JSON), cada documento, subdocumento y cadena incluye un encabezado int32 de 4 bytes en little-endian con su tamaño exacto en bytes, permitiendo que el motor salte subárboles enteros mediante suma de punteros sin parsear su contenido interno.

[!CAUTION]

Prohibición de Double (Tipo 0x01) para Dinero: En colecciones financieras o contables, jamás almacenes montos como Number estándar de JavaScript (IEEE 754 float64). Utiliza obligatoriamente NumberDecimal (Decimal128 - IEEE 754-2008 decimal floating point de 16 bytes) con 34 dígitos significativos exactos en base 10.

Semántica de Consistencia: ReadConcern (majority/linearizable), WriteConcern y el Oplog Idempotente

1. Prevención de Dirty Reads y Rollbacks tras Partición de Red

En un Replica Set de $N$ nodos (ej. $N=3$: 1 Primary, 2 Secondaries), escribir con w: 1 confirma el éxito tan pronto como el nodo primario escribe en memoria. Si ese primario sufre un aislamiento de red antes de replicar la operación en su local.oplog.rs, el nuevo primario electo descartará (rollback) esa escritura confirmada al cliente.

Estándar de Grado Financiero: - Escrituras: { w: "majority", j: true, wtimeout: 5000 } (confirmado en el journal de al menos $\lfloor N/2 \rfloor + 1$ nodos votantes). - Lecturas Consistentes (Read-Your-Own-Writes): readConcern: "majority" combinado con Causal Consistency Sessions (propagando operationTime y clusterTime mediante relojes lógicos híbridos HLC).

Patrones Arquitectónicos Avanzados: Bucket Pattern, Outlier Pattern, Computed y Polymorphic

1. El Anti-Patrón Fatal de los Arreglos de Crecimiento Ilimitado (Unbounded Arrays)

Embeber un arreglo eventos: [...] o comentarios: [...] que crece indefinidamente dentro de un documento padre provoca: 1. Reescritura Completa del Bloque en WiredTiger: Modificar 50 bytes dentro de un documento de $4\text{ MB}$ ensucia todo el documento y escribe $4\text{ MB}$ en el Checkpoint. 2. Multiplicación de Entradas de Índice (Multikey Index Explosion): Un índice sobre un array de $10,000$ elementos inserta $10,000$ punteros en el B-Tree por un solo documento. 3. Colisión con el Límite Físico de $16\text{ MB}$ por documento BSON.

2. El Patrón Bucket (Agrupación Acotada por Ventana o Conteo)

Agrupamos lecturas de sensores o transacciones bancarias en documentos acotados (ej. máximo count <= 200 eventos por documento o 1 hora por documento) usando $inc y $push con un filtro en el updateOne({ account_id, count: { $lt: 200 } }, ... { upsert: true }). Esto reduce el tamaño del índice B-Tree en un factor de $200\times$ y agrupa datos contiguos en una sola página física de disco.

Ingeniería de Índices Compuestos: La Regla ESR (Equality, Sort, Range), Multikey y Partial Indexes

1. Demostración de la Regla ESR en Árboles B+

El orden de las llaves dentro de un índice compuesto { a: 1, b: 1, c: 1 } determina si MongoDB puede resolver una consulta mediante un escaneo contiguo sin ordenamiento en memoria (SORT stage bloqueante de $100\text{ MB}$):

1. E — Equality (Igualdad Exacta): status: "ACTIVE" fija una sub-rama exacta del B-Tree. 2. S — Sort (Ordenamiento): created_at: -1 recorre las hojas ya ordenadas en disco en el orden exacto de salida, permitiendo terminar apenas se alcance limit(20). 3. R — Range (Rango / $gt, $in): amount: { $gte: 1000 }. Si colocas un campo de rango antes del campo de ordenamiento, las ramas del B-Tree dejan de estar globalmente ordenadas por la llave de Sort, forzando un Blocking Sort en memoria.

Aggregation Framework y Slot-Based Execution Engine (SBE): Poda Temprana, $lookup y Covered Queries

1. Reglas de Oro del Optimizador de Pipelines

1. $match + $sort en la Etapa 0: Solo la primera etapa del pipeline puede aprovechar los índices B-Tree (IXSCAN). Cualquier $project o $addFields previo sobre las llaves indexadas impide el pushdown del índice. 2. Proyección Cubierta (Covered Query): Si proyectas exclusivamente campos presentes en el índice compuesto y excluyes _id: 0, el plan de ejecución reporta totalDocsExamined: 0 y PROJECTION_COVERED, respondiendo directamente desde las hojas del índice en RAM sin tocar el almacén de documentos.

Arquitectura de Clústeres Particionados: Routers mongos, Config Server Replica Set y Balanceo de Chunks

1. Anatomía de un Clúster Sharded y el Peligro de las Consultas Scatter-Gather

flowchart TD
    APP["Aplicación Backend"] --> MONGOS["Router Stateless mongos (Caché de Tabla de Enrutamiento)"]
    MONGOS -.->|"Lee Metadatos de Rangos"| CSRS["Config Server Replica Set (CSRS - Raft)"]
    MONGOS -->|"Targeted Query (Incluye Shard Key -> 1 Shard)"| SH1["Shard 1 Replica Set (P + S + S)"]
    MONGOS -->|"Scatter-Gather (Sin Shard Key -> Todos los Shards)"| SH2["Shard 2 Replica Set (P + S + S)"]
    MONGOS -->|"Scatter-Gather"| SH3["Shard 3 Replica Set (P + S + S)"]

Si una consulta de alto volumen omite el prefijo de la shardKey en el predicado find(), mongos debe transmitir la consulta a todos los shards del clúster (Broadcast / Scatter-Gather), haciendo que la latencia global sea igual a la del shard más lento ($p99_{\text{cluster}} = \max_i p99_i$).

Diseño Matemático de la Shard Key: Cardinalidad, Distribución de Frecuencia y Trampa Monotónica

1. Por Qué _id (ObjectId) o created_at Como Ranged Shard Key Crea un Cuello de Botella del 100%

Los primeros 4 bytes de un ObjectId corresponden al timestamp Unix en segundos (crecimiento estrictamente monotónico). Si eliges un Ranged Shard Key sobre _id o timestamp, el 100% de las nuevas inserciones caerán siempre en el último chunk [MaxKey_prev, MaxKey), saturando la CPU y el IOPS de un único shard mientras los otros $N-1$ shards permanecen ociosos en escritura.

Solución de Producción (Compound Shard Key): Utilizar una llave compuesta { tenant_id: 1, created_at: 1 } o { customer_id: "hashed" }: - Distribuye uniformemente las escrituras entre todos los shards. - Preserva la localidad de lectura por inquilino (Targeted Queries) cuando se consulta por tenant_id y rango de fechas.

Change Streams sobre el Oplog: Arquitecturas CDC en Tiempo Real y Resiliencia con Resume Tokens

1. Suscripción Reactiva Determinista Sin Polling

Los Change Streams abren un cursor continuo sobre el oplog.rs filtrando únicamente eventos confirmados por mayoría (readConcern: "majority"). Cada evento emitido incluye un _id opaco llamado Resume Token (que codifica el clusterTime HLC y el UUID de colección), permitiendo que un conector Kafka/Debezium reanude exactamente desde el último evento procesado tras una caída sin perder ni duplicar mensajes.

Forense de Consultas Lenta con explain("executionStats"): Razón de Escaneo (Keys/Docs Returned)

El indicador definitivo de la eficiencia de un índice en producción es el Scan Ratio:

$\text{Document Scan Ratio} = \frac{\text{totalDocsExamined}}{\text{nReturned}}, \qquad \text{Key Scan Ratio} = \frac{\text{totalKeysExamined}}{\text{nReturned}}$

En una consulta saludable gobernada por la regla ESR, ambos ratios deben ser cercanos a $1.0$ (y en una Covered Query, totalDocsExamined = 0). Un ratio de $500:1$ indica un índice mal ordenado o un predicado no selectivo.

Laboratorio Práctico: Auditoría de Eficiencia de Índices (Scan Ratio) y Detección de Scatter-Gather

Contexto del Desafío de Arquitectura Documental

Hemos exportado las métricas del profiler de nuestro clúster particionado a la tabla de telemetría mongo_profiler_stats: - collection_ns (TEXT: namespace de la colección) - keys_examined (INTEGER: llaves del B-Tree inspeccionadas) - docs_examined (INTEGER: documentos físicos leídos de WiredTiger) - docs_returned (INTEGER: documentos efectivamente devueltos al cliente) - shards_targeted (INTEGER: cantidad de shards consultados por mongos)

Objetivo de la Consulta SQL

Evaluación de Certificación: DB-901

Valida tu dominio sobre la arquitectura interna de WiredTiger, la regla ESR de índices compuestos, patrones de modelado documental y Sharding.