sonumb

TiDB Architecture 본문

개발자 이야기/DBMS_Development

TiDB Architecture

sonumb 2021. 11. 2. 14:31
✅ 정보:
 https://docs.pingcap.com/tidb/stable/architecture (v4.0)
를 번역한 문서다.

 

TiDB 플랫폼은

  • TiDB 서버
  • PD 서버 및
  • TiKV 서버

의 세 가지 주요 구성 요소로 구성됩니다. 

또한 TiDB는 

  • 복잡한 OLAP 요구 사항을위한 TiSpark 구성 요소 와
  • 클라우드의 배포 및 관리 작업을 간소화하기 위해 TiDB 오퍼레이터 

를 제공합니다.

 

TiDB 서버

TiDB 서버는 다음 작업을 담당합니다.

  1. SQL 요청을 받기
  2. SQL 관련 로직 처리
  3. 데이터 저장 및 컴퓨팅을 위해서, PD(Placement Driver)를 통해 TiKV 주소 찾기
  4. TiKV와 데이터 교환
  5. 결과 반환

TiDB 서버는 상태를 저장하지 않습니다(stateless). 데이터를 저장하지 않으며 컴퓨팅 전용입니다. TiDB는 수평 확장 가능하며 Linux Virtual Server (LVS), HAProxy 또는 F5와 같은로드 밸런싱 구성 요소를 통해 외부에 통합 인터페이스를 제공합니다.

PD(Placement Driver) 서버

PD (Placement Driver) 서버는 전체 클러스터의 관리 구성 요소이며 다음 세 가지 작업을 담당합니다.

  1. 특정 키의 지역 위치와 같은 클러스터의 메타 데이터 저장
  2. TiKV 클러스터 내에서 스케쥴링과 로드 밸런싱
    1. 데이터 마이그레이션 및 Raft 그룹 리더 전송은 제한하지 않음
  3. 전 세계적으로 고유하고, 하나씩 증가하는 트랜잭션 ID를 할당합니다.

PD 서버는 Raft 컨센서스 알고리즘을 사용하여 중복성을 보장합니다. Raft 리더는 모든 작업을 처리 할 책임이 있으며, 나머지 PD 서버는 고가용성에만 사용할 수 있습니다. 홀수 개의 노드로 PD를 배치하는 것이 좋습니다.

TiKV 서버

TiKV 서버는 데이터 저장을 담당합니다. 외부 관점에서 TiKV는 분산 트랜잭션 키-값 스토리지 엔진입니다. 리전(Region)은 데이터 저장의 기본 단위입니다. 각 리전은 특정 Key Range로 데이터를 저장하는데, 이는 StartKey에서 EndKey까지이며 왼쪽-닫힘 및 오른쪽-열림입니다. (주석: 예를 들어, [0,200) 의 경우, 0~199의 키들이다). 각 TiKV 노드에는 다수의 리전이 있습니다. TiKV는 복제에 Raft 프로토콜을 사용하여 데이터 일관성 및 재해 복구를 보장합니다. 다른 노드에서 동일한 리전의 복제본은 Raft Group으로 구성합니다. 다른 TiKV 노드들 사이에서 데이터의 로드 밸런싱은 리전 PD가 리전 단위 내 부하를 스케줄링하여 수행(carry out)된다.

TiSpark

TiSpark는 복잡한 OLAP 요구 사항을 처리합니다. TiSpark는 Spark SQL을 TiDB 클러스터의 스토리지 계층에서 직접 실행하고, 분산 TiKV 클러스터의 장점을 결합한 후, 빅데이터 에코 시스템에 통합합니다. TiSpark를 사용하면, TiDB는 하나의 클러스터에서 OLTP 및 OLAP 시나리오를 모두 지원할 수 있으므로 사용자는 데이터 복제에 대해 걱정할 필요가 없습니다.

✅ OLAP을 위해서, TiFlash 가 필요하다. TiFlash는 columnar 스토리지 엔진이다.

 

TiDB 오퍼레이터

TiDB 오퍼레이터(operator)는 TiDB 사용자가 클라우드 인프라인 Kubernetes에 TiDB 클러스터를 배치하고 관리 할 수 있도록합니다.

TiDB 오퍼레이터:

  • 클라우드 네이티브 커뮤니티의 컨테이너 오케스트레이션 모범 사례와 TiDB 운영 및 유지 관리 노하우를 결합합니다.
  • 빠른 배포, 여러 클러스터 간의 혼합 배포, 자동 운영 및 유지 관리, 자동 장애 조치 등
  • TiDB를 사용하고 관리하기에 편리합니다.
반응형