mongodb는 CAP 정리에서 어디에 서 있습니까?

mongodb는 CAP 정리에서 어디에 서 있습니까?

---

어디를 가든 MongoDB가 CP라는 것을 알 수 있습니다. 하지만 파헤쳐 보면 결국 일관성이 있음을 알 수 있습니다. safe = true를 사용할 때 CP입니까? 그렇다면 safe = true로 쓸 때 결과를 얻기 전에 모든 복제본이 업데이트된다는 의미입니까?

---

MongoDB는 기본적으로 강력하게 일관됩니다. 쓰기를 한 다음 읽기를 수행하면 쓰기가 성공했다고 가정하면 방금 읽은 쓰기의 결과를 항상 읽을 수 있습니다. 이는 MongoDB가 단일 마스터 시스템이고 모든 읽기가 기본적으로 기본으로 이동하기 때문입니다. 선택적으로 보조에서 읽기를 활성화하면 MongoDB는 오래된 결과를 읽을 수있는 최종 일관성이됩니다.

MongoDB는 또한 복제본 세트에서 자동 장애 조치를 통해 고 가용성을 제공합니다. http://www.mongodb.org/display/DOCS/Replica+Sets

---

이것은 다른 NoSQL 및 기타 영구 스토리지 시스템과 함께 질문에 대한 답을 찾는 데 도움이 될 것입니다.

---

루카스 포스트에 동의합니다. MongoDB가 CP / AP / CA라고 말할 수는 없습니다. 실제로 데이터베이스 / 드라이버 구성 및 재해 유형에 따라 C, A 및 P 사이 의 절충안 이기 때문 입니다 . 여기에 시각적 요약이 있습니다. 더 자세한 설명.

    Scenario                   | Main Focus | Description
    ---------------------------|------------|------------------------------------
    No partition               |     CA     | The system is available 
                               |            | and provides strong consistency
    ---------------------------|------------|------------------------------------
    partition,                 |     AP     | Not synchronized writes 
    majority connected         |            | from the old primary are ignored                
    ---------------------------|------------|------------------------------------
    partition,                 |     CP     | only read access is provided
    majority not connected     |            | to avoid separated and inconsistent systems

일관성:

MongoDB는 단일 연결 또는 올바른 쓰기 / 읽기 문제 수준 을 사용할 때 강력하게 일관됩니다 ( 실행 속도가 저하됨 ). 이러한 조건을 충족하지 않으면 (특히 보조 복제본에서 읽을 때) MongoDB는 Eventually Consistent가됩니다.

유효성:

MongoDB는 Replica-Sets를 통해 고 가용성을 얻습니다 . 기본이 다운되거나 다른 곳에서 사용할 수 없게되는 즉시 보조는 다시 사용할 수있는 새 기본을 결정합니다. 이에 대한 단점이있다 :됩니다 이전 기본에 의해 수행하지만 보조에 동기화되지 않은 모든 쓰기 다시 압연 및 롤백 파일에 저장이되는 즉시 세트에 다시 연결로 (이전 기본은 보조입니다 지금). 따라서이 경우 가용성을 위해 일부 일관성이 희생됩니다.

파티션 공차 :

상기 레플리카 세트의 사용을 통해 MongoDB는 파티션 허용도를 달성합니다. 레플리카 세트의 서버 중 절반 이상이 서로 연결되어 있는 한 새로운 1 차 서버를 선택할 수 있습니다 . 왜? 두 개의 분리 된 네트워크를 보장하기 위해 둘 다 새로운 기본을 선택할 수는 없습니다. 충분한 보조가 서로 연결되지 않은 경우에도 여전히 읽을 수 있지만 (일관성이 보장되지 않음) 쓰기는 불가능합니다. 이 세트는 일관성을 위해 사실상 사용할 수 없습니다.

---

A와 화려한 새 문서 도 일부 나타났다 카일에 의해 멋진 실험 이 분야에서 C 또는 A로 MongoDB를, 그리고 다른 데이터베이스를 라벨 때주의해야

물론 CAP는 데이터베이스가 우세한 내용을 많은 말없이 추적하는 데 도움이되지만 사람들은 예를 들어 CAP의 C가 원자 일관성 (선형성)을 의미한다는 사실을 종종 잊습니다. 그리고 이것은 분류하려고 할 때 이해하는 데 많은 고통을주었습니다. 따라서 MongoDB가 강력한 일관성을 제공하는 것 외에도 이것이 C라는 것을 의미하지는 않습니다. 이런 식으로이 분류를 수행하면 실제로 작동하는 방식에 대해 더 심도있게 설명하여 의심을 남기지 않는 것이 좋습니다.

---

네, 사용시 CP safe=true입니다. 이것은 단순히 데이터가 마스터 디스크로 전송되었음을 의미합니다. 일부 복제본에도 도착했는지 확인하려면 'w = N'매개 변수를 살펴보십시오. 여기서 N은 데이터를 저장해야하는 복제본의 수입니다.

자세한 내용은 this 와 this 를 참조하십시오.

---

Mongo의 P에 대해 잘 모르겠습니다. 상황을 상상해보십시오.

• 복제본은 두 개의 파티션으로 분할됩니다.
• 새로운 마스터가 선출됨에 따라 양측에 계속 쓰기
• 파티션이 해결됨-이제 모든 서버가 다시 연결됨
• 가장 높은 oplog가있는 새 마스터가 선택되지만 다른 마스터의 데이터는 파티션 이전의 일반 상태로 되돌려지고 수동 복구를 위해 파일에 덤프됩니다.
• 모든 보조가 새 마스터를 따라 잡습니다.

여기서 문제는 덤프 파일 크기가 제한되어 있고 파티션이 오랫동안 있으면 데이터를 영원히 잃을 수 있다는 것입니다.

당신은 그것이 일어날 것 같지 않다고 말할 수 있습니다. 그렇습니다. 클라우드에서 생각하는 것보다 더 흔하지 않다면 말입니다.

이 예는 데이터베이스에 문자를 할당하기 전에 매우주의해야하는 이유입니다. 너무 많은 시나리오와 구현이 완벽하지 않습니다.

이 시나리오가 Mongo의 이후 릴리스에서 해결되었는지 아는 사람이 있으면 의견을 보내주십시오! (나는 한동안 일어난 모든 일을 따르지 않았습니다 ..)

---

Mongodb는 보조 쓰기를 허용하지 않습니다. 보조 읽기는 허용되지만 쓰기는 허용되지 않습니다. 따라서 기본이 중단되면 보조가 다시 기본이 될 때까지 쓸 수 없습니다. 이것이 바로 CAP 정리에서 고 가용성을 희생하는 방법입니다. 기본에서만 읽기를 유지함으로써 강력한 일관성을 가질 수 있습니다.

참고 URL : https://stackoverflow.com/questions/11292215/where-does-mongodb-stand-in-the-cap-theorem