1. NoSQL Data Models
NoSQL은 이제 인지 단계에서 벗어나 사용 단계로 발전되고 있다. 이 글을 본격적으로 전개하기 전에 NoSQL에는 어떤 것이 있고, 각 제품별 특성은 어떤 것이 있는지 간단히 살펴본다. 이전에 NoSQL에 대한 별도 연재가 나갔으므로 여기서는 본문 이해 차원에서 소개한다.
그림 1. NoSQL 카테고리와 종류
1.1 키 밸류형 NoSQL
키 밸류(Key-Value)형은 말 그대로 키와 값의 쌍으로 관리되고 키를 사용해 값을 확인하는 기본적인 스타일의 NoSQL이다. 특징은 데이터 모델이 단순하다는 점이다.
키 범위 처리를 요구하는 경우 적용이 안돼 Key-Value 모델의 가장 큰 약점 중 하나다. 그래서 정렬된 Key-Value(Ordered Key-Value) 모델이 이 한계를 극복해 발전시켰다.
프로그래밍 언어에서 자주 등장하는 연관 배열 대신에 이용할 수 있고, 사용자 정보와 세션 정보를 여러 응용 프로그램 간에 공유하고, RDBMS의 검색 결과를 저장하는 등 현재 RDBMS가 기 구축된 응용 프로그램에 적용하기 쉬운 것이 특징이다.
RDBMS는 행(레코드) 단위로 데이터를 취급하는 반면, 칼럼형 NoSQL은 열 단위로 데이터 액세스를 한다. 특징은 지정된 열의 데이터를 빠르게 검색할 수 있다. 열 단위로 업데이트하는 대규모 데이터 검색 시스템 또는 업데이트 작업이 많은 경우 유용하다.
1.3 도큐먼트형 NoSQL
데이터가 일정한 형식을 취할 필요가 없는 데이터베이스 즉, 스키마가 필요 없는 데이터베이스이다. RDBMS 데이터 모델링 시 테이블 정의를 필요로 하는 반면, Document방식의 NoSQL은 포맷이 서로 다른 경우에도 상관 없다. 특징은 유연한 스키마와 인덱스를 통해 자동 색인 기능이 있다는 점이다. 미리 형식을 결정할 필요가 없기 때문에 변경 빈도가 높은 데이터베이스에 적용된다.
1.1 키 밸류형 NoSQL
키 밸류(Key-Value)형은 말 그대로 키와 값의 쌍으로 관리되고 키를 사용해 값을 확인하는 기본적인 스타일의 NoSQL이다. 특징은 데이터 모델이 단순하다는 점이다. 키 범위 처리를 요구하는 경우 적용이 안돼 Key-Value 모델의 가장 큰 약점 중 하나다. 그래서 정렬된 Key-Value(Ordered Key-Value) 모델이 이 한계를 극복해 발전시켰다. 프로그래밍 언어에서 자주 등장하는 연관 배열 대신에 이용할 수 있고, 사용자 정보와 세션 정보를 여러 응용 프로그램 간에 공유하고, RDBMS의 검색 결과를 저장하는 등 현재 RDBMS가 기 구축된 응용 프로그램에 적용하기 쉬운 것이 특징이다.
1.4 그래프형 NoSQL
데이터의 관계(노드, 관계, 프로퍼티) 정보를 저장하는 데이터베이스다. 주로 소셜 네트워크 등의 관계 데이터 분석에 활용된다.
2. NoSQL 데이터 모델링의 고려사항
NoSQL의 데이터 모델링은 관계형 데이터베이스 모델링과 달리 애플리케이션에 특화된 쿼리를 가진다. 그래서 비즈니스를 먼저 정의하고 거기에 맞는 쿼리 결과를 예측한 다음 데이터 모델링을 해야 한다.
？ -관계형 데이터 모델링의 중점은 사용 가능한 데이터 구조에서 출발한다. 그래서 데이터 모델링의 관점은 ‘내가 어떤 답을 가지고 있는가?’ 이다.
？ -NoSQL 데이터 모델링은 특정 애플리케이션에서 접근하는 액세스 패턴에서 출발한다. 즉, 지원되는 쿼리 가능성 여부다. 주요 모델링의 관점은 '자신은 무엇을 알고 싶은가?'이다.
？ -관계형 데이터베이스 모델링에 비해 NoSQL 데이터 모델링 시에 데이터 구조와 알고리즘에 대한 깊은 이해가 필요로 한다.NoSQL 데이터 모델링에 있어서 데이터 중복과 비정규화는 가장 중요한 사항이다. 계층적이거나 그래프 기반의 데이터 모델링은 기존 관계형 데이터베이스로는 매우 불편하다. 이런 경우에는 그래프 NoSQL이 해답을 줄 수 있다.
3. NoSQL 데이터 모델링의 기본 원칙들
3.1 개념적인 기법들
이 장에서는 NoSQL 데이터 모델링의 기본 원리에 대해 설명한다.
3.1.1 비정규화(Denormalization)
비정규화는 NoSQL 데이터 모델링의 필수 불가결한 원칙이다. 비정규화는 쿼리를 단순화？최적화하기 위해 사용자 데이터를 특정 데이터 모델에 맞추기 위해 동일한 데이터를 여러 다큐먼트나 테이블에 복사하는 것을 말한다. 비정규화는 다음과 같은 이율배반 (trade-offs)이 존재한다.
？ -쿼리 데이터 볼륨 or 쿼리당 I/O vs. 전체 데이터 볼륨 비정규화를 사용하면 특정 쿼리를 처리하기 위해 필요한 모든 데이터를 한 곳에 모아둘 수 있다. 이를 통해 입출력에 대한 부담을 줄일 수 있다. 그런데 질의마다 다른 데이터들을 조합하기 위해 여러 가지 조합으로 동일한 데이터를 접근하게 된다. 같은 데이터에 대해 다른 방법의 조합으로 조회할 수 있음을 말한다. 따라서 비정규화를 통해 각 질의에 맞는 조합으로 데이터들을 모은다면 결국 같은 데이터를 복사해야 하고 그 결과 전체 데이터 볼륨은 늘어나게 된다.
？ -처리의 복잡성 vs 전체 데이터 볼륨 정규화와 사후 쿼리로 조인을 사용한다면 쿼리 프로세서의 부담을 가중시킬 수밖에 없다. 특히 분산 시스템에서는 더더욱 복잡해진다. 대신 비정규화를 적용하면 쿼리 처리를 단순하게, 쿼리 친화적인 구조로 데이터를 저장할 수 있다. 물론 이 경우도 전체 데이터 볼륨은 증가한다.
키 밸류 스토어 데이터베이스, 도큐먼트 데이터베이스, 빅테이블(BigTable) 유형의 데이터베이스가 이에 해당된다.
3.1.2 집계(Aggregates)
대부분의 NoSQL은 어떻게든 소프트한 스키마를 제공한다.
？ -Key-Value 저장소와 그래프 데이터베이스는 일반적으로 값에 제약을 갖지 않기 때문에 값은 임의의 형식을 포함할 수 있다. 또 하나의 비즈니스 엔터티를 위해 복합 키를 사용해 약간의 레코드를 바UserID_email, UserID_messages 등의 복합 키를 가진 항목 집합으로 모델링할 수 있다. 만약 사용자가 전자메일 및 메시지를 갖고 있지 않으면 해당 항목은 기록되지 않는다. ？
-BigTable 모델은 칼럼 패밀리 안에 다양한 칼럼 집합과 각각의 셀 버전 변수 같은 소프트 스키마를 지원한다. ？
-도큐먼트 데이터베이스는 기본적으로 스키마리스이지만, 일부 제품은 사용자 정의 스키마를 사용해 입력 데이터의 유효성을 검증한다.
소프트 스키마는 복잡한 내부 구조(중첩된 엔티티)의 엔티티 클래스를 형성할 수 있고, 특정 엔터티의 구조를 변경할 수 있다. 이 기능은 두 개의 큰 특징을 제공한다.
？ -엔티티의 중첩을 통해 one-to-many 관계를 최소화해 결과적으로 조인을 줄일 수 있다. ？
-하나의 도큐먼트 집합또는 테이블을 사용해 잡다한 비즈니스 엔터티의 모델링과 비즈니스 엔티티 사이의 ’기술적인’ 차이를 희석시킬 수 있다.
이러한 특징을 보여주는 것이 <그림 2>이다. 이 그림은 e커머스 비즈니스 도메인에서 제품 엔티티 모델링을 보여준다. 우선 모든 제품은 ID, Price, Description을 갖고 있고, 제품의 유형마다 다른 속성을 가질 수 있다. 예를 들어 Book의 Author, Jeans의 Length와 같이 다른 속성을 가질 수 있다. 이러한 속성 중 일부는 Music Album의 Tracks와 같이 one-to-many 또는 many-to-many의 특성을 갖는다. 그리고 어떤 엔티티는 고정된 유형으로 모델링 할 수 없다. 예를 들어, Jeans 속성은 브랜드와 특정 제조자가 모두 다르다. 이런 문제는 관계형 정규화 데이터 모델을 통해 해결할 수 있지만, 이 해결 방법은 현명하지 않다. 소프트 스키마를 통해 모든 종류의 제품과 그 속성들을 모델링해 단일 군집화(product) 기법을 사용할 수 있다.
그림 2. Entity Aggregation
비정규화는 업데이트의 성능과 일관성에 큰 영향을 미친다. 따라서 업데이트 흐름에 특별한 주의가 필요하다. 키 밸류 스토어, 도큐먼트 데이터베이스, 빅테이블 계열의 데이터베이스가 이에 해당된다. 다.
3.1.3 애플리케이션 사이드 조인(Application Side Join)
NoSQL 솔루션은 조인이 거의 지원하지 않는다. NoSQL의 질의지향의 특성으로 인해 조인은 쿼리 실행시간에 처리되는 관계 모델링과 달리 설계시에 처리된다. 쿼리를 실행할 때 조인은 항상 성능 저하를 가져오지만 많은 경우 비정규화 및 집계(군집화), 예를 들어 중첩된 엔터티를 사용해 이 문제를 해결 할 수 있다. 물론 조인이 불가피할 경우 애플리케이션에서 처리해야 한다. 주요 사례는 다음과 같다.
그림 3. Join 사례
？ -Many-to-Many 관계는 보통 링크에 의해 모델링되고 조인이 필요하다. ？
-집계(Aggregates) 엔티티 내부가 자주 수정되는 경우 적용할 수 없다. 일반적으로 뭔가 일어났다는 것에 대해 레코드로 유지하는 것이 바람직하고, 값을 변경하지 않고 쿼리 실행 시에 조인하는 것이 낫다. 예를 들어 메시징 시스템은 Message 요소를 중첩해 User 엔티티로 모델링할 수 있다. 그러나 메시지가 자주 추가된다면, Message를 별도의 엔티티로 취급하고 쿼리할 때 조인하는 게 바람직하다.
키 밸류 스토어, 도큐먼트 데이터베이스, 빅테이블 계열의 데이터베이스, 그래프 데이터베이스가 이에 해당된다.
3.2 일반 모델링 기법들
이 장에서는 다양한 NoSQL 구현에 적용할 수 있는 일반적인 모델링 기법에 대해 알아 본다.
3.2.1 원자 집계(Atomic Aggregate)
전부는 아니지만, 제한적으로나마 NoSQL 솔루션은 트랜잭션을 지원한다. 분산 잠금 또는 application-managed MVCC를 사용해 트랜잭션을 보장하지만, ACID 특성의 일부를 보장하기 위해 집계 기법을 사용해 데이터를 모델링하는 것이 일반적이다. MVCC 기법은 하나의 레코드에 대해 변경이 발생할 경우 그 레코드의 원래 버전은 그대로 유지한 채 새로운 버전을 만들어 그 새로운 버전에 대해 변경을 수행함으로써, 비록 한 트랜잭션이 동일 레코드에 대해 연산을 수행하고 있더라도 그 레코드를 검색하는 다른 트랜잭션에게는 영향을 미치지 않도록 하는 동시성 제어 기법이다. 강력한 트랜잭션 메커니즘은 관계형 데이터베이스의 필수 부분인 이유는 정규화된 데이터는 일반적으로 여러 부분의 업데이트가 필요하기 때문이다. 한편 집계(Aggregate)에서는 하나의 비즈니스 엔터티를 하나의 문서, 행 또는 key-value 쌍으로 저장하고 자동으로 업데이트할 수 있다.
그림 4. Atomic Aggregates
물론 데이터 모델링 기법으로 원자 집계(Atomic Aggregates)는 완벽한 트랜잭션 솔루션은 아니지만, 만약 저장소가 어느 정도의 일관성 보장하도록 원자성, 락, test-and-set 명령 도구를 제공하는 경우 Atomic Aggregate를 적용할 수 있다. 키 밸류 스토어, 도큐먼트 데이터베이스, 빅테이블 계열의 데이터베이스가 이에 해당된다.
3.2.2 열거 가능한 키(Enumerable Keys)
아마 순서가 지정되지 않은 키 밸류 데이터 모델의 가장 큰 장점은 단순히 키를 해싱해 여러 서버에 파티션 할 수 있다는 것이다. 정렬은 복잡해지겠지만, 스토리지가 이 기능을 제공하지 않더라도 애플리케이션에서 정렬된 키를 이용할 수 있다. 예를 들어 전자메일 메시지 모델링을 생각해 보자.
？ -일부 NoSQL 저장소는 순차적인 ID를 생성할 수 있는 원자 카운터를 제공한다. 이 경우 userID_messageID 복합 키로 저장할 수 있다. 만일 최신 message ID를 알고 있으면, 그 이전 메시지를 아는 것도 가능하다. 또한 주어진 어떤 message ID에 대해서도 전후의 메시지를 알 수 있다.
？ -메시지는 예를 들어 일별 버킷 등의 버킷으로 그룹화할 수 있다. 이는 특정 날짜나 현재 날짜로 앞뒤로 시작하는 메일 박스의 메시지들을 검색할 수 있다.
키 밸류 스토어 데이터베이가 이에 해당한다.
3.2.3 차원 축소(Dimensionality Reduction)
차원 축소는 다차원 데이터를 키 밸류 모델로, 혹은 다른 비 다차원 모델로 매핑하는 기법이다. 전통적인 지리 정보 시스템은 인덱스를 Quadtree 또는 R-Tree의 변형된 형태를 사용한다. 이러한 데이터 구조는 in-place 업데이트를 해야 하는데 데이터 볼륨이 큰 경우에는 조작에 비용이 많이 든다. 대체 방법은 2D 구조를 탐색하고 일반 목록으로 평평하게 만들어서 엔트리 목록으로 구조화하는 방법이 있다. 이 기술의 잘 알려진 예는 Geohash이다. Geohash는 2D 공간을 채우기 위해 Z-like 검색을 사용하고 각각의 이동하는 방향에 따라 0 또는 1로 인코딩된다. 위도와 경도 비트는 이동할 때마다 교대로 이동한다. 이 인코딩 프로세스는 다음 그림과 같이 표시되고 검정과 빨강의 각 비트의 경도와 위도를 나타낸다.
그림 5. Geohash Index
Geohash 중요한 기능은 그림에서 볼 수 있듯이 bit-wise code proximity 기법을 사용해 영역의 거리를 측정하는 능력이 있다는 점이다. Geohash 인코딩은 평평한 데이터 모델을 사용해 공간 관계 정보를 가진 정렬된 key value처럼 지리 정보를 저장할 수 있다. 키 밸류 스토어, 도큐먼트 데이터베이스, 빅테이블 계열의 데이터베이스가 이에 해당된다.
3.2.4 인덱스 테이블(Index Table)
인덱스 테이블은 내부적으로 인덱싱을 지원하지 않는 저장소에 인덱싱 기술을 활용할 수 있도록 해주는 직관적인 기법이다. 그런 저장소의 가장 중요한 클래스는 빅테이블(BigTable)형 데이터베이스이다.
이 아이디어는 액세스 패턴에 따라 키의 특별한 테이블을 만들고 유지하는 것이다. 예를 들어 user ID로 접근하는 user account가 저장되는 마스터 테이블이 있다고 하자. 특정 도시에서 모든 사용자를 검색하는 쿼리는 city가 키인 추가 테이블을 사용해야 지원할 수 있게 된다.
그림 6. Index Table 예제
인덱스 테이블은 마스터 테이블의 개별 업데이트 및 배치 모드마다 업데이트할 수 있다. 어쨋든 이러한 방법은 추가적인 성능 저하 및 일관성 문제를 초래한다. 인덱스 테이블은 관계형 데이터베이스의 MView와 비슷하다고 생각될 수도 있다.
MView는 어떤 결과를 뽑아내는 쿼리가 빈번히 사용될 경우, Query 실행 시간의 수행속도 향상을 위해 여러 가지의 Aggregate View를 두어, 미리 비용이 많이 드는 조인이나 Aggregate Operation을 처리해야 하는 SQL을 위해, 데이터베이스의 한 테이블로 저장하며, 그 테이블을 조회하도록 하는 것이다. 예를 들어 대용량의 데이터를 SUM, MIN, MAX, AVG, COUNT(*)이런 명령어를 사용해 자주 조회하는 Query를 수행 속도를 향상을 위해 Query의 결과만큼의 새로운 테이블을 생성해 놓는 벙법이다. Materialized View와 일반 View의 차이점은 MView의 결과값은 물리적으로 존재하는 것이고, 일반 View의 결과값은 물리적으로 존재하지 않는다. 그리고 MView는 MView를 생성할 때의 Query로 물리적으로 이미 데이터가 생성돼 있기 때문에 조회 속도가 빠르다. 하지만 View는 단지 쿼리정보가 딕셔너리에 저장돼 있고 사용될 때 그 SQL이 다시 실행되기 때문에 MView보다 느리다. MView로 생성된 결과값이 일반 View로 조회하는 Data의 결과값보다 훨씬 적은 Row를 조회하게 된다.
빅테이블 계열 테이터베이스가 이에 해당된다.
3.2.5 복합 키 인덱스(Composite Key Index)
복합 키는 매우 일반적인 기법이지만, 정렬된 키를 사용할 때 매우 유용하다. 보조 정렬을 결합한 복합 키로 위의 차원 축소 기법과 근본적으로 유사한 다차원 인덱스를 만들 수 있다.
한 예로서 각 레코드가 사용자 통계인 레코드 집합을 생각해 보자. 만약 사용자 출신지 통계를 집계할 수 있다면, 그 저장소가 부분 키워드 검색에서 (BigTable-style 시스템처럼) 키 범위 선택을 지원하는 경우, (State : City : UserID) 형식의 키를 사용하여 특정 국가 또는 도시의 레코드를 반복 조회할 수 있다.
그림 7. 복합키 인텍스
빅테이블 계열 데이터베이스가 이에 해당된다.
3.2.6 복합 키를 활용한 집계(Aggregation with Composite Keys)
복합 키는 인덱싱뿐만 아니라 다른 유형의 그룹화에도 사용된다. 예로 인터넷 사용자와 그들이 어떤 사이트에서 방문했는지를 아는 방문 통계 정보(click stream)를 가진 엄청난 양의 로그 레코드의 배열이 있다. 목표는 각 사이트의 유니크 가입자 수다. 다음 SQL 쿼리와 비슷하다.
이 형태는 UserID를 프리픽스로 해 복합 키를 사용해 다음과 같이 모델화할 수 있다.
그림 8. 복합키를 사용한 유니크 사용자 카운팅
이 방법은 모든 레코드에 각 사용자 정보가 함께 저장되기 때문에 해시 테이블이나 다른 방법들을 사용해 사이트의 중복정보를 삭제한 뒤 메모리에 적재한다. 다른 대안은 한 사용자당 엔트리를 갖고 이벤트 도달 함께 site를 엔트리에 추가해 나가는 것이다. 그럼에도 불구하고 일반적으로 구현 단계 엔트리 삽입보다 엔트리 수정이 비효율적이다. Ordered Key-Value Stores, 빅테이블 계열 데이터베이스가 이에 해당된다.
3.2.7 역 검색- 직접 집계(Inverted Search - Direct Aggregation)
이 기술은 데이터 모델링보다는 데이터 프로세싱 패턴이다. 그럼에도 불구하고 데이터 모델 또한 이 패턴에 영향을 받는다. 이 기술의 주요 아이디어는 기준에 맞는 데이터를 찾는 데 인덱스를 사용하는 것이지만, 독자적인 표시나 전체 검색을 사용해 데이터를 집계한다. 한 예로서 인터넷 사용자와 그들이 어떤 사이트에서 방문했는지에 대한 엄청난 정보의 로그 레코드가 있다고 하자. 각 레코드는 user ID, 사용자가 속한 카테고리(Men, Women, Bloggers 등), 출신도시, 방문한 사이트의 정보를 갖는다. 주요 목표는 청중들 속에 발견되는 각 카테고리의 유니크 사용자 관점에서 몇 가지 기준(사이트, 도시 등)에 도달하는 청중들을 얻는 것이다(즉 기준을 만족하는 유저의 집합).
{Category -> user IDs]} 또는 {Site -> user IDs]} 같은 역 인덱스를 이용해 기준을 만족하는 사용자의 검색을 효과적으로 하는 것은 분명하다. 이러한 인덱스를 이용해 해당 사용자 ID를 교차 또는 통합(이것은 user IDs가 정렬된 목록 또는 비트 집합으로 저장되는 경우 효과적으로 실행 가능하다)할 수 있고 청중들 정보를 얻을 수도 있다. 그러나 청중을 뽑는 방식은 다음 집계 쿼리와 비슷하다.
이 카테고리 범위가 크다면 역 인덱스 사용은 비효율적으로 처리된다. 이를 해결하기 위해 {UserID -> Categories]} 형식의 직접 인덱스를 작성해야 최종 보고서를 작성할 수 있다. 이 스키마는 다음 그림과 같다.
그림 9. 직접/역인덱스를 사용해 유니크 사용자 카운팅
마지막으로 주의할 것은 청중의 사용자 ID를 위한 각 레코드의 무작위 검색은 비효율적일 수 있다. 누군가가 배치 쿼리 처리의 영향으로 이 문제를 놓고 고심하게 될지도 모른다. 이것은 여러 사용자 집합을(다른 기준) 사전에 계산될 수 있음을 의미한다. 그때 청중의 모든 배치 보고서는 직접 또는 역 인덱스의 풀 스캔 계산이 가능하다. 키 밸류 스토어, 도큐먼트 데이터베이스, 빅테이블 계열의 데이터베이스가 이에 해당된다.
3.3 계층 모델링 기법들
이 장은 계층형으로 분석하는 모델링 기법에 대해 논의한다.
3.3.1 트리 집계(Tree Aggregation)
트리나 비정규화의 힘을 빌린 모든 그래프는 단일 레코드와 도큐먼트로 모델링될 수 있다.
？ -이 기술은 트리가 한 번에 접근하는 경우에 효과적이다. 예를 들어, 블로그 댓글 트리를 가져와 게시물과 함께 표시하는 경우를 들 수 있다.
？ -엔트리의 검색과 임의 액세스는 문제가 될 수 있다.
？ -업데이트는 독립 노드들과 비교해 대부분의 NoSQL 구현물들 중에서 가장 비효율적이다.
그림 10. 트리 집계
키 밸류 스토어, 도큐먼트 데이터베이스가 이에 해당된다.
3.3.2 인접리스트(Adjacency Lists)
인접 리스트는 그래프 모델링의 직선적인 방법이다. 각 노드는 자손 또는 선조를 가리키는 배열을 포함하는 별도의 레코드로 모델링된다. 이것은 노드를 부모 또는 자식의 식별자로 검색할 수도 있고, 물론 쿼리마다 한 홉씩 그래프를 지나갈 수도 있다. 그러나 이 방법은 일반적으로 주어진 노드의 모든 하위 트리를 깊이 우선 탐색과 너비 우선 탐색으로 검색하는 데에는 비효율적이다.
키 밸류 스토어, 도큐먼트 데이터베이스가 이에 해당된다.
3.3.3 실체 경로(Materialized Paths)
실체 경로는 트리와 비슷한 구조로 재귀적으로 순회를 방지하는 데 도움이 되는 기술이다. 이 기술은 비정규화의 일종이라고 생각할 수 있다. 이 아이디어는 각 노드에 모든 부모 또는 자녀의 식별자를 속성화하는 것이므로, 탐색 없이 모든 조상 또는 자손을 구할 수 있다.
그림 11. 이숍 카테고리 계층화를 위한 Materialized Paths
이 기법은 계층 구조를 평면 문서로 변환할 수 있으므로, 전문 검색 엔진에 특히 유용하다. <그림 11>에서는 모든 제품 또는 Men's Shoes 커테고리의 하위 카테고리의는 단순한 카테고리 이름으로 된 숏쿼리로 검색될 수 있다. Materialized Paths는 ID 집합 또는 ID를 결합한 단일 문자열로 저장된다. 후자는 정규식을 사용하여 경로의 일부와 일치하는 노드를 검색할 수 있다. 이 옵션은 <그림 12>에서 나타난다.
그림 12. Query 정규식을 사용한 Materialized Paths
키 밸류 스토어, 도큐먼트 데이터베이스, 서치 엔진이 이에 해당된다.
3.3.4 중첩된 세트(Nested Sets)
중첩된 세트는 트리 모양의 구조를 모델링하기 위한 표준 기술이다. 관계형 데이터베이스에서 널리 이용되고 있지만, 키 밸류 스토어와 도큐먼트 데이터베이스에 완벽하게 적용할 수 있다. 이것은 아래 그림과 같이 트리의 리프를 하나의 배열에 저장하고 start와 end 인덱스를 사용해 리프 범위에 각각의 비 리프 노드를 매핑하는 아이디어다.
그림 13. 중첩 세트를 사용한 이커머스의 카탈로그 모델링
이 구조는 메모리 사용량이 적고 탐색 없이 주어진 노드의 모든 리프를 가져올 수 있으므로, 변하지 않는 데이터에 매우 효율적이다. 그렇지만 리프를 추가하는 것은 인덱스의 부하가 큰 업데이트를 일으키므로 삽입 및 업데이트는 높은 비용 구조를 갖고 있다. 키 밸류 스토어, 도큐먼트 데이터베이스가 이에 해당된다.
3.3.5 중첩된 도큐먼트의 평면화: 번호가 지정된 필드 이름(Nested Documents Flattening: Numbered Field Names)
검색 엔진은 일반적으로 평면 도큐먼트 작업, 즉 각 도큐먼트 필드와 값의 단순 목록이다. 이 데이터 모델링의 목적은 비즈니스 엔터티를 일반 도큐먼 트로 매핑하는 것이며, 이것은 엔터티가 복잡한 내부 구조를 갖고 있다면 도전에 직면할 것이다. 하나의 전형적인 도전은 도큐먼트를 계층 구조로 매핑하는, 예로 중첩된 도큐먼트가 들어있는 도큐먼트다. <그림 14>처럼 생각해 보자.
그림 14. 중첩 도큐먼트 문제
각 비즈니스 엔터티는 이력서와 같은 것이다. 이것은 사람의 이름과 그 사람이 가진 기술 목록, 기술 수준을 포함한다. 이러한 엔터티를 모델링하는 명백한 방법은 Skill과 Level 필드가 있는 일반 도큐먼트를 작성하는 것이다. 이 모델링은 개별 기술이나 기술 수준에서 인물을 검색할 수 있지만, 두 필드가 포함된 쿼리는 <그림 14>와 같이 false를 리턴해 버린다. 이 기술의 주요 아이디어는 각각의 기술과 지원 수준을 Skill_i, Level_i 필드를 전용의 쌍으로 인덱싱해 동시에 이러한 쌍을 병렬로 검색할 수 있게 하는 것이다(쿼리에서 OR되는 단어의 수는 한 사람의 스킬의 최대값까지).
. 
그림 15. Numbered Field Names를 사용한 중첩 도큐먼트 모델링
이 방법은 중첩된 구조의 개수가 기능적으로 복잡성이 빠르게 증가 할 수 있으므로 확장성이 떨어진다. 서치엔진이 이에 해당된다.
3.3.6 중첩된 도큐먼트의 평면화: 근처 쿼리(Nested Documents Flattening: Proximity Queries)
이 아이디어는 도큐먼트 내에서 단어 사이의 거리를 제한하는 proximity 쿼리를 사용한다. <그림 16>에서는 모든 스킬과 수준이 하나의 SkillAndLevel 필드에 인덱스되고, 그 쿼리는 "Excellent"며 "Poetry"과 접해 있는 단어들을 가리키고 있다.
그림 16. Proximity Queries를 사용한 중첩 다큐먼트 모델링
Solr의 성공 사례가 돼 있고, 적용 범위는 서치 엔진이다.
3.3.7 배치 그래프 프로세싱
Neo4j와 같은 그래프 데이터베이스는 예외적으로 주어진 노드의 이웃 탐색 또는 두 개 혹은 약간의 노드 간의 관계 탐색은 잘 된다. 그러나 거대한 그래프의 글로벌 프로세스는 일반적인 용도의 그래프 데이터베이스여서 스케일하지 않기 때문에 효율이 별로 좋지 않다. 그러나 분산 그래프 프로세싱은 MapReduce와 Message Passing 패턴들을 실행할 수 있다.
맵리듀스의 메시지 패싱 패턴에서 네트워크는 노드 집합으로 저장되고, 각 노드는 인접 노드의 ID 목록을 포함한다. 개념적으로 MapReduce 작업은 박복적으로 수행되고, 반복된 각 노드는, 옆에 엔터티에 메시지를 보낸다. 각각의 이웃 노드는 받은 메시지에 기초해 상태를 업데이트한다. 반복적인 작업은 두 개의 연속적인 반복 잡 간에 무시할 수 있는 상태의 변화와 정해진 반복 잡의 최대값 등의 여러 조건에 의해 종료된다. 결과적으로 모든 메시지는 수신자 노드로 그룹화되어 Reducer는 상태를 다시 계산해 새로운 상태에서 노드를 수정할 수 있다.
이 방법은 키 밸류 스토어, 도큐먼트 데이터베이스, 빅테이블 계열의 데이터베이스를 거대한 그래프 처리에 적합하게 한다. 키 밸류 스토어, 도큐먼트 데이터베이스, 빅테이블 계열의 데이터베이스들이 이에 해당된다.
출처
http://www.dbguide.net/knowledge.db?cmd=view&boardUid=167344&boardConfigUid=20&boardStep=&categoryUid=209
