CouchDB 복제 프로토콜은 무엇입니까? Git과 같은가요?
두 Couches 간의 복제 작동 방식을 설명하는 기술 문서가 있습니까?
CouchDB 복제의 기본 개요는 무엇입니까? 그것에 대해 주목할만한 특징은 무엇입니까?
불행히도 복제 프로토콜을 설명하는 자세한 문서가 없습니다. CouchDB에 내장 된 참조 구현과 필리페 마나 나의 재 작성 만이 미래에 새로운 구현이 될 것입니다.
그러나 이것은 일반적인 아이디어입니다.
키 포인트
Git을 알고 있다면 Couch 복제가 어떻게 작동하는지 알 것입니다. 복제는 Git과 같은 분산 소스 관리자를 사용하여 푸시하거나 당기는 것과 매우 유사합니다.
CouchDB 복제에는 자체 프로토콜이 없습니다. 복제기는 클라이언트로 두 개의 DB에 연결 한 다음 하나에서 읽고 다른 DB에 씁니다. 푸시 복제는 로컬 데이터를 읽고 원격 DB를 업데이트합니다. 풀 복제는 그 반대입니다.
- 재미있는 사실 1 : 복제기는 실제로 자체 프로세스에서 독립적 인 Erlang 응용 프로그램입니다. 두 소파에 연결 한 다음 하나에서 레코드를 읽고 다른 소파에 씁니다.
- 재미있는 사실 2 : CouchDB는 누가 일반 클라이언트이고 누가 복제 자 인지 알 수있는 방법 이 없습니다 (복제가 푸시인지 풀인지는 말할 것도 없습니다). 모두 클라이언트 연결처럼 보입니다. 그들 중 일부는 기록을 읽습니다. 그들 중 일부는 기록을 씁니다.
모든 것이 데이터 모델에서 흘러 나옴
복제 알고리즘은 사소하고 흥미롭지 않습니다. 훈련 된 원숭이가 디자인 할 수 있습니다. 영리함은 다음과 같은 유용한 특성을 가진 데이터 모델이기 때문에 간단합니다.
- CouchDB의 모든 레코드는 다른 모든 레코드와 완전히 독립적입니다.
JOIN또는 트랜잭션 을 수행하려면 짜증나 지만 복제기를 작성하려면 굉장합니다. 하나의 레코드 를 복제하는 방법을 파악한 다음 각 레코드에 대해 반복하십시오 . - Git과 마찬가지로 레코드에는 링크 된 목록 개정 내역이 있습니다. 레코드의 개정 ID는 자체 데이터의 체크섬입니다. 후속 개정 ID는 새 데이터와 이전 개정 ID의 체크섬입니다.
애플리케이션 데이터 (
{"name": "Jason", "awesome": true}) 외에도 모든 레코드는 자신에 이르는 모든 이전 개정 ID의 진화 타임 라인을 저장합니다.- 운동 : 잠시 조용히 반성을하십시오. A와 B라는 두 개의 다른 레코드를 고려하십시오. A의 개정 ID가 B의 타임 라인에 나타나면 B는 A에서 확실히 진화 한 것입니다. 이제 Git의 빨리 감기 병합을 고려하십시오. 들리나요? 그것은 당신의 마음이 날아가는 소리입니다.
Git은 실제로 선형 목록이 아닙니다. 한 부모가 여러 자녀를 가질 때 포크가 있습니다. CouchDB도 있습니다.
연습 : A와 B라는 두 개의 다른 레코드를 비교합니다. A의 개정 ID가 B의 타임 라인에 나타나지 않습니다. 그러나 하나의 개정 ID C는 A와 B의 타임 라인 에 모두 있습니다. 따라서 A는 B에서 진화하지 않았습니다. B는 A에서 진화하지 않았습니다. 오히려 A와 B는 공통 조상 C를 가지고 있습니다. Git에서 그것은 "포크"입니다. CouchDB에서는 "충돌"입니다.
Git에서 두 아이들이 독립적으로 타임 라인을 개발한다면 멋지다. 포크는이를 완전히 지원합니다.
- CouchDB에서 두 아이들이 독립적으로 타임 라인을 개발한다면 그 역시 멋지다. 갈등은 그것을 전적으로 뒷받침합니다.
- 재미있는 사실 3 : CouchDB "충돌"은 Git "충돌"과 일치하지 않습니다. Couch 충돌은 Git이 "포크"라고 부르는 다양한 개정 내역입니다. 이러한 이유로 CouchDB 커뮤니티는 침묵 n : "co-flicked" 로 "충돌"을 선언 합니다.
Git은 또한 한 자식에 여러 부모가있을 때 병합이 있습니다. CouchDB를 용 의 종류 도 그 있습니다.
- 데이터 모델에는 병합이 없습니다. 클라이언트는 단순히 하나의 타임 라인을 삭제 된 것으로 표시하고 유일한 기존 타임 라인으로 계속 작업합니다.
- 응용 프로그램에서는 병합처럼 느껴집니다. 일반적으로 클라이언트는 애플리케이션 별 방식으로 각 타임 라인 의 데이터 를 병합합니다 . 그런 다음 새 데이터 를 타임 라인에 씁니다 . Git에서 이것은 분기 A에서 분기 B로 변경 사항을 복사하여 붙여 넣은 다음 분기 B에 커밋하고 분기 A를 삭제하는 것과 같습니다. 데이터 가 병합되었지만
git merge. - 이러한 동작은 Git에서 타임 라인 자체가 중요하기 때문에 다릅니다. 하지만 CouchDB에서는 데이터가 중요하고 타임 라인은 부수적입니다. 복제를 지원하기 위해 존재합니다. 이것이 CouchDB의 내장 개정이 위키 페이지와 같은 개정 데이터를 저장하는 데 부적절한 이유 중 하나입니다.
최종 노트
이 글에서 적어도 한 문장 (아마도이 문장)은 완전한 BS입니다.
훌륭한 개요에 대해 Jason에게 감사합니다! TouchDB 및 Couchbase 용 복제 작업을 수행하는 Jens Alfke 는 "표준"CouchDB 복제기 프로토콜이 작동하는 방식에 대한 기술적 세부 사항에 관심이있는 경우 CouchDB 복제 알고리즘 자체를 (비공식적으로) 설명 했습니다.
그가 설명한 단계를 요약하면 다음과 같습니다.
- 이전 복제가 얼마나 멀리 있는지 파악
_changes그 시점부터 소스 데이터베이스 가져 오기- 사용
revs_diff대상에서 필요로하는보고 변화의 배치에 - 누락 된 개정 메타 데이터 및 현재 문서 데이터 + 첨부 파일을 소스에서 대상으로 복사하고,
bulk_docs최적화 를 위해 둘 다에 게시하고 에서 일반적인 상위 수준 MVCC 처리와 다르게 문서를 저장합니다PUT.
여기에서 많은 세부 사항을 살펴 보았으며 원래 설명도 읽어 보는 것이 좋습니다.
CouchDB를의 V2.0.0에 대한 문서는 복제 알고리즘을 포함 훨씬 더 광범위. 다이어그램, 예제 중간 응답 및 예제 오류가 있습니다. 그들은 IETF RFC의 "MUST", "SHALL"등의 언어를 사용합니다.
2.0.0 (2016 년 1 월 현재 아직 출시되지 않음)에 대한 세부 사항은 1.x와 약간 다르지만 기본 사항은 여전히 @natevw가 설명한대로 입니다.
에서 아파치 CouchDB를 컨퍼런스 2013 , 벤자민 젊은 소개 replication.io을 자신의 FTW, 복제! 이야기 . HTTP 기반 마스터-마스터 복제에 대한 사양을 정의하고 궁극적으로 수정하려는 지속적인 노력입니다.
http://www.dataprotocols.org/en/latest/couchdb_replication.html 도 여기에 문서화되어 있습니다 .
참고 URL : https://stackoverflow.com/questions/4766391/what-is-the-couchdb-replication-protocol-is-it-like-git
'IT박스' 카테고리의 다른 글
| Android EditText에서 수직 콘텐츠 정렬 (0) | 2020.11.17 |
|---|---|
| sqlite 한 테이블에서 다른 테이블로 데이터 복사 (0) | 2020.11.17 |
| HTML 일반 제어 div에 CSS 클래스를 추가하는 방법은 무엇입니까? (0) | 2020.11.17 |
| INSERT… RETURNING의 반환 값을 다른 INSERT에서 사용할 수 있습니까? (0) | 2020.11.17 |
| Windows Batch Command를 사용하여 Jenkins에서 환경 변수를 어떻게 사용합니까? (0) | 2020.11.17 |