Database Systems Labs
Qué se gana y qué se paga al repartir los datos: replicación, partición, los teoremas que acotan lo posible y el consenso.
5 clases · 17 horas · 20 conceptos · 17 fuentes
Esta parte se apoya en lo trabajado antes. Si vienes de fuera del programa, revisa al menos el vocabulario de:
Repartir los datos entre máquinas resuelve problemas de capacidad y de disponibilidad, y crea una clase entera de problemas nuevos que no existían en una sola máquina. Esta parte los nombra con precisión y acota lo que es teóricamente posible, para que las decisiones de arquitectura dejen de apoyarse en eslóganes.
Réplica primero, con las tres arquitecturas y la consecuencia que el usuario nota: guardar algo y al recargar no verlo. Después particionado, con los dos esquemas de reparto y el punto caliente que cada uno genera. Luego CAP dicho con precisión —la disponibilidad del teorema es mucho más estricta que el noventa y nueve coma nueve del lenguaje operativo— y PACELC, que añade lo que CAP calla: el compromiso entre latencia y consistencia existe también los días en que no hay avería. Después el espectro de modelos de consistencia con las garantías de sesión que resuelven en la práctica la mayoría de los síntomas. Y al final consenso, commit en dos fases y sagas.
Es la parte más citada del programa en fuentes primarias: Gilbert y Lynch, Brewer, Abadi, Lamport, Ongaro, DeCandia y Corbett. Merece leerse con los artículos abiertos al lado.
| # | Clase | Nivel | Horas | Fuentes |
|---|---|---|---|---|
| 053 | Réplica: líder único, multilíder y sin líder | Avanzado | 4 | 3 |
| 054 | Particionado, rebalanceo y claves calientes | Avanzado | 3 | 3 |
| 055 | CAP, PACELC y lo que realmente se elige | Avanzado | 3 | 4 |
| 056 | Modelos de consistencia y garantías de sesión | Avanzado | 3 | 5 |
| 057 | Consenso y transacciones distribuidas: Raft, 2PC y sagas | Avanzado | 4 | 4 |
Las tres arquitecturas de réplica y el compromiso que define cada una. La consecuencia visible para el usuario es el retraso de réplica: guardar algo y al recargar no verlo. Introduce las garantías de sesión que lo tapan y el quórum de los sistemas sin líder.
replicación sincrónica retraso de réplica quórum lectura de tu propia escritura
Repartir los datos entre nodos sin crear un cuello de botella. Compara hash consistente y partición por rango por lo que cada una permite y por el punto caliente que cada una genera, y explica por qué el rebalanceo se diseña fijando muchas más particiones que nodos desde el principio.
hash consistente partición por rango punto caliente reequilibrio
CAP dicho con precisión y despojado de la versión de póster. La disponibilidad del teorema es mucho más estricta que el «99,9 % de tiempo activo» del lenguaje operativo, y confundirlas es el origen de casi todas las lecturas erróneas. PACELC añade lo que CAP calla: el compromiso entre latencia y consistencia existe también los días en que no hay avería.
partición de red disponibilidad latencia frente a consistencia
El espectro entre linealizabilidad y consistencia eventual, con las garantías de sesión —leer tu propia escritura, lectura monótona— que resuelven en la práctica la mayoría de los síntomas visibles. Insiste en que la consistencia eventual solo converge si existe una regla determinista de resolución de conflictos.
linealizabilidad consistencia causal lectura monotona convergencia
Cómo se ponen de acuerdo varios nodos y cómo se confirma algo que abarca varios sistemas. Raft para el consenso y la elección de líder, el commit en dos fases con su fragilidad conocida —el coordinador que cae dejando cerrojos tomados— y la saga con compensaciones como la alternativa que renuncia al aislamiento para no bloquear.
consenso elección de líder commit en dos fases saga compensación
Cada uno de estos es una creencia habitual y su corrección.
Los 20 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 |
|---|---|---|
| commit en dos fases | Protocolo para confirmar una transacción que abarca varios sistemas: primero se pregunta a todos si pueden, después se les ordena confirmar. Es correcto y es frágil: si el coordinador cae entre las dos fases, los participantes quedan bloqueados con los cerrojos tomados. | 057 |
| compensación | Operación de negocio que deshace el efecto de otra ya confirmada: reembolsar en vez de revertir, anular una reserva en vez de borrarla. No es un `ROLLBACK`, porque el estado intermedio existió y alguien pudo verlo. | 057 |
| consenso | Que un conjunto de nodos se ponga de acuerdo en un valor y no cambie de opinión, tolerando caídas de una minoría. Es el cimiento de la elección de líder, de la pertenencia al clúster y del commit atómico; Raft y Paxos son las dos formulaciones de referencia. | 057 |
| consistencia causal | Si un evento pudo influir en otro, todos los observadores los ven en ese orden; los eventos sin relación causal pueden verse en cualquier orden. Es el punto dulce entre lo débil y lo caro: evita el efecto «respuesta antes que la pregunta» sin exigir coordinación global. | 056 |
| convergencia | Que las réplicas acaben en el mismo estado si cesan las escrituras. Es la promesa de la consistencia eventual, y solo se cumple si hay una regla determinista de resolución de conflictos, como la que dan los CRDT. | 056 |
| disponibilidad | En el enunciado formal de CAP, que toda petición a un nodo no caído reciba respuesta. Es una definición mucho más estricta que el «99,9 % de tiempo activo» del lenguaje operativo, y confundirlas es el origen de casi todas las lecturas erróneas del teorema. | 055 |
| elección de líder | Procedimiento por el que la mayoría acuerda quién ordena las escrituras durante un mandato. Que se necesite mayoría es lo que impide dos líderes simultáneos —el escenario de cerebro dividido— cuando la red se parte. | 057 |
| hash consistente | Reparto de claves sobre un anillo de posiciones de modo que añadir o quitar un nodo mueva solo una fracción de los datos, y no obligue a redistribuirlo todo como haría un `hash mod N`. Es la base del rebalanceo en Dynamo y Cassandra. | 054 |
| latencia frente a consistencia | La mitad de PACELC que CAP ignora: incluso sin particiones hay que elegir entre responder rápido desde una réplica cercana o esperar la coordinación que garantiza el dato más reciente. Es el compromiso que se paga todos los días, no solo el día de la avería. | 055 |
| lectura de tu propia escritura | Garantía de sesión que asegura que quien acaba de escribir verá su propio cambio, aunque otros aún no. Se implementa dirigiendo al líder las lecturas recientes de ese usuario, o esperando a que la réplica alcance el LSN de su escritura. | 053 |
| lectura monotona | Garantía de sesión que impide retroceder en el tiempo: si ya viste un valor, no volverás a ver uno anterior. Sin ella, alternar entre réplicas con distinto retraso hace que un dato aparezca y desaparezca al recargar. | 056 |
| linealizabilidad | La garantía más fuerte para un objeto: el sistema se comporta como si hubiera una sola copia y cada operación ocurriera en un instante entre su inicio y su fin. Es cara porque exige coordinación, y casi ninguna aplicación la necesita para todo. | 056 |
| partición de red | Situación en la que dos grupos de nodos siguen vivos pero no pueden comunicarse. No es un fallo hipotético: es lo que ocurre con un cable, un cortafuegos mal aplicado o una latencia lo bastante alta como para que los tiempos de espera venzan. | 055 |
| partición por rango | Repartir por intervalos ordenados de la clave. Permite consultas por rango eficientes, a costa de generar puntos calientes cuando las escrituras se concentran al final del rango —el caso típico de una clave temporal. | 054 |
| punto caliente | Partición que recibe una parte desproporcionada del tráfico: la celebridad con millones de seguidores, la fecha de hoy, el cliente que factura el 40 %. Ninguna cantidad de nodos ayuda mientras el reparto siga concentrando ahí. | 054 |
| quórum | Regla de los sistemas sin líder: si las escrituras van a W réplicas, las lecturas consultan R, y `W + R > N`, entonces toda lectura toca al menos una réplica con el último valor. Permite ajustar el compromiso entre latencia y frescura por operación. | 053 |
| reequilibrio | Mover particiones entre nodos al cambiar la capacidad del clúster. La práctica recomendada es fijar de antemano muchas más particiones que nodos y mover particiones enteras, en lugar de recalcular la asignación de cada clave. | 054 |
| replicación sincrónica | El líder no confirma la escritura hasta que al menos una réplica la ha recibido. Garantiza que no se pierda al caer el líder, a cambio de que la latencia del cliente incluya la de la réplica más lenta y de que una réplica caída pueda detener las escrituras. | 053 |
| retraso de réplica | La distancia temporal entre lo que ya está en el líder y lo que la réplica ha aplicado. Con replicación asíncrona es inevitable, y es la causa directa de que un usuario guarde algo y al recargar no lo vea. | 053 |
| saga | Secuencia de transacciones locales, cada una con su compensación, que sustituye a una transacción distribuida. Renuncia al aislamiento —los estados intermedios se ven— a cambio de no bloquear recursos entre servicios. | 057 |
17 obras distintas sostienen lo que se afirma en estas 5 clases.