10.1 Optimization Overview

10.1 Optimization Overview

데이터베이스 성능은 테이블, 쿼리, 구성 설정과 같은 데이터베이스 수준의 여러 요인에 따라 달라집니다. 이러한 소프트웨어 구성 요소들은 하드웨어 수준에서 CPU 및 I/O 연산을 발생시키며, 이들을 가능한 한 최소화하고 효율적으로 만드는 것이 중요합니다. 데이터베이스 성능을 개선하는 작업을 할 때에는 먼저 소프트웨어 측면에 대한 상위 수준의 규칙과 지침을 익히고, 벽시계 시간을 사용하여 성능을 측정하는 것에서 시작합니다.

전문가가 되어 갈수록 내부에서 어떤 일이 일어나는지 더 많이 이해하게 되고, CPU 사이클이나 I/O 연산과 같은 것들을 측정하기 시작합니다.

일반적인 사용자는 기존 소프트웨어 및 하드웨어 구성을 사용하여 가능한 최고의 데이터베이스 성능을 얻는 것을 목표로 합니다. 고급 사용자는 MySQL 소프트웨어 자체를 개선할 기회를 찾거나, 자체 스토리지 엔진과 하드웨어 어플라이언스를 개발하여 MySQL 에코시스템을 확장하려고 합니다.

• Optimizing at the Database Level

• Optimizing at the Hardware Level

• Balancing Portability and Performance

Optimizing at the Database Level

데이터베이스 애플리케이션을 빠르게 만드는 데 가장 중요한 요소는 그 기본 설계입니다:

• 테이블이 올바르게 구조화되어 있습니까? 특히, 컬럼이 올바른 데이터 타입을 가지고 있으며, 각 테이블이 해당 작업 유형에 적합한 컬럼을 가지고 있습니까? 예를 들어, 빈번한 업데이트를 수행하는 애플리케이션은 보통 컬럼이 적은 테이블을 많이 가지고 있는 반면, 대량의 데이터를 분석하는 애플리케이션은 보통 컬럼이 많은 소수의 테이블을 가집니다.

• 쿼리를 효율적으로 만들기 위해 적절한 index가 설정되어 있습니까?

• 각 테이블에 적절한 스토리지 엔진을 사용하고 있으며, 사용하는 각 스토리지 엔진의 강점과 기능을 활용하고 있습니까? 특히, InnoDB 와 같은 트랜잭션 스토리지 엔진을 선택하느냐, MyISAM 과 같은 비트랜잭션 스토리지 엔진을 선택하느냐는 성능과 확장성에 매우 중요할 수 있습니다.

참고

InnoDB는 새 테이블의 기본 스토리지 엔진입니다. 실제로 고급 InnoDB 성능 기능 덕분에, InnoDB 테이블이 특히 busy한 데이터베이스에서 더 단순한 MyISAM 테이블보다 더 나은 성능을 보이는 경우가 많습니다.

• 각 테이블은 적절한 로우 포맷을 사용하고 있습니까? 이 선택은 테이블에 사용된 스토리지 엔진에 따라 달라지기도 합니다. 특히, 압축된 테이블은 더 적은 디스크 공간을 사용하므로, 데이터를 읽고 쓰는 데 필요한 디스크 I/O가 줄어듭니다. InnoDB 테이블에서는 모든 종류의 워크로드에 대해 압축을 사용할 수 있으며, 읽기 전용 MyISAM 테이블에서도 압축을 사용할 수 있습니다.

• 애플리케이션은 적절한 locking strategy를 사용하고 있습니까? 예를 들어, 가능한 경우 공유 액세스를 허용하여 데이터베이스 연산이 동시에 실행될 수 있도록 하고, 적절한 경우 배타적 액세스를 요청하여 중요한 연산이 최우선 순위를 갖도록 해야 합니다. 여기서도 스토리지 엔진의 선택이 중요합니다. InnoDB 스토리지 엔진은 대부분의 잠금 문제를 사용자의 개입 없이 처리하여, 데이터베이스에서 더 나은 동시성을 제공하고 코드에 대한 실험과 튜닝의 양을 줄여 줍니다.

• 캐싱에 사용되는 모든 메모리 영역의 크기가 적절하게 설정되어 있습니까? 즉, 자주 접근되는 데이터를 담을 수 있을 만큼 충분히 크되, 물리적 메모리를 과부하시켜 페이징을 유발할 정도로 크지는 않아야 합니다. 구성해야 하는 주요 메모리 영역은 InnoDB 버퍼 풀과 MyISAM 키 캐시입니다.

Optimizing at the Hardware Level

데이터베이스가 점점 더 busy해짐에 따라, 어떤 데이터베이스 애플리케이션도 결국 하드웨어 한계에 도달하게 됩니다. DBA는 애플리케이션을 튜닝하거나 서버를 재구성하여 이러한 bottleneck을 회피할 수 있는지, 아니면 더 많은 하드웨어 자원이 필요한지를 평가해야 합니다. 시스템 병목 현상은 일반적으로 다음과 같은 원인에서 발생합니다:

• 디스크 시크. 디스크가 특정 데이터 조각을 찾는 데 시간이 걸립니다. 최신 디스크에서는 평균 시간이 보통 10ms 미만이므로, 이론적으로는 초당 약 100 시크를 수행할 수 있습니다. 이 시간은 새로운 디스크에서도 서서히만 개선되며, 단일 테이블에 대해 최적화하기는 매우 어렵습니다. 시크 시간을 최적화하는 방법은 데이터를 둘 이상의 디스크에 분산하는 것입니다.

• 디스크 읽기 및 쓰기. 디스크가 올바른 위치에 도달하면, 데이터를 읽거나 써야 합니다. 최신 디스크의 경우, 하나의 디스크는 최소 10–20MB/s의 처리량을 제공합니다. 이는 여러 디스크에서 병렬로 읽을 수 있기 때문에, 시크보다 최적화하기가 더 쉽습니다.

• CPU 사이클. 데이터가 메인 메모리에 있으면, 결과를 얻기 위해 이를 처리해야 합니다. 메모리에 비해 테이블이 매우 큰 경우가 가장 일반적인 제한 요소입니다. 그러나 테이블이 작은 경우에는 속도가 보통 문제가 되지 않습니다.

• 메모리 대역폭. CPU 캐시에 담을 수 있는 것보다 더 많은 데이터를 CPU가 필요로 할 때, 메인 메모리 대역폭이 병목 지점이 됩니다. 이는 대부분의 시스템에서 흔하지 않은 병목이지만, 인지하고 있어야 할 요소입니다.

Balancing Portability and Performance

이식 가능한 MySQL 프로그램에서 성능 지향적인 SQL 확장을 사용하기 위해, statement 내에서 MySQL 고유의 keyword를 /*! */ 주석 구분자로 감쌀 수 있습니다. 다른 SQL 서버는 이 주석 처리된 keyword를 무시합니다. 주석 작성에 대한 정보는 Section 11.7, “Comments”를 참조하십시오.