1. 데이터베이스의 용도와 역할
가. 데이터 조작
•
데이터 검색(Read)
•
데이터 갱신(Insert, Update, Delete)
나. 동시성 제어
•
여러 사용자가 동시에 같은 파일에 대해 갱신하려고 할 때, 데이터베이스는 어떻게 처리할 것인가?
→ 옵션1) 최초로 파일을 사용하는 사용자가 있으면 그 다음의 사용자는 파일을 사용할 수 없음
→ 옵션2) 최초로 파일을 사용하는 사용자가 있으면 그 다음의 사용자는 해당 파일을 읽기 전용으로 사용할 수밖에 없음
→ 옵션3) 최초로 파일을 사용하는 사람이 있어도 그 다음의 사용자는 해당 파일을 읽고 갱신할 수 있음
다. 장애 대응
•
데이터베이스 장애를 어떻게 대비할 것인가?
→ 심장정책: 데이터베이스를 구성하는 요소 하나하나에 신경써서 에러 발생 가능성을 사전 차단
→ 신장정책: 미래에 발생할 에러를 모두 예측하고 예방하는 것은 불가능하므로 에러 발생에 대비함
라. 보안
•
데이터베이스의 보안이라는 목표를 어떻게 달성할 것인가?
→ 사용자의 조작 영역을 클라이언트 계층으로 한정함으로써 데이터베이스를 직접 조작할 수 없음
→ 데이터베이스의 데이터에 대한 접근권한을 상승시켜서 접근 자체를 어렵게 함(심지어 DB 관리자도 접근이 어려움)
마. 정합성과 무결성
•
정합성(Consistency): 데이터가 일관되게 일치함
→ 외래키 제약조건으로도 불림
→ 정합성을 만족하지만 무결성을 만족하지 못하는 경우도 존재
ex) 잘못된 정보가 일관되게 일치하는 경우
•
무결성(Integrity): 데이터가 결함없이 일관되게 정확함을 유지하는 것을 보증
→ 데이터베이스의 주요 목표
2. 관계형 데이터베이스란
가. '관계'란
•
DB에서 관계란 2차원 표를 의미함
•
2차원표의 개념으로 특정 데이터에 접근하는 것은 사람에게 매우 직관적임
나. '2차원 표란'
•
DB에서 2차원 표를 테이블이라 말함
•
테이블은 행(Row)과 열(Column)로 이루어져 있음
•
행과 열이 겹치는 부분을 셀(Cell)이라고 함
다. 'SQL'이란
•
SQL(~~ Language)은 프로그래밍 언어를 몰라도 데이터베이스를 쉽게 이용할 수 있도록 고안됨
•
SQL을 활용하면 프로그래밍 언어의 반복문(for) 또는 제어문(if)을 사용하지 않고 특정 데이터를 쉽게 검색하고 갱신할 수 있음
라. 데이터베이스 vs DBMS
•
데이터베이스는 데이터를 검색하고 갱신하는 시스템에 대한 추상적인 개념
•
DBMS(DataBase Management System)은 데이터베이스를 구현한 소프트웨어
•
MySQL은 관계형데이터베이스를 구현한 DBMS이며 RDBMS로 말할 수 있음
마. 미들웨어로써 데이터베이스
•
미들웨어는 OS와 App 사이에서 구동되는 소프트웨어임
•
미들웨어는 OS의 호환성이 중요하기 때문에 특정 DB를 특정 OS에 설치할 때, 두 소프트웨어 간의 호환성을 고려해야 함
ex) Linux(OS) + SQL Server(DBMS) → 불가능
3. 초기비용과 운영비용
가. 비용 종류
•
초기비용: 라이선스료
•
운영비용: 기술지원 비용 또는 유지보수 비용
→ 초기비용 없이 운영비용만 적용되는 서브스크립션이라는 과금형태 존재
나. 초기비용 O + 운영비용 O
•
일반적인 벤더 제품 ex) SQL Server, Oracle 제품
다. 초기비용 O + 운영비용 X
•
OSS(Open Source Software) 기반 프로그램 ex) MySQL
4. 데이터베이스와 아키텍쳐 구성
가. 신뢰성과 가용성
•
신뢰성: 시스템 컴포넌트가 고장 나지 않는 빈도
•
가용성: 사용자 입장에서 시스템 전체가 고장 나지 않는 빈도
ex) 가용률 99.99%: 서비스 정지 시간(1년에 5분 15초)
나. 가용성을 높이는 기술
•
클러스터링(Clustering): 하나의 저장소에 대해 여러 대의 DB 서버와 연동
•
리플리케이션(Reflecation): 저장소와 DB 서버의 세트를 복사하는 것
다. 클러스터링
•
Shared Disk: 복수의 DB 서버가 하나의 저장소를 공유하는 형태
→ Active-Active: 복수의 DB 서버가 가동되어 있는 상태
→ Active-Standby: 하나의 DB 서버가 가동되어 있고 나머지는 대기하고 있는 상태
→ Hot-Standby: Standby 서버가 작동 상태로 대기, Active 서버의 장애 발생 시 전환시간이 짧음
→ Cold-Standby: Standby 서버가 미작동 상태로 대기, 상대적으로 전환시간이 김
•
Heartbeat: Standby 서버에서 Active 서버의 정상상태를 주기적으로 확인하는 기능
→ Hearbeat 기능에 의해 Active 서버의 비정상상태를 확인하여 서버 전환 동작
라. 리플리케이션
•
동작 방식: 동일한 구조의 시스템을 복제판을 만들고 데이터를 동기화
→ 사회 주요 인프라의 경우, 재해대비 목적으로 리플리케이션 구조 적용
•
마스터 슬레이브: 마스터 세트의 데이터를 슬레이브 세트에 동기화
•
멀티 마스터: 복수의 마스터 세트에서 각각의 데이터를 처리하고 서로에게 데이터를 동기화하는 방식
5. DBMS를 조작할 때 필요한 기본 지식
가. Connection vs Session
•
Connection: 특정 시스템에 연결되는 것
•
Session: DBMS와 연결됨에 따라 여러 데이터를 주고 받는데, 이러한 교환의 시작부터 종료까지를 세션이라고 함
나. SQL 명령과 관리 명령
•
SQL 명령: DB 내 record 조작
→ DDL(Data Definition Language): 스키마 또는 테이블을 작성 또는 제거함
ex) create(테이블 생성), drop(테이블 제거), alter(테이블 변경)
→ DML(Data Manipulation Language): 테이블의 행을 조작함
ex) select, insert, update, delete
→ DCL(Data Control Language): 데이터 제어
ex) commit(변경 확정), rollback(변경 취소)
•
관리 명령: DBMS의 정상동작 여부, 이상 동작 시 에러 해결을 위한 용도로 사용됨
다. 관계형 데이터베이스의 계층
•
관계형 데이터베이스이 계층은 트리형
→ 4계층 구조: 인스턴스 - 데이터베이스 - 스키마 - 테이블
→ 인스턴스: DBMS의 동작단위, OS 입장에서 프로세스, 서버 또는 서버 프로세스라 부르기도 함
→ 스키마: 테이블을 담는 일종의 폴더 역할
•
MySQL에서는 데이터베이스와 스키마를 하나로 묶어서 사용함(스키마 == 데이터베이스 동의어)
→ MYSQL은 3계층 구조: 인스턴스 - 스키마 - 테이블
6. SQL문의 기본
가. 데이터 검색(SELECT)
•
'SQL 연습' 참고
•
연산자의 우선순위
→ 아래와 같은 우선순위에 따라 조건이 결정되므로 주의
→ 소괄호()를 사용하여 우선순위를 강제적으로 지정할 수 있음
select distinct district from city where (countrycode='KOR') and (popularity > 10000);
SQL
복사
•
기초 기술 규칙
→ SQL문에서 대소문자 구분이 없다
→ 문자열, 날짜, 시각은 작은 따옴표로 감싸서 표현한다
•
DISTINCT: 중복 배제
select distinct district from city where countrycode='KOR';
SQL
복사
나. 데이터 검색 응용
•
'SQL 연습' 참고
•
SELECT ~ ORDER BY 열: 검색결과 정렬
→ 정렬 시, 정렬 순서를 일정하게 검색하기 위해 정렬키(키가되는 열)가 고유해야 함
→ 만약 하나의 열이 고유하지 않다면 정렬키를 두 개 이상 섞어도 됨
select * from city where countrycode='KOR' order by district, name;
SQL
복사
•
집약함수: 복수의 행이나 행의 값에 대해 집계
→ COUNT
→ SUM
→ AVG
→ MAX
→ MIN
다. 데이터 갱신(UPDATE, INSERT, DELETE)
•
'SQL 연습' 참고
라. 뷰 작성과 서브쿼리 및 결합
•
'SQL 연습' 참고
7. 트랜잭션과 동시성 제어
가. 트랜잭션이란
•
트랜잭션이란 복수의 쿼리를 하나의 논리적인 단위로 묶은 것
나. ACID 특성
•
Atomicity(원자성): 트랜잭션은 하나의 단위(원자)로써 완전히 성공하거나 완전히 실패하거나 둘 중의 하나만 있음.
→ 트랜잭션을 구성하는 일부 쿼리의 성공 또는 실패는 존재할 수 없음
→ 복수의 쿼리 중 일부의 쿼리에 이상이 발생하면 트랜잭션 전체가 실패
•
Consistency(일관성): DB Object(인스턴스, 스키마, 테이블 등)에 각종 제약사항(Unique 등)을 둠으로써 데이터 조작 전후에도 데이터의 일관성을 유지함
•
Isolation(고립성): 동시다발적인 쿼리를 처리할 때, 마치 순차적 또는 직렬적으로 처리하는 것과 같은 결과를 보장함
•
Durability(지속성): 트랜잭션이 완료(Commit)된 이후 다양한 원인에 따른 장애에도 트랜잭션의 결과를 지속적으로 유지함
→ Disk에 로그를 남겨서 문제 발생 시 rollback 지원
다. MVCC에 따른 MySQL 특성
•
MVCC(Multi Versioning Concurrency Control): RDBMS의 주류 기술로 MySQL도 채택하고 있음
→ 트랜잭션의 고립성을 보장하는 기술로 쿼리의 종류에 따라 쿼리 실행 중에 다른 쿼리의 실행여부를 결정함
•
first transaction SELECT + second transaction SELECT = okay
→ 복수의 쿼리 중 읽기 쿼리에 대해 block 처리 하지 않는다
•
first transaction UPDATE + second transaction SELECT = okay
→ 하나의 DB object에 대해 하나의 쿼리가 쓰기 중 다른 쿼리가 읽는 것에 대해 block 처리하지 않는다
•
first transaction UPDATE + second transaction UPDATE = not okay
→ 하나의 DB object에 대해 복수의 쿼리가 동시에 쓰기를 할 때 두번째 쿼리에 대해 block처리한다
→ 첫번째 트랜잭션이 해당 DB object에 대한 lock갖게 됨으로 이를 반환해야 다른 트랜잭션이 해당 DB object에 쓰기를 수행할 수 있음
→ 두번째 쿼리는 lock timeout 이후에 transaction을 재시도할 수 있음
라. 잠금 타임아웃(Lock timeout)과 교착상태(deadlock)
•
잠금 타임아웃: 하나의 트랜잭션이 특정 DB object에 대한 lock을 소유하고 있는 상태에서 다른 트랜잭션이 해당 DB object에 쓰기를 시도할 때, 잠금 타임아웃 에러가 발생함
→ 후에 들어온 트랜잭션은 설정된 시간이 지난 후에 트랜잭션을 재시도할 수 있음
•
교착상태
→ a라는 트랜잭션이 A라는 DB object에 대한 lock을 소유하고 있는 상태이고 b라는 트랜잭션이 B라는 DB object에 대한 lock을 소유하고 있다고 가정함.
→ 이때 a 트랜잭션이 B DB object에 대해 쓰기를 시도하고 b 트랜잭션이 A DB object에 쓰기를 시도할 때, 각각의 트랜잭션은 lock을 해제할 수 없으므로 교착상태에 빠짐
•
교착상태를 완전히 제거하는 것은 불가능하므로 어플리케이션은 교착상태에 빠질 경우, 트랜잭션을 재실행하는 구조로 설계해야 함
8. 테이블 설계의 기초
가. 테이블 설계의 기초
•
관계형 데이터베이스가 표준이된 이유: 데이터의 정합성을 높이기 위한 설계 노하우가 매우 발달함
•
'테이블'은 공통적인 요소의 집합
→ 테이블의 주제 또는 테이블명과 관련된 속성이 테이블의 열로 정리됨
→ 테이블의 셀은 테이블의 열(테이블의 속성)에 속하는 데이터가 할당되어야 함
•
테이블명은 반드시 복수형이나 집합명사로 표현되어야 함
나. 테이블 설계 규칙
•
테이블 설계 규칙이 필요한 이유: 인간의 무절제한 패턴과 자유도를 그대로 반영하면 성능면에서 문제가 생길 수 있음
•
가장 상위의 개념집합으로 여러 속성을 묶는다
→ 여러 군집의 사람들을 DB로 관리하려면 여러 군집 중 가장 상위의 개념집합을 선택한다
→ ex) 나이별, 회원등급별, 지역별, 실력별로 나뉘지만 '회원'이라는 가장 상위의 개념집합으로 묶일 수 있으므로 테이블명 '회원'으로 여러 속성을 주고 관리하는 것이 효율적임
•
열이란 개체의 속성
→ 테이블의 열은 속성으로 이해할 수 있음
→ 행은 각각의 속성이 실체화된 인스턴스
•
기본키는 고유성, 불변성, not NULL의 특성을 가진다
→ 기본키가 변경되면 특정 데이터의 유일성을 보장할 수 없음
→ 과거 데이터와 결합(매칭)이 불가능
→ NULL: 값이 아니라 '값이 없다'는 것을 나타내는 표시
•
함수의 종속성을 가진다
→ 기본키로 구성된 열의 값에 따라 고유한 record를 찾을 수 있음
다. 정규형
•
제1정규형(1NF): 테이블 셀에 복합적인 값을 포함하지 않는다
→ 복합적인 값의 대표적인 예는 배열이나 리스트
→ RDBMS은 기본적으로 제 1정규형으로 자동으로 만족함
→ 복합적인 값을 넣지 않는 이유는 기본키를 기준으로 행의 고유한 값을 특정할 수 없음
→ 이것은 데이터 정합성에 어긋남
•
제2정규형(2NF): 부분함수 종속성을 제거한다
→ 부분함수 종속성: 기본키를 구성하는 열에 의해 테이블의 일부만 종속됨
→ 테이블을 분리하여 부분함수 종속성을 제거해야 함
→ 테이블 분리의 원칙은 '테이블 설계 규칙'을 참고
→ 부분함수를 제거하는 이유: 새로운 데이터를 삽입할 때, 갱신이상 발생위험이 있음
→ 예제 찾아보자
•
제3정규형(3NF): 추이함수 종속성을 제거한다
→ 추이함수 종속성: 기본키 이외의 열에 특정 열의 고유한 값에 접근할 수 있음
→ 테이블을 분리하여 추이함수의 종속성을 제거
→ 추이함수를 제거하는 이유: 새로운 데이터를 삽입할 때, 갱신이상 발생위험이 있음
9. 성능
가. 성능 측정 지표
•
응답 시간(Response Time): 특정 처리의 시작부터 종료까지 걸리는 시간
ex) GET 요청에 따른 response를 받기까지 5초 소요
•
처리율(Throughput): 특정 단위 시간에 따른 처리 개수
ex) 초당 15만건의 요청 처리
•
처리율이 높아질 수록 하드웨어의 성능도 높아져야 함
→ 병목현상을 방지하기 위해 성능계획(Capacity Plan)을 수립해야 함
나. DB 병목 현상
•
저장소의 경우 scale out에 따른 성능향상에 제한이 있으므로 튜닝을 통해 해결
→ 일반적으로 DB 서버와 저장소는 Active-StandBy, Active-Active로 구성되어 하나의 저장소를 공유하는 구조이므로 설계상 복수의 저장소를 추가할 수 없음
다. SQL 실행 프로세스
•
Parsing(1단계): SQL 질의문 분석 및 비문요소 확인에 따른 에러코드 반환
•
Optimizing: SQL 질의문에서 요구하는 데이터를 어떻게 접근할지에 대한 계획(실행계획)을 결정
→ Optimizer(실행계획 결정하는 내부 프로그램)에 의해 복수의 실행계획 중 하나가 결정됨
→ 사용자가 실행계획을 직접 결정하는 것은 권장되지 않음
→ Optimizing을 세분화 하면 실행계획 작성, 실행계획 평가, 데이터 엑세스로 구분
•
통계정보: Optimizer가 실행계획 수립 시 참고하는 정보
ex) 테이블의 행 또는 열의 수, 테이블 크기 등
라. 인덱스
•
Full Scan vs Range Scan
→ Full Scan: 처음부터 끝까지 접근
ex) SELECT city FROM world
→ Range Scan: 인덱스로 설정된 열에 따라 일부분만 접근
오직 id만 인덱스 열인 경우
ex) range scan O: SELECT city FROM world WHERE id BETWEEN 2900 AND 3100
ex) range scan X: SELECT city FROM world WHERE people BETWEEN 100 AND 200
•
DB 튜닝 선택지 1번으로 인덱스 설정하는 이유는 비용 대비 성능이 높기 때문임
→ SQL 질의문을 변경하지 않아도 성능 개선 가능
→ 테이블의 데이터에 영향 X
→ 일정한 효과 기대 가능
마. 인덱스 작성이 역효과가 나는 예
•
인덱스 열의 데이터를 대상으로 갱신 작업이 많은 경우
→ 인덱스에 대한 갱신 작업이 발생하므로 오버헤드 발생
•
하나의 테이블에 너무 많은 인덱스를 설정한 경우
→ 너무 많은 인덱스가 존재하여 옵티마이저가 낮은 성능의 실행계획을 생성할 가능성 존재
→ 인덱스에 대한 저장 공간 소비
→ 인덱스도 백업 대상인 경우 백업에 많은 시간 소비
바. 인덱스 생성 기준
•
'값의 분산도'가 높은 열에 인덱스 생성
→ 값의 분산도(Cardinality): 특정 열에 존재하는 값의 종류가 다양성을 나타내는 척도
ex) 운전면허증의 운전면허 번호는 Cardinality가 높음, 반면 성별은 Cardinality가 낮음
→ Cardinality가 낮으면 B-Tree 구조로 인덱스가 생성되어도 인덱스 기준으로 이진탐색이 거의 불가능
•
크기가 큰 테이블에만 인덱스 생성
→ 크기가 작은 테이블에는 range scan이나 full scan이나 처리속도 면에서 큰 차이가 없음
•
기본키 제약 또는 유일성 제약이 적용된 열에는 인덱스 생성 불필요
→ 위의 두 제약이 적용된 열에는 자동으로 인덱스가 생성됨
사. B-Tree
•
Balancing: B-Tree(Balanced Tree)는 모든 노드에 대하여 루트 노드에서 리프 노드까지의 거리가 일정하도록 균형을 유지함
→ 인덱스에 대한 갱신 작업 발생 시, 루트 노드에서 리프 노드까지의 거리 균형이 깨지기 때문에 인덱스 재구성을 통해 트리의 균형을 되찾는 작업이 필요함
•
대규모 데이터 처리에 효과적: 데이터 양에 따른 처리시간이 로그함수 곡선의 형태를 보임
→ 데이터의 양이 아무리 많아져도 루트 노드에서 리프 노드까지의 거리는 크게 증가하지 않음
Reference
•
미트, 기무라 메이지, 데이터베이스 첫걸음