NoSQL 조사

NoSQL DB 비교라는 문서를 기준으로 각 데이터베이스의 특성을 간략 조사해봤다.

mongodb

10gen 이라는 회사에서 운영. 오픈 소스. 컬럼 그룹 기반.

• C++ based
• SQL과의 호환성(쿼리, 인덱스)
• protocol: BSON & custom
• storage: memory mapped file
• sharding
• query: javascript expression
• server script: javascript
• 다이나믹 쿼리가 필요한 경우
• map/reduce 보다 index 가 많은 경우
• 데이터가 많을 때 성능이 중요한 경우
• couch db 에 비해서 데이터가 자주 변하는 경우

Riak

• Erlang & C (+ JS) based
• fault tolerance 가 최우선
• Protocol: HTTP/REST
• map/reduce: by JS & Erlang

CouchDB

• Erlang based
• DB 안정성이 최우선. 손쉬운 사용.
• Protocol: HTTP/REST
• 자주 바뀌지 않는 데이터
• 데이터 버전관리가 중요한 경우
• ex> CMS, CRM

Redis

key-value store. github, disqus, digg, stackoverflow 에서 사용중이다.

특징

• C/C++ based
• 속도가 최우선
• Protocol: telnet like?
• disk backed in memory db ??
• disk swap 지원 안함
• set, list, hash, sorted set 등 다양한 타입 지원
• 트랜잭션도 있다..
• 데이터 용량 == 메모리에 올라 갈 정도의 크기여야 한다
• 자주 데이터가 바뀌지만 크기는 예측 가능한 분야에 적절
• ex> 주가, 분석, 실시간 데이터, 실시간 통신..

데이터 안정성

via 스냅샷

저장 방식

• RDB(snapshot): 큰 파일 하나에 DB 전체를 저장.
• AOF(Append Only File): 변경 사항(command)을 로그 파일에 계속 추가함. 서버가 뜰 때 이걸 쭈욱 읽어서 원본 데이터를 만들어낸다.
• 둘 다 끄면 캐시 모드가 됨. 서버 끄면 사라짐.
• 둘 다 적용하면, 마지막 rdb 다음부터의 AOF 를 읽어서 만들어냄

RDB 의 장점

• 특정 시각의 데이터를 하나의 파일에 담았다
• 백업/복구에 용이: 주기적으로 RDB를 만들어서 외부에 백업하기 쉽다
• 성능면에서 최고
• 빠른 재시작

RDB 단점

• 데이터 손실 가능성: 파워 나감
• 주기적으로 여러 RDB를 만들어야 된다.
• 저장할 때마다 fork 한다. 이때 I/O 가 멈추거나 CPU가 스파이크 친다.
• 물론 AOF 도 fork 를 하긴 한다.. 대신 조정이 가능.

AOF 장점

• 보다 안정적. fsync 정책을 튜닝 가능(매 초마다, 모든 쿼리 마다)
• 기본 정책은 1초마다. 백그라운드 쓰레드가 실행함.
• append only 라서 데이터 커럽션이 없다. 마지막 데이터가 깨질 경우에도 쉽게 고칠 수 있다.
• 로그가 너무 커지면 자동적으로 다른 파일로 분할한다.
• 로그 포맷이 이해하기 쉽다.

AOF 단점

• RDB 보다 파일 용량이 크다
• RDB 보다 느리다
• 데이터가 꼬일 확률이 존재한다. 과거에 그런 버그가 있었다. 근데 아직 버그 리포트는 없다.

결론

• 둘 다 사용해야 함
• 스냅샷: dump.rdb 를 남김.
• 초 단위 주기. 또는 데이터셋의 변화량 단위.
  ex> save 60 1000 === 60초 마다, 1000 개의 변화 마다
• fork 해서 자식 프로세스가 dump.rdb 를 저장하면 기존 파일을 변경
• AOS:

cassandra

페이스북이 개발해서 오픈소스화. 지금은 아파치에서 관리중. 페이스북/트위터/Digg 에서 사용. 컬럼 그룹 형태의 데이터 모델. 데이터 일관성 잘 지원한다.

• 자바 기반
• 읽기 보다는 쓰기를 많이 할 때
• 모든 컴포넌트가 다 자바일때
• 은행, 금융.

couchbase(membase)

via Features

membase 가 couchbase 로 통합됨

• Erlang & C 기반
• memcache 호환성 + 영속성 + 클러스터링 이 중요
• 존나 빠름
• 디스크 영속성
• web GUI
• DB를 끄지 않고 업그레이드 가능
• 데이터 접근 속도가 중요할 때, 많은 접근이 있을 경우, 높은 가용성 필요할 때
• 징가 같은 highly concurrent web app

HBase

• google big table 의 오픈 소스 클론

총평

유력한 후보들

• mongodb: 팔방미인. blob
• redis: 로그 & 캐시
• couchbase(membase): 메모리 기반 but 용량 한계. 근데 node.js 클라 없다.

무시할 놈들

• couchdb: 데이터가 자주 바뀐다…
• cassandra: 자바 기반
• riak: 머임..
• hbase: 즐..