
본 포스트는 Real MySQL 8.0 1권을 읽은 뒤 정리하는 글입니다.
MySQL은 1979년 스웨덴의 TcX 회사의 터미널 인터페이스 라이브러리인 UNIREG로부터 시작했다. 이전에는 TcX 사내에서 사용되다가 1996년 일반인에게 공개되었다.
2006년에 현재와 같은 두 가지 라이선스 정책을 취하게 된다.
오라클이 인수한 이후 MySQL 서버의 소스코드 레벨부터 리팩토링을 시작하였고, 이후 안정성과 성능 개선에 집중하였으며 MySQL 8.0 버전부터는 상용 DBMS가 가지고 있는 기능들이 장착되기 시작하였다.
가격, 비용
자기가 가장 잘 활용할 수 있는 DBMS가 가장 좋은 DBMS, 이에 대해 명확한 확신이 없다면 아래와 같은 순서로 고려할 수 있다.
해당 챕터를 읽게 되며 내가 프로젝트에서 MySQL을 사용한 이유를 정리하고자 하였으나, 책에서는 특정 DBMS와의 기능, 성능 측면에서의 구체적인 비교보다는 DBMS를 선택할 때 고려해야 할 기준을 제시하고 있어 비용적인 측면 외에 특출난 장점에 대해서는 알 수 없었다.
따라서 같은 DBMS 중 주로 비교되는 PostgreSQL과의 차이를 따로 찾아보았다.
| PostgreSQL | MySQL | |
|---|---|---|
![]() | ![]() | |
| 데이터 유형 | 객체 관계형 데이터베이스(ORDBMS) | 관계형 데이터베이스(RDBMS) |
| ACID | 모든 구성에서 ACID와 완벽하게 호환 | InnoDB 및 NDB 클러스터 스토리지 엔진 또는 소프트웨어 모듈과 함께 사용하는 경우에만 ACID 규정 준수 |
| 동시성 제어(MVCC) | 대모든 구성에서 MVCC를 지원 | InnoDB 스토리지 엔진을 사용하면 MVCC가 완벽하게 지원, MyISAM 스토리지 엔진에서 지원 X |
| 인덱스 | 트리, 표현식 인덱스, 부분 인덱스 및 해시 인덱스를 포함. 크기를 확장할 때 데이터베이스 성능 요구 사항을 세밀하게 조정할 수 있는 더 많은 옵션 존재 | 계층적으로 인덱싱된 데이터를 저장하는 B-트리 및 R-트리 인덱싱을 지원 |
| 러닝커브 | 초보자에게는 PostgreSQL이 훨씬 더 어려울 수 있음. 복잡한 인프라 설정 및 문제 해결 경험이 필요 | 초보자에게 더 적합하며 학습 기간이 짧음 |
| 성능 요구 사항 | 잦은 데이터 업데이트가 필요한 경우 적합 | 데이터를 자주 읽어야 하는 경우 적합 |
| 읽기 성능 | 데이터베이스에 연결된 모든 사용자에 대해 상당한 메모리 할당량(약 10MB)을 포함하는 새로운 시스템 프로세스를 생성, 여러 사용자를 위해 확장하려면 메모리 집약적 리소스가 필요 | 여러 사용자를 위해 단일 프로세스를 사용 |
| 쓰기 성능 | 읽기-쓰기 잠금이 없는 다중 버전 동시성 제어(MVCC) 지원이 내장. 쓰기 작업이 빈번하고 동시에 수행되는 경우 PostgreSQL 데이터베이스이가 더 잘 작동함 | 쓰기 잠금을 사용하여 실제 동시성을 구현 |
| 애플리케이션 범위 | 쓰기 작업이 빈번하고 쿼리가 복잡한 엔터프라이즈급 애플리케이션에 더 적합 | 프로토타입을 만들거나, 사용자 수가 적은 내부 애플리케이션을 만들거나, 읽기 횟수가 많고 데이터 업데이트가 자주 이루어지지 않는 정보 스토리지 엔진을 만들고 싶은 경우 적합 |
위 차이점을 통해, 내 프로젝트에서 MySQL을 사용한 이유를 아래와 같이 정리할 수 있을 것 같다.
현재 진행 중인 프로젝트는 사이드 프로젝트 규모의 웹 서비스로, 복잡한 분석 쿼리나 대규모 동시 쓰기보다는 읽기 작업의 비중이 높다.
이러한 특성상 읽기 성능에 강점을 가지는 MySQL이 프로젝트의 성격과 요구사항에 더 적합하다고 생각했다.또한 MySQL은 러닝 커브가 낮고, Spring Boot + JPA 환경에서의 레퍼런스와 운영 사례가 풍부해 개발과 운영 모두에서 안정적인 선택이라고 판단했다.