TDSQL for MySQL은 자동 샤딩(수평 분할) 및 Shared Nothing 아키텍처를 지원하는 Tencent Cloud에 배포된 분산 데이터베이스 서비스입니다. 분산 데이터베이스를 사용하면 백엔드의 여러 물리적 샤드 노드에 균등하게 분할 및 분산되는 완전한 논리적 데이터베이스 테이블을 얻을 수 있습니다. TDSQL은 기본적으로 프라이머리-세컨더리 아키텍처를 배포하고 재해 복구, 백업, 복원, 모니터링 및 마이그레이션을 위한 전체 솔루션 세트를 제공하므로 TB 또는 PB의 데이터를 저장하는 데 이상적입니다.
제품 특징
OLTP
TDSQL은 OLTP 비즈니스를 위한 분산 데이터베이스입니다.
샤딩
TDSQL은 샤딩을 지원하는 분산 데이터베이스입니다.
샤딩은 정의된 규칙에 따라 테이블의 데이터를 여러 개의 독립된 물리적 데이터베이스 서버로 분산시켜 ‘독립적’인 데이터베이스 ‘샤드’를 형성하는 것입니다. 여러 샤드가 함께 논리적으로 완전한 데이터베이스 인스턴스를 형성합니다.
Shared Nothing 아키텍처
Shared Nothing 아키텍처는 단순히 더 많은 서버를 추가하여 데이터와 액세스 용량을 확장할 수 있습니다. 대부분의 사용자의 데이터베이스 용량 요구 사항을 충족할 수 있지만 본질적으로 용량 및 성능 병목 현상이 발생하기 쉽고 상대적으로 비용이 많이 드는 미니 컴퓨터 + 공유 스토리지 솔루션입니다.
데이터 분할 방법(샤딩 규칙)
TDSQL은 원칙적으로 자동 수평 분할을 기반으로 하는 샤딩 방식을 사용합니다. 구체적으로, shardkey에 대해 모듈로 연산을 실행한 후, 모듈로 연산 후 특정 값 범위에 따라 TProxy를 통해 데이터를 다른 데이터베이스에 배포합니다.
관계형 데이터베이스는 2차원 모델입니다. 데이터를 샤딩하려면 일반적으로 샤딩 차원을 결정하기 위해 **샤드키 필드(shardkey)**를 찾아야 합니다. 그런 다음 실제로 데이터베이스를 샤딩하기 위한 규칙을 정의해야 합니다.
몇 가지 일반적인 샤드키 옵션:
연도별 샤딩과 같은 날짜 순서를 기반으로 합니다(2015년 1개 샤드, 2016년 1개 샤드).
장점: 간단하고 찾기 쉽습니다.
단점: 현재(예: 2016년) 핫 데이터에 대한 서버 성능이 부족할 수 있는 반면 콜드 데이터에 대한 스토리지 성능은 유휴 상태일 수 있습니다.
모듈로 작업 후 특정 범위의 필드가 다른 데이터베이스에 분산되는 사용자 ID 모듈로를 기반으로 합니다.
장점: 성능이 비교적 균형 잡혀 있고 동일한 사용자의 모든 데이터가 동일한 데이터베이스에 있습니다.
단점: 데이터 왜곡을 유발할 수 있습니다(예: 판매자 시스템을 설계할 때 이커머스 쇼핑몰에 있는 한 판매자의 데이터는 수천 명의 소규모 판매자의 데이터보다 많을 수 있음).
모듈로 작업 후 특정 범위의 필드가 다른 데이터베이스에 분산되는 기본 키(primary key) 모듈로를 기반으로 합니다.
장점: 성능이 상대적으로 균형을 이루고 데이터 왜곡이 거의 발생하지 않으며 동일한 기본 키의 모든 데이터가 동일한 데이터베이스에 있습니다.
단점: 데이터가 무작위로 배포되며 일부 비즈니스 논리에는 직접 지원되지 않는 교차 샤드 join이 필요할 수 있습니다.
여러 테이블을 샤딩하기 전에 사용 가능한 옵션:
Noshard: 샤딩이 없습니다.
tableshard: 각 테이블이 샤딩될 때 테이블 간 관계에 관계없이 실제 필요에 따라 샤딩을 위해 임의로 샤드 키를 선택합니다.
groupshard: 관련 데이터를 하나의 물리적 노드로 집계할 수 있도록 몇 개의 상관 테이블이 동일한 샤드 키를 기반으로 설계되었습니다.
분할된 데이터 소스 관리 측면에서 현재 두 가지 모드:
클라이언트 모드: 여러 샤드의 데이터 소스는 비즈니스 프로그램 모듈의 구성에 의해 관리되며 샤드의 읽기, 쓰기 및 데이터 통합은 비즈니스 프로그램 내에서 수행됩니다.
미들웨어 프록시 모드: 미들웨어 프록시는 프런트엔드 애플리케이션에서 감지할 수 없는 샤딩 데이터베이스의 프런트엔드에 구축됩니다.
TDSQL이 해결할 수 있는 문제
독립 실행형 데이터베이스의 성능 병목 현상
수백만 명의 인터넷 기반 비즈니스 사용자에 직면하여 독립 실행형 데이터베이스는 비즈니스가 성장함에 따라 하드웨어 및 소프트웨어 제한으로 인해 데이터 저장 용량, 액세스 용량 및 재해 복구에서 병목 현상에 도달하게 됩니다.
애플리케이션 계층 샤딩 개발을 위한 과중한 워크로드
애플리케이션 계층 샤딩은 비즈니스 로직과 데이터베이스 로직을 긴밀하게 연결하므로 현재 비즈니스의 빠른 반복에 많은 개발 워크로드가 발생합니다. 감지할 수 없는 TDSQL의 샤딩 체계를 기반으로 개발자는 후속 반복 동안 데이터베이스 로직에 많은 신경을 쓰지 않고 초기 액세스 중에만 코드를 수정하면 되므로 개발 워크로드를 크게 줄일 수 있습니다.
오픈 소스 솔루션 또는 NoSQL의 문제
오픈 소스 또는 NoSQL 솔루션을 선택하면 데이터베이스 병목 현상을 무료로 또는 비교적 저렴한 비용으로 해결할 수도 있습니다. 그러나 이러한 솔루션과 관련하여 다음 문제에 주의해야 합니다.
1. 제품의 bug 수정은 커뮤니티의 진행 상황에 따라 다릅니다. 심각한 bug가 발생하면 기다릴 수 있습니까?
2. 제품에 익숙하고 직원 변경 시 프로젝트에 영향을 미치지 않고 지속적으로 유지할 수 있는 팀 구성원이 있습니까?
3. 관련 시스템이 준비되어 있습니까?
4. 어떤 비즈니스에 집중하시나요? 귀하의 비즈니스 메트릭 시스템에는 오픈 소스 제품의 리소스 및 수명 주기 관리, 분산 논리, 고가용성 배포 및 전환, 재해 복구 및 백업, 셀프 OPS, 문제 해결을 보장하기 위한 리소스 입력이 포함됩니까?
