[SQLD : Ⅱ. 데이터 모델과 성능] 4. 대량 데이터에 따른 성능

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

 - 한 테이블에 데이터가 대량으로 집중되거나

   하나의 테이블에 여러 컬럼이 존재햐여 디스크에 많은 블록을 점유하는 경우 성능저하 유발 가능

 - 한 테이블에 대량의 데이터가 존재할 경우 인덱스의 tree구조가 너무 커져서 효율성이 떨어짐

 - 한 테이블에 많은 컬럼 존재 시 디스크에서 데이터를 읽는 IO량이 많아져서 성능 저하(로우체이닝, 로우마이그레이션)

 - 로우체이닝 : 로우 길이가 너무 길어서 두 개 이상의 블록에 하나의 로우가 저장되는 형태

 - 로우마이그레이션 : 데이터블록에서 수정 발생 시 수정된 데이터를 다른 블록 빈 공간을 찾아서 저장하는 방식

 

* 한 테이블에 많은 컬럼을 갖는 경우

 - 도서정보 테이블 가정 : 컬럼은 200개, 하나의 로우 길이가 10KB, 블록은 2KB

 - 많은 컬럼을 갖는 테이블에 대해 트랜잭션 발생 시 어떤 컬럼에 대해 집중적으로 발생하는지 분석하여 쪼개기

 - 도서정보 테이블에는 전자출판 유형에 대한, 대체제품에 대한 유형의 트랜잭션이 독립적으로 발생되는 경우가 많음

   => 1:1관계로 분리, 분리된 테이블은 로우마이그레이션, 로우체이닝이 많이 줄어듦

 - 트랜잭션을 분석하여 적절하게 1:1 관계로 분리함으로써 성능향상 가능하도록 함

 

* 대량 데이터 저장 및 처리로 인한 성능

 - 테이블에 많은 양의 데이터가 예상될 경우 파티셔닝 적용 또는 PK에 의한 테이블 분할 방법 적용

 - 오라클 : list partition, range partition, hash partition, composite partition 등 가능

 - 논리적으로는 하나의 테이블로 보이지만 물리적으로는 여러 테이블 스페이스에 쪼개저 저장됨

 

* range partition

 - 요금 테이블에 PK가 요금일자+요금번호로 구성, 데이터건수가 1억2천만 건인 대용량 테이블 가정

 - 요금의 특성상 월단위로 데이터를 처리하는 경우가 많으므로 요금일자의 년+월을 이용하여 12개의 파티션 테이블

 - SQL문 처리 시 하나의 테이블처럼 보이는 요금 테이블 이용 처리,

    DBMS 내부에서는 SQL WHERE절에 비교된 요금일자에 의해 각 파티션에 있는 정보를 찾음, 성능 개선

 - 날짜나 숫자로 분리가 가능하고 각 영역별로 트랜잭션이 분리되면 적용

 - 데이터 보관주기에 따라 데이터를 쉽게 DROP할 수 있음

 

* list partition

 - 지점, 사업소, 사업장, 핵심적인 코드 값 등으로 PK 구성된 대량 데이터 테이블은 값에 의해 파티셔닝

 - 고객 테이블, 1억 건 데이터, 지역을 나타내는 사업소코드별로 list partition 가정

 - 대용량 데이터를 특정값에 따라 분리 저장할 수 있지만 range같이 보관주기에 따라 쉽게 삭제 기능은 제공 안됨

 

* hash partition

 - 지정된 hash 조건에 따라 해시 알고리즘이 적용되어 테이블이 분리됨

 - 설계자는 테이블에 데이터가 정확하게 어떻게 들어갔는지 알 수 없음

 - 데이터 보관 주기에 따라 쉽게 삭제하는 기능도 제공 안됨

 

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

 1) 데이터 모델링 완성

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

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

 4) 컬럼 단위로 집중화된 처리가 발생하는지, 로우 단위로 집중화된 처리가 발생하는지 분석하여 

    집중화된 단위로 테이블을 분리하는 것을 검토