데이터베이스 애플리케이션에는 OLTP (온라인 트랜잭션 처리)와 OLAP (온라인 분석 처리)의 두 가지 유형이 있습니다. OLAP는 일반적으로 데이터웨어 하우스 (하나 이상의 소스 데이터베이스의 히스토리 데이터 및 메타 데이터가 저장되는 관계형 데이터베이스 모델) 또는 데이터 마트 (데이터웨어 하우스에서 관련 데이터를 추출하는 데 사용되는 데이터웨어 하우스의 액세스 계층)에서 사용됩니다. , 쿼리에는 복잡한 SQL 문이 필요합니다. OLTP는 일상적인 트랜잭션 처리 응용 프로그램에서 주로 사용되며 데이터베이스 용량은 OLAP에 비해 상대적으로 작습니다.
InnoDB 엔진은 일반적으로 OLTP 데이터베이스 애플리케이션에 사용되며,이 애플리케이션의 특징은 다음과 같습니다.
1. 동시 사용자 작업량이 많습니다.
2. 트랜잭션 처리 시간은 일반적으로 비교적 짧습니다.
3. 질의 문은 비교적 단순하며 일반적으로 인덱스가 사용됩니다.
4. 덜 복잡한 쿼리.
위의 특성에서 볼 수 있듯이 OLTP 데이터베이스 응용 프로그램에는 높은 CPU가 필요하지 않습니다. 복잡한 쿼리 만 비교, 정렬 및 연결과 같은 CPU 소모 작업을 수행 할 수 있기 때문입니다. OLAP는 CPU를 많이 사용하는 작업이고 OLTP는 IO를 많이 사용하는 작업이라고 할 수 있습니다 (구입시 IO 구성 개선에 더 많은주의를 기울여야 함).
더 많은 메모리 지원을 받으려면 CPU가 64 비트 응용 프로그램을 지원해야합니다. 그렇지 않으면 64 비트 운영 체제 설치를 지원할 수 없습니다.
InnoDB 엔진의 설계 아키텍처 관점에서 메인 백그라운드 작업은 멀티 코어 애플리케이션을 잘 지원하지 않는 단일 MASTER THREAD에서 수행됩니다. 새로운 InnoDB Plugin 버전은 멀티 코어 CPU의 처리 성능을 크게 향상시킵니다. , 또한 매개 변수 innodb_read_io_threads 및 innodb_write_io_threads를 수정하여 IO 스레드를 늘릴 수 있으며, 이는 또한 CPU 멀티 코어 성능을 최대한 활용할 수 있습니다.
현재 버전에서 SQL 문은 하나의 CPU에서만 작동 할 수 있습니다. OLTP 데이터베이스 응용 프로그램의 작업은 일반적으로 매우 간단하기 때문에 OLTP 응용 프로그램에는 거의 영향을 미치지 않지만 여러 CPU 또는 다중 코어 CPU는 대규모 동시 요청에 매우 유용합니다. .
위 테스트에서 데이터 파일과 인덱스의 총 크기는 18GB입니다. 버퍼 풀이 증가하면 테스트 결과 TPS (Transaction Per Second)가 선형 적으로 증가합니다. 버퍼 풀이 20GB로 증가하면 데이터베이스 성능이 크게 향상됩니다. 버퍼 풀의 크기가 데이터 파일 자체의 크기보다 크기 때문에 데이터 파일에 대한 작업을 메모리에서 수행 할 수 있습니다. 이때 성능은 최적입니다. 버퍼 풀을 늘리면 데이터베이스 성능이 저하되지 않습니다. 더 이상 개선됩니다.
데이터베이스 메모리가 병목 상태에 도달했는지 확인합니다.
매개 변수 의 의미 :
1. Innodb_buffer_pool_reads : 물리적 디스크에서 페이지를 읽은 횟수.
2. Innodb_buffer_pool_read_ahead : 미리 읽은 횟수.
3. Innodb_buffer_pool_read_ahead_evicted : 읽지 않고 버퍼 풀에서 교체 된 페이지 수로, 일반적으로 사전 읽기의 효율성을 결정하는 데 사용됩니다.
4. Innodb_buffer_pool_read_requests : 버퍼 풀에 대한 읽기 요청 수.
5. Innodb_data_read : 읽은 총 바이트 수.
6. Innodb_data_reads : 시작된 읽기 요청 수, 각 읽기는 여러 페이지를 읽어야 할 수 있습니다.
위의 매개 변수에 따라 버퍼 풀 적중률을 계산할 수 있습니다 (일반적으로 99 % 이상이어야 함) :
(innodb_buffer_pool_read_requests) / (Innodb_buffer_read_requests + Innodb_buffer_pool_read_ahead + Innodb_buffer_pool_reads)
시간당 읽은 평균 바이트 수 :
innodb_data_read / innodb_data_reads
버퍼 풀 크기가 데이터베이스 크기보다 크더라도 디스크 작업이 없음을 의미하는 것은 아닙니다. 백그라운드 마스터 스레드는 더티 페이지를 디스크에 비동기 적으로 기록하는 역할도 담당하며 리두 로그 파일에 기록해야합니다. 트랜잭션이 커밋 될 때마다 즉시.
서버 필드는 일반적으로 SAS 또는 SATA 인터페이스가있는 기계식 하드 디스크를 사용합니다. 기계식 하드 디스크에는 검색 시간과 회전 속도라는 두 가지 중요한 표시기가 있습니다. 기계식 하드 디스크에 대한 임의 액세스는 찾기 위해 오랜 시간의 머리 회전 및 위치 지정이 필요하며 순차 액세스 속도는 임의 액세스 속도보다 훨씬 빠릅니다. 데이터베이스의 많은 특성도 순차 액세스 특성을 최대한 활용하고 있습니다. 여러 기계식 하드 디스크를 RAID로 구성하여 데이터베이스 성능을 향상시킬 수 있으며 데이터 파일을 다른 하드 디스크에 분산하여로드 균형을 맞출 수도 있습니다.
솔리드 스테이트 드라이브는 낮은 대기 시간, 낮은 전력 소비 및 내 충격성을 가진 플래시 메모리로 구성됩니다. 플래시 메모리는 기존의 기계식 하드 드라이브의 읽기 및 쓰기 헤드가없는 완전한 전자 장치이며 솔리드 스테이트 드라이브는 일관된 임의 액세스 시간을 제공 할 수 있습니다. 플래시 메모리의 데이터는 업데이트 할 수 없으며 섹터별로 만 덮어 쓸 수 있습니다. 덮어 쓰기 및 덮어 쓰기 전에 매우 시간이 많이 소요되는 지우기 작업을 수행해야합니다. 지우기 작업은 섹터에서 완료 할 수 없지만 지워야합니다. 블록이 완료 될 때까지 삭제 블록은 일반적으로 128KB이지만 각 삭제 블록에는 삭제 및 쓰기 횟수에 제한이 있으므로이 문제를 해결하기위한 몇 가지 알고리즘이 있습니다. 쓰기 문제로 인해 솔리드 스테이트 읽기 속도가 쓰기 속도보다 빠르며 과도한 쓰기 작업을 피하기 위해 읽기 성능을 사용해야합니다.
InnoDB 엔진에서 솔리드 스테이트 드라이브의 최적화를 위해 innodb_io_capacity 파라미터 (InnoDB 백그라운드 작업에 사용할 수있는 IOPS (초당 I / O 작업) 수)의 값을 늘릴 수 있습니다.
RAID (Redundant Array of Independent Disks)의 기본 아이디어는 비교적 저렴한 여러 개의 하드 디스크를 디스크 어레이로 결합하여 대용량의 고가의 하드 디스크 성능에 도달하거나 초과 할 수 있도록하는 것입니다. 여러 하드 디스크가 하나의 논리 섹터로 결합되기 때문에 RAID는 단일 하드 디스크 또는 논리 저장 장치처럼 보이며 운영 체제는이를 하드 디스크로만 취급합니다.
다른 디스크 조합 방법에 따라 일반적인 RAID 조합은 다음과 같습니다.
1. RAID 0 : 중복성, 병렬 IO 및 가장 빠른 속도없이 여러 디스크를 큰 디스크로 결합합니다. RAID 0은 스트라이프 세트라고도합니다. 데이터를 저장할 때 데이터는 디스크 수에 따라 분할되고 데이터는 동시에 해당 디스크에 기록됩니다. 이론적으로 여러 디스크의 성능은와 동일 单一磁盘效能 * 磁盘数하지만 실제로 버스 IO 병목 현상 및 기타 요인에 의해 제한되어 RAID의 성능은 여유와 함께 감소합니다.
2. RAID 1 : 두 개 이상의 N 디스크 그룹이 서로의 미러 이미지이며 다중 스레드 운영 체제에서는 읽기 속도가 좋지만 쓰기 속도가 약간 느립니다. 동일한 데이터를 가진 기본 디스크와 미러가 동시에 손상되지 않는 한 하나의 디스크가 정상이면 작동이 유지 될 수 있고 신뢰성이 높습니다. 미러링의 원리는 데이터가 기본 하드 디스크에 저장 될 때 동일한 데이터가 미러링 된 하드 디스크에도 기록된다는 것입니다. 사용되는 디스크 세트의 수에 관계없이 RAID 1은 디스크 세트의 용량으로 만 계산하며 디스크 사용률은 낮습니다.
3. RAID 5 : 스토리지 성능, 데이터 보안 및 스토리지 비용을 고려한 솔루션입니다. 디스크 스트라이핑 (하드 디스크 파티셔닝) 기술을 사용합니다. RAID 5에는 최소 3 개의 하드 디스크 (데이터를 저장하는 데 2 개의 디스크, 두 개의 디스크 패리티 정보를 저장하는 디스크), 저장된 데이터를 백업하지 않고 RAID 5를 구성하는 각 디스크에 데이터 및 해당 패리티 정보를 저장하고 데이터 및 해당 패리티 정보를 저장합니다. 디스크에서 RAID 5의 디스크 데이터가 손상되면 나머지 데이터와 해당 패리티 정보를 사용하여 손상된 데이터를 복구 할 수 있습니다 (데이터 A1 = 00000111, A2 = 00000101 및 A3 = 00000000의 복사본이 3 개 있다고 가정하면 3 개). 결과 Ap = 00000010을 얻기 위해 데이터가 XOR됩니다. 이때 A2가 액세스하지 못하면 다음을 통과 할 수 있습니다.A1 XOR A3 XOR Ap = 00000101A2의 값이 계산됩니다. 원칙은 두 개의 동일한 숫자에 대한 배타적 OR의 결과는 0이고 0과 모든 숫자의 배타적 OR은 숫자 자체이며 배타적 OR에는 교환 법칙이 있습니다. RAID 5는 RAID 0과 RAID 1 사이의 절충안으로 이해할 수 있습니다. RAID 5의 보안 기능은 미러링보다 낮고 디스크 공간 사용률은 미러링보다 높습니다. RAID 5의 읽기 속도는 RAID 0에 가깝지만 추가 패리티 정보로 인해 쓰기 속도가 상당히 느립니다. Write Back을 사용하면 성능이 향상 될 수 있습니다.
4. RAID 10 및 RAID 01 : RAID 10이 먼저 미러링 된 다음 스트라이핑 :
RAID 01이 먼저 스트라이핑 된 다음 미러링 :
RAID 10이 더 안전하고 Disk0이 손상되었다고 가정하면 RAID 10도 동시에 Disk1에 있습니다. 데이터가 손실됩니다. 손상된 경우에만 손상 률을 1/3로 계산하면됩니다. RAID 01의 경우 먼저 RAID 0이므로 Disk0과 Disk1은 둘 다 고장난 논리 디스크입니다.이 때, Disk2 또는 Disk3 중 하나가 손상되면 (Disk2 및 Disk3 전체가 손상되는 것과 동일) 데이터가 손상되므로 손상 률을 2/3로 계산하면됩니다. 이 두 가지 방법의 단점은 더 많은 하드 디스크가 필요하고 최소 4 개의 짝수 번호 하드 디스크가있을 때만 사용할 수 있다는 것입니다.
(5) RAID 50 : 미러링 된 어레이 스트라이프라고도합니다. 최소 6 개의 하드 디스크가 필요합니다. 구조는 다음과 같습니다.
RAID Write Back은 RAID 컨트롤러가 데이터를 자체 캐시에 넣고 실제 데이터를 기록함을 의미합니다. 나중에 실행되도록 정렬하여 실제 디스크 쓰기가 완료 될 때까지 기다릴 필요가 없으며 성능이 크게 향상됩니다. 이 방법은 sync_binlog가 1로 설정된 경우 데이터베이스의 리두 로그에 쓰기, 바이너리 로그에 쓰기, 더티 페이지 새로 고침과 같은 작업의 성능을 크게 향상시킬 수 있습니다.
시스템에 사고가 발생하면 쓰기 실패 전에 Write Back이 발생할 수 있으며,이를 위해 대부분의 하드웨어 RAID 카드는 배터리 백업 장치 (BBU, Battery Backup Unit)를 제공하므로이 기능을 안전하게 켤 수 있습니다.
Write Back이 활성화되지 않은 경우 RAID 카드 설정에 Write Through가 표시되어 쓰기를 버퍼링하지 않으므로 쓰기 성능이 저하 될 수 있지만 가장 안전한 쓰기입니다.
Write Back이 켜져 있어도 RAID 카드는 Write Through를 활성화 할 수 있습니다. Write Back의 안전한 사용을위한 전제 조건은 RAID 카드에 배터리 백업 장치가 있어야합니다. 배터리의 유효성을 확인하기 위해 RAID 카드는 배터리 상태를 정기적으로 유지하고 배터리가 부족할 때 충전하십시오. 충전 중에는 Write Back 기능이 가장 안전한 Write Through로 전환됩니다.
20W 데이터를 데이터베이스에 삽입하여 (20W 트랜잭션을 통해) Write Back과 Write Through 간의 성능 차이를 테스트합니다
. Write Through 모드에서 매개 변수 innodb_flush_log_at_trx_commit을 0으로 설정하여 성능을 향상시킬 수도 있습니다. 이때 redo 로그 쓰기는 다음과 같습니다. not 각 트랜잭션이 제출 될 때 백그라운드 마스터 스레드가 매초마다 자동으로 새로 고쳐지면 물리 디스크 쓰기 요청이 줄어들고 실행 속도가 향상됩니다.
RAID 카드는 서버가 시작될 때 다양한 설정을 위해 BIOS와 유사한 구성 인터페이스로 들어갈 수 있습니다. 많은 제조업체는 RAID 카드를 구성하기 위해 다양한 운영 체제에서 소프트웨어를 개발했습니다.
다양한 파일 시스템은 성능 차이가 거의 없지만 제공하는 기능에주의가 필요합니다. 예를 들어 ZFS는 스냅 샷을 지원할 수 있으므로 LVM 스냅 샷이 필요하지 않습니다.
벤치 마크 테스트 도구는 튜닝 후 데이터베이스 또는 운영 체제의 성능을 비교하는 데 사용할 수 있습니다. MySQL 자체에서 제공하는 우수한 도구 외에도 더 좋고 일반적으로 사용되는 sysbench 및 mysql-tpcc도 있습니다.
sysbench는 주로 다음 테스트 방법을 포함하는 모듈 식 크로스 플랫폼 다중 스레드 벤치 마크 테스트 도구입니다. 1.
CPU 성능.
2. 디스크 IO 성능.
3. 스케줄러 성능.
4. 메모리 할당 및 전송 속도.
5. POSIX 스레드 성능.
6. 데이터베이스 OLTP 벤치 마크 테스트.
TPC (Transaction Processing Performance Council)는 대규모 데이터베이스 시스템의 소프트웨어 및 하드웨어 성능을 평가하는 비영리 조직입니다. TPC-C는 일반적인 복잡한 OLTP 시스템 (일반적으로 학계 및 산업에서 사용됨)의 성능을 테스트하기 위해 TPC Association에서 공식화합니다.
TPC-C는 3NF (Third Normal Form)를 사용하여 9 개의 기본 관계를 포함하여 창고 판매 공급 업체를 시뮬레이션합니다.
TPC-C 성능 측정 단위는 tpmC (분당 트랜잭션, C는 TPC C 벤치 마크 테스트를 나타냄)이며 값이 더 큽니다. , 트랜잭션 처리 성능이 높아집니다.
tpcc-mysql은 TPC-C 표준을 완전히 준수하는 오픈 소스 TPC-C 테스트 도구입니다.