RDB 전문가가 NoSQL DB를 접하면 처음엔 당황합니다.
어떻게 쓰는건지 잘 모르겠거든요.
안되는 것도 많고, 일일히 코딩을 해야 하고.
하지만, 그러라고 나온 DB는 아닙니다.
간단한 개발을 한다면 DB 에 바라는 기능은, 단순히 데이터를 잘 읽고 쓰는 것 정도이죠.
다양한 데이터 조작과 조합기능?
그런거 필요없습니다.
빠른 탐색속도가 더 좋습니다.
NoSQL DB 은 그런 목적에 특화된 DB 입니다.
다양하게 데이터를 조합해 보려면 여전히 RDB 가 효과적입니다.
2차원 데이터셋은 사람들이 이해하기 가장 편한 포맷이거든요.
NOSQL 데이터베이스의 4가지 종류
※원문: The four categories of NoSQL databases
※출처: http://rebelic.nl/, 2011.5.28
Monitis 블로그에 “올바른 NoSQL 도구를 고르는 방법”이라는 글이 올라왔다.
모처럼 재미있게 읽었다.
그들은 NoSQL DB가 무엇인지, 왜 RDBMS 는 안되는지 파고 들었고,
NoSQL DB의 다양한 종류와 장단점에 대해 자세하게 설명했다.
많은 사람들이 NoSQL DB라는 장르를 하나로 보는데, 그 속으로 들어가면 꽤 많은 차이점들이 있다.
예를 들면 Graph Database를 이용하고자 한다면, Key-value store를 사용할 순 없다.
반면 RDBMS 는 꽤 많은 케이스에서 잘 호환된다.
Montis 는 아래와 같이 분류했다.
1. Key-Value Stores
- DB : Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB, Amazon SimpleDB, Riak
이 아이디어는 DB 에 Hash Table 을 사용하자는 거다.
Hash Table 은 하나의 Key 가 하나의 Value 를 가리키고 있다.
가장 간단한 DB 모델이고, 구현하기도 쉽다.
하지만, Key 값이 아니라 Value 를 기준으로 일부분을 조회한다면?
또는 그 일부분을 업데이트해야 한다면?
예를 들어 “Key : Value = GN : 서울시 강남구” 인 상황에서 “GN”을 찾는 게 아니라, “강남구”로 검색하는 거다.
이런 경우라면 이 DB는 비효율적이다.
2. Column Family Store
- DB : Cassandra, HBase
이 기술은 많은 서버에 분산된 대량의 데이터를 처리하기 위해 만들어졌다.
여전히 Key 방식을 쓰고 있지만, 하나의 Key가 여러 개의 컬럼을 가리키고 있다.
각 Column 들은 Column Family 로 묶여서 관리된다.
3. Document Database
- DB : CouchDB, MongoDb
이 기술은 Lotus Notes 에서 영향을 받았다.
기본적으로는 Key-Value 방식을 사용한다.
Document는 기본적으로 Key-value 집합들의 집합이다.
반구조화된 “문서”들은 JSON 포맷으로 저장된다.
Document DB는 기본적으로 Key-value DB의 다음 단계로, 각 Key 들마다 중첩된 값들을 가지고 있다.
그래서 Key-Value 방식에 비해 좀 더 효율적으로 조회할 수 있다.
4. Graph Databases
- DB : Neo4J, InfoGrid, Infinite Graph
Row, Column 기반의 정형화된 SQL 대신, 유연하게 여러 대의 서버가 병렬처리할 수 있게 Graph model 이 제공된다.
NoSQL DB 는 긴 Query time 을 피하기 위해 SQL과 같은 고수준의 선언형 Query 언어를 지원하지 않는다.
데이터 질의 방식은 데이터 모델에 따라 달라진다.
RDBMS 가 Query API 를 제공한다면, 대부분의 NoSQL 플랫폼들은 RESTful API 를 제공하고 있다.
끝.
IT의 중심에서 