[SQLD] 2장. 데이터 모델과 성능

제1절. 성능 데이터 모델링의 개요
 
성능 데이터 모델링
DB  성능 고려해서 데이터 모델링하는 것
EX) 정규화, 반정규화, 테이블 통합/분할/조인, PK/FK ...
 
수행 시점
빠를수록 good
in 분석/설계 단계 good
 
고려사항
관심사별로 정규화
DB 용량산정
DB에 발생되는 트랜잭션 유형 파악 ←  CRUD 매트릭스 활용
용량, 트랜잭션 유형 따라 반정규화
이력모델 조정 or 인덱스 고려하여 PK/FK 순서 조정 or 슈퍼/서브 조정
성능관점에서 data model 검증

---

제2절. 정규화와 성능
정규화
삽입/삭제/갱신 이상 현상 방지
! 함수적 종속성*에 기반
 

* 함수적 종속성 : 어떤 기준값에 의해 종속되는 현상
     결정자 ex : 주민등록번호, 학번
     종속자 ex : 이름, 혈액형, 출생지, 주소, 학년
(주민등록번호에 따라 이름, 혈액형, 출생지가 달라짐)

 
정규형 Normal Form
정규화로 도출된 data model이 갖춰야 할 특성
1NF : 모두 원자값 (도메인 ,다중값 속성 분리)
2NF : 부분함수종속 x 즉, 완전 종속
3NF : 이행함수종속x (A → B, B → C일 때, A → C 종속이면 안 됨)
BCNF(보이스코드) : 모든 결정자가 후보키
 
+
입력,수정,삭제 → 성능↑
-
조회 시 메모리,CPU 저하될 수도

---

제3절. 반정규화와 성능
반정규화 Denormalization
정규화된 엔터티,속성,관계를 중복,통합,분리 for 성능↑
cf. 비정규화 : 정규화 안 하는 것
재현의 적시성으로 판단

특징
종합적으로 고려
과도하면 data 무결성 침해
 
how?
① 테이블 반정규화
     1) 병합 : 관계, 슈퍼/서브 타입
     2) 분할 : 수직, 수평
     3) 추가 : 중복/통계/이력/부분
 
② 칼럼 반정규화
     1) 중복 추가 → 조인↓
     2) 파생 추가 →  예상값 미리 계산
     3) 이력테이블 추가 → 종료 여부, 최근값 여부
     4) for PK 의미적 분리 →  PK단일, 조회↑ 
     5) for 데이터 복구 → 실수 방지
 
③ 관계 반정규화
     1) 중복 추가 → 조인 경로 ↓ *이건 데이터 무결성 보장!

---

제4절. 대량 데이터에 따른 성능
성능 저하 원인 - 해결방안
1) 한 테이블에 대량 집중 : 구조 너무 ↑, 디스크 I/O ↑
2) 한 테이블에 여러 col : 디스크 점유량↑, 읽는 I/O↑ ---- 수직 분할
3) 대량 data 처리 table : SQL I/O↑, 인덱스 구성  ---- 파티셔닝, PK에 의한 테이블 분할
4) 대량 data가 한 table : 인덱스 크기 ↑    ---- 파티셔닝, PK에 의한 테이블 분할
5) col 많음 : 로우 체이닝*, 로우 마이그레이션* 발생 ---- 1:1 분리
 
대량 data => 블록* I/O ↑, 디스크 I/O 가능성 ↑, 디스크 I/O 성능 저하
 

* 로우 체이닝 : row 길어서 두 블록에 걸쳐 저장

* 로우 마이그레이션 : 수정된 data가 다른 블록의 빈 공간에 저장

* 블록 : 테이블 데이터 저장 단위

 
파티셔닝 Partitioning
테이블 수평 분할 기법
논리적으론 한 테이블 but, 물리적으론 여러 data파일에 분산 저장
So, 데이터 조회 범위 줄여 성능 향상
 
① Range Partition : 범위로 (ex. 개발부서 2000~3000)
② List Partition : 특정 값 기준으로 (ex. 지역 : 서울, 부산, 경기)
③ Hash Partition : 해시함수 적용. 데이터위치 알 수 x
④ Composite Partition : 여러 파티션 기법을 복합적으로 사용

*해시 함수 : 임의를 짧은 길이 data로 매핑

---

 
제5절. 데이터베이스 구조와 성능
슈퍼/서브타입 데이터 모델
논리적 데이터 모델에서 주로 사용 (주로 분석단계)
물리적 데이터 모델로 설계 시 문제 o (노하우 x-> 1:1 or All in one ->성능저하)
 
슈퍼 타입 : 공통부분
서브 타입 : 상속 from 공통. So, 다른 엔터티와 차이 있는 속성만 모델링
 
DB 성능 저하 원인 3가지
1. Union 연산
- 트랜잭션 : 전체 일괄처리
- 테이블 : 개별로 유지
2. 조인
- 트랜잭션 : 슈퍼+서브 공통 처리
- 테이블 : 개별로 유지
3. 불필요하게 많은 데이터 집적
- 트랜잭션 : 서브타입만 개별 처리
- 테이블 : 하나로 통합
 
슈퍼/서브타입 데이터모델 변환 -> 성능향상
변환 기준 : data 양, 트랜잭션 유형
- 소량 data : 처리 유연성 고려해서 가급적 1:1 유지
- 대량 data : 3가지 변환 방법@

구분	One to one type	plus type	Single type
설명	개별처리 트랜잭션에 개별 테이블 구성	슈퍼+서브 공통처리 트랜잭션에 슈퍼/서브 각각 테이블 구성	하나의 통합 테이블
확장성	우수	보통	나쁨
조인 필요 수	많	보통	적
I/O 성능 저하	양호	양호	나쁨
관리 용이성	나쁨	나쁨	좋음
적합 트랜잭션 유형	개별 테이블 접근 많을 때	슈퍼+서브 형식 많을 떄	전체 일괄처리 많을 때

 쪼개질수록 확장성,  I/O성능은 좋은데,  조인이 많아져 관리 힘듦
 
PK/FK 칼럼 순서 및 성능
1. 인덱스 중요성
데이터 조작 시 가장 효과적 처리 접근경로 제공
(앞쪽 위치 속성 값이 비교자여야 good. 가급적 = 아니면 BETWEEN)
2. PK/FK 설계 중요성
데이터 접근 시 접근경로 제공. 설계 단계 마지막에 col 순서조정
3. PK 순서 중요성
물리적 모델링 단계에서 스스로 생성 or 상속 PK 중요
4. FK 순서 중요성
조인할 수단됨(=경로). 조회 조건 고려해서 반드시 인덱스 생성@@
 
고려 안 하고 데이터 모델링 된 상태로 DDL 생성해서 성능 저하 자주 겪음
 WHY?
- 조회 조건 (WHERE)에 따라 인덱스 처리 범위가 달라지는데,
이를 자동 생성하면, 트랜잭션이 인덱스 범위를 넓게 하거나 full scan함
 
@@물리적 테이블에 FK제약 없으면, 인덱스 x -> 성능저하
FK 참조 무결성으로 상속받은 FK에 인덱스 만들어야 함
 
인덱스 접근 범위 좁히는 좋은 방법
PK 여러 개일 때, Where 조건의 col들이 우선순위여야 !
=이 젤 앞, BETWEEN, IN 범위 조건이 그 다음
나머지 PK는 아무렇게나

---

제6절. 분산 데이터베이스와 성능
분산 데이터베이스
물리적으로 분산된 db를 하나의 논리적 시스템으로 사용
빠른 네트워크 환경 → db를 여러 지역에서 노드로 위치 → 사용성, 성능 극대화~
 
설계 방식
- 상향식 : 지역 스키마 → 전역 스키마 작성
- 하향식 : 전역 스키마 → 지역사상(mapping) 스키마 작성
 
+
지역 자치성 증가, 점증적 시스템 용량 확장 o
신뢰/가용/효용/융통성
응답속도 빠름, 통신비용 절감시스템 규모 따라 조절 o각 지역 사용자의 요구 수용 o
 
-
sw개발 비용, 오류 잠재성, 처리비용, 설계/관리 복잡성 증가응답속도 불규칙통제, 데이터 무결성 유지 어려움
 
분산 DB의 투명성
1. 분할 투명성 : 하나가 분할되어 각 단편의 사본이 여러 사이트에 저장
2. 위치 투명성 : 저장 장소 명시 안 해도 o
3. 지역사상 투명성 : 지역 DMBS와 물리적 DB 사이의 Mapping 보장
4. 중복 투명성 : DB객체중복 여부 몰라도 o
5. 장애 투명성 : 구성요소의 장애 무관하게 트랜잭션 원자성 유지 o
6. 병행 투명성 : 다수 트랜잭션 동시 -> 일관성 o
 
적용 기법
1. 테이블 위치 분산
 본사 vs 지사.
 위치별 DB문서 필요
2. 테이블 분할 분산
 수평분할 : row. 지사 다를 때 중복x
 수직 분할 : col. 같은 PK 있어야 함
3. 테이블 복제 분산
:  같은 테이블을 다른 지역/서버에서 동시 생성해서 관리
 부분 복제 : 마스터DB에서 테이블 일부만 다른 데 위치
 광역 복제 : 전부.
4. 테이블 요약 분산 
:  비슷한 내용의 data를 서로 다른 관점에서 요약하여 분산
 분석 요약 rollup replication : 지사별 같은 주제의 정보를 본사에서 통합 -> 전체 요약
 통합 요약 consolidation replication : 지사별 존재하는 다른 내용을 본사에 통합 후 다시 전체 요약