데이터베이스 분할
데이터베이스에 저장하는 데이터가 지속해서 누적되어 데이터베이스 볼륨이 커질수록 데이터베이스의 읽기/쓰기 성능은 감소한다. 이로 인해 베이터베이스가 병목 지점이되어 시스템 성능 저하의 원인이 되기도 하니, 데이터를 적절하게 분할하여 저장할 필요가 있다.
데이터베이스를 분할하는 방법으로는 크게 파티셔닝(Partitioning)과 샤딩(Sharding)이 있다.
파티셔닝(Partitioning)
파티셔닝은 매우 큰 테이블을 여러 개의 테이블로 분할하는 작업을 말한다. 데이터를 물리적으로 여러 테이블에 분산하여 저장하지만, 사용자는 하나의 테이블에 접근하는 것처럼 사용할 수 있다. 큰 데이터를 여러 테이블로 나누어 저장하기 때문에, 파티셔닝을 통해 쿼리 성능이 개선될 수 있다. 이러한 파티셔닝 기술은 MySQL에서 자체적으로 지원하는 기능이다.
MySQL의 공식문서의 4가지 파티셔닝 종류를 알아보자.
•
List Partitioning
위 그림에서 특정 지역별로 데이터를 분할하듯, 데이터 값이 특정 목록에 포함된 경우 데이터를 분리한다.
•
Range Partitioning
위 그림처럼 데이터를 특정 범위 기준으로 분할한다.
•
Hash Patitioning
해시 함수를 사용하여 데이터를 분할한다. 특정 컬럼의 값을 해싱하여 파티션을 선택하여 저장하거나 조회한다. 여러 컬럼으로 해싱할 수 있지만, 공식문서에서는 크게 권장하지 않는다고 한다.
•
Composite Partitioning
위의 파티셔닝 종류들 중 2가지 이상을 병행하여 사용하는 방식이다.
샤딩(Sharding)
샤딩은 하나의 데이터베이스에 저장된 데이터들을 동일한 스키마를 가지고 있는 여러 대의 데이터베이스로 데이터를 분산하여 저장하는 기법이다.
샤딩은 수평적 파티셔닝의 일종으로 볼 수 있지만, 수평적 파티셔닝은 동일한 데이터베이스에 테이블을 분할하는 것이고
샤딩은 데이터베이스를 분할한다는 차이가 있다. 물리적으로 다른 데이터베이스에 저장하기 때문에, 쿼리 성능 향상에 더해 부하를 분산시키는 효과도 얻을 수 있다. 다시말해, 샤딩은 데이터베이스의 수평적 확장(scale-out)인 셈이다.
샤딩은 일반적으로 애플리케이션 레벨에서 구현하여 사용되지만, 플랫폼 차원에서 제공하려는 시도가 늘어나고 있는 추세이다. 플랫폼 차원에서 제공하는 사딩은 CUBRID SHARD, Spock Proxy, Gizzard 와 같이 미들 티어(middle tier)에서 동작하는 형태, nStore나 MongoDB와 같이 데이터베이스 자체에서 샤딩을 제공하는 형태 등이 있다.
샤딩을 적용하면 얻을 수 있는 여러 장점이 있다.
•
데이터를 분산하여 저장하기 때문에, 각 데이터베이스 서버의 부하를 줄이고 성능을 향상시킬 수 있다.
•
샤드를 추가하여 Scale-Out을 통한 수평적 확장에 용이하다.
•
하나의 샤드에서 장애가 발생하더라도 다른 샤드에 영향을 미치지 않는다.
샤딩을 적용했을 때 몇 가지 주의해야 할 점이 있다.
•
시스템의 복잡도가 증가하고 유지보수의 비용이 높아지게 된다.
•
샤딩을 적용하면 물리적으로 데이터가 분산되어 저장되므로, 여러 샤드에 걸친 데이터를 Join하는 것이 어렵다.
•
하나의 데이터베이스에 집중적으로 데이터가 몰리면 Hotspot이 되어 성능이 느려지게 되므로, 여러 샤드로 데이터를 골고루 분배하는 것이 중요하다.
•
샤딩 적용 이후 샤딩 적용 이전의 구조로 돌아가기에 힘들다.
샤딩의 종류
•
Hash Sharding
해시 샤딩 방식은 특정 컬럼의 값으로 해시 함수를 통해 해시 값을 얻어 샤드에 라우트하는 방식이다. 구현이 간단하고 데이터가 균일하게 분산된다는 장점이 있지만, 샤드를 추가하는 경우 기존 샤드의 데이터들에 대해 재정렬이 필요하다는 단점이 있다.
모듈러 샤딩(Modular Sharding)은 해시 샤딩의 일종으로 PK를 모듈러 연산한 결과로 샤드에 라우팅하는 방식이다.
•
Range Sharding
범위 샤딩 방식은 특정 컬럼의 값의 범위 기준으로 샤드에 라우트하는 방식이다. 구현이 간단하고 샤드의 추가 시 데이터 재정렬 비용이 발생하지 않지만, 일부 샤드에 데이터가 몰려 Hotspot이 될 수 있다.
•
Directory Sharding
디렉토리 샤딩 방식은 별도의 조회 테이블을 사용해 샤드를라우팅하는 방식이다. 샤딩에 사용되는 시스템이나 알고리즘을 유연하게 적용할 수 있고 샤드를 추가하는 것도 용이하지만, 모든 읽기/쓰기 시 조회 테이블을 참고하기 때문에 오버헤드가 존재하며 조회 테이블이 단일 장애 포인트가 될 수 있다는 단점이 있다.
샤딩 시 고려사항
일반적으로 사용되는 애플리케이션 샤딩의 경우 시스템 특성에 맞는 샤딩 방식을 선택하면 되는데, 이 때 고려해야하는 사항들이 있다.
•
값의 변화
◦
샤딩에 사용되는 컬럼의 값의 변경이 얼마나 자주 발생되는지 고려해야한다.
◦
값이 거의 변경되지 않는 값을 사용하는 것이 좋다.
•
분포
◦
해시 값이나 모듈러 연산, range 등 샤딩 키가 얼마나 분포되어있는지 고려해야한다.
◦
데이터가 제대로 분산되지 않는다면 Hotspot이 발생하여 샤딩을 적용 안하느니만 못한 성능을 얻게 된다.
•
Cardinality
◦
일부 샤딩 방식에 따라 샤딩 키로 사용되는 컬럼의 카디널리티도 고려해야한다.
