둘 다 사용경험은 있는데, 사용 경험상으로는 큰 차이가 있다고 보기는 어려웠다. 구글링을 통해 차이를 찾아보면 좋지않을까 하여 이곳 저곳 뒤져보았고, 같은 관계형 데이터베이스(RDBMS)로서 어떤 차이가 있는 것인지 정리해보려 한다! 👨💻
0. 소프트웨어는 버전이 몇 인지가 중요하다.
항상 느끼지만 소프트웨어는 계속 발전하고, 부족한 부분들이 보완 업그레이드되는 방향으로 흘러간다. 그래서 이전에는 단점이었던 부분들이 업그레이드를 통해서 좋아지는 경우가 많다. MySQL의 경우에는 2020년 8.0 버전업을 하면서 이전에는 단점이라 꼽던 많은 부분들이 개선이 되었다. (그만큼 하위 호환이 안 되는게 많다고 한다.) 그 부분들은 고려해서 차이를 찾아볼 필요가 있다. 다른 블로그들의 비교 글들이 이 부분을 간과하고 작성되거나, 2020년 이전의 포스팅한 글이라 명확한 비교가 아닌 것들이 많았다.
1. MySQL 은 PostgreSQL보다 인기가 많다.
성능이 좋았기 때문에 인기가 많은 건지, 인기가 많다보니 인기가 많은 건지는 알 수 없지만, 현 시점 가장 유명하고, 가장 많이 쓰는 RDBMS는 MySQL이다. 그래서 커뮤니티도 잘 발달되어 있고, 이곳 저곳 구글링 해보기도 쉽다. 그 자체가 가장 큰 장점이자, 가장 큰 특징이 아닐까 싶다. 국내에서 PostgreSQL은 MySQL 비해서는 인기가 없고 쓰는 기업이 그렇게 많지는 않지만, 세계적으로 보았을때는 꽤 많이 치고 올라오는 상태이다. (물론 그래도 MySQL이 높다)
2. MySQL 은 8.0버전으로 PostgreSQL와의 차이를 극복을 많이 했다.
MySQL는 5.6, 5.7, 8.0 버전을 현재 제공중에 있다. 특히, 8.0 버전은 2020년 8월 30일 출시로 현재 글작성 기준으로 1년도 채 안된 신규버전이다. 안정화를 위해 패치 버전이 엄청나게 나오는 것으로 보인다. 8.0의 핵심은 이전 버전에 비해 속도도 매우 개선되었을 뿐만 아니라, 다른 RDBMS가 가지고 있는 많은 기능들은 탑재해서 출시되었다. MySQL 대비 PostgreSQL의 장점이라고 할 수 있었던 With쿼리(병렬쿼리, CTE, Common Table Expressions), Window Function 뿐만 아니라, Join 방법이 단순 중첩루프밖에 되지 않는다는 MySQL 단점을 보완하고자, Hash Join 까지 가능하게 업그레이드가 되었다. (Sort Merge Join은 아직 구현이 안 된 것으로 확인된다) 그 밖에도 정말 많은 부분들이 개선되었는데, 그러한 점이 PostgreSQL과 비교하여 단점이라고 했던 부분들이 많이 보완한 것으로 보인다.
PostgreSQL vs MySQL join 처리방법라는 포스팅을 참고하면, MySQL 5.7까지는 PostgreSQL이 JOIN에서 성능우위가 있었지만, 8.0으로 버전 업된 이상 장담할 수 없다.
PostgreSQL도 부지런히 버전업을 하고 있는데, 포커스가 다양한 INDEX 방식 (BRIN, GIST 등)과 좀 더 깊이 있는 기능들에 대한 업그레이드를 주로 진행하고 있기에, 좀 더 복잡하고, 많은 기능을 가진, 전문적으로 활용가능한 RDBMS의 방향으로 나아가고 있다고 보인다.
3. PostgreSQL은 MVCC이고, MySQL은 아니다.
물론 세세하게 기능적 차이가 존재하겠지만, 결국 가장 큰 차이는 MVCC(다중 버전 동시성 제어)에 있다고 본다. 내가 이해한 바로는 postgreSQL은 MySQL과 달리 데이터 행마다 git 처럼 버전관리가 진행되고 있다. 그래서 가지는 이 점은 동시성 제어에 있어 성능우위를 가진다. MySQL은 로킹(Lock)을 통해 동시성을 제어하지만, postgreSQL은 동시에 데이터 작업이 진행되더라도 일단 모든 동작을 기록해두고 가장 마지막 작업 결과가 최종 값으로 인지하게 하는 것이다. 또 다른 장점은 로킹에 의해 병목이 생기지 않기 때문에 postreSQL이 속도 우위를 가진다는 점이다. 단, 단점은 Update 시 과거 행을 삭제하고, 변경된 데이터를 가진 행을 추가해야 하기에 MySQL보다 성능이 좋지 않고, postgreSQL은 버전 관리 중인 데이터들 중 필요없는 데이터들을 날리는 Vacuum 작업이 주기적으로 필요하다. (Vacuum에 대한 내용은 PostgreSQL: 베큠(VACUUM)을 실행해야되는 이유 그리고 성능 향상 포스팅을 참고하면 좋을 것 같다)
=> 22/04/23 추가내용 - Postresql만 mvcc라고 하기엔 정확한 내용이 아니라고 판단했다. 둘다 mvcc이지만, mvcc의 방법이 달라 postgresql만 vacuum을 하는것이다. 또, postgresql 은 mvcc, mysql은 lock 으로 동시성 제어를 하는게 아니라 두 db 모두 mvcc와 lock 둘다 적절하게 트랜잭션 격리수준에 따라 활용하여 동시성 제어를 하고 있다. 명확한 차이라고 볼 수 있는 부분은 postgresql의 디폴트 격리수준은 Read Committed이고, mysql의 디폴트 격리수준은 Repeatable Read 수준이라는 차이이다.
mysql이 좀 더 높은 고립수준을 가져 일관성 있는 데이터를 가져올 확률이 높다. 직접 쓴 아래의 글들을 참고하여 위와 관련된 지식을 보완하면 좋을 것 같다.
- [DB] 트랜잭션 격리수준과 부정합 이슈 (feat. Dirty Read ~ Phantom Read)
- [DB] MVCC (feat. RDBMS 동시성 제어)
4. 마무리
이것저것 구글링 해보고 위와 같이 정리도 해보았지만 그럼에도 불구하고 프로덕션 급에서 정말 큰 차이를 느낄 수 있을까 의문이 든다. Uber는 2016년에 postgreSQL을 쓰다가 MySQL로 마이그레이션했다고는 해서 우버 기술 블로그에 이유를 좀 찾아보기는 했는데, 좀 더 깊이 있는 영역으로 보여 이해하기는 어려웠다. Uber 외에는 마이그레이션했다고 들어본 케이스가 없는 것 같긴한데, 여튼 RDBMS는 나날이 발전할 것이고, 각 기업에 맞게 열심히 DEVELOP 시키면 되지 않을까 싶다. 차이는 물론 있겠지만 결국 관계형 데이터베이스의 본질은 변하지 않을테니까...
※ 참고한 블로그 포스팅
'Googling > postgresql' 카테고리의 다른 글
| [postgreSQL] shared_buffers (feat. 권장하는 값, Aurora-vs-RDS, ScaleUp) (0) | 2022.06.08 |
|---|---|
| [postgreSQL] 써보니 유용한 쿼리 (feat. 메타 정보 쿼리) (0) | 2022.02.22 |
| [postgreSQL] 카운트 쿼리 쓸 때 알아두면 좋은 것 (null, limit) (0) | 2021.08.02 |
| [postgreSQL] 재귀쿼리 만들기 (Recursive) ( + 매우 주의해야하는 케이스 : 무한루프) (2) | 2021.08.01 |
| [postgreSQL] 인덱스의 성능을 위하여 알아둘 것. 카디널리티 (0) | 2021.05.26 |
