MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
*If you see the screen is not good condition, downloading please.*
MariaDB Optimization
- 풀 테이블 스캔
- ORDER BY 처리(Using filesort)
- GROUP BY 처리
- DISTINCT 처리
- 임시 테이블(Using Tempoary)
- 인덱스 컨디션 푸시다운(Index Condition Pushdown, ICP)
- 멀티 레인지 리드(Multi Range Read)
- 인덱스 머지(Index merge)
- 테이블 조인
- 서브 쿼리
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
*If you see the screen is not good condition, downloading please.*
MariaDB Optimization
- 풀 테이블 스캔
- ORDER BY 처리(Using filesort)
- GROUP BY 처리
- DISTINCT 처리
- 임시 테이블(Using Tempoary)
- 인덱스 컨디션 푸시다운(Index Condition Pushdown, ICP)
- 멀티 레인지 리드(Multi Range Read)
- 인덱스 머지(Index merge)
- 테이블 조인
- 서브 쿼리
- MariaDB 소개
- MariaDB 서버 구성 및 아키텍처 이해
- MariaDB 스토리지 엔진
- MariaDB 데이터베이스 관리
- 트랜잭션 / Locking 의 이해
- MariaDB 보안
- 백업과 복구를 통한 데이터베이스 관리
- MariaDB upgrade
- MariaDB 모니터링
- MySQL 에서 MariaDB 로의 전환
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
- MariaDB 소개
- MariaDB 서버 구성 및 아키텍처 이해
- MariaDB 스토리지 엔진
- MariaDB 데이터베이스 관리
- 트랜잭션 / Locking 의 이해
- MariaDB 보안
- 백업과 복구를 통한 데이터베이스 관리
- MariaDB upgrade
- MariaDB 모니터링
- MySQL 에서 MariaDB 로의 전환
사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
[국비지원추천]마리아db(maria db) & mysql 기초 및 sql 활용 재직자 향상과정_직장인환급과정/내일배움카드/마리아DB학원/S...탑크리에듀(구로디지털단지역3번출구 2분거리)
"마리아DB(MariaDB) & MySQL 기초 및 SQL 활용 재직자 향상과정 “은
단기간에 MariaDB에 대한 설치 및 설정 부터 기초 쿼리 활용 능력, 서브쿼리, 조인, 쿼리최적화방법, 스토리지 엔진, SQL 실행계획의 분석까지 배울 수 있는 실무/실습위주의 교육 입니다.
Presentation for DEVIEW 2013, developer conference by NHN.
This session have introduced encryption technology, engine-level encryption for MySQL & MariaDB.
This is main technology of MyDiamo.
Although this is Korean one, you can understand what we said.
See more at http://www.mydiamo.com
Thanks.
4. MariaDB
• 개 발 자 : Monty Program Ab
• 발 표 일 : 2009-01-22
• 종 류 : 관계형 데이터베이스 관리시스템(RDBMS)
• 운영체제 : 크로스 플랫폼(윈도, 리눅스, 솔라리스 등)
• 라이선스 : GPL V2 라이선스
• MySQL과 동일한 소스코드 기반
• Oracle의 MySQL 라이선스 반발에 의해 개발됨
MariaDB4
MySQL MariaDB
5.1
5.1
5.2
5.3
5.5 5.5
5.6 10.0
6. 1.1. 인덱스
MariaDB6
• Index 생성시 Create Index 구문 또는 Alter table 구문을 사용
• Index 생성시 metadata lock이 걸리며 이는 인덱스를 생성시 해당
테이블은 R/W lock 발생
• MariaDB의 Index Type은 BTREE, RTREE, HASH 타입 지원
• 인덱스 생성 예시1
• 인덱스 생성 예시2
7. 1.2. 함수
MariaDB7
• 함수 특징
– 스토어드 함수 생성시 함수는 읽기 전용이므로, IN 또는 OUT 파라미터 보유하지 않음
– 정의부에 반드시 Returns 키워드를 이용해 반환되는 값의 타입을 명시
• 함수 생성시 주의 사항
– 생성시 delimiter 명령어를 통해서 종료문자를 변경시킨 후 생성
– 민감한 정보를 저장하는 DB보안을 위해 SQL SECURITY = INVOKER로 사용 권장
9. 1.3. 데이터 타입
MariaDB9
• 숫자 타입
타입 MariaDB Size
Integer Type
BIGINT 8 bytes
DECIMAL(M,D)
DOUBLE 8 bytes
FLOAT 4 bytes
INT 4 bytes
INTEGER 4 bytes
MEDIUMINT 3 bytes
NUMERIC
REAL 8 bytes
SMALLINT 2 bytes
10. 1.3. 데이터 타입
MariaDB10
• 문자 타입
• 주의 사항
– TEXT, Blob 타입을 제외한 전체 칼럼의 크기는 65KB를 초과할 수 없음
(다른 컬럼에서 40KB를 사용하고 있다면 그 레코드의 VARCHAR타입은 24KB만 사용가능)
– CHAR또는 VARCHAR뒤의 지정 숫자는 칼럼의 바이트가 아니라 문자의 수를 의미
타입 설명 예시
CHAR
• 고정길이 칼럼 타입
• 0~255 byte 지원 CHAR(10) : 10개의 문자 저장
VARCHAR
• 가변길이 칼럼 타입
• 0~65536 byte 지원 VARCHAR(10) : 10개의 문자 저장
11. 1.3. 데이터 타입
MariaDB11
• 문자 집합(Character_set)
Character_set 설명
Character_set_system MaraiDB 서버가 식별자를 저장할때 사용하는 문자집함
Character_set_server MariaDB 서버의 기본 문자집합
Character_set_database
DB 생성시 기본 문자집함
Character_set_client Client가 보낸 SQL문장은 이 변수에 설정된 문자집합으로 인코
딩해서 MariaDB서버로 전송
Character_set_connection Client로부터 전달받은 SQL문장을 처리하기 위해 이 변수값으
로 문자집합을 변환
Character_set_results
쿼리 처리 결과를 Client로 전송시 사용하는 문자집함
13. 2.1. 실행 계획
• MariaDB의 옵티마이저는 CBO(Cost-Based Optimizer) 방법으로 산출
• MariaDB의 실행계획은 explain 명령어를 수행하면 확인 가능
– MariaDB의 옵티마이저는 시스템 테이블에 저장된 통계정보로 최적의 실행계획 산출
MariaDB13
14. 2.1. 실행 계획
• 쿼리 실행이 좋은 경우
– Distinct
– Using Index
– Using Index for group-by
• 쿼리 실행이 나쁜 경우
– Using filesort
– Using join buffer
– Using temporary
– Using Where
MariaDB14
15. 3. 쿼리 작성 시 주의사항 및 최적화
MariaDB15
3.1 Sub Query 사용 시 주의사항
3.2 SQL Hint
3.3 쿼리 프로파일링
16. 3.1. Sub Query 사용시 주의사항
• 상관 서브 쿼리
– 외부에서 정의된 테이블의 칼럼을 조회해서 검색을 수행하는 쿼리
– 상관 서브쿼리는 독립적으로 실행되지 못하고 항상 외부쿼리가 실행된 후 그
결과값이 전달되어야 사용 가능
MariaDB16
17. 3.1. Sub Query 사용시 주의사항
• Sub Query 제약 사항
– Sub Query는 대부분 쿼리 문장에서 사용 가능
– LIMIT 절과 LOAD DATE INFILE의 파일명에는 사용 불가
– IN 연산자 안에서 ORDER BY와 LIMIT을 동시 사용 불가
– FROM 절에서는 상관 서브쿼리 형태로 사용 불가
– 서브 쿼리를 이용해 하나의 테이블에 대해 읽고 쓰기를 동시 사용 불가
MariaDB17
18. 3.1. Sub Query 사용시 주의사항
• MariaDB Sub Query 최적화
– WHERE 절에 IN 연산자를 상수와 함께 사용할 때 동등 비교로 처리되므로 최
적화 된 성능 보장
– WHERE 절에 IN 연산자를 서브쿼리를 사용하면 EXISTS형태로 변환되어 상관
서브 쿼리 형태로 실행
– MariaDB에서는 IN + Subquery 형태의 구문에 대해 최적화 실행중
MariaDB18
19. 3.2. HINT
• SQL문에 정보를 주어 SQL문 실행에 빠른 결과를 가져오려는 것
• STRAIGHT JOIN HINT
– 옵티마이저 실행 계획을 무시하고 테이블 순서 대로 JOIN
• USE INDEX
– 가장 자주 사용되는 힌트로 옵티마이저에게 특정 테이블의 인덱스를 사
용하도록 권장
• FORCE INDEX
– USE INDEX보다 옵티마이저에게 더 강한 영향을 주는 힌트
• IGNORE INDEX
– 특정 인덱스를 사용하지 못하도록 옵티마이저를 유도
MariaDB19
20. 3.2. HINT
• 쿼리 캐시 HINT
– MariaDB는 쿼리 캐시를 사용할지 여부를 선택할수 있도록 힌트 제공
– SQL_CACHE
• Query_cache_type이 1 또는 2로 설정되어 있는 경우 쿼리 캐시를 사용
– SQL_NOCACHE
• 어떠한 경우에도 쿼리 캐시 사용 불가
MariaDB20
21. 3.3. 쿼리 프로파일링
• MariaDB는 쿼리가 처리되는 동안 각 단계별 작업 시간에 대한 통계정보 제공
• 쿼리 프로파일링 기능을 통해 쿼리의 성능을 예측
• 프로파일링 활성화
– SET PROFILING=1 or 0 명령어를 이용하여 프로파일링 on/off 가능(default : 0)
• 쿼리 실행 후 각 쿼리에 대한 프로파일 확인
– SHOW PROFILES / SHOW PROFILE
– SHOW PROFILE FOR QUERY <쿼리번호>
– SHOW PROFILE CPU FOR QUERY <쿼리번호>
– SHOW PROFILE SOURCE FOR QUERY <쿼리번호>
MariaDB21
22. 3.3. 쿼리 프로파일링
• MariaDB는 쿼리가 처리되는 동안 각 단계별 작업 시간에 대한 통계정보 제공
• 쿼리 프로파일링 기능을 통해 쿼리의 성능을 예측
• 프로파일링 활성화
– SET PROFILING=1 or 0 명령어를 이용하여 프로파일링 on/off 가능(default : 0)
• 쿼리 실행 후 각 쿼리에 대한 프로파일 확인
– SHOW PROFILES / SHOW PROFILE
– SHOW PROFILE FOR QUERY <쿼리번호>
– SHOW PROFILE CPU FOR QUERY <쿼리번호>
– SHOW PROFILE SOURCE FOR QUERY <쿼리번호>
MariaDB22
23. • 쿼리 프로파일링 활성화
• SHOW PROFILES 결과
3.3. 쿼리 프로파일링
MariaDB23
24. 3.3. 쿼리 프로파일링
• SHOW PROFILE FOR QUERY 6
MariaDB24
• SHOW PROFILE CPU FOR QUERY 6
26. 4.1. 파티션
• 파티션 특징
– MariaDB에서 Partition은 저장할 데이터를 분할하여 관리함으로써
보다 빠른 데이터처리 가능
– Partitioning 하지 않고 하나의 큰 테이블로 사용할 경우
그만큼 인덱스도 커지고 물리적인 공간도 많이 필요
– Partition을 하게 되면 데이터와 인덱스를 조각화하여
물리적 공간을 효율적으로 사용 가능
• 파티션 장점
– 특정 데이터 집합의 추가/삭제가 간편
– 데이터 검색 시 특정 파티션만 읽어서 속도를 향상 가능
– 병렬처리가 가능
– 한 테이블에 너무 많은 데이터가 입력되었을 시 발생하는 속도 저하를 방지
MariaDB26
27. 4.1. 파티션
• 파티션 사용시 주의사항
– 모든 파티션은 동일한 스토리지 엔진 사용
– 테이블과 인덱스를 별도로 파티션 불가(테이블과 인덱스 같이 해야함)
– 파티션 된 테이블은 foregin key를 지원불가
– 파티션 된 테이블은 FullText Index를 지원 불가
– 파티션 된 테이블은 Geometry 칼럼 타입 지원 불가
– 한 테이블당 파티션의 개수는 최대 1024개
– Temp Table 은 파티션 사용 불가
– Partition 값은 반드시 정수형 타입
MariaDB27
28. 4.1. 파티션
• MariaDB 파티션 종류
– Range Partitioning
• 파티션 키의 연속된 범위로 파티션을 정의
• 날짜 기반 데이터가 누적되고 년도,월,일 단위로 분석, 삭제 할 경우
• 범위 기반으로 데이터를 여러 파티션에 균등하게 나눌 수 있을 경우
• 파티션 키 위주로 검색이 자주 실행 될 경우
• 예) 회원 가입 일자별로 분할, 상품 판매 월별로 분할 등…
– List Partitioning
• 파티션 키 값이 코드 값이나 카테고리와 같이 고정 값일 경우
• 키 값이 연속적이지 않고 정렬순서와 관계없이 파티션을 해야 할 경우
• 파티션 키 값을 기준으로 레코드 건수가 균일하고 검색 조건에 파티션 키가 자주 사용 될 때
• 예) 회원 데이터를 지역별로 분할, 판매 데이터를 매장별로 분할 등…
MariaDB28
29. 4.1. 파티션
• MariaDB 파티션 종류
– Hash Partitioning
• Hash 함수에 의해 레코드가 저장될 파티션을 결정하는 방식
• Range, List 로 데이터를 균등하게 나누는 것이 어려울 때
• 테이블의 모든 레코드가 비슷한 사용 빈도를 보이지만
너무 커서 파티션 적용이 필요한 경우
• 예) 상품 주문 일련번호 등
– Key Partitioning
• Hash 파티션과 동일하지만 Hash 값을 계산하는 방법을 사용자가 지정 가능
• 키 파티션은 선정된 파티션 키 값에 대하여 내부적인 함수를 이용하여 Hash값을 계산하고
그 값에 mod를 적용하여 저장할 파티션을 결정
MariaDB29
30. 4.2. 스토어드 프로시저
• MariaDB의 스토어드 프로시저는 독립적으로 호출
• SELECT 나 UPDATE 등의 SQL 문장에서 스토어드 프로시저 참조 불가
• 스토어드 프로시저를 생성 시 주의 사항
– 생성시 DELIMITER 명령어를 통해서 종료문자를 변경시킨 후 생성
– 민감한 정보를 저장하는 DB보안을 위해서 SQL SECURITY = INVOKER로 사용
– 프로시저 생성시 가능하면 DETERMINISTIC 옵션을 정의
– 생성한 프로시저는 CALL 함수를 통해서 호출
MariaDB30
Editor's Notes
마이클 몬티 와이드니어스
대부분의 소프트웨어에 대한 라이선스는 소프트웨어를 공유하거나 수정할 수 있는 자유를 금지하기 위하여 고안되었다.
반면에 GNU 일반 공중 라이선스는 자유 소프트웨어를 공유하고 수정할 수 있는 자유를 보장하기 위해 의도되었다
인덱스란 간단한 용어로 목차 라고 할 수 있다.
- 목차를 지정하여 검색속도가 향상되지만 INSERT, UPDATE, DELETE가 자주 발생한다면 성능이 하락할 수 있다.
쿼리 캐시(Query Cache)는 SELECT 쿼리의 결과(Result Set)을 캐시하고 있다가, 동일한 SELECT 쿼리에 대해서 캐시된 결과를 리턴해 주는 기능이다
자주 사용되거나 복잡한 과정을 가지고 있는 쿼리를 저장하여 하나의 개체로 관리하는 것 - 서버에 미리 컴파일 되어 저장 되어 있음
- SQL서버에는 기본적으로 시스템 정보를 사용하고 갱신하기 위해 여러정보를 스토어드 프로시져로 만들어 master 데이터베이스에 가지고 있음 - 사용자가 원하는 작업을 위해 직접 스토어드 프로시저를 생성할 수 있음