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 solo dos de las tres garantías siguientes : [1] [2] [3]

Consistencia
Cada lectura recibe la escritura más reciente o un error.
Disponibilidad
Toda solicitud recibida por un nodo que no falla en el sistema debe generar una respuesta. Esta es la definición de disponibilidad en el teorema CAP según lo definen Gilbert y Lynch. [1] Tenga en cuenta que la disponibilidad según se define en el teorema CAP es diferente de la alta disponibilidad en la arquitectura de software. [4]
Tolerancia de partición
El sistema continúa funcionando a pesar de que la red descarta (o retrasa) un número arbitrario de mensajes entre nodos.

Cuando ocurre una falla en la partición de red , se debe decidir si se debe realizar una de las siguientes acciones:

  • cancelar la operación y así disminuir la disponibilidad pero asegurar la consistencia
  • Proseguir con la operación y, por lo tanto, garantizar la disponibilidad, pero con el riesgo de inconsistencia. Cabe señalar que esto no significa necesariamente que el sistema esté altamente disponible para sus usuarios. [5]
Diagrama de Euler del teorema CAP

Por lo tanto, si hay una partición de red, hay que elegir entre consistencia o disponibilidad. Hay que tener en cuenta que la consistencia definida en el teorema CAP es bastante diferente de la consistencia garantizada en las transacciones de bases de datos ACID . [6]

Explicación

Ningún sistema distribuido está a salvo de fallos de red, por lo que generalmente se debe tolerar la partición de la red. [7] [8] En presencia de una partición, uno queda entonces con 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 una información particular 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.

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

Los sistemas de bases de datos diseñados con garantías ACID tradicionales en mente, como 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. [10]

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. [10] Se publicó como el principio CAP en 1999 [11] y Brewer lo presentó como una conjetura en el Simposio sobre Principios de Computación Distribuida (PODC) de 2000. [12] En 2002, Seth Gilbert y Nancy Lynch del MIT publicaron una prueba formal de la conjetura de Brewer, convirtiéndola en un teorema . [1]

En 2012, Brewer aclaró algunas de sus posiciones, incluyendo por qué el concepto de "dos de tres" que se usa a menudo puede ser algo engañoso porque los diseñadores de sistemas solo necesitan sacrificar la consistencia o la disponibilidad en presencia de particiones; existen técnicas de recuperación y administración de particiones. Brewer también señaló la diferente definición de consistencia utilizada en el teorema CAP en relación con la definición utilizada en ACID . [10] [13]

Birman y Friedman publicaron en 1996 un teorema similar que establece el equilibrio entre consistencia y disponibilidad en sistemas distribuidos. [14] El resultado de Birman y Friedman restringió este límite inferior a operaciones sin desplazamientos.

El teorema PACELC , introducido en 2010, [9] 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 es entre disponibilidad (A) y consistencia (C); de lo contrario (E), la compensación es entre latencia (L) y consistencia (C).

Véase también

Referencias

  1. ^ abc Gilbert, Seth; Lynch, Nancy (2002). "La conjetura de Brewer y la viabilidad de servicios web consistentes, disponibles y tolerantes a particiones". Noticias de ACM SIGACT . 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 . 2009-01-11.
  3. ^ "Teorema CAP de Brewers sobre sistemas distribuidos". royans.net . 14 de febrero de 2010.
  4. ^ Fowler, Adam (2015). NoSQL para principiantes . Para principiantes. ISBN 978-8126554904.
  5. ^ Fowler, Adam (2015). NoSQL para principiantes . Para principiantes. ISBN 978-8126554904.
  6. ^ Liochon, Nicolas. "La confusa redacción de CAP y ACID". Esta larga carrera . Consultado el 1 de febrero de 2019 .
  7. ^ 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 .
  8. ^ 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 .
  9. ^ ab Abadi, Daniel (23 de abril de 2010). "Reflexiones sobre DBMS: problemas con CAP y el sistema NoSQL poco conocido de Yahoo". Reflexiones sobre DBMS . Consultado el 23 de enero de 2018 .
  10. ^ abc Brewer, Eric (2012). "CAP doce años después: cómo han cambiado las "reglas". Informática . 45 (2). Instituto de Ingenieros Eléctricos y Electrónicos (IEEE): 23–29. doi :10.1109/mc.2012.37. ISSN  0018-9162. S2CID  890105.
  11. ^ Armando Fox; Eric Brewer (1999). Cosecha, rendimiento y sistemas tolerantes escalables . Proc. 7.º taller Temas de actualidad en sistemas operativos (HotOS 99). IEEE CS. págs. 174–178. doi :10.1109/HOTOS.1999.798396.
  12. ^ Eric Brewer. "Hacia sistemas distribuidos robustos" (PDF) .
  13. ^ Carpenter, Jeff; Hewitt, Eben (julio de 2016). Cassandra: The Definitive Guide (2.ª edición). O'Reilly Media. ISBN 9781491933657En febrero de 2012, Eric Brewer proporcionó 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 la consistencia o la disponibilidad en presencia de particiones, y que los avances en las técnicas de recuperación de particiones han hecho posible que los diseñadores alcancen altos niveles tanto de consistencia como de disponibilidad. 
  14. ^ Ken Birman; Roy Friedman (abril de 1996). "Comercio de consistencia por disponibilidad en sistemas distribuidos". hdl :1813/7235.


Obtenido de "https://es.wikipedia.org/w/index.php?title=Teorema_CAP&oldid=1246483713"