# 2장 데이터 모델과 쿼리 언어

데이터 중심 애플리케이션 구축(Designing Data-Intensive Application, 2017) 책을 읽고 정리하였습니다.

아래 블로그에 정리가 잘 되어있어서 필요한 부분만 추가로 작성하였습니다.

02. 데이터 모델(Data Models)과 질의 언어(Query Languages) - 1Smart Tiger's blog

02. 데이터 모델(Data Models)과 질의 언어(Query Languages) - 2Smart Tiger's blog

1. 위 블로그 요약

• 3가지 데이터모델 설명 - 문서, 관계형, 그래프

• one-to-many(일대다) - 트리구조 데이

  • 문서 데이터 모델형인 JSON으로 표현하는 것이 매우 적합

  • 관계형 모델에서 사용하는 다중 테이블 스키마보다 더 나은 locality를 가집니다.

• many-to-one(다대일)

  • 관계형 모델이 적합

  • 문서 데이터베이스는 조인에 대한 지원이 약해서 다대일 관계를 처리하는데 어려움이 있다.

• many-to-many(다대다)

  • 관계형 모델도 간단한 다대다 관계를 사용할 수 있지만 연결관계가 복잡해진니다. 이때는, 그래프형 데이터 모델을 고려해봐야 합.니다 다

• 하나의 모델이 다른 모델을 흉내는 낼 수 있지만 대체할 수 없다.

2. 그래프 모델만 다시정리

• 그래프 구성

  • vertices (= 노드)

  • edges (= 관계 )

• 데이터를 구조화하고 쿼리하는 몇 가지 다른 방법

  • 프로퍼티 그래프 (property graph model) - Neo4j, Titan, and InfiniteGraph

  • 트리플-저장 모델 (triple-store model) - Datomic, AllegroGraph

[그림 1] 그래프 구조 예시

• 이런 구조는 관계형으로 구현하기 힘듭니다.

2.1 프로퍼티 그래프 (property graph model)

2.1.1 VERTEX와 EDGE의 구성요소들

• VERTEX(노드)

  • 고유한 식별자

  • outgoing edge 집합

  • incoming edge 집합

  • 속성 컬렉션(키-값 쌍)

• EDGE(관계)

  • 고유한 식별자

  • 관계가 시작하는 정노드(tail vertex)

  • 관계가 끝나는 노드(head vertex)

  • 두 노드 간 관계 유형을 설명하는 레이블

  • 속성 컬렉션(키-값 쌍)

// 관계형 스키마를 사용하는 속성 그래프(property graph model)의 표
CREATE TABLE vertices (
 vertex_id integer PRIMARY KEY,
 properties json
);

CREATE TABLE edges (
 edge_id integer PRIMARY KEY,
 tail_vertex integer REFERENCES vertices (vertex_id),
 head_vertex integer REFERENCES vertices (vertex_id),
 label text,
 properties json
);

CREATE INDEX edges_tails ON edges (tail_vertex);
CREATE INDEX edges_heads ON edges (head_vertex);

• 모든 정점은 다른 VERTEX(노드)과 연결되는 EDGE(관계)를 가질 수 있다. 연관관을 가능하게 또는 가능하지 않게 제한하는 스키마는 없다.

• 어떤 VERTEX이 주어지면, incoming EDGE와 outgoing EDGE를 모두 효율적으로 찾아 그래프를 가로 지르는 (즉, VERTEX 체인을 통과하는 경로를 따라) 앞뒤로 이동할 수 있다. 따라서 예 2-2에 tail_vertex 및 head_vertex 컬럼 모두에 대한 색인이 있다.

• 서로 다른 종류의 관계에 서로 다른 레이블을 사용하면 깨끗한 데이터 모델을 유지하면서 여러 종류의 정보를 하나의 그래프에 저장할 수 있다.

2.1.2 사이퍼(Cypher) 질의 언어

• 프로퍼티 그래프들을 위한 선언형 질의 언어 (Neo4j를 위해 개발되었다.)

• 그림 1의 아내 Lucy를 사이퍼를 통해 생성 해보자.

// 사이퍼 Lucy 생성 코드 
CREATE
 (NAmerica:Location {name:'North America', type:'continent'}),
 (USA:Location {name:'United States', type:'country' }),
 (Idaho:Location {name:'Idaho', type:'state' }),
 (Lucy:Person {name:'Lucy' }),
 (Idaho) -[:WITHIN]-> (USA) -[:WITHIN]-> (NAmerica),
 (Lucy) -[:BORN_IN]-> (Idaho)
 // Lucy -> Idaho -> US -> NAmerica

// 미국에서 유럽으로 이민온 사람들 조회 
MATCH
 (person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
 (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name

관계형 데이터베이스에서 구현한다면...

// 미국에서 유럽으로 이민온 사람들 조회를 관계형 SQL로 짠다면...

WITH RECURSIVE
    in_usa(vertex_id) AS (
        SELECT vertex_id FROM vertices WHERE properties ->> 'name' = 'United States'
        UNION
        SELECT edges.tail_vertex FROM edges
        JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
        WHERE edges.label = 'within'
    ),
    in_europe(vertex_id) AS (
        SELECT vertex_id FROM vertices WHERE properties ->> 'name' = 'Europe'
        UNION
        SELECT edges.tail_vertex FROM edges
        JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
        WHERE edges.label = 'within'
    ),
    born_in_usa(vertex_id) AS (
        SELECT edges.tail_vertex FROM edges
        JOIN in_usa ON edges.head_vertex = in_usa.vertex_id
        WHERE edges.label = 'born_in'
    ),

    lives_in_europe(vertex_id) AS (
        SELECT edges.tail_vertex FROM edges
        JOIN in_europe ON edges.head_vertex = in_europe.vertex_id
        WHERE edges.label = 'lives_in'
    )

SELECT vertices.properties  ->> 'name'
FROM vertices
JOIN born_in_usa ON vertices.vertex_id = born_in_usa.vertex_id
JOIN lives_in_europe ON vertices.vertex_id = lives_in_europe.vertex_id;

적절 모델을 사경우에 따라 사용하자.

2.2 트리플-저장 모델 (triple-store model)

• 비록 속성 모델과 대부분 같지만, 많은 툴과 언어들을 제공하기 때문에 애플리케이션 만드는데 유용하기 때문에 설명한다.

• 모든 정보는 주어, 동사, 목적어(subject, predicate, object) 형태로 저장된다.

• subject는 속성그래프의 노드와 동일하다.

• predicate와 object

  • lucy, age, 33 동사가 없이 숫자, 문자인 경우

    • predicate = 키 object = 값

  • lucy, marriedTo, alain 경우

    • lucy = 꼬리 노드, marriedTo = 동, alain = 머리 노드

// Turtle triples로 표현된 트리플-저장 모델 
@prefix : <urn:example:>.
_:lucy a :Person.
_:lucy :name "Lucy".
_:lucy :bornIn _:idaho.
_:idaho a :Location.
_:idaho :name "Idaho".
_:idaho :type "state".
_:idaho :within _:usa.
_:usa a :Location.
_:usa :name "United States".
_:usa :type "country".
_:usa :within _:namerica.
_:namerica a :Location.
_:namerica :name "North America".
_:namerica :type "continent".


// 위보다 더 간결한 방법 - 같은 결과 
@prefix : <urn:example:>.
_:lucy a :Person; :name "Lucy"; :bornIn _:idaho.
_:idaho a :Location; :name "Idaho"; :type "state"; :within _:usa.
_:usa a :Location; :name "United States"; :type "country"; :within _:namerica.
_:namerica a :Location; :name "North America"; :type "continent".

// 위는 사람이 읽을 수 있게 만들어 졌고 
// 아래는 RDF(사이트끼리 공유가능한 포맷) 

<rdf:RDF xmlns="urn:example:"
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 
 <Location rdf:nodeID="idaho">
  <name>Idaho</name>
  <type>state</type>
  <within>
   <Location rdf:nodeID="usa">
    <name>United States</name>
    <type>country</type>
    <within>
     <Location rdf:nodeID="namerica">
      <name>North America</name>
      <type>continent</type>
     </Location>
    </within>
   </Location>
  </within>
 </Location>
 
 <Person rdf:nodeID="lucy">
  <name>Lucy</name>
  <bornIn rdf:nodeID="idaho"/>
 </Person>
 
</rdf:RDF>

• 트리플-저장은 시멘틱웹에 완전히 독립적이다?

• RDF - 동일한 포맷으로 데이타들을 퍼블리싱하기 위해 개발되었다. 사이트끼리 공유가능하다.

• Apache Jena를 사용하면 쉽게 RDF 포맷을 변경할 수 있다.

정리

• NoSQL이 나오게된 요소

  • 매우 큰 데이터 세트 또는 높은 쓰기 처리량을 포함하여 쉽게 ​​확장

  • 상용 데이터베이스 제품보다 무료 및 오픈 소스 소프트웨어에 대한 선호

  • 관계형 모델에서 잘 지원되지 않는 특수한 쿼리 작업

  • 역동적이고 표현적인 데이터 모델에 대한 요구

• 객체-관계형 불일치

  • 객체지향과 관계형DB 임피던스 불일치 -> ORM 등장

  • JSON이 해결한 대안이라 생각했지만...

  • JSON은 멀티-테이블 스키마보다 지역성이 강하다.

• IBM의 IMS(hierarchical model) -> 다대다 관계, 조인 표현 불가

  • 비정규화하여 데이터 중복을 허용해야 하는가 고민(60,70년대)

  • 계층형 모델 제한을 해결하기 위해 관계형, 네트워크형 등장하였으나 네트워크형은 into obscurity.

• 네트워크형 = CODASYL 모델

  • 외래키를 사용하지않고 프로그래밍 같은 포인터를 사용(저장은 디스크에 했음)

  • traversal하는 연결리스트랑 비슷

  • tape drives와 같은 저 사양에서 효율적으로 사용된다.

Summary

• 역사적으로, 데이터는 하나의 큰나무(계층적 모델)로 표현되었었다.

  • 하지만 다대다 관계들을 표현하기에는 충분하지 못했고 대안으로 관계형모델이 개발되었다.

• 요즘에는, 이 관계형 데이터베이스가 항상 회사에 서비스 특성에 따라 최적의 데이터모델이 되지 못하였고 새로운 비관계형인 NoSQL(문서지향, 그래프 DB)이 필요하게 되었다.

• 오늘날 데이터모델로 문서, 관계형, 그래프( document, relational, and graph )가 가장 많이 사용된다. 이 3가지가 각각의 도메인에서 역할을 톡톡히 해주고 있다.

• one-size-fits-all 해결법이란 존재하지 않기에 다양한 모델이 나왔다.

• document와 graph의 공통점은 저장되는 데이터를 위한 스키마를 강요하지 않는다는 것이다. 이로써, 변화하는 요구사항을 잘 반영할 수 있다.

• 각 데이터모델은 각자의 질의언어나 프레임워크가 있다.

참고 블로그