데이터 중심 애플리케이션 설계 - 2(데이터 모델과 질의 언어)

2장. 데이터 모델과 질의 언어

데이터 모델은 소프트웨어 개발에서 가장 중요한 부분이다. SW가 어떻게 작성됐는지 뿐만 아니라 해결하려는 문제를 어떻게 생각해야 하는지 영향을 미치기 때문이다.

대부분의 애플리케이션은 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 둬서 만든다.

2장에서 중요한 내용
- 범용 데이터 모델 비교(관계형 모델, 문서 모델, 그래프 기반 데이터 모델)
- 여러 질의 언어와 사용 사례

관계형 모델과 문서 모델

가장 잘 알려진 데이터 모델은 1970년 에드가 코드가 제안한 관계형 모델으로한 SQL이다. 관계(relation)(=테이블)로 구성 되고 튜플(tuple)(=로우)의 모임.

관계형 데이터베이스의 근원은 비즈니스 데이터 처리에 있다. -> 트랜잭션 처리, 일괄 처리
관계형 모델의 목표는 정리된 인터페이스 뒤로 구현 세부 사항을 숨기는 것이다.

NoSQL의 탄생

NoSQL은 약 30년간 지속된 관계형 모델의 우위를 뒤집으려는 가장 최신의 시도이며 NoSQL은 어떤 기술이 아닌 Not Only SQL로 해석됨.
NoSQL 데이터베이스를 채택하게 된 원동력
- 대규모 데이터셋이나 많은 처리량 달성을 쉽게 하기 위한 확장성 필요
- 무료 오픈소스 소프트웨어 선호도 증가
- 관계형 모델에서 지원하지 않는 특수 질의
- 관계형 스키마에 제한에 따르지 않는 모델

객체 관계형 불일치

객체지향 프로그래밍 언어 애플리케이션에서 데이터를 관계형 테이블에 저장하려면 둘 사이에 전환 계층 필요 -> 임피던스 불일치(impedance mismatch) 

모든 내용을 갖추고 있는 데이터 구조는 문서이기 때문에 JSON표현에 적합하다. -> 문서 지향 데이터베이스(document-oriented)

다대일과 다대다 관계

중복된 데이터를 정규화하려면 다대일 관계를 사용한다.(문서 모델과 적합하지 않음 -> 조인 지원 약함)
애플리케이션의 데이터는 개발되면서 상호 연결되는 경향이 있다.(다대일, 다대다 필요성)

---

과거 IBM의 데이터모델 IMS의 설계는 계층 모델 사용

문서 데이터베이스 JSON 모델과 유사했다. 다대다 관계 표현의 문제를 해결하기 위한 해결책 두가지는 관계형 모델(SQL)과 네트워크 모델이었다. 

네트워크 모델(=코다실 모델)

계층 모델을 일반화 하며, 계층 모델 트리 구조에서 모든 레코드는 하나의 부모가 있지만 네트워크 모델에서는 다중 부모가 있을 수 있다.
접근 경로는 최상위 레코드에서부터 연속된 연결 경로를 따르는 방법.
문제는 다른 경로가 같은 레코드로 이어질 수 있고 프로그래머가 경로의 맨 앞에서 접근 경로를 계속 추적해야함.

관계형 모델(SQL)

관계형 모델이 하는 일은 알려진 모든 데이터를 배치하는 것이다. 튜플(로우) 컬렉션이 전부이며 복잡한 접근 경로가 없다.
질의 최적화기(query optimizer)가 최적의 접근 경로를 만들어준다.

---

문서 모델과 계층 모델의 비교

문서 모델과 계층 모델의 공통점
- 별도 테이블이 아닌 상위 레코드 내에 중첩된 레코드(ex. 지역, 교육사항 등)를 저장한다.

문서 모델과 관계형 모델의 공통점
- 다대일과 다대다 관계 표현 시 관련 항목은 고유한 식별자로 참조한다.
  -> 관계형 모델 = 외래 키(foreign key)
  -> 문서 모델 = 문서 참조(document reference)
- 조인이나 후속 질의를 사용해 읽기 시점에 확인
- 문서 모델은 코다실 모델의 전철을 밟고 있지 않음.

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

관계형 데이터베이스와 문서 데이터베이스의 차이
  1. 내결함성(5장 참고), 동시성 처리(7장 참고)
  2. 데이터 모델에서의 차이점
    - 문서 데이터 모델: 스키마 유연성, 지역성(성능), 애플리케이션 데이터 구조와 가까움
    - 관계 데이터 모델: 조인, 다대일, 다대다 관계 지원 높음

데이터 항목 관계 유형에 따라 어떤 모델이 나은 지 판단 필요

- 데이터가 문서와 비슷한 구조일 경우(일대다 구조) -> 문서 모델 사용
  -> 여러 테이블로 나누어 찢는(shredding) 관계형 기법은 스키마와 복잡한 애플리케이션 코드 발생됨
- 정규화된 데이터(다대일, 다대다 관계 사용 구조) -> 관계 모델 사용 ··· 조인 강점
- 상호 연결이 많은 데이터 -> 그래프 모델(or 관계 모델) 사용

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

스키마 강요
- JSON(문서형, 관계형): 스키마 강요 X
- XML(관계형): 스키마 유효성 검사 포함 가능
  ※ 스키마가 없다는 뜻은 임의의 키와 값을 문서에 추가할 수 있고 읽을 때 필드의 존재 여부를 보장하지 않는다는 의미

쓰기 스키마(schema-on-write): 관계형 DB의 접근 방식으로 스키마를 명시하고 DB는 스키마를 따른다.(정적)
읽기 스키마(schema-on-read): 데이터 구조는 암묵적이며 데이터를 읽을 때 해석한다.(동적)

질의를 위한 데이터 지역성

웹 상에 문서를 보여주는 동작처럼 애플리케이션이 자주 전체 문서에 접근 시 저장소 지역성(Storage location)을 활용하여 성능 향상
필요 부분이 작을 때 큰 문서를 접근하는 경우 낭비(문서 전체를 적재하기 때문) -> 문서를 작게 유지, 문서 크기 증가하는 쓰기 지양

지역성 특성을 가진 관계 DB
- 구글, 스패너(Spanner)
- 오라클, 다중 테이블 색인 클러스터 테이블(multi-table index cluster table)

관계형 데이터베이스와 문서 데이터베이스는 시간이 지남에 따라 서로 비슷해지고 있다.

 데이터를 위한 질의 언어

관계형 모델이 등장하면서 데이터 질의 방법도 새로 등장

모델에 따른 질의언어
1. 선언형 질의언어 -> SQL, 관계대수
  - 목표를 달성하기 위한 방법이 아닌 결과가 충족해야 하는 조건과 데이터를 어떻게 변환(정렬, 그룹화 등)할지 지정
  - 명령을 실행할 때 접근 경로는 질의 최적화기(query optimizer)가 결정
  - 명령형 언어보다 간결하게 작업할 수 있고 상세 구현이 숨겨져있어 질의를 변경하지 않고 성능 향상 가능
  - 병렬 실행에 적합

2. 명령형 코드 질의언어 -> IMS(계층 모델), 코다실(네트워크 모델), 프로그래밍 언어
  - 특정 순서로 특정 연산을 수행하도록 컴퓨터에게 지시
  - ex) 한줄씩 단계별 실행하여 조건을 평가하고 변수를 갱신하고 루프를 더 실행할지 여부 결정

웹에서의 선언형 질의

선언형 질의의 장점은 데이터베이스에만 국한되지 않는다. -> 웹 CSS, XSL
명령형 접근방식은 JavaScript 코어 DOM(Document Object Model) API

맵리듀스 질의

맵리듀스(MapReduce)는 많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델
map(collect)과 reduce(fold, inject) 함수를 기반으로 하며, 선언형 질의와 명령형 질의의 중간 정도 모델
몽고DB와 카우치DB 등 일부 NoSQL 데이터베이스에서 맵리듀스를 지원한다.

그래프형 데이터 모델