03.09~03.10) 1-2장.데이터 모델과 성능

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

1.성능 데이터 모델링의 정의

• =>데이터의 용량이 커질수록 기업의 의사결정의 속도가 빨라질수록 데이터를 처리하는 속도는 빠르게 처리되어야 할 필요성을 반증해 준다.
• 성능이 저하되는 데이터모델의 경우
• 데이터 모델구조에 의해, 데이터가 대용량이 됨, 인덱스의 특성을 고려하지 않고 생성함
• 성능=데이터 조회의 성능( :데이터 입력/수정/삭제는 일시적이고 빈번하지 않고 단건처리vs데이터 조회는 반복적/빈번/여러번)
• 성능데이터 모델링이란 데이터베이스 성능향상을 목적으로 설계단계의 데이터 모델링 때부터 정규화, 반정규화, 테이블 통랍, 테이블 분할, 조인구조, PK,FK등 여러가지 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것으로 정의
• 
• 성능 데이터 모델링이 단순히 반정규화만을 의미하지 않음을 주의->정규화를 통해서도 수행할 수 있고, 인덱스의 특징을 고려해서 칼럼의 순서도 변형할 수 있다. 또한 대량의 데이터 특성에 따라 비록 정규화된 모델이라도 테이블을 수직/수평분할 하여 적용하는 방법도 있고 논리적인 테이블을 물리적인 테이블로 전환할 때 데이터 처리의 성격에 따라 변환하는 방법도 성능데이터 모델링의 범주에 포함 될 수 있다.

2.성능 데이터 모델링 수행시점

• =>사전에 할 수록 비용이 들지 않는다. 특히 분석/설계 단계에서 데이터 모델링을 수행할 경우 성능저하에 따른 재업무(Rework)비용을 최소화 할 수 있는 기회를 가지게 된다. 특히 데이터의 증가가 빠를수록 성능저하에 따른 성능개선비용은 기하급수적으로 증가하게 된다.
• 
• 많은 프로젝트에서 분석/설계 단계 때부터 치밀하게 하지 않고 성능이 저하된 결과만을 대상으로 문제발생 시점에 근시안적인 튜닝->SQL튜닝이 모든것인건 아니다! 따라서 분석/설계 단계에서 데이터베이스 처리 성능을 향상시킬 수 있는 방법을 주도면밀하게 고려해야 한다.

3.성능 데이터 모델링 고려사항

• 데이터 모델링을 할 때 정규화를 정확하게 수행
• 데이터 베이스 용량산정을 수행
• 데이터베이스에 발생되는 트랜젝션의 유형 파악
• 용량과 트랜잭션의 유형에 따라 반정규화 수행
• 이력모델의 조정, PK/FK조정, 슈퍼타입/서브타입 조정 등을 수행한다.
• 성능관점에서 데이터 모델을 검증한다.

제 2절 정규화와 성능

0.정규화

• 
• 

1.정규화를 통한 성능 향상 전략

• =>데이터 모델링을 하면서 정규화를 하는것은 기본적으로 데이터에 대한 중복성을 제거해주고 데이터가 관심사별로 처리되는 경우가 많기 때문에 성능이 향상되는 특징
• 데이터 베이스에서 데이터를 처리할 때 성능이라고 하면 조회성능과 입력/수정/삭제 성능의 두가지로 Trade-off되어 나타나는 경우가 많다.
• 따라서 정규화된 테이블은 데이터를 처리할 때 속도가 빨라질 수도 있고 느려질 수도 있는 특성이 있다.
• 
• 따라서 일반적으로 정규화가 잘 되어 있으면 입력/수정/삭제의 성능이 향상되고 반정규화를  많이 하면 조회의 성능이 향상된다고 인식될 수 있으나 데이터 모델링을 할 때 반정규화 만이 조회 성능을 향상시킨다는 고정관념은 탈피되어야 한다. 정규화를 해서 성능이 저하되기는 커녕 정규화를 해야만 성능이 향상되는 경우가 아주많이 나타나기 때문이다.

2.반정규화된 테이블의 성능저하 사례1

• =>정규화하여 조인이 발생하면 성능이 심각하게 저하 되는가? 2차정규화를 적용한 테이블에 대해서 조인을 하더라도 PK Unique Index를 이용하면 조인 성능 저하는 미미하게 발생된다.(누적데이터 vs driving테이블을 잘 만들어 한번에 출력)

3. 반정규화된 테이블의 성능저하 사례2

• =>대량의 데이터에서 조인조건이 되는 대상을 찾기위해 인라인 뷰를 사용하기 때문에 성능이 저하된다. 
• 복합식별자 중에서 일반속성이 주식별자 속성 중 일부에만 종속관계를 가지고 있으므로 2차 정규화의 대상이 된다. 2차 정규화를 적용하면 업무흐름에 따른 정확한 데이터 모델링 표기도 가능해지고, 드라이빙된 테이블이 원하는 내용만 갖고 있기 때문에 성능도 향상된다.(정규화 되며 드라이빙이 되는 대상 테이블의 데이터가 줄어들어 조회처리가 빨라진다.)

4.반정규화된 테이블의 성능저하 사례3

• =>동일한 속성형식을 두개 이상의 속성으로 나열하여 반정규화한 경우에 해당한다.
• (참고로 한테이블에 인덱스가 많아지면 조회성능은 향상되지만 데이터 입력/수정/삭제 성능은 저하된다.)
• 이때. 중복속성에 대한 분리가 이루어지며 1차 정규화의 대상이 되는데, 로우단위/컬럼단위로 중복이 되는 경우도 1차정규화의 대상이 된다. 정규화 되어 분리된 이후에는 인덱스 추가생성이 되지 않고, 또한 분리된 테이블에 PK인덱스를 생성/이용 함으로써 성능이 향상된다.
• =>칼럼단위에서 중복되었을땐 인덱스 생성 영향도를 파악한 이후에 적용하는것이 좋은방법이다.

5.반정규화된 테이블의 성능저하 사례4

• 1차 정규화가 안되어 컬럼단위로 중복된 모델을 1차 정규화를 통해 분리함으로 상세를 구분함으로써 트랜젝션의 성능저하를 예방할 수 있게 되었다.

6.함수적 종속성(Functional Dependency)에 근거한 정규화 수행 필요

• 함수적 종속성은 데이터들이 어떤 기준값에 의해 종속되는 현상으로 이때, 이준값을 결정자(Determinant)라 하고 종속되는 값을 종속자(Dependent)라고 한다.
• 
• =>함수의 종속성은 데이터가 가지고 있는 근본적인 속성으로 인식되고 있다. 정규화의 궁극적인 목적은 반복적인 데이터를 분리하고 각 데이터가 종속된 테이블에 적절하게(프로세스에 의해 데이터의 정합성이 지켜질 수 있어야 함) 배치되도록 하는 것이므로 이 함수의 종속성을 이용하여 정규화작업이나 각 오브젝트에 속성을 배치하는 작업에 이용되는 것이다.
• 기본적으로 데이터는 속성간의 함수종속성에 근거하여 정규화 되어야 하는데. 프로젝트 수행헤서 정규화는 선택이 아니라 필수사항이다.

제 3절 반정규화와 성능

1.반정규화를 통한 성능향상 전략

• 반정규화(=역정규화) 여기서 반은 Half 의 의미가 아닌 한자로 반대하다의 의미를 지닌  反(되돌릴 반)의 의미로, 영어로 De-Normalization 이다. 비정규화는 아예 정규화를 수행하지 않은 모델을 지칭할때 사용한다. 
• 반정규화를 정의하면 정규화된 엔터티, 속성, 관계에 대해 시스템의 성능향상과 개발(Development)과 운영(Maintenance)의 단순화를 위해 중복, 통합, 분리 등을 수 행하는 데이터 모델링의 기법(데이터를 중복하여 성능 향상)
• 데이터 무결성이 깨질 위험을 무릅쓰고 중복하여 반정규화를 적용하는 이유
• 데이터를 조회할 때 디스트 I/O량이 많아서 성능이 저하
• 경로가 너무 멀어 조인으로 인한 성능저하 예상
• 칼럼을 계산하여 읽을 때 성능이 저하될 것이 예상되는 경우 수행하게 된다.
• 
• 프로젝트에서는 설계단계에서 반정규화를 적용하게 되는데 기술적으로 수행하지 않는 경우에는
• 성능이 저하된 데이터 베이스가 생성될 수 있다.
• 구축단계나 시험단계에서 반정규화를 적용할 때 수정에 따른 노력비용이 많이 들게 된다.
• 반정규화의 적용방법
• =>난이도 높은 데이터모델링의 실무기술로 보통 프로젝트에서는 칼럼중복을 통해서만 반정규화를 수행하게 된다. 보통 중복하여 SQL문장을 단순하게 처리하도록 하기위해 요청하는데 무분별하게 반정규화를 하게되면 데이터에 대한 무결성을 깨뜨리는 결정적인 역할을 하는 경우가 많이 있다. 따라서 반정규화를 적용할 때에는 기본적으로 데이터 무결성이 깨질 가능성이 많이 있기 때문에 반드시 데이터무결성을 보장할 수 있는 방법을 고려한 이후에 반정규화를 적용하도록 해야 한다.
• =>Trade-Off관계 즉, 마치 저울추가 양쪽에 존재하여 한쪽이 무거워지면 한쪽이 올라가는 것처럼 정규화만을 강조하다 보면 성능의 이슈가 발생될 수 있고 반정규화를 과도하게 적용하다 보면 데이터 무결성이 깨질수 있는 위험이 증가하게 되는 것이다. 따라서 반정규화를 적용할 때에는 데이터 무결성이 중요함을 알고 데이터 무결성이 충분히 유지될 수 있도록 프로세스 처리에 있어서 안정성이 먼저 확인이 되어야 한다.
• 
• =>반정규화를 적용하기 위해서는 그림에 나타난 것처럼 먼저 반정규화의 대상을 조사하고 다른 방법을 적용할 수 있는지 검토하고 그 이후에 반정규화를 적용하도록 한다.
• 반정규화의 대상을 조사한다
• 반정규화의 대상에 대해 다른방법으로처리할 수 있는지 검토한다.
• 지나치게 많은 조인은 뷰(VIEW)로 해결->단, 조회의 성능을 향상시키는 역할을 하지는 않는다.
• 대량의 데이터처리나 부분처리에 의해 성능이 저하되는경우에는 클러스터링을 적용하거나 인덱스를 조정함으로써 성능 향상->클러스터링 : 대량의 데이터를 특정 클러스터링 팩트에의해 저장방식을 다르게 하는방법. 데이터를 입력/수정/삭제하는 경우 성능이 많이 저하../인덱스를 통해 성능을 충분히 확보 할 수 있다면 인덱스를 조장하여 반정규화 회피
• 응용 애플리케이션에서 로직을 구사하는 방법을 변경함으로 성능 향상->응용메모리영역이나 중간 클래스 영역에 데이터를 캐쉬하여 공유해 성능향상
• 반정규화를 적용한다->반정규화를 하는 대상으로는 테이블, 속성, 관계에 대해 적용할 수 있으며 꼭 테이블과 속성, 관계에 대해 중복으로 가져가는 방법만이 반정규화가 아니고 테이블, 속성, 관계를 추가할 수도 있고 분할할 수도 있으며 제거할 수도 있다. 성능을 향상시킬 수 있는 포괄적인 방법을 적용하여 반정규화를 적용하는것이 전문화된 반정규화의 기법임을 기억하자

2.반정규화의 기법

• 테이블 반정규화
• 
• 칼럼 반정규화 +rollback기능을 갖고 있다.
• 
• 관계 반정규화
• 

3.정규화가 잘 정의된 데이터 모델에서 성능이 저하될 수 있는 경우

• =>공급자와 전화번호, 메일주소, 위치는 1:M관계로 한명의 공급자당 여러개의 값들이 존재한다. 따라서 최근 변경된 값을 가져오기 위해서는 복잡한 조인이 발생된다. 위의 모델을 적절하게 반정규화를 적용하면, 즉 가장 최근에 변경된 값을 마스터에 위치시키면 다음과 같이 아주 간단한 SQL구문이 된다.
• 
• =>위에서 복잡하던 SQL문장이 반정규화를 적용하므로 인해 다음과 같이 간단하게 작성이 되어 가독성도 높아지고 성능도 향상되었다.
  

4.정규화가 잘 정의된 데이터 모델에서 성능이 저하된 경우

• 
• =>데이터베이스서버가 여러 대인 경우(분산데이터베이스가 구성되어있을때) 반정규화를 통해 성능을 향상시킬수 있는 경우로 Oracle의 경우 DB LINK JOIN이 발생하여 일반조인보다 성능이 저하된다. 그 땐 속성 반정규화를 함으로써 조회성능을 향상시킬 수 있다.(연결->연결하여 링크조인인것일까 그냥 연결고리를 얘기하는 것일까?)
• 
• =>반정규화를 하면 SQL구문도 간단해 지고 분산되어있는 서버간에도 DB LINK JOIN이 발생하지 않아 성능이 개선되었다. 반정규화를 적용할때 기억해야 할 내용은 데이터를 입력,수정,삭제 할 때는 성능이 떨어지는 점을 기억해야 하고 데이터의 무결성 유지에 주의를 해야 한다.(중복을 피하려했으나 걸리는 시간에 손실이 더커 중복해주는것)

제 4절 대량 데이터에 따른 성능

1.대량 데이터발생에 따른 테이블 분할 개요

• 
• 칼럼이 많아지게 되면 물리적인 디스크에 여러 블록에 데이터가 저장되게 된다. 따라서 데이터를 처리할 때 여러 블록에서 데이터를 I/O해야하는 즉 SQL문장의 성능이 저하될 수 있는 특징을 가지게 된다. 함수적 종속성에 근거하여 하나의 테이블에 설계할 수도 있으나 대량의 데이터를 가진테이블에서 불필요하게 많은양의 I/O를 유발하여 성능이 저하되는경우에는 성능을 향상하는 방법으로 분할 할 수 있다.
• 
• 블럭=레코드 여러개
• 워드=한번에 불러올 수 있는 양
• =>이렇게 많은 칼럼은 로우체이닝과 로우마이그레이션이 많아지게 되어 성능이 저하된다.
• 로우체이닝(Row Chaining)현상 : 로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 두개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태
• 로우마이그레이션(Row Migration)현상 : 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈공간을 찾아 저장하는 방식
• 이 두가지 현상이 발생하여 많은 블록에 데이터가 저장되면 데이터베이스메모리에서 디스크와 I/O(입력/출력)가 발생할때 불필요하게 I/O가 많이 발생하여 성능이 저하된다.

2.한 테이블에 많은 수의 칼럼을 가지고 있는 경우

• 칼럼수가 많은 테이블에서 데이터 처리를 하게되면 디스크 I/O양이 증가하여 성능이 저하.->트랜젝션이 발생될때 집중되는 칼럼을 분석하여 테이블을 쪼개어 주면 I/O가 감소하게 되어 성능이 개선됨(1:1분리)
• 
•  트랜젝션이 독립적으로 발생되는 경우가 많아 1:1관계로 분리하였다. 트랜잭션을 분석하여 적절하게 1:1 관계로 분리함으로 성능향상이 가능하도록 해야 한다.

3.대량 데이터 저장 및 처리로 인해 성능 저하

• =>많은양의 데이터(몇 천만건을 넘어서면 성능이 나오지 않음)가 예상될 경우 파티셔닝을 적용하거나 PK에 의해 테이블을 분할하는 방법을 적용 할 수 있다. Oracle의 경우 크게 LIST PARTITION(특정값 지정), RANGE PARTITION(범위), HASH PARTITION(해쉬 적용), COMPOSITE PARTITION(범위와 해쉬가 복합) 등이 가능하다.=>여러개의 테이블스페이스에 쪼개어 저장하는 파티셔닝
• RANGE PARTITION 적용
• PK를 이용하여 파티션테이블을 나눔=>프로그램은 하나의테이블에 접근하면 내부적으로 RANGE로 구분된 테이블에서 트랜젝션을 처리한다.
• 가장많이 사용하는 파티셔닝의 기준이 RANGE PARTITION으로 대상테이블이 날짜 또는 숫자값으로 분리가 가능하고, 각 영역별로 트랜잭션이 분리된다면 RANGE PARTITION을 적용한다. 보관주기에 따라 데이터를 지우는것도 쉬워 데이터보관주기에 다른 테이블 관리가 용이하다.(월별)
• LIST PARTITION 적용
• 지점, 사업소, 사업장 등의 핵심적인 코드값 등으로 PK가 구성되어 있고 대량의 데이터가 있는 테이블이라면 값 각각에 의해 파티셔닝이 되는 LIST PARTITION을 적용 할 수 있다.
• 프로그램이 하나의 테이블에 접근하면 내부적으로 LIST로 구분된 파티션 테이블에서 트랜잭션을 처리한다.
• LIST PARTITION은 대용량데이터를 특정값에 따라 분리 저장할 수는 있으나 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.(지역별)
• HASH PARTITION 적용
• 지정된 HASH 조건에 따라 해슁알고리즘이 적용되어 테이블이 분리되며 설계자는 테이블에 데이터가 정확하게 어떻게 들어갔는지 알 수 없다. 역시 성능향상을 위해 사용하며 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없다.
• (난수발생으로 인해 쓰는 애들만 씀..?)

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

• 데이터 모델링을 완성한다
• 데이터베이스 용량산정(데이터의 양이 대용량이 되는지 분석)을 한다.
• 대량 데이터가 처리되는 테이블에 대해서 트랜잭션 처리패턴을 분석한다.
• 컬럼단위로 집중화된 처리가 발생하는지, 로우단위로 집중화된 처리가 발생되는지 분석하여 집중화된 단위로 테이블을 분리하는 것을 검토한다.(분리할 수 있는지, 파티셔닝 전략 고려하여 적용)

제 5절 데이터베이스 구조와 성능

1.슈퍼타입/서브타입 모델의 성능고려 방법

• 슈퍼/서브타입 데이터 모델의 개요
•  Extended ER모델이라고 부르는 이른바 슈퍼/서브타입 데이터 모델은 최근 자주 쓰이는 방법으로 업무를 구성하는 데이터의 특징을 공통과 차이점의 특징을 고려하여 효과적으로 표현할 수 있기 때문이다.
• 즉, 공통의 부분을 슈퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의 서브엔터티로 구분하여 정확하게 표현한다는 장점.
• 논리적인 데이터 모델에서 이용되는 형태이고, 분석단계에서 많이 쓰인다. 따라서 물리적인 데이터 모델을 설계하는 단계에서 일정한 기준에 의해 변환하는데 기준이 없이 변환하는것 자체가 성능저하가 될 수 있음을 기억하자
• 슈퍼/서브타입 데이터 모델의 변환
•  
  
• 슈퍼/서브타입에 대한 변환을 잘못하면 성능이 저하되는 이유는 트랜잭션의 특성을 고려하지 않고 테이블이 설계되었기 때문이다.
• 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union연산에 의해 성능이 저하
• 트랜잭션은 항상 서브타입 개별로 처리하는데, 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 있어 성능이 저하
• 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하
• =>해당 테이블에 발생되는 성능이 중요한 트랜잭션이 빈번하게 처리되는 기준에 따라 테이블을 설계해야 이러한 성능저하 현상을 예방할 수 있음을 기억해야 한다.
• 슈퍼/서브 타입 성능을 고려한 물리적인 데이터 모델로 변환하는 기준은 데이터 양과 해당 테이블에 발생되는 트랜잭션의 유형에 따라 결정된다.
• 슈퍼/서브타입 데이터 모델의 변환 기술
• 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
• 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성(Plus Type변환)
• 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성(통합처리->하나의 테이블)
• 슈퍼/서브타입 데이터 모델의 변환타입 비교
• 
• 각각의 type별로 특징이 있고 데이터처리를 할 때도 성능이 좋을수도 나쁠수도 있기 때문에 변환모델의 선택은 철저하게 데이터베이스에 발생되는 트랜잭션의 유형에 따라 선택해야 한다.

2.인덱스 특성을 고려한 PK/FK 데이터베이스 성능 향상

• PK/FK 칼럼 순서와 성능개요
• 데이터를 조회할 때 가장 효과적으로 처리될 수 있도록 접근경로를 제공하는 오브젝트가 바로 인덱스이다. 일반적으로 데이터베이스 테이블에서는 균형잡힌 트리구조의 B*Tree구조를 많이 사용하는데 내부알고리즘까지는 알 필요가 없더라도 이 특징에 따라 설계에 반영해야 할 요소에 대해서는 반드시 알고 있어야 좋은데이터 모델을 만들 수 있다.
• 
• 간단한 것 같지만 실전 프로젝트에서는 아주 중요한 내용이 바로 PK순서이다. 인덱스의 특징은 여러 개의 속성이 하나의 인덱스로 구성되어 있을때 앞쪽에 위치한 속성이 값이 비교자로 있어야 인덱스가 좋은 효율을 나타낸다.
• PK칼럼의 순서를 조정하지 않으면 성능 저하 이유
• 데이터모델링에서 엔터티를 설계하면 그에따라 DDL이 생성되고 그에 따라 인덱스가 셍성된다. 이 때 우리가 알아햐 할 구조는 인덱스의 정렬구조이다. 위와같은 인덱스 정렬 구조에서 SQL구문의 조건에 따라 인덱스를 처리하는 범위가 달라지게 된다. 맨앞에 있는 인덱스 칼럼에 대해 조회조건이 들어올때 데이터를 접근하는 방법은 인덱스의 정렬된 첫번째 칼럼에 비교가 되었기 때문에 순차적으로 데이터를 찾아가게 되어 맨앞에 있는 칼럼이 제외된 상태에서 데이터를 조회 할 경우 비교하는 범위가 매우 넓어지게 되어 성능저하 유발.
•  =>PK의 순서를 인덱스 특징에 맞게 고려하지 않고 바로 그대로 생성하게 되면, 테이블에 접근하는 트랜잭션의 특징에 효율적이지 않은 인덱스가 생성되어 있으므로 인덱스의 범위를 넓게 이용하거나 Full Scan을 유발하게 되어 성능저하!
• PK순서를 잘못 지정하여 성능이 저하된 경우 - 간단한 오류
• PK순서만 제대로 지정해주어도 테이블 FULL SCAN을 하게되었던게 인덱스 스캔을 하게되어 성능이 향상된다. 빈번하게 들어오는 순으로 변경함으로 인덱스를 이용가능하도록 할 수 있다.
•  PK순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류
• 인덱스를 이용하였으나 최적화된 인덱스 이용이 안된 경우로 튜닝이 잘된것으로 착각할 수 있는데, 문제는 인덱스를 이용하기는하는데 얼마다 효율적으로 이용하는지 검증이 필요하다. BETWEEN비교를 한 거래일자가 앞에 위치하면 범위가 넓어지지만 사무소코드의 인덱스의 경우 '='비교를 한 경우 범위가 좁아졌다.(좁은 범위로 검색이 가능해 검색할 때 성능 향상)
• 그러므로 이 경우 인덱스 순서를 고려하여 데이터 모델의 PK순서를 수정하여 성능을 개선할 수 있다. 최적화된 인덱스 생성을 위해 PK순서변경을 통한 인덱스 생성이 바람직하다.

3.물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하

• FK컬럼으로 WHERE절에 비교자로 들어오지는 않았지만 인덱스를 생성하지 않아 조인이 되면서 FULL TABLE SCAN이 발생하여 성능저하가 발생했다. 이때는 FK인덱스를 생성하여 성능을 개선할 수 있다.
• 비록 물리적으로 연결되어 있지 않다고 하더라도 학사기준으로부터 상속받은 FK에 대해 FK인덱스를 생성함으로써 SQL문장이 조인이 발생할 때 성능저하를 예방할 수 있다.
• 데이터 양이 누적될수록 성능이 떨어져 장애현상을 초래한다. 그러므로 물리적인 테이블에 FK제약을 걸었을 때는 반드시 FK인덱스를 생성하도록 하고 FK제약이 걸리지 않았을 경우에는 FK인덱스를 생성하는것을 기본정책으로 하되 발생되는  트랜잭션에 의해 거희 활용되지 않았을때에만 FK인덱스를 지우는 방법으로 하는 것이 적절한 방법이 된다.

제 6절 분산 데이터베이스와 성능

1.분산 데이터베이스의 개요

• 여러 곳으로 분산되어있는 데이터베이스를 하나의 가상시스템으로 사용할 수 있도록 한 데이터베이스
• 논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임. 물리적 Site 분산, 논리적으로 사용자 통합/공유
• =>즉, 분산 데이터베이스는 데이터베이스를 연결하는 빠른 네트워크 환경을 이용하여 데이터 베이스를 여러지역 여러노드로 위치시켜 사용성/성능 등을 극대화 시킨 데이터베이스이다.

2.분산 데이터베이스의 투명성(Transparency)

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

3.분산 데이터베이스의 적용 방법 및 장단점

• 분산 데이터베이스 적용방법
• 업무이 흐름을 보고 업무 구성에 따른 아키텍쳐 특징에 따라 데이터베이스를 구성. 단순히 구축 목적이 아니라, 업무의 특징에 따라 데이터베이스 분산구조를 선택적으로 설계하는 능력이 필요. =>데이터베이스 분산설계라는 측면보다는 데이터베이스 구조설계(아키텍쳐)라는 의미로 이해해도 무방
• 분산 데이터베이스 장단점
• 

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

• =>업무적인 기능이 다양해지고 데이터의 양이 기하급수적으로 증가하는 최근 데이터베이스환경에서 적용하는 고급화된 기술이다. 업무적인 특징에 따라 분산 데이터베이스를 활용하는 기술 필요.
• 

5.데이터베이스의 분산구성의 가치

• 통합된 데이터베이스에서 제공할 수 없는 빠른성능 제공(데이터 처리 성능)

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

• =>가장 많이 사용하는 방식은 테이블 복제 분할 분산(가장 유용하게 적용)이고, 방법으로는 일단 통합 데이터 모델링을 하고 각 테이블별 업무적인 특징에 따라 테이블을 분산 배치나 복제배치 하는 형태로 설계한다.
• 테이블 위치 분산
• 케이블의 구조는 변하지 않고, 또한 다른 데이터베이스에 중복되서 생성되지도 않는다. 다만 설계된 테이블의 위치를 각각 다르게 위치시키는 것이다.
• 
• 테이블별 위치분산은 정보를 이용하는 형태가 각 위치별로 차이가 있을 경우에 이용. 위치를 파악할 수 있는 도식화된 위치별 데이터베이스 문서가 필요하다.
• 테이블 분할(Fragmentation) 분산
• =>테이블 분할분산은 단순히 위치만 다른곳에 두는것이 아니라 각각의 테이블을 쪼개어 분산하는 방법이다. 로우단위로 분리하는 수평분할(Horizontal Fragmentation)과 칼럼(Column)단위로 분할하는 수직분할(Vertical Fragmentation)이 있다.
• 수평분할 (Horizontal Fragmentation)
• 지사(Node)에 따라 특정 칼럼의 값을 기준으로 로우(Row)를 분리. 모든데이터가 각 지사별로 분리되어이 있는 형태로 항상 배타적으로 존재하며, 데이터를 한군데 집합시켜 놓아도 Primary Key에 의해 중복이 발생되지 않는다.
• 각 지사별로 사용하는 로우가 다를때 이용하며, 타 지사에 있는 데이터를 원칙적으로 수정하지 않고 자신의 데이터에 대해서 수정하도록한다. 통합처리를 해야 하는 경우는 조인이 발생해 성능저하가 예상되므로 프로세스가 많은지 검토후에 많지 않은경우에 수평분할을 한다.
• 데이터가 지사별로 별도로 존재해 중복은 발생하지 않아 데이터의 무결성은 보장된다.
• 
• 수직분할 (Vertical Fragmentation)
• 지사에 따라 칼럼을 기준으로 칼럼(Column)을 분리. 로우단위로는 분리되지 않는다. 모든데이터가 각 지사별로 분리되어있는 형태로 칼럼기준이라 동일한 Primary Key의 구조와 값을 가져야 한다. 데이터를 한군데 집합시켜 놓아도 동일한 Primary key는 하나이므로 데이터 중복은 발생되지 않는다.
• 
• 테이블의 전체 칼럼 데이터를 보기 위해서는 각 지사별로 조인하여 가져와야 하므로 가능하면 통합처리 프로세스가 많은 경우에는 이용하지 않도록한다. 일반적으로 실제 프로젝트의 사례는 드물다.
• 테이블 복제(Replication) 분산
• =>동일한 테이블을 다른 지역이나 서버에서 동시에 생성하여 관리하는 유형으로 마스터 데이터베이스에서 일부만 위치시키는 부분복제와 내용을 각 지역이나 서버에 존재시키는 광역복제가 있다.
• 부분복제(Segment Replication)
• 통합된 테이블을 한군데(본사)에 가지고 있으면서 각 지사별로는 지사에 해당된 로우를 가지고 있는 형태이다.
• 본사의 데이터는 지사데이터의 합이 되는것으로 지사별 처리와 전체데이터에 대한 통합처리도 가능해 조인이 발생하지 않는 빠른 작업 수행이 가능해 진다.
• 지사간에는 데이터의 중복이 발생하지 않으나 본사와 지사간에는 데이터의 중복이 항상 발생하게 되는 경우로 보통 지사에 먼저 발생하고 본사데이터는 통합하여 발생된다.
• 
• 실제 많이 사용하는 데이터베이스 분산기법으로 복제에 시간이 소요되고 부하가 발생해 실시간보다는 야간에 배치작업에 의해 수행되는 경우가 많다. 또한 수정하는 경우 정합성을 일치시키는 것이 어렵기 때문에 가능하면 한쪽(지사) 에서 데이터의 수정이 발생하여 본사로 복제(Replication)을 하도록 한다.
• 광역복제(Broadcast Replication)
• 통합된 테이블을 한군데(본사) 에 가지고 있으면서 각 지사에도 본사와 동일한 데이터를 모두 가지고 있는 형태. 지사에 존재하는 데이터는 반드시 본사에도 존재하며 모든 지사에 있는 데이터양과 본사에 있는 데이터양이 다 동일하다. 모두 동일한 정보를 가져 데이터 처리에 특별한 제약을 받지 않는다. 
• 예를 들어, 본사에서 코드테이블에 데이터에 대해 입력,수정,삭제가 발생하고 각 지사에서는 코드 데이터를 이용하는 프로세스가 발생한다. 즉 본사에서는 데이터를 관리하고 지사에서는 이데이터를 읽어 업무프로세스를 발생시키는 것이다.
• 
• 광역복제 역시 실제 프로젝트에서 많이 사용하는 분산기법으로 부분복제의 경우는 지사에서 데이터에 대한 입력,수정,삭제가 발생하여 본사에서 이용하는 방식이 많은방면 광역복제의 경우는 본사에서 데이터가 입력,수정,삭제가 되어 지사에서 이용하는 형태가 차이점이다.
• 부분복제와 마찬가지로 데이터를 복제하는데 많은 시간이 소요되고 부하가 발생하므로 실시간처리로 복사하는 것보다는 배치에 의해 복제가 되도록한다.
• 테이블 요약(Summarization) 분산
• =>테이블 요약 분산은 지역간에 또는 서버간에 데이터가 비슷하지만 서로 다른 유형으로 존재하는경우로 요약의 방식에 따라, 동일한 테이블 구조를 가지고 있으면서 분산되어있는 동일한 내용의 데이터를 이용하여 통합된 데이터를 산출하는 방식의 분석요약과 분산되어 있는 다른 내용의 데이터를 이용하여 통합된 데이터를 산출하는 방식의 통합요약이 있다.
• 분석요약(Rollup Replication)
• 각 지사별로 존재하는 요약정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방법이다.
• 
• 모든 칼럼과 로우가 지사에도 동일하게 존재하지만 지사에는 동일한 내용에 지사별로 요약한 정보를 가지고 있고 본사에는 각 지사의 요약정보를 통합하여 재 산출하여 전체애 대한 요약정보를 가지고 있는것으로 표시되어있다.
• 
• 각종 통계데이터를 산정할 경우에, 모든 자사의 데이터를 이용하여 처리하면 성능이 지연되고 각 서버에 부하를 주기 때문에 업무에 장애가 발생할 수 있다. 통합 통계 데이터에 대한 정보제공에 용이한 분산방법으로 본사에 분석요약된 테이블을 생성하고 데이터는 역시 업무가 종료되는 야간에 수행하여 생성한다.
• 통합요약(Consolidation Replication)
• 각 지사별로 존재하는 다른 내용의 정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방법
• 
• 테이블에 있는 모든 칼럼과 로우가 지사에도 동일하게 존재하지만 각 지사에는 타지사와 다른 요약정보를 가지고 있고 본사에는 각 지사의 요약정보를 데이터를 같은 위치에 두는것으로 통합하여 전체에 대한 요약정보를 가지고 있는것으로 표시된다.
• 
• 통합요약은 단지 지사에서 산출한 요약정보를 한군데에 취합하여 보여주는 형태로 분석요약은 지사에 있는 데이터를 이용하여 본사에서 통합하여 요약데이터를 산정하였지만 통합요약에서는 지사에서 요약한 정보를 본사에서 취합하여 각 지사별로 데이터를 비교하기 위해 이용되는 것이다.
• 각종 통계데이터를 산정할 경우에, 조인하여 처리하면 성능이 지연되고 각서버에 부하를 주기 때문에 업무에 장애가 발생할 수 있다. 따라서 통합요약은 통합 통계데이터에대한 정보제공에 용이한 분산방법이다. 본사에 통합요약된 테이블을 생성하고 데이터는 역시 야간에 수행하여 생성하는것이 일반적인 적용방법이다.

7.분산 데이터베이스를 적용하여 성능이 향상된 사례

• =>복제분산의 원리를 간단하게 응용하면 많은 업무적인 특성이 있는 곳에서 그성능을 향상시켜 설계할 수있다. 단순한 개념도 이지만 위의 원리가 복잡한 업무처리에서 효과적으로 성능을 향상시킬수 있음을 주목
• 
• 성능이 중요한 사이트에 적용
• 공통코드, 기준정보, 마스터 데이터 등에 대해 분산환경을 구성하면 성능이 좋아진다.
• 실시간 동기화가 요구되지 않을 때 좋다. 거의 실시간 (Near Real Time)의 업무적인 특징을 가지고 있을때도 분산환경을 구성할 수 있다.
• 특정 서버에 부하가 집중될 때 부하를 분산할 때도 좋다
• 백업 사이트(Disaster Recovery Site)를 구성할 때 간단하게 분산기능을 적용하여 구성할 수 있다.
• ==>혼합하여 많이 사용한다.