Partitioning, Sharding, Replication
Partitioning
Partitioning : database table을 더 작은 table들로 나누는것
vertical partitioning : column을 기준으로 table을 나누는 방식
horizontal partitioning : row을 기준으로 table을 나누는 방식
vertical partitioning
정의
column을 기준으로 table을 나눈다. 정규화도 vertical partitioning 중 하나이다.
예시
쿼리를 실행하고 where 조건절에 만족하는 데이터들을 read해올 때, 하드디스크 또는 SSD에서 조건에 만족하는 데이터들(row)을 전부 가져온 후 select절에 존재하는 attribute만으로 tuple을 구성하는것이다.
content는 tuple을 구성하지 않지만, 일단은 저장장치에서 가져온 후 제외시킨다. 만약, content의 크기가 너무 큰경우 어떨까? 사용하지 않지만, 저장장치에서 read해야한다. I/O에 대한 부담이 커진다.
적용
content를 기존 table에서 분리 후 id와 content만 존재하는 table을 새로 생성한다.
Article table만 select하면 되기 때문에 I/O의 부담이 적어지고, 성능도 빨리진다.
글목록이 보일 경우 article_content table을 조회하지 않아도 되고, 글 상세보기에 들어가게 되면 기존 데이터들은 front-end에서 가지고 있다가, 글 상세보기에 들어가면 article_content table에서 content만 read해서 가져온다.
민감 정보, 자주 사용되는 데이터 - 자주 사용되지 않는 데이터 등 여러가지로 파티셔닝이 될 수 있고, join으로 데이터를 read해오면 된다.
horizontal partitioning
정의 및 특징
horizontal partitioning : row를 기준으로 table을 나누는 방식
vertical partitioning과는 다르게 table schema는 유지된다.
유튜브 유저가 어떤 채널을 구독하는 경우
유저가 채널을 구독할때마다 tuple들이 생성된다.
즉, 데이터의 최대 갯수 유저 수 * 채널 수가 될 수있다.
테이블의 크기가 커질수록 인덱스의 크기도 커지며, 데이터 변경이 일어날때마다 인덱스도 변경되기 때문에 처리속도가 느려진다.
hash-based horizontal partitioning
user_id를 hash function을 통해 값을 처리한 후 hash function의 결과값에 따라 저장되는 table이 달라진다.
기존 table을 사용하지 않고 hash function을 통해 나눈 파티셔닝 테이블을 사용하며, hash function에 사용된 user_id를 partition key라 부른다.
user_id를 partition key로 지정하고 user_id로 테이블을 조회하면 성능이 좋지만, 만약 partition key가 아닌 channel_id로 조회한다면 어떻게 될까?
모든테이블에 대해서 조회를 해야하기 때문에 full scan한다.
주로 조건에 사용되는 attribute로 key를 설정하는것이 좋으며, 데이터가 잘 분배되도록 설정한다.
주의
첫 hash-based 파티셔닝 후 추가적으로 파티셔닝을 하게되면, 새롭게 hash function들을 적용해야하고, 데이터들을 재배치해야하기 때문에 운영 중 재배치하면 위험이 따른다.
Sharding
row를 기준으로 동작하는 horizontal partitioning과 유사하다.
하지만, 각 partition이 독립된 DB 서버에 저장된다.
horizontal partioning과 차이
horizontal partioning은 파티션 후 나뉘어진 파티션들이 같은 DB서버에 저장된다.
하나의 DB서버로 관리하기 때문에 다수의 요청이 오는 경우 조회시간이 오래 걸릴 수 있다.
샤딩을 실행하면 파티션된 테이블이 서로 다른 독립된 DB서버에 저장되기 때문에 요청에 맞는 테이블만 조회할 수 있으며, DB 서버에 부하가 적다.
부하를 분산시키는 목적을 가진다.
샤드에 사용되는 attribute를 shard key라 부르며, 각각의 테이블을 shard라 한다.
Replication
기존에 존재하는 table의 데이터를 그대로 복사해온다.
두 table은 항상 같은 데이터를 가지고 있다.
백엔드 서버가 데이터베이스에 write한 경우 복사한 테이블도 데이터가 동기화 된다.
원본 table : 주로 master, primary라 불린다.
복사 table : 주로 slave, secondary, replica라 불린다.
secondary server는 항상 1개가 아니다. 필요에 따라 증설가능
master 서버에 문제가 생겼을 경우 백엔드 서버는 secondary서버에서 read/write 한다.
장애 상황이 발생해도 빠르게 서비스를 유지할 수 있다.
고가용성 (HA, high availability)
장애 상황이 아닌경우, secondary 서버로 트래픽을 나눌 수 있기 때문에, 성능이 향상되며 서버 부하를 낮춘다.
정리
용어에 대한 설명이기 때문에 추가적으로 공부할 것!!!
파티셔닝, 샤딩, ★레플리케이션
