[데이터베이스] RDB(Relational Database)에서 수평 확장(샤딩)이 어려운 이유

RDB(Relational Database)에서 수평 확장(샤딩)이 상대적으로 구현이 어려운 이유는 관계형 데이터베이스의 설계 원칙과 구조적인 특징에서 비롯됩니다. 주요 이유를 아래와 같이 정리할 수 있습니다.

데이터 간의 강한 관계

• 관계형 데이터베이스는 테이블 간의 관계(Foreign Key)를 바탕으로 동작합니다.
• 샤딩은 데이터를 여러 노드에 분산 저장하는 방식이므로, 관계를 유지하며 데이터를 분산시키는 것이 복잡합니다.
  • 예를 들어, 두 테이블이 서로 조인(Join)을 해야 하는 경우, 데이터가 서로 다른 노드에 있을 가능성이 커집니다.
  • 이 경우 조인을 수행하려면 각 샤드에서 데이터를 가져와야 하므로 성능이 저하되고 구현도 복잡해집니다.

트랜잭션 처리

• RDB는 ACID(Atomicity, Consistency, Isolation, Durability) 특성을 엄격히 준수합니다.
• 샤딩된 데이터베이스에서 트랜잭션이 여러 샤드에 걸쳐 발생하면, 분산 트랜잭션(Distributed Transaction)을 관리해야 합니다.
  • 2단계 커밋(2PC) 같은 복잡한 프로토콜이 필요하며, 성능 저하와 장애 처리 문제가 발생할 수 있습니다.
  • 트랜잭션 일관성을 보장하면서 샤딩을 구현하기가 어렵습니다.

샤딩 키 설계의 어려움

• 샤딩에서는 데이터를 분산시키기 위해 샤딩 키를 설계해야 합니다.
  • 샤딩 키 선택에 따라 쿼리 성능과 데이터 균형이 크게 달라집니다.
  • 잘못된 샤딩 키를 선택하면 특정 샤드에 데이터가 집중되는 핫스팟 문제가 발생하거나, 조인 및 조회 성능이 저하될 수 있습니다.
• 데이터 구조와 사용 패턴에 따라 적절한 샤딩 키를 설계하는 것은 매우 어렵고 시간 소모적입니다.

데이터 일관성 및 동기화 문제

• 샤딩된 RDB에서는 데이터를 수정하거나 삭제할 때 각 샤드 간의 데이터 일관성을 유지하는 것이 어렵습니다.
  • 특히, 다수의 샤드에 걸친 데이터 변경 작업에서 데이터 정합성을 보장하기 위한 추가 작업이 필요합니다.
• 마이그레이션이나 샤드 재배치(Shard Rebalancing)가 필요할 경우, 데이터의 재분배와 동기화 작업은 복잡한 문제를 야기합니다.

운영 및 관리의 복잡성

• 샤딩된 RDB에서는 다음과 같은 관리 복잡성이 증가합니다:
  • 각 샤드의 성능 모니터링과 문제 해결
  • 새로운 샤드 추가 시 기존 데이터의 분산 및 마이그레이션
  • 샤드 간의 데이터 복제 및 백업 관리
• 이러한 작업은 자동화하기 어렵고 운영 비용이 크게 증가합니다.

SQL 기능 제한

• RDB는 일반적으로 SQL 표준을 따릅니다. 하지만 샤딩 환경에서는 다음 기능들이 제한될 수 있습니다:
  • 조인(Join): 데이터를 여러 샤드에서 가져와야 하므로 성능이 저하되거나 불가능할 수 있음.
  • 집계(Aggregation): 데이터를 샤드별로 처리한 후 결과를 합산해야 하므로 성능 저하.
  • 동적 쿼리: 샤드 간의 데이터 분포를 고려해야 하므로 SQL 쿼리 작성이 복잡해짐.

RDB 설계 철학과 샤딩의 근본적 불일치

• RDB는 중앙 집중식 데이터 관리와 데이터 일관성을 전제로 설계되었습니다.
  • 샤딩은 데이터의 분산 저장을 목표로 하므로, RDB의 설계 철학과 근본적으로 상충됩니다.
  • 이러한 차이로 인해 샤딩을 RDB에 적용하는 데 기술적 제약이 따릅니다.

결론

RDB의 강력한 일관성, 관계 기반 설계, 고정된 스키마 등의 특성이 샤딩의 구현을 복잡하게 만듭니다. 이를 해결하기 위해 일부 RDBMS(MySQL, PostgreSQL 등)는 샤딩 지원 기능을 제공하거나, 외부 샤딩 솔루션(e.g., Vitess, Citus)을 사용하는 방식으로 확장을 지원하고 있지만, 여전히 NoSQL만큼 자연스럽거나 간단하지는 않습니다. NoSQL은 이러한 문제를 해결하기 위해 처음부터 분산과 확장을 우선으로 설계된 반면, RDB는 이러한 요구를 충족하기 위해 별도의 작업이 필요합니다.