Neo-Oracle Home

Feature Support

2018년 11월쯤에 조사했던 내용

gru의 블로그나 제품 매뉴얼에서 조사

틀린 내용이 있을 수 있으니 일반 참고 측면에서만 참고

추가 비교할 사항들이 있겠지만 중점적으로 본 내용 위주로 정리한 내용

둘 다 가지고 있는 기능(FK등)이나 복제 관련은 논하지 않음

※ Mysql은 기본 스토리지 엔진인 InnoDB 기준

Mysql8

버전 정보

Mysql8 = Mysql 5.8
8.0.0 출시일 2016. 9. 12.
8.0.13 출시일 2018. 10. 22.
5.7부터 performance_schema 생성

기능

예전까지는 PostgreSQL에 비해 전체적으로 SQL 등 기능이 적었다
Mysql 8이 나오면서 간격은 매우 좁혀짐
Mysql 8부터 힌트도 더 나아짐
CTE(common table expressions), Windows Function 추가 등
PostgreSQL을 쓰는 주된 이유였지만 이젠 아니게 됐다

단점

Oracle사의 소유라는 공포

단, 개발은 Oracle 사로 넘어간 뒤 더 가속화

No Hash Join

MariaDB는 있음

대량 데이터 처리 불리

Merge Join도 없음

PostgreSQL 10

버전 정보

PostgreSQL10

10.0 출시일 2017. 10. 5.
10.6 출시일 2018. 11. 8.

PostgreSQL11

11.0 출시일 2018. 10. 18.

단점

복제 설정의 유연성 결여

우버가 mysql로 전환한 이유 중 하나

이젠 post도 된다고 하는데..

Overhead UPDATE

우버가 mysql로 전환한 이유 중 하나

하지만 많은 PostgreSQL 옹호자들이 반박하는 내용들이 존재합니다

SQL 성능이나 파일 크기에 대해 불안정하고 예상하기 어렵다

Vacuum은 너무 비싼 작업

Update에 관해선 Mysql이 더 낫다

비교

항목	Mysql 8	PostgreSQL 10	비고
프로세스 방식	MultiThread	MultiProcess	PostgreSQL이 세션당 메모리 사용량이 더 높다
테이블 구조	Cluster Index(IOT)	HEAP(IOT 미지원)	InnoDB 엔진 기준
Non-Partitioned Index	미지원	지원	파티션 테이블 대상
Update 방식	별도 Rollback Segment 사용	데이터와 같은 Block 사용
Redo/복제 로그	별도	동일
Block Size	16KB	8KB	InnoDB 엔진 기준
Update Overhead	Bloat 현상 x 파일크기/SQL성능 Stable	Bloat 현상 o 파일크기/SQL성능 Unstable	Heavy UPDATE WORKLOAD 기준
대량 Insert	PostgreSQL 대비 불리	Mysql 대비 유리

선택

Mysql8

OLTP에 BEST
DW에 불리

대량 처리용 Join이 없다

Only NL join

대량 처리용 Insert가 느리다(IOT)

PostgreSQL10

DW에 BEST
OLTP에 불리한 이유

빈번한 UPDATE 성격일 경우 성능/용량 불안정

감안하고 사용하더라도 세심한 Vacuum 관리 필요

INSERT 위주 성격일 경우에는 적합

결론

"Mysql이 좋은가 PostgreSQL이 좋은가" : X

"Mysql 이나 PostgreSQL 사용시 무엇을 고려 해야 하는가" : O

DB별 특징을 참고하여 구축시 성격에 맞는 DB 선택하고 테스트해봐야 합니다.

1) mysql 강제로 kill한다. 패스워드를 몰라서 mysqladmin 으로 내릴 수 없음

pkill -9 <mysqlPID>

2) skip-grant-tables 옵션으로 mysql 을 올린다.

# /usr/local/mysql/bin/mysqld_safe --user=mysql --skip-grant-tables &

3) root로 접속한다.

# mysql -u root mysql

4) root 패스워드를 바꾼다.

mysql> update user set password=PASSWORD(‘New password’) where user=’root’;

5) 권한을 적용한다.

mysql> FLUSH PRIVILEGES;

6) mysql을 내린다.

# ./mysqladmin -uroot -p shutdown

7) 다시 정상적으로 올린다.

# /usr/local/mysql/bin/mysqld_safe --user=mysql &

워드프레스 기반 웹서버의 mysql 5.6 DB였는데 사이트가 너무 느려서 혹시나 해서 확인해봤더니 파라미터 설정이 엉망이었다.

OS 메모리가 32GB이고 데이터 크기는 6GB정도인데 왜 버퍼풀을 18GB나 잡은건지 따로 엔지니어나 DBA가 설정을 건드려준 적이 한번도 없어보였다.

수정한 내용은 아래와 같고 이후 아주 쾌적하게 된 상태

query_cache는 사용 여부를 잘 정해야 하는데 이 사이트는 할만한 것으로 판단돼 설정하였다.