top of page

Partition

 

 

 

 

 

 

 

 

기간별 또는 어떤 기준에 따라 데이터를 분리 해놓은것
데이터가 많은 곳은 한 테이블로 데이터를 관리하는 것 보다 파티션으로 나누는 것이 데이터를 찾을 때 더 빠르기 때문
파티션 1, 2는 동일한 구조의 인덱스를 가진다
파티션은 파티션 별로 b-tree구조이다

파티션 테이블을 구성 하기 위해서는 파티션 함수, 파티션 구성표를 생성하고 테이블에 매핑 시켜야함

  1. 파티션 함수: 테이블 내에서 어떠한 경계로 나눌 것인지를 지정 할 수 있다. 함수만 있다해서 파티션 테이블을 생성 할 수 있는 것은 아님
    -파티션 범위 유형: LEFT, RIGHT로 설정 할 수 있다.
    RANGE RIGHT: 경계선을 기준으로 경계점 데이터가 오른쪽 파티션에 포함
    RANGE LEFT: 경계선을 기준으로 경계점 데이터가 왼쪽 파티션에 포함

  2. 파티션 구성표: 파티션의 함수와 매핑하고 파일구룹과 연결하여 파티션 별로 장소를 지정

 

파티션은 데이터 퍼지를 위한것
만약에 파티션을 해놓지 않고 데이터를 삭제 해달라고 했을때 뭐.. top 100 처럼 삭제를 해서 쭉 delete를 하면 로그가 엄청나게 쌓이고 불편함... 그래서 파티션을 나누게 된다면
파티션 1, 파티션 2, 파티션 3 이렇게 있다면
파티션 1만 truncate 해버리면 되니깐 편함
(데이터 퍼지란 테이블 1이 테이블 2랑 인덱스나 이런게 다 똑같은데 1에 있는 데이터를 2에다가 쭉 옮겨 담고 테이블 1에는 데이터를 삭제해버림. 약간 백업 같은 개념? TC_TRAY에 있는 데이터를 TH_TRAY에 옮겨버리는것과 같은)

그리고 만약 파티션이 1, 2, 3 나눠져 있으면 파티션에 쓰이는 인덱스는 통합된거인데 파티션 1을 truncate해야한다면 그냥 truncate를 진행하게 되면 인덱스를 지웠다가 truncate 파티션1을 해주고 다시 인덱스를 만들어 줘야함 아니면 에러가 발생

파티션을 했을 때 만약 select 문에 파티션에 기준이 되는 column을 쓰지 않으면 속도, 성능에 영향이 없다. 굳이 파티션을 안해줘도됨.
파티션을 쓸 땐 모든 문에 무조건 들어가는 기준이 되는 column을 기준으로 나눠주면 속도랑 성능이 빠르다
ex)TC_TRAY테이블에서 TRAY_NO는 모든 쿼리에 들어가는 컬럼이라 TRAY_NO로 파티션을 나눠주게되면 빠름.

속도, 성능을 위해서 파티션을 나눠달라고 하는건 안됨..

파티션 종류

  1. Range partitioning
    기간 또는 날짜에 따라 파티션을 나눔

  2. Hash partitioning
    파티션 키값에 해시함수 적용 -> 값으로 파티션을 매핑

  3. List partitioning
    불연속적인 값의 목록으로 나눔
    ex) 지역별로

  4. Composite partitioning
    Range나 List파티션 내에서 또다른 sub파티션 구성

Partition Pruning
옵티마이저가 SQL의 대상 테이블과 조건절을 분석해 불필요한 파티션을 액세스 대상에서 제외시키는 것

bottom of page