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

Advertisements

Innodb Full-Text Search : Part 1

슬라이드3

 

오늘은 MySQL Server Blog 에 올라온 MySQL FTS ( Full-Text Search ) 에 대해서…

 

FTS ( Full-Text Search ) 란?

https://en.wikipedia.org/wiki/Full_text_search

 

MySQL 5.5 때까지는 MyISAM 만 FTS 를 지원하였지만, MySQL 5.6 부터는 InnoDB 엔진도 지원하고 있습니다.

http://www.drdobbs.com/database/full-text-search-with-innodb/231902587

 

MySQL 5.7.3 부터 CJK ( China, Japan, Korea ) 를 위한 plugin parser in fulltext index 를 지원합니다.

http://mysqlserverteam.com/innodb-supports-plugin-parser-in-fulltext-index/

 

MySQL Server Team Blog 에 올라온 N-gram & MeCab Parser 에 대해서…

 

Category Archives: Full Text Search

http://mysqlserverteam.com/category/full-text-search/

 

InnoDB Full-Text: MeCab Parser ( China )

http://mysqlserverteam.com/innodb-full-text-mecab-parser/

 

InnoDB全文索引:N-gram Parser ( China )

http://mysqlserverteam.com/innodb%E5%85%A8%E6%96%87%E7%B4%A2%E5%BC%95%EF%BC%9An-gram-parser/

 

InnoDB 全文検索 : N-gram Parser ( Japan )

http://mysqlserverteam.com/innodb-%E5%85%A8%E6%96%87%E6%A4%9C%E7%B4%A2-n-gram-parser/

 

InnoDB 全文検索 : MeCab Parser ( Japan )

http://mysqlserverteam.com/innodb-%E5%85%A8%E6%96%87%E6%A4%9C%E7%B4%A2-n-gram-parser/

 

InnoDB 전문 검색 : N-gram Parser ( Korea )

http://mysqlserverteam.com/innodb-%EC%A0%84%EB%AC%B8-%EA%B2%80%EC%83%89-n-gram-parser/

 

 

여기서 잠깐,

N-gram 은 ( n byte or lexim 긴가민가?! ㅠㅠ) 이기 때문에 CJK 문제가 없습니다?! 그런데, MeCab 는 일본어를 위한 엔진인데, Japan 과 Korea 는 어순도 LR 이고, 문법도 비슷한 점이 많아서 엔진과 사전을 조금만 수정해서 쓴다고 하지만, China 는 모르겠습니다. 그리고, 사전도 일본어 IPADIC 를 씁니다?!

우리는 은전한닢이란 MeCab Fork 프로젝트가 있습니다!? 일본이라서 고맙다!? ㅠㅠ

 

Shaohua Wang 란 Oracle China 분인 것 같은데, 아는지 모르는지…

 

“MeCab is a Japanese morphological analyzer, and we now have a full-text plugin parser based on it!”

 

MeCab : Yet Another Part-of-Speech and Morphological Analyzer

http://taku910.github.io/mecab/

http://mecab.googlecode.com/svn/trunk/mecab/doc/feature.html

 

IPADIC

http://parame.mwj.jp/blog/0209

 

은전한닢 프로젝트

http://eunjeon.blogspot.kr/

 

MeCab-Ko-Dic

 

https://bitbucket.org/eunjeon/mecab-ko-dic

 

기타참고

http://d.hatena.ne.jp/studio-m/20091108/1257668762

 

결론은…

N-gram FTS Parser 는 CJK 상관없이 쓰셔도 되지만, MeCAB Parser 는 엄밀히 언어별, 인코딩별 형태소분석기 ( Tokenizer ) + 사전( Dictionary ) 이 필요합니다. 일본과 우리는 문제 없다!? ㅠㅠ

MySQL 5.7.7 에는 기본적으로 libpluginmecab.so 과 ipadic_euc-jp, ipadic_sjis, ipadic_utf-8 이 포함되어 있습니다.

 

MySQL InnoDB is DEAD ?!

슬라이드1

Linkbench for MySQL & MongoDB with a cached database

http://smalldatum.blogspot.kr/2015/07/linkbench-for-mysql-mongodb-with-cached.html

 

Mark Callaghan 옹의 small datum 블로그에 RocksDB, MongoDB 게시글들이 많이 올라오고 있습니다.

언제부터인가 OLTP 에서 MySQL vs PostgreSQL 이 아닌, MySQL vs MongoDB 구도가 되어 버린 탓도 있을거고, MongoDB 가 WireTiger 를 선택해서!? Tim 이 팽당함?! ^^;

RocksDB 는 Facebook 에서 만들고 있는 LevelDB 기반의 key-value storage engine 입니다.

왜 engine 일까요?! MySQL, MongoDB, 등등 engine 을 교체해서 본인들이 원하는 성능과 기능을 추가하고 싶은거겠죠!? 물론 독립적으로도 사용가능합니다. 기능은 모르겠지만, 성능은 좋습니다. LevelDB 기반들의 공통점이죠?!

http://rocksdb.org

 

그런데, 왜 Facebook 은 InnoDB 를 개선하지 않고, RocksDB 를 만들었고, Tokutek 은 TokuDB 를 만들었을까요?!

InnoDB vs TokuDB vs RocksDB

B-Tree, B*Tree, B+Tree 란 자료구조의 근본적인 성능이슈 때문이기도 하고, 스토리지가 spin disk to flash 로 변하는 패러다임에, memory device 의 가격하락, OTLP 부하 증가, 등등으로 인해서 B+Tree 보다는 다른 자료구조를 찾게되었죠. ( HDD to SSD, SSD to MEM 심화때문이죠! )

TokuDB -> fractal tree, RocksDB -> LSM

https://en.wikipedia.org/wiki/Fractal_tree_index

https://en.wikipedia.org/wiki/Log-structured_merge-tree

 

최근에는 InnoDB engine 의 insert 성능, 용량때문에, TokuDB engine 를 혼용해서 사용하는 곳이 많습니다. 그럼에도, Oracle MySQL 5.7 engine list 에 들어가 있지는 않습니다. ( 예전에 InnoDB 범용적으로 많이 쓰임에도 MyISAM 을 제끼고 default engine 으로 되는데 오래 걸리긴 했습니다. ) TokuDB engine 의 안정화 이슈도 있고, 3rd party 와의 호환성, FK 미지원, backup tool 등 많은 이슈가 있긴 합니다.

앞으로 향후에도 Oracle MySQL 은 TokuDB, RocksDB, BlahDB, BlahDB~ 가 나와도 절대로 InnoDB 를 바꾸지 않을겁니다. Oracle 은 SUN 보다 Innobase 를 먼저 인수하였고, 모든건 다 계획대로?!

https://en.wikipedia.org/wiki/Innobase

 

MySQL 은 Oracle 로 인수된 후로 글로벌한 이슈를 못따라가고 있습니다. 아니 안따라가고 있습니다. 물론 enterprise 와 open source 개발은 좀 성격이 달라서 빠르게 따라가기는 힘든 부분이 있긴 합니다. ^^;

향후에도 InnoDB 로 대응하기에는 한계가 있기 때문에 TokuDB, RocksDB, BlahDB, BlahDB~ engine 을 고려된 아키텍처 및 운영이 되어야할 것 같습니다.

 

기승전FB !! 대동단FB !!

Rocks 는 InnoDB 대비해서 insert 성능은 좋으나, TokuDB 보다는 못합니다. 그러나, FB 님이 지속적으로 개선해주시라 보고, 앞으로 어떤 멋진 것들을 내놓으실지 모릅니다?! ( 사실 TokuDB 이 더 앞서나갈 것 같습니다. percona 로 인수 되었기 때문에 MongoDB 미련을 버릴테니… )

용량이슈도 해결되리라 봅니다?!

https://github.com/MySQLOnRocksDB/mysql-5.6/issues/80

Using Cgroups to Limit MySQL and MongoDB, Redis memory usage

슬라이드1

 

PERCONA MYSQL PERFORMANCE BLOG Vadim Tkachenko 님의 게시글 : 

Ref : https://www.percona.com/blog/2015/07/01/using-cgroups-to-limit-mysql-and-mongodb-memory-usage/

 

요즘 많은 솔루션 및 오픈소스 프로젝트들이 In-Memory Processing 이라고 하지만…

실제로 In-Memory Architecture 기반이라고 보기는 힘든 부분이 많습니다. 그 예가 Memory Management 입니다.

MySQL 의 경우에는 my.cnf 를 보시면 대부분의 설정값들은 memory allocate 를 합니다.

innodb_buffer_pool_size + innodb_log_buffer_size + innodb_sort_buffer_size + * _size …

이렇게 할당된 값의 총합 + @ 만큼 메모리가 할당됩니다.

그런데말입니다. 문제는 이 값들이 갈수록 갈수록 늘어난다는 말입니다!! memory fragmentation !!

그래서, cgroup 으로 OS 레벨에서 강제로 limit 를 걸어야 하는 경우가 생깁니다.

또, 다른 방법으로 numactl 로 memory affinity 하는겁니다.

 

Cgroups 란?

Ref : http://www.slideshare.net/sprdd/linux-performan-tuning-part-1

 

MySQL vs NUMA

Ref : http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

 

그리고, 이런 이슈는 MySQL, MongoDB 말고도 대부분의 In-Memory 기반에서 문제가 되고 있습니다.

 

Deview 2014 : ARCUS 차별 기능, 사용 이슈, 그리고 카카오 적용 사례

Ref  : http://deview.kr/2014/session?seq=9

 

How to change mysql time_zone

MySQL Timezone 설정방법입니다.

 

What’s Timezone ?!

시간대(時間帶)는 영국의 그리니치 천문대를 기준으로 (경도 0도) 지역에 따른 시간의 차이, 다시 말해 지구의 자전에 따른 지역 사이에 생기는 낮과 밤의 차이를 인위적으로 조정하기 위해 고안된 시간의 구분선을 일컫는다. 시간대는 협정 세계시(UTC)를 기준으로한 상대적인 차이로 나타낸다.

 

How-to

1.  Timezone 확인

$ date +%Z

KST

$ date +%z

+0900

$ cat /etc/sysconfig/clock

ZONE=”Asia/Seoul”

 

2. Timezone 설정

$ ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

or

$ ln -sf /usr/share/zoneinfo/UTC  /etc/localtime

$ vi /etc/sysconfig/clock

ZONE=”Asia/Seoul”

UTC=true

ARC=false

or

$ tzselect

or

export TZ=”Asia/Seoul”

 

3. MySQL Timezone Table 설정

$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -D mysql -u root -p

$ mysql -u root -p

mysql> select count(*) from mysql.time_zone;

+———-+
| count(*) |
+———-+
| 1738     |
+———-+
1 row in set (0.00 sec)

 

4. MySQL Timezone 확인

$ mysql -u root -p

mysql> SELECT @@global.time_zone, @@session.time_zone;

+—————————+—————————+
| @@global.time_zone | @@session.time_zone |
+—————————+—————————+
| SYSTEM                  | SYSTEM                    |
+—————————+—————————+
1 row in set (0.00 sec)

 

mysql> show variables like ‘%time_zone%’;
+———————–+———–+
| Variable_name         | Value     |
+———————–+———–+
| system_time_zone | KST       |
| time_zone            | SYSTEM |
+———————–+———–+
2 rows in set (0.00 sec)

 

5. MySQL Timezone 설정

$ mysql -u root -p

mysql> set @@global.time_zone=’Asia/Seoul’;

mysql> set global time_zone =’Asia/Seoul’;

mysql> set @@session.time_zone = “+00:00”;

mysql> set session time_zone =’Asia/Seoul’;

mysql> set time_zone = ‘Europe/Helsinki’;

mysql> set time_zone = “+00:00”;

mysql> select now();

 

set_time_zone

 

MySQL Timezone Support

 

MySQL Server Variables

 

Ref :

MySQL & MariaDB blog list – 14Q3v1

MySQL & MariaDB 관련해서 참고할만한 블로그 또는 사이트를 공유합니다.

 

MySQL Performance Blog

> 제일 유명한 블로그 중 하나일 겁니다. 게시글도 좋지만, 필히 덧글을 추가로 읽어보실 것을 권합니다. 성능에 대한 부분은 100% 신뢰하긴 힘듭니다. 그들은 MySQL Expert 입니다.

 

MySQL Performance Engineer

> 이런 스타일의 그래프는 99% !! dimitrik 블로그의 자료입니다. Oracle MySQL 에 성능문의를 하신다면 dimitrik 의 답변(의견)일 수도 있습니다.

 

MySQL Sandbox & Tungsten Replicator

> sandbox & gearmand 창시자이시며, 지금은 continuent 에 계십니다. tungsten replicator 참고할만 합니다.

 

MySQL Developer

> handlersocket 창시자이시며, 지금은 facebook 에 계십니다. 최근에는 WebScaleSQL 에 참여하시고 계십니다. slideshare 에서 yoshinori matsunobu 슬라이드는 필독입니다.

 

Kakao DB Team

 

ronald bradford blog

 

Mikael Ronstrom

> My name is Mikael Ronstrom and I work for Oracle as Senior MySQL Architect. I am a member of the LDS church. The statements and opinions expressed on this blog are my own and do not necessarily represent those of Oracle Corporation