왜 동네짱은 PostgreSQL에서 MySQL 으로 데이터베이스를 마이그레이션?

이전글

https://mysqlko.wordpress.com/2016/08/05/mysql-vs-postgresql-uber

 

97d37ea1d4a07355a3be45d80001e985
우석고 실질적 짱 : 현상태

Why Uber migrated its databases from Postgres to MySQL?

http://blog.webyog.com/uber-migrated-databases-postgres-mysql

 

Uber 사태?! 에 대한 PostgreSQL 진영!?의 글에 이어서 MySQL 진영?! 글이 올라 왔습니다.

webyog 란?!

SQLyog : MySQL GUI & Admin  과 MONyog : MySQL Monitor 를 만드는 회사입니다. SQLyog Community 버전도 있습니다.

https://www.webyog.com/product/downloads/

PostgreSQL 제한?! 한계?!

  1. Inefficient architecture for writes: A relational database must perform certain key tasks that Postgres were not suited for Uber’s needs.
    • Providing efficient insert/update/delete capabilities
    • Providing capabilities for making schema changes
    • Implementing a MVCC mechanism so that different connections have a transactional view of the data they work with.

  1. 비효율적인 쓰기 구조?! : 우버는 다음과 같은 RDBMS 요건을 필요로 한다. 그러나, PostgreSQL 은…
  • INSERT/UPDATE/DELETE 가 효율적이야 한다. / OLTP 성능이 좋아 한다.
  • 스키마 변경이 되어야 한다. / ALTER 구문이 효율적이야 한다.
  • 서로 다른 연결에 대해서 트랜잭션날 관점에서의 MVCC 메카니즘 구현이 필요하다. / CTID ( OID, RID  동일 ) 값이 물리적 오프셋값(green) 으로 되어 있어서 비효율적이다. CTID 값이 변경시 모든 index 가 변경되어 한다.

With Postgres, the primary index and secondary indexes all point directly to the on-disk tuple offsets. When a tuple location changes, all indexes must be updated.

  • Inefficient data replication: Postgres’ replication required higher bandwidth as compared to MySQL but Postgres replication may not be a problem within a single data center. The real problem with Postgres arises when replication is done between multiple data centers.
  • 비효율적인 데이터 리플리케이션 : PostgreSQL Replication 은 MySQL 대비해서 높은 대역폭(bandwidth) 을 요구하다. 그러나, PostgreSQL Replication 은 데이터센터 내에서는 문제가 되지 않는다. / DC-to-DC 간에는 문제가 될 수 있다?!

  • Issues with table corruption: During one of Uber’s routine master database promotion to increase database capacity, they encountered a Postgres 9.2 bug. This resulted in numerous incorrect timeline switches on replicas that were being undertaken.
  • 테이블 손상 이슈 : 마스터 서버중 하나가 과도한 용량 증가 버그가 PostgreSQL 9.2 에서 있었다. 이 버그는 복제에까지 수많은 영향을 미쳤다. / 마스터서버의 버그가 슬레이브까지 영향을 미쳤다.

  • Poor replica MVCC support: Postgres does not have true replica MVCC support. The fact that replicas apply WAL updates results in having a copy of on-disk data identical to the master at any given point in time.
  • 가난한 리플리카?! MVCC 지원 : PostgreSQL 은 레알 리플리카 MVCC 를 지원하지 않는다. 실제로, 리플리카는 WAL 업데이트가 디스크에 쓰여진 복사본을 가진 시점에서 동일하게 적용된다. / WAL 로그가 디스크에 반영된 후에 복사본을 가지고 이루어지다 보니, 성능이 좋지 않다.

  • Difficulty upgrading to newer releases: With different general available releases of Postgres, it was not possible to replicate the data. Replication records work at the physical level which made it difficult for Uber.
  • 새로운 릴리즈 업그레이드 어려움 : PostgreSQL 은 GA 릴리즈 버전간의 데이터 리플리케이션이 가능하지 않다. 물리적 레벌에서 복제는 우Uber 를 힘들게 했다. / 이중화 구성시 한쪽만 순차적 업그레이드가 불가능하다. downtime 이 불가결하다?!

구글번역기 감사합니다!! ㅠㅠ

이에 반해서 MySQL 은… 생략?!

결국 Uber 가 PostgreSQL 에서 MySQL 로 바꾼 이유는 크게 보면 2가지 입니다.

성능 (Performance)  and 운영, 가용성 ( High Availability, Replication )

예전부터 OLTP : MySQL , OLAP : PostgreSQL 이란 선입견이 일반적이었습니다. 많은 글로벌 서비스가 메인DBMS 를 MySQL 을 채용하고 있는데, 그 이유 중 하나는 글로벌 서비스 자체가 OLTP : high short-request 이기 때문입니다. 거기에, PostgreSQL 이 WAL( Physical Log  ) Replication 을 default 로 하고 있다보니, 그로 인해서 Master-Slave upgrade ( downtime ), Master- Slave incorrect, Replication Performance 등이 뒤따서 이슈가 된 것 같습니다.

결국 Uber 와 같은 글로벌 서비스에서는 운영관리가 편한 자알~ 알려진 Open Source 기반의 OLTP DBMS 가 적합했던 것 같습니다.

PostgreSQL 은 Logical Log Replication 을 지원합니다. 향후에는 default 가 되지 않을까!? 라고 생각됩니다. 그리고, INSERT/UPDATE/DELETE 성능에 대해서는 PostgreSQL 9.x 부터는 성능 이슈에 대해서 EDB 가 크게 기여하고 있기 때문에, 향후 버전업에 따라서 많은 개선이 있으리라 봅니다. 그리고, PostgreSQL 9.6 GA 에는 Parallel Query 가 지원된다면 많은 개선이 되리라 봅니다.

추가적으로, 드루팔 7.x 성능 비교 자료를 보시면 PostgreSQL vs MySQL 성향차이를 이해하는데 도움이 되리라 봅니다.

Comparing PostgreSQL 9.1 vs. MySQL 5.6 using Drupal 7.x

http://posulliv.github.io/2012/06/29/mysql-postgres-bench/

 

Advertisements

MySQL vs PostgreSQL, 뭣이 중헌디 뭣이!?

뭣이 중한지도 모르면서…

image

최근에 이슈가 되고 있는 Uber 사태!?를 아십니까!?

Why Uber Engineering switched from Postgres TO MySQL by Evan Klitzke, 06.26.2016

이전부터 낌새는… ㅠㅠ

Designing Schemaless, Uber Engineering’s  Scalable Datastore Using MySQL BY Jakob Holdgaard Thomsen, 01.12.2016

그런데, 예전에는…

Migrating Uber from MySQL to PostgreSQL by Evan Klitzke, 03.13.2013

MySQL 의 경우는 Google, Twitter, Facebook, … 등 누구나 알만한 글로벌 서비스에서 RDBMS 로 사용되고 있습니다. 2014년에는 MySQL 5.6 Branch 에서 WebScaleSQL 로 fork 하였습니다. 작년에는 Alribaba 도 참여하였습니다.

그에 반해서 PostgreSQL 은 딱히 떠오르는 서비스와 기업이 없습니다. Yahoo, MySpace, Skype 등이 사용한다고 하지만, 공개된 내용들도 별로 없고, MySQL 대비해서는 서비스 및 기업들이 핫하지 못합니다.

거기에 광명같은 존재가 Uber 였는데 최근에 MySQL Migration – Engineering blog 에 장문의 디스같은 디스같지 않은 글을 올려서 Y’s Hacker News 와 PostgreSQL Community 에도 글이 올라 왔습니다.

PostgreSQL 를 리딩하는 2개의 회사의 글도 올라왔습니다. 조금 늦게 올라온 감이 있습니다.

2ndQuadrant’s Simon Riggs

EDB’s Robert Haas

영어가 짧은지라… 대충 훑어봤습니다.

Uber 의 지적질은  디테일합니다. 그리고, 대부분 불편한 진실!?입니다. 그에 반해서 EDB 와 2ndQuadrant 의 항변?!은 딱히 와닿지 않습니다. ㅠㅠ

여기서 맹점은…

We encountered many Postgres limitations:

  • Inefficient architecture for writes
  • Inefficient data replication
  • Issues with table corruption
  • Poor replica MVCC support
  • Difficulty upgrading to newer releases

요약하면…

  1. performance
  2. replication ( shard )

2가지 항목에 대해서 반박글들은 어느 정도 타당하고, 반납득이 가는 내용들입니다. 그러나, 근본적으로 이슈(문제) 자체의 해결책을 제시한 것은 아닌 듯 합니다. 명확하게 더 빠르다라고 주장은 안하고 있습니다. 역시 성능에 관해서는 한풀 접고 들어갑니다.

조금은 지난 글이지만, PostgreSQL vs MySQL 성능이슈에 대한 좋은 블로깅이라고 생각합니다.

추가적으로 비교한다면…

  • PostgreSQL vs MySQL
  • Strict RDBMS vs Non-Strict RDBMS
  • MultiProcessing vs MultiThreading
  • Buffered IO vs Direct IO
  • Logical Replication vs Physical Replication

결론은?!

OLTP is…
MySQL > PostgreSQL

OLAP is…
MySQL < PostgreSQL

슬라이드4

Uber is …

“The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL. In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL.” (Thanks to Dimitri John Ledkov)

 

이 이슈는 MySQL 10.x vs PostgreSQL 10.x 에서 다시 논의해야 할 필요가 있습니다. PostgreSQL 9.6 부터는 Parallel Query 가 지원됩니다. 그래도, insert/update 성능은 크게 달라지지 않으리라 봅니다. ^^;

 

Ref :

중국이 무섭다?! ㅠㅠ

https://yq.aliyun.com/articles/58421

luke 요약글

http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases