문서 저장소(Document Store)

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

ACID   ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어입니다. 짐 그레이는 1970년대 말에 신뢰할 수 있는 트랜잭션 시스템의 이러한 특성들을 정의하였으며 자동으로 이들을 수행하는 기술을 개발해 냈습니다. 1983년 앤드리스 류터(Andreas Reuter)와 테오 하더(Theo Harder)는 ACID라는 용어를 만들면서 이를 기술했습니다.   데이터베이스에서 데이터에 대한 하나의 논리적 실행단계를 트랜잭션이라고 합니다. 예를 들어, 은행에서의 계좌이체를 트랜잭션이라고 할 수 있는데, 계좌이체 자체의 구현은 내부적으로 여러 단계로 이루어질 수 있지만 전체적으로는 ‘송신자 계좌의 금액 감소’, ‘수신자 계좌의 금액 증가’가 한 동작으로 이루어져야 하는 것을 의미합니다.   원자성(Atomicity)은 트랜잭션과 관련된 작업들이 모두 수행되었는지 아니면 모두 실행이 안 되었는지를 보장하는 능력입니다. 자금 이체는 성공할 수도 실패할 수도 있지만 원자성은 중간 단계까지 실행되고 실패하는 일은 없도록 하는 것입니다.   일관성(Consistency)은 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미합니다. 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단됩니다.   고립성(Isolation)은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미합니다. 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미합니다. 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없습니다. 공식적으로 고립성은 트랜잭션 실행내역은 연속적이어야 함을 의미합니다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건입니다.   지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미합니다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미합니다. 전형적으로 모드 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴수 있습니다. 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있습니다.

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

개체(엔티티, Entity) 식별 가능한 사건, 사물등의 의미 있는 하나의 정보 단위를 말합니다. (학생, 고객, 주문 등)   속성(Attribute) 개체(Entity)의 특성이나 상태를 기술하는 것을 말한다. 아래의 그림에서 학생번호, 이름, 학과, 학년등이 속성에 속한다. 속성은 컬럼, 필드, 도메인으로도 불립니다.   튜플(Tuple) 튜플은 행 또는 레코드를 말합니다.    [ 학생 엔티티 ]

 

 

 

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

 

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

 

 

문서란 무엇인가?

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

 

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

 

3층 스키마 (3-Level Schema)   데이터베이스에서 말하는 스키마(Schema)는 자료의 구조, 자료의 표현 방법, 자료간의 관계를 정의한 것을 말하는 전산학 용어이며, 3층 스키마 구조로 되어 있습니다. 3층 스키마는 사용자, 설계자, 개발자가 데이터베이스를 보는 관점에 따라 데이터베이스를 기술하고 이들간의 관계를 정의한 ANSI 표준을 말합니다.  [ 3층 스키마의 구성요소 ]   외부 스키마(External Schema)는 사용자 관점이며, 사용자의 입장에서 데이터베이스의 모습으로 조직의 일부분을 정의한 것입니다. 개념 스키마(Conceptual Schema)는 설계자 관점이며, 모든 응용 시스템과 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 데이터베이스 구조를 논리적으로 정의한 개념입니다. 마지막으로 내부 스키마(Internal Schema)는 개발자 관점이며 전체 데이터베이스의 물리적 저장 형태를 기술하는 개념입니다.   [ 3층 스키마의 개념도 ]

 

 

문서 데이터베이스는 다릅니다. 대부분의 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) 필드는 전화번호 목록을 포함하고 있습니다.

  

{"CustomerID":99,  "Title":"Mr",  "FirstName":"Mark",  "LastName":"Hanson",  "Address":{     "StreetAddress":"999 500th Ave",     "City":"Bellevue",     "State":"WA","ZipCode":"12345"  },  "Telephone":["111-2223334","222-1112223","333-2221114"]}   {"CustomerID":100,  "Title":"Ms",  "FirstName":"Lisa",  "LastName":"Andrews",  "Address":{     "StreetAddress":"888 W. Front St",     "City":"Boise",     "State":"ID",     "ZipCode":"54321" }, "Telephone":["555-4443332","444-5552223","333-5554442"]}

  

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

 

 

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

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

 

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

 

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