008. 아키텍처의 SQL 실행 프로세스

읽기 실행

• 메타데이터 읽기
  
  Executor는 항상 information_schema에서 테이블의 메타데이터 정보(테이블 메타)를 가져오며, 정보 스키마가 캐시되어 있기 때문에 메타데이터 정보를 메모리에서 읽을 수 있습니다.

• DistSQL
  
  DistSQL: 다중 테이블(t1 t2) 연관 쿼리와 같은 쿼리 문 외에도 단일 테이블 쿼리(select * from t1 where xx)(select * from t2 where xx)로 변환하여 처리하며, 간단한 SQL은 Send it to TiKV입니다. 이는 TikV와 복잡한 SQL을 분리하는 것과 같습니다.

• UnifyRead Pool
  TiKV는 이러한 SQL 문을 수신한 후 먼저 스냅샷 개체(특정 시점의 콘텐츠)를 구성합니다.
  이러한 간단한 SQL 문은 모두 UnifyRead Pool 스레드 풀에 들어갑니다. (이러한 SQL을 우선순위에 따라 실행)

• Rocksdb KV는 데이터를 읽은
  다음 Rocksdb kv 데이터를 계층적으로 읽습니다.
  참고: 이 영역은 다른 tikv에 있을 수 있으므로 병렬로 쿼리할 수 있습니다. 이것이 DistSQL이라고 하는 이유입니다.
  
  TiKV는 연산자를 푸시 다운하고 일부 작업을 TiKV로 푸시하는 기능이 있습니다. 실행에서 볼 수 있습니다. 그것이 경찰 임무라고 불리는 것을 계획하십시오.
  물론 여러 테이블과 관련된 데이터 요약 작업과 같은 일부 작업은 여전히 ​​TiDB 서버의 실행 계획에서 루트 작업으로 볼 수 있습니다.

쓰기 실행

우선 여전히 읽기 작업이 진행 중이며 처리된 데이터를 memBuffer(순서가 지정된 KV 레코드)로 읽어
작업 데이터를 찾고 제출을 시작한 후 2단계 제출에 진입하기 시작합니다.
간단한 이해:
1단계: 트랜잭션(데이터 수정 + 잠금)
2단계: 커밋(잠금 해제 레코드 추가 + 커밋)

DDL 실행

• TiDB 서버에서 발행한 ddl 문은 소유자가 누구든 실행하기 때문에 반드시 실행되는 것은 아닙니다.
• 인덱스를 추가하는 명령문은 인덱스 추가 대기열에 배치됩니다.

온라인 DDL은 DML을 차단하지 않고 실행 가능
TiDB 작업자(소유자)는 한 번에 한 명만 실행 가능
스키마 로드: 최신 객체를 로드하는 역할.

이 소유자는 TiDB 서버에서 폴링됩니다.

SQL 연산

SQL 구문 분석 및 컴파일

SQL 구문 분석 및 컴파일, AST 구문 트리
최적화에는 논리 최적화(예: 하위 테이블 쿼리를 조인 쿼리로 변환) 및 물리적 최적화(예: 행 수를 기준으로 인덱스 사용 여부 판단 등)가 포함되어 최적을 찾습니다. 실행 계획을 생성하는 연산자.

SQL 계층 아키텍처

• TiDB의 SQL 계층, 즉 TiDB 서버는 SQL을 키-값 작업으로 변환하고 이를 공유 분산 키-값 스토리지 계층 TiKV로 전달한 다음 TiKV에서 반환된 결과를 조합하고 마지막으로 쿼리 결과를 클라이언트에 반환하는 역할을 합니다. .
• 이 계층의 노드는 모두 상태 비저장이고 노드 자체는 데이터를 저장하지 않으며 노드는 완전히 피어 투 피어입니다.

SQL 작업

가장 간단한 솔루션은 이전 섹션에서 설명한 테이블 데이터와 키-값 간의 매핑 관계를 통해 SQL 쿼리를 KV 쿼리로 매핑한 다음 KV 인터페이스를 통해 해당 데이터를 얻고 최종적으로 다양한 계산을 수행하는 것입니다.

예를 들어 select count(*) from user where name = "TiDB", 이러한 SQL 문은 테이블의 모든 데이터를 읽은 다음 이름 필드가 TiDB인지 확인하고 그렇다면 이 행을 반환해야 합니다.

구체적인 프로세스는 다음과 같습니다.

• 키 범위 구성: 테이블의 모든 RowID는 [0, MaxInt64) 범위에 있으며, 행 데이터의 키 인코딩 규칙에 따라 0과 MaxInt64를 사용하여 왼쪽으로 닫힌 [StartKey, EndKey)를 구성할 수 있습니다. 권리.
• 스캔 키 범위: 위에서 구성한 키 범위에 따라 TiKV의 데이터를 읽습니다.
• 데이터 필터링: 읽은 데이터의 각 행에 대해 식 이름 = "TiDB"를 계산하고, 참이면 이 행을 위쪽으로 반환하고, 그렇지 않으면 이 데이터 행을 버립니다.
• Count( ) 계산: 요구 사항을 충족하는 각 라인에 대해 Count( ) 결과를 누적합니다.

전체 프로세스의 개략도는 다음과 같습니다.

이 솔루션은 직관적이고 실행 가능하지만 분산 데이터베이스 시나리오에는 몇 가지 명백한 문제가 있습니다.

• 데이터를 스캔할 때 KV 작업을 통해 각 행을 TiKV에서 읽어야 하며, 최소 하나의 RPC 오버헤드가 있습니다. 스캔할 데이터가 많으면 오버헤드가 매우 커집니다.
• 모든 행이 필터 조건 이름 = "TiDB"를 충족하는 것은 아니며 조건이 충족되지 않으면 읽을 필요가 없습니다. 이 쿼리는 해당 행의 값이 아니라 적합한 행의 수를 반환하는 데만 필요합니다.

분산 SQL 작업

위의 문제를 해결하려면 많은 수의 RPC 호출을 피하기 위해 컴퓨팅이 스토리지 노드에 최대한 가까워야 합니다. 먼저 SQL의 술어 조건 이름 = "TiDB"는 계산을 위해 스토리지 노드로 푸시다운되어야 하므로 의미 없는 네트워크 전송을 방지하기 위해 유효한 행만 반환하면 됩니다. 그런 다음 집계 함수 Count( )도 사전 집계를 위해 스토리지 노드로 푸시다운할 수 있습니다. 각 노드는 Count( ) 결과를 반환하기만 하면 SQL 계층에서 Count(*) 결과를 반환하고 누적됩니다. 합산.

다음은 계층별 데이터 반환 계층의 개략도입니다.

SQL 계층 아키텍처

위의 예제를 통해 SQL 문의 처리에 대한 기본적인 이해가 되셨기를 바랍니다. 실제로 TiDB의 SQL 계층은 훨씬 더 복잡하고 많은 모듈과 계층이 있습니다.다음 그림은 중요한 모듈과 호출 관계를 나열합니다.사용자 SQL 요청은

TiDB 서버에 직접 또는 Load Balancer를 통해 전송되며 TiDB 서버는 MySQL을 구문 분석합니다. 프로토콜 패킷, 요청 콘텐츠 획득, SQL에 대한 구문 분석 및 의미 분석 수행, 쿼리 계획 수립 및 최적화, 쿼리 계획 실행, 데이터 획득 및 처리. 모든 데이터는 TiKV 클러스터에 저장되므로 TiDB 서버는 이 프로세스 중에 데이터를 얻기 위해 TiKV와 상호 작용해야 합니다. 마지막으로 TiDB 서버는 쿼리 결과를 사용자에게 반환해야 합니다.