[DB] 성능 데이터 모델링

안녕하세요. 바른호랑이입니다.

이번 게시글에서는 성능 데이터 모델링에 대해서 알아볼 예정입니다.

대용량의 복잡한 데이터들의 관리비용을 최소화하고 효율적인 관리를 위해서는 성능데이터 모델링이 요구되며 관련 개념들로는 정규화, 반정규화, 테이블 통합 등이 존재합니다. 이와 관련된 세부 내용들은 아래와 같습니다.

 

1. 성능데이터 모델링의 개요

① 정의

ㆍ DB 성능향상을 목적으로 설계 단계의 데이터 모델링 때부터 정규화, 반정규화, 테이블 통합, 테이블 분할, 조인구조, Key관리 등 여러가지 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것

ㆍ SQL 튜닝만을 통해 성능에 대한 데이터 모델 설계를 하게되면 한계에 부딪칠 수 밖에 없고, 시간이 지날수록 성능개선의 비용은 증가하게 되기에 프로젝트 초기에 테스트 환경을 구현한 후 트랜잭션을 발생시켜 실제 성능을 테스트 해봐야 함.

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

- 데이터 모델링 시 정규화를 정확하게 수행해야하며, DB 용량산정과 트랜잭션 유형을 파악한 후 필요시 반정규화를 수행해야함.

- 이력모델의 조정, PK/FK조정, 슈퍼타입/서브타입 조정등을 수행한 후 성능관점에서 데이터 모델을 검증해야함.

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

- 엔터티에 대한 용량산정을 진행하면 데이터가 집중되는 엔터티(테이블)을 파악할 수 있음.

- 트랜잭션 유형은 CRUD 매트릭스나 시퀀스 다이어그램을 통해 파악이 가능하며, 이를 통해 데이터 조회 주요컬럼들을 확인할 수 있게 됨.

- 반정규화는 테이블, 속성, 관계에 대해 포괄적인 반정규화 방법을 적용해야함.

 

2. 성능향상 전략

① 정규화

정규화와 성능

ㆍ 정규화는 기본적으로 데이터 중복성을 제거해주고, 데이터가 관심사별로 처리되게 해주기 때문에 성능이 향상되나 엔터티의 수가 증가하기 때문에 사례에 따라 성능저하가 발생할 수 있음.

ㆍ DB에서 데이터 처리시 성능은 조회 성능과 입력, 수정, 삭제 성능의 2가지로 분류가 가능하며 일반적으로 이 2가지 성능은 Trade-Off관계임.

ㆍ 정규화를 하면 데이터 입력, 수정, 삭제성능은 일반적으로 향상되고 조회성능은 상황에 따라 향상될 수도 있고 저하될 수도 있음. 

ㆍ 함수의 종속성(Functional Dependency)은 데이터들이 특정 기준값에 의해 종속되는 현상을 지칭하는 것으로 기준값을 결정자(Determinant), 종속되는 값을 종속자(Dependent)라고 하며, 이름, 출생지, 주소가 주민등록번호에 종속된다면 주민등록번호는 결정자가, 이름, 출생지, 주소는 종속자가 됨.

ㆍ 정규화의 궁극적인 목적은 반복되는 데이터를 분리하고, 데이터 정합성이 지켜질 수 있게 종속된 테이블에 데이터가 적절하게 배치되도록 하는 것임.

ㆍ 데이터는 속성간의 함수종속성에 근거하여 정규화되어야하며, 프로젝트 수행에서 정규화는 선택사항이 아닌 필수사항임.

 

② 반정규화

반정규화와 성능

ㆍ 반정규화(De-Normalization)는 시스템 성능향상과 개발 및 운영의 단순화를 위해 정규화된 엔터티, 속성, 관계에 대해 중복, 통합, 분리등을 수행하는 데이터 모델링 기법을 지칭함.

ㆍ 데이터 무결성(Integrity )훼손의 위험성을 감수하고 반정규화를 수행하는 이유는 데이터 조회시 I/O량이 많거나 경로가 너무 멀어 조인으로 성능저하가 예상되는 경우 성능을 향상시키기 위함임.

ㆍ 반정규화는 난이도가 높은 데이터 모델링 실무 기술로 일반적으로 컬럼 중복을 통해서만 반정규화를 진행하지만 무분별하게 컬럼의 반정규화를 수행하게되면 데이터 무결성을 깨뜨리는 결정적인 역할을 할 수 있음.

ㆍ 반정규화 진행시에는 데이터무결성을 보장할 수 있는 방법들을 고려한 이후에 적용해야하며, 정규화와 반정규화 사이에는 Trade-Off관계가 존재하므로 정규화와 반정규화를 적절히 사용하는 것이 필요함.

ㆍ 반정규화 진행 프로세스

- 반정규화 대상조사 : 범위처리빈도수 조사, 대량의 범위 처리 조사, 통계성 프로세스 조사, 테이블 조인 개수 확인

⑴ 자주 사용하는 테이블에 접근하는 프로세스의 수가 많고 일정한 범위를 조회하는 경우

⑵ 대량의 데이터가 있고 대량의 데이터 범위를 자주 처리하는 경우 처리범위를 일정하게 줄이지 않으면 성능을 보장할 수 없는 경우

⑶ 통계성 프로세스에 의해 통계정보를 필요로 하는 경우

⑷ 지나치게 많은 조인으로 인해 데이터를 조회하는 작업이 기술적으로 어려울 경우

 

- 다른 방법 유도 및 검토 : 뷰(View) 테이블, 클러스터링, 인덱스 조정, 응용애플리케이션

⑴ SQL 문장 작성방식에 따라 성능저하가 발생할 수 있으므로 성능을 고려한 뷰를 생성하여 개발자가 뷰를 통해 접근하게 함으로써 성능저하 위험예방

⑵ 대량의 데이터 처리나 부분처리에 의한 성능 저하는 클러스터링이나 인덱스 조정으로 성능향상이 가능하나 데이터 입력, 수정, 삭제 성능은 저하되므로 조회 중심의 테이블에는 적용을 고려

⑶ 파티셔닝 키에 의해 물리적으로 저장공간이 분리된 파티셔닝 테이블을 적용하는 파티셔닝 기법을 통해 성능향상을 고려

⑷ 응용 메모리 영역에 데이터 처리를 위한 값을 캐쉬하거나 중간 클래스 영역에 데이터를 캐쉬하여 공유함으로써 성능향상을 고려

 

- 반정규화 적용 : 테이블 반정규화, 속성의 반정규화, 관계의 반정규화

테이블 반정규화
분 류	기 법	내 용
테이블 병합	1:1 관계 테이블 병합	1:1 관계의 테이블들을 통합하여 성능향상
	1:M 관계 테이블 병합	1:M 관계의 테이블들을 통합하여 성능향상
	슈퍼/서브타입 테이블 병합	슈퍼/서브 타입 관계의 테이블들을 통합하여 성능향상
테이블 분할	수직 분할	컬럼 단위로 테이블을 분리하여 성능향상 (트랜잭션 처리 유형 파악이 선행되어야 함.)
	수평 분할	로우 단위로 테이블을 분리하여 성능향상
테이블 추가	중복 테이블 추가	다른 업무거나 서버가 다른 경우 동일 테이블구조를 중복하여 원격조인을 제거함으로써 성능향상
	통계 테이블 추가	통계 테이블을 미리 생성하여 조회시 성능향상
	이력 테이블 추가	이력 테이블 중 마스터 테이블에 존재하는 레코드를 중복시켜 성능향상
	부분 테이블 추가	특정 테이블에서 자주 이용되는 컬럼들만 따로 모아 별도의 테이블을 생성함으로서 성능향상

컬럼의 반정규화
기 법	내 용
중복컬럼 추가	조인 감소를 위해 중복된 컬럼을 위치시킴
파생컬럼 추가	계산이 필요한 값들을 미리 계산하여 컬럼에 보관하는 방법으로 Derived Column이라고 함
이력테이블 컬럼추가	이력 테이블에 기능성 컬럼(최근값 여부, 시작과 종료일자 등)을 추가함
PK에 의한 컬럼추가	PK안에 데이터가 존재하더라도 성능향상을 위해 일반속성으로 포함함
응용시스템 오작동을 위한 컬럼 추가	이전 데이터를 임시적으로 중복하여 보관하는 기법

관계의 반정규화
기 법	내 용
중복관계 추가	여러 경로를 거쳐 조인이 가능하지만 성능저하예방을 위해 추가적인 관계를 맺는 방법

 

③ 데이터량

대량 데이터에 따른 성능

ㆍ 대량의 데이터가 하나의 하드웨어 공간과 테이블에 집중되어 있으면 성능저하의 가능성이 높아지며, 이 때 트랜잭션이 분산 처리될 수 있도록 테이블 단위에서 분할의 방법(수평분할, 수직분할)을 적용함으로써 성능향상을 도모할 수 있음.

ㆍ 하나의 테이블에 대량의 데이터가 있으면 인덱스의 Tree구조가 커지게 되고, 이로 인해 입력, 수정, 삭제, 조회시 디스크 I/O를 많이 유발하게 되고, 많은 수의 컬럼이 존재하게 되면 데이터가 디스크의 여러 블록에 존재하므로 디스크에서 데이터를 읽는 I/O량이 많아지게 되어 성능이 저하됨.

ㆍ 다량의 컬럼은 로우체이닝(Row Chaining : 로우의 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 거쳐 하나의 로우가 저장되어있는 형태)과 로우마이그레이션(Row Migration : 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식)을 많이 유발하게 만들며, 이는 많은 데이터 블록에 데이터를 저장하게 만들고, 이는 불필요한 I/O를 많이 발생시켜 성능을 저하시킴.

ㆍ 테이블에 대량의 데이터가 예상될 경우 파티셔닝 또는 PK를 이용한 테이블 분할 방법을 적용할 수 있음.

- Range Partition : PK가 요금일자 + 요금번호일 경우 월 단위로 테이블을 분할하여 파티션 테이블을 작성

- List Partition : PK가 사업소코드일 때 각각의 사업소 코드별로 테이블을 분할하여 파티션 테이블을 작성

- Hash Partition : HASH 조건에 따른 해쉬 알고리즘이 적용되어 테이블을 분할하여 파티션 테이블을 작성

ㆍ 테이블 수직/수평 분할 절차

- 데이터 모델링 완성 후 DB 용량산정 및 트랜잭션 처리 패턴 분석하여 집중화된 처리 발생여부를 파악한 후 상황에 맞게 테이블을 분리

 

④ DB 구조

데이터베이스 구조와 성능

ㆍ 공통의 부분을 슈퍼타입으로 상이한 부분을 서브타입으로 구분하여 표현하는 Extended ER모델은 데이터 모델링 시 자주 쓰이는 데이터 모델링인데 명확한 기준 없이 슈퍼/서브타입으로 변환하게되면 성능이 저하될 수 있음

ㆍ 슈퍼/서브타입 데이터 모델의 변환기술

- 개별로 발생하는 트랜잭션에 대해서는 개별 테이블로 구성

- 슈퍼타입+서브타입에 대해 발생하는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성

- 일괄적으로 트랜잭션이 발생할 때는 하나의 테이블로 구성

구 분	OneToOne Type	Plus Type	Single Type
특 징	개별 테이블 유지	슈퍼+서브타입 테이블	하나의 테이블
확장성	우수함	보통	나쁨
조인성능	나쁨	나쁨	우수함
I/O량 성능	좋음	좋음	나쁨
관리용이성	좋지않음	좋지않음	좋음
트랜잭션 유형에 따른 선택방법	개별 테이블로 접근이 많은 경우	슈퍼+서브 형식으로 데이터를 처리하는 경우	전체를 일괄적으로 처리하는 경우

ㆍPK/FK 설계는 업무적인 의미 뿐만 아니라 데이터를 접근할 때 경로를 제공하는 성능의 측면에서도 중요한 의미를 가지며, PK가 복합식별자일 경우 PK의 순서는 데이터를 조회할 경우 영향을 미치게 되므로 이를 고려하는 것이 필요함

ㆍ PK가 주문번호, 주문일자, 주문번호코드가 결합된 복합 식별자이고 이를 Index로 지정하면 주문번호, 주문일자, 주문번호코드 순으로 정렬되게 됨. 이 때 주문번호가 아닌 주문일자를 먼저 조건을 걸게 되면 인덱스를 처리하는 범위가 달라지게 되어 성능에 영향을 줌.

ㆍ 연산자 =과 같이 특정 값을 비교하는 컬럼을 우선적으로 Index앞쪽에 위치시키고 범위나 그 외의 조건들은 나중 순서로 구성하는 것이 좋음.

# DDL 생성
CREATE TABLE ORDER
(
	ORDER_NUMBER CHAR(10) NOT NULL,
    ORDER_DATE VARCHAR2(8) NOT NULL,
    ORDER_CODE NUMBER(6) NOT NULL,
    PRICE NUMBER(13) NULL
 );
 
 CREATE UNIQUE INDEX XPKORDER ON ORDER
 ( 
 	ORDER_NUMBER ASC,
    ORDER_DATE ASC,
    ORDER_CODE ASC
);

ALTER TABLE ORDER ADD ( PRIMARY KEY (ORDER_NUMBER, ORDER_DATE, ORDER_CODE));

# 1
SELECT PRICE FROM ORDER
WHERE ORDER_NUMBER = N'1002'

# 2
SELECT PRICE FROM ORDER 
WHERE ORDER_NUMBER = N'2021.12.3'

# 1번은 주문번호가 1002에 해당하는 값들만 조회하나 2번은 FULL SCAN을 하게되어 성능이 저하됨

 

⑤ 분산 DB

분산 데이터베이스와 성능

ㆍ 분산 DB : DB를 연결하는 네트워크 환경을 이용하여 DB를 여러 지역, 노드로 위치시켜 사용성, 성능등을 극대화 시킨 DB

ㆍ 분산 DB의 투명성(Transparency)

- 분할 투명성(Division Transparency) : 하나의 논리적 테이블이 단편으로 분할되어 각 단편의 사본이 여러 위치에 저장됨

- 위치 투명성(Location Transparency) : 사용하려는 데이터의 저장 장소 명시가 불필요함

- 지역사상 투명성(Local mapping transparency) : 지역 DBMS와 물리적 DB사이의 Mapping보장, 각 지역시스템과 무관한 이름 사용가능함

- 중복 투명성(Replication Transparency) : DB 객체가 여러 장소 중복되어 있는지 사용자는 알 필요가 없음

- 장애 투명성(Failure Transparency) : 구성요소(Computer, DBMS)의 장애와 무관한 트랜잭션 원자성 유지

- 병행 투명성(Concurrency Transparency) : 다수 사용자의 다수 트랜잭션 동시 수행시에도 일관성 유지

ㆍ 분산 DB의 장, 단점

장 점	단 점
- 지역 자치성, 점증적 시스템 용량 확장 - 신뢰성과 가용성, 효용성과 융통성 - 빠른 응답 속도와 비용 절감 - 각 지역 사용자의 요구 수용 증대	- SW 개발 비용이 높고 오류의 잠재성 증가 - 설계, 관리의 복잡성과 처리 비용의 증가 - 불규칙한 응답 속도와 어려운 통제 - 데이터 무결성에 대한 위협

ㆍ 분산 DB 적용기법

- 테이블 위치 분산 : 테이블의 물리적 위치를 다르게 위치시키는 것(예 : 가각의 테이블들을 다른 지역에 위치)

- 테이블 분할(Fragmentation) 분산 : 위치뿐만 아니라 테이블을 수평 또는 수직분할하여 위치시키는 것

- 테이블 복제(Replication) 분산 : 동일한 테이블을 다른 지역이나 서버에서 동시에 생성하여 관리하는 것
⑴ 부분복제(Segment Replication) : 통합본은 한군데에만 위치하고 각 노드별로 기준에 따라 통합본이 분할된 테이블들을 가지고 있는 것으로 데이터 수정시 각 노드에서 수정 후 통합본을 가진 노드로 데이터를 보내 갱신하는 것이 일반적
⑵ 광역복제(Broadcast Replication) : 통합본을 모든 노드에 저장하는 것으로 데이터 수정 시 정해진 특정 노드에서 수정 후 각 노드로 배포하는 것이 일반적
- 테이블 요약(Summarization) 분산 
⑴ 분석요약(Rollup Replication) : 각 지사별로 분산된 요약정보를 본사에 통합하여 전체 요약정보를 산출
⑵ 통합요약(Consolidation Replication) : 각 지사별로 분산된 요약정보를 본사에서 취합(지사별 요약정보 비교를 위해 주로 사용)
ㆍ DB 분산 설계를 적용하면 좋은 경우
- 성능이 중요한 사이트이거나 공통코드, 기준정보, 마스터 데이터 등에 대해 분산환경을 구성하면 좋음
- 실시간 동기화가 요구되지 않고 특정 서버에 부하가 집중될 때 부하분산 목적으로 좋음
- 백업 사이트(Disaster Recovery Site)를 구성할 때 간단한 분산기능을 적용하면 좋음

 

P.S 더 나은 개발자가 되기위해 공부중입니다. 잘못된 부분을 댓글로 남겨주시면 학습하는데 큰 도움이 될 거 같습니다.

+ 본 글은 「SQL 전문가 가이드, 한국 데이터베이스 진흥원」참고하여 작성하였습니다.