이 방법은 샤드 키에 수학 공식(해시 함수)을 사용하여 데이터를 할당합니다. 예를 들어 시스템은 사용자 ID(mod 4)를 계산하여 사용자를 4개의 서버 중 하나에 할당할 수 있습니다.

해시 함수는 데이터를 일관되게 배포하는 데 도움이 되지만 샤드 키의 카디널리티가 높고 빈도 편향이 낮은 경우에만 균등한 배포를 보장합니다. '파인'보다 '스미스'가 1,000배 더 많이 나타나는 '성'과 같이 공통 값이 있는 샤드 키를 선택하면 해시 함수가 모든 '스미스' 레코드를 동일한 샤드로 보냅니다. 수학 공식을 사용했음에도 불구하고 '핫 샤드'가 생성됩니다.

이 방법으로는 공식이 변경되므로 새 서버를 추가하기도 어렵습니다. 이로 인해 데이터를 '다시 샤딩'하거나 새 서버 클러스터로 이동해야 하는 경우가 많습니다.

데이터는 값의 범위를 기준으로 할당됩니다. 예를 들어 사용자 ID 1~1,000을 서버 A에, 1,001~2,000을 서버 B에 배치할 수 있습니다. 이 방식은 매우 직관적이며 데이터 시퀀스(범위 쿼리)를 읽어야 하는 쿼리에 적합합니다. 단점은 '핫스팟'입니다. 모든 신규 사용자가 서버 B에 할당되면 서버 A가 유휴 상태인 동안 서버 B가 모든 작업을 수행하게 됩니다.

이 전략은 어떤 샤드에 어떤 데이터가 있는지 정확하게 추적하는 참고표(디렉터리)를 사용합니다. 수식을 변경하지 않고도 샤드 간에 데이터를 이동할 수 있으므로 가장 유연한 옵션입니다. 그러나 이 참고표는 병목 현상이 됩니다. 모든 쿼리가 먼저 디렉터리를 확인해야 하므로 지연 시간이 추가됩니다. 디렉터리가 실패하면 전체 데이터베이스에 액세스할 수 없게 됩니다.

지리적 샤딩은 사용자의 실제 위치를 기반으로 데이터를 특정 서버에 할당합니다. 예를 들어 프랑스 사용자의 데이터는 EU의 서버에 저장되고 미국 사용자의 데이터는 북미의 서버에 저장됩니다. 이를 통해 사용자의 지연 시간(속도)이 크게 줄어들고 기업이 GDPR과 같은 데이터 상주 법규를 준수하는 데 도움이 됩니다.

기능적 파티셔닝이라고도 하는 이 방법은 데이터를 행이 아닌 특성별로 분할합니다. 예를 들어 모든 '사용자 프로필' 테이블을 서버 A에 배치하고 모든 '사진 업로드' 테이블을 서버 B에 배치할 수 있습니다. 이러한 방식은 데이터를 논리적으로 정리하지만 기능적으로는 마이크로서비스 데이터 아키텍처와 유사하며, 특정 특성(예: 포토)이 단일 서버에 비해 너무 커지면 문제를 해결하지 못합니다.

샤딩은 데이터 조각이 완전히 다른 서버에 분산되는 수평 파티셔닝의 한 유형입니다. 이렇게 하면 서로 다른 서버가 동시에 쓰기를 처리할 수 있으므로 하드웨어 용량 한도(스토리지)와 쓰기 처리량 병목 현상이 모두 해결됩니다.

• 수동 샤딩: 수동 샤딩 환경에서는 개발자 또는 데이터베이스 관리자가 샤드 키를 정의하고, 각 샤드에 대한 인프라를 만들고, 쿼리를 라우팅하는 로직을 작성해야 합니다. 이를 통해 데이터가 정확히 어디에 저장되는지 세부적으로 제어할 수 있습니다. 하지만 유지보수에 상당한 노력이 필요합니다. 샤드 1개가 너무 커지면 데이터를 수동으로 '다시 샤딩'해야 하는데 이 과정에서 애플리케이션 다운타임을 최소화하면서 수백만 개의 행을 새로운 서버로 이동해야 합니다.
• 자동 샤딩: Bigtable과 같은 NoSQL 데이터베이스나 Spanner와 같은 분산 SQL 데이터베이스에서 자주 볼 수 있는 자동 샤딩은 데이터와 트래픽의 분산을 자동으로 처리합니다. 시스템은 각 서버의 데이터 크기와 부하를 모니터링합니다. 특정 샤드가 '핫스팟'이 되거나 너무 커지면 데이터베이스 엔진이 자동으로 샤드를 분할하고 데이터를 덜 혼잡한 서버로 이동합니다. 이를 통해 팀의 운영 부담을 줄이고 애플리케이션이 확장될 때 일관된 성능을 유지할 수 있습니다.

파티셔닝은 큰 테이블을 더 작고 관리하기 쉬운 조각으로 분할(예: 로그 테이블을 월별로 분할)하지만 동일한 서버 인스턴스에 유지하는 것을 의미합니다. 이렇게 하면 테이블의 나머지 부분에 영향을 주지 않고 이전 데이터를 더 쉽게 보관처리하거나 삭제할 수 있으므로 스토리지 문제가 해결됩니다. 하지만 서버 문제를 해결하지는 못합니다. 모든 파티션이 여전히 단일 머신에 상주하므로 동일한 CPU와 RAM을 계속 공유합니다. 즉, 서버가 성능 한도에 도달하면 파티셔닝이 도움이 되지 않습니다.

복제는 전체 데이터베이스를 여러 서버에 복사하는 프로세스입니다. 읽기 가용성 측면에서 좋은 선택이 될 수 있습니다. 한 서버에 장애가 발생하면 다른 서버가 인계할 수 있습니다. 그러나 작성된 모든 데이터가 모든 복제본에 복사되어야 하므로 쓰기 속도가 단일 머신의 용량으로 제한되어 쓰기 확장에는 도움이 되지 않습니다.

또 하나 중요한 것은 대부분의 복제 모델은 한 번에 하나의 '작성자'(기본 노드)만 허용합니다. 여러 서버가 동시에 쓰기를 수락하도록 허용하려고 하면 2개의 서버가 서로 다른 정보로 동일한 레코드를 업데이트하려고 시도하는 쓰기 충돌이 발생할 위험이 있습니다. 이러한 충돌을 해결하는 것은 기술적으로 어렵고 정교한 분산 시스템으로 처리하지 않으면 데이터 손실이나 불일치로 이어질 수 있습니다.

Spanner와 같은 분산 데이터베이스는 수동 오버헤드 없이 샤딩의 이점을 제공합니다. 이러한 시스템은 처음부터 머신 클러스터 전반에 걸쳐 작동하도록 설계되었습니다. 데이터 배포, 재조정, 복제를 자동으로 투명하게 처리합니다. 이러한 시스템 중 일부에는 여러 작성자가 있으며 쓰기 충돌을 자동으로 처리합니다. 이를 통해 기존 관계형 데이터베이스의 일관성을 유지하면서 수평으로 확장할 수 있습니다.