partitioning

• 테이블을 더 작은 테이블들로 나누는 것

vertical partitioning

• 컬럼을 기준으로 테이블을 나누는 것
• 정규화 또한 vertical partitioning의 일종

vertical partitioning이 필요한 상황

article 테이블이 있고 content 컬럼이 크기가 매우 크다고 가정,
다음과 같이 content 컬럼을 제외한 쿼리를 날리면

SELECT id, title FROM article WHERE id = 1;

HDD에서 RAM으로 WHERE에 해당하는 로우를 가져오고, 그 이후 특정 컬럼을 추출하는 과정을 RAM에서 처리
즉, content는 사용하지 않지만 HDD에서 RAM으로 가져와지게 됨 => 비효율적인 I/O 발생

위와 같이 vertical partitioning을 하면 더 효율적

위는 성능 향상 목적으로한 분할
이외에도 민감한 정보를 분리하기 위한 보안 목적
자주 사용되는 컬럼을 분리하기도 한다.

horizontal partitioning

• 로우를 기준으로 테이블을 나누는 것

horizontal partitioning이 필요한 상황

hash based를 기준으로한 horizontal partitioning이며 다른 방법도 있음

어떤 유저가 어떤 유튜브 채널을 구독하는지 확인하는 테이블이 있고, 이 테이블의 로우가 매우 많다고 가정
로우가 많아지면 인덱스도 커지며 read/write 성능이 저하

다음과 같이 user_id를 hash 함수로 해싱하여 이를 기준으로 테이블을 분리
이때 분리의 기준이되는 user_id를 partition key라고 함

위 그림에서 user_id가 yeah의 구독한 채널들은 hash 함수로 해싱하여 해당 하는 테이블로 접근하면
기존 테이블에 비하여 row가 1/2로 줄어듦, 즉 성능이 향상됨

channel_id가 1인 채널을 구독한 유저들은 2개의 테이블에 나누어져 성능 향상에 이점이 없음
즉, partition key를 잘 선택하는 것이 중요
또한, 각 파티션의 로우가 균일하게 분포되어야 하므로 어떤 hash 함수를 사용하는지도 중요

sharding

• horizontal partitioning으로 나누어진 테이블을 여러 대의 서버에 분산하는 것
• 부하 분산으로 병목 현상 방지
• 여기서 각 파티션을 shard라고 함

replication

• DB를 복제하여 여러 대의 DB를 사용하는 것
• 주 DB(leader)과 복제된 DB(replica)이 있고 주 DB를 사용하며 복제된 DB를 sync 함
• leader에 문제가 생기면 replica를 사용 가능 => 고가용성(high availability)
• read 연산의 경우 부하 분산이 가능