관계형 모델과 문서 모델

관계형 데이터베이스의 근원은 비즈니스 데이터 처리에 있다. 이것은 보통 트랜잭션 처리, 일괄처리 등이다. (오늘날 일반적인)

관계형 데이터베이스와 비관계형 데이터스토어가 함께 사용되는 것을 다중 저장소 지속성(polyglot persistence)이라고 한다.

객체 관계형 불일치

데이터를 관계형 테이블에 저장하려면 애플리케이션 코드와 DB모델 객체 사이에 전환 계층이 필요하다. 하이버네이트 같은 ORM 프레임워크가 코드양을 줄여주긴 하지만 그 차이를 완벽히 없앨 순 없다.

JSON 표현은 관계형 데이터베이스에서 여러 테이블을 참조하여 하나의 정보를 만드는 구조보다 더 나은 지역성을 갖는다. (관계형 DB는 여러 하위 테이블 간 다중 조인을 수행해야 하지만, JSON 표현은 모든 정보가 한 곳에 모여있다.)

다대일과 다대다 관계

ID나 텍스트 문자열 저장 여부는 중복의 문제다. 텍스트를 직접 저장하면 그것을 사용하는 모든 곳에서 똑같이 저장해야해서 중복으로 저장하게 된다. 데이터가 변경되었을 때 모든 중복된 정보들도 같이 변경해줘야 한다 (쓰기 오버헤드, 정보 불일치 위험). ID로 저장하면 값을 변경해도 ID는 동일하게 유지할 수 있다.

중복된 데이터를 정규화하려면 다대일 관계가 필요한데, 이는 문서 모델에 적합하지 않다.

역사

과거에 사용되던 계층 모델의 한계를 해결하기 위해 나온 것이 관계형 모델, 네트워크 모델.

• 네트워크 모델 최상위 레코드부터 연속된 연결 경로를 따르는 접근 경로를 찾아야 한다. 코드가 복잡해지고 알맞는 경로가 없다면 상황이 어려워진다.
  
• 관계형 모델 관계형 데이터베이스에는 쿼리 최적화기가 있어, 쿼리의 어느 부분을 어떤 순서로 수행할지 결정하고, 사용할 색인을 자동으로 결정한다. 이는 네트워크 모델의 접근 모델과 같은데, 차이점은 접근 경로를 네트워크 모델에서는 개발자가 직접 만들고, 관계형 모델에서는 쿼리 최적화기가 자동으로 만든다는 점이다.
  

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

• 문서 모델을 선호하는 이유 스키마 유연성, 지역성에 기인한 더 나은 성능, 일부 애플리케이션에서 데이터 구조와 더 유사함
  
• 관계형 모델 조인, 다대일, 다대다 관계를 더 잘 지원
  

어떤 데이터 모델이 코드를 더 간단하게 할까?

애플리케이션 데이터가 문서와 비슷한 구조라면 문서 모델을 사용.

애플리케이션에서 다대다 관계를 사용한다면 문서 모델은 별로.

어떤 모델이 더 간단하게 만든다고 일반화해서 말할 순 없음. 데이터 간에 존재하는 관계 유형에 따라 다름. 상호 연결이 많은 데이터의 경우, 문서 모델 < 관계형 모델 < 그래프 모델

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

문서 데이터베이스는 스키마리스로 불리지만, 이는 오해의 소지가 있음. 암묵적인 스키마가 있지만 데이터베이스가 이를 강요하지 않음.

관계형 데이터베이스는 쓰기 스키마, 문서 데이터베이스는 읽기 스키마다.

읽기 스키마는 런타임 타입 확인과 유사, 쓰기 스키마는 컴파일 타임 타입 확인과 유사.

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

관계형 데이터베이스는 JSON을 지원하고, 문서 데이터베이스는 조인과 유사한 것을 지원하면서 서로 점점 비슷해지고 있다.

데이터를 위한 질의 언어

웹에서의 선언형 질의

SQL은 선언형 질의 언어. (선언형 ↔ 명령형)

선언형 질의 언어는 목표를 달성하기 위한 방법이 아니라, 결과가 충족해야 하는 조건과 데이터를 어떻게 변환할지를 지정하기만 하면 된다. (구체적인 실현 방법은 쿼리 최적화기가 함)

선언형 언어는 병렬 실행에 적합하기도 함.

맵 리듀스 질의

맵리듀스는 많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델.

맵리듀스는 선언형과 명령형의 중간 정도.

몽고DB는 맵리듀스 기능을 지원한다. 몽고DB의 map, reduce 함수는 순수 함수여야 한다. (순수 함수는 입력으로 전달된 데이터만 사용, 추가적인 데이터베이스 질의 수행할 수 없음, 부수 효과 없어야 함)

몽고DB는 aggregation pipeline라는 선언형 질의 언어를 추가했다. (쿼리 최적화기가 쿼리 성능을 높일 수 있게 하기 위함)

그래프형 데이터 모델

관계형 모델은 단순히 다대다 관계를 다룰 수 있지만 데이터 간 연결이 더 복잡해지면 그래프로 데이터를 모델링하기 시작하는 편이 더 자연스럽다.

그래프는 정점(노드나 엔티티), 간선(관계나 호)라는 두 유형의 객체로 이ㅜ러진다.

그래프는 동종 데이터에 국한 되지 않고, 그래프를 동종 데이터와 마찬가지 방식으로 사용하면 단일 데이터 저장소에 완전 다른 유형의 객체를 일관성있게 저장할 수 있다.

속성 그래프

• 정점을 구성하는 요소
  1. 고유한 식별자
  2. 유출 간선 집합
  3. 유입 간선 집합
  4. 속성 컬렉션 (키-값 쌍)
• 간선을 구성하는 요소
  1. 고유한 식별자
  2. 간선이 시작하는 정점
  3. 간선이 끝나는 정점
  4. 두 정점 간 관계 유형을 설명하는 레이블
  5. 속성 컬렉션 (키-값 쌍)
• 속성 그래프의 중요한 면
  1. 정점은 다른 정점과 간선으로 연결된다.
  2. 정점이 주어지면 정점의 유입, 유출 간선을 효율적으로 찾을 수 있고, 그래프를 순회할 수 있다.
  3. 다른 유형의 관계에 서로 다른 레이블을 사용하면 단일 그래프에 다른 유형의 정보를 저장하면서 데이터 모델을 깔끔하게 유지할 수 있다.

사이퍼 질의 언어

사이퍼는 속성 그래프를 위한 선언형 질의 언어

(Idaho) -[:WITHIN:]→ (USA) 와 같이 노드와 간선을 나타낸다.

SQL의 그래프 질의

그래프 데이터를 관계형 구조로 넣어도 SQL을 사용해 질의할 수는 있지만, 그래프를 위한 질의 언어보다 훨씬 많은 질의를 작성해야 한다. 애플리케이션에 적합한 데이터 모델을 선택하는 것이 중요하다.

트리플 저장소와 스파클

트리플 저장소에는 모든 정보를 주어, 서술어, 목적어처럼 매우 간단한 세 부분 구문 형식으로 저장한다.

스파클 질의 언어

스파클은 RDF 데이터 모델을 사용한 트리플 저장소 질의 언어

초석: 데이터로그

사이퍼와 스파클은 SELECT로 바로 질의하는 반면, 데이터로그는 단계를 나눠 한 번에 조금씩 질의로 나아간다. 먼저 새로운 서술어를 데이터베이스에 전달하는 규칙을 정의한다.