[DB]파티셔닝? 샤딩? 레플리케이션? (partitioning? sharding? replication?)

요약정리

partitioning	sharding	replication
table을 목적에 따라 작은 table들로 나누는 방식	horizontal partitioning으로 나누어진 table들을  각각의 DB서버에 저장하는 방식	DB를 복제해서 여러 대의 DB서버에 저장하는 방식

 

partitioning

개념: database table을 더 작은 Table들로 나누는 것

 

분할 기준

파티셔닝	대용량 데이터베이스를 여러 섹션으로 분할 (조회 속도 향상) . 범위 분할: 파티션 키 값을 범위로 분할 . 해시 분할: 해시 함수 적용 후 반환된 값으로 파티션 분할 . 합성 분할: 범위 분할 후 해시 함수 적용하여 다시 분할

 

partitioning종류

vertical partitioning	horizontal partitioning
column을 기준으로 table을 나누는 방식	row를 기준으로 table을 나누는 방식

1.vertical partitioning

정규화 = 중복을 제거

 

BCNF까지 진행

 

정규화 과정도 vertical partitioning이다.

이 쿼리는 테이블의 여러 열 중에서 id, title, comment_cnt와 같은 특정 칼럼들만 필요로 합니다.

 

테이블에 저장된 데이터는 일반적으로 HDD 또는 SSD에 저장된다.

쿼리문 실행 순서

1. 데이터베이스는 해당 테이블에서 적합한 행(row)을 찾아야 합니다. 이는 WHERE 절의 조건에 따라 수행됩니다.
2. 해당 행을 찾으면 데이터베이스는 해당 행의 모든 열(column)을 읽어와야 합니다.
3. 그런 다음 SELECT 문에서 지정한 칼럼들만을 필터링하여 결과를 반환합니다.

DB는 행 단위로 데이터를 읽기 때문에 content 칼럼(content가 사이즈가 크다 = 긴 데이터)도 함께 읽어 I/O 부하가 발생한다.

그러나 게시글 목록 조회와 같은 쿼리에서는 이러한 긴 칼럼들이 필요하지 않습니다.

select 할 때 성능(performance)에 영향을 준다.

vertical Partitioning을 통해 content와 같은 긴 데이터를 별도의 테이블로 나누어 데이터를 저장하게 된다.

게시글 목록 조회와 같은 쿼리에서는 content와 같은 불필요한 데이터를 HDD 또는 SSD에서 읽어오지 않아도 되므로 I/O 부담이 감소하고 성능이 향상된다.

 

정규화가 진행된 테이블이어도 성능을 위해 vertical Partitioning을 활용할 수 있다.

민감 정보는 접근 제한을 위해 파티셔닝 한다.

자주 사용하는 속성과 자주 사용하지 않는 속성을 나눠 파티셔닝

전체 데이터가 필요하다면 조인을 사용한다.

2.horizontal partitioning

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

horizontal partitioning을 사용해 이러한 문제를 해결할 수 있다.
horizontal partitioning을 사용하는 여러 가지 방법론이 존재한다.  hash-based를 살펴보자.

user_id를 입력으로 받아서 0 또는 1과 같은 해시값을 출력하는 해시 함수를 구현한다.

해시 함수의 결과에 따라 두 개의 파티션 테이블, subscription_0 테이블과 subscription_1 테이블을 생성한다.

user_id를 기준으로 두 파티션 중 하나로 분할되어 저장됩니다. 여기서 user_id를 파티션 키라고 부른다.

user_id를 기준으로 hash function에 적용을 해서 구분을 했기 때문에 같은 유저는 항상 같은 테이블에 저장이 된다.

 

partition key

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

vs

id가 1인 channel을 구독한 사용자의 id를 모두 조회하고 싶다면? subscription_0 테이블과 subscription_1 테이블에서 모두 조회

channelId를 구독한 사용자의 user_id를 조회하려면 channelId를 조건으로 사용할 수 있습니다. 그러나  주의할 점은 user_id를 파티션 키로 선택했으므로 모든 파티션을 조회해야 한다. 

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

 

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

hash-based horizontal partitioning은 한 번 partition이 나눠져서 사용되면 이후에 partition을 추가하기 까다롭다.

{0, 1}이 아니라 {0, 1, 2, 3}으로 하면 이미 0,1에 있는 것을 2,3으로 옮겨야 해서 까다롭다.

 

horizontal partitioning은 모든 partition들을 같은 DB 서버에 저장합니다. 그렇기 때문에 백엔드 서버로부터 요청이 밀려오면 DB 서버의 CPU, Memory 사용량이 늘면서 부하가 발생할 수 있습니다.

 

Sharding

• horizontal partition처럼 동작
• 각 partition이 독립된 DB서버에 저장

두개의 테이블이 하나의 DB서버에 저장되면 horizontal partitioning이다.

서버에 요청이 밀려오면 DB서버의 cpu와 memory를 사용해서 처리되는데 하드웨어 자원은 한정된다.

• 각 partition들을 서로 다른 DB서버에 저장
• 부하(load)를 분산시키는 목적
• partition key를 shard key라고 부름
• 각 partiton을 shard라고 부름: subscription_0은 shard1, subscription_1은 shard2

 

Replication

레플리케이션이란, 메인 DB 서버와 동기화된 보조 DB 서버를 운영하는 것을 의미한다.

Replication은 데이터베이스에서 데이터의 복사본을 생성하여 여러 대의 서버에 동일한 데이터를 유지한다.

 

테이블이 DB 서버에 저장되어 있고, 백엔드 서버에서 DB 서버로 read/write 요청을 보내는 경우를 가정한다.

이 때, DB 서버에 어떠한 문제가 생긴다면 정상적으로 동작할 수 없기 때문에 사용자들은 피해를 보게 된다. 이런 상황이 실제 서비스에서는 발생하면 안 되기 때문에 해결을 해줘야 하는데 이럴 때 사용하는 방식 중 하나가 레플리케이션이다.

 

Failover 장애 대비: Replication의 주요 목적 중 하나는 장애 대비입니다. 기존의 데이터베이스 서버(주 서버 또는 primary 서버)를 복제하여 여러 대의 서버(복제 서버 또는 secondary 서버)에 동일한 데이터를 유지한다. 주 서버에 장애가 발생하더라도 복제 서버가 해당 정보를 제공하여 서비스의 지속성을 보장한다.

고가용성 (High Availibility): Replication을 통해 고가용성을 달성할 수 있다. 주 서버에 문제가 발생하면 자동으로 복제 서버 중 하나가 새로운 주 서버로 승격되어 서비스가 중단되지 않고 계속된다. 이러한 기능을 failover(복구)라고 한다.

Read Traffic 분산: 서버 부하(load)를 낮춘다. Replication은 읽기 작업(Read)을 복제 서버로 분산시킬 수 있다. 주 서버가 받는 읽기 작업의 부하를 분산하여 성능을 향상할 수 있다. 주로 읽기 작업이 많은 시나리오에서 유용하다.

 

레플리케이션에서는, 메인 DB 서버와 보조 DB 서버를 (master - slave, primary - secondary, leader - replica) 이러한 형태로 호칭한다. master - slave는 구시대적이다라는 의견도 있다.

---

참고 자료: 쉬운코드 https://www.youtube.com/watch?v=P7LqaEO-nGU