데이터 모델에 따른 Nosql 선택과 고려사항

데이터의 성격과 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. 문제가 없는 완벽함은 없다. 문제가 생겨도 괜찮은가?