공유글 / Why Uber Engineering Switched from Postgres to MySQ

postgreSQL의 FDW(Foreign Data Wrappers)를 살펴보다가 postgreSQL이 mysql에 비해서 제공되는 기능들이 훨씬 많은걸 알게되었습니다. 그런데 이 좋은걸 왜 다들 안쓰고 아직 mysql을 사용하는지 궁금해서 찾다가 비교해볼만한 블로그를 찾아서 공유해드립니다~

이 포스트는 2016년도에 Postgres 9.2버전(현재는 15) 때 작성된것으로 mysql과 postgreSQL의 차이점에 대한 이해를 돕는 목적으로 읽기에 적당한 글인것 같습니다.

Why Uber Engineering Switched from Postgres to MySQ
https://www.uber.com/en-KR/blog/postgres-to-mysql-migration/

요약:
1. 한 행의 데이터 하나를 수정할 경우 mysql이 postgres보다 빠르다.
2. 복제 기능을 mysql이 더 많이 지원한다.
3. 데이터 변경 중 데이터 손상이 생기면 postres의 b-tree 구조에서는 복원하기가 쉽지 않다.
4. DR구성할 경우 Replication 과정에서 비용이 많이 발생할 수 있다.
5. 등등..

Cascading replication limits the inter–data center bandwidth requirements to the amount of replication required between just the master and a single replica, even if there are many replicas in the second data center. However, the verbosity of the Postgres replication protocol can still cause an overwhelming amount of data for a database that uses a lot of indexes. Purchasing very high bandwidth cross-country links is expensive, and even in cases where money is not an issue it’s simply not possible to get a cross-country networking link with the same bandwidth as a local interconnect. This bandwidth problem also caused issues for us with WAL archival. In addition to sending all of the WAL updates from West Coast to East Coast, we archived all WALs to a file storage web service, both for extra assurance that we could restore data in the event of a disaster and so that archived WALs could bring up new replicas from database snapshots. During peak traffic early on, our bandwidth to the storage web service simply wasn’t fast enough to keep up with the rate at which WALs were being written to it.