[2] 어떤 데이터 모델을 어떤 경우에 쓰면 좋을까?

✹ 데이터 모델이 중요한 이유: 해결하려는 문제를 어떻게 생각해야 하는지에 대해서도 영향을 미치기 때문

대부분의 애플리케이션은 데이터 모델간의 계층을 둬서 만든다. 하위 계층은 추상화 되어 있어 복잡성을 숨기고 효율적으로 일할 수 있게 한다.

• API 를 개발해서 인풋 아웃풋만 제공하고 내부 구조는 숨긴다거나
• 데이터 구조를 저장할 때는 범용 모델인 json, xml, 테이블, 그래프로 한다거나
• json,xml,테이블,그래프 데이터를 디스크/메모리/네트워크 상태의 바이트 단위로 표현하는 방법을 결정해서 질의,처리 등을 할 수 있게 한다거나

이번 2장에서 할 것: 범용 데이터 모델 (관계형, 문서, 그래프기반) 비교 & 질의 언어

관계형 모델 vs. 문서 모델

관계형 데이터베이스(Relational Datebase Management System)

• "관계" 용어의 유래: 테이블의 컬럼들이 관계로 구성되어있기 때문
• 약 30년 정도 우위가 지속됨.
  • (elsboo) p.28 그 이후는 NoSQL 인기가 높아짐. 비구조화데이터를 분석하려는 요구가 높아지기 때문. 첫 회사에서 데이터레이크 컨셉으로 커다란 호수에 데이터 다 때려넣고 필요한 데이터만 골라 데이터마트에 저장 후 분석하는 컨셉이 있었다.
• RDB의 목표: 정리된 인터페이스 뒤로 구현 세부 사항을 숨기자
• 당시 네트워크 모델, 계층 모델, 객체 데이터베이스, XML 데이터베이스 경쟁자가 있었지만 다 제치고 RDB가 이김
  • (elsboo) p.29 네트워크 모델: 망 구조로 자식이 여러 부모를 가질 수 있고 얽힌 형태 데이터 모델 종류
  • (elsboo) 계층 모델: 리눅스 파일시스템 구조 처럼 자식이 한 부모를 가지는 트리 형태
  • (elsboo) 객체 데이터베이스: OOP 처럼 객체, 상속, 오버라이딩 개념이 구성된 형태
• NoSQL 이 관계형 모델을 이기려는 가장 최신 시도이다. 뭐가 좋길래?
  • 확장성이 좋아 RDB보다 대규모 데이터나 매우 높은 쓰기 처리량을 쉽게 할 수 있음.
  • 무료 오픈소스
  • RDB 는 지원 안 하는 특수 질의 동작
  • 스키마 제한이 약함

임피던스 불일치

• OOP 언어로 RDB 에 저장하려면 코드와 데이터모델 사이의 거추장스러운 전환 계층이 필요한 형상
• (elsboo) p.30 RDB의 구조화된 데이터 타입은 json 저장&질의를 말하는 건가?
• (elsboo) p.31 RethinkDB: 섭종
• (elsboo) p.32 지역성: 데이터지역성을 의미하는거라면 이는 cpu 캐시 hit 이 더 많이 일어날 수 있도록 데이터를 배치하는 코드 최적화 방법

다대일 vs. 다대다

• ※ ID 를 무슨 값으로 해야할 지 고민이 되면 아무 의미 없는 값으로 해라. 의미를 가졌다간 미래에 그 의미를 변경하게 되는 경우가 생길 때 큰 코 다친다.
• 다대일: 많은 사람들이 한 특정 지역에 산다든가, 많은 사람들이 한 특정 업계에서 일한다든가
• 다대일은 문서 모델에 적합하지 않다!
  • 왜? RDB 는 조인이 쉽기 때문에 다른 테이블 참조가 일반적이지만 문서 DB는 조인에 대한 지원이 약하다.
  • 코드단에서 할 수는 있지만 번거롭다.

네트워크모델 vs. 관계형 모델: 문서DB와 계층 모델의 다대다 구현 한계를 위한 해결책

네트워크 모델

• 계층모델 트리구조는 하나의 부모만 가질 수 있지만, 네트워크 모델에서는 여러 부모를 가질 수 있다. 그래서 다대다가 가능하다.
• 원하는 레코드에 접근하기 위해선 최상위 레코드 부터 연결 경로(접근 경로)를 따라가는 방법 뿐이다.
• 그렇기 때문에 다중 부모를 갖고 있으면 관계를 모두 추적해야한다.

관계형 모델

• 복잡한 접근 경로가 없어 데이터 접근이 쉽다.
• 쿼리 옵티마이저가 있어 질의의 어떤 부분을 어떤 순서로 실행할지와 사용할 색인을 자동으로 결정한다. → 접근 경로를 자동으로 만든다. → 위에서 나온 RDB의 목표에 부합

문서 DB는?

• 계층 모델과 비슷한 점: positions:[{},{}] 형태의 중첩 레코드를 저장하는 방식
• 관계형 DB 와 비슷한 점: 문서 참조할 때는 고유한 식별자로 참조함

중간 결론

문서DB가 관계형DB 보다 필요한 경우

• 스키마 정의가 유연해야 할 때
• 지역성에 기인한 더 나은 성능을 기대할 때
• 애플리케이션 데이터 구조가 문서에 더 가까울 때

관계형DB가 문서DB 보다 필요한 경우

• 조인, 다대일, 다대다 관계가 있는 데이터일 때
• 하지만 다대다가 많다면 그래프 모델이 더 자연스럽다.

가장 이상적인 경우

• 관계형과 문서의 혼합 모델
• 관계형(postgresql, mysql, db2): json 질의 기능 지원
• 문서(mongoDB): 자동으로 데이터베이스 참조
  • (elsboo) 몽고디비 드라이버가 자동으로 데이터베이스 참조한다는게 무슨 뜻일까

데이터 지역성

(elsboo) 저장소 지역성: 데이터 접근 속도를 향상시키기 위해 최근에 접근한 데이터나 그 근처 데이터를 메모리에 미리 올려놓는 방법

• 어느 경우에 좋은가? 한 번에 해당 문서의 많은 부분을 필요로 할 때
• 보통 문서의 작은 부분만 접근하거나 갱신할 때도 문서 전체를 적재하거나 재작성해야하기 때문에 문서 수는 작으면서 문서 크기가 증가하는 쓰기는 피하라고 권장한다.

데이터를 위한 질의 언어

명령형 vs. 선언형 언어

명령형 언어

• ex. 애플리케이션 코드
• 특성 순서로 특정 연산을 수행하게끔 지시한다.

선언형 언어

• ex. sql
• 원하는 결과와 조건만 입력
• 그걸 가지기 위해 어떻게 실행할지는 쿼리 옵티마이저가 알아서 해줌
• 병렬 실행하는게 쉽다. DB 내부에서 병렬 처리를 구현해주기 때문이다.

맵리듀스 질의

• 대량 데이터를 처리하기 위한 프로그래밍 모델
• 일부 NoSQL(mongoDB, couchDB) 에서 지원
• 선언형도 아닌 완전한 명령형도 아닌 중간 정도
  • 질의 로직이 반복적으로 호출되는 조각 코드를 표현하기 때문
• map() 과 reduce() 두 개 함수를 신중히 작성하는게 어렵고 선언형이 쿼리 옵티마이저가 해주기 때문에 몽고db는 선언형인 aggregation pipeline 지원

그래프형 데이터 모델

• 다대다 관계가 매우 일반적인 경우 유용
• 정점(vertex), 간선(edge) 두 객체로 이루어짐
• 그래프형이 잘 쓰이는 알고리즘: 자동차 길찾기, 페이지랭크
• 속헝형 그래프 모델: Neo4j, Titan, InfiniteGrapgh
• 트리플 저장소 모델: Datomic, Allegrograph
• 질의어 3가지: Cyper, SPARQL, Datalog 를 알아보겠다.

속성 그래프

정점 구성요소

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

간선 구성 요소

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

그래프가 좋은 이유

• 지역을 프랑스는 주/도 를 사용하고 미국은 군/주를 사용하는데 국가마다 다른 지역 구조를 표현할 수 있다.

사이퍼(cyper) 질의 언어

• 속성 그래프용 선언형 질의 언어
• ex. (Idaho) -[:WITHIN]-> (USA)
• 이를 SQL 의 with recursive 문으로 구현은 할 수 있지만 꽤나 어렵고 복잡하다. (사이퍼: 4줄, sql:29줄) → 적합한 데이터 모델을 선택해야 하는 이유

트리플 저장소

• 속성 그래프와 거의 동등하다.
• (주어, 서술, 목적어) 순으로 표현할 뿐이다.
  • ex) _:usa :name "US" : usa 정점은 name 속성이 "US" 이다
  • ex) _:usa :within _:namerica : usa 정점과 namerica 정점은 within 간선으로 관계를 맺고 있다.
• (elsboo) turtle 형식이 뭔가..?

시멘틱 웹

: 컴퓨터가 읽게끔 기계가 판독 가능한 데이터로도 정보를 게시하는 건 어떨까라는 개념

RDF(Resources Description Framework, 자원 기술 프레임워크) : 서로 다른 웹 사이트가 일관된 형식으로 데이터를 게시하기 위한 방법을 제안

현재는 너무 복잡한 표준과 약어로 사라지는 추세

https://kr.aving.net/news/articleView.html?idxno=13412 (스스로 판단하고 선택하는 지능형 웹비서 '시맨틱웹(Semantic Web)')

스파클 질의 언어

• 트리플 저장소용 질의 언어
• ex) ?usa :name "US"

이외에 데이터로그 질의 언어도 있다.

정리

✓ 관계형 DB: 계층(트리) 모델이 다대다 관계를 표현하기 어렵기 때문에 고안된 모델

✓ 문서 DB: 문서 끼리 관계가 거의 없을 때

✓ 그래프 DB: 문서DB 와 정반대로 모든 문서가 잠재적으로 관련이 있을 때

→ 한 모델을 다른 모델로 흉내낼 수는 있지만 매우 복잡하므로 각 목적에 맞는 시스템을 보유해야 한다.

✹ 문서&그래프 DB는 스키마를 강제하지 않아 애플리케이션을 쉽게 변경할 수 있다. ( ⇒ 읽기 스키마)

• 쓰기 스키마: 관계형db의 접근 방식. 스키마는 명시적이로 쓰여진 모든데이터가 스키마를 따르고 있음을 보장
• 읽기 스키마: 데이터 구조는 암묵적이고 데이터를 읽을때만 해석

✹ 이외 full-text 검색도 일종의 데이터 모델이다. 3장에서 색인 검색을 알려주겠다.

 

레퍼런스

데이터 중심 애플리케이션 설계 2장

데이터 중심 애플리케이션 설계