NoSQL 7종 비교

문서 지향 데이터베이스에서는 데이터가 개별 칼 럼 타입(Column Type)으로 테이블에 저장되지 않는다. 대신, 데이터는 임의 개수의 필드와 임의 개수 의 중첩 구도(Nested Structure)를 갖는 프리폼(Freeform: 자유 형식) “문서”에 저장된다. 이런 문서는 대 개 JSON으로 표시되며, API를 사용하거나, JSON을 REST 엔드포인트로 보내서 업데이트한다. 대부분의 최 신 프로그래밍 언어는 JSON과 REST를 지원하므로, 문서 지향 데이터베이스를 사용해서 작업하는 것은 전 통적 데이터베이스보다 데이터 구조를 더 ‘네이티브하 게’ 다룬다는 인상을 준다. 스키마리스(Schemaless) 설계라는 개념에도 제약사 항은 있다. 데이터베이스 자체에서 항상 일관성을 보장 하지 않으므로, 개발자는 삽입된 데이터의 일관성을 보 장하기 위해 더 많은 작업을 해야만 한다. 또, 대부분의 문서 지향 데이터베이 스가 표준 규격이며 널리 보급된 데이터베이스 작업용 언어인 SQL을 지원하지 않기 때문에, 개발자 입장에서는 기존 데이터베이스 전문성을 활용하지 못하고 처음부터 시작해야 한다는 것도 단점이 될 수 있다. 그렇지만, 문서 지향적 데이 터베이스의 속도, 확장성, 그리고 다재다능한 특성과 다양하고 자유로운 형식의 데이터 구조가 필요한 애플리케이션을 작성할 때는 따라올 것이 없다. 이번 리뷰에서는 가장 잘 알려지고 가장 폭넓게 사용되고 있는 7가지 문서 지 향 데이터베이스를 분석해본다. 카우치DB(CouchDB), 카우치베이스(Couchbase) 서버, 몽고DB(MongoDB), 리씽크DB(RethinkDB), 이 4가지는 오픈소 스로 프로젝트 시작에 있어 실제적 장벽이 거의 없다고 할 수 있다. 카우치베이 스와 몽고DB는 상용 라이선스로 지원되는 엔터프라이즈 에디션으로도 사용할 수 있다. 나머지 3가지–아마존 다이나모DB(DynamoDB), 구글 파이어베이스 (Firebase), 그리고 IBM 클라우던트(Cloudant)–는 유명 클라우드 공급업체 의 호스팅 서비스로, 클라우드에서 다른 서비스와의 밀접한 통합이 커다란 매 력이다. <표 1>에서는 간략하게 각 데이터베이스의 특징을 비교했다. 

아마존 다이나모

DB 아마존의 다이나모DB는 2012년 아마존 심플DB(SimpleDB)의 확장판으로 태어났다. 키-밸류 스토어(Key-Value Store)인 다이나모에 의해 작동한다. 다이나모DB의 공동 개발자는 나중에 아파치 카산드라(Cassandra)를 개발할 때 동일한 아이디어를 많이 차용했다. 물론, 오픈소스 버전의 다이나모DB는 찾 을 수 없을 것이다. 다이나모DB는 전적으로 아마존 클라우드 상에서 호스팅 되 는 서비스로만 사용할 수 있다. 대부분의 아마존 클라우드 상품과 마찬가지로, 다이나모DB도 필요한 곳에 사 용하고 사용한 만큼 지불하는 매니지드 서비스(Managed Service)다. 개발자 표 1│각 데이터베이스의 특징 비교 Amazon DynamoDB Couchbase CouchDB Google Firebase IBM Cloudant MongoDB RethinkDB Platforms Cloud-only LWM LWMIAO Cloud-only Cloud-only LWMS LWM Query systems REST API Memcached protocol, REST API REST API REST/ JavaScript API REST API JSON-based API, partial REST API ReQL query language, REST API SQL querying No1 Via N1QL language No No No No1 No Strong typing Yes Yes No Yes No Yes Yes Native joins No Yes No No No Yes Yes Sharding partitioning Yes Yes Yes NA Yes Yes Yes2 Clustering NA Yes Yes NA NA Yes Yes Replication Yes Yes Yes NA Yes Yes Per table Consistency: Immediate Per read Per overall No Connected clients No Per write Per document Consistency: Eventual Yes Yes Yes Offline clients Yes Yes Entire database Concurrency Yes Yes Yes Yes Yes Yes Yes In-memory operations NA No No NA No Yes3 No Stored procedures No JavaScript4 JavaScript4 Rules JavaScript4 JavaScript No Transactions By app Single documents Single documents Yes Single documents Single documents5 Single documents Current version NA 4.6 (Feb. 2017) 2.0.0 (Sept. 2016) NA NA 3.4.4 (April 2017) 2.3.5 (Aug. 2016) Initial release 2012 2011 2005 2012 2010 2009 2009 기호 설명 : L=리눅스, W=윈도우, M=맥OS, S=솔라리스, I=iOS, A=안드로이드, O=다른 모바일 OS 1. 서드파티 도구가 해당 기능을 제공할 수도 있음 2. 테이블 당 3. 엔터프라이즈 에디션 전용 4. 함수 보기만 5. 다중문서(Multidocument) 트랜잭션도 사용할 수 있지만, 공유 클러스터 상에서는 불가 IT World ▶▶▶ 3 IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 가 비정형 문서, 키-밸류 쌍을 유지하기 위해 얼마만큼의 스토리지 용량이 필 요한지를 설정하고, 데이터베이스에 대한 읽기와 쓰기 요청에 대한 시간당 정 액제 요금 한도를 선택한다. 서버를 제공하거나 복제를 구성할 필요가 전혀 없 다. 아마존은 이면에서 이 모든 작업을 처리하며, 최근에는 자동 스케일 조정 (Autoscaling) 기능까지 추가했다. 다이나모DB는 개발자들에게 아마존 클라우드에서 다른 서비스들과의 유용한 통합 기능을 제공한다. 예를 들면, AWS 람다 함수를 통해 트리거(Trigger)를 설정할 수 있다. 아마존의 BI와 분석 도구 역시 함께 사용할 수 있다. 다른 서 비스와의 근접성은 편리한 점이지만, 한편으로는 아마존이 여러 가지 방식으로 고가에 기능을 끼워팔 수도 있다는 의미이기도 하다. 예를 들면, 레디스(Redis) 의 캐싱과 가속화 기능은 유료 애드온인 DAX(DynamoDB Accelerator)에서 사용할 수 있다. 처음부터 클라우드의 이점을 살려 설계된 다른 클라우드 네이티브(Cloudnative) 데이터베이스와는 달리, 다이나모DB는 다운로드해서 로컬(Local) 실 행 버전으로도 사용할 수 있다. 그렇지만, 다이나모DB 로컬은 업무용으로 개발 된 것이 아니라, 연결이 필요하지 않거나 아마존에 비용을 지불하지 않고 테스 트 환경에서 애플리케이션을 준비하려는 방편으로 개발된 것이다.

카우치베이스 

서버 카우치베이스는 선배 격인 카우치DB와 닮은 점이 많지 않은 후임이다. 카 우치DB와 멤베이스(Membase)에서 수행된 작업을 기반으로 구축되기는 했지 만, 이 두 가지 프로젝트 중 어느 것과도 관련되지 않았다. 카우치베이스는 문 서 지향 데이터베이스와 분산 키-밸류 스토어가 하나로 합쳐져서 만들어진 것 으로, 자동 대체작동(Automated Failover)과 데이터센터 교차 복제(CrossDatacenter Replication) 같은 고급 기능을 가지고 있으며, 엔터프라이즈 용 도로 개발되었다. 카우치DB 등 다른 경쟁 데이터베이스보다 돋보이는 카우치베이스만의 기 능은 N1 QL(“니클(nickle)”이라고 발음)이라 부르는 SQL 비슷한 쿼리 언어 이다. N1 QL은 ANSI SQL 구현 표준 정의된 전체 명령어를–최소한 아직까 지는– 제공하고 있지 않지만, SQL을 사용해본 개발자라면 실행 가능한 결과 를 얻을 수 있는 JOIN 작업 같은 명령어는 충분히 제공하고 있다. 카우치베이 스 쿼리 시스템은 개발자만을 위한 것이 아니라, 보통은 대화형 데이터베이스 를 다루는 DBA와 비즈니스 애널리스트를 위한 것이기도 하다. EXPLAIN 키워 드(Keyword) 같은 기능은 분명히 그런 특정 사용자층의 관심을 끌기 위해 포 함된 것으로 보인다. 문서 지향 데이터베이스와 키-밸류 스토어의 결합체인 카우치베이스는 자체 적인 고유 ID를 키로 사용해 문서를 저장한다. TTL(Time-to-Live: 문서 만 료 기간) 값을 문서에 할당해서, 키-밸류 캐시처럼 기능하게 할 수도 있다. 기 본적인 키-밸류 저장에서는 레디스 같은 진짜 키-밸류 캐싱 시스템이 훨씬 더 4 ▶▶▶ IT World IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 속도가 빠르다. 그러나 카우치베이스가 더 유연해서, 작업 속도를 높이기 위해 레디스와 카우치베이스를 효율적으로 결합할 수 있다. 그런 맥락에서 카우치베 이스는 기본적으로 멤캐시드(Memcached) 프로토콜을 지원하고 있기 때문에, 멤캐시드를 사용하는 기존 애플리케이션을 카우치베이스의 대용품으로 플러그 인 할 수 있다. 카우치베이스 서버에는 완전한 유료 에디션, 자유롭게 사용할 수 있는 커뮤 니티 에디션, 그리고 다른 에디션의 기초가 되는 오픈소스 에디션이 있다. 커뮤 니티 에디션을 업무용으로 배포할 수는 있지만, 구매자들은 엔터프라이즈 에디 션이 제공하는 더 많은 고급 기능과 지원 서비스가 없음에 주의해야 한다. 수평 스케일링(Horizontal Scaling) 기능 같은 카우치베이스의 몇 가지 기능이 카우 치DB 프로젝트에 포함되어 있지만, 이는 규칙이라기보다는 예외에 해당한다. 앱 개발자들이 주목할 만한 또 다른 카우치베이스 에디션으로는 카우치베이 스 라이트(Couchbase Lite)가 있다. 이 에디션은 백엔드와 자동으로 동기화하 는 데이터 스토어가 필요한 모바일 앱을 위한 애플리케이션 스택이다. 카우치 베이스 모바일(Mobile)은 iOS, 안드로이드, 자바, 닷넷(.Net), 맥OS, 그리고 tvOS에서 사용할 수 있다.

카우치DB 

카우치DB 프로젝트는 2005년 전직 IBM 개발자가 시작했으며 2008년에 아 파치 소프트웨어 재단으로 이관되었다. 카우치DB가 카우치베이스의 기반으로 불리는 경우도 있는데, 카우치DB와 카우치베이스는 목표가 다른 병렬 프로젝트 다. 카우치베이스는 문서 지향 데이터베이스인 동시에 키-밸류 스토어이고, 카 우치DB는 오로지 문서 지향 데이터베이스다. 카우치베이스는 오래 전부터 결함 내성이나 SQL과 유사한 쿼리 언어 같은 엔터프라이즈 기능에 주력해 왔지만, 이런 세부 사항들은 이제서야 겨우 카우치DB에 들어오기 시작했다. 카우치DB는 배포의 단순성과 사용의 용이성을 강조하고 있다. 데이터베이스에 서 데이터를 회수하는 작업에는 그 결과가 JSON 형태로 되돌려지는, JSON 포맷 의 쿼리를 REST HTTPS 엔드포인트로 송신하는 작업만 수반된다. 현대적 프로 그래밍 언어 대부분이 이런 작업을 할 수 있으며, 카우치DB 쿼리와 리포트 작성 이면에서 각종 뷰를 생성할 때 필요한 맵 처리(Mapping)와 리듀스 작업(Reducing)도 수행한다. ODBC 드라이버나 데이터 커넥터(Connector)가 필요 없다. 카우치DB의 특별한 소스 중 한 가지는 데이터 보정(Data Reconciliation) 기 술이다. 하나의 카우치DB 피어(Peer)에서 수행된 변경 사항이 VCS(Version Control System: 버전 관리 시스템)와 유사한 방식으로 다른 피어에도 자동으 로 적용되고 보정된다. 문서 버전 간 상충 사항이 있더라도 마치 해당 문서에 대 한 이전 수정 사항인 것처럼 유지된다. 이렇게 일관성 있는 최종 모델은 항상 혹은 지속적으로 연결되어 있지 않은 데이터베이스(예를 들면, 간헐적으로 연결되는 모바일 애플리케이션)와 특정 노 드에서 가장 큰 최신 버전 데이터가 필요하지 않은 경우에 유용하다. 그러나 이 IT World ▶▶▶ 5 IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 것은 카우치DB의 가장 큰 약점 중 하나이기도 하다. 정말로 즉각적인 일관성 이 필요하다면, 카우치DB에서는 그런 빠른 일관성을 찾아볼 수 없을 것이다. 최근에는 오래 전부터 카우치DB의 취약점이었던 확장성 문제가 해소되었다. 클라우던트와 IBM이 버전 2.0부터 오픈소스로 전환해 프로젝트에 합병하고 새 로운 클러스터링 기술을 선보인 것이다. 몽고DB에 친숙하고 유사한 선언적인 쿼리 구문을 사용하고 싶어 하는 사람 들을 위해 몽고 프로젝트 역시 클라우던트/IBM 덕분에 이 기술을 외부 애드온 으로 제공하고 있다.

구글 파이어베이스 실시간 데이터베이스 

파이어베이스 실시간 데이터베이스는 인증, 성능 감시, 사용자 분석, 그리고 수많은 다른 기능을 포함한 파이어베이스 스택에서 하나의 구성요소일 뿐이다. 전체 스택은 가입자 참여와 통찰력에 중점을 두는 애플리케이션 구축을 의도 한 것이지만, 다이나모DB에 대한 구글의 대응, 즉 클라우드 백엔드와 여러 플 랫폼상의 지역 앱 간의 빠른 데이터 동기화를 제공하기 위한 수단이라고 생각 해도 무방하다. 구글은 2014년에 파이어베이스를 인수한 이후, 파이어베이스와 여러 가지 구 글 클라우드 기능을 적극적으로 연결해왔다. 예를 들면, 파이어베이스용 구글 클라우드 함수에서는 파이어베이스 이벤트에 대한 응답으로 클라우드에서 자바 스립트 함수를 트리거할 수 있다. 파이어베이스용 구글 애널리틱스에서는 더 심 도 있는 분석을 위해 모바일 앱 데이터를 빅쿼리(BigQuery)로 끌어올 수 있다. 파이어베이스의 대상 적용 분야 중 한 가지는 게임이다. 그래서 파이어베이스 용 SDK에는 유니티(Unity) 교차 플랫폼 게임 개발 프레임워크가 포함되어 있 다. 좀 더 전통적인 엔터프라이즈 집중적인, 그리고 소비자 지향적인 프로젝트 를 위해 충분한 선택사항이 있다. 순수 iOS, 안드로이드, C++, 일반적인 웹/ 자바스크립트, 그리고 REST를 지원하는 다른 모든 언어라면 자바, 파이썬, 무 엇이든 가능할 것이다. 파이어베이스는 연결이 보장되지 않는 경우에도 동작하도록 설계되었다. 카 우치DB처럼, 오프라인일 때는 로컬에서 변경사항을 유지하다가, 연결이 복구 되면 백엔드와 자동으로 동기화한다. 파이어베이스는 단독으로는 완전한 오프 라인 솔루션으로 사용되도록 설계되지 않았음에 유의해야 한다. 예를 들면, 안 드로이드 상에서 로컬 데이터베이스는 20MB의 용량으로 제한된다.

IBM 클라우던트 

클라우던트는 본질적으로 IBM에 호스팅 된 카우치DB 에디션이다. 원래, 클 라우던트는 IBM의 소프트레이어(SoftLayer) 클라우드에서 호스팅 되는 “빅카 우치(BigCouch)”라는 에디션의 카우치DB를 공급하던 독립 업체였다. 2014년 IBM은 분석과 빅데이터로의 전반적인 노력의 일환으로 노골적으로 클라우던트 를 인수했다. 현재 클라우던트는 주로 IBM의 블루믹스(Bluemix) PaaS 상의 개 6 ▶▶▶ IT World IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 발자로 자리 매김했으며, 서로 용도가 다른 여러 가지 데이터 제품(클라우던트, 대시DB, 데이터웍스, 그리고 왓슨 애널리틱스)을 보유하고 있다. 클라우던트는 카우치DB의 호스팅 버전 이상의 것이어야 한다. 클라우던트는 전문 검색(Full-text Search) 기본 통합 등, 카우치DB 자체에서 쉽게 사용할 수 없는 기능을 제공하고 있다. 카우치DB에서의 전문 검색을 위해서는 대개 외 부 프로젝트와의 통합이 필요하다. 클라우던트의 사내 구축형 에디션인 클라우던트 로컬(Cloudant Local)은 서비스형(as-a-Service) 제품과 동일한 모든 기능을 제공한다. 레드햇이나 SUSE를 구동하는 IBM 자체의 시스템 z뿐 아니라 x86 리눅스 중 우분투와 레 드햇 계열에서도 사용할 수 있다. 개발자는 도커(Docker) 이미지 형태로 시험 과 개발 전용 무료 버전을 사용할 수 있다. 클라우던트와 카우치DB 인스턴스 사 이에서 양방향으로 데이터를 복제할 수 있어서, 필요에 따라 둘 중 어느 하나로 이동하기가 비교적 쉽다. 카우치DB 2.0의 수평적 스케일링 기능과 몽고 쿼리 언어 인터페이스를 포함 해서, 카우치DB에 대한 클라우던트의 개선 사항 중 몇 가지는 기초를 이루는 카 우치DB 프로젝트로 수용되었다. 그렇다고 클라우던트 기능이 자동으로 카우치 DB로 넘어갈 것이라는 증거로 받아들이는 것은 이르다.

몽고DB 

몽고DB는 가장 널리 배포되고, 또 개발자 커뮤니티에서 가장 잘 알려져 있는 문서 지향 데이터베이스다. 몽고DB는 문서 지향 데이터베이스, 그리고 일반적 으로 NoSQL 시스템에서 볼 수 있는 대부분의 핵심 개념, 즉 스키마리스 데이 터 저장, 스케일 아웃 아키텍처, Shared-nothing 아키텍처를 구현하고 있다. 몽고DB 오픈소스 에디션에는 기본적인 업무용 배포에 필요한 엄청나게 많은 기능이 이미 포함되어 있다. 상용 라이선스에는 백업, 자동화 확장기능, 감시, 데이터 탐색 도구, SQL이 지원되는 BI 커넥터, 인메모리 스토리지 엔진 등 많 은 핵심 엔터프라이즈 기능이 추가되어 있다. 몽고DB에 있는 엔터프라이즈 기능은 최근 추가된 인메모리 처리, 서드파티 데이터 탐색을 통한 SQL과 유사한 인터페이스 그리고 타블로 같은 BI 도구, 그 리고 문서 데이터에 대한 재귀적 그래프 쿼리 (Recursive Graph Query) 등에 서 볼 수 있듯이 엔터프라이즈 개발자들을 오라클 같은 데이터베이스로부터 떨 어뜨리려는 의도를 가지고 있다. 그래프 쿼리는 가계도나 소셜 네트워크 같은 제한을 두지 않는 관계 사슬을 탐색하는 데 유용하다. 몽고DB는 많은 비판의 대상이 되어왔다. 이런 비판 중 일부는 이 제품의 목 표와 방법론을 제대로 이해하지 못하는 개발자에서 기인한 것이다. 하지만 비판 중 일부는 더티 리드(Dirty Read, 데이터 캐시에는 변경되었지만, 아직 스토리 지에는 변경되지 않은 데이터 즉, 아직 커밋(Commit) 되지 않은 데이터에 대한 읽기 작업)와 스테일 리드(Stale Read, 업데이트 작업을 통해 동기화되지 않은 소스에서 잘못된 값을 가져오는 읽기 작업), 업데이트 손실(Lost Update), 유 IT World ▶▶▶ 7 IDG Tech Review│개발자 친화적 NoSQL 7종 비교 분석 니코드 문서를 처리할 때 심각한 제약으로 작용하는 ‘순서에 따른 분류 불능’ 등 의 실제적 문제를 지적하는 것이기도 하다. 이런 모든 문제점이 몽고DB 3.4에 서 해소되었음에 주목해야 할 것이다. 또 다른 커다란 문제로는 보안을 들 수 있 다. 잘못 구성되고 공개적으로 노출된 몽고DB 인스턴스가 공격을 받고 랜섬웨 어의 표적이 된 사례가 있지만, 업무용으로 배포하기 전에 몽고DB의 보안 설정 에 상당한 주의를 기울임으로써 바로잡을 수 있다.

리씽크DB 

리씽크DB에 얽힌 뒷이야기는 프로젝트 자체만큼이나 흥미롭다. 리씽크DB는 원래 오픈소스(GNU Affero GPL) 라이선스 버전이 있는 상용 제품으로 구상되 었지만, 이 데이터베이스를 개발하던 회사가 도산했다. 이후 CNCF(Cloud Native Computing Foundation)가 도움의 손을 내밀어서, 이 프로젝트에 대한 지 적 재산권을 인수해서 리눅스 재단에 기부했다. 이제 리씽크DB는 더욱 진보적인 오픈소스 라이선스와 오픈소스 진영으로부터 후원을 받아 제2의 생명을 얻었다. 애플리케이션에 실시간 업데이트를 스트리밍하는 내장 변경 알림 시스템은 리씽크DB만의 커다란 혁신이다. 소개 문서에 있는 말을 옮기자면, “변경사항 을 알려면 폴링(Polling)해야 했지만, 이제 개발자가 실시간으로 업데이트된 쿼 리를 끊임없이 애플리케이션으로 푸시(Push)하라고 데이터베이스에 지정할 수 있다”. 이렇게 해서, 리씽크DB는 비록 전체적인 ACID(ACID: Atomicity(원 자성), Consistency(일관성), Isolation(고립성), Durability(지속성)의 약자로 데이터베이스 트랜잭션이 안전하게 수행되는 것을 보장하기 위한 속성) 컴플라 이언스를 희생하지만, 멀티플레이어 게임 같은 실시간 애플리케이션 개발 과정 을 간소화할 수 있다. 데이터베이스에 있는 개별 문서는 트랜잭션처럼 다뤄지지 만, 전체 데이터베이스의 상태는 결과적인 일관성을 유지한다. 리씽크DB는 근본적으로 SQL을 지원하지는 않으나, 파이썬, 자바스크립트, 루비, 자바의 고유 구문을 통해 구현되는 ReQL이라는 쿼리 시스템을 포함하 고 있다. ReQL는 개발자 본인이 원하는 언어로 복잡하고, 사후평가형 표현식 (Lazily Evaluated Expression)을 구성할 수 있도록 하기 위해 연결된 닷 명령 어(Dot Command)를 사용한다. 예시는 다음과 같다. r.table(‘users’).pluck(‘last_name’).distinct().run(conn) 문서에 대한 변경사항이 리씽크DB로 들어오면, 애플리케이션이 변경사항의 상세 정보를 알아내기 위해 파싱하는 “변경피드(Changefeed)”를 통해서 사용 할 수 있다. 예를 들어, 문제의 데이터가 새로운 것이거나 기존 데이터의 변경된 버전인 경우, ReQL 표현식은 변경피드 이벤트를 다루기 위한 콜백 함수에 해당 하는 것을 생성하기 위해 사용된다(기본적으로 트리거와 같다). 표현식은 테이 블 결합(Table Join)을 에뮬레이션하는 메커니즘을 통해 데이터 엔티티(Data Entity)들 간의 관계를 정의할 수도 있다.