답변:
MongoDB는 기본적으로 강력하게 일관됩니다. 쓰기를 한 다음 읽기를 수행하면 쓰기가 성공했다고 가정하면 방금 읽은 쓰기의 결과를 항상 읽을 수 있습니다. 이는 MongoDB가 단일 마스터 시스템이고 모든 읽기가 기본적으로 기본으로 이동하기 때문입니다. 선택적으로 보조에서 읽기를 활성화하면 MongoDB는 오래된 결과를 읽을 수있는 곳에서 결국 일관성을 갖게됩니다.
MongoDB는 복제본 세트에서 자동 장애 조치를 통해 고 가용성을 제공합니다. http://www.mongodb.org/display/DOCS/Replica+Sets
루카스 포스트에 동의합니다. 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 systemsMongoDB는 단일 연결 또는 올바른 쓰기 / 읽기 문제 수준 을 사용할 때 강력하게 일관됩니다 ( 실행 속도가 저하됨 ). 이러한 조건을 충족하지 않으면 (특히 보조 복제본에서 읽을 때) MongoDB는 Eventually Consistent가됩니다.
MongoDB는 Replica-Sets를 통해 고 가용성을 얻습니다 . 기본이 다운되거나 다른 곳에서 사용할 수 없게되는 즉시 보조는 다시 사용할 수있는 새 기본을 결정합니다. 여기에는 단점이 있습니다. 이전 기본에서 수행되었지만 보조와 동기화되지 않은 모든 쓰기가 롤백됩니다. 및 롤백 파일에 저장이되는 즉시 세트에 다시 연결로 (이전 기본은 보조입니다 지금). 따라서이 경우 가용성을 위해 일부 일관성이 희생됩니다.
상기 레플리카 세트의 사용을 통해 MongoDB는 파티션 허용도를 달성합니다. 레플리카 세트의 서버 중 절반 이상이 서로 연결되어 있는 한 새로운 1 차 서버를 선택할 수 있습니다 . 왜? 두 개의 분리 된 네트워크를 보장하기 위해 둘 다 새로운 기본을 선택할 수는 없습니다. 충분한 보조가 서로 연결되지 않은 경우에도 여전히 읽을 수 있지만 (일관성이 보장되지 않음) 쓰기는 불가능합니다. 이 세트는 일관성을 위해 사실상 사용할 수 없습니다.
A와 화려한 새로운 기사가 나타나서 일부 카일로 멋진 실험 이 분야에서 C 또는 A로 MongoDB를, 그리고 다른 데이터베이스를 라벨 때주의해야
물론 CAP는 데이터베이스가 우세한 내용을 많은 말없이 추적하는 데 도움이되지만, 사람들은 예를 들어 CAP의 C가 원자 일관성 (선형성)을 의미한다는 사실을 종종 잊습니다. 그리고 이것은 분류하려고 할 때 이해하는 데 많은 고통을주었습니다. 따라서 MongoDB가 강력한 일관성을 제공하는 것 외에도 이것이 C라는 것을 의미하지는 않습니다. 이런 식으로이 분류를 만들면 실제로 작동하는 방식에 대해 더 깊이 설명하여 의심을 남기지 않는 것이 좋습니다.
네, 사용시 CP safe=true입니다. 이것은 단순히 데이터가 마스터 디스크로 전송되었음을 의미합니다. 일부 복제본에도 도착했는지 확인하려면 'w = N'매개 변수를 살펴보십시오. 여기서 N은 데이터를 저장해야하는 복제본의 수입니다.
Mongo의 P에 대해 잘 모르겠습니다. 상황을 상상해보십시오.
여기서 문제는 덤프 파일 크기가 제한되어 있고 파티션이 오랫동안 있으면 데이터를 영원히 잃을 수 있다는 것입니다.
당신은 그것이 일어날 것 같지 않다고 말할 수 있습니다. 그렇습니다. 클라우드에서 생각하는 것보다 더 흔하지 않다면 말입니다.
이 예는 데이터베이스에 문자를 할당하기 전에 매우주의해야하는 이유입니다. 너무 많은 시나리오와 구현이 완벽하지 않습니다.
이 시나리오가 Mongo의 이후 릴리스에서 해결되었는지 아는 사람이 있으면 의견을 보내주십시오! (나는 한동안 일어난 모든 일을 따르지 않았습니다 ..)
MongoDB는 파티션이있을 때마다 가용성보다 일관성을 선택합니다. 의미하는 바는 파티션 (P)이있을 때 가용성 (A)보다 일관성 (C)을 선택한다는 것입니다.
이것을 이해하기 위해 MongoDB가 복제 세트가 작동하는 방식을 이해합시다. 복제 세트에는 단일 기본 노드가 있습니다. 데이터를 커밋하는 유일한 "안전한"방법은 해당 노드에 쓴 다음 해당 데이터가 집합의 대부분의 노드에 커밋 될 때까지 기다리는 것입니다. (쓰기를 보낼 때 w = majority 플래그가 표시됩니다)
파티션은 다음과 같은 두 가지 시나리오에서 발생할 수 있습니다.
기본적으로 파티션이 발생하고 MongoDB가 수행 할 작업을 결정해야 할 때마다 가용성보다 일관성을 선택합니다. 해당 쓰기를 안전하게 완료 할 수 있다고 판단 될 때까지 시스템에 대한 쓰기 허용을 중지합니다.
Mongodb는 일관성 과 파티션 허용 오차를 제공합니다 .
분산 (NoSQL) 데이터베이스의 맥락에서 이것은 일관성과 가용성 사이에 항상 절충안이 있음을 의미합니다. 이는 분산 시스템이 항상 파티션을 허용하기 때문입니다 (즉, 파티션 허용이 아니라면 분산 데이터베이스가 아닐 것입니다).
일관성 -시스템은 결국 일관성이 있습니다. 데이터는 조만간 모든 곳으로 전파되지만 시스템은 계속해서 입력을 받고 다음 트랜잭션으로 이동하기 전에 모든 트랜잭션의 일관성을 확인하지 않습니다.
가용성 -기본적으로 Mongo DB Client (MongoDB 드라이버)는 모든 읽기 / 쓰기 요청을 리더 / 기본 노드로 보냅니다. 시스템을 일관성있게 만들지 만 다음과 같은 이유로 사용할 수 없습니다.-리더가 클러스터에서 연결이 끊어지면 새 리더를 선택하는 데 몇 초가 걸립니다. 따라서 해당 기간 동안 쓰기 및 읽기에 사용할 수 없습니다.