[SQLD] 1-2 데이터 모델링과 성능

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

성능 저하 요인

1) 데이터 모델 구조 2) 데이터가 대용량이 되는 경우 3) 인덱스 특성을 충분히 고려하지 않고 인덱스 생성하는 경우

 

성능 => 보통 데이터조회의 성능을 의미

- 데이터입력/수정/삭제는 일시적이며 빈번하지 않고 단건 처리가 많으나 데이터조회의 경우 반복적이고 빈번하며 여러 건을 처리하는 경우가 많음.

- 일반적으로 트랜잭션의 성격이 조회의 패턴이나 업무에 따라서는 입력/수정/삭제의 성능이 중요한 경우도 존재

 

성능 데이터 모델링

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

 

수행시점

- 분석/설계 단계 => 성능저하에 따른 재업무 비용을 최소화할 수 있는 기회를 가짐

-> 데이터의 증가가 빠를수록 성능저하에 따른 성능개선비용은 기하급수적으로 증가하게 됨

 

고려사항

1) 데이터 모델링을 할 때 정규화를 정확하게 수행

- 주요 관심사별로 분산시키는 효과

2) 데이터베이스 용량산정을 수행

- 각각의 엔티티에 어느정도 트랜잭션이 들어오는지 파악(어떤 엔티티에 데이터가 집중되는지)

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

- CRUD매트릭스를 보거나 객체지향모델링의 경우 시퀀스 다이어그램을 확인

- 조인 관계 테이블에서 데이터조회의 칼럼을 파악할 수 있음.

4) 용량과 트랜잭션의 유형에 따라 반정규화 수행

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

5) 이력모델의 조정, PK/FK조정, 슈퍼타입/서브타입 조정 등을 수행

- 대량 데이터가 처리되는 이력모델에 대해 성능고려/ PK,FK를 성능이 우수한 순서대로 칼럼의 순서를 조정

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

- 일반적인 데이터 모델 규칙뿐만 아니라 충분하게 성능이 고려되었는지 체크리스트에 포함하여 검증

제2절 정규화와 성능

정규화

- 기본적으로 데이터에 대한 중복성을 제거하고 데이터가 관심사별로 처리되는 경우가 많기 때문에 성능이 향상

- 과도하면 조인이 많이 발생하여 오히려 성능 저하

- 데이터 처리시 성능(조회 성능, 입력/수정/삭제 성능)

- 결정자에 의해 함수적 종속을 가지고 있는 일반속성을 의존자로 하여 입력/수정/삭제 이상을 제거

- 입력/수정/삭제할 때 일반적인 반정규화된 테이블에 비해 처리 성능 향상되나 처리조건에 따라 조회 성능을 향상되거나 저하됨

- 정규화 후 오히려 조회 성능이 향상되는 경우도 있기에 (정규화=> 입력/수정/삭제 향상 반정규화 => 조회 향상)X 

> 한 테이블의 데이터 용량이 최소화

 

함수적 종속성

- 데이터들이 어떤 기준값(결정자)에 의해 종속(종속자)되는 현상

- 반복적인 데이터를 분리하고 각 데이터가 종속된 테이블에 적절하게 배치되도록 하는 것으로 함수의 종속성을 이용하여 정규화 작업이나 각 오브젝트에 속성을 배치하는 작업에 이용

제3절 반정규화와 성능

반정규화

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

- 데이터를 중복하여 향상시키기 위한 기법 --> 성능을 향상시키기 위해 정규화된 데이터모데레에서 중복, 톡합, 분리 등을 수행하는 모든 과정

- 데이터를 조회할 때 디스크I/O량이 많아서 성능이 저하되거나 경로가 너무 멀어 조인으로 인한 성능저하가 예상되거나 칼럼을 계산하여 읽을 때 성능이 저하될 것이라고 예상되는 경우 사용

- 업무적으로 조회에 대한 처리성능이 중요하다고 판단될 때 부분적으로 반정규화 고려

- 함수적 종속관계는 위반하지 않지만 데이터의 중복성을 증가시켜야한 데이터조회의 성능을 향상되는 경우 사용

 

기술적으로 수행하지 않는 경우 문제점

1) 성능이 저하된 DB가 생성될 수 있음

2) 구축단계나 시험단계에서 반정규화를 적용할 때 수정에 따른 노력비용이 많이 듦

 

적용방법

- 보통 SQL문 작성이 복잡해지고 조인이 많아짐에 따른 성능저하가 예상되는 경우 사용

- 칼럼, 테이블, 관계의 반정규화를 종합적으로 고려하여 적용

- 중복을 유도, 성능을 향상시키는 방법을 고려해야함

- 정규화의 경우 성능 이슈, 반정규화의 경우 데이터 무결성의 이슈가 발생하기에 데이터 무결성이 충분히 유지될 수 있도록 프로세스 처리에 있어 안정성이 먼저 확인되어야 함

 

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

- 데이터의 양을 조사하여 그 데이터가 해당 프로세스가 처리될 때 성능저하가 나타나는가?

-> 자주 사용되는 테이블에 접근하는 횟수가 많고 항상 일정한 범위만 조회하는 경우

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

-> 통계성 프로세스에 의해 통계 정보를 필요로 할 때 별도의 통계테이블 생성

-> 테이블에 지나치게 많은 조인이 걸려 데이터를 조회하는 작업이 기술적으로 어려울 경우

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

-> 지나치게 많은 조인이 걸려 데이터 조회하는 작업이 기술적으로 어려울 경우 뷰를 사용( 뷰가 조회 성능을 향상X)

 성능을 고려한 뷰를 생성하여 개발자가 뷰를 통해 접근하게 하여 성능저하의 위험을 예방하는 것이 좋은 방법

-> 대량의 데이터 처리나 부분처리에 의해 성능이 저하되는 경우 클러스터링을 적용하거나 인덱스를 조정하여 성능향상

대량의 데이터를 특정 클러스터링 팩터에 의해 저장방식을 다르게=>입력/수정/삭제시 성능 저하 (only 조회중심 table)

인덱스를 조정하여 성능 향상이 가능하다면 인덱스를 조정하여 반정규화를 회피하도록 함

-> 대량의 데이터는 PK의 성격에 따라 부분적인 테이블로 분리 (파티셔닝 기법(물리적인 저장기법)으로 성능저하 방지)

특정 기준에 의해 다른게 저장되고 파티셔닝 키에 따른 조회시 성능이 좋아지는 특성

when 특정 기준에 따라 물리적 저장공간에 구분될 수 있고 트랜잭션이 들어올 때 일정한 기준에 의해 들어오는 경우

-> 응용 애플리케이션에서 로직을 구사하는 방법을 변경함으로써 성능 향상

응용 메모리 영역에 데이터를 처리하기 위한 값을 캐쉬하거나 중간 클래스 영역에 데이터를 캐쉬하여 공유

3. 반정규화 적용 (테이블, 속성, 관계)

- 반정규화를 하는 대상으로는 테이블, 속성, 관계에 대해 적용 가능

- 테이블, 속성, 관계에 대해 중복을 가져가는 방법만이 반정규화가 아니라 테이블, 속성, 관계를 추가, 분할, 제거 가능

 

테이블과 칼럼의 반정규화는 데이터 무결성에 영향을 주나 관계의 반정규화는 데이터 무결성을 깨뜨릴 위험을 갖지 않고서도 데이터처리의 성능을 향상시킬 수 있음

> 데이터 모델 전체가 관계로 연결되어 있고 관계가 서로 먼 친척간의 조인 관계가 빈번하다면 관계의 비정규화를 통해 성능향상 도모

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

- 트랜잭션이 분산 처리될 수 있도록 테이블단위에서 분할의 방법을 적용할 필요가 있음.

1) 하나의 테이블에 대량의 데이터가 존재하는 경우 > 인덱스의 Tree구조가 너무 커져 효율성이 떨어져 디스크 I/O 유발

- 대량의 데이터가 하나의 테이블에 존재하는 경우 인덱스를 찾아가는 단계가 깊어져 조회 성능에 영향

- 인덱스의 크키가 커질경우 조회 성능에는 영향이 적어지지만 입력/수정/삭제의 경우 성능의 저하가 유발

- 특히 범위 조회시 더 많은 I/O 유발하여 성능저하를 유발

2) 한 테이블에 많은 수의 칼럼이 존재시 데이터가 디스크의 여러 블록에 존재 > 디스크에서 데이터를 읽는 I/O양 증가

- 데이터 처리시 여러 블록에서 데이터를 I/O해야 하는 성능이 저하되는 특징을 가짐

- 대량 데이터를 가진 테이블에서 불필요하게 많은 양의 I/O를 유발하여 성능 저하시 기술적 분석으로 분할 가능

 

로우체이닝 - 로우 길이가 너무 길어서 데이터 블록 하나에 데이터가 모두 저장되지 않고 두 개 이상의 블록에 걸쳐 하나의 로우가 저장되어 있는 형태

로우마이그레이션 - 데이터 블록에서 수정이 발생하면 수정된 데이터를 해당 데이터 블록에서 저장하지 못하고 다른 블록의 빈 공간을 찾아 저장하는 방식

=> 불필요한 I/O가 많이 발생하여 성능이 저하됨

 

많은 칼럼을 가지고 있는 테이블 - 트랜잭션 발생시 어떤 칼럼에 대해 집중적으로 발생하는지 분석하여 테이블 분할

 

테이블에 많은 양의 데이터가 예상되는 경우 > 파티셔닝을 적용하거나 PK에 의해 테이블을 분할하는 방법 적용 가능

Oracle > LIST PARTITION(특정값 지정), RANGE PARTITION(범위), HASH PARTITION(해쉬적용), COMPOSITE PARTITION(범위와 해쉬가 복합)

=> 하나의 테이블로 보이지만 물리적으로 여러 개의 테이블스페이스에 쪼개어 저장될 수 있는 구조의 파티셔닝을 적용

1) RANGE PARTITION -> 테이블이 날짜 혹은 숫자값으로 분리가 가능하고 각 영역별로 트랜잭션이 분리 가능시

- 데이터보관주기에 따라 테이블에 데이터를 쉽게 지우는 것이 가능하여 데이터 보관주기에 따른 테이블 관리 용이

2) LIST PARTITION  -> 핵심적인 코드값등으로 PK가 구성되어 있고 대량의 데이터가 있는 테이블이라면 값 각각에 의해 파티션

- 대용량의 데이터를 특정값에 따라 분리저장은 가능하나 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공X

3) HASH PARTITION -> 지정된 hash 조건에 따라 해싱 알고리즘이 적용되어 테이블이 분리되며 설계자는 데이터가 정확하게 어떻게 들어갔는지 알 수 없음

- 데이터 보관주기에 따라 쉽게 삭제하는 기능은 제공될 수 없음

 

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

1) 데이터 모델링 완성

2) 데이터베이스 용량산정을 함

- 어느 테이블에 데이터의 양이 대용량이 되는지 분석

3) 대량 데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석

4) 칼럼 단위로 집중화된 처리가 발생하는지, 로우단위로 집중화된 처리가 발생되는지 분석하여 집중화된 단위로 테이블 분리

- 칼럼수가 많은 경우 > 트랜잭션의 특성에 따라 테이블을 1:1 형태로 분리되는지 검증

- 칼럼수가 적지만 데이터 용량이 많은 경우 > 테이블에 대해 파티셔닝 전략을 고려(임의 or 발생되는 시간)

 

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

Extended ER 모델(슈퍼/서브타입 데이터 모델)

- 공통의 부분을 슈퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성에 대해 별도의 서브 엔티티로 구분 ( 물리적 데이터 모델로 변환시 선택의 폭을 넓힐 수 있음)

- 논리적 데이터 모델에서 이용되는 형태이며 분석단계에서 많이 쓰이는 모델

 

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

- 1:1 타입/ 슈퍼+서브 타입 / All in One 타입

 

변환을 잘못하여 성능이 저하되는 경우

1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union 연산에 의한 저하

2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블이 하나로 통합되어 있어 많은 양의 데이터가 집약에 의한 저하

3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하

 

슈퍼/서브타입을 성능을 고려한 물리적인 데이터 모델로 변환 => 데이터 양과 해당 테이블에 발생되는 트랜잭션 유형

 

데이터 양

- 데이터양이 소량일 경우 성능에 영향을 미치지 않아 데이터처리의 유연성을 고려하여 가급적 1:1 관계를 유지

=> 트랜잭션의 성격을 고려하지 않고 전체를 하나의 테이블로 묶어도 좋은 방법

- 데이터용량이 많아지는 경우 해당 업무적인 특징이 성능에 민감한 경우 3가지 변환방법 사용

1) 개별로 발생되는 트랜잭션에 대해 개별 테이블로 구성

- 업무적으로 발생되는 트랜잭션이 슈퍼타입, 서브타입 각각 발생

- 독립적으로 발생시 슈퍼타입에도 꼭 필요한 속성만 가지게 하고 서브타입에도 꼭 필요한 속성 및 자신의 타입에 맞는 데이터만 가지게 하기 위해 모두 분리하여 1:1 관계를 가짐

- 데이터량이 대용량으로 존재하는 경우 공통으로 이용하는 슈퍼타입의 속성수가 많아져 디스크 I/O가 많아지는 것을 막기 위해 1:1로 가져가는 경우 존재

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

3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

 

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

인덱스 - 데이터 조회시 가장 효과적으로 처리될 수 있도록 접근경로를 제공하는 오브젝트

- B*Tree구조를 많이 사용

 

PK순서

- 성능저하 현상이 많은 부분 > PK가 여러 개의 속성으로 구성된 복합식별자일 때 PK 순서에 대해 별로 고려하지 않을 경우

- 물리적 데이터 모델링 단계에서 스스로 생성된 PK 순서 이외에 다른 엔티티로부터 상속받아 발생되는 PK순서까지 주의

 

PK

- 해당 테이블의 데이터를 접근할 가장 빈번하게 사용되는 유일한 인덱스를 모두 자동 생성

- 인덱스의 특징은 여러 개의 속성이 하나의 인덱스로 구성되어 있을 때 앞쪽에 위치한 속성의 값이 비교자로 있어야 인덱스가 좋은 효율을 나타낼 수 있음.

- 결정한 PK순서와 다르게 DDL문장을 통해 PK순서를 다르게 생성가능

- FK라고 하더라도 데이터를 조회할 때 조인의 경로를 제공하는 역할을 수행하므로 FK에 대해서는 반드시 인덱스를 생성하도록 하고 인덱스 칼럼의 순서도 조회의 조건을 고려하여 접근이 가장 효율적인 칼럼 순서대로 인덱스 생성

 

PK칼럼의 순서를 조정하지 않으면 성능이 저하 이유

- PK의 순서를 인덱스 특징에 맞게 고려하지 않고 바로 그대로 생성하면 테이블에 접근하는 트랜잭션의 특징에 효율적이지 않은 인덱스가 생성되어 인덱스의 범위를 넓게 이용하거나 Full Scan을 유발

1) PK순서를 잘못 지정하여 성능이 저하된 경우(간단한 오류)

2) PK순서를 잘못 지정하여 성능이 저하된 경우(복잡한 오류)

- 테이블의 PK구조를 그대로 둔 상태에서 인덱스만 하나 더 만들어도 성능은 개선될 수 있다. 이때 이미 만들어진 PK인덱스가 전혀 사용되지 않는다면 입력,수정,삭제 시 불필요한 인덱스로 인해 더 성능이 저하되어 좋지 않음

- A+B형태로도 조회가 되며 B+A로도 조회가 되는 경우 더 자주 조회되는 형태로 PK순서를 구성하여 이용하게 하고 순서를 바꾼 인덱스를 추가로 생성하는 것이 필요

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

- 물리적 테이블에 FK를 사용하지 않아도 데이터 모델 관계에 의해 상속받은 FK속성들은 SQL WHERE 절에서 조인으로 이용되는 경우가 많이 있어 FK 인덱스를 생성해야 성능이 좋은 경우가 빈번

- 물리적 테이블에 FK 제약을 걸었을 때 반드시 FK인덱스를 생성하도록 하고 FK제약이 걸리지 않았을 때 FK인덱스를 생성하는 것을 기본정책으로 하되 발생되는 트랜잭션에 의해 거의 활용되지 않았을 때에만 FK 인덱스를 지우는 방법으로 하는 것이 적절한 방법이 됨.

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

분산데이터베이스

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

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

- 물리적 Site 분산, 논리적으로 사용자 통합 공유

=> DB를 연결하는 빠른 네트워크 환경을 이용하여 DB를 여러 지역 여러 노드로 위치시켜 사용성/성능 등을 극대화시킴

 

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

1) 분할 투명성(단편화) - 하나의 논리적 Relation이 여러 단편으로 분할되어 각 단편의 사본이 여러 site에 저장

2) 위치 투명성 - 사용하려는 데이터의 저장 장소 명시 불필요, 위치정보가 System calalog에 유지

3) 지역사상 투명성- 지역 DBMS와 물리적 DB사이의 Mapping 보장, 가ㅑㄱ 지역시스템 이름과 무관한 이름 사용 가능

4) 중복 투명성 - DB 객체가 여러 site에 중복되어 있는지 알 필요가 없음

5) 장애 투명성 - 구성요소의 장애에 무관한 Transaction의 원자성 유지

6) 병행 투명성 - 다수 Transaction 동시 수행시 결과의 일관성 유지 (Time stamp,. 분산 2단계 locking을 이용 구현)

 

분산 데이터베이스 적용방법

- 업무의 흐름을 보고 업무구성에 따른 아키텍처 특징에 따라 DB를 구성

 

분산 데이터베이스 장단점

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

- 통합된 데이터베이스에서 제공할 수 없는 빠른 성능을 제공

- 원거리 또는 다른 서버에 접속하여 처리됨으로 발생되는 네트워크 부하 및 트랜잭션 집중에 따른 성능 저하의 원인을 분산된 데이터베이스 환경을 구축하므로 빠른 성능을 제공하는 것이 가능해짐

 

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

분산환경으로  DB 설계

통합 데이터모델링 -> 각 테이블별 업무적 특징에 따라 지역 또는 서버별로 테이블을 분산배치하거나 복제 배치

 

1)테이블 위치 분산

- 테이블의 구조는 변하지 않고 테이블이 다른 데이터베이스에 중복되어 생성되지 않음

- 설계된 테이블의 위치를 각각 다르게 위치하는 것

- 정보를 이용하는 형태가 각 위치별로 차이가 있을 경우 이용

- 테이블 위치가 위치별로 다르기에 테이블의 위치를 파악할 수 있는 도식화된 위치별 데이터베이스 문서 필요

 

2)테이블 분할 분산

- 단순히 위치만 다른 곳에 두는 것이 아니라 각각의 테이블을 쪼개어 분산하는 방법

- 1) 로우 단위로 분리하는 수평분할 - 지사에 따라 테이블을 특정 칼럼의 값을 기준으로 분리

=> 각 지사에 있는 데이터와 다르며 한군데 합쳐도 PK에 의해 중복이 발생X

- 각 지사별로 사용하는 로우가 다른 경우 이용/ 데이터 수정시 자신의 데이터에 대해서 수정

- 각 지사에 존재하는 테이블에 대해 통합처리를 해야 하는 경우 조인이 발생하여 성능저하 예상

- 데이터의 지사구분이 변경시 변경된 지사로 데이터를 이송해야함 => 한 시점에서 한 지사에서 하나의 데이터만 있기에 무결성은 보장되는 형태

- 2) 칼럼 단위로 분할하는 수직분할 - 지사에 따라 테이블 칼럼을 기준으로 분리

=> 각 테이블에는 동일한 PK구조와 값을 가지고 있어야 하며 지사별로 쪼개진 테이블 조합시 PK가 동일한 데이터의 조합이 가능해야 하며 하나의 완전한 테이블 조합이 가능해야함.

- 데이터를 한군데 집합시켜놓아도 동일한 PK는 하나로 표현하면 되기에 데이터중복발생X

- 테이블의 전체 칼럼 데이터를 보기 위해 각 지사별로 흩어져 있는 테이블들을 조인하여 가져와야 하기에 통합처리하는 프로세스가 많은 경우 이용X 

 

3) 테이블 복제 분할 분산

- 성능이 저하되는 많은 DB에서 가장 유용하게 적용할 수 있는 기술적 방법

- 동일한 테이블을 다른 지역이나 서버에서 동시에 생성하여 관리하는 유형

- 1) 부분복제 - 통합된 테이블을 한군데 가지고 있으면서 각 지사별로는 지사에 해당된 로우를 가지고 있는 형태

- 지사에 존재하는 데이터는 반드시 본사에 존재하며 본사의 데이터는 지사데이터의 합

- 데이터 처리가 용이하며 전체 데이터에 대한 통합처리도 본사에 있는 통합테이블을 이용하여 조인이 발생하지 않는 빠른 작업 수행이 가능해짐

- 각 지사별로 업무수행이 용이하고 본사에 있는 데이터로 보고서를 출력하거나 통게를 산정하는 등으로 이용 가능

- 다른 지역간의 데이터 복제시 많은 시간이 소요되고 DB와 서버에 부하가 발생되어 보통 실시간 처리에 의해 복사하는 것보다 야간에 배치 작업에 의해 수행

- 본사와 지사 양쪽에서 모두 데이터를 수정하여 전송하는 경우 데이터의 정합성을 일치시키는 것이 어려워 가능하면 한쪽에서 데이터 수정이 발생하면 본사로 복제를 하도록 함

- 2) 광역복제 - 통합된 테이블을 한군데 가지고 있으면서 각 지사에도 본사와 동일한 데이터를 모두 가지고 있는 형태

- 모든 데이터가 본사와 지사가 모두 동일함 => 데이터 처리에 특별한 제약X

- 본사에서 데이터가 입력, 수정, 삭제되어 지사에서 이용하는 형태

- 데이터를 복제하는데 시간이 소요되고 DB와 서버에 부하가 발생하여 실시간 처리에 의해 복사하는 것보다 야간에 배치 작업에 의해 복제가 됨

 

4) 테이블 요약 분산

- 지역간, 서버간에 데이터가 비슷하지만 서로 다른 유형으로 존재하는 경우

- 1) 분석 요약  > 각 지사별로 존재하는 요약정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 방법

-> 통합 통계데이터에 대한 정보제공에 용이한 분산방법

-> 본사에 분석 요약된 테이블을 생성하고 데이터는 야간에 수행하여 생성

- 2) 통합 요약 > 각 지사별로 존재하는 다른 내용의 정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출

-> 단지 지사에서 산출한 요약정보를 한군데 취합하여 보여주는 형태

-> 지사에서 요약한 정보를 본사에서 취합하여 각 지사별로 데이터를 비교하기 위해 이용

-> 통합 통계데이터에 대한 정보제공에 용이한 분산방법

-> 본사에 통합 요약된 테이블을 생성하고 데이터는 야간에 수행하여 생성

 

성능 개선 사례

-  성능이 중요한 사이트에 적용

- 공통코드, 기준정보, 마스터 데이터 등에 대해 분산환경 구성시 성능이 좋아짐

- 실시간 동기화가 요구되지 않을 때 좋음/ 거의 실시간의 업무적인 특징을 가지고 있을 때도 분산 환경 구성 가능

- 특정 서버에 부하가 집중될 때 부하를 분살할 때 좋음

- 백업 사이트를 구성할 때 간단하게 분산기능을 적용하여 구성 가능