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

서론

애플리케이션을 설계하는 데 있어서 사용자들이 선택할 수 있는 다양한 선택지가 존재하고 있다. 이러한 데이터 모델을 이해하고, 애플리케이션에 적절한 데이터 모델을 선택하는 것이 중요하다.

관계형 모델과 문서 모델

오늘날 가장 많이 알려지고 사용되고 있는 모델이 관계형 모델이다. Oracle, MySQL 등 사용자들이 가장 많이 접하고 있는 형태라 가장 익숙할 것이다.
이렇게 오랫동안 우세한 관계형 모델에 우위를 점하기 위해 가장 최신시도가 바로 NoSQL이다.
관계형 모델을 사용하면서 불편하다고 느꼈던 점들이 문서 모델에서는 해결이 되어 혁신적이라고 생각할 수도 있다.
하지만 문서 모델을 사용하다보면 관계형 모델에서 느꼈던 장점들이 부족하거나 없는 것들을 발견할 수도 있다.
이렇듯 관계형 모델과 문서 모델은 각 각 장점이 있다. 이러한 두 모델이 어떠한 것이 더욱 우월하다기 보다는 특정 상황에 적합하다라는 표현이 더 적합하다고 보여진다.
따라서 상황에 맞게 관계형 모델과 문서 모델을 조합해서 사용하는 것이 중요하다.

이 책에서 또한 임피던스 불일치라는 용어가 등장한다.
일대다 관계에서 관계형 데이터베이스는 개별테이블에 데이터를 넣고 사용하는 형태를 취하거나, 보통 좋지 못한 방법이지만 하나의 컬럼에 리스트와 같은 형식으로 데이터를 저장하기도 한다.
하지만 문서 모델 같은 경우에는 JSON과 XML 과 같은 형식으로 더 나은 지역성을 가지게 된다는 장점이 있다.

JSON과 XML이 이 책에 나오고 있는데, 두 가지 모두 결국 데이터를 저장하고 전달하기 위해서 고안되었고, 모두 기계와 사람이 쉽게 읽을 수 있는 형태를 가지고 있다.
하지만 JSON 데이터가 XML 보다 더 읽고 쓰기가 편하고, JSON의 구문과 XML 의 구문이 더 짧은 등 JSON이 최근에는 많이 쓰이고 있다.
레거시에서 주로 보이는 XML을 직접 접한다면 물론 읽고 쓰는 데에 무리가 없을 것이지만, JSON으로 변경하고 싶은 욕구가 스멀스멀 생길 것이라고 생각한다. (글쓴이가 그랬음)

XML
<dog>
    <name>식빵</name>
    <family>웰시코기<family>
    <age>1</age>
    <weight>2.14</weight>
</dog>

JSON
{
    "name": "식빵",
    "family": "웰시코기",
    "age": 1,
    "weight": 2.14
}

위에서 언급한대로 문서 모델에 장점만 있지는 않다. 다대일과 다대다 관계를 나타내는 부분에서 문서 모델의 부족한 점을 발견할 수 있다.
중복된 데이터를 정규화하는 데에는 다대일 관계가 필요한데, 이러한 부분에서 문서 모델은 조인 대한 지원이 약하기 때문에 애플리케이션 단에서 다중 질의를 만들어 조인을 흉내내야 한다.

책에서는 네트워크 모델에 관한 내용도 나오고 있다. 1970년대 관계형 모델과 네트워크 모델 두가지가 주된 계층 모델의 한계의 해결책으로 논쟁이 이뤄지고 있었다고 한다.
하지만 수동 접근 경로 선택이라는 네트워크 모델의 특징은 데이터 베이스 질의와 갱신을 위한 코드가 복잡하고 유연하지 못한 문제가 있었고, 계층 모델과 비슷하게, 원하는 데이터에 대한 경로가 없다면 어려움이 발생할 수 있다는 문제를 가지고 있다.
관계형 모델도 접근 경로를 가지고 있지만 네트워크 모델과는 다르게 질의 최적화기가 이러한 접근 경로를 자동으로 만들어서 따로 접근 경로에 대해 고려하지 않아도 된다는 차이점을 가지고 있다.

결국 문서 데이터 모델을 선호하는 이유는 스키마 유연성, 지역성에 기인한 더 나은 성능, 관계형 모델은 조인, 다대일, 다대다 관계를 더 잘 지원한다는 특징들을 가지고 있다.
이러한 특징들을 잘 고려해서 상황에 적절한 모델을 선택, 사용을 하는 것이 적절하다.
최종적으로는 관계형 모델과 문서 데이터 모델의 혼합하는 것이 적절하다고 말하고 있다.

책에서 큰 테이블을 업데이트 시키는 내용이 나오고 있다.
해당 부분에서는 다음과 같은 방법으로 UPDATE를 대신해 first_name을 널(NULL) 값으로 설정하고, 읽는 시점에 값을 채워넣도록 하는 방법을 설명하고 있다.
하지만 해당 부분에서도 고민할 점이 있는 것 같다.

1. 대부분의 값들이 채워졌을 경우에도 해당 로직은 어떻게 할 것인지
2. 중단 하는 시간과 추가적인 로직이 반복적으로 동작하는 것 중 어느 것이 더 주어진 상황에서 적절한가 
3. 작성한 로직을 제거하기 위해서는 아직 채워지지 않은 값들을 채워넣어야하지 않을까

데이터를 위한 질의 언어

SQL에서 사용하는 선언형과 코다실에서 사용하는 명령형 언어가 있다.
일반적으로 프로그래밍 언어는 명령형 언어이고, 우리가 주로 사용하는 SQL은 선언형 언어이다.
선언형 질의 언어는 목표를 달성하기 위한 방법이 아니라 알고자 하는 데이터의 패턴에 대해 집중하고 있다.

책에서는 맵리듀스 질의에 대해서도 설명을 하고 있다. 사실 맵리듀스는 대용량 데이터 처리에 관해서 조금 관심을 가져봤다면 많이 들어봤을 것이라고 생각이 된다.
맵리듀스는 구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작되었고, 이러한 개념을 오픈소스화 한 것이 우리가 잘 알고 있는 하둡이다.
간단하게 맵리듀스는 큰 덩어리를 작게 나누고, 여러 컴퓨터에서 데이터를 각 각 처리한 후 해당 데이터들을 모아서 결과물을 내는 방식이다.

그래프형 데이터 모델

처음에 해당 부분을 읽으면서 든 생각은 트리도 결국 그래프 아닌가? (물론 다른 특징을 가지고 있지만) 하는 생각이었다.
하지만 책에서 나온 질의나 그림들을 보면서 그래프형 데이터 모델은 결국 가지각색인 노드들을 저장하고 싶다는 것으로 부터 기반한 것이라고 느껴졌다.
관계형 데이터베이스에서는 질의에 필요한 조인들을 미리알고 있어야하기 때문에 그래프 질의와 같이 여러 간선을 순회하는 경우에는 조인 수를 고정할 수 없다.
그래프형 데이터 모델은 발전성이 좋아 애플리케이션에 기능을 추가하는 경우에도 데이터 구조 변경을 수용하여 그래프를 쉽게 확장할 수 있다는 장점이 있다.

책에서는 트리플 저장소와 스파클에 대해서도 나와있다. 트리플 저장소에서는 모든 정보를 주어, 서술어, 목적어 처럼 매우 간단한 세 부분 구문으로 저장을 한다.
해당하는 부분은 읽기에는 쉬워 보이는 장점이 있다고 나와있으나, 나에게는 익숙하지 않은 형태인 것 같아서 읽기 쉽다라는 느낌을 받지는 못했다.

시맨틱 웹은 웹 사이트는 이미 사람이 읽을 수 있는 텍스트와 그림으로 정보를 게시하고 있으니 컴퓨터가 읽을 수 있게 판독 가능한 데이터로도 정보를 게시하는 건 어떨까하는 개념이라고 한다. 이렇게 서로 다른 웹 사이트가 일관된 형식으로 데이터를 게시하기 위한 방법으로 RDF를 제안했다고 한다.
하지만 어지러운 약어의 과잉 지나치게 복잡한 표준 제안, 자만심등으로 인해 어려움을 겪었다고 한다.
이러한 RDF 데이터 모델을 사용한 트리플 저장소 질의 언어가 스파클 질의 언어라고 한다.

마지막으로 데이터로그는 1980년대에 탄생된 오래된 언어로 질의 언어의 기반이 되는 초석이라고 한다.
데이터로그는 트피플 저장소 모델과 유사하지만 조금 더 일반화된 주어 목적어 형식으로 작성한다.
사이퍼나 스파클과는 다르게 데이터로그는 단계를 조금씩 나눠서 질의하는 형태로 나아간다.

정리

해당 장에서는 여러 데이터 모델과 질의에 대해 설명해주고 있다. 각 데이터 모델들은 서로 다른 특징들을 가지고 있다. 그래서 여러 데이터 모델에 대해 이해를 하고 상황에 맞는 데이터 모델을 사용해야한다는 것을 계속해서 말하고 있는 것 같다.