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

Microsoft는 CosmosDB 출시 이후 많은 화제를 불러일으켰습니다. 기본적으로 몇 가지 멋진 새 기능이 추가된 Amazon DocumentDB의 리브랜딩입니다. 이에 대해 좀 더 자세히 살펴보고 전략, 문서, 개발자들이 어떤 이야기를 하고 있는지, 그리고 Couchbase Server와 어떻게 비교되는지 살펴보겠습니다.

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

간단히 말해서, Microsoft는 CosmosDB가 말 그대로 다음을 수행할 수 있는 NoSQL 데이터베이스라고 주장합니다. 모든 것: 문서 데이터베이스, 컬럼형 저장소, 키-값 저장소, 그래프 데이터베이스입니다. 모두 원자 기록 시퀀스(ARS)라는 데이터 형식의 추상화 덕분에 달성되었습니다.

Microsoft의 작업의 좋은 징조는 각 모델에 따라 데이터가 어떻게 다르게 구성되는지입니다. 먼저, 사용하려는 API(SQL, MongoDB API, Microsoft Azure Table, Cassandra 또는 Gremlin)를 선택하고 나중에 변경할 수 없으므로 이를 고수해야 합니다. 현재 일부 모델에 대한 액세스는 DocumentDB API를 통해 시도해 볼 수 있습니다. CosmosDB는 내부적으로 장식된 JSON 형식을 사용합니다. 를 사용하여 데이터를 저장합니다.

Microsoft는 대부분의 NoSQL 데이터베이스와 경쟁하려는 것처럼 보이는데, 이는 단일 데이터베이스의 황금기를 지났기 때문에 매우 위험한 전략입니다. 모든 것을 위한 데이터베이스 솔루션입니다. 전문 스토리지를 선택하면 큰 이점이 있으며, 현재 대부분의 애플리케이션이 다음과 같은 경로를 따르고 있습니다. 다국어 지속성. An 올인원 같은 솔루션은 요구사항이 적은 애플리케이션에는 적합할 수 있지만, 이러한 모든 추상화에는 비용이 발생하며 궁극적으로 단순성, 성능에 영향을 미치고 기능이 제한됩니다.

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

두 기술을 비교하는 데 가장 적합한 시나리오에 초점을 맞춰 CosmosDB와의 비교를 제한하려고 합니다. 아래 표에서는 몇 가지 차이점을 나란히 보여드리려고 합니다:

결론

이 글이 코스모스DB와 다른 데이터베이스를 비교하는 첫 번째 글인 것 같습니다. 많은 문서와 개발자의 피드백, 웨비나 등을 검토하는 데 상당한 시간이 걸렸습니다.

전반적으로 코스모스DB의 비전은 훌륭하지만 현재로서는 아직 미숙한 부분이 있다는 것이 제 느낌입니다. 예를 들어 문서화 및 백업은 강점 중 하나가 아닌데, 이는 한 번에 여러 분야에 초점을 맞춰 무언가를 구축하다 보니 당연한 결과입니다. Microsoft의 데이터베이스는 또한 많은 혁신을 가져왔는데, 가장 눈에 띄는 것 중 하나는 새로운 다중 수준의 최종 일관성입니다: 바운드-스탤런트, 세션, 일관된 접두사 및 최종 일관성입니다.

사실 세션 가 기본 일관성으로 설정되어 있다는 것은 코스모스DB를 사용하는 권장 방법에 대해 많은 것을 말해줍니다. 또한 강력한 데이터 일관성이 필요한 경우 최상의 솔루션이 아닐 수도 있다는 힌트를 제공합니다.

CosmosDB에서 캐싱 메커니즘에 대한 언급을 찾을 수 없었기 때문에 데이터베이스의 주요 부분은 아니라고 가정하고 있습니다. 문제는 캐싱이 일관성이 강한 데이터베이스에서 좋은 성능을 내기 위해 매우 중요하며, 메모리 우선이라는 점이 Couchbase Server의 속도가 빠른 이유 중 하나라는 점입니다.

CosmosDB는 메모리에 최적화된 인덱스를 제공하지 않으며 기본적으로 모든 필드는 글로벌 보조 인덱스(GSI)에서 인덱싱됩니다. 어떤 필드를 색인할지 지정하는 것이 어떤 필드를 색인하지 않을지 지정하는 것보다 더 쉽다고 생각하기 때문에 저에게는 완전히 과잉인 것처럼 들립니다. 물론 색인에서 해당 필드를 반드시 제거할 필요는 없지만 비용이 청구된다는 사실을 잊지 마세요.

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

파티션 키는 변경할 수 없으므로 변경하려면 전체 데이터를 다른 컬렉션에 복사해야 합니다. Couchbase에서는 다음과 같이 투명하게 처리합니다. vBuckets 간에 문서를 고르게 배포합니다. 를 사용하여 이 문제를 방지하고 읽기/쓰기 성능을 향상시킬 수 있습니다.

현재 스로틀링은 완전 관리형 데이터베이스의 일반적인 표준인 요청 단위(RU)를 증가시키는 방식으로만 이루어집니다(예를 들어, DynamoDB에서는 읽기/쓰기 용량 단위를 증가시키는 방식으로 스로틀링이 이루어집니다). 이 접근 방식의 문제점은 쿼리 성능을 잘 예측하지 못하며 쓰기 용량만 늘리는 것과 같은 특정 동작만 강화하기가 더 어렵다는 것입니다.

Microsoft는 RU 프로비저닝을 이해하기 쉽게 만들기 위해 많은 노력을 기울여 왔지만, 개발자들이 RU를 과소평가하는 댓글을 많이 발견했습니다( 여기 또는 여기 ), 예상보다 훨씬 높은 청구서를 받게 됩니다. 일반적으로 코스모스DB에서 제가 본 프로비저닝의 패턴은 대부분 시행착오에 기반합니다. Couchbase에서는 스로틀링이 매우 유연하여 수직/수평 확장, 노드 하드웨어에 따른 특정 서비스 실행, 인덱스를 메모리에 보관하는 등의 방식으로 수행할 수 있습니다.

Microsoft는 또한 MongoDB의 사용자들이 CosmosDB로 마이그레이션하도록 설득하기 위해 노력하고 있습니다. 심지어 마이그레이션을 쉽게 할 수 있도록 상당히 호환되는 커넥터도 제공합니다. 문제는 일부 사용자가 다른 데이터베이스로 마이그레이션하려는 근본적인 이유가 MongoDB의 확장성과 성능 문제 때문이라는 점입니다. 우리는 그 이유를 잘 알고 있습니다. 이러한 사용자 중 상당수가 Couchbase Server로 마이그레이션하게 됩니다.의 성능은 적어도 합리적인 비용으로는 큰 장점이 아닌 것 같습니다.

Microsoft는 개발을 위한 제한된 로컬 버전을 제공하지만, 현재까지는 Windows 컴퓨터에서만 실행됩니다.

CosmosDB는 또한 전 세계 여러 위치에서 데이터를 아주 간단하게 복제할 수 있는 멋진 푸시 버튼 글로벌 데이터 배포 기능을 제공합니다. 그러나 이러한 단순성을 필요로 할 만큼 매일 사용하지 않는 기능이지만, 단일 클라우드에서 실행해야 한다는 제한 없이 Couchbase Server에서 몇 분 만에 쉽게 달성할 수 있습니다.

요약하자면, 저는 최종 일관성이 너무 광범위하게 정의되어 있다는 CosmosDB의 관점에 동의합니다. 새로운 일관성 모델을 통해 개발자는 애플리케이션이 허용하는 일관성 수준을 선택할 수 있습니다.

이 기능을 사용하는 이유는 다음에서 언급한 것과 거의 동일합니다. DynamoDB에 대한 나의 글. 물론 가장 큰 차이점은 코스모스DB가 다이나모DB보다 훨씬 더 유연하다는 것입니다. 현재 강력한 일관성을 갖춘 평균 성능을 요구하는 애플리케이션을 위한 평균적인 다목적 데이터베이스입니다. 또한 쉽게 는 Azure 함수의 일부 기능과 통합됩니다.

CosmosDB는 아직 유명한 사용 사례/클라이언트가 부족하지만, 궁극적으로 일관성이 중요한 애플리케이션에서 두각을 나타낼 수 있는 잠재력을 가지고 있습니다. 그러나 일관성이 매우 중요한 중/고 요구사항이 많은 애플리케이션의 경우, 가격 및 성능 관점에서 볼 때 Couchbase Server가 훨씬 더 나은 선택입니다.

예를 들어, CosmosDB에서 30.000개의 RU를 프로비저닝할 때 얼마나 많은 서버가 실행되고 있는지 불분명하기 때문에 두 데이터베이스 간에 공정한 벤치마크를 제시하기가 어렵기 때문에, 예상 성능을 예측하는 가장 쉬운 방법은 아키텍처/기능을 통해 예측하는 것입니다.

초당 읽기/쓰기 횟수가 적은 소규모 데이터베이스의 경우, DynamoDB와 마찬가지로 CosmosDB의 가격이 매력적입니다. 하지만 그 이상의 모든 것 초당 쓰기 4회, 읽기 40회인 45KB의 문서 200,000개를 만들려면 최소 US$ 2,500달러의 비용이 듭니다.

이 계산기는 사용하려는 일관성 모델을 고려하지 않으므로 강력한 일관성을 위해 이 수치에 몇 달러를 더 추가해야 합니다. 이 설정에서 CosmosDB 비용은 권장 아키텍처(그 이상을 처리할 수 있음)로 Amazon Web Services에서 Couchbase EE를 실행하는 데 드는 비용의 최소 두 배에 달합니다.

글의 서두에서 언급했듯이 특정 목적에 따라 특화된 스토리지를 선택하면 많은 이점이 있으며, Couchbase Server는 강력한 일관성으로 고성능을 제공하는 데 정말 탁월합니다.

질문이 있으시면 언제든지 다음 주소로 트윗해 주세요. @deniswsrosa