류프리

NewSQL은 NoSQL처럼 높은 확장성과 성능을 갖춘 RDB를 일컫는다. SQL을 지원하고, SQL이 트랜잭션 데이터를 처리하기 위해 기업이 갖추고 있어야 할 4가지 속성인 ACID(Atomicity, Consistency, Isolation, Durability) 등록 정보를 준수합니다. 여기에 NoSQL의 특징인 확장성과 유연성을 데이터베이스 관리 시스템(DBMS)에 더했습니다. SQL과 NoSQL에서 장점만 뽑아 결합한 형태입니다.

하둡의 엔터프라이즈 시장 진입

빅데이터 표준 플랫폼은 하둡(Hadoop) 입니다. 하둡과 빅데이터의 엔터프라이즈 시장 진입이 계속 늦어지고 있습니다. 하둡 진영은 SQL 쿼리 분석을 하둡에서 보다 빠르게 수행할 수 있느냐를 열쇠로 보고 관련 기술을 개발하기 위해 노력중입니다.

SQL-온-하둡

‘SQL-온-하둡(SQL on Hadoop)” 혹은 ‘대화형(Interactive) 쿼리 엔진(Query Engine)’ 등으로 불리는 기술은 2012년부터 본격적인 개발경쟁 양상을 보였습니다. 클라우데라의 임팔라(Impala), 호튼웍스의 스팅거(Stinger), 맵R의 드릴(Drill)등이 대표적인 제품입니다. EMC 자회사 피보탈이니셔티브가 올해초 호크(HAWK)를 내 놓으며 엔터프라이즈 시장 진입에 출사표를 던졌습니다. 한국의 그루터도 ‘타조(Tajo)’ 개발에 박차를 가하고 있습니다.

아파치(Apache)의 하이브(Hive)

이 같은 움직임의 중심에 아파치 하이브(Hive)가 있습니다. 하이브는 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)에 저장된 데이터를 SQL과 유사한 하이브QL(HiveQL)로 분석하게 해주는 기술입니다. 하지만 대용량 병렬처리(MPP, Massively Parallel Processing) 기반의 데이터웨어하우스(DW)에 비하면 하이브의 쿼리속도는 현저히 느립니다. 질의를 던질때마다 맵리듀스 작업을 매번 수행하기 때문입니다. 질의를 던지고 결과를 받기까지 수시간을 기다려야 합니다. 이 때문에 대화형 쿼리 분석엔 적합하지 않다는 평을 받고 있습니다..

빅데이터 관련업계는 하이브의 이 같은 한계를 극복해야 하둡이 엔터프라이즈 시장에 진입할 수 있을 것으로 보고 있습니다. 하이브가 SQL에 익숙한 사람들에게는 성에 차지 않습니다.

'SQL-온-하둡'의 두갈래 대처 방안

진영은 두갈래로 나뉩니다. 하이브를 완전히 대체하는 새 기술을 쓸 것인가? 아니면 하이브를 개선해 속도를 높일 것인가? 하지만, 하이브는 사실상 시한부 판정을 받았다는 쪽으로 여론이 흐르고 있습니다. 하이브를 만든 페이스북조차 ‘프레스토’란 새로운 데이터웨어하우스(DW) 엔진을 만들었습니다.

호튼웍스의 스팅어

하이브를 살려야 한다는 입장을 가장 강력하게 내세운 회사는 호튼웍스다. 호튼웍스는 하이브를 최적화하고 파일 포멧 작업을 통해 하이브 쿼리속도를 100배 끌어올리겠다는 비젼을 내놓았습니다. 호튼웍스는 하이브야말로 SQL-온-하둡을 위한 최고의 선택이라며 3단계에 걸친 개선계획을 발표했습니다. 이것이 바로 스팅어(Stinger)입니다.

호튼웍스는 하이브의 성능을 35~45배 끌어올리기로 했습니다. 다양한 쿼리 기능을 추가하고 ORCFile 같은 파일 포맷으로 성능을 끌어올리는 것이 2단계입니다. 그리고 맵-리듀스 대신 아파치 테즈(Tez)란 새 기술을 이용해 하이브에 접목합니다. 이를 통해 최종적으로 하이브의 SQL 쿼리 속도를 100배 향상시킨다는 것입니다.

그루터의 타조

하이브를 버리고 새로운 엔진을 찾아야 한다는 진영은 타조가 대표적이다. 타조는 하이브를 개선하는데 한계가 명확하기 때문에, 대용량 SQL 쿼리 분석에 적합하지 않다는 입장입니다. 애초 기획 단계부터 하이브를 대체하는 새로운 엔진으로 개발되고 있습니다.

클라우데라의 임팔라

클라우데라의 임팔라도 하이브를 대체하는 엔진입니다. 그러나 일정 규모 이상의 데이터는 임팔라로 분석할 수 없습니다. 임팔라가 메모리 기반 처리 엔진이어서, 일정 용량 이상에선 디스크 환경의 하이브를 사용해야 합니다. 그러나 SQL on Hadoop이란 전체 틀에선 하이브를 버리는 쪽으로 무게를 두고 있습니다.

하이브의 한계

구도상 하이브에 주요 회사중에서 호튼웍스만 전력을 기울이는 것처럼 보인다. 하지만, 호튼웍스도 장기적으로는 하이브를 유지하자는 입장으로 단정하기는 어렵다. 바로 스팅어의 핵심인 테즈 때문입니다. 테즈는 SQL 처리시 맵-리듀스를 대신하는 새 기술입니다. 다수 개발자들은 맵리듀스를 사용하지 않는 하이브는 하이브가 아니다라고 반문합니다. 맵-리듀스 와 하이브 조합을 버리는 순간 하이브라 부를수 없다는 것입니다.

호튼웍스의 입장을 십분 받아들인다고 해도 하이브의 한계는 뚜렷합니다. 호튼웍스가 최근 올린 블로그가 그 한계를 스스로 보여줍니다. TPC-DS 벤치마크에서 호튼웍스 데이터 플랫폼(HDP)2.0을 사용했을 때 44배의 속도개선을 보였다고 주장했습니다. 그런데 그 비교 대상이 최근버전인 하이브 0.11이 아니라 하이브 0.10버전입니다.

하이브는 0.10 버전에서 0.11버전으로 업데이트되면서 이미 32배의 속도 개선을 이루었습니다. 즉 호튼웍스의 주장은2007년에 만들어져 이제 거의 사용되지 않는 버전보다 44배 빠르다는 것이다. 직접 버전인 0.11과 비교하면 30% 가량 빨라졌을뿐입니다.

하이브의 미래

하이브의 미래에 대한 징후는 현재 개발되는 하이브 0.12버전의 코드 기여도 통계에서도 나타납니다. 호튼웍스가 공개한 자료에 의하면, 하이브 0.12 코드라인 기여자 소속회사 통계(8월 30일 기준)에서 호튼웍스는 8만 3천 742라인으로 절반을 훌쩍 넘긴 비중을 차지합니다. 다음으로 페이스북이 3만 148라인을 차지합니다. 세번째로 많은 기여자는 한국의KT 넥스알입니다. KT 넥스알은 1만2천 103라인을 기여했습니다. 다음은 4천244라인을 기부하였으며, 클라우데라는 3천528라인을 기부했습니다.

주목할 부분은 페이스북과 클라우데라 입니다. 페이스북은 하이브 0.10을 내 놓는데 가장 많은 비중을 차지했던 회사입니다. 그런 페이스북이 점차 하이브에 대한 관심을 줄여가고 있는 것입니다. 호튼웍스와 함께 아파치 하둡 프로젝트의 주요 기여자인 클라우데라의 기여도는 호튼웍스의 2%에 불과합니다. 주요 기여자의 참여축소와 기타 기여자의 비중도 확연히 줄었습니다.

하둡 진영이 ‘SQL-온-하둡’에 열을 올리는 이유

하둡 생태계는 왜 하이브와 SQL on Hadoop에 이토록 열을 올리고 있는가? 이는 SQL을 쓸수 있는냐가 엔터프라이즈 시장에서 하둡을 사용하느냐로 직결되기 때문입니다.

엔터프라이즈는 데이터웨어하우스(DW) 시스템과 고급 분석도구, 비즈니스 인텔리젼스(BI)를 사용하는 집단입니다. 기업의 분석가 집단이 주요 사용자입니다. 이들은 정형화된 데이터를 이용해 여러 분석을 시도하는데, 간단한 SQL 쿼리만 활용할 뿐 복잡한 프로그래밍 능력은 갖고 있지 않습니다. 프로그래밍은 IT 부서의 일이라 여깁니다. 분석가는 분석을 할 뿐 기술엔 관심이 없습니다.

기업 분석가 집단이 보기에 하둡은 생소하고 어려운 기술일 수밖에는 없습니다. 자신들은 잘 알지도 못하는 다양한 프로그래밍 작업을 요구하기 때문입니다. 현존 데이터 분석도 만족스러운데 굳이 본업도 아닌 프로그래망까지 하려니 당연히 필요성을 못 느낍니다. SQL과 유사한 도구인 하이브도 그 속도가 너무 느립니다.

하이브를 만들어낸 회사는 인터넷서비스 회사인 페이스북입니다. 하이브를 가장 많이 활용하는 회사도 페이스북입니다. 하둡과 하이브를 다양하게 사용하는 회사도 야후, 넷플릭스, 트위터, 페이스북과 같은 인터넷 서비스 회사들은 여러 사람이 사용하기 바라는 마음으로 하둡과 하이브를 만들지 않았습니다. 이 회사의 개발자들은 자사의 서비스를 개선하는 과정에서 SW를 만들고, 그를 외부에서도 쓸 수 있게 공개한 것 뿐입니다. 페이스북이 만든 하이브라면 페이스북 개발자가 활용하기 좋은 수준 정도로 만들어집니다. 엔터프라이즈 기업의 기대치와 당연히 거리가 있습니다.

개발자 입장에선 하둡과 하이브를 이용해 분석하는데 거리낌이 적습니다. 개발자로서 전문 분석가는 아니지만, 예전에 하지 못했던 분석을 할 수 있게 됐으니 그 정도 성능이면 충분하다고 느끼는 것입니다.

엔터프라이즈의 분석가와 인터넷 서비스 업체의 개발자 사이엔 높고 두터운 벽이 존재합니다. 빅데이터와 하둡이 엔터프라이즈 시장으로 진입하려면 기업 내 분석가를 설득해야 합니다. 데이터웨어하우스(DW)와 성능도 비슷하고 분석도 쉽다는 메시지를 앞세워야 합니다. SQL-온-하둡은 바로 이 벽을 지나는 문입니다.

드레멜은 데이터 분석에 적합한 기능을 가지고 있으며, 조 단위가 넘는 데이터를 가진 테이블에 대한 쿼리를 순식간에 처리할 수 있고, 수천 개의 CPU와 페타바이트급 데이터로 확장이 가능하며 SQL 쿼리(Query)를 지원하기 때문에 일반 사용자도 편리하게 사용할 수 있습니다.

드레멜은 2011년 공개된 구글 빅-쿼리(Big Query) 서비스에 사용된 분석 기술로 위키피디아를 수초만에 조회할 정도로 빠른 속도를 자랑합니다. 드레멜에서 아이디어를 얻은 오픈소스 하둡 진영이 새로 구현한게 클라우데라의 임팔라(Impala)와 호튼웍스의 스팅어(Stinger) 제품의 ‘SQL-온-하둡(SQL on Hadoop)’ 입니다.

구글 운영에 있어 수천 명의 사용자들은 웹 문서 분석, 안드로이드 앱을 위한 설치 데이터 추적, 충돌 보고, 수십만 디스크를 위한 디스크 I/O 통계 유지 등과같은 다양한 애플리케이션에서 드레멜을 사용합니다.

빅쿼리(BigQuery)는 드레멜에 기반한 호스트 기반 빅데이터 분석 서비스입니다. 막대한 양의 서버에 대한 로그 데이터를 준비하고, 지우고, 변형하고, 옮기기 위해서는 하둡의 맵리듀스 기술이 사용되고, 데이터 분석에 대해서는 드레멜이 사용됩니다. 

스팅어는 아파치 하이브(Apache Hive)의 쿼리 속도를 현재보다 100배 높인다는 프로젝트로, 대화형 쿼리 분석을 실현하기 위해 개발되고 있습니다. 클라우데라의 임팔라, 그루터의 타조 등이 맵리듀스와 하이브를 대체하는 새로운 쿼리엔진을 개발하는데 비해 스팅어는 하이브의 최적화와 포맷 변경으로 속도를 개선하는데 초점을 맞추고 있습니다.

호튼웍스는 하이브야말로 SQL-온-하둡(SQL on Hadoop)을 위한 최고의 선택이라고 생각하며, 3단계에 걸친 개선 계획을 발표했습니다.

스팅어 1단계(Stinger Phase One) – 하이브 0.11 (HDP 1.3)

HDP1.3에 포함된 스팅어 1단계는 하이브 0.11를 사용합니다. 스팅어 1단계에서는 SQL 호환성 개선(일반적인 분석 쿼리에 대해 35~45배 성능 향상)과 컬럼 스토어 기술, 압축, 인메모리 해시 조인 등이 개발되었습니다.

스팅어 2단계(Stinger Phase Two) – 하이브 0.12 (HDP 2.0)

HDP2.0에 포함된 스팅어 2단계는 하이브 0.12를 사용합니다. 하지만 맵리듀스 엔진은 그대로 사용해 얀(YARN, Yet Another Resource Negotiator) 아키텍처의 이점을 활용하지 못했습니다. VARCHAR 및 DATE 데이터 타입을 통해서 단순화된 SQL 상호 운영성을 지원하며, 여러가지 요인에 의해서 복잡한 쿼리(Query)의 속도를 향상시키는 새로운 쿼리 최적화 작업을 진행하여, 스팅어 2단계에서는 1단계보다 60~70배 정도의 성능개선이 있었습니다. 

[ 하이브의 데이터 유형 ]

스팅어 3단계(Stinger Phase Three)

현재 진행형인 스팅어 3단계는 맵-리듀스를 대체하는 테즈(Tez)엔진으로 데이터 처리부를 교체하는 작업이 주요 내용입니다. 호튼웍스는 HDP2.0을 통해 여러 하둡 스택도 최신 버전으로 업데이트했습니다. 

임팔라는 하둡상에서 맵-리듀스(Map-Reduce)를 이용하지 않고 SQL(Standard Query Language)을 처리하는 기능을 내장한 제품입니다. 임팔라를 이용하면 하둡(Hadoop)의 하이브(Hive) 기술을 사용하지 않고서도 SQL 분석이 가능함으로써 데이터 처리시간을 단축할 수 있습니다.

하이브(Hive) 구조의 문제점

하이브(Hive)는 유사 ANSI SQL을 사용할 수 있어 기존 분석가가 쉽게 사용할 수 있다는 장점을 가지고 있는 반면에, 대용량 병렬처리 기반 데이터 웨어하우스(DW, Data Warehouse) 시스템보다 SQL 실행 시간이 많이 소요된다는 단점이 있습니다.

이유는 하이브가 SQL을 맵-리듀스(Map-Reduce) 작업으로 변환하는 작업이 중간에 추가되었기 때문입니다. 맵-리듀스는 사용자들이 제어하기에는 불편한 점이 많고 처리 속도가 느리다는 태생적 단점이 있습니다.

피그(Pig)와 하이브(Hive)는 맵-리듀스 프레임워크의 사용 편의성을 높이기 위해서 2008년에 등장한 플랫폼이었습니다. Pig와 Hive 모두 하둡의 서브 프로젝트이며, 하이-레벨 언어(High-Level Language)입니다. 차이점은 Pig는 절차적인 언어임에 반해서 Hive는 SQL과 유사한 선언적인 언어입니다. Pig와 Hive의 등장으로 하둡 사용자들이 편리하게 대용량 데이터 분석작업을 수행할 수 있었습니다.

Pig나 Hive 모두가 사용자들에게 데이터를 쉽게 조회할 수 있는 수단을 제공한 반면에 데이터를 처리하기 위해서는 맵-리듀스 언어로 변환되어 처리가 되었습니다. 문제는 맵-리듀스는 분산 환경에서 대용량의 데이터를 배치(Batch) 형태로 처리되도록 설계가 되어서, 속도가 느린 단점을 가지고 있었고, 이로 인하여 Pig와 Hive 역시 맵-리듀스 위에서 동작하기 때문에 같은 문제점을 가지고 있는 것입니다.

[ 하이브와 맵-리듀스의 관계 ]

아파치 임팔라(Impala)

임팔라는 H베이스(HBase)나 맵-리듀스 같은 별도 계층을 거치지 않고 HDFS(Hadoop Distributed File System)와 직접 통신을 합니다. 그리고 하이브처럼 ‘하이브쿼리언어(HiveQL)’를 사용합니다.

클라우데라는 임팔라와 하이브의 최대 차이를 성능으로 꼽습니다. 하이브는 자바로 만들어졌지만 임팔라는 C++ 기반으로 만들어졌으며, 별도의 실행엔진을 사용하므로 맵-리듀스 프로그래밍을 할 필요가 없습니다.

임팔라는 맵-리듀스와는 달리 쿼리(Query)를 아주 낮은 지연속도로 처리할 수 있다고 합니다. 맵-리듀스에 있는 ‘셔플링(Shuffling)’ 단계를 거치지 않아 테이블간의 조인(Join) 작업도 반드시 맵-리듀스 처럼 다대다 커뮤니케이션을 요구하지 않습니다.

[ 임팔라 다이어그램 ]

2012년부터 하둡 분야의 주요 관심사 중에 하나가 임팔라와 타조 같은 ‘SQL 온 하둡(SQL on Hadoop)’ 기술이였습니다. 그 이유는 임팔라 같은 기술이 완성이 되면, 하둡이 실시간으로 대용량 데이터를 분석할 수 있는 기반이 마련이 된 것이며, 기존의 데이터웨어하우스(DW) 제품을 대체할 수 있는 가장 중요한 문제를 해결한 것이기 때문입니다.

기업들은 고가의 하드웨어를 사용하는 데이터웨어하우스(DW) 어플라이언스와 솔루션을 구매하지 않고, 저가의 하드웨어와 솔루션 업체에 종속되지 않는 오픈소스를 확보하게 되어 비용면에서도 큰 이익을 취할 수 있습니다. 

현재 빅데이터 시장에서 주로 사용하고 있는 데이터베이스(Database)는 NoSQL 계통의 데이터베이스입니다. H베이스(Hbase), 카산드라(Cassandra), 몽고DB(MongoDB), 레디스(Redis) 등이 여기에 속합니다. 빅데이터 등장 후에 대용량 데이터 처리 방식을 놓고 관계형 데이터베이스(RDB, Relational Database) 처리 도구로 써 왔던 SQL로 데이터 처리를 계속할 지, 아니면 데이터의 분산 처리가 가능한 NoSQL을 선택할 지는 지금까지도 데이터베이스 관리자(DBA)나 웹서비스 개발자들에게는 고민거리가 아닐 수 없습니다.

RDBMS은 비정형 데이터의 처리가 필요 없던 시절에는 최적의 기술로 인정을 받았습니다. 시간이 흐르고 사진, 동영상, 소셜네트워크서비스(SNS) 등과 같은 비정형 데이터의 출현으로 인하여 DB 관리 시스템에 변화가 생기기 시작합니다.

개발자들은 자연스럽게 비정형 데이터를 쉽게 처리하고 저장할 수 있는 NoSQL로 눈을 돌리기 시작했습니다. NoSQL은 ‘Not Only SQL’ 로서 우리말로 해석하자면 “SQL 뿐만 아니라” 이며, 정해진 틀이 잡혀 있는 SQL에서 벗어나 분산 아키텍처의 확장성, 유연성 등을 장점으로 내세우며 데이터 분산 처리 시 필요한 기술로 자리잡기 시작했습니다.

많은 종류의 NoSQL 데이터베이스가 존재하는 이유로는 부루어의 정리(Brewer’s Theorem)로 알려진 ‘CAP’ 정리를 들수가 있습니다. CAP 정리는 일관성(Consistency), 가용성(Availability), 파티션 수용성(Partition Tolerance) 이라는 세가지 요소들 중에서 모두 만족하기는 힘들고 최대 두 가지 사항에 대해서 만족하면 된다는 이론입니다. 이 때문에  NoSQL 데이터베이스가 많이 존재하는 것입니다. 

[ NoSQL 데이터베이스 선정 기준 ]

NoSQL은 뛰어난 확장성을 가지고 있는 반면에 스카마 변경이 불가능해 데이터에 문제가 발생하면 감지하는게 쉽지가 않고 처리속도에서도 문제가 발생하였습니다. 여기에 SQL과 같이 정해진 언어가 없는데다가 도큐먼트 스토리지 기반으로 되어 있어서 레코드를 개발해 본인이 직접 넣어야 하는 식이다 보니 개발자들로부터 ‘다루기 어렵다’라는 말이 나오기 시작합니다.

이러한 배경으로 현재는 기존의 SQL 기반의 RDB 장점을 수용하고, 확장성과 유연성등 NoSQL의 장점을 가미한 NewSQL이 등장하게 된 것입니다.

가장 인기 있는 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 리스트를 유지합니다. 캐시 항목을 접근할 때마다 슬랩 할당자는 저장할 값 크기를 확인하고 수용할 수 있을 만큼 큰 슬랩내의 캐시 항목을 되돌려줍니다. 어떤 경우에는 이 방법이 공간을 비효율적으로 사용하기도 하지만 성능이 좋고 메모리 스래싱을 피할 수 있습니다.

레디스(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)을 지원합니다. 

문서 저장소 또는 문서 지향 데이터 저장소는 NoSQL의 대표적인 표상이 되었습니다. 이들 시스템은 ACID의 엄격함이 중요하지 않을 경우에 관계형 데이터베이스를 대체할 수 있는 용도로서 주로 사용되고 있습니다. 

일반적으로 이 부류의 NoSQL은 좀더 복잡한 논리 데이터 모델을 갈망하는 사람들의 요구와 맞아 떨어졌습니다. 문서가 기본적인 개체(엔티티, Entity)이기 때문에 그들은 문서 지향 이라고 불렀습니다. 문서는 ID를 가지고 그룹화된 속성들의 집합체입니다. 관련 문서들은 일반적으로 네임 스페이스(Name Space)로 그룹화 되어져 있습니다. 이 속성들이 사실대로 무엇인지 모두 정의할 필요는 없고 네임스페이스 내의 모든 문서에는 모두 속성들을 가지고 있어야 합니다. 

데이터 볼륨과 워크로드 볼륨을 위한 시스템들을 스케일링하는 것은 관계형데이터베이스보다 제약이 많지 않기 때문에 관계형 데이터베이스보다 쉽습니다. 트랜잭션에 있는 정확성보다 수집/저장 성능이 좀더 중요한 경우에 문서 저장소의 사용을 고려할 수 있습니다.

여기서는 일반 문서 데이터베이스의 주요 기능을 설명하고 신속하고 효율적으로 구조화된 정보를 저장하고 검색할 수 있는 기능을 가장 잘 활용한 문서를 디자인 할 수 있는 방법을 설명합니다.

문서란 무엇인가?

문서 데이터베이스에서의 문서는 명명된 필드(namedfields) 의 컬렉션(collection)을 포함한 간단한 개체(엔티티, Entity)입니다. 마이크로소프트 워드와 PDF 파일로 만든 문서와 혼동하면 안됩니다.

관계형 데이터베이스의 경우 데이터를 저장하기 전에 먼저 데이터를 보유할 테이블을 작성해야 합니다. 테이블 작성시 스키마를 정의하고 각 데이터 항목이 포함된 열을 지정합니다.

문서 데이터베이스는 다릅니다. 대부분의 NoSQL 데이터베이스는 스키마가 없습니다. 이것이 의미하는 것은 데이터베이스는 단순히 데이터를 저장하는 저장소의 역할을 하지만 데이터를 어떻게 저장하고 관리하는 것은 프로그램에서 담당하기 때문에 해당 데이터에 어떤 형태의 정형화된 구조를 강요하지는 않습니다. 그들은 효과적으로 데이터를 원하는대로 저장할 수 있기 때문에 프로그램의 역할이 커집니다.

문서 데이터베이스는 자체적으로 표현될 수 있는 문서를 필요로 하고, JSON, BSON, XML과 같이 잘 알려진 형식으로 정보를 문서 데이터베이스에 저장합니다. 저장되는 데이터 타입은 숫자(number), 날짜(date) 및 부울(boolean)등의 일반적인 데이터 타입을 지원하며, 필드에서는 정보를 복잡한 구조를 정의할 수 있습니다.

문서 데이터베이스 디자인

문서 데이터베이스에서 데이터의 구조는 데이터베이스를 사용하는 프로그램의 성능에 중요한 영향을 미칠 수 있습니다. 문서 구조를 디자인 할 때는 다음과 같은 요인들을 고려해야 합니다.

① 어떻게 문서속의 데이터와 컬렉션을 분할하고, 문서속의 데이터를 정규화(normalize) 또는 비 정규 화(denormalize)할 것인가? 

② 데이터가 어떻게 동적이며, 프로그램은 어떻게 많은양의 생성(create), 삭제(delete), 변경(update) 동작을 수행할 것인가?

데이터를 문서로 모델링

데이터를 문서 데이터베이스로 저장할 때, 처음에는 프로그램이 데이터베이스가 예상하는 형식(JSON, BSON, XML)으로 모든 객체를 직렬화해서 데이터베이스에 기록합니다. 이는 프로그램이 같은 타입의 제한된 객체(Object)의 집합을 처리하는 경우에는 적합할 수 있습니다. 하지만 대부분의 경우에는 거대한 양의 데이터 복제를 초래할 가능성이 있습니다. 문서 데이터베이스를 최대한 활용하기 위해서, 쿼리를 최적화하기 위해서 문서의 구조를 설계해야 합니다.

비정규화(Denormalizing) 문서 및 포함(Embedding) 데이터

이 전략은 중복 데이터를 제거할 수는 있지만, 필연적으로 많은 양의 작은 문서들로 이루어지기 때문에 관계형 데이터베이스의 접근방식에 따라 문서를 설계하지 말아야 합니다. 이 경우 개체(엔티티, Entity)를 위해서 데이터를 재구성하기 위해서 프로그램은 여러 문서에서 데이터를 검색하고 결합할 수도 있습니다.

관계형 데이터베이스는 테이블에서 데이터를 조인(Join) 할 수 있는 일반화된 쿼리(Query)를 최적화하고 지원하도록 설계되었지만, 문서 데이터베이스는 아닙니다. 대부분의 문서 데이터베이스는 쿼리에서 문서의 조인을 지원하지 않으므로, 이러한 작업은 프로그램에서 수행되어야 합니다.

문서를 설계하는 일반적인 방법은 프로그램이 데이터를 검색하고 처리하는 방법을 검토하는 것입니다. 이상적인 방법은 프로그램이 문서 데이터베이스에 질의를 수행할 때, 한번만에 문제를 해결하는 것입니다. 개체(Entity)의 세부사항을 표시하고 관리하는데 필요한 모든 정보를 문서에 포함시키기 위해서는 데이터를 비정규화(Denormalize) 해야 합니다.

예를 들면, 프로그램이 전화번호와 주소를 포함한 고객에 대한 정보를 검색하고 저장할 경우, 다음 그림과 같은 개념적 구조를 사용할 수 있습니다.

 [ 고객 정보를 포함하는 문서 컬렉션의 개념적 구조 ]

JSON 측면에서 이 두 고객을 위한 문서 구조는 다음 코드와 같습니다. 주소(Address) 필드가 중첩된 문서이며, 전화번호(Telephone) 필드는 전화번호 목록을 포함하고 있습니다.

이 구조는 고객 ID를 기반으로 데이터를 검색하기에 매우 적합합니다. 또한 고객 이름 등의 기준에 따라 데이터를 검색하는 쿼리를 수행할 수 있습니다. 전화번호와 주소를 분리해서 다른 문서로 저장할 수 있지만 비 정규 문서의 경우에는 한 문서에 관련된 세부 정보들을 모두 포함하고 있습니다.

정규화(Normalizing) 문서 및 참조 데이터

비정규 문서에서 프로그램이 데이터를 가져오기 위해서 질의하는 문서의 수를 줄임으로써 최적화할 수 있습니다. 최대한 적은 문서에 연관되는 정보들을 저장하는 방법입니다. 그러나 이러한 방법은 문서의 크기가 커질 수 있는 부작용을 가질수 있으며, 데이터를 정규화하는 것이 더 적절할 수 있습니다.

다음의 그림은 정규화 방법의 예를 나타내고 있습니다. 각각의 판매 주문정보는 고객 ID를 지정하지만, 고객에 대한 상세한 정보는 포함하고 있지 않습니다. 프로그램에서 주문을 자주하고 고객의 세부 사항에 대한 정보를 검색 할 경우, 고객 상세 정보가 판매 주문 문서에 직접 포함되어야 한다고 주장할 수 있습니다. 이 경우에 고객의 세부사항은 추가되거나 변경될 소지가 높습니다. 따라서 별도의 컬렉션으로 고객 세부사항을 관리하는 것이 좋습니다.

[ 판매 주문 정보를 포함하는 문서 컬렉션의 개념적 구조 ] 

키-값(Key-Value) 스토어(Store)는 NoSQL 데이터베이스 중 가장 간단한 것입니다. 이름에서 알 수 있듯이, K-V 스토어는 키와 값을 한 쌍으로 저장하며, 더 이상의 기능이 없고 단지 키 기반으로 값을 저장할 수 있습니다. 많이 알려진 프로그래밍 언어의 맵(Map) 또는 해시 테이블(Hash Table)과 동일한 방법을 사용합니다.

일부 K-V 스토어 구현 시스템에서는 해시나 리스트와 같은 복잡한 값의 데이터 타입을 허용하지만 꼭 필요한 것은 아닙니다. 그리고 저장된 키들을 순환 처리하는 방법을 제공하지만 이것 역시 보너스로 생각하면 됩니다. 만일 파일의 경로는 키로, 파일의 내용은 값으로 생각한다면 파일 시스템을 키-값 스토어라고 할 수 있을 것입니다.

K-V 스토어는 자체적으로 필요로 하는 것(자원 등)이 거의 없어서 이런 유형의 데이터베이스는 많은 경우에는 놀랄 만한 성능을 보여줄 수 있습니다. 그러나 복잡한 쿼리(Query)나 집합 연산이 필요할 때는 그리 도움이 안 될 것입니다.

Key-Value Store 디자인

키-값 저장소에서는 데이터의 각 조각들은 키-값 쌍으로 구성되어, 키를 사용하여 데이터베이스에 값을 저장합니다. NoSQL 데이터베이스에서는 키-값 저장소가 분산 서버에 분할되어 저장될 가능성이 높습니다.

애플리케이션이 데이터를 검색할 때, 키를 키-값 저장소에 제공합니다. 키-값 저장소는 키를 해시하여 저장된 위치에서 값을 가져옵니다.

[ 분산 서버에서 데이터 검색 ]

해싱 함수(Hashing Function)의 효율성(Efficiency)과 일관성(Consistency) 관리

해시를 사용하여 키-값 저장소에서 분산 서버에 데이터를 저장하고 검색하기 위해서는 해쉬 함수에서 키를 기반으로 값의 위치를 계산하는 로직의 성능이 중요합니다. 만약 두 키가 동일하여 같은 위치의 값을 접근하게 되면 충돌이 발생합니다. 키-값 저장소는 이러한 충돌를 감지하고 이를 해결하기 위해서 준비를 해야 합니다.

삽입에 대한 충돌 감지 및 처리

키-값 데이터베이스는 새로운 위치를 결정하기 위하여 보조 해시(Secondary hash)를 사용하거나 선형 검색을 수행합니다. 어느 경우에도 추가 작업은 데이터베이스의 반응성(Responsiveness)을 감소시킬 수 있습니다. 다음의 그림은 키-값 저장소에서 새 항목을 추가할 때 충돌을 감지하고 처리하는 과정을 보여줍니다. 충돌을 검출하는 방법은 파티션에서 다음 이용 가능한 슬롯에 값을 저장하는 것입니다.

[ 삽입에 대한 충돌 감지 및 처리 ]

검색할 때 충돌을 감지하고 데이터 처리

애플리케이션이 데이터를 검색할 때 키-값 저장소는 충돌 이전에 일어난 경우에 적용하기 전에 재 해시 함수를 이용하여 계산된 위치에 유지키를 검사합니다. 키가 정확하지 않을 경우, 키-값 저장소는 데이터를 삽입할 때 처럼 동일한 전략을 이용하여 데이터의 위치를 조사합니다. 다음의 그림은 그 과정을 보여줍니다.

[ 검색할 때 충돌을 감지하고 데이터 처리 ]

아래의 그래프는 2013년 기준으로 가장 인기 있는 키-밸류 스토어 제품의 순위를 나타내고 있습니다. Redis, Memcached, Riak, DynamoDB 순으로 사람들에게 사랑을 받고 있습니다.