데이터베이스 최적화 검토(2장)

2장 :

스토리지 엔진

MySQL 스토리지 엔진은 실제로 추상 클래스입니다. 파일 액세스 계층의 추상 인터페이스는 파일 액세스 메커니즘을 사용자 정의하는 데 사용됩니다. 이 액세스 메커니즘을 스토리지 엔진이라고 합니다. MySQL을 다른 데이터베이스와 구별하는 가장 중요한 기능은 플러그-인입니다. 스토리지 엔진 인터페이스 모듈, 플러그형 스토리지 엔진 .

스토리지 엔진은 MySQL 공식 스토리지 엔진과 타사 스토리지 엔진으로 나눌 수 있습니다.

MySQL의 공식적이고 가장 주류적인 스토리지 엔진은 다음과 같습니다.

1. MyISAM 스토리지 엔진
2. InnoDB 스토리지 엔진
3. 메모리 스토리지 엔진
4. NDB 스토리지 엔진
5. 아카이브 스토리지 엔진

MyISAM 스토리지 엔진(OLAP 데이터베이스 애플리케이션용)

1. 저장 용량 한도: 256TB
2. 트랜잭션을 지원하지 않으며 MVCC(다중 버전 동시성 제어)를 지원하지 않습니다.
3. 잠금 세분성: 테이블 수준
4. 지원되는 인덱스 유형: B-트리 인덱스, 전체 텍스트 인덱스
5. 복제 지원, 외래 키 지원 안 됨 , 쿼리 캐시 지원
6. 빠른 액세스 속도 , 향상된 인덱스 최적화 및 데이터 압축 기술

MyISAM 스토리지 엔진 테이블은 MYD와 MYI로 구성되며, MYD는 데이터 파일을 저장하는 데 사용되고 MYI는 인덱스 파일을 저장하는 데 사용됩니다 .

MySQL 5.0 이전에는 MyISAM이 기본적으로 4GB의 테이블 크기를 지원하고, MySQL 5.0 이후에는 256TB의 단일 테이블 데이터를 지원합니다 .

MyISAM 버퍼 풀은 데이터 파일이 아닌 인덱스 파일만 캐시합니다 .

InnoDB 스토리지 엔진(OLTP 데이터베이스 애플리케이션용)

1. 트랜잭션 지원 , MVCC(다중 버전 동시성 제어) 지원
2. 잠금 세분성: 행 수준
3. 지원되는 인덱스 유형: B-트리 인덱스, 적응형 해시 인덱스 , 전체 텍스트 인덱스
4. 복제 지원, 외래 키 지원 , 쿼리 캐시 지원

MyISAM과 InnoDB의 차이점:

MyISAM은 테이블의 총 행 수를 저장하고 InnoDB는 테이블의 총 행 수를 저장하지 않습니다.

MyISAM 쿼리 속도는 InnoDB보다 훨씬 빠릅니다.

NDB 스토리지 엔진

NDB 스토리지 엔진은 클러스터형 스토리지 엔진 입니다 .

NDB의 특징은 모든 데이터가 메모리에 저장되므로 기본 키 조회가 매우 빠르며 , 가용성이 높고 성능이 뛰어난 클러스터 시스템 이다 .

그러나 테이블의 연결 작업은 스토리지 엔진 계층이 아닌 MySQL 데이터베이스 계층에서 수행됩니다. 이는 복잡한 연결 작업에 막대한 네트워크 오버헤드가 필요하므로 복잡한 쿼리가 느려지고 NDB 스토리지 엔진이 트랜잭션을 지원하지 않는다는 것을 의미 합니다 .

메모리 스토리지 엔진

메모리 스토리지 엔진은 테이블의 데이터를 메모리에 저장하며 , 데이터베이스가 재시작되거나 충돌이 발생하면 테이블의 데이터는 사라집니다.

임시 데이터를 저장하는 데 적합한 임시 테이블입니다.

메모리 저장 엔진은 매우 빠르지 만 사용 시에는 여전히 특정 제한 사항이 있습니다. 예를 들어 테이블 잠금 만 지원되고 동시성 성능이 낮으며 트랜잭션 이 지원되지 않습니다 . 메모리 스토리지 엔진은 기본적으로 B+ 트리 인덱스 대신 해시 인덱스를 사용합니다 .

아카이브 스토리지 엔진

아카이브 스토리지 엔진은 INSERT 및 SELECT 작업만 지원합니다 . zlib 알고리즘을 사용하여 데이터 행을 압축하고 저장하면 압축 비율은 일반적으로 1:10에 도달할 수 있습니다.

Archive 스토리지 엔진은 로그 정보와 같은 아카이브된 데이터를 저장하는 데 매우 적합합니다.

아카이브 스토리지 엔진은 트랜잭션에 안전하지 않으며 설계 목표는 주로 고속 삽입 및 압축 기능을 제공하는 것 입니다 .

엔진 수정

변환 테이블의 스토리지 엔진은 원래 스토리지 엔진과 관련된 모든 기능을 잃게 됩니다 . 예를 들어 InnoDB 테이블을 MyISAM으로 변환한 다음 다시 InnoDB로 변환하면 원래 InnoDB 테이블의 모든 외래 키가 사라집니다.

Innodb 스토리지 엔진 아키텍처

1. 버퍼 풀
2. 버퍼 변경
3. 적응형 해시 인덱스
4. 리두 로그 버퍼
5. 이중 쓰기

MySQL은 WAL을 사용하여 데이터베이스 트랜잭션의 일관성과 내구성을 보장합니다. 구체적으로:

1. 레코드를 수정하기 전에 먼저 .
2. 트랜잭션 제출 프로세스 중에 로그가 먼저 디스크에 배치되어 트랜잭션 제출이 완료되는지 확인 해야 합니다 .

InnoDB 버퍼 풀

InnoDB 엔진은 버퍼 풀 기술을 사용하여 데이터베이스의 전반적인 성능(속도)을 향상시킵니다.

InnoDB 스토리지 엔진에는 다양한 버퍼 풀이 있으며 이러한 버퍼 블록은 대규모 InnoDB 스토리지 엔진 메모리 풀을 형성합니다. 주요 작업은 다음과 같습니다.

1. 모든 프로세스/스레드가 액세스해야 하는 여러 내부 데이터 구조를 유지합니다.
2. 빠른 읽기를 위해 디스크에 데이터를 캐시하고 , 디스크 파일을 수정하기 전에 캐시합니다.
3. Redo 로그 캐시 등

Innodb 엔진에서 디스크와 메모리 사이의 데이터 상호 작용의 기본 단위 는 데이터 페이지 이며 기본 크기는 16KB입니다 .

Innodb 엔진은 각 캐시 페이지에 해당하는 블록 구조를 생성하고 , 블록 구조에는 페이지의 테이블스페이스 번호, 페이지 번호 등의 정보가 저장됩니다.

데이터 페이지는 LRU 최근 사용 알고리즘을 통해 교체됩니다 .

버퍼 풀 관련 매개변수

1. innodb_buffer_pool_size : 버퍼 풀의 총 크기
2. innodb_buffer_pool_instances : 버퍼 풀의 인스턴스 수 높은 동시 잠금 경합의 부담을 줄이기 위해 버퍼 풀을 여러 인스턴스로 나눕니다.
3. innodb_buffer_pool_chunk_size : 청크의 크기, 기본값은 128M이며 Mysql5.7 버전 이후 Innodb 엔진에서는 청크 구조를 도입했습니다. Buffer Pool(확장시)은 운영체제에서 연속적인 메모리 공간의 일부를 위해 적용되며, 운영체제에 청크 단위로 적용되며, 청크에는 캐시 페이지의 컨트롤 블록과 캐시 페이지, 링크드 리스트 정보가 저장된다. 이러한 캐시 페이지를 관리합니다.
4. innodb_buffer_pool_dump_at_shutdown=ON은 MySQL이 종료될 때 메모리의 핫 데이터가 디스크의 ib_buffer_pool 파일에 저장된다는 의미입니다.
5. innodb_buffer_pool_load_at_startup=ON은 시작 시 핫 데이터가 자동으로 Buffer_Pool 버퍼 풀에 로드됨을 의미합니다. 이렇게 하면 핫 데이터가 항상 메모리에 유지됩니다.

InnoDB의 변경 버퍼

보조 인덱스는 일반적으로 고유하지 않고 삽입 순서가 매우 무작위이며 업데이트와 삭제가 인접 위치에 있지 않습니다. 변경 버퍼는 많은 무작위 I/O 생성을 피하고 여러 작업을 소수의 I로 전환합니다. /O 작업을 최대한 많이 수행합니다.

변경 버퍼 관련 매개변수:

1. innodb_change_buffering : 캐시에 해당하는 작업입니다.
2. innodb_change_buffer_max_size : 버퍼 풀에서 변경 버퍼의 최대 비율을 구성하는 데 사용됩니다.

InnoDB의 적응형 해시 인덱스

lnnoDB 스토리지 엔진은 테이블의 보조 인덱스 조회를 모니터링합니다. 보조 인덱스에 자주 접근하는 것으로 확인되면 보조 인덱스는 핫 데이터가 되고 , 해시 인덱스를 구축하면 속도가 빨라질 수 있으면 해시 인덱스를 구축하므로 적응형, 즉 적응형이라고 한다. 해시 인덱스 . MySQL은 자동으로 관리되며 인간이 개입할 수 없습니다.

적응형 해시 인덱스는 버퍼 풀의 B+Tree를 통해 구성됩니다.

적응형 해시 인덱스는 lnnoDB 버퍼 풀을 차지합니다.

이 기능을 끄거나 켜려면 "set global innodb_adaptive_hash_index off/on" 명령을 사용하십시오.

InnoDB의 리두 로그 버퍼

리두 로그 버퍼는 리두 로그 파일에 기록될 데이터를 저장합니다. 크기는 를 통해 설정됩니다.

매개변수:

1. innodb_flush_log_at_trx_commit, 리두 로그 플러시 빈도 제어(0, 1, 2, 보안은 낮음에서 높음으로, 성능은 높음에서 낮음으로)
2. innodb_log_buffer_size, 리두 로그 버퍼의 크기를 설정합니다.

InnoDB의 이중 쓰기

이중 쓰기 기술의 도입은 데이터 쓰기의 신뢰성을 향상시키는 것입니다 . 순차 쓰기는 무작위 쓰기보다 비용이 저렴합니다. 단점은 새로운 유형의 SSD 스토리지에 반복적으로 쓰기가 SSD의 수명에 큰 영향을 미친다는 것입니다.

매개변수:

1. innodb_doublewrite=0 : 이중 쓰기 기능을 끕니다.

트랜잭션 커밋

트랜잭션 커밋 프로세스

스토리지 엔진이 트랜잭션을 구현하는 일반적인 방법은 다시 실행 로그와 실행 취소 로그를 기반으로 합니다. Redo 로그는 트랜잭션에 의해 수정된 데이터를 기록 하고, Undo 로그는 트랜잭션 이전의 원본 데이터를 기록합니다 .

트랜잭션이 실행될 때 발생하는 실제 프로세스

1. 먼저 실행 취소/재실행 로그를 기록하여 로그가 영구 저장을 위해 디스크에 플러시되었는지 확인합니다 .
2. 데이터 레코드를 업데이트하고 , 작업을 캐시하고, 디스크를 비동기적으로 플러시합니다.
3. 트랜잭션 로그를 binlog에 유지합니다.
4. 트랜잭션을 커밋 하고 리두 로그에 커밋 기록을 씁니다.

binlog는 트랜잭션 저장 엔진의 범위 내에 있지 않으므로 트랜잭션 로그는 트랜잭션이 커밋되기 전(업데이트 후, 커밋 전) binlog에 유지되어야 합니다.

거래가 제출된 후

1. 트랜잭션이 제출된 후 실행 취소 세그먼트가 제거 됩니다 . 제거의 주요 기능은 실제로 물리적 기록을 삭제하는 것입니다. (삭제 또는 업데이트 작업을 수행하면 실제 오래된 레코드가 실제로 삭제되는 것이 아니라 (is_deleted와 유사) 레코드에 표시가 표시되지만 트랜잭션이 커밋된 후에는 퍼지 스레드가 실제로 삭제합니다.)

2. 잠금 리소스 해제

3. 리두 로그를 브러시합니다. Redo 로그 삭제 작업을 통해 데이터베이스의 무결성과 일관성을 보장합니다 .

4. 저장점 목록 정리 각 문에는 실제로 롤백을 위한 저장점이 있습니다.

InnoDB 백그라운드 스레드

InnoDB 백그라운드 스레드의 주요 기능은 메모리 풀의 데이터를 새로 고쳐 버퍼 풀의 메모리 캐시가 최신 데이터인지 확인하는 것입니다.

InnoDB 메인 스레드

마스터 스레드: 주요 작업은 더티 페이지 새로 고침, 버퍼 병합 및 삽입 등을 포함하여 데이터 일관성을 보장하기 위해 버퍼 풀의 데이터를 디스크에 비동기식으로 새로 고치는 것입니다.

마스터 스레드는 스레드 우선순위가 가장 높으며 내부는 여러 개의 루프로 구성됩니다 . 마스터 스레드는 데이터 작업 상태에 따라 여러 사이클 사이를 전환합니다.

1. 배경 루프
   1. 쓸모없는 실행 취소 페이지 삭제(항상)
   2. 일정량의 삽입 버퍼 병합(항상)
   3. 사용자 활동이 있으면 메인 루프로 다시 점프하고, 그렇지 않으면 새로 고침 루프로 점프합니다(항상).
2. 새로고침 주기
   1. 특정 수의 더티 페이지를 디스크에 플러시합니다(항상).
   2. 일시정지 루프로 점프(항상)
3. 일시 정지 루프
   1. 마스터 스레드 일시 중단
   2. 이벤트가 발생하면 메인 루프로 점프합니다(항상).

InnoDB 백그라운드 I/O 스레드

AIO 비동기 I/O는 InnoDB 스토리지 엔진에서 널리 사용되어 I/O 요청을 처리하므로 데이터베이스 성능을 크게 향상시킬 수 있습니다 .

읽기 스레드는 디스크에서 버퍼 풀의 페이지로 데이터를 로드하는 역할을 합니다.

쓰기 스레드는 버퍼 풀의 더티 페이지를 디스크로 플러시하는 역할을 합니다.

로그 스레드는 로그 버퍼의 내용을 디스크로 플러시하는 역할을 합니다.

삽입 버퍼 스레드는 변경 버퍼의 내용을 디스크로 플러시하는 역할을 합니다.

매개변수: my.cnf 구성 파일에서 설정할 수 있습니다.

1. innodb_read_io_threads
2. Innodb_write_io_threads

InnoDB 더티 페이지 새로 고침 스레드

MySQL 5.6 이전에는 더티 페이지 정리가 마스터 스레드 에 의해 처리되었습니다 . 5.6 이후에는 페이지 클리너 스레드가 버퍼 풀에서 더티 페이지를 플러시하는 작업을 구현합니다.

매개변수:

1. innodb_page_cleaners : 더티 페이지 플러시 스레드 수를 설정합니다. (다중 페이지 클리너 스레드는 버전 5.7.4 이후에 도입되었습니다.)
2. Innodb_buffer_pool_wait_free : 더티 페이지가 시스템의 성능 병목 현상이 되었는지 여부를 표시합니다. innodb_buffer_pool_size가 충분히 크면 Innodb_buffer_pool_wait_free 값을 작게 또는 0으로 만들 수 있습니다.

InnoDB 퍼지 스레드

제거 스레드는 사용 및 할당된 실행 취소 페이지(원본 데이터 기록)를 회수하는 역할을 담당합니다.

예외:

1. 삽입 취소 로그에는 삽입 작업이 이 트랜잭션에만 표시되므로 제거가 필요하지 않으므로 트랜잭션이 커밋된 후 바로 삭제됩니다.
2. 업데이트 실행 취소 로그는 업데이트 삭제 작업에 의해 생성되며, 이는 나중에 MVCC에서 사용될 수 있으므로 제출 시 삭제할 수 없습니다. Undo 로그의 연결 목록에 들어가 최종 삭제를 위한 Purge를 기다립니다 .

데이터 행 삭제 및 업데이트 시 데이터 페이지에서 삭제할 데이터 행을 "삭제됨"으로 표시하고 트랜잭션 제출 속도가 빠르며 백그라운드 스레드 퍼지 스레드는 실제로 데이터에서 "삭제됨" 라벨이 있는 데이터 행을 삭제합니다. 페이지.

매개변수:

1. innodb_purge_threads : 동시 제거 스레드 수를 조정할 수 있습니다.