1. 데이터 모델
•
데이터 모델은 소프트웨어 개발에서 제일 중요한 부분이다.
•
데이터 모델은 소프트웨어가 어떻게 작성됐는지, 해결하려는 문제를 어떻게 생각해야 하는지에 대해서도 지대한 영향을 미치기 때문이다.
2. 관계형 모델과 문서 모델
2.1 관계형 모델
•
오늘날 가장 잘 알려진 데이터 모델
•
1970년 에드가 코드가 제안한 관계형 모델
•
데이터는 관계(relation)와 순서 없는 튜플(tuple)의 모음으로 구성된다.
•
1960-1970년대에 비즈니스 데이터 처리를 하기 위한 것이 근원
•
트랜잭션 처리(영업, 은행 거래, 항공 예약, 창고 재고 보관) + 일괄 처리(고객 송장 작성, 급여 지불, 보고)
2.2 NoSQL
•
2010년대에 관계형 모델의 우위를 뒤집으려는 가장 최신시도
•
Not Only SQL
•
대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성이 필요해짐
•
상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산
•
관계형 모델에서 지원하지 않는 특수 질의 동작
•
관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람
2.3 객체 관계형 불일치
•
오늘날 대부분의 애플리케이션은 객체지향 프로그래밍 언어로 개발됨
◦
이는 SQL 데이터 모델과 애플리케이션 사이에 거추장 스러운 전환 계층이 필요함
◦
모델 사이의 분리를 임피던스 불일치라고 부름
◦
액티브레코드나 하이버네이트같은 ORM 으로 boilerplate code 를 줄이지만, 여전히 두 모델의 차이가 완벽히 숨길 수 없다.
•
이력서와 같은 문서는 JSON표현이 더 적합하다.
◦
임피던스 불일치 감소, 스키마 유연성, 더 나은 지역성(locality)
◦
일대다(1:N) 관계 (데이터 트리 구조)
2.4 다대일 다디대 관계
•
ID나 텍스트 문자열의 저장 여부는 중복의 문제
◦
ID를 사용할 경우 = 참조하는 ID를 한곳에서 관리
▪
ID를 사용하게 된다면 ID 자체의 값은 아무런 의미가 없어야지 변경가능성에 벗어날 수 있다.
▪
의미를 가지게 된다면 ID를 변경해야 하는데 ID의 정보가 중복돼 있으면 모든 중복을 변경해야 한다.
▪
이러한 중복을 제거하는 일이 데이터베이스 정규화의 핵심이다.
◦
텍스트를 사용할 경우 = 중복 저장
▪
사용자 인터페이스에 자유 텍스트 필드가 있다면 평문 저장이 나을 수 있다.
2.4.1 N대 1관계
•
지역명이나 학교명을 평문으로 저장하게되면, 나중에 이름이 바뀌었을 때 갱신하기 어려워진다.
•
unique id 로 저장하게 된다면, id 자체는 아무런 의미가 없기때문에 변경할 필요가 없어진다.
•
id가 의미를 갖게되면, 미래에 언젠가 id를 변경해야할 수도 있다.
•
이러한 중복된 데이터(N대 1)를 정규화하는 것은 관계형 모델에선 쉽지만, 문서 지향에선 어렵다.
•
DBMS가 join을 지원해주지 않으면, 어플리케이션에서 다중 질의를 해서 join을 흉내내야 한다.
•
지금은 join이 필요없게 만들더라도, 비즈니스가 확장되가며, 데이터는 점차 상호 연결되는 경향이 있다.
2.4.2 N대 M관계
2.5 문서 데이터베이스는 역사를 반복하고 있나?
•
1970년대 비즈니스 데이터 처리를 위해 가장 많이 사용한 DB는 IBM의 IMS(Information Management System) 이다
•
IMS의 데이터 설계는 계층 모델이라 부르고 이것은 JSON 구조와 비슷하게 중첩된 레코드 트리로 표현한다
•
문서 DB 처럼 IMS에서도 일대다 관계는 잘 동작하지만 다대다 표현이 어려웠고 조인을 지원하지 않는다
◦
다대다 표현이 어렵기 때문에 데이터를 중복으로 표현할지? 참조를 수동으로 해결할지 결정해야 했다
•
이러한 어려움을 해결하기 위한 해결책은 관계형 모델과 네트워크 모델이 있다
2.5.1 네트워크 모델 (코다실 모델)
•
계층 모델을 일반화
◦
계층 모델의 트리구조에서 모든 레코드는 정확하게 하나의 부모가 있지만 네트워크 모델에서는 다중 부모가 있을 수 있다
•
원하는 레코드에 접근하는 유일한 방법은 최상위 레코드(root)부터 순차적으로 찾는 것이다 이를 접근 경로라고 한다
◦
가장 간단한 경우 접근 경로가 연결 목록의 순회와 같을 때이다
▪
루트부터 순차적으로 시작하여 원하는 것을 찾을때까지 한번에 하나씩 순회하는 방식
◦
다대다 관계에서는 다양한 경로가 어떤 레코드에 도달할 수 있다(다중 부모가 있는 경우)
▪
이렇게 다양한 경로인 경우에 모든 경로를 추적 해야한다
•
단점
◦
질의와 갱신을 위한 코드가 복잡하여 유연하지 못한 문제
◦
원하는 데이터 경로가 없다면 수많은 DB 질의 코드를 살펴봐야하고 새로운 접근 경로를 다루기 위해 코드를 재작성
2.5.2 관계형 모델
•
테이블, 로우의 컬렉션이 전부
•
네트워크 모델과 달리 개발자가 접근 경로를 생각할 필요가 없다
◦
접근 경로를 query optimizer가 대신 작성한다.
•
네트워크 모델에 비해 유지보수가 쉽다
2.5.3 문서 데이터베이스와의 비교
•
한 가지 측면에서 계층 모델로 되돌아감
•
테이블이 아닌 상위 레코드 내에 중첩된 레코드를 저장
•
다대일, 다대다 표현 시 근본적으로 관계형 데이터베이스와 다르지 않다
◦
서로를 고유한 식별자로서 참조하는데 관계형 모델에서는 외래키, 문서 모델에서는 문서참조(document reference)라고 부른다
◦
이 식별자들은 조인이나 후속 질의를 사용해 읽기 시점에 확인한다
2.6 관계형 데이터베이스와 오늘날의 문서 데이터베이스
2.6.1 어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까?
•
문서와 비슷한 구조(1대N, 트리 구조로 한번에 전체 트리를 적재)라면 문서 모델
•
상호 연결이 많은 데이터일 수록 문서 모델은 곤란, 관계형 모델은 무난, 그래프 모델은 매우 자연스럽다.
2.6.2 문서 모델에서의 스키마 유연성
•
사실 스키마가 완전히 없다고 볼 수는 없다.
•
쓰기 스키마는 없지만, 읽기 스키마가 암묵적으로 존재하기 때문이다.
◦
쓰기 스키마 : 정적 타입 확인, RDB의 방식
▪
이게 없다면 임의의 키와 값을 자유롭게 추가
◦
읽기 스키마 : 동적 타입 확인, 문서DB의 방식
▪
이게 없다면 필드의 존재여부가 보장되지 않음
•
즉 어플리케이션은 데이터를 읽는 코드가 있으므로 읽기 스키마를 어느정도 가정하고 사용한다.
•
데이터 타입 변경 예시
◦
문서형의 경우 쓰기의 경우 새로운 필드를 가진 문서를 작성하면 됨, 읽기의 경우 이전 문서 처리에 대한 추가코드를 추가해줘야 함
◦
DB는 마이크레이션이 필요하고 중단시간이 필요함
2.6.3 질의를 위한 데이터 지역성
•
관련 데이터를 함께 그룹화하는 개념
•
문서는 json, xml 로 부호화된 문자열이나 BSON 같은 바이너리로 저장된다.
•
문서 중 일부만을 접근경로로 꺼내서 사용하지 않고, 전체를 잘 사용한다면 지역성의 이점을 누렸다고 볼 수 있다.
◦
전체를 찾아야한다면 RDB는 multi table 을 join 해야하므로 이런 지역성 관점에선 좋지않다.
2.7 데이터를 위한 질의 언어
•
SQL은 선언형 질의 언어인 반면 IMS와 코다실은 명령형 코드를 사용하여 데이터베이스의 질의한다
◦
명령형 코드
▪
순서대로 어떤 연산을 수행하게끔 컴퓨터에 지시함
▪
명령어를 특정 순서로 수행하게끔 지정하기 떄문에 병렬 처리가 어렵다
◦
선언형 질의
▪
알고자 하는 데이터 패턴에 해당하는 조건, 데이터를 어떻게 변환(정렬, 그룹화, 집계) 할지를 지정함
▪
어떤 색인(index) 어떤 조인(join) 함수를 사용하고 어떤 순서로 실행할지는 질의 최적화기(query optimizer)가 결정함
▪
결과를 결정하기 위한 알고리즘을 지정하는게 아니라 결과의 패턴만 지정하기 때문에 병렬 실행으로 성능이 좋아질 가능성이 크다
2.7.1 맵리듀스 질의
•
많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델
•
여러 함수형 프로그래밍 언어에 있는 map(collect) 과 reduce(fold or inject) 함수를 기반으로 함
•
몽고 DB는 집계 파이프라인 Aggregation pipeline이라 부르는 선언형 질의 언어지원을 추가함.
•
맵리듀스는 연계된 자바스크립트 함수 두 개를 신중하게 작성해야 한다.
•
질의 최적화기가 질의 성능을 높일 수 있는 기회도 제공
2.8 그래프형 데이터 모델
•
N대M 관계가 일반적일 때 사용
•
그래프 = 정점(=노드, 엔티티, vertex) + 간선(관계, 호, edge)
•
단일 노드에서 사용 예제
◦
소셜 그래프 : vertex = 사람 , edge = 사람들이 서로 알고 있음
◦
웹 그래프 : vertex = 웹페이지 , edge = 다른 페이지로의 링크
▪
ex) pagerank : 웹페이지의 인기와 검색 결과에서 순위 결정
◦
교통 네트워크 : vertex = 교차로 , edge = 교차로 간 도로, 철도
▪
ex) 네비게이션 : 최단 경로 탐색
•
복합 노드에서 사용 예제
◦
페이스북 : vertex = 사람, 장소, 이벤트, 댓글 등 , edge = 친구여부, 체크인 위치, 이벤트 참석, 포스트 댓글 등
•
그래프 모델
◦
속성 그래프 모델 : Neo4j, Titan, InfiniteGraph
◦
트리플 저장소 모델 : Datomic, AllegroGraph
•
그래프 질의 언어
◦
선언형 질의 언어 : 사이퍼(Cypher), 스파클(SPARQL), Datalog
◦
명령형 질의 언어 : 그렘린(Gremlin)
•
그래프 처리 프레임워크 : 프리글(Pregel)
2.8.1 속성 그래프 모델
•
정점의 구성 요소
◦
id
◦
유출(outgoing) 간선 집합
◦
유입(incoming) 간선 집합
◦
속성 컬렉션 (키-값 쌍)
•
간선의 구성 요소
◦
id
◦
간선이 시작하는 정점(tail vertex)
◦
간선이 끝나는 정점(head vertex)
◦
두 정점 간 관계 유형을 설명하는 레이블
◦
속성 컬렉션 (키-값 쌍)
•
특징
◦
정점은 다른 정점과 간선으로 연결됨 (특정 유형 제한 스키마 x)
◦
일련의 정점을 따라 앞뒤 방향으로 순회
◦
다른 유형의 관계에 서로 다른 레이블 사용 (=> 깔끔한 모델 유지)
2.8.2 사이퍼 질의 언어
•
사이퍼 (Cypher)
◦
속성 그래프를 위한 선언형 질의 언어
◦
Neo4j 그래프 데이터베이스용으로 제작
2.9 스파클 질의 언어
•
스파클(SPARQL)은 RDF 데이터 모델을 사용한 트리플 저장서 질의 언어
2.9.1 그래프 데이터베이스와 네트워크 모델의 비교
•
코다실 데이터베이스는 다른 레ㅁ코드 타입과 중첩 가능한 레코드 타입을 지정하는 스키마가 있다.
◦
그래프 데이터베이스에는 이런 제한이 없다.
•
코다실에서 특정 레코드에 도달하는 유일한 방법은 레코드 접근 경로 중 하나를 탐색하는 방식
◦
그래프 데이터베이스는 고유id를 가지고 임의 정점을 직접 참조하거나 색인을 사용해 특정 값을 가진 정점을 빠르게 찾는다.
2.10 데이터로그
•
데이터로그는 스파클이나 사이퍼보다 훨씬 오래된 언어로 1980년대 학계에서 광범위하게 연구됨
•
질의 언어의 기반이 되는 초석을 제공했음
•
데이터로그의 모델은 트리플 저장소 모델과 유사하지만 조금 더 일반화됐다.
◦
(주어, 서술어, 목적어)로 트리플 작성하는 대신 서술어(주어, 목적어)로 작성한다.
2.10.1 질의 방법
•
새로운 서술어를 데이터베이스에 전달하는 규칙을 정의한다.
◦
서술어는 데이터나 다른 규칙으로부터 파생된다.
•
시스템이 :- 연산자의 오른편에 있는 모든 서술어의 대응을 찾으면 규칙이 적용된다.
◦
규칙이 적용될때 :-의 왼편이 데이터베이스에 추가된다.
정리
•
역사적으로 데이터를 하나의 큰 트리로 표현하려고 노력했지만 다대다 관계를 표현하기에는 트리 구조가 적절하지 않았음
◦
이 문제를 해결하기 위해 관계형 모델이 고안됨
•
최근에는 관계형 모델도 적합하지 않은 애플리케이션이 있다고 발견되어 새롭게 NoSQL이 등장함
◦
문서 데이터베이스는 데이터가 문제 자체에 포함돼 있으며 하나의 문서와 다른 문서간 관계가 거의 없는 사용 사례
◦
그래프 데이터베이스는 문서 데이터베이스와는 정반대로 모든 것이 잠재적으로 관련 있다는 사용 사례
