핵심 요약
TiDB 8 Serverless는 MySQL 8 wire 프로토콜 호환의 분산 NewSQL. TiKV(행)와 TiFlash(컬럼)를 한 클러스터에서 운영하는 HTAP가 강점. 6개월 30TB 데이터셋 운영 결과 OLTP는 단일 MySQL의 78% 수준 지연, OLAP은 30배 가속. 단, AUTO_INCREMENT 비단조·외래키 제약 없음·일부 함수 미지원이 발목을 잡는다.
1. 아키텍처 한 장 요약
- TiDB 노드: SQL 파서·옵티마이저·트랜잭션 코디네이터(상태 없음)
- TiKV: 행 저장 분산 KV(Raft 복제 3중, RocksDB 기반)
- TiFlash: 컬럼 저장 분석 엔진(TiKV에서 실시간 복제)
- PD: 메타데이터·타임스탬프·리전 스케줄러
- Serverless: 자동 스케일링, 콜드/웜 분리, S3 백킹
2. 6개월 운영 환경
| 지표 | 값 |
|---|
| 데이터 크기 | 30TB (TiKV) + TiFlash 복제 |
| QPS 평균 | 18K (피크 64K) |
| 테이블 수 | 412 |
| 가장 큰 테이블 | events 184억 행, 12TB |
| 월 비용 | $3,840 (대등 RDS Aurora 추정 $7,200) |
| 가용성 6개월 | 99.987% |
3. OLTP 성능 — MySQL vs TiDB
| 워크로드 | MySQL 8 (db.r6g.2xl) | TiDB 8 Serverless | 비율 |
|---|
| oltp_read_only QPS | 34K | 27K | 0.79x |
| oltp_write_only QPS | 18K | 14K | 0.78x |
| p99 단순 조회 ms | 2.1 | 3.4 | +62% |
| p99 쓰기 ms | 4.8 | 7.2 | +50% |
4. OLAP — TiFlash가 진짜 가치
| 쿼리 | TiKV only | TiFlash MPP | 가속 |
|---|
| 월별 매출 집계 24개월 | 184s | 4.8s | 38x |
| 고객 세그먼트 JOIN 4테이블 | 312s | 11.2s | 28x |
5. TiFlash 설정 — 한 줄로 컬럼 복제
-- 분석용 테이블에 TiFlash 복제 2개
ALTER TABLE events SET TIFLASH REPLICA 2;
-- 옵티마이저 자동 선택, 강제하려면
SELECT /*+ READ_FROM_STORAGE(TIFLASH[events]) */
date_trunc('month', created_at) AS m,
SUM(amount)
FROM events
WHERE created_at >= '2024-01-01'
GROUP BY m;
6. MySQL 호환 한계
| 기능 | TiDB 동작 | 대응 |
|---|
| FOREIGN KEY | 8.0부터 지원, 성능 페널티 큼 | 앱 레벨 검증 |
| AUTO_INCREMENT | 비단조(노드별 캐시) | AUTO_RANDOM 또는 UUIDv7 |
| 스토어드 프로시저 | 미지원 | 앱으로 이동 |
| 트리거 | 미지원 | CDC + 앱 |
7. 트랜잭션 — 분산 환경의 함정
- 대형 트랜잭션: 기본 100MB 제한. 대량 UPDATE는 chunk로
- 핫스팟: AUTO_INCREMENT는 마지막 리전 쓰기 집중 — AUTO_RANDOM 또는 샤딩
- Repeatable Read: TiDB는 snapshot isolation. MySQL의 next-key lock과 동작 다름
- 2단계 커밋: 분산 트랜잭션 지연이 단일 MySQL의 2~3배
8. 도입 결정 가이드
| 상황 | 추천 |
|---|
| 데이터 100TB 이상, OLTP+OLAP 혼합 | TiDB 강점 |
| 샤딩하지 않고 MySQL 호환 필요 | TiDB |
| 단일 노드 1TB 이하 OLTP만 | MySQL/Aurora가 빠르고 싸다 |
| 외래키·트리거·SP 광범위 사용 | 호환 비용 큼, 재검토 |
참고
- docs.pingcap.com/tidb/v8.5
- tidbcloud.com
댓글 0