물리 데이터베이스 설계는 논리적 구조로 표현된 논리적 데이터베이스를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터로 변환하는 과정이다.
꼭 포함되어야 할 것은 저장 레코드의 양식 설계, 레코드 집중의 분석 및 설계, 접근 경로 설계 등이 있다. (참고: 목표 DBMS에 맞는 스키마 설계는 어느 단계? -> 논리적 설계 단계에서 수행!)
여기서 레코드란 필드의 집합으로써, 예를 들어 Person이라는 하나의 레코드는 id, name, age, job으로 표현되는 4개의 필드로 구성된다.
데이터베이스에 데이터를 저장하려면 테이블이나 컬럼 등 실제 데이터가 저장되는 공간(저장 레코드의 양식 설계!)을 정의해야 한다. 테이블, 컬럼, 데이블스페이스의 개념과 특징을 알아놓자.
테이블
테이블은 논리 설계 단계의 개체에 대응하는 객체이다. (잠깐! 논리 데이터베이스의 구성요소는 개체, 관계, 속성을 잊지 말자) 테이블의 종류로는
- 일반 테이블
- 클러스터드 인덱스 테이블(기본키나 인덱스키의 순서에 따라 데이터가 저장되는 테이블로 일반적인 인덱스를 사용하는 테이블에 비해 접근 경로가 단축되는 장점이 있다. 밑에 내려가면 인덱스키에 대한 설명이 있음)
- 파티셔닝 테이블(대용량의 테이블을 작은 논리적 단위인 파티션으로 나눈 테이블이다. 대용량의 테이터를 효과적으로 관리할 수 있지만 파티션 키를 잘못 구성하면 성능 저하가 발생한다. 종류: 범위 분할(연도를 기준으로 나눈다는지), 해시 분할(특정 파티션에 데이터가 집중되는 범위 분할의 단점을 보완해 고르게 분할하는 방법. 이 방법은 특정 테이터가 어디 있는지 알 수 없다는 단점이 있다), 조합 분할(범위 분할 후 해시 함수를 적용해서 또 분할한 것))
- 외부 테이블(외부 파일이라고 생각하면 쉽다. 테이터 웨어하우스(주요 업무 시스템에서 추출된 새로이 생성된 데이터베이스!)에서 ETL(추출, 변환 적재하는 일련의 과정) 등의 작업에 유용하게 사용됨)
- 임시 테이블(트랜젝션이나 세션별로 데이터를 저장하고 처리할 수 있는, 즉 절차적인 처리를 위해 임시로 사용하는 테이블)
테이블스페이스
테이블스페이스는 테이블이 저장되는 논리적인 영역이다. (영어 그대로 해석하면 테이블 공간) 하나의 테이블스페이스에 하나 이상의 테이블을 저장할 수 있다. 테이블을 저장하면 논리적으로는 테이블스페이스에 저장되고 물리적으로는 해당 테이블스페이스와 연관된 데이터 파일(Data File)에 저장된다. 이렇게 테이블스페이스, 데이터 파일 등으로 나눠 관리하면 논리적 구성이 물리적 구성에 종속되지 않아 투명성이 보장된다.
트랜잭션 분석 / CRUD 분석
먼저, 데이터의 무결성을 보장하기 위해 DBMS의 트랜잭션이 가져야 할 특성은 ACID 외우자.
- Atomicity(원자성) : 트랜잭션 내의 모든 명령은 반드시 완벽하게 수행되어야 하거나 어느 하나가 오류가 발생하면 전부가 취소 되어야 하는 특성
- Consistency(일관성) : 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환
- Isolation(독립성) : 한 트랜잭션 실행 중에 다른 트랜잭션의 연산이 끼어들기 NO!
- Durability(지속성) : 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나도 지속적으로, 영구적으로 반영되어야 함
CRUD 분석은 테이블에 발생하는 트랜잭션을 분석해 물리적 테이터베이스 설계 시 구조를 최적화하는 목적이 있다. 책에 있는 표를 보면 금방 이해 될 것이므로 몇가지만 정리하자.
- 각 셀에 CRUD를 적어야 하며 복수의 변화를 줄 때는 우선 순위는 CDUR 순으로 (씨디유알로 외우자) 한가지만 적어야 하지만 모두 기록도 가능하다.
- 프로세스에는 C나 R이 없을 수 있다. (신규 회원 테이블을 만드는 경우 Create 연산만 수행 가능)
트랜잭션 분석의 목적은 CRUD 매트릭스를 기반으로 테이블에 발생하는 트랜잭션 양을 분석하는데, 데이블에 저장되는 데이터 양을 유추하고 이를 근거로 DB용량을 산정하고 DB구조를 최적화하는 것이다. 트랜잭션 분석을 통해 프로세스가 과도하게 접근하는 테이블을 확인하여 여러 디스크에 배치함으로써 성능 향상을 가져올 수 있다.
인덱스 설계
인덱스는 데이터 레코드를 빠르게 접근하기 위해 <키 값, 포인터> 쌍으로 구성되는 데이터 구조이다. 인덱스가 없으면 특정한 값을 찾기 위해 모든 데이터 페이지를 확인하는 테이블 스켄이 발생한다. 랜덤 엑세스가 빈번한 테이블일 경우 인덱스 설계하면 좋다.
- 트리 기반 인덱스 : 이 구조는 인덱스를 저장하는 블록들이 트리 구조를 이루고 있는 형태이다. 루트 노드(상위 노드)에서 하위 노드로 키 값의 크기를 비교해 나가면서 찾고자 하는 데이터를 검색한다=B트리 인덱스. B+ 트리 인덱스는 트리 전체를 도는 B트리 인덱스를 보완한 것이라고 생각하자.
- 비트맵 인덱스 : 인덱스 컬럼의 데이터를 Bit 값인 0 또는 1로 변환하여 인덱스 키로 사용하는 방법이다. 예를 들어 빨간색은 101, 노란색은 100, 검정색은 111등으로 이렇게 구성되어 있어서 다중조건을 만족하는 튜플의 개수 계산에 적합하다고 한다.
- 함수 기반 인덱스 : 컬럼에 특정 함수나 수식을 적용하여 산출된 값을 사용, B+트리 인덱스 또는 비트맥 인덱스를 생성하여 사용한다.
- 비트맵 조인 인덱스 : 다수의 조인된 객체로 구성된 인덱스
- 도메인 인덱스 : 개발자가 필요한 인덱스를 직접 만들어 사용하는 것
레코드의 삽입과 삭제가 수시로 일어나는 경우는 인덱스의 개수를 최소로 하는 것이 좋다. 왜냐하면 테이블에 레코드를 삽입 또는 삭제할 때는 인덱스도 변경해야 하는데, 인덱스의 개수가 많을 경우 삽입과 삭제 시 매번 모든 인덱스를 갱신하느라 속도가 느려지기 때문이다.
뷰 설계
뷰는 사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 데이블로부터 유도된, 이름을 가지는 가상 테이블이다. 뷰는 저장장치 내에 물리적으로 존재하진 않지만, 사용자에게는 있는 것처럼 간주된다. 뷰를 통해서만 데이터에 접근하게 되면 뷰에 나타나지 않는 데이터를 안전하게 보호하는 효율적인 기법으로 사용할 수 있다.
참고 : 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동으로 삭제된다!
뷰의 단점
- 독립적인 인덱스를 가질 수 없다.
- 뷰의 정의를 변경할 수 없다.
- 뷰로 구성된 내용에 대한 삽입, 삭제, 갱신 연산에 제약이 따른다.
클러스터 설계
클러스터링은 비슷한 종류끼리 묶어준다는 의미로 기억하자. 글로 설명하는 것보다 아래 그림을 참고하는게 더 이해가 쉬울 것 같아서 첨부하였다.
<부서>테이블과 <사원>테이블이 '부서번호' 필드를 기준으로 클러스터링 되었다. 이런 경우 '부서번호'를 클러스터링키라고 한다.
클러스터링된 테이블은 데이터 조회 속도는 향상시키지만 데이터 입력, 수정, 삭제에 대한 성능은 저하시킨다. 또한 클러스터는 데이터의 분포도(전체 레코드 중 조건에 맞는 레코드의 숫자가 적은 경우 분포도가 좋다고 말함. 분포도를 선택성이란 용어로 사용하기도 한다)가 넓을수록 유리하고(인덱스는 분포도가 좁은 테이블은 좋지만 클러스터링은 분포도가 넓은 데이블에 유리하다) 데이터 분포도가 넓은 테이블을 클러스터링 하면 저장공간을 절약할 수 있다. 즉 클러스터링된 테이블은 클러스터링키 열을 공유하므로 저장 공간이 줄어든다! 하지만 대용량을 처리하는 트랜색션은 전체 테이블을 스캔하는 일이 자주 발생하므로 클러스터링을 하지 않는 것이 좋다.
클러스터 대상 테이블 : 분포도가 넓은 테이블, 대량의 범위를 자주 조회하는 테이블, 입력 수정 삭제가 자주 발생하지 않는 테이블, 자주 조인되어 사용되는 테이블
파티션 설계
장단점 간단하게 정리하면, 파티션의 장점은 데이터 접근 시 엑세스 범위를 줄여 쿼리 성능이 향상되고 파티션별로 데이터가 분산되어 저장되므로 디스크의 성능이 향상된다. 허나 단점은 하나의 테이블을 세분화해서 관리해서 세심한 관리가 요구되고 테이블간 조인에 대한 비용이 증가한다. 또한 용량이 작은 테이블을 파티셔닝 수행하면 오히려 성능이 저하된다.
인덱스 파티션은 파티션된 테이블의 데이터를 관리하기 위해 인덱스를 나눈 것이다.
- Local Partiotioned Index : 테이블 파티션과 인덱스 파티션이 1:1 대응
- Global Partitioned Index : 테이블 파티션과 인덱스 파티션이 독립적으로 구성
Local이 Global에 비해 데이터 관리가 쉽다. 왜냐하면 테이블 파티션과 인덱스 파티션의 범위가 동일하기 때문이다.
분산 데이터베이스 설계
논리적으로는 하나의 시스템에 속하지만 물리적으로는 네트워크를 통해 연결된 분산되어 있는 데이터베이스. 4대 목표를 암기하는 것이 좋다.
- 위치 투명성(Location Transparency)
- 중복 투명성(Replication Transparency)
- 병행 투명성(Concurrency Transparency)
- 장애 투명성(Failure Transparency)
데이터베이스 이중화 / 서버 클러스터링
데이터베이스 이중화는 시스템 오류로 인한 데이터베이스 서비스 중단이나 물리적 손상 발생 시 이를 복구하기 위해 동일한 데이터베이스를 복제하여 관리하는 것이다. 변경 내용 전달 방식은 2가지로 나눠지는데 영어 단어대로 생각하면 쉽다. Eager 기법(트랜잭션 수행 중 데이터 변경이 일어나면 즉시 내용이 전달되어 적용되는 기법), Lazy 기법(트랜잭션 수행이 종료되면 변경 사실을 각 데이터베이스에 전달하는 기법)
데이터베이스 이중화 구성 방법에는 활동-대기 방법(한 DB는 활성 상태로 서비스, 다른 DB는 대기 상태.. 장애 시 출동)과 활동-활동 방법(두 개의 DB 모두 활동 중)이 있다.
서버 클러스팅 - 두 대 이상의 서버를 하나의 서버처럼 운영하는 기술. 고가용성 클러스터링(하나의 서버에 장애가 발생하면 다른 서버가 처리해서 서버가 중단되는 것을 막는다), 병렬 처리 클러스터링(하나의 작업을 여러 개의 서버에서 분산하여 처리하는 방식)
데이터베이스 보안 / 암호화
암호화 기법 중 암호화 알고리즘과 암호화키는 공개해서 누구든지 평문을 암호문으로 만들 수 있지마. 해독 알고리즘과 해독키는 비밀로 유지하는 기법(관리자가 비밀리에 관리)을 공중키 암호화 기법(공개키 암호화 기법)이라고 한다. 즉 서로 다른 키로 데이터를 암호화하고 복호화한다. 이와 반대로 동일한 키로 데이터를 암호화하고 복호화하는 방법을 개인키 암호화 방식=비밀키 암호화 방식=대칭 암호 암식=단일키 암호화 기법이라고 한다. 대표적으로 DES가 있다.
시간 관계상 다 올리지 못하였습니다. 뒷 내용은 시간 나면 올리겠습니다.