Mongodb는 CAP 정리에서 어디에 위치합니까?

Mongodb는 CAP 정리에서 어디에 위치합니까?

어디를 봐도 MongoDB는 CP입니다.하지만 내가 파고들면 결국 일관성이 있다는 것을 알 수 있다.safe=true를 사용하면 CP입니까?그렇다면 safe=true로 쓰면 결과를 얻기 전에 모든 복제본이 업데이트된다는 의미입니까?

기본적으로는 MongoDB는 매우 일관성이 있습니다.쓰기를 수행한 후 읽기를 수행하면 쓰기가 성공했다고 가정하면 읽은 지 얼마 안 된 쓰기의 결과를 항상 읽을 수 있습니다.이는 MongoDB가 싱글 마스터 시스템이기 때문에 기본적으로는 모든 읽기가 프라이머리로 진행되기 때문입니다.필요에 따라 세컨더리로부터의 판독을 유효하게 하면, MongoDB는, 기한이 지난 결과를 판독할 수 있는 장소에서도 일관되게 됩니다.

MongoDB는 레플리카 세트의 자동 페일오버를 통해 고가용성을 실현합니다.http://www.mongodb.org/display/DOCS/Replica+Sets

나는 Luccas 포스트에 동의한다.MongoDB는 CP/AP/CA라고만 할 수 없습니다.이것은 실제로는 데이터베이스/드라이버의 구성과 디저스터의 유형에 따라 C, A, P의 트레이드오프이기 때문입니다.다음은 시각적인 개요와 보다 상세한 설명입니다.

시나리오	주안점	묘사
파티션 없음	CA	시스템을 사용할 수 있으며 강력한 일관성을 제공합니다.
파티션, 과반수 연결	액세스 포인트	이전 프라이머리에서 동기화되지 않은 쓰기는 무시됩니다.
파티션, 대다수가 연결되어 있지 않음	CP	시스템 분리 및 불일치를 방지하기 위해 읽기 액세스만 제공됨

일관성:

MongoDB는 단일 연결 또는 올바른 쓰기/읽기 문제 수준(실행 속도가 저하됨)을 사용할 때 매우 일관성이 있습니다.이러한 조건(특히 secondary-replica에서 읽을 때)을 충족하지 못하면 MongoDB는 최종적으로 일관되게 됩니다.

가용성:

MongoDB는 Replica-Sets를 통해 고가용성을 실현합니다.프라이머리가 다운되거나 다른 기능을 사용할 수 없게 되면 세컨더리가 새로운 프라이머리를 다시 사용할 수 있게 됩니다.여기에는 다음과 같은 단점이 있습니다.이전 프라이머리에 의해 실행되었지만 세컨더리에 동기화되지 않은 모든 쓰기는 세트에 재접속되는 즉시 롤백되어 롤백파일에 저장됩니다(이전 프라이머리는 세컨더리입니다).따라서 이 경우 가용성을 위해 일정 부분 일관성이 손실됩니다.

파티션 허용 범위:

상기 Replica-Sets를 사용함으로써 MongoDB도 파티션 허용치를 달성합니다.Replica-Set의 서버 중 절반 이상이 서로 연결되어 있는 한, 새 주 서버를 선택할 수 있습니다. 이유는 무엇입니까?2개의 분리된 네트워크가 모두 새로운 프라이머리 네트워크를 선택할 수 없도록 하기 위해서입니다.세컨더리가 서로 충분히 연결되어 있지 않은 경우에도 세컨더리에서 읽을 수 있지만(단, 일관성은 보장되지 않음) 쓰기는 할 수 없습니다.그 세트는 일관성을 위해 사실상 사용할 수 없다.

이 분야의 Kyle에 의한 멋진 실험과 훌륭한 새로운 기사가 나왔기 때문에 MongoDB 및 기타 데이터베이스에 C 또는 A라는 라벨을 붙일 때는 주의해야 합니다.

물론 CAP은 데이터베이스가 우세한 부분을 단어 없이 추적하는 데 도움이 되지만, 예를 들어 CAP의 C가 원자적인 일관성(선형성)을 의미한다는 것을 잊어버리는 경우가 많습니다.그래서 분류할 때 많은 고통을 겪었습니다.따라서 MongoDB가 강력한 일관성을 제공한다고 해서 C가 되는 것은 아닙니다.이와 같이 분류를 할 경우, 의문을 남기지 않도록, 실제로 어떻게 기능하는지에 대해서도 보다 깊이 있는 설명을 하는 것을 추천합니다.

,, 용, 사 CP이다를 가 됩니다.safe=true이는 단순히 데이터가 마스터 디스크에 도달했음을 의미합니다.일부 복제본에도 도달했는지 확인하려면 'w=N' 매개 변수를 확인합니다. 여기서 N은 데이터를 저장해야 하는 복제본 수입니다.

자세한 것은, 이것과 이것을 참조해 주세요.

MongoDB는 파티션이 있을 때마다 가용성보다 일관성을 선택합니다.즉, 파티션(P)이 있는 경우 가용성(A)보다 일관성(C)을 선택합니다.

이를 이해하기 위해 MongoDB의 레플리카 세트 구조에 대해 알아보겠습니다.복제 세트에는 단일 기본 노드가 있습니다.데이터를 커밋하는 유일한 "안전한" 방법은 해당 노드에 쓴 다음 해당 데이터가 세트 내 대부분의 노드에 커밋될 때까지 기다리는 것입니다.(쓰기를 전송할 때 w=slags에 대한 플래그를 볼 수 있습니다.

파티션은 다음과 같은 두 가지 시나리오에서 발생할 수 있습니다.

• [프라이머리(Primary)]노드가 다운되면: 새로운 프라이머리가 선택될 때까지 시스템을 사용할 수 없게 됩니다.
• [프라이머리(Primary)]노드가 너무 많은 세컨더리 노드에서 접속을 잃으면 시스템을 사용할 수 없게 됩니다.다른 세컨더리는 새로운 프라이머리 선출을 시도하고 현재의 프라이머리는 물러납니다.

기본적으로 파티션이 발생하여 MongoDB가 작업을 결정해야 할 경우 가용성보다 일관성을 선택합니다.시스템에 대한 쓰기가 안전하게 완료될 수 있을 때까지 더 이상 허용되지 않습니다.

Mongodb는 세컨더리에 쓰는 것을 허용하지 않습니다.세컨더리로부터의 읽기(옵션)는 가능하지만, 기입은 할 수 없습니다.따라서 프라이머리가 다운되면 세컨더리가 프라이머리가 될 때까지 쓸 수 없습니다.이렇게 하면 CAP 정리의 고가용성(HA)이 희생됩니다.읽기를 프라이머리에서만 유지함으로써 높은 일관성을 유지할 수 있습니다.

P for Mongo는 잘 모르겠어요.상황을 상상해 보세요.

• 복제본이 두 개의 파티션으로 분할됩니다.
• 새로운 마스터가 선출됨에 따라 양쪽에 쓰기가 계속됨
• 파티션이 해결되었습니다.모든 서버가 다시 연결되었습니다.
• 새로운 마스터가 선출됩니다.이 마스터는 oplog가 가장 높지만 다른 마스터의 데이터는 파티션 전에 공통 상태로 되돌아가며 수동으로 복구하기 위해 파일에 덤프됩니다.
• 모든 부관이 새 주인을 따라잡다

여기서의 문제는 덤프 파일의 크기가 제한되어 있으며 오랫동안 파티션을 사용했다면 데이터가 영구적으로 손실될 수 있다는 것입니다.

이러한 일이 일어날 가능성은 낮다고 할 수 있습니다.그렇습니다.그러나 생각보다 일반적인 클라우드에서는 그렇지 않습니다.

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

이 시나리오가 Mongo의 후속 릴리즈에서 해결되었는지 알고 계신 분은 코멘트를 부탁드립니다! (요즘 모든 상황을 지켜본 것은 아닙니다.)

Mongodb는 가용성을 포기합니다.CAP 정리의 맥락에서 가용성에 대해 설명할 때는 다운될 수 있는 단일 장애 지점을 피하는 것입니다.몽고브에서.프라이머리 라우터 호스트가 있습니다.이 호스트가 다운되면 새로운 대체 서버를 선택하는 데 걸리는 시간이 길어집니다.사실, 그건 아주 쉽게 일어날거야 우린 거기에 몇명의 뜨거운 스탠바이들이 앉아있거든따라서 프라이머리 라우팅 호스트가 다운된 것을 검출하면 즉시 새로운 라우팅 호스트로 전환됩니다.엄밀히 말하면, 이것은 여전히 단일 장애 지점입니다.이 경우에도 다운타임이 발생할 가능성이 있습니다.

주 서버인 구성 서버가 있고 앱 서버가 있습니다. 앱 서버는 항상 주 서버입니다.백업이 여러 개 있어도 서버 중 하나라도 다운되면 짧은 시간 동안 다운타임이 발생합니다.시스템은 먼저 정지가 발생한 것을 검출하고, 그 후 나머지 서버는 새로운 프라이머리 호스트를 다시 선택해 그 자리를 대신할 필요가 있습니다.몇 초가 걸릴 수 있으며, 이는 mongodb가 가용성을 교환하고 있다고 말하기에 충분합니다.

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