Contents
see List개요
NewSQL은 전통적인 관계형 데이터베이스의 ACID 트랜잭션과 SQL 인터페이스를 유지하면서, NoSQL의 수평 확장성을 결합한 데이터베이스 카테고리입니다. CockroachDB와 TiDB는 NewSQL의 대표 주자로, 글로벌 분산 환경에서 강력한 일관성을 제공합니다. 이 글에서는 두 데이터베이스의 아키텍처, 성능, 운영 특성을 비교 분석합니다.
핵심 개념
CockroachDB: Google Spanner에서 영감을 받아 설계된 분산 SQL 데이터베이스입니다. PostgreSQL 호환 프로토콜을 사용하며, 멀티 리전 배포에서 자동 데이터 복제와 리밸런싱을 지원합니다. Raft 합의 알고리즘으로 강력한 일관성을 보장합니다.
TiDB: PingCAP에서 개발한 MySQL 호환 분산 SQL 데이터베이스입니다. TiKV(분산 스토리지), TiDB Server(SQL 레이어), PD(배치 관리)로 구성된 3계층 아키텍처를 사용합니다. HTAP(Hybrid Transactional and Analytical Processing)을 지원하여 OLTP와 OLAP 워크로드를 동시에 처리할 수 있습니다.
분산 트랜잭션: 두 DB 모두 분산 환경에서 ACID 트랜잭션을 보장합니다. CockroachDB는 직렬화 격리(Serializable Isolation)를 기본으로 제공하며, TiDB는 Snapshot Isolation을 기본으로 사용합니다.
자동 샤딩: 데이터가 증가하면 자동으로 리전/레인지를 분할하고 노드 간에 균형을 맞춥니다. 수동 샤딩의 복잡성을 완전히 제거합니다.
실전 예제
CockroachDB와 TiDB의 주요 기능 비교 예제입니다.
-- CockroachDB: 멀티 리전 테이블 설정
CREATE TABLE user_accounts (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email STRING NOT NULL,
region STRING NOT NULL,
balance DECIMAL(10,2) DEFAULT 0
) LOCALITY REGIONAL BY ROW;
-- 특정 리전에 데이터 고정
ALTER TABLE user_accounts
SET LOCALITY REGIONAL BY ROW AS region;
-- CockroachDB: 분산 트랜잭션 (자동 분산)
BEGIN;
UPDATE accounts SET balance = balance - 50000
WHERE id = 'user-seoul' AND region = 'ap-northeast-2';
UPDATE accounts SET balance = balance + 50000
WHERE id = 'user-tokyo' AND region = 'ap-northeast-1';
COMMIT;
-- 클러스터 상태 확인
SHOW RANGES FROM TABLE user_accounts;
-- TiDB: HTAP 쿼리 (TiFlash 활용)
-- TiFlash 레플리카 생성 (분석용 컬럼 스토어)
ALTER TABLE orders SET TIFLASH REPLICA 2;
-- OLAP 쿼리가 자동으로 TiFlash로 라우팅
SELECT
DATE_FORMAT(created_at, '%Y-%m') AS month,
category,
SUM(amount) AS revenue,
COUNT(DISTINCT user_id) AS unique_buyers
FROM orders
WHERE created_at >= '2024-01-01'
GROUP BY month, category
ORDER BY month, revenue DESC;
-- 실행 계획에서 TiFlash 사용 확인
EXPLAIN ANALYZE
SELECT COUNT(*) FROM orders WHERE amount > 100000;
-- TiDB: 자동 분할 확인
SHOW TABLE orders REGIONS;
활용 팁
- 마이그레이션 호환성: CockroachDB는 PostgreSQL 호환, TiDB는 MySQL 호환입니다. 기존 ORM과 드라이버를 거의 수정 없이 사용할 수 있지만, 일부 비호환 기능(저장 프로시저, 트리거 등)은 사전에 확인하세요.
- 비용 최적화: 3개 노드로 시작하여 트래픽에 따라 수평 확장하세요. CockroachDB Serverless나 TiDB Serverless를 사용하면 소규모에서 비용 효율적으로 시작할 수 있습니다.
- 레이턴시 고려: 멀티 리전 배포 시 리전 간 네트워크 레이턴시가 트랜잭션 성능에 영향을 줍니다. 쓰기 작업이 많은 테이블은 주 리전을 지정하세요.
- HTAP 활용: TiDB의 TiFlash를 활용하면 별도의 분석 DB 없이 실시간 분석 쿼리를 처리할 수 있어 아키텍처가 크게 단순화됩니다.
- 백업과 복구: 두 DB 모두 증분 백업을 지원합니다. S3나 GCS에 정기적으로 백업을 설정하고, 복구 테스트를 주기적으로 수행하세요.
마무리
CockroachDB와 TiDB는 각각의 강점이 있습니다. PostgreSQL 생태계와 멀티 리전 분산이 중요하다면 CockroachDB가, MySQL 호환성과 HTAP이 필요하다면 TiDB가 좋은 선택입니다. 두 DB 모두 기존 단일 인스턴스 DB의 확장 한계를 극복하면서도 SQL의 편의성을 유지한다는 공통된 가치를 제공합니다.
database
| No | 작성일 | Title |
|---|---|---|
| 3380 | 2026. 08. 20. | PostgreSQL 느린 조회를 진단하는 방법: EXPLAIN ANALYZE와 복합 인덱스 실전 가이드 |
| 3348 | 2026. 08. 11. | PostgreSQL 잠금 대기 줄이기: 트랜잭션 범위와 lock_timeout 설정 실전 가이드 |
| 3316 | 2026. 08. 03. | PostgreSQL 백업 복구 실전 가이드: pg_dump·pg_restore로 장애 복구 절차 만들기 |
| 3284 | 2026. 07. 26. | PostgreSQL 인덱스가 있는데도 느린 쿼리 해결하기: EXPLAIN ANALYZE와 복합 인덱스 설계 |
| 3254 | 2026. 07. 18. | PostgreSQL 잠금 대기 진단 가이드: pg_stat_activity로 블로킹 쿼리 찾고 장애 줄이기 |
| 3202 | 2026. 07. 09. | PostgreSQL 백업 복구 검증 가이드: pg_dump와 psql로 실제 복원까지 확인하기 |
| 3170 | 2026. 07. 01. | MySQL 느린 쿼리 원인 찾기: EXPLAIN과 복합 인덱스 점검 가이드 |
| 3116 | 2026. 06. 23. | PostgreSQL 트랜잭션 충돌 줄이기: 잠금 순서와 짧은 재시도로 데드락 대응하기 |
| 3058 | 2026. 06. 15. | PostgreSQL JSONB 조회 튜닝: GIN 인덱스와 생성 컬럼으로 느린 검색 줄이기 |
| 2971 | 2026. 06. 07. | MySQL/MariaDB 복합 인덱스 설계: 느린 목록 조회를 줄이는 WHERE·ORDER BY 점검법 |