류프리

문서 지향 데이터베이스에서는 데이터가 개별 칼 럼 타입(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)들 간의 관계를 정의할 수도 있다.

Neo4j는 가장 인기 있는 그래프 데이터베이스 중에 하나입니다. 상용버전 뿐만이 아니라 오픈소스 버전도 존재합니다. Neo4j는 ‘4j’가 자바 언어(Java Language)로 구현되었음을 의미하며, 이들 생태계는 기본적으로 JVM(Java Virtual Machine) 기반위에서 동작합니다. Neo4j 클라이언트는 루비(Ruby)와 파이썬(Python)과 같은 다른 언어를 지원합니다. 

Neo4J의 특징

    ① JTA(Java Transaction API) 지원

    ② REST(Representational State Transfer) 방식 지원.

    ③ 이중화를 통한 고가용성을 지원(Zookeeper)

    ④ 인덱스(Index) 및 노드 탐색 지원

    ⑤ 백업 / 복구 지원

Neo4J의 데이터의 표현

그래프 모델(Graph Model)에서 그래프(Graph)는 정점(Vertex)과 간선(Edge) 그리고 프로퍼티(Property)로 구성이 되어 있습니다. 이러한 데이터 표현은 관계형 데이터베이스의 객체-관계(Entity-Relationship) 모델과 일치합니다. 정점(Vertex)은 노드(Node) 의미하며 완전히 동일하지는 않지만 관계형 데이터베이스의 객체(Entity)와 유사합니다. 간선(Edge)은 관계(Relationship)를 나타냅니다.

아래의 그림은 그래프를 구성하는 3대요소(노드, 관계, 프로퍼티)를 도식화한 것입니다. 노드(Node)는 정점(Vertex)를 의미하며, 관계(Relationship)은 간선(Edge)를 의미합니다. 마지막으로 프로퍼티(Properties)는 노드와 관계에 대한 속성 값을 의미합니다.

[ 그래프의 구성요소 ]

Neo4j의 데이터 구조

노드(Node)와 관계(Relationship)은 각각의 데이터 구조를 가지고 있습니다. 아래의 표는 노드와 관계에 대한 데이터구조를 나타낸 것입니다.

노드(Node)

관계(Relationship)

아래의 그림은 노드(N1, N2, N3, N4)와 관계(E1, E2, E3, E4, E5)를 그래프로 도식화한 것입니다. 관계는 두 노드 사이의 연결을 표현하는 것으로 단방향 또는 양향일수 있으며, 노드로 들어오는 관계인 ‘incoming’ 과 노드에서 나가는 관계인 ‘outgoing’을 가집니다.

[ Neo4j의 데이터 표현 ]

상단의 그래프를 노드와 관계로 표현을 하면 아래처럼 정리할 수 있습니다.

Neo4j의 활용 분야

소셜 네트워크 서비스는 태생적으로 그래프로 데이터를 표현하기에 적합한 구조를 가지고 있습니다. 트위터(Twitter)를 보면 글을 게시하는 특정 사용자를 다른 사람이 팔로우(follow)하는 구조를 보면, 한 노드와 다른 노드와의 관계(Relationship)를 그래프로 표현할 수 있습니다.

다음 그림은 매트릭스에 나오는 인물들에 대한 관계도를 나타내고 있습니다. 이러한 구조를 페이스북(Facebook)에서도 이용하고 있으며, 두 노드간의 관계들을 계속 확장하여 이전에는 몰랐던 새로운 인간 관계를 발견할 수 있습니다. 또한 인간관계들을 더욱 확장하여 이들 관계에서 가장 영향력을 발휘하는 사용자들을 찾아내어 마케팅에 활용할 수도 있습니다.

[ 매트릭스의 인물 관계도 ]

Neo4j 라이선스(Licenses)

Neo4J는 3가지의 라이선스를 가지고 있습니다. ‘Community’는 MySQL처럼 자유롭게 사용할 수 있으며, GPL 라이선스여서 프로그램에 포함하는 경우가 아니라면 소스를 공개할 의무가 없습니다. ‘Advanced’는 모니터링과 운영 지원이 포함되어 있습니다. 이 버전에서는 소스 코드는 무료로 이용이 가능하지만 소스 코드에 대한 수정사항은 커뮤니티의 이익을 우해서 공개되어야 하는 AGPL 라이선스 규정을 준수해야 합니다. 만약 소스 코드에 대한 공개를 하지 않기 위해서는 상용 라이선스를 구매해야 합니다. 마지막으로 ‘Enterprise’는 Auto Replication과 전체적인 모니터링을 지원하며 24시간 운영 지원이 포함되어 있습니다.

아파치 H베이스는 2007년 처음 만들어진 하둡 플랫폼을 위한 NoSQL 데이터베이스입니다. 2006년 구글에서 공개한 빅테이블(BigTable) 논문을 참고하여 만들어졌으며, 대용량의 분산된 데이터를 저장하기 위해서 무정지(Fault Tolerant) 방법을 제공하는 구글의 빅테이블과 비슷한 기능을 제공합니다. 2008년 아파치 하둡 프로젝트에 편입되었으며, 하둡의 분산 파일 시스템(HDFS, Hadoop Distributed File System)기반 위에서 데이터를 저장합니다. 또한 H베이스는 자바 언어(Java Language)로 만들어졌습니다.

H베이스는 압축 기능과 자주 사용되는 데이터를 메모리에 미리 캐싱하는 인-메모리(In-Memory) 처리 기술과 초기 빅테이블에 제시하고 있는 Bloom 필터 기능을 제공합니다. 

H베이스에 있는 테이블들은 하둡에서 동작하는 맵-리듀스(Map-Reduce) 잡들을 위한 입력, 출력을 제공하며, 클라이언트 프로그램은 자바 API나 REST, Avro 또는 다른 언어를 풍부하게 지원하는 쓰리프트(Thrift) 게이트웨이를 통하여 접근할 수 있습니다.

H베이스는 기존의 SQL 데이터베이스를 직접적으로 대체하지는 않지만 페이스북의 메시징 플랫폼과 핀터레스트, 카시니, 세일즈포스닷컴과 같은 다수의 기업에서  사용되고 있습니다.

H베이스의 특징

  ① 메모리에 우선 기록되어지며, 디스크에 저장된 후에는 읽기 전용 상태

  ② 추가적인 환경 구성없이 간단하게 클러스터를 추가하여 확장 가능

  ③ 대량의 Read/Write 기능을 지원하며 Fast Scans 기능 지원

  ④ 주키퍼(Zookeeper)를 이용한 고 가용성 보장

  ⑤ 마스터(Master)와 리전(Region) 서버 관리를위한 웹 기반의 UI 관리툴을 제공

논리 스토리지 구조

관계형 데이터베이스에서 테이블(Table)은 와이드 컬럼 스토어에서는 키스페이스(Keyspace)라고 불립니다. 키스페이스는 N개의 행(row)으로 구성되어 있고, 하나의 행(row)는 N개의 컬럼 패밀리(Column Family)로 구성되어 있고, 하나의 컬럼 패밀리는 N개의 컬럼으로 구성되어 있습니다.

[ H베이스의 데이터 모델 ]

H베이스 구조

H베이스는 완전한 분산 시스템입니다. 초기에 개발할 때부터 분산을 고려해서 설계되었습니다. 그래서 전통적인 단일-머신 가용성 전략은 하나의 노드(Node) 가 아닌 N개 노드(Node)들의 집합인 클러스터(Cluster) 수준에서 동작되도록 만들어졌습니다.

H베이스 클러스터는 두개의 파트로 구성이 되어 있습니다. 하나는 주키퍼(Zookeeper)로써 주로 설정 정보를 관리하며, 주키퍼 노드들로 구성된 클러스터를 형성하고 있습니다. 테이블에 대한 메타데이터는 마스터 서버(Master 서버)에서 관리를 합니다.

노드(Node)라는 용어가 자주 나오는데, 서버(Server) 또는 머신(Machine) 또는 하나의 컴퓨터(Computer)와 같은 의미라고 생각하시면 됩니다.

[ 주키퍼 클러스터, 마스터 서버, 리전서버 관계 ]

마스터 노드는 여러 개의 리전서버를 관리합니다. 하단의 그림에서 ‘RS’가 하나의 리전서버입니다. 리전서버는 N개의 리전으로 구성되어 있습니다.

[ H베이스 Region Server의 구조 ]

리전서버에서의 리전은 테이블에 존재하는 데이터들의 부분 집합을 관리합니다. 그리고 각각의 리전은 기본값으로 설정된 256MB 보다 커지면 동일한 크기로 분리가 됩니다. 분리된 덩어리들은 리전이 되고 설정된 크기까지 데이터를 저장할 수 있습니다.

리전서버의 경우 테이블에 있는 데이터을 저장할 때 동일한 데이터를 3곳의 데이터 노드(DataNode)에 분산하여 저장함으로써 장애 발생으로부터 데이터의 손실을 예방합니다.

[ 리전 서버의 구조 ]

HBase Write Path

데이터를 put()하면 일단 멤스토어(MemStore)에 데이터가 저장됩니다. 멤스토어가 가득차게 되면 HFile형식으로 파일로 기록이 되면 멤스토어에 저장되어 있는  데이터는 비워지게 됩니다. HFile은 한번 기록되면 변경할 수 있는 메소드가 없기 때문에 변경이 불가능하며 하나의 블록 크기는 64KB입니다.

[ H베이스 쓰기 동작 ]

WAL(Write Ahead Log)

다음 그림은 리전(Region)에 있는 데이터를 디스크에 파일로 저장하는 과정을 보여주는 시퀀스 다이어그램(Sequence Diagram)입니다. H베이스에서 모든 변경 작업(Puts/Deletes)은 특정 리전 서버의 멤스토어에 저장되고 동시에 WAL(Write Ahead Log) 파일안에 WALEdit 형태로 저장이 됩니다.

WALEdit는 하나의 트랜잭션을 나타내는 오브젝트이고, 하나 이상의 변경 작업을 가지고 있습니다. H베이스가 Single-Row 레벨의 트랜잭션을 지원하기 때문에, WALEdit는 오직 하나의 로우에 대한 정보만 가지고 있습니다. WAL 파일들은 설정된 시간(기본적으로 60분 마다) 이후에 지속적으로 변경되므로, 특정 시간에 하나의 리전 서버에는 오직 하나의WAL 파일만 존재합니다.

멤스토어에 저장되는 데이터는 휘발성 메모리에 저장되기 때문에, 시스템에 문제가 발생할 경우에 메모리에 있는 정보들은 모두 손실될 수 있습니다. 이러한 단점에도 불구하고 멤스토어를 사용하는 것은 쓰기 작업시에 빠른 속도를 보장하기 때문입니다.

만약 시스템에 문제가 발생하여 멤스토어에 저장된 데이터가 디스크(Disk)에 기록되지 않고 사라지는 경우에도WAL(Write Ahead Log) 파일을 이용하여 효율적으로 파일을 재생할 수 있습니다.

주키퍼(Zookeeper)의 역할

주키퍼는 복제(Replication)에서 중요한 역할을 담당합니다. 주키퍼는 슬레이브 클러스터(Slave Cluster)를 등록하거나 복제(Replication)을 시작/중지하거나, 새로운 WAL(Write Ahead Log)을 큐에 넣거나, 리전 서버의 장애를 핸들링하거나 등의 중요한 업무를 관리합니다.

H베이스를 사용하는 곳

H베이스는 엄격하지 않은 스키마(Schema) 구조에서 동작하는 NoSQL 계통의 데이터베이스로 단순한 데이터 구조나 연산이 별로 필요없는 채팅 프로그램에서 많이 이용되고 있습니다. 특히 H베이스는 쓰기 연산 성능이 다른 데이터베이스에 비해서 빠른 편이어서, 네이버의 라인(Line) 또는 페이스북의 메신저에서 많이 사용됩니다.

카산드라는 아마존의 다이나모(Dynamo) 설계에 참여한 Avinash Lakshman과 페이스북의 Prashant Malik 가 최초로 만들었고, 페이스북에 적용하여 사용하다가 2008년 구글 코드를 통해서 오픈 소스로 배포가 되었고 2009년 3월에는 아파치 인큐베이터 프로젝트로 등록이 되었습니다.

카산드라는 자바 언어를 통하여 만들어졌으며 Ruby, Perl, Python, Scala, Java, PHP등 다양한 언어들을 지원합니다. 또한 관계형 데이터베이스에서 사용하는 테이블간의 관계 정의(Foreign Key)가 필요 없으며, 대용량 데이터 처리가 필요한 페이스북과 같은 소셜네트워크 시스템(SNS)에서 많이 사용되고 있습니다.

논리 스토리지 구조

아래 그림과 같이 카산드라는 ‘클러스터(Cluster)’ 하위에 ‘키스페이스(Keyspace) 모임으로 구성되어져 있고 ‘키스페이스’는 ‘컬럼패밀리(Column Family)’ 모임으로 구성되어져 있습니다. 또한 ‘컬럼패밀리’ 하위는 ‘컬럼(Column)’ 모임 또는 ‘슈퍼 컬럼(Super Column)’ 모임으로 구성되어져 있고, ‘슈퍼 컬럼’은 ‘컬럼’ 모임으로 이루어져 있습니다. 카산드라의 가장 하부 조직인 ‘컬럼(Column)’은 ‘이름(name)’과 ‘값(value)’으로 구성되어져 있습니다.

[ 카산드라의 논리 스토리지 구조 ]

Column

컬럼은 ‘이름’ 과 ‘값’ 으로 이루어진 데이터 구조체를 말합니다.

Super Column

슈퍼 컬럼은 컬럼 구조체 안에 다시 컬럼이 들어가 있는 구조체를 말합니다.

Column Family

컬럼 패밀리는 컬럼과 슈퍼 컬럼들의 집합이며, 컬럼 패밀리간의 구분은 ‘키(Key)’ 에 의해서 식별을 할 수 있습니다.

여기에서 컬럼 패밀리는 ‘PersonalStruct’ 이며, 각 행(row)에 대한 키들은 ‘Info1’, ‘Info2’, ‘Info3’ 이며, 각 행들은 여러 개의 컬럼(Column)으로 구성되어 있습니다.그리고 각 행(row)의 데이터 구조는 서로 다를 수가 있습니다.

Keyspace

키스페이스는 컬럼패밀리를 묶어주는 개념입니다. 예를 들면 블로그에 저장되는 게시물이라고 표현할 수 있습니다. 하나의 블로그 게시물이 컬럼 패밀리가 되며, 이러한 블로그 게시물들의 모임을 키스페이스라고 말합니다.

물리 스토리지 구조

‘노드(Node)’는 하나의 서버에서 구동되는 카산드라 프로세스를 말합니다. 보통 하나의 서버에서는 하나의 프로세스만 구동되므로 ‘노드’는 서버 한대를 지칭합니다. 저장공간에 대한 물리적 구조는 여러대의 서버가 링의 형태로 연결된 것을 말하지만 논리적으로는 물리적 구조의 여러 서버들을 클러스터라는 확장 공간에서 하나의 저장공간처럼 사용하는 것입니다.

노드들은 토큰링(Token ring)을 구성하고 노드의 수에 따라서 구간을 분할합니다. 데이터를 저장할 때에는 키(Key)값을 해싱하여 해싱된 값을 가지고 어느 노드에 데이터를 저장시킬지를 결정합니다. 저장되기 전에 노드의 어느 영역에 저장할지가 결정되기 때문에 데이터를 어느 영역에 위치시키는 것은 어렵지 않습니다.

[ 카산드라 토큰링의 구조 ]

카산드라는 자바로 구현되어 있어 JVM에 익숙할 필요가 있습니다. API는 쓰리프트(Thrift) 게이트웨이를 통해서 많은 언어의 클라이언트를 제공합니다. 쿼리 언어는 별도로 없습니다. 대신 컬럼 패밀리 문법을 이용해서 API로 어플리케이션에서 프로그래밍할 수 있습니다. 많은 다른 키-밸류 저장소와 컬럼 패밀리 저장소와 틀리게 카산드라는 일부 제약이 있는 이차 인덱스를 지원합니다. 이는 행(row)의 키보다는 값에 의해 레코드를 찾을 수 있게 해 줍니다.

카산드라 2.0에서는 SQL과 비슷한 CQL의 지원과 트랜잭션 두 부분에 대해서 많은 기능들을 제공하고 있습니다. CQL 기능은 카산드라에서 쿼리 언어(Query Language)를 사용할 수 있도록 합니다. 카산드라가 이러한 기능들을 지원하는 이유는 많은 분석가와 사용자들에게 관계형 데이터베이스에서 느꼈던 분석에 대한 편리성을 제공하여 더 많은 사람들을 끌어들이기 위한 포석으로 보입니다.

카우치(Couch)DB는 Cluster Of Unreliable Commodity Hardware의 약어로 2005년에 개발이 시작되고, 2008년초에 아파치 인큐베이팅 프로젝트에 등록된 문서 기반 데이터베이스입니다. 이 프로젝트를 이끌고 있는 사람은 Damien Katz씨로 로터스에서 근무했고 현재는 IBM에서 일하고 있습니다. 카우치DB는 아파치 프로젝트 중에서 유일하게 얼랭을 언어로 사용하고 있습니다. 얼랭으로 구현되어 있지만 사용자들은 얼랭을 알 필요가 없습니다.

카우치DB와 관계형 데이터베이스의 차이점

몽고DB와 카우치DB와 같은 문서형 저장소는 데이터를 테이블에 저장하지 않고 문서 형식으로 저장하여 모든 연관된 정보들을 세분화하여 분리시키지 않고 JSON 형식으로 한 문서안에 저장을 시킵니다. 대표적인 예를 들자면 HTML 형식으로 이루어진 웹 문서를 생각하시면 됩니다. 이에 반해서 관계형 데이터베이스의 경우에는 정보들을 분류 가능한 최소 단위까지 세분화하여 세분화 된 정보들간의 관계를 설정함으로써 데이터를 구조화 시킵니다.

문서형 저장소는 데이터들간의 요소들의 관계가 비교적 느슨하며, 새로운 데이터를 추가하기 위해서 모든 문서들에 불 필요한 공간을 생성할 필요가 없습니다. 이렇게 스카마 변경에 따른 어려움이 없다는 것이 카우치DB와 같은 NoSQL의 큰 장점입니다.

카우치DB와 몽고DB의 차이점

같은 NoSQL이면서 문서지향 데이터베이스인 몽고DB와의 차이점에 대해서 말하자면 우선 몽고DB의 경우에는 커스텀 바이너리 프로토콜(Custom Binary Protocol)을 사용하기 때문에 몽고DB를 사용하기 위해서는 별도의 드라이버(Driver)가 필요한 반면에 카우치DB의 경우에는 HTTP/REST 프로토콜을 사용함으로 별도의 드라이버가 필요없고 인터넷에 연결이 되어 있으면 HTTP를 이용하여 카이치DB를 사용할 수 있습니다.

카우치DB의 사상은 간단합니다. 모든 정보를 문서형태로 저장합니다. 이러한 문서들을 저장하는데 초점을 맞춥니다. 이에 반해서 몽고DB의 경우에는 문서 형태로 저장하는 목적이외에 문서 저장소를 관리하는 계층을 두어서 저장소에 대한 세부적인 관리를 실시합니다.

몽고DB에서 쿼리(Query)를 사용하여 문서를 빠르게 검색할 수 있습니다. 이러한 쿼리는 관계형 데이터베이스와 유사하여 관계형 데이터베이스 사용자들이 몽고DB를 손쉽게 사용할 수 있도록 유도하는 장점중에 하나입니다. 하지만 카우치DB는 쿼리를 뷰(View)에 대해서만 할 수 있으며, 이 뷰는 기본적으로 맵-리듀스 함수를 기반으로 작동을 합니다. 맵-리듀스는 분산 환경을 위해서 탄생하였지만 쿼리 속도가 느리다는 태생적 한계점을 가지고 있습니다.

카우치DB를 적용하기 쉬운 분야로는 CRM, CMS와 같은 데이터를 누적하는 시스템 및 데이터의 변화가 별로 없는 시스템이며, 몽고DB는 동적인 질의가 필요한 시스템이나 빠른 조회를 위해서 인덱스 사용이 필요한 시스템에 사용하는 것이 적절합니다.

[ 카우치DB와 몽고DB의 차이점 ]

문서 저장소(Document Store)

카우치DB가 다른 데이터베이스와 다른점은 자바 스크립트와 JSON을 사용한다는 것입니다. 쿼리를 하기 위해서는 자바 스크립트를 이용하며, 데이터를 표현하기 위해서는 JSON형식이 사용됩니다. 또한 “수정”이라는 개념이 없어서 문서를 수정하면 수정한 문서의 내용이 변경되는 것이 아니라 문서의 버전이 올라간 새로운 문서가 생성이 됩니다.

만약 여러명이 동시에 같은 문서를 편집을 한다면 나중에 저장하는 사용자는 편집하고 있는 문서가 누군가에 의해서 수정된 사실을 알게 됩니다. 이러한 경우에는 나중에 수정한 사용자가 최신 버전의 문서를 기반으로 다시 수정된 사항을 반영해야 합니다. 문서가 변경될 때마다 별도의 문서가 생성되기 때문에 엄격한 ‘ACID’를 필요로 하지 않으며 여러명이 읽거나 쓰더라도 잠금을 걸 필요가 없습니다.

다른 데이터베이스의 메타데이터나 데이터들의 쿼리를 위해서는 연관된 여러 개의 테이블을 참조해야 하지만, 카우치DB의 경우에는 문서안에 필요한 모든 데이터가 기록되어 있기 때문에 쓰기와 검색이 다른 데이터베이스에 비해서 단순한편입니다.

맵-리듀스 뷰(Map-Reduce View)

카우치DB의 경우에는 비정형 데이터를 처리하기 위해서 자바 스크립트 함수를 이용합니다. 이러한 자바 스크립트 함수를 카우치DB에서는 뷰라고 하는데 맵-리듀스 모델을 사용합니다.

맵-리듀스 뷰는 카우치DB 문서들을 입력변수로 받아서 먼저 맵(Map) 함수를 통해서 JSON 형식으로 이루어진 문서들의 항목들을 키(Key)-값(Value)으로 정리를 합니다. 리듀스(Reduce) 함수에서는 맵함수에서 나온 키-값들을 기준으로 데이터를 가공하여 키값으로 데이터를 정렬합니다.

보안 모델(Security Model)

카우치DB는 문서에 접근할 수 있는 접근 권한을 지정할 수 있으며 크게 3가지 접근 권한으로 구분 할 수 있습니다. 먼저 관리자 접근 권한의 경우에는 다른 관리자 계정을 만들거나 설계 문서를 수정할 수 있습니다. 리더 접근 권한의 경우에는 카우치DB 문서에 리더(Reader) 목록을 저장합니다. 리더 목록이 없는 경우에는 모든 사람들이 문서를 읽을 수 있지만, 리더 목록이 존재하는 경우에는 지정된 리더들만 읽기가 가능합니다. 마지막으로 업데이터 접근 권한의 경우에는 디스크에 문서를 저장하는 시점에 자바 스크립트 함수를 사용하여 유효성 검증이 이루어지게 됩니다. 유효성 검증을 통과하면 업데이트가 실행되는 반면에 실패한 경우에는 작업이 중단되고 클라이언트는 오류 응답을 받게 됩니다.

복제(Replication)

카우치DB는 P2P 기반의 분산 데이터베이스 시스템으로 인터넷 접속이 안되는 상황에서도 공유가 가능한 데이터에 대한 접근과 수정이 가능합니다. 카우치dB는 정상적으로 복제가 일어났던 시점 이후에 변경된 문서들만 복제를 합니다. 만약 도중에 복제가 실패하더라도 복제를 실패한 문서부터 다시 시작합니다.

또한 조건을 지정하여 조건에 만족하는 문서들만 선별적으로 복제하도록 자바 스크립트 함수로 필터링하는 기능도 가능합니다. 이러한 기능들은 복제가 필요없는 문서들의 복제를 생략함으로써 실제 사용해야 하는 문서들을 빠르게 복제할 목적으로 사용하기도 합니다. 

몽고DB는 웹 프로그램과 인터넷 기반 서비스를 위해 만들어진 데이터베이스 관리 시스템입니다. 몽고DB는 관계형 데이터베이스와 키-값 저장 시스템의 장점만을 모아서 설계되었습니다. 키-값 저장 시스템은 데이터 구조의 단순성을 통한 빠른 처리 속도와 정형화되지 않은 데이터 구조를 저장할 수 있는 장점이 있으며, 관계형 데이터베이스는 강력한 쿼리 기능을 바탕으로 다양한 분석능력과 인덱스를 기반으로 처리 속도가 빠른점이 장점입니다.

몽고DB는 이들 데이터베이스의 중간형이라 말할 수 있으며 빅데이터 처리를 위해서 서버들을 수평으로 확장이 가능하며, 비정형 데이터를 저장할 수 있으며 정교한 쿼리를 통한 양질의 분석 결과를 얻을 수 있습니다.

개발자들이 몽고DB에 관심을 갖는 이유는 빅데이터 처리를 위한 서버의 수평적 확장의 용이성 때문이 아니라 정형화 되지 않는 계층적 구조의 데이터를 표현할 수 있기 때문입니다. 이를 통해서 관계형 데이터베이스에서 사용하는 조인연산이 필요없이도 원하는 분석 결과를 도출할 수 있기 때문입니다.

예를 들면 트위터에서 입력되는 데이터를 관계형 데이터베이스로 모델링 한다고 생각을 해 보면, 정규화 과정을 통해서 몇 개의 테이블로 분할되어 설계되어질 것입니다. 이 구조에서 원하는 결과를 얻기 위해서는 복잡한 조인연산을 통해서 데이터를 선별해야하는 복잡한 과정을 거치게 됩니다. 이에 반해서 몽고DB의 경우는 트위터의 정보를 여러 개의 테이블로 분산하지 않고 하나의 문서로 표현하여 저장할 수 있습니다. 모든 정보가 하나의 문서로 저장되기 때문에 복잡한 조인 연산은 필요치 않습니다.

몽고DB와 관계형 데이터베이스의 구조적 차이점

일반적인 관계형 데이터베이스 모델과 몽고DB의 데이터베이스 모델의 저장 구조의 차이는 다음 그림과 같습니다.

[ 관계형 데이터베이스의 저장 구조 ]

[ 몽고DB의 저장 구조 ] 

관계형 데이터베이스와 몽고DB에서 사용되는 용어들의 차이점은 다음과 같습니다.

[ RDBMS와 몽고DB의 용어 정리 ]

다큐먼트(Document) 의 의미

관계형 데이터베이스의 경우에는 열(column)이 모여서 행(row)을 이루고 여러개의 행들이 모여서 테이블(Table)을 구성합니다. 그리고 모든 행들은 동일한 열(row)들로 구성되어 있는 구조입니다. 이런 정형화된 구조로 인하여 SQL을 사용하여 원하는 결과를 빠르게 찾는 이점이 있는 반면에 컬럼을 추가하기 위해서는 모든 레코드에 동일한 저장공간을 만들어야 하는 비효율적인 측면도 존재합니다.

이에 반해 몽고DB의 경우에는 저장되는 데이터의 형식이 정해져 있지 않습니다. 레코드마다 삽입되는 정보의 구조가 틀려도 상관이 없습니다. 이에 반해 SQL을 사용하여 세밀하게 정보를 검색하는 기능은 관계형 데이터베이스에 비해서 다소  떨어집니다. 다음 그림은 관계형 데이터베이스와 몽고DB의 구조적 차이점을 도식화한 것입니다.

[ 관계형 데이터베이스와 몽고DB의 모델 비교 ]

다음 그림은 소셜 뉴스 사이트의 기사를 나타내는 도큐먼트 저장소의 한 형태를 나타내고 있습니다. 여기서 알수 있듯이 도큐먼트 저장소의 기본 구조는 키-값 의 집합입니다. 값들은 숫자, 문자열, 날짜와 같은 데이터 타입이 될 수도 있지만 배열 구조처럼 복잡한 구조를 가질수도 있으며 이를 통해서 다양한 구조를 가진 데이터를 도큐먼트 저장소에 담을수 있습니다. 아래의 그림에서 ‘tags’ 부분을 보면 단순한 배열 구조로 데이터가 저장이 되어 있으며, ‘comments’의 경우에는 좀더 복잡한 배열 구조를 가지고 있습니다.

[ 소셜 뉴스 사이트의 저장 문서의 구조 ]

다큐먼트 저장소에 데이터를 저장하는 형태는 XML, JSON, BSON 형태입니다.

몽고DB의 유연한 쿼리 제공

몽고DB가 많은 사람들에게 각광 받고 있는 것은 빠른 속도와 유연한 쿼리를 제공해주기 때문입니다. 빠른 속도는 관계형 데이터베이스가 가지고 있던 대용량으로 확장하는데 걸림돌을 제거해 주었고, 유연한 쿼리는 관계형 데이터베이스가 가지는 복잡한 쿼리를 대체할 수 있는 기대감을 주었습니다. 

[ 관계형 데이터베이스와 몽고DB의 쿼리 비교 ]

관계형 데이터베이스에서는 애드혹(ad hoc)기능을 지원하고 있습니다. 애드혹이란 데이터베이스 시스템이 받아들일 수 있는 질의를 미리 정의할 필요가 없으며 질의의 내용이 무엇이든지 간에 잘 알려진 형식이면 쿼리가 실행이 된다는 것입니다. 애드혹 기능은 모든 데이터베이스 시스템에서 디폴트로 제공하는 기능은 아니지만 몽고DB에서는 이 그 기능을 대부분 지원하려고 노력하고 있습니다.

몽고DB의 복제 정책

몽고DB는 데이터베이스의 복제(Replication) 기능을 제공합니다. 이 기능은 서버와 네트워크 장애가 발생할 경우를 대비해 데이터를 다른 서버에 백업하고 핵심 서버가 동작이 불가능할 경우 다른 보조 서버에게 핵심서버의 역할을 맡기는 일을 담당합니다.

또한 복제는 데이터베이스의 읽기에 대한 확장을 위해서도 사용됩니다. 데이터베이스 연산 작업시 성능과 가장 밀접한 관계에 있는 것이 데이터베이스에 접근하여 데이터를 읽는 작업입니다. 속도 성능을 개선하기 위해서 여러대의 서버에 읽는 작업을 분산하여 처리를 합니다.

몽고DB에서의 복제 방법은 기본적으로 마스터(Master)-슬레이브(Slave) 방식을 채택하고 있습니다. 마스터가 죽더라도 슬래이브중에서 마스터를 선출할 수 있는 마스터 선출 방식을 채택하고 있습니다.

[ 몽고DB의 복제 정책 ]

쓰기 연산 동작은 마스터에서만 이루어집니다. 쓰기 연산 데이터를 저장하는 곳은 ‘Data Store’와 ‘Oplog’ 두 군데 영역에 저장합니다. ‘Data Store’에는 쓰기 연산을 수행한 결과를 저장하고 ‘Oplog’는 연산 수행과 관련된 명령 자체를 타임스탬프와 같이 저장합니다. 슬래이브는 읽기만 가능합니다.

확장

대부분의 데이터베이스에서 시스템을 확장 하는 방법에는 수직적 확장(Vertical scaling)과 수평적 확장(Horizontal scaling)으로 나눌수 있습니다. 먼저 수직적 확장은 디스크나 메모리를 추가하는 방법을 말합니다. 이 방법은 아주 간단하며 신뢰성이 뛰어나고 비용이 적게 들지만 빅데이터와 같은 대용량 데이터 처리에서는 문제가 발생합니다.

수평적 확장은 데이터베이스를 여러대의 서버에 분산시켜서 저장을 합니다. 이 구조의 장점은 기존의 하드웨어 장비를 그대로 사용할 수 있으며 장애 발생시 복제 서버를 통한 지속적인 서비스 제공이 가능합니다.

몽고DB는 수평적 확장이 용이하도록 설계되었습니다. 자동 샤딩(Auto sharding)을 통해서 데이터를 여러 노드에 걸쳐 분산하는 것을 자동으로 관리해줍니다. 또한 샤딩 시스템은 샤드 노드를 추가해서 용량을 필요한 만큼 늘릴수 있습니다.

몽고DB의 라이센스

몽고DB는 많은 자바 기반의 시스템과 틀리게 C++로 구현되어 있으며, 맥 OS, 윈도우, 리눅스에서 컴파일 되고 실행할 수 있습니다. 바이너리의 경우에는 ‘mongodb.org’에서 다운로드 받을 수 있으며, 해당 소스코드는 오픈되었으며 ‘GNU-AGPL’ 라이센스를 가지고 있습니다.

‘GNU-AGPL’에 대해서는 논란의 소지가 많은데, 이 라이선스가 실제로 의미하는 바는 소스 코드는 무료로 이용이 가능하지만 소스 코드에 대한 수정사항은 커뮤니티의 이익을 우해서 공개되어야 한다는 것입니다. 수정사항에 대해서 공개를 원하지 않는 회사에 대해서는 특별한 상업적 라이선스를 제공하고 있습니다.

가장 인기 있는 NoSQL 솔루션으로 불릴 수 있는 프로젝트는 바로 Memcached입니다. 페이스북(Facebook), 트위터(Twitter), Reddit 및 유투브(YouTube)와 같은 클라우드 및 웹 서비스 회사에서 사용하는 키-밸류 스토어 기반의 인-메모리(In-Memory) 제품입니다.

원래 라이브저널에서 내부적인 용도로 개발 되었고 맴캐시는 작은 크기의 다량의 데이터에 접속할 때 가장 빠른 속도를 제공해줍니다. 맴캐시는 간단한 프로토콜을 넘어서 키-밸류 스토어의 데이터 모델이라 할 수 있으며, NoSQL 커뮤니티내의 산업계 표준으로 사용되고 있습니다.

맴캐시 클라이언트는 대다수의 프로그램 언어에서 사용이 가능합니다. 거의 오늘날 인터넷의 모든 대부분의 큰 사이트에서는 맴캐시를 사용하거나 다른 비슷한 솔루션을 사용하고 있습니다.

Memcached 프로그램의 위치

Memcached는 키-밸류쌍으로이루어져 간단한 데이터 타입을 저장하며, 인-메모리(In-Memory) 기반에서 데이터를 처리하기 때문에 NoSQL처럼 영구적(persistent) 으로 데이터를 디스크에 저장하지는 않습니다. 아래의 그림은 웹 서비스 아키텍처를 설명한 그림으로 여기에서 Memcached 프로그램은 프론트-엔드 웹(Front-end web) 과 백-엔드 데이터베이스(Back-end Database) 사이에 위치합니다.

[ 웹 서비스 아키텍처 ]

멤캐시드(Memcached)의 용도
멤캐시드의 용도는 데이터 요청을 가로채어 가능한 경우 이를 캐시(시스템 메모리)에서 직접 서비스 하게 만들고, 데이터베이스에 연결된 디스크 스토리지에 대한 접근을 줄이는 것이 목적입니다. 그리고 미리 계산된 값을 캐시에서 저장하고 조회하게 하여, 요청 때 마다 많은 양의 계산을 피할 수 있도록 합니다.

논리적 캐시(Cache) 확보 방법

멤캐시드에서 논리적 캐시를 확보하는 방법은 연결된 서버에서 전체 논리적 캐시의 일부분으로 시스템 메모리를 제공합니다. 예를 들면, 각 노드에 128GB의메모리 공간이 있는 10개 노드로 구성된 멤캐시드 클러스터는 전체적으로 1.28TB의 논리적 캐시를 제공합니다. 논리적 캐시는 웹 서비스를 위한 영구 데이터 저장소인 데이터베이스의 내용과 쿼리와 계산 결과들이 사용합니다.

캐시(Cache) 교체 알고리즘

캐시의 키와 값은 LRU(Least Recently Used) 정책과 TTL(Time To Live)을 사용하여 유지 관리됩니다. 웹 서비스에서 사용자에게 요청이 들어오면 데이터베이스에서 요청된 데이터를 인출하기 위해서 여러 번의 접근이 필요하게 됩니다. 속도를 향상시키기 위해서는 데이터베이스에서 데이터를 가져오는 횟수를 줄이고 캐시를 이용하여 데이터를 가져와야 합니다. 효율적인 캐시 교체 알고리즘을 사용하면 데이터베이스에 접근하여 데이터를 가져오는 횟수를 현저히 줄일 수 있습니다.

멤캐시드(Memcached) 아키텍처

데이터구조

멤캐시드는 다음과 같은 4가지 주요 데이터 구조가 있습니다.

① 캐시 항목을 찾기 위한 해시테이블

② 캐시가 가득 찼을 때 캐시 항목 제거(eviction) 순서를 결정하는 LRU 리스트

③ 키(Key), 값(Value), 플래그 및 포인터들을 담고 있는 캐시 데이터 구조

④ 캐시 항목 데이터 메모리 관리자인 슬랩 할당자 (Slab allocator)

해시 테이블 구조

해쉬 테이블의 구조는 버킷(Bucket) 배열을 말합니다. 버킷 배열이란 하나의 주소를 가진 연속된 저장 공간을 말합니다. 하나의 공간은 단방향 링크드 리스트로 구성되어 있습니다.

[ 캐시 항목 조회에 사용되는 해쉬 테이블 데이터 구조 ]

LRU 리스트

제거(eviction) 순서를 결정하는데 사용되는 LUR는 단일 크기의 슬랩(메모리 할당 단위)마다 존재하며, 그 슬랩의 모든 캐시 항목들을 접근 순서대로 유지하는 더블 링크드 리스트(Double linked list) 입니다.

LUR 리스트에서 어떤 캐시 항목을 제거하는 경우 이 리스트의 마지막에 있는 캐시 항목부터 검사하여 가장 오랫동안 사용하지 않은 항목을 찾아냅니다.

[ LRU 데이터 구조 ]

캐시 데이터 구조

캐시 항목 데이터 구조는 키-값 구조로 데이터가 들어가고, 다음과 같은 메타데이터(Metadata)도 들어 있습니다.

① 해시테이블에서 버킷(Bucket) 당 단일 링크드 리스트를 가리키는 포인터

② LRU에서 이중 링크드 리스트에 사용되는 포인터

③ 캐시 항목에 동시에 접근하는 스레드 수를 나타내는 레퍼런스 카운터

④ 캐시 항목 상태 플래그

⑤ 키(Key)

⑥ 값 길이(Byte)

⑦ 값(Value)

슬랩 할당자

슬랩 할당자는 캐시 항목에 대한 메모리 관리 기능을 제공합니다. 캐시 항목은 상대적으로 크기가 작아서 시스템 콜(malloc/free)을 사용한 작은 메모리 청크(chunk)의 할당 및 해제는 속도가 느리고 스래싱(thrashing)이 발생할 가능성이높습니다. 그래서 멤캐시드는 이 방법 대신에 할당 단위로 슬랩을 사용합니다. 스랩은 내부에 많은 항목들을 포할할 수 있는 큰 메모리 청크(Chunk)입니다.

예를 들면, 1,024바이트 메모리 청크의 슬랩은 64바이트 이하 캐시 항목을 16개까지 저장 가능합니다. 슬랩 할당자는 우선 큰 메모리를 할당하고 Free 리스트를 유지합니다. 캐시 항목을 접근할 때마다 슬랩 할당자는 저장할 값 크기를 확인하고 수용할 수 있을 만큼 큰 슬랩내의 캐시 항목을 되돌려줍니다. 어떤 경우에는 이 방법이 공간을 비효율적으로 사용하기도 하지만 성능이 좋고 메모리 스래싱을 피할 수 있습니다.

2014년 NoSQL 순위는 아래와 같습니다.

Key-value stores

Document stores

Graph DBMS

Wide column stores

레디스(Redis, Remote Dictionary Server) 는 인-메모리(In-Memory) 기반의 키-밸류 스토어(Key-Value Store)입니다. 성능은 데이터를 메모리에 바로 처리하므로 메모리 기반의 데이터베이스에 비해서 속도가 빠릅니다. 또한 저장할 수 있는  데이터 타입의 경우에 다른 저장소는 기본적인 프리미티브 타입(Primitive Type)만을 제공하는데 반해서 레디스는 문자열(String), 스트링 집합(Set), 해쉬(Hash), 리스트(List)등의 다양한 데이터 타입을 지원하고 있으며, 데이터에 대한 검색, 추가, 삭제등의 기능을 기본적으로 제공합니다. 

아래의 그림은 레디스의 구조도 입니다. 레디스 인스턴스(Radis Instance)는 가상 머신 (또는 물리 서버) 위에서 실행되며, 하나의 가상 머신에 1개 이상의 인스턴스를 가동시킬수 있습니다. 아래의 그림에서 3개의 샤드(Shard)로 구성되어 있으며 각각의 샤드는 마스터/슬레이브 구조로 이중화되어 있습니다. 각각의 샤드에는 전체 데이터의 일부가 저장되어 있으며, 마스터 노드의 복제본을 슬레이브에서 가지고 있는 구조입니다.

[ 레디스의 구조도 ]

레디스의 데이터 타입 설명

레디스의 장점은 값 영역에 들어갈 수 있는 데이터 타입이 프리미티브 타입 뿐만 아니라 다양하고 풍부한 데이터 구조를 넣을 수 있습니다. 이러한 데이터 구조는 하나의 키당 총 2^32개의 데이터를 이론적으로 저장할 수 있으나 최적의 성능을 낼 수 있는 것은 일반적으로 1,000~5,000개 사이로 알려져 있습니다.

[ 레디스 데이터 구조 ]

Strings

레디스의 가장 기본적인 데이터형으로 키당 하나의 값을 저장할 수 있습니다. 스트링이라고 해서 문자열만 저장할 수 있는 것이 아니라 이진(Binary)데이터도 가능합니다.

키당 넣을 수 있는 데이터의 최대 크기는 512M 바이트이며, 데이터의 값이 정수인 경우에는 ‘int’로 아닌 경우에는 ‘raw’로 인코딩(Encoding) 됩니다. 참고로 레디스에서는 정수형, 실수형을 구분하지 않습니다.

Sets

Sets은 정렬되지 않은 집합형을 말합니다. 집합이기 때문에 한 키에 중복된 데이터는 존재하지 않습니다. 왜냐하면 동일한 키에 “ABCD” 값을 두번 추가해도 Sets 상에는 “ABCD” 값은 하나만 존재하게 됩니다.

이 데이터형의 장점은 데이터의 검색, 추가, 삭제시 소모되는 시간이 Sets 안에 포함된 수에 상관없이 일정하다는 것입니다. 또한 집합간의 연산을 지원하며 교집합, 합집합, 차집합등의 연산을 매우 빠르게 수행할 수 있습니다. 한 키에 넣을 수 있는 데이터의 최대 개수는 4,294,967,295 (2^32-1) 개입니다. 

[Set의 구조 ]

Sorted Sets

Sets의 각 요소마다 ‘score’라는 실수값을 가지고 있는 형태입니다. 요소들은 정렬된 형태로 보여지는데, ‘score’ 값을 기반으로 오름차순 정렬을 합니다. Sets와 마찬가지로 동일한 키에서 각 데이터들의 값은 유일합니다.

데이터의 추가, 제거, 갱신은 매우 빠른 방법으로 진행되는데 이런 특징으로 인하여 랭킹 시스템이나 다른 데이터 형의 정렬을 위한 인덱스 값으로 활용할 수 있습니다. 예를 들어 Hashes로 사용자 데이터를 저장하는데 나이에 따른 정렬이 필요한 경우, Sorted Sets에 데이터의 ‘score’ 에는 나이 값을 넣어주고, 값으로는 사용자 ID를 넣어주면 됩니다.

[ Sorted Set의 구조 ]

Hashes

해싱(Hashing)은 키 값에 직접 산술적인 연산을 적용하여 항목이 저장되어 있는 테이블의 주소를 계산하여 항목에 접근하는 방법입니다. 값의 연산에 의해 직접 접근이 가능한 구조를 해시 테이블(hash table)이라 부르며, 해시테이블을 이용한 탐색을 해싱(Hashing)이라 부릅니다.

해시 함수(Hash function)은 탐색키를 입력받아 해시 주소(Hash address)를 생성하고 이 해시 주소가 배열로 구현된 해시 테이블(Hash table)의 인덱스를 구합니다.

[ 해싱의 방법 ]

리스트(List)

순서를 가지고 일렬로 나열한 원소들의 모임으로 정의할 수 있습니다. 순서가 있다는 점에서 집합과 구별되며, 일렬로 나열되어 처음과 끝이 각각 하나씩만 있다는 점에서 트리나 그래프와도 구별됩니다. 일반적으로 이러한 구조를 링크드 리스트(Linked List)라고 부릅니다.

링크드 리스트는 데이터를 저장할 때 그 다음 순서의 데이터가 있는 위치 정보를 데이터에 포함시키는 방식으로 자료를 저장합니다.

[ 연결 리스트(Linked List) 구조 ]

인-메모리 상태에서의 데이터 저장 방법

레디스는 메모리 기반 데이터베이스 이기 때문에 전원이 꺼지면 모든 데이터가 모두 사라지게 됩니다. 이러한 경우를 방지하기 위해서 파일에 메모리 내용을  저장해 두고 레디스 서버 실행시 다시 그 파일에서 데이터를 읽어와 메모리상에 올리는 기능을 제공하는데 이를 Persistence(지속성) 이라고 부릅니다.

레디스에서 데이터를 저장하는 방법은 Snapshotting 방식과 AOF(Append On File) 두가지 방식이 제공하고 있습니다. 두가지 방식은 하나만 선택하는 것이 아니라 두가지 모두 병합하여 사용할 수 있습니다. 두가지 방식을 모두 사용하도록 설정한 상태에서 레디스 서버를 실행하면 보통은 AOF를 이용하여 데이터를 메모리로 가져오게 됩니다.

RDB 방식

RDB 방식은 메모리상의 데이터를 모두 파일로 덤프를 뜨게 됩니다. ‘save’ 와 ‘bgsave’ 두가지 방식이 있습니다. ‘save’는 동기식(Blocking) 방식으로 순간적으로 레디스의 모든 동작을 정지 시킨 후에 메모리 내용을 디스크에 저장합니다.

‘bgsave’는 비동기식(Non-Blocking) 방식으로 백그라운드에 별도의 프로세스(Process)를 실행시킨 후에 수행 당시의 메모리 내용을 디스크로 저장하며, 레디스는 동작을 멈추지 않고 정상적으로 작업을 수행합니다. 저장 파일은 보통 ‘.rdb’ 확장자를 사용합니다.

레디스가 메모리의 내용을 디스크에 덤프하는 과정은 다음과 같습니다.

① 레디스의 포크(fork)로 자식 프로세스를 생성한다.

② 자식 프로세스는 임시 rdb 파일에 데이터를 저장한다.

 ③ 자식 프로세스가 새로운 rdb 파일에 데이터 쓰기를 마치면 임시 rdb 파일로어전 rdb 파일을 덮어 씁니다.

이 방식의 장점은 특정 시점의 백업 및 복구에 유리하며, 레디스 서버가 디스크에 저장하기 전까지는 디스크 I/O가 발생하지 않으므로 성능을 극대화 시킬수 있습니다. 마지막으로 AOF에 비해 더 빨리 메모리에 데이터를 올리고 작업을 시작할 수 있습니다.

단점으로는 사고 발생시 백업이 일어난 시점이후의 데이터는 유실할 수 있으며, 백업 작업시 fork()로 자식 프로세스를 생성해서 백업 작업을 수행하는데, 이 시점에 저장할 데이터가 많아서 순간적으로 CPU에게 과부하를 줄 수 있습니다.

AOF(Append On File) 방식

AOF 방식은 레디스의 모든 write/update 연산 자체를 모두 로그(Log) 파일에 기록하는 형태입니다. 서버가 재 시작될 때 기록된 write/update 동작을 순차적으로 재 실행하여 데이터를 복구합니다. 저장되는 파일의 확장자는 ‘.aof‘ 를 사용합니다.

AOF는 설정에서 파일을 쓰는 시점에 3가지 옵션을 선택할 수 있는데, 기본값인 ‘everysec’를 사용합니다. 또한 정전등의 문제로 AOF 파일이 손상될 수 있습니다. 이 경우에는 ‘redis-check-aof’ 툴을 사용하여 복구가 가능합니다.   

이 방식의 장점은 사고 발생시 손실되는 데이터가 최소화되며, 정전등의 문제로 AOF 파일에 문제가 생긴다고 해도 ‘redis-check-aof‘ 툴을 사용하여 복구가 가능합니다. 또한 AOF 파일의 형식이 단순하여, 문제가 있는 부분만 삭제하고 복구를 해도 됩니다.

발행자(Publish)와 구독자(Subscribe) 프로토콜(Protocol)

이 프로토콜은 양방향을 제공해 주기 때문에 레디스를 pub/sub (publish/subscribe, 발행자와 구독자의 의미) 메시지 센터로서 사용될 수 있게 해줍니다. 클라이언트는 메시지 채널을 구독할 수 있고 레디스는 다른 클라이언트가 구독된 채널에 메시지를 발행하면 클라이언트에게 발송해 줍니다.

[ Publish/Subscribe 구조 ]

(여기서 채널을 구독하고 발행한다는 의미는 방송국과 TV의 관계를 생각하면 될 것 같습니다. TV는 채널을 보게 되면 구독하게 되고 방송국은 컨텐츠를 TV에 발행합니다. 하지만 여기서 틀린 점은 TV에서 방송국으로 정보를 보낼 수 있습니다. 즉 TV와 달리 양방향 채널이라는 점이 틀린점 입니다.)

복제 토폴로지(Replication Topology)

레디스는 NoSQL 계열의 키-밸류 스토어인데도 확장성(Scalability)을 지원하지 않습니다. 이로 인하여 확장성과 성능에 제약사항이 있는데, 마스터(Master)/슬레이브(Slave) 구조의 복제를 지원하기 때문에 확장성 부분에서 어느 정도 융통성을 가집니다.

마스터(Master)/슬레이브(Slave) 복제(Replication)

마스터/슬레이브 복제란 마스터 노드에 있는 내용을 복제를 통해서 슬레이브 노드에 복제하는 것을 의미합니다. 1개의 마스터 노드는 N개의 슬레이브 노드를 가질 수 있으며, 각 슬레이브 노드도 다른 슬레이브 노드를 가질 수 있습니다.

[ 마스터 / 슬레이브 복제 구조 ]

마스터/슬레이브 간의 복제는 Non-Blocking 상태에서 이루어집니다. 이 말은 마스터 노드가 어떤 동작을 수행하고 있을 때에도 백그라운드에서 슬레이브 노드로 데이터를 복제할 수 있다는 것을 의미합니다. 이 경우에 슬레이브 노드에서 데이터를 조회할 경우 이전 내용이 조회될 수도 있습니다.

Query Off Loading을 통한 성능 향상

마스터 노드의 내용을 슬레이브로 복제하는 이유는 조회 성능을 높이기 위해서입니다. Query Off Loading은 마스터 노드에서는 쓰기 동작을 담당하고 슬레이브 노드에서는 조회 동작을 담당합니다. 이렇게 쓰기와 조회를 분리하는 이유는 대부분의 데이터베이스의 트랜젝션은 쓰기동작이 10~20%, 조회 동작에서 70~80%의 시간을 사용하기 때문에 조회 동작을 여러 노드로 분산시킨다면 속도를 비약적으로 증가시킬수 있습니다.

Sharding을 통한 용량 확장

레디스가 클러스터링을 통한 확장성을 제공하지 않기 때문에 일반적으로 Sharding 아키텍처를 이용합니다. Sharding은Query Off Loading과 마찬가지로 RDBMS나 다른 NoSQL에서도 많이 사용하는 아키텍처입니다. 여러 개의 레디스 서버를 구성한 후에 데이터를 일정 구역별로 나누어서 저장하는 방법입니다. 데이터 분산에 대한 통제권은 클라이언트가 가집니다. 샤딩(Sharding)은 데이터를 여러 개의 데이터베이스에 분할해서 저장하는 방법입니다. 분할하는 방법에 따라서 수평적 샤딩(Horizontal Sharding) 과 수직적 샤딩(Vertical Sharding)으로 나눌 수 있습니다.

수평적 샤딩(Horizontal Sharding)

수평 분할(Horizontal Partitioning)은 스키마가 동일한 데이터를 행을 기준으로 두 개 이상의 테이블에 나누어 저장하는 방법을 말합니다. 수평 분할로 인하여 각 테이블의 데이터와 인덱스의 크기가 감소하고 작업 동시성이 늘어나 성능 향상을 기대할 수 있습니다.

[ 수평 분할 ]

수평적 샤딩은 물리적으로 다른 데이터베이스에 데이터를 수평 분할방식으로 분산 저장하고 조회하는 방법을 말합니다. 수평적 샤딩은 성능상의 이익뿐만 아니라 하나의 데이터베이스 인스턴스에 넣을 수 없는 큰 데이터를 분산하여 처리하기 위해서 사용됩니다. 분할된 각 데이터베이스를 ‘Shard’ 또는 ‘Database Shard’라고 부릅니다.

[ 수평적 샤딩 ]

수직적 샤딩(Vertical Sharding)

수직적 샤딩은 데이터베이스를 수직으로 나누어서 분산 저장하는 방식을 말합니다.

[ 수직적 샤딩 ]

키-값(Key-Value) 및 문서 데이터베이스는 행(row)에 초점을 맞춥니다. 이 말은 하나 또는 그 이상의 조건에 일치하는 완벽한 데이터를 검색하는 최적화된 환경을 제공해 줍니다. 그러나 때때로 프로그램은 열에서 데이터를 검색할 필요가 있습니다. 컬럼 패밀리는 개념적으로 열의 집합체이고 각 열은 키-값의 쌍으로 구성되어 있습니다.

컬럼 패밀리 데이터베이스에서 열은 컬렉션(Column Collection) 구조를 가지며 하나의 행은 많은 열을 포함할 수 있습니다. 컬럼 패밀리의 유연성은 프로그램에게 관계형 데이터베이스에서도 지원하는 복잡한 쿼리와 데이터 분석을 수행할 수 있는 능력을 제공해 줍니다. 

컬럼 패밀리 데이터베이스는 방대한 양의 데이터를 저장하도록 설계되어 같은 시간에 데이터를 매우 빠르게 접근할 수 있습니다. 잘 설계된 컬럼 패밀리 데이터베이스는 본질적으로 매우 빠르고 확장성이 뛰어납니다.

컬럼 패밀리란?

이름에서 알수 있듯이 컬럼 패밀리는 NoSQL 데이터베이스로부터 컬럼 패밀리 데이터베이스를 구분짓는 특징입니다. 컬럼 패밀리는 단순히 테이블에서 데이터를 보유한 컬럼의 집합입니다.. 컬럼 패밀리는 개념적으로 행과 열의 집합으로 구성되어 있는 관계형 데이터베이스의 테이블과 비슷합니다. 그러나 관계형 데이터베이스의 테이블과는 달리 컬럼 패밀리에서의 열은 정의된 스키마를 엄격하게 준수할 필요가 없습니다.

예를 들어, 컬럼 패밀리 데이터베이스에 고객의 이름을 포함할 경우에 아래의 그림과 같이 컬럼 패밀리를 만들수 있습니다. 이 컬럼 패밀리는 제목(title)과 고객 이름으로 구성되어 있습니다. 이 그림에서 고객은 유일키(Unique key)인CustomerID를 사용하여 데이터를 식별할 수 있습니다.

그러나 각 열에서 정의한 고객 데이터의 구조는 서로 다를 수가 있습니다. 아래의 그림에서 정의한 ‘MiddleName’ 의 경우 상황에 따라서 존재할 수도 있고, 없을 수도 있습니다. 상황에 따라서 특정한 열이 작업에 필요 하지 않을 경우에는 쉽게 작업 대상에서 제외하면 됩니다. 이 접근법은 관계형 데이터베이스의 테이블에 비해서 매우 효율적으로 데이터를 저장할 수 있습니다.

[ 고객 정보를 보유한 컬럼 패밀리 ]

어떤 경우에는 열(column) 영역에서 정해진 이름을 사용하는 것보다 가변적으로 변하는 이름을 사용할 수도 있습니다. 예를 들어 아래의 그림은 고객이 보유한 주식을 모니터링하는 금융 기관의 주식 포트폴리오 관리 시스템에서 특정 부분을 컬럼 패밀리로 만들어서 보여주고 있습니다. 

[ 주식 시세 기호를 기초로 한 이름의 컬럼 패밀리 ]

고객을 위한 포트폴리오는 상장 기업에 대한 채권과 주식을 포함할 수 있습니다. 포트폴리오 컬럼 패밀리는 열(column) 에서 데이터의 구조를 키-값 형태로 저장할 수 있습니다. 여기서 키에 해당하는 것은 주식의 이름이며, 값으로는 보유한 주식의 수로 표시할 수 있습니다. 고객이 새로운 주식를 구입한 경우 이름이 다른 주식이 목록에 추가될 수 있습니다. 대부분의 컬럼 패밀리 데이터베이스는 컬럼의 값으로 스칼라 타입(Scalar type)을 지원합니다.