DB 정리 - 데이터 모델과 성능

▶ 성능 데이터 모델링이란?

- 데이트베이스 성능 향상을 목적으로, 데이터 모델 설계 시점부터 정규화, 반정규화, 테이블 통합, 테이블 분할, 조인 구조, PK, FK 등 여러 가지 성능과 관련된 사항들이 데이터 모델링 작업에 반영될 수 있도록 하는 것.

- 성능 데이터 모델링은 IT 시스템 구축 프로젝트 전체 일정(분석/설계 → 구현 → 테스트 → 운영)에서 가장 앞 단계에서 할수록 성능 저하에 따른 비용을 감소시킴.

 

 

> 성능 데이터 모델링 시 고려사항

- 데이터 모델링 시 정규화 작업을 수행

- DB의 용량 산정

- DB에 발생되는 트랜잭션 유형 파악

- DB 용량 및 트랜잭션의 유형에 따라 반정규화 수행

- 이력 데이터 모델의 조정, PK/FK 조정, 슈퍼/서브 타입 변환 조정 등을 수행

- 성능 관점에서 데이터 모델 검증

 

 

▶ 정규화와 성능

- 정규화된 모델은 주요 관심사별로 데이터를 분산시키는 효과가 있으므로 그 자체로 성능을 향상시키는 효과 있음

- 정규화를 수행한다는 것은 데이터를 결정하는 결정자에 의해 함수적 종속을 가지고 있는 일반 속성을 의존자로 하여 입력/수정/삭제 이상현상을 제거하는 것.

- 정규화 작업은 데이터의 중복 속성을 제거하고, 결정자에 의해 동일한 의미의 일반 속성이 하나의 테이블로 집약되므로 한 테이블의 데이터 용량이 최소화됨.

↳ ex) 사원 테이블에서 사원번호가 '1000'인 직원의 사원명이 '홍길동'일때, 사원명 컬럼은 사원 테이블에만 존재하면 됨. 또한 사원번호가 사원명을 결정할 수 있으므로 "사원명은 사원번호에 함수적으로 종속된다"로 표현가능.

 

 

▷ 정규화 용어

정규화 (Normalization)	함수적 종속성 등과 같은 이론에 근거하여 관계형 데이터베이스 테이블의 삽입/삭제/갱신 이상 현상 발생을 최소화하기 위해 좀 더 작은 단위의 테이블로 설계하는 과정. 즉 정규화는 데이터 모델을 정규형에 맞도록 고치는 과정이라 할 수 있음.
정규형 (NF : Normal Form)	정규화한 결과. 정규화 결과에 의해 도출된 데이터 모델이 갖춰야 할 특성을 만족한 형태
함수적 종속성 (FD : Functional Dependency)	테이블의 특정 컬럼 A의 값을 알면 다른 컬럼 B 값을 알 수 있을 때, 컬럼 B는 컬럼 A에 함수적 종속성이 있다라고 표현.
결정자 (Determinant)	함수적 종속성 설명에서 컬럼 A에 해당하는 것을 결정자라고 함. (ex. 주민번호는 고객명을 결정하므로 주민번호는 고객명의 결정자)
다치종속 (MVD : MultiValued Dependency)	결정자 컬럼 A에 의해 컬럼 B의 값을 다수 개 알 수 있을 때, 컬럼 B는 컬럼 A에 다치종속되었다고 함

 

 

> 정규화 효과 및 장점

- 정규화는 상호 종속성이 강한 데이터 요소들을 분리, 독립된 개념(엔티티, 테이블)으로 정의하게 됨에 따라 높은 응집도 + 낮은 결합도 원칙에 충실해지며, 이로 인해 유연성이 극대화됨. (해당 개념에 대한 재활용 가능성 높아짐)

- 정규화는 식별자가 아닌 속성이 한번만 표현됨에 따라 중복이 최소화됨. 이에 따라 데이터 품질이 확보되고 저장공간이 절약되며, DML 처리시 성능이 향상됨.

- 1차, 2차, 3차, 보이스-코드 정규화는 함수 종속성에 근거하여 정규화를 수행하고, 4차 정규화는 속성의 값이 여러개 발생하는 다치종속, 5차 정규화는 조인에 의해 발생하는 이상현상제거로 정규화 수행.

 

 

⦁ 제1 정규형

- 한 속성에 여러 개의 속성값을 갖거나 같은 유형의 속성이 여러개인 경우 해당 속성을 분리시켜야 함을 의미.

 

연락처

010-1111-1111, suldenlion@naver.com

010-2222-2222, suldentiger@naver.com

010-3333-3333, suldendog@gmail.com

010-4444-4444, suldencat@gmail.com

↳ 연락처 속성에 전화번호와 이메일 주소가 같이 들어 있으므로 제1 정규형을 위반함.

↳ 기존 엔티티의 연락처 속성을 제거하고 전화번호와 이메일을 분리한 엔티티를 추가하면 제1 정규형을 만족할 수 있음.

 

 

⦁ 제2 정규형

- 제2 정규형은 제1 정규형을 만족하고 모든 PK가 아닌 컬럼은 PK 전체에 종속되어야 함.

- PK에 종속적이지 않거나 PK 중 일부 컬럼에만 종속적인 컬럼은 분리되어야 함.

 

고객아이디	주문순번	고객명	고객등급
A0001	1	홍길동	프리미엄
A0001	2	홍길동	프리미엄
A0002	1	김자바	일반
A0002	2	김자바	일반

↳ 위의 고객주문 엔티티의 PK가 고객아이디+주문순번일 때, 고객명과 고객등급 속성은 해당 엔티티의 복합식별자에 완전 종속되지 않음. (고객아이디 컬럼에만 종속됨)

↳ 이런 경우, 갱신 시에 갱신 이상이 발생할 가능성이 존재하고 주문 시마다 고객정보를 중복으로 저장해야함. 또한 고객정보를 모르면 주문 자체가 불가능한 구조가 됨.

↳ 고객 엔티티를 추가하여 고객아이디를 PK로 하여 고객명과 고객등급 속성을 관리해야 함.

 

 

⦁ 제3 정규형

- 제3 정규형은 제2 정규형을 만족하고 일반 속성들 간에도 함수 종속 관계가 존재하지 않아야 함.

- 제3 정규형을 만족하려면 일반 속성들 간 종속 관계가 존재하는 것들은 분리되어야 함.

 

고객아이디	고객명	나이	직업코드	직업명
A0001	홍길동	36	X001	SQL 개발자
A0002	김자바	27	X002	건축사
A0003	박디비	25	X003	용접공

↳ PK는 고객아이디이며, 고객아이디 속성을 제외하고 일반 속성인 직업코드와 직업명 속성 간에 함수 종속이 발생함. (직업명은 직업코드가 정하기 때문에 직업명은 직업코드에 함수 종속). 

↳ 식별자를 제외한 일반 속성 간에 함수 종속이 발생하는 경우 제3 정규형 위반.

↳ 제3 정규형을 만족하려면 직업코드와 직업명을 직업 엔티티로 따로 추가해야 함.

 

 

▷ 정규화와 성능

- 정규화를 수행한 후, 전에 없었던 조인이 발생하게 되더라도 효율적인 인덱스 사용을 통해 조인 연산을 수행하면 성능상의 단점은 거의 없음.

- 정규화를 수행한 후, 적은 용량의 테이블이 생성된다면 조인 연산시 적은 용량의 테이블을 먼저 읽어 조인을 수해앟면 되므로 성능상 유리함.

- 정규화가 제대로 되지 않으면 비슷한 종류의 속성이 여러개가 되어 과도하게 많은 인덱스가 만들어질 수 있음. (정규화시 하나의 인덱스만 만들어도 됨)

 

 

> 함수적 종속성에 근거한 정규화 수행 필요

- 함수적 종속성은 데이터들이 어떤 기준값에 의해 종속되는 현상을 지칭하는 것. 이때 기준값을 결정자(Determinant)라 하고 종속되는 값을 종속자(Dependent)라고 함.

 

 

▶ 반정규화와 성능

- 반정규화는 시스템의 성능 향상 및 개발과 유지보수의 단순화를 위해 정규화된 데이터 모델을 분석하여 엔티티/속성/관계를 중복, 통합, 분리 등의 작업으로 수행하는 데이터 모델링 기법을 의미함.

- 일반적으로 반정규화는 데이터를 고의적으로 중복 저장하여 조회 성능을 향상시키기 위한 기법이라고 정의할 수 있음. (데이터를 중복 저장함으로써 조인 연산이 회피되어 성능이 향상됨)

- 더 넓은 의미의 반정규화는 조회 성능을 향상시키기 위해 정규화된 데이터 모델에서 중복, 통합, 분리 등을 수행하는 모든 과정을 의미함.

- 데이터 무결성이 깨질 수 있는 위험을 무릅쓰고 데이터를 중복하여 반정규화를 적용하는 상황은 데이터를 조회할 때 디스크 I/O량이 많아서 성능이 저하되는 경우, 테이블 간 경로가 너무 멀어 조인으로 인한 성능 저하가 예상되는 경우, 컬럼을 계산하여 읽을때 성능이 저하될 것이 예상되는 경우가 있음.

 

 

> 반정규화의 절차

- 반정규화가 필요하다가 판단시 컬럼의 반정규화, 테이블의 반정규화, 관계의 반정규화를 종합적으로 고려하여 적용해야 함.

 

① 반정규화 대상 조사 

- 범위 처리 빈도수 조사

- 대량의 범위 처리 조사

- 통계성 프로세스 조사

- 테이블 조인 개수

② 다른 방법 유도 검토 (반정규화의 대상에 대해 다른 방법으로 처리할 수 있는지 검토) 

- 뷰 테이블

- 클러스터링 적용

- 인덱스의 조정

- 응용 애플리케이션 변경

③ 반정규화 적용

- 테이블 반정규화

- 속성의 반정규화

- 관계의 반정규화

 

 

> 반정규화 기법

⦁ 테이블 반정규화 기법

테이블 병합	1:1 관계 테이블 병합	- 1:1 관계를 통합하여 성능을 향상시키는 방법 - 2개의 테이블을 하나의 테이블로 병합하여 테이블 간 조인 연산 제거
	1:M 관계 테이블 병합	- 1:M 관계를 통합하여 성능을 향상시키는 방법 - 2개의 테이블을 하나의 테이블로 병합하여 테이블 간 조인 연산 제거
	슈퍼/서브 타입 테이블 병합	- 슈퍼/서브 관계를 통합하여 성능을 향상시키는 방법 - 슈퍼/서브 타입 관계를 하나의 테이블로 병합하여 조인 연산 제거
테이블 분할	수직 분할	- 컬럼 단위의 테이블을 디스크 I/O 분산 처리하기 위해 테이블을 1:1로 분리하여 성능을 향상시키는 방법으로, 트랜잭션이 처리되는 유형 파악이 선행되어야 함.
	수평 분할	- 로우 단위로 집중 발생되는 트랜잭션을 분석하여 디스크 I/O 및 데이터 접근 효율을 높여 성능을 향상하기 위해 로우 단위로 테이블을 쪼개는 방법.
테이블 추가	중복 테이블 추가	- 다른 업무이거나 서버가 다른 경우 동일한 테이블 구조를 중복하여 원격 조인을 제거하여 성능 향상
	통계 테이블 추가	- SUM, AVG 등을 미리 수행하여 계산해둠으로써 조회시 성능 향상
	이력 테이블 추가	- 이력 테이블 중에서 마스터 테이블에 존재하는 레코드를 중복하여 이력 테이블에 저장하는 반정규화 기법
	부분 테이블 추가	- 특정 테이블에서 전체 컬럼 중 자주 조회하는 집중화된 컬럼들이 있을때, 디스크 I/O를 줄이기 위해 해당 컬럼들을 모아놓은 별도의 반정규화된 테이블 생성

↳ 테이블 병합은 여러 개의 테이블을 하나의 테이블로 합치는 것. (데이터의 중복 저장이 발생하지만 조회 성능 향상을 위해 병합)

↳ 테이블 분할은 특정 테이블을 여러 개의 테이블로 쪼개는 것.

↳ 테이블 추가는 특정 테이블을 추가하여 데이터의 중복 저장이라는 비효율이 발생하는 것을 감안하더라도 조회 성능을 높이기 위한 방법.

 

 

⦁ 컬럼 반정규화 기법

중복 컬럼 추가	- 조인 연산으로 인한 성능 저하를 예방하기 위해 중복 컬럼을 추가하여 조인 연산을 하지 않도록 함
파생 컬럼 추가	- 트랜잭션이 처리되는 시점에 계산에 의해 발생되는 값의 성능 저하를 예방하기 위해 미리 값을 계산하여 컬럼에 보관
이력 테이블 컬럼 추가	- 대량의 이력 데이터를 처리할때 불특정한 날 조회나 최근 값을 조회할때 나타날 수 있는 성능 저하를 예방하기 위해 이력 테이블에 컬럼 추가.
PK에 의한 컬럼 추가	- 복합의미를 갖는 PK를 단일 속성으로 구성하였을 경우 단일 PK 안에서 특정 값을 별도로 조회하는 경우 성능 저하가 발생할 수 있음. - 이때 이미 PK 안에 데이터가 존재하지만 성능 향상을 위해 일반 속성으로 생성하는 방법이 PK에 의한 컬럼 추가 반정규화.
응용 시스템의 오작동을 위한 컬럼 추가	- 비즈니스적으로 의미가 없지만 사용자가 데이터 처리를 하다가 잘못 처리하여 원래의 값으로 복구를 원하는 경우 이전 데이터를 임시적으로 중복하여 보관하는 기법 - 컬럼으로 이것을 보관하는 방법은 오작동 처리를 위한 임시적인 기법이지만, 이것을 이력 데이터 모델로 풀어내면 정상적인 데이터 모델의 기법이 될 수 있음.

 

 

⦁ 관계 반정규화 기법

중복 관계 추가

데이터를 처리하기 위한 여러 경로를 거쳐 조인이 가능하지만, 이때 발생할 수 있는 성능 저하를 예방하기 위해 추가적인 관계를 맺는 방법

- 여러 경로에 걸쳐서 조인하는 경우 조인 연산을 줄여주게 되어 조회 성능을 향상시키는 방법. (ex. A → B → C 조인을 A → C 조인으로 만듦)

- 테이블과 컬럼의 반정규화는 데이터 무결성에 영향을 미치게 되나, 관계의 반정규화는 데이터 무결성을 깨뜨릴 위험을 갖지 않고서도 데이터 처리의 성능을 향상시킬 수 있는 반정규화 기법.

 

 

▷ 대량 데이터에 따른 성능

- 대량의 데이터가 존재하는 테이블에 많은 트랜잭션이 발생하여 성능이 저하되는 테이블 구조는 수평/수직 분할 설계를 통해 성능 저하를 예방할 수 있음.

- 수평 분할은 행 단위로 분할하여 Input/Output을 감소시키는 방법. (ex. 1년치 데이터가 대용량인 경우 월별로 분할하여 저장한다면 특정 월을 조회하는 경우에는 해당 월만 조회하면 됨)

- 수직 분할은 컬럼 단위로 분할하여 I/O를 감소시키는 방법. (ex. 고객의 생년월일, 주소 등의 개인정보와 취미/특기 등의 기타정보를 별도로 저장 가능)

 

 

> I/O에 대한 추가 정보

- 테이블 내에 모든 행은 블록 단위로 디스크에 저장됨

- 오라클 DBMS 기준 1개의 블록은 8,192 바이트. 각 블록이 모여서 테이블의 데이터를 이루게 됨.

- 컬럼이 많아지게 되면 하나의 행을 저장시 물리적인 디스크에 여러 블록에 걸쳐 데이터가 저장될 가능성이 높아짐. 이런 경우 하나의 행을 읽더라도 여러개의 블록을 읽어야 함.

- 특정 테이블에서 한 행의 용량이 8,193 바이트라고 가정하면 하나의 행을 읽더라도 2개의 블록을 읽게됨. (8,191 바이트 낭비됨)

- SQL 문의 블록 I/O의 수가 많아지게 되어 성능 저하 발생

 

 

> 성능 저하 현상

로우 체이닝 (Row Chaining)	- 로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고, 2개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태. - 하나의 행을 읽을때 2개 이상의 데이터 블록을 읽게 될 수 있음. - 절대적으로 읽어야 할 데이터 블록의 수가 늘어나면서 성능이 저하됨
로우 마이그레이션 (Row Migration)	- 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고, 다른 블록의 빈 공간을 찾아 저장하는 방식. - 해당 현상이 일어나면서 하나의 행을 읽을때 2개 이상의 데이터 블록을 읽게 됨. - 로우 체이닝 현상과 마찬가지로 절대적으로 읽어야 할 데이터 블록의 수가 늘어나면서 성능이 저하됨.

↳ 로우 체이닝과 로우 마이그레이션이 발생하여 많은 블록에 데이터가 저장되면 데이터 조회시 절대적인 블록 I/O 횟수가 많아짐.

↳ 블록 I/O의 횟수가 많아지면 Disk I/O를 할 가능성도 높아짐. (Disk I/O = 특정 블록을 DB 내 메모리에서 찾을수 없어 디스크를 읽게되는 상황 / 고비용의 작업이므로 DBMS 성능 저하를 유발함)

 

 

> 한 테이블에 많은 수의 컬럼을 가지는 경우의 성능 저하

- 많은 수의 컬럼을 가지고 있는 테이블을 조회할 때, SQL문이 실행될 떄마다 도서정보 테이블에 있는 모든 컬럼을 읽게 되고, 그중 조회대상이 아닌 컬럼은 버려지게 되어 불필요한 블록 I/O 수가 많아짐. (블록 I/O가 많아지면 디스크 I/O의 양도 증가 → DBMS의 전체 성능이 저하됨)

- 이런 경우 테이블을 수직 분할하면 성능이 향상될 수 있음.

• 테이블에 대한 트랜잭션이 독립적으로 발생되는 경우가 많아 1:1 관계로 수직 분할함.
• 분리된 테이블은 컬럼의 수가 적어지므로, 1개의 행을 읽기 위해서 절대적으로 읽어야 할 데이터 블록의 수가 줄어들어 로우 마이그레이션과 로우 체이닝 현상이 감소함.
• 조회시에도 디스크 I/O가 줄어들어 성능이 좋아짐

 

> 한 테이블에 많은 수의 행을 가지는 경우의 성능 저하

- 대형 통신사와 같이 매월 수천만 건씩 내용이 저장되는 요금 테이블은 행의 수가 많아서 SQL문의 성능이 저하될 수 있음.

- 테이블의 저장 건수가 매우 많을 때 수평 분할하여 성능을 향상 시킬 수 있음.

- 수평 분할을 파티셔닝이라고 하며 특정 기간으로 분할하는 것을 범위 파티셔닝이라고 함.

- 요금 테이블의 특성상 월단위로 데이터 처리를 하는 경우가 많으므로 요금일자와 같은 PK 컬럼을 이용하여 월별로 12개의 파티션 테이블을 생성. 이렇게 하면 보관 주기에 따라 테이블에 데이터를 쉽게 지우는 것이 가능하믈 데이터 보관 주기에 따른 테이블 관리가 용이함.

 

⦁ 리스트 파티셔닝 : 고객 테이블에 데이터가 1억 건이 있는데 하나의 테이블에서 데이터를 처리하기에는 SQL문의 성능이 저하되어 지역을 나타내는 사업소 코드별로 리스트 파티셔닝 적용.

- 리스트 파티셔닝은 대용량 데이터를 특정 값에 따라 분리 저장할 수는 있으나 범위 파티셔닝과 같이 데이터 보관 주기에 따라 쉽게 삭제하는 기능은 제공하지 않음.

 

⦁ 해시 파티셔닝 : 지정된 Hash 조건에 따라 해싱 알고리즘을 적용하여 테이블을 분리.

- 해싱 알고리즘에 의해 각각의 해시 파티션에 분리되어 데이터가 입력되므로 기존에 1개의 테이블에만 데이터를 입력하는 방식보다 입력시의 경합 부하가 줄어듦.

- 설계자 및 데이터 입력자는 특정 데이터가 어떤 파티션에 저장되는지 정확하게 예측 불가.

- 데이터 입력시 경합에 의한 성능 부하를 해소하기 위해 사용.

- 데이터 보관 주기에 따라 쉽게 삭제하는 기능 제공 안함.

`

 

> 테이블에 대한 수평/수직 분할의 절차

① 데이터 모델링을 완성한다.

② 데이터베이스 용량을 산정한다.

③ 대량의 데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석한다.

④ 컬럼 단위로 집중화된 처리가 발생하는지, 로우 단위로 집중화된 처리가 발생되는지 분석하여 처리 작업이 집중화된 단위로 테이블을 분리하는것을 검토한다.

 

 

▷ 데이터베이스 구조와 성능

- 슈퍼/서브 타입 모델 : 공통의 부분을 슈퍼 타입 엔티티로 도출하고 공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성에 대해서는 별도의 서브 타입 엔티티로 구분하는 방식

- 비즈니스의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환할 때 선택의 폭을 넓힐 수 있는 장점이 있음.

- 논리 데이터 모델링 시 정의한 슈퍼/서브 타입 모델은, 물리 데이터 모델로 변환 시 슈퍼 타입 기준, 서브 타입 기준, 개별 타입 기준으로 변환될 수 있음.

슈퍼 타입 (Single 타입, All in One 타입) 기준	슈퍼/서브 타입 모델을 하나의 테이블로 변환한 것. Single 타입 기준 혹은 All in One 타입 기준이라고도 함.
서브 타입 (Plus 타입, Super+Sub 타입) 기준	슈퍼/서브 타입을 서브 타입 테이블들로 변환한 것. 도출된 각각의 서브 타입에는 변환전 슈퍼 엔티티에 있던 컬럼들을 공통적으로 가지고 있음. Plus 타입 기준 혹은 Super+Sub 타입 기준이라고도 함.
개별 타입 (OneToOne 타입, 1:1 타입) 기준	슈퍼/서브 타입을 슈퍼 타입과 서브 타입의 각각 개별 테이블로 변환한 것. 슈퍼 테이블, 서브 테이블 모두 생성한 것. OneToOne 타입 기준 혹은 1:1 타입 기준이라고도 함.

 

 

> 슈퍼/서브 타입 모델 변환의 중요성

• 트랜잭션은 항상 슈퍼 타입 기준으로 처리하는데 테이블은 개별 타입으로 유지되어 UNION 연산에 의해 성능이 저하될 수 있음.
• 트랜잭션은 항상 서브 타입을 기준으로 처리하는데 슈퍼 타입으로 되어 있는 경우 성능이 저하되는 경우가 있음.
• 트랜잭션은 항상 개별 타입 기준으로 처리하는데, 테이블은 슈퍼 타입으로 되어 있어서 불필요하게 많은 양의 데이터가 집약되어 성능이 저하되는 경우가 있음.

 

- 논리 데이터 모델의 슈퍼/서브 타입을 물리 데이터 모델로 변환하는 3가지 기법 비교

구분	슈퍼 타입	서브 타입	개별 타입
특징	하나의 테이블	각각의 서브 타입 테이블	슈퍼, 서브 각각의 테이블
확장성	나쁨	보통	좋음
조인 성능	우수함	나쁨	나쁨
I/O 성능	나쁨	좋음	좋음
관리 용이성	좋음	좋지 않음	좋지 않음
트랜잭션 유형에 따른 선택 방법	전체를 일괄적으로 처리하는 경우 선택	각각의 서브 타입을 기준으로 처리하는 경우 선택	각각의 슈퍼, 서브 타입을 기준으로 처리하는 경우 선택

 

 

▷ PK 컬럼 순서와 성능

- 테이블에는 기본키(PK)가 존재하고 PK는 단 1개의 컬럼으로 이루어져 있을 수 있고(단일 PK), 2개 이상의 컬럼으로 이루어져 있을 수도 있음(복합 PK).

- 복합 PK인 경우 PK 컬럼의 순서에 따라 SQL문의 성능이 빨라질 수도 있고 느려질 수도 있음.

ex) 인구 테이블의 PK가 "행정동코드 + 기준년월 + 인구구분코드 + 연령대구분코드"로 되어 있고, 인구 테이블을 조회할 때 대부분 "기준년월 + 인구구분코드 + 연령대구분코드"로만 조건값을 준다고 가정할 때, PK 컬럼 맨 앞의 행정동코드 컬럼에 대해서는 조건값이 들어오지 않기 때문에 테이블 전체 내용을 모두 읽어야만 조회 결과를 가져 올 수 있게됨. (테이블 풀 스캔 발생) → 이 경우 인구 테이블의 PK를 "기준년월 + 인구구분코드 + 연령대구분코드 + 행정동코드" 순으로 변경하면 성능 향상 효과를 얻을 수 있음.

 

 

▷ 외래키(FK) 컬럼에 대한 인덱스 생성의 중요성

- 논리 데이터 모델상으로 관계에 의한 외래키 제약이 걸린 경우, 해당 외래키 제약이 실제 물리 데이터베이스에 적용될지 안될지는 물리 데이터 모델 설계자의 몫.

- 관계가 있어도 FK 제약조건을 생성하지 않는 경우도 있고, FK 제약조건을 생성했다고 하더라도 해당 FK 컬럼에 인덱스를 미생성하는 경우도 있음.

- 물리적인 외래키의 생성 여부와는 상관없이 논리적이든 물리적이든 FK 제약조건이 있다면 외래키 컬럼에 대해 인덱스를 생성하는 것이 성능상 유리한 경우가 많음.

 

 

▷ 분산 데이터베이스와 성능

- 분산 데이터베이스는 여러 곳으로 분산되어 있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스.

- 논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임임.

- 물리적 위치가 분산되지만, 논리적으로는 여러 사용자가 공유할 수 있음.

 

> 분산 데이터베이스의 투명성

- 분산 데이터베이스의 투명성은 해당 DB를 사용하는 사용자가 DB 시스템이 분산되어 있는 것을 인식하지 못하고 자신만의 DB 시스템을 사용하는 것으로 인식하도록 만드는 것.

분할 투명성 (단편화)	하나의 논리적 Relation(테이블)이 여러 단편으로 분할되어 각 단편의 사본이 여러 Site에 저장됨. 하지만 사용자는 한 곳에 위치하는 것으로 인식해야 함.
위치 투명성	사용하려는 데이터의 저장 장소를 명시할 필요가 없음. 위치정보가 System Catalog에 유지되어야 함. 사용자는 데이터가 어디에 위치하는지에 대해 신경 쓸 필요가 없음.
지역 사상 투명성	지역 DBMS와 물리적 DB 사이의 Mapping을 보장. 각 지역 시스템 이름과 무관한 이름 사용 가능. 사용자가 해당 데이터 어느 지역에 위치하는지를 신경 쓸 필요가 없어야 함.
중복 투명성	DB 객체가 여러 Site에 중복되어 있는지 사용자는 전혀 알 필요가 없는 성질임.
장애 투명성	구성요소(DBMS, Computer)의 장애에 무관한 Transaction의 원자성을 유지. 분산 DB의 장애상황과는 무관하게 원자성을 유지해야 함.
병행 투명성	다수 Transaction이 동시에 수행시 결과의 일관성을 유지해야 함. (Locking과 Time Stamp 방법을 주로 이용)

 

- 분산 환경의 DB를 우수한 성능으로 현장에서 가치있게 사용하는 방법은 업무의 흐름을 보고 업무 구성에 따른 아키텍처 특징에 따라 DB를 구성하는 것.

 

> 분산 데이터베이스의 장단점

⦁ 장점 : 지역자치성, 점증적 시스템 용량 확장. / 신뢰성과 가용성 / 효용성과 융통성 / 빠른 응답 속도와 통신비용 절감 / 데이터의 가용성과 신뢰성 증가 / 시스템 규모의 적절한 조절 / 각 지역 사용자의 요구 수용 증대

⦁ 단점 : 소프트웨어 개발 비용 / 오류의 잠재성 증대 / 처리 비용의 증대 / 설계 및 관리 복잡성과 비용 / 불규칙한 응답 속도 / 통제의 어려움 / 데이터 무결성에 대한 위협

 

> 분산 데이터베이스의 활용 방향성

- 과거 : 위치 중심의 분산 설계

- 현재 : 업무 특성에 맞게 내부 및 외부를 나눠서 설계. 내부 운영 서버가 있고 외부에 오픈된 서버가 있어서 업무에 따라 내/외부를 분산. 이 방식은 통합된 DB에서 제공할 수 없는 빠른 성능을 제공함.

 

> 분산 데이터베이스의 적용 기법

테이블 위치(Location) 분산	설계된 테이블의 위치를 각각 다르게 위치시키는 것. (자재품목은 본사 DB에 위치시키고 생산제품은 지사 DB에 위치시킴)
테이블 분할(Fragmentation) 분산	각각의 테이블을 쪼개어 분산하는 방법. 수평 분할 : 지사에 따라 테이블을 특정 컬럼의 값을 기준으로 Row를 분리. 수직 분할 : 지사에 따라 테이블 컬럼을 기준으로 Column을 분리.
테이블 복제(Replication) 분산	동일한 테이블을 다른 지역이나 서버에서 동시에 생성하여 관리하는 유형. 부분복제 : 통합된 테이블을 한 군데(본사)에 가지고 있으면서 각 지사별로는 지사에 해당된 Row를 가지고 있는 형태. 광역복제 : 통합된 테이블을 한 군데에 가지고 있으면서 각 지사에도 본사와 동일한 데이터를 모두 가지고 있는 형태.
테이블 요약(Summarization) 분산	지역 간에 또는 서버 간에 데이터가 비슷하지만 서로 다른 유형으로 존재하는 경우. 분석요약 : 각 지사별로 존재하는 요약정보를 본사에 통합하여 다시 전체에 대해서 요약 정보를 산출하는 분산방법. 통합요약 : 각 지사별로 존재하는 다른 내용의 정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방법.

 

 

 

참고 도서 - 이경오의 SQL+ SQLD 비밀노트