일반 영어의 최종 일관성

일반 영어의 최종 일관성

---

나는 종종 NoSQL, 데이터 그리드 등에 대한 다른 연설에서 최종 일관성에 대해 듣습니다. 최종 일관성의 정의는 많은 소스에서 다양하며 (아마도 구체적인 데이터 스토리지에 따라 다름).

누구든지 구체적인 데이터 저장과 관련이없는 최종 일관성이 무엇인지 간단히 설명 할 수 있습니까?

---

최종 일관성 :

1. 날씨 보고서를보고 내일 비가 올 것임을 알게됩니다.
2. 내일 비가 올 것이라고 말씀드립니다.
3. 이웃이 아내에게 내일 맑을 것이라고 말합니다.
4. 내일 비가 올 것이라고 이웃에게 말하십시오.

결국, 모든 서버 (당신, 나, 이웃)는 진실을 알고 있습니다 (내일 비가 올 것입니다). 그러나 그 동안 클라이언트 (그의 아내)는 그녀가 물었을지라도 맑을 것이라고 생각했습니다. 하나 이상의 서버 (귀하와 나)가 더 최신의 가치를 얻은 후에.

엄격한 일관성 / ACID 준수와 반대로 :

1. 은행 잔고는 $ 50입니다.
2. 당신은 $ 100를 입금합니다.
3. 모든 ATM에서 쿼리 한 은행 잔고는 $ 150입니다.
4. 딸이 ATM 카드로 40 달러를 인출합니다.
5. 어디서나 ATM에서 조회 한 은행 잔고는 $ 110입니다.

귀하의 잔고는 계정에서 이루어진 모든 거래의 실제 합계를 정확히 그 순간까지 반영 할 수 없습니다.

이유는 많은 NoSQL이 시스템은 최종 일관성있는 이유는 거의 모든 이들의 분배 할 수 있도록 설계, 완전히 분산 시스템 (만 지금까지 일을 천천히 시작하기 전에 확장 할 수 있습니다 의미 엄격한 일관성을 유지하기 위해 슈퍼 선형 오버 헤드가된다는 것입니다 다운 될 때 확장을 유지하려면 문제에 대해 기하 급수적으로 더 많은 하드웨어를 던져야합니다).

---

최종 일관성 :

1. 데이터가 여러 서버에 복제됩니다
2. 클라이언트는 서버에 액세스하여 데이터를 검색 할 수 있습니다
3. 누군가 서버 중 하나에 데이터를 쓰지만 아직 나머지 서버로 복사되지 않았습니다.
4. 클라이언트는 데이터를 사용하여 서버에 액세스하여 최신 사본을 얻습니다.
5. 다른 클라이언트 (또는 동일한 클라이언트)는 다른 서버 (아직 새 사본을 얻지 못한 서버)에 액세스하여 이전 사본을 가져옵니다.

기본적으로 여러 서버에서 데이터를 복제하는 데 시간이 걸리므로 데이터 읽기 요청은 새 복사본이있는 서버로 이동 한 다음 이전 복사본이있는 서버로 이동합니다. "최종"이라는 용어는 결국 데이터가 모든 서버에 복제되므로 모두 최신 사본을 갖게됩니다.

응답 서버는 자체 데이터 복사본을 반환해야하고 다른 서버를 참조하고 데이터 내용에 대해 상호 합의에 도달 할 수 없기 때문에 지연 시간이 짧은 읽기를 원할 경우 최종 일관성이 필수적입니다. 이것을 자세히 설명 하는 블로그 게시물을 작성했습니다 .

---

응용 프로그램과 복제본이 있다고 생각하십시오. 그런 다음 응용 프로그램에 새 데이터 항목을 추가해야합니다.

그런 다음 응용 프로그램은 아래의 다른 복제본 쇼와 데이터를 동기화합니다.

한편 새 클라이언트는 아직 업데이트되지 않은 하나의 복제본에서 데이터를 가져옵니다. 이 경우 그는 정확한 날짜 데이터를 얻을 수 없습니다. 동기화에는 시간이 걸리기 때문입니다. 이 경우 결국 일관성 이 없었습니다.

문제는 어떻게 결국 일관성을 유지할 수 있는가?

이를 위해 중개자 애플리케이션을 사용하여 데이터를 업데이트 / 생성 / 삭제하고 직접 쿼리를 사용하여 데이터를 읽습니다. 결국 일관성을 유지 하는 데 도움이되는

---

When an application makes a change to a data item on one machine, that change has to be propagated to the other replicas. Since the change propagation is not instantaneous, there’s an interval of time during which some of the copies will have the most recent change, but others won’t. In other words, the copies will be mutually inconsistent. However, the change will eventually be propagated to all the copies, and hence the term “eventual consistency”. The term eventual consistency is simply an acknowledgement that there is an unbounded delay in propagating a change made on one machine to all the other copies. Eventual consistency is not meaningful or relevant in centralized (single copy) systems since there’s no need for propagation.

source: http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf

---

In simple English, we can say: Although your system may be in inconsistent states, the aim is always to reach consistency at some point for each piece of data.

---

Eventual consistency is more like a spectrum. On one end you have strong consistency and on other you have eventual consistency. In between there are levels like Snapshot, read my writes, bounded staleness. Doug Terry has a beautiful explanation in his paper on eventual consistency thru baseball .

As per me eventual consistency is basically toleration to random data in random order every time you read from a data store. Anything better than that is a stronger consistency model. For example, a snapshot has stale data but will return same data if read again so it is predictable. Sometimes application can tolerate data which is stale for a given amount of time beyond which it demands consistent data.

If you look at meaning of consistency it relates more to uniformity or lack of deviation. So in non computer system terms it could mean toleration for unexpected variations. It could be very well explained thru ATM. An ATM could be offline hence divergent from account balance from core systems. However there is a toleration for showing different balances for a window of time. Once the ATM comes online, it can sync with core systems and reflect same balance. So an ATM could be said to be eventually consistent.

---

Eventually consistency means changes take time to propagate and the data might not be in the same state after every action, even for identical actions or transformations of the data. This can cause very bad things to happen when people don’t know what they are doing when interacting with such a system.

Please don’t implement business critical document data stores until you understand this concept well. Screwing up a document data store implementation is much harder to fix than a relational model because the fundamental things that are going to be screwed up simply cannot be fixed as the things that are required to fix it are just not present in the ecosystem. Refactoring the data of an inflight store is also much harder than the simple ETL transformations if a RDBMS.

Not all document stores are created equal. Some these days (MongoDB) do support transactions of a sort, but migrating datastores is likely comparable to the expense of re-implementation.

WARNING: Developers and even architects who do not know or understand the technology of a document data store and are afraid to admit that for fear of losing their jobs but have been classically trained in RDBMS and who only know ACID systems (how different can it be?) and who don’t know the technology or take the time to learn it, will miss design a document data store. They may also try and use it as a RDBMS or for things like caching. They will break down what should be atomic transactions which should operate on an entire document into “relational” pieces forgetting that replication and latency are things, or worse yet, dragging third party systems into a “transaction”. They’ll do this so their RDBMS can mirror their data lake, without regard to if it will work or not, and with no testing, because they know what they are doing. Then they will act surprised when complex objects stored in separate documents like “orders” have less “order items” than expected, or maybe none at all. But it won’t happen often, or often enough so they’ll just march forward. They may not even hit the problem in development. Then, rather than redesign things, they will throw “delays” and “retries” and “checks” in to fake a relational data model, which won’t work, but will add additional complexity for no benefit. But its too late now - the thing has been deployed and now the business is running on it. Eventually, the entire system will be thrown out and the department will be outsourced and someone else will maintain it. It still won’t work correctly, but they can fail less expensively than the current failure.

참고 URL : https://stackoverflow.com/questions/10078540/eventual-consistency-in-plain-english