더 이상 데이터베이스와 테이블을 나누지 말고 TiDB를 사용해 보세요!

• NewSQL이란?

• 기존 SQL의 문제

  • 서버 하드웨어 업그레이드

  • 데이터 샤딩

• NoSQL의 문제점

  • 이점

  • 결점

• NewSQL 기능

• NewSQL의 주요 기능

• 세 종류의 SQL 비교

• TiDB는 어떻게 생겼습니까?

• TiDB 커뮤니티 에디션 및 엔터프라이즈 에디션

• TIDB 핵심 기능

  • 수평 탄성 확장

  • 분산 트랜잭션 지원

  • 재무 등급 고가용성

  • 실시간 HTAP

  • 클라우드 네이티브 분산 데이터베이스

  • MySQL과의 높은 호환성

• OLTP&OLAP(자율 학습)

  • OLTP(온라인 거래 처리)

  • OLAP(온라인 분석 처리)

  • 기능 비교

  • 디자인 각도 차이

• TiDB 전체 아키텍처

• TiDB의 장점

• TiDB의 구성요소

  • TiDB 서버

  • PD(배치 동인) 서버

  • TiKV 서버

  • 티스파크

  • TiFlash

• TiKV의 전체 구조

  • 지역 분할 및 병합

  • 지역 일정

  • 분산 트랜잭션

• 고가용성 아키텍처

  • TiDB 고가용성

  • PD 고가용성

  • TiKV 고가용성

• 애플리케이션 시나리오

  • MySQL 조각화 및 병합

  • MySQL 직접 교체

  • 데이터 베이스

  • 다른 시스템의 모듈로

• 애플리케이션

• TiDB와 MySQL의 호환성 비교

• TiDB에서 지원하지 않는 MySql 기능

• 자동 증분 ID

• SELECT의 한계

• 보다

• 기본 설정의 차이점

  • 문자 집합

  • 대조

  • 대소문자 구분

  • 매개변수 설명

  • 타임스탬프 유형 필드 업데이트

  • 매개변수 설명

  • 외래 키 지원

---

TiDB는 분산 NewSQL 데이터베이스입니다. 수평 탄력적 확장, ACID 트랜잭션, 표준 SQL, MySQL 구문 및 MySQL 프로토콜을 지원하고 강력한 데이터 일관성을 가진 고가용성 기능을 가지고 있으며 OLTP 시나리오뿐만 아니라 OLAP 시나리오에도 적합한 하이브리드 데이터베이스입니다.

TiDB는 PingCAP에서 독자적으로 설계하고 개발한 오픈소스 분산관계형 데이터베이스로 온라인 거래 처리와 온라인 분석 처리(HTAP)를 모두 지원하는 통합 분산 데이터베이스 제품이다. 레벨 고가용성, 실시간 HTAP, 클라우드 네이티브 분산 데이터베이스, MySQL 5.7 프로토콜과의 호환성 및 MySQL 생태계. 목표는 사용자에게 원스톱 OLTP(Online Transactional Processing), OLAP(Online Analytical Processing) 및 HTAP 솔루션을 제공하는 것입니다. TiDB는 고가용성, 강력한 일관성에 대한 높은 요구 사항, 대용량 데이터와 같은 다양한 애플리케이션 시나리오에 적합합니다.

NewSQL이란?

데이터베이스는 3세대 동안 개발되었습니다.

1. SQL, MySQL과 같은 전통적인 관계형 데이터베이스

2. MongoDB, Redis와 같은 noSQL

3. newSQL

기존 SQL의 문제

인터넷은 금세기 초에 급속히 발전하기 시작하여 인터넷 애플리케이션의 사용자 규모와 데이터 양이 증가하고 있으며 온라인은 7X24시간이 요구됩니다.

기존의 관계형 데이터베이스는 이 환경에서 병목 현상이 발생했으며 일반적으로 두 가지 솔루션이 있습니다.

서버 하드웨어 업그레이드

성능이 향상되었지만 항상 상한선이 있습니다.

데이터 샤딩

분산 클러스터 구조 사용

단일 포인트 데이터베이스에서 데이터를 단편화하여 값싼 장비로 구성된 분산 클러스터에 저장하면 확장성이 더 좋아지지만 새로운 문제도 발생합니다.

하나의 라이브러리에 있던 데이터는 이제 여러 라이브러리에 걸쳐 있으며, 응용 시스템은 자체적으로 여러 라이브러리에서 작동할 수 없으며 데이터베이스 샤딩 미들웨어를 사용해야 합니다.

Fragmentation 미들웨어는 단순한 데이터 작업에는 좋지만 교차 데이터베이스 조인 및 교차 데이터베이스 트랜잭션에 관해서는 많은 사람들이 단순히 비즈니스 계층에서 혼자 처리하므로 더 복잡합니다.

NoSQL의 문제점

이후 noSQL이 등장하여 기존 SQL의 강력한 트랜잭션 보장과 관계형 모델을 버리고 데이터베이스의 고가용성과 확장성에 중점을 두었습니다.

이점

• 고가용성 및 확장성, 자동 파티셔닝, 손쉬운 확장

• 강력한 일관성이 보장되지 않으며 성능이 크게 향상됩니다.

• 관계형 모델의 제약 없이 매우 유연함

결점

• Strong Consistency는 보장되지 않으며 일반 애플리케이션에서는 문제가 되지 않지만 여전히 Strong Consistency를 요구하는 금융과 같은 엔터프라이즈급 애플리케이션은 많습니다.

• SQL 문을 지원하지 않고 호환성이 큰 문제인데, NoSQL 데이터베이스마다 데이터를 운용하는 API가 달라서 더 복잡하다.

NewSQL 기능

NewSQL은 noSQL과 동일한 확장성을 제공하며 여전히 관계형 모델을 기반으로 하며 쿼리 언어로서 매우 성숙한 SQL을 유지하고 ACID 트랜잭션 특성을 보장합니다.

간단히 말해, NewSQL은 NoSQL의 강력한 확장성을 기존 관계형 데이터베이스에 통합합니다.

전통적인 SQL 아키텍처 설계 유전자에는 분산 아키텍처가 없지만 NewSQL은 클라우드 시대에 탄생했으며 본질적으로 분산 아키텍처입니다.

NewSQL의 주요 기능

• 복잡한 쿼리 및 빅 데이터 분석을 위한 SQL 지원.

• ACID 트랜잭션 지원, 격리 수준 지원.

• 탄력적인 확장, 용량 확장 및 축소는 비즈니스 계층에 완전히 투명합니다.

• 고가용성 및 자동 재해 복구.

세 종류의 SQL 비교

그림

TiDB는 어떻게 생겼습니까?

유명한 오픈 소스 분산 캐싱 서비스 Codis의 저자이자 수석 인프라 엔지니어인 PingCAP의 공동 창립자이자 CTO인 Huang Dongxu는 분산 스토리지 시스템의 설계 및 구현에 능숙하며 오픈 소스 광신자의 기술 마스터입니다. 오늘날 인터넷이 이렇게 번성할 때에도 데이터베이스의 모호하고 불확실한 영역에서 그는 여전히 결정론적인 실천 방향을 찾으려고 노력하고 있다. 공식 z 번호: code ape 기술 컬럼, 응답 키워드: 1111 Get Ali의 내부 Java 성능 최적화 매뉴얼에 주목하세요!

2012년 말까지 그는 구글이 내놓은 두 편의 논문이 프리즘처럼 자신의 마음 속 빛을 굴절시키는 것을 보았다. 이 두 논문은 Google에서 내부적으로 사용하는 대규모 관계형 데이터베이스인 F1/Spanner에 대해 설명합니다. 이 데이터베이스는 관계형 데이터베이스, 탄력적 확장 및 글로벌 배포의 문제를 해결하고 프로덕션에서 대규모로 사용됩니다. "이것이 실현될 수 있다면 데이터 스토리지 분야에 파괴적일 것입니다." Huang Dongxu는 완벽한 솔루션의 등장에 흥분했고 PingCAP의 TiDB는 이를 기반으로 탄생했습니다.

TiDB 커뮤니티 에디션 및 엔터프라이즈 에디션

TiDB는 커뮤니티 에디션과 엔터프라이즈 에디션으로 구분되며, 엔터프라이즈 에디션은 유료 서비스 및 보안 지원을 제공합니다.

그림

TIDB 핵심 기능

수평 탄성 확장

TiDB의 수평적 확장은 단순히 새로운 노드를 추가하는 것으로 실현될 수 있으며, 높은 동시성 및 대규모 데이터 시나리오에 쉽게 대처할 수 있도록 필요에 따라 처리량 또는 스토리지를 확장할 수 있습니다.

TiDB의 스토리지-컴퓨팅 분리형 아키텍처 설계 덕분에 필요에 따라 컴퓨팅과 스토리지를 온라인으로 확장 또는 축소할 수 있으며 확장 또는 축소 프로세스는 애플리케이션 운영 및 유지 관리 담당자에게 투명합니다.

분산 트랜잭션 지원

TiDB는 표준 ACID 트랜잭션을 100% 지원합니다.

재무 등급 고가용성

기존의 마스터-슬레이브(MS) 복제 체계와 비교하여 Raft 기반 다수결 프로토콜은 금융 수준의 100% 데이터 강력한 일관성 보장을 제공할 수 있으며 대부분의 사본을 잃지 않고 자동 장애 복구(자동 장애 조치)를 실현할 수 있습니다. 간섭

데이터는 여러 복사본으로 저장되며 데이터 복사본은 Multi-Raft 프로토콜을 통해 트랜잭션 로그와 동기화됩니다.대부분의 트랜잭션은 성공적인 쓰기 후에만 제출할 수 있으므로 강력한 데이터 일관성을 보장하고 데이터 가용성에 영향을 미치지 않습니다. 적은 수의 사본이 실패할 때. 지리적 위치 및 복제본 수와 같은 정책은 다양한 재해 복구 수준의 요구 사항을 충족하도록 필요에 따라 구성할 수 있습니다.

실시간 HTAP

전형적인 OLTP row-storage 데이터베이스인 TiDB 역시 강력한 OLAP 성능을 가지고 있으며, TiSpark와 함께 원스톱 HTAP 솔루션을 제공할 수 있습니다.

두 개의 스토리지 엔진 제공: 행 스토리지 엔진 TiKV 및 열 스토리지 엔진 TiFlash TiFlash는 Multi-Raft Learner 프로토콜을 통해 실시간으로 TiKV에서 데이터를 복사하여 행 스토리지 엔진 TiKV와 열 스토리지 엔진 TiFlash 간의 강력한 데이터 일관성을 보장합니다. HTAP 리소스 격리 문제를 해결하기 위해 필요에 따라 TiKV 및 TiFlash를 다른 시스템에 배포할 수 있습니다.

클라우드 네이티브 분산 데이터베이스

TiDB는 클라우드용으로 설계된 데이터베이스로 쿠버네티스와 긴밀하게 결합되어 있으며 퍼블릭 클라우드, 프라이빗 클라우드, 하이브리드 클라우드를 지원하여 배포, 구성 및 유지 관리가 매우 간단합니다. TiDB의 설계 목표는 100% OLTP 시나리오와 80% OLAP 시나리오이며 TiSpark 프로젝트를 통해 보다 복잡한 OLAP 분석을 수행할 수 있습니다. TiDB는 비즈니스에 방해가 되지 않으며 기존 데이터베이스 미들웨어, 데이터베이스 하위 데이터베이스 및 하위 테이블 및 기타 샤딩 솔루션을 정상적으로 대체할 수 있습니다. 동시에 개발 및 유지 관리 인력이 데이터베이스 규모의 세부 사항에 주의를 기울이지 않고 비즈니스 개발에 집중할 수 있도록 하여 연구 개발의 생산성을 크게 향상시킵니다.

MySQL과의 높은 호환성

MySQL 5.7 프로토콜, MySQL의 공통 기능 및 MySQL 에코시스템과 호환되는 애플리케이션은 약간의 코드 수정 없이 또는 약간 수정하여 MySQL에서 TiDB로 마이그레이션할 수 있습니다.

풍부한 데이터 마이그레이션 툴을 제공하여 애플리케이션이 편리하게 데이터 마이그레이션을 완료할 수 있도록 지원하며, 대부분의 경우 코드 수정 없이 MySQL에서 TiDB로 마이그레이션이 용이하며, 서브데이터베이스 및 테이블 분할 후 MySQL 클러스터도 실시간 마이그레이션 가능 TiDB 도구를 통해.

OLTP&OLAP(자율 학습)

OLTP(온라인 거래 처리)

OLTP(Online Transactional Processing) 온라인 거래 처리 OLTP는 전통적인 관계형 데이터베이스의 주요 응용 프로그램으로 주로 기본 및 일상 거래 처리에 사용되며 입출금 등의 기록 추가, 삭제, 수정 및 실시간 확인 은행의 금액 지불은 비즈니스 거래입니다.

온라인 트랜잭션 처리는 매우 트랜잭션적인 시스템입니다. 일반적으로 가용성이 높은 온라인 시스템입니다. 주로 작은 트랜잭션과 작은 쿼리에 중점을 둡니다. 시스템을 평가할 때 일반적으로 초당 실행되는 트랜잭션 및 SQL 실행 수에 따라 달라집니다. . 이러한 시스템에서 단일 데이터베이스는 종종 초당 수백 또는 수천 개의 트랜잭션을 처리하고 Select 문의 실행 볼륨은 초당 수천 또는 수만입니다. 대표적인 OLTP 시스템으로는 매우 대표적인 OLTP 데이터베이스인 미국 eBay의 비즈니스 데이터베이스와 같은 전자상거래 시스템, 은행, 증권 등이 있다.

OLAP(온라인 분석 처리)

OLAP(Online Analytical Processing)은 데이터 웨어하우스의 핵심으로 복잡한 분석 작업을 지원하고 의사 결정 지원에 중점을 두며 직관적이고 이해하기 쉬운 쿼리 결과를 제공합니다. 일반적인 애플리케이션은 복잡한 동적 보고 시스템입니다.

이러한 시스템에서는 문장의 실행 시간이 매우 길 수 있고 읽은 데이터도 매우 크기 때문에 문장의 실행 볼륨은 평가 기준이 아닙니다. 따라서 이러한 시스템에서 평가 기준은 종종 얼마나 많은 MB/s 트래픽을 달성할 수 있는지와 같은 디스크 하위 시스템의 처리량(대역폭)입니다.

기능 비교

OLTP와 OLAP의 특성 비교

—	OLTP	올랩
실시간	OLTP는 실시간 요구 사항이 높으며 OLTP 데이터베이스는 트랜잭션 응용 프로그램이 단일 트랜잭션을 최대한 빨리 처리하는 데 필요한 데이터만 쓸 수 있도록 설계되었습니다.	OLAP의 실시간 요구 사항은 그다지 높지 않으며 많은 응용 프로그램이 기껏해야 매일 데이터를 업데이트합니다.
데이터의 양	OLTP 데이터의 양은 그다지 크지 않으며 일반적으로 수십 개의 레코드를 읽고 쓰고 간단한 트랜잭션을 처리합니다.	OLAP은 동적 질의를 지원하기 때문에 데이터 양이 많기 때문에 사용자가 알고 싶은 정보를 얻기 위해 시계열 분석 등 많은 데이터를 수집해야 하므로 처리되는 데이터의 양이 많다.
사용자 및 시스템 방향	OLTP는 트랜잭션 및 쿼리 처리를 위한 고객 지향적입니다.	OLAP는 데이터 분석을 위한 시장 지향적입니다.
데이터베이스 설계	OLTP는 엔티티 관계 ER 모델 및 애플리케이션 지향 데이터베이스 설계를 채택합니다.	스타 또는 눈송이 스키마와 주제 중심 데이터베이스 디자인을 사용한 OLAP

디자인 각도 차이

—	OLTP	올랩
사용자	운영자, 하급 관리	의사 결정자, 고위 관리자
기능	일일 작업	분석 결정
주요 작업	추가, 삭제, 변경	문의
DB설계	애플리케이션 지향	주제 지향적
데이터	현재, 최신 세부 정보, 2차원, 이산	역사적, 집계된, 다차원적으로 통합된, 통합된
입장	수십 개의 레코드 읽기/쓰기	수백만 개의 레코드 읽기
고용주	단순한 일	복잡한 쿼리
사용자 번호	수천	수백
DB 크기	100MB-GB	100GB-TB

TiDB 전체 아키텍처

TiDB의 장점

기존의 독립형 데이터베이스와 비교하여 TiDB는 다음과 같은 이점이 있습니다.

• 확장성이 좋은 순수 분산 아키텍처로 유연한 확장 및 축소 지원

• SQL을 지원하고 MySQL의 네트워크 프로토콜을 외부 세계에 노출하며 대부분의 MySQL 구문과 호환되며 대부분의 시나리오에서 MySQL을 직접 대체할 수 있습니다.

• 고가용성은 기본적으로 지원되며, 적은 수의 복제본이 실패하는 경우 데이터베이스 자체가 자동으로 데이터 복구 및 페일오버를 수행할 수 있어 비즈니스에 투명합니다.

• ACID 트랜잭션을 지원하고 은행 송금과 같은 강력한 일관성 요구 사항이 있는 일부 시나리오에 적합합니다.

• 데이터 마이그레이션, 동기화, 백업 및 기타 시나리오를 다루는 풍부한 도구 체인 생태계를 보유합니다.

TiDB의 구성요소

TiDB의 수평 확장 및 고가용성 기능을 깊이 이해하려면 먼저 TiDB의 전체 아키텍처를 이해해야 합니다. TiDB 클러스터는 주로 TiDB 서버, PD 서버 및 TiKV 서버의 세 가지 핵심 구성 요소로 구성되며, 사용자의 복잡한 OLAP 요구 사항을 해결하기 위한 TiSpark 구성 요소도 있습니다. 공식 z 번호: code ape 기술 칼럼, 응답 키워드: 1111 Get Ali의 내부 Java 성능 최적화 매뉴얼에 주목하세요!

커널 설계 측면에서 TiDB 분산 데이터베이스는 전체 아키텍처를 여러 모듈로 분할하고 각 모듈은 서로 통신하여 완전한 TiDB 시스템을 형성합니다. 해당 아키텍처 다이어그램은 다음과 같습니다.

그림

건축학

TiDB 서버

TiDB Server는 SQL 요청을 받고, SQL 관련 로직을 처리하고, PD를 통해 계산에 필요한 데이터를 저장하기 위한 TiKV 주소를 찾고, TiKV와 상호 작용하여 데이터를 얻고, 최종적으로 결과를 반환하는 역할을 담당합니다. TiDB 서버는 상태 비저장이며, 데이터 자체를 저장하지 않고, 컴퓨팅만 담당하고, 무한정 수평으로 확장할 수 있으며, 로드 밸런싱 구성 요소(예: LVS, HAProxy 또는 F5)를 통해 외부에 통합 액세스 주소를 제공할 수 있습니다.

PD(배치 동인) 서버

배치 동인(PD라고 함)은 전체 클러스터의 관리 모듈이며 세 가지 주요 작업이 있습니다.

• 하나는 클러스터의 메타 정보(키가 저장된 TiKV 노드)를 저장하는 것입니다.

• 두 번째는 TiKV 클러스터(예: 데이터 마이그레이션, Raft 그룹 리더 마이그레이션 등)를 예약하고 로드 밸런싱하는 것입니다.

• 세 번째는 전역적으로 고유하고 점진적인 트랜잭션 ID를 할당하는 것입니다.

PD는 Raft 프로토콜을 통해 데이터 보안을 보장합니다. Raft의 리더 서버는 모든 작업을 처리하고 나머지 PD 서버는 고가용성을 보장하는 데만 사용됩니다. 홀수의 PD 노드를 배포하는 것이 좋습니다.

TiKV 서버

TiKV 서버는 데이터 저장을 담당하며 외부에서 TiKV는 트랜잭션을 제공하는 분산 키-값 스토리지 엔진입니다. 데이터를 저장하는 기본 단위는 Region이며, 각 Region은 Key Range(StartKey에서 EndKey까지의 좌측 폐쇄 우측 개방 간격)의 데이터 저장을 담당하고 각 TiKV 노드는 여러 Region을 담당합니다. TiKV는 복제에 Raft 프로토콜을 사용하여 데이터 일관성 및 재해 복구를 유지합니다. 레플리카는 리전 단위로 관리되며 서로 다른 노드의 여러 리전은 서로의 레플리카인 Raft 그룹을 형성합니다. 여러 TiKV 간의 데이터 로드 밸런싱은 PD에 의해 예약되며 이 역시 지역 단위로 예약됩니다.

티스파크

사용자의 복잡한 OLAP 요구 사항을 해결하기 위한 TiDB의 주요 구성 요소인 TiSpark는 TiDB 스토리지 계층에서 직접 Spark SQL을 실행하는 동시에 TiKV 분산 클러스터의 장점을 통합하고 빅 데이터 커뮤니티 생태계에 통합합니다. 지금까지 TiDB는 하나의 시스템을 통해 OLTP와 OLAP를 모두 지원할 수 있어 사용자 데이터 동기화의 번거로움을 없앴습니다.

TiFlash

TiFlash는 특별한 유형의 스토리지 노드입니다. 일반 TiKV 노드와 달리 TiFlash 내부에는 데이터가 열 형태로 저장되며 주요 기능은 분석 시나리오를 가속화하는 것입니다.

TiKV의 전체 구조

기존의 전체 노드 백업 방법과 달리 TiKV는 키 범위에 따라 데이터를 거의 동일한 슬라이스(이하 통칭하여 지역이라고 함)로 나눕니다.각 슬라이스에는 여러 복사본(보통 3개)이 있으며 그 중 하나는 리더이고, 읽기 및 쓰기 서비스를 제공합니다. TiKV는 PD를 통해 이러한 지역 및 복제본을 예약하여 데이터 및 읽기 및 쓰기 로드가 각 TiKV에 고르게 분산되도록 합니다. 이 설계는 전체 클러스터 리소스의 완전한 활용을 보장하고 시스템 수가 증가함에 따라 수평으로 확장할 수 있습니다.

그림

지역 분할 및 병합

지역의 크기가 특정 제한(기본적으로 144MB)을 초과하면 TiKV는 각 지역의 크기가 대략적으로 유사하도록 두 개 이상의 지역으로 분할하여 PD의 일정 결정에 더 도움이 됩니다. 마찬가지로 많은 수의 삭제 요청으로 인해 지역이 작아지면 TiKV는 인접한 두 개의 작은 지역을 하나로 병합합니다.

지역 일정

Raft 프로토콜을 통해 리전과 레플리카 간에 데이터 정합성을 유지하며 쓰기 요청은 리더에만 쓸 수 있고 대부분의 레플리카에 써야 한다(기본 구성은 레플리카 3개, 즉 모든 요청 두 개 이상의 복제본에 기록해야 함) 클라이언트 쓰기 성공을 반환합니다.

PD가 한 TiKV 노드에서 다른 노드로 영역 복사를 예약해야 하는 경우 PD는 먼저 대상 노드에서 이 Raft 그룹에 대한 학습자 복사본(리더 데이터 복사)을 추가합니다. Learner copy의 진행 상황이 Leader copy를 따라잡았을 때 Leader는 Follower로 변경한 후 Operation Node의 Follower copy를 제거하여 Region copy의 스케줄링을 완료합니다.

Leader copy의 스케쥴링 원리는 비슷하지만 대상 노드의 Learner copy가 Follower copy가 된 후 Leader Transfer가 다시 실행되어 Follower가 새로운 Leader가 되기 위한 선거를 시작하고 새로운 Leader가 이전 리더 사본 삭제를 담당합니다.

분산 트랜잭션

TiKV는 분산 트랜잭션을 지원합니다.사용자(또는 TiDB)는 이러한 키-값이 동일한 데이터 슬라이스(지역)에 있는지 여부를 신경쓰지 않고 한 번에 여러 키-값을 쓸 수 있습니다.TiKV는 두 가지를 통해 이러한 읽기 및 쓰기 요청을 보장합니다. 단계 커밋 ACID 제약.

고가용성 아키텍처

고가용성은 TiDB의 또 다른 주요 기능입니다.TiDB/TiKV/PD의 세 가지 구성 요소는 전체 클러스터의 가용성에 영향을 주지 않고 일부 인스턴스의 장애를 허용할 수 있습니다. 다음은 이러한 세 가지 구성 요소의 가용성, 단일 인스턴스 장애의 결과 및 복구 방법에 대해 설명합니다.

TiDB 고가용성

TiDB는 Stateless로 최소한 2개의 인스턴스를 배포하는 것을 권장하며 프런트 엔드는 로드 밸런싱 구성 요소를 통해 외부 서비스를 제공합니다. 단일 인스턴스가 실패하면 이 인스턴스에서 진행 중인 세션에 영향을 미치며, 응용 프로그램 관점에서 단일 요청 실패가 있으며 다시 연결한 후 서비스를 계속 얻을 수 있습니다. 단일 인스턴스가 실패하면 다시 시작하거나 새 인스턴스를 배포할 수 있습니다.

PD 고가용성

PD는 Raft 프로토콜을 통해 데이터 정합성을 유지하는 클러스터로 단일 인스턴스가 실패해도 Raft의 리더가 아니면 서비스에 전혀 영향을 미치지 않으며 인스턴스가 Raft의 리더이면 새로운 Raft 리더는 자동으로 서비스를 복원하기 위해 재선출됩니다. PD는 선거 과정에서 외부 서비스를 제공할 수 없으며, 이 시간은 약 3초입니다. 최소 3개의 PD 인스턴스를 배포하는 것이 좋으며 단일 인스턴스가 실패하면 인스턴스를 다시 시작하거나 새 인스턴스를 추가합니다.

TiKV 고가용성

TiKV는 Raft 프로토콜을 통해 데이터 일관성을 유지하고(사본 수는 구성 가능하며 기본적으로 3개 사본이 저장됨) 로드 밸런싱 스케줄링에 PD를 사용하는 클러스터입니다. 단일 노드에 장애가 발생하면 이 노드에 저장된 모든 지역에 영향을 미칩니다. 리전의 리더 노드의 경우 서비스가 중단되고 재선을 기다리며, 리전의 팔로워 노드의 경우 서비스에 영향을 미치지 않습니다. TiKV 노드가 실패하고 일정 기간(기본적으로 10분) 내에 복구할 수 없는 경우 PD는 해당 노드의 데이터를 다른 TiKV 노드로 마이그레이션합니다.

애플리케이션 시나리오

MySQL 조각화 및 병합

그림

TiDB가 적용되는 첫 번째 유형의 시나리오는 MySQL의 샤딩 및 병합입니다. 이미 MySQL을 사용하고 있는 기업의 경우 서브데이터베이스, 테이블, 샤드, 미들웨어 등이 공통적으로 사용되는 방식이며, 샤드가 증가함에 따라 교차 샤드 쿼리가 큰 문제가 되고 있습니다. TiDB는 비즈니스 계층에서 MySQL 액세스 프로토콜과 호환됩니다.PingCAP은 Huang Dongxu TiDB를 MySQL 슬레이브로 사용할 수 있고 TiDB를 기본 MySQL 라이브러리 뒤에 있는 기존 데이터베이스의 슬레이브 라이브러리로 연결할 수 있는 데이터 동기화 도구인 Syncer를 만들었습니다. . 이 계층은 데이터를 연결하고 복잡한 데이터베이스 간, 테이블 간 및 비즈니스 간 실시간 SQL 쿼리를 직접 수행할 수 있습니다. Huang Dongxu는 "과거에는 데이터베이스에 하나의 마스터와 여러 개의 슬레이브가 있었습니다. TiDB를 사용하면 여러 마스터와 하나의 슬레이브로 전환할 수 있습니다."라고 말했습니다.

MySQL 직접 교체

그림

두 번째 유형의 시나리오는 MySQL을 TiDB로 직접 교체하는 것입니다. 귀사의 IT 아키텍처가 구축 초기에 sub-database와 sub-table의 문제를 고려하지 않고 모두 MySQL을 사용한다면 비즈니스의 급속한 성장과 함께 점점 더 방대하고 높은 동시성 OLTP 시나리오가 있습니다. 아키텍처의 단점을 해결합니까?

TiDB 데이터베이스에서 모든 비즈니스 시나리오는 데이터베이스와 테이블로 나눌 필요가 없으며 모든 분산 작업은 데이터베이스 계층에서 수행됩니다. TiDB는 MySQL 프로토콜과 호환되므로 MySQL을 직접 대체할 수 있으며 기본적으로 기본적으로 작동합니다.기존의 데이터베이스 및 테이블 분할 방식에서 발생하는 과도한 작업 부하와 복잡한 유지 관리 비용에 대해 걱정할 필요가 없습니다. 사용자 인터페이스를 통해 일반 기술자가 유지 보수 및 관리를 효율적으로 수행할 수 있습니다. 또한 TiDB는 NoSQL과 유사한 용량을 가지고 있으며, 데이터 양과 접근 트래픽이 지속적으로 증가하고 응답 지연이 안정적일 때 수평적 확장을 통해 시스템의 비즈니스 지원 능력을 향상시킬 수 있다.

데이터 베이스

그림

TiDB 자체는 분산 시스템이며 세 번째 사용 시나리오는 TiDB를 데이터 웨어하우스로 사용하는 것입니다. TPC-H는 데이터 분석 분야의 테스트 세트입니다.OLAP 시나리오에서 TiDB 2.0의 성능이 크게 향상되었습니다.데이터 웨어하우스에서만 실행할 수 있는 일부 복잡한 쿼리를 TiDB 2.0에서 실행할 수 있으며 시간을 단축할 수 있습니다. 기본적으로 10초 이내로 제어됩니다. 물론 OLAP의 범위가 매우 크기 때문에 TiDB의 SQL도 불확실합니다.이러한 이유로 PingCAP은 TiSpark를 오픈 소스로 제공합니다.TiSpark는 Spark 플러그인입니다.사용자는 Spark SQL을 직접 사용하여 TiKV에서 빅 데이터 분석을 수행할 수 있습니다. 실시간.

다른 시스템의 모듈로

그림

TiDB는 스토리지와 컴퓨팅을 분리하는 전통적인 프로젝트로, 기본 키-값 레이어는 HBase 대체품으로 단독으로 사용할 수 있으며 교차 행 트랜잭션을 지원합니다. TiDB는 외부적으로 두 가지 API 인터페이스를 제공하는데, 하나는 교차 행 트랜잭션을 지원하는 데 사용되는 ACID Transaction API이고, 다른 하나는 전반적인 성능 향상을 위해 단일 행 트랜잭션을 수행할 수 있지만 교차용 ACID를 제공하지 않는 Raw API입니다. -행 트랜잭션 지원. 사용자는 필요에 따라 두 API 중에서 선택할 수 있습니다. 예를 들어 일부 사용자는 TiKV 위에 Redis 프로토콜을 직접 구현하여 TiKV를 대용량 및 낮은 대기 시간 요구 사항이 있는 일부 Redis 시나리오로 대체했습니다.

애플리케이션

그림

TiDB와 MySQL의 호환성 비교

• TiDB는 MySQL  전송 프로토콜과 대부분의 구문을 지원합니다. 이는 기존 MySQL 커넥터와 클라이언트가 계속 작동함을 의미합니다. 대부분의 경우 기존 애플리케이션을 코드 수정 없이 TiDB로 마이그레이션할 수 있습니다.

• 현재 공식적으로 지원되는 TiDB 서버 버전은 MySQL 5.7 입니다  . 대부분의 MySQL 운영 및 유지 관리 도구(예: PHPMyAdmin, Navicat, MySQL Workbench 등)와 백업 및 복구 도구(예: mysqldump, Mydumper/myloader)를 직접 사용할 수 있습니다.

• 그러나 일부 기능은 분산 환경에서 제대로 구현되지 않기 때문에 당분간 지원하지 않거나 성능이 MySQL과 다릅니다.

• 일부 MySQL 구문은 TiDB에서 구문 분석 및 전달될 수 있지만 후속 처리는 수행되지 않습니다  예를 들어 Create Table 문의 엔진은 구문 분석되고 무시됩니다.

TiDB에서 지원하지 않는 MySql 기능

• 저장 프로시저 및 함수

• 방아쇠

• 이벤트

• 맞춤 기능

• 외래 키 제약

• 임시 테이블

• 전체 텍스트/공간 함수 및 인덱스

• 비  ascii- latin1////  문자 집합 binary_ utf8_utf8mb4

• SYS 스키마

• MySQL 추적 최적화 프로그램

• XML 함수

• X 프로토콜

• 세이브포인트

• 열 수준 권한

• XA 구문(TiDB는 내부적으로 2단계 커밋을 사용하지만 SQL 인터페이스를 통해 노출되지 않음)

• CREATE TABLE tblName AS SELECT stmt 문법

• CHECK TABLE 문법

• CHECKSUM TABLE 문법

• GET_LOCK 및  RELEASE_LOCK 기능

자동 증분 ID

TiDB의 auto-increment 열은 고유함만 보장되며 단일 TiDB 서버에서도 자동 증가가 보장될 수 있지만 여러 TiDB 서버에서 자동 증가가 보장되지 않으며 자동 할당된 값은 보장되지 않으며, 기본값과 사용자 Duplicated Error 지정 .

TiDB는 시스템 변수를 통해  tidb_allow_remove_auto_inc 열 제거를 허용하는 속성을 활성화 또는 비활성화  할 수 있습니다 AUTO_INCREMENT . 열 속성을 제거하기 위한 구문은 다음과 같습니다. alter table modify 또는  alter table change.

AUTO_INCREMENT TiDB는 컬럼 추가 속성을 지원하지 않으며  이 속성을 제거한 후에는 복원할 수 없습니다.

SELECT의 한계

• SELECT ... INTO @变量 구문이 지원되지 않습니다  .

• SELECT ... GROUP BY ... WITH ROLLUP 구문이 지원되지 않습니다  .

• TiDB에서  SELECT .. GROUP BY expr 반환된 결과는 MySQL 5.7과 일치하지 않습니다. MySQL 5.7의 결과는  GROUP BY expr ORDER BY expr. 그러나 TiDB에서 이 구문에 의해 반환된 결과는 순서를 보장하지 않으며 이는 MySQL 8.0의 동작과 일치합니다.

보다

TiDB는 현재  뷰에서 UPDATE, INSERT 및 DELETE와 같은 쓰기 작업을 지원하지 않습니다  .

기본 설정의 차이점

문자 집합

• TiDB 기본값: utf8mb4.

• MySQL 5.7 기본값: latin1.

• MySQL 8.0 기본값: utf8mb4.

대조

• TiDB의  utf8mb4 기본 문자 집합 : utf8mb4_bin.

• MySQL 5.7의  utf8mb4 기본 문자 집합 : utf8mb4_general_ci.

• MySQL 8.0의  utf8mb4 기본 문자 집합 : utf8mb4_0900_ai_ci.

대소문자 구분

lower_case_table_names구성 정보

• TiDB 기본값: 2, 이 값 설정만 지원합니다  2.

• MySQL의 기본값은 다음과 같습니다.

• • Linux 시스템에서 값은 0

• Windows 시스템에서 이 값은 1

• macOS 시스템에서 값은 2

매개변수 설명

• lower_case_table_names=0 테이블 이름은 주어진 크기로 저장되며 비교는 대소문자를 구분합니다.

• lower_case_table_names = 1 테이블 이름은 디스크에 소문자로 저장되지만 비교할 때 대소문자를 구분하지 않습니다.

• lower_case_table_names=2 테이블 이름은 주어진 대소문자로 저장되지만 소문자로 비교됩니다.

타임스탬프 유형 필드 업데이트

기본적으로 타임스탬프 유형 필드가 있는 데이터 행이 업데이트되면 필드가 현재 시간으로 자동 업데이트되며 명시적_기본값_for_타임스탬프 매개변수가 이 동작을 제어합니다.

• TiDB 기본값: ON, 이 값 설정만 지원합니다  ON.

• MySQL 5.7 기본값: OFF.

• MySQL 8.0 기본값: ON.

매개변수 설명

• explicit_defaults_for_timestamp=off, 데이터 행이 업데이트되면 타임스탬프 유형 필드가 현재 시간으로 업데이트됩니다.

• explicit_defaults_for_timestamp=on, 데이터 행이 업데이트되면 타임스탬프 유형 필드가 현재 시간으로 업데이트되지 않습니다.

외래 키 지원

• TiDB 기본값: OFF, 이 값 설정만 지원합니다  OFF.

• MySQL 5.7 기본값: ON.