Hispanopedia Wiki
Articulo de referencia

Teorema CAP

En la teoría de bases de datos , el teorema CAP , también llamado teorema de Brewer en honor al científico informático Eric Brewer , establece que cualquier almacén de datos dis...

Hispanopedia WikiContenido en espanolLectura gratuita

En la teoría de bases de datos , el teorema CAP , también llamado teorema de Brewer en honor al científico informático Eric Brewer , establece que cualquier almacén de datos distribuido puede proporcionar como máximo dos de las siguientes tres garantías: [ 1 ] [ 2 ] [ 3 ]

Consistencia
Cada lectura recibe la escritura más reciente o un error. La consistencia implica que todos los clientes vean los mismos datos al mismo tiempo, independientemente del nodo al que se conecten. Para que esto ocurra, cada vez que se escriben datos en un nodo, estos deben reenviarse o replicarse instantáneamente a todos los demás nodos del sistema antes de que la escritura se considere "exitosa" [ 4 ] . La consistencia, tal como se define en el teorema CAP, es bastante diferente de la consistencia garantizada en las transacciones de bases de datos ACID [ 5 ] .
Disponibilidad
Cada solicitud recibida por un nodo que no falla en el sistema debe generar una respuesta, sin garantía de que contenga la versión más reciente de los datos [ 6 ] . Esta es la definición de disponibilidad en el teorema CAP, según lo definido por Gilbert y Lynch [ 1 ] . La disponibilidad, tal como se define en el teorema CAP, es diferente de la alta disponibilidad en la arquitectura de software [ 7 ] .
Tolerancia de partición
El sistema continúa funcionando a pesar de que la red entre nodos pierde (o retrasa) una cantidad arbitraria de mensajes. [ 8 ]

Cuando se produce un fallo en la partición de red , hay que decidir si se realiza una de las siguientes acciones:

  • cancelar la operación y, por lo tanto, disminuir la disponibilidad, pero asegurar la consistencia
  • Proceder con la operación y, por lo tanto, proporcionar disponibilidad, pero con el riesgo de inconsistencia. Esto no significa necesariamente que el sistema tenga una alta disponibilidad para sus usuarios. [ 7 ]
Teorema CAP Diagrama de Euler

Por lo tanto, si existe una partición de red, hay que elegir entre consistencia o disponibilidad.

Durante los períodos de funcionamiento normal, un almacén de datos cubre los tres. [ 9 ]

Explicación

Ningún sistema distribuido está a salvo de fallos de red, por lo que, en general, debe tolerarse la partición de la red. [ 10 ] [ 11 ] En presencia de una partición, quedan dos opciones: consistencia o disponibilidad . Al elegir la consistencia sobre la disponibilidad, el sistema devolverá un error o un tiempo de espera si no se puede garantizar que cierta información esté actualizada debido a la partición de la red. Al elegir la disponibilidad sobre la consistencia, el sistema siempre procesará la consulta e intentará devolver la versión más reciente disponible de la información, incluso si no puede garantizar que esté actualizada debido a la partición de la red. [ 12 ]

En ausencia de una partición de red, se pueden satisfacer tanto la disponibilidad como la consistencia. [ 13 ]

Los sistemas de bases de datos diseñados con garantías ACID tradicionales en mente, como los RDBMS, eligen la consistencia sobre la disponibilidad, mientras que los sistemas diseñados en torno a la filosofía BASE , común en el movimiento NoSQL , por ejemplo, eligen la disponibilidad sobre la consistencia, [ 14 ] pero MongoDB y Redis resuelven particiones de red manteniendo la consistencia a costa de la disponibilidad. [ 4 ] [ 9 ] CouchDB , Cassandra y ScyllaDB son ejemplos de bases de datos AP. [ 9 ] No hay bases de datos NoSQL que se puedan clasificar como CA. [ 9 ] La mayoría de las bases de datos distribuidas modernas ofrecen opciones de configuración tanto para la consistencia como para la disponibilidad. [ 6 ]

Algunos servicios en la nube optan por una consistencia fuerte, pero utilizan redes de fibra óptica privadas a nivel mundial y sincronización de reloj GPS para minimizar la frecuencia de particiones de red . Por último, las arquitecturas consistentes sin recursos compartidos pueden utilizar técnicas como el desdoblamiento geográfico para mantener la disponibilidad de los datos propiedad del nodo consultado, pero sin que estén disponibles para solicitudes arbitrarias durante una partición de red .

Historia

Según el científico informático Eric Brewer de la Universidad de California, Berkeley , el teorema apareció por primera vez en otoño de 1998. [ 14 ] Se publicó como el principio CAP en 1999 [ 15 ] y Brewer lo presentó como una conjetura en el Simposio de 2000 sobre Principios de Computación Distribuida (PODC). [ 16 ] En 2002, Seth Gilbert y Nancy Lynch del MIT publicaron una demostración formal de la conjetura de Brewer, convirtiéndola en un teorema . [ 1 ]

En 2012, Brewer aclaró algunas de sus posturas, incluyendo por qué el concepto frecuentemente utilizado de "dos de tres" puede resultar algo engañoso, ya que los diseñadores de sistemas solo necesitan sacrificar la consistencia o la disponibilidad en presencia de particiones; existen técnicas de gestión y recuperación de particiones. Brewer también señaló la diferencia en la definición de consistencia utilizada en el teorema CAP en relación con la definición utilizada en ACID . [ 14 ] [ 17 ]

Birman y Friedman publicaron en 1996 un teorema similar que establecía la relación de compromiso entre consistencia y disponibilidad en sistemas distribuidos. [ 18 ] El resultado de Birman y Friedman había restringido este límite inferior a operaciones no conmutativas.

El teorema PACELC , introducido en 2010, [ 13 ] se basa en CAP al afirmar que, incluso en ausencia de particionamiento, existe otra compensación entre latencia y consistencia. PACELC significa que, si se produce una partición (P), la compensación se establece entre disponibilidad (A) y consistencia (C); de lo contrario (E), la compensación se establece entre latencia (L) y consistencia (C). 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 particionarse 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 utilizar el teorema PACELC , que es más completo y considera compensaciones como la latencia y la consistencia incluso en ausencia de particiones de red. [ 19 ]

Véase también

Referencias

  1. 1 2 3 Gilbert, Seth; Lynch, Nancy (2002). "La conjetura de Brewer y la viabilidad de servicios web consistentes, disponibles y tolerantes a particiones". ACM SIGACT News . 33 (2). Association for Computing Machinery (ACM): 51– 59. doi : 10.1145/564585.564601 . ISSN 0163-5700 . S2CID 15892169 .  
  2. ↑ "Teorema CAP de Brewer" . julianbrowne.com . 11 de enero de 2009.
  3. ↑ Eric A. Brewer (2000). Hacia sistemas distribuidos robustos (PDF) . Principios de computación distribuida (PODC).
  4. 1 2 "¿Qué es el teorema CAP? | IBM" . www.ibm.com . 2022-12-20 . Consultado el 2025-12-05 .
  5. ↑ Liochon, Nicolas. "La confusa terminología de CAP y ACID" . This long run . Consultado el 1 de febrero de 2019 .
  6. 1 2 "Hola Entrevista | Diseño de sistemas en una prisa" . Hola Entrevista . Recuperado el 07-12-2025 .
  7. 1 2 Fowler, Adam (2015). NoSQL para principiantes . Para principiantes. ISBN 978-8126554904.
  8. ↑ Gilbert, Seth; Lynch, Nancy (2012). "Perspectivas sobre el teorema CAP" . Computer . 45 (2): 30–36 . doi : 10.1109/mc.2011.389 . hdl : 1721.1/79112 . ISSN 0018-9162 . 
  9. 1 2 3 4 alastairn. "Teorema CAP" . ScyllaDB . Recuperado el 06-12-2025 .
  10. ↑ Kleppmann, Martin (18 de septiembre de 2015). Una crítica del teorema CAP (Informe). Apollo - Repositorio de la Universidad de Cambridge. arXiv : 1509.05393 . Bibcode : 2015arXiv150905393K . doi : 10.17863/CAM.13083 . S2CID 1991487. Consultado el 24 de noviembre de 2019 . 
  11. ↑ Martin, Kleppmann. "Por favor, dejen de llamar a las bases de datos CP o AP" . Blog de Martin Kleppmann . Consultado el 24 de noviembre de 2019 .
  12. ↑ "Teorema CAP: Disponibilidad y más allá: Comprender y mejorar la resiliencia de los sistemas distribuidos en AWS" . docs.aws.amazon.com . Consultado el 7 de diciembre de 2025 .
  13. 1 2 Abadi, Daniel (23-04-2010). "Reflexiones sobre DBMS: Problemas con CAP y el poco conocido sistema NoSQL de Yahoo" . Reflexiones sobre DBMS . Recuperado el 23-01-2018 .
  14. 1 2 3 Brewer, Eric (2012). "CAP doce años después: Cómo han cambiado las "reglas"" . Computer . 45 (2). Instituto de Ingenieros Eléctricos y Electrónicos (IEEE): 23–29 . doi : 10.1109/mc.2012.37 . ISSN 0018-9162 . S2CID 890105 .  
  15. ↑ Armando Fox; Eric Brewer (1999). Harvest, Yield and Scalable Tolerant Systems . Proc. 7th Workshop Hot Topics in Operating Systems (HotOS 99). IEEE CS. pp. 174– 178. doi : 10.1109/HOTOS.1999.798396 . 
  16. ↑ Eric Brewer. "Hacia sistemas distribuidos robustos" (PDF) .
  17. ↑ Carpenter, Jeff; Hewitt, Eben (julio de 2016). Cassandra: La guía definitiva (2.ª ed.). O'Reilly Media. ISBN  9781491933657En febrero de 2012 , Eric Brewer ofreció una perspectiva actualizada sobre su teorema CAP  . Brewer ahora describe el axioma "2 de 3" como algo engañoso. Señala que los diseñadores solo necesitan sacrificar consistencia o disponibilidad en presencia de particiones, y que los avances en las técnicas de recuperación de particiones han permitido a los diseñadores alcanzar altos niveles tanto de consistencia como de disponibilidad.
  18. ↑ Ken Birman; Roy Friedman (abril de 1996). "Intercambiar consistencia por disponibilidad en sistemas distribuidos" . hdl : 1813/7235 .
  19. ↑ Diseño de aplicaciones con uso intensivo de datos: Las grandes ideas detrás de sistemas fiables, escalables y mantenibles . O'Reilly Media. ISBN 978-1449373320.