[DB] 파티셔닝, 샤딩, 레플리케이션

참고 자료 

유투브 쉬운코드 파티셔닝, 샤딩, 레플리케이션

Partitioning (파티셔닝)

database table을 더 작은 table들로 나누는 것 

 

vertical partitioning 

column을 기준으로 table을 나누는 방식 

 

horizontal partitioning

row를 기준으로 table을 나누는 방식 

vertical partitioning (수직 파티셔닝)

column을 기준으로 table을 나누는 방식 

 

이전 쉬운코드님 강의에서 정규화를 했었다. 

1개의 EMPLOYEE_ACOUNT 테이블을 1NF ~ BCNF까지 

이런 정규화 작업 또한 컬럼을 기준으로 테이블의 나누는 방식인 vertical partitioning 중 하나이다.

 

정규화 작업 말고 다른 vertical partitioning에 대해서 알아보자 

 

vertical partitioning 이해를 위한 예시 

해당 사진은 게시글 목록이다. 

우린 이런 데이터를 조회할 때 다음과 같은 쿼리를 작성하게 된다. 

SELECT id, title, writer_id, created_at 
FROM article
order by created_at desc;

 

 

이렇게 게시글 목록에 필요한 attribute(s)만 쿼리를 작성해서 조회를 한다. 

하지만 I/O 작업은 Secondary Storage(SSD/HDD)에서 전체 attribute(s)들을 가져오고 
필요한 attribute(s)를 필터링 해서 요청한 SQL에 맞게 반환한다.  

즉, 사이즈가 크고 필요없는 content도 가져온다. 

이는 체감하지 못할 수도 있지만 SELECT 할 때 performance에 영향을 준다.

이를 vertical partitioning을 통해서 해결하자 

 

vertical partitioning 적용 

이제 게시글 목록에서는 ARTICLE 테이블을 Secondary Storage에서 가져올 때 용량이 큰 content를 가져오지 않는다. 

 

vertical partitioning 다양한 적용 사례

예시로 들었던 performance를 위해서 용량이 큰 attribute(s) 나누기 

자주 사용하는 attribute(s)와 자주 사용하지 않는 attribute(s)를 나누기

민감한 정보에 대한 접근 권한을 분리하기 위해서 attribute(s) 나누기 

 

이렇게 다양한 목적으로 이미 정규화된 테이블을 vertical partitioning을 적용할 수 있다.

horizontal partitioning (수평 파티셔닝)

row를 기준으로 table을 나누는 방식 

vertical partitioning과 다르게 horizontal partitioning은 테이블의 기존 스키마는 유지된다 

 

horizontal partitioning 이해를 위한 예시 

SUBSCRIPTION 테이블은 사용자의 구독 정보를 가지는 테이블이다. 

유저 id, 채널 id, 알람 설정 여부, 멤버쉽 가입 여부 정보가 있다. 

 

SUBSCRIPTION 테이블의 row 수를 생각해 보자 

사용자 수: N

채널 수: M

MAX SUB: N * M

 

모든 사용자가 모든 채널을 구독하면 최대 N * M 사이즈의 SUBSCRIPTION 테이블의 row가 생긴다.

만약 사용자 수가 100만 채널 수가 1000개라면 최대 10억이다.

 

테이블의 크기가 커질수록 인덱스의 크기도 계속 커진다. 

즉, 테이블에 읽기/쓰기 작업이 있을 때마다 인덱스에서 처리되는 시간도 늘어난다

이런 문제를 해결하는 방법이 horizontal partitioning 이다. 

 

horizontal partitioning by hash based

 

hash function 하나를 정의한다. 

해당 hash function의 input은 user_id / output은 0 or 1 이다. 

 

기존 테이블은 하나의 테이블에 사용하지만 이제 같은 스키마를 가지는 2개의 테이블을 사용한다.

이 방식이 해시 기반의 수평 파티셔닝이다.

현재는 2개의 테이블로 파티셔닝 했지만 상황에 맞게 n개의 테이블로 파티셔닝 할 수 있다.

그리고 현재 파티셔닝은 user_id를 기준으로 하고 있는데 이를 partition key라고 한다.

 

수평 파티셔닝 주의점 

2개의 SELECT 문

1. dingyo가 구독한 채널들 정보를 모두 조회하고 싶다면?

2. id가 1인 channel을 구독한 사용자의 id를 모두 조회하고 싶다면?

 

1번은 hash function에 맞는 테이블 1개를 조회 

2번은 전체 테이블을 다 조회  

 

즉, 가장 많이 사용될 패턴에 따라 partition key를 정하는 것이 중요하다 

그래야 테이블을 나눈 이점을 얻을 수 있다. 

 

또한 데이터가 균등하게 분배될 수 있도록 hash function을 잘 정의하는 것도 중요하다

hash-based 수평 파티셔닝은 한번 파티션이 나눠져서 사용되면 (실제 서비스) 이후에 파티션을 추가하기 까다롭다.

기존 테이블에 있던 데이터중에서 새로 정의된 hash function에 의해서 값이 바뀐다면 데이터를 옮겨야 한다.

이는 실제 운영하고 있는 서비스에서 진행하기 매우 어렵다.

 

수평 파티셔닝 기법은 hash-based 말고도 range-based 같이 여러 기법이 있다. 

나중에 적용할 때 찾아봐야겠다 

Sharding (샤딩)

horizontal partitioning처럼 동작한다.

각 partintion이 독립된 DB 서버에 저장된다

 

horizontal partitioning

모든 partition이 1개의 DB 서버에 저장되기 때문에 결국 같은 CPU가 처리한다.

즉, 하나의 서버가 여러 파티션에 대한 모든 작업을 처리해야 하므로 CPU 자원의 경쟁이 발생할 수 있다.

서버가 처리할 수 있는 데이터 양과 쿼리 요청이 많아지면 서버 과부하로 이어질 수 있다.

 

 

Sharding

각 partition 들이 서로 다른 DB 서버에 저장된다.

그래서 여러 서버가 각 파티션에 대한 작업을 하기 때문에  DB 부하가 분산된다. 

 

shard key , shard

partition key를 shard key라고 부른다.

각 partition을 shard라고 부른다.

replication (레플리케이션)

데이터 동기화는 주 서버에 데이터 변경(insert, update, delete)가 일어나면 똑같이 백업 서버에도 적용한다. 

 

main 서버를 master / primary / leader 라고 부른다.

백업 서버를 slave / secondary / replica 라고 부른다. 

 

replication 장점

장애 대처가 빠르다 

백엔드 서버에서 primary DB 서버에  요청을 보냈는데 문제가 생기면  secondary 서버에 요청을 보내면 된다.

이런 replication 방식의 구조를 High Availability (고가용성) 아키텍처라고 한다.

 

보통 write 작업보다 read 작업이 많은데 

많은 read 작업을 secondary 서버로 보내서 트래픽을 분산시킬  수 있다. 

요약 

partitioning 

table을 목적에 따라 작은 table로 나누는 방식 

 

sharding

horizontal partitioning 방식으로 나누어진 table들을 각각의 DB 서버에 저장하는 방식 

 

replication 

DB를 복제해서 여러 대의 DB 서버에 저장하는 방식