플랫폼 개발팀 I DBA 성동찬

대형 사이트 구축을 위한 MySQL 튜닝 전략

대형 사이트 구축을 위한 MySQL 튜닝 전략

MySQL DBMS 특성 Nested Loop Join Multiple Storage Engine Data Replication

01

대형 사이트 구축 전략 서버 구성 전략 스토리지 엔진 선정 전략 인덱싱 전략 파티셔닝 전략 리플리케이션 전략 캐시 전략

02

사례 03

MySQL DBMS 특성 01 Nested Loop Join Multiple Storage Engine Data Replication

단일 코어, SQL처리

Core 1 Core 3

Core 2 Core 4

단순 SQL

Outer Join (1분)

무거운 SQL

(3시간)

Core 1

Core 2

Core 3

단일 코어, SQL처리

Nested Loop Join

Nested Loop Join

Sort Merge Join

Hash Join

Inner Join? Outer Join?

Sub-Query?

Nested Loop Join

Only Nested Loop Join!

Nested Loop Join & 단일 코어, SQL처리

DataWarehouse?

OnLine Transaction Processing!

MySQL DBMS 특성 01 Nested Loop Join Multiple Storage Engine Data Replication

Multiple Storage Engine

MyISAM Federated

InnoDB Memory

Archive NDB

3rd Engine

MyISAM

InnoDB

Archive

다양한 스토리지 엔진

스토리지 제한

트랜잭션

Locking 레벨

인덱스

Cache

파티셔닝

Cluster Index

Foreign Key

비고

Multiple Storage Engine

MyISAM

256TB

No

Table

B-Tree

Index

YES

No

No

백그라운드

로그 수집

InnoDB

64TB

Yes

Row

B-Tree

Data/Index

YES

YES

Yes

OLTP

Archive

None

No

Row

NO

NO

YES

No

No

원시 로그 수집

64TB

Yes

Row

B-Tree

Data/Index

YES

YES

Yes

None

No

Row

NO

NO

YES

No

No

256TB

No

Table

B-Tree

Index

YES

No

No

대용량 처리

Multiple Storage Engine - InnoDB

JOB4

ROW01 ROW02 ROW03

ROW04 ROW05 ROW06

ROW07 ROW08 ROW09

TABLE

트랜잭션 + 행 단위 잠금

JOB1

JOB2

JOB3

Multiple Storage Engine - InnoDB

10

1

data1

data2

data3

data4

20

9

data1

data2

data3

data4

30

2

data1

data2

data3

data4

30

3

data1

data2

data3

data4

30

4

data1

data2

data3

data4

B+ Tree

PK

Data

21

30

data1

data2

data3

data4

데이터는 Primary Key 순!!

이동

30

2

data1

data2

30

3

data1

data2

30

4

data1

data2

20

9

data1

data2

10

1

data1

data2

PK

Multiple Storage Engine - InnoDB

100 7 23 3 22 INDEX

22

10

1

23

30

4

100

30

2

7

30

3

3

20

9

KEY

VALUE

B+ Tree

인덱스는 PK를 Value로..

MySQL DBMS 특성 01 Nested Loop Join Multiple Storage Engine Data Replication

Data Replication

데이터 변경

Active!!

Passive!!

“1” 마스터, “다중” 슬레이브

Data Replication

MySQL Replication Oracle RAC

공유 스토리지

VS

디스크는 물리적으로 독립

Data Replication

Asynchronous

Replication

Statement Row Statement Row

Mixed

로그 기반 데이터 동기화

Master Slave

Data Replication

Session01

Session02

Session03

Database

Dump

Relay Log Binary Log

IO Thread SQL Thread

Database

슬레이브는 단일 Thread 처리

서버 구성 전략 스토리지 엔진 선정 전략 인덱싱 전략 파티셔닝 전략 리플리케이션 전략 캐시 전략

대형 사이트 구축 전략 02

서버 구성 전략 - 프로세서

Scale Up? Scale Out? VS

프로세서는 빠르게!!

서버 구성 전략 - 메모리

메모리는 최대한 크게!!

RAID0

서버 구성 전략 - 디스크

RAID1 RAID1

“RAID1+0”, RAID5, RAID1

Striping

Mirroring

서버 구성 전략 - 네트워크

NIC1

NIC2

기가 비트 NIC로 이중화

Insert

Delete

Update

Select

서버 구성 전략 - 네트워크

서비스용, 내부 통신용 분리

NIC1

NIC2

NIC7

NIC8

NIC5

NIC6

NIC3

NIC4

Master Slave

Select

Insert

Delete

Update

Select

서버 구성 전략 스토리지 엔진 선정 전략 인덱싱 전략 파티셔닝 전략 리플리케이션 전략 캐시 전략

대형 사이트 구축 전략 02

스토리지 엔진 선정 전략

스토리지 엔진 선정

동시처리?

트랜잭션? 로그전용?

서비스 특성을 고려!!

DISK

스토리지 엔진 선정 전략

서비스 데이터

InnoDB Buffer Pool (Memory)

I/O

단순 LOG 데이터

Flush

엔진을 잘못 선정하면?

스토리지 엔진 선정 전략

INNODB MyISAM Archive

업데이트?

로그전용?

읽기전용?

동시처리?

트랜잭션?

서버 구성 전략 스토리지 엔진 선정 전략 인덱싱 전략 파티셔닝 전략 리플리케이션 전략 캐시 전략

대형 사이트 구축 전략 02

인덱싱 전략

인덱스는 많을 수록

무조건 좋다??

인덱싱 전략

분포도 고려하여 “가장 적게”

중복된 데이터 많으면 대상 제외! 1

2

3

인덱스 많을 수록 효율은 떨어짐!!

인덱스도 데이터!

인덱싱 전략

작은 데이터 타입으로..

문자열 인덱스는 최대한 회피 1

2

3

CRC32+Trigger로 대체 인덱스 구성

인덱스도 데이터! × 𝟐

인덱싱 전략

NULL 허용 금지!!

NULL 허용 시 추가 1 Byte 소요 1

2 인덱스도 데이터!!!

서버 구성 전략 스토리지 엔진 선정 전략 인덱싱 전략 파티셔닝 전략 리플리케이션 전략 캐시 전략

대형 사이트 구축 전략 02

파티셔닝 전략

Data File

File01

File01

파티셔닝?

파티셔닝 전략

파티셔닝 적용?

랜덤 PK시 Clustering 비효율 개선 1

2 대용량 데이터 날짜 별 관리

파티셔닝 전략

주의 사항

Foreign key 사용 불가 1

2 Full-text 및 Spatial 인덱싱 사용 불가

3 파티셔닝 키는 PK안에 존재해야 함

4 조회 조건에 파티셔닝 키 포함

서버 구성 전략 스토리지 엔진 선정 전략 인덱싱 전략 파티셔닝 전략 리플리케이션 전략 캐시 전략

대형 사이트 구축 전략 02

리플리케이션 전략

“Async”hronous!!

슬레이브는 1 Thread에서만 반영 1

2 Master-Slave 동기화 지연 발생 가능

리플리케이션 전략

DB

버그

무거운

SQL

과도한

트래픽 에러

무거운

SQL

동기화 지연 발생 원인

리플리케이션 전략

MIXED? ROW!

Create

Table

As

Select

Insert

into

Select

세션 별 Binary Log 포멧 변경

리플리케이션 전략

DB

버그

무거운

SQL

과도한

트래픽 에러

과도한

트래픽

동기화 지연 발생 원인

파티셔닝 전략

Must Primary Key!!

5.1.57 이전 버전 버그 존재!! 1

2 Binary Log가 “ROW” 시 비효율 발생!!

리플리케이션 전략

user

log

service A

S1

S2

S3

M

user

log

service A

특정 DB만 동기화 전략!

리플리케이션 전략

슬레이브를 고 스펙으로!!

서버 구성 전략 스토리지 엔진 선정 전략 인덱싱 전략 파티셔닝 전략 리플리케이션 전략 캐시 전략

대형 사이트 구축 전략 02

캐시 전략

Query Cache Type

ON

OFF

DEMAND

서비스 특성을 고려!!

캐시 전략

제약 조건

SQL의 Hash 값을 키로 사용 1

2 테이블 변경 시 연관된 캐시 전체 소멸

3 쿼리 가지 수가 많으면 비효율 발생

캐시 전략

MySQL은 단순 데이터 처리에 강한 관계형 DBMS이다!! 단일 코어에서 Nested Loop으로 SQL처리

1

맺음말

MySQL에서 대용량 처리는 InnoDB가 적합하다. 트랜잭션과 행 단위 잠금으로 데이터 처리!!

2

맺음말

InnoDB에서 Primary Key는 Cluster Index로 구성!!

추가 인덱스는 Primary Key를 Value로..

MySQL에서 Replication 으로 데이터를 분산 가능하다. 단일 마스터, 다중 슬레이브 구조로 디스크는 독립적

3

맺음말

로그 기반으로 비동기적으로 데이터를 복제

슬레이브는 단일 Thread로 데이터를 반영

감사합니다. 플랫폼개발실 / 공통플랫폼팀 대리 / DBA 성동찬

sdchan1@kthcorp.com

@gywndi