matteblack9
commented
2 years ago - 자사의 데이터베이스의 분산 정책에 관한 글이 이해하는 데 도움이 많이 되요. 링크
- (p210) 파티션을 노드 대수보다 많이 만들고 각 노드에 여러 파티션을 할당할때, 새로운 노드 추가 -> 값 입력받음 -> 노드 장애 의 상황에서 갱신/추가된 데이터들의 복구 정책들이 궁금합니다.
Open hyeriful opened 2 years ago
matteblack9
commented
2 years ago
6장 파티셔닝
데이터셋이 매우 크거나 질의 처리량이 매우 높다면 복제만으로는 부족하다. 데이터를 파티션으로 쪼갤 필요가 있고, 이 작업을 샤딩이라고도 한다.
왜 데이터 파티셔닝을 원하는가? ➡︎ 확장성
각 데이터 단위 (e.g. 레코드, 로우, 문서)가 하나의 파티션에 속하도록 한다.
파티셔닝과 복제
복제 + 파티셔닝 -> 각 파티션의 복사본을 여러 노드에 저장 일반적으로 파티셔닝 방식과 복제 방식은 독립적으로 선택한다.
파티셔닝의 목적: 데이터와 질의 부하를 노드 사이에 고르게 분산시키는 것
자 이제 뭘 살펴볼꺼냐면,
key-value 데이터 파티셔닝
기본키를 통해 레코드에 접근
"어떤 레코드를 어느 노드에 저장할꺼야?"
1. 키 범위 기준 파티셔닝
데이터가 고르게 분포하지 않을 수도 있기 때문에, 키 범위 크기가 반드시 동일할 필요는 없다. * 파티션 경계 - 수동(관리자) vs. 자동(DB) ---> rebalancing에서 !
키를 정렬된 순서로 저장할 수 있다. -> SS테이블 LSM트리 (2장)
단점: 특정한 접근 패턴이 핫스팟을 유발할 수 있다. 책에 나온 예시. 타임스탬프 (년-월-일-시-분-초)
2. 키의 해시값 기준 파티셔닝
각 파티션에 (키 범위 대신) 해시값 범위를 할당.
-> 해시와 범위, 두 파티셔닝 젼략 사이에서 타협 e.g. 카산드라 복합 기본키 지정 후, 키의 첫 부분에만 해싱을 적용해 파티션 결정에 사용하고 남은 칼럼은 카산드라의 SS테이블에서 데이터를 정렬하는 연쇄된 색인으로 사용한다.
skewed한 작업부하와 핫스팟 완화
현대 데이터 시스템은 크게 쏠린 작업부하를 자동으로 보정하지는 못한다. 애플리케이션에서 쏠림을 완화해야 한다. 요청이 몰리는 소수의 키에 적절한 방법 사용. trade-off 따지기.
결론: 아직까진 핫스팟 자동해소 불가능. 완전한 해소도 불가능.
파티셔닝과 보조 색인
Local index (문서 기준 보조 색인 파티셔닝)
각 파티션이 완전히 독립적으로 동작한다. 각 파티션은 자신의 보조 색인을 유지하며 그 파티션에 속하는 문서만 담당한다.
Global index (용어 기준 보조 색인 파티셔닝)
global index - 모든 파티션의 데이터를 담당 하지만, 그렇다고 해서 한 노드에만 색인을 저장할 수는 없다. global index도 파티셔닝 해야 한다.
여기서도 마찬가지로 index을 파티셔닝할 때, 용어 자체를 쓸 수도 있고 용어의 해시값을 사용할 수도 있다.
파티션 rebalancing
rabalancing: 클러스터에서 한 노드가 담당하던 부하를 다른 노드로 옮기는 과정
보통 '해시 파티셔닝' 이거 사용 (해시 파티셔닝은 부하분산이 그래도 균일하므로) 처음에 적절한 파티션 개수를 정하는게 어렵다. (미래 일은 아무도 몰라~~)
동적 파티셔닝 '키 범위 파티셔닝'을 이용하는 DB에서는 특히 파티션을 동적으로 만든다. (해시 파티셔닝도 사용가능)
노드 비례 파티셔닝 노드당 할당되는 파티션 개수를 고정
※ 쓰면 안되는 방법: mod 연산 ※ mod N 에서 N값이 변경되면 대부분의 키가 노드 사이에 옮겨져야 한다. -> 데이터를 필요 이상으로 이동하게 된다.
요청 라우팅
모든 경우에 핵심 문제는! 노드에 할당된 파티션의 변경 사항을 어떻게 아느냐 !! ➡︎ 주키퍼(zookeeper) 같은 별도의 코디네이션 서비스를 사용한다.