샤딩이란?
- 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법을 의미합니다.
- Application level에서도 가능하지만 database level에서도 가능합니다.
- Horizontal Partitioning이라고도 합니다.
샤딩을 적용한다는 것은?
- 프로그래밍, 운영적인 복잡도는 더 높아지는 단점이 있습니다.
- 가능하면 샤딩을 피하거나 지연시킬 수 있는 방법을 찾는 것이 우선되어야 합니다.
- Scale-in
- 하드웨어 스펙이 더 좋은 컴퓨터를 사용합니다.
- Read 부하가 크다면?
- 캐시나 데이터베이스의 Replication을 적용하는 것도 하나의 방법이 됩니다.
- Table의 일부 컬럼만 자주 사용한다면?
- Vertically Partition도 하나의 방법입니다.
- Datafmf Hot, Warm, Cold Data로 분리하는 것이다.
샤딩에 필요한 원리
- 분산된 데이터베이스에서 데이터를 어떻게 READ 할 것인가?
- 분산된 데이터베이스에 데이터를 어떻게 잘 분산시켜 저장할 것인가?
- 분산이 잘 되지 않고, 한쪽으로 Data가 몰리게 되면 자연스럽게 Hotspot이 되어 성능이 느려지게 됩니다.
- 그렇기 때문에 균일하게 분산하는 것이 중요한 목표입니다.
샤딩 방법에 대해
- Shart key를 어떻게 정의하느냐에 따라 데이터를 효율적으로 분산시키는 것이 결정됩니다.
[Hash Sharding]
- Shard Key - 데이터베이스 아이디를 해싱하여 결정한다.
- 해시 크기는 클러스터 안에 있는 Node 개수로 정하게 된다.
- 아주 간단한 방법
- 해시 샤딩의 단점은?
- 클러스터가 포함하는 Node 개수를 늘려보거나 줄여보면 해시 크기가 변하게 되고 해시 키가 변하게 된다. 그러면 기존에 있던 해시 키에 따라 분배된 데이터 규칙이 다 어긋나게 되면서 결국 다시 샤딩작업을 해야합니다.
- 짝수번째 노드에 큰 크기의 데이터만 들어간다고 가정한다면 해시 키로 분산되기 때문에 공간에 대한 효율은 고려하지 않는다.
[Dynamic Sharding]
- 네이밍을 그대로 다이나믹으로 바꿀 수 있다.
- Locator Service를 통해 Shard key를 얻습니다.
- 클러스터가 포함하는 노드의 개수를 늘려본다면?
- Locator Service에 Shard Key를 추가하기만 하면 된다.
- 기존의 데이터의 Shard Key는 변경이 없다.
- 확장에 유연한 구조이다.
- Example
- HDFS : Name Node
- MongoDB : ConfigServer
- 다이나믹 샤딩의 단점은?
- Data를 Relocation 하게 된다면 Locator Service의 Shard Key Table도 일치시켜줘야 한다.
- Locator가 성능을 위해 캐시하거나 Replication을 한다면? 잘못된 라우팅을 통해 데이터를 찾지 못하고 에러가 발생한다. Locator에 의존할 수 밖에 없는 단점이 있습니다.
[Entity Group]
- 해시 샤딩과 다이나믹 샤딩은 키 벨류 형태를 지원하기 위해 나온 방법입니다.
- Key - value가 아닌 다양한 객체들로 구성된다면?
- 우리는 RDBMS의 Json, Index Tracsaction을 사용함으로써 Application의 복잡도를 줄이는 효과를 얻었다. 이와 유사한 방법으로 샤딩하는 방법이 엔티티 그룹이다.
- 장점은?
- 하나의 물리적인 Shard에 쿼리를 진행한다면 효율적입니다.
- 하나의 Shard에서 강한 응집도를 가질 수 있습니다.
- 데이터는 자연스럽게 사용자별로 분리되어 저장됩니다.
- 사용자가 늘어남에 따라 확장성이 좋은 Partitioning이다.
- 단점은
- cross-partition 쿼리는 Single partition 쿼리보다 consistency의 보장과 성능을 잃습니다.
- 그렇기 때문에 이런 쿼리들이 자주 실행되지 않도록 만들어야 한다.
