'Knowledge/MySQL'에 해당되는 글 4건

  1. 2019.02.12 Mysql 8.0 InnoDB Storage Engine Features
  2. 2019.01.02 Mysql 8 vs PostgreSQL 10 간단 비교 2
  3. 2015.01.19 reset root password
  4. 2015.01.14 mysql parameter 튜닝했던 기록

Feature Support

기능

지원

B-tree indexes

Yes

Backup/point-in-time recovery (Implemented in the server,rather than in the storage engine.)

Yes

Cluster database support

No

Clustered indexes

Yes

Compressed data

Yes

Data caches

Yes

Encrypted data

Yes (Implemented in the server via encryption functions; In MySQL 5.7 and later, data-at-rest tablespace encryption is supported.)

Foreign key support

Yes

Full-text search indexes

Yes (InnoDB support for FULLTEXT indexes is available in MySQL 5.6 and later.)

Geospatial data type support

Yes

Geospatial indexing support

Yes (InnoDB support for geospatial indexing is available in MySQL 5.7 and later.)

Hash indexes

No (InnoDB utilizes hash indexes internally for its Adaptive Hash Index feature.)

Index caches

Yes

Locking granularity

Row

MVCC

Yes

Replication support (Implemented in the server, rather than in the storage engine.)

Yes

Storage limits

64TB

T-tree indexes

No

Transactions

Yes

Update statistics for data dictionary

Yes

'Knowledge > MySQL' 카테고리의 다른 글

Mysql 8 vs PostgreSQL 10 간단 비교  (2) 2019.01.02
reset root password  (0) 2015.01.19
mysql parameter 튜닝했던 기록  (0) 2015.01.14
Posted by neo-orcl
,

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 선택하고 테스트해봐야 합니다.

'Knowledge > MySQL' 카테고리의 다른 글

Mysql 8.0 InnoDB Storage Engine Features  (0) 2019.02.12
reset root password  (0) 2015.01.19
mysql parameter 튜닝했던 기록  (0) 2015.01.14
Posted by neo-orcl
,

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 &

'Knowledge > MySQL' 카테고리의 다른 글

Mysql 8.0 InnoDB Storage Engine Features  (0) 2019.02.12
Mysql 8 vs PostgreSQL 10 간단 비교  (2) 2019.01.02
mysql parameter 튜닝했던 기록  (0) 2015.01.14
Posted by neo-orcl
,

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

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

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

항목 기존값 변경값 비고
sort_buffer_size 10M 2M 기존값 큼
read_buffer_size 8M 128K 기존값 큼
query_cache_type 0 1 쿼리캐시기능 사용
query_cache_size 512M 128M 기존값 큼
query_cache_limit 1024M 1M 기존값 잘못됨
max_connections 2000 1000 기존값 큼
thread_cache_size 100 50 기존값 큼
innodb_io_capacity - 500 추가
innodb_write_io_threads - 16 추가
innodb_read_io_threads - 16 추가
innodb_buffer_pool_size 18G 10G 기존값이 현 innodb 테이블 크기에 비해 너무 큼
innodb_additional_mem_pool_size 4M 20M 기존값 작음
innodb_log_buffer_size 128M 32M 기존값 큼
innodb_flush_method - O_DIRECT 추가

 

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

'Knowledge > MySQL' 카테고리의 다른 글

Mysql 8.0 InnoDB Storage Engine Features  (0) 2019.02.12
Mysql 8 vs PostgreSQL 10 간단 비교  (2) 2019.01.02
reset root password  (0) 2015.01.19
Posted by neo-orcl
,