Programmer J

Sharding(샤딩)

• DB 확장성을 위해 장비 업그레이드를 통해서 Scale-Up을 해서 병목을 피해감.
• Scale-Up을 통해서도 병목을 피할 수 없을 경우 Scale-Out을 해야 한다. Scale-Otu의 기술 중 하나 Sharding 이다.
• 샤딩은 데이터베이스가 저장하고 있는 테이블을 테이블 단위로 분리하는 방법(수직 샤딩)과 테이블 자체를 분할 하는 방법(수평 샤딩)이 있다.
• 수직 샤딩에서는 테이블 하나를 서로 다른 column을 가진 테이블로 나누는 방법도 있다.

• 수평 샤딩을 하면 샤딩 이후 DB를 증가 시킬 때 마다 데이터 재분배를 해야 한다.
  • SELECT 작업을 할 때 마다 샤드한 테이블 모두를 검색해야 하기 때문에 통계 작업 등에서 꽤 골치 아픔
  • 이 부분을 자동으로 해 주는 미들웨어가 있으면 좋음
• 수직 샤딩은 각 테이블 별로 데이터가 잘 나누어지지 않고 한쪽으로 집중되면 샤딩의 의미가 약해진다
• 샤딩의 특징
  • 성능 개선
  • 신뢰성 개선
  • 위치 추상화

• 샤딩은 안하면 안 할 수록 좋다!!!
  • 최대한 데이터 구조 개선이나 Scale-Up을 통해서 샤딩을 하지 않는 것이 좋다. 복잡성 증가를 피하기 위해
  • 샤딩 이전에 memchaced나 Redis를 통해서 성능 개선을 한다
  • 샤딩을 해야 한다면 수직 샤딩을 먼저 시도해 본다.
  • 마지막으로 수평 샤딩을 한다.

사례-MongoDB의 샤딩

• 자동 샤딩을 할 수 있다.
• 그러나 DB 요청이 아주 많을 때 라우팅 역할을 하는 서버에 병목이 발생할 수 있다.
• 버전 업 주기가 짧고 버전 업이 될 때 마다 성능 및 기능 개선이 있으므로 언제나 최신 버전을 기준으로 확인 해봐야 한다
  • 웹이나 주위의 이전 버전 기준의 이야기를 그대로 들으면 안된다!!!
• http://blog.naver.com/musasin84/60191877212

사례-MasterDB 방식의 샤딩

• MasterDB의 맵핑 테이블을 사용하여 유저마다 사용할 shard를 나누어서 분산하는 방법
• 유저 로그인 시 맵핑 테이블을 조회하면 어디에 있는지 알 수 있음
• AUTO_INCREMENT 값도 맵핑 테이블에서 관리. 샤드마다 중복 값이 생기지 않음
• 데이터 재분배 시 맵팅 테이블을 사용

사례-인스타그램의 샤딩

• http://webgenie.tistory.com/44

SQL- Spider fo MySQL을 사용한 샤딩

• https://launchpad.net/spiderformysql
• 서로 다른 MySQL 인스턴스 테이블을 동일 인스턴스 테이블과 같이 다룰 수 있다.
• xa 트랜잭션을 포함한 트랜잭션을 지원하기 때문에 갱신계 DB 클라스터링으로 이용 할 수 있다
• 테이블 파티션을 지원하고 있기 때문에 파티션 룰을 이용하여 동일 테이블의 데이터를 복수의 서버에 분산 배치 할 수 있다
• spider 스토리지 엔진 테이블을 만들면 MySQL 내부에서는 파일로의 심볼릭 링크 같이 하여 리모트 서버 테이블에 테이블 링크를 생성한다
• 링크처의 테이블 스토리지 엔진에 제한이 없다
• 사용 방법
  • (일본어) http://memocra.blogspot.kr/2011/08/ec2mysqlspider1-spider.html