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

'nosql' 카테고리의 다른 글

[Hadoop 설치 에러] bin/hadoop namenode -format 실패시  (0) 2011.08.22
Redis 소개  (2) 2011.08.18
Memcached와 Redis 성능 테스트 비교 자료  (2) 2011.08.17
mysql -> mongoDB로 migration  (0) 2011.05.27
Nosql in Facebook  (0) 2011.05.24
Posted by '김용환'

댓글을 달아 주세요