데이터 중심 어플리케이션 설계 [PART 1]
Designing Data Intensive Applications - O’REILLY

02. Data Models and Query Languages


📖 Overview

02-1. 관계형 모델과 문서 모델

02-2. 데이터를 위한 질의 언어

02-3. 그래프형 데이터 모델

02 정리
Reference


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

배경

“내 언어의 한계는 내 세계의 한계를 의미한다” (..?)

  • 데이터 모델 = 소프트웨어 개발에서 제일 중요한 부분

    • (why?) 소프트웨어가 어떻게 작성됐는지 + 해결하려는 문제를 어떻게 생각해야 하는지 에도 영향

  • 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 둬서 만드는 것이 일반적 애플리케이션 개발

  • 각 계층의 핵심적 문제는 다음 하위 계층 관점에서 데이터 모델을 표현하는 방법

    (1) 애플리케이션 개발자는 현실을 보고 객체나 데이터구조, API를 모델링 (for 애플리케이션)
    (2) 데이터 구조 저장 시에는 범용 데이터 모델로 표현 (JSON/XML 문서, 관계형 DB 테이블, 그래프 모델) => 2장 내용
    (3) DB SW 개발하는 엔지니어는 위 데이터를 메모리나 디스크, 네트워크 상의 바이트 단위로 표현하는 방법 결정 (표현은 다양한방법으로 질의,탐색,조작,처리 등을 가능하게함) => 3장
    (4) HW 개발 엔지니어는 전류, 빛의파동, 자기장등의 관점에서 바이트를 표현하는 방법 발견

  • 각 계층은 명확한 데이터 모델을 제공해 하위 계층의 복잡성을 숨긴다 (추상화)

  • 다양한 유형의 데이터 모델 => 각 데이터 모델은 사용 방법에 대한 가정을 나타냄

  • 애플리케이션에 적합한 데이터 모델을 선택하는 작업은 매우 중요

    • (why?) 데이터모델은 그 위에서 SW가 할수 있는/없는 일에 지대한 영향을 주므로

그래서 2장에서는 💡

  • 데이터 저장과 질의를 위한 다양한 범용 데이터 모델 알아보기
    • 관계형 모델 (relational model)
    • 문서 모델 (document model)
    • 그래프 기반 데이터 모델 (graph-based data model)
  • 다양한 질의 언어 & 사용 사례 비교

02-1 관계형 모델과 문서 모델

Most Famous 데이터모델은? => 관계형 모델 기반의 SQL

관계형 모델

  • 데이터 구성
    • 관계 (relation) : 순서 없는 튜플의 모음 (= SQL의 테이블)
    • 튜플 (tuple) : (= SQL의 로우(row))
  • 관계형 데이터베이스 관리 시스템 (RDBMS, relational database management system)
    • RDBMS + SQL
    • 정규화된 구조로 데이터를 저장/질의 가능
  • 관계형 데이터베이스 (RDB) 의 근원 => 비즈니스 데이터 처리
    • 사용 사례 : 트랜젝션 처리, 일괄처리
  • 관계형 모델의 목표
    • “정리된 인터페이스 뒤로 구현 세부사항을 숨기는 것”
  • 접근 방식의 경쟁
    • 네트워크 모델, 계층 모델 제시 (1970-80s)
    • 객체 데이터 베이스 반짝 (1980-90s)
    • XML 데이터베이스 인기no (2000s)
    • 결국은 관계형 모델이 오랜시간 우위 지속
    • NoSQL은? (2010s) => NoSQL의 탄생
  • 컴퓨터의 발전 & 네트워크화로 인한 변화
    • 컴퓨터의 목적이 다양해짐
    • 관계형 데이터베이스 => 비즈니스 데이터 처리 + a

NoSQL의 탄생

  • NoSQL 이란?
    • 처음엔 인기 트위터 해시태그 #NoSQL
    • “Not Only SQL” 로 재해석됨
  • NoSQL의 원동력 (장점)
    • 뛰어난 확장성
    • 무료 오픈소스
    • 특수질의 동작
    • 제한↓ 동적이고 풍부한 표현력
  • 다중 저장소 지속성(polyglot persistence)
    • 애플리케이션의 요구사항에 따라 적절한 다양한 데이터 저장소를 동시에 사용
    • (관계형 데이터베이스 + 비관계형 데이터스토어) 사용도 가능

객체 관계형 불일치

  • 객체 지향 프로그래밍(OOP) 언어로 개발하는 어플리케이션 + SQL
    • 애플리케이션 코드 <==(전환 계층 필요)==> 데이터 베이스 모델 객체
    • RDB의 SQL 과 프로그래밍 언어 사이의 데이터 구조, 기능등의 차이로 인한 충돌
    • = 임피던스 불일치(impedance mismatch)
  • 객체 관계형 매핑(ORM) 프레임워크
    • ORM (Object-Relational Mapping) : 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해주는 것
    • => 전환 계층의 Boilerplate Code 감소 (but 차이는 여전)
  • 예제
    • p.30 ~ Linkedin 예제
    • 이력서 같이 모든 내용을 갖추고 있는 문서 형태의 데이터 구조 (=> JSON 👍🏻)
  • 문서 지향 데이터베이스 (document-oriented database)
    • JSON 포맷 지원
    • ex. MongoDB, RethinkDB, CouchDB, Espresso
  • JSON 표현
    • 임피던스 불일치 감소, 스키마 유연성, 더 나은 지역성(locality)
    • 일대다(1:N) 관계 (데이터 트리 구조)
    • But, 데이터 부호화 형식으로서 가지는 문제 有 => [4장]

다대일과 다대다 관계

  • 평문(텍스트 문자열) 저장 vs ID 사용
    • ID : 의미있는 정보는 한 곳에만 저장. 참조는 모두 ID 사용
    • 텍스트 : 그것을 사용하는 모든 레코드에서 중복 저장
    • 즉, ID 사용의 장점은 => 중복 제거, 변경 용이
  • 중복된 데이터의 정규화
    • 다대일(N:1) 관계 필요
    • 관계형 > 문서형
  • 문서 데이터베이스의 JOIN ?
    • 보통 지원 X (트리구조, 조인 필요 x)
    • DB가 지원하지않으면 다중 질의를 만들어 조인을 흉내내야함
  • Q. 앗 나는 join-free 문서여도 문제 없다구요?
    • 기능이 추가될수록 데이터는 상호 연결되는 경향 => 다대다(N:M) 관계
    • 따라서 참조 표현 / 질의를 위한 조인이 필요하게 될 수도 있음

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

  • “‘다대다 관계’ 를 어떻게 표현할건가? “ 의 논쟁
    • 관계형 데이터베이스 : “ssap-possible”
    • 문서 데이터 베이스 & NoSQL : “…”
    • 오래된 ‘대논쟁’. 가장 초기의 전산화 데이터베이스 시스템으로 돌아가면 …
  • IBM의 정보 관리 시스템 (IMS, Information Management System)
    • 계층 모델 사용 (= JSON 모델과 비슷)
    • 일대다 (o) / 다대다 (x) 조인(x)
  • 계층 모델의 한계를 극복하기 위한 2가지 솔루션
    • 관계형 모델 (SQL)
    • 네트워크 모델 (희미..)

네트워크 모델

  • = 코다실 모델
    • 코다실 (CODASYL, Conference on Data Systems Languages) 에서 표준화
  • 특징
    • 계층 모델을 일반화 (+ 다중 부모 가능)
    • 레코드 간 연결은 foreign key 보다는 ‘프로그래밍 언어의 포인터’ 와 비슷
    • 사실상 삽입시 조인 수행
  • 접근 경로
    • 레코드 접근의 유일한 방법
    • 최상위 레코드(root) 에서부터 연속된 연결 경로를 따르는 방법
  • 접근 경로의 문제점
    • 다중 부모 가질 시, 다양한 관계를 모두 추적해야 함
    • 수동 접근 경로는 성능은 효율, 코드의 복잡성 및 유연X
  • 즉, 네트워크 모델 (계층 모델) 은 원하는 데이터가 경로에 없으면 GG
    • 새로운 접근 경로 다룰 시, 질의 코드 재작성 필요 (☠️)

관계형 모델

  • 관계형 모델의 하는 일
    • 모든 데이터 배치
    • 관계(테이블) = 튜플(로우)의 컬렉션
  • 특징 (vs 네트워크 모델)
    • 복잡한 접근 경로 X
    • 임의 조건에 일치하는 로우 읽기 가능
    • 다른 테이블과의 foreign key 관계와 무관하게 로우 삽입 가능
    • 질의 시 조인
  • “접근경로가 없다?”
    • 없다기보단 Query Optimizer가 자동으로 대신 만드는 것
  • 관계형 데이터베이스의 ‘질의 최적화기 (Query Optimizer)’
    • 새로운 기능 추가가 쉬움
      • 새로운 색인을 위해 질의를 바꿀 필요 X (자동으로 가장 적합한 색인 사용)
    • 범용 최적화기 사용시 모든 애플리케이션이 혜택

문서 데이터베이스와의 비교 (공통점)

  • 문서 데이터베이스 = 계층 모델
    • 상위 레코드 내에 중첩된 레코드 저장 (별도 테이블 x)
  • 문서 데이터베이스 = 관계형 데이터베이스
    • 다대일, 다대다 관계 표현의 근본적 동작 => 관련 항목은 고유한 식별자로 참조
      • 관계형 모델 : 외래 키 (foreign key)
      • 문서 모델 : 문서 참조 (document reference)
      • => 조인이나 후속질의를 사용해 읽기 시점에 확인

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

  • 관계형 데이터베이스 vs 문서 데이터베이스
    • 내결함성(5장), 동시성 처리(7장), …
    • 여기서는 ‘데이터 모델’의 차이점 만 집중
  • 데이터 모델 비교
    • 관계형 DB : 조인, 다대일/다대다 관계 지원 good
    • 문서 DB : 스키마 유연성, 지역성 (성능 ↑), 애플리케이션의 데이터구조와 유사
      • 한계) 문서 내 중첩항목 바로 참조 X, 미흡한 조인 지원
  • “아 ㅋㅋ 그래서 어떤게 더 간단한데?”
    • => 데이터 항목 간의 관계 유형에 따라 다름

a) 데이터가 문서랑 비슷한 구조일 경우 => 문서 모델

  • 여러 테이블로 찢는(shredding) 관계형 기법은 불필요한 복잡도

b) 다대다 관계 사용 => 관계형 사용

  • 비정규화 데이터의 일관성을 유지하기 위한 코드 복잡도 및 다중 요청 (성능 ↓)

c) 상호 연결이 많은 데이터 => 관계형은 무난, 그래프 모델 사용

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

  • 스키마 강요
    • JSON (문서, 관계형) : 스키마 강요 X
    • XML (관계형) : 선택적 스키마 유효성 검사 포함
  • 문서 데이터베이스는 스키마리스(Schemaless) ?
    • “스키마가 없다”
      • = 임의의 키와 값을 문서에 추가 가능
      • = 읽을 때 필드 존재 여부를 보장하지 않음
    • 암묵적 스키마는 있지만 DB 는 강요 X
  • 스키마 접근 방식
    • 쓰기 스키마 (schema-on-write) : 스키마는 명시적이고 DB는 모든 데이터가 스키마를 따름을 보장 (RDB 접근 방식)
      • (= Statically typed)
      • 모든 레코드가 동일한 구조일 경우 good
    • 읽기 스키마 (schema-on -read) : 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석
      • (= Dynamically typed)
      • 컬렉션 내 항목이 모두 동일한 구조가 아닐 경우 good
  • 데이터 타입 변경 예시
    • 쓰기 스키마 : 마이그레이션 수행 필요 (중단시간 ↑)
    • 읽기 스키마 : 애플리케이션에서 이전 문서에 대한 처리 코드 추가
  • 더 자세한 스키마 내용은 [4장] 에서

질의를 위한 데이터 지역성

  • 저장소 지역성 (storage locality)
    • 한번에 해당 문서의 많은 부분을 필요로 하는 경우 good
  • 문서 모델의 저장소 지역성
    • 큰 문서에서는 낭비일 수도 (갱신시에도 전체 문서 적재)
      • 부호화된 크기를 바꾸지 않는 수정은 쉽게 수행 가능 (ref #19)
      • = update() vs upsert()
    • 따라서, 문서는 작게 유지하면서 크기가 커지는 쓰기를 지양
  • 문서 모델이 아닌 경우의 지역성
    • 구글의 Spanner DB 의 로우 교차 배치 스키마 (ref $28)
    • 오라클의 다중 테이블 색인 클러스터 테이블(multi-table index cluster table)
    • 빅테이블(Bigtable) 데이터 모델의 칼럼 패밀리(column-family) 개념
  • 더 자세한 지역성 내용은 [3장] 에서

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

  • 관계형 => 문서
    • 대부분의 RDBMS (MySQL 빼고) : XML 지원
    • PostgresQL(>=9.3), MySQL(>=5.7), IBM DB2(>=10.5) : JSON 지원
  • 문서 => 관계형
    • RethinkDB : 관계형 조인 지원
    • MongoDB driver : 자동으로 데이터베이스 참조 확인 (클라이언트 측 조인)
  • 관계형 DB 와 문서 DB는 점점 더 비슷해지는 중 (상호보완)
skrrr~🦷

02-2 데이터를 위한 질의 언어

관계형 모델의 등장 => 데이터를 질의하는 새로운 방법 도 등장

  • 선언형 질의언어 (SQL, 관계대수)
    • 결과가 충족해야하는 조건 + 데이터를 어떻게 변환할지 지정 (정렬, 그룹화, 집계, ..)
    • 어떻게 실행할지는 Optimizer의 몫
  • 명령형 코드 (IBM, 코다실)
    • 특정 순서로 특정 연산을 수행하게끔 컴퓨터에게 지시
    • 목표를 달성하기 위한 방법
  • 선언형의 장점 (vs 명령형)
    • 선언형은 더 간결하고 쉬운 작업
    • 질의 변경 없이도 성능 향상 가능 (기능적으로 더 제한적 = 자동 최적화 여지 더 많음)
    • 종종 병렬 실행에 적합 (순서 의존 x)

웹에서의 선언형 질의

  • 예제
    • p.44 ~ 웹 사이트 예제
    • CSS, XSL (선언형) vs JS의 코어 DOM API (명령형)
    • 명령형 접근 방식의 문제점
      • 클래스 삭제 감지 x (페이지 리로딩 필요)
      • API 변경 시 코드 재작성 필요
  • 결론은 선언형 > 명령형 ?
    • 웹 브라우저 : 선언형 CSS 스타일 사용이 낫다
    • 데이터베이스 : 선언형 질의언어 SQL등이 명령형 질의 API보다 낫다

맵리듀스 질의

  • 맵리듀스 (MapReduce)
    • 많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델
    • (구글때문에 유명해졌다? (ref #33))
  • 일부 NoSQL 데이터 저장소 => 제한된 형태의 맵리듀스 제공
    • MongoDB, CouchDB
    • 많은 문서를 대상으로 read-only 질의 시 사용
  • 예제 - MongoDB의 맵리듀스
    • 선언형 질의와 명령형 질의 API 그 사이 어디쯤
    • FP의 map (collect) & reduce (fold/inject) 함수 기반
      • 단, 순수 함수 (pure function) 여야함 (side-effect X)
      • 임의 순서로 실행 가능, 재실행 가능
    • 집계 파이프라인(aggregation pipeline) 지원 (>= 2.2)
      • JSON 기반 구문
      • 맵리듀스 함수 작성의 어려움 해소를 위함
      • 선언형 질의 언어 (=> Optimizer 열일 가능)
  • 맵리듀스 (low-level) vs SQL (high-level)
    • 반대 개념이 아님. 분산 SQL 구현도 가능하고, MR 사용한/사용하지 않은 구현 모두 O
    • 질의 중간에 자바스크립트 사용/확장 가능 (MR, 일부 SQL)
  • 더 자세한 맵리듀스는 [10장] 에서

02-3 그래프형 데이터 모델

  • 1:N (트리구조), 레코드간 관계 無 => 문서모델
  • N:1, N:M 관계 => 관계형 모델
  • 복잡한 N:M 관계 => 그래프형 모델
  • 구성
    • 정점 (vertex) : (=노드, 엔티티)
    • 간선 (edge) : (=관계, 호(arc))
  • 특징
    • 많은 유형의 데이터 모델링 가능
    • 동종 데이터 뿐만아니라 다른 유형의 객체도 일관성있게 저장 가능
  • 그래프의 데이터 구조화
    • 속성 그래프 모델 : Neo4j, Titan, InfiniteGraph
    • 트리플 저장소 모델 : Datomic, Allegrograph
  • 그래프의 질의 방식
    • 선언형 질의 언어 : Cypher, SPARQL, Datalog
    • 명령형 질의 언어 : Gremlin
    • 그래프 처리 프레임워크 : Pregel => [10장]

속성 그래프

  • 정점(vertex) 구성 요소
    • 고유한 식별자
    • 유출(outgoing) 간선 집합
    • 유입(incoming) 간선 집합
    • 속성 컬렉션 (key-value)
  • 간선(edge) 구성 요소
    • 고유한 식별자
    • 간선 시작 정점 (꼬리 정점)
    • 간선 끝 정점 (머리 정점)
    • 두 정점 간 관계 유형을 설명하는 레이블
    • 속성 컬렉션 (key-value)
  • 특징
    • 1. 정점은 다른 정점과 간선으로 연결됨 (특정 유형 제한 스키마 x)
    • 2. 일련의 정점을 따라 앞뒤 방향으로 순회
    • 3. 다른 유형의 관계에 서로 다른 레이블 사용 (=> 깔끔한 모델 유지)
  • 즉, 많은 유연성 제공
    • 기능 추가 시 쉬운 확장 ok
    • 구조가 다르거나 데이터 입도가 가지각색인 경우도 ok
    • 데이터 입도 (granularity)
      • “데이터가 얼마나 자세히 분할되었는가”
      • = 얼마나 세밀하게 나눌지 (Fine-grained) + 거칠게 묶을지(Coarse-grained)

사이퍼 질의 언어

  • 사이퍼 (Cypher)
    • 속성 그래프를 위한 선언형 질의 언어
    • Neo4j 그래프 데이터베이스용으로 제작
  • 사이퍼 질의
    • 정점 : 상징적 이름 (id) 포함
    • 간선 생성 : (꼬리노드 id) -[:간선 label]=> (머리노드 id)
    • MATCH 질의 사용 예제
      • :WITHIN*0 = Regex * (0회 이상 반복)
  • 다양한 질의 실행의 방법 => 고민 x (Optimizer 가 알아서)

SQL의 그래프 질의

  • 관계형 DB <=> 그래프 데이터
    • 관계형 ➡ 그래프 표현 : 가능 ([예제 2-2] 참고)
    • 그래프 ➡ 관계형 구조로 + SQL 쿼리 : 가…가능.. (△)
  • 그래프 데이터 vs 관계형 데이터베이스 (변환이 어려운 이유)
    • 관계형 : 질의에 필요한 조인 미리 파악 가능
    • 그래프 : 가변적인 간선 순회 (조인 개수 고정 X)
  • 재귀 공통 테이블 식 (recursive common table expression)
    • WITH RECURSIVE 문
    • 관계형 DB에서도 가변 순회 경로에 대한 질의 표현 가능
    • But 예제에서는 훨씬 길고 복잡한 질의문.. ([예제 2-4 vs 2-5])
  • => 사용 사례에 맞는 데이터 모델 선택이 중요

트리플 저장소와 스파클

  • 트리플 저장소 모델 == 속성 그래프 모델 ?
    • 거의 동등. 같은 생각을 다른 용어로 표현
  • 정보 저장 형식 => 세 부분 구문 (three-part statements)
    • (주어(subject), 서술어(predicate), 목적어(object))
    • 주어 = 그래프의 정점 (V)
    • 목적어 = (1) 원시 데이터타입 값 (value) or (2) 다른 그래프의 정점(V)
    • 서술어 = (1) 속성 (key) or (2) 간선(E)
  • 예시
    • (1) 정점+속성의 키+값 : ex. (루시, 나이(key), 33(value))
    • (2) 꼬리정점+간선+머리정점 : ex. (루시, 결혼하다, 알랭)
  • 터틀 (Turtle) 형식의 트리플
    • 터틀은 Notation3(N3) 의 부분 집합
    • 정점 : _:someName
      • 서술어 a 는 뭘까 🤔 => 정점 선언? (ex. _:usa a :Location)
    • 세미콜론(;) 사용 시, 동일 주어에 대한 반복 작업 수행 가능

시맨틱 웹

  • 트리플 저장소 데이터 모델 != 시맨틱 웹
    • 어떠한 관계도 주장하지는 않으나 (ex. Datomic), 많은 사람들이 밀접한 관계로 생각
  • 시맨틱 웹 : 컴퓨터(기계)가 읽을 수 있는 (Ontology) 데이터로 정보를 게시하고 처리하는 방식의 웹
    • 과대평가 후 현재는 부진..

RDF 데이터 모델

  • 자원 기술 프레임워크 (RDF, Resource Description Framework)
    • 서로 다른 웹 사이트가 일관된 형식으로 데이터를 게시하기 위한 방법 제안
    • => 데이터 웹 (web of data) 에 자동으로 결합 가능 (=database of everything)
  • RDF는 인터넷 전체의 데이터 교환을 위해 설계
    • (주어, 서술어, 목적어) 가 주로 URI
    • 접속 가능 여부와는 무관 (RDF 관점에선 just 네임스페이스)
  • 형식
    • 터틀 언어 (보기 쉬움)
      • RDF 데이터를 human-readable format 으로 표현
    • XML 형식 (가능은 하지만 장황)
    • 서로 다른 RDF 형식으로 변환하는 도구 => 아파치 제나(Jena)

스파클 질의 언어

  • 스파클 (SPARQL, SPARQL Protocol And RDF Query Language)
    • RDF 데이터 모델을 사용한 트리플 저장소 (선언형) 질의 언어
    • 사이퍼와 유사 (p61 참고)
    • 시맨틱 웹이 아니더라도 애플리케이션 내부적 사용하는 강력한 도구가 될 수 있음
  • 스파클 질의
    • 변수는 ?로 시작
  • RDF는 서술어만 사용 (속성/간선 구별 x)

그래프 데이터베이스 vs 네트워크 모델 (차이)

  • 스키마
    • 코다실 : 다른 레코드 타입, 중첩가능 레코드 타입 지정하는 스키마 존재
    • 그래프 : 제한 x (모든 정점은 다른 정점으로 가는 간선 ok)
  • 접근 방식
    • 코다실 : only 접근 경로 중 하나 탐색
    • 그래프 : 고유 ID로 정점 직접 참조 or 색인으로 빠르게 찾기
  • 정렬
    • 코다실 : 레코드 하위 항목은 정렬된 집합 (신규 삽입시 위치 고려)
    • 그래프 : 정렬 x. 질의 시에만 결과 정렬
  • 질의
    • 코다실 : 모든 질의는 명령형. 스키마 변경 시 질의 쉽게 손상
    • 그래프 : 대부분 고수준 선언형 질의언어 사용. (명령형도 가능은 o)

초석: 데이터로그

  • 데이터로그 (Datalog)
    • 스파클, 사이퍼보다 훨씬 오래된 언어.. 말그대로 질의언어의 기반 초석 제공
    • 사용 예) Datomic, Cascalog (s-expression 문법)
  • 정보 저장 형식
    • 서술어(predicate) (주어(subject), 목적어(object))
    • 트리플 보다 좀 더 일반화
  • 데이터로그 질의
    • 복잡한 질의를 작은부분으로 나눠 단계별로 차례대로 나아감 => 규칙(rule) 정의
    • 규칙은 다른 규칙 참조 가능
  • 예제
    • p63 ~ (예제는 Prolog 문법)
    • 서술어 = 데이터나 다른 규칙으로부터 파생 (트리플 x)
    • 변수 = 대문자로 시작하는 단어
  • 특징
    • 이전의 질의 언어와는 다른 사고
    • 다른 질의의 규칙을 결합/재사용 가능하다는 점이 강력 (복잡한 데이터에 효과적)

02 정리

  • 데이터 모델은 애플리케이션 요구사항에 가장 적합한 모델을 찾는 것이 중요 (만능 솔루션 x)
  • 데이터 표현을 위한 발전
    • 데이터를 큰 트리(계층 모델) 로 표현 하려니 __ 다대다 관계 표현에 부적합
    • => 관계형 모델 고안 __ 애플리케이션 요구사항에 부적합한 케이스 존재
    • => 비관계형 데이터저장소 (NoSQL) 등장
  • NoSQL의 2가지 갈래
    • 문서 데이터베이스 (문서 간 관계 ↓)
    • 그래프 데이터베이스 (모든것의 관계 ↑)
  • 스키마 유연성의 차이
    • 스키마가 명시적인지(쓰기에 강요)
    • 스키마가 암시적인지(읽기에 다룸)
  • 각 데이터 모델은 고유한 질의 언어 or 프레임워크 제공
  • 그 외 다양한 데이터 모델들
    • GenBank, ROOT, 전문(full-text) 검색, …

Reference