2016-09-26 4 views
0

"products"라는 couchDB 데이터베이스와 양식이있는 프론트 엔드 데이터베이스가 있다고 가정 해 보겠습니다. 이제 사용자가이 데이터베이스의 문서를 양식으로 열면 다른 사용자가이 특정 문서를 편집하지 못하게하고 싶습니다.데이터베이스 클러스터 - 비동기 작업

보통 아주 간단합니다 :

-> read document from couchDB 
-> set a variable to true like: { edit : true } 
-> save (merge) document to couchDB 
-> if someone else tries to open the document he will receive an error, becaus of edit:true. 

하지만, 만약에 두 사용자가 동일한 시간에 문서를 열? 이 함수는 두 번 호출되며 두 번째 문서가 열리면 첫 번째 편집에 저장할 시간이 없으므로 false로 편집을 받게됩니다. 그래서 어떻게 이런 행동을 방지 할 수 있을까요?

첫 번째 해결 방법은 다음과 같습니다. 데이터베이스 요청의 큐로 배열을 작성하고 병렬 요청을 허용하지 않으므로 모든 요청이 차례로 처리됩니다. 그러나 내 의견으로는이 시스템은 어느 시점에서 매우 느릴 수 있기 때문에 이것은 나쁜 해결책입니다.

두 번째 해결 방법 : 현재 편집 된 문서의 documentID를 스크립트의 로컬 배열에 저장합니다. 이는 비동기 프로세스가 아니기 때문에 작동하며 두 번째 사용자는 오류를 즉시 받게됩니다.

언젠가는 너무 많은 사용자가 있고이 시스템이 클러스터가 아닌 노드 클라이언트 서버 (데이터베이스가 아닌)에서 실행되어야한다면 어떨까요? 이제는 두 번째 솔루션이 더 이상 작동하지 않습니다. 모든 클러스터 슬레이브는 고유의 documentID 배열을가집니다. 거기서 공유하면 다른 비동기 작업이 끝나고 위와 동일한 문제가 발생합니다.

지금은 아이디어가 없습니다. 대형 클러스터 시스템이 그런 문제를 어떻게 처리합니까?

+0

동시에 문서를 저장하면 충돌이 발생합니다. 따라서 귀하의 솔루션 중 어느 것도 유용하지 않습니다. 업데이트 처리기를 사용하면 충돌 가능성을 줄일 수 있지만 여전히 가능합니다. –

답변

2

CouchDB는 MVCC을 사용하여 데이터베이스의 일관성을 유지합니다. 문서가 업데이트 될 때 ID (_id)와 개정 번호 (_rev)를 입력해야합니다. 그렇지 않으면 변경 사항이 거부됩니다.

즉, 2 명의 클라이언트가 리비전 1의 문서를 읽었을 때 동일한 리비전 번호를 사용하여 변경 사항을 쓰려고하면 첫 번째 것만 데이터베이스에서 승인됩니다. 두 번째 클라이언트는 오류를 수신하고 진행하기 위해 문서의 최신 버전을 가져와야합니다.

단일 노드 환경에서이 모델은 충돌을 완전히 방지합니다. 그러나 복제가 발생하는 경우 MVCC를 사용하는 경우에도 여전히 충돌이 발생할 수 있습니다. 이는 충돌하는 개정판이 서로 복제되기 전에 서로 다른 노드에 기술적으로 기록 될 수 있기 때문입니다. 이 경우, CouchDB는 충돌을 기록하고 응용 프로그램이이를 해결할 책임이 있습니다.

CouchDB에는 특히이 주제에 대해 권장하는 an article all about conflicts and replication이 있습니다.