[Database] NoSQL

NoSQL (Not Only SQL)

: 기존 관계형 DBMS가 갖고 있는 특성뿐만 아니라 다른 특성들을 부가적으로 지원함

2000년 후반으로 넘어오면서 인터넷이 활성화되고, 소셜네트워크 서비스 등이 등장하면서 관계형 데이터 또는 정형데이터가 아닌 데이터, 즉 비정형데이터라는 것을 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 데이터 베이스들이 관심을 받게 되었고, 해당 기술이 점점 더 발전하게 되면서, NoSQL 데이터베이스가 각광을 받게 된 것입니다. 이러한 배경하에서 어떤 엔지니어들은 NoSQL을 Modern web-scale databases라고 정의하기도 합니다.

 

특징

• 기존의 관계형 데이터베이스 보다 더 융통성 있는 데이터 모델을 사용, 데이터의 저장 및 검색을 위한 특화된 매커니즘을 제공
• 관계형 모델을 사용하지 않으며 테이블간의 조인 기능 없음
• 직접 프로그래밍을 하는 등의 비SQL 인터페이스를 통한 데이터 액세스
• 대부분 여러 대의 데이터베이스 서버를 묶어서(클러스터링) 하나의 데이터베이스를 구성
• Schema-less (스키마 없이 동작), 구조에 대한 정의를 변경할 필요 없이 데이터베이스 레코드에 자유롭게 필드를 추가 가능
• 데이터베이스의 중단 없는 서비스와 자동 복구 기능 지원
• 다수가 Open Source로 제공

 

종류

1. Key-value
2. Document
3. Column-family
4. Graph

 

1. Key - value

특징	가장 단순한 형태의 NoSQL으로, 데이터가 키와 값의 쌍으로 저장된다. 키는 값에 접근하기 위한 용도로 사용되며, 값은 어떠한 형태의 데이터라도 담을 수 있다.
장점	간단한 API를 제공하는 만큼 질의의 속도가 굉장히 빠른 편이다. 수평적 확장이 용이하다.
단점	값의 내용을 사용한 쿼리가 불가능하다.
사용되는 DB	Memcached, Riak, Redis, Amazon Dynamo DB, LevelDB

 

2. Document

특징	데이터는 키와 도큐먼트(Document)의 형태로 저장된다. 키-값 모델과 다른 점이라면 Value가 계층적인 형태인 도큐먼트로 저장된다는 것이다. 객체지향에서의 객체와 유사하며, 이들은 하나의 단위로 취급되어 저장된다. 다시 말해 하나의 객체를 여러 개의 테이블에 나눠 저장할 필요가 없어진다.
장점	객체-관계 매핑이 필요하지 않다. 객체를 도큐먼트의 형태로 바로 저장 가능하기 때문이다.
단점	사용이 번거롭고 쿼리가 SQL과는 다르다. 도큐먼트 모델에서는 질의의 결과가 JSON이나 xml 형태로 출력되기 때문에 그 사용 방법이 RDBMS에서의 질의 결과를 사용하는 방법과 다르다.
사용되는 DB	MongoDB, CouchDB, MarkLogic

 

3. Column-Family

특징	키에서 필드를 결정한다. 키는 Row(키 값)와 Column-family, Column-name을 가진다. 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가진다. 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능하며, 질의는 Row, Column-family, Column-name을 통해 수행된다.
장점	클러스터링이 쉽게 이뤄지며, Time stamp가 존재해 값이 수정된 히스토리를 알 수 있다. 또한 값들은 일련의 바이너리 데이터로 존재하기 때문에 어떤 형태의 데이터라도 저장될 수 있다.
단점	Blob 단위의 쿼리가 불가능하며, Row와 Column의 초기 디자인이 중요하다. Schema-less이긴 하지만 새로운 필드를 만드는 데 드는 비용이 크기 때문에 사실상 결정된 스키마를 변경하는 것이 어렵다.
사용되는 DB	HBase, Cassandra, Hypertable

 

4. Graph

특징	실제 세계의 데이터를 관계와 함께 표현하기 위해 디자인된 모델로써, 데이터는 연속적인 노드, 관계, 특성의 형태인 그래프 형태로 저장된다. 따라서 질의는 그래프 순회를 통해 이루어진다. 관계형 모델이라고 할 수 있으며, 데이터 간의 관계가 탐색의 키일 경우에 적합하다. 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터베이스로 적합하다. 또한 집합 지향 모델과는 다르게 개체의 ACID 트랜잭션을 지원한다.
단점	클러스터링에는 적합하지 않다. 또한 질의 언어도 특화되어 있어 배우기 어렵다.

 

의의

NoSQL이 RDBMS를 대체할 수 있을 것이라고는 생각하지 않는다. 그러기에는 RDBMS가 가진 장점이 너무나 명확하고, 또한 많은 사람들이 RDBMS을 사용하는 데 익숙해져 있기 때문이다. 그럼에도 불구하고 NoSQL이 각광받고 있는 까닭은 NoSQL만의 장점이 뚜렷하기 때문이다.

예를 들어 구매 내역이나 게임의 로그 같은 데이터들은 매 초마다 엄청난 양이 생성되지만 한번 저장되고 난 뒤에는 수정될 일이 거의 없다. 이런 데이터들을 저장하는 데 데이터의 일관성을 보장하기 위해 ACID 트랜잭션을 지원할 필요는 없을 것이다. 거기다 생성되는 데이터의 양도 많기 때문에 장비의 성능에도 상당한 영향을 미칠 것이다. NoSQL은 이러한 데이터들을 효율적으로 저장할 수 있다. 여러 대의 장비에 빠른 속도로 저장이 가능하며, 데이터의 양이 누적되더라도 얼마든지 수평적 확장이 가능하기 때문이다.

실제로 소셜 네트워크 서비스에서는 게시글들을 저장하는 데 NoSQL 데이터베이스를 사용하고 있다. 매 초에 수백 기가~수 테라 바이트씩 생성되는 데이터들을 RDBMS를 사용해 저장한다면, 글 작성 버튼을 누른 후 글이 중앙 데이터베이스에 저장되기까지 한참을 기다려야 글을 성공적으로 게시할 수 있을 것이다. 하지만 NoSQL의 분산 데이터베이스를 사용한다면 부하가 분산되기 때문에 우리가 글쓰기 버튼을 누르고 한참을 기다릴 필요가 없게 된다.

또한 각종 검색 엔진에도 사용되는 것이 NoSQL인데, 웹 페이지 내의 텍스트들을 형태소 단위의 토큰으로 분리하여 토큰과 해당 토큰이 포함된 페이지들의 URL을 맵핑하는 Inverted Index(역 인덱스) 구조를 NoSQL을 통해 구현한다. 이런 기능을 일반적인 RDMBS로 구현했을 경우 검색 창에 단어를 입력했을 때마다 상당한 시간이 소요될 것이다.

C++, Java, Python 등 여러 언어를 사용해서 하나의 프로그램을 만들 수 있는 것처럼 데이터베이스 역시 다양한 저장소를 사용할 수 있게 되었다는 점에서 NoSQL의 의의는 크다고 볼 수 있다.