distributed read/write cache for type value store

riak을 ram(memory) backend로 설정도 해보고,
redis/memcached도 고려해 보고,
couchBase도 고려해보고,
RabbitMQ를 이용한 방식도 생각해봤다.
scalaris도 설치해봤다.

riak은 내부적으로 erlang의 ets를 사용하는데, stress test시 garbage collection을 제대로 처리 못해서, swap memory를 사용한다. 그래서, 갑자기 퍼포먼스가 떨어진다.

redis/memcached는 memory flush out에 callback을 붙이는 것이 단기간에는 쉽지 않았다.

couchBase는 license비용 때문에, 엄두가 나질 않았다.

scalaris는 설정하다가 실패. 아직 찾아볼 자료도 별로 없다. 소스 리뷰는 도움이 된다.

결국, cache에 대해서는, mnesia를 사용해서 자체적인 분산처리 agent를 만들기로 결정했다.

결론적으로, 현재의 best practice는 memory cache 를 read only로 redis를 사용하고,(그것이 싫다면 자체제작) persistence에 대해서는 riak의 bitcask를 사용하는 것인 듯.

mongoDB와 riak은 근본적으로 분산처리 알고리즘이 다르다.
어떻게 다른지, 잘 알고 써야 한다. mongoDB는 controller를 통해서, hash key를 통제하는 방식이고, riak은 vnode를 사용하여, peer끼리 gossip하며 balance시키며 교환하는 방식이다. mongoDB는 자체적으로 memory cache를 갖고 있기 때문에, 성능이 더 좋다. 하지만, 잘 쓰기 나름이다. 개인적으로 riak이 더 마음에 든다.
Riak의로 AP를 확보하고, Memory Cache로 C(Consistency)와 성능을 확보하면 완벽할 듯.

distributed key-value store

요즘 distributed DB에 대한 needs가 많다.
저에게도 문의가 가끔씩 옵니다.

제 생각엔, MySQL로 잘 버티다가 옮기는 방법이 현실적이라고 생각합니다.

저도 아직 써보진 않았지만, 제가 기술책임자라면,
scalaris와 kumofs, tokyocabinet를 쓰면 어떨까 합니다.
http://elliotsp.blogspot.com/2011/01/choosing-type-value-store-for-user.html

저도 시간되면, 테스트 프로젝트를 해 볼까 합니다.

추가적으로 couchDB,DEX graph DB도 쓸만 할 것으로 예상합니다.
언어는 Erlang을 추천하지만, 다른 언어를 써도 무방합니다.

도움이 되셨다면, PayPal donate(또는 광고 클릭)를 ㅎㅎ ^^

Implementing SSO using Scalaris in Erlang?

SSO(Single Sign On) Service는 다음과 같은 역할을 가진 서비스이다.
1. 인증 - 한번 로그인(인증)을 함으로써, 해당 서비스사의 다른 서비스를 위해 다시 인증을 하지 않아도 되게 한다. Kerberos 구조로 구현한다. 보안이 잘 되어야 한다.
2. 이중 접속 방지 - 어떤 서비스는 동시에 단 한 사람만이 이용할 수 있도록 해야 한다. 온라인 게임들이 주로 그렇다. 이중 접속을 체크하려면, 현재 사용 하는 사람들의 ID와 접속 상황을 실시간으로 업데이트하고 있어야 한다.
3. 1번에 붙여서, 서비스 사용에 대한 권한조회까지 할 수 있어야 한다.

이것을 구현하기 위해서, 예전에는 동시접속자 20만 정도의 수준 이하에서는 C++로 구현한 단일 서버에 사용하였다. 그런데, 결국 200만명 이상이 되자, 단일 서버로 구현하기 힘들게 되고, 인증구조와 이중 접속 방지를 위해 다시 구조를 만들어야 했다.

따라서, 새로 만드는 SSO는 scalable, distributed 특징이 가장 필요하다.

Erlang으로 구현한 Scalaris가 이 용도에 딱 적합하다.
처리 용량과 속도는 구현후에 공유하도록 해야겠다.

Scalaris is a scalable, transactional, distributed key-value store. It can be used for building scalable Web 2.0 services.

http://code.google.com/p/scalaris/

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는 아니지만,
홈페이지의 주장에 따르면, 매우 빠르다!
이것데 대한 벤치마킹 결과도 올려야겠다.

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