MySQL8.0 InnoDB 병렬 실행에 대한 자세한 설명

개요

MySQL은 수년간의 개발을 거쳐 가장 인기 있는 데이터베이스가 되었으며 인터넷 산업에서 널리 사용되며 점차 다양한 전통 산업에도 침투하고 있습니다. 인기가 높은 이유는 한편으로는 뛰어난 동시성 트랜잭션 처리 능력 때문이고, 다른 한편으로는 MySQL의 풍부한 생태계의 혜택도 누리고 있습니다. MySQL은 OLTP 시나리오에서 짧은 쿼리를 처리하는 데는 효과적이지만 복잡한 대규모 쿼리를 처리하는 능력은 제한되어 있습니다. 가장 직접적인 점은 SQL 문의 경우 MySQL은 이를 처리하기 위해 최대 하나의 CPU 코어만 사용할 수 있다는 것입니다. 이 시나리오에서는 호스트 CPU의 멀티 코어 기능을 사용할 수 없습니다. MySQL은 가만히 있지 않고 계속해서 발전해 나가고 있습니다. 새롭게 출시된 버전 8.0.14에서는 Check Table과 Select Count(*) 형태의 문의 성능을 두 배로 향상시킨 병렬 쿼리 기능을 최초로 도입했습니다. 현재 사용 시나리오는 여전히 상대적으로 제한되어 있지만 후속 개발은 기대할 가치가 있습니다.

권장: "mysql 비디오 튜토리얼"

사용 방법

innodb_parallel_read_threads 매개변수를 구성하여 병렬 검색 기능을 시작하여 동시 스레드 수를 설정합니다. 기본값은 4입니다. 여기서는 간단한 실험을 해보겠습니다. sysbench를 통해 2억 개의 데이터를 가져오고 각각 innodb_parallel_read_threads为1，2，4，8，16，32，64，测试并行执行的效果。测试语句为select count(*) from sbtest1;

을 구성하겠습니다. 가로 축은 구성된 동시 스레드 수이고 세로 축은 명령문 실행 시간입니다. 테스트 결과에 따르면, 전체 병렬 성능은 단일 스레드의 경우 18개에서 32개 스레드의 경우 1개로 감소한 2억 개의 레코드를 검색하는 데 여전히 좋습니다. 앞으로 아무리 동시성이 발전하더라도 제한된 데이터 양으로 인해 멀티 스레드의 관리 소비는 동시성이 가져온 성능 향상을 초과하며 SQL 실행 시간은 지속적으로 단축될 수 없습니다.

MySQL 병렬 실행

사실, 아래 그림과 같이 현재 MySQL의 병렬 실행은 아직 매우 초기 단계입니다. 왼쪽은 단일 SQL 형식의 이전 MySQL 직렬 처리입니다. 하나는 현재 MySQL 버전인 InnoDB에서 제공하는 병렬 기능입니다. 엔진 병렬 스캐닝의 형태는 MySQL이 향후 개발할 형태이며, 최적화 프로그램은 시스템 부하와 SQL을 기반으로 병렬 계획을 생성합니다. , 병렬 실행을 위해 파티션 계획을 실행자에게 보냅니다. 병렬 실행은 병렬 스캐닝뿐만 아니라 병렬 집계, 병렬 조인, 병렬 그룹화 및 병렬 정렬도 포함합니다. 현재 MySQL 버전의 상위 수준 최적화 프로그램 및 실행 프로그램에 대한 지원 수정은 없습니다. 따라서 다음 논의에서는 주로 분할, 병렬 스캐닝, 미리 읽기 및 실행기와 상호 작용하는 어댑터 클래스를 포함하여 InnoDB 엔진이 병렬 스캐닝을 구현하는 방법에 중점을 둡니다.

파티션

병렬 스캔의 핵심 단계는 스캔한 데이터를 여러 부분으로 나누고 여러 스레드가 병렬로 스캔할 수 있도록 하는 파티셔닝입니다. InnoDB 엔진은 인덱스로 구성된 테이블이며, 데이터는 B+트리 형태로 디스크에 저장되며, 동시에 핫 페이지는 버퍼 풀에 캐시됩니다. LRU 알고리즘을 통해 제거됩니다. 파티셔닝의 논리는 루트 노드 페이지에서 시작하여 레이어별로 스캔하는 것입니다. 특정 레이어의 분기 수가 구성된 스레드 수를 초과한다고 판단되면 분할이 중지됩니다. 구현 중에 실제로는 총 2개의 파티션이 수행됩니다. 첫 번째 파티션은 루트 노드 페이지의 분기 수에 따라 나누어집니다. 각 분기의 가장 왼쪽 리프 노드의 레코드는 왼쪽 하한입니다. 인접 상한으로 기록됩니다. 가지의 오른쪽 상한. 이런 방식으로 B+트리는 여러 개의 하위 트리로 나뉘며, 각 하위 트리는 스캔 파티션입니다. 첫 번째 파티션 이후에는 파티션 개수가 멀티코어를 충분히 활용하지 못하는 문제가 발생할 수 있습니다. 예를 들어 병렬 스캐닝 스레드를 3개로 구성하고, 첫 번째 파티션 이후에는 4개의 파티션이 생성되고, 처음 3개 파티션은 병렬로 완료되고, 네 번째 파티션은 최대 하나의 스레드로만 스캔할 수 있으며, 최종 결과는 멀티 코어 리소스를 완전히 활용할 수 없다는 것입니다.

보조 파티션

이 문제를 해결하기 위해 버전 8.0.17에서는 네 번째 파티션에 대해 분할을 계속 탐색하여 여러 하위 파티션을 동시에 스캔할 수 있으며 InnoDB 엔진이 스캔합니다. 동시에 가장 작은 세분성은 페이지 수준입니다. 2차 파티셔닝을 판단하는 구체적인 논리는 1차 파티셔닝 후 파티션 수가 스레드 수보다 크면 파티션 수가 스레드 수보다 큰 파티션은 2차 파티셔닝을 위해 계속되어야 한다는 것입니다. 스레드 수보다 적고 B+트리 수준이 매우 깊은 경우 모든 파티션에는 보조 파티셔닝이 필요합니다.

관련 코드는 다음과 같습니다.

split_point = 0;
if (ranges.size() > max_threads()) {
   //最后一批分区进行二次分区                                      
   split_point = (ranges.size() / max_threads()) * max_threads();          
 } else if (m_depth < SPLIT_THRESHOLD) {                                  
   /* If the tree is not very deep then don&#39;t split. For smaller tables    
   it is more expensive to split because we end up traversing more blocks*/
   split_point = max_threads();                                            
 } else {
   //如果B+tree的层次很深(层数大于或等于3，数据量很大)，则所有分区都需要进行二次分区
 }

주 파티션이든 보조 파티션이든 파티션 경계의 논리는 동일합니다. 각 파티션의 가장 왼쪽 리프 노드의 레코드는 왼쪽 하단 경계입니다. 레코드는 분기의 오른쪽 상단 경계로 기록됩니다. 이렇게 하면 충분한 파티션, 충분한 세분성 및 충분한 병렬성이 보장됩니다. 아래 그림은 2차 파티셔닝을 위한 3개의 동시 스레드 스캐닝 구성을 보여줍니다.

해당 코드는 다음과 같습니다.

create_ranges(size_t depth, size_t level)
一次分区：
parallel_check_table
 add_scan
   partition(scan_range, level=0)  /* start at root-page */
     create_ranges(scan_range, depth=0, level=0)
   create_contexts(range, index >= split_point)
二次分区：                                                      
split()
 partition(scan_range, level=1)
   create_ranges(depth=0,level)

병렬 스캐닝

파티션 후에는 각 파티션 스캐닝 작업을 잠금 없는 대기열에 넣습니다. 병렬 작업자 스레드는 대기열에서 작업을 가져와서 스캐닝 작업을 실행합니다. 획득한 작업에 분할 속성이 있는 경우 작업자는 작업을 두 번 분할합니다. 그리고 대기열에 넣습니다. 이 프로세스에는 주로 두 개의 핵심 인터페이스가 포함됩니다. 하나는 작업자 스레드 인터페이스이고 다른 하나는 순회 기록 인터페이스입니다. 전자는 대기열에서 작업을 가져와 실행하고, 후자는 가시성을 기반으로 적절한 레코드를 획득하고 주입합니다. 계산 등의 상위 계층 콜백 기능 처리를 통해 수행됩니다.

Parallel_reader::worker(size_t thread_id)

{

1. ctx-queue

에서 ctx 작업을 추출합니다. 2. ctx의 분할 속성을 기반으로 파티션을 추가로 분할해야 하는지 결정합니다(split() )

3. 파티션의 모든 레코드를 순회합니다(traverse())

4. 파티션 작업이 끝난 후 m_n_completed 개수를 유지합니다.

5. m_n_compeleted 개수가 ctx 번호에 도달하면 모든 작업자 스레드를 깨워 종료합니다.

6. 트래버스 인터페이스에 따라 오류 정보를 반환합니다.

}

Parallel_reader::Ctx::traverse()

{

1. 범위에 따라 pcursor를 설정합니다

2. btree를 찾아 범위의 시작 위치에 커서를 놓습니다

3. 가시성 결정(check_visibility )

4. 보이는 경우 콜백 함수(예: 통계)에 따라 계산합니다.

5. 뒤로 이동하여 페이지의 마지막 레코드에 도달하면 사전 읽기 메커니즘을 시작합니다(submit_read_ahead)

6. 범위 초과 후 종료

}

동시에 버전 8.0.17에서는 IO 병목 현상으로 인한 병렬 효과 저하 문제를 피하기 위해 미리 읽기 메커니즘도 도입했습니다. 현재는 미리 읽기를 위한 스레드 개수를 구성할 수 없으며 코드에 2개의 스레드로 하드코딩되어 있습니다. 각 pre-read의 단위는 클러스터(InnoDB 파일은 세그먼트, 클러스터, 페이지의 3단계 구조로 관리된다. 클러스터는 연속된 페이지의 그룹이다.)이며, 크기에 따라 1M 또는 2M가 될 수 있다. 페이지 구성. 일반적인 16k 페이지 구성의 경우 매번 1M을 미리 읽으며 이는 64페이지입니다. 작업자 스레드는 스캔할 때 먼저 다음 인접 페이지가 클러스터의 첫 번째 페이지인지 확인하고, 그렇다면 사전 읽기 작업을 시작합니다. 미리 읽기 작업은 잠금 없는 대기열을 통해서도 캐시됩니다. 작업자 스레드는 생산자이고 미리 읽기 작업자는 소비자입니다. 모든 파티션 페이지가 겹치지 않으므로 미리 읽기 작업이 반복되지 않습니다.

Executor 상호 작용(어댑터)

사실 MySQL은 이후의 더욱 풍부한 병렬 실행을 준비하기 위해 상위 계층에서 사용할 어댑터 클래스 Parallel_reader_adapter를 캡슐화했습니다. 우선, 이 클래스는 레코드 형식의 문제를 해결하고 엔진 계층에서 스캔한 레코드를 MySQL 형식으로 변환해야 합니다. 이렇게 하면 실행자가 엔진을 인식할 필요가 없습니다. 레이어 형식이며 MySQL 형식으로 처리됩니다. 전체 프로세스는 조립 라인이며, 작업자 스레드는 지속적으로 엔진 계층에서 레코드를 읽는 동시에 상위 계층에서 레코드를 계속 처리합니다. 속도는 버퍼를 통해 균형을 이룰 수 있습니다. 전체 프로세스가 흐르는지 확인하세요. 기본 캐시 크기는 2M입니다. 버퍼가 캐시할 수 있는 MySQL 레코드 수는 테이블의 레코드 행 길이에 따라 결정됩니다. 핵심 프로세스는 주로 process_rows 인터페이스에 있습니다. 프로세스는 다음과 같습니다

process_rows

{

1. 엔진 레코드를 MySQL 레코드로 변환

2. 이 스레드의 버퍼 정보를 얻습니다(변환된 mysql 레코드 수와 상위 계층으로 전송된 수)

3. MySQL 레코드를 버퍼에 채우고 통계 m_n_read

를 자동 증가시킵니다. 4. 처리(예: 통계, 집계, 정렬 등)를 위한 콜백 함수를 호출합니다. 통계 자동 증가 m_n_send

}

호출자에 대해서는 테이블의 메타 정보 설정이 필요하며, 집계 처리, 정렬, 그룹화 등 레코드 처리를 위한 콜백 함수 주입이 필요합니다. 콜백 함수는 m_init_fn, m_load_fn 및 m_end_fn을 설정하여 제어됩니다.

요약

MySQL 8.0은 병렬 쿼리를 도입했지만 아직은 상대적으로 초보적이지만 실험을 통해 이미 MySQL 병렬 쿼리의 잠재력을 확인할 수 있었습니다. 명령문 실행은 멀티 코어 기능을 최대한 활용하여 응답 시간이 급격히 떨어졌습니다. 가까운 미래에 8.0에서는 병렬 집계, 병렬 연결, 병렬 그룹화, 병렬 정렬 등 더 많은 병렬 연산자를 지원할 것이라고 믿습니다.

위 내용은 MySQL8.0 InnoDB 병렬 실행에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!