Apache Cassandra와 MongoDB 비교

Apache Cassandra와 MongoDB는 대용량의 데이터를 저장하고 관리하기 위해 설계된 널리 사용되는 NoSQL 데이터베이스입니다.

이 두 데이터베이스 시스템의 인기는 부분적으로 높은 확장성과 가용성에 기인합니다. 둘 다 10년 넘게 사용되어 왔습니다. Cassandra는 2008년에 오픈 소스 프로젝트로 출시되었고, MongoDB는 그 다음해에 출시되었습니다.

여러 유사점에도 불구하고 Apache Cassandra와 MongoDB는 데이터 모델, 아키텍처 및 기타 구성 요소와 관련하여 크게 다릅니다. 이러한 기본적인 차이점은 주요 특성과 관련된 성능에 영향을 미치며, 어떤 데이터 관리 사용 사례에 가장 적합한지에 영향을 미칠 수 있습니다.

Apache Cassandra와 MongoDB를 비교하기 전에 NoSQL 데이터베이스에 대한 이해를 확립하는 것이 도움이 됩니다.

'Not Only SQL' 또는 '비 SQL' 데이터베이스라고도 하는 NoSQL 데이터베이스는 분산 데이터베이스입니다. 즉, 그 안에 있는 정보는 다양한 노드(데이터를 저장하는 개별 서버)로 복제됩니다. 이 분산 아키텍처는 고가용성과 내구성을 지원하며, 하나 이상의 노드가 오프라인 상태가 되더라도 나머지 데이터베이스는 계속 실행될 수 있습니다.

하지만 가장 주목할만한 점은 NoSQL 데이터베이스가 관계형 데이터베이스 관리 시스템(RDBMS)에서 볼 수 있는 기존 구조 외부에 데이터를 저장하고 쿼리하도록 설계되었다는 것입니다. 기존의 관계형 데이터베이스에 내재된 엄격한 테이블 형식 구조를 준수하는 대신, 비관계형 데이터베이스 설계는 엄격한 스키마를 필요로 하지 않습니다. 따라서 빠른 확장을 통해 정형, 반정형 및 비정형 데이터 세트를 비롯한 대규모 데이터 세트를 관리할 수 있습니다.

(Cassandra와 MongoDB를 포함한 NoSQL 데이터베이스에서 중요하게 여겨지는 확장성은 수평적 확장성 또는 '스케일아웃'이라는 점에 유의하세요. 수평적 확장성의 경우 기존 하드웨어에 메모리를 추가해야 하는 SQL 데이터베이스와 관련된 수직적 확장성 또는 '스케일업'과 달리 워크로드를 서버 간에 나눌 수 있습니다.)

NoSQL 데이터베이스는 뛰어난 성능, 확장성 및 유연성으로 인해 빅데이터 애플리케이션 및 실시간 워크로드를 지원하기 위한 필수 선택으로 부상했습니다. Apache Cassandra, MongoDB 외에도 인기 있는 다른 NoSQL 데이터베이스로는 DynamoDB(AWS에서 제공), Redis, CouchDB가 있습니다.

둘 다 밀레니엄이 시작되고 몇 년 후에 시작되었지만, Apache Cassandra와 MongoDB는 서로 다른 역사를 가지고 있습니다.

Apache Cassandra의 역사는 2007년경 Facebook으로 거슬러 올라갑니다. 당시 엔지니어들은 회사의 성장 중인 메시징 플랫폼을 위해 데이터를 저장할 수 있는 시스템을 찾고 있었습니다. 기존 NoSQL 데이터베이스 모델을 결합하여 효율적인 데이터 구조와 최종 일관성(시간이 지남에 따라 모든 복제본이 일치할 때까지 업데이트 전파)을 갖춘 시스템을 구축했습니다. 이 엔지니어들은 2008년에 Cassandra를 오픈 소스 프로젝트로 출시했습니다. 1년 후 Apache Software Foundation이 운영권을 넘겨받았습니다. 

MongoDB는 2007년 10Gen이라는 회사의 서비스형 플랫폼 프로젝트의 일환으로 시작되었습니다. 10Gen은 MongoDB('humongous'이라는 단어의 언어 유희)에 집중하기로 방향을 전환하고, MongoDB를 빠르게 작동하고 사용하기 쉬운 문서 중심의 데이터베이스로 발전시켰습니다. ¹

결국 MongoDB Inc.로 사명을 변경한 10Gen은 2009년에 MongoDB를 오픈 소스 프로젝트로 출시했습니다. 하지만 최신 버전의 MongoDB는 서버 측 공개 라이선스 v1에 따라 게시됩니다.

Apache Cassandra와 MongoDB의 근본적인 차이점은 성능과 이상적인 사용 사례에 영향을 미칩니다. 주요 요소는 다음과 같습니다.

• 데이터 모델
• 아키텍처 및 스토리지
• 쿼리 및 기타 언어

NoSQL 데이터베이스는 다음 네 가지 데이터 모델 중 하나를 기반으로 합니다.

• 문서 모델: 데이터는 일반적으로 JSON(JavaScript Object Notation) 또는 BSON(Binary JSON) 형식의 구조화된 문서로 저장됩니다.
• 와이드 컬럼 모델: 데이터는 열이 희소한 테이블에 저장되므로 테이블의 모든 행이 서로 다른 열 수를 가질 수 있습니다.
• 키-값 모델: 데이터는 키-값 쌍(특정 값과 쌍을 이루는 식별자 또는 레이블)으로 저장됩니다.
• 그래프 모델: 데이터는 엔티티 및 관계를 나타내는 노드 및 엣지로 저장됩니다.

Cassandra의 데이터 모델은 와이드 컬럼 저장소라고도 하는 와이드 컬럼 모델입니다. Cassandra 테이블의 각 행에는 열 컬렉션, 그리고 노드 및 데이터 센터에 데이터를 배포하는 데 사용되는 고유한 파티션 키가 있습니다. 행은 기본 키로 식별되며, 기본 키는 파티션 키와 선택적 클러스터링 키(파티션 또는 관련 그룹 내의 행을 고유하게 식별할 수 있는 열)로 구성될 수 있습니다.

이 접근 방식은 설정된 수의 열에 공간이 할당된 관계형 데이터베이스보다 더 유연합니다. Cassandra의 데이터 모델을 통해 필요한 경우에만 열을 사용하면 스토리지 효율성이 높아지고 쿼리 속도가 빨라집니다. ²

반면 MongoDB는 문서 모델을 사용합니다. 데이터는 주로 MongoDB에서 개발한 JSON의 바이너리 표현인 BSON으로 저장됩니다.

BSON은 표준 JSON이 데이터베이스에 제시하는 장애물, 즉 제한된 데이터 유형 지원, 개체의 고정된 길이 부족(순회 속도 저하), 메타데이터 부족(문서 검색 속도 저하) 등을 해결하는 데 도움이 됩니다. BSON은 형식 및 길이 정보를 인코딩하여 속도와 효율성을 최적화하도록 설계되었습니다. 또한 날짜 및 바이너리 데이터와 같은 일부 비네이티브 JSON 데이터 유형도 지원합니다. ³

NoSQL 데이터베이스인 Apache Cassandra와 MongoDB는 모두 분산 시스템을 지원하며, 여러 컴퓨팅 리소스에 있는 데이터 스토리지 통해 다운타임을 최소화합니다. 하지만 데이터 모델과 마찬가지로, 이러한 배포의 기반이 되는 아키텍처가 근본적으로 다릅니다.

Apache Cassandra는 피어 투 피어(P2P) 아키텍처를 사용합니다. Cassandra 클러스터의 모든 노드는 마스터 노드에 의존하지 않고 동등합니다. 데이터를 클러스터에 넣으면 행의 파티션 키에 해시 함수를 적용하며, 해당 아웃풋을 사용하여 특정 노드에 데이터를 할당합니다. 이 데이터는 다른 노드에도 복사됩니다.

Cassandra 데이터베이스의 복제 계수는 데이터베이스에 저장된 데이터의 복사본 수를 설명합니다. Cassandra의 스토리지 엔진은 커밋 로그, 메모리 내 테이블(memtable), 정렬된 문자열 테이블(SSTable) 파일로 구성된 단계별 흐름(또는 쓰기 경로)을 사용합니다.

Cassandra와 달리 MongoDB는 분산 아키텍처에 기본/보조 모델을 사용합니다. MongoDB에서 복제본 세트(인스턴스 그룹)는 모든 쓰기 작업(데이터 추가 또는 수정)을 처리하는 기본 노드와 기본 노드의 데이터를 반영하는 보조 노드로 구성됩니다.

MongoDB의 대규모 데이터 세트는 샤딩(sharding)이라는 프로세스를 통해 여러 머신에 배포될 수도 있습니다. 정보는 데이터 요청을 처리하는 시스템 용량을 개선하기 위해 샤딩된 클러스터(여러 복제본 세트와 해당 복제본 세트로 애플리케이션의 쿼리를 전달하는 라우터)로 나뉩니다.

또한 데이터베이스는 다양한 인덱싱 방식을 사용합니다. Apache Cassandra에서 기본 인덱스는 파티션 키이지만, Cassandra 설명서에는 스토리지 연결 인덱싱(파티션이 없는 열에 대한 인덱스 포함)이 대부분의 사용 사례에 적합하다고 언급되어 있습니다. ⁴ 또한 Cassandra에는 인덱싱되는 값과 별도로 테이블에 저장된 로컬 인덱스인 보조 인덱스도 있습니다. MongoDB는 지리 공간 인덱스, 다중 키 인덱스, 텍스트 인덱스를 비롯한 다양한 사용 사례에 대해 다양한 인덱스 유형을 지원합니다.

정의에 따르면 NoSQL 데이터베이스는 관계형 데이터베이스의 표준화된 프로그래밍 언어인 구조화 쿼리 언어(SQL)를 사용하지 않습니다. 그러나 Apache Cassandra와 MongoDB에는 모두 자체 쿼리 언어가 있습니다.

Cassandra는 Cassandra 쿼리 언어(CQL)라는 사용자 지정 버전의 SQL을 사용합니다. CQL은 SQL과 크게 유사하지만, 둘 사이에는 주요 차이점이 있습니다. 예를 들어, SQL은 정규화된 테이블에서 작동하는 반면, CQL은 파티션 키에 맞춘 비정규화된 Cassandra 데이터를 위해 설계되었습니다. 또한 SQL은 트랜잭션에 최적화되어 있는 반면, CQL은 실시간 쿼리 및 대용량 쓰기 작업에 적합하도록 설계되었습니다.

MongoDB는 MongoDB 쿼리 언어(MQL)를 사용합니다. 문서 모델 쿼리를 위해 설계된 MQL은 문서와 동일한 구문을 공유하므로, Cassandra 쿼리 언어보다 SQL에서 더 크게 벗어났습니다. MQL은 복잡한 쿼리, 집계 파이프라인, 지리 공간 데이터 쿼리를 포함한 다양한 쿼리 및 데이터 조작 기능을 지원하는 것으로 유명합니다. ⁵

각각의 쿼리 언어 외에도 데이터베이스는 프로그래밍 지원이 다릅니다. MongoDB는 Java, Python, Ruby 및 Node.js와 같은 12개 이상의 프로그래밍 언어에 대한 공식 드라이버를 제공합니다. 이러한 언어 및 기타 언어도 Cassandra와 호환되지만, 드라이버는 대부분 타사 공급자에서 제공합니다.

Apache Cassandra와 MongoDB의 근본적인 차이점으로 인해 성능과 관련된 특성에 약간의 차이가 있습니다. 이러한 변화는 CAP 정리로도 설명할 수 있습니다.

CAP는 분산 시스템의 바람직한 세 가지 특성, 즉 일관성(Consistency, 모든 클라이언트가 동시에 동일한 데이터를 볼 수 있음), 가용성(Availability, 하나 이상의 노드가 다운되더라도 데이터를 요청하는 모든 클라이언트가 응답을 수신함), 분할 내성(Partition Tolerance, 노드 클러스터는 둘 이상의 노드 간 통신 장애 시에도 계속 작동)을 나타내는 약자입니다.

CAP 정리에 따르면 분산 시스템이 원하는 세 가지 특성 중 두 가지만 제공할 수 있습니다. Apache Cassandra는 일반적으로 'AP' 데이터베이스로 분류되며, 주로 가용성 및 분할 내성에 대한 높은 성능을 제공합니다.

한편, MongoDB는 분할 내성 및 일관성 측면에서 탁월한 'CP' 데이터베이스로 알려져 있습니다. 그러나 두 데이터베이스 모두 손상된 것으로 알려진 특성(Cassandra의 일관성과 MongoDB의 가용성)을 개선하기 위한 조치도 존재합니다.

바람직한 세 가지 특성에 대해 자세히 살펴보겠습니다.

Cassandra는 데이터가 여러 노드에 복제되는 분산형 시스템으로서 내결함성이 높고 단일 장애 지점이 없기 때문에 높은 가용성을 지원합니다. 한 노드에서 다운타임이 발생하면 동일한 데이터의 복사본이 있는 다른 노드가 데이터 요청을 처리할 수 있습니다. 또한 전 세계 데이터 센터에 데이터를 복제하면 로컬 사용자의 지연 시간이 짧아집니다.

MongoDB의 아키텍처는 기본/보조 모델을 기반으로 하기 때문에 기본 노드가 중단되면 단일 장애 지점이 발생할 수 있습니다. 하지만 MongoDB의 장애 조치는 강력합니다. 복제본 세트 선택이라고 하는 기간 동안 복제본 세트에 속한 노드는 사용할 수 없는 기본 노드를 대체할 새로운 기본 노드를 선택합니다. 이러한 프로세스를 통해 MongoDB는 잠시 지연되기는 하지만 새로운 기본 노드가 선택된 후에만 성능이 재개되는 고가용성을 제공할 수 있습니다.

MongoDB는 모든 클라이언트가 신뢰할 수 있는 단일 소스에 쓰기 때문에 본질적으로 높은 일관성을 제공합니다. 즉, 각 복제본 세트에는 모든 쓰기 작업을 수신하는 기본 노드가 하나만 있을 수 있습니다. 반면, Apache Cassandra는 클라이언트가 언제든지 모든 노드에 쓸 수 있는 최종 일관성을 제공하며, 불일치는 가능한 한 빨리 조정됩니다.

또한 Cassandra는 사용자가 조정 가능한 일관성을 통해 가용성을 우선순위에서 제외하면서 일관성을 최적화할 수 있도록 합니다. 사용자는 일관성 수준을 선택하여, 클라이언트 애플리케이션에 읽기 또는 쓰기를 확인하기 전에 얼마나 많은 복제본이 이를 승인해야 하는지 설정할 수 있습니다. 일관성 수준이 높을수록 승인 응답을 위해 더 많은 복제본이 필요하지만, 이로 인해 지연 시간이 늘어나고 가용성이 감소합니다.

Apache Cassandra와 MongoDB는 모두 시스템의 한 부분에서 통신 장애가 발생하더라도 계속 작동하도록 설계되어 분할 내성을 제공합니다.

Apache Cassandra에서 노드는 통신 문제가 발생할 경우에도 계속 사용할 수 있지만, 일부 노드는 분할이 해결될 때까지 최신 버전의 데이터(데이터 요청에 대한 응답)를 제공하지 않을 수 있습니다. MongoDB에서는 분할이 처리되는 동안 데이터 일관성을 보장하기 위해 가용성이 제한됩니다.

Apache Cassandra는 스트리밍 및 엔터테인먼트와 같이 가용성과 확장성이 중요하며 처리량이 많고, 전역적으로 분산되고, 쓰기가 많은 워크로드에 권장되는 경우가 많습니다. 예를 들어, Netflix와 같은 스트리밍 서비스는 Cassandra를 사용하여 글로벌 사용자 활동을 처리합니다.

MongoDB는 개발자의 민첩성과 강력한 일관성의 이점을 누릴 수 있는 문서 중심의 유연한 스키마 사용 사례에 이상적입니다. MongoDB는 다양한 콘텐츠 자산을 저장하고 제공하기 때문에 기업은 콘텐츠 관리 시스템을 지원하기 위해 MongoDB에 의존하는 경우가 많습니다.

두 데이터베이스의 이러한 차이점에도 불구하고 Apache Cassandra의 사용 사례와 MongoDB의 사용 사례는 겹칠 수 있습니다. 각 데이터베이스에 대한 사례 연구는 사물인터넷(IoT) 애플리케이션, 전자 상거래 등에 대한 효율성을 보여줍니다.