Computer >> 컴퓨터 >  >> 소프트웨어 >> 소프트웨어

NoSQL 데이터베이스 완전 정리: 개념, 유형, 주요 제품부터 미래 전망까지

'NoSQL'이라는 용어는 1998년 처음 만들어졌습니다. 많은 사람이 NoSQL을 SQL을 흉보려고 만든 경멸적인 표현으로 오해하지만, 실제 의미는 'Not Only SQL(단지 SQL만이 아닌)'입니다. 즉, 두 기술은 대체 관계가 아니라 공존하며 각자의 역할을 수행할 수 있다는 발상입니다. 지난 몇 년간 웹 2.0을 주도한 기업들이 NoSQL 기술을 대거 도입하면서 NoSQL은 큰 주목을 받았습니다. 페이스북, 트위터, 디그(Digg), 아마존, 링크드인, 구글 등이 모두 다양한 형태로 NoSQL을 활용하고 있습니다. 이 글에서는 NoSQL을 쉽게 풀어 설명해 CIO에게, 혹은 동료에게 자신 있게 소개할 수 있도록 정리했습니다.

NoSQL은 왜 등장했을까?

폭발적으로 늘어나는 데이터 저장 수요

전 세계에 저장된 디지털 데이터의 양은 엑사바이트(exabyte) 단위로 측정됩니다. 엑사바이트는 10억 기가바이트(GB)에 달하는 어마어마한 단위입니다. 인터넷닷컴(Internet.com)에 따르면 2006년 한 해에 새로 저장된 데이터의 양은 161엑사바이트였고, 불과 4년 뒤인 2010년에는 약 1,000엑사바이트에 이를 것으로 예상돼 500% 이상의 증가율을 기록했습니다. 참고로 오늘날 전 세계 데이터 총량은 엑사바이트의 1,000배인 자바이트(zettabyte) 규모를 훌쩍 넘어섰습니다. 세상에 저장되는 데이터는 앞으로도 계속 증가할 수밖에 없습니다.

서로 연결되는 데이터

데이터는 점점 더 긴밀하게 연결되고 있습니다. 웹의 등장으로 하이퍼링크가 보편화됐고, 블로그에는 핑백(pingback)이 생겼으며, 모든 주요 소셜 네트워크는 콘텐츠를 서로 묶어 주는 태그 시스템을 갖추고 있습니다. 현대의 대규모 시스템은 처음부터 상호 연결을 전제로 설계됩니다.

복잡해지는 데이터 구조

NoSQL은 계층형 중첩 데이터 구조를 손쉽게 처리할 수 있습니다. 같은 작업을 SQL로 수행하려면 각종 키로 얽힌 여러 개의 관계형 테이블이 필요합니다. 게다가 성능은 데이터 복잡도와 밀접한 관련이 있습니다. 소셜 네트워킹 애플리케이션처럼 대규모 데이터를 저장해야 하는 환경에서는 전통적인 RDBMS의 성능이 저하될 수 있습니다.

NoSQL이란 무엇인가?

NoSQL을 정의하는 한 가지 방법은 'NoSQL이 아닌 것'부터 생각해 보는 것입니다. NoSQL은 SQL이 아니며, 관계형 모델도 아닙니다. 이름 그대로 RDBMS를 대체하는 것이 아니라 보완하는 기술입니다. NoSQL은 초대규모 데이터 처리를 위한 분산 데이터 저장소(distributed data store)를 위해 설계되었습니다. 사용자 5억 명을 보유한 페이스북이나 매일 테라비트 단위의 데이터를 쌓아 가는 트위터를 떠올리면 쉽게 이해할 수 있습니다. 참고로 현재 페이스북의 사용자 수는 30억 명을 넘어섰습니다.

NoSQL 데이터베이스에는 고정된 스키마도, 조인(join)도 없습니다. RDBMS가 더 빠른 하드웨어와 더 많은 메모리를 장착하는 '스케일 업(scale-up)' 방식으로 확장한다면, NoSQL은 '스케일 아웃(scale-out)' 방식을 활용합니다. 스케일 아웃이란 부하를 여러 대의 범용(commodity) 서버에 분산시키는 것을 말합니다. 바로 이 특성 덕분에 NoSQL은 대용량 데이터를 저렴하게 처리할 수 있는 솔루션이 됩니다.

NoSQL의 4가지 주요 유형

현재 NoSQL 생태계는 크게 네 가지 범주로 나눌 수 있습니다.

  1. 키-값 저장소(Key-Value Store): 2007년 아마존이 발표한 'Dynamo 논문'에 기반을 둔 모델입니다. 고유한 키(key)와 특정 데이터 항목을 가리키는 포인터로 이루어진 해시 테이블 구조가 핵심이며, 성능을 극대화하기 위해 캐시 메커니즘이 함께 사용되는 경우가 많습니다.
  2. 컬럼 패밀리 저장소(Column Family Store): 여러 머신에 분산된 대량의 데이터를 저장하고 처리하기 위해 고안되었습니다. 키가 존재한다는 점은 키-값 저장소와 비슷하지만, 하나의 키가 여러 컬럼을 가리킵니다. 구글의 BigTable이 대표적이며, 행(row)은 로우 키(row key)로 식별되고 데이터는 이 키를 기준으로 정렬·저장되며, 컬럼은 컬럼 패밀리(column family) 단위로 배치됩니다.
  3. 문서 데이터베이스(Document Database): 로터스 노츠(Lotus Notes)에서 영감을 받았으며 키-값 저장소와 유사한 면이 있습니다. 문서의 버전을 관리하는 모델로, 문서는 다른 키-값 컬렉션들의 집합으로 구성됩니다. 반정형 문서는 주로 JSON 같은 형식으로 저장됩니다.
  4. 그래프 데이터베이스(Graph Database): 노드(node), 노드 간 관계(relationship), 노드의 속성(property)으로 구성됩니다. SQL의 행과 열로 이루어진 경직된 테이블 구조 대신 유연한 그래프 모델을 사용하며, 여러 머신에 걸쳐 확장할 수 있습니다.

대표적인 NoSQL 제품

NoSQL의 주요 기술들은 해당 기술을 도입한 조직들을 통해 알려지게 되었습니다. 대표적인 NoSQL 제품은 다음과 같습니다.

  • Dynamo: 아마존닷컴이 개발한 가장 잘 알려진 키-값 NoSQL 데이터베이스입니다. 전자상거래 사업에 필요한 고확장성 분산 플랫폼이 절실했던 아마존이 직접 만들었으며, 아마존 S3가 스토리지 메커니즘으로 활용하고 있습니다.
  • Cassandra: 페이스북이 오픈소스로 공개한 컬럼 지향(column-oriented) NoSQL 데이터베이스입니다.
  • BigTable: 구글의 독점적(proprietary) 컬럼 지향 데이터베이스입니다. 구글이 사용을 허용하되 Google App Engine에서만 사용할 수 있습니다.
  • SimpleDB: 아마존의 또 다른 데이터베이스로, Amazon EC2 및 S3와 함께 사용되며 사용량 기반 과금이 적용되는 AWS(Amazon Web Services) 서비스의 일부입니다.
  • CouchDB: MongoDB와 함께 대표적인 오픈소스 문서 지향(document-oriented) NoSQL 데이터베이스입니다.
  • Neo4j: 오픈소스 그래프 데이터베이스입니다.

NoSQL 데이터는 어떻게 조회할까?

NoSQL 데이터베이스를 어떻게 질의(query)하느냐는 대부분의 개발자가 궁금해하는 부분입니다. 아무리 거대한 데이터베이스에 데이터가 쌓여 있어도, 이를 꺼내 최종 사용자나 웹 서비스에 보여 줄 수 없다면 아무 소용이 없기 때문입니다. NoSQL 데이터베이스는 SQL처럼 고수준의 선언적 질의 언어를 제공하지 않으며, 대신 데이터 모델에 맞는 개별적인 질의 방식을 사용합니다.

많은 NoSQL 플랫폼이 RESTful 인터페이스로 데이터에 접근할 수 있게 하고, 일부는 전용 쿼리 API를 제공합니다. 또한 여러 NoSQL 데이터베이스를 동시에 질의하려고 시도하는 도구들도 등장했는데, 이런 도구들은 대개 단일 NoSQL 범주 안에서만 동작합니다. 대표적인 예가 SPARQL입니다. SPARQL은 그래프 데이터베이스를 위해 설계된 선언적 질의 명세로, 다음은 특정 블로거의 URL을 조회하는 SPARQL 쿼리 예제입니다(IBM 제공).

PREFIX foaf: <https://xmlns.com/foaf/0.1/>
SELECT ?url
FROM <https://example.org/blog>
WHERE {
?contributor foaf:name 'Jon Foobar' .
?contributor foaf:weblog ?url .
}

NoSQL의 미래 전망

대규모 데이터 저장 수요를 가진 조직들은 NoSQL을 진지하게 검토하고 있습니다. 반면 상대적으로 규모가 작은 조직에서는 아직 큰 호응을 얻지 못하는 편입니다. Information Week가 실시한 설문조사에 따르면 응답자의 44%가 NoSQL이라는 용어 자체를 들어보지 못했다고 답했고, NoSQL이 자사의 전략 방향에 포함되어 있다고 응답한 곳은 1%에 불과했습니다. NoSQL이 상호 연결된 오늘날의 세계에서 분명한 입지를 갖고 있다는 것은 자명하지만, 많은 이들이 기대하는 대중적 호응을 얻기 위해서는 앞으로도 지속적인 진화가 필요할 것입니다.