데이터의 성격과 Need을 바탕으로 어떤 nosql을 써야할지에 대한 내용이 담겨져 있는 article이다. 잘 정리되어 있었다. 
 
http://highscalability.com/blog/2011/6/20/35-use-cases-for-choosing-your-next-nosql-database.html 

좋은 기사가 있어서 내 맘대로 정리및 번역했다..
 

1. 데이터 성격

- 문서 (Document, key-value 집합)
* CouchDB, MongoDB
* 특정 패턴이나 다양한 종류의 데이터를 저장
* json, http, rest, javascript 와 쉽게 연동
* CRUD
* 작은 단위 data read/write가 많다
* 스키마를 쉽게 변경
* fluid data type
* mobile platform

-그래프 (Graph)
* AllegroGraph, InfoGrid, Neo4j
* 소셜 네트웍기능
* 관계도를 동적으로 만들 떄

-관계형 DB
* VoltDB,  Clustrix, MySQL
* VoltDB : 실시간 정보에 대해서 뷰단위로 트랜잭션을 하는 경우에 탁월
* 기업 고객이 고려
* complex transaction
* secondary index 지원

-OO DB
Objectivity, Gemstone

-Key-Value
* Membase, Riak
* Riak : 소셜 네트웍기능, 검색
* membase : SLA 
* 작은 단위 data read/write가 많다
* 스키마를 쉽게 변경
* BLOB 데이터의 캐쉬 또는 저장
* fluid data type

-BigTable
* HBase, Hypertable, Cassandra
* HBase : 데이터가 항상 저장되고 높은 HA가 필요
* Hadoop : 대용량 오프라인 리포팅 기능
* 여러 IDC간에 데이터 분산
* consitency에 대한 개런티
* fluid data type
* Cassandra : secondary index 지원
* 계속 커지는 큰 데이터 저장

-Data Structure 서버 (데이터에 대해서 list, set 지원)
* Redis
* 리스트, 셋, 큐, pub-sub

-Grid DB
* GigaSpaces, Coherence
* complex transaction

- 대용량 데이터
* 아마존 S3


고려사항
1. 25% 성능 향상때문에 nosql을 선택하는 이유가 되지 않을 것이다.
2. 벤치마크는 유스케이스에 의존한다. 이거 상황과 꼭 맞을지 확인해야 한다.
3. SQL과 nosql 선택은 토론의 여지가 있다.
4. 여러개의 Node로 써서 나오는 성능도 확인할 필요가 있다.
5. 문제가 없는 완벽함은 없다. 문제가 생겨도 괜찮은가?

Posted by 김용환 '김용환'