Principio de diseño de PACELC

En la teoría de bases de datos , el principio de diseño PACELC es una extensión del teorema CAP . Este principio establece que, en caso de particionamiento de red (P) en un sistema informático distribuido, se debe elegir entre disponibilidad (A) y consistencia (C) (según el teorema CAP), pero en caso contrario (E), incluso cuando el sistema funciona normalmente sin particiones, se debe elegir entre latencia (L) y pérdida de consistencia (C).

El teorema CAP se puede formular como "PAC", el teorema de imposibilidad que establece que ningún almacén de datos distribuido puede ser consistente y estar disponible simultáneamente en ejecuciones que contienen particiones. Esto se puede demostrar examinando la latencia: si un sistema garantiza la consistencia, las latencias de las operaciones aumentan con los retrasos de los mensajes y, por lo tanto, las operaciones no pueden terminar eventualmente si la red está particionada, es decir, el sistema no puede garantizar la disponibilidad. ^{[ 1 ]}

En ausencia de particiones, se pueden satisfacer tanto la consistencia como la disponibilidad. ^{[ 2 ]} Por lo tanto, PACELC va más allá y examina cómo el sistema replica los datos. Específicamente, en ausencia de particiones, existe una compensación adicional (ELC) entre latencia y consistencia. ^{[ 3 ]} Si el almacenamiento es atómicamente consistente, entonces la suma del retardo de lectura y escritura es al menos el retardo del mensaje. En la práctica, la mayoría de los sistemas se basan en acuses de recibo explícitos en lugar de retardos temporizados para garantizar la entrega, lo que requiere un viaje de ida y vuelta completo de la red y, por lo tanto, retardo del mensaje tanto en lecturas como en escrituras para garantizar la consistencia. ^{[ 1 ]} En sistemas de baja latencia, por el contrario, la consistencia se relaja para reducir la latencia. ^{[ 2 ]}

En el espacio PACELC existen cuatro configuraciones o compensaciones:

• PA/EL: priorizar la disponibilidad y la baja latencia sobre la consistencia.
• PA/EC: cuando haya una partición, elija disponibilidad; de lo contrario, elija consistencia.
• PC/EL: cuando haya una partición, elija consistencia; de lo contrario, elija menor latencia.
• PC/EC: elige la coherencia en todo momento.

PC/EC y PA/EL proporcionan modelos cognitivos naturales para un desarrollador de aplicaciones. Un sistema PC/EC ofrece una garantía firme de consistencia atómica, como en ACID, mientras que PA/EL proporciona alta disponibilidad y baja latencia con un modelo de consistencia más complejo. En contraste, los sistemas PA/EC y PC/EL solo ofrecen garantías condicionales de consistencia. El desarrollador aún debe escribir código para manejar los casos en los que no se cumple la garantía. Los sistemas PA/EC son poco comunes fuera de la industria de la cuadrícula de datos en memoria, donde los sistemas están localizados en regiones geográficas y la compensación entre latencia y consistencia no es significativa. ^{[ 4 ]} PC/EL es aún más difícil de entender. PC no indica que el sistema sea completamente consistente; más bien indica que el sistema no reduce la consistencia más allá del nivel de consistencia base cuando ocurre una partición de red, sino que reduce la disponibilidad. ^{[ 3 ]}

Algunos expertos, como Marc Brooker, sostienen que el teorema CAP es particularmente relevante en entornos con conectividad intermitente, como los relacionados con el Internet de las Cosas (IoT) y las aplicaciones móviles . En estos contextos, los dispositivos pueden quedar incompletos debido a condiciones físicas adversas, como cortes de energía o al entrar en espacios confinados como ascensores. Para sistemas distribuidos , como las aplicaciones en la nube , es más apropiado usar PACELC, que es más completo y considera compensaciones como la latencia y la consistencia incluso en ausencia de particiones de red. ^{[ 5 ]}

El principio de diseño PACELC fue descrito por primera vez por Daniel Abadi de la Universidad de Yale en 2010 en una entrada de blog, ^{[ 2 ]} que luego aclaró en un artículo en 2012. ^{[ 3 ]} El propósito de PACELC es abordar su tesis de que "Ignorar la compensación entre consistencia y latencia de los sistemas replicados es un gran error [en CAP], ya que está presente en todo momento durante el funcionamiento del sistema, mientras que CAP solo es relevante en el caso posiblemente raro de una partición de red". PACELC fue demostrado formalmente en 2018 en un artículo de SIGACT News. ^{[ 1 ]}

Las calificaciones PACELC de la base de datos original provienen de ^{[ 6 ]} . Las actualizaciones posteriores fueron aportadas por la comunidad de Wikipedia.

• Las versiones predeterminadas de las primeras bases de datos (internas) de Amazon, Dynamo , Cassandra , Riak y Cosmos DB , son sistemas PA/EL: si se produce una partición, sacrifican la consistencia en aras de la disponibilidad, y en condiciones normales de funcionamiento, sacrifican la consistencia en aras de una menor latencia.
• Los sistemas totalmente ACID, como VoltDB /H-Store, Megastore, MySQL Cluster y PostgreSQL, son PC/EC: se niegan a renunciar a la consistencia y asumen los costos de disponibilidad y latencia para lograrla. Bigtable y sistemas relacionados, como HBase, también son PC/EC.
• Amazon DynamoDB (lanzado en enero de 2012) es bastante diferente del Dynamo inicial (interno de Amazon) que se consideró para el documento PACELC. ^{[ 6 ]} DynamoDB sigue un modelo de líder fuerte, donde cada escritura se serializa estrictamente (y las escrituras condicionales no conllevan penalización) y admite la consistencia de lectura después de la escritura. Esta garantía no se aplica a las "Tablas globales ^{[ 7 ]} " entre regiones. Los SDK de DynamoDB utilizan lecturas con consistencia eventual por defecto (disponibilidad y rendimiento mejorados), pero cuando se solicita una lectura consistente, el servicio devolverá una vista actual del elemento o un error.
• Couchbase ofrece diversas opciones de consistencia y disponibilidad durante una partición, así como opciones de latencia y consistencia sin partición. A diferencia de la mayoría de las bases de datos, Couchbase no tiene un único conjunto de API ni escala ni replica todos los servicios de datos de forma homogénea. Para las escrituras, Couchbase prioriza la consistencia sobre la disponibilidad, lo que la convierte formalmente en CP, pero en las lecturas existe una mayor variabilidad controlada por el usuario, dependiendo de la replicación de índices, el nivel de consistencia deseado y el tipo de acceso (búsqueda de un solo documento frente a escaneo de rango frente a búsqueda de texto completo, etc.). Además, existe una variabilidad adicional dependiendo de la replicación entre centros de datos (XDCR), que toma varios clústeres CP y los conecta con replicación asíncrona, y Couchbase Lite, que es una base de datos integrada y crea una topología distribuida multi-maestro completa (con seguimiento de revisiones).
• Cosmos DB admite cinco niveles de consistencia configurables que permiten establecer compromisos entre C/A durante P y L/C durante E. Cosmos DB nunca viola el nivel de consistencia especificado, por lo que formalmente es CP.
• MongoDB puede clasificarse como un sistema PA/EC. En el caso básico, el sistema garantiza que las lecturas y escrituras sean consistentes.
• PNUTS es un sistema PC/EL.
• Hazelcast IMDG y, de hecho, la mayoría de las cuadrículas de datos en memoria son una implementación de un sistema PA/EC; Hazelcast se puede configurar para ser EL en lugar de EC. ^{[ 8 ]} Las primitivas de concurrencia (Lock, AtomicReference, CountDownLatch, etc.) pueden ser PC/EC o PA/EC. ^{[ 9 ]}
• FaunaDB implementa Calvin, un protocolo de transacciones creado por el Dr. Daniel Abadi, autor ^{[ 3 ]} del artículo original de PACELC, y ofrece a los usuarios controles ajustables para la compensación LC. Es PC/EC para transacciones estrictamente serializables y EL para lecturas serializables.

• Teorema CAP
• Modelo de consistencia
• Falacias de la computación distribuida
• Arquitectura Lambda (solución)
• Paxos (informática)
• Triángulo de gestión de proyectos
• Balsa (algoritmo)
• Trilema

• "Compromisos de consistencia en el diseño de sistemas de bases de datos distribuidas modernas", por Daniel J. Abadi, Universidad de Yale. Artículo original que formalizó PACELC.
• "Problemas con CAP y el sistema NoSQL poco conocido de Yahoo", por Daniel J. Abadi, Universidad de Yale . Entrada de blog original que describió por primera vez PACELC.
• "Demostración de PACELC", por Wojciech Golab, Universidad de Waterloo. Demostración formal del teorema PACELC.