[DATABASE] Partitioning VS Sharding

데이터베이스 성능 최적화와 관리 효율성을 높이기 위한 다양한 전략은 아래와 같이 다양하다.

1) Denormalization(반정규화)

2) Partitioning(파티셔닝)

3) Sharding(샤딩)

4) Replication(리플리케이션)

5) Clustering(클러스터링)

 

이번 시간에는 파티셔닝, 샤딩에 대해 알아보자.

반정규화에 대해서는 링크를 참고하길 바란다.

 

1. Partitioning(파티셔닝)

Database Table을 더 작은 Table들로 나눈 것

 

파티셔닝은 아래 두 가지 종류로 나뉜다.

Vertical Partitioning	Horizontal Partitioning
`Column`을 기준으로 Table을 나누는 방식	`Row`를 기준으로 Table을 나누는 방식

 

 

1-1. Vertical Partitioning

Vertical Partitioning은 하나의 테이블을 여러 개의 테이블로 분할하여, 각 테이블이 원래 테이블의 일부 컬럼만을 가지게 하는 방법

 

데이터를 더 작은 단위로 나누어 관리함으로써, 특정 쿼리 수행 시 필요하지 않은 데이터를 읽지 않도록 하여 성능을 최적화할 수 있다.

 

컬럼을 기준으로 나누기 때문에 스키마에 대한 변경이 발생한다.

 

1) Vertical Partitioning은 어떤 경우에 수행될까?

- 특정 컬럼들에 자주 접근하는 경우

   자주 사용되는 컬럼들만 별도의 테이블로 분리하여, 데이터 접근 속도와 처리 효율을 향상시킬 수 있다.
- 데이터 크기가 클 경우

   대용량 데이터를 보다 효율적으로 관리하기 위해, 관련성이 높은 컬럼끼리 그룹화하여 별도의 테이블로 관리할 수 있다.
- 보안 요구사항이 있는 경우

   특정 컬럼들이 민감한 정보를 포함하고 있어 접근 제어가 필요한 경우, 해당 컬럼들만 분리하여 보안 수준을 강화할 수 있다.

 

2) 예시

Article Table

아래와 같은 Article Table이 있다고 가정해보자

article_Id(PK)	title	author_id(FK)	content	publication_date	category	views
1	"New Tech Trends"	3	"In this article, we explore new trends in technology..."	2024-03-01 10:00:00	Tech	150
2	"Healthy Living Tips"	2	"Discover ways to lead a healthier lifestyle..."	2024-02-28 09:30:00	Health	200
3	"Global Economic Outlook"	5	"An analysis of global economic trends and forecasts..."	2024-03-05 08:15:00	Economy	180
4	"The Future of AI"	4	"What the future holds for artificial intelligence..."	2024-03-10 11:20:00	Tech	0
5	"Mastering Python"	1	"A comprehensive guide to mastering Python programming..."	2024-03-15 14:45:00	Education	250

 

아래와 같은 페이지를 조회할 때, 각각의 페이지보다 리스트 페이지를 더 많이 조회한다고 가정하자

 

이 때 우리는, content 컬럼은 포함되어 있지 않기 때문에 필요없는 정보인 content 컬럼을 제외하고 아래와 같이 Select문을 진행할 것이다.

SELECT
	artical_id, 
	title, 
	author_id, 
	title, 
	publish_date, 
	views
FROM
	article
WHERE
	....

 

하지만 위 쿼리문은 한가지 문제가 있다.

위 쿼리문을 Database에 요청하면 일단 HDD(Hard disk)나 SSD에서 해당 Table의 모든 컬럼에 대해 가져온 후, Select절에 걸린 컬럼에 대해서만 다시 필터링을 진행한다는 점이다.

 

여기서 content 컬럼은 크기가 매우 클 수 있다.

현재 지금 작성 중인 블로그 글 또한 content에 해당되는데, 글의 제목이나 날짜, 조회수 등 보다 훨씬 데이터 크기가 큰 것을 알 수 있다.

 

그렇다는 것은 HDD나 SSD에서 데이터를 읽어올 때, I/O에 대한 부담이 생긴다는 것이다.

가장 데이터가 큰 content가 현재 select에서는 사용되지 않는 컬럼인 것이다.

 

우리가 체감하지 못할 수도 있지만, select할 때 full scan을 하는 경우가 생기거나 한다면 체감할 정도로 performance에 영향을 줄 수 있다.

 

이때, 컬럼을 기준으로 아래와 같이 테이블을 나누어 Vertical Partitioning을 진행하여 I/O의 부담을 줄일 수 있다.

 

Article Table과 Artical_content Table

아래 테이블을 살펴보면 content는 article_content 테이블로 파티셔닝 한 것을 알 수 있다.

 

article Table

article_Id(PK)	title	author_id(FK)	publication_date	category	views
1	"New Tech Trends"	3	2024-03-01 10:00:00	Tech	150
2	"Healthy Living Tips"	2	2024-02-28 09:30:00	Health	200
3	"Global Economic Outlook"	5	2024-03-05 08:15:00	Economy	180
4	"The Future of AI"	4	2024-03-10 11:20:00	Tech	0
5	"Mastering Python"	1	2024-03-15 14:45:00	Education	250

 

article_content Table

article_Id(PK)	content
1	"In this article, we explore new trends in technology..."
2	"Discover ways to lead a healthier lifestyle..."
3	"An analysis of global economic trends and forecasts..."
4	"What the future holds for artificial intelligence..."
5	"A comprehensive guide to mastering Python programming..."

 

그러면 이제 리스트에 대한 Select를 수행할 때, article에서만 수행할 수 있게 된다.

content에서는 수행하지 않아도 되기 때문에 I/O에 대한 부담이 많이 줄어들게 된다.

 

또한, article 각각의 content를 수행할 때에도 이점이 있다.

리스트 화면에서 내용을 확인하기 위해 디테일 화면으로 이동할 때,

Front에서는 이미 article의 article_id, title, author_id, publication_date, category, views에 대한 정보를 알고 있기 때문에

해당 content 내용에 대해서만 조회하면 된다.

 

따라서 리스트는 article table에서, 디테일은 article_content table에서 조회하면 되는 것이다.

 

하지만 리스트에서 넘어가는 것이 아니라 url을 통해 바로 디테일 화면으로 가는 경우에는 프론트에서 리스트 정보를 저장하고 있지 않기 때문에 join 연산이 발생할 것이다.

 

따라서 파티셔닝을 진행하는 경우에는 아래와 같은 장단점에 대해 검토한 후 신중히 결정해야 한다.

 

3) Vertical Parititioning 장단점

(1) 장점

- 성능 향상

   필요한 데이터만 빠르게 접근할 수 있어, 데이터베이스 쿼리 성능 향상

- 보안 강화

   민감한 데이터를 분리하여 관리함으로써, 데이터에 대한 보안을 강화할 수 있음

- 데이터 관리 용이성

   데이터를 더 작은 단위로 나누어 관리함으로써, 데이터베이스의 관리 및 유지보수 용이

 

(2) 단점

- 조인 비용 증가

   데이터가 여러 테이블로 분리되어 있을 때, 이들을 다시 결합하기 위한 조인(join) 작업이 필요할 수 있으며,

   이는 성능 저하를 일으킬 수 있음

- 설계 복잡성

   올바른 Vertical Partitioning을 위해서는 데이터베이스의 설계가 더 복잡해질 수 있으며,

   데이터 관계를 정확히 이해하고 분할 계획을 세워야 함
- 데이터 무결성 관리

   데이터가 여러 테이블에 분산되어 있기 때문에, 데이터의 무결성을 유지하는 것이 더 어려워질 수 있음

 

1-2. Horizontal Partitioning

Horizontal Partitioning은 데이터베이스의 테이블을 행 단위로 분할하는 방법

 

row를 기준으로 나누기 때문에 스키마에 대한 변경은 발생하지 않는다.

즉, 각 파티션은 동일한 스키마(컬럼 구조)를 가지지만, 다른 데이터 세트(행)를 포함한다.

 

이 분할은 데이터를 더 효율적으로 관리하고, 검색 및 검색 성능을 향상시키기 위해 사용된다.

 

1) Horizontal Partitioning은 어떤 경우에 수행될까?

- 대용량 데이터 처리

   테이블이 너무 커져서 쿼리 성능이 저하되는 경우, 데이터를 분할하여 처리 속도를 개선할 수 있다.

- 데이터베이스 확장

   데이터를 여러 서버에 분산시켜 저장 공간을 확장하고, 부하를 분산시킬 필요가 있을 때 사용된다.

- 데이터 접근 최적화

   특정 행에 대한 접근이 빈번한 경우, 이러한 행들을 분할하여 데이터 접근 속도를 향상시킬 수 있다.

- 보안 및 규정 준수

   특정 데이터를 지리적으로 분리해야 하는 보안 요구 사항이나 규정 준수를 위해 사용될 수 있다.

 

2) 예시

유튜브를 생각해보자

 

유튜브를 사용하는 유저가 있고, 유저가 유튜버를 구독할 때 알람과 멤버쉽에 대한 정보를 담고 있는 테이블이 아래와 같다고 가정하자.

 

Subscription Table

 

구독 정보를 저장하는 subscription 테이블은 아래와 같다

 

subscription Table

user_id(PFK)	channel_id(PFK)	alarm	membership
1	1	True	Premium
2	401	False	Standard
3	395	True	Premium
4	717	False	Standard
5	1	True	Premium
6	22	False	Standard
1	28	True	Premium
4	101	True	Standard
1	42	False	Premium
3	42	True	Standard

 

여기서 이 테이블은 어느 정도의 정보를 `최대치`로 가지고 있을 수 있을지 생각해보자.

 

유저의 수를 N, 채널의 수를 M이라고 했을 때, 최대치는 단순 곱셈 연산으로 N*M이 된다.

# of users : N
# of channels : M

# of max subscription : N * M

 

따라서 아래 상황이 된다면

# of users : 1M
# of channels : 1K

# of max subscription : 1G(10억)

 총 10억개의 데이터가 한 테이블에서 관리되어야 하는 것이다.

 

그렇다면 어떤 문제가 있을까?

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

- 따라서 테이블에 읽기(b-tree라고 가정)/쓰기가 있을 때마다 인덱스에서 처리되는 시간도 조금씩 늘어난다.

 

이때 사용할 수 있는 방법이 바로 Horizontal partitioning인 것이다.

 

Horizontal partitioning을 할 수 있는 방식은 여러가지가 있는데 여기에서는 `hash-based`로 예시를 들어보도록 하겠다.

 

Horizontal Partitioning: Hash-based

아래와 같이 hash function을 이용해 파티셔닝을 진행한다.

 

hash function에 user_id를 input 값으로 넣어주면 user_id를 기준으로 0 또는 1의 값이 산출되도록 하는 간단한 함수이다.

 

여기서 산출되는 0 또는 1을 기준으로 파티셔닝 된 테이블로 가게 된다.

 

예를 들어 user_id가 1일때, hash_function의 결과값이 0이었다면, user_id가 1인 row는 모두 subscription_0으로 이동하는 것이다.

그리고 user_id가 2일때, hash_function의 결과값이 1이었다면, user_id가 2인 row는 모두 subscription_1로 이동한다.

 

이렇게 분류된 테이블은 아래와 같다.

 

subscription_0 Table

user_id(PFK)	channel_id(PFK)	alarm	membership
1	1	True	Premium
3	395	True	Premium
1	28	True	Premium
1	42	False	Premium
3	42	True	Standard

 

subscription_1 Table

user_id(PFK)	channel_id(PFK)	alarm	membership
2	401	False	Standard
4	717	False	Standard
5	1	True	Premium
6	22	False	Standard
4	101	True	Standard

 

위 테이블을 확인해보면 user_id를 기준으로 저장을 했기 때문에 같은 user는 항상 같은 테이블에 위치하게 된다는 것을 알 수 있다.

 

user_id가 1인 것은 모두 subscription_0에 있고, user_id가 4인 것은 모두 subscription_1에 있다.

 

현재 예시는 이해를 돕기 위해 간단하게 2개 테이블로만 분리했지만, 더 많은 N개의 테이블로 분리하는 것도 가능하다.

 

이것이 바로 hash를 기반으로 한 horizontal partitioning이다.

 

여기서 hash function의 기준이 된 user_id는 `paritition key`라고 부른다.

 

Partition Key

파티션 키가 user_id인 상태에서 user_id가 아니라, channel_id로 조회하는 경우를 생각해보자.

그렇다면 subscription_0과 subscription_1을 모두 조회해야 한다.

이 경우 파티션을 나눈 의미가 퇴색될 수 있다.

 

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

 

 

그럼 Horizontal partitioning된 테이블에 select를 할 때는 실제로 어떻게 진행하게 될까?

user_id가 3인 user가 구독한 채널들 정보를 모두 조회하고 싶다면?

 

해시 함수를 백엔드 서버 측에서 구현했는지, DB 측에서 자동으로 처리해주는지에 따라 조금 다르게 진행한다.

 

(1) 백엔드 서버 측에서 해시 함수를 적용하는 경우

① 백엔드 서버에서 해시 함수 사용

     만약, 해시 함수의 결과가 0이라면 subscription_0에 위치한다는 것을 알 수 있음

② 쿼리 실행

     해시 함수의 결과를 바탕으로 해당하는 테이블에서만 조회 쿼리를 실행

     따라서 user_id가 3인 것은 해시 함수의 결과가 0이므로, subscription_0에서 쿼리문 수행

SELECT
	*
FROM
	SUBSCRIPTION_0
WHERE
	user_id = 3

 

(2) DB 측에서 자동으로 관리해주는 해시 함수 사용

① 파티션 설정

     데이터베이스 설정 단계에서 특정 테이블에 대해 해시 기반 파티셔닝을 활성화하고, 파티션 키를 지정

     여기서는 user_id를 파티션 키로 지정함

# MYSQL에서 파티셔닝 설정하기
CREATE TABLE Subscription (
    user_id INT NOT NULL,
    channel_id INT,
    alarm BOOLEAN,
    membership TEXT,
    PRIMARY KEY (user_id)
) PARTITION BY HASH (user_id)
PARTITIONS 2;

② 쿼리 실행

     내부적으로 파티션 키 값을 기반으로 해시 함수를 적용했기 때문에 Subscription이라는 원본 테이블명으로 사용 가능

     실제로는 subscription_0, subscription_1과 같은 물리적인 파티션으로 나뉘어져 있지만, 사용자는 논리적으로 단일 테이블로서 작업

     DBMS는 user_id 값에 기반한 내부 해시 함수를 사용해 자동으로 적절한 파티션에서 데이터 조회

     따라서 user_id가 3인 것을 subscription에서 조회하는 쿼리문 작성

SELECT
	*
FROM
	SUBSCRIPTION
WHERE
	user_id = 3

 

(3) 백엔드 서버 측과 DB 측 비교

기준	백엔드 서버 측에서 해시 함수 사용	데이터베이스(DB) 측에서 해시 함수 사용
해시 함수 실행 위치	애플리케이션 레벨(백엔드 서버)	데이터베이스 관리 시스템(DBMS)
파티셔닝 로직 제어	개발자가 직접 해시 함수를 구현하고 관리, 데이터를 적절한 파티션에 배치하는 로직을 애플리케이션 코드 내에서 제어	데이터베이스가 자동으로 해시 기반 파티셔닝을 관리, 개발자는 파티션 관리에 신경 쓸 필요가 없음
유연성	높음: 개발자가 해시 함수와 파티셔닝 전략을 자유롭게 설정하고 조정할 수 있음	낮음: 파티셔닝 전략과 해시 함수는 DBMS에 의해 내부적으로 결정됨
복잡성	높음: 파티션 관리 로직을 애플리케이션 코드에 직접 구현해야 함	낮음: 데이터베이스가 모든 파티셔닝 로직을 자동으로 처리
성능 최적화	개발자가 파티셔닝 로직을 최적화할 수 있으나, 부하 분산과 데이터 관리에 대한 깊은 이해 필요	DBMS의 최적화 메커니즘에 의존, 일반적으로 높은 성능을 제공하지만 세부 최적화는 제한적
확장성	애플리케이션 레벨에서 파티셔닝 로직을 조정하여 데이터 분산 방식을 변경할 수 있음	데이터베이스 레벨의 확장성에 의존, 데이터베이스 클러스터링이나 샤딩 등의 기능을 통해 확장 가능
데이터베이스 종속성	낮음: 파티셔닝 로직이 애플리케이션 내부에 있어, 데이터베이스를 변경하더라도 애플리케이션 로직에 따라 조정 가능	높음: 파티셔닝 기능과 성능은 사용 중인 DBMS의 구현에 크게 의존

 

일반적으로는 데이터베이스 측에서 해시 함수를 사용하는 방법을 사용한다고 한다.

 

3) Horizontal Partitioning 전략

위 예시에서는 Hash-based 전략으로 설명을 진행했다.

하지만 이외에도 여러가지 전략이 존재한다.

아래에서 간략히 살펴보도록 하자.

 

 

(1) Hash Partitioning

     - Partition Key의 Hash값에 의한 Partitioning (균등한 데이터 분할 가능)
     - Select시 조건과 무관하게 병렬 처리 (질의 성능 향상)

        병렬 처리 시 각 쿼리는 여러 파티션에 대해 동시에 실행될 수 있으며, 이는 대기 시간을 줄이고 처리량을 높이는 데 기여함
     - 특정 Data가 어느 Hash Partition에 있는지 판단 불가 (DB hash 함수 사용 시)
     - 특정 패턴이 없는 데이터의 분산에 유리

(2) Range Partitioning

      - 연속적인 숫자나 날짜 기준으로 Partitioning 진행
      - 손쉬운 관리 기법 제공 에 따른 관리 시간의 단축할 수 있음
         ex) 우편번호, 일별, 월별, 분기별 등 의 데이터에 적합

(3) List Partitioning

      - 명시적으로 지정된 값의 리스트를 기준으로 데이터를 분할
      - 분포도가 비슷하며, 많은 SQL에서 해당 Column의 조건이 많이 들어오는 경우 유용

         ex) 국가 코드, 지역 코드 등
      - Multi-Column Partition Key를 제공하기 힘듦
         ex) [한국, 일본, 중국 -> 아시아] [노르웨이, 스웨덴, 핀란드 -> 북유럽]

(4) Composite Partitioning

      - 두 가지 이상의 파티셔닝 전략을 조합하여 사용

         ex) range partitioning으로 데이터를 분할한 후, 각 range 내에서 list partitioning을 적용할 수 있음
      - 큰 파티션에 대한 I/O 요청을 여러 partition으로 분산할 수 있음
      - 데이터를 더 세분화하여 관리하고자 할 때 사용

         ex) Range Partitioning을 할 수는 있지만, Partitioning 결과 생성된 Partition이 너무 커서 효과적으로 관리할 수 없을 때

 

(5) 정리

특성/전략	Hash partitioning	Range partitioning	List partitioning	Comporite partitioning
정의	파티션 키의 해시 값에 기반하여 데이터를 분할	특정 범위에 따라 데이터를 분할	사전에 정의된 값 목록에 따라 데이터를 분할	두 가지 이상의 파티셔닝 방식을 조합하여 데이터를 분할
데이터 분산	균등하게 분산	연속적인 값이나 범위에 따라 분산	특정 값에 따라 분산	여러 기준에 따라 분산될 수 있음
주요 사용 사례	데이터를 균일하게 분산시켜야 할 때 사용	시간 기반 데이터나 순차적인 값에 기반한 데이터 분할에 적합	카테고리, 지역 코드와 같이 명확히 구분되는 값을 가진 데이터 분할에 적합	복잡한 데이터 모델이나 다양한 쿼리 패턴을 가진 시스템에서 사용
장점	데이터를 균등하게 분산시킬 수 있음	범위 쿼리를 최적화할 수 있음	특정 값에 대한 쿼리를 최적화할 수 있음	여러 파티셔닝 방식의 이점을 조합할 수 있음
단점	특정 범위에 대한 쿼리 최적화가 어려움	균등하지 않은 데이터 분산이 발생할 수 있음	Multi-Column 파티션 키 사용이 어려움	구성이 복잡하고 관리가 어려울 수 있음
적합한 쿼리 유형	모든 쿼리 유형에 균등한 성능을 제공	특정 범위 내의 데이터를 조회하는 쿼리에 유리	특정 값을 기준으로 데이터를 조회하는 쿼리에 유리	다양한 쿼리 유형을 최적화할 수 있음

 

4) Horizontal Partitioning 장단점

(1) 장점

- 성능 향상

   데이터를 분할함으로써, 쿼리 성능을 개선하고 검색 속도를 높일 수 있음
- 확장성

   데이터를 여러 서버에 분산시킴으로써 시스템의 확장성을 높일 수 있음

- 관리 용이성

   데이터를 더 작은 단위로 관리함으로써, 백업 및 유지보수 작업이 더 용이해짐

 

(2) 단점

- 복잡성 증가

   데이터베이스 아키텍처의 복잡성이 증가하며, 관리가 더 어려워질 수 있음

- 트랜잭션 처리 복잡성

   여러 파티션에 걸쳐 있는 데이터를 처리하는 트랜잭션의 복잡성이 증가할 수 있음

- 조인 연산 비용

   다른 파티션에 있는 데이터를 조인해야 할 경우, 성능 저하를 초래할 수 있음

 

2. Sharding(샤딩)

Horizontal partitioning처럼 동작하지만 차이점이 있다.

 

바로 나누어진 각 partition이 `독립된 DB 서버`에 저장된다는 것이다.

Horizontal partitioning의 개념을 분산 데이터베이스 환경에 적용한 것이기 때문이다.

 

2-1. Horizontal partitioning VS Sharding

Horizontal partitioning은 모든 파티션들을 같은 DB 서버에 저장하는 것이다.

이 경우, 파티션을 나누어 다른 테이블에 값을 저장하고 있더라도, 같은 DB 서버로 요청이 들어오기 때문에

결국 같은 CPU와 메모리를 사용하는 것이어서 부담이 발생할 수 있다.

 

Sharding은 다른 파티션을 서로 다른 DB서버에 저장하는 것이다.

따라서 DB 서버의 부하를 분산시키는 효과를 얻을 수 있다.

 

sharding을 진행하게 되면 horizontal parititioning에서 사용하던 용어가 달라지게 된다.

partition key를 shard key라고 부르고, 각 partition을 shard라고 부르게 된다.

 

Sharding 전략 또한 위에서 살펴봤던 partitioning 전략과 동일하고, 용어만 sharding으로 변경된다.

따라서 sharding 전략에는 hash 샤딩, range 샤딩, list 샤딩, composite 샤딩이 있다.

 

우아한 형제들의 기술 블로그를 확인해보면 모듈러 샤딩이라는 용어를 확인할 수 있는데, 모듈러 샤딩은 해시 샤딩의 한 형태이다.

우아한 형제들의 기술 블로그에 적힌 샤딩에 대한 더 깊은 이야기는 링크를 통해 확인해보길 바란다.

 

2-2. Sharding 장단점

1) 장점

- 확장성

   샤딩은 데이터베이스의 수평적 확장을 가능하게 하여, 데이터와 트래픽이 증가함에 따라 시스템을 유연하게 확장할 수 있음

- 성능 향상

   데이터와 부하를 여러 노드에 분산시킴으로써, 개별 쿼리의 처리 속도와 전체 시스템의 처리량을 개선할 수 있음

- 부하 분산

   샤딩은 여러 서버에 걸쳐 데이터와 트래픽을 분산시키므로, 단일 서버에 집중되는 부하를 줄이고 시스템의 안정성을 높일 수 있음

  (Comment: 실무에서 샤딩을 경험했을 때, 트래픽이 많은 테이블의 부하를 분산시키는데는 확실히 탁월한 효과가 있었다고 함)

- 고가용성

   적절히 구성된 샤딩 환경은 데이터의 복제본을 여러 샤드에 저장함으로써 데이터의 고가용성을 보장할 수 있음

 

2) 단점

- 복잡성 증가

   샤딩은 데이터베이스 아키텍처의 복잡성을 증가시킴. 샤딩 키의 선택, 데이터 분배, 샤드 간 라우팅 등을 관리해야 함
- 데이터 리밸런싱의 어려움

   시스템 확장 시 새로운 샤드를 추가하거나 기존 샤드의 데이터를 재분배하는 과정이 복잡하고 시간이 많이 소요될 수 있음

- 트랜잭션 관리의 복잡성

   여러 샤드에 걸쳐 있는 데이터에 대한 트랜잭션을 처리하고 일관성을 유지하는 것이 복잡해질 수 있음

- 조인 연산의 어려움

   서로 다른 샤드에 저장된 데이터 간의 조인 연산을 수행하는 것이 기술적으로 어렵거나 성능에 부정적인 영향을 줄 수 있음

- 샤딩 키 선택의 중요성

   샤딩 키를 잘못 선택하면 데이터 분배가 균등하지 않게 되어 성능 저하나 핫스팟 문제를 발생시킬 수 있음

   (* 핫스팟 문제: 데이터베이스 시스템이나 분산 시스템에서 특정 노드나 리소스가 과도한 부하를 받는 상황)

 

 

 

---

참조

https://www.youtube.com/watch?v=P7LqaEO-nGU

https://nesoy.github.io/articles/2018-02/Database-Partitioning

Database의 파티셔닝(Partitioning)이란?

 

https://geekswithblogs.net/gwbarchive/sql-azure-federation-introduction/

SQL Azure Federation – Introduction - Geeks with Blogs

https://techblog.woowahan.com/2687/

DB분산처리를 위한 sharding | 우아한형제들 기술블로그

https://gmlwjd9405.github.io/2018/09/24/db-partitioning.html

[DB] DB 파티셔닝(Partitioning)이란 - Heee's Development Blog