예, TiDB는 go 언어로 작성되었습니다. TiDB는 분산형 NewSQL 데이터베이스입니다. 수평적 탄력적 확장, ACID 트랜잭션, 표준 SQL, MySQL 구문 및 MySQL 프로토콜을 지원하며 강력한 데이터 일관성과 고가용성 기능을 갖추고 있습니다. TiDB 아키텍처의 PD는 키가 어느 TiKV 노드에 있는지와 같은 클러스터의 메타 정보를 저장합니다. PD는 클러스터의 로드 밸런싱 및 데이터 샤딩도 담당합니다. PD는 etcd를 내장하여 데이터 배포 및 내결함성을 지원합니다. PD는 go 언어로 작성되었습니다.
이 튜토리얼의 운영 환경: Windows 7 시스템, GO 버전 1.18, Dell G3 컴퓨터.
Go 언어에는 많은 헤비급 프로젝트가 있는데, 중국에서 가장 강력한 Go 오픈소스 프로젝트는 아마도 TiDB일 것입니다. TiDB는 많은 사람들이 전혀 알지 못하는 분산 데이터베이스입니다. 오늘은 이 주제에 대해 말씀드리겠습니다.
TiDB는 디자인이 단순하고 공식 웹사이트와 코드가 매우 읽기 쉽습니다. 분산 데이터베이스 학습을 위한 첫 번째 선택 오픈 소스 프로젝트입니다.
데이터베이스, 운영 체제, 컴파일러를 총칭하여 3대 시스템이라고 하며, 이는 전체 컴퓨터 소프트웨어의 초석이라고 할 수 있습니다.
많은 사람들이 데이터베이스를 사용해왔지만 데이터베이스, 특히 분산 데이터베이스를 구현한 사람은 거의 없습니다. 데이터베이스의 구현 원리와 세부 사항을 이해하면 한편으로는 개인의 능력을 향상시키고 다른 시스템을 구축하는 데 도움이 될 수 있으며, 다른 한편으로는 데이터베이스를 효과적으로 활용하는 데에도 도움이 될 수 있습니다.
TiDB는 분산형 NewSQL 데이터베이스입니다. 수평 탄력적 확장, ACID 트랜잭션, 표준 SQL, MySQL 구문 및 MySQL 프로토콜을 지원하며 강력한 데이터 일관성의 고가용성 기능을 갖추고 있으며 OLTP 시나리오뿐만 아니라 OLAP에도 적합한 하이브리드 데이터베이스입니다. 시나리오. OLTP: 온라인 거래 처리, 온라인 거래 처리
.OLAP: 온라인 분석 처리, 온라인MySQL 5.7과 높은 호환성분석 처리.
TiDB는 현재 트리거, 저장 프로시저, 사용자 정의 함수 및 외래 키를 지원하지 않습니다.
사용 편의성.
분산 트랜잭션 지원
TiDB 트랜잭션 모델은 Google Percolator 모델에서 영감을 받았습니다. 본체는
2단계 커밋 프로토콜이며 몇 가지 실용적인 최적화가 이루어졌습니다. 이 모델은 트랜잭션 충돌이 감지되도록 각 트랜잭션에 단조롭게 증가하는 타임스탬프를 할당하는 타임스탬프 할당자를 사용합니다. TiDB 클러스터에서 PD는 타임스탬프 배포자 역할을 합니다. TiDB는 MySQL과 같은 데이터베이스 간 트랜잭션을 충족하기 위해 XA를 지원할 필요가 없습니다. TiDO 자체 분산 트랜잭션 모델은 성능 및 안정성 측면에서 XA보다 훨씬 높으므로 XA를 지원할 필요도 없습니다.
전통적인 독립형 데이터베이스와 비교하여 TiDB는 다음과 같은 장점이 있습니다
:순수 분산 아키텍처, 우수한 확장성, 탄력적인 확장 및 축소 지원
SQL 지원, MySQL 네트워크 프로토콜을 외부에 노출 world 이며 대부분의 MySQL 구문과 호환되므로 대부분의 시나리오에서 MySQL을 직접 대체할 수 있습니다원클릭 가로 확장 또는 축소
디자인 덕분입니다 TiDB의 스토리지와 컴퓨팅 분리 아키텍처는 컴퓨팅과 스토리지를 필요에 따라 별도로 수행할 수 있습니다. 온라인 확장 또는 축소, 확장 또는 축소 프로세스는 애플리케이션 운영 및 유지 관리 담당자에게 투명합니다.
금융 수준의 고가용성
데이터는 여러 복사본에 저장됩니다. 데이터 복사본은 Multi-Raft 프로토콜을 통해 트랜잭션 로그를 동기화하여 강력한 데이터 일관성을 보장합니다. 데이터 가용성에 영향을 주지 않고 몇 가지 복사본의 오류를 방지합니다. 다양한 재해 허용 수준 요구 사항을 충족하기 위해 필요에 따라 복제본 지리적 위치 및 복제본 수와 같은 전략을 구성할 수 있습니다.
실시간 HTAP
행 스토리지 엔진 TiKV와 열 스토리지 엔진 TiFlash의 두 가지 스토리지 엔진을 제공하는 TiFlash는 Multi-Raft Learner 프로토콜을 통해 실시간으로 TiKV의 데이터를 복사하여 행 스토리지를 보장합니다. 엔진 TiKV 및 컬럼 스토리지 엔진 TiFlash 데이터는 강력하게 일치합니다. TiKV와 TiFlash는 필요에 따라 서로 다른 시스템에 배포되어 HTAP 리소스 격리 문제를 해결할 수 있습니다.
클라우드 기반 분산 데이터베이스
클라우드용으로 특별히 설계된 분산 데이터베이스입니다. TiDB Operator를 통해 퍼블릭 클라우드, 프라이빗 클라우드, 하이브리드 클라우드에서 배포 도구 및 자동화를 구현할 수 있습니다.
MySQL 5.7 프로토콜 및 MySQL 생태계와 호환됩니다.
MySQL 5.7 프로토콜, MySQL 공통 기능 및 MySQL 생태계와 호환됩니다. 애플리케이션은 소량의 코드를 수정하거나 수정하지 않고도 MySQL에서 TiDB로 마이그레이션할 수 있습니다. 애플리케이션이 데이터 마이그레이션을 쉽게 완료할 수 있도록 다양한 데이터 마이그레이션 도구를 제공합니다.
높은 데이터 일관성과 높은 신뢰성, 높은 시스템 가용성, 확장성 및 재해 복구가 필요한 높은 금융 산업 속성을 갖춘 시나리오
우리 모두 알고 있듯이 , 금융 산업은 데이터 일관성과 높은 신뢰성, 높은 시스템 가용성, 확장성 및 재해 복구에 대한 높은 요구 사항을 가지고 있습니다. 기존 솔루션은 동일한 도시에 있는 두 개의 컴퓨터실에서 서비스를 제공하고 데이터 재해 복구 기능을 제공하지만 다른 곳에 있는 한 컴퓨터실에서는 서비스를 제공하지 않는 것입니다. 이 솔루션에는 낮은 리소스 활용도, 높은 유지 관리 비용, 등의 단점이 있습니다. RTO(복구 시간 목표) 및 RPO(복구 지점 목표)는 기업이 기대하는 가치를 실제로 달성할 수 없습니다. TiDB는 다중 복사 + 다중 래프트(Multi-Raft) 프로토콜을 사용하여 데이터를 다른 컴퓨터실, 랙 및 기계에 예약합니다. 일부 기계에 장애가 발생하면 시스템은 자동으로 전환하여 시스템의 RTO
높은 저장 용량, 확장성 및 동시성을 요구하는 대용량 데이터 및 높은 동시성 OLTP 시나리오
비즈니스의 급속한 발전과 함께 데이터가 폭발적으로 증가했으며 기존의 독립형 데이터베이스는 이러한 요구 사항을 충족할 수 없습니다. 요구 사항 데이터베이스 용량이 필요한 데이터의 폭발적인 증가로 인해 가능한 솔루션은 하위 데이터베이스 및 하위 테이블이 포함된 미들웨어 제품을 사용하거나 대신 NewSQL 데이터베이스를 사용하거나 고급 스토리지 장치를 사용하는 것입니다. 비용 효율적인 것은 TiDB와 같은 NewSQL 데이터베이스입니다. TiDB는 컴퓨팅과 스토리지를 각각 확장 및 축소할 수 있는 컴퓨팅 및 스토리지 분리 아키텍처를 채택합니다. 컴퓨팅은 최대 512개의 노드를 지원하고, 각 노드는 최대 1000개의 동시성을 지원하며, 클러스터 용량은 최대 PB 수준을 지원합니다.
실시간 HTAP 시나리오
5G, 사물 인터넷, 인공 지능의 급속한 발전으로 기업은 점점 더 많은 데이터를 생산하게 되며 그 규모는 수백 TB 또는 심지어 PB 수준에 도달할 수 있습니다. 전통적인 솔루션은 OLTP 데이터베이스를 통해 온라인 온라인 트랜잭션을 처리하고, ETL 도구를 통해 데이터 분석을 위해 데이터를 OLAP 데이터베이스에 동기화하는 것입니다. TiDB는 버전 4.0에서 컬럼 스토리지 엔진 TiFlash를 도입하고 이를 행 스토리지 엔진 TiKV와 결합하여 스토리지 비용을 조금 증가시키면서 온라인 트랜잭션 처리와 실시간 데이터 분석을 동일한 시스템에서 수행할 수 있습니다. , 기업의 비용을 크게 절감합니다.
데이터 집계 및 2차 처리 시나리오
현재 대부분의 기업의 비즈니스 데이터는 통일된 요약 없이 여러 시스템에 분산되어 있습니다. 비즈니스가 발전함에 따라 기업의 의사 결정 수준에서는 적시에 의사 결정을 내리기 위해 회사 전체의 비즈니스 상태를 이해해야 합니다. 데이터의 분산이 필요합니다. 다양한 시스템의 데이터를 동일한 시스템에 모아 두 번 처리하여 T+0 또는 T+1 보고서를 생성합니다. 전통적인 공통 솔루션은 ETL + Hadoop을 사용하는 것이지만 Hadoop 시스템은 너무 복잡하고 운영 및 유지 관리 및 저장 비용이 너무 높아 사용자의 요구를 충족할 수 없습니다. Hadoop에 비해 TiDB는 훨씬 간단합니다. 비즈니스는 ETL 도구를 통해 데이터를 TiDB에 동기화하거나 TiDB 동기화 도구를 통해 SQL을 통해 TiDB에서 직접 생성할 수 있습니다.
TiDB는 분산 시스템입니다. 가장 기본적인 TiDB 테스트 클러스터는 일반적으로 TiDB 인스턴스 2개, TiKV 인스턴스 3개, PD 인스턴스 3개 및 TiFlash 인스턴스 옵션으로 구성됩니다. TiUP Playground를 통해 위의 기본 테스트 클러스터를 빠르게 구축할 수 있습니다. 단계는 다음과 같습니다. TiUP Playground，可以快速搭建出上述的一套基础测试集群，步骤如下：
step1、下载并安装 TiUP。
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
安装完成后显示：
Successfully set mirror to https://tiup-mirrors.pingcap.com Detected shell: bash Shell profile: /home/user/.bashrc /home/user/.bashrc has been modified to add tiup to PATH open a new terminal or source /home/user/.bashrc to use it Installed path: /home/user/.tiup/bin/tiup =============================================== Have a try: tiup playground ===============================================
step2、声明全局环境变量。 source ${your_shell_profile}
source /home/user/.bashrc
tiup playground
2단계. 전역 환경 변수를 선언합니다. source ${your_shell_profile}
#新开启一个 session 以访问 TiDB 数据库。 #使用 TiUP client 连接 TiDB： tiup client #也可使用 MySQL 客户端连接 TiDB mysql --host 127.0.0.1 --port 4000 -u root #通过 http://127.0.0.1:9090 访问 TiDB 的 Prometheus 管理界面。 #通过 http://127.0.0.1:2379/dashboard 访问 TiDB Dashboard 页面，默认用户名为 root，密码为空。 #通过 http://127.0.0.1:3000 访问 TiDB 的 Grafana 界面，默认用户名和密码都为 admin。
#简单来说，没有 MVCC 之前，可以把 TiKV 看做这样的 Key1 -> Value Key2 -> Value …… KeyN -> Value #有了 MVCC 之后，TiKV 的 Key 排列是这样的： Key1-Version3 -> Value Key1-Version2 -> Value Key1-Version1 -> Value …… Key2-Version4 -> Value Key2-Version3 -> Value Key2-Version2 -> Value Key2-Version1 -> Value …… KeyN-Version2 -> Value KeyN-Version1 -> Value ……
rrreee
TiDB 분산 데이터베이스는 핵심 설계 측면에서 전체 아키텍처를 여러 모듈로 분할하고 각 모듈은 통신합니다. 완전한 TiDB 시스템을 형성하기 위해 서로. 해당 아키텍처 다이어그램은 다음과 같습니다.
1. TiDB 데이터베이스 저장 - TiKV 서버
TiDB 저장 모델, 트랜잭션이 포함된 분산 KV 엔진【
전 세계적으로 정렬된 분산 키-값 엔진
TiKV
데이터를 저장하려면 다음 사항을 확인해야 합니다. 데이터가 손실되지 않고 데이터가 양호함 → Raft 프로토콜. 또한 다음 문제를 고려해야 합니다.
1. 데이터 센터 간 재해 복구를 지원할 수 있습니까? 🎜 2. 쓰기 속도는 충분히 빠른가요? 🎜 3. 데이터를 저장한 후 읽기 쉽나요? 🎜 4. 저장된 데이터를 수정하는 방법은 무엇인가요? 동시 수정을 지원하는 방법은 무엇입니까? 🎜 5. 여러 레코드를 원자적으로 수정하는 방법은 무엇입니까? 🎜🎜TiKV 프로젝트는 위의 문제를 매우 잘 해결합니다. 그렇다면 🎜TiKV처럼 고성능과 높은 신뢰성을 갖춘 거대한 (분산) 맵을 구현하는 방법은 무엇일까요? 🎜🎜TiKV는 데이터 복제를 위해 Raft를 사용합니다. 각 데이터 변경 사항은 Raft의 로그 복제 기능을 통해 그룹의 대부분의 노드에 안전하고 안정적으로 동기화될 수 있습니다. .
TiKV는 데이터를 디스크에 직접 쓰는 것을 선택하지 않고 RocksDB에 데이터를 저장합니다. 특정 데이터 구현을 담당합니다. [RocksDB는 매우 우수한 오픈 소스 독립형 스토리지 엔진입니다. 】
Raft 합의 알고리즘을 사용하여 데이터는 TiKV 노드 간에 여러 복사본으로 복사되어 노드에 장애가 발생할 경우 데이터의 보안을 보장합니다.
실제로 내부적으로 TiKV는 복제 로그 + 상태 머신(State Machine) 모델을 사용하여 데이터를 복제합니다. 쓰기 요청의 경우 데이터가 리더에 기록되고 리더는 명령을 로그 형식으로 팔로어에 복사합니다. 클러스터에 있는 대부분의 노드가 이 로그를 수신하면 로그가 커밋되고 그에 따라 상태 머신이 변경됩니다.
KV 시스템의 경우 여러 시스템에 데이터를 배포하기 위한 두 가지 일반적인 솔루션이 있습니다. 하나는 키에 따라 해시하고 해시 값에 따라 해당 스토리지 노드를 선택하는 것입니다. 첫 번째는 Range를 분할하는 방식으로, 일정 기간 동안 연속된 Key가 저장 노드에 저장됩니다. 범위 쿼리를 지원하기 위해 TiKV는 전체 키-값 공간을 여러 세그먼트로 나누는 두 번째 방법을 선택했습니다. 각 세그먼트는 일련의 연속된 키입니다. 각 세그먼트를 Region이라고 합니다. 각 지역에 저장된 데이터를 특정 크기(이 크기는 구성 가능하며 현재 기본값은 96Mb) 이하로 유지하도록 최선을 다하십시오. 각 지역은 StartKey에서 EndKey까지 왼쪽이 닫히고 오른쪽이 열리는 간격으로 설명할 수 있습니다.
데이터를 Region으로 나눈 후 중요한 두 가지를 수행합니다.
클러스터의 모든 노드에 대한 데이터를 Region 단위로 배포하고 각 노드가 Region의 수를 확보하도록 노력합니다. 서비스는 거의 같습니다.
데이터는 키에 따라 여러 지역으로 나뉘며, 각 지역의 데이터는 하나의 노드에만 저장됩니다. 우리 시스템에는 클러스터의 모든 노드에 가능한 한 균등하게 지역을 배포하는 구성 요소[PD]가 있어 한편으로는 저장 용량의 수평적 확장을 달성합니다(새 노드를 추가한 후 다른 노드가 자동으로 추가됨). ) 노드 위의 리전이 예정되어 있음), 반면에 로드 밸런싱도 이루어집니다 (특정 노드의 데이터가 많고 다른 노드의 데이터가 적은 상황은 없을 것입니다). 동시에 상위 계층 클라이언트가 필요한 데이터에 액세스할 수 있도록 시스템의 구성요소[PD]도 노드의 지역 분포를 기록합니다. 즉, 모든 키를 통해 가능합니다. 키가 어느 지역에 있는지, 그리고 지역이 현재 어느 노드에 있는지 쿼리합니다.
TiKV는 지역 단위로 데이터를 복제합니다. 즉, 지역의 데이터는 여러 복사본을 저장하며 각 복사본을 복제본이라고 합니다. Replica는 Raft를 사용하여 데이터 일관성을 유지합니다(마지막으로 언급된 Raft). 한 지역의 여러 복제본은 Raft 그룹을 형성하기 위해 서로 다른 노드에 저장됩니다. 하나의 복제본은 이 그룹의 리더 역할을 하고 다른 복제본은 팔로어 역할을 합니다. 모든 읽기 및 쓰기는 리더를 통해 수행된 후 팔로어로 복사됩니다.
지역을 이해한 후에는 다음 그림을 이해할 수 있어야 합니다.
对于同一个 Key 的多个版本，把版本号较大的放在前面，版本号小的放在后面。这样当用户通过一个 Key + Version 来获取 Value 的时候，可以将 Key 和 Version 构造出 MVCC 的 Key，也就是 Key-Version。然后可以直接 Seek(Key-Version)，定位到第一个大于等于这个 Key-Version 的位置。
#简单来说，没有 MVCC 之前，可以把 TiKV 看做这样的 Key1 -> Value Key2 -> Value …… KeyN -> Value #有了 MVCC 之后，TiKV 的 Key 排列是这样的： Key1-Version3 -> Value Key1-Version2 -> Value Key1-Version1 -> Value …… Key2-Version4 -> Value Key2-Version3 -> Value Key2-Version2 -> Value Key2-Version1 -> Value …… KeyN-Version2 -> Value KeyN-Version1 -> Value ……
TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。Garbage Collection (GC) 的任务便是清理不再需要的旧数据。
一个 TiDB 集群中会有一个 TiDB 实例被选举为 GC leader，GC 的运行由 GC leader 来控制。
GC 会被定期触发。每次 GC 时，首先，TiDB 会计算一个称为 safe point 的时间戳，接下来 TiDB 会在保证 safe point 之后的快照全部拥有正确数据的前提下，删除更早的过期数据。每一轮 GC 分为以下三个步骤：
step1：“Resolve Locks” 【清理锁】阶段会对所有 Region 扫描 safe point 之前的锁，并清理这些锁。
step2：“Delete Ranges” 【删除区间】阶段快速地删除由于 DROP TABLE/DROP INDEX 等操作产生的整区间的废弃数据。
step3：“Do GC”【进行GC清理】阶段每个 TiKV 节点将会各自扫描该节点上的数据，并对每一个 key 删除其不再需要的旧版本。
默认配置下，GC 每 10 分钟触发一次，每次 GC 会保留最近 10 分钟内的数据（即默认 GC life time 为 10 分钟，safe point 的计算方式为当前时间减去 GC life time）。如果一轮 GC 运行时间太久，那么在一轮 GC 完成之前，即使到了下一次触发 GC 的时间也不会开始下一轮 GC。另外，为了使持续时间较长的事务能在超过 GC life time 之后仍然可以正常运行，safe point 不会超过正在执行中的事务的开始时间 (start_ts)。
从 SQL 的角度了解了数据是如何存储，以及如何用于计算。
TiDB 在 TiKV 提供的分布式存储能力基础上，构建了兼具优异的交易处理能力与良好的数据分析能力的计算引擎。
TiDB Server：SQL 解析层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
可以将关系模型简单理解为 Table 和 SQL 语句，那么问题变为如何在 KV 结构上保存 Table 以及如何在 KV 结构上运行 SQL 语句。 SQL 和 KV 结构之间存在巨大的区别，那么如何能够方便高效地进行映射，就成为一个很重要的问题。一个好的映射方案必须有利于对数据操作的需求。
首先我们需要将计算尽量靠近存储节点，以避免大量的 RPC 调用。其次，我们需要将 Filter 也下推到存储节点进行计算，这样只需要返回有效的行，避免无意义的网络传输。最后，我们可以将聚合函数、GroupBy 也下推【计算下推】到存储节点，进行预聚合，每个节点只需要返回一个 Count 值即可，再由 tidb-server 将 Count 值 Sum 起来【并行算子】。 这里有一个数据逐层返回的示意图：
实际上 TiDB 的 SQL 层要复杂的多，模块以及层次非常多，下面这个图【SQL引擎架构】列出了重要的模块以及调用关系：
SQL 쿼리 반환의 간략한 프로세스: 사용자의 SQL 요청은 직접 tidb-server로 전송되거나 Load Balancer를 통해 tidb-server가 MySQL 프로토콜 패킷을 구문 분석하고 요청 내용을 얻은 다음 구문 분석, 쿼리 계획을 수행합니다. 공식화 및 최적화, 쿼리 계획을 실행하여 데이터를 획득하고 처리합니다. 모든 데이터는 TiKV 클러스터에 저장되므로 이 프로세스에서 tidb-server는 tikv-server와 상호 작용하여 데이터를 얻어야 합니다. 마지막으로 tidb-server는 쿼리 결과를 사용자에게 반환해야 합니다.
TiDB에서 입력된 쿼리 텍스트부터 최종 실행 계획 실행 결과까지의 과정은 아래 그림과 같습니다.
먼저 파서는 원본 쿼리 텍스트를 파싱하고 일부 단순 합법성 확인 후 TiDB는 먼저 쿼리에 논리적으로 동일한 일부 변경(쿼리 논리 최적화)을 수행합니다.
이러한 동등한 변경을 통해 이 쿼리는 논리적 실행 계획에서 더 쉽게 처리할 수 있습니다. 동등한 변경이 완료된 후 TiDB는 원래 쿼리와 동등한 쿼리 계획 구조를 얻은 다음 데이터 분포 및 연산자의 특정 실행 비용을 기반으로 최종 실행 계획을 얻습니다. - 쿼리 물리적 최적화.
동시에 TiDB가 PREPARE 문을 실행할 때 캐싱을 활성화하여 TiDB 생성 실행 계획 비용(실행 계획 캐싱)을 줄일 수 있습니다.
PD(배치 드라이버)는 TiDB 클러스터의 관리 모듈이며 클러스터 데이터의 실시간 스케줄링도 담당합니다.
PD(배치 드라이버) 서버: 전체 TiDB 클러스터의 메타 정보 관리 모듈로, 각 TiKV 노드의 실시간 데이터 분포와 전체 토폴로지를 저장하는 역할을 담당합니다. TiDB 대시보드 관리 및 제어 인터페이스를 제공하고 분산 트랜잭션에 트랜잭션 ID를 할당합니다. PD는 메타정보를 저장할 뿐만 아니라, TiKV 노드가 실시간으로 보고하는 데이터 분포 상태를 바탕으로 특정 TiKV 노드에 데이터 스케줄링 명령을 내리는 역할을 하며 전체 클러스터의 '브레인'이라고 할 수 있다. 또한 PD 자체도 고가용성을 제공하기 위해 최소 3개 이상의 노드로 구성된다. 홀수의 PD 노드를 배포하는 것이 좋습니다.
첫 번째 범주: 분산형 고가용성 스토리지 시스템으로서 충족해야 하는 요구 사항에는 여러 가지 유형이 포함됩니다.: [재해 복구 기능]
범주 2: 좋은 분산 시스템으로서 고려해야 할 사항은 다음과 같습니다. : [더 높고 합리적인 리소스 활용도, 우수한 확장성]
이러한 요구를 충족하려면 각 노드의 상태, 각 Raft 그룹의 정보, 비즈니스 액세스 작업 통계 등 충분한 정보를 수집해야 하며, 두 번째로 일부 정책을 설정해야 합니다. 이 정보와 일정 정책을 바탕으로 앞서 언급한 요구 사항을 최대한 충족하는 일정 계획을 개발합니다.
스케줄링의 기본 작업은 스케줄링을 충족시키기 위한 전략을 의미합니다. 위의 일정 요구 사항은 다음 세 가지 작업으로 구성될 수 있습니다.
Raft 프로토콜이 통과하는 경우가 발생합니다. AddReplica、RemoveReplica、TransferLeader 이 세 가지 A 명령은 위의 세 가지 기본 작업을 지원할 수 있습니다.
TiKV Store의 상태는 구체적으로 Up, Disconnect, Offline, Down 및 Tombstone으로 구분됩니다. 각 상태 간의 관계는 다음과 같습니다.
PD는 Store[즉, TiKV 노드] 또는 Leader의 하트비트 패킷을 통해 지속적으로 정보를 수집하여 전체 클러스터의 세부 데이터를 얻고, 이 정보와 스케줄링을 기반으로 스케줄링 작업 시퀀스를 생성합니다. PD는 매번 Region Leader로부터 Heartbeat 패킷을 수신하면 해당 Region에 수행할 작업이 있는지 확인하고, Heartbeat 패킷의 응답 메시지를 통해 필요한 작업을 Region Leader에게 반환하고 모니터링합니다. 후속 하트비트 패킷에서 실행됩니다. 여기서의 작업은 지역 리더를 위한 제안일 뿐이며 실행 여부와 시기는 현재 상태에 따라 지역 리더가 직접 결정합니다.
TiDB의 모범 사례는 구현 원칙과 밀접하게 관련되어 있습니다. 먼저 Raft, 분산 트랜잭션, 데이터 샤딩, 로드 밸런싱, SQL에서 KV로의 기본 구현 메커니즘을 이해하는 것이 좋습니다. 매핑 방식, 보조 인덱스 구현 방법, 분산 실행 엔진.
Raft는 강력한 일관성 데이터 복제 보장을 제공할 수 있는 일관성 프로토콜입니다. TiDB의 하위 계층은 Raft를 사용하여 데이터를 동기화합니다. 각 쓰기는 외부에서 성공이 반환되기 전에 대부분의 복사본에 써야 합니다. 이렇게 하면 몇 개의 복사본이 손실되더라도 시스템에서 최신 데이터를 계속 사용할 수 있습니다. 예를 들어 최대 3개의 복사본이 있는 경우 2개의 복사본에 대한 각 쓰기는 성공한 것으로 간주됩니다. 언제든지 하나의 복사본만 손실되면 두 개의 복사본 중 적어도 하나에 최신 데이터가 있게 됩니다.
3개의 복사본도 저장하는 Master-Slave 동기화 방식에 비해 Raft 방식은 가장 느린 복사본이 아닌 가장 빠른 두 개의 복사본에 따라 쓰기 지연이 달라지기 때문에 더 효율적입니다. 따라서 Raft 동기화를 사용하면 여러 위치에 거주하는 것이 가능합니다. 두 곳에 세 개의 센터가 있는 일반적인 시나리오에서 각 쓰기에는 데이터 일관성을 보장하기 위해 로컬 데이터 센터와 인근 데이터 센터에서만 성공적인 쓰기가 필요하며, 세 개의 데이터 센터 모두에서 성공적인 쓰기가 필요하지는 않습니다.
TiDB는 완전한 분산 트랜잭션을 제공합니다. 트랜잭션 모델은 Google Percolator를 기반으로 최적화되어 있습니다.
Optimistic Lock
TiDB의 낙관적 트랜잭션 모델은 실제로 제출될 때만 충돌 감지를 수행합니다. 충돌이 발생하면 다시 시도해야 합니다. 이 모델은 재시도 전 작업이 유효하지 않고 반복되어야 하기 때문에 심각한 충돌이 있는 시나리오에서는 상대적으로 비효율적입니다. 좀 더 극단적인 예를 들자면 데이터베이스를 카운터로 사용하는 경우 액세스 동시성이 상대적으로 높을 경우 심각한 충돌이 발생하여 재시도 횟수가 많아지거나 시간 초과가 발생할 수도 있습니다. 그러나 액세스 충돌이 그다지 심각하지 않은 경우에는 낙관적 잠금 모델이 더 효율적입니다. 심각한 충돌이 있는 시나리오에서는 비관적 잠금을 사용하거나 Redis에 카운터를 배치하는 등 시스템 아키텍처 수준에서 문제를 해결하는 것이 좋습니다.
비관적 잠금
TiDB의 비관적 트랜잭션 모드는 기본적으로 MySQL과 동일합니다. 충돌 상황에서 재시도를 피하기 위해 선착순으로 실행 단계에서 잠깁니다. 더 많은 충돌 성공률을 보장합니다. 비관적 잠금은 업데이트 선택을 통해 미리 데이터를 잠그려는 시나리오도 해결합니다. 그러나 비즈니스 시나리오 자체에 충돌이 적다면 낙관적 잠금 성능이 더 유리할 것입니다. select for update 对数据提前锁定的场景。但如果业务场景本身冲突较少，乐观锁的性能会更有优势。
事务大小限制
由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制【单个事务包含的 SQL 语句不超过 5000 条（默认）】。
TiKV 自动将底层数据按照 Key 的 Range 进行分片。每个 Region 是一个 Key 的范围，从 StartKey 到 EndKey
StartKey에서 EndKey까지 왼쪽으로 닫히고 오른쪽으로 열리는 키 범위입니다. 한 Region 내 Key-Value의 총 개수가 일정 값을 초과하면 자동으로 분할됩니다. 이 부분은 사용자에게 투명합니다. TableID로 구성되며 행 ID는 접미사입니다. TableID 构造前缀，以行 ID 为后缀TableID+IndexID
TableID+IndexID 접두사, 인덱스 값으로 접미사 쿼리 동시성.
데이터는 여러 지역에 분산되어 있으므로 TiDB는 동시에 쿼리를 수행합니다. 동시성이 너무 높으면 시스템 리소스가 많이 소모되기 때문에 기본 동시성은 상대적으로 보수적입니다.
많은 양의 데이터를 포함하지 않는 OLTP 유형 쿼리의 경우 낮은 동시성으로 이미 요구 사항을 충족할 수 있습니다.
더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 비디오
를 방문하세요! ! 🎜위 내용은 tidb가 go 언어인가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
