궁극적인 일관성

Eventual consistency

최종 일관성이란 분산 컴퓨팅에서 사용되는 일관성 모델로, 고가용성을 실현하기 위해 특정 데이터 항목에 대한 새로운 업데이트가 이루어지지 않으면 해당 항목에 대한 모든 액세스가 마지막으로 업데이트된 [1]값을 반환한다는 것을 비공식적으로 보증합니다.최적의 복제라고도 [2]불리는 궁극적인 일관성은 분산형 시스템에 널리 도입되며 초기 모바일 컴퓨팅 [3]프로젝트에서 비롯되었습니다.최종적인 일관성을 달성한 시스템은 종종 컨버전스 또는 레플리카 [4]컨버전스를 달성했다고 합니다.최종적인 일관성은 취약한 보증입니다. 선형화 가능성과 같은 대부분의 강력한 모델은 결국 일관성이 있습니다.

종래의 ACID(원자성, 일관성, 격리, 내구성)[5][6]와는 대조적으로, 최종 일관성 서비스는 종종 BASE 의미론(기본적으로 이용 가능한, 부드러운 상태, 궁극적인 일관성)을 제공하는 것으로 분류된다.화학에서 염기는 [7]약어를 기억하는데 도움을 주는 산의 반대이다.같은 리소스에 따르면 BASE의 각 용어의 대략적인 정의는 다음과 같습니다.

  • 기본적으로 사용 가능: 가능한 한 읽기 및 쓰기 작업을 사용할 수 있지만(데이터베이스 클러스터의 모든 노드를 사용) 일관성이 없을 수 있음(경합 조정 후 쓰기가 지속되지 않고 읽기가 최신 쓰기를 얻지 못할 수 있음)
  • 소프트 스테이트: 일관성이 보장되지 않으면 일정 시간이 지나면 상태를 알 수 있습니다.이는 아직 수렴되지 않았을 수 있기 때문입니다.
  • 최종적으로 일관성: 일부 쓰기를 실행한 후 시스템이 충분히 작동하면 데이터 상태를 알 수 있습니다.데이터 항목을 더 읽으면 동일한 값이 반환됩니다.

궁극적인 일관성은 분산 소프트웨어 애플리케이션의 복잡성을 증가시킨다는 비판을[8] 받기도 합니다.이는 부분적으로 궁극적인 일관성이 순전히 활성 보증(판독은 결국 동일한 값을 반환함)이며 안전을 보장하지 않기 때문입니다. 최종적인 일관성이 있는 시스템은 수렴하기 전에 값을 반환할 수 있습니다.

충돌 해결

복제본 컨버전스를 보장하기 위해 시스템은 분산된 데이터의 여러 복사본 간의 차이를 조정해야 합니다.이것은 다음 두 부분으로 구성됩니다.

  • 서버 간 데이터 버전 또는 업데이트 교환(흔히 안티바이러스라고 함)[9]
  • 동시 업데이트가 발생했을 때 적절한 최종 상태를 선택합니다(조정).

조정에 대한 가장 적절한 접근법은 응용 프로그램에 따라 달라집니다.널리 알려진 접근법은 "마지막 작가가 승리한다"[1]입니다.다른 하나는 사용자 지정 충돌 [4]핸들러를 호출하는 것입니다.타임스탬프와 벡터클럭은 업데이트 간의 동시성을 검출하기 위해 자주 사용됩니다.어떤 사람들은 "최후의 작가가 이기는 것"이 용납될 [10]수 없는 상황에서 "최초의 작가가 이기는 것"을 사용한다.

동시 쓰기의 조정은 다음 읽기 전에 수행되어야 하며, 다른 [3][11]인스턴스에서 예약할 수 있습니다.

  • 판독 복구:보정은 읽기에서 불일치가 발견되면 수행됩니다.이로 인해 읽기 작업이 느려집니다.
  • 쓰기 복구:보정은 쓰기 작업 중에 이루어지며 쓰기 작업이 느려집니다.
  • 비동기 복구:수정은 읽기 또는 쓰기 작업의 일부가 아닙니다.

궁극적인 강력한 일관성

최종적인 일관성은 활성 보증(업데이트가 최종적으로 관찰됨)일 뿐이지만, 강력한 최종 일관성(SEC)은 동일한 (순서 없는) 업데이트 세트를 수신한 모든 2개의 노드가 동일한 상태에 있을 것이라는 안전 보증을 추가합니다.게다가 시스템이 단조로운 경우, 애플리케이션은 롤백하지 않습니다.SEC에 경합이 없는 복제 데이터 [12]유형을 보장하는 일반적인 접근 방식입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Vogels, W. (2009). "Eventually consistent". Communications of the ACM. 52: 40–44. doi:10.1145/1435417.1435432.
  2. ^ Vogels, W. (2008). "Eventually Consistent". Queue. 6 (6): 14–19. doi:10.1145/1466443.1466448.
  3. ^ a b Terry, D. B.; Theimer, M. M.; Petersen, K.; Demers, A. J.; Spreitzer, M. J.; Hauser, C. H. (1995). "Managing update conflicts in Bayou, a weakly connected replicated storage system". Proceedings of the fifteenth ACM symposium on Operating systems principles - SOSP '95. p. 172. CiteSeerX 10.1.1.12.7323. doi:10.1145/224056.224070. ISBN 978-0897917155. S2CID 7834967.
  4. ^ a b Petersen, K.; Spreitzer, M. J.; Terry, D. B.; Theimer, M. M.; Demers, A. J. (1997). "Flexible update propagation for weakly consistent replication". ACM SIGOPS Operating Systems Review. 31 (5): 288. CiteSeerX 10.1.1.17.555. doi:10.1145/269005.266711.
  5. ^ Pritchett, D. (2008). "Base: An Acid Alternative". Queue. 6 (3): 48–55. doi:10.1145/1394127.1394128.
  6. ^ Bailis, P.; Ghodsi, A. (2013). "Eventual Consistency Today: Limitations, Extensions, and Beyond". Queue. 11 (3): 20. doi:10.1145/2460276.2462076.
  7. ^ Roe, Charles (March 2012). "ACID vs. BASE: The Shifting pH of Database Transaction Processing". DATAVERSITY. DATAVERSITY Education, LLC. Retrieved 29 August 2019.
  8. ^ HYaniv Pessach (2013), Distributed Storage (Distributed Storage: Concepts, Algorithms, and Implementations ed.), Amazon, OL 25423189M, Systems using Eventual Consistency result in decreased system load and increased system availability but result in increased cognitive complexity for users and developers
  9. ^ Demers, A.; Greene, D.; Hauser, C.; Irish, W.; Larson, J. (1987). "Epidemic algorithms for replicated database maintenance". Proceedings of the sixth annual ACM Symposium on Principles of distributed computing - PODC '87. p. 1. doi:10.1145/41840.41841. ISBN 978-0-89791-239-6. S2CID 1889203.
  10. ^ 록포드 로트카."통화 기술"2003.
  11. ^ Olivier Mallassi (2010-06-09). "Let's play with Cassandra… (Part 1/3)". OCTO Talks!. Retrieved 2011-03-23. Of course, at a given time, chances are high that each node has its own version of the data. Conflict resolution is made during the read requests (called read-repair) and the current version of Cassandra does not provide a Vector Clock conflict resolution mechanisms [sic] (should be available in the version 0.7). Conflict resolution is so based on timestamp (the one set when you insert the row or the column): the higher timestamp win[s] and the node you are reading the data [from] is responsible for that. This is an important point because the timestamp is specified by the client, at the moment the column is inserted. Thus, all Cassandra clients’ [sic] need to be synchronized...
  12. ^ Shapiro, Marc; Preguiça, Nuno; Baquero, Carlos; Zawirski, Marek (2011-10-10). "Conflict-free replicated data types". SSS'11 Proceedings of the 13th International Conference on Stabilization, Safety, and the Security of Distributed Systems. Springer-Verlag Berlin, Heidelberg: 386–400.