Partitioning(파티셔닝)과 Sharding(샤딩)

이번에는 정말 기초적인 개념에 대해서 공부를 하고 정리를 해보았다.

partitioning과 sharding을 많이 들어보기도 했고, 실제로 사용도 해보았지만, 막상 이걸 설명을 하려고 하고 partitioning과 sharding의 차이에 대해서 정리해보려고 하니까 잘 안되더라..그래서 이 참에 한 번 정리를 쭉 해보았다.

(부끄럽..이거 외에도 기초지식을 좀더 탄탄히 잡아야할 필요성을 요즘 많이 느끼고 있다.)

 

 

Intro

파티셔닝과 샤딩을 사용하는 목적은 실질적으로 동일하다. 

DBMS에 너무 큰 용량이 데이터를 다루게 되면서 이에 대한 성능을 향상시키기 위해서 데이터베이스를 분할하여 데이터를 저장하고 활용하고자 하는 것이 바로 파티셔닝과 샤딩이다.

 

실질적으로 파티셔닝 혹은 샤딩을 사용했을 경우 얻을 수 있는 이점 또한 유사하다(목적이 동일하기 때문이 아닐까 싶다)

1. 성능향상
   1. 특정 쿼리의 성능을 향상
   2. 대용량 쓰기 환경에서 효율적
   3. 필요한 데이터만 빠르게 조회할 수 있으므로 쿼리가 가벼워진다
   4. full scan에서 데이터 접근의 범위를 줄여 성능을 향상할 수 있다.
2. 가용성
   1. 물리적인 파티셔닝으로 전체 데이터의 훼손 가능성이 준다
   2. 파티션 별로 독립적으로 백업하고 복구가능
   3. 파티션 단위로 disk i/o를 분산하여 경합을 줄이므로 update 성능 향상
3. 관리 용이성

결국 이에 따른 트레이드 오프 또한 유사하다.

바로 테이블을 여러 파티션으로 쪼갰기 때문에 테이블 간의 join 비용이 증가한다는 점이다.

 

정확하게 샤딩은 파티셔닝 중에서도 수평파티셔닝과 같이 언급되는데, 이는 실질적인 목적도 동일하고 방식도 비슷하기 때문이다.

하지만 이 둘을 다른 개념으로 나누어서 활용하는 이유는 있을 것이다.

따라서 각 개념에 대해서 정리를 하며 차이점을 파악하고 각 특징에 대해서도 정리해보려 한다.

 

Sharding(샤딩)

샤딩은 위의 그림과 같이 하나의 테이블 내에서 특정 칼럼을 key로 잡고 특정 기준에 의해서 수평으로 쪼개는 것이다.

샤딩의 가장 큰 특징은 이렇게 쪼갠 두개 이상의 테이블을 서로 다른 데이터베이스에 분산 저장한다는 것이다.

 

즉 DBMS하나를 사용할 때, 리소스 및 성능과 관련해서 여러 이슈가 발생할 경우,

다수의 데이터베이스에 분산 저장하여 성능적 한계를 극복하는 것이다.

 

실제로 이렇게 데이터베이스 하나를 사용하는 경우의 성능적 한계를 극복하기 위해 등장한 것이 분산 스토리지들이다. 
그러나 분산 스토리지의 경우 여러 기능적인 제약이 뒤따른다(Join/ 범위검색이 힘들다)
따라서 기능을 최대한 활용하면서도 데이터 확장을 위해서 RDBMS를 샤딩하여 사용하는 것이다. 

 

샤딩의 방식

Hash Sharding

• Shard Key : Database id를 Hashing
• 아주 간단한 Sharding 기법
• 수평 파티셔닝의 해시분할과 유사한 방식인거 같다.

 

Dynamic Sharding

• Locator Service(위의 그림에서 데이터의 range와 그에 따른 키를 대응하여 정리해둔 가상의 테이블을 의미)를 통해 Shard Key를 얻는다.
• Cluster가 포함하는 Node 개수를 늘려본다면?
  • Locator Service에 Shard Key를 추가
  • 기존의 Data의 Shard Key는 변경이 없다.
  • 확장에 유연한 구조.
• Example
  • HDFS : Name Node
  • MongoDB : ConfigServer

 

Entity Group

 

실질적으로 Hash Sharding과 Dynamic Sharding은 Key-Value 형태를 지원하기 위해 나온 방법이다. 즉 RDBMS에서의 샤딩 방식이라기 보다는 NoSQL의 샤딩 방식이다. 

 

RDBMS의 join, index, transaction을 사용함으로써 Application의 복잡도를 줄이는 방법과 유사한 방식으로 샤딩하는 것이 위의 그림에서 설명하는 Entity Group이다.

 

샤딩의 단점

• 데이터베이스 서버 간의 연결 과정이 많아져서 비용이 증가할 수 있다.
• 하나의 서버가 고장나면 데이터의 무결성이 깨질수도 있다.
• 가장 큰 문제는 하나의 트랜잭션에서 두 개 이상의 샤드에 접근할 수 없다는 것이다. 
• 여러 데이터 베이스를 대상으로 작업해야 하므로 경우에 따라서는 Join등의 기능에 제약이 있을 수 있고 일관성과 복제 등에 불리한 점이 많다.

따라서!

가능하면 샤딩을 피하거나 지연시킬 수 있는 방법을 찾는 것이 우선되어야 한다.

• Scale-in
  • Hardware Spec이 더 좋은 컴퓨터를 사용
• Read 부하가 크다면?
  • Cache나 Database의 Replication을 적용
• Table의 일부 컬럼만 자주 사용한다면?
  • Vertically Partition(수직 파티셔닝)
  • 이를 통해 Data를 사용빈도에 따라서 Hot, Warm, Cold Data로 분리

즉, 샤딩은 많은 데이터를 저장하고 있는 데이터 베이스를 효율적으로 활용하기 위한 방안이지만, 여러 트레이드오프 때문에 최대한 다른 방법을 활용하여 샤딩을 피해야 한다고 한다.

 

 

Partitioning(파티셔닝)

수평파티셔닝

해당 예시 그림만 보아도 샤딩과 매우 유사하다.

차이점이라면 파티셔닝의 경우 분산저장하되 하나의 데이터베이스 내에 저장된다. 

즉 같은 데이터베이스 내에서 하나의 큰 테이블을 쪼개는 것이다.

 

(수평)파티셔닝 방식

1. 범위 분할(range partitioning)
   1. 연속적인 숫자나 날짜를 기준
   2. 분할키 값이 범위내에 있는지 여부
   3. 우편 번호, 날짜 등의 데이터
2. 목록 분할(list partitioning)
   1. 값 목록에 파티션을 할당.
   2. 분포도가 비슷 하며, 많은 SQL에서 해당 Column의 조건이 많이 들어오는 경우 유용하다.
   3. 예를 들어 (한국,일본,중국) -> 동북아시아로 / (프랑스,영국,이탈리아) -> 유럽으로 묶어서 분할할 수 있다.
3. 해시분할(Hash partitioning)
   1. 파티션 키의 해시값에 의한 파티셔닝
   2. 균등한 데이터 분할
   3. 특정 데이터가 어느 파티션에 있는지 판단이 어렵다.
   4. 파티션을 위한 범위가 없는 데이터에 적합
4. 합성 분할(composite partitioning)
   1. 위의 기술들을 결합
   2. 파티션의 sub-partitioning 진행

 

수직 파티셔닝

위의 그림 처럼 테이블의 칼럼을 기준으로 나누어 수직으로 파티셔닝한다.

RDB의 3정규화와 연관지어 볼 수 있다.

어떻게 보면 정규화도 수직 파티셔닝과 관련된 과정이긴 하나(하나의 테이블을 수직으로 쪼개에서 서로 다른 테이블로 나눈다는 개념은 유사하므로)

정확히는 수직 파티셔닝은 이미 정규화된 데이터를 분리하는 과정이다.

 

• 자주 사용하는 칼럼을 별도로 분리하여 성능을 향상하고
• 같은 타입의 데이터가 저장되어 데이터 압축률을 높인다.
• 위에서 언급되었는데 수직 파티셔닝을 통해 데이터 내 컬럼의 활용빈도에 따라서 hot, warm,cold 데이터로 분리하여서 성능을 향상하고 관리할 수 있다.
• 이 또한 데이터를 찾는 과정이 기존보다 복잡하다

 

RDB의 3정규화

정규화는 데이터의 중복성을 줄이고 무결성을 위해서 실행한다.

 

OLTP 같이 CRUD가 많이 일어나는 데이터 베이스의 경우 정규화를 진행하는 것이 좋지만,

OLAP의 경우 반정규화를 통해 최대한 데이터 조회시의 다른 테이블과의 join을 줄이고, 해당 테이블 내에서 단순조회 가능하도록 해야한다

 

이런 정규화에는 6단계까지 있는데, 실무에서는 1~3정규화 까지의 과정을 거친다.

자세히는 별도로 다뤄볼 예정이며, 해당 블로그를 참고하자!

 

3정규화에 대해서만 정리하자면, “기본키는 중복되지 않고, 모든 데이터는 기본키에 의존하고 있는 상태이다.”라고 할 수 있다.

 

 

 

Reference

• 파티셔닝과 샤딩의 차이점
• 데이터베이스 정규화
• 데이터베이스의 샤딩이란