![[SQLD] 성능 - 대량 데이터, 데이터베이스 구조, 분산 데이터베이스 요약](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbEOYJD%2Fbtrdyj6WVmB%2FGYTibBrnmTKQwtewgRk9DK%2Fimg.png)
1. 대량 데이터에 따른 성능
> 대량 데이터 발생에 따른 테이블 분할 개요
- 아무리 설계가 잘되어 있는 데이터 모델이라고 하더라도 대량의 데이터가 하나의 테이블에 집약되어 있고 하나의 하드웨어 공간에 저장되어 있으면 성능 저하를 피하기가 힘들다.
- 하나의 테이블에 대량의 데이터가 존재하는 경우에는 인덱스의 tree 구조가 너무 커져서 효율성이 떨어져 데이터를 처리할 때 디스크 I/O를 많이 유발하게 된다. 또한 한 테이블에 많은 수의 칼럼이 존재하게 되면 데이터가 디스크의 여러 블록에 존재하므로 디스크에서 데이터를 읽는 I/O량이 많아지게 되어 성능이 저하된다.
> 한 테이블에 많은 수의 칼럼을 가지고 있으면 성능 저하
- 칼럼 수가 많은 테이블에서 데이터를 처리하게ㅐ 되면 디스크 I/O량이 증가하여 성능이 저하됨.
- 정규화를 통해 해결.
- 1:1 테이블 분할 통해 성능 개선
- 파티셔닝을 통한 성능 개선 : 프로그램은 하나의 테이블에 접근하면 내부적으로 range로 구분된 테이블에서 트랜잭션 처리
> 테이블 대한 수평분할 / 수직 분할의 절차
- 데이터 모델링을 완성한다.
- 데이터베이스 용량산정을 한다.
- 대량 데이터가 처리되는 테이블에 대해서 트랜잭션 처리 패턴을 분석한다.
- 칼럼 단위로 집중화된 처리가 발생하는지, 로우 단위로 집중화된 처리가 발생되는지 분석하여 집중화된 단위로 테이블을 분리하는것을 검토한다.
2. 데이터베이스 구조와 성능
> 슈퍼타입 / 서브타입 모델의 변환 방법
- 성능을 고려한 슈퍼타입과 서브타입의 모델 변환의 방법은 세가지 => 1:1 타입, 슈퍼+ 서브타입 , All in One 타입
> 슈퍼타입 / 서브타입 모델의 변환 기준
- 슈퍼/서브타입을 성능을 고려한 물리적인 데이터 모델로 변환하는 기준은 데이터 양과 해당 테이블에 발생되는 트랜잭션의 유형에 따라 결정해야한다.
> 슈퍼타입 / 서브타입 데이터 모델의 변환타입 비교
| 구분 | OnetoOne Type | Plus Type | Single Type |
| 특징 | 개별 테이블 유지 | 슈퍼 + 서브타입 테이블 | 하나의 테이블 |
| 확장성 | 우수함 | 보통 | 나쁨 |
| 조인 성능 | 나쁨 | 나쁨 | 우수함 |
| I/O량 성능 | 좋음 | 좋음 | 나쁨 |
| 관리용이성 | 좋지않음 | 좋지않음 | 좋음 |
| 트랜잭션 유형에 따른 선택 방법 |
개별 테이블로 접근이 많은 경우 선택 | 슈퍼 + 서브 형식으로 데이터를 처리하는 경우 선택 | 전체를 일괄적으로 처리하는 경우 선택 |
> 인덱스 특성을 고려한 PK/FK 데이터 베이스 성능향상
- 인덱스 : 데이터를 조회할 때 가장 효과적으로 처리될 수 있도록 접근 경로를 제공하는 오브젝트. 일반적으로 데이터베이스 테이블에서는 균형 잡힌 트리구조의 B*Tree 구조를 많이 사용
- 인덱스가 정렬되어 있는 특징으로 인해 데이터베이스 설계에 이 특징을 따라 설계에 반영해야 할 요소에 대해서는 반드시 알고 있어야 좋은 데이터 모델을 만들어 낼 수 있게 된다.
- 프로젝트에서 PK/FK 설꼐는 업무적 의미로도 매우 중요한 의미를 가지고 있지만 데이터 접근할 때 경로를 제공하는 성능의 측면에서도 중요한 의미를 가지고 있기 때문에 성능을 고려한 데이터베이스 설계가 될 수 있도록 설계단계 말에 칼럼의 순서를 조정할 필요가 있다.
3. 분산 데이터 베이스
> 분산 데이터 베이스의 개요
- 여러 곳으로 분산되어있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스
- 논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임
> 분산 데이터 베이스의 투명성
- 분할 투명성(단편화) : 하나의 논리적 Relation이 여러 단편으로 분할되어 각 단편의 사본이 여러 site에 저장
- 위치 투명성 : 사용하려는 데이터의 저장 장소 명시 불필요. 위치 정보가 System Catalog에 유지되어야 함
- 지역사상 투명성 : 지역 DBMS와 물리적 DB 사이에 Mapping 보장
- 중복 투명성 : DB 객체가 여러 사이트에 중복 되 있는지 알 필요가 없는 성질
- 장애 투명성 : 구성요소의 장애에 무관한 트랜잭션의 원자성 유지
- 병행 투명성 : 다수 트랜잭션 동시 수행시 결과의 일관성 유지
> 분산 데이터 베이스의 장단점
> 장점
- 지역 자치성, 점층적 시스템 용량 확장
- 신뢰성과 가용성
- 효율성과 융통성
- 빠른 응답 속도와 통신 비용 절감
- 데이터의 가용성과 신뢰성 증가
- 시스템 규모의 적절한 조절
- 각 지역 사용자의 요구 수용 증대
> 단점
- 소프트웨어 개발 비용
- 오류의 잠재성 증대
- 처리 비용의 증대
- 설계, 관리의 복잡성과 비용
- 불규칙한 응답 속도
- 통제의 어려움
- 데이터 무결성에 대한 위협
> 데이터베이스 분산 구성의 가치
- 데이터를 분산 환경으로 구성하였을 때 가장 핵심적인 가치는 바로 통합된 데이터 베이스에서 제공할 수 없는 빠른 성능를 제공한다는 점
- 원거리 또는 다른 서버에 접속하여 처리하므로 인해 발생되는 네트워크 부하 및 트랜잭션 집중에 따른 성능 저하의 원인을 분산된 데이터베이스 환경을 구축하므로 빠른 성능을 제공하는것이 가능해진다.
> 테이블 위치 분산
- 테이블 위치 분산은 테이블의 구조는 변하지 않는다.
- 테이블이 다른 데이터베이스에 중복되어 생성되지 않는다.
- 설계된 테이블의 위치를 각각 다르게 위치시키는 것이다.
> 테이블 분할 - 수평 분할
- 지사에 따라 테이블을 특정 칼럼의 값을 기준으로 로우를 분리한다. 칼럼은 분리되지 않는다. 모든 데이터가 각 지사별로 분리되어 있는 형태를 가지고 있다.
- 각 지사에 있는 데이터와 다른 지사에 있는 데이터가 항상 배타적으로 존재. 데이터를 한군데 집합시켜 놓아도 PK에 의해 중복이 발생되지 않는다.
> 테이블 분할 - 수직 분할
- 지사에 따라 테이블 칼럼을 기준으로 칼럼을 분리한다. 로우 단위로는 분리되지 않는다. 모든 데이터가 각 지사별로 분리되어 있는 형태를 가지고 있다.
- 칼럼을 기준으로 분할하였기 때문에, 각각의 테이블에는 동일한 PK 구조와 값을 가지고 있어야 한다.
> 테이블 복제 분산 - 부분 복제
- 통합된 테이블을 한군데에 가지고 있으면서 각 지사별로는 지사에 해당된 로우를 가지고 있는 형태이다.
- 지사에 존재하는 데이터는 반드시 본사에 존재하게 된다. 즉 본사의 데이터는 지사데이터의 합이 되는 것이다.
- 각 지사에서 데이터 처리가 용이할 뿐만 아니라 전체 데이터에 대한 통합처리도 본사에 있는 통합 테이블을 이용하게 되므로 여러 테이블에 조인이 발생하지 않는 빠른 작업 수행이 가능해진다.
> 테이블 복제 분산 - 광역 복제
- 합된 테이블을 한군데에 가지고 있으면서 각 지사에도 본사와 동일한 데이터를 모두 가지고 있는 형태
- 지사에 존재하는 데이터는 반드시 본사에 존재하게 된다. 모든 지사에 있는 데이터량과 본사에 있는 데이터량 동일
- 본사와 지사 모두 동일한 정보를 가지고 있으므로 본사나 지사나 데이터 처리에 특별한 제약을 받지 않는다.
> 테이블 요약 분산 - 분석 요약
- 분석 요약은 각 지사별로 존재하는 요약 정보를 본사에 통합하여 다시 전체에 대해서 요약 정보를 산출하는 방법
> 테이블 요약 분산 - 통합 요약
- 각 지사별로 존재하는 다른 내용의 정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 방법
> 분산 데이터베이스 적용이 효과적인 경우
- 성능이 중요한 사이트에 적용해야 한다.
- 공통 코드, 기준 정보, 마스터 데이터 등에 대해 분산환경을 구성하면 선능이 좋아진다.
- 실시간 동기화가 요구되지 않을 때
- 특정 서버에 부하가 집중이 될때 부하를 분산하면 좋음
- 백업 사이트를 구성할 때
출처 : 한국데이터산업진흥원 게시자료