[DB] Sharding

1.Sharding?

 → 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스에 분산하여 저장하는 방법

 *Horizontal Partition이라고 볼 수 있으며, Application level 및 database level에서도 가능하다. 

 *프로그래밍, 운영적인 복잡도가 높아진다는 단점이 있다.

 

2.Sharding에 필요한 원리

 - 분산된 Database에서 Data를 어떻게 Read할 것인가?

 - 분산된 Database에 Data를 어떻게 잘 분산되어 저장할 것인가 - 균일하게 분산하는 것이 목표

 

3. Sharding 방법

Hash Sharding

 - Shard Key : Database id를 Hashing하여 결정

 - Hash크기는 Cluster안에 있는 Node개수로 정한다.

단점 

 - Cluster가 포함하는 Node개수에 변화가있을 때, Hash크기, Hash Key가 변해 ReSharding이 필요하다.

 - Hash Key로 분산되기 때문에 공간에 대한 효율을 고려하지 않는다.

 

Dynamic Sharding

 - Locator Service를 통해 Shard Key를 얻는다.

 - Cluster가 포함하는 Node개수가 늘어나는 경우 Locator Service에 Shard Key만 추가하면 된다.

*확장에 유연하다.

단점

 - Data Relocation시 Locator Service의 Shard Key Table도 일치시켜줘야 한다.

 - Locator가 성능을 위해 Cache하거나 Replication시 잘못된 Routing을 통해 Data를 찾지 못하고 Error가 발생한다.

*Location에 의존할 수 밖에 없다.

 

Entity Group

→ Entity 데이터 오브젝트는 virtual member manager 엔티티를 표시한다.

 - 하나의 물리적인 Shard에 쿼리를 진행시 효율적이다.

 - 하나의 Shard에서 강한 응잡도를 가질 수 있다.

 - 데이터는 자연스럽게 사용자별로 분리되어 저장됩니다.

 - 사용자가 늘어남에 따라 확장성이 좋다.

단점

 - cross-partition쿼리는 single partition쿼리보다 consistency의 보장과 성능을 잃는다.

 

4.Pitfall?

 - Dynamic Sharding을 진행한다면 작업량을 효과적으로 줄일 수 있다.

 - 지속적으로 Sharding을 진행하게 된다면 가장 오른쪽 Node만 Write를 진행하게 된다.

 - 나머지 Node들은 Read Performance가 향상되는 효과를 얻을 수 있다.