프로젝트에 MySQL을 사용하려고 버전을 확인해 봤다.
8.0을 사용하려고 하는데, 회사에서 사용했던 버전은 5버전대 였다.
8.0과 다른 버전들은 어떤 차이가 있는지 알아보자!
5.x 버전과 8.x 버전
MySQL 5.5~5.7 버전에서는 안정성과 성능 개선에 집중했다면, MySQL 8.0 버전으로의 업그레이드는 상용 DBMS가 가지고 있는 기능들을 장착하는 시기였다.
또한 8.0 버전으로 업그레이드하면서 몇몇 기능들이 향상되었다.
개선된 점
읽기 전용에서 I/O Bound
내림차순 인덱스를 지원하면서 I/O Bound 읽기 성능에서 크게 향상되었다. (I/O Bound에 의한 처리량 제한을 개선했다.)
I/O Bound
계산을 완료하는 데 걸리는 시간이 입출력 작업 시간에 의해 결정되는 조건
개선되는 하드웨어
랜덤으로 읽는 상황에서는 미리 캐시 하거나 프리 패치할 수 없기 때문에 HDD rotation penalty를 가하고 있다.
지금은 플래시 스토리지 덕에 이 문제를 어느 정도 해결할 수 있다.
rotation penalty
하드 디스크가 회전할 수 있는 RPM이 높을수록 비트 전송률이 높아지기 때문에 디스크에서 더 빨리 읽고 쓸 수 있다. 회전에 페널티가 생긴다는 것은 부하로 인해 읽고 쓰는 성능이 떨어지는 것을 의미한다.
압축과 페이지 분할
압축을 통해 페이지 크기를 줄여 처리량 한계에 쉽게 도달하지 않는다. 이로 인해 I/O 연산을 적게 수행할 수는 있지만, 실질적인 QPS 성능 향상은 얻을 수 없다.
전체 InnoDB 인스턴스의 페이지 크기를 4KB로 고정한다면 I/O 처리량 수준 내에서 4배 더 많이 읽고, 4배 더 많이 처리할 수 있는 방식을 고안해 QPS를 획기적으로 개선할 수 있다.
InnoDB
MySQL에서 사용하는 데이터베이스 엔진
QPS (Query per second)
MySQL Server가 초당 실행하는 Query의 총량
제한 삭제
압축과 분할을 활용한 방식은 InnoDB의 모든 I/O 작업이 global lock(file_system_mutex)로 인해 I/O 속도가 제한되기 때문에 부분적으로 사용할 수 있었지만, MySQL 8.0 이후 제한이 사라졌다.
즉, 8.0 버전에서는 압축과 분할을 통해 4배 더 많이 읽고, 4배 더 많이 처리할 수 있는 방식을 고안해서 QPS를 획기적으로 개선할 수 있다.
Reqd-Write에서 OLTP_RW/Update-NoKEY
OLTP_RW와 Update-NoKEY를 기준으로 성능을 측정한다.
즉, 트랜잭션이 발생하는 상황에서 키를 건들지 않고 테스트를 한다는 의미이다.
- OLTP_RO 성능 비교
MySQL 5.6 버전이면 업그레이드를 고려해야겠지만, 아니라면 큰 성능 차이는 발생하지 않는다.
OLTP_RO : Online Transaction Proccessiong_Read Only
- OLTP_RW 성능 비교
테스트 단위는 OLTP_RO 쿼리 + 2*UPDATE 쿼리 + DELETE 쿼리 + INSERT 쿼리로 진행한다.
OLTP_RW/Update-NoKEY 상황에서 8.0과 5.7 버전 처리량 차이는 최대 5배 차이가 발생한다.
OLTP_RW : Online Transaction Proccessing_Read Write
Update-NoKEY
인덱싱 된 열을 변경하지 않았다고 볼 수 있다.
이중 쓰기 버퍼 활용 - Read_Write에서 I/O Bound
이중 쓰기 버퍼(Double Write Buffer, DBLWR)는 쓰기 페이지가 데이터 파일의 적절할 위치에 페이지를 쓰기 전, 버퍼 풀에 플러시 되는 저장 영역을 의미한다.
디스크 파일로 플러시 할 때 일부만 기록되는 문제가 발생하면 페이지 내용을 복구할 수 없는데, DBLWR을 활용하여 데이터 무결성을 보장한다.
DBLWR은 데이터 무결성을 보장하는 방식이기 때문에 동시성 처리 상황에서는 좋지 않은 성능을 보였지만, MySQL-8.0.20 릴리즈에서 업데이트되었다. 따라서 8.0.19와 8.0.20 버전은 성능 차이가 있다.
MySQL 8.0.19 vs 8.0.20
- I/O 바인딩이 발생하지 않는 경우
동일한 성능을 보장한다. 즉, 페이지의 플러시가 REDO 쓰기를 따라갈 수 있을 만큼 빠르게 진행되면 안전하다.
- I/O 바인딩이 발생하는 경우
페이지 쓰기가 지연되면 I/O 바인딩이 되고, DBLWR의 경우에 I/O 바인딩이 되는 상황에서 성능 효과를 발휘한다.
결과 차이가 발생한 이유는 이전 버전의 DBLWR 디자인이 높은 동시성을 위해 만들어지지 않았기 때문이다.
결과적으로 메모리 크기에 따라 TPS 영향을 받게 되지만, 8.0.20에서 개선된 DBLWR을 활용해 성능 저하를 막을 수 있다.
TPS (Transaction per Second)
1초당 처리할 수 있는 트랜잭션의 수
성능 차이 정리
- 8.0 버전은 읽기 연산을 진행하면서 발생하는 I/O Bound 상황에서 QPS를 개선했다.
- OLTP_RO인 상황에서 TPS는 5.7에서 개선됐다.
- 8.0 버전은 OLTP_RW/Update-NoKEY 상황에서 TPS를 개선했다.
- 8.0.20 버전은 DBLWR이 개선되면서 I/O Bound 상황에서 commit 처리 속도를 개선했다.
References
https://www.mysql.com/why-mysql/benchmarks/mysql/
https://myvelop.tistory.com/208