SlideShare a Scribd company logo
대형 사이트
   구축을 위한
MySQL 튜닝 전략
플랫폼 개발팀 I DBA 성동찬
대형 사이트 구축을 위한 MySQL 튜닝 전략



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

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

03 사례
01 MySQL DBMS 특성
   Nested Loop Join
   Multiple Storage Engine
   Data Replication
단일 코어, SQL처리



    단일 코어, SQL처리
단순
SQL     Core 1     Core 3


                                 무거운
                                   SQL
Outer     Core 2      Core 4
                                 (3시간)
 Join
(1분)
Nested Loop Join



  Only Nested Loop Join!
Inner Join?
                      Hash        Outer Join?
                      Join


               Sort
              Merge
               Join
                         Nested
                          Loop
                          Join
    Sub-Query?
Nested Loop Join & 단일 코어, SQL처리




 DW   ata        arehouse   ?
OL T
 n   ine      ransaction    P   rocessing!
01 MySQL DBMS 특성
   Nested Loop Join
   Multiple Storage Engine
   Data Replication
Multiple Storage Engine



다양한 스토리지 엔진

         Federated   MyISAM



 3rd Engine     InnoDB    Memory




              NDB    Archive
Multiple Storage Engine

                                       대용량
                                        처리
                MyISAM    Archive          InnoDB

스토리지 제한          256TB     None              64TB

  트랜잭션            No        No               Yes

Locking 레벨       Table
                 Table     Row               Row
                                             Row

   인덱스          B-Tree
                B-Tree      NO              B-Tree
                                            B-Tree

   Cache         Index
                 Index      NO            Data/Index
                                          Data/Index

  파티셔닝           YES       YES               YES

Cluster Index     No        No               YES

Foreign Key       No        No               Yes

                백그라운드
    비고                   원시 로그 수집            OLTP
                로그 수집
Multiple Storage Engine - InnoDB



트랜잭션 + 행 단위 잠금
JOB1   TABLE                           JOB3

        ROW01   ROW02   ROW03


        ROW04   ROW05   ROW06


        ROW07   ROW08   ROW09



JOB2                                   JOB4
Multiple Storage Engine - InnoDB



   데이터는 Primary Key 순!!
B+ Tree




           10      20                 30       30       30
    PK
           1       9                   2        3       4
          data1   data1    21        data1    data1    data1
          data2   data2    30        data2    data2    data2
  Data
          data3   data3   data1      data3    data3    data3
          data4   data4   data2      data4    data4    data4
                          data3
                          data4     이동
Multiple Storage Engine - InnoDB



  인덱스는 PK를 Value로..
           10      20      30        30       30
   PK
           1       9       2         3         4
INDEX     data1
           22     data1
                    3     data1
                           100     data1
                                     7       data1
                                              23
          data2   data2   data2    data2     data2




B+ Tree



  KEY      3       7       22        23       100
           20      30      10        30       30
VALUE
           9       3       1         4         2
01 MySQL DBMS 특성
   Nested Loop Join
   Multiple Storage Engine
   Data Replication
Data Replication



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

   데이터 변경




            Passive!!
Data Replication



  디스크는 물리적으로 독립
MySQL Replication             Oracle RAC

                         공유 스토리지


                    VS
Data Replication



로그 기반 데이터 동기화
               Mixed

Statement                  Row



            Asynchronous
            Replication
Data Replication



슬레이브는 단일 Thread 처리
 Master                    Slave

   Session01
                Database           Database

   Session02

                    Dump    IO Thread    SQL Thread
   Session03




       Binary Log                  Relay Log
02 대형 사이트 구축 전략
  서버 구성 전략
  스토리지 엔진 선정 전략
  인덱싱 전략
  파티셔닝 전략
  리플리케이션 전략
  캐시 전략
서버 구성 전략 - 프로세서



  프로세서는 빠르게!!
Scale Up?   VS   Scale Out?
서버 구성 전략 - 메모리



메모리는 최대한 크게!!
서버 구성 전략 - 디스크



“RAID1+0”,            RAID5, RAID1


      Striping      RAID0


Mirroring   RAID1           RAID1
서버 구성 전략 - 네트워크



   기가 비트 NIC로 이중화

Insert
Delete   NIC1

Update   NIC2

Select
서버 구성 전략 - 네트워크



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

Insert
Delete   NIC1   NIC3   NIC5     NIC7   Select
Update   NIC2   NIC4   NIC6     NIC8

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



서비스 특성을 고려!!

   트랜잭션?   로그전용?


      동시처리?




   스토리지 엔진 선정
스토리지 엔진 선정 전략



 엔진을 잘못 선정하면?
InnoDB Buffer Pool (Memory)


                              서
                              비
                              스
    단순 LOG 데이터                데
                              이
                              터
                                  I/O   DISK


                     Flush
스토리지 엔진 선정 전략




                            로그전용?



                  읽기전용?


         동시처리?




                 트랜잭션?               업데이트?




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




인덱스는 많을 수록
 무조건 좋다??
인덱싱 전략




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

1   중복된 데이터 많으면 대상 제외!
2   인덱스 많을 수록 효율은 떨어짐!!
3   인덱스도 데이터!
인덱싱 전략




    작은 데이터 타입으로..

1   문자열 인덱스는 최대한 회피
2   CRC32+Trigger로 대체 인덱스 구성
3   인덱스도 데이터! × 𝟐
인덱싱 전략




      NULL 허용 금지!!

1   NULL 허용 시 추가 1 Byte 소요
2
    인덱스도 데이터!!!
02 대형 사이트 구축 전략
  서버 구성 전략
  스토리지 엔진 선정 전략
  인덱싱 전략
  파티셔닝 전략
  리플리케이션 전략
  캐시 전략
파티셔닝 전략




            파티셔닝?
Data File      File01   File01
파티셔닝 전략




        파티셔닝 적용?

1   랜덤 PK시 Clustering 비효율 개선
2   대용량 데이터 날짜 별 관리
파티셔닝 전략




            주의 사항
1   Foreign key 사용 불가
2   Full-text 및 Spatial 인덱싱 사용 불가
3   파티셔닝 키는 PK안에 존재해야 함
4   조회 조건에 파티셔닝 키 포함
02 대형 사이트 구축 전략
  서버 구성 전략
  스토리지 엔진 선정 전략
  인덱싱 전략
  파티셔닝 전략
  리플리케이션 전략
  캐시 전략
리플리케이션 전략




    “Async”hronous!!
1   슬레이브는 1 Thread에서만 반영
2   Master-Slave 동기화 지연 발생 가능
리플리케이션 전략



동기화 지연 발생 원인
    DB   무거운
    버그    SQL


   과도한
         에러
   트래픽
리플리케이션 전략



세션 별 Binary Log 포멧 변경

        Create
                 Insert
        Table
                  into
          As
                 Select
        Select




   MIXED?             ROW!
리플리케이션 전략



동기화 지연 발생 원인
    DB   무거운
    버그    SQL


   과도한
         에러
   트래픽
파티셔닝 전략




    Must Primary Key!!

1   5.1.57 이전 버전 버그 존재!!
2   Binary Log가 “ROW” 시 비효율 발생!!
리플리케이션 전략



특정 DB만 동기화 전략!
                 user

                 log
         M
               service A




    S1               S3

         S2
  user             service A

         log
리플리케이션 전략




슬레이브를 고 스펙으로!!
02 대형 사이트 구축 전략
  서버 구성 전략
  스토리지 엔진 선정 전략
  인덱싱 전략
  파티셔닝 전략
  리플리케이션 전략
  캐시 전략
캐시 전략



서비스 특성을 고려!!

     Query Cache Type



ON                      DEMAND

           OFF
캐시 전략




          제약 조건
1   SQL의 Hash 값을 키로 사용
2   테이블 변경 시 연관된 캐시 전체 소멸

3   쿼리 가지 수가 많으면 비효율 발생
캐시 전략
맺음말




1


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




2


MySQL에서
대용량 처리는
InnoDB가 적합하다.
 트랜잭션과 행 단위 잠금으로 데이터 처리!!
 InnoDB에서 Primary Key는 Cluster Index로 구성!!
 추가 인덱스는 Primary Key를 Value로..
맺음말




3


MySQL에서
Replication 으로
데이터를 분산 가능하다.
 단일 마스터, 다중 슬레이브 구조로 디스크는 독립적
 로그 기반으로 비동기적으로 데이터를 복제
 슬레이브는 단일 Thread로 데이터를 반영
감사합니다.
플랫폼개발실 / 공통플랫폼팀 대리 / DBA 성동찬
       sdchan1@kthcorp.com
             @gywndi

More Related Content

What's hot

What's hot (20)

개발자가 도전하는 MariaDB 서버구축
개발자가 도전하는 MariaDB 서버구축개발자가 도전하는 MariaDB 서버구축
개발자가 도전하는 MariaDB 서버구축
 
MariaDB Optimization
MariaDB OptimizationMariaDB Optimization
MariaDB Optimization
 
[오픈소스컨설팅]MySQL Monitoring
[오픈소스컨설팅]MySQL Monitoring[오픈소스컨설팅]MySQL Monitoring
[오픈소스컨설팅]MySQL Monitoring
 
Maria db
Maria dbMaria db
Maria db
 
MySQL Deep dive with FusionIO
MySQL Deep dive with FusionIOMySQL Deep dive with FusionIO
MySQL Deep dive with FusionIO
 
MySQL_Fabric_운영시유의사항
MySQL_Fabric_운영시유의사항MySQL_Fabric_운영시유의사항
MySQL_Fabric_운영시유의사항
 
MySQL Administrator 2021 - 네오클로바
MySQL Administrator 2021 - 네오클로바MySQL Administrator 2021 - 네오클로바
MySQL Administrator 2021 - 네오클로바
 
AWS 환경에서 MySQL BMT
AWS 환경에서 MySQL BMTAWS 환경에서 MySQL BMT
AWS 환경에서 MySQL BMT
 
Percona server for MySQL 제품 소개
Percona server for MySQL 제품 소개Percona server for MySQL 제품 소개
Percona server for MySQL 제품 소개
 
MySQL 상태 메시지 분석 및 활용
MySQL 상태 메시지 분석 및 활용MySQL 상태 메시지 분석 및 활용
MySQL 상태 메시지 분석 및 활용
 
Maxscale 소개 1.1.1
Maxscale 소개 1.1.1Maxscale 소개 1.1.1
Maxscale 소개 1.1.1
 
MS 빅데이터 서비스 및 게임사 PoC 사례 소개
MS 빅데이터 서비스 및 게임사 PoC 사례 소개MS 빅데이터 서비스 및 게임사 PoC 사례 소개
MS 빅데이터 서비스 및 게임사 PoC 사례 소개
 
From MSSQL to MySQL
From MSSQL to MySQLFrom MSSQL to MySQL
From MSSQL to MySQL
 
Intro KaKao ADT (Almighty Data Transmitter)
Intro KaKao ADT (Almighty Data Transmitter)Intro KaKao ADT (Almighty Data Transmitter)
Intro KaKao ADT (Almighty Data Transmitter)
 
MySQL/MariaDB Proxy Software Test
MySQL/MariaDB Proxy Software TestMySQL/MariaDB Proxy Software Test
MySQL/MariaDB Proxy Software Test
 
From MSSQL to MariaDB
From MSSQL to MariaDBFrom MSSQL to MariaDB
From MSSQL to MariaDB
 
AWS 환경에서 MySQL Infra 설계하기-2부.본론
AWS 환경에서 MySQL Infra 설계하기-2부.본론AWS 환경에서 MySQL Infra 설계하기-2부.본론
AWS 환경에서 MySQL Infra 설계하기-2부.본론
 
[오픈소스컨설팅]J boss6 7_교육자료
[오픈소스컨설팅]J boss6 7_교육자료[오픈소스컨설팅]J boss6 7_교육자료
[오픈소스컨설팅]J boss6 7_교육자료
 
Tungsten 을활용한 MySQL / Hadoop 동기화
Tungsten 을활용한 MySQL / Hadoop 동기화Tungsten 을활용한 MySQL / Hadoop 동기화
Tungsten 을활용한 MySQL / Hadoop 동기화
 
redis 소개자료 - 네오클로바
redis 소개자료 - 네오클로바redis 소개자료 - 네오클로바
redis 소개자료 - 네오클로바
 

Similar to H3 2011 대형사이트 구축을 위한 MySQL 튜닝전략_데이터지능팀_성동찬

Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
cranbe95
 
Mongodb 특징 분석
Mongodb 특징 분석Mongodb 특징 분석
Mongodb 특징 분석
Daeyong Shin
 
Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017
Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017
Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017
Amazon Web Services Korea
 

Similar to H3 2011 대형사이트 구축을 위한 MySQL 튜닝전략_데이터지능팀_성동찬 (20)

Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
Ndc2011 성능 향상을_위한_데이터베이스_아키텍쳐_구축_및_개발_가이드
 
Mongodb 특징 분석
Mongodb 특징 분석Mongodb 특징 분석
Mongodb 특징 분석
 
나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016
나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016
나에게 맞는 AWS 데이터베이스 서비스 선택하기 :: 양승도 :: AWS Summit Seoul 2016
 
[스마트스터디]MongoDB 의 역습
[스마트스터디]MongoDB 의 역습[스마트스터디]MongoDB 의 역습
[스마트스터디]MongoDB 의 역습
 
MySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptxMySQL_MariaDB-성능개선-202201.pptx
MySQL_MariaDB-성능개선-202201.pptx
 
MySQL InnoDB Cluster 소개
MySQL InnoDB Cluster 소개MySQL InnoDB Cluster 소개
MySQL InnoDB Cluster 소개
 
Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017
Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017
Amazon Aurora 성능 향상 및 마이그레이션 모범 사례 - AWS Summit Seoul 2017
 
Introduction to Apache Tajo
Introduction to Apache TajoIntroduction to Apache Tajo
Introduction to Apache Tajo
 
iris solution_overview_for_bigdata
iris solution_overview_for_bigdatairis solution_overview_for_bigdata
iris solution_overview_for_bigdata
 
AWS RDS, DYNAMO
AWS RDS, DYNAMOAWS RDS, DYNAMO
AWS RDS, DYNAMO
 
The MongoDB Strikes Back / MongoDB 의 역습
The MongoDB Strikes Back / MongoDB 의 역습The MongoDB Strikes Back / MongoDB 의 역습
The MongoDB Strikes Back / MongoDB 의 역습
 
[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영[215]네이버콘텐츠통계서비스소개 김기영
[215]네이버콘텐츠통계서비스소개 김기영
 
Amazon Aurora Deep Dive (김기완) - AWS DB Day
Amazon Aurora Deep Dive (김기완) - AWS DB DayAmazon Aurora Deep Dive (김기완) - AWS DB Day
Amazon Aurora Deep Dive (김기완) - AWS DB Day
 
토이 프로젝트를 위한 속성 RDB(MySQL) 스터디 1
토이 프로젝트를 위한 속성 RDB(MySQL) 스터디 1토이 프로젝트를 위한 속성 RDB(MySQL) 스터디 1
토이 프로젝트를 위한 속성 RDB(MySQL) 스터디 1
 
Infiniflux introduction
Infiniflux introductionInfiniflux introduction
Infiniflux introduction
 
AWS 6월 웨비나 | AWS에서 MS SQL 서버 운영하기 (김민성 솔루션즈아키텍트)
AWS 6월 웨비나 | AWS에서 MS SQL 서버 운영하기 (김민성 솔루션즈아키텍트)AWS 6월 웨비나 | AWS에서 MS SQL 서버 운영하기 (김민성 솔루션즈아키텍트)
AWS 6월 웨비나 | AWS에서 MS SQL 서버 운영하기 (김민성 솔루션즈아키텍트)
 
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
관계형 데이터베이스의 새로운 패러다임 Amazon Aurora :: 김상필 :: AWS Summit Seoul 2016
 
IRIS
IRISIRIS
IRIS
 
IBM Storage for AI - NVMe & Spectrum Scale 기술을 탑재한 ESS3000
IBM Storage for AI - NVMe & Spectrum Scale 기술을 탑재한 ESS3000IBM Storage for AI - NVMe & Spectrum Scale 기술을 탑재한 ESS3000
IBM Storage for AI - NVMe & Spectrum Scale 기술을 탑재한 ESS3000
 
AWS BigData 전략과 관련 AWS 서비스 이해하기
AWS BigData 전략과 관련 AWS 서비스 이해하기AWS BigData 전략과 관련 AWS 서비스 이해하기
AWS BigData 전략과 관련 AWS 서비스 이해하기
 

More from KTH, 케이티하이텔

[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
KTH, 케이티하이텔
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH, 케이티하이텔
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH, 케이티하이텔
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH, 케이티하이텔
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH, 케이티하이텔
 

More from KTH, 케이티하이텔 (20)

[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
 
[H3 2012] 내컴에선 잘되던데? - vagrant로 서버와 동일한 개발환경 꾸미기
[H3 2012] 내컴에선 잘되던데? - vagrant로 서버와 동일한 개발환경 꾸미기[H3 2012] 내컴에선 잘되던데? - vagrant로 서버와 동일한 개발환경 꾸미기
[H3 2012] 내컴에선 잘되던데? - vagrant로 서버와 동일한 개발환경 꾸미기
 
[H3 2012] Open API 와 Ruby on Rails 에 대한 이야기
[H3 2012] Open API 와 Ruby on Rails 에 대한 이야기[H3 2012] Open API 와 Ruby on Rails 에 대한 이야기
[H3 2012] Open API 와 Ruby on Rails 에 대한 이야기
 
[H3 2012] UX, 애자일하고 싶어요
[H3 2012] UX, 애자일하고 싶어요[H3 2012] UX, 애자일하고 싶어요
[H3 2012] UX, 애자일하고 싶어요
 
[H3 2012] Instant Prototyping with ROR
[H3 2012] Instant Prototyping with ROR[H3 2012] Instant Prototyping with ROR
[H3 2012] Instant Prototyping with ROR
 
[H3 2012] Bridge over troubled water : make plug-in for Appspresso
[H3 2012] Bridge over troubled water : make plug-in for Appspresso[H3 2012] Bridge over troubled water : make plug-in for Appspresso
[H3 2012] Bridge over troubled water : make plug-in for Appspresso
 
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
[H3 2012] 스마트모바일 환경에서의 App.품질관리전략
 
[H3 2012] 스타트업 개발사의 생존필수 아이템, BaaS 모바일 고객센터
[H3 2012] 스타트업 개발사의 생존필수 아이템, BaaS 모바일 고객센터[H3 2012] 스타트업 개발사의 생존필수 아이템, BaaS 모바일 고객센터
[H3 2012] 스타트업 개발사의 생존필수 아이템, BaaS 모바일 고객센터
 
[H3 2012] Local based SNS를 이용한 타겟 마케팅
[H3 2012] Local based SNS를 이용한 타겟 마케팅[H3 2012] Local based SNS를 이용한 타겟 마케팅
[H3 2012] Local based SNS를 이용한 타겟 마케팅
 
[H3 2012] 오픈소스로 개발 실력 쌓기
[H3 2012] 오픈소스로 개발 실력 쌓기[H3 2012] 오픈소스로 개발 실력 쌓기
[H3 2012] 오픈소스로 개발 실력 쌓기
 
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
[H3 2012] 앱(APP) 중심으로 생각하기 - DevOps와 자동화
 
[H3 2012] 하이브리드앱 제작 사례 공유 - 푸딩얼굴인식 3.0
[H3 2012] 하이브리드앱 제작 사례 공유 - 푸딩얼굴인식 3.0[H3 2012] 하이브리드앱 제작 사례 공유 - 푸딩얼굴인식 3.0
[H3 2012] 하이브리드앱 제작 사례 공유 - 푸딩얼굴인식 3.0
 
[H3 2012] Cloud Database Service - Hulahoop를 소개합니다.
[H3 2012] Cloud Database Service - Hulahoop를 소개합니다.[H3 2012] Cloud Database Service - Hulahoop를 소개합니다.
[H3 2012] Cloud Database Service - Hulahoop를 소개합니다.
 
[H3 2012] 기획/디자인/개발자 모두 알아야 하는 '대박앱의 비밀'
[H3 2012] 기획/디자인/개발자 모두 알아야 하는 '대박앱의 비밀'[H3 2012] 기획/디자인/개발자 모두 알아야 하는 '대박앱의 비밀'
[H3 2012] 기획/디자인/개발자 모두 알아야 하는 '대박앱의 비밀'
 
[H3 2012] OAuth2 - API 인증을위한 만능 도구상자
[H3 2012] OAuth2 - API 인증을위한 만능 도구상자[H3 2012] OAuth2 - API 인증을위한 만능 도구상자
[H3 2012] OAuth2 - API 인증을위한 만능 도구상자
 
[H3 2012] 오픈 소스로 구현하는 실시간 데이터 처리를 위한 CEP
[H3 2012] 오픈 소스로 구현하는 실시간 데이터 처리를 위한 CEP[H3 2012] 오픈 소스로 구현하는 실시간 데이터 처리를 위한 CEP
[H3 2012] 오픈 소스로 구현하는 실시간 데이터 처리를 위한 CEP
 

H3 2011 대형사이트 구축을 위한 MySQL 튜닝전략_데이터지능팀_성동찬

  • 1. 대형 사이트 구축을 위한 MySQL 튜닝 전략 플랫폼 개발팀 I DBA 성동찬
  • 2. 대형 사이트 구축을 위한 MySQL 튜닝 전략 01 MySQL DBMS 특성  Nested Loop Join  Multiple Storage Engine  Data Replication 02 대형 사이트 구축 전략  서버 구성 전략  스토리지 엔진 선정 전략  인덱싱 전략  파티셔닝 전략  리플리케이션 전략  캐시 전략 03 사례
  • 3. 01 MySQL DBMS 특성  Nested Loop Join  Multiple Storage Engine  Data Replication
  • 4. 단일 코어, SQL처리 단일 코어, SQL처리 단순 SQL Core 1 Core 3 무거운 SQL Outer Core 2 Core 4 (3시간) Join (1분)
  • 5. Nested Loop Join Only Nested Loop Join! Inner Join? Hash Outer Join? Join Sort Merge Join Nested Loop Join Sub-Query?
  • 6. Nested Loop Join & 단일 코어, SQL처리 DW ata arehouse ? OL T n ine ransaction P rocessing!
  • 7. 01 MySQL DBMS 특성  Nested Loop Join  Multiple Storage Engine  Data Replication
  • 8. Multiple Storage Engine 다양한 스토리지 엔진 Federated MyISAM 3rd Engine InnoDB Memory NDB Archive
  • 9. Multiple Storage Engine 대용량 처리 MyISAM Archive InnoDB 스토리지 제한 256TB None 64TB 트랜잭션 No No Yes Locking 레벨 Table Table Row Row Row 인덱스 B-Tree B-Tree NO B-Tree B-Tree Cache Index Index NO Data/Index Data/Index 파티셔닝 YES YES YES Cluster Index No No YES Foreign Key No No Yes 백그라운드 비고 원시 로그 수집 OLTP 로그 수집
  • 10. Multiple Storage Engine - InnoDB 트랜잭션 + 행 단위 잠금 JOB1 TABLE JOB3 ROW01 ROW02 ROW03 ROW04 ROW05 ROW06 ROW07 ROW08 ROW09 JOB2 JOB4
  • 11. Multiple Storage Engine - InnoDB 데이터는 Primary Key 순!! B+ Tree 10 20 30 30 30 PK 1 9 2 3 4 data1 data1 21 data1 data1 data1 data2 data2 30 data2 data2 data2 Data data3 data3 data1 data3 data3 data3 data4 data4 data2 data4 data4 data4 data3 data4 이동
  • 12. Multiple Storage Engine - InnoDB 인덱스는 PK를 Value로.. 10 20 30 30 30 PK 1 9 2 3 4 INDEX data1 22 data1 3 data1 100 data1 7 data1 23 data2 data2 data2 data2 data2 B+ Tree KEY 3 7 22 23 100 20 30 10 30 30 VALUE 9 3 1 4 2
  • 13. 01 MySQL DBMS 특성  Nested Loop Join  Multiple Storage Engine  Data Replication
  • 14. Data Replication “1” 마스터, “다중” 슬레이브 Active!! 데이터 변경 Passive!!
  • 15. Data Replication 디스크는 물리적으로 독립 MySQL Replication Oracle RAC 공유 스토리지 VS
  • 16. Data Replication 로그 기반 데이터 동기화 Mixed Statement Row Asynchronous Replication
  • 17. Data Replication 슬레이브는 단일 Thread 처리 Master Slave Session01 Database Database Session02 Dump IO Thread SQL Thread Session03 Binary Log Relay Log
  • 18. 02 대형 사이트 구축 전략  서버 구성 전략  스토리지 엔진 선정 전략  인덱싱 전략  파티셔닝 전략  리플리케이션 전략  캐시 전략
  • 19. 서버 구성 전략 - 프로세서 프로세서는 빠르게!! Scale Up? VS Scale Out?
  • 20. 서버 구성 전략 - 메모리 메모리는 최대한 크게!!
  • 21. 서버 구성 전략 - 디스크 “RAID1+0”, RAID5, RAID1 Striping RAID0 Mirroring RAID1 RAID1
  • 22. 서버 구성 전략 - 네트워크 기가 비트 NIC로 이중화 Insert Delete NIC1 Update NIC2 Select
  • 23. 서버 구성 전략 - 네트워크 서비스용, 내부 통신용 분리 Master Slave Insert Delete NIC1 NIC3 NIC5 NIC7 Select Update NIC2 NIC4 NIC6 NIC8 Select
  • 24. 02 대형 사이트 구축 전략  서버 구성 전략  스토리지 엔진 선정 전략  인덱싱 전략  파티셔닝 전략  리플리케이션 전략  캐시 전략
  • 25. 스토리지 엔진 선정 전략 서비스 특성을 고려!! 트랜잭션? 로그전용? 동시처리? 스토리지 엔진 선정
  • 26. 스토리지 엔진 선정 전략 엔진을 잘못 선정하면? InnoDB Buffer Pool (Memory) 서 비 스 단순 LOG 데이터 데 이 터 I/O DISK Flush
  • 27. 스토리지 엔진 선정 전략 로그전용? 읽기전용? 동시처리? 트랜잭션? 업데이트? INNODB MyISAM Archive
  • 28. 02 대형 사이트 구축 전략  서버 구성 전략  스토리지 엔진 선정 전략  인덱싱 전략  파티셔닝 전략  리플리케이션 전략  캐시 전략
  • 29. 인덱싱 전략 인덱스는 많을 수록 무조건 좋다??
  • 30. 인덱싱 전략 분포도 고려하여 “가장 적게” 1 중복된 데이터 많으면 대상 제외! 2 인덱스 많을 수록 효율은 떨어짐!! 3 인덱스도 데이터!
  • 31. 인덱싱 전략 작은 데이터 타입으로.. 1 문자열 인덱스는 최대한 회피 2 CRC32+Trigger로 대체 인덱스 구성 3 인덱스도 데이터! × 𝟐
  • 32. 인덱싱 전략 NULL 허용 금지!! 1 NULL 허용 시 추가 1 Byte 소요 2 인덱스도 데이터!!!
  • 33. 02 대형 사이트 구축 전략  서버 구성 전략  스토리지 엔진 선정 전략  인덱싱 전략  파티셔닝 전략  리플리케이션 전략  캐시 전략
  • 34. 파티셔닝 전략 파티셔닝? Data File File01 File01
  • 35. 파티셔닝 전략 파티셔닝 적용? 1 랜덤 PK시 Clustering 비효율 개선 2 대용량 데이터 날짜 별 관리
  • 36. 파티셔닝 전략 주의 사항 1 Foreign key 사용 불가 2 Full-text 및 Spatial 인덱싱 사용 불가 3 파티셔닝 키는 PK안에 존재해야 함 4 조회 조건에 파티셔닝 키 포함
  • 37. 02 대형 사이트 구축 전략  서버 구성 전략  스토리지 엔진 선정 전략  인덱싱 전략  파티셔닝 전략  리플리케이션 전략  캐시 전략
  • 38. 리플리케이션 전략 “Async”hronous!! 1 슬레이브는 1 Thread에서만 반영 2 Master-Slave 동기화 지연 발생 가능
  • 39. 리플리케이션 전략 동기화 지연 발생 원인 DB 무거운 버그 SQL 과도한 에러 트래픽
  • 40. 리플리케이션 전략 세션 별 Binary Log 포멧 변경 Create Insert Table into As Select Select MIXED? ROW!
  • 41. 리플리케이션 전략 동기화 지연 발생 원인 DB 무거운 버그 SQL 과도한 에러 트래픽
  • 42. 파티셔닝 전략 Must Primary Key!! 1 5.1.57 이전 버전 버그 존재!! 2 Binary Log가 “ROW” 시 비효율 발생!!
  • 43. 리플리케이션 전략 특정 DB만 동기화 전략! user log M service A S1 S3 S2 user service A log
  • 45. 02 대형 사이트 구축 전략  서버 구성 전략  스토리지 엔진 선정 전략  인덱싱 전략  파티셔닝 전략  리플리케이션 전략  캐시 전략
  • 46. 캐시 전략 서비스 특성을 고려!! Query Cache Type ON DEMAND OFF
  • 47. 캐시 전략 제약 조건 1 SQL의 Hash 값을 키로 사용 2 테이블 변경 시 연관된 캐시 전체 소멸 3 쿼리 가지 수가 많으면 비효율 발생
  • 49. 맺음말 1 MySQL은 단순 데이터 처리에 강한 관계형 DBMS이다!!  단일 코어에서 Nested Loop으로 SQL처리
  • 50. 맺음말 2 MySQL에서 대용량 처리는 InnoDB가 적합하다.  트랜잭션과 행 단위 잠금으로 데이터 처리!!  InnoDB에서 Primary Key는 Cluster Index로 구성!!  추가 인덱스는 Primary Key를 Value로..
  • 51. 맺음말 3 MySQL에서 Replication 으로 데이터를 분산 가능하다.  단일 마스터, 다중 슬레이브 구조로 디스크는 독립적  로그 기반으로 비동기적으로 데이터를 복제  슬레이브는 단일 Thread로 데이터를 반영
  • 52. 감사합니다. 플랫폼개발실 / 공통플랫폼팀 대리 / DBA 성동찬 sdchan1@kthcorp.com @gywndi