What is difference between MongoDB and Cassandra

본 글은 해석한 내용이며 원문 링크는 하단에 있습니다. 

Cassandra vs. MongoDB

 Cassandra나 MongoDB를 다음 프로젝트의 데이터베이스로 생각하고 있으신가요? 두 데이터베이스를 비교하고 싶으신가요? Cassandra 와 MongoDB 모두 NoSQL 데이터베이스이지만 사실 둘은 매우 다릅니다. 그들은 매우 다른 능력과 방향성을 갖고 있으므로 미묘한 차이를 갖고 있습니다. 두 데이터베이스 중 어느 것도 RDBMS를 대체하지는 않으며 ACID를 보장하지도 않습니다. 만약 당신이 이러한 트랜잭션 단위의 작업이 주된 요구사항이라면 이러한 데이터베이스는 적합하지 않습니다. 이러한 경우에는 MySQL이나 PostgreSQL, Oracle과 같은 트랜잭션을 지원하는 관계형 데이터베이스를 사용하는 것이 더 적합합니다. 이제 관계형 데이터베이스는 배제하고 이야기 해봅시다. Cassandra와 MongoDB 간의 주된 차이점을 비교해보는 것이 결정하는데 도움이 될 것입니다. 이 포스팅에서는 결정을 내리는데 도움을 주기 위해서 데이터베이스에 대한 구체적인 기능에 대해 논하는 것 대신 고차원의 전략적 차이점을 논할 것입니다.

1. Expensive Object Model

 MongoDB는 다양한 객체모델(Object Model)을 지원합니다. 객체(Object)는 속성(Property)를 가질 수 있고 객체는 다른 객체를 계층구조로 가질 수 있습니다. 이런 모델은 상당히 객체지향적이며 어떠한 객체의 구조라도 표현할 수 있습니다. 또한 계층구조 전반에 대해서 어떠한 속성이라도 인덱스를 설정할 수 있다는 특성이 있으며 매우 큰 장점입니다. 반면 Cassandra의 경우에는 행과 열로 이루어진 기존의 테이블형태를 제공합니다. 데이터는 보다 구조화되고 각각의 컬럼은 테이블을 생성할 때 데이터타입이 정의되어야 합니다. 만약 다양한 형태의 데이터모델이 필요하다면 MongoDB가 Cassandra에 비해 적합할 것입니다.

2. Secondary Indexes

 MongoDB의 보조인덱스(Secondary Indexes)는 적재된 객체의 어떠한 속성이라도 쉽게 인덱스로 설정할 수 있으며 이를 통해서 쿼리를 보다 쉽게 질의할 수 있습니다. Cassandra는 보조인덱스에 대해 피상적인 수준으로만 제공할 뿐입니다. 단일 컬럼에 대해서만 설정할 수 있으며 동등비교연산(=)만 가능합니다. 만약 기본키를 주로 사용할 것이라면 Cassandra가 적합할것입니다. 만약 보조인덱스를 필요로 하며 쿼리모델에서 유연성(flexibility)가 요구된다면 MongoDB가 더욱 적합할 것입니다.

3. High Availability

 MongoDB는 하나의 마스터노드(Master node)와 다수의 슬레이브노드(Slave node)로 구성된 Single Master 모델을 지원합니다. 만약 마스터노드에 장애가 발생한 경우에 슬레이브노드의 하나가 마스터로 설정됩니다. 이러한 과정은 자동으로 이뤄지지만 10초에서 40초 가량의 시간이 소요됩니다. 기존의 슬레이브노드가 리더로서 선정되는 동안 다른 쓰기작업을 할 수 없습니다. 대부분의 응용프로그램에게 있어서 이러한 작업이 수행되지만 결국은 사용자에 필요에 의해 결정됩니다. Cassandra는 Multiple master 모델을 지원합니다. 클러스터 중에 단일노드가 유실되더라도 쓰기작업에 대해 영향을 미치지 않습니다. 그러므로 100% 가용성을 유지할 수 있습니다. 만약 100% 가동시간을 확보하고 싶다면 Cassandra가 더욱 적합할 것입니다.

4. Write Scalability

 Single master 모델을 차용하고 있는 MongoDB는 마스터노드에서만 쓰기작업을 수행할 수 있습니다. 보조서버들은 읽기 작업에만 사용됩니다. 만약 세 개의 노드의 구성으로 되어있다면 마스터는 오직 읽기만 수행할 것이고 나머지 두 개의 노드는 읽기 작업을 수행하게 됩니다. 이러한 구성은 쓰기작업에 제약사항이 됩니다. 여러 샤드를 배포를 할 수 있지만 한 개의 데이터노드만이 쓰기작업을 수행할 수 있습니다. Multiple master 모델인 Cassandra는 어떠한 노드에서든 쓰기작업을 할 수 있습니다. 쓰기 확장성은 클러스터에 존재하는 서버의 수와 상관이 있습니다. 클러스터에 서버가 많을 수록 쓰기 가용성이 높아질것입니다. 만약 높은 쓰기 확장성이 필요로한다면 Cassandra가 적합할 것입니다.

5. Query Language Support

 Cassandra는 SQL와 매우 흡사한 형태인 CQL를 지원합니다. 만약 기존의 데이터분석팀이 있다면 SQL 기술들을 이용하여 대응할 수 있다는 것은 대규모 데이터를 최적화 하는데 있어서 매우 중요한 부분입니다. 하지만 CQL은 JOIN이나 OR절을 지원하지 않는 등 ANSI SQL을 모두 지원하지는 않고 몇 가지 제약사항이 존재합니다. MongoDB는 이러한 부분에 대해 쿼리문에 대한 지원을 하지 않습니다. 쿼리는 JSON으로 구성되어있습니다. 만약 쿼리문을 지원하길 바란다면 Cassandra가 더욱 적합할 것입니다.

6. Performance Benchmarks

 성능에 대해서 이야기해봅시다. 이 부분에서 데이터베이스의 비교를 기대하겠지만 의도적으로 이러한 부분을 포함하지 않았습니다. 어떠한 비교에서든 apples-to-apples 비교라는 것을 충분히 인지해야합니다.

Database Model - 데이터베이스의 모델이나 스키마가 가장 큰 차이를 만드는 것으로 테스트 되었습니다. 어떠한 스키마는 MongoDB에 적합하였고 또 다른 것은 Cassandra에 적합하였습니다. 우리가 데이터베이스를 비교할때 각각의 데이터베이스에 합리적으로 작동하도록 모델을 적용하는 것이 매우 중요합니다.

Load characteristic - 벤치마크 부하의 형질이 매우 중요합니다. 예를 들어 쓰기에 비중을 둔 벤치마크라면 Cassandra가 MongoDB보다 앞설것이며, 읽기에 비중을 둔 테스트라면 MongoDB와 Cassandra가 비슷한 성능을 낼것입니다.

Consistency requirements - 이 것은 꽤나 까다로운 문제입니다. 당신이 읽기/쓰기의 일관성이 두 데이터베이스에 동일하여 다른 한 쪽에 편향되지 않도록 주의해아합니다. 매우 많은 마케팅 벤치마크에서는 다른 쪽을 불리하게 조정합니다. 그러므로 일관성을 조정하는데 주의를 기울여야 할 것입니다.

 마지막으로 유념해야할 것은 성능테스트가 당신의 프로그램의 형질을 반영하지 않았을 수 있다는 것입니다. 그러므로 성능측정이 무의미해지지 않기 위해서 당신의 프로그램의 형질을 제대로 반영했는지 여부를 확인하는 것이 매우 중요한 일입니다. 

7. Ease of Use

 만약 이러한 질문을 몇 넌 전에 했다면 MongoDB가 승자였을것입니다. MongoDB를 구동하고 운영하는 것은 꽤나 간단한 작업이기 때문입니다. 하지만 지난 몇년동안 Cassandra는 이 부분에 있어서 상품으로서 괄목할만한 성장을 했습니다. Cassandra에 기본 인터페이스로서 CQL을 도입하므로서 더욱 개선되었고 SQL 프로그래머들이 Cassandra를 쉽게 사용할 수 있도록 하였습니다.

8. Native Aggregation

 MongoDB는 데이터베이스에 적재된 데이터를 변형할 수 있도록 ETL 파이프라인을 구동할 수 있는 자체 집합 프레임워크(Aggregation framework)를 제공합니다. 이는 중-소규모 작업에서 효과적이지만 당신의 데이터의 복잡도와 규모가 커질수록 디버깅하기 더욱 어려워집니다. Cassandra는 이러한 툴을 제공하지 않으며 Hadoop이나 Spark와 같은 외부 툴을 이러한 목적을 위해 이용할 수 있습니다.

9. Schema-less Model

 MongoDB에서 당신은 도큐먼트(Document)에 어떠한 스키마도 강제하지 않도록 설정할 수 있습니다. 이전 버전에서는 이것이 기본설정이었지만 새로운 버전에서는 도큐먼트에 스키마를 강제하도록 하는 옵션을 설정할 수 있게 되었습니다. MongoDB에서의 각 도큐먼트는 다른 구조를 가질 수 있었고 이를 해석하여 사용하는 일은 어플리케이션에 달려있습니다. 이러한 경우는 대부분의 어플리케이션에서 적절하지 않지만 유연성이 필요한 특정 케이스에서는 중요합니다. CQL을 기본 언어로 하는 새로운 버전의 Cassandra에서는 정적타입(static typing)을 지원합니다. 당신은 컬럼의 타입을 사전에 정의해아합니다.

* 모든 오역은 피드백 주시면 반영하도록 하겠습니다.

원문 : https://scalegrid.io/blog/cassandra-vs-mongodb/