류프리

문서 저장소 또는 문서 지향 데이터 저장소는 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 순으로 사람들에게 사랑을 받고 있습니다.

그래프(Graph) 란?

그래프 이론은 그래프의 특성을 연구하는 수학과 컴퓨터 과학의 한 분야로써, 특정 집단내 대상들 간의 관계를 그래프로 나타낸 수학적 구조입니다. 여기서의 그래프는 노드(Nodes)와 두 노드를 연결하는 선(Edge)으로 구성되어 있습니다. 

[ 정점과 간선 ]

이는 페이스북에서 사람이 정점이 되고, 친구 관계가 간선으로 표현되는 것으로 비교할 수 있습니다. 이 기술은 페이스북, 트위터와 같은 규모가 있는 분산 환경에서 대상 사이의 연관 관계를 파악하기 쉽게 해 줍니다. 예를 들어 사람들 사이의 관계를 그래프로 처리해두면, 아무리 복잡한 인간관계라도 빠르게 파악할 수 있습니다.

쾨니히스베르크 다리 문제

그래프 이론을 말할 때 자주 인용되는 이야기 중의 하나가 ‘쾨니히스베르크 다리’ 문제입니다. 아래 그림처럼 프로이센의 쾨니히스베르크(오늘날 러시아 칼리닌그라드)에는 강이 있었고, 강으로 둘러싸인 섬이 하나 있었습니다. 섬을 잇는 다리가 7개가 있는데 사람들 가운데 운동이나 산책을 하면서 이 다리들을 모두 한 번씩만 건너서 출발한 곳으로 다시 돌아오려고 하는 이들이 있었습니다. 

[ 오일러 시절 쾨니히스베르크의 지도 ]

쾨니히스베르크 다리 문제로 잘 알려진 이 문제는 스위스의 수학자 오일러가 관심을 두기 전에는 누구도 해답을 찾지 못했다고 합니다. 수학자 오일러는 이 문제를 해결하기 위하여 강으로 분할된 도시의 부분들을 꼭짓점으로 생각하고, 다리를 변으로 생각하여 다음과 같은 그래프를 고안하였습니다.

[ 오일러 그래프 ]

오일러는 어떤 그래프가 한 꼭지점에서 시작하여 펜을 떼지 않고 모든 변을 한 번씩만 지나서 처음 출발점으로 되돌아올 수 있으려면 그래프의 각 꼭짓점에 연결된 변의 개수가 모두 짝수이어야 함을 증명하였습니다. 따라서 쾨니히스베르크의 다리에 관한 문제는 해가 존재하지 않는다는 것을 밝혔습니다.

그래프 데이터베이스(Graph Database)

그래프 데이터베이스 저장소는 엔티티와 엔티티 사이의 관계를 저장합니다. 그래프 데이터베이스 내에서 데이터 모델은 엔티티와 관계를 중심으로 돌아갑니다. 그들은 표현하고 저장하고 데이터를 쿼리하기 위해 그래프형의 구조 (노드와 관계 그리고 속성)을 사용합니다. 그래프 데이터베이스는 더 많은 데이터들이 각각의 데이터 포인트의 집합의 연결로 표현될 수 있기 때문에 근래들어 많이 채택되고 있습니다.

[ 엔티티 개념의 예]

[ 부서와 사원간의 관계의 예 ]

그래프 데이터베이스는 대부분 지역적인 문제들, 추천 엔진, 네트워크/클라우드 분석, 생물정보학(bioinformatics) 등에 사용되는데, 크게 보면 데이터 사이의 관계가 데이터 자체 만큼이나 중요한 어느 곳이든 쓰일 수 있습니다. 이는 다양한 금융 분석 기능에서도 중요한 기술이 될 것입니다.

2000년대에 들어서면서 인터넷의 발전과 SNS 서비스의 활성화로 특정 고객이 아닌 전세계 사람들을 대상으로 하는 형태의 서비스로 발전되었고 이전까지 볼수 없었던 대규모 데이터를 만들었습니다. 이는 기존의 데이터 저장 시스템으로는 처리할 수 없는 여러가지 한계를 야기했고 새로운 형태의 데이터 저장 기술을 요구하게 되었습니다.

인터넷 기업이면서 대용량 단순 데이터를 가장 많이 보유하고 있었던 구글과 아마존에 의해서 구글의 빅테이블(Google’s Bigtable) 과 아마존의 다이나모(Amazon’s Dynamo) 제품이 선을 보였고 이 두 기업의 영향으로 새로운 형태의 데이터베이스가 탄생하게 되었습니다.

기존의 오라클등의 RDBMS 중심의 데이터 저장 기술 시장에 새로운 데이터 저장 기술인 NoSQL이 등장하는 계기가 되었습니다. NoSQL은 Not Only SQL의 약자로 기존 RDBMS 형태의 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 의미합니다.

관계형 데이터베이스의 경우 모든 노드가 같은 시간에 같은 데이터를 보여주는 일관성과 일부 노드가 다운되어도 다른 노드에 영향을 주지 않아야 하는 유효성에 중점을 두고 있는 반면, NoSQL기술은 네트워크 전송 중 일부 데이터를 손실하더라도 시스템이 정상 동작을 하는 분산 가능성에 중점을 두고 일관성과 유효성은 보장하지 않습니다.

이러한 특성으로 NoSQL 데이터베이스들은 기존의 관계형 데이터베이스에 비해 특수한 목적에 따라 보다 빠른 처리가 가능하여, 대용량의 데이터를 분산시켜 저장하고 실시간으로 처리할 수 있는 기능을 제공합니다.

NoSQL의 특징

① NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않습니다.

RDBMS의 경우 데이터의 관계를 외래키(Foreign Key) 등으로 정의하고 이를 이용해 조인(Join) 등의 관계형 연산을 하는 반면, NoSQL은 데이터 간의 관계를 정의하지는 않습니다. 테이블 간의 관계는 정의하지 않고 테이블간의 조인도 불가능합니다.

② RDBMS에 비해 대용량의 데이터를 저장할 수 있습니다.

분산처리 시스템을 이용하여 대용량의 데이터를 저장할 수 있습니다.

③ 분산형 구조

NoSQL은 기존의 RDBMS와는 다르게 고성능 머신에 데이터를 저장하는 것이 아니라, 보통의 서버들을 연결해서 데이터를 여러 대의 서버에 분산해 저장하고, 분산시점에 데이터를 복제하여 특정 서버의 고장으로 인한 장애가 발생하였을 경우에도 서비스가 가능한 구조를 가지고 있습니다.

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

RDBMS와는 다르게 테이블의 스키마가 유동적입니다. 예를 들어 다음의 테이블과 같은 형태일 경우 반드시ID, 이름, 주소 순서로 입력하여야 합니다. 

[ 예제: RDBMS 테이블 구조 ]

이에 반해서 NoSQL의 경우에는 ID로 사용하는 키 부분만 타입이 동일하고 나머지는 동일하지 않아도 상관이 없습니다.

[ 예제: NoSQL 테이블 구조 ]

⑤ Document-Based 방식

데이터를 문서 형태로 저장합니다.

⑥ 트랜잭션이 없음

MySql과 같은 RDBMS가 가지고 있는 트랜잭션 (예: 은행 예금 출금시 중간에 여러 단계를 거치는데, 중간에 에러가 나면 롤백하는 기능) 기능이 없으므로, 포인트나 결재등 중요한 데이터에 대한 정합성 문제가 발생할 수 있습니다.