2011년 1월 19일 수요일

choosing type-value store for user account DB - scalaris, kumofs

천만이상/억대의 유저의 계정 정보를 관리하는 계정 데이터베이스를 운영하고 싶다.
그것도, 가장 효율적인 방식으로.

계정은 가장 간단하게만 설계한다면,
ID/Password와 Password Recovery를 위한 정보만 가지면 된다.
결국, 하나의 ID에 Key-Value Pair의 Array를 가지게 된다.

효율적으로 최적화해야 할 부분은 다음과 같다.
1. 최초 계정 생성시 ID중복 여부를 빠르게 체크하기
2. 로그인시 PW 확인을 빠르게 체크하기
3. 로그인시 중복 로그인을 빠르게 체크하기
4. 로그인 컨펌이후에, 서비스를 위한 데이터 로드하기
5. 로그인 컨펌이후에, 각 서비스에 대한 권한 확인하기
6. 로그인이후에, 서비스 사용 데이터 기록하기
 
1,2번을 위해서 Distributed In-Memory Database가 필요하다. 또한 인덱싱이 잘 되어 있어야 한다.
하지만, 결국 메모리에 다 넣을 수는 없다. Persistent Storage가 필요하다.
3번을 위해서, Double Login Check Middleware Server를 만들기도 한다. 하지만, 데이터베이스로
가능하면 좋지 않을까?

이를 위해서 NoSQL쪽을 조사해 보았다.
다음의 아티클을 보자.


http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores

저자의 요구사항과 나의 요구사항과 비슷하다.
DHT(Distributed hash Table)을 사용해야 하고, low-latency가 필요하다.

저자의 의견대로 Scalaris가 가장 우수한 후보이다. ( http://code.google.com/p/scalaris )

하지만, In-Memory에서만 지원한다. 지금 보니 TokyoCabinet을 통해서 Persistent Storage도 지원한다.

일단 Scalaris를 써보기로 했다.
MySQL과의 벤치마킹 결과를 나중에 올려야겠다.

다른 후보로는,
Kumofs이다. (  http://kumofs.sourceforge.net )
비록 In-Memory는 아니지만,
홈페이지의 주장에 따르면, 매우 빠르다!
이것데 대한 벤치마킹 결과도 올려야겠다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

댓글 없음:

댓글 쓰기