데이터중심 애플리케이션 설계 - 6장 [파티셔닝] 리뷰 - 1

 

5장 리뷰 작성을 미루다가 6장을 먼저 공부해버렸다. 이후에 5장도 마저 작성하도록한다...

 

6장 preview 

• 파티셔닝 방법
• 인덱스와 파티셔닝 간의 상호 작용
• 재균형화
• 데이터베이스가 올바른 파티션을 찾아 요청을 전달하고 질의를 실행하는 방법

 

파티셔닝

데이터 셋이 크거나, 질의 처리량이 매우 높은 경우 데이터를 작은 단위[파티션]으로 쪼개는 작업 (≒ 샤딩) 
ex)
- 샤드(MongoDB, Elasticsearch, Solr), 리전 (Hbase), 태블릿 (Bigtable)
- 브이노드 (Cassandra, Riak),  브이버켓 (Couchbase)

• 파티션은 보통 각 데이터 단위(record, row, document)가 하나의 파티션에 속함

 

물론 파티셔닝과 샤딩의 정확한 의미의 차이는 존재합니다. 
파티셔닝 : 하나의 DB 인스턴스 내에 여러 테이블로 나누어 저장하는 기법 
샤딩 : 여러 DB 인스턴스에 여러 데이터 서브셋으로 저장하는 기법 

 

 

 

파티셔닝의 목적

• 확장성 - 비공유 클러스터에서 다른 파티션은 다른 노드에 저장 가능 
• 부하 분산 (디스크 분산, 질의 처리량 부하 감소[여러 노드에서 병렬 실행 가능])
• 용도에 따른 차이(파티셔닝 지원 데이터베이스의 용도 2가지 - 트랜잭션 작업부하 or 분석)는 시스템 튜닝의 차이일뿐, 
  파티셔닝의 기본 원칙은 동일하게 적용

 

 

파티셔닝과 복제 

• 복제와 파티셔닝은 보통 함께 적용되어 각 파티션의 replica를 여러 노드에 저장 - 내결함성 보장 
• 이 때 primary 파티션(리더)는 하나의 노드에 할당된다. 
  

 

 

key-value 데이터 파티셔닝

• 부하 분산이 안되었을 때  = 쏠렸다(skew)라고 표현하며,  부하가 쏠린 파티션 = 핫스팟
• 핫스팟을 회피하는 가장 단순한 방법 : 할당 노드를 무작위 선택 
  • 장점 : 데이터 고르게 분산
  • 단점 : 어느 노드에 해당 데이터가 저장되어있는 지 trace hard (모든 노드에 병렬 질의)

이어서 책에서는 더 나은 파티셔닝 방법에 대해 소개한다. 

 

 

 

키 범위 기준 파티셔닝

• 각 파티션에 연속된 범위(temp_min ~ temp_max) 의 키를 할당
• 각 범위들의 경계값을 통해 어떠한 key가 어느 파티션에 속하는 지 알 수 있음 
  
  • 이를 통해 어떤 파티션이 어느 노드에 있는 지만 알면 적절한 질의 가능 
• 키 범위 크기는 반드시 동일할 필요 X ( ∵ 데이터가 고르게 분포하지 않을 수 있음)
  • 키의 범위는 수동 / 자동 선택 가능 

ex) Bigtable, HBase, RethinkDB, MongoDB(<2.4)

 

 

 

key의 hash 값 기준 파티셔닝 

앞서 설명한 쏠림현상과 핫스팟의 위험 때문에 많은 분산 데이터스토어는 해시 함수 사용

• 좋은 해시함수 : 유사한 데이터가 들어와도 균일 분산
• 프로그래밍 언어의 내장 해시 함수는 파티셔닝에 적합하지 않을 수도 (ex. Java의 Object.hashCode())

파티셔닝용 해시 함수는 암호적으로 강할 필요 X 

ex) 카산드라, MongoDB - MD5 / 볼드모트 - Fowler-Noll-Vo 함수 

장점 :

• 키를 파티션 사이에 균일하게 분산시키기 좋음 
• 파티션 경계는 크기가 동일하도록 나누기 가능 / 무작위에 가깝게 선택 가능 
• 이런 기법을 일관성 해싱이라 칭하기도 함 

단점 : 

• 범위 질의 효율성 ↓
• 정렬 순서 유지 x

ex)

• Riak, Couchbase, Voldmort (기본 키에 대한 범위 질의가 지원 X)
• MongoDB - 해시기반샤딩모드 : 범위 질의가 모든 파티션에 전송 
• Cassandra : 해시값 + 범위 기준 파티셔닝 전략 타협안 사용 (복합 기본키 지정)
  • 키의 첫 부분 해싱 : 파티션 지정 
  • 남은 칼럼 SS Table에서 데이터 정렬하는 연쇄된 색인으로 사용 (연쇄 색인을 통한 일대다 관계 표현 good) 
    • ex) (user_id, update_timestamp) : 특정 사용자가 특정 시간 구간에서 수정한 문서를 정렬하여 읽어오기 가능 

 

 

 

쏠림 및 핫스팟 완화 

앞서 설명한 것처럼 키 해싱을 통해 파티션 지정시, 핫스팟을 줄일 수 있지만, 완벽히 제거는 불가

• ex) 특정 key request 쏠림현상 

현대 데이터 시스템은 쏠림 현상에 대한 자동 보정이 어렵다 

따라서 대부분 어플리케이션 level 에서 완화

 

 

책에서 소개되는 어플리케이션 레벨에서의 쏠림 키 완화 방법 

요청이 많은 키에 대해서는 key의 시작 or 끝에 임의의 숫자를 붙인다. 
ex_ 임의의 10진수 두 개를 붙일 떄 : 키에 대한 쓰기 작업이 100개의 다른 키로 균등하게 분산, 그 키들은 다른 파티션으로 분산 

but 트레이드오프로 다른 키에 쪼개서 쓰면 읽기 실행시, 추가적인 작업 필요
- 100 개 키에 해당하는 데이터를 읽어서 조합 
- 추가적으로 저장해야할 메타데이터 발생 

또한 쓰기 처리량이 낮은 키에 적용시, 불필요한 오버헤드가 발생. 따라서 어떤 키가 쪼개졌는지 trace 할 방법도 있어야함