NoSQL의 필요성
- 관계형 DB의 스케일업으로 대응하기 어려운 급격한 데이터의 증가
- 관계형 DB의 고비용을 감당하기 어려운 업체들의 데이터 관리 정책의 전환
- 고장 감내, 재난복구, 지리적 분산에 대한 요구
- 저렴한 클러스터 내 하드웨어 비용에 대한 요구
- 모든 데이터가 트랜잭션이 필요한 것은 아님
- 모든 데이터가 강한 일관성 조건이 필요한 것은 아님
- 서비스에 따른 비정형 데이터에 대한 처리 요구
부루어의 CAP 이론 (Brewer's CAP Theorem)
- 분산 시스템이 지녀야할 특성을 일관성(Consistency), 가용성(availability), 생존성(partition tolerance)으로 분류 및 정의하고, 분산 시스템 3가지 특성을 모두 다 보장하는 것은 불가능하며, 한가지 특성을 타협할 수 밖에 없다는 이론.
일관성(Consistency) - 모든 노드들은 같은 시간에 동일한 항목에 대하여 같은 내용의 데이터를 사용자에게 보여준다.
가용성(availability) - 모든 사용자들이 읽기 및 쓰기가 가능해야하며, 몇몇 노드의 장애 시에도 다른 노드에 영향을 미치면 안된다.
생존성(partition tolerance) - 노드 간의 메시지 손실이 있어도 정상적으로 동작해야 한다.
ACID(Atomicity, Consistency, Isolation, Durability)
트랜잭션이 안전하게 수행되는 것을 보장하기 위해 가져야하는 특성으로 원자성, 일관성, 고립성, 지속성으로 표현된다. 원자성은 한 트랜잭션 안의 모든 작업은 모두 성공하거나 모두 실패하는 것을 원칙으로 하는 단위 작업의 특성을 의미한다. 즉, 내 계좌에서 친구에게 이체할 경우 해당 금액 전체가 이체되거나 이체 자체가 실패해야지 일부 금액만 이체되어서는 안됨을 의미한다. 일관성은 한 트랜잭션이 성공하면 모든 데이터는 동시에 일관성 있는 상태로 유지되어야 한다는 것을 의미한다. 즉, 내 계좌에서 친구에게 이체하였을 경우, 두 계좌의 총합은 항상 처음과 끝이 같아야함을 의미한다. 고립성은 한 트랜잭션의 작업에 수행되는 도중에는 다른 트랜잭션 작업이 수행될 수 없음을 의미한다. 즉, 내 계좌의 지금 이체 트랜잭션이 완전히 끝나기 전까지는 다른 입금 트랜잭션이 수행될 수 없음을 의미한다. 지속성은 트랜잭션이 성공하면 해당 최종 상태는 영원히 반영되어야함을 의미한다. 즉, 내 계좌의 자금 이체가 성공했으면, 은행 전상망이 다운되어 내 계좌 정보를 담고 있는 DB가 재시작 되어도 나의 자금 이체기록은 항상 최종 상태를 유지하고 있어야 함을 의미한다. 이를 위한 모든 트랜잭션은 로그를 남기고 난 이후에 커밋 상태로 처리된다.
NoSQL은 BASE 특성을 가진다.
-Basically Available : 데이터가 항상 접근될 수 있는 가용성을 의미한다. 즉, ACID의 I(isolation)와는 다른 속성을 의미한다.
-Soft- state : 노드가 가진 데이터의 상태(일관성이 맞는지 등)의 결정은 노드 스스로 결정할수 있는 것이 아니라 외부의 노드에서 전송된 정보를 통하여 상태를 결정지을 수 있음을 의미한다. 즉, 각 노드별로 자기 자신이 가진 정보가 항상 최신임을 보장할 수 없음을 의미한다.
- Eventual Consistency : 일관성을 제공하기는 하지만, 그 일관성의 상태가 모든 노드에서 동시에 보장되지는 않음을 의미한다. 즉 ,몇몇의 노드는 조금 일찍 동일 데이터에서 일관성을 유지할 수 있으며, 반대로 몇몇의 노드는 조금 늦게 데이터의 일관성을 유지할 수 있음을 의미한다. 하지만 충분한 시간이 지나면 해당 데이터에 대하여 모두 다 일관성을 유지함을 의미한다. 즉, 일시적인 비일관성 상태를 용인하나, 일정 시간 이후에는 일관성을 보장하는 '지연된 일관성' 보장 속성을 의미한다.
* 일관성 C+ 생존성 P: 모든 노드가 함께 성능을 내며 일관성을 보장해야하는 유형으로, 데이터의 저장이나 분산 파일 시스템용으로 사용한다. 시스템 장애 시에는 일부 또는 전체 노드에서 응답을 받을 수 없음을 의미한다. (Google Bigtable, HBase등)
* 가용성A+생존성P: 비동기화 서비스에 특화된 데이터 스토어 유형, 장애 시에도 데이터를 받을 수 있지만, 데이터가 최신의 정확한 데이터라고는 보장하지 못한다 (Amazon Dynamo, Apache Cassandra등 )
NoSQL 데이터 베이스 모델, 시스템 제품군들의 특성과 내용
Key-Value Model
- key-value 기반의 단순하고 빠른 Get, Put, Delete 기능을 제공하는 모델로, 모든 NoSQL분류들의 가장 기초적인 모델이다.
- Key-value 데이터 모델은 매우 단순하면서도 매우 근본적이기 때문에 오히려 매우 강력한 모델이다.
- Key-value 모델의 가장 큰 단점은 Key(Range)범위 프로세싱이 필요한 경우에 있어, 그 적용이 제한된다는 것이다. 이러한 제한점을 극복한 것이 Ordered Key-Value 모델임
Ordered-key Value Model
- key-value 모델에서 Key 간의 순서에 따른 범위 검색뿐만 아니라, 순차 읽기 등의 지원으로 단일 데이터의 접근과 함께 특정 범위의 데이터 셋의 접근(range scan)을 지원하여 Key-value 모델보다 좀 더 향상된 기능의 제공이 가능하다
- Key-value, Order key-value 모델은 value에 관한 어떠한 모델링도 제공하고 있지 않기 때문에, 응용프로그램에서 직접적으로 value에 대한 모델링을 처리해야 한다. 이ㅣ러한 제한점을 부분적으로 극복한 것이 Big-table style의 데이터베이스 모델이다.
BigTable-Style Model
- Row행 기반의 관계형 데이터베이스와는 다르게 value에 있어 컬럼(column)을 기본 구성으로 한다.
- BigTable-Style 모델은 value 자체를 지속적으로 다차원적인 Map으로 구성한다. 다차원적이란느 말은 Map의 Map을 지원한다는 것이다.
Document Database Model
Document database 모델은 big table 모델과 비교하여 두가지의 개선점이 있다. Value 자체를 Map의 Map 형태만이 아닌 다양하고 임의적인 스키마를 사용할 수 있다. 두번째는 데이터베이스의 기본 인덱스 제공이다. 이러한 특성은 유연한 스키마와 자동화된 인덱스를 제공하는 엘라스틱 서치와 같은 풀텍스트 검색엔진과 유사하다고 할 수 있다. 이러한 검색엔진들과 DocumentDB 모델의 가장 큰 차이점은 인덱스를 필드이름으로 구성하는 반면, 검색엔진의 경우 인덱스를 필드값으로 구성함에 있다.
SON, XML, JSON 형태로 문서를 구조적으로 저장한다.
이러한 NoSQL 형태의 DB모델에 추가적인 인덱스 또는 세컨더리 인덱스를 제공하여 저장하고 있는 value에 대한 검색기능의 제공
Graph Data Model
- Graph Data Model은 근본적으로 Ordered key-value 모델에서 분화되어 진화해온 모델이다.
- Graph data Model은 MySQL과 같은 관계형 데이터베이스에서의 엔트리 속성을 노드로, 관계를 노드간 엣지로 표현하여 확장성이 높은 그래프 표현을 만들어 낸다.
NoSQL 모델링은 관계형 모델링과는 반대로, 어플리케이션 특징적인 쿼리들로부터 시작된다.
- 관계형 모델링은 전형적으로 가용한 데이터의 구조에 기반을 둔다. 데이터 모델링의 메인 테마는 '내가 가지고 있는 답은 무엇인가' 이다. 즉, 관계형 모델링에서는 데이터 모델이 정의한 이후에, 어플리케이션에 맞는 쿼리를 개발한다.
- NoSQL 데이터 모델링은 전형적으로 어플리케이션 특징적인 데이터 접근 패턴에 따라 모델링된다. 이때 모델링 메인 테마는 '내가 가지고 있는 질문이 무엇인가' 이다. 즉, NoSQL 모델링에서는 어플리케이션의 필요한 쿼리와 성능을 정의한 이후에, 그 요구사항에 부합하도록 데이터 모델을 구성한다.
- NoSQL 모델링은 관계형 데이터베이스 모델링 보다 더 깊은 데이터 구조 및 접근 알고리즘에 대한 이해가 요구된다. 본 장에서는 다양한 NoSQL에 실용적으로 적용 가능한 몇몇 데이터 구조에 대해서도 소개한다.
- 관계형 DB는 계층적 구조나 그래프 구조와 같은 데이터 모델을 저장하고, 처리하기에는 적합하지 못하거나 불편하다. 이러한 구조에 가장 적합한 것은 Graph Data Model이며, 다른 대다수의 NoSQL 솔루션들 역시 다양한 데이터 모델링 기법을 통하여 해결할 수있다.
Key-value Stores
- Amazon SimpleDB: 오픈소스 아님
- Azure Table Storage : 자유로운 형태의 엔트리구조(row Key, partition key, timestamp) 지원, 블라 및 큐 스토리지 지원, 3중 데이터 복제, REST나 ATOM을 통하여 접근 지원
- Codrdless : 언어지원(API) - Java / 프로토콜 - internal / 기반언어 -Java
- Redis: 언어지원(API) - 다양한 언어/ 기반언어 -C
- Scalaris: 기반언어 - Erlang
- GT.M: 언어지원(API)- C, Python, Perl/ 프로토콜- native, inprocessC
- Scalien: 언어지원(API): C, C++,Python/프로토콜- http(text, html, JSON)
- Berkeley DB: 언어지원(API) - 다양한 언어/ 기반언어 C
- Berkeley DB Java edition: 언어지원API - Java/기반언어 -Java
- MemcacheDB: 언어지원API - Memcache/프로토콜- get,set,add,replace, etc/ 기반언어-C
- NorthScale: Memcached 기반
- Pincaster: 언어지원(API) - HTTP, JSON/ 기반언어 C
그 외 : GenieDB, Mnesia, Tokyo Tyrant, LightCloud 등
Big-Table style Database
- HBase :언어지원(API) Java / 프로토콜 - any write call / 기반언어 - Java
- Cassandra: Thrift (Java,PHP, etc) 프로토콜 ,Trifit 기반언어 - Java
- Hypertable: Trift (Java, PHP, Perl, Python, Ruby, etc), 프로토콜- Thrift
- Cloudera: Professional software & service based on Hadoop
Document Database
- Couch DB : JSON/ REST/ Erlang base
- MongoDB: BSON(Binary JSON)/ 다양한 언어지원/C++
- Riak : JSON/ REST/ Erlang base
- Terrastore: Java & http/ http/ Java
- OrientDB: Java/ Java
Graph DB
- Neo4J: 다양한 언어 지원/ 프로토콜 Java REST/ JAVA base
- Sones: .NET/ .NET REST, WebServices/ C#
- InfoGrid: Java, Http, REST/ PRISO, OpenID, RSS, Atom, JSON, JAVA embedded/ Java
- HyperGraphDB: Java/ Java
- AllegroGraph: Java, Python, Ruby, C#, Perl, Clojure, Lisp/ REST/ CommonLisp
- Bigdata: Java/Java
- DEX: Java, Java embedded/ Java, C++
Full Text Search Engines: Apache Lucene, Apache Solr
NoSQL데이터 모델링의 기본적 원칙
(1) 비정규화
(적용성) Key-Value stores, Document Database, BigTable-style Database
비정규화는 데이터의 중복을 허용하라는 것이다. 즉, 쿼리 프로세싱을 간단히 또는 최적화하거나 사용자의 데이터를 특정한 데이터 모델에 맞추기 위하여 같은 데이터를 다중의 도큐먼트나 테이블에 복제하여 중복을 허용한다는 것이다.
비정규화는 trade-off가 있음..
* 쿼리당 I/O 또는 쿼리 데이터 사이즈 vs 전체 데이터 사이즈
비정규화를 통하면 쿼리를 수행하기 위한 모든 데이터를 한 곳에 모아 놓고 쿼리를 실행하기 때문에 쿼리 수행을 위한 전체I/O의 숫자 자체를 줄여 전체 성능을 향상 시킬 수 있다. 하지만, 해당 데이터는 다른 쿼리 수행을 위하여 다른 도큐먼트나 데이플에 중복 저장되기 때문에 전체 데이터 사이즈는 필연적으로 증가한다.
* 쿼리 수행의 복잡도 vs 전체 데이터 사이즈
데이터 모델링 시점에서 데이터 자체의 정규화(데이터 중복의 제거)나 쿼리 수행 시점에서 데이터 간 연속적인 조인(join)은 쿼리 프로세서의 복잡도를 증가시킨다. 더욱이 시스템과 데이터 사이즈가 큰 분산 환경에서는 그 복잡도가 더욱 더 높아진다. 정규화는 반대로 데이터를 비정규화하면 쿼리에 필요한 모든 데이터를 한곳(Document나 Table)에 쿼리-친숙한 구조로 모아 놓을 수 있기 때문에 전체적인 쿼리 프로세싱을 단순화하고 수행시간을 단축시킬 수 있다.
(2) 어그리게이션
(적용성): Key-Value Stores, Document Databases, BigTable-style Database
Key-value Store와 Graph Database의 경우 일반적으로 저장되는 value들과 데이터에 대하여 어떻나 제약조건을 가지고 있지 않기에 다양한 임의의 포맷들로 구성될 수 있다. 또한, Key를 디자인할 때, 조합키(Composition Key)를 활용하여 다수의 레코드들을 하나의 항목(entity)으로 구성할 수 있다. 예를들어, 사용자 계정은 어플리케이션 요구에 따라 다수의 엔트리를 포함한 하나의 조합키로 표현되어 하나의 도큐먼트나 테이블로 구성될 수 있다.
BigTable 모델은 Value 안의 다양한 컬럼 패밀리와 또 그 안에 복수 개의 컬럼의 셋을 통해 유연한 스키마를 제공한다.
Document Database는 태생적으로 Schema-less한 속성을 가진다.
'유연한 스키마 속성'은 복잡하고 다양한 구조의 내부 엔티니(nested entities)를 가지고 있는 데이터 클래스를 구성 가능하게 한다. 이러한 특징은 다음의 큰 이점을 제공한다.
* 다양한 구조의 내부 엔티티 지원으로 일대다 관계를 최소화하여 결과적으로 조인(Join)연산을 줄인다. 이는 곧 수행시간의 단축과 대용량 데이터의 지원을 저렴한 비용으로 가능하게 한다는 것을 의미한다.
* 하나의 도큐먼트 형태 또는 테이블 데이터 구조를 통하여 복잡하고 다양한 비지니스 엔티티들을 담을 수 있다. 이는 추후 확장성 및 변동성에 대한 유연한 대응을 가능케 한다.
'유연한 스키마' 속성은 '어그리게이션'된 하나의 데이터 모델에서 다양한 콘텐츠의 정보와 속성을 각각 자유롭게 담는 것을 가능케 하여, 추후의 각 데이터 유형의 변동과 서비스의 확장으로 인한 데이터 속성의 증가 및 재구조화를 유연하게 대처할 수 있다. 또한, 데이터 간의 JOIN을 최소함으로써 대용량 데이터에 대한 대응을 상대적으로 저렴한 비용으로 지원한다.
(3) 응용프로그램상의 조인
(적용성) Key-value stores, Document Database, BigTable-style DB, Graph DB
Nosql은 태생적으로 데이터 쿼리 타임시 JOIN을 고려하지 않으며, 오히려 많이 제약하는 편이다. NoSQL을 사용하여 데이터 스토어 구성 시에는 쿼리 타임 시 조인이 발생하지 않도록 데이터 모델에 대한 비정규화와 어그리게이션을 수행하여 구성함을 기본 전체로 하고 있다. 즉, NoSQL에서의 데이터 모델은 데이터 자체 간의 관계와 속성에 따라 구성하기보다는 해당 데이터를 이용하는 응용 프로그램이 그 데이터를 어떻게 이용(질의)하는 가에 따라 구조화되고 구성된다.