NoSQL이란 무엇인가?

인터넷 대중화에 이어 수년 전부터 SNS 서비스가 활성화되면서 컴퓨팅 시스템에도 변화가 찾아오기 시작했다.

NoSQL의 등장 배경
예전에 컴퓨팅 시스템은 기업 업무를 자동화하고 효율화하는 데 그 목적이 있었다. 그래서 기업의 복잡한 데이터를 저장하고 그 데이터 간의 관계를 정의하고 분석하는 데 최적화되어 있었다. 기업의 업무 시스템은 해당 기업의 생산과 판매를 지원하기 위한 것이었고 거기에서 생성되는 데이터양은 한계를 가지고 있었다.

그러나 2000년대에 들어서면서 인터넷의 발전과 함께 SNS 서비스가 활성화되면서 SNS 서비스 시스템은 특정 고객이 아닌 전 세계 사람들을 대상으로 하는 형태의 서비스로 발전되었고 이는 기존의 기업 시스템에서 볼 수 없었던 대규모 데이터를 생산해냈다. 또한 이 데이터들은 기존 기업 데이터에 비해 매우 단순한 형태를 띠게 되었다.

즉 데이터의 패러다임이 한정된 규모의 복잡성이 높은 데이터에서 단순한 대량의 데이터로 넘어가기 시작했다. 이는 기존의 데이터 저장 시스템으로는 커버할 수 없는 여러 가지 한계를 야기했고 결국에는 새로운 형태의 데이터 저장 기술을 요구하게 되었다.

이때 대표적인 인터넷 기업이면서 이러한 대용량 단순 데이터를 가장 많이 보유해 단순한 대용량 데이터 처리에 대한 요구가 가장 많은 구글과 아마존에 의해 빅테이블(Bigtable)과 Dynamo라는 논문이 발표되었고, 이 두 논문은 새로운 데이터 저장 기술을 만들어내는 시발점이 되었다.

이것은 기존의 오라클 등으로 대변되는 RDBMS 중심의 데이터 저장 기술 시장에 새로운 데이터 저장 기술인 NoSQL이 등장하는 계기였다. NoSQL은 Not Only SQL의 약자로 기존 RDBMS 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미한다. NoSQL이라고 해서 RDBMS 제품군(MS-SQL, Oracle, Sybase, MySQL) 등과 같이 공통된 형태의 데이터 저장 방식(테이블)과 접근 방식(SQL)을 갖는 제품군이 아니라 RDBMS와 다른 형태의 데이터 저장 구조를 총칭하며, 제품에 따라 각기 그 특성이 매우 달라서 NoSQL을 하나의 제품군으로 정의할 수는 없다.

NoSQL의 특징
그럼에도 불구하고 NoSQL은 기존 RDBMS에 비해 몇 가지 공통된 특징을 가지고 있다. 이를 정리하면 다음과 같다. 

● NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않는다
가장 큰 특징 중의 하나는 관계형 데이터베이스인 RDBMS가 데이터의 관계를 Foreign Key 등으로 정의하고 이를 이용해 Join 등의 관계형 연산을 한다고 하면, NoSQL은 데이터 간의 관계를 정의하지 않는다. 데이터 테이블은 그냥 하나의 테이블이며 각 테이블 간의 관계를 정의하지도 않고 일반적으로 테이블 간의 Join도 불가능하다.

● RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있다
RDBMS의 복잡도와 용량 한계를 극복하기 위한 목적으로 등장한 만큼, 페타바이트급의 대용량 데이터를 저장할 수 있다.

● 분산형 구조
NoSQL은 기존의 RDBMS와는 다르게 하나의 고성능 머신에 데이터를 저장하는 것이 아니라, 일반적인 서버(인텔 계열의 CPU를 사용하는 Commodity Server) 수십 대를 연결해 데이터를 저장 및 처리하는 구조를 갖는다. 즉 분산형 구조를 통해 데이터를 여러 대의 서버에 분산해 저장하고, 분산 시에 데이터를 상호 복제해 특정 서버에 장애가 발생했을 때에도 데이터 유실이나 서비스 중지가 없는 형태의 구조다.

● 고정되지 않은 테이블 스키마 

<표 1> RDBMS에서 간단한 테이블 구조 예제

RDBMS와는 다르게 테이블의 스키마가 유동적이다. 예를 들어 RDBMS의 경우 테이블이 <표 1>과 같은 형태로 되어 있을 때 해당 테이블은 반드시 숫자, 이름 문자열, 주소 문자열만 들어갈 수 있다.
그런데 NoSQL은 대부분 이런 개념이 없다. ID로 사용하는 키 부분에만 타입이 동일하고, mandatory(생략되지 않는) 필드로 지정하면 값에 해당하는 컬럼은 어떤 타입이든, 어떤 이름이 오든 허용된다. 즉 <표 2>와 같이 ID 필드는 공통이지만, 데이터를 저장하는 컬럼은 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용된다.

<표 2> NoSQL에서 테이블 설계 예제

CAP 이론

<그림 1> CAP 기반의 DB 분류

NoSQL은 분산형 구조를 띠고 있기 때문에 분산 시스템의 특징을 그대로 반영하는데, 그 특성 중의 하나가 CAP 이론이다. 이 이론은 2002년 버클리대학의 Eric Brewer 교수에 의해 발표된 분산 컴퓨팅 이론으로, 분산 컴퓨팅 환경은 Consistency, Availability, Partitioning 세 가지 특징을 가지고 있으며, 이중 두 가지만 만족할 수 있다는 이론이다. NoSQL은 대부분 이 CAP 이론을 따르고 있다(<그림 1> 참조).

- Consistency는 분산된 노드 중 어느 노드로 접근하더라도 데이터 값이 같아야 한다는 기능적 특징이다(데이터 복제 중에 Query가 되면, Consistency를 제공하지 않는 시스템의 경우 다른 데이터 값이 Query 될 수 있다).
- Availability는 클러스터링된 노드 중 하나 이상의 노드가 FAIL이 되더라도, 정상적으로 요청을 처리할 수 있는 기능을 제공하는 특징이다.
- Partition Tolerance는 클러스터링 노드 간에 통신하는 네트워크가 장애를 겪더라도 정상적으로 서비스를 수행할 수 있는 기능이다.

그래서 NoSQL을 선택할 때는 이 CAP 이론을 이해하고 해당 NoSQL 제품이 CAP 중 어느 두 가지 특성을 가지고 있는지를 파악한 후에 업무 특성에 맞게 선택해야 한다.

NoSQL의 분류
NoSQL은 데이터 저장 구조에 따라 다음과 같이 크게 세 가지 분류로 정의될 수 있다.

● Key/Value Store
가장 기본적인 패턴으로 대부분의 NoSQL은 다른 데이터 모델을 지원하더라도, 기본적으로 Key/Value의 개념을 지원한다. Key/Value Store란 Unique한 Key에 하나의 Value를 가지고 있는 형태를 이야기한다. Put(Key,Value), Value := get(Key) 형태의 API로 접근한다.

<그림 2> Key Value Store 데이터 구조

Value는 String이나 Integer와 같은 Primitive 타입이 될 수도 있지만, 이 정도로는 우리가 일반적으로 사용하는 테이블 형태의 데이터를 저장할 수 없다. 이런 까닭에 조금 더 확장된 개념을 사용하는데, 그것이 바로 Column Family라는 개념이다. Key 안에 (Column, Value) 조합으로 된 여러 개의 필드를 갖는데 이를 Column Family라고 한다.

<그림 3> Column Family 기반의 데이터 구조

예를 들어, 사용자 프로필을 저장하는 시나리오가 있을 때 사용자의 이름을 KEY로 한다면 성별, 주소, 나이들은 각각의 Column이 될 수 있다. Key 필드는 RDBMS에서 Primary Key, Column 필드들은 RDBMS의 일반 데이터 필드로 이해하면 된다. 프로그래밍 언어와 비교해서 생각한다면 Key/Value Store는 Map 데이터 구조와 유사하다.
Oracle Coherence나 Redis와 같은 NoSQL이 이 데이터 모델을 기본 모델로 사용한다.

● Ordered Key/Value Store
Key/Value Store의 확장된 형태로 Key/Value Store와 데이터 저장 방식은 동일하나, 데이터가 내부적으로 Key 순서로 Sorting되어 저장된다.

<그림 4> Ordered Key/Value Store의 테이블 구조

Sorting이 대수롭지 않은 것 같지만, NoSQL 관점에서는 대단히 중요한 기능을 제공하게 된다. 뒤에 데이터 모델링 기법에서도 다루겠지만, NoSQL은 RDBMS의 Order By와 같은 기능을 제공하지 않기 때문에 결과값을 업데이트 날짜 등으로 Sorting해서 보여주는 것은 이 Ordered Key/Value Store가 절대적으로 유리하다. 대표적인 제품으로는 아파치(Apache)의 HBase, Cassandra 등이 있다.

● Document Key/Value Store
Key/Value Store의 확장된 형태로, 기본적으로는  Key/Value Store이다. Key에 해당하는 Value 필드에 데이터를 저장하는 구조는 같으나, 저장되는 Value의 데이터 타입이 Document라는 타입을 사용한다. Document 타입은 MS 워드와 같은 문서를 이야기하는 것이 아니라 XML, JSON, YAML과 같이 구조화된 데이터 타입으로, 복잡한 계층 구조를 표현할 수 있다. 

<그림 5> Document Store 기반의 테이블 구조

아울러 Document Store 기반의 NoSQL은 제품에 따라 다르기는 하지만 대부분 추가적인 기능(Sorting, Join, Grouping 등)을 제공한다. 대표적인 제품으로는 MongoDB, CouchDB, Riak 등이 있다.

그리고 여기서는 구체적으로 다루지 않지만 Graph나 Tree와 같은 데이터 구조를 저장하기 위해 최적화된 Neo4J 등의 NoSQL이 있다. 만약에 테이블 구조의 데이터가 아니라 Graph 구조의 데이터를 저장하고자 한다면 Neo4J를 한번 고려해보길 바란다.

NoSQL 제품별 선호도
NoSQL 영역에는 수많은 제품이 있기 때문에 어떤 제품을 고를지는 매우 어려운 문제로 다가온다. 제품 특성이 유사하다 하더라도 교육은 쉬운지, 기술 지원은 가능한지, 오픈소스일 경우 지속적인 유지 보수 등은 가능한지를 판단해야 하는데, 다른 솔루션 선정과 마찬가지로 가장 손쉬운 판단 방법은 많이 쓰는 NoSQL을 고려하는 것이다. 

<그림 6> Indeed.com의 구인자 분포 결과 분석을 통한 NoSQL 선호도

<그림 6>은 미국의 구인 사이트 자료를 토대로 작성한 각 NoSQL 제품별 구인자 수 변화 추이다.

<그림 6>에서 보면 MongoDB가 제일 높고, Cassandra나 HBase가 그 뒤를 따른다. 그 다음으로는 Redis가 있으며 기타 NoSQL 제품들(Voldmort, Riak, CouchDB) 등이 따른다. MongoDB의 경우 RDBMS적인 특성을 가지고 있어서 기존 RDBMS 기반의 개발자들이 쉽게 적응할 수 있고 HBase나 Cassandra의 경우 대용량 데이터 저장과 성능 면에서 조금 더 유리하기 때문에 이런 추이를 보이는 것으로 판단된다.

NoSQL과 기존 RDBMS와의 차이
NoSQL이 DBMS라고 생각해서 RDBMS와 같은, 또는 떨어지지만 유사한 기능을 제공할 것이라고 생각하면 큰 오산이다. NoSQL은 데이터를 저장한다. 그리고 Key에 대한 Put/Get만 지원한다. RDBMS로 치면 다음과 같이만 딱 지원한다.

Put : Insert into TABLE VALUES(KEY,value1,value2,…,valuen)
Get : Select * from TABLE where KEY=”key”

물론 제품에 따라서 기능에 대한 지원 범위가 다르긴 하지만, 공통적으로 고민해야 하는 기능은 다음과 같다.

- Sorting (SQL의 Order By)
- Join (RDBMS에서 2개의 Table을 Foreign Key를 이용해 join)
- Grouping (SQL 문의 group by)
- Range Query (where key>“start” and key<“end”와 같이 일정 범위 내의 내용을 쿼리해오는 기능)
- Index (RDBMS에 Index를 지정해 select query 성능을 높이는 기능)

RDBMS에서는 너무나도 익숙하게 사용했던 기능들이기 때문에, 막상 이 기능들을 빼고 데이터를 다루고자 하면 매우 불편하다. 여기서는 이러한 기능들을 ‘NoSQL 데이터 모델링 패턴’ 소개를 통해 NoSQL에서 어떻게 구현할 수 있는지 알아볼 것이다.

NoSQL 사용시 주의할 점
NoSQL이 나온 지 수년이 지나긴 했지만, 특히 국내에서는 아직까지 NoSQL에 대한 경험이 매우 적은 편이다. 또한 NoSQL이라는 이름으로만 묶여 있지, 각 제품군에 따른 특성이 매우 다르기 때문에 특정 제품의 경험을 다른 제품에 적용하기도 매우 어렵다. 그럼에도 불구하고 최신 기술이라는 이름과 빅데이터라는 패러다임에 묶여 많이 검토되고 있는 게 지금의 상황이다. 그럼 NoSQL을 사용할 때 주의해야 할 점은 무엇일까?

● 과연 NoSQL이 필요한가?
먼저 NoSQL이 정말로 필요한지를 판단해야 한다. NoSQL이라는 새로운 기술과 제품군을 사용하려면, 그에 들어가는 교육과 개발 비용들이 결코 만만치 않다. 기존의 Oracle이나 MySQL과 같은 RDBMS를 사용해도 국내 대부분의 서비스는 구현이 가능하다. 데이터가 늘어나면 추가 RDBMS 클러스터를 추가해 용량을 증설하는 방법도 있다(카카오톡의 경우 MySQL을 사용해 서비스하고 있으며 여러 MySQL 인스턴스에 데이터를 분산해 저장하는 형태를 사용한다).

물론 여러 RDBMS에 걸쳐서 데이터를 저장하는 것보다는 NoSQL 클러스터 하나만 사용하는 것이 운영 등에 있어서 효율적이기는 하지만, 그만큼 만만하지 않다는 것이다. 

과연 현재 업무에 NoSQL이 적절한지 그리고 그 정도의 데이터 용량이 필요한지 판단해 볼 필요가 있다. 벤처에서 1억 명을 대상으로 한 서비스를 만들려고 시도할 때 NoSQL이 적합해 보이지만, NoSQL을 공부하는 데 시간이 들어가고 운영하면서 수많은 장애를 겪다 보면 사용자들은 다 떨어나갈지도 모른다. MySQL 등 기존의 익숙한 기술을 사용하다가 MySQL로 도저히 용량 감당이 되지 않을 경우에 NoSQL로의 전환을 고려하는 것은 어떨까? MySQL로 용량이 안 된다면 그때는 이미 사업이 성공했을 때이므로, NoSQL로 전환할 기술력이나 자금력도 충분할 것이다(실제로 페이스북도 MySQL로 서비스하다가 수년 전에 Cassandra로 전환했다).

● 적절한 NoSQL 제품군의 선정
앞서도 설명했지만, NoSQL은 RDBMS가 아닌 것의 약자이다. 즉 RDBMS만 아니면 모두 NoSQL이기 때문에 그 특성이 매우 다양하다. 따라서 각 NoSQL의 특성을 잘 파악하고 업무와 팀의 특성에 맞는 제품을 선정하는 것이 첫걸음인 셈이다.

예를 들어 Riak의 경우 기술 지원이 가능하며 2nd Index 및 Full Text Search가 지원된다. MongoDB의 경우에는 RDBMS와 유사한 기능을 가지고 있으므로 사용이 매우 편리하지만, 반대로 타 NoSQL에 비해 용량적인 한계를 갖는다. 

Cassandra의 경우, 구조적인 특성상 쓰기 성능(Write Performance)이 매우 우수하다. 이외에도 데이터가 Sorting이 되는지, Consistency 적용은 어떻게 되는지 등에 대해 이해한 후에 알맞은 NoSQL을 선택해야 한다.

● 데이터 모델링
NoSQL은 기본적으로 RDBMS와 다르다. 데이터 저장 방식도 다르고 기능도 부족하기 때문에, RDBMS처럼 데이터 모델링을 하면 100% 성능 문제가 생길 수밖에 없다.

RDBMS가 데이터 모델링에서부터 시작해서 정규화를 통해(중복 제거) 테이블을 만들어내고, 해당 테이블을 통해 쿼리를 수행해 결과를 뽑아낸다고 하면, NoSQL은 이와 정반대의 접근이 필요하다. 먼저 수행할 쿼리를 정의하고 이에 맞춰 데이터 테이블을 정의하고, 성능을 높이기 위해 일부로 중복을 허용해 테이블을 정의해야 한다.

사실상 NoSQL은 이 데이터 모델링이 설계의 90%라고 봐도 된다. NoSQL의 데이터 모델링에 대해서는 이어지는 2부에서 자세히 설명하기로 하겠다.

● RDBMS와 적절한 혼합
NoSQL은 데이터를 저장하기는 하지만, 복잡한 데이터 저장이나 쿼리에는 한 없이 부족하다. 대용량 데이터를 빠르게 저장 및 쿼리하는 데 최적화된 기술이지만, 서비스 시스템에는 당연히 복잡한 데이터도 있고 관계 정의가 필요한 경우도 있다. NoSQL을 사용할 때는 모든 데이터를 NoSQL에 저장할 생각을 하는 것보다는 인덱스성 데이터나 복잡한 쿼리가 필요한 데이터는 RDBMS에 저장하고, 실제 데이터 등을 NoSQL에 저장함으로써 RDBMS와 NoSQL을 적절하게 혼합해 사용토록 설계하는 것이 좋다.

● 하드웨어 설계 병행
NoSQL을 사용할 때는 처음부터 하드웨어 설계를 병행하는 것이 좋다. 디스크 RAID 구성은 할 것인지 말 것인지, 한다면 어떤 RAID 구성을 할 것인지 등을 고려한다. 

그리고 NIC, 데이터 트래픽을 위한 부분과 관리(management)를 위한 부분을 물리적으로 분리하는 것이 좋으며, 대역폭은 1G를 사용할 것인지 10G를 사용할 것인지도 결정해야 한다. 또한 물리적인 디스크 수에 따라 성능 변화가 많은 만큼 같은 용량이라도 몇 개의 디스크를 사용할 것인지 등에 대해서도 고민해야 한다. 따라서 NoSQL 제품을 결정하고 하드웨어를 도입하기 전에 레퍼런스를 충분히 검토하고 PoC(Proof of Concept)를 거쳐야 한다.

● 운영 및 백업
RDBMS를 운영하면 DBA가 당연히 따라 붙는다. NoSQL도 DB인 만큼, 당연히 운영과 관리를 위해 administrator가 필요하다. 일반적인 WAS(톰캣과 같은 웹서버)에 비해 복잡도가 훨씬 높고 분산되어 있으며 하드웨어까지 함께 관리 및 관제해야 하기 때문에 반드시 전문적인 administrator가 있어야 하며, 시스템에 대한 체계적인 모니터링 방안 등의 운영 체계가 수립돼야 한다.

특히 NoSQL의 용량을 증설할 때는 단순히 서버만 증설해서 되는 제품도 있지만, 대부분은 기존 서버에 새로운 서버를 포함해서 데이터를 재분배시키는 등의 작업이 필요하다. 이러한 작업은 철저한 사전 연습과 경험이 없으면 운영 과정에서 데이터를 유실할 우려가 있으므로 증설에 대한 운영 정책을 가지고 있어야 한다. 

NoSQL이 분산 및 복제 구조를 통해 데이터의 안정성을 보장하지만 앞에서 언급한 바와 같이 운영상의 실수 또는 데이터센터 자체의 장애(특히 클라우드 사용시)로 데이터가 유실되는 경우가 발생할 수 있으므로 백업에 대한 방안도 똑같이 고려돼야 한다.

지금까지 NoSQL에 대한 개념과 특징 등을 설명했다. NoSQL은 대용량의 데이터를 빠르고 안전하게 저장할 수 있다는 점에서 분명히 훌륭한 기술이기도 하지만, 그만큼 기술적인 난이도가 높고 다루기가 쉽지 않다. NoSQL은 절대 ‘은탄환(Silver Bullet)’과 같은 특효약이 아니다. 반드시 제대로 된 이해와 철저한 준비가 있어야만 사용할 수 있는 기술이다.

[출처] 마이크로 소프트웨어 

2014/02/20 - 프로그램 개발에 유용한 3종 셋트 사이트

2014/02/12 - 자바 Spring3.x 스케줄링

2014/02/12 - 자바스크립트