현재 진행 중인 교육 시리즈에서 매번 여러 가지 질문이 나오는데, 아래에 각 질문에 대한 답변을 나열해 보았습니다!
Couchbase 102 - SDK 운영
언어별 연산 개념: https://github.com/couchbaselabs/개발자의 날
질문: 이러한 작업은 모바일 애플리케이션에서도 동일하게 적용되나요?
A: 아니요, 둘은 동일하지 않습니다. Couchbase Lite에는 자체 API가 있습니다. iOS용 Couchbase Lite 베타 2 API 문서는 여기에서 확인할 수 있습니다: https://couchbase.github.io/couchbase-lite-ios/docs/html/annotated.html
질문: 모든 작업이 유지된다는 것을 보장할 수 있나요? 즉, CouchBase에 대한 풋이 반환되면 CouchBase가 서버에서 데이터가 디스크 대기열과 복제 대기열에 있는 동안 하드 크래시가 발생합니다. 이를 보장하기 위해 어떤 메커니즘이 사용되나요?
A: 아니요, 그렇게 보장할 수 없습니다. 클라이언트에 성공적인 작업이 표시될 수는 있지만 서버가 복제되거나 지속되기 전에 하드 크래시가 발생할 수 있습니다. 하드 크래시에서 안전한 시스템은 없습니다. 저희는 데이터 손실을 최소화하고 높은 성능을 유지하려고 노력합니다. 복제 및 장애 조치를 통해 이를 달성할 수 있으며, 노드 장애 시에도 복제본을 신속하게 홍보하고 클러스터와 애플리케이션을 계속 유지할 수 있습니다. 문서 작업별로 스토리지 작업에 대한 내구성 관찰을 제공하지만, 문서가 복제되거나 보존되거나 둘 다 보존된 경우에만 콜백을 받습니다. 이는 작업 지연 시간을 증가시키므로 모든 작업에 사용하는 대신 필요할 때 사용하는 것이 가장 좋습니다.
질문: Observe와 함께 스토리지를 사용하면 오버헤드가 많이 발생할 것 같은데, Jasdeep에서 몇 가지 수치(포함 및 제외 비율)를 알려주실 수 있나요?
A: 하드웨어와 수평적 규모에 따라 달라지기 때문에 정확한 수치를 제시할 수 없습니다. 제가 말씀드릴 수 있는 것은 쓰기량이 많은 경우 특히 모든 스토리지 작업에 대해 두 번 생각할 만큼 충분히 중요하다는 것입니다.
질문: 두 데이터 센터에서 정확히 동시에 새로운 K-V 쌍(키는 같지만 값이 다른)이 동시에 삽입되는 경우 어떻게 되나요? 이 경우 캐시에 기록되고 있기 때문에(즉, XDCR 대기열이 여전히 뒤처져 있기 때문에) 실제로 "일관성"을 유지할 수 없겠죠? 이 충돌은 어떻게 처리되나요?
A: 일관성만 적용됩니다. 내 클러스터의 경우, 데이터가 이동해야 하기 때문에 XDCR은 정의상 결국 일관성이 있습니다. 사이 클러스터를 가로질러야 합니다. 질문에 답하기 위해 Couchbase 105 교육 웨비나에서 XDCR 충돌 해결 규칙을 다루었는데, 현재로서는 충돌 해결 로직이 다소 간단합니다. 충돌 해결 로직은 보편적으로 작성하기 어려운 것으로 악명이 높습니다. 귀하의 시나리오에서는 두 문서가 모두 새 문서이고, 각각 한 번만 생성되었으며, 양방향 XDCR을 사용하여 동시에 두 클러스터에 작성되었으므로 "무작위"로 "승자"가 선택됩니다. 충돌 해결 규칙은 다른 기준과 함께 문서의 수정본 수와 관련이 있습니다.
질문: XDCR로 여러 클러스터에 걸쳐 문서를 잠글 수 있나요?
A: 아니요, 문서 잠금은 클러스터 전체가 아닌 Couchbase 클러스터에만 로컬로 적용됩니다.
질문: 문서에서 몇 가지 항목을 수정/업데이트하려는 경우 특정 항목/필드를 수동으로 찾아 업데이트하는 대신 자바(또는 다른 언어) 코드를 작성하여 이를 수행하려면 어떻게 해야 하나요?
A: 이것은 사실 매우 일반적인 사용법입니다. Java를 사용하는 경우 JSON을 객체로 트랜스코딩/마샬링 해제하고, 값을 수정한 다음, 바꾸기 작업을 위해 다시 JSON으로 트랜스코딩/마샬링합니다. Couchbase 서버 측의 문서에 대한 부분 업데이트를 위한 API는 없으며, 클라이언트와 Couchbase 서버 간에 항상 전체 문서를 주고받습니다. 즉, 부분적인 JSON 수정 사항을 Couchbase 서버로 전송하고 서버가 문서를 가져와 부분적인 변경 사항을 업데이트하도록 할 수 없습니다.
질문: 동일한 박스에서 서로 다른 두 가지 버전(예: v2.0.1과 v2.2)의 Couchbase가 공존할 수 있나요?
A: 둘 다 설치할 수는 있지만 클러스터에서 둘 다 실행하는 것은 가능하지만 까다롭고 확실히 비표준적인 사용 방법입니다. 두 번째 서버가 클러스터링할 수 있도록 모든 포트 매핑과 기대치를 변경해야 합니다. 일반적으로는 그만한 노력의 가치가 없다고 말하고 싶습니다. Docker에 익숙하다면 core.os를 사용하여 Docker에서 클러스터를 만들 수 있습니다.
질문: 삽입/업데이트 작업은 전체 컬렉션 또는 문서에 잠금을 생성하나요? 카우치베이스는 콜/문서에 대한 읽기 작업을 허용하나요?
답변: 기본적으로 잠그지 않습니다. 개별 문서는 최대 30초의 자동 시간 제한이 있는 GetWithLock 작업을 통해 쓰기를 잠글 수 있습니다. "컬렉션"이라는 개념이나 컬렉션 잠금, 버킷(데이터베이스) 잠금도 없습니다. 일반적으로 최적의 동시성을 위해 CAS 연산을 사용하는 것이 잠금보다 훨씬 나은 방법이며, 잠금은 CAS로 충분하지 않을 수 있는 특정 사용 사례나 주어진 시간 동안 수정을 실제로 방지해야 하는 경우에만 실제로 필요합니다. 읽기/쓰기를 위해 잠글 필요는 없습니다.
질문: 이미지/비디오 파일용으로 몽고DB에 있는 gridFS와 같은 것이 있나요?
A: 문서를 별도의 조각으로 나누지 않습니다. 하지만 사용 사례에 따라 필요한 경우 애플리케이션 내에서 이 작업을 수행할 수 있습니다.
질문: 카우치베이스 서버에 JSON 문서의 대량 업로드 기능이 있나요? 엔터프라이즈 시스템(데이터 저장소)의 변경 내용을 Couchbase로 복제하고 싶습니다.
A: 일부 SDK에는 멀티 세트가 있지만 일반적으로 사람들은 이를 스크립트로 작성합니다. 운영 작업을 하는 것은 운영 작업을 하는 것이므로 일반적으로 스크립트 언어보다는 병렬화할 수 있는 방법을 찾고 가장 빠른 코딩 VM이나 언어(Java/C)를 사용하는 것이 좋습니다. 예를 들어 JSON의 소스가 파일인 경우, 이 도구는 기본적으로 c 라이브러리를 사용하므로 명령줄 도구인 cbtransfer를 사용하면 질문하신 내용 중 일부를 수행할 수 있습니다.
Q: 자바 코드에서 "https://127.0.0.1:8091/pools"에 풀을 지정할 때 풀이란 무엇인가요?
A: 연결 URI의 일부일 뿐입니다. Java에서는 IP:Port 대신 이 구문을 오랫동안 사용해 왔습니다. 이는 저희의 첫 번째 SDK 클라이언트 중 하나였습니다. 여러 개의 풀에 대한 '아이디어'를 허용했지만 실제로는 하나만 존재합니다. 다른 SDK는 IP:Port 구문만 사용하고 URI 자체에 풀/기본/{버킷} 부분을 추가하는데, Java도 마찬가지로 그렇게 하고 있습니다.
Q: CAS가 어떻게 작동하는지 자세히 설명해 주시겠어요? WCAS 값이 일치하지 않는 경우?
답변: 문서를 저장하거나 문서를 수정(만료 변경)할 때마다 문서와 연결된 새로운 긴 정수 값이 생성됩니다(메타데이터에). 이 값은 CRC 검사 또는 MD5 해시와 유사하게 문서의 현재 상태를 나타냅니다. 바꾸기 작업을 수행하면서 문서에 대해 마지막으로 검색한 CAS 값을 제공하면 이 값이 일치하면 작업이 진행됩니다. 일치하지 않으면 CAS 불일치 오류가 발생하며, 이는 문서가 수정되어 현재 다른 CAS를 가지고 있음을 의미합니다. 그러면 해당 경쟁 조건을 처리할 수 있습니다. 이를 낙관적 동시성이라고 부르는데, 이를 처리하는 데 서버 리소스가 필요하지 않기 때문에 즉, 잠금이 필요하지 않기 때문입니다.
질문: 클러스터에 존재하는 복제본의 내구성 파라미터를 >로 세트를 만들면 어떻게 되나요?
A: 오류 :).
질문: 전체 문서 크기의 최대 한도는 얼마인가요? 이진 데이터를 저장할 때 Value로 데이터를 저장할 수 있는 최대 한도는 얼마인가요?
A: 두 경우 모두 20MB입니다. 대용량 파일(대부분 동영상)을 저장하고 배포하기 위한 훨씬 더 스마트한 CDN 기반 솔루션이 있기 때문에 이보다 더 큰 용량을 Couchbase에 저장하고 싶지 않을 것입니다. 이러한 경우 파일 메타데이터는 파일 링크가 포함된 JSON으로 Couchbase에 저장하고 실제 파일은 CDN에 저장합니다. 또한 저희 창립자 중 한 명이 작성한 Couchbase를 사용하는 이중화 분산 파일 저장소와 같은 오픈 소스 S3인 CBFS를 확인할 수도 있습니다: https://github.com/couchbaselabs/cbfs
Q: 모든 문서가 RAM에 들어갈 수 있도록 서버를 구성하는 것이 좋다고 계속 말씀하십니다. SSD 디스크와 낮은 램을 사용하면 어느 정도 성능 저하가 발생하나요?
A: 상황에 따라 다릅니다. 쓰기량이 많고 버킷 RAM 할당량을 모두 채운 경우, RAM에서 활성 문서를 꺼내어 RAM에 공간을 확보하고 새 문서를 디스크에 쓰는 등 문서를 디스크로 옮기려는 경쟁 프로세스가 발생할 수 있습니다. SSD 레이드를 통해 충분한 디스크 I/O를 확보하여 RAM을 다시 채우는 것보다 더 빠르게 활성 문서를 꺼낼 수 있다는 측면에서 쓰기 볼륨을 초과할 수 있다면 가능합니다. 수평으로 확장하면 많은 노드가 동시에 내보내므로 이론적으로 쓰기 볼륨을 능가할 수 있으므로 가능성이 더 높습니다! 그렇지 않은 경우, 클라이언트에서 작업을 '백 오프'하고 다시 시도하라는 임시 OOM 오류가 발생합니다.
질문: 바이너리 데이터(이미지, PDF 등의 파일)는 어떻게 저장하나요?
A: 아래 다음 질문을 참조하세요... :)
질문: Couchbase에 사진을 저장할 때 어떤 일이 발생하나요?
A: Couchbase에서는 두 가지 방법으로 사진을 저장할 수 있는데, 하나는 바로 바이너리 데이터를 문서 값으로 저장하는 것입니다. 두 번째 옵션은 JSON 문서 내에 미리 인코딩된 베이스64로 저장하는 것입니다. 즉, 하나 이상의 이미지가 JSON 값으로 인코딩된 표준 JSON 문서(JSON 키 포함)로 저장하는 것입니다. 이 경우의 장점 이미지 저장 의 가장 큰 장점은 디스크가 아닌 RAM에서 제공되므로 성능이 매우 뛰어나다는 것입니다. 이를 XDCR(데이터 센터 간 복제)과 결합하면 이미지용 CDN을 직접 만들 수 있습니다!
질문: 여러 문서를 수정/업데이트하고 그 중 하나에서 오류가 발생하면 어떻게 롤백하나요?
A: 카우치베이스에서는 다음 트랜잭션에 대해 낙관적(CAS) 또는 비관적(잠금) 동시성을 매우 쉽게 사용할 수 있습니다. 단일 문서를 사용할 수 있지만, 단일 '트랜잭션'에 여러 문서가 있는 경우에는 2단계 커밋이라는 것을 사용해야 합니다. 자세한 내용은 여기에서 확인할 수 있습니다: https://www.couchbase.com/docs/couchbase-devguide-2.0/two-phase-commits.html
질문: 카우치베이스에서 거래가 가능한가요?
답변: 이전 질문과 마찬가지로 (CAS - 비교 및 스왑) 또는 가져오기 및 잠그기를 사용하여 단일 문서 트랜잭션을 쉽게 수행할 수 있습니다.
질문: 기본 디스크에 쓴 후 실패한 삽입/업데이트 목록으로 콜백하는 일괄 삽입/업데이트 작업이 있나요?
A: 일부 SDK(예: Python)에는 다중 집합 유형 연산이 있지만(모두 다중 get 연산이 있음), 저희는 다중 집합 및 관찰 유형 연산을 지원하지 않는 것으로 알고 있습니다.
질문: 이름, 날짜, 상태와 같이 전달할 매개변수가 여러 개 있는 쿼리를 만들려면 어떻게 해야 하나요? SQL의 "where"처럼요?
A: 뷰(인덱스)를 사용하여 여러 매개변수를 쿼리하려면 별도의 뷰를 쿼리하고 애플리케이션 내에서 교차 작업을 수행하거나 인덱스 키를 창의적으로 사용하여 범위 쿼리를 수행해야 할 수 있습니다. 이를 위한 여러 가지 전략이 있으며, 사용 사례와 문서 디자인에 따라 간결하게 답변할 수 있는 방법이 달라집니다.
질문: Go나 Clojure와 같은 다른 언어도 지원하나요?
A: 네! Go용 커뮤니티 에디션이 있습니다(https://github.com/dustin/go-couchbase)의 모든 고객 페이지에서 모든 커뮤니티 고객을 확인할 수 있습니다: https://www.couchbase.com/communities/all-client-libraries 커뮤니티 클라이언트 라이브러리는 지원 계약에 의해 공식적으로 지원되지 않지만 IRC 또는 트위터를 통해 엔지니어의 도움을 쉽게 찾을 수 있습니다.
질문: 키 패턴이 조회수보다 빠른가요?
A: 키 패턴을 실제로 사용할 수 있는 대부분의 경우, 예. 왜냐하면 키 패턴은 RAM 캐시에서 데이터가 나오는 바이너리 소켓 작업이기 때문입니다. 데이터가 분산되고 데이터 배포를 담당하는 클러스터의 각 노드에서 인덱싱이 이루어지기 때문입니다, 보기를 사용하려면 클러스터의 모든 노드에 쿼리를 분산하고 클러스터의 모든 노드에서 결과를 수집해야 합니다. 이는 단일 키에 대한 영구 바이너리 소켓 연결을 통해 Couchbase의 단일 노드로 직접 이동하여 바이너리 CRUD 작업을 수행하는 것보다 항상 느립니다. 따라서 키 패턴이 뷰보다 빠릅니다. 하지만 모든 문제를 키 패턴으로 해결할 수 있는 것은 아니기 때문에 뷰가 존재하는 것입니다. 보기의 일반적인 사용 사례는 보기를 쿼리한 다음 필요한 경우 보기 결과 집합의 문서에 대한 다중 가져오기 작업을 수행하는 것입니다. 보다 복잡한 쿼리가 필요한 사용 사례에서는 보기가 그 다음 해답이며, 보다 유연한 검색이 필요한 사용 사례에서는 Elastic Search 통합이 그 해답입니다. 저희는 Couchbase 쿼리 언어(N1QL)의 애드혹 쿼리를 위해 현재 개발자 프리뷰 버전에 있으며, 쿼리를 위한 또 다른 흥미롭고 강력한 선택지이기도 합니다.
