MongoDB에서 Couchbase 서버로 이동(재방문)

애플리케이션이 MongoDB에 JSON 형식의 문서를 저장하고 있을 가능성이 높으므로 여기서부터 시작하겠습니다.

MongoDB는 바이너리 JSON과 유사한 형식인 BSON 형식으로 데이터를 저장합니다. 마이그레이션 시 주요 차이점은 BSON이 추가 유형 정보를 기록한다는 것입니다.

다음과 같은 도구를 사용하여 MongoDB에서 데이터를 내보내는 경우 몽고 수출를 입력하면 도구는 해당 유형 정보를 확장 JSON이라는 형식으로 보존하는 JSON을 생성합니다.

확장 JSON의 예시를 살펴보겠습니다:

보시다시피 확장 JSON은 여전히 유효한 JSON입니다. 즉, Couchbase Server를 사용하여 저장, 색인, 쿼리 및 검색할 수 있습니다. 그러나 애플리케이션 계층에서 추가 유형 정보를 유지 관리해야 합니다(예를 들어, 위 예제에서 확장 JSON은 긴 정수를 문자열로 저장하고 있습니다).

또는 확장 JSON을 Couchbase Server로 가져오기 전(또는 가져온 후)에 표준 JSON으로 변환할 수도 있습니다. N1QL 쿼리의 경우 이 작업은 비교적 간단하지만 지루할 수 있습니다. 다음은 위의 "myInt" 필드를 표준 JSON 숫자 필드로 변환하는 예제입니다:

그 결과는 다음과 같습니다:

몽고DB와 카우치베이스 서버 모두 불투명 바이너리 데이터를 저장할 수 있습니다.

바이너리 데이터의 내부 표현은 둘 간에 크게 다르지만, MongoDB에 저장하던 바이너리 데이터를 Couchbase Server에 계속 저장할 수 있습니다.

가장 큰 차이점은 카우치베이스 서버는 최대 20MB 크기의 바이너리를 저장할 수 있는 반면, 몽고DB는 매우 큰 파일을 여러 문서로 분할하는 편리한 계층을 제공한다는 점입니다.

데이터베이스에 대용량 바이너리를 저장하는 것에 반대하는 강력한 주장이 있습니다.. 대용량 바이너리가 많은 경우 전용 오브젝트 스토리지 서비스를 사용하여 바이너리를 저장하고 Couchbase를 사용하여 해당 바이너리의 메타데이터를 보관하는 것을 고려할 수 있습니다.

카우치베이스 서버는 클러스터의 노드 간에 해시 공간을 자동으로 분배하여 데이터를 샤딩하고 수평적으로 확장합니다.

그런 다음 문서의 키를 사용하여 해당 문서가 해시 공간의 어느 위치에 있는지, 즉 클러스터의 어느 노드에 있는지 결정합니다. 개발자는 클라이언트 SDK를 통해 이 과정을 추상화할 수 있습니다.

몽고DB를 사용하려면 샤딩 방법과 샤드 키를 선택해야 합니다. 샤드 키는 문서 내부의 인덱싱된 필드로, 클러스터에서 문서가 있는 위치를 결정합니다.

여기서 가장 큰 차이점은 Couchbase Server는 모든 샤딩을 자동으로 처리하는 반면, MongoDB는 샤딩 방법과 샤드 키를 사용자가 선택할 수 있다는 점입니다. 애플리케이션이 클러스터 전체에 걸쳐 특정 데이터 배포에 의존하는 경우, Couchbase에서 사용하는 해시 기반 배포를 허용하도록 애플리케이션을 조정해야 합니다.

해시 기반 샤딩은 MongoDB에 비해 확장을 크게 간소화합니다. 개발자의 입장에서는 이것이 자신과 상관없고 운영상의 문제라고 생각할 수도 있습니다. 하지만 소프트웨어 사용량이 늘어날 경우 Couchbase Server에 더 쉽게 의존할 수 있다는 의미이기도 합니다.

카우치베이스 서버는 각 문서의 활성 복사본 하나를 유지한 다음 최대 3개의 복제본을 유지하며, 버킷 전체 또는 작업별로 복제본 수를 구성할 수 있습니다.

즉, 정상적인 작업 중에는 문서에 쓰고 읽을 때마다 동일한 실시간 사본을 처리하게 됩니다. 따라서 충돌하는 버전의 문서를 처리할 필요가 없습니다. 복제본은 활성 사본을 사용할 수 없을 때만 작동합니다.

개발자는 문서의 배포와 복제가 추상화되어 있습니다. 버킷에 대한 연결을 사용해 쓰고, 읽고, 쿼리하면 데이터가 저장된 위치를 SDK가 정확하게 처리합니다. 복제 세트나 샤딩 체계를 고려할 필요가 없습니다.

만약 당신이 CAP 정리를 사용하면 일관성을 선호하는 것이 가용성에 영향을 미친다는 것을 알 수 있습니다. 노드에 장애가 발생하면 클러스터가 적절한 복제본을 활성 상태로 승격할 수 있도록 잠시 동안 활성 문서를 사용할 수 없게 됩니다. 코드에서는 실패한 작업을 다시 시도하기만 하면 됩니다.

카우치베이스 서버는 크게 두 가지 유형의 인덱스를 제공합니다:

MongoDB 서버가 한 대 이상으로 늘어나면 라우터 프로세스를 도입하고 서버를 구성해야 합니다.

Couchbase Server에서는 이 두 기능이 모두 클라이언트 SDK에 있습니다. 애플리케이션에서 클러스터에 연결하면 SDK는 클러스터에서 각 샤드가 있는 위치에 대한 맵을 수신합니다. 그러면 클러스터의 모양이 변경될 때마다 Couchbase Server가 클러스터 맵을 자동으로 업데이트합니다. 그런 다음 각 요청은 애플리케이션 서버에서 관련 Couchbase 노드로 직접 이루어집니다.

클러스터가 커지면 특수 데이터, 쿼리 및 인덱싱 노드를 실행하도록 선택할 수 있습니다. 다차원 스케일링에 대해 자세히 알아보기.

이 모든 과정은 개발자에게 투명하게 공개됩니다.

Couchbase Server와 MongoDB 모두 데이터 집합을 문서 그룹으로 나눌 수 있습니다: Couchbase에는 버킷이 있고 MongoDB에는 컬렉션이 있습니다.

MongoDB 컬렉션은 관계형 테이블과 동등한 범위이지만, Couchbase Server 버킷은 관계형 데이터베이스에 더 가깝다고 할 수 있습니다.

이 구분이 중요한 이유는 일반적으로 단일 Couchbase 클러스터에 버킷을 10개 이상 사용하지 않기 때문입니다. 따라서 네임스페이스로는 적합하지 않습니다. 대신 비슷한 유형의 문서 간에 구성 및 모델링 결정을 공유하는 방법으로 사용됩니다.

이는 크게 두 가지 결과를 초래합니다:

카우치베이스 서버 제공 사항 N1QL. N1QL은 SQL과 유사한 언어이며 MongoDB에서 쿼리하는 것과는 상당히 다릅니다.

마운틴뷰 지사에서 2년 이상 근무한 직원의 이름을 입사 날짜 순으로 반환하는 예를 살펴보겠습니다:

SQL로 작업해 본 적이 있다면 N1QL은 매우 친숙할 것입니다. 비교적 적은 노력으로 MongoDB 쿼리를 N1QL로 변환할 수 있습니다.

쿼리 재작성을 시작하기 전에 N1QL이 제공하는 한 가지 주요 이점을 고려해야 합니다. 조인 를 반환합니다. 위의 쿼리를 사용하여 각 사람의 관리자 이름도 반환해 보겠습니다.

카우치베이스 서버에서 잠금은 항상 문서 수준에서 이루어지며 두 가지 유형이 있습니다:

낙관적 잠금 가 더 효율적일 수 있지만 때로는 비관적 잠금이 필요할 수 있습니다. 올바른 잠금 유형 선택에 대해 자세히 알아보기.

다음이 있습니다. 공식적으로 지원되는 SDK Java, .NET, NodeJS, Python, Go, Ruby 및 C를 포함한 모든 주요 언어에 대해 커뮤니티에서 개발한 클라이언트 라이브러리를 찾을 수 있으며, Erlang을 포함한 언어에 대해서도 찾을 수 있습니다.

마찬가지로 다음과 같은 공식 통합이 있습니다. 스프링 데이터, Spark, Hadoop, Kafka, Talend, Elasticsearch 및 ODBC/JDBC, Linq2Couchbase 에 대한 오스만이라는 NodeJS ODM. 현재 몽고DB용 몽구스를 사용 중이시라면, 다음 내용을 참고하세요. Ottoman.js를 사용하여 MongoDB에서 마이그레이션하는 방법에 대한 비디오.