조회
하나의 범위 조회가 fan-out되어 여러 샤드를 돌고,
응답은 애플리케이션에서 다시 합쳐야 합니다.
range query -> all shards -> merge
샤드 수만큼 지연과 실패 지점이 늘어납니다. 특히 집계나 검색은 tail latency가 커집니다.
조인
관련 데이터가 서로 다른 샤드에 있으면 DB 내부 JOIN으로 끝내기 어렵고,
앱 조인이나 비정규화로 우회해야 합니다.
읽기 경로가 복잡해지고, 중복 데이터 관리 비용과 모델링 제약이 커집니다.
트랜잭션
여러 샤드를 하나의 ACID 경계로 묶기 어려워
2PC 같은 무거운 조율이나 Saga 같은 eventually consistent 패턴이 필요합니다.
일관성 보장은 비싸지고, 실패 복구와 보상 로직을 직접 설계해야 합니다.
운영 · 설계
데이터 편중이 생기면 리밸런싱이 필요하고,
잘못 고른 샤드 키는 오래 고착됩니다. ID도 전역 충돌을 피하는 방식이 필요합니다.
UUID / Snowflake / ID service
초기 설계 실수가 전체 재분배 비용으로 이어집니다. 샤딩은 도입보다 운영이 더 어렵습니다.