앱)아는만큼 보이는 데이터베이스 설계과 구축 요약3

16 성능 데이터 모델링
데이터 모델의 성능이 저하되는 원인
-데이터 모델구조
-데이터가 대용량
-인덱스 특성을 고려 못함

성능 데이터 모델을 수행하는 방법의 단계
첫째, 정규화를 정확하게 수행
둘째, 데이터베이스 용량 산정을 수행한다
셋째, 데이터베이스에 발생하는 트랜잭션의 유형을 파악한다
넷째, 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.
다섯째, 이력모델 조정, PK/FK 조정, 수퍼타입/서브타입 조정 등을 수행한다
여섯째, 데이터 모델을 검증한다

17 정규화를 통한 데이터베이스 성능 향상
정규화 수행과 성능의 관계
정규화 수행 -> 조회 기능 -> 성능이 향상되거나 저하될 수 있음
정규화 수행 -> 입력수정삭제기능 ->성능이 향상됨

18 반정규화를 통한 데이터베이스 성능 향상
반정규화는 비정규화, 역정규화라고 함
반은 반대하다의미이다

반정규화란 시스템의 성능 향상과 개발 및 운영의 단순화를 위해 정규화된 엔티티타입, 속성, 관계에 대해 중복, 통합, 분리 등을 수행하는 데이터 모델링 기법을 의미한다
좁은 의미의 반정규화는 데이터 중복하여 성능을 향상시키는 기법을 의미하며
더 넓은 의미의 반정규화는 성능을 향상시키기 위해 정규화된 데이터 모델에서 중복, 통합, 분리 등을 수행하는 모든 과정을 의미한다
반정규화를 적용할때는 데이터 무결성이 깨질 가능성이 많기 때문에 반드시 데이터 무결성을 보장할 수 있는 방법을 고려한 이후에 적용해야 한다

반정규화를 적용의 단계
첫째, 반정규화의 대상을 조사
전체 데이터양을 조사하고 그 데이터가 해당 프로세스를 처리할 때 성능 저하가 나타날 것인지 검증해야 한다
데이터가 대량이고 성능이 저하될 것으로 예상될때 다음 네가지 경우 중 하나에 해당하면 반정규화를 고려
-자주 사용되는 테이블에 접근하는 프로세스의 수가 많고 항상 일정한 범위만을 조회하는 경우
-테이블에 대량의 데이터가 있고 대량의 데이터 범위를 자주 처리하는 경우에 처리범위를 일정하게 줄이지 않으면 성능을 보장할 수 없는 경우
-통계성 프로세스에 의해 통계 정보를 필요로 하는 경우(이때는 반정규화된 별도의 통계 테이블을 생성한다)
-테이블에 지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우

둘째, 반정규화의 대상에 대해 다른 방법으로 처리할 수 있는지 검토
-지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우 뷰를 사용하면 이를 해결할수도 있다
뷰가 조회 성능을 향상시키는 역할을 수행하지는 않는다. 다만 개발자별로 SQL문장을 만드는 방법에 따라 성능 저하가 나타날 수 있으므로 성능을 고려한 뷰를 생성하여 개발자가 뷰를 통해 접근하게 함으로써 성능 저하의 위험을 예방하는 것도 좋은 방법이 된다.
-대량의 데이터 처리나 부분 처리에 의해 성능이 저하되는 경우 클러스터링을 적용하거나 인덱스를 조정함으로써 성능을 향상시킬 수 있다.
클러스터링을 적용하는 방법은 대량의 데이터를 특정 클러스터링 팩트에 의해 저장 방식을 다르게 하는 방법이다
이 방법은 데이터 입력/수정/삭제할때 성능이 많이 저하되므로 조회 중심의 테이블이 아니라면 생성하면 안되는 오브젝트이다
다만 조회가 대부분이고 인덱스를 통해 성능 향상이 불가능하다면 클러스터링을 고려할 만하다
인덱스를 통해 성능을 충분히 확보할 수 있다면 인덱스를 조정하여 반정규화를 회피하도록 한다
-대량의 데이터는 PK의 성격에 따라 부분적인 테이블로 분리할 수 있다
즉 파티셔닝 기법의 적용으로 성능 저하를 방지할 수 있다
인위적인 테이블을 통합/분리하지 않고 물리적인 저장기법에 따라 성능을 향상시키는 파티셔닝을 고려해 볼 수 있다
이 경우는 데이터가 특정기준(파티셔닝 키)에 의해 다르게 저장되고 파티셔닝 키에 따른 조회가 될때 성능이 좋아지는 특성이 있다.
따라서 특정 기준에 의해 물리적인 저장 공간이 구분될 수 있고 트랜잭션이 일정한 기준에 의해 들어온다면 파티셔닝 테이블을 적용하여 조회 성능을 향상시키는 것도 좋은 방법이 될 수 있다.
-응용 애플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능을 향상시킬수 있다.
응용 메모리 영역에 데이터를 처리하기 위한 값을 캐쉬하거나 중간 클래스 영역에 데이터를 캐쉬하여 공유하게 하는 것도 성능을 향상시키는 방법이 될 수 있다.

셋째, 다른 방법이 없다면 반 정규화를 적용한다.

반정규화의 기법들
테이블관련 반정규화 방법
테이블 병합 기법
1)1:1관계 테이블 병합 -> 1:1관계를 통합하여 성능 향상
2)1:M관계 테이블 병함 -> 1:M관계를 통합하여 성능 향상
3)수퍼/서브타입 테이블 병합 -> 수퍼/서브 관계 통합하여 성능 향상

테이블 분할 기법
1)수직 분할 - 컬럼단위의 테이블을 디스크 I/O를 분산 처리하기 위해 테이블 1:1로 분리하여 성능 향상(트랜잭션이 처리되는 유형 파악이 선행되어야 함)
2)수평 분할 - 로우 단위로 집중 발생하는 트랜잭션을 디스크 I/O 및 데이터 접근의 효율성을 높여 성능을 향상시키기 위해 로우 단위로 테이블을 쪼깸(관계가 없음)

테이블 추가 기법
1)중복 테이블 추가 - 다른 업무이거나 서버가 다른 경우 동일한 테이블 구조를 중복하여 원격 조인을 제거하여 성능 향상
2)통계 테이블 추가 - SUM, AVG등을 미리 수행하여 계산해 둠으로써 조회 성능 향상
3)이력 테이블 추가 - 이력 테이블 중에서 마스터 테이블에 존재하는 레코드를 중복하여 이력 테이블에 존재하는 방법은 반정규화의 유형
4)부분 테이블 추가 - 하나의 테이블의 전체 컬럼 중 자주 이용하는데 자주 이용하는 집중화된 컬럼들이 있을 때 디스크 I/O를 줄이기 위해 해당 컬럼들을 모아놓은 별도의 반정규화된 테이블을 생성

컬럼관련 반정규화 방법
1)중복 컬럼 추가 - 조인에 의해 처리할 때 성능 저하를 예방하기 위해 즉 조인을 감소시키기 위해 중복된 컬럼을 위치시킴
2)파생 컬럼 추가 - 트랜잭션이 처리되는 시점에 계산에 의해 발생되는 성능 저하를 예방하기 위해 미리 값을 계산하여 컬럼에 보관함(Derived Column이라고 함)
3)이력 테이블 컬럼 추가 - 대량의 이력 데이터를 처리할 때 불특정 날 조회나 최근 값을 조회할 때 나타날 수 있는 성능 저하를 예방하기 위해 이력 테이블에 기능성 컬럼(최근값 여부, 시작과 종료일자 등)을 추가함
4)PK에 의한 컬럼 추가 - 복합 의미를 갖는 PK를 단일 속성으로 구성하였을 경우 발생이 됨. 단일 PK 안에서 특정값을 별도로 조회하는 경우 성능 저하가 발생될 수 있음. 이때 이미 PK안에 데이터가 존재하지만 성능 향상을 위해 일반 속성으로 포함하는 방법이 PK에 의한 컬럼 추가 반정규화임
5)응용 시스템 오작동을 위한 컬럼 추가 - 업무적으로 의미가 없지만 사용자가 데이터 처리를 하다가 잘못 처리하여 원래 값으로 복귀하기를 원하는 경우 이전 데이터를 임시적으로 중복하여 보관하는 방법. 컬럼으로 이것을 보관하는 방법은 오작동 처리를 위한 임시적인 기법이지만 이것을 이력 데이터 모델로 풀어내면 정상적인 데이터 모델의 기법이 될 수 있음

관계관련 반정규화 방법
1)중복관계 추가 - 데이터를 처리하기 위한 여러경로를 거쳐 조인이 가능하지만 이때 발생할 수 있는 성능 저하를 예방하기 위해 추가적인 관계를 맺는 방법

20 데이블 수직/수평 분할에 의한 성능 향상
트랜잭션의 집중 -> 수평분할/수직분할
대량의 데이터가 존재하는 테이블에 많은 트랜잭션이 발생하여 성능이 저하되는 구조의 테이블을 수평/수직분할 설계하면 성능 저하를 예방할 수 있다

수평분할 : 컬럼단위로 분할하여 I/O 경감
수직분할 : 로우단위로 분할하여 I/O 경감

테이블의 많은 양의 데이터가 예상될 경우 파티셔닝을 적용하거나 PK에 의해 테이블을 분할하는 방법을 적용할 수 있다
Rage partition적용(가장 많이 사용하는 파티셔닝의 기준)
요금일자+요금번호->요금일자의 년+월을 이용하여 12개의 파티션 테이블을 만들었음

List partition적용
지점, 사업소, 사업장, 핵심적인 코드값으 로 PK가 구성되어 있고 대량의 데이터가 있는 테이블이라면 적용할 수 있다.
List partition은 대용량 데이터를 특정값에 따라 분리 저장할 수 있으나 range partition과 같이 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공하지 않는다.

테이블을 수평분할할 것인지, 수직분할할 것인지 정하려면 두가지를 적용하면 된다
첫째, 데이터 모델링을 완성한다
둘째, 데이터베이스 용량 산정을 한다


21 수퍼타입/서브타입 모델의 성능 고려방법
Extended ER 모델이라고 불리우는 이른바 수퍼/서브 타입 데이터 모델은 최근 데이터 모델링을 할때  매우 자주 쓰이는 모델이다
이 모델이 자주 쓰이는 것은 업무를 구성하는 데이터의 특징을 공통점과 차이점을 고려하여 효과적으로 표현할 수 있기 때문
즉, 공통의 부분을 수퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔티티타입과 차이가 있는 속성에 대해서는 별도의 서브 엔티티타입으로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수 있다는 장점이 있다.

수퍼/서브 타입의 데이터 모델은 논리적인 데이터 모델에서 이용되는 형태이다

22 인덱스 특성을 고려한 PK/FK 데이터베이스 성능 향상
데이터 조회가 가장 효과적으로 처리될 수 있도록 접근 경로를 제공하는 오브젝트가 바로 인덱스이다
PK/FK컬럼 순서는 간단해 보이지만 실전프로젝트에서 아주 중요하다

물리적인 테이블에  FK를 사용하지 않아도 데이터 모델 관계에 의해 상속받은 FK속성들은 SQL Where 절에서 조인으로 이용되는 경우가 많이 있다.
따라서 FK 인덱스를 생성해야 성능이 좋은 경우가 많다.
그러므로 물리적인 테이블에 FK 제약을 걸었을 때는 반드시 FK 인덱스를 생성하도록 해야 한다.


23 효율적인 채번 방식을 통한 성능 향상
업무적으로 의미있는 식별자와 일련번호 형식의 시스템적 식별자에는 장단점이 존재

채번의 방법
-채번 테이블을 이용하여 일련번호를 증가시키는 방법 -> 채번구분컬럼, 채번컬럼
장:중복에러 없음, 순차적 데이터 입력 가능
단:잠금 현상 유발, 성능저하, 관리 항목 증가

-해당 테이블에 일련번호에 최대값+1을 바로 가져오면서 입력하는 방법 -> max(번호+1)
장:빠른 성능, 순차적 데이터 입력 가능, 관리항목 증가 없음
단:중복 에러 가능

-DBMS에서 제공하는 일련번호 증가 오브젝트(오라클의 시퀀스 오브젝트)를 이용하여 처리하는 방법
장:빠른 성능, 중복에러 없음, 잠금 현상 없음
단:순차적 데이터 입력 불가능, 관리 항목 증가

해당 테이블에 최대값을 처리하는 방법이 가장 권할 만하다 + PK중복 안되게 설계
예를 들어 구분자에 지역구분코드, 사업소구분코드, 업무구분코드 등을 포함하여 데이터 입력시 이코드에 따라 채번할 수 있게 하면 중복에러가 거의 발생하지 않게 되는 것

24 FK를 이용할 것인가?
FK를 생성하지 않을 때 발생하는 문제는 한가지 뿐이다
데이터의 참조 무결성이 깨지는 것이다

나중에 FK를 반영할때는 다음의 단계를 거쳐야 한다
1단계 데이터 베이스에 FK 제약 조건 생성
2단계 데이터 전환을 수행할 때 데이터의 문제점 검증(null값, 기존에 입력된 값의 FK규칙 만족성)
3단계 참조무결성으로 인해 입력되지 않은 데이터를 수정하여 전환
4단계 프로그램에 데이터 입력/수정/삭제 검증(에러가 발생하는 프로그램들을 추출하여 데이터 처리의 순서 등을 조정해야 함)
5단계 프로그램에서 데이터처리 성능 검증


25 데이터베이스 분산 설계를 활용
분산데이터의 정의
-여러곳으로 분산되어 있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스
-논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임, 물리적 site분산, 논리적으로 사용자 통합 및 공유

분산데이터베이스가 되기 위한 6가지 투명성
-분할 투명성(단편화):하나의 논리적 relation이 여러 단편으로 분할되어 각 단편의 사본이 여러 site에 저장
-위치 투명성:사용하려는 DATA의 저장 장소 명시 불필요. 위치정보가 system catalog에 유지되어야 함
-지역사상 투명성:지역 DBMS의 물리적 DB 사이의 Mapping 보장, 각 지역시스템 이름과 무관한 이름 사용 가능
-중복 투명성:DB객체가 여러 site에 중복되어 있는지 알 필요가 없는 성질
-장애 투명성:구성요소(DBMS, computer)의 장애에 무관한 transaction의 원자성 유지
-병행 투명성:다수 transaction 동시 수행시 결과의 일관성 유지, timestamp, 분산2단계 locking을 이용하여 구현

분산 설계의 방법
-테이블의 복제
-분할 분산

분산환경에서의 데이터 동기화
-트랜잭션의 동기화
-배치작업 처리
-DBMS 기능 활용

언제 적용하면 효과적일까?
성능이 중요한 사이트에 적용해야 한다
공통코드, 기준 정보, 마스터 데이터 등에 대해 분산환경을 구성하면 성능이 좋아진다.
또한 실시간 동기화가 요구되지 않을때 좋다.
거의 실시간의 업무적인 특징을 가지고 있을때도 분산환경을 구성할 수 있다.
특정 서버에 부하가 집중이 될때 부하를 분산시키는 목적으로도 좋다
백업사이트(Disaster Recovery Site)를 구성할때도 간단하게 분산 기능을 적용하여 구성할 수 있다

26 데이터베이스 진단의 핵심 원리
설계단계의 진단
1) 데이터베이스 설계 - 물리적 데이터 모델, 데이터 무결성, 오브젝트설계, 테이블스페이스 설계, 데이터베이스 환경(파라미터설계), 가용성 설계
데이터 무결성을 유지할 수 있도록 비즈니스 규칙에 따른 참조 무결성 졔약 조건, 체크값, 디폴트 값들이 적절한지 진단함
오브젝트의 크기 및 성능을 고려한 인덱스의 설계 등을 진단함
세션의 수, 사용자 수, 메모리 사용량, 업무 증가량 등을 고려하여 데이터베이스 파라미터를 설계하였는지 진단

2) 표준 설계 - 명명규칙 설계,  SQL 작성 규칙 설계
데이터베이스 오브젝트(테이블, 테이블스페이스, 데이터파일, 인덱스, 뷰, 시퀀스, 컬럼명 등)에 대한 명명규칙이 존재하는지 진단
SQL 문장 작성에 대한 규칙은 존재하는지, SQL 문장에 대한 작성 규칙은 성능을 고려하여 반영되어 있는지 진단
개발자에게 SQL 튜닝, SQL 작성 가이드를 교육하였는지를 진단

3) 데이터 전환 - 현행 데이터 분석, 데이터 전환 계획서
전환 설계에는 데이터양, 전환 절차 및 방법, 데이터 검증 절차 및 방법, 테스트 일정이 포함되어 있는지 진단

4) 데이터베이스 운영 관리 - DB 변경 관리절차, DB 성능관리 절차, 백업/복구 절차
운영환경의 DB변경 절차가 있는지, 변경 절차에 관리자의 합의/검토/조정이 포함되었는지 진단
고객의 성능에 대한 요구 사항을 도출하였는지, 적절한 성능 모니터링 방안/툴이 있는지 진단
인덱스 생성/변경/삭제의 영향 분석을 위한 방안이 있는지 진단
DB 장애/백업/복구에 대한 고객의 요구 사항을 도출하였는지 진단

5) 분산 설계 - 분산 구조, 분산 구조에 따른 모델
업무별, 지역별, 서버별 프로세스 데이터 모델의 트랜잭션이 분석되었는지 업무별, 지역별, 서버별 분산 환경에 따라 트랜잭션을 고려한 분산 데이터 모델이 작성되었는지 진단함

6) 데이터베이스 보안 설계 - 데이터베이스 보안 정책, 접근 제어 설계, 암호화 필드
DB개발자 계정과 관리자 계정은 분리하여 관리하는지 진단
패스워드 컬럼에 대한 암호화 규칙은 설계되어 있는지 진단
DBMS의 기본계정(sys, system)에 대한 패스워드는 변경되어 있는지 진단

구축단계의 진단
1) 데이터베이스 성능 - 애플리케이션 성능, 데이터베이스 구조 성능
수행 애플리케이션에 대한 성능이력을 관리하는지 진단(성능 모니터링에 의거한 지속적인 튜닝작업을 하고 있는지, 성능 점검 프로세스를 준수하고 있는지 진단)
애플리케이션성능 기준을 설정하였는지, 운영 환경 데이터베이스에 실제 환경과 유사한 테스트 데이터가 입력되어 있는지 진단함
데이터베이스 메모리의 크기를 업무, 데이터양, 시스템의 물리 메모리를 고려해 산정하였는지 진단
데이터베이스의 동시 세션수, 세션 메모리, 세션 연결 방법에 대해 적절히 산정하였는지 진단
트랜잭션양을 고려해서 redo log의 크기를 산정하였는지 진단
인스턴스 복구 시간과 성능을 고려한 체크포인트 발생 주기를 설정하였는지 진단
데이터 정렬을 위한 메모리 크기는 적절한지를 진단

2) DB 오브젝트 관리 - 인덱스 추가 설계, 명명규칙
3) 데이터 전환
4) 데이터베이스 운영 관리, 변경 관리, 백업/복구, 운영 환경 준비
컨트롤 파일과 redo log에 대한 미러링이 되어 있는지 진단
운영자 가이드 작성을 위한 준비가 되어 있는지 진단

시스템 운영시점의 진단
1) 데이터베이스 구성 - 오브젝트, 테이블 스페이스, 이중화/분산 구성
인덱스의 데이터 분포도는 인덱스 효율을 보장할 수 있는지 진단
대용량 테이블은 적절한 방법으로 파티셔닝 되어 있는지 진단
VIEW, LOB, PL/SQL은 성능 고려하여 적절하게 구현되어 있는지 진단
테이블과 인덱스의 테이블스페이스를 분리하였는지 진단
트랜잭션양을 고려하여 redo log 크기를 산정하였는지 진단
데이터베이스 클러스터링(HA, RAC)에 대한 구성은 적합한지 진단

2) 데이터베이스 성능 - SQL 성능, 데이터베이스 구조 성능
3) 데이터베이스 관리 - 변경관리, 인시던트/문제관리, 데이터관리, 용량 관리
변경 실행전 원상복구 방안이 준비되고 충분한 테스트가 이루어지고 있는지 진단
장애 시나리오별 대응 방안이 수립되어 있는지, 이를 바탕으로 장애처리 하고 있는지, 장애 시나리오별 가용성 테스트를 주기적으로 수행하고 있는지 진단
version upgrade 및 patch 적용이 적절히 이루어지고 있는지 진단
테이블 및 인덱스에 대한 reoranization작업은 주기적으로 적절하게 수행되고 있는지 진단
데이터 보관주기에 따라 데이터 purge작업이 주기적으로 적절하게 이루어지고 있는지 진단

4) 데이터 품질
PK, FK, CK등 데이터 정합성이 유지되고 있는지 진단
비즈니스적 데이터 오류, 사용자의 데이터 입력 오류가 사전에 차단되고 있는지 진단