[DB] Partitioning VS Sharding VS Replication 에 대해 알아보기

 

 

Partitioning (파티셔닝)

테이블을 성능/관리 효율성 목적으로 분리하여 저장.

컬럼/row단위로 분리할 수 있다

 

1. Vertical Partitioning (버티컬 파티셔닝)

컬럼 단위로 테이블을 나눠 관리하는 기법.

특정 컬럼(content)에 데이터 크기가 너무 클 때 사용.

 

예를들어

게시글 목록을 조회할 때 SELECT절에 content를 넣지 않는다고 하더라도 DB에서는 일단 모든 데이터들을 메모리에 올린 다음에 불필요한 속성들을 잘라낸다. 게시글 목록인데 불필요하며 크기가 큰 속성인 content를 메모리에 올리는 것은 DB I/O측면에서 부담이 가고 성능에도 안좋다. 이때 기존 article_tb에서 article_content_tb로 content 속성을 별도 테이블로 분리해놓는다면 먼저 게시글 목록을 보여준 뒤에, 나중에 속성만 반환하면 된다. 이렇게 버티컬 파티셔닝으로 불필요한 속성을 쓰지 않고 성능향상을 이뤄낼 수 있다.

 

이미 정규화된 테이블이라도 성능향상을 위해 버티컬 파티셔닝을 쓸 수 있다.
    

목적(사용되는 상황)

1. 성능향상
2. 자주 사용되는 속성들 / 잘 안쓰이는 속성들을 분리하여 파티셔닝도 가능하다 
3. 민감한 데이터 시 접근 불가하게 막음

 

 

단점

1. 전체 데이터가 필요할때는 조인 비용 발생.

2. 분리된 테이블은 기존 인덱스 사용불가.
    

 

 

2. Horizontal Partitioning (호리즌탈 파티셔닝)

테이블을 row 단위로 분산하여 저장.

테이블 크기가 커질수록 인덱스의 크기도 커진다. 테이블에 읽기/쓰기가 있을 때마다 인덱스에서 처리되는 시간도 조금씩 늘어난다. 
    
세부 구분

• 해쉬-호리즌탈 파티셔닝
• 레인지-호리즌탈 파티셔닝

 

특정 키(파티션키)를 기준으로 해쉬함수에 넣고 결과에 따라 테이블을 분류한다. 이때 where문 조건이 파티션키로 들어오면 하나의 테이블만 조회하면 되는데 파티션키와 무관한 속성으로 들어오면 여러 테이블을 모두 뒤져야한다. 그래서 가장 많이 사용될 패턴에 따라 파티션 키를 정하는 것이 중요하다. 그리고 데이터가 균등하게 분배될 수 있도록 해쉬함수를 잘 정의하는 것이 중요하다.
    
해쉬기반 호리즌탈 파티셔닝은 한번 파티션이 나눠지면 이후에 파티션을 추가하기가 까다롭다. 따라서 한번 나눌 때 잘 나눠야 한다.
    

레인지기반 호리즌탈 파티셔닝은 특정값(생성일)의 범위에 따라 테이블을 분류하는 것이다. 이 파티셔닝은 새로운 파티션을 추가/관리가 쉽다. 날짜를 가지고 레인지 기반 호리즌탈 파티셔닝을 쓰는 경우가 많다. 특정 기간 데이터를 불러오거나, 특정기간이 지난 데이터들을 삭제하는등  관리가 쉽다.

 

 

Sharding(샤딩)

호리즌탈 파티셔닝으로 나눠진 테이블들을 서로 다른 DB에 저장. 
DB서버의 부하를 분산시키는 목적.
파티션키를 샤드키로 부른다. 각 파티션을 샤드로 부른다.
    

 

 

Replication(레플리케이션)

보조 DB 서버를 둬서 주 DB서버의 데이터를 계속해 복제해 동기화하는 것. 실제 DB 작업은 주 DB서버가 담당한다.
주 DB서버는 마스터/프라이머리/리더라고 부른다
보조 DB서버는 슬레이브/세컨더리/레플리카 라고 부른다.
    

 

장점

1. 주 DB서버에 오류가 생기면 보조 DB서버로 대체 가능하다.(고가용성(HA, High Availablity))
2. 읽기 작업이 더 많다는 특성을 이용해, 읽기 작업 트래픽 일부를 레플리카로 옮길 수 있다. (부하 감소)