요즘 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(또는 광고 클릭)를 ㅎㅎ ^^
2011년 5월 26일 목요일
2011년 1월 19일 수요일
installing kumofs in ubuntu 10.10
1. ruby를 설치합니다.
1) sudo apt-get install ruby
-> patch level이 최신이 아닙니다.
2) ruby 홈페이지에 가서 ruby 1.8.7최신 버전(p302)을 받아서 풀고,
#./configure
#make
#sudo make install 합니다.
#ruby --version 을 하면 예전 ruby가 실행됩니다.
PATH에 /usr/local/bin이 우선되면 최신 ruby가 실행됩니다.
2. tokyocabinet을 설치합니다.
1) 홈페이지에서 다운로드해서 압축을 풉니다.
2) libbz2-dev 를 설치합니다.
#sudo apt-get install libbz2-dev
3) compile및 설치하니다.
#./configure
#make
#sudo make install
3. messagepack을 설치합니다.
#wget http://downloads.sourceforget.net/project/msgpack/msgpack/cpp/msgpack-0.5.2.tar.gz
#tar xvfz msgpack-0.5.2.tar.gz
#cd msgpack-0.5.2
#./configure
#make
#sudo make install
4. bootstrap을 실행하면 다음을 추가로 설치해야 합니다.
#sudo apt-get install ragel #sudo apt-get install libtool
#sudo apt-get install automake
#./bootstrap 이 성공적으로 수행됩니다.
5. #./configure
#make
#sudo make install
설치 완료!
이제 설치를 확인해야 합니다.
kumo 홈페이지의 example을 실행해보면 됩니다.
도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^
1) sudo apt-get install ruby
-> patch level이 최신이 아닙니다.
2) ruby 홈페이지에 가서 ruby 1.8.7최신 버전(p302)을 받아서 풀고,
#./configure
#make
#sudo make install 합니다.
#ruby --version 을 하면 예전 ruby가 실행됩니다.
PATH에 /usr/local/bin이 우선되면 최신 ruby가 실행됩니다.
2. tokyocabinet을 설치합니다.
1) 홈페이지에서 다운로드해서 압축을 풉니다.
2) libbz2-dev 를 설치합니다.
#sudo apt-get install libbz2-dev
3) compile및 설치하니다.
#./configure
#make
#sudo make install
3. messagepack을 설치합니다.
#wget http://downloads.sourceforget.net/project/msgpack/msgpack/cpp/msgpack-0.5.2.tar.gz
#tar xvfz msgpack-0.5.2.tar.gz
#cd msgpack-0.5.2
#./configure
#make
#sudo make install
4. bootstrap을 실행하면 다음을 추가로 설치해야 합니다.
#sudo apt-get install ragel #sudo apt-get install libtool
#sudo apt-get install automake
#./bootstrap 이 성공적으로 수행됩니다.
5. #./configure
#make
#sudo make install
설치 완료!
이제 설치를 확인해야 합니다.
kumo 홈페이지의 example을 실행해보면 됩니다.
도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^
Labels:
kumofs,
messagepack,
ruby,
tokyocabinet
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는 아니지만,
홈페이지의 주장에 따르면, 매우 빠르다!
이것데 대한 벤치마킹 결과도 올려야겠다.
도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^
그것도, 가장 효율적인 방식으로.
계정은 가장 간단하게만 설계한다면,
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는 아니지만,
홈페이지의 주장에 따르면, 매우 빠르다!
이것데 대한 벤치마킹 결과도 올려야겠다.
도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^
Labels:
kumofs,
nosql,
scalaris,
type-value store
피드 구독하기:
글 (Atom)