» sharding » sharding key (ID) 생성 과 관련 이슈 

sharding key (ID) 생성 과 관련 이슈 

목표는 중복되지 않는 unique ID 값을 만들려는 것이 목표.
보통 database에서는 auto_increment를 통해서 겹치지 않는 값을 만들 수 있지만,
여러 서버입장에서 보면 이 값들이 동일하게 되기 때문에
여러 서버에서 보면 중복되는 값이 서버 개수 만큼 생길 수 가 있음.

시스템 요구사항.
1. ID 는 시간으로 정렬할 수 있는 형태여야 함.
2. ID 는 64bit 이어야 함.( redis 등의 더 작은 인덱싱이 가능한 시스템을 위해서 ..)
3. 시스템은 가능한 변동하는 부분이 없어야 함.  
겨우 몇명의 엔지니어로 시스템의 확장성을 가지기 위해서 간결하고,
이해하기 쉬운, 신뢰할 수 있는 솔루션이어야 함.
twitter 의 SnowFlake 같은 경우, Apache Zookeeper 와 Thrift 서버를 추가로 구성해야 함.

이를 위한 기존 솔루션들 정리
웹 어플리케이션에서 IDs 생성하기 ( 개인적으로 이 방법으로 샤드 키를 생성 해서 사용 해 왔음. )
이 방법은 데이터베이스에 접근하지 않고, 어플리케이션에서 전적으로 ID를 생성하는 방법!
MongoDB의 경우 ObjectId는 12bytes 의 인코딩된 timestamp를 이용.
( http://www.mongodb.org/display/DOCS/Object+IDs)
다른 방법으로 UUID 가 있음.

-장점
1. 각 어플리케이션에서 독립적으로 ID를 생성하므로,
ID 생성시에 생기는 실패나 병목지점을 최소화 할 수 있음.
2. timestamp 를 이용하면, ID는 시간으로 정렬이 가능.

-단점
1. 일반적으로 유일한 ID를 만들기 위해서는 스토리지 용량이 더 필요함.( 일반적으로 96bits 이상)
2. 몇몇 UUID는 완전 랜덤으로 만들어져서 정렬을 할 수 가 없음.

중앙서비스를 이용한 IDs 생성하기
트위터의 SnowFlake( https://github.com/twitter/snowflake/ ) ,
Apache Zookeeper 를 이용한 Thrift 서비스로 64bit 의 유일한 ID를 생성함.
-장점
1. SnowFlake 의 ID는 64bits 로 UUID의 절반 사이즈.
2. time 정보를 이용해서 시간으로 정렬이 가능.
3. 일부 노드가 죽어도 사용할 수 있는 분산 시스템임.

– 단점
1. 서비스에 사용하기에는 ZooKeeper, SnowFlake Servers 등 이 많아서, 더 시스템을 복잡하게 만듬.

DB Ticket 서버를 이용
데이터베이스의 Auto-Incrementing 기능을 이용.
Flickr(플리커) 가 이 방법을 이용. 두 개의 ticket DB를 이용해서 SPOF를 피함.
(http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/)

하나는 홀수로만, 하나는 짝수로만 증가하게 함.
보통 uID가 꼭 연속적일 필요가 없기 때문에, 장애 대비용으로 홀수, 짝수로 구분해 놓고 많이 사용.
또한, 짝수 서버를 홀수 서버의 slave로 설정해두고, 평소에는 홀수 내용을 저장하다가,
자기쪽으로 insert 가 직접적으로 들어왔을 때만, 짝수로 동작하게 해서 Consistency를 보장하는 방법도 가능.

-장점
1. DB는 확장 요소를 쉽게 예측가능하고, 이해하기 쉬움.

-단점
1. 쓰기 병목이 일어날 수 있음.( Flickr 에서 이 내용을 리포팅 했습니다.)
2. 관리해야한 장비. 즉,두 대의 장비를(instance) 추가해야 함.
3. 하나의 DB만 이용한다면, SPOF 가 생기기 때문에 여러 개의 DB를 이용!
4. 시간으로 정렬됨을 더 이상 보장하지 않습니다.

issue
전체를 시간순으로 정렬할 수 없는 이슈가 생김. 홀수, 짝수일 경우,
한대의 서버가 장애가 나면,다른 장비로 값이 계속 증가될 텐데,
장애가 복구가 되었을 때, 해당 장비의 시작값이 다른 서버보다 작기 때문!!

위의 방법들을 봤을 때, 트위터의 SnowFlake 가
가장 요구사항에 근접 하지만 시스템 복잡도가 증가 함.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중