02장: 데이터 모델과 질의 언어

[LOG-INFO]

끄적끄적

전체적으로 관계형DB vs 문서형DB vs GraphDB의 특징들과 각각의 비교를 나타내었다. (+ 네트워크모델도 소개함)

이전에 한 때 문서형 DB(중에서 MongoDB)에 흥미가 생겨 사이드 프로젝트에 MongoDB를 적용하였다가 나중에 후회한 경험이 생각났다. 해당 프로젝트는 다대다구조가 많았는데, 데이터가 각 문서에 중복으로 저장되다보니 한 데이터가 변경될 때마다 해당 데이터가 포함된 문서들을 모두 변경해주어야 했다. 그 이후로는 문서형 DB는 schema-on-write가 필수가 아닌 경우에만 사용하는 것으로.... (+ 쿼리도 상당히 복잡해서 거부감 들었음. SQL 짱짱이라는 걸 느낌. 안 익숙해서 그렇다기엔 약간 무리가 있어보임...)

GraphDB는 나중에 기회가 되면 한 번 사용해보고 싶다. 지도나 SNS 같은 서비스를 해야 도입해볼만 할 듯.

궁금한 점

• 40p. 대부분의 관계형 데이터베이스 시스템은 ALTER TABLE 문을 수 밀리초 안에 수행한다. 마이SQL은 상당히 예외적이다.

  • MySQL만 그런 것인가? 수 ms 안에 수행하는 DB는 어떤거지? Oracle도 오래 걸렸음

[MinJunKweon]

느낀점

• RDB가 정말 범용적으로 잘쓰이는 이유를 알게됨
• 지금도 문서형 DB를 사용하고 있는데, 이렇게 설계된 이유를 대충이나마 알게됨
• 조상님들은 역시 모든걸 고려했구나..

---

정리

• 데이터 저장과 질의를 위한 다양한 범용 데이터 모델을 살펴봄

관계형 모델과 문서 모델

• 관계형 모델
  • 데이터는 관계(Relation)로 구성되고 각 관계는 순서 없는 튜플(Tuple) 모음
  • 1980년대 중반에 RDBMS과 SQL로 정규화된 구조로 데이터를 저장하고 질의할 피룡가 있는 사람들 대부분이 선택하는 도구가 됐음
  • RDBMS는 비즈니스 데이터 처리에 적합함
    • 트랜잭션 처리와 일괄처리로 일상적으로 수행됨

NoSQL의 탄생 배경

• 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 RDB보다 쉽게 할 수 있는 확장성의 필요
• 상용 DB 제품보다 무료 오픈소스에 대한 선호도 확산
• RDB에선 지원하지 않는 특수 질의 동작
• 관계형 스키마의 제한에 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

객체 관계형 불일치

• 대부분 애플리케이션은 OOP로 개발됨
• SQL 데이터 모델과 OOP 객체 사이에는 전환 계층이 필요해짐
• ORM 프레임워크를 통해 전환 계층의 보일러플레이트 코드를 줄일 수 있지만 모델 간의 차이를 완벽히 대응시킬 수는 없음
• 이력서 같은 데이터 구조는 모든 내용을 갖추고 있는 문서이기 때문에 JSON으로 표현하기 적합함
• JSON은 XML에 비해 훨씬 간단하기 때문에 문서 지향 DB는 JSON 데이터 모델을 지원함
• JSON은 1대다 관계는 Array나 Map 형태로 표현할 수 있어서 문서 자체만으로 표현이 가능하다.
  • RDB의 경우 다른 테이블을 참조해야하는 등 복잡함
• 문서형 DB(e.g. MongoDB)들은 DB 자체에서 조인에 대한 지원을 잘 해주지 않기 때문에 다대일 / 다대다 관계를 표현할 때 불편함
  • 데이터를 문서 자체에 저장하기 때문에 locality가 증가함 (데이터 중복)
• 초기엔 Join-Free 문서 모델에 적합하더라도 점점 기능을 추가하면 상호 연결되는 경향이 있음
• 결국 다중 질의를 만들어서 애플리케이션에서 조인을 흉내내게됨

문서형 DB는 역사를 반복하고 있나?

• IBM의 정보 관리 시스템(IMS)는 오늘날의 JSON 구조와 마찬가지로 모든 데이터를 레코드 내에 중첩된 레코드 트리로 표현했음
• IMS는 다대다 관계 표현은 어려웠고 조인은 지원하지 않았음
• 개발자는 데이터를 중복할지 한 레코드와 또 다른 레코드의 참조를 수동으로 해결할지 결정했음
  • ⇒ 이 고민을 한게 1960년대, 1970년대 였는데, 지금도 이 고민을 하고있음
• 이걸 해결하기 위해 관계형 모델과 네트워크 모델이었음

네트워크 모델

• 코다실(CODASYL) 모델이라고도 불림
• 네트워크 모델에서 레코드는 다중 부모가 있을 수 있음
  • C언어의 포인터와 비슷함
  • root로 부터 연속된 연결 경로를 따르는 방법. (접근 경로)
• 이런 방식은 매우 제한된 하드웨어 성능을 효율적으로 사용할 수 있었지만, DB 질의와 갱신을 위한 코드가 복잡하고 유연하지 못함
  • 애플리케이션 데이터 모델을 바꾸는 작업이 매우 어려워짐

관계형 모델

• 알려진 모든 데이터를 배치하는 것
• 복잡한 접근 경로 없이 임의 조건과 일치하는 테이블의 일부를 선택해서 읽을 수 있음
• 다른 테이블과 신경쓰지 않고 임의 테이블에 새로운 레코드를 추가할 수 있음
• 쿼리 옵티마이저를 통해 자동으로 어떤 순서로 어떤 색인을 사용할지 결정함. (접근 경로 역할)
• 자동으로 효율적인 접근 경로를 찾으므로 범용 솔루션에 유리함

문서 DB와의 비교

• 문서 DB는 관계형 모델과 달리 상위 레코드 내에 중첩된 레코드를 저장함
• 다대일 관계과 다대다 관계를 표현할 때, RDB는 외래 키(Foreign Key)를 사용하고 문서 DB는 문서 참조(Document Reference)를 사용할 뿐 근본적으로 같다.
• 문서 참조는 읽기 시점에 다른 문서를 참조하므로 코다실과는 방식이 다르다.
  • 따라서, 역사를 반복하고 있지 않다.

관계형 데이터 모델과 문서 데이터 모델

• 문서 데이터 모델은 일대다 관계 트리로 보통 한번에 전체 트리를 적재하는 모델에 사용하는 편이 좋다.
• 문서가 여러번 깊게 중첩되지 않으면 일반적으로 문제가 되지 않는 방식

• 하지만, 애플리케이션에서 다대다 관계를 사용한다면 문서 모델은 적합하지 않음

  • 비정규화로 조인의 필요성을 줄일 수 있지만, 일관성을 유지하기 위해 추가적으로 작업해야함

  수정이 일어났을 때 관련된 모든 문서를 수정해야함.

  • 조인을 사용하려면 애플리케이션에서 흉내를 내야해서 복잡도가 증가함 (DB보다 성능이 떨어지는 것은 덤)

• 문서 데이터 모델은 JSON 형태로 저장하기 때문에 스키마 유연성을 가짐
  • 읽기와 쓰기 작업에서의 스키마가 암묵적으로 존재함
  • 스키마가 특별히 정해져있지 않기 때문에 정적 타입에 비해서 마이그레이션이 쉬움
• 문서 데이터 모델은 지역성이 보장됨.
  • 하나의 문서만 찾아도 연관된 부분을 찾기 위해 다른 테이블을 참조할 필요가 없음(디스크의 다른 부분을 찾을 필요가 없음)
• 문서 데이터 모델은 지역성이 보장될 수 있으나, 문서 크기가 크면 오히려 손해가 될 수 있음
  • 작은 한 부분을 찾기 위해서 거대한 문서를 참조해야하는 등의 문제가 발생가능
  • 문서 크기를 작게 유지하는 걸 권장하고 있음

데이터 질의 언어

• ‘데이터를 어떻게 요청할 것인지’에 대한 언어
• 명령형 언어
  • 일반적인 프로그래밍 언어
  • 특정 순서로 특정 연산을 수행하게끔 지시하는 언어
  • 한 줄씩 실행하고 조건을 평가(evaluation)해서 변수를 갱신하는 등등..
• 선언형 언어(SQL)
  • 목표를 달성하기 위한 방법이 아니고 알고자 하는 데이터의 패턴
  • 결과가 충족해야 하는 조건과 데이터를 어떻게 변환할지 지정하는 방식
  • 상세 구현이 숨겨져 있어서 쿼리를 변경하지 않고 DB 시스템의 성능을 향상시킬 수 있음
  • 병렬 실행에 적합함. 명령형 언어는 순서가 보장되어있기 때문에 다중 코어나 다중 장비에서 다루기 어려움

웹에서의 선언형 질의

• 웹에서 선언형 / 명령형 둘다 사용가능함
  • 선언형 : CSS Selector, XPath 표현식 등등
  • 명령형 : Javascript에서 Core DOM API를 사용해서 렌더링하는 방식

맵리듀스 질의

• 선언형과 명령형 질의 사이에 있음
• map과 reduce를 사용해서 데이터를 처리함
  • map으로 데이터를 emit하고
  • reduce로 데이터를 묶어서 처리함
• MongoDB에서도 제한적으로 map, reduce를 지원하고 있음. 하지만 몇가지 제한사항이 있음
  • 두 함수는 순수 함수여야함.
    • 입력으로 전달된 데이터로만 처리가 되어야함. 함수 내에서 외부에 접근 X. 사이드 이펙트 방지
  • 따라서, 임의 순서로 언제 어디서나 실행 가능함이 보장됨 (분산 처리에 특화)
• 맵 리듀스는 순수 함수여야한다는 점 때문에 사용이 어려움.
  • 오히려 쿼리를 작성하는 것보다 함수 작성이 어려울 정도
• MongoDB에서는 이 점을 보완하고자 aggregation pipeline 기능을 지원함
  • 선언되는 순서대로 데이터를 처리하는 방식을 기술함 (파이프라인 형태)

그래프형 데이터 모델

• 다대다 관계가 다양한 데이터 모델을 구별하는 중요한 기능임
• 다대다 관계가 많은 경우 그래프형 데이터 모델이 적합할 수 있음
• 정점과 간선으로 나눠서 많은 유형의 데이터를 그래프로 모델링 가능

속성 그래프

• 정점과 간선을 구성하기 위해 그래프 저장소를 사용함.
  • 그래프 저장소는 RDB도 될 수 있고, 문서형 DB도 될 수 있음
• 정점은 다른 정점과 간선으로 연결됨
• 정점이 주어지면 정점의 유입과 유출 간선을 효율적으로 찾을 수 있고 그래프를 순회할 수 있음.
  • 일련의 정점을 따라 앞뒤 방향으로 순회 가능
• 다른 유형의 관계에 서로 다른 레이블을 사용하면 단일 그래프에 다른 유형의 정보를 저장하면서도 데이터 모델을 깔끔하게 유지 가능

사이퍼 질의 언어

• 사이퍼(Cypher)는 속성 그래프를 위한 선언형 질의 언어로, Neo4j 그래프 DB용으로 만들어짐
• 모든 정점과 간선을 DB에 추가하면 쿼리를 수행할 수 있음.
  • e.g. 미국에서 유럽으로 이민 온 모든 사람들의 이름 찾기
    • 해석) born_in 간선을 가진 정점과 유럽 내 위치의 living_in 간선을 갖는 모든 정점을 찾아서 name 속성을 반환
• 이는 선언형 질의 언어로 구현 가능함

MATCH
  (person) -[:BORN_IN]-> () -[:WITHIN*0..]-> (us:Location {name:'United States'}),
  (person) -[:LIVES_IN]-> () -[:WITHIN*0..]-> (eu:Location {name:'Europe'})
RETURN person.name

SQL의 그래프 질의

• SQL로도 위처럼 그래프 데이터 모델을 선언형으로 질의할 수 있지만 약간 어려움
• 일반적인 SQL로는 힘들고 WITH RECURSIVE 문을 통해 표현 가능함

트리플 저장소와 스파클

• 트리플 저장소 모델은 속성 그래프 모델과 거의 동등함.
• 주어(subject), 서술어(predicate), 목적어(object)로 나눈 형식으로 저장함
• 저장된 정보를 토대로 찾게됨
• 시멘틱 웹과 독립적이지만, 많은 사람들이 시멘틱 웹과 매우 밀접한 관계가 있다고 생각함
  • 웹은 이미 사람이 읽을 수 있는 텍스트와 그림으로 정보를 게시하고 있으니 컴퓨터가 읽게끔 기계가 판독 가능한 데이터로도 정보를 게시하는 건 어떨까라는 개념
  • RDF 프레임워크를 통해 서로 다른 웹사이트가 일관된 형식으로 데이터를 게시하는 방법을 제안함
  • 하지만, 현실에서 실현된 흔적이 없음. 실패한 프로젝트
• RDF 데이터 모델은 인터넷 전체의 데이터 교환을 위해 설계했기 때문에 이상한 점이 있음
  • 트리플의 주어, 서술어, 목적어는 주로 URI임
  • 다른 사람의 데이터와 결합할 수 있어야 하기 때문에 URI일 수 있음
• 스파클(SPARQL)은 RDF 데이터 모델을 사용한 트리플 저장소 질의 언어
  • 사이퍼와 매우 흡사함

그래프 DB와 네트워크 모델의 비교

• 네트워크 모델은 다른 레코드 타입과 중첩 가능한 레코드 타입을 지정하는 스키마가 있음
  • 그래프 DB에는 제한이 없음. 모든 정점은 다른 정점으로 가능 간선을 가질 수 있음
• 네트워크 모델에서 특정 레코드에 도달하는 유일한 방법은 root를 통해 레코드의 접근 경로 중 하나를 탐색하는 방식
  • 그래프 DB는 고유 ID를 가지고 임의 정점을 직접 참조하거나 색인을 사용해 특정 값을 가진 정점을 빠르게 찾을 수 있음.
• 네트워크 모델에서 레코드의 하위 항목은 정렬된 집합이므로 데이터베이스는 정렬을 유지해야함. 새로운 데이터를 삽입할 때 정렬된 집합에서 새로운 레코드의 위치를 찾아야함
  • 그래프 DB는 정점과 간선을 정렬하지 않음. 질의를 만들 때만 결과를 정렬할 수 있음
• 네트워크 모델에서 모든 질의는 명령형이고 작성이 어려움. 스키마가 변경되면 질의가 쉽게 손상됨
  • 그래프 DB는 사이퍼나 스파클 같은 고수준 선언형 질의 언어를 제공함

[minkukjo]

정리 정리

• 코다실의 네트워크 모델이라는게 무엇인지 머리로 이해가 잘 안되서 이것저것 찾아봄
• 코다실은 Conference/Committee on Data Systems Languages라고 부르며, 프로그래밍 언어 개발의 표준을 만드는 집단이다.
• 이 제안은 1980년대 관계형 데이터베이스가 대두되면서 자연스럽게 잊혀졌다고 한다. (...)

문서 모델과 관계형 모델

• 관계형 모델은 다대다를 표현하기에 적합하지만, 스키마 변경에 취약하다. ( 시간이 오래 걸림 )
• 문서 모델은 다대다를 표현하긴 어렵지만 스키마 변경에 유연하다.
• 결국 개발자가 제어할 수 없고, 언제나 외부 시스템에 의해 데이터 구조가 결정되는 요구사항이라면 문서 모델이 더 적합할 것이다.

질의의 데이터 지역성

• 일반적으로 저장소 지역성을 활용하면 성능 이점이 있다.
• 데이터가 다중 테이블로 나뉘어졌다면 전체를 검색하기 위해 다중 색인 검색이 필요한데, 오라클은 다중 테이블 색인 클러스터 테이블라는 이름으로 이를 제공해준다.

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

• MySQL은 5.7부터, 포스트그레 SQL 9.3부터 JSON에 대한 지원을 한다.
• 특히 포스트그레SQL은 JSON에 강력한 인덱싱 기능도 제공해준다.
• 어느정도의 보장된 성능과 스키마와 트랜잭션이 필요하면서 문서 (JSON)이 필요하다면 포스트그레 SQL이 적합한 대안이 될 것이다.

맵 리듀스 질의

• 대량의 데이터를 처리하기 위한 모델로, 몽고 DB나 카우치 DB가 이를 제공한다.
• 순수함수로 작성된 함수를 통해서 질의를 수행할 수 있다.
• 그러니 모든 데이터 프로세싱을 SQL로 하지 않고 코드로도 가능하며, 엘라스틱 서치는 아예 쿼리 조차도 JSON으로 지원한다.
• 재밌게도 NOSQL이 SQL을 재발견 하고 있다.

[HaeUlNam]

관계형 모델을 기반으로 한 SQL

• 데이터는 Relation으로 구성되고 각 관계는 순서 없는 Row 모음이다.
• 관계형 데이터베이스의 근원은 비즈니스 데이터 처리에 있다. 보통 트랜잭션 처리/일괄 처리

NoSQL

NoSQL 데이터베이스를 채택하는 이유

• 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성의 필요
• 무료 오픈소스 소프트웨어에 대한 선호도 확산
• 관계형 모델에서 지원하기 않는 특수 질의 동작
• 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

객체 관계형 불일치

• 객체 지향 프로그래밍 언어와 데이터베이스 모델 객체 사이의 불일치로 인해 전환 계층이 필요하다. 이런 모델 사이의 분리를 Impedance mismatch라고 부른다. 이걸 지원해주는 것이 Hibernate와 같은 ORM 프레임워크이지만, 두 모델 간의 차이를 완벽히 숨길 수는 없다.
• 일대다를 표현하는 방법
  • 개별 테이블을 생성하고 다중 조인/질의를 통해
  • JSON 표현 - 일대다가 트리 구조를 가지고 있기 때문에
• ID - ID 자체에 아무런 의미가 없다면 변경할 필요가 없다. 즉, 식별 정보를 변경해도 ID는 동일하게 유지할 수 있다.

관계형 데이터베이스 vs 문서 데이터베이스

• 문서 데이터 모델: 스키마 유연성, 지역성에 기반한 더 나은 성능, 애플리케이션에서 사용하는 데이터 구조와 가깝
• 관계형 데이터 모델: 조인, 다대일, 다대다 관계를 더 잘 지원함
• 어떤 데이터 모델이 애플리케이션 코드를 더 간단하게? 데이터가 문서와 비슷한 구조 (일대다 관계)라면, 문서 모델을 사용하는 것이 좋다. 문서와 비슷한 구조를 여러 테이블로 찢으면 불필요한 코드 발생. 하지만 다대다 관계에 대해서는 문서 모델은 다중 조인 또는 이를 흉내내기 위한 복잡도 증가를 불러일으킨다
• 스키마에는 schema-on-write(관계형 데이터베이스의 정적 타입)와 schema-on-read(암묵적이고 읽을 때만 해석)가 존재.
• 문서는 보통 JSON, XML로 부호화된 단일 문자열이나 JSON 또는 XML의 이진 변형으로 저장된다. 이는 storage locality 활용을 가능하게 한다. 데이터가 많은 테이블로 나뉘어져있다면 더 많은 디스크 탐색 등 시간이 소요

데이터를 위한 질의 언어

• SQL과 같은 선언형 질의 언어: 결과가 충족해야 하는 조건과 데이터를 어떻게 변환할지 지정하기만 하면 된다. 더 간결함

그래프형 데이터 모델

• 다대다 관계에서 데이터 간 연결이 복잡해지면 그래프로 데이터를 모델링하는 것이 더 자연스럽다.
• 특히, 소셜미디어등에서 이러한 그래프형 데이터 모델을 쓰는 것이 적합