CAP 정리

CAP theorem

이론 컴퓨터 과학에서, 컴퓨터 과학자인 에릭 브루어의 이름을 따서 Brewer's 정리로도 명명된 CAP 정리는 모든 분산 데이터 저장소가 다음 세 가지 [1][2][3]중 두 가지만 제공할 수 있다고 명시합니다.

일관성.
모든 읽기는 최신 쓰기 또는 오류를 수신합니다.
유용성
모든 요청은 최신 쓰기가 포함되어 있다는 보증 없이 (비오류) 응답을 받습니다.
파티션 허용 오차
노드간의 네트워크에 의해서 임의의 수의 메세지가 드롭(또는 지연) 되어도, 시스템은 계속 동작합니다.

네트워크 파티션에 장애가 발생했을 때 다음 중 하나를 선택해야 합니다.

  • 조작을 취소하여 가용성을 낮추지만 일관성을 확보하거나
  • 작업을 계속 진행하여 가용성을 제공하지만 불일치의 위험이 있습니다.

따라서 네트워크 파티션이 있는 경우 일관성과 가용성 중 하나를 선택해야 합니다.CAP 정리에 정의된 일관성은 ACID 데이터베이스 트랜잭션에서 [4]보장되는 일관성과는 상당히 다릅니다.

Eric Brewer는 시스템 설계자가 파티션 존재 시 일관성이나 가용성을 희생하기만 하면 되기 때문에 자주 사용되는 "3개 중 2개" 개념은 다소 오해의 소지가 있다고 주장하지만 대부분의 시스템 파티션은 드물다고 [5][6]합니다.

설명.

네트워크 장애로부터 안전한 분산 시스템은 없기 때문에 일반적으로 네트워크 파티셔닝을 [7][8]허용할 필요가 있습니다.파티션이 있는 경우 일관성 또는 가용성이라는 두 가지 옵션이 남습니다.가용성보다 일관성을 선택하면 네트워크 파티셔닝으로 인해 특정 정보가 최신임을 보증할 수 없는 경우 오류 또는 타임아웃이 반환됩니다.일관성보다 가용성을 선택하면 네트워크 파티셔닝으로 인해 최신임을 보증할 수 없는 경우에도 시스템은 항상 쿼리를 처리하고 사용 가능한 최신 버전의 정보를 반환하려고 합니다.

파티션이 없는 경우 가용성과 일관성을 모두 [9]충족할 수 있습니다.

RDBMS 등 기존의 ACID 보증을 염두에 두고 설계된 데이터베이스 시스템은 가용성보다 일관성을, 예를 들어 NoSQL 이동에서 흔히 볼 수 있는 BASE 철학을 기반으로 설계된 시스템은 [5]일관성보다 가용성을 선택합니다.

역사

캘리포니아 대학의 버클리 컴퓨터 과학자인 에릭 브루어에 따르면,[5] 이 정리는 1998년 가을에 처음 나타났다고 한다.1999년에[10] CAP 원칙으로서 발표되어 2000년에 개최된 분산 컴퓨팅의 원칙(PODC)[11] 심포지엄에서 Brewer가 추측으로 제시했습니다.2002년 MIT의 Seth Gilbert와 Nancy Lynch는 Brewer의 추측에 대한 공식 증거를 발표하여 이를 [1]정리하였다.

2012년에 Brewer는 파티션의 존재 하에서 시스템 설계자가 일관성이나 가용성을 희생하기만 하면 되기 때문에 자주 사용되는 "3개 중 2개" 개념이 다소 오해를 일으킬 수 있는 이유를 포함하여 자신의 입장을 명확히 했습니다.Brewer는 또한 [5][6]ACID에 사용된 정의와 관련하여 CAP 정리에 사용된 일관성의 다른 정의에 주목했다.

1996년 Birman과 Friedman은 분산 시스템의 일관성과 가용성 사이의 균형을 설명하는 유사한 정리를 발표했다.[12]Birman과 Friedman의 결과는 이 하한을 비출근 업무로 제한했다.

2010년에 [9]도입된 PACELC 정리는 파티셔닝이 없는 경우에도 지연과 일관성 사이에 또 다른 트레이드오프가 있음을 기술함으로써 CAP를 기반으로 합니다.PACELC는 파티션(P)이 발생한 경우 가용성(A)과 일관성(C) 사이에서 트레이드오프가 이루어지며, 그렇지 않은 경우(E)는 지연(L)과 일관성(C) 사이에서 트레이드오프가 이루어짐을 의미합니다.

블록체인 테크놀로지는 가용성과 파티션 허용성의 즉각적인 일관성을 희생합니다.특정 수의 "확인"을 요구함으로써 블록체인 컨센서스 알고리즘은 기본적으로 궁극적인 일관성으로 감소합니다.[13]

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Seth Gilbert와 Nancy Lynch, "Brewer의 추측과 일관성 있고, 사용 가능하며, 파티션에 견딜 수 있는 웹 서비스의 실현 가능성", ACM SIGACT News, Volume 33 Issue 2 (2002), 51-59. doi:10.1145/565.564601.
  2. ^ "Brewer's CAP 정리", julianbrowne.com, 2010년 3월 2일 취득
  3. ^ "분산 시스템에 대한 브루어스 CAP 정리", Royans.그물
  4. ^ Liochon, Nicolas. "The confusing CAP and ACID wording". This long run. Retrieved 1 February 2019.
  5. ^ a b c d Eric Brewer, "12년 후 CAP: '규칙이 어떻게 변했는가', 컴퓨터, 제45권, 제2호(2012), 페이지 23-29. doi:10.1109/MC.2012.37.
  6. ^ a b Carpenter, Jeff; Hewitt, Eben (July 2016). "Cassandra: The Definitive Guide, 2nd Edition [Book]". www.oreilly.com. Archived from the original on 2020-08-07. Retrieved 2020-12-21. In February 2012, Eric Brewer provided an updated perspective on his CAP theorem [..] Brewer now describes the “2 out of 3” axiom as somewhat misleading. He notes that designers only need sacrifice consistency or availability in the presence of partitions, and that advances in partition recovery techniques have made it possible for designers to achieve high levels of both consistency and availability.
  7. ^ Kleppmann, Martin (2015-09-18). "A Critique of the CAP Theorem". Apollo - University of Cambridge Repository. arXiv:1509.05393. Bibcode:2015arXiv150905393K. doi:10.17863/CAM.13083. S2CID 1991487. Retrieved 24 November 2019. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  8. ^ Martin, Kleppmann. "Please stop calling databases CP or AP". Martin Kleppmann's Blog. Retrieved 24 November 2019.
  9. ^ a b Abadi, Daniel (2010-04-23). "DBMS Musings: Problems with CAP, and Yahoo's little known NoSQL system". DBMS Musings. Retrieved 2018-01-23.
  10. ^ Armando Fox 및 Eric Brewer, "Harvest, Yield and Scalable Tolerance Systems", Proc. 제7회 워크샵 운영체제 핫토픽(HotOS 99), IEEE CS, 1999-178.doi:10.1109/HOTOS.798396.
  11. ^ Eric Brewer, "강력한 분산 시스템 지향"
  12. ^ Ken Birman과 Roy Friedman, "분산 시스템의 가용성을 위한 거래 일관성", 1996년 4월hdl: 1813/7235.
  13. ^ 바시르, 임란(2018).블록체인을 마스터하고 있습니다.영국 버밍엄: 팩트 출판사, 페이지 41.ISBN 978-1-78883-904-4.

외부 링크