[DB] 파티셔닝? 샤딩? 레플리케이션?

백엔드·2023년 9월 2일

RDBMS

들어가며

해당 강의를 보고 정리한 내용입니다.

이번 글에서는 파티셔닝, 샤딩, 레플리케이션에 대해 살펴보겠습니다.

partitioning

개념

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

종류

vertical partitioning

SQL

SELECT id, title ..., comment_cnt
FROM article
WHERE ...

문제 예시

게시글 테이블의 경우, 게시글 목록을 조회하는 쿼리를 예로 들어보겠습니다. 이 쿼리는 테이블의 여러 열 중에서 id, title, comment_cnt와 같은 특정 컬럼들만 필요로 합니다. 그러나 테이블에 저장된 데이터는 일반적으로 HDD 또는 SSD에 저장되어 있으며, 쿼리가 실행되는 방식은 다음과 같습니다.

실행 순서

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

여기서 주목해야 할 점은 content와 같은 긴 데이터를 포함하는 컬럼이 크기가 크다는 것입니다. 그러나 게시글 목록 조회와 같은 쿼리에서는 이러한 긴 컬럼들이 필요하지 않습니다. 그럼에도 불구하고 데이터베이스는 해당 행의 모든 열을 읽어와야 하므로 I/O 부담이 크고 시간과 자원이 낭비될 수 있습니다.

문제 해결

이러한 문제를 해결하기 위해 Vertical Partitioning을 활용할 수 있습니다. 이를 통해 content와 같은 긴 데이터를 별도의 테이블로 나누어 데이터를 저장하게 됩니다.

결과적으로 게시글 목록 조회와 같은 쿼리에서는 content와 같은 불필요한 데이터를 HDD 또는 SSD에서 읽어오지 않아도 되므로 I/O 부담이 감소하고 성능이 향상됩니다. Vertical Partitioning은 데이터베이스의 성능을 최적화하고 비용을 절감하는 데 유용한 전략 중 하나입니다.

horizontal partitioning

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

horizontal partitioning을 사용해 이러한 문제를 해결할 수 있습니다.
horizontal partitioning을 사용하는 여러가지 방법론이 존재합니다.
해당 글에서는 hash-based horizontal partitioning을 살펴보겠습니다.

예시

user_id를 입력으로 받아서 0 또는 1과 같은 해시값을 출력하는 해시 함수를 구현합니다.해시 함수의 결과에 따라 두 개의 파티션 테이블, subscription_0 테이블과 subscription_1 테이블을 생성합니다. user_id를 기준으로 두 파티션 중 하나로 분할되어 저장됩니다. 여기서 user_id를 파티션 키라고 부릅니다.

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

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

주의할 점

만약 특정 channelId를 구독한 사용자의 user_id를 조회하려면 channelId를 조건으로 사용할 수 있습니다. 그러나 이 때 주의할 점은 user_id를 파티션 키로 선택했으므로 모든 파티션을 조회해야 합니다. 따라서 이런 쿼리는 모든 파티션에 대해 수행되어야 합니다.

그렇기 때문에 가장 많이 사용될 패턴에 따라 partition key를 정하는 것이 중요합니다.
또 중요한 점은 데이터가 균등하게 분배될 수 있도록 hash function을 잘 정의하는 것이 중요합니다

Sharding

개념

Sharding은 데이터베이스에서 데이터를 수평으로 나누는 수행 방법 중 하나로, 각각의 파티션을 독립적인 데이터베이스 서버에 저장하는 전략입니다.

Sharding의 주요 이점 중 하나는 데이터베이스 서버의 부하를 분산시킬 수 있다는 것입니다. 각각의 파티션은 독립적인 데이터베이스 서버에 저장되므로 서버 간의 부하가 분산됩니다.

Sharding은 특히 대규모 서비스에서 데이터 관리와 성능 최적화를 위한 중요한 전략 중 하나입니다. 대규모 트래픽을 처리하거나 대용량 데이터를 관리할 때 Sharding은 데이터베이스 성능을 향상시키는 데 도움이 됩니다

Sharding에서는 각 파티션을 식별하기 위한 특정 열(또는 열 조합)을 선택합니다. 이 열은 Shard Key로 알려져 있으며, 일반적으로 데이터의 분산을 균형있게 유지하기 위해 신중하게 선택됩니다.

Sharding에서 각 파티션을 Shard라고 부릅니다. 각 Shard는 독립적인 데이터베이스 서버에 저장되며, Shard Key를 기반으로 데이터가 분할됩니다.

Replication

개념

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

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

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

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