TiDB — TiKV와 TiFlash로 구현하는 HTAP

지난 글에서 CockroachDB의 Raft 기반 분산 아키텍처를 살펴봤다. 이번에는 다른 접근 방식을 택한 분산 SQL, TiDB를 다룬다. TiDB의 핵심 차별점은 **HTAP(Hybrid Transactional and Analytical Processing)**이다. 같은 데이터에 대해 OLTP와 OLAP 쿼리를 별도 데이터 이동 없이 동시에 처리한다.

TiDB 핵심 구성요소

TiDB 클러스터는 크게 세 가지 역할로 나뉜다.

TiDB SQL 노드: MySQL 5.7 프로토콜과 호환되는 SQL 레이어다. Stateless 설계라 수평 확장이 자유롭고, 실패 시 다른 TiDB 노드가 즉시 대체한다. 쿼리 파싱, 최적화, 실행 계획 생성을 담당한다.

PD (Placement Driver): 클러스터 메타데이터를 관리하고, 글로벌 트랜잭션 타임스탬프(TSO)를 발급한다. TiKV의 Region(데이터 조각) 스케줄링과 부하 분산도 PD가 담당한다.

TiKV: 행 기반(row-oriented) 분산 키-값 스토리지다. 데이터를 96MB 크기의 Region으로 나눠 클러스터에 분산하고, 각 Region마다 Raft 그룹으로 복제한다. OLTP 쿼리의 기본 스토리지다.

TiFlash: 열 기반(columnar) 스토리지로, TiKV의 Raft Learner로 동작한다. TiKV에 쓰인 데이터를 비동기적으로 복제받아 열 형식으로 저장한다. 대규모 집계와 범위 스캔에 최적화돼 있다.

HTAP: 같은 데이터, 두 가지 엔진

전통적인 OLTP + OLAP 아키텍처는 ETL로 분리된 데이터 웨어하우스가 필요하다. TiDB는 TiFlash가 TiKV의 Raft Learner로서 실시간으로 복제를 받기 때문에, 추가 파이프라인 없이 분석 쿼리를 신선한 데이터로 실행할 수 있다.

-- TiFlash 활성화 (테이블별 설정)
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- 복제 상태 확인
SELECT TABLE_NAME, REPLICA_COUNT, AVAILABLE
FROM information_schema.tiflash_replica
WHERE TABLE_NAME = 'orders';

-- 옵티마이저가 자동으로 TiFlash 선택 (분석 쿼리)
SELECT product_id, SUM(amount) AS revenue
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY product_id
ORDER BY revenue DESC
LIMIT 20;
-- EXPLAIN 출력에 "cop[tiflash]" 확인

옵티마이저는 쿼리 패턴을 분석해 포인트 조회는 TiKV, 집계·범위 스캔은 TiFlash로 자동 라우팅한다. 힌트(READ_FROM_STORAGE)로 명시적으로 지정할 수도 있다.

Percolator 기반 분산 트랜잭션

TiDB는 Google Percolator 논문을 기반으로 한 낙관적 트랜잭션 모델을 사용한다. 모든 읽기는 TSO에서 받은 타임스탬프 기준의 스냅샷을 읽는다. 쓰기는 Two-Phase Lock 방식으로 진행되지만, TiKV 내에서 분산 처리된다.

-- TiDB 트랜잭션 (MySQL 호환)
BEGIN;
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
UPDATE accounts SET balance = balance - 500 WHERE id = 1;
UPDATE accounts SET balance = balance + 500 WHERE id = 2;
COMMIT;

-- 비관적 잠금 모드 (MySQL과 동일한 동작)
SET tidb_txn_mode = 'pessimistic';
BEGIN;
-- FOR UPDATE 즉시 락 획득
SELECT * FROM inventory WHERE id = 100 FOR UPDATE;
UPDATE inventory SET qty = qty - 1 WHERE id = 100;
COMMIT;

기본값은 낙관적 모드지만, 쓰기 충돌이 많은 워크로드에는 비관적 모드가 성능상 유리할 수 있다.

Region과 핫스팟 문제

TiKV의 Region은 기본 96MB이며, 크기 초과 시 자동 분할된다. 순차 INSERT가 많으면 마지막 Region에 쓰기가 집중되는 핫스팟이 발생한다. TiDB는 이를 해결하기 위해 AUTO_RANDOM PK를 제공한다.

-- 핫스팟 방지: AUTO_RANDOM (내부적으로 값 샤딩)
CREATE TABLE orders (
    id      BIGINT      AUTO_RANDOM PRIMARY KEY,
    user_id BIGINT      NOT NULL,
    amount  DECIMAL(12,2),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- AUTO_RANDOM은 값을 랜덤하게 배분해 쓰기가 여러 Region에 분산됨
-- AUTO_INCREMENT와 달리 last_insert_id()가 다를 수 있음에 주의

TiDB vs CockroachDB 선택 기준

TiDB를 선택할 때: MySQL을 사용하고 있고 분산 확장이 필요한 경우, 별도 데이터 파이프라인 없이 OLTP+OLAP를 함께 처리해야 하는 경우, 중국·아시아 기업 생태계와 연동이 필요한 경우.

CockroachDB를 선택할 때: PostgreSQL 생태계를 선호하는 경우, 글로벌 멀티 리전 배포에서 행 단위 지역 핀닝이 필요한 경우, 강한 일관성(Serializable)이 기본값으로 필요한 경우.

두 시스템 모두 Raft를 사용하는 분산 SQL이지만, TiDB는 HTAP과 MySQL 호환성, CockroachDB는 멀티 리전과 PostgreSQL 호환성에서 강점을 보인다.

---

지난 글: CockroachDB — 분산 SQL의 실전 구현

다음 글: YugabyteDB — PostgreSQL과 Cassandra의 분산 결합

읽어주셔서 감사합니다. 😊