sharding, consistent hashing

대용량 처리를 위한 DB 샤딩 전력중,
웹2.0사이트에서의 기본 파티셔닝인 [ Key or Hash Based Partitioning ] 구현시, 주의사항 및 해결방안은 다음과 같음

1) 해쉬결과 데이터가 균등하게 분포되도록 해쉬함수를 정하는게 중요하다.
=> 해결방안 : 데이터 균등 분포 문제는 Virtual Node 기법을 통하여, 분포도의 편차를 줄일 수 있다고 판단됨
2) 서버의 수를 늘리기 위해서 해쉬함수를 변경하는 작업이 무지무지 비싼 작업이다.
=> 해결방안 :  Apache Zookeeper 를 활용하여 hash ring 구조인 consistent hashing의 구현.
3) 샤딩에 따른 Join 및 인덱스 처리
=> 해결방안 : 인덱스 구성을 위한 컬럼기반 noSQL 사용, RDBMS에서의 Schema-less Data 저장, 전문검색알고리즘의 활용
( a) 대용량 Write 처리가 필요할 경우 Cassandra 가 유리, 핵심은 샤딩구성시 Table Join 이 불가능하므로, 스키마의 비정규화가 얼마나 성공적으로 이후어지느냐가 관건
  b) SQL 에서 Schema-Less 데이터를 저장 - 데이터를 JSON형태로 한 컬럼(BLOB 등)에 저장하는것과 인덱스 구성이 핵심 포인트
  c) Lunece 을 이용한 인덱스 검색의 활용
)
4) 성능문제에 있어서 빠른 pre/post process 를 위한 비동기처리
=> 해결방안 : 서버사이드에서의 비동기처리를 위한 amqp cloud 의 구현(마찬가지로 consistent hashing의 구현 필요), 클라이언트사이드에서의 비동기처리를 위한 ajax(node.js) cloud 의 구현.
5) 성능문제 해결을 위한 캐시구현
=> 해결방안 : 캐시클라우드(memcached or redis)의 구현. 서버사이드 데이터가 아닌, 클라이언트사이드 데이터에 대한 캐시처리가 핵심 포인트


대용량 처리에 있어서의 공통적인 핵심은
확장 가능성을 염두해 둔, Consistent Hashing 구조(소프트웨어 아키텍쳐) 이며, 쉽게 노드를 추가,제거,백업,마이그레이션 할 수 있는 클라우드와 가상화(하드웨어아키텍쳐) 인 것 같음


조만간 최소인력(1인 이더라도)으로 운영할 수 있는 소프트웨어 및 하드웨어 아키텍쳐가 되는것도 가능하지 않을까?




참고자료

consistent hashing
- http://en.wikipedia.org/wiki/Consistent_hashing

[DB] DB Sharding은 무엇이고, 적용 전략은? ( 적용시 고려사항 )
- http://hanburn.tistory.com/m/106

cassandra 에서의 consistent hashing
- http://theeye.pe.kr/entry/how-implement-of-consistent-hashing-on-cassandra-nosql

memcached 에서의 consistent hashing
- http://charsyam.wordpress.com/2011/11/25/memcached-에서의-consistent-hashing/

FriendFeed에서는 어떻게 MySQL에 Schema-Less 데이터를 저장하는가?
- http://www.mimul.com/pebble/default/2012/07/09/1341819559265.html

Building a Consistent Hashing Ring - Part 1
- http://greg.brim.net/post/2011/02/08/0026.html

Cassandra 에 대해 정리를 잘 해주신 글
- http://azuroth37.blogspot.kr/2011/06/cassandra-112.html