- Connection Pool 이 접속 제어
- SQL Support, Parser, Optimizer, Caches&Buffers 등의 앞단에서 쿼리를 처리
- Storage
- MySQL은 Pluggable Storage Engines를 사용 - 다양한 스토리지 엔진을 사용할수 있다
예) InnoDB, MyISAM, 등.
- 어플리케이션에 따라서 스토리지 엔진을 선택하여 사용할 수 있다.
Connection Pool
- 실제적으로는 Thread Pool 임(Thread Reuse 가능)
- 유저의 접속시 쓰레드를 할당함. 프로세스기반의 오라클보다 성능상 이익
- 각각의 쓰레드에 메모리 캐쉬를 할당함
- 유저의 접근 인증을 처리함
- 트래픽이 많은 웹사이트와 어플리케이션에 유리함.
SQL Support
- SELECT, DML, DDL, 스토어드 프로시져, 트리커, 뷰 등을 지원
- SQL에 대한 함수 지원
Parser/Optimizer
- 유저의 오브젝트 접근 권한 확인
- SQL을 데이터베이스 내부 언어로 변환
- 사용자의 SQL요청의 최적화된 처리를 결정
메모리 캐시
- 빈번하게 사용되는 인덱스와 데이터를 메모리에 캐시
- 쿼리 캐시는 Select문과 결과의 조합을 캐시하여 매우 빠른 응답을 지원
- 데이터베이스 메타데이터 메모리 캐쉬를 제공
- 서버전체, 엔진별, 유저별 캐시를 포함
관리도구
- 데이터베이스 관리(MySQLAdmin), 쿼리 브라우징(Query Browser), 데이터 베이스 디자인(WorkBench), 마이그레이션등을 위한 GUI제공
엔터프라이즈 서비스
- 인증,오브젝트별 권한관리, 데이터 암호화의 보안 제공
- 백업,복구,복제,클러스터링 등의 제공
플러그인 스토리지 엔진 구조
- 사용중인 어플리케이션에 맞은 엔진 선택
- 단일 어플리케이션 안에서 여러 스토리지 엔진을 쉽게 조합하여 사용가능
스토리지엔진의 종류별 특징
- 표 참고
MySQL 스토리지엔진별 특징
MyISAM - 기본적인 특징
- 비활성화 할수 없는 기본 스토리지 엔진
- 데이터 저장에 실제적인 제한이 없음(파일시스템의 제한과 동일)
- 데이터를 매우 효율적으로 저장
- 빈번한 데이터 사용(Read)의 부하를 잘 소화
- B-tree,R-Tree, Full-Text 인덱스 지원
- 특정 인덱스에 대한 메모리 캐시지원(데이터는 캐시하지 않음)
- 데이터 압축 옵션 제공(압축하게 되면 ReadOnly가 되지만 디스크효율이 높아짐)
- 지리적 데이터 지원
- 테이블 레벨의 락
- 트랜적션 미지원
- 백업 및 특정 시점으로의 복구 지원
- 적합한 사용처 : 트레픽이 많은 웹사이트(Read트래픽), 데이터 웨어하우스
MyISAM - 테이블의 구성
- 하나의 테이블은 .frm .MYI .MYD 총 3개 파일 사용
- Merge테이블은 .frm이라는 테이블 정의 파일과 .mrg라는 테이블 목록 파일로 이루어짐
예) 동일한 구조의 '월,화...일' 테이블이 있고 '일주일'이라는 통합 테이블이 있는 경우
- .MYI 인덱스 저장파일, 파일의 크기는 1024byte의 배수로 증가
- .MYD 데이터 저장파일, 레코드 길이의 배수로 증가
- .MRG merge테이블에 포함되는 테이블의 목록을 담고 있는 텍스트 파일(트릭사용가능)
MyISAM - Merge
- 여러 동일한 구조의 테이블을 하나의 테이블로 사용
- ALTER TABLE로 추가하거나 삭제 가능
- 테이블에 포함되는 모든 테이블에 대한 권한 필요
- SELECT, INSERT, UPDATE, DELETE 작업을 지원
(INSERT 작업시에는 INSERT_METHOD를 지정해야함)
InnoDB - 기본적인 특징
- ACID 트랜잭션 지원
- 테이블스페이스당 64TB 저장 지원
- MyISAM보다 데이터 저장 비율이 낮음
- 다른 엔진들에 비해서 느린 데이터 로드 속도
- MVCC/Snapshot read 지원
- B-tree, clustered 인덱스 지원
- 데이터와 인덱스 메모리 캐시 지원
- 외부키 지원
- 데이터 압축 옵션을 제공하지 않음
- row레벨 락을 지원 하며 isolation 레벨 지원
- 자동 에러 복구 기능
- 백업 및 특정 시점으로 복구 지원
InnoDB - 적합한 사용처
- 온라인 트랜잭션을 지원하는 어플리케이션
InnoDB - 구조
InnoDB 구조
- Additional Memory Pool - 메타데이터 저장
- 다수의 로그 파일 - 로그작성시 병목 제거
MySQL의 기본적인 DataFile 구조
- Data - Hostname.err(에러로그), Hostname-slow.log(슬로우쿼리로그), Ibdata1 - innodb기본 테이블 스페이스, Ib_logfile0x(innodb redo log파일)
- Data/mysql - 기본적으로 존재
- Data/test - 기본 생성되는 DB 유저 관련 데이터와 인증관련 데이터
- Data/유저생성MyISAM - 테이블명.frm(테이블정보파일), 테이블명.MYI(인덱스), 테이블명.MYD(데이터)
- Data/유저생성InnoDB - 위와 동일, 테이블명.ibd(file per table옵션일 경우 테이블별로 생성되는 스페이스)
InnoDB - 테이블의 구성
- 최소한 하나의 테이블 스페이스와 redo로그 파일
- MyISAM과 호환을 위해 DB별로 디렉토리 생성
- 테이블별 .frm파일 존재
- 테이블별 테이블 스페이스 생성시 .idb라는 테이블 스페이스 파일 생성
- redo로그는 기본적으로 두개의 파일 생성
- 테이블별로 테이블스페이스를 생성하더라도 Undo로그는 테이블이 고유하는 기본 테이블 스페이스에 생성되어 테이블 스페이스 복사로 복제는 불가능
InnoDB와 MyISAM의 성능상 차이
- InnoDB가 디스크 공간은 많이 사용
- InnoDB가 PK기반 Select는 우수함
- InnoDB가 Index Rebuild속도가 느림
- InnoDB가 Count(*)은 MyISAM에 비해 느림
- InnoDB는 Fixed Length row가 없음
InnoDB의 제약
- 최소테이블스페이스 크기 10M(최대 64TB)
- SHOW TALBE STATUS 결과는 근사치결과
- 풀 텍스트 인덱스 지원 안함
- 데드락은 자동으로 검출되며 그런경우 트랜잭션 자동 롤백
Cluster(NDB) - 기본적인 특징
- 트랜잭션 지원
- 모든 데이터와 인덱스 메모리에 저장
- 매우 빠른 데이터 로드 속도
- MVCC/Snapshop read를 지원
- B-tree인덱스 지원
- 프라이머리 키 사용시 최상의 속도
- 99.999% uptime제공
- 클러스터간 어떤것도 공유하지 않는 구조(Shared Nothing)
- SQL API와 함께 고속적근 API제공(이걸 사용해야 최적의 성능)
- 온라인 백업과 특정 시점 복구 지원
Cluster(NDB) - 적합한 사용처
- 고가용성이 필요한 어플리케이션
- 고속의 데이터/키 룹업이 필요한 어플리케이션
- 대량의 사용자의 인증서버
Archive - 기본적인 특징
- 5.0버전에 도입
- 자동적인 데이터 압축지원
- 다른 스토리지 엔진 대비 20%저장공간
- 저장용량 제한 없음
- 가장 빠른 로드 속도(벌크 인서트 최적화)
- MVCC/Snapshot read 제공
- 인덱스 미지원
- 빠른 Insert 속도를 위한 입력 버퍼 지원
- row레벨락 지원
- 백업 및 복구 지원
Archive - 적합한 사용처
- 해를 두고 계속되는 데이터를 위한 데이터 워어하우스
- 데이터 저장 어플리케이션
- 데이터 감사
Federated - 기본적인 특징
- 5.0에 새롭게 도입
- 원격의 물리적 데이터베이스에 대한 논리적 데이터베이스로 사용(DB Link)
- 하나의 데이터베이스에서 다른 타겟오브젝트로의 '포인터'역할
- 원격접근을 위한 미들웨어 필요 없음
- 실행속도는 네트워크 요소에 좌우됨
- SSL보안 처리 가능
- 모든 SQL 오퍼레이션 지원
Federated - 적합한 사용처
- 분산데이터베이스 환경
Memory - 기본적인 특징
- 완전하게 메모리에 존재
- 갑작스런 종료시 데이터 소실
- 너무 많은 메모리 사용제한을 위해서 MAX_ROW를 설정하는 것이 현명함
- Auto_increment 지원
- B-Tree 인덱스 지원
- varchar칼럼 지원(내부적으로는 char와 동일한 형태로 지원)
- 대량의 데이터 로드시 MyISAM에 비해 30% InnoDB에 비해 50% 성능향상
Memory - 테이블 제약
- fixed length레코드만 지원
- BLOG나 Text사용불가
- Hash인덱스는 하나의 row를 찾기 위해 모든 키를 사용
- Hash인덱스는 Where 조건절을 사용할 경우 '='이나'<>'인 경우만 사용가능(하지만 매우빠름)
리플리케이션 아키텍쳐
- 마스터 서버 : Binlog활성화, Slave에서의 접근을 위한 유저 생성
- 슬레이브 서버 : 두개의 쓰레드가 추가 생성
IO-Thread : Binlog모니터링 후 RelayBinlog에 복제
SQL-Thread : RelayBinlog의 내용을 실행
- 구성이 쉽다
- 동작 자체가 명쾌하다
- ASync 동작
다양항 형태의 리플리케이션
- 하나의 마스터 다수의 슬레이브 : 리드 부하분산 및 백업
- 양방향마스터 : 서로서로 마스터 슬레이브 관계, 양방향 장애 대응
- 링형 : 특별한 목적이 있지 않는 한 피해야함
- 피라미드형 : 마스터, 슬레이브/마스터, 슬레이브 형태의 다단계 구조, 넓은 지역을 커버하기 위한 구조(다중 IDC)
댓글 없음:
댓글 쓰기