채팅 DB 선정하기 - DevCamp2Flame/FlameTalk_Server Wiki

MongoDB vs Cassandra

  1. 문제 도메인에 풍부한 데이터 모델이 필요한 경우 MongoDB가 더 적합

MongoDB는 다양한 객체모델(Object Model)을 지원

  1. 애플리케이션이 2차 인덱스와 유연한 쿼리가 필요하다면 MongoDB가 더 적합

MongoDB는 보조 인덱스(Secondary Indexes)를 지원함(어떤 칼럼이라도 보조 인덱스로 설정 가능) 이에 비해 Cassandra는 피상적인 수준으로만 제공(단일 칼럼에 대해서만 설정 가능. 비교 연산(=)만 가능)

  1. 100% 가동 시간이 필요한 경우 Cassandra가 더 적합

MongoDB는 하나의 마스터 노드(Master node)와 다수의 슬레이브 노드(Slave node)로 구성됨. 마스터에서 오류나면 슬레이브로 자동으로 넘어가나 10 ~ 40초 가량 소요(이때 읽기/쓰기 불가!!) Cassandra는 Multiple master 모델지원. 단일 노드에서 문제가 일어나도 쓰기 작업에 영향 없으므로 100% 가동 시간 확보 가능

  1. (쓰기) 확장성이 고려대상이라면 Cassandra가 더 적합

MongoDB는 마스터 노드만 쓰기 작업 수행. 슬레이브 노드는 읽기 작업만 가능 Cassandra는 어떤 노드에서든 쓰기 작업 가능

  1. 질의어(query language) 지원이 필요한 경우 Cassandra가 더 적합

Cassandra는 SQL와 매우 흡사한 형태인 CQL를 지원 (단, 완벽하게 지원하는 것은 X. join, or는 지원 X) MongoDB는 이러한 부분에 대해 쿼리문에 대한 지원 X

  1. 성능 비교는 절대적이지 않음.

애플리케이션의 특성에 따라 다름 Database Model - 주로 성능 테스트 시 가장 큰 비중을 차지함. 스키마 별로 성능이 다름. Load characteristic - 쓰기에 비중을 둔 성능 비교라면 Cassandra가 우위. 읽기라면 비슷. Consistency requirements

  1. 사용하기 쉬운 정도(러닝 커브)

몇 년 전까지만 해도 MongoDB지만, 최근 Cassandra에 기본 인터페이스로 CQL을 도입하면서 개선됨

  1. Native Aggregation(집계)

MongoDB: 데이터를 변형할 수 있는 자체 집계 프레임워크 제공. 소규모 중-소규모 작업에서 효과적이지만 복잡도와 규모가 커지는 경우 어려워집니다. Cassandra: 자체적으로는 툴을 제공하지 않음. 외부 툴인 Hadoop이나 Spark를 사용할 수 있음

  1. Schema-less Model

MongoDB: 새로운 버전에서는 스키마를 강제하지 않도록 옵션 설정 가능. 각 document가 다른 스키마 구조를 가질 수 있고 이를 사용하는 건 애플리케이션 나름.(유연성이 필요한 특정한 스키마라면 해당 옵션이 매우 유용) Cassandra: CQL이 기본 언어인 새로운 버전에서는 정적 타입 지원. 컬럼 타입을 사전에 정의 해야함

Discord가 DB를 변경하게 된 이유

MongoDB에 저장된 메시지 수가 1억 개가 되면서 데이터와 인덱스가 RAM에 적합하지 않고, 지연 시간이 예측 불가능해지는 이슈 발생

Discord가 새로운 DB를 찾을 때 고려한 점

  1. 읽기/쓰기 패턴 & 현재의 문제점 읽기/쓰기 비율은 약 50:50 (요약) 서버 별(heavy한 음성 서버, heavy한 개인 텍스트 채팅 서버, 대형 퍼블릭 서버) 메세지를 주고받는 양이 다름. 자주 요청되는 메세지 데이터는 캐시에 있지만 그렇지 않은 경우는 디스크 캐시에서 제거됨
  2. 요구사항 정의 Linear scalability(수평적 확장성): 고려하고 싶지 않음 Automatic failover(자동 장애 조치): 원함 Low maintenance (낮은 유지 보수): 일단 빠르게 작동되기를 원함. 데이터가 증가함에 따라 노드를 추가하는 정도만 고려하고 싶음. Proven to work(입증된 기술): 매우 새로운 것을 원하진 않음. Predictable performance(예측 가능한 성능): 경고가 발생할 수 있어야 함. 또한 Redis나 Memcached로 메시지를 캐싱하는 것을 원하지 않음 Not a blob store(멀티미디어 데이터 X): 지속적으로 blob 데이터를 역직렬화하고 추가해야 한다면 초 당 수천 개의 메시지를 write해야 하므로 성능에 좋지 않을 것임 Open Source: 원함. 타 회사를 의존하고 싶지는 않음
  3. 결정 그래서 Cassandra를 선택했다!!!

Why?

노드를 추가하여 확장 가능 애플리케이션에 영향을 주지 않고 노드 삭제 가능 Apple이나 Netflix는 수천 개의 Cassandra 노드를 가지고 있음 데이터는 디스크에 지속적으로 저장되므로 최소한의 검색과 쉬운 배포 가능 DataStax가 관리하지만 여전히 오픈 소스 및 커뮤니티 중심

참고한 자료)