06장: 파티셔닝

[minkukjo]

스으윽

• 훑어봄
• NoSQL을 메인 저장소로 팀에서 사용하고 있는 케이스가 없다보니, 다소 파티셔닝에 대해서 무지한 편
• 파티셔닝과 샤딩에 대해서 언급하는데, 정확한 의미 구분을 위해 다시 정리

파티셔닝과 샤딩의 차이

파티셔닝

• 대규모 데이터베이스를 하위 집합으로 분리해내는 기술
• 하위 데이터 집합들은 전체 데이터 집합과 함께 저장된다. ( 하나의 저장소 안에서 작은 집합으로 구성되어지고, 분산되어 저장되지는 않음 )

샤딩

• 큰 데이터베이스에서 작고 관리할 수 있는 하위 집합으로 분리해내는 기술
• 분리된 하위 집합은 샤딩이라고 불리며, 데이터들은 클러스터 내에서 다른 서버로 분산되어 저장되어짐

출처 : https://www.baeldung.com/cs/database-sharding-vs-partitioning

데이터 파티셔닝의 이점과 문제점

• 파티셔닝은 이론상 데이터가 균등하게 분배되면 N대의 노드만큼의 읽기/쓰기 성능의 향상을 가져올 수 있다.
• 다만 파티셔닝이 고르게 이루어지지 않을 경우, skewed(쏠림) 현상이 발생할 수 있으며 이 때 파티셔닝 성능은 매우 떨어진다.
• 하나의 노드에 극단적으로 요청이 몰리게 될 경우 이를 핫스팟현상이라고 부른다.
• 핫스팍 문제를 해결하기 위한 가장 쉬운 해결책은, 저장될 노드를 무작위로 선택하게 하는 것이다.
  • 문제는 그렇게 할 경우, 매 번 특정 데이터를 찾기 위해서 모든 노드에 병렬로 질의를 날려 찾아오는 것이 필요하다. 왜? 어떤 데이터가 어떤 노드에 저장되어있는지 알 수 없으니까.
• 더 나은 방법으로는 키-값 데이터 모델을 사용한다면, 키를 정렬해서 원하는 항목을 빨리 찾을 수 있을 것이다.

키 범위 기준 파티셔닝

• 각 파티션에 연속된 범위로 저장하게 하면 좋지 않을까?
• 물론 이렇게 하더라도 핫스팟 문제는 발생할 수 있다. 특정 키로 데이터가 쏠릴 수 있으니까
• 이 때는 파티션 경계를 관리자가 수동으로 선택하게 하거나 DB가 자동으로 선택하게 할 수 있다.
• 키 범위 기준 파티셔닝은 키를 정렬된 순서로 저장되게 할 수 있으므로, 범위 스캔이 쉬워지고 키를 연쇄된 색인으로 간주해서 질의 하나로 레코드를 여러 개 읽어오는 것도 가능함
• 그러나 키 범위는 여전히 핫스팟을 유발한다는 문제가 있다.

키의 해시값 기준 파티셔닝

• 그러면 키의 파티션을 정할 때 해시를 써보자!
• 해시는 암호적으로 강력한걸 쓸 필요는 없고, 균등하게 분배만 시키면 된다.
• 키 해시값 파티셔닝의 문제는, 키 범위 파티셔닝에서 제공해주던 범위 질의를 할 수 없다는 문제가 있다. ( 해시의 고질적 문제다 )
• 인접한 키들이 이제는 흩어져서 정렬이 안되며, 몽고 DB에서 해시 기반 샤딩 모드를 활성화하면 범위 질의는 모든 파티션에서 수용되기 때문에 비효율적이다. ( 그래서 다른 Key-Value DB들은 아예 범위 연산 자체를 지원해주지 않는다고 함 )
• 카산드라는 키 - 범위와 키- 해시를 적절하게 조합했는데, 키의 첫 부분에만 해싱을 적용해서 파티셔닝 하고, 남은 컬럼은 SS 테이블에서 연쇄된 색인을 사용하는 복합 기본키를 사용한다.
• 첫 번째 컬럼에는 범위 질의가 안되지만, 첫 번째 컬럼에만 값을 지정하면 다른 컬럼에 범위 스캔을 사용할 수 있다는 장점이 있음
• 여담이지만, 카산드라가 이렇게 똑똑하게 동작하는데 대체 얘는 뭐길래 https://www.scylladb.com/ 좋은 걸까?

핫스팟 완화

• 일반적으로 키 쏠림 현상은, 키 앞 뒤에 10진수 두 개만 붙이더라도 쓰기 작업이 100개의 다른 키로 균등하게 분산될 수 있다.
• 다만 그렇게 될 경우, 읽기를 할 때 모든 키들을 다 가져와서 조합해야하기 때문에 이 역시도 부하가 있다.

보조색인

• 보조색인은 관계형 DB에서도 핵심 요소인데, 문서 DB에서도 흔하게 사용된다.
• 솔라나 엘라스틱 서치같은 검색 서버는 보조 색인이 사실상 그 자체이다. ( Inverted Index... )

문서 기준 보조 색인

• ID 기준으로 하는 보조색인
• 예를 들어 각 파티션마다 "color.red"라는 컬럼에 해당하는 문서 ID를 다 저장하고, 빨간색 차에 대한 질의가 들어오면 해당 색인으로 찾아서 반환하는 방식

용어 기준 보조 색인

• 문서 기준 보조색인과 다르게 "용어"를 기준으로 색인하는 방식이다.
• 예를 들어, color:red에 해당하는 모든 데이터를 특정 파티션에 몰아버리는 방식이다.
• 즉, 파티셔닝 할 때 특정 보조색인을 기준으로 파티셔닝 해버린다.
• 이렇게 하면 색인은 항상 최신이오, 파티션 하나만 보면 되기 때문에 편리하다.
• 다만, 전역 색인은 쓰기가 느리고 복잡하다. 단일 문서를 쓸 때 마다 항상 색인의 여러 파티션의 영향을 줄 수 있기 때문! ( 특정 문서에 있는 모든 용어가 다른 노드에 있는 다른 파티션에 속할 수도 있기 때문 )

파티션 재균형화

• 파티션을 노드에 할당하는 방법이 몇 가지 있다.
• 해시에 모드 N 연산을 사용하는 방법이 있는데, 이 방법은 좋지 않다.
  • Why? 노드가 10대일 때 노드 개수가 바뀌게 되면 키가 노드 사이에 옮겨다니면서 바뀌어야한다.
  • 키가 자주 이동하면 재균형화 비용이 증가한다.

• 파티션 개수 고정을 하자

  • 파티션을 노드 대수보다 많게 하고, 각 노드에 여러 파티션을 할당해버리는 방법이 있다.
  • 클러스터에 노드가 추가되면 기존 노드의 파티션을 몇 개 뺏어서 새로운 노드에 주는 방식으로 하면 된다.
  • 클러스터에서 노드가 제거될 경우에도 비슷한 방식을 사용해볼 수 있다.
  • 이런 식의 재균형화는 ES에서 주로 사용한다.
  • 알잘딱한 파티션 크기를 구하는 것이 중요하지만, 이를 찾는 것은 어렵다.

• 동적으로 파티셔닝을 해볼까?

  • HBase나 리싱크DB는 키 범위 파티셔닝을 사용할 때 파티셔닝을 DB가 동적으로 만든다.

• 노드 비례 파티셔닝은 어때?

  • 카산드라나 케타마는 파티션 개수가 노드 대수에 비례하게 하는 것이다. 즉, 노드당 할당하는 파티션 개수를 고정하는 방식이다.
  • 파티션 경계를 무작위로 선택하게 하려면 해시 기반 파티셔닝을 써야한다.

운영 관점에서 자동 재균형 VS 수동 재균형

• 가급적이면 손이 더 가더라도, 수동으로 하는 편이 좋다.
• 대부분 DB에서도 자동을 하더라도 관리자의 승인을 필요로 한다.

요청 라우팅

• 요청 라우팅을 위한 세 가지 방식을 위에서 소개하고 있다.
• 개인적으론 두 번째 방법이 제일 무난해보인다.

• 다만 주키퍼와 같은 코디네이션 서비스는 2번 + 별도의 코디네이터를 두고 항상 최신화된 정보를 라우터에 전달해주는 방식을 사용한다.

병렬 질의 실행

• 자세한 병렬 질의 실행은 10장에서 알아본다고 함.

[MinJunKweon]

정리

정리

- 파티셔닝(샤딩) : 데이터 셋 크기가 큰 경우 데이터를 파티션 단위로 나눔 - 하나의 논리적인 테이블을 물리적으로 데이터를 나누어서 저장 ## 파티셔닝을 하는 이유 - 확장성 - 대용량 데이터셋이 여러 디스크에 분산될 수 있고 질의 부하를 여러 프로세서 분산 - 크고 복작한 질의는 훨씬 더 어렵기는 하지만 여러 노드에서 병렬 실행이 가능 - 이력 데이터 효율적인 관리 - 불필요한 데이터 삭제 작업은 단순히 파티션을 추가하거나 삭제하는 방식으로 간단하고 빠르게 해결 가능 - ex) 로그 데이터 - 단기간에 대량으로 누적되며 일정 기간이 지나면 쓸모가 없어지는 데이터이며 삭제하며 백업할 때 고부하 작업 ## 키-값 파티셔닝 - skewed : 파티셔닝이 고르게 이뤄지지 않아서 한쪽 파티션에 데이터가 몰려서 질의를 많이 받는 파티션이 존재하는 경우 - hotspot : 불균형하게 부하가 높은 파티션을 지칭하는 용어 ### 키 범위 기준 파티셔닝 - 파티션에 연속된 범위의 키를 할당하는 것 - 장점 - 파티션 내 키를 정렬된 순서로 저장할 수 있음 (범위 스캔 용이) - 단점 - 특정한 접근 패턴이 핫스팟을 유발할 수 있음 ### 키 해시값 기준 파티셔닝 - 특정 해시 함수 결과를 가지고 파티션을 선택하는 것 - 복잡한 해시함수를 사용할 필요가 없어서 MD5 같은 해시함수를 써도 무방함 - 장점 - 쏠림과 핫스팟의 위험을 줄여 쏠린 데이터를 입력으로 받아 균일하게 분산 - 단점 - 범위 질의를 효율적으로 실행할 수 있는 키 범위 파티셔닝의 좋은 속성을 잃음 - 모든 파티션에 흩어지기 때문에 정렬 순서가 유지되지 않음 - 몇몇 DBMS는 범위질의를 지원하지 않음 - ❗카산드라 DB - 복합 키를 해시값 기준 파티셔닝을 사용할 때, 첫번째 키만 해싱하기 때문에 첫번째 키가 고정되어 있는 질의는 나머지 컬럼은 범위 스캔을 사용할 수 있음 ### 쏠린 작업부하와 핫스팟 완화 - 핫스팟 이슈를 100% 예방할 수는 없음 (극단적인 상황이 발생할 수 있기 때문에) - 유명인 문제(Celebrity Problem) - 유명인을 팔로우하고있는 사용자 모두에게 데이터 변경이 일어나야해서 핫스팟이 생길 수 있음 - 해결책 - 각 키의 시작이나 끝에 임의 숫자를 붙임 ⇒ 임의 숫자로 인해 키가 균등하게 배분될 수 있음 - 그러나 다른 키에 쪼개서 쓰면 읽기를 실행할 때 추가작업이 필요해짐 - 추가적으로 저장해야하는 정보가 생김 - 쓰기 요청이 자주 일어나는 소수의 키에만 적용하는 것이 타당함 ## 보조색인 - 보조 색인은 파티션에 깔끔하게 대응되지 않음 ### 문서 기준 보조 색인 파티셔닝 - 각 파티션에 속하는 문서만 담당하여 독립적으로 동작하는 색인 방법 ⇒ Local Index - DB에 문서 추가, 삭제, 갱신 등 쓰기 작업을 할 때, 문서 ID를 포함하는 파티션만 다루면 됨 ### 용어 기준 보조 색인 파티셔닝 - 모든 파티션의 데이터를 담당하는 색인 방법 ⇒ Global Index - 특정 노드에 병목이 발생할 수 있어서 인덱스를 여러 노드에 나누어서 저장함 - 찾으려는 용어에 따라 인덱스가 있는 파티션을 결정하므로 term-partitioned 라고함 - 특이사항 - 색인을 파티셔닝할 때 용어 자체를 쓸 수도 있고 용어의 해시값을 쓸 수 있다 - 용어 자체로 파티셔닝하면 범위 스캔에 유용한 반면 용어의 해시값을 사용해 파티셔닝하면 부하가 좀 더 고르게 분산됨 - 장점 - 문서 파티셔닝 색인에 비해 읽기가 효율적이다 - 클라이언트는 모든 파티션에 scatter/gather를 실행할 필요 없이 원하는 용어를 포함하는 파티션으로만 요청을 보내면 됨 - 단점 - 단일 문서를 쓸 때 해당 색인의 여러 파티션에 영향을 줄 수 있으며 쓰기가 느리고 복잡함 ### Local Index vs Global Index - 특정 파티션에 추가 삭제를 많이 하기 때문에 작업 대상 파티션의 인덱스만 영향을 받는 로컬 인덱스를 많이 사용함 - 글로벌 인덱스는 파티션에 해당하는 작업을 하는 경우 전체적으로 다시 재조정 작업을 해줘야해서 부하가 많아짐 ## 파티션 리밸런싱 - 상황 : 물리 장비에 대한 변화 발생 - CPU, RAM, Disk 추가 - 새로운 노드 추가 등 - 클러스터에서 한 노드가 담당하던 부하를 다른 노드로 옮기는 과정 - 리밸런싱 요구사항 - 부하 균등 - 순단 X - 데이터 이동 최소화 ### 해시값에 mod N(노드 개수) 연산 - 단점 - 노드 개수 N이 바뀌면 대부분의 키가 노드 사이에 옮겨져야함 ⇒ 리밸런싱 비용 상승 ### 정적 파티셔닝 (파티션 개수 고정) - 전체 데이터셋 크기 변동이 심하다면 적절한 파티션 개수를 정하기 어려움 - 파티션이 너무 커지면 리밸런싱 및 장애 복구 비용이 큼 - 적절한 크기를 정하는 것이 제일 좋지만 어려움 ### 동적 파티셔닝 - 파티션 개수가 전체 데이터 용량에 맞춰 조정됨 - 빈 데이터베이스의 경우 파티션 경계 설정 값에 도달하기 전에는 파티션이 1개임

[LOG-INFO]

끄적끄적

• 데이터 작업을 고르게 분포하는게 중요 (쓰는 작업이든, 읽는 작업이든)
• 분산 DB로 가면 전역 보조 색인을 많이 사용하게 될 듯
• p.210. 쓰면 안 되는 방법: 해시값에 모드 N 연산을 실행 딱 면접에 나오기 좋은 질문이다
• p.210. 파티션을 노드 대수보다 많이 만들고 각 노드에 여러 파티션을 할당하는 것은 Kafka topic의 partition을 이렇게 많이 쓰는 듯.
• p.213. 카산드라 3.0에는 불균등한 분할을 회피할 수 있는 대안적인 재균형화 알고리즘이 추가됐다
  • DB에서 cronjob으로 계속 메트릭을 수집해서 자동으로 리밸런싱하도록 하면 좋을 듯. 물론 성능문제나 일관성 깨지는 문제 뒤따르겠지만..
  • 이라는 생각을 하자마자 바로 다음에 완전 자동 재균형화 얘기가 나옴...
  • 실제로 수동으로 리밸런싱 한 경험이 있음
• p.215. service discovery 방법 중 1번 방법은(아무데나 보내고 다른 노드로 리다이렉트) redis에서도 쓰이는 듯?
  • redis에서 특정 노드에 접속해서 get {key} 하면 그 키가 있는 node의 IP주소를 알려줌

[2rohyun]

파티셔닝과 복제

• 각 레코드는 정확히 한 파티션에 속하더라도 이를 여러 다른 노드에 저장해서 내결함성을 보장할 수 있다는 의미다.

키-값 데이터 파티셔닝

• 불균형하게 부하가 높은 파티션을 핫스팟이라고 한다.
• 핫스팟을 회피하는 가장 단순한 방법은 할당할 노드를 무작위로 선택. 단점은, 어떤 레코드를 읽으려고 할 때 해당 레코드가 어느 노드에 저장됐는지 알 수 없으므로 모든 노드에서 병렬적으로 질의를 실행해야 한다.

키 범위 기준 파티셔닝

• 데이터를 고르게 분산시키려면 파티션 경계를 데이터에 맞춰 조정해야 한다.
• Hbase, RethinkDB, 2.4 버전 이전의 몽고DB
• 특정 접근 패턴이 핫스팟 유발, 타임스탬프가 키라면 파티션은 시간 범위에 대응

키의 해시값 기준 파티셔닝

• 자바의 Object.hashcode(), 루비의 Object#hash 는 같은 키를 넣어도 다른 프로세스에서는 다른 해시값을 반환할 수 있다.
• 키에 적합한 해시 함수를 구했다면 각 파티션에 키 범위 대신 해시값 범위를 할당하고 해시값이 파티션의 범위에 속하는 모든 키를 그 파티션에 할당하면 된다.
• 유감스럽게도 파티셔닝에 키의 해시값을 사용해서 파티셔닝하면 키 범위 파티셔닝의 좋은 속성을 잃어버린다. 바로 범위 질의를 효율적으로 실행할 수 있는 능력이다. 전에는 인접했던 키들이 이제는 모든 파티션에 흩어져서 정렬 순서가 유지되지 않는다.
• 몽고DB 에서는 해시 기반 샤딩 모드를 활성화하면 범위 질의가 모든 파티션에 전송되어야 한다.

쏠린 작업부하와 핫스팟 완화

---

파티셔닝과 보조 색인

• 보조색인은 솔라나 엘라스틱서치 같은 검색 서버에게는 존재의 이유다.

문서 기준 보조 색인 파티셔닝

• 파티션에 속하는 문서만 담당, 다른 파티션에 어떤 데이터가 저장되는지는 신경 쓰지 않는다. (지역 색인)
• 단점은 모든 파티션으로 질의를 보내서 얻은 결과를 모두 모아야 한다. (스캐터/개더)

용어 기준 보조 색인 파티셔닝

• 문서 파티셔닝 색인에 비해 전역 색인이 갖는 이점은 읽기가 효율적이라는 것이다. 그렇지만 전역 색인은 쓰기가 느리고 복잡하다. 단일 문서를 쓸 때 해당 색인의 여러 파티션에 영향을 줄 수 있기 때문이다.

  파티션 재균형화

• 리밸런싱 후, 부하가 클러스터 내에 있는 노드들 사이에 균등하게 분배
• 리밸런싱 도중에도 데이터베이스는 읽기 쓰기 요청을 받아들여야 한다.
• 리밸런싱이 빨리 실행되고 네트워크와 디스크 I/O 부하를 최소화할 수 있도록 노드들 사이에 데이터가 필요 이상으로 옮겨져서는 안된다.

리밸런싱 전략

• 쓰면 안되는 방법 : 해시값에 mod N 연산
  • 노드 갯수 N 이 바뀌면 대부분의 키가 노드 사이에 옮겨져야 하는 치명적 단점
• 파티션 개수 고정
  • 파티션을 노드 대수보다 많이 만들고 각 노드에 여러 파티션을 할당하는 것이다.
  • 파티션은 노드 사이에서 통째로 이동하기만 한다. 파티션 개수는 바뀌지 않고 파티션에 할당된 키도 변경되지 않는다. 유일한 변화는 노드에 어떤 파티션이 할당되는가 뿐이다.
  • 처음 설정된 파티션 개수가 사용 가능한 노드 대수의 최대치가 되므로 미래에 증가될 것을 수용하기에 충분히 높은 값으로 선택해야 한다. 그러나 개별 파티션도 관리 오버헤드가 있으므로 너무 큰 수를 선택하면 역효과를 낳을 수 있다.
• 동적 파티셔닝
  • 파티션 크기가 설정된 값을 넘어서면 파티션을 두 개로 쪼개 각각에 원래 파티션을 절반 정도의 데이터가 포함되게 한다.
• 노드 비례 파티셔닝
  • 동적 파티셔닝에서는 파티션 분할과 병합을 통해 개별 파티션 크기가 어떤 고정된 최솟값과 최댓값 사이에 유지되게 하므로 파티션 갯수가 데이터셋 크기에 비례한다. 반면 파티션 개수를 고정하면 개별 파티션의 크기가 데이터셋 크기에 비례한다. 두 경우 모두 모두 파티션 개수는 노드 대수와 독립적이다.
  • 노드당 할당되는 파티션 개수를 고정한다. 이 경우 노드 대수가 변함 없는 동안은 개별 파티션 크기가 데이터셋 크기에 비례해서 증가하지만 노드 대수를 늘리면 파티션 크기는 다시 작아진다.

• 운영 : 자동 리밸런싱과 수동 리밸련싱

  요청 라우팅

  1. 클라이언트가 아무 노드나 접속, 적용할 파티션 있다면 직접 처리, 없다면 올바른 노드로 전달해서 응답을 받고 클라이언트에게 응답을 전달
  2. 클라이언트의 모든 요청을 라우팅 계층으로 보낸다.
  3. 클라이언트가 파티셔닝 방법과 파티션이 어떤 노드에 할당됐는지를 알고 있게 한다.
• 많은 분산 데이터 시스템은 주키퍼와 같은 별도 코디네이션 서비스를 사용한다. 각 노드는 주키퍼에 자신을 등록하고 주키퍼는 파티션과 노드 사이에 신뢰성 있는 할당 정보를 관리한다. 라우팅 계층이나 파티션 인지 클라이언트 같은 다른 구성요소들은 주키퍼에 있는 정보를 구독할 수 있다. 파티션 소유자가 바뀌든지, 노드가 추가되거나삭제되면 주키퍼는 라우팅 계층에 이를알려서 라우팅 정보를 최신으로 유지할 수 있게 한다.
• 몽고DB 도 자체적인 컨피그 서버 구현에 의존하고 몽고스 데몬을 라우팅 계층으로 사용한다.