데이터베이스 샤딩 개요
데이터베이스 샤딩은 데이터베이스의 성능과 확장성을 최적화하는 강력한 도구입니다. 데이터에 더 빠르게 액세스할 수 있으며, 데이터와 처리 능력을 여러 서버에 분산하여 데이터베이스가 더 큰 워크로드를 처리할 수 있게 해줍니다. NoSQL 데이터베이스는 분산 컴퓨팅과 자동 샤딩을 염두에 두고 설계되었기 때문에 샤딩과 가장 연관성이 높은 데이터베이스인 경우가 많습니다. 하지만 충분한 노력만 기울이면 어떤 데이터베이스 기술로도 샤딩을 수행할 수 있습니다.
데이터베이스 샤딩은 어떻게 작동하나요?
데이터베이스 샤딩은 전체 데이터 집합을 샤드라고 하는 여러 그룹으로 나눕니다. 일단 분할된 각 샤드는 일반적으로 클러스터라고 하는 여러 서버에 독립적으로 저장할 수 있습니다. 각 샤드는 독립적으로 액세스할 수 있으므로 데이터에 더 빠르게 액세스할 수 있고 처리, 컴퓨팅, 저장에 더 많은 리소스를 사용할 수 있습니다.
샤딩은 어디에서 이루어지나요?
데이터베이스에 샤딩 기능이 내장되어 있는 경우, 개발팀은 샤딩을 구현하는 데 필요한 작업이 줄어듭니다. 샤딩이 선택적 기능이거나 구성이 필요한 경우에는 신중하게 계획해야 하지만 샤딩을 위해 코드베이스를 크게 변경하거나 추가할 필요는 없습니다. 기본 데이터베이스가 샤딩을 수행할 수 없는 경우(많은 관계형 데이터베이스의 경우처럼) 코드베이스를 크게 변경해야 할 수 있으며, 개발자는 애플리케이션의 지속성 계층에 샤딩을 구축해야 합니다.
데이터를 샤딩해야 하나요?
샤딩을 사용할지 여부는 여러 가지 요인에 따라 달라집니다. 이러한 요인에는 데이터 집합의 크기, 시스템 사용자 수, 수행되는 작업 수, 인프라 제약 등이 포함됩니다.
사용자 또는 작업 수가 증가하여 애플리케이션의 성능이 눈에 띄게 저하되는 경우, 수평적 확장(샤딩을 사용하는 경우가 많습니다)은 데이터베이스에서 사용할 수 있는 컴퓨팅 리소스를 늘리는 한 가지 방법입니다. 그러나 성능 저하는 최적이 아닌 코드, 적절한 인덱스의 부족, 데이터 모델링 변경의 필요성 또는 기타 문제를 나타낼 수도 있습니다. 샤딩이 항상 성능 향상을 위한 첫 번째 선택은 아니지만, 일부 데이터베이스 기술의 경우 샤딩이 성능 목표를 달성하기 위한 마찰이 적은 수단이 될 수 있습니다.
샤딩의 장점
- 더 빠른 성능: 입력/출력을 처리할 수 있는 서버가 더 많아졌습니다.
- 수평 확장: 클러스터에 서버를 빠르게 추가할 수 있습니다.
- 비용: 수평적 확장은 수직적 확장(즉, 한 서버를 더 강력한 서버로 업그레이드하는 것)보다 비용이 적게 드는 경우가 많습니다.
- 분산/가동 시간: 수평적으로 확장된 분산 데이터베이스는 기존의 단일 서버보다 더 나은 가동 시간을 달성할 수 있습니다.
샤딩의 단점
- 복잡성: 데이터베이스 시스템에 따라 샤딩 복잡성은 달라질 수 있습니다. 일부 데이터베이스는 분산, 수평적 확장 및 샤딩이 포함된 상태로 설계되었습니다. 다른 데이터베이스는 보다 실질적인 DIY 접근 방식이 필요합니다.
- 리밸런싱: 클러스터에 시스템을 추가할 때 데이터를 균등하게 분산하기 위해 샤드를 재조정해야 할 수 있습니다. (예를 들어, 3개의 샤드에 1,000개의 문서가 균등하게 분산되어 있다면 샤드당 약 333개의 문서가 있는 셈입니다. 네 번째 샤드를 추가하면 샤드당 250개의 문서가 균등하게 분산됩니다.) 데이터베이스에 샤딩 기능이 내장되어 있지 않은 경우, 리밸런싱은 복잡한 수동 DIY 프로세스가 될 수밖에 없습니다.
샤딩의 유형
샤딩에는 여러 가지 접근 방식이 있습니다. 일부 데이터베이스 시스템에는 샤딩 기능이 내장되어 있는 반면, 샤딩을 직접 지원하지 않는(그리고 많은 사용자 정의 코딩이나 DIY 프로세스가 필요한) 시스템도 있습니다. 각 접근 방식의 목표는 데이터를 일관되게 샤드로 분할하여 매번 동일한 샤드에서 데이터를 조회하거나 샤드에 쓸 수 있도록 하는 것입니다.
범위 기반 샤딩
범위 기반 샤딩은 데이터 값을 선택하고 특정 범위에 속하는지 여부에 따라 샤드에 할당하는 것을 포함합니다. 예를 들어 연령이 포함된 사용자 데이터가 있는 경우, 한 샤드에는 0~10세 사이의 사용자를 저장하고, 다른 샤드에는 11~20세 사이의 사용자를 저장하는 등의 방식으로 저장할 수 있습니다.
이 접근 방식은 한 샤드가 다른 샤드보다 더 많은 사용자를 저장하게 될 수 있기 때문에 문제가 될 수 있습니다. 또한 불균형적으로 많은 양의 데이터를 저장하는 샤드는 성능에 영향을 미치는 핫스팟이 될 수 있습니다.
키 기반 샤딩
키 기반 샤딩은 좀 더 독립적인 접근 방식을 취합니다. 데이터의 값(일반적으로 NoSQL 문서 데이터베이스의 문서 ID)은 해시를 통해 실행되며, 이 해시는 데이터를 어느 샤드에 저장할지 결정합니다.
데이터베이스에 액세스하는 모든 애플리케이션이 해시를 구성할 수 있어야 하므로 데이터베이스에서 직접 지원하지 않는 경우 이 접근 방식은 문제가 될 수 있습니다. 또한 이 접근 방식을 사용하려면 해시에 사용되는 데이터 값이 불변이어야 합니다. 이는 일반적으로는 문제가 되지 않지만 드문 에지 케이스의 경우 문제가 될 수 있습니다.
카우치베이스 사용 자동 키 기반 샤딩 를 사용하여 클러스터에 데이터를 고르게 분산하고 자동 리밸런싱과 자동 복제 기능도 제공합니다. 이러한 자동화를 통해 중요한 프로세스를 간소화하고 개발 팀의 소중한 시간을 확보할 수 있습니다.
디렉토리 기반 샤딩
디렉터리 기반 샤딩은 데이터의 일부 값이 조회 테이블 또는 조회 구성에 있는 값을 기반으로 특정 샤드에 매핑되는 접근 방식입니다. 범위 접근 방식과 유사하지만 간단한 조회가 포함될 수 있습니다. 예를 들어, 오하이오에 주소가 있는 사용자는 '오하이오' 샤드에 저장되고, 캘리포니아에 있는 사용자는 '캘리포니아' 샤드에 저장되는 식입니다.
이 접근 방식은 조회 테이블이나 구성을 사용할 수 없게 되거나 다운되거나 손상될 수 있기 때문에 문제가 될 수 있습니다. 이러한 경우 애플리케이션은 더 이상 읽기 또는 쓰기를 수행할 수 없습니다.
지리적 샤딩
지리적 샤드는 다른 샤딩 옵션과 함께 사용하거나 다른 샤딩 옵션 대신 사용할 수 있습니다. 지리적 샤딩의 기본 개념은 데이터를 가장 자주 액세스하는 위치에 물리적으로 가까운 곳에 저장하는 것입니다. 예를 들어 오하이오 주소의 사용자는 오하이오에 있는 서버에 저장하고 캘리포니아 주소의 사용자는 캘리포니아에 있는 서버에 저장하는 것입니다.
이 접근 방식은 더 빠른 액세스를 제공할 수 있지만 핫스팟과 활용도가 낮은 서버를 초래할 수도 있습니다. 또한 지리적 샤딩은 특정 애플리케이션이나 관할 지역의 법적 요건을 충족하지 못할 수도 있습니다.
자동 샤딩을 제공하는 것 외에도 Couchbase는 다음을 통해 지리적 샤딩을 지원할 수 있습니다. 데이터 센터 간 복제(XDCR).
엔티티 기반 샤딩
엔티티 기반 샤딩은 서로 밀접하게 연관된 개별 데이터가 동일한 샤드에 함께 저장되는 것을 의미합니다. 예를 들어, 사용자는 애플리케이션 로직 내에서 하나의 엔티티로 간주되지만 사용자의 쇼핑 내역은 다른 샤드에 별도로 저장될 수 있습니다. 관련 데이터를 같은 샤드에 저장하면 동시에 검색하는 데 필요한 컴퓨팅 작업량을 줄일 수 있습니다.
이 접근 방식의 단점은 복잡성입니다. 특히 일부 데이터를 여러 엔터티에서 사용하는 경우에는 어떤 데이터를 어디로 보낼지 구성하는 과정이 복잡할 수 있습니다.
데이터베이스 샤딩의 대안
수평 확장에는 항상 어느 정도 수준의 샤딩이 수반되지만, 다음과 같은 다양한 옵션이 있습니다. 어떻게 를 샤딩할 수 있습니다. 한 가지 방법은 마이크로서비스 아키텍처나 사용자에게 불투명한 물리적 디스크 샤딩과 같은 아키텍처 샤딩입니다. 샤딩을 숨기고 추상화할 수도 있습니다. 클라우드 데이터베이스.
데이터베이스 시스템을 고려할 때는 샤딩이 어떻게 수행되는지 이해하는 것이 중요합니다. 완전히 추상화되어 숨겨져 있을 수도 있고, 자동일 수도 있으며, 잠재적으로 복잡한 구성 옵션으로 지원될 수도 있고, 지원되지 않아서 DIY 접근 방식이 필요할 수도 있습니다.
데이터베이스 샤딩에 Couchbase Capella가 도움이 되는 방법
카우치베이스 카펠라 는 디지털 기업을 위한 클라우드 데이터베이스 플랫폼입니다.
Capella는 키 기반 자동 샤딩인 Couchbase Server와 동일한 샤딩 시스템을 사용합니다. 사용자 또는 개발자의 관점에서 볼 때, Couchbase를 사용한 샤딩은 추가 구성이나 유지 관리가 필요하지 않습니다. Capella는 vBuckets와 함께 CRC32 알고리즘을 사용함으로써 시스템에 핫스팟이 생기지 않도록 보장합니다.
Capella는 복제를 자동화합니다. 원하는 복제본 수를 선택하기만 하면 나머지는 Capella가 알아서 처리합니다.
Capella는 리밸런싱도 자동화합니다. 서버를 추가하거나 클러스터에서 제거하면 가동 중단 시간 없이 자동으로 서버의 밸런스를 재조정합니다.
마지막으로, Capella는 XDCR 기능을 통해 지리적 샤딩을 구현할 수 있습니다. XDCR은 데이터 센터 간에 데이터를 실시간으로 복제합니다. XDCR 복제는 로컬 지연 시간을 개선하거나 데이터 위치 요건을 충족하기 위해 사용자 정의 필터에 따라 데이터를 포함하거나 제외할 수 있습니다.
결론
샤딩은 더 많은 작업을 처리하기 위해 데이터베이스를 확장하는 경우 이해해야 할 중요한 개념입니다. NoSQL 데이터베이스는 관계형 데이터베이스에 의해 부과되는 많은 제약을 제거하기 때문에 특히 샤딩에 적합합니다. 즉, Couchbase Capella는 관계형 데이터베이스의 최고의 기능 중 일부(SQL 구문 및 JOIN 및 산 거래)를 자동 샤딩을 통해 분산 데이터베이스에 저장합니다.
Couchbase의 샤딩에 대해 자세히 알아보려면 여기를 확인하세요:
데이터베이스 확장 방법을 고려하는 데 도움이 되는 기타 중요한 리소스입니다:
