분산 데이터베이스는 분산 컴퓨팅의 원리를 데이터 저장에 적용합니다. 가장 간단한 예는 네트워크로 연결된 두 대 이상의 서버에 데이터를 저장하는 데이터베이스입니다. 이 '클러스터'는 마치 하나의 데이터베이스 서버인 것처럼 액세스하고 관리할 수 있습니다.
이에 비해 데이터베이스의 전통적인 단일 서버 모델은 하나의 서버에 존재합니다.
서비스에 분산 데이터베이스 아키텍처를 사용할 때의 주요 이점은 다음과 같습니다:
- 부하 처리를 위한 클러스터링(수평 확장)
- 고가용성(하나의 서버가 오프라인 상태가 되어도 나머지 서버는 온라인 상태를 유지하며 사용 가능)
- 복제(고가용성, 재해 복구 및 지리적 배포 지원)
분산 데이터베이스에는 다양한 옵션, 토폴로지, 서버 간에 부하를 분산하는 방법 등 많은 모범 사례가 있습니다. 그렇다면 분산 데이터베이스는 어떻게 작동할까요?
수평 스케일링
소규모 애플리케이션과 데이터를 위한 단일 데이터베이스 서버는 지금까지 잘 작동해 왔습니다. 그러나 대규모의 공개 사용자 기반에 노출된 경우 이러한 서버의 용량을 늘리는 유일한 방법은 더 비싼 서버로 업그레이드하는 것입니다.
용량을 늘리려면 데이터베이스 소프트웨어를 메모리, 디스크 공간, 프로세서가 더 많은 다른 단일 시스템으로 옮기세요. 이를 "수직 확장"이라고 합니다. 이 접근 방식의 단점은 다운타임이 필요할 수 있다는 것입니다. 또한 단일 시스템에서 얻을 수 있는 성능에는 한계가 있습니다. (허브 서터의 공짜 점심은 끝났습니다).
안타깝게도 많은 데이터베이스, 특히 관계형(RDBMS) 데이터베이스는 분산 및 클러스터링이 가능하도록 설계되지 않았습니다.
하지만 분산 데이터베이스는 처음부터 탄력적인 확장성을 지원하기 위해 만들어집니다. 더 많은 부하를 처리하기 위해 더 많은 리소스를 추가해야 하나요? 데이터베이스 소프트웨어를 1대 이상의 컴퓨터에 추가로 설치하고 클러스터에 추가하세요.
그런 다음 필요할 때 저렴한 상용 머신을 클러스터에 추가하세요. 더 이상 필요하지 않은 경우 제거하여 규모를 축소할 수도 있습니다.
분산 데이터베이스 아키텍처
데이터베이스의 경우, 데이터를 배포하는 데 널리 사용되는 두 가지 접근 방식이 있습니다: 기본/보조(역사적으로 마스터/슬레이브) 및 shared-nothing (마스터리스라고도 함).
기본/보조 아키텍처
기본/보조 아키텍처에는 지정된 "기본" 서버가 있습니다. 이 서버는 모든 데이터를 저장하고 모든 데이터 요청을 처리합니다. 하나 이상의 "보조" 서버가 있습니다. 이러한 서버는 동기화 상태를 유지하고 데이터의 완전한 복제본을 저장하기 위해 기본 서버로부터 데이터 업데이트를 받습니다.
기본 서버가 오프라인 상태가 되면(충돌) 나머지 서버(및/또는 조정 서버)가 보조 서버 중 하나를 새 기본 서버로 지정합니다.
아키텍트는 이 패턴을 사용하여 다음을 제공합니다. 고가용성 를 기존의 비분산형 데이터베이스로 전환했습니다. 그러나 이러한 분산 데이터베이스 아키텍처는 부하 증가 문제를 해결하는 데 큰 도움이 되지 않습니다. 이를 해결하기 위해 샤딩 를 사용해야 합니다.
공유되지 않는 분산 데이터베이스
공유 아키텍처는 데이터를 일반적으로 "샤드"라고 하는 파티션으로 분할합니다. 각 샤드는 클러스터의 개별 서버(노드)에 존재합니다. 예를 들어 레코드가 300개이고 노드가 3개인 경우, 각 노드는 (이상적으로는) 100개의 레코드를 저장합니다. 각 추가 노드는 데이터를 추가로 분할하고 필요에 따라 부하를 계속 분산시킬 수 있습니다.
클러스터는 또한 고가용성을 유지하기 위해 노드 간에 샤드를 복제합니다. 예를 들어, 노드 1에 활성 샤드 A가 포함되어 있으면 노드 2에는 복제 샤드 A가 포함되는 식입니다.
그런 다음 노드 3이 오프라인 상태가 되면 클러스터는 샤드 C의 복제본을 활성으로 승격하여 분산 DB 클러스터를 (전체적으로) 온라인 상태로 유지합니다.
관계형 데이터베이스의 특성은 데이터의 개별 행을 긴밀하게 연결된 테이블에 함께 저장하는 것입니다. 따라서 분산형 SQL 데이터베이스는 어렵습니다. 그렇기 때문에 클러스터링, 고가용성, 복제가 중요한 조직에서는 NoSQL을 선택하는 경우가 많습니다. NoSQL은 테이블 외부에 존재할 수 없는 엄격하게 결합된 데이터를 클러스터의 특정 샤드에 존재할 수 있는 독립 데이터와 교환합니다.
분산 데이터베이스 예제
사용하는 분산 DB에 따라 샤딩은 완전히 자동으로 이루어질 수도 있고 계획 및 유지 관리에 상당한 노력이 필요할 수도 있습니다.
널리 사용되는 NoSQL을 사용하는 분산 데이터베이스의 두 가지 예와 그 차이점을 살펴보겠습니다:
카우치베이스 서버
카우치베이스 서버는 데이터를 문서라는 개별 JSON 데이터 조각으로 저장하는 분산형 NoSQL 데이터베이스입니다. 각 문서에는 고유한 키가 있습니다.
각 문서는 샤드 내에 존재합니다( vBuckets )로 구성되며, 각 샤드는 노드에 할당됩니다. Couchbase 클러스터에는 총 1024개의 고정된 양의 vBucket이 있습니다.
카우치베이스 자동으로 는 키를 기반으로 문서를 vBucket에 할당합니다(CRC32 해싱 알고리즘 사용). 개발자, DBA 또는 DevOps가 샤딩을 만들고 관리할 필요가 없습니다. 각 노드에는 클러스터 관리자 를 통해 모든 샤드의 균형을 유지하고 데이터가 고르게 분산되도록 합니다. 한 노드가 다른 노드보다 훨씬 더 많은 양의 데이터를 저장하는 '핫스팟'이 없습니다. 쿼리 라우팅을 처리하거나 로드 밸런싱을 제공하기 위해 Couchbase Server 클러스터 외에 다른 서버가 필요하지 않습니다.
MongoDB
몽고DB는 분산형 NoSQL 데이터베이스이기도 합니다. 또한 데이터를 다음과 같은 형식의 개별 조각으로 저장합니다. 유사 을 BSON이라는 JSON으로 변환합니다. 각 문서에는 고유한 키가 있습니다.
MongoDB는 샤딩에 대해 다른 접근 방식을 취합니다. 데이터를 샤딩하려면 샤드 키(하나 이상의 BSON 데이터 조각으로 구성)를 선택해야 합니다. 예를 들어, '성'과 '우편 번호'로 데이터를 샤딩하는 것을 고려할 수 있습니다.
샤드 키를 정의하면, Mongo는 "쿼리 라우터"를 실행하는 다른 서버를 통해 클라이언트 요청을 라우팅합니다. 이 쿼리 라우터는 "구성 서버"라는 또 다른 서버를 참조합니다. 그러면 원하는 샤드가 어느 데이터 서버에 있는지 확인할 수 있습니다.
샤딩 프로세스는 자동으로 진행되지 않습니다. 개발팀은 병목 현상과 핫스팟을 피하기 위해 샤드 키를 신중하게 선택하고 주기적으로 검토해야 합니다.
요약
이는 주목할 만한 두 가지 분산 데이터베이스 예시일 뿐입니다. 아키텍처에 대한 다양한 접근 방식을 취하는 더 많은 예가 있습니다.
이들 모두의 공통점은 네트워크에 연결된 서버에 데이터를 저장한다는 점입니다.
카우치베이스 서버의 자동 샤딩 방식에 관심이 있으신가요? 이것은 Couchbase가 할 수 있는 일의 극히 일부에 불과합니다. 내장된 메모리 우선 아키텍처, 전체 텍스트 검색, 분산 SQL 쿼리 기능 등을 갖춘 Couchbase는 완벽한 데이터 플랫폼입니다. 지금 Couchbase Server 다운로드 를 클릭하고 사용해 보세요.
[...]에 데이터를 저장하여 중요한 파일과 문서를 모니터링하지 않도록 하세요. https://www.couchbase.com/distributed-databases-overview/ 같은 사이트를 방문하여 [...]에 대해 자세히 알아보세요.