카우치베이스 카펠라와 코스모스DB 비교

CosmosDB는 Microsoft Azure 전용으로 제공되는 Microsoft의 NoSQL 제품입니다. 이전에는 DocumentDB라고 불렸지만 이름을 변경하고 몇 가지 흥미로운 새 기능을 추가했습니다. 이에 대해 좀 더 자세히 살펴보고 전략, 설명서, 개발자들이 말하는 내용, 그리고 Couchbase Capella와 비교하는 방법을 살펴보겠습니다.

하나의 데이터베이스로 모든 것을 관리할 수 있나요?

Microsoft는 CosmosDB가 말 그대로 다음을 수행할 수 있는 NoSQL 데이터베이스라고 주장합니다. 모든 것: 문서 데이터베이스, 컬럼형 스토리지, 키-값 저장소 및 그래프 데이터베이스입니다. 모두 다음과 같은 데이터 형식의 추상화 덕분에 달성되었습니다. 아톰 레코드 시퀀스(ARS).

각 모델에 따라 데이터가 어떻게 정리되는지 살펴봅시다. 먼저, 사용하려는 API(SQL, MongoDB API, Microsoft Azure Table, Cassandra 또는 Gremlin)를 선택하고 나중에 변경할 수 없으므로 이를 고수해야 합니다. 하지만 그 이면에는 사용자 지정 JSON 형식.

코스모스DB는 모든 주요 NoSQL 데이터베이스와 경쟁하려고 하는데, 이는 위험한 전략일 수 있습니다. 우선, 이러한 접근 방식은 CosmosDB가 궁극적으로 제공할 수 있는 기능을 제한할 수 있습니다. 하나의 공통 분모가 있으며, 그 분모에서 너무 멀리 벗어날 수는 없습니다. 또한 MongoDB 및 Cassandra와 같은 API는 Microsoft에서 정의하거나 계획한 것이 아닙니다. 즉, Microsoft는 항상 최신 릴리스를 따라잡고 있으며 궁극적으로 100% 호환성을 달성하지 못할 것입니다. Microsoft는 다음에 대한 문서를 유지 관리합니다. 지원되는 몽고DB 기능 와 그렇지 않은 것(그리고 카산드라). An 올인원 같은 솔루션은 기능 요구가 적은 단순한 애플리케이션에는 적합할 수 있지만, 이러한 모든 추상화에는 비용이 발생하고 궁극적으로 단순성, 성능에 영향을 미치며 기능이 제한됩니다. 

카우치베이스와 코스모스DB - "사과"와 "사과"의 비교

 이 비교는 두 기술을 비교하는 것이 타당한 시나리오에 초점을 맞출 것입니다(예: Couchbase는 그래프 데이터베이스가 아니므로 비교가 타당하지 않습니다).

또 한 가지 중요한 참고 사항: Couchbase Capella는 AWS 및 GCP(곧 Azure에서도 제공될 예정)에서 사용할 수 있는 Couchbase의 DBaaS(서비스형 데이터베이스) 제품입니다. 기본적으로 여전히 다운로드할 수 있는 Couchbase Server의 관리형 버전이므로 매우 유사합니다. 달리 명시되지 않는 한, "Couchbase" 열은 Capella와 Server 모두에 적용됩니다.

현실 세계에서의 성공

이렇게 나란히 비교하면 CouchBase가 더 유리할 수 있지만, CosmosDB를 사용하다가 CouchBase로 전환한 조직의 실제 경험은 어떨까요?

Facet Digital의 데이터베이스 비용 절감 를 50%로 늘리고, Couchbase Capella로 전환하여 성능을 100배 향상시켰습니다.

어떻게 가능했을까요?

• 배포 시간 단축
• 간편한 검색 통합
• 더 빠른 인덱싱
• 더 나은 DevOps 자동화(CI/CD 인덱스 정의)
• 친숙하고 완벽한 SQL 구문

요약

코스모스DB는 독특한 비전을 가지고 있지만, 한 번에 여러 분야에 초점을 맞춰 무언가를 구축하다 보니 자연스럽게 원하는 모든 기능을 지원하는 것이 고르지 않을 수 있습니다.

가장 눈에 띄는 기능 중 하나는 여러 수준의 최종 일관성 중에서 선택할 수 있는 기능입니다: 바운드-스탤런트, 세션, 일관된 접두사 및 최종적으로 일관성. 사실 세션 가 기본 일관성으로 설정되어 있다는 것은 CosmosDB를 사용하는 권장 방법에 대해 많은 것을 말해줍니다. 이는 강력한 데이터 일관성이 필요한 경우 최상의 솔루션이 아닐 수도 있음을 의미할 수 있습니다(그리고 아마도 Microsoft는 자사의 주력 데이터베이스인 SQL Server로 사용자를 다시 유도하고 싶을 수도 있습니다).

메모리 우선주의는 Couchbase가 매우 빠른 이유 중 하나입니다. 코스모스DB는 통합 캐시 (현재 프리뷰 중)를 지원하지만 검색과 마찬가지로 추가해야 하는 별도의 제품입니다. Couchbase는 처음부터 메모리를 우선시해 왔습니다.

CosmosDB를 사용하면 모든 필드가 글로벌 보조 인덱스(GSI)에 색인됩니다. 과한 것 같습니다. 색인할 필드를 지정하는 것보다 색인할 필드를 지정하는 것이 더 쉬울 수 있습니다. not 를 인덱싱할 수 있습니다. JSON이 몇 가지 속성보다 훨씬 커지면(특히 JSON 객체를 중첩할 때) 이러한 인덱스는 확실히 과잉이 될 것이며, 기본적으로 비용이 전가됩니다. 인덱스가 너무 많다는 것은 RU가 너무 많다는 것을 의미하며, 이는 곧 비용이 너무 많이 든다는 것을 의미합니다.

샤딩은 코스모스DB에서 가장 까다로운 기능 중 하나인 것 같습니다. 파티션은 노드 간에 자동으로 이동되지만 여전히 파티션 키를 지정해야 합니다. 이 접근 방식의 한 가지 단점은 각 파티션의 최대 크기가 10Gb로 분할할 수 없다는 것입니다. 잘못된 파티션 키를 선택하면 자주 액세스하는 많은 문서가 같은 파티션에 있게 되어 파티션이 저장되는 노드 용량에 따라 읽기/쓰기 처리량이 제한될 수 있습니다.

파티션 키는 변경할 수 없으므로 변경하려면 전체 데이터를 다른 컬렉션에 복사해야 합니다. 카우치베이스에서는 문서가 vBuckets 간에 균등하게 배포됩니다. 를 사용하여 이 문제를 방지하고 읽기/쓰기 성능을 향상시킬 수 있습니다.

CosmosDB를 사용하면 스로틀링은 요청 단위(RU)를 늘리는 방식으로만 이루어집니다. 이 접근 방식의 문제점은 쿼리 성능을 잘 예측하지 못하며, 쿼리 성능을 향상시키기가 더 어렵다는 것입니다. 특정 쓰기 용량만 늘리는 것과 같은 행동을 하지 마세요. 일부 사용 사례의 경우, 쿼리를 제대로 파악하고 유지 관리하기 위해 팀에서 풀타임으로 RU 작업을 하는 사람이 필요할 수도 있습니다.

Microsoft는 RU를 이해하기 쉽게 만들기 위해 많은 노력을 기울여 왔지만 개발자가 RU를 과소평가하는 경우가 종종 있습니다( 여기 또는 여기), 예상보다 훨씬 높은 청구서를 받게 됩니다. Couchbase에서 스로틀링 업은 매우 유연하며, 수직 및/또는 수평 확장, 노드 하드웨어에 따른 특정 서비스 실행, 메모리에 인덱스 유지 등을 통해 수행할 수 있습니다.

CosmosDB는 또한 전 세계 여러 데이터 센터에서 데이터를 매우 간단하게 복제할 수 있는 멋진 푸시 버튼 글로벌 데이터 배포 기능을 제공합니다. 하지만 Azure에서만 실행해야 한다는 제한 없이 Couchbase Server에서도 몇 분 만에 쉽게 달성할 수 있습니다.

코스모스DB의 RU 모델 때문에 벤치마킹은 어렵습니다. YCSB 접근 방식을 사용한 타사 벤치마크 는 처리량과 지연 시간에서 Couchbase Capella의 확실한 이점을 보여줍니다.

초당 읽기/쓰기 횟수가 적은 소규모 데이터베이스라면 CosmosDB의 가격이 매력적입니다. 하지만 그 이상이면 비용이 많이 들 수 있습니다. CosmosDB의 가격 계산기에 따르면 읽기와 쓰기가 50대 50으로 혼합되어 있고 초당 쿼리가 몇 건이면 한 달에 최대 수천 건에 달할 수 있습니다. 코스모스DB는 유용한 계산기를 사용할 수도 있지만 앞서 언급한 바와 같이 RU를 예측하기 어렵기 때문에 다소 신뢰성이 떨어집니다. 또한 계산기는 사용하려는 일관성 모델을 고려하지 않으므로 강력한 일관성의 경우 이 수치에 몇 달러를 더 추가해야 합니다.

카우치베이스 카펠라 가격 는 훨씬 더 예측 가능하며, 특히 대규모의 미션 크리티컬 사용 사례의 경우 비용이 더 적게 드는 경우가 많습니다.