Document Conflicts & Resolution in Couchbase Mobile 2.0

한 명 이상의 작성자가 동시에 문서를 업데이트할 수 있는 데이터 동기화를 지원하는 분산 환경에서 문서 충돌이 발생할 수 있습니다. 특히 네트워크 연결이 불안정하여 여러 장치에서 동시에 변경한 내용이 적시에 동기화되지 않는 모바일 환경에서 자주 발생합니다.

예를 들어 문서가 로컬에서 업데이트되는 동안 원격 서버에서 클라이언트로 문서 변경 내용이 내려오는 경우와 같이 클라이언트 측에서도 발생할 수 있습니다. 따라서 이러한 문서 충돌을 해결해야 합니다. 카우치베이스 모바일 2.0를 소개합니다. "자동 충돌 해결" 또는 "충돌 없음" 모드를 사용하면 충돌이 자동으로 처리되고 Couchbase 데이터베이스에 충돌하는 문서 수정본이 사실상 존재하지 않습니다.

앱 개발자는 시스템의 기본 충돌 해결기가 자동으로 처리하기 때문에 충돌을 처리하기 위해 앱 측에서 특별히 할 일이 없을 것입니다. 그러나 필요한 경우 충돌에 대한 알림을 받고 적절한 조치를 취할 수 있는 옵션이 있습니다. 이 게시물에서는 Couchbase Mobile 2.0에서 문서 충돌이 자동으로 처리되는 방식에 대한 기본 사항에 대해 "자동 충돌 해결" 또는 "충돌 없음 " 모드로 전환합니다.

가정

이 게시물에서는 다음을 포함하는 Couchbase Mobile 스택의 아키텍처에 익숙하다고 가정합니다. 카우치베이스 라이트 모바일 클라이언트를 위한 임베디드 데이터베이스인 동기화 게이트웨이 그리고 카우치베이스 서버. 플랫폼을 처음 사용하시는 분이라면 다음 내용을 참고하시기 바랍니다. 리소스.

배경

아직 읽어보지 않으셨다면 이 글을 먼저 읽어보시는 것이 좋습니다. 이해하기 쉬운 갈등 해결 게시물 개요 다중 버전 동시성 제어(MVCC) 시스템을 포함하여 카우치베이스 모바일에서 "충돌이 없는" 모드에서 충돌 해결이 처리되는 방식에 대한 기본 사항을 설명합니다.

문서 수정본 트리

충돌 해결 프로세스를 이해하려면 문서가 저장되는 방식에 대한 기본적인 이해가 필요합니다. Couchbase Mobile에서는 모든 문서에 시스템에서 생성된 고유한 리비전 ID 또는 revID. 이 ID는 문서 수정본에 걸쳐 동일하게 유지되는 문서 ID에 추가됩니다. 수정이든 삭제든 문서에 대한 모든 변경은 문서의 새 수정본으로 간주되므로 새 수정본 ID가 할당됩니다.

또한 모든 문서 수정본에는 "세대ID"를 추가합니다. 문서를 처음 만들면 수정본이 "세대ID"이후 개정판이 업데이트될 때마다 이 숫자가 증가합니다.

기존 문서를 변경(편집 또는 삭제)할 때마다 작성자는 업데이트 중인 문서의 현재 리비전 ID를 포함해야 합니다. 변경 사항에 대한 새 리비전이 생성되고 업데이트 중인 현재 리비전의 하위 노드로 추가되어 문서의 리비전 트리가 생성됩니다.

참고 "revID" 는 앱에서 불투명 객체로 취급되어야 하며, 앱이 불투명 객체를 생성하려고 시도해서는 안됩니다. "revID".

문서 충돌이 발생하는 방식

높은 수준에서 충돌은 여러 작성자가 동일한 상위 문서 수정본을 변경할 때 발생합니다.

카우치베이스 라이트의 충돌

아래 그림은 앱이 메모리에서 문서 수정본을 업데이트하는 동안 동일한 수정본이 풀 복제로 인해 업데이트되는 시나리오를 설명합니다.

동기화 게이트웨이의 충돌

아래 그림은 두 클라이언트가 동일한 문서 수정본에 대한 변경 내용을 푸시하는 시나리오를 설명합니다.

카우치베이스 모바일 2.0의 충돌 해결

In "충돌 없음" 모드에서 동기화 게이트웨이는 기본적으로 충돌하는 모든 업데이트를 거부합니다. 충돌은 문서가 생성, 업데이트 또는 삭제될 때 자동으로 해결됩니다.
따라서 이것이 의미하는 바는 데이터베이스에 충돌하는 문서가 저장되어 있지 않다는 것이며, 사실상 "충돌 없음". 이것이 어떻게 작동하는지 살펴보겠습니다.

카우치베이스 라이트 2.0의 자동 충돌 해결

카우치베이스 라이트 2.0의 모든 문서에는 "충돌 해결사" 를 시도할 때 충돌이 발생하면 실행됩니다. 저장 또는 삭제 문서를 선택합니다. 충돌 해결 기능은 "우승자'를 선택하면 충돌하는 수정본 중 이 수정본이 문서 수정본 트리에 자식으로 추가됩니다.

카우치베이스 라이트에서 지원하는 동시성 제어 정책은 두 가지입니다.

동시성 제어 정책

마지막 쓰기가 항상 승리합니다(기본값):

이는 기본 충돌 해결사 정책이기도 합니다. 이 경우 데이터베이스에 대한 마지막 업데이트가 항상 승리합니다.

전화할 때 저장 문서 인수가 없는 경우 기본적으로 적용되는 정책입니다.

다음은 스위프트의 통화 예시입니다.

 let savedDocument = try saveDocument(docToSave)

1	let 저장된 문서 = 시도 저장 문서(문서 저장)

아래 예시를 통해 이 정책의 의미를 명확히 이해할 수 있습니다.

예를 들어, 마지막으로 문서를 읽은 이후 데이터베이스의 문서가 업데이트되었음에도 불구하고 저장/업데이트 요청이 성공하는 경우가 있습니다. 데이터베이스의 문서는 풀 복제 또는 원격 서버로부터의 데이터 가져오기와 같은 외부 트리거의 결과로 앱의 다른 스레드에 의해 업데이트되었을 수 있습니다. 즉, 문서를 읽은 시점과 업데이트한 시점 사이에 문서에 적용된 모든 변경 사항을 덮어쓴다는 의미입니다.

아래와 같이 데이터베이스의 문서가 마지막으로 문서를 읽은 이후 삭제되었음에도 불구하고 저장/업데이트 요청이 성공합니다. 데이터베이스의 문서는 풀 복제 또는 원격 서버로부터의 데이터 가져오기와 같은 외부 트리거의 결과로 앱의 다른 스레드에 의해 업데이트되었을 수 있습니다. 이는 삭제된 문서가 저장의 결과로 다시 부활할 수 있다는 의미입니다.

충돌 시 실패

대부분의 경우 '마지막 쓰기가 승리'라는 기본 동시성 제어 정책이 작동할 것으로 예상되지만, 문서를 저장하는 동안 충돌이 발생할 경우 알림을 받도록 지정하여 기본 동작을 재정의할 수 있습니다. 이 작업은 선택 사항인 ConcurrentControl 인수를 저장 요청의 일부로 사용합니다.

반환 값 false 와 동시성 제어 정책 failOnConflict 는 충돌로 인해 저장된 문서가 실패했음을 나타냅니다. 이제 충돌 오류를 처리하는 방법을 살펴보겠습니다.

충돌 시 실패 처리하기

충돌을 처리하는 방법은 애플리케이션의 의미론에 따라 다릅니다. 다음은 스위프트에서 이를 처리하는 방법의 예시입니다(다른 언어에 쉽게 매핑할 수 있음).

옵션 1: 충돌하는 버전의 문서를 병합하고 저장합니다.

do {
    var success = false
    repeat {
        if try db.saveDocument(docToSave, concurrencyControl: .failOnConflict) {
            // save was a success. docToSave is the new saved revision. Proceed as usual
            success = true
        }
        else {
            // Failure on save with failOnConflict mode
            // Handle conflict appropriately
            // First, fetch the current saved version of doc
            if let currDoc = db.document(withID: docToSave.id) {
                // Option 1 : Merge the contents of doc1b and currDoc
                docToSave = mergeDocument(newDoc: docToSave, currentDoc: currDoc)
            }
            else {
                // Doc was deleted. Handle appropriately
            }
        }
        
    } while (!success)
}
catch {
    print("Some other error in saving \(error)")
}

do {

var 성공 = false

반복 {

만약 시도 db.저장 문서(문서 저장, 동시성 제어: .failOnConflict) {

// 저장에 성공했습니다. 문서가 새로 저장된 수정본입니다. 평소와 같이 진행합니다.

성공 = true

}

else {

// failOnConflict 모드로 저장 시 저장 실패

// 충돌을 적절히 처리하기

// 먼저, 현재 저장된 문서 버전을 가져옵니다.

만약 let currDoc = db.문서(withID: 문서 저장.id) {

// 옵션 1 : doc1b와 currDoc의 내용을 병합합니다.

문서 저장 = mergeDocument(newDoc: 문서 저장, currentDoc: currDoc)

}

else {

// 문서가 삭제되었습니다. 적절하게 처리

}

} 동안 (!성공)

}

catch {

인쇄("저장 중 다른 오류 \(오류)")

}

이것은 충돌하는 수정본을 병합하는 방법의 예입니다. 다시 말하지만, 어떻게 병합할지는 전적으로 애플리케이션에 달려 있습니다. 이 예는 다음과 같은 방법을 참조하기 위한 것입니다. could 처리합니다.


/// Merges two conflicting versions of CBL document using following criteria
/// - Newly added properties are added 
/// - If we are updating an existing property, that is ignored a property that already exists
///
/// - Parameter 
///   - newDoc: The new version of document to be saved
///   - currentDoc : The current saved version of the document
func mergeDocument(newDoc: Document, currentDoc: Document) -&gt; MutableDocument {
    // 1. Create a resolved mutable document based on the current saved document
    let resolved = currentDoc.toMutable()
    
    // 2. Add the additional properties that don't already exist
    for key in newDoc.keys {
        if !resolved.contains(key) {
            resolved.setValue(newDoc.value(forKey: key), forKey: key)
        }
    }
    return resolved
}

/// 다음 기준을 사용하여 충돌하는 두 버전의 CBL 문서를 병합합니다.

/// - 새로 추가된 프로퍼티가 추가됩니다.

/// - 기존 프로퍼티를 업데이트하는 경우 이미 존재하는 프로퍼티는 무시됩니다.

///

/// - 매개변수

/// - newDoc: 저장할 문서의 새 버전입니다.

/// - currentDoc : 문서의 현재 저장된 버전입니다.

func mergeDocument(newDoc: 문서, currentDoc: 문서) -> 뮤터블 도큐먼트 {

// 현재 저장된 문서를 기반으로 해결된 변경 가능한 문서를 만듭니다.

let 해결됨 = currentDoc.toMutable()

// 2. 아직 존재하지 않는 추가 속성을 추가합니다.

에 대한 키 in newDoc.키 {

만약 !해결됨.포함(키) {

해결됨.setValue(newDoc.값(forKey: 키), forKey: 키)

}

반환 해결됨

}

옵션 2: 강제 저장으로 승리하기

이 옵션은 "쓰기가 항상 승리"라는 기본 동시성 정책과 사실상 동일합니다. 다만 이 경우 현재 저장된 문서의 내용을 검토한 다음 강제로 저장할지 여부를 결정하기 위해 저장 문서.
문서를 저장하기 전에 문서가 다시 업데이트될 수 있다는 점에서 여전히 경합 조건의 위험이 있을 수 있다는 점에 유의하세요.

do {
    if try db.saveDocument(docToSave, concurrencyControl: .failOnConflict) {
        // save was a success. docToSave is the new saved revision. Proceed as usual
    }
    else {
        // Failure on save with failOnConflict mode
        // Handle conflict appropriately
        if let currDoc = db.document(withID: docToSave.id) {
            // Option 2: Examine contents of current saved version of doc
            // Force write of document
            try db.saveDocument(docToSave)
        }
        else {
            // Doc was deleted.
            // Option 2: Attempt to do a force write of document to override the delete
            try db.saveDocument(docToSave)
        }
    }
}
catch {
    print("Some other error in saving \(error)")
}

do {

만약 시도 db.저장 문서(문서 저장, 동시성 제어: .failOnConflict) {

// 저장에 성공했습니다. 문서가 새로 저장된 수정본입니다. 평소와 같이 진행합니다.

}

else {

// failOnConflict 모드로 저장 시 저장 실패

// 충돌을 적절히 처리하기

만약 let currDoc = db.문서(withID: 문서 저장.id) {

// 옵션 2: 현재 저장된 문서 버전의 내용 확인

// 문서 강제 쓰기

시도 db.저장 문서(문서 저장)

}

else {

// 문서가 삭제되었습니다.

// 옵션 2: 문서 강제 쓰기를 시도하여 삭제를 재정의합니다.

시도 db.저장 문서(문서 저장)

}

catch {

인쇄("저장 중 다른 오류 \(오류)")

}

옵션 3: 저장 건너뛰기

이 경우 현재 저장된 문서의 내용을 검토한 다음 현재 저장된 버전의 문서를 유지하는 것이 더 낫다고 판단할 수 있습니다.

do {
    let docToSave = MutableDocument(id: "docId")
    if !(try db.saveDocument(docToSave, concurrencyControl: .failOnConflict)) {
        // Fetch the current saved version of doc
        if let currDoc = db.document(withID: docToSave.id) {
            // Option 3 : Examine contents of doc
            // Current saved doc looks fine. Do nothing
        }
        else {
            // Doc was deleted. Handle appropriately
        }
    }
    else {
        // save was a success. docToSave is the new saved revision. Proceed as usual
    }
}
catch {
    print("Some other error in saving \(error)")
}

do {

let 문서 저장 = 뮤터블 도큐먼트(id: "docId")

만약 !(시도 db.저장 문서(문서 저장, 동시성 제어: .failOnConflict)) {

// 현재 저장된 문서 버전 가져오기

만약 let currDoc = db.문서(withID: 문서 저장.id) {

// 옵션 3: 문서 내용 검토

// 현재 저장된 문서는 정상적으로 보입니다. 아무것도 하지 않음

}

else {

// 문서가 삭제되었습니다. 적절하게 처리

}

else {

// 저장에 성공했습니다. 문서가 새로 저장된 수정본입니다. 평소와 같이 진행합니다.

}

catch {

인쇄("저장 중 다른 오류 \(오류)")

}

동일한 ID로 문서 만들기에 대한 시사점

기본 충돌 해결 정책은 저장 문서 를 사용하여 문서를 다시 만들려고 하면 마지막 쓰기가 항상 승리한다는 것입니다. docId 데이터베이스에 이미 존재하는 문서에 새 수정본을 추가하여 기존 문서를 업데이트합니다.

따라서 실수로 기존 문서를 업데이트하지 않도록 하려면 "ConcurrenyControl 인수를 사용하여 failOnConflict. 그러면 적절하게 처리할 수 있는 오류가 반환됩니다.

이 경우 문서의 현재 내용을 검사할 필요가 없다는 점을 제외하면 앞서 지정한 옵션 3과 매우 유사합니다. 충돌 실패는 Id가 있는 문서가 이미 존재한다는 의미입니다.

다음은 Swift의 예시입니다.

do {
    let docToSave = MutableDocument(id: "docId")
    if !(try db.saveDocument(docToSave, concurrencyControl: .failOnConflict)) {
        // Document with Id already exists. Handle appropriately
    }
    else {
        // save was a success. docToSave is the new saved revision. Proceed as usual
    }
}
catch {
    print("Some other error in saving \(error)")
}

do {

let 문서 저장 = 뮤터블 도큐먼트(id: "docId")

만약 !(시도 db.저장 문서(문서 저장, 동시성 제어: .failOnConflict)) {

// Id가 있는 문서가 이미 존재합니다. 적절하게 처리

}

else {

// 저장에 성공했습니다. 문서가 새로 저장된 수정본입니다. 평소와 같이 진행합니다.

}

catch {

인쇄("저장 중 다른 오류 \(오류)")

}

동기화 게이트웨이 2.0의 충돌 방지 모드

이 모드에서는 동기화 게이트웨이가 HTTP 409 오류와 충돌을 일으키는 수정본을 거부하여 데이터베이스에 충돌하는 수정본이 없도록 효과적으로 보장합니다. 충돌은 끌어오기 복제 중에 클라이언트 측에서 처리됩니다.

푸시 복제

클라이언트가 수정본 변경 내용을 동기화 게이트웨이에 푸시합니다.
동기화 게이트웨이에서 들어오는 수정본이 서버에 저장된 현재 수정본과 충돌하는 것을 감지합니다(즉, 들어오는 수정본의 상위 수정본이 서버의 활성 수정본이 아닌 경우).
동기화 게이트웨이가 수정본 변경을 거부하면 409 오류. Couchbase Lite는 오류를 기록하는 것 외에는 실제로 아무것도 하지 않습니다. 충돌은 이후 풀 복제 중에 해결됩니다.

풀 복제

풀 복제 중에 클라이언트가 충돌을 감지하면 다음과 같은 결정론적 기준을 사용하여 충돌이 해결됩니다.

삭제가 항상 승리합니다. 이 경우의 예는 아래와 같습니다.

가장 최근 변경 사항(가장 높은 세대 ID)가 승리하거나 최대 revID 는 세대가 동일한 경우, 즉 단순 ASCII 비교에서 더 높은 정렬 순위를 갖는 revID가 승리합니다. 이에 대한 예는 아래와 같습니다.

다음으로 풀 복제 중 사례를 살펴봅니다.

서버 브랜치가 승자

클라이언트가 동기화 게이트웨이에서 리비전 변경 사항을 가져옵니다.
클라이언트가 들어오는 수정본이 현재 저장된 수정본과 충돌하는 것을 감지합니다(즉, 들어오는 수정본과 저장된 수정본이 공통 부모를 공유함).
클라이언트는 현재 저장된 수정본과 서버 수정본 간의 승자를 결정하는 충돌 해결기 함수를 호출합니다.
1. 다음 개정 이후(Rev2-B)가 로컬 수정본(Rev2-A)을 누르면 서버 리비전이 승자로 선택됩니다. 서버의 리비전이 삭제된 경우에도 마찬가지입니다.
서버 브랜치가 로컬 리비전 트리에 접목되고 로컬 브랜치는 툼스톤 처리된다.
그 후 변경 사항이 서버로 푸시되면 충돌이 발생하지 않고 서버가 클라이언트 측과 동기화됩니다.

지역 지사가 우승자

클라이언트가 동기화 게이트웨이에서 리비전 변경 사항을 가져옵니다.
클라이언트가 들어오는 수정본이 현재 저장된 수정본과 충돌하는 것을 감지합니다(즉, 들어오는 수정본과 저장된 수정본이 공통 부모를 공유함).
클라이언트는 현재 저장된 수정본과 서버 수정본 간의 승자를 결정하는 충돌 해결기 함수를 호출합니다.
1. 로컬 개정 이후(Rev2-B)가 들어오는 서버 개정판(Rev2-A), 로컬 리비전이 우승자로 선정됩니다. 로컬 브랜치의 리비전이 삭제된 경우에도 마찬가지입니다.
서버 브랜치가 로컬 리비전 트리에 접목되고 새 리비전이 만들어집니다. Rev3 가 추가되며, 이는 수상작의 내용에 해당합니다, Rev2-B
그 후 변경 사항이 서버로 푸시되면 충돌이 발생하지 않고 서버가 클라이언트 측과 동기화됩니다.

참고: 보시다시피, 충돌은 풀 복제 중에 Couchbase Lite에서 해결됩니다. 이는 복제기가 푸시 복제기로만 구성되어 있는 경우 Couchbase Lite의 데이터 보기가 동기화 게이트웨이의 데이터 보기와 달라진다는 의미입니다(CBL의 일부 쓰기 시도가 409로 실패할 수 있기 때문). 따라서 충돌이 발생할 것으로 예상되는 경우, 충돌 없는 모드에서 사용할 때 Couchbase Lite 복제기를 푸시-풀 모드로 구성하는 것이 좋습니다.

동기화 게이트웨이에서 충돌 없는 모드 구성하기

동기화 게이트웨이의 "충돌 없음" 모드는 다음을 통해 구성할 수 있습니다. 허용_갈등 속성을 동기화 게이트웨이 구성 파일에 추가합니다. "false"로 변경하여 충돌 없는 모드를 활성화합니다. 또한 이 속성 구성에 관계없이 Couchbase Lite 2.0 클라이언트와 동기화할 때 동기화 게이트웨이에 충돌하는 수정 버전이 추가되지 않는다는 점에 유의해야 합니다. 이에 대해서는 앞서 복제 섹션에서 설명했습니다. "allow_conflicts" 구성은 2.0 이외의 클라이언트 및 REST API 클라이언트에 대해서만 영향을 미칩니다. 아래 표에는 그 의미가 요약되어 있습니다.

충돌 방지 모드가 데이터베이스 크기에 미치는 영향

충돌 해결이 데이터베이스 크기에 미치는 영향은 이전 게시물에서 자세히 설명했습니다. 데이터베이스 크기 관리. 충돌을 허용하는 시스템에서는 충돌하는 리비전이 증가함에 따라 리비전 트리의 크기가 커져 데이터베이스 크기에 영향을 미칠 수 있습니다. 따라서 충돌을 적시에 해결하는 것이 중요했습니다. 동기화 게이트웨이에는 revs_limit 리비전 트리의 크기를 결정하는 속성입니다. 리비전 트리의 revs_limit 속성의 기본값은 1000으로, 이는 마지막 1000개의 수정본에 해당하는 메타데이터가 정리되기 전에 동기화 게이트웨이에 저장된다는 의미입니다. 설정하는 동안 revs_limit 를 큰 값으로 설정하면 데이터베이스 크기에 부정적인 영향을 미치므로 매우 낮은 값으로 설정하지 않는 것이 중요했습니다. 충돌 해결을 처리하는 데 필요한 이전 리비전에 해당하는 메타데이터를 유지하는 것이 중요했는데, 그렇지 않으면 문서의 리비전에 대한 연결이 끊어진 리비전 트리의 숲이 생길 위험이 있기 때문이죠. 따라서 허용되는 최소값인 revs_limit 는 20입니다.

그러나 충돌 없는 모드를 사용하면 이전 버전에 해당하는 메타데이터를 저장할 필요가 없습니다. 즉, 이전 버전에 해당하는 revs_limit 는 1에 불과할 수 있습니다. 이는 최신/활성 수정본만 저장된다는 의미입니다. 이렇게 하면 데이터베이스 크기를 크게 줄일 수 있습니다.

감사

특별 감사 대상 파신 수리엔트라콘 모바일 엔지니어링 팀에서 Couchbase Lite 섹션에 대한 피드백을 보내주셨습니다. 아담 프레이저동기화 게이트웨이 섹션에 대한 피드백을 제공한 모바일 엔지니어링 팀의 Daniel Petersen과 동기화 게이트웨이 섹션에 대한 피드백을 제공한 모바일 엔지니어링 팀의 Daniel Petersen에게 감사드립니다.

다음 단계

이 블로그 게시물에서는 Couchbase Mobile 2.0에서 충돌이 자동으로 처리되는 방법에 대해 설명합니다. Couchbase Mobile 2.0은 다음에서 다운로드할 수 있습니다. 다운로드 페이지로 이동합니다.

질문이나 피드백이 있으면 아래에 댓글을 남기거나 다음 주소로 트위터에 문의해 주세요. @rajagp 또는 다음 주소로 이메일을 보내주세요. priya.rajagopal@couchbase.com. . 카우치베이스 포럼 는 질문이 있을 때 연락할 수 있는 또 다른 좋은 장소입니다.

프리야 라자고팔, 제품 관리 부문 선임 이사

이 문서 공유하기

댓글 하나

avia_bdg 3월 20, 2018에서 1:51 오전

안녕하세요 프리야,

모바일 2.0에 새로운 '충돌 방지' 모드가 도입되면 대체 모드는 무엇인가요? 특히 게이트웨이는 EE로 '충돌 없음'만 지원합니다. 커뮤니티 에디션에서는 충돌이 어떻게 해결되거나 해결되지 않나요?

ConcurrencyControl을 사용하면 로컬 클라이언트 측에서 Save()에서 충돌을 수동으로 처리하고 해결할 수 있습니다. 복제로 인해 발생하는 충돌의 경우
> 클라이언트에서 충돌 해결사 함수 호출
이 충돌 해결 기능은 어디에 설정되어 있나요? 베타 2에는 레플리케이터 구성에 이전 충돌 해결기가 없습니다. 이것은 내부 자동 해결기를 가리키는 건가요, 아니면 수동으로 해결할 수 있는 건가요? 이것이 자동 전용이라면 내부 로컬 저장 충돌은 사용자 지정 방식으로 처리할 수 있지만 외부 복제 충돌은 처리할 수 없는 것이 이상하지 않을까요?
또한 '충돌 방지'(EE) 모드가 없는 경우 어떻게 다르게 처리되나요?

감사합니다.

로그인 하여 답글 남기기
프리야 라자고팔, 개발자 옹호자, Couchbase 3월 20, 2018에서 8:17 오전

안녕하세요!
CE에서는 SGW의 충돌이 1.x 버전에서와 같은 방식으로 처리됩니다. 기본적으로 푸시 충돌 시 409 오류가 발생하지 않습니다.
예. 이것은 내부 충돌 해결사입니다. 2.0에서는 이를 재정의할 수 없습니다.
로컬 저장에 대한 충돌은 앱에서 감지할 수 있지만 복제로 인한 충돌은 그렇게 할 수 없다는 말씀이 맞습니다. 그러나 두 경우의 기본 충돌 해결 정책은 로컬 저장의 경우와 달리 복제의 경우 결정론적이며 대부분의 경우 사용자가 결정론적 상태를 선호할 것으로 생각한다는 점에도 유의하세요.

목표는 "충돌이 없는" 것입니다. 따라서 두 경우 모두 문서가 업데이트될 때(로컬 또는 원격 가져오기) 충돌 해결이 자동으로 이루어집니다. 따라서 이러한 목표를 염두에 두면 쉽게 추론할 수 있듯이 로컬 저장을 거부할 수 있는 전자의 경우와 달리 끌어오기 복제에서는 동일한 작업을 수행할 수 없습니다.

이제 자동 충돌 해결기를 재정의할 수 있는 옵션을 제공하는 것을 고려할 수 있습니다. 이는 사용자 수요에 따라 2.0 이후가 될 것입니다. 그럴 필요가 있을까요?

로그인 하여 답글 남기기
1. avia_bdg 3월 20, 2018에서 9:13 오전
  
  2.0 문서에는 다음과 같이 명시되어 있습니다:
  > Couchbase Lite 2.0부터는 자동 충돌 해결을 사용하거나 애플리케이션에서 문서 충돌을 해결해야 합니다.
  그렇다면 CE가 대신 v1.x 방법을 사용하도록 되어 있다면 이는 사실이 아닌가요?
  
  충돌 해결기, 문서 수정본 클래스 등 수정본 및 충돌을 관리하는 데 v1.x에서 사용되었던 모든 항목이 2.x API에서 모두 제거된 것 같습니다. 그렇다면 2.x CE가 v1.x 방식을 사용하게 된다면 어떻게 되나요? 모든 것이 새로운 자동 방식만을 위해 설계된 것 같습니다. CE 게이트웨이에서는 충돌이 해결될 때까지 충돌 상태의 문서에 대해 여전히 여러 개의 수정본이 있을 것입니다. 따라서 클라이언트는 어떤 문서가 충돌 상태에 있는지, 어떤 수정본이 존재하는지 확인할 수 있어야 합니다.
  
  클라이언트 저장() 메서드에서 재정의할 수 있으므로 자동 충돌 해결기를 재정의할 필요가 있습니다. 물론, 연속 복제를 사용하는 경우 변경 사항이 즉시 복제되므로 (희망적으로) 저장 시 충돌이 발생할 가능성이 가장 높습니다. 그러나 대부분 오프라인으로 작업하고 가끔씩만 복제하는 경우 충돌은 대부분 save()가 아니라 복제할 때 발생합니다. 이 시나리오에서는 save()의 고급 사용자 지정 병합 기능이 훨씬 덜 유용하며, 가장 긴 리비전 트리에 대한 기본값만 '고착'될 것입니다. save()에서 충돌을 처리하려면 같은 방식으로 복제에서 충돌을 처리할 수 있는 기능도 있어야 할 것 같습니다.
  
  물론 끌어오기를 '거부'할 수 없기 때문에 기술적인 문제는 다릅니다. v1.x에서는 여러 리비전을 충돌 상태로 만든 다음 이를 해결하는 방식으로 이 문제를 해결했습니다. v2.x에서도 어떻게든 이 옵션을 원하실 것 같습니다. 이 기능을 구현하는 데 따르는 기술적 어려움 때문에 v1.x와 비교했을 때, 그리고 save()의 기능과 비교했을 때 기능을 마비시켜야 할 이유는 없다고 생각합니다.
  
  로그인 하여 답글 남기기
벤 케네디 3월 20, 2018에서 10:23 오전

첫 번째 다이어그램의 세 번째 패널("카우치베이스 라이트에서 충돌")에는 캡션이 있습니다: "앱이 로컬로 수정된 버전의 문서를 저장하려고 합니다. 문서가 충돌하지 않습니다!"

그림에 충돌이 명확하게 묘사되어 있는 것 같습니다. 캡션에 오류가 있나요?

로그인 하여 답글 남기기
1. 프리야 라자고팔, 개발자 옹호자, Couchbase 3월 20, 2018에서 11:59 오전
  
  죄송합니다. 캡션에 오류가 있습니다. 수정하겠습니다.
  
  로그인 하여 답글 남기기
벤 케네디 3월 20, 2018에서 11:26 오전

위의 avia_bdg의 의견에 덧붙여, 복제와 관련된 충돌 해결 전략에 대해 좀 더 명확히 설명해 주셨으면 합니다. 위의 글과 대화를 읽어보니 현재 CBL 2.0의 설계는 동기화 게이트웨이를 사용하는 오프라인 클라이언트의 데이터 손실을 사실상 보장하는 것처럼 들립니다. 이렇게 되면 제품을 완전히 사용할 수 없게 됩니다.

풀 복제로 인해 발생하는 충돌을 결정적으로 해결할 수 있는 수단이 없으면 클라이언트는 변경 사항이 버려질지 여부를 주사위를 던져 결정합니다. 현재 CBL 1.x를 사용하는 주요 프로젝트를 비롯한 많은 애플리케이션의 기본 요구 사항인 병합이 더 이상 불가능합니다. 정말 놀라운 일이죠.

제가 잘못 이해한 것 같으니 안심시켜 주세요.

로그인 하여 답글 남기기
1. 프리야 라자고팔, 개발자 옹호자, Couchbase 3월 20, 2018에서 12:12 오후
  
  피드백을 보내주셔서 감사합니다. 귀하의 이해가 옳습니다. 이 기능을 도입하는 것을 검토해 보겠습니다...
  
  로그인 하여 답글 남기기
프리야 라자고팔, 개발자 옹호자, Couchbase 3월 20, 2018에서 11:58 오전

아주 좋은 질문입니다!
먼저 더 간단한 방법인 복제에 대한 사용자 지정 충돌 해결 정책을 재정의하는 옵션을 검토할 예정이지만 이는 2.0 이후가 될 것입니다.
이제 다른 질문으로 넘어가겠습니다.
명확히 하기 위해, Couchbase Lite 2.0 클라이언트는 항상 충돌 없는 모드(CE 또는 EE)를 사용합니다. CE와 EE의 구분은 SGW 쪽에 있습니다.
자세한 내용은 다음과 같습니다.
SGW 측의 구분을 명확히 하기 위해, 2.0 클라이언트의 푸시는 항상 "충돌 없음" 모드가 됩니다. 프로토콜에 대해 너무 자세히 설명하지 않으면서도 이것이 의미하는 바는 충돌이 발생할 경우 SGW(EE 및 CE)가 수정안을 거부한다는 것입니다(블로그 게시물에서 설명한 대로). CE와 EE를 구분하는 것은 CBL 2.0이 아닌 클라이언트/REST API 클라이언트에서 업데이트가 들어올 때입니다. EE SGW는 이러한 클라이언트로부터의 충돌을 방지합니다. 그러나 비 CBL 2.0 클라이언트와 상호 작용할 때 SGW CE 모드에서 충돌이 발생할 수 있습니다. 이러한 충돌은 1.x에서 일반적인 방식으로 처리되며 CBL 2.0 클라이언트는 서버에서 승리한 리비전을 가져옵니다.

로그인 하여 답글 남기기
1. avia_bdg 3월 20, 2018에서 2:35 오후
  
  다행히도 1.x/2.x 혼합 문제는 없을 것 같으니 CE를 사용해도 괜찮을 것 같습니다.
  
  벤과 저는 풀 복제로 인한 충돌을 사용자 지정으로 해결할 수 있는 방법이 필요하다는 데 거의 동의합니다.
  
  인터넷 가용성이 희박한 환경에서 오프라인 상태이고 가끔씩 원샷 복제가 이루어지는 기기에서 Xamarin 모바일에 CBL을 적용하고 있습니다. 모바일 앱이기 때문에 사용자가 앱을 일시 중단한 후 앱을 닫고 부분 편집을 하고 싶을 때를 대비해 데이터 양식에 자동 저장 기능을 추가하는 방안을 검토 중입니다... 이는 잠재적으로 높은 수정율을 의미하며, 이는 푸시될 때까지만 로컬에 저장됩니다. 제가 몇 가지 테스트를 해본 결과, 자동 저장을 통해 두세 번 편집하면 나중에 다른 기기에서 오프라인으로 편집한 단일 수정본은 수정본 수가 적어 손실됩니다. 이것은 허용되지 않습니다. 마지막 편집(날짜별)이 더 좋을 것이고, 병합을 수행하는 사용자 정의 코드가 더 좋을 것이며, 편집 횟수(현재 자동 리졸버 알고리즘)는 이에 적합하지 않습니다.
  
  즉시 자동 저장에서 저장 횟수를 줄이거나 수동 저장으로 변경하더라도 자동 충돌 해결 알고리즘은 온라인 시나리오에서만 작동하며, 클라이언트가 오프라인에 짧거나 긴 시간(주 또는 월) 동안 오프라인에 있을 수 있고 오프라인 상태에서 많은 편집을 하거나 다른 오프라인 클라이언트와 다른 비율과 양으로 편집을 하고 이전 편집이 많으면 최신 편집이 줄어들 수 있는 오프라인 시나리오에서는 허용되지 않는다는 문제가 남습니다.
  
  로그인 하여 답글 남기기
  1. 프리야 라자고팔, 개발자 옹호자, Couchbase 3월 20, 2018에서 7:02 오후
    
    자세한 내용을 알려주셔서 감사합니다. 귀하의 피드백은 도움이 됩니다. 추가 검토를 거쳐 계속 알려드리겠습니다.
    
    로그인 하여 답글 남기기
  2. 프리야 라자고팔, 개발자 옹호자, Couchbase 3월 21, 2018에서 4:04 오후
    
    빠른 업데이트: CE/EE에 대한 참고 사항을 삭제했습니다 .... 이를 명확히 하기 위해 SGW 구성에 대한 새 섹션을 추가했습니다. CE/EE 수준에서는 구분이 없습니다.
    
    로그인 하여 답글 남기기
Nithya 4월 3, 2019에서 2:25 오전

안녕하세요 팀,

현재 카우치라이트를 2.1.2로 업데이트했습니다.
충돌을 해결하려면 서버에서 최신 개정판을 가져와야 하는데 개정판과 관련된 문서를 어떻게 얻을 수 있나요? 최신 버전에서는 개정판 ID를 얻지 못하는데 애플리케이션 수준에서 충돌을 해결하려면 어떻게 해야 하나요?

로그인 하여 답글 남기기
1. avia_bdg 4월 3, 2019에서 2:38 오전
  
  적어도 아직은 애플리케이션 수준에서 충돌을 해결할 수 없습니다. 카우치베이스는 버전 2에서 자동 충돌 해결로 전환했습니다. 다시 일부 제어를 허용하는 솔루션을 개발 중입니다.
  
  로그인 하여 답글 남기기
  1. 프리야 라자고팔 , 수석 제품 관리자 8월 27, 2019에서 2:22 오후
    
    양방향 병합을 통한 사용자 지정 충돌 해결은 이제 Couchbase Mobile 2.6에서 사용할 수 있습니다(https://docs.couchbase.com/couchbase-lite/2.6/index.html#custom-conflict-resolution)
    
    로그인 하여 답글 남기기

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

카우치베이스 모바일 2.0의 문서 충돌 및 해결 방법

가정

배경

문서 수정본 트리

문서 충돌이 발생하는 방식

카우치베이스 라이트의 충돌

동기화 게이트웨이의 충돌

카우치베이스 모바일 2.0의 충돌 해결

카우치베이스 라이트 2.0의 자동 충돌 해결

동시성 제어 정책

마지막 쓰기가 항상 승리합니다(기본값):

충돌 시 실패

충돌 시 실패 처리하기

동일한 ID로 문서 만들기에 대한 시사점

동기화 게이트웨이 2.0의 충돌 방지 모드

푸시 복제

풀 복제

지역 지사가 우승자

동기화 게이트웨이에서 충돌 없는 모드 구성하기

충돌 방지 모드가 데이터베이스 크기에 미치는 영향

감사

다음 단계

받은 편지함에서 카우치베이스 블로그 업데이트 받기

작성자

게시자 프리야 라자고팔, 제품 관리 부문 선임 이사

댓글 하나

댓글 남기기 응답 취소

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

카펠라 무료 사용

연락하기