파티셔닝의 목표는 데이터및 쿼리 로드를 여러 시스템에 분산시켜 핫스팟을 방지하는 것이다.
이때, 핫스팟이란 쿼리 비용이 높은 노드를 말한다.
이렇게 여러 시스템에 분산시킬 때의 장점은 무엇일까?
- 확장성
- 데이터를 읽거나 쓸 때 단일 시스템이 처리할 수 있는 것보다 커지면 잠재적으로 여러 시스템에 로드를 분산시킬 수 있다.
- 내결함성/고가용성
- 하나의 시스템, 또는 여러시스템이 다운되더라도 어플리케이션이 계속 작동해야 하는 경우 여러 시스템을 사용해서 중복성을 제공할 수 있다. 하나가 실패하면 다른 하나가 대신 할 수 있다.
- 대기 시간
- 전 세계에 사용자가 있는 경우 지리적으로 가까운 데이터 센터에서 각 사용자에게 서비스를 제공할 수 있도록 전세계 여러 위치에 서버를 두고 싶을 수 있다. 이는 사용자가 네트워크 패킷이 지구 반대편을 이동할 때까지 기다려야 하는 것을 방지한다.
위와 같이 설정하려면 데이터에 적합한 파티션을 선택하고 노드가 클러스터에 추가되거나 클러스터에서 제거될 때 파티션을 재조정해야 한다. 데이터가 여러 노드에 분산되는 두가지 일반적인 방법이 있는데 이때 사용하는 것이 복제와 파티셔닝이다.
- 복제
- 다른 위치에 있는 여러 다른 노드에 동일한 데이터의 복사본을 유지한다. 복제는 중복성을 제공한다.
- 일부 노드를 사용할 수 없는 경우에도 나머지 노드에서 데이터를 계속 제공할 수 있다.
- 성능 향상에도 도움이 될 수 있다.
- 파티셔닝
- 큰 데이터베이스를 파티션이라는 작은 하위 집합으로 분할하여 다른 파티션을 다른 노드에 할당할 수 있다. 이를 샤딩이라고 한다.
복제
동기식 복제를 사용할 지 비동기식 복제를 사용할 지여부와 실패한 복제본을 처리하는 방법과 같이 복제와 관련해서 고려해야 할 많은 장단점이 있다. 이들은 종종 데이터 베이스의 구성 옵션이면서 세부사항은 데이터 베이스마다 다르지만 일반적인 원칙은 여러 구현에서 유사하다. 복제의 어려움은 복제된 데이터의 변경 사항을 처리하는데 있다.
단일 리더, 다중 리더 리더 없는 복제와 같이 노드 간에 변경사항을 복제하는 데 널리 사용되는 세가지 알고리즘이 있다.
Leader-based (master-slave) 복제
데이터베이스 복사본을 저장하는 각 노드를 복제본이라고 한다. 복제본이 여러 개인 경우모든 데이터가 모든 복제본에 저장되도록 하려면 어떻게 해야할까? 데이터 베이스에 대한 모든 쓰기는 리더 DB에서 처리되어야 한다. 그렇지 않으면 복제본에 동일한 데이터가 포함되지 않는다. 이에 대한 일반벅인 솔루션이 리더기반 복제로, active/passive 또는 master–slave 복제라고 한다.
이때 복제본 중 하나는 리더로 지정된다. 클라이언트가 데이터 베이스에 쓰기를 원할 때 리더에게 요청을 보내야 하며 리더는 먼저 새 로컬 스토리지에 쓰게된다. 다른 복제본은 팔로워라고 한다. 리더가 로컬 스토리지에 새 데이터를 쓸 때마다 데이터 변경사항을 복제 로그 또는 변경 스트림의 일부로 모든 팔로워에게 보낸다. 이때 각 팔로워는 리더에서 로그를 가져오고 그에 따라 리더에서 처리된 것과 동일한 순서로 모든 쓰기를 적용하여 데이터 베이스의 로컬 복사본을 업데이트한다.
상황에 따라 복제본의 수를 늘리거나 실패한 노드를 교체하기 위해 새로운 팔로워를 설정해야 한다.
이러한 복제모드는 MySQL, Oracle 와 같은 관계형 데이터 베이스의 기본 제공 기능이며, MongoDB 와 같은 일부 NoSQL 데이터 베이스에서도 사용된다. 리더 기반 복제는 데이터베이스 뿐만 아니라 Kafka 및 RabbitMQ와 같은 고가용성 대기열과 같은 분산 메세지 브로커로도 사용한다.
Multi-Leader 복제
리더 기반 복제에는 한 가지 큰 단점이 있다. 리더가 하나만 있고 모든 쓰기가 리더를 거쳐야 한다는 것이다. 어떤 이유로든 리더에 연결할 수 없는 경우(네트워크 중단과 같은 불가피한 상황) 데이터 베이스에 쓰기를 할 수 없다. 이를 보완해서 둘 이상의 노드가 쓸 수 있도록 하는 것을 다중리더 복제라고 한다. 여러가지 다른 데이터 센터에 복제본이 있는 데이터 베이스가 있을 때 일반벅인 리더 기반 복제 설정에서 리더는 데이터 센터 중 하나에 있어야 하며 모든 쓰기는 해당 데이터 센터를 거쳐야 한다. 다중 리더 구성에서는 각 데이터 센터에 리더가 있을 수 있다. 각 데이터 센터 내에서 정기적인 리더-팔로워의 복제가 사용되며, 데이터 센터간에 리더는 변경사항을 다른 데이터 센터의 리더에게 복제한다.
다중 리더 복제에는 장점도 있지만 큰 단점도 있다. 동일한 데이터가 서로 다른 두 데이터 센터에서 동시에 수정될 수 있으며 이러한 쓰기 충돌을 해결해야한다. 이러한 충돌을 장기하기 위해 아래와 같은 방법이 사용되고, 가장 일반적으로 사용하는 방법은 모든 리더가 다른 모든 리더에게 쓰기를 보내는 all-to-all 방식이다.
파티셔닝
데이터 복제는 기본적으로 서로 다른 노드에 동일한 데이터의 여러 복사본을 가지고 있다.
로컬로 제공되는 작은 데이터 세트에 유용하다. 반면 매우 큰 데이터 세트나 매우 높은 쿼리 처리량의 경우는 적합하지 않다.
이럴 때에는 데이터를 파티션으로 분할해야 한다. 일반적으로 파티션은 각 데이터 조각이 정확히 하나의 파티션에 속하는 방식으로 정의된다. 데이터를 분할 하려는 주된 이유는 확장성이다. 따라서 대규포 데이터는 여러 디스크에 분산될 수 있으며 쿼리도 여러 프로세서에 분산될 수 있다. 분할 데이터베이스는 NoSQL 데이터 베이스에 의해 재정의 되었는데, 여기서 파티션이라고 부르는 것은 MongoDB, Elasticsearch에서 샤드라고 한다.
그럼 데이터 베이스를 파티션 테이블로 만들때 어떤 방식이 있을까?
1. Hash Partitioning
- 데이터의 균등 분할을 통해 성능을 향상하고자 하는 경우에 효율적이다.
- 파티션 키에 해시 함수를 적용한 값이 같은 레코드를 같은 파티션 세그먼트에 저장해 두는 방식이다.
- 파티션 키의 해시 값에 의해 데이터가 다수의 파티션에 분배되며 균등한 분배를 위해서는 파티션의 개수를 명시하여 파티션의 수는 2의 거듭 제곱의 수로 지정한다.
https://www.itworld.co.kr/news/200134
https://www.linkedin.com/pulse/data-replication-partitioning-suraj-patil/
'Backend > DB' 카테고리의 다른 글
PostgreSQL,pgAdmin4 설치 및 실행 in Linux(Ubuntu) (0) | 2022.06.14 |
---|---|
[Mysql] mod 함수 사용법 (0) | 2021.07.21 |
[MySQL] User(사용자)생성, 권한 추가, 변경, 삭제 (0) | 2021.03.23 |
[oracle] table space 생성 (0) | 2021.02.04 |
[oracle] sqlplus line 넓게 보기 (0) | 2021.02.04 |