분산 데이터베이스
DB 시스템 구축 시 한 대의 물리적 시스템에 DBMS를 설치하고 여러 사용자가 접속하여 DB를 사용하는 구조를 중앙 집중형 데이터베이스라고 한다. 또 분산 데이터베이스는 데이터베이스를 연결하는 빠른 네트워크 환경을 이용하여 데이터베이스를 여러 지역의 여러 노드로 위치시켜 사용성/성능 등을 극대화 시킨 데이터베이스이다.
분산데이터베이스의 정의는 다음과 같다.
- 여러 곳으로 분산되어있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스
- 논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임
- 물리적 Site 분산, 논리적으로 사용자 통합·공유
분산 데이터베이스의 투명성Transparency
투명성 | 설명 |
분할 투명성 | 고객은 하나의 논리적 릴레이션이 여러 단편으로 분할되어 각 단편의 사본이 여러 시스템에 저장되어 있음을 인식할 필요가 없다 |
위치 투명성 | 고객이 사용하려는 데이터의 저장 장소를 명시할 필요가 없으며 고객은 데이터가 어디에 있더라도 동일한 방법으로 데이터에 접근할 수 있어야 한다 |
지역 사상 투명성 | 지역 DBMS와 물적 DB 사이 사상이 보장되어 각 지역 시스템 이름과 무관한 이름을 사용할 수 있다 |
중복 투명성 | DB 객체가 여러 시스템에 중복되어 존재해도 고객과는 무관하게 데이터 일관성이 유지된다 |
장애 투명성 | DB가 분산되어 있는 각 지역의 시스템이나 통신망에 이상이 생겨도 데이터 무결성은 보장된다 |
병행 투명성 | 여러 고객의 응용 프로그램이 동시에 분산 DB에 대한 트랜잭션을 수행해도 결과에 이상이 없다 |
분산 DB 설계 방식
1. 상향식 설계 방식: 지역 스키마 작성 후 전역 스키마 작성
2. 하향식 설계 방식: 전역 스키마 작성 후 지역 사상 스키마 작성
상향식 설계 방식은 지역별로 DB를 구축한 후에 전역 스키마로 통합하는 것이다. 반대로 분산 DB를 하향식을 구축한다는 것은 기업 전체의 전사 데이터 모델을 수렵해 전역 스키마를 생성한 후 각 지역별로 지역 스키마를 생성한는 것이다.
분산 DB의 장단점
장점 | 단점 |
신뢰성, 가용성, 효용성, 융통성이 높다 병렬 처리를 수행하므로 응답이 빠르고 통신 비용이 절감된다 시스템 용량 확장이 쉽다 각 지역 사용자들의 요구를 보다 잘 수용할 수 있다 |
설계와 관리가 복잡해 비용이 많이 든다 데이터 무결성에 대한 위협이 있다 보안 관리, 통제가 어렵고 오류의 잠재성이 크다 응답 속도가 불규칙하다 |
분산 데이터베이스의 활용 방향성
데이터베이스 분산구성의 가치
데이터를 분산 환경으로 구성하였을 때의 가장 핵심적인 가치는 통합된 DB에서 제공할 수 없는 빠른 성능을 제공한다는 점이다. 원거리 또는 다른 서버에 접속하여 처리할 때 발생되는 네트워크 부하 및 트랜잭션 집중에 따른 성능 저하를, 분산된 DB 환경을 구축함으로써 해결할 수 있다.
분산 데이터베이스의 적용 기법
데이터베이스의 분산의 종류에는 테이블 위치 분산과 테이블 분할 분산, 테이블 복제 분산, 테이블 요약 분산이 있다. 그 중에서도 테이블의 복제 분할 분산을 가장 많이 사용한다. 분산 환경으로 데이터베이스를 설계하는 방법은 일단 통합 데이터 모델링을 하고 각 테이블별 업무적인 특징에 따라 지역/서버별로 테이블을 분산/복제 배치하는 것이다.
테이블 위치 분산
테이블 구조는 변경되지 않고 테이블이 다른 DB에 중복 생성되지도 않는다. 다만 설계된 테이블의 위치를 각각 다르게 위치시킨다. 예를 들어, 자재품목은 본사에서 구입하여 관리하고 각 지사별로 자재품목을 이용하여 제품을 생산한다고 하면 아래와 같이 본사와 지사단위로 DB를 분산시킬 수 있다.
위의 분산방법은 설계된 테이블 각각이 지역별로 분산 생성되는 경우이다. 각 테이블마다 위치가 다르게 지정되어야 한다면 아래 표와 같이 각 테이블마다 위치를 표기하여 테이블을 생성하도록 한다.
테이블별 위치 분산은 정보를 이용하는 형태가 각 위치별로 차이가 있을 때 이용한다. 따라서 테이블의 위치를 파악할 수 있는 도식화된 위치별 데이터베이스 문서가 필요하다.
테이블 분할Fragmentation 분산
테이블 분할 분산은 단순히 위치만 다른 곳에 두는 것이 아니라 각각의 테이블을 쪼개어 분산하는 방법이다. 이는 테이블을 나누는 기준에 따라 두 가지로 구분된다. 첫 번째는 테이블의 로우Row단위로 분리하는 수평분할Horizontal Fragmentation이 있고 두 번째는 테이블을 칼럼Column 단위로 분할하는 수직분할Vertical Fragmentation이 있다.
- 수평분할(Horizontal Fragmentation)
지사Node에 따라 테이블을 특정 칼럼 값을 기준으로 로우Row를 분리한다. 칼럼은 분리되지 않는다. 모든 데이터가 각 지사별로 분리되어 있는 형태를 가지고 있다. 데이터가 노드 별로 존재하므로, 데이터를 한군데 집합시켜 놓아도 PK에 의해 중복되지 않는다. 대신 타 노드 데이터의 노드 구분이 변경되면 단순 수정 외에 변경된 노드로 데이터를 이송해야 한다. 한 시점에는 한 노드에서 하나의 데이터만 존재하므로 데이터 무결성이 보장되는 형태이다.
이는 노드 별로 사용하는 로우가 다를 때 이용한다. 데이터를 수정할 땐 타 노드의 데이터를 원칙적으로 수정하지 않고 자신의 데이터에 대해 수정해야 한다. 각 노드에 존재하는 테이블에 대해서 통합 처리를 해야할 땐 조인Join이 발생하여 성능이 저하될 수 있으므로 통합 처리 프로세스가 많은지 먼저 검토한 후 많지 않은 경우에 수평분할 해야 한다. 노드 별로 데이터베이스를 운영하는 경우는 데이터베이스가 속한 서버가 노드에 존재하든, 본사에 통합해서 존재하든 수평 분할하는 것이 좋다.
지사Node별로 운영하는 테이블들의 예를 들어보자. 고객, 생산제품, 협력회사, 사원, 부서 테이블이 지사1과 지사2에서 일의 시작과 끝이 항상 다르게 발생한다고 하면 각 테이블은 지사별로 수평 분할하여 아래 표와 같이 생성된다.
- 수직분할Vertical Fragmentation
지사Node에 따라 칼럼Row을 분리한다. 로우 단위로는 분리하지 않는다. 모든 데이터가 각 노드별로 분리되어 있으며 칼럼을 기준으로 분할했기 때문에 각 테이블은 동일한 PK 구조와 값을 가지고 있다. 노드별로 쪼개진 테이블들을 조합하면, PK가 동일한 데이터 조합이 가능하며 하나의 완전한 테이블이 구성되어야 한다. 데이터를 한군데 집합시켜 놓아도 동일한 PK는 하나로 표현하면 되므로 데이터 중복은 없다.
예를 들어 제품의 재고량은 각 지사별로 관리하고 제품에 대한 단가는 본사에서 관리한다고 하면 본사 테이블에는 제품번호, 단가가 존재하고 지사에는 제품번호, 재고량이 존재한다. 이를 본사와 지사단위로 분리된 칼럼의 모습을 도식화 하면 다음과 같다.
테이블의 전체 칼럼 데이터를 보기 위해서는 각 지사Node 별로 흩어진 테이블들을 조인해 가져와야 하므로 가능하면 통합 처리 프로세스가 많을 땐 이용하지 않는 것이 좋다. 일반적으로 수직분할 분산 환경을 구성하는 사례는 드물다.
테이블 복제Replication 분산
테이블 복제 분산은 동일 테이블을 다른 지역/서버에 동시 생성하여 관리하는 유형이다. 마스터 DB에서 테이블의 일부 내용만 다른 지역/서버에 위치시키는 부분 복제Segment Replication와 마스터 DB 테이블의 내용을 각 지역/서버에 존재시키는 광역 복제Broadcas Replication가 있다.
- 부분복제Segment Replication
통합된 테이블을 한 곳(본사)에 가지면서 각 노드(지사) 별로는 노드에 해당하는 로우를 가진 형태이다. 지사에 존재하는 데이터는 반드시 본사에도 있다. 즉, 본사의 데이터는 지사 데이터의 합인 것이다. 각 지사에서의 데이터 처리가 용이하며 전체 데이터에 대한 통합 처리도 본사의 통합 테이블을 이용하므로 여러 테이블에 조인이 발생하지 않아 작업 수행이 빠르다.
위 그림을 보면, 본사 DB의 테이블에는 테이블 전체 내용이, 각 지사 DB의 테이블에는 지사 별로 관계된 데이터만 들어간다. 수평분할 분산과 같이 지사 간에는 데이터 중복이 없고 본사-지사 간에는 데이터 중복이 항상 있다.
보통 전국의 고객을 관리할 때 본사에는 전국 고객에 대한 정보를, 지사에는 각 지사와 거래하는 고객 정보를 관리한다. 본사 데이터를 이용하여 통계, 이동 등을 관리하며 지사 데이터로는 지사별 빠른 업무수행을 한다. 보통 지사 데이터가 먼저 발생하고 본사 데이터는 지사 데이터를 통합하여 발생된다.
실제 프로젝트에서 많이 사용하며 각 지사별 업무 수행이 용이하고 본사 데이터를 통해 보고서를 출력하거나 통계를 산정하는 등 다양하게 이용 하기에 좋다. 하지만 다른 지역간 데이터를 복제하는데 많은 시간이 소요되고 DB와 서버에 부하가 커서 보통 실시간On-Line 처리 복사보다는 야간 배치 작업에 의해 수행되는 경우가 많다. 또 본사-지사 양쪽 모두 데이터를 수정 후 전송하는 경우 데이터 정합성을 지키기 어려워 가능하면 한 쪽(지사)에서 데이터 수정 후 다른 한 쪽(본사)으로 복제하도록 한다.
- 광역복제Broadcast Replication
통합 테이블을 한 곳(본사)이 가지면서 각 지사에도 본사와 동일한 데이터를 모두 가진 형태이다. 지사 데이터는 반드시 본사에 존재하며, 모든 지사 데이터량과 본사 데이터량이 동일하다. 본사와 지사 모두 동일한 정보를 가지므로 데이터 처리에 특벼한 제약을 받지 않는다.
본사에서 코드테이블 데이터에 대해 입력/수정, 삭제가 발생하고 각 지사에서는 코드데이터를 이용하는 프로세스가 발생한다. 즉 본사에서는 데이터를 관리하고 지사에서는 이 데이터를 읽어 업무프로세스를 발생시킨다.
광역 복제 방식도 실제 프로젝트에서 많이 사용한다. 부분 복제의 경우 지사 데이터에 대한 입력/수정/삭제 후 본사에서 이용하는 방식이 대부분인 반면 광역 복제는 본사에서 데이터 입력/수정/삭제 후 지사에서 이용하는 형태이다. 부분 복제와 마찬가지로 데이터를 복제하는 데 많은 시간이 소요되고 DB와 서버에 부하가 커 실시간 처리보다는 배치에 의해 복제되도록 한다.
테이블 요약Summarization 분산
지역/서버 간 데이터가 비슷하지만 서로 다른 유형으로 존재하는 경우다. 요약 방식에 따라 동일한 테이블 구조를 가지며 분산된 동일한 내용의 데이터를 이용해 통합된 데이터를 산출하는 방식인 분석 요약Rollup Summarization과 분산된 다른 내용의 데이터를 이용하여 통합된 데이터를 산출하는 방식의 통합 요약Consolidation Summarization이 있다.
- 분석요약(Rollup Replication)
분석 요약은 각 지사별로 존재하는 요약 정보를 본사에 통합하고, 다시 전체에 대해 요약 정보를 산출한다.
위 그림을 보면, 테이블의 모든 칼럼과 로우가 지사에도 동일하게 존재하지만 각 지사에는 동일한 내용에 대해 지사 별로 요약된 정보를 가진다. 반면 본사는 각 지사의 요약 정보를 통합하여 재산출한, 전체에 대한 요약 정보를 가진다.
예를 들어, 제품 별 판매실적 테이블이 존재한다고 가정하자. 각 지사는 취급 제품이 동일하며 지사별로 판매된 제품에 대해서 지사별로 판매실적이 관리된다. 지사1과 지사2도 동일한 제품을 취급하므로 이를 본사에서 판매실적을 집계할 경우, 통합된 판매실적을 관리할 수 있는 것이다.
각종 통계 데이터를 산정할 경우, 모든 지사 데이터를 이용해서 처리하면 성능이 지연되고 각 지사 서버에 부하를 주기 때문에 업무 장애가 발생할 수 있다. 하지만 통합 통계 데이터에 대한 정보 제공에 용이한 방법이며 데이터 처리는 역시 업무 종료 후 야간에 수행한다.
- 통합 요약Consolidation Replication
각 지사별로 존재하는 다른 내용의 정보를 본사에 통합한 후 다시 전체에 대해 요약 정보를 산출하는 분산방법이다.
위 그림을 보자. 테이블의 모든 칼럼과 로우가 지사에도 동일하게 존재하지만 각 지사에는 타 지사와 다른 요약 정보를 가지고 본사는 각 지사의 요약 정보와 데이터를 같은 위치에 두는 것으로 통합하여 전체에 대한 요약 정보를 가진다.
본사가 통계 데이터를 산정하는 것은 분석 요약과 비슷하나, 통합 요약은 분석 요약과 달리 지사 데이터를 본사가 취합하여 각 지사별 데이터를 비교할 때 사용한다.
각종 통계데이터를 산정할 때 모든 지사 데이터를 조인하면 성능이 저하되고 각 지사 서버에 부하가 걸린다. 하지만 통합 통계데이터를 위한 정보 제공에 용이하다. 데이터 처리는 역시 일반 업무가 종료되는 야간에 수행하여 생성하는 것이 일반적이다.
분산 데이터베이스 적용이 효율적인 사례
아래는 개인정보를 관리하는 DB가 인사 DB일 때 업무 DB가 사용자 정보에 접근하는 그림이다. 분산이 안된 각 서버에 독립적으로 테이블이 있을 때의 트랜잭션과 복제 분산을 통해 테이블의 정보가 양쪽에 있을 때 트랜잭션의 차이를 보여준다. 단순한 개념도이지만 복잡한 업무처리에서 효과적으로 성능을 향상시킬 수 있다.
*선지 추가: GSI(Global Single Instance)는 분산 DB의 반대되는 통합 DB의 개념이다
데이터베이스 분산 설계는 다음과 같은 경우에 적용하면 효과적이다.
- 성능이 중요한 사이트에 적용한다.
- 공통코드, 기준정보, 마스터 데이터 등에 대해 분산환경을 구성하면 성능이 좋아진다.
- 실시간 동기화가 요구되지 않을 때 좋다. 거의 실시간Near Real Time 업무일 때도 분산 환경을 구성할 수 있다.
- 특정 서버에 부하가 집중이 될 때 부하 분산을 위해 쓸 수 있다.
- 백업 사이트Disaster Recovery Site를 구성할 때 간단한 분산기능을 적용하여 구성할 수 있다.
'SQLD > 데이터 모델링의 이해' 카테고리의 다른 글
2-5 데이터베이스 구조와 성능 (0) | 2020.02.22 |
---|---|
2-4 대량 데이터에 따른 성능 (0) | 2020.02.22 |
2-3 반정규화와 성능 (0) | 2020.02.16 |
2-2 정규화와 성능 (0) | 2020.02.16 |
2-1 성능 데이터모델링의 개요 (0) | 2020.02.16 |