같은 분산 DB라도 먼저 구분해야 할 축은 강한 일관성, 기존 SQL 생태계 확장, 가용성·유연 모델이다.
핵심 이해
제품 비교의 핵심은 이름이 아니라 “어떤 일관성 규칙과 운영 방식으로 확장하느냐”에 있다.
|
CP 중심 분산 SQL
CockroachDB · TiDB · Spanner
|
기존 DB 확장 계층
Vitess · Citus · Aurora · PlanetScale
|
가용성·유연 모델
Cassandra · DynamoDB · MongoDB
|
|
|---|---|---|---|
| 먼저 보는 질문 | 전역 일관성과 분산 트랜잭션이 필요한가? 여러 리전에서도 같은 상태를 맞추는 데 초점을 둔다. | 기존 MySQL·PostgreSQL을 더 크게 운영하고 싶은가? 애플리케이션과 호환성을 유지한 채 샤딩·확장을 덧붙인다. | 높은 쓰기량, 관리형 운영, 유연한 모델이 더 중요한가? 일관성보다 가용성이나 데이터 모델 자유도를 더 크게 본다. |
| CAP 성향 | CP Spanner는 TrueTime으로 전역 일관성을 더 정교하게 다룬다. | 기존 엔진 기반 기본 성향은 원본 DB와 서비스 구현에 많이 좌우된다. | AP 중심 Cassandra·DynamoDB는 AP 성향이 강하고, MongoDB는 보통 CP 쪽으로 읽는다. |
| 핵심 구조 | Raft + 분산 SQL 계층 노드가 합의하며 트랜잭션 상태를 맞춘다. | 샤딩 계층 또는 분산 확장 모듈 기존 SQL 엔진 앞뒤에 분산 운영 기능을 배치한다. | 링 구조·관리형 KV·문서 복제 모델별로 쓰기 처리, 확장 방식, 스키마 유연성이 달라진다. |
| 대표 강점 | 강한 일관성, 글로벌 분산, SQL 유지 금융·주문처럼 상태 오류 비용이 큰 업무에 유리하다. | 기존 생태계 재사용, 점진적 확장 도입 장벽을 낮추고 현재 서비스 구조를 덜 흔든다. | 높은 쓰기량, 쉬운 확장, 유연한 데이터 표현 이벤트, 로그, 빠른 수평 확장이 필요한 워크로드와 잘 맞는다. |
| 선택 신호 | “정합성이 먼저다” 지연이 조금 늘어도 같은 결과를 보장해야 할 때. | “기존 SQL을 버리기 어렵다” MySQL·PostgreSQL 운영 경험과 도구 체인을 그대로 살리고 싶을 때. | “쓰기량·가용성·모델 자유도가 먼저다” 데이터 형태가 빠르게 바뀌거나 초고속 분산 쓰기가 중요할 때. |