[백엔드 개발자 로드맵 2020] DATABASE - Sharding

Database Sharding

-관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서 데이터를 파티셔닝 하는 기술

 : DBMS레벨에서 파티셔닝하는 것이 아닌 데이터베이스 자체를 분할하는 것

  => 애플리케이션 레벨에서 구현

ex) 지역이나 ID를 기준으로 샤드를 나눔

 

 

- 샤딩 적용시 고려할 점

 : 데이터 재분배 (Rebalancing)

 ㆍ서비스 정지 없이 Scale out이 가능한지 고려 (데이터베이스 서버의 갯수를 늘릴 수 있는지)

 

: 데이터 조인

 ㆍSharding DB간의 join이 불가능 하므로 역정규화를 감안하여 설계해야 함

 ㆍ대용량 처리에 있어 데이터 중복은 불가피

 

 : Partitioning 기법

 ㆍ어떤 식으로 데이터를 나눌지

 

 : Global Unique Key

 ㆍDB간 사용하는 키의 고유성을 고려해야 함

 

 : Compact Table

 ㆍ테이블의 단위를 가능한 작게 유지해야 함

 

 : 트랜잭션 문제

 ㆍGlobal Transaction을 이용하면 샤드DB간 트랜잭션 가능 (성능저하 우려)

 

 

=> 수평파티셔닝 : 샤딩

=> 수직파티셔닝 : 리플리케이션

 

 

 

 

샤딩의 전략

Vertical Partitioning (Sharding)

- 테이블 별로 서버를 분할하는 방식

 ex) 사용자 프로필 서버, 사용자 친구리스트용 서버, 사용자 컨텐츠용 서버 등.. 

 

- 장점

 : 구현이 간단함

 : 전체 시스템에 대한 큰 변화가 필요없음

 

- 단점

 : 각 서버의 데이터가 거대해지면 추가 적인 샤딩이 필요

  ex) 1000만명의 사진을 저장한다면 추가적인 컨텐츠 서버 확장 필요

 

 

 

 

Range Based Partitioning

- 하나의 테이블이 거대해지는 경우 서버를 분리하는 방식

 ex) 사용자가 많은 경우 지역정보를 기준으로 서버 분리

      연도별로 서버 분리

 

- 주의점

 : 데이터를 분할하는 방법이 예측가능해야 함

 

 

 

 

Key or Hash Based Partitioning

- Entity에 해시함수를 넣어 나오는 값으로 서버를 정하는 방식

 : 해시 값과 같은 키를 기준으로 서버 결정 

※ 해시함수

 => 임의의 데이터를 고정된 길이의 데이터로 매핑하는 함수

 => 해시 값, 해시 코드, 해시 체크섬 등의 데이터를 반환

 

- 주의 

 : 해시결과 데이터가 균둥하게 분포되도록 해시함수를 정하는 것이 중요

 

- 단점

 : 서버의 수를 늘릴 경우에 해시함수를 변경하는 작업에 높은 비용 필요

 

 

 

Diricetory Based Partitioning

- 데이터베이스와 별개로 추상화된 Lookup 테이블을 만들어 샤드 키에 해당하는 데이터를 찾는 방식

 

 

 

 

 

 

 

Refference

샤딩(Sharding)에 대해서

 

DataBase Sharding 전략

 

대용량 Data 처리를 위한 웹 서비스의 샤딩(Sharding) 기법