단일 서버 안에서는

핵심 규칙이 모두 로컬 처리입니다

JOIN 같은 서버 메모리와 디스크 안에서 끝납니다.
트랜잭션 한 엔진이 commit 순서를 통제합니다.
스키마 변경 한 번 적용하면 전체가 같은 구조를 봅니다.
ID 생성 하나의 sequence만 관리하면 됩니다.
스케일 아웃
데이터 분산
노드가 여러 개가 되면

같은 규칙이 서버 간 조정 문제로 바뀝니다

문제의 본질

데이터를 나누는 것보다, 일관성 있는 한 번의 결과를 여러 노드가 함께 보장하는 일이 더 어렵습니다.

JOIN

한 질의가 데이터 이동으로 바뀝니다

서로 다른 노드의 행을 끌어와야 하므로, 로컬 연산 대신 네트워크 왕복과 전송 비용이 붙습니다.

트랜잭션

commit 전에 노드 합의가 필요합니다

모든 노드가 같은 commit 결과를 보장해야 해서 지연, 블로킹, 장애 전파 위험이 커집니다.

스키마 변경

ALTER가 클러스터 운영 작업이 됩니다

적용 순서와 호환성을 맞추지 않으면 일부 노드만 다른 구조를 보게 되어 점진 배포가 필요해집니다.

순차 ID

전역 순서를 맞추려다 병목이 생깁니다

AUTO_INCREMENT와 SEQUENCE를 공유하려면 중앙 조정 지점이 필요해져, 확장성이 다시 제한됩니다.

핵심

RDB 스케일 아웃의 어려움은 데이터를 여러 서버에 저장하는 일 자체보다, 원래 한 서버 안에서 보장하던 규칙을 분산된 상태에서도 계속 맞춰야 한다는 데 있습니다.