hanburn : a line of code

작성자 : hanburn

작성일 : 2012-01-17

1. 샤딩 ( sharding ) 이란 무엇인가?

2. 샤딩 및 전략

 2.1 vertical partitioning

 2.2 Range Based Partitioning

 2.3 Key or Hash Based Partitioning

 2.4 Directory Based Partitioning

3. 샤딩 적용시 고려사항

1. 샤딩 ( sharding ) 이란 무엇인가?

관계형 데이터베이스에서 대량의 데이터를 처리하기 위해서 데이터를 파티셔닝하는 기술이다. 파티셔닝은 DBMS에서 지원하기도 하는데, 일부 DBMS ( MySQL 5.1 미만에서는 지원 안함) 에서는 지원안하기도 한다. 샤딩은 DBMS 레벨에서 데이터를 나누는 것이 아니고 데이터베이스 자체를 분할하는 방식이다. 따라서 어플리레이션 레벨에서 구현해야 한다.

간단하게 예를 들면, 전 세계의 고객 데이터를 저장하는 대형 데이터베이스를 분산한다고 할때, 미국 고객의 경우는 샤드A, 아시아 고객의 경우는 샤드B, 유럽 고객의 경우는 샤드C로 분할해서 저장할수 있다.  

2. 샤딩 및 전략

샤딩에서 데이터베이스를 분할하는 방법에 대해서 살펴본다. 각 방법마다 장단점과 주의할 점이 있으므로 서비스에 맞게 적절하게 선택하거나 조합하여 사용 한다.

2.1 Vertical Partitioning

    테이블 별로 서버를 분할하는 방식이다. 예를들면 사용자 프로필정보용 서버, 사용자 친구리스트용 서버, 사용자가 만든 컨텐츠( 사진같은것 ) 용 서버등으로 분할하는 방식이다.

    장점 : 구현이 간단하고, 전체 시스템에 큰변화가 필요 없다.

    단점 : 각 서버의 데이터가 점점 거대해지면 추가 샤딩이 필요해진다. ( 1천만명이 1000장의 사진을 생성한다면 컨텐츠 서버에 또 샤딩이 필요할 것이다. )

  2.2 Range Based Partitioning

    하나의 feature(또는 table)가 점점 거대해지는 경우 서버를 분리하는 방식이다. 예를들면 사용자가 많은경우 사용자의 지역정보를 이용해서 user 별로 서버를 분리하거나, 일정데이터라면 년도별로 분리, 거래정보라면 우편번호를 이용하는 방식이다.

    주의점 : 데이터를 분할하는 방법이 예측가능해야 한다.

  2.3 Key or Hash Based Partitioning

    이방식은 웹2.0 사이트에서 기본 파티셔닝 방식으로 알려져있다. 엔티티를 해쉬함수에 넣어서 나오는 값을 이용해서 서버를 정하는 방식이다. 사용자ID가 숫자일 경우 나머지연산( module operation)을 이용하는 방법이다.

    주의점 : 해쉬결과 데이터가 균등하게 분포되도록 해쉬함수를 정하는게 중요하다.

    단점 : 서버의 수를 늘리기 위해서 해쉬함수를 변경하는 작업이 무지무지 비싼 작업이다.

  2.4 Directory Based Partitioning

    파티셔닝 메커니즘을 제공하는 추상화된 서비스를 만드는 것이다.(데이터베이스 액세스 코드와는 떨어져 있는)  샤드키를 look-up 할수 있으면 되므로, 구현은 DB와 cach를 적절히 조합해서 만들수 있다.

3. 샤딩 적용시 문제점들 및 고려사항

 3.1 데이터 재분배 ( Rebalancing data )

  Sharding된 DB의 물리적인 용량한계나 성능한계에 다르면 shard의 수를 늘리는 scale-up 작업이 필요하다. 서비스 정지 없이 scale-up 할수 있도록 설계방향을 잡아야 한다.

 3.2 샤딩으로부터 데이터 조인하기 ( Joining data from multiple shards )

   Sharding-db 간에 조인이 불가능 하기에 처음부터 역정규화를 어느정도 감수해야 한다. Shard의 목정이 대용량 데이터 처리이므로, 대용량처리시 수행성능을 위해서 데이터 중복은 trade-off 관계 임을 이미 알고 있다.

 3.3 샤드에 데이터를 파티션하는 방법 ( How do you partition your data in shards? )

  shard 해쉬함수를 잘 설계해야 한다.

 3.4 샤드간의 트랜잭션 문제

  Global Transaction을 사용하면 shard DB간의 트랜잭션도 가능하다. 그 유명한 XA인데, 성능저하의 문제가 있다.

 3.5 Global Unique Key

  DBMS 에서 제공하는 auto-increament를 사용하면 key가 중복될수 있기 때문에, application 레벨에서 Key 생성을 담당해야 한다.

 3.6 데이터는 작게

  Table의 단위를 가능한 작게 만들어야 한다.

참고

http://www.ibm.com/developerworks/kr/library/j-javadev2-11/

http://highscalability.com/unorthodox-approach-database-design-coming-shard

http://www.25hoursaday.com/weblog/2009/01/16/BuildingScalableDatabasesProsAndConsOfVariousDatabaseShardingSchemes.aspx