카우치베이스 모바일 는 JSON 문서 스타일의 NoSQL 데이터 모델을 지원합니다. 표준 JSON 데이터 유형을 지원하는 것 외에도 Couchbase Mobile은 이미지, 오디오, 비디오, PDF 파일 등을 포함하는 바이너리 데이터도 지원합니다. JSON 문서는 '첨부 파일' 또는 '블롭'이라고 하는 하나 이상의 바이너리 데이터 요소와 연결될 수 있습니다. 바이너리 데이터는 동기화 게이트웨이를 통해 Couchbase Lite 클라이언트와 서버 간에 동기화할 수 있습니다. 이 글에서는 바이너리 데이터 첨부 파일을 만드는 방법과 이를 검색하고 업데이트하는 방법에 대해 설명합니다. 또한 첨부 파일이 내부적으로 어떻게 표현되는지, 관련 특이점 및 처리 방법에 대해서도 자세히 살펴봅니다.
이 게시물의 모든 내용은 Couchbase Mobile 2.x 기반 배포에 적용됩니다.
배경 첨부 파일 및 블롭
Couchbase Mobile 내에서 바이너리 데이터를 JSON 문서와 연결하기 위한 지원은 수년에 걸쳐 발전해 왔습니다. JSON 문서 내 바이너리 데이터의 내부 표현은 Couchbase Mobile 버전에 따라 변경되었습니다. Couchbase Mobile 1.x에서 바이너리 데이터는 최상위 수준 "_" 안에 "첨부 파일" 형태로 저장되었습니다.첨부 파일" 어트리뷰트. 카우치베이스 모바일은 blob 데이터 유형을 사용하여 바이너리 데이터를 저장할 수 있습니다. 대부분의 경우 버전 간 표현의 불일치는 Couchbase Mobile에서 원활하게 처리되므로 최종 사용자는 이를 처리하기 위해 앱 내에서 특별한 작업을 수행할 필요가 없습니다. 그러나 앱 개발자가 불일치를 처리하기 위해 추가 조치를 취해야 하는 경우가 있습니다. 이 글에서는 이러한 조치에 대해 논의하고 자주 묻는 몇 가지 질문에 답해 드리겠습니다.
워크플로 #1: Couchbase Lite에서 만든 첨부 파일 처리하기
Couchbase Lite를 사용하여 바이너리 데이터가 첨부된 JSON 문서를 만들고 이를 서버 측으로 동기화하는 방법을 살펴보겠습니다. 이것이 우리가 설명할 흐름입니다:
카우치베이스 라이트에서 바이너리 데이터 첨부 파일 만들기
개발자는 반드시 blob API 을 사용하여 블롭 데이터를 만들 수 있습니다. 문서는 하나 이상의 첨부파일 또는 블롭과 연결될 수 있습니다. 다음은 스위프트에서 이 API의 사용법을 보여주는 코드 스니펫입니다. 다른 플랫폼에 해당하는 코드 스니펫은 개발자 문서를 참조하세요.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
let mutableDoc = 뮤터블 도큐먼트.init(id: "사용자::프리야") 만약 let 프로필 이미지 = UIImage(명명된: "profile.jpg"), let 이미지데이터 = UIImageJPEG표시(프로필 이미지, 0.75) { let blob = Blob(콘텐츠 유형: "image/jpeg", 데이터: 이미지데이터) mutableDoc.setBlob(blob, forKey: "이미지") } // ... 다른 속성 추가 mutableDoc.setString("user", forKey: "type") mutableDoc.setString("Priya", forKey: "name") mutableDoc.setString("priya.rajagopal@couchbase.com, forKey: "이메일") do { try? db.saveDocument(mutableDoc) } catch { print("오류 in 저장 문서 : (오류)") } |
내부 대표
Couchbase Lite에서 문서가 생성되면 내부적으로 다음과 같이 표시됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "이메일": "priya.rajagopal@couchbase.com", "이미지": { "길이": 3888349, "다이제스트": "sha1-4xlj1AKFgLdzcD7a1pVChrVTJIc=", "content_type": "image/jpeg", "@유형": "blob" }, "type": "user", "name": "Priya", "id": "사용자::프리야", "rev": "1–1c8502034001b333cc469fe8c4c39e112eedf8a3" } |
주목하세요. "@유형": "blob" 이미지 유형 데이터에 대해 생성된 유형 항목입니다.
참고 와 같은 여러 시스템 수준 메타데이터가 있다는 것을 알 수 있습니다.id 문서에 포함되어 있습니다. 간결성을 위해 예제에는 모든 속성이 표시되어 있지 않습니다. 애플리케이션은 시스템 수준 메타데이터의 형식과 가용성에 대해 어떠한 가정도 해서는 안 되며, 따라서 앱은 이러한 속성에 직접 액세스해서는 안 됩니다. 항상 다음과 같은 메타데이터 검색 옵션을 사용하세요. 메타().id.
동기화 게이트웨이에 첨부 파일 동기화하기
즉, 동기화 게이트웨이는 1.x__를 사용하여 바이너리 데이터를 처리할 수 있어야 하며, 이는 동기화 게이트웨이가 Couchbase Mobile 1.x와 역호환된다는 것을 의미합니다. 첨부 파일 스타일 표현뿐만 아니라 2.x blob 유형으로 설정해야 합니다. 이는 또한 Couchbase Lite 2.x 클라이언트가 데이터를 동기화 게이트웨이로 푸시업할 때 1.x 클라이언트와 호환되는 형식으로 전송해야 한다는 의미이기도 합니다.
이러한 이유로 Couchbase Lite가 문서를 동기화 게이트웨이와 동기화할 때 동기화 게이트웨이에 _첨부 파일 항목을 문서에 추가합니다. 따라서 문서가 위로 밀려나면 아래 예시와 같은 모양이 됩니다. 문서와 연결된 첨부 파일 목록은 문서에 있는 첨부 파일 객체입니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
<em><코드>{ "첨부 파일": { "blob/이미지": { "content_type": "image/jpeg", "다이제스트": "sha1-4xlj1AKFgLdzcD7a1pVChrVTJIc=", "길이": 3888349, "revpos": 1, "stub": true } }, "이메일": "priya.rajagopal@couchbase.com", "이미지": { "@유형": "blob", "content_type": "image/jpeg", "다이제스트": "sha1-4xlj1AKFgLdzcD7a1pVChrVTJIc=", "길이": 3888349 }, "name": "Priya", "type": "user", "id": "사용자::프리야", "rev": "1–1c8502034001b333cc469fe8c4c39e112eedf8a3", }</코드></em> |
참고 와 같은 여러 시스템 수준 메타데이터가 있다는 것을 알 수 있습니다.id 문서에 포함되어 있습니다. 간결성을 위해 예제에는 모든 속성이 표시되지 않았습니다. 애플리케이션은 시스템 수준 메타데이터의 형식과 가용성에 대해 어떠한 가정도 해서는 안 되며, 따라서 앱은 이러한 속성에 직접 액세스해서는 안 됩니다. 항상 다음과 같은 메타데이터 검색 옵션을 사용하세요. 메타().id.
동기화 게이트웨이에서 첨부 파일 검색
첨부 파일 데이터는 동기화 게이트웨이를 통해 검색해야 합니다. _첨부 파일 REST 엔드포인트를 사용해야 합니다. 이 게시물을 작성하는 시점에서는 Couchbase Server SDK를 사용하여 첨부 파일을 직접 관리할 수 없습니다.
다음은 _를 사용하여 문서와 연결된 첨부파일을 검색하는 샘플 curl 명령어입니다.첨부 파일 REST 엔드포인트로 이동합니다. 인증 헤더를 시스템에 구성된 사용자에 해당하는 적절한 자격 증명으로 대체합니다. 또한 첨부 파일의 이름인 "blob_%2Fimage” is the URL encoded version of "blob/이미지"_.
|
1 2 3 4 |
curl -X GET 'http://sync-gateway-url:4984/dbname/user::priya/blob_%2Fimage' -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzpwYXNzd29yZA==' |
동기화 게이트웨이에서 첨부 파일 업데이트하기
첨부 파일 데이터는 동기화 게이트웨이를 통해 업데이트해야 합니다. _첨부 파일 REST 엔드포인트가 필요합니다. 이 게시물을 작성하는 시점에서는 Couchbase Server SDK를 사용하여 모바일 첨부 파일을 관리할 수 없습니다.
다음은 _를 사용하여 문서와 연결된 첨부 파일을 업데이트하는 샘플 curl 명령어입니다.첨부 파일 REST 엔드포인트로 이동합니다. 권한 부여 헤더를 설정에 구성된 사용자에 해당하는 적절한 자격 증명으로 대체합니다. 또한 "rev" 매개 변수를 제공해야 합니다. 이 매개변수는 업데이트할 문서의 수정본에 해당합니다. revId를 검색할 때는 GET 문서 REST.
|
1 2 3 4 5 6 |
curl -i -X PUT 'http://sync-gateway-url:4984/dbname/user::priya/blob_%2Fimage?rev=12-fa2bf00dab7e811eb562a502429ec633' -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzE6cGFzc3dvcmQ=' -H '콘텐츠 유형: 이미지/png' -H '캐시 제어: 캐시 없음' -데이터-바이너리 "@레이어드.png" |
하지만...잠깐만요...불일치입니다!
이제 첨부 파일을 업데이트한 후 문서를 검색할 때 GET 문서 REST,
|
1 2 3 4 5 6 |
curl -X GET 'http://sync-gateway-url:4984/dbname/user::priya/blob_%2Fimage' -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzE6cGFzc3dvcmQ=' -H '콘텐츠 유형: 애플리케이션/json' -H '캐시 제어: 캐시 없음' |
해당 응답은 다음과 같이 표시됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
{ "첨부 파일": { "blob/이미지": { "content_type": "image/png", "다이제스트": "sha1-XeeXt0I014+1qpH+s2S2AUSg4II=", "길이": 3444504, "revpos": 16, "stub": true } }, "id": "사용자::데모1", "rev": "13-e61d1a9e63069030212007a8b5eddde9", "주소": "", "이메일": "demo1", "이미지": { "@유형": "blob", "content_type": "image/jpeg", "다이제스트": "sha1-4xlj1AKFgLdzcD7a1pVChrVTJIc=", "길이": 3888349 }, "name": "프리야 라자고팔", "type": "user" } |
다음과 같이 _attachment 그리고 blob 항목이 일치하지 않습니다. 동안 _attachment 최신 이미지에 대한 엔트리 포인트, 즉 blob 항목은 여전히 이전 이미지를 설명합니다. 하지만 괜찮습니다.!
이러한 불일치가 발생하는 이유는 동기화 게이트웨이가 1.x 스타일 첨부 파일만 처리하기 때문입니다.
그렇다면 여전히 어떻게 작동할까요?
이는 1.x 스타일 첨부파일을 처리하는 동기화 게이트웨이의 컨텍스트 내에서 첨부파일 항목만 존중되기 때문에 작동합니다.
하지만 Couchbase Lite는 어떨까요? 업데이트된 문서가 Couchbase Lite 2.x 클라이언트에 의해 동기화되면 어떻게 되나요?
CouchBase Lite 2.x 클라이언트에 의해 문서가 복제되면 CouchBase Lite는 다음 항목이 있는지 찾습니다. 첨부 파일 그리고 blob 문서 내에서 적절한 로직을 구현하여 이 문서가 2.x 클라이언트에서 작성되었지만 이후 1.x 클라이언트(예: 동기화 게이트웨이 REST API)에 의해 업데이트된 2.x 스타일 문서임을 식별합니다. 따라서 첨부 파일 항목을 "실제" 첨부 파일로 지정하고 해당 블롭 항목을 통합합니다.
개발자의 입장에서는 이 모든 것이 자동으로 처리됩니다. 따라서 세부 사항에 대해 걱정할 필요가 없습니다. 개발자는 Couchbase Lite 지원 앱 내에서 업데이트된 첨부 파일을 검색하는 방법을 알고 있어야 합니다.
Couchbase Lite에서 업데이트된 첨부 파일 검색
업데이트된 첨부 파일이 카우치베이스 라이트 앱에 동기화되면, 카우치베이스 앱의 블롭 API 를 사용하여 데이터를 검색할 수 있습니다. 다음은 이 API의 사용법을 스위프트에서 보여주는 코드 스니펫입니다. 다른 플랫폼에 해당하는 코드 스니펫은 개발자 설명서를 참조하세요.
|
1 2 3 4 5 6 |
만약 let doc = db.문서(withID: "사용자::프리야") { let blobValue = doc.blob(forKey:"이미지")?.콘텐츠 // blobValue 사용 } |
이제 그 반대의 흐름을 살펴보겠습니다.
워크플로 #2: 동기화 게이트웨이에서 생성된 첨부 파일 처리
동기화 게이트웨이에서 바이너리 데이터가 첨부된 JSON 문서를 만들고 이를 Couchbase Lite 측으로 동기화하는 방법을 살펴보겠습니다.
이것이 우리가 설명할 흐름입니다.
서버에서 바이너리 데이터 첨부 파일 만들기
동기화 게이트웨이를 통해 클라이언트에 동기화할 수 있는 바이너리 데이터를 카우치베이스 서버 측에 첨부하려면, 동기화 게이트웨이를 사용해야 합니다. 첨부 파일 REST 엔드포인트. 이 게시물을 작성하는 시점에 모바일 호환 첨부 파일은 Couchbase Server SDK를 사용하여 직접 만들 수 없습니다. 동기화 게이트웨이 REST 엔드포인트를 통해 생성된 첨부 파일 데이터는 Couchbase Server 버킷에 유지되며 동기화 게이트웨이에 구성된 액세스 제어 정책에 따라 Couchbase Lite 클라이언트로 동기화됩니다.
이렇게 하려면 먼저 문서를 만들거나 이전에 만든 문서를 검색한 다음 문서에 대한 첨부파일을 만듭니다. 또는 JSON과 바이너리 데이터가 모두 포함된 여러 부분으로 구성된 문서를 만들 수도 있습니다. 하지만 관련 첨부 파일 메타데이터도 생성해야 하므로 번거로울 수 있습니다. 따라서 아래에 설명된 단계가 제가 선호하는 옵션입니다.
- 문서 만들기
JSON 문서는 Couchbase Server SDK 또는 관리자 UI를 사용하여 Couchbase Server에서 직접 만들거나 다음을 사용하여 만들 수 있습니다. PUT 문서 REST API. Couchbase Lite 클라이언트에서 문서를 동기화할 수도 있습니다.
다음은 Id가 있는 문서를 만들기 위해 동기화 게이트웨이 REST 엔드포인트를 사용하는 예입니다. "사용자::제인". 권한 부여 헤더를 설정에 구성된 사용자에 해당하는 적절한 자격 증명으로 대체할 수 있습니다.
|
1 2 3 4 5 6 7 8 9 10 |
curl -X PUT 'http://sync-gateway-url:4984/dbname/user::jane/' -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzpwYXNzd29yZA==' -H '콘텐츠 유형: 애플리케이션/json' -d '{ "이메일": "jane.doe@example.com", "type": "사용자", "이름": "신원 미상" }' |
응답은 아래와 같이 표시됩니다:
|
1 2 3 4 5 |
{ "id": "사용자::제인", "ok": true, "rev": "1-ed2d37e7ece0dc5726fecd211433cbba" } |
- 동기화 게이트웨이에서 문서에 대한 첨부 파일 만들기
첨부 파일 데이터는 동기화 게이트웨이를 통해 생성해야 합니다. _첨부 파일 REST 엔드포인트로 이동합니다. 이 단계는 REST 엔드포인트를 통해 첨부파일을 업데이트할 때의 이전 흐름과 동일합니다.
다음은 _를 사용하여 문서와 연결된 첨부 파일을 업데이트하는 샘플 curl 명령어입니다.첨부 파일 REST 엔드포인트로 이동합니다. 권한 부여 헤더를 설정에서 구성된 사용자에 해당하는 적절한 자격 증명으로 대체합니다. 인증 헤더의 "rev" 매개 변수를 제공해야 합니다. 이 매개 변수는 업데이트할 문서의 수정본에 해당합니다.
|
1 2 3 4 5 6 |
curl -i -X PUT 'http://sync-gateway-url:4984/dbname/user::jane/blob_%2Fimage?rev=1-ed2d37e7ece0dc5726fecd211433cbba' -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzE6cGFzc3dvcmQ=' -H '콘텐츠 유형: 이미지/png' -데이터-바이너리 "@레이어.png" |
내부 대표
동기화 게이트웨이에 의해 문서가 업데이트되면 다음과 같이 표시됩니다.
문서를 검색하는 경우 GET 문서 REST,
|
1 2 3 4 5 6 |
curl -X GET 'http://sync-gateway-url:4984/dbname/user::jane/blob_%2Fimage' -H '수락: application/json' -H 'Authorization: 기본 ZGVtbzE6cGFzc3dvcmQ=' -H '콘텐츠 유형: 애플리케이션/json' -H '캐시 제어: 캐시 없음' |
해당 응답은 다음과 같이 표시됩니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<em><코드>{ "첨부 파일": { "blob/이미지": { "content_type": "image/png", "다이제스트": "sha1-VteI8PPA3tFVxeW8z2qoJpQo40Y=", "길이": 1768, "revpos": 2, "stub": true } }, "id": "사용자::제인", "rev": "2–95da324bd67db252d8b682cd113e3879", "이메일": "jane.doe@example.com", "type": "user", "name": "제인 도" }</코드></em> |
동기화 게이트웨이의 첨부파일 REST API를 사용하여 첨부파일을 만들면 첨부파일이 1.x 스타일로 표현됩니다. 2.x 스타일의 "블롭" 메타데이터가 없다는 점에 유의하세요. 이는 Couchbase Lite에서 문서에 액세스할 때 주의해야 할 중요한 사항입니다.
Couchbase Lite에서 업데이트된 첨부 파일 검색
이전에 생성된 문서가 Couchbase Lite 측으로 동기화되면 1.x 스타일 문서임을 감지하고 첨부 파일 항목을 그대로 유지합니다. 안에 중첩된 객체를 처리합니다. 첨부 파일 항목을 블롭으로 추가합니다. 그러나 추가된 '블롭' 항목을 포함하도록 문서가 자동으로 업데이트되지는 않습니다. 따라서 앱에서 블롭의 존재 여부를 확인하려면 블롭 API 두 위치 모두에 있습니다.
|
1 2 3 4 5 6 7 8 9 10 11 |
// 먼저 최상위 블롭 항목에서 블롭을 찾습니다. 만약 let imageVal = userVal.blob(forKey:"이미지")?.콘텐츠 { // imageVal에는 첨부 파일이 포함됩니다. } else { // 동기화 게이트웨이 API를 통해 생성된 첨부 파일로 캠퍼빌리티 처리하기 // 해당 첨부 파일은 1.x 스타일로 생성됩니다. let 첨부 파일 = userVal.사전(forKey: "첨부 파일") let imageVal = 첨부 파일?.blob(forKey:"blob/이미지")?.콘텐츠 // imageVal에는 첨부 파일이 포함됩니다. } |
자주 묻는 질문
마무리로, Couchbase Mobile에서 첨부 파일 처리와 관련하여 자주 묻는 질문 목록을 정리해 보았습니다.
첨부 파일은 어디에 저장되나요?
Couchbase Lite에서 첨부 파일은 해당 문서가 포함된 Couchbase Lite 데이터베이스 인스턴스에 저장됩니다. 첨부 파일은 첨부 파일에 대한 참조를 담고 있는 관련 메타데이터가 포함된 문서와는 별도로 저장됩니다. 동일한 첨부 파일이 여러 문서에서 공유되는 경우 첨부 파일의 단일 인스턴스만 데이터베이스에 저장됩니다.
Couchbase Server에서 첨부 파일은 해당 문서와 동일한 Couchbase Server 버킷에 저장됩니다. 첨부 파일에 대한 참조를 담고 있는 관련 메타데이터가 포함된 문서와는 별도로 저장됩니다. 동일한 첨부파일이 여러 문서에서 공유되는 경우에는 첨부파일의 단일 인스턴스만 버킷에 저장됩니다.
문서에 연결할 수 있는 첨부 파일의 수에 제한이 있나요?
JSON 문서에 하나 이상의 첨부파일을 첨부할 수 있습니다. 문서에 연결할 수 있는 첨부 파일의 수에는 엄격한 제한이 없습니다. 그러나 첨부 파일 메타데이터는 문서 xattrs에 저장되므로(shared_bucket_access가 활성화된 경우) 첨부 파일 수는 문서당 허용되는 동기화 메타데이터 크기에 의해 제한됩니다. 첨부 파일 메타데이터는 100-200바이트이고 동기화 메타데이터 크기 제한은 문서당 1MB이므로 문서에 연결할 수 있는 첨부 파일 수에는 실질적인 제한이 있습니다.
첨부 파일의 최대 크기는 어떻게 되나요?
각 첨부 파일의 최대 크기는 20MB입니다. 이는 Couchbase Server의 문서 크기 제한에 따른 것입니다. Couchbase Lite 자체에서는 20MB보다 큰 크기의 첨부 파일을 허용하며, 첨부 파일이 로컬 전용이고 서버에 동기화되지 않도록 보장되는 한 괜찮습니다. 그러나 개발자는 동기화 게이트웨이에서 거부될 수 있으므로 이러한 대용량 첨부 파일을 만들지 않도록 주의해야 합니다.
연결된 JSON 문서가 변경될 때마다 첨부파일이 동기화되나요?
복제 프로토콜은 첨부파일에 업데이트가 있을 때만 동기화하도록 최적화되어 있습니다. 즉, 연결된 JSON 문서에 다른 데이터에 대한 업데이트가 있더라도 Couchbase Lite 클라이언트에 의해 푸시되거나 풀리지 않습니다.
첨부 파일을 동기화할 때 프로토콜은 실패를 어떻게 처리하나요?
이 프로토콜은 네트워크 중단으로 인한 동기화 실패를 처리하는 측면에서 매우 강력합니다. 연결된 모든 첨부파일 또는 블롭이 성공적으로 동기화될 때까지 문서는 동기화 게이트웨이 또는 Couchbase Lite에서 유지되지 않습니다. 따라서 연결된 문서가 없는 고아 첨부파일/블로그로 끝날 수 있는 시간이 있을 수 있습니다. 이후 문서를 동기화하면 첨부파일이 이미 유지된 것으로 인식하고 다시 동기화를 시도하지 않으므로 문제가 되지 않습니다.
다음 단계
카우치베이스 모바일은 첨부파일을 관리할 수 있는 사용하기 쉬운 인터페이스를 제공합니다. 자세한 내용은 문서 에서 각 플랫폼의 블롭 처리에 대한 자세한 내용을 확인하세요.
질문이나 피드백이 있으시면 아래에 댓글을 남기거나 다음을 통해 언제든지 저에게 연락해 주세요. 트위터 또는 이메일 보내기. . 카우치베이스 개발자 포럼 는 카우치베이스 개발 커뮤니티에 참여할 수 있는 좋은 장소입니다.
안녕하세요 프리야,
가능한 경우 FAQ에 대한 또 다른 질문이 있습니다.
블롭이나 첨부파일은 바이너리이므로 처리, 검색, 압축, Diff 등을 할 수 없습니다. 고유한 파일명을 가진 폴더가 아닌 거대한 데이터베이스에 저장되는 이유는 무엇인가요?
데이터베이스-문서-콘텐츠를 관리하는 웹사이트가 포함된 폴더를 여러 노드에 복제할 수 있나요?
안녕하세요
사용 사례에 따라 다릅니다. 대량의 바이너리 데이터에 대해 이야기하는 경우 외부 CDN/스토어에 저장하는 것이 선호되는 옵션입니다. 이 경우 바이너리 데이터를 Couchbase 서버 외부에 저장하고 문서에 참조 URL을 포함시킵니다. 앱은 이러한 변경 사항이 감지되면 첨부 파일을 내리고 올리고 문서에 대한 해당 참조를 업데이트할 책임이 있습니다.
바이너리 첨부파일을 '문서'로 취급하면 동기화 프로토콜에 의해 푸시 및 풀이 처리되므로 (최종적인) 일관성이 보장된다는 이점이 있습니다. 저희는 첨부파일의 변경 사항을 감지하고 필요할 때마다 변경 사항을 내리는 작업을 처리합니다.
서버 버킷에 저장하는 것을 우회하기 위해 외부 저장소에 첨부 파일을 저장하도록 선택하더라도 오프라인 우선 기능을 원하는 경우 클라이언트가 오프라인 상태에서도 사용할 수 있도록 Couchbase lite에서 첨부 파일을 로컬로 유지해야 합니다.
참고로 바이너리 데이터는 압축이 잘 됩니다.
안녕하세요 프리야,
카우치베이스 서버 SDK에 첨부 파일(블롭)을 직접 추가하는 옵션이 제공되지 않고 동기화 게이트웨이를 거쳐야 하는 이유를 이해할 수 없습니다. 이에 대해 자세히 설명해 주시겠어요? 향후 릴리스에 해당 기능을 추가할 계획이 있나요?
최고,
PShri
안녕하세요
카우치베이스 라이트 클라이언트와 동기화할 수 있는 바이너리 데이터를 생성하기 위해 CBS SDK를 사용하는 것에 대한 지원이 시작되었습니다. 그 동안 일반적인 패턴은 SDK를 통해 문서를 만들고 동기화 게이트웨이 REST 엔드포인트를 사용하여 첨부파일/바이너리 데이터를 연결하는 것이었습니다.
CBS SDK에 언제 추가되는지 어떻게 알 수 있나요? 구독하고 이에 대해 알아볼 수 있는 곳이 있나요? 시간을 내어 답변해 주셔서 감사합니다.
질문을 잘 이해하지 못했습니다. 서버 버킷에 문서를 작성하는 동일한 SDK 클라이언트가 REST 엔드포인트를 사용하여 첨부 파일을 연결/생성할 책임이 있습니다. 따라서 문서와 첨부 파일을 만들기 위해 한 번만 호출하는 대신 SDK 클라이언트는 버킷에 문서를 만들기 위해 INSERT/UPSERT 호출을 한 다음 문서와 연결된 첨부 파일을 만들기 위해 _attachment REST API를 호출하는 두 번의 호출을 수행합니다.
안녕하세요 프리야,
대용량 첨부파일(20MB 이상)을 지원할 수 있는 다른 방법을 제안할 수 있나요?
20MB보다 큰 첨부 파일을 분할할 수 있나요?
고마워요
대용량 첨부파일이 있는 경우 외부 CDN에 저장하고 문서에 URL을 넣는 것이 좋습니다. 이러한 대용량 바이너리 데이터를 데이터베이스에 저장하고 싶지는 않을 것입니다. 앱에서 첨부파일을 관리할 책임이 있습니다. 첨부 파일을 청크하고 병합하는 기본 제공 메커니즘은 없습니다.