← HubBDII Estudio
Bigtable
BDII Estudio · Distributed Storage for Structured Data
Módulos 0/9

Un mapa gigante, ordenado y versionado

Esa es Bigtable en una frase: un mapa multidimensional ordenado, disperso, distribuido y persistente que escala a petabytes en miles de servidores, y que da al cliente control total sobre localidad, formato y si sirve desde memoria o disco.

Esta app te lleva desde cero (¿qué es una tablet?) hasta los trade-offs finos que siempre caen en el quiz — Bloom vs disco, compresión vs CPU, un solo commit log vs recovery complejo, in-memory vs RAM — con citas del paper, explicación didáctica, animaciones y casos.

No es relacional

Bigtable no soporta modelo relacional completo. Da un modelo simple: (fila, columna, timestamp) → string sin interpretar, y el cliente decide el layout.

La idea central en 1 línea

Todo es un tablet (rango de filas de ~100-200MB). Localízalo en 3 niveles, escríbelo en log + memtable, léelo fusionando SSTables.

PBs
escala: petabytes + miles de servers
2³⁴
tablets direccionables (3 niveles)
388
clusters, ~24.500 tablet servers (2006)
10×
compresión Webtable (vs 3-4× gzip)

¿Cómo usar esta app?

Tres pasos, en orden. Cada uno prepara el siguiente.

Ruta de aprendizaje

Aprende Bigtable desde cero

Sigue los módulos en orden. Los términos del glosario aparecen con subrayado punteado: hover o tap abre la burbuja. Los Trade-off son los que más caen en el quiz.

Laboratorio visual

Animaciones interactivas

Pulsa los botones y observa el sistema en movimiento. Cada animación muestra su estado (play / pausa / listo), barra de progreso y narrador paso a paso.

1 · Webtable: fila, familias y versiones

La fila com.cnn.www: familia contents: con 3 versiones y familia anchor: con 2 columnas.

Webtable · Pulsa un botón.

2 · Localización de tablets en 3 niveles

Caché vacía = 3 round-trips (incl. Chubby). Caché stale = hasta 6. Con prefetch se amortiza.

Localización · Pulsa "Siguiente paso".

3 · Tablet serving + compactions

Write → commit log → memtable → minor → merging → major. Read = vista fusionada.

Serving · Pulsa "Siguiente paso".

4 · Un solo commit log: el trade-off de recovery

Un log por servidor = group commit eficiente, pero recovery exige ordenar por (tabla, fila, seq).

Recovery · Pulsa reproducir.

5 · Path de lectura: Bloom + cachés + bloques

Bloom evita seeks a SSTables que no tienen la fila; Scan Cache vs Block Cache; bloque de 64KB vs 8KB. Prueba apagar Bloom o cambiar el bloque y mira cómo cambian los seeks visibles.

Seeks visibles: 1 · 64KB (64×)
Lectura · Pulsa "Animar lectura".
Comprueba tu aprendizaje

Quiz y casos

Las marcadas con trade-off preguntan qué se gana y qué se pierde. Usa Estudio (feedback ya), Examen (nota al final) o Solo falladas.

0 / 0 correctas
Vista
0%

Casos prácticos

Intenta resolver antes de ver la solución. Pistas y soluciones se guardan en este dispositivo.

Referencia rápida

Glosario bilingüe

Misma fuente que las burbujas del Aprende. Escribe para filtrar (ej: bloom, compaction, Boxwood).

Repaso de último minuto

Cheatsheet

Todo lo esencial en una página. Ideal para imprimir o guardar PDF antes del quiz.