[Desinging Data-Intensive Applications] 02장. 데이터 모델과 질의 언어

애플리케이션에 적합한 데이터 모델을 선택하는 방법 ..

과 그 모델에 따른 질의 언어에 대해 알아보자 ..

관계형 모델과 문서 모델

관계형 모델과 문서 모델은 어떻게 다를까?

관계형 모델은 보통 우리가 아닌 RDB로, 관계 로 구성되고 각 관계는 튜플 의 모음임

BUT RDB에는 다음과 같은 drawback 이 있음

• 동적이고 변하는 스키마에 대응하기 어려움
• 관계형 모델에서 지원하지 않는 특수 질의 동작
• 대규모 데이터셋 or 높은 쓰기량 달성을 해야 할 경우

또한 RDB 에서, 데이터를 테이블에 저장하려면 app 코드 ↔ DB 모델 객체 간 전환 계층이 필요 (임피던스 불일치)

linkedin 예제를 보면, 같은 table 데이터를 JSON 형식으로 저장할 수 있음

 

SON 형식으로 데이터를 저장 (= 문서 형식으로 데이터를 저장) 하면 ,

지역성 을 가짐. 질의하려는 데이터가 한 곳에 있어 질의 하나로 충분함. RDB의 경우 다중 join 필요

문서형 데이터베이스의 경우, 다대일 관계를 표현하기 적합하지 않음

 

위의 Linkedin 사례처럼 중복된 데이터를 정규화해 id로 표현할 수 있지만, 문서 데이터베이스에는 조인에 대한 지원이 약함. app 코드에서 조인을 수행해야 함.

문서형 데이터베이스에서 다대다 관계를 표현하기 위해서는 1) 데이터를 중복하거나 (비정규화 하거나) 2) app에서 조인을 흉내내어 수동으로 해결해야 함

 

문서형 모델을 더 선호되는 케이스는

• 스키마 유연성
• 지역성에 기인한 더 나은 성능 (1번의 질의로 app에서 사용하는 데이터 구조와 유사한 데이터를 얻을 수 있음)
• 어떤 시점에 발생한 이벤트를 기록하는 경우 (다대다 관계가 필요하지 않음)

BUT 문서형 모델을 선택하려면, 다대다 관계에서는 이점이 없을 수 있다

비정규화로 중복 줄이기를 할 수 있지만, app 코드에서 데이터 일관성을 위해 추가 작업을 해야 하고 DB단에서 수행되는 조인보다 성능이 안나옴

 

 

RDB도 무조건 답이 아닌 것이 문서와 비슷한 구조를 여러 테이블로 나누어 shredding 하는 기법은 다루기 힘든 스키마와 불필요한 app 코드를 발생시킬 수 있다 ..

그때그때 적절한 데이터 모델을 선택할 것

 

 

RDB는 쓰기 스키마 (스키마는 명시적이고 쓰여진 모든 데이터가 스키마를 따르고 있음)

Document DB는 읽기 스키마 (구조는 암묵적이고 읽을 때만 해석)

 

 

읽기 스키마 접근 방식은

컬렉션 안의 어떤 항목이 모두 동일한 구조가 아닐 때 (다른 유형으로 구성돼 있을 때) 유용.

여러 유형의 오브젝트가 있고 각 오브젝트 별로 테이블에 넣는 방법은 실용적이지 않음.

사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정되는 경우 유용함

 

질의를 위해, 문서형 DB를 저장소 지역성 을 사용하면 이점이 있음 (질의하려는 데이터가 인접한 곳에 있음)

RDB의 경우 색인이 있다고 하더라도 디스크 탐색을 해야 하기 때문에 더 많은 시간이 소요됨

한 번에 해당 문서의 많은 부분을 필요로 하는 경우 유용, 한 번에 문서 전체를 적재해야 하고 문서 갱신해야 할 때도 전체 문서를 재작성 해야 하기 때문에 큰 문서는 낭비일 수 있고 문서를 가능한한 작게 유지

문서형 모델 뿐만이 아니라 다른 모델에서도 지역성을 위해 관련 데이터를 그룹화 하는 개념이 있음

• 오라클: 다중 테이블 색인 클러스터 테이블

클러스터 테이블이란?: 특정 key 값을 공유하는 다른 table의 row가 같은 data block에 저장되는 것 (지역성)

같이 join 되어 query되는 경우가 많은 table 인 경우 Disk I/O 를 줄일 수 있음, 클러스터 key 가 각 row 에 따로 저장되는 것이 아니기 때문에 적은 storage 를 쓸 수 있음

 

BUT 테이블이 자주 업데이트 되거나(데이터 블록을 재배치해야 하는 문제가 있음), full table scan을 하는 경우 유용하지 않음

종류에는 인덱스 클러스터 (클러스터 키 기반으로 인덱스 생성), 해쉬 클러스터 (인덱스 키가 해쉬 함수, hask key value가 row가 저장된 disk 주소를 가리킴, 인덱스 클러스터와 비교해서 disk I/O 한번이 줄어듬)

• 빅 테이블 데이터 모델 (카산드라, HBase ..): 칼럼 패밀리

An HBase table contains column families, which are the logical and physical grouping of columns. There are column qualifiers inside of a column family, which are the columns. (https://www.ibm.com/docs/en/db2-big-sql/7.1?topic=performance-hbase-basics)

다양한 질의 언어

명령형 질의 언어 (IMS, 코다실) - 어떻게 질의 해야 하는지 표현, 명령어를 특정 순서대로 수행하게 질의하기 때문에 다중 코어에 적절하지 않음

선언형 질의 언어 (sql) - 데이터베이스 상세 구현이 숨겨져 있어 질의 변경하지 않고도 구현을 변경하여 최적화 가능, 병렬 실행 가능

맵 리듀스 함수 (Map-reduce)

대량 데이터를 처리하기 위한 프로그래밍 모델,

읽기 전용 질의를 수행할 때 사용

map(⇒ collect와 유사), reduce 함수를 기반

map, reduce 함수는 순수 함수여야 함. 입력으로 전달된 데이터만 사용하고 추가적으로 DB 질의를 수행할 수 없어야 하고, side-effect 가 없어야 함

이 제약사항이 있어야 장애가 발생해도 재실행 할 수 있음

몽고 DB는 집계 pipeline 함수가 있음

그래프 기반 데이터 모델

데이터 간 연결이 복잡해지면?

RDB에서 다대다 관계가 매우 일반적이라면 ? → 그래프 모델

그래프 모델은 정점 과 간선 으로 이루어짐

그래프 모델은 데이터 저장소에 완전히 다른 유형의 객체를 일관성 있게 저장 가능

속성 그래프 모델

정점:

• 식별자
• 속성 컬렉션 (키-값 쌍)
• 유입 간선 set
• 유출 간선 set

간선:

• 식별자
• 간선 시작 정점
• 간선 끝 정점
• 정점 간 관계 유형 레이블
• 속성 컬렉션

서로 다른 유형의 관계에 대해 서로 다른 레이블을 사용하면 단일 그래프에 다른 유형의 정보를 저장하면서도 데이터 모델 유지 가능

데이터 구조를 변경하더라도 단일 그래프에 손쉽게 통합할 수 있음

사이퍼 질의 를 이용할 수 있음

MATCH (:Person {name: 'Keanu Reeves'})-[:ACTED_IN]->(:Movie)<-[:ACTED_IN]-(coActor:Person),
  (coActor)-[:ACTED_IN]->(:Movie)<-[:ACTED_IN]-(:Person {name:'Tom Hanks'})
RETURN DISTINCT coActor.name AS coActor

Keanu Reeves and Tom Hanks 와 함께 연기한 배우를 retrieve 하는 query

이렇게 각 data 간 연결이 복잡하지만 각 data의 유형이 다른 경우 graph 를 사용하면 될 듯 함 (⇒ social media 같은 경우)

sql에서 위와 같은 그래프를 질의할 경우, 질의에 필요한 조인을 미리 알고 있어야 함 .. 재귀 공통 테이블식 을 이용할 수 있지만 그래프 질의에 비해 복잡할 수 있음

그래프 질의에서는 가변적으로 여러 간선을 순회해야 함, 미리 수를 고정할 수 없음

트리플 저장소 모델

트리플 저장소에는 모든 정보를 주어, 서술어, 목적어 처럼 3가지 형식으로 저장

주어는 그래프의 정점임

목적어는 두 가지 타입 중 하나

• 서술어와 목적어는 주어 정점에서 속성의 키-값 쌍과 유사
• 서술어는 그래프의 간선이고 주어나 목적어가 정점이 될 수 있음

RDF는 자원 기술 프레임워크로 서로 다른 웹 사이트가 일관된 형식으로 데이터를 기술할 수 있도록 하는 방법, 스파클(SPARQL)은 RDF 데이터 모델 사용한 트리플 저장소 질의 언어

PREFIX  dc: <http://purl.org/dc/elements/1.1/>
PREFIX  : <http://example.org/book/>

SELECT  $title
WHERE   { :book1  dc:title  $title }

정리

문서 데이터베이스 는 app이 요구하는 데이터 형식이 문서 자체에 포함되어 있고 문서 간 관계가 없을 때 주로 사용

그래프 데이터베이스는 문서 데이터베이스와는 정반대로 모든 데이터가 (잠재적으로) 관련 있다는 사용 사례를 기반으로 할 때 주로 사용

스키마가 명시적인지 / 암시적인지에 따라 다양한 데이터 모델을 선택할 수 있음

 

 

참고:

https://docs.oracle.com/en/database/oracle/oracle-database/21/cncpt/tables-and-table-clusters.html#GUID-22771373-D8B8-4A76-9F08-1567489269BB

https://neo4j.com/docs/cypher-manual/5/queries/basic/