NoSQL RDBMS의 한계를 극복하기 위하여 만들어진 새로운 형태의 Database 패러다임이다

기존의 관계형 데이터베이스와 다르게 고정된 스키마 및 JOIN이 존재하지 않으며 트랜잭션의 개념이 존재하지 않는다.


NoSQL은 초당 데이터가 수십만개씩 쌓이는 소셜 서비스들 및 Massive 한 규모의 트랜잭션을 다루는 웹서비스들이 많아지면서 그 사용량이 많아지고 있다.

기존의 RDBMS의 경우 Read 집약적인 서비스에서 강하지만 큰 규모의 서비스임에도 Write가 많은 서비스의 경우 성능 저하가 눈에 띄게 되고 이는 서비스의 불안정을 초래할 수 있다


NoSQL은 스키마 자체를 없애면서 데이터의 정형성은 보장하지 못하는 대신 데이터의 정형성을 위해 RDBMS가 희생하는 분산처리의 장점을 살린다

(RDB의 경우 규격화된 스키마 때문에 ACID 를 고려한 분산이 쉽지 않다.)


NoSQL 모델의 종류로는 Key/Value Store, Wide Column Store, Document Store 가 있다.


-  Key/Value Store 는 거의 모든 종류의 NoSQL 이 지원하는 개념으로 Key에 대한 Value를 저장하는 개념이다. Value Primitive 타입이 될 수도 있지만 Column Family라 불리는 Column, Value 페어의 컬렉션이나 Object가 된다. Redis가 이러한 모델이다.


-  Ordered Key/Value Store Key/Value Store와 데이터 저장 방식은 동일하나 내부적으로 Key Sorting한다. HBase, Cassandra 가 있다.


-  Document Key/Value Store  Key/Value Store와 같지만 Value 값에 Object와 같은 복잡한 형태가 들어갈 수 있다. MongoDB, CouchDB등이 있다.



NoSQL RDB로 대표되는 SQL의 장점을 흡수하기 위한 테크닉들이 있다

이는 아무리 NoSQL 이 기존 RDB의 한계를 뛰어넘고자 고안된 모델이라 할지라도 관계형 데이터베이스가 갖는 데이터의 무결성과 관계지향 모델이 갖는 장점을 무시할 수 없다는 것을 의미하기도 한다.


(1)  Atomic aggregation : 두개 이상의 테이블을 업데이트할 때 트랜잭션 관리가 트랜잭션이 없는 NoSQL에서는 문제가 될 수 있다. 이럴 때 NoSQL을 사용하는 테크닉은 기능별로 테이블을 묶는 것이다. 예를들어 유저 정보를 갱신할 때 유저의 주소 정보와 프로필 정보를 동시에 갱신을 한다면 주소 정보와 프로필 정보를 유저 하위로 밀어넣어서 한번에 처리하게끔 한다.


(2)  Index : 일부 NoSQL 제품의 경우 Index를 지원하지만 그렇지 않은 경우 Key에 대한 Value를 검색하는 경우가 아니라면 Full Scan을 하게 된다. 이를 해결하기 위한 테크닉으로 인덱스를 위한 별도의 인덱스 테이블을 만드는 방법이 있다. 알고자 하는 항목에 대한 Key를 인덱스 테이블에 담아두어 한번에 참조가능하게 할 수 있다.


(3)  계층형 구조 : 데이터 모델링을 하다보면 Tree와 같은 계층형 모델이 필요한 경우가 있다. NoSQL에서는 이를 해결하기 위해 몇가지 설계를 이용한다.

     첫번째는 계층형 구조 자체를 아예 별도의 테이블 형태로 관리하는 것이다.

     ((ex) key : root – {parent: NULL, child: test}, key: test – {parent:root, child:NULL} => 이 경우 Tree 구조 순회에 많은 IO를 소모한다.) 

     또는 키 자체를 경로로 잡는 경우가 있다. ((ex) key: root -  value: object, key: root/test – value : object2 => 가장 무난하다.) 

     혹은 Leaf Node에만 데이터를 저장하고 줄기 노드에는 경로만을 저장하는 Nested Set 방식이 있다.


 위와 같이 NoSQL은 간단한 사용 인터페이스와 Insert에서의 이점 및 분산환경에서의 손쉬운 이식이라는 장점을 얻는 대신 데이터 모델링이 작업의 주가 된다

웹서비스에 새로운 시스템으로 NoSQL을 도입하고자 한다면, 기존의 전통적인 개체 지향 모델링에서 쿼리 지향 모델링으로 변경해야 하고 정규화를 역정규화로 바꾸는 노력이 필요하다


구조가 단순하지만 부족한 부분이 분명 있기 때문에 실무에서는 데이터의 정합성이 중요하고 복잡한 처리가 필요하거나 SELECT 집약적인 데이터에 대하여 RDB Cache 솔루션과 같이 사용하고, 분산처리 및 INSERT 집약적인 확장성 요청이 많은 경우 NoSQL 을 고려한 설계를 통해 혼용해서 쓰는 것이 Best이다.



* NoSQL은 분산형 구조를 띄고 있는 만큼(Schemeless) CAP의 특성을 지닌다.


Consistency : 분산된 노드 중 어느 노드로 접근하더라도 데이터 값이 같아야 한다는 기능적 특징이다.


- Availability : 클러스터링된 노드 중 하나 이상의 노드가 실패하더라도 정상적으로 요청을 처리할 수 있어야 한다.(Failover)


- Partition Tolerance : 클러스터링 노드 간의 네트워크 장애가 나더라도 정상적으로 서비스가 수행가능해야 한다.

 


+ Recent posts