NoSQL이 등장하게된 계기는, 기존 RDBMS는 구조상 분산처리에 적합하지 않았습니다. 데이터베이스를 분산 저장하는 샤딩이라는 기술이 있지만, 어플리케이션 레벨에서 직접 구성해야 했기 때문에 번거로웠고, 다른 방법인 오라클의 공유 디스크 기술의 경우에는 라이선스 문제가 있었습니다. 또한 하드웨어의 성능을 증가시키는 scale-up 확장방식에 적합하였기 때문에 장비수를 늘리는 scale-out 방식을 사용할 수 없어 비용부담이 컸습니다. 두번째로 SNS등의 발전으로 처리할 데이터가 폭발적으로 증가하고, 데이터의 형식은 예측할 수 없어 스키마가 정해져있는 기존 관계형 데이터베이스를 대체할 방법이 필요했습니다. 세번째로, RDBMS 시장은 주로 오라클과 마이크로소프트, IBM같은 상용 DBMS가 대부분 차지하고 있는 상황이여서, Mysql과같은 오픈소스의 선택지가 넓은 NoSQL을 고려하게 되었습니다. 기존의 RDBMS와 NoSQL에 대해 정리한 표 입니다. 가장 큰 차이는 각각 ACID와 BASE특성을 갖고 있다는 점과 schema 구조의 유연성의 차이, 하드웨어 업그레이드 방식의 수직적 확장에 의존하는 RDBMS와는 달리 NoSQL 수평적 확장이 가능하고, noSQL은 데이터를 저장할 때의 형식에 의존하지 않습니다. 또한 NoSQL은 집합 단위로 데이터가 저장됩니다. 그럼 특징을 하나씩 살펴보겠습니다. 우선 기존 RDBMS부터 알아보자면 각각 트랜잭션이 무조건 다 완료되거나 다 실패한다는 ATOMICITY(원자성), 트랜잭션이 데이터의 일관성(공통되는 특징)에 영향을 끼치면 안된다는 CONSISTENCY(일관성) , 트랜잭션이 순차적으로 동시에 한개씩 실행됨을 보장하는 ISOLATION(독립성), 트랜잭션의 결과가 영구히 남아있어야 한다는 DURABILITY(지속성) 4개의 특성 ACID라고 하고, 이 특성을 기반으로 두고 있습니다. 이와 반대로 NoSQL은 기본적으로 시스템이 언제나 사용할 수 있는 상태로 유지될 수 있도록 지원하는 availability, 아래 eventually consistency를 위해 input 없이도 시스템 상태가 바뀔 수 있다는 soft-state, 입력 당시엔 일관성이 유지된 상태가 아니지만, 특정 상황엔 일관성이 유지된 상태가 된다는 Eventually consistency 총 3개의 특성 BASE라 하고, 기반으로 두고 있습니다. RDBMS와의 가장 큰 차이점은 noSQL같은 경우 무조건적으로 일관성을 보장하지 않습니다. 지금까지의 RDBMS와 다른 특징 데이터에 일관성이 보장되지 않아도 되고, 데이터 타입이 고정되지 않고 유연하며, 확장성이 좋다라는 특징 덕분에 빅데이터 처리에 유리합니다. NoSQL은 아직 제품군이 제대로 정의되지 않았고, 제품 각각의 특성이 있기에 CAP 이론을 기반으로 제품을 구분합니다. Consistency는 모든 사용자가 서로 같은 시점의 데이터를 볼 수 있어야 한다는 특성, Availability는 시스템이 항상 작동해야 한다는 특성, 세번쨰 Tolerance to Network Partitions는 각각의 분산처리를 위해 나눠진 노드끼리 메시지 손실이 일어날 수 있다는 특성입니다. 1,2번째 특성의 경우 분산 시스템의 특성이지만, 3번째 P의 경우 네트워크 구성에 관련한 특성이고, 장애가 없는 네트워크란 존재하지 않기 때문에 모든 nosql 제품은 P를 택하게 됩니다. 즉, 네트워크 장애 상황(P)가 일어나면 A와 P중 무엇에 가중치를 두느냐의 차이입니다. 아까의 CAP는 P를 포함(즉, 장애가 있다는 상황)을 전제로 계산하기 때문에, 이를 개선하여 장애가 존재할시(partitio일시) Availability와 Consitency를, 일반 상황에선 consistency 와 latency 중 하나에 우선순위를 두어 제품군을 나누도록 권장하고 있습니다. NoSQL 제품을 큰 범위로 나누자면 집합지향 모델과 그래프 모델로 이루어져 있습니다. 주로 집합지향 모델이 채택되고, 각각 키-밸류 형식, 도큐먼트 형식, 컬럼패밀리 방식으로 나눠집니다. 그래프 모델은 기존 RDBMS와 비슷한 특성을 가지고, 클러스터링에 적합하지 않으며 특수한 상황에만 사용됩니다. NoSQL은 주로 aggregate이라는 단위를 씁니다. 오른쪽이 기존 관계형 데이터베이스가 값을 저장하는 방식이라면, 왼쪽에는 의미있는 단위로 값을 묶어 한번에 저장합니다. 이 방식으로 인해 여러 큰 클러스터에 값을 저장하는데 유리하고, 질의가 빨라집니다. 또한 하나의 집합이 하나의 노드에 저장됨을 보장합니다. Agreegate oriented 모델 방식 중 Key-value oriented 방식은 Key값과 value값이 1대1로 매칭되는 가장 간단한 방식입니다. Put,get,delete 정도의 단순한 쿼리만 지원하고, 키로만 값을 찾아올 수 있습니다. value에는 들어가는 값의 형식을 제한하지 않습니다. 이 방식을 사용한 DB로는 aws dynamodb, redis가 있습니다. Column family stores 방식은 하나의 키에 여러 컬럼을 묶어놓은 column family를 저장하는 방식으로 여러 개의 데이터를 한번에 저장할 수 있습니다. 이 방식을 사용한 db는 Cassandra, apache hbase가 있습니다. DOCUMENT DATABASE 방식은 키와 – json, xml 등의 구조화된 데이터 형식으로 저장됩니다. 다른 도큐먼트 query languag를 사용시 도큐먼트 안의 데이터도 질의 가능합니다. 이 방식을 사용한 DB로는 mongoDB, CouchDB가 있습니다. NoSQL은 RDBMS의 데이터 분석 – 테이블 디자인 – 쿼리 디자인 방식과 다르게 데이터 분석 – 쿼리 디자인 – 테이블디자인의 순서로 모델링합니다. 감사합니다.

1. NOT ONLY SQL
ebong2.org

2. 1. 기존 RDBMS는 클러스터에 적합하지 않음
2. 비구조적 데이터의 양이 폭발적으로 증가함
(ex. SNS게시글)
3. 대부분 오픈소스임
왜 등장했을까?

3.  ACID의 성질을 가짐
 제한적인 Schema 구조
 수직적 확장(Scale-up) 확장에 의존
 모든 데이터가 같은 속성을 갖고 있어야 함
 튜플과 같은 단순한 형식의 데이터 저장
 BASE의 성질을 가짐
 유연한 Schema 구조(schema-less)
 수평적 확장(Scale-out) 확장 가능 (분산처리)
 데이터가 각각 다른 형식을 갖고 있어도 상관 없음
 집향 지향 (Aggregation Oriented)
 데이터 그래프 모델
차이점 비교
RDBMS NoSQL

4. Atomicity
Each transaction be “all or nothing”
Consistency
Transaction will bring the database from one valid state to another
Isolation
transactions were executed sequentially, one after the other
Durability
transaction has been committed, it will remain so, even
the event of power loss, crashes or errors.
ACID

5. Basically Available
The system does guarantee availability.
Soft-State
The state of the system may change over time, even without input.
Eventually consistency
The system will become consistent over time,
given that the system doesn’t receive input during that time.
BASE

6. ACID / BASE
일관성이 중요하지 않음
데이터 타입이 고정되지 않음
확장성이 좋음
빅데이터 처리에 유리
(대용량 로그 분석,
SNS 게시글,
데이터 마이닝)

7. CAP
Consistency
after an update operation all client see the same data
Availability
System is always on
Tolerance to network Partitions
The network will be allowed to lose arbitrarily many
messages sent from one node to another
->네트워크 장애 상황 중
일관성과 가용성 중 하나만 선택이 가능하다

8. PACELC

9. NOSQL의 모델별 분류
Key-value
Document
Column-family
Aggregate-oriented
Key-value
Document
Column-family
Grpah

10. AGREEGATE ORIENTED

11. KEY-VALUE ORIENTED

12. COLUMN FAMILY ORIENTED

13. DOCUMENT ORIENTED

14. 데이터 모델링

15. 참고
NoSQL에 대해서 간단히 알아보자! :http://blog.embian.com/6
AggregateOrientedDatabase : https://martinfowler.com/bliki/AggregateOrientedDatabase.html
NoSQL 데이타 모델링 #1-데이타모델과, 모델링 절차 : http://bcho.tistory.com/665
NoSQL : https://namu.wiki/w/NoSQL
NoSQL과 SQL : https://docs.microsoft.com/ko-kr/azure/documentdb/documentdb-nosql-vs-sql
CAP Theorem, 오해와 진실 : http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem
NoSQL 간단한 소개: http://www.slideshare.net/WonchangSong1/no-sqlsimpleintro