2. 데이터 모델과 질의 언어

내 언어의 한계는 내 세계의 한계를 의미합니다.

데이터 모델은 소프트웨어가 어떻게 작성됐는지 뿐만 아니라 해결하려는 문제에 대해 고민해봐야합니다.
각 계층의 핵심적인 문제는 다음 하위 계층 관점에서 데이터 모델을 표현하는 방법입니다.
각 계층은 명확한 데이터 모델을 제공해 하위 계층의 복잡성을 숨깁니다.

관계형 모델과 문서 모델#

가장 유명한 데이터 모델은 RDBMS인 관계형 모델입니다.
목적은 비즈니스 데이터 처리이며 트랜잭션 처리와 일괄 처리를 수행합니다.
현대로 넘어오면서 관계형 데이터베이스가 비지니스 데이터를 넘어서 폭넓은 분야에서도 사용되고 있습니다.

NoSQL의 탄생#

CAP이론

NoSQL의 채택 이유는 다음과 같습니다.

대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성이 필요합니다.
상용 데이터베이스 보다 오픈소스 소프트웨어에 대한 선호도 확산
관계형 모델에서 지원하지 않는 특수 질의 동작
관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

현재는 관계형 데이터베이스와 비관계형 데이터스토어를 함께 사용하며, 이러한 개념을 다중 저장소 지속성(polyglot persistence) 라고 합니다.

객체 관계형 불일치#

대부분의 애플리케이션은 객체지향 프로그래밍 언어로 개발하며 이는 관계형 데이터 모델과의 불필요한 전환 계층이 필요합니다. 이러한 분리를 임피던스 불일치(impedance mismatch)라고 부릅니다.

링크드인 프로필 예시#

[사진] 빌 게이츠 / 그레이터 시애틀 구역 | 자선활동

요약
- 빌 & 멜린다 게이츠 재단 공당 의장
- 마이크로소프트 기업 회장
- ...

경력
- 빌 & 멜린다 게이츠 재단 공동 의장 (2000 ~)
- 마이크로소프트 공동 창업자, 회장 (1975 ~)

학력
- 하버드 대학교(1973-1975)
- 레이크사이드 스쿨, 시애틀

연락처
- 블로그: ...
- 트위터: ...

관계형 스키마로 표현한 링크드인 프로필#

관계형 스키마 예시

JSON 문서로 표현한 링크드인 프로필#

데이터

{
  "user_id": 251,
  "first_name": "Bill",
  "last_name": "Gates",
  "summary": "Co-chair of the Bill & ....",
  "region_id": "us:91",
  "industry_id": 131,
  "photo_url": "/p/7/000/253/08b/308dd6e.jpg",
  "positions": [
    {
      "job_title": "Co-chair",
      "organization": "Bill & Melinda Gates Foundation"
    },
    { "job_title": "Co-founder", "organization": "Microsoft" }
  ],
  "educations": [
    { "school_name": "Harvard University", "start": 1973, "end": 1975 },
    { "school_name": "Lakeside School, Seattle", "start": null, "end": null }
  ],
  "contact_info": {
    "blog": "http://thegatesnotes.com",
    "twitter": "http://twitter.com/BillGates"
  }
}

다중 테이블 스키마보다는 더 나은 지역성(locality) 를 가집니다.

지역성이란?

데이터 접근이 시각적, 공간적으로 가깝게 일어나는 것을 말합니다.

다대일과 다대다 관계#

위의 예시에서 구역이나 활동등은 ID로 표현하였는데, 이런 식으로 표준 목록으로 관리하게 되면 아래의 장점을 가집니다.

프로필 간 일관된 스타일과 철자
모호함 회피
갱신의 편의성 (이름 변경 등이 쉽습니다.)
현지화 지원 (사이트를 다른 언어로 번역시 유리합니다.)
더 나은 검색 서비스를 만들기 쉽습니다.

중복된 데이터를 정규화하려면 다대일(many-to-one) 관계가 필요하지만 이는 문서 모델에 적합하지 않습니다.

다대다 관계.

문서 데이터베이스는 역사를 반복하고 있는가#

관계형 데이터베이스는 다대다 관계와 조인을 주로 사용을 합니다.
최초 1970년도의 비지니스 데이터 처리를 위해 가장 많이 사용된 데이터베이스는 IMS라 불리는 계층 모델이였습니다.
- 현재의 JSON과 비슷합니다.
- 일대다 관계에서는 잘 동작합니다. 다만 다대다 관계 표현의 어려움과 조인의 미지원이라는 단점이 있습니다.
이러한 계층 모델의 한계를 해결하기 위해 관계형 모델(SQL) 과 네트워크 모델이 등장했습니다.

네트워크 모델#

코다실 모델

코다실 모델이라고도 불립니다.
계층 모델을 일반화하며 계층 모델의 트리 구조에서는 모든 레코드는 정확하게 하나의 부모가 있습니다.
레코드에 접근하는 유일한 방법은 최상위 레코드에서부터 연속된 연결 경로를 따르는 방법이며 이를 접근 경로라 부릅니다.
수동 접근 경로 선택은 데이터베이스 질의와 갱신을 위한 코드가 복잡하고 유연하지 못하고, 데이터 모델을 바꾸기도 힘들어집니다.

관계형 모델#

관계형 모델은 단순히 튜플(로우)의 컬렉션이 전부입니다.
데이터에 질의하고 싶은 경우 새로운 색인을 선언하기만 하면 질의는 자동으로 가장 적합한 색인을 사용합니다.
관계형 모델은 애플리케이션에 새로운 기능을 추가하는 작업이 훨씬 쉽습니다.

문서 데이터베이스와의 비교#

다대일과 다대다 관계를 표현할 때 관계형 데이터베이스와 문서 데이터베이스는 모두 고유한 식별자를 참조합니다.
관계형 모델에서는 외래 키라 부르고 문서 모델에서는 문서 참조(document reference)라고 부릅니다.

관계형 데이터베이스와 오늘날의 문서 데이터베이스#

문서 데이터 모델의 선호 이유는 다음과 같습니다.

스키마 유연성, 지역성에 기인한 더 나은 성능
일부의 경우는 애플리케이션에서 사용하는 데이터 구조와 가깝습니다.

관계형 모델은 다음과 같습니다.

조인, 다대일, 다대다 관계를 더 잘 지원합니다.

어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까?#

문서 모델을 사용하면 좋은 경우

애플리케이션에서 데이터가 문서와 비슷한 구조인 경우 (일대다 관계 트리)
문서와 비슷한 구조를 여러 테이블로 나누어 찢는(shredding) 관계형 기법은 다루기 힘든 스키마와 불필요하게 복잡한 애플리케이션 코드를 발생시킵니다.

문서 모델이 제한적인 경우

문서가 너무 깊게 중첩되는 경우 (문서 내 중첩 항목을 바로 참조 불가능)
문서 데이터베이스는 조인 지원이 미흡합니다.
애플리케이션에서 다대다 관계를 사용하는 경우

문서 모델에서의 스키마 유연성#

문서 데이터베이스와 관계형 데이터베이스의 JSON은 문서의 데이터에 어떤 스키마를 강요하지 않습니다.
스키마가 없다는 것은 임의의 키와 값을 문서에 추가할 수 있고 읽을 때 클라이언트는 문서에 포함된 필드의 존재 여부를 보장하지 않습니다.
문서 데이터베이스는 쓰기 스키마(schema-on-write, 관계형 데이베이스의 전통적인 접근 방식으로 스키마는 명시적이고 데이터 베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장합니다.)가 아닌 읽기 스키마(schema-on-read, 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석됩니다.)입니다.
읽기 스키마는 프로그래밍 언어에서 동적(런타임) 타입 확인과 유사하고 쓰기 스키마는 정적(컴파일 타입) 타입 확인과 비슷합니다.
애플리케이션이 데이터 타입을 변경하고자 할 때 접근 방식 간 차이가 다르며, 문서 데이터베이스에서는 새로운 필드를 가진 새로운 문서를 작성하면 됩니다.

if (user && user.name && !user.first_name) {
  user.first_name = user.name.split(' ')[0]
}

정적 타입의 데이터베이스 스키마에서는 보통 다음 행과 같이 마이그레이션(migration) 을 수행합니다.

ALTER TABLE users ADD COLUMN first_name text;
UPDATE users SET first_name = substring_index(name, ' ', 1); -- MySQL

이러한 정적 타입의 스키마 변경은 느리고 중단시간을 요구합니다.
읽기 스키마 접근 방식은 컬렉션 안의 항목이 어떤 이유로 모두 동일한 구조가 아닐때 유리합니다.
- 다른 여러 유형의 오브젝트가 있고 각 유형의 오브젝트별로 자체 테이블에 넣는 방법은 실용적이지 않습니다.
- 사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정됩니다.
모든 레코드가 동일한 구조라 예상 가능하다면 스키마가 문서화 구조를 강제하기 위한 유용한 메커니즘입니다.

스키마란?

질의를 위한 데이터 지역성#

애플리케이션이 자주 전체 문서에 접근할 때, 저장소 지역성(storage locality) 을 활용하면 성능 이점이 있습니다.
데이터가 다중 테이블로 나눠졌으면 전체를 검색하기 위해 다중 색인 검색이 필요합니다. 이 경우 더 많은 디스크 탐색이 필요하고 더 많은 시간이 소요됩니다.
지역성의 이점은 한 번에 해당 문서의 많은 부분을 필요로 하는 경우에만 적용됩니다.
데이터베이스는 대개 문서의 작은 부분에만 접근해도 전체 문서를 적재해야하므로 큰 문서에서는 낭비가 발생할 수 있습니다.
일반적으로 문서를 아주 작게 유지하면서 문서의 크기가 증가하는 쓰기를 피하는 것이 중요합니다. 이는 또 하나의 제한이 됩니다.
오라클은 다중 테이블 색인 클러스터 테이블(multi-table index cluster table) 기능을 사용해 지역성 특성을 제공합니다.
빅테이블 데이터 모델의 컬럼 패밀리(column-family) 개념(카산드라나 HBase에서 사용)이 지역성 관리와 유사한 목적입니다.

문서 데이터베이스와 관계형 데이터베이스의 통합#

대부분의 관계형 데이터베이스 시스템은 XML을 지원합니다.
문서 데이터베이스를 사용할 때와 매우 비슷한 데이터 모델을 애플리케이션이 사용할 수 있습니다.
관계형 데이터베이스와 문서 데이터베이스는 시간이 지남에 따라 더 비슷해지고 서로 보완해주고 있습니다.

데이터를 위한 질의 언어#

SQL은 선언형 질의 언어인 반면, IMS와 코다실은 명령형 코드를 통해 데이터베이스에 질의합니다.
선언형 질의 언어는 명령형보다 간결하고 쉽게 작업가능합니다.
선언형 질의 언어는 데이터베이스 엔진의 상세 구현이 숨겨져 있어서 질의를 변경하지 않고 데이터베이스 시스템의 성능을 올릴 수 있습니다.
SQL 예제는 특정 순서를 보장하지 않으며 순서가 바뀌어도 상관없습니다.
마지막으로 선언형 언어는 종종 병렬 실행에 장점을 가집니다.

웹에서의 선언형 질의#

선언형 질의 언어의 장점은 데이터베이스엣만 국한되지 않습니다.

<ul>
  <li class="selected">
    <p>Sharks</p>
    <ul>
      <li>Great White Shark</li>
      <li>Tiger Shark</li>
      <li>Hammerhead Shark</li>
    </ul>
  </li>
  <li>
    <p>Whales</p>
    <ul>
      <li>Blue Whale</li>
      <li>Humpback Whale</li>
      <li>Fin Whale</li>
    </ul>
  </li>
</ul>

li.selected > p {
  background-color: blue;
}

이러한 css 코드를 선언형, XSL을 사용하면 다음과 같이 표현할 수 있습니다.

<xsl:template match="li[@class='selected']/p">
  <fo:block background-color="blue">
    <xsl:apply-templates/>
  </fo:block>
</xsl:template>

명령형 접근 방식은 다음과 같이 해야합니다.

var liElements = document.getElementsByTagName('li')
for (var i = 0; i < liElements.length; i++) {
  if (liElements[i].className === 'selected') {
    var children = liElements[i].childNodes
    for (var j = 0; j < children.length; j++) {
      var child = children[j]
      if ((child.nodeType === Node.ELEMENT_NODE) & (child.tagName === 'P')) {
        child.setAttribute('style', 'background-color: blue')
      }
    }
  }
}

이러한 명령형 코드는 이해하기 어렵고 아래의 문제가 있습니다.

selected 클래스가 삭제된 경우, 코드가 재실행되더라도 파란색은 삭제되지 않습니다.
API의 장점을 취하고 싶으면 코드를 재작성해야합니다.

맵리듀스 질의#

맵리듀스(MapReduce) 는 많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델입니다.
몽고DB나 카우치DB를 포함한 일부 NoSQL 데이터 저장소는 제한된 형태의 맵리듀스를 지원합니다.
맵리듀스는 질의 로직을 처리 프레임워크가 반복적으로 호출하는 조각 코드로 표현하며 map 함수와 reduce 함수를 기반으로 합니다.

맵리듀스란? 여러 노드에 테스크를 분배하는 방식이며, 맵과 리듀스로 나눠집니다.

맵은 흩어져 있는 데이터를 연관성이 있는 데이터들로 분리하는 것, 리듀스는 Map에서 분류된 데이터에서 중복 데이터를 제거하고 원하는 데이터를 추출합니다.

맵리듀스

클러스터 환경에서 분산 실행을 위한 프로그래밍 모델인 맵리듀스는 상당히 저수준 프로그래밍 모델입니다.
맵리듀스를 구현할 때는 연계된 함수 두 개를 신중하게 작성해야합니다. (한개보다 어려움)

그래프형 데이터 모델#

데이터에서 다대다 관계가 매우 일반적인 경우에는 그래프로 데이터를 모델링하는 것이 더 자연스럽습니다.
그래프는 정점(vertex, 노드나 엔티티) 와 간선(edge, 관계나 호) 라고 합니다.
다음의 예시가 있습니다.
- 소셜 그래프, 웹 그래프, 도로나 철도 네트워크
그래프에서 데이터를 구조화하고 질의하는 몇가지 방법이 있습니다.
- 속성 그래프 모델 : Neo4j, Titan, InfiniteGraph
- 트리플 저장소 모델 : Datomic, Allegrograph
- 그래프용 선언형 질의 언어 : Cypher, SPARQL, Datalog
- 명령형 그래프 질의 언어 : Gremlin
- 그래프 처리 프레임워크 : Pregel

속성 그래프#

속성 그래프 모델에서 각 정점(vertex) 은 다음과 같은 요소로 구성됩니다.

고유한 식별자
유출(outgoing) 간선 집합
유입(ingoing) 간선 집합
속성 컬렉션(키-값 쌍)

각 간선(edge) 은 다음의 구성 요소로 구성됩니다.

고유한 식별자
간선이 시작하는 정점, 꼬리 정점
간선이 끝나는 정점, 머리 정점
두 정점간 관계 유형을 설명하는 레이블
속성 컬렉션(키-값 쌍)

속성 그래프는 다음의 장점을 가집니다.

정점은 다른 정점과 간선으로 연결됩니다.
정점이 주어지면 정점의 유입과 유출 간선을 효율적으로 찾을 수 있고 그래프를 순회할 수 있습니다. 즉, 일련의 정점을 따라 앞뒤 방향으로 순회합니다.
다른 유형의 관계에 서로 다른 레이블을 사용하면 단일 그래프에 다른 유형의 정보를 저장하면서도 데이터 모델을 깔끔하게 유지할 수 있습니다.

사이퍼 질의 언어#

사이퍼(Cypher)는 속성 그래프를 위한 선언형 질의 언어로 Neo4j 그래프 데이터베이스용으로 만들어 졌습니다.
예시) 미국에서 유럽으로 이민 온 사람을 찾는 사이퍼 질의

MATCH
  (person) -[:BORN_IN] -> () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
  (person) -[:LIVES_IN] -> () -[:WITHIN*0..]-> (es:Location {name:'Europe'})
RETURN person.name

질의 최적화기가 가장 효율적으로 예측한 전략을 자동으로 선택하며 사용자는 나머지 애플리케이션만 작성합니다.

SQL의 그래프 질의#

사이퍼에서는 :WITHIN*0..은 "0회 이상 WITHIN 간선을 따라가라"는 의미를 가집니다.
SQL의 가변 순회 경로에 대한 질의 개념은 재귀 공통 테이블 식(recursive common table expression) 을 사용해 표현합니다.

-- 코드 생략

트리플 저장소와 스파클#

트리플 저장소 메들은 속성 그래프 모델과 거의 비슷합니다.
트리플 저장소에서는 모든 정보를 주어(subject), 서술어(predicate), 목적어(object) 와 같은 세 부분 구문 형식으로 저장됩니다.
트리플의 주어는 그래프의 정점과 동등합니다.

@prefix : <urn:example:>
_:lucy  a   :Person.

시맨틱 웹#

컴퓨터가 읽을 수 있는 기계 판독 가능한 데이터로 정보를 게시하는 개념
자원 기술 프레임 워크(Resource Description Framework, RDF)는 서로 다른 웹 사이트가 일관된 형식으로 데이터를 게시하기 위한 방법을 제안함
RDF는 서로 다른 데이터가 데이터 웹(web of data)에 자동으로 결합할 수 있게 합니다.

RDF 데이터 모델#

RDF는 인터넷 전체의 데이터 교환을 위해 설계했습니다.
터틀 언어는 RDF 데이터를 사람이 읽을 수 있는 형식으로 표현합니다.

스파클 질의 언어#

스파클(SPARQL) 은 RDF 데이터 모델을 사용한 트리플 저장소 질의 언어입니다.

-- 위의 내용과 동일한 기능
SELECT ?personName WHERE {
  ?person :name ?personName.
  ?person :bornIn / :within* / :name "United States".
  ?person :livesIn / :within* / :name "Europe"
}

그래프 데이터베이스와 네트워크 모델의 비교

코다실 데이터베이스에는 다른 레코드 타입과 중첩 가능한 레코드 타입을 지정하는 스키마가 있으나 그래프 데이터베이스에는 이러한 제한이 없습니다.
코다실에서 특정 레코드에 도달하는 유일한 방법은 접근 경로 중 하나를 탐색하는 방법이나 그래프 데이터베이스는 고유 ID를 가지고 임의 정점을 직업 참조하거나 색인을 통해 특정 값을 가진 정점을 빠르게 찾습니다.
코다실에서는 정렬하여 저장하지만 그래프 데이터베이스에서 정점과 간선은 정렬하지 않습니다.
코다실에서 모든 질의는 명령형이고 작성이 어렵고 스키마 변경이 어렵습니다.

초석#

데이터로그(Datalog) 는 질의 언어의 기반이 되는 초석을 제공합니다.
데이터로그의 데이터 모델은 트리플 저장소 모델과 유사하나 조금 더 일반화됩니다. (서술어(주어, 목적어)로 작성합니다.)

name(namerica, 'North America').

사이퍼와 스파클은 SELECT로 바로 질의하는 반면 데이터로그는 단계를 나눠 한 번에 조금씩 질의로 나아갑니다.

정리#

데이터 모델은 광범위한 주제입니다.

게층 모델 (버려짐) -> 관게형 모델 -> NoSQL

다대다 문제를 해결하기 위해 관계형 모델이 고안되었습니다. 이에 적합하지 않는 애플리케이션을 위해 NoSQL이 등장했습니다.
NoSQL은 다음의 두 가지 주요 갈래가 있습니다.
- (1) 문서 데이터베이스는 데이터가 문서 자체에 포함되어 있으면서 하나의 문서와 다른 문서 간 관계가 거의 없는 사용 사례를 대상으로 합니다.
- (2) 그래프 데이터베이스는 문서 데이터베이스와는 정반대로 모든 것이 잠재적으로 관련 있다는 사용 사례를 대상으로 합니다.
문서, 관계형, 그래프 모델 모두 널리 사용되며 각자의 영역에서 훌륭하며 흉내를 내는 경우 대부분 엉망이 됩니다.
문서 및 그래프 데이터베이스는 스키마를 강제하지 않아 요구사항에 맞춰 애플리케이션을 쉽게 변경할 수 있습니다.
각 데이터 모델은 고유한 질의 언어나 프레임워크를 제공합니다.