[데이터 중심 애플리케이션 설계] 02. 데이터 모델과 질의 언어

 

 

 

 

[데이터 중심 애플리케이션 설계] 02. 데이터 모델과 질의 언어

 

1. 데이터 모델의 중요성

• 데이터 모델은 소프트웨어 개발에서 제일 중요한 부분이다.
• 데이터 모델은 소프트웨어가 어떻게 작성됐는지, 해결하려는 문제를 어떻게 생각해야 하는지 지대한 영향을 미친다.
• 데이터 모델은 그 위에서 소프트웨어가 할 수 있는 일과 할 수 없는 일에 영향을 주므로 적합한 데이터 모델을 선택하는 작업은 굉장히 중요하다.
• 데이터 모델의 큰 범주
  • 관계형 모델
  • 문서 모델
  • 그래프 모델

 

2. 관계형 모델과 문서 모델

• 관계형 모델
  
  • 데이터는 관계(relation)으로 구성
  • 각 관계는 순서없는 튜플(tuple)의 모음
  • SQL 은 정규화된 구조로 데이터를 저장하고 질의할 필요가 있을 때 사용
• NoSQL의 탄생 : Not Only SQL
  • 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할수 있는 확장성의 필요
  • 무료, 오픈소스 스프트웨어 선호
  • 관계형 모델에서 지원하지 않는 특수 질의
  • 관계형의 스키마 제한에 대한 불만, 동적이고 표현력 풍부한 데이터 모델을 선호

 

3. 데이터 모델들이 관계를 표현하는 방법

• 객체 관계형 불일치
  • 객체지향 프로그래밍의 객체를 SQL 데이터 모델로 바꾸려면 애플리케이션 코드와 데이터 베이스 모델 객체 사이에 거추장스러운 전환 계층이 필요 : 임피던스(impedance) 불일치
  • ActiveRecord 나 Hibernate 같은 ORM 으로 boilerplate code 를 줄이지만, 여전히 두 모델의 차이가 완벽히 숨겨지진 않는다.
  • 이력서 같은 데이터 구조는 모든 내용을 갖추고 있는 문서라서, 난잡한 다중 조인을 수행하는 관계형 데이터베이스 보다는 JSON 표현에 매우 적합하다.

• N대1 관계
  • ex) N명이 하나의 학교를 가리킴
  • 지역명이나 학교명을 평문으로 저장하게되면, 나중에 이름이 바뀌었을 때 갱신하기 어려워진다.
  • unique id 로 저장하게 된다면, id 자체는 아무런 의미가 없기때문에 변경할 필요가 없어진다.
  • id가 의미를 갖게되면, 미래에 언젠가 id를 변경해야할 수도 있다.
  • 이러한 중복된 데이터(N대 1)를 정규화하는 것은 관계형 모델에선 쉽지만, 문서 지향에선 어렵다.
  • DBMS가 join을 지원해주지 않으면, 어플리케이션에서 다중 질의를 해서 join을 흉내내야 한다.
  • 지금은 join이 필요없게 만들더라도, 비즈니스가 확장되가며, 데이터는 점차 상호 연결되는 경향이 있다.
• N대M 관계
  • ex) 내 프로필에 추천인의 프로필이 뜬다. 추천인추천해준 모든 사람 내 프로필의 추천인 사진이 바뀌어야한다. 즉, 엔티티를 참조해야한다.

  • 

 

 

• 관계형 모델 : 알려진 모든 데이터를 배치하고, 관계는 단순히 튜플의 컬렉션이 전부이다.
  • 임의 조건과 일치하는 테이블의 일부 또는 모든 로우를 선택해서 읽는다.
  • 외래 관계에서도 새로운 레코드를 쉽게 생성 가능 (외래 키 제약을 줄수는 있긴 함)
  • 관계형 데이터베이스에서 질의 최적화를 자동으로 하기 때문에, 개발자는 접근 경로를 신경쓸 필요가 없다. 
• 문서 데이터베이스와의 비교
  • N대1, N대M 관계를 표현할 때는 관계형 데이터베이스처럼 고유한 식별자로 참조한다.

3.1. 문서 모델

• 어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까? 
  • 문서와 비슷한 구조(1대N, 트리 구조로 한번에 전체 트리를 적재)라면 문서 모델
  • 상호 연결이 많은 데이터일 수록 문서 모델은 곤란, 관계형 모델은 무난, 그래프 모델은 매우 자연스럽다.
• 문서 모델의 스키마 유연성(schemaless)
  • 데이터를 읽는 코드는 보통 구조의 유형을 어느 정도 가정한다. 즉, 암묵적인 스키마는 있으나, 데이터베이스는 이를 강요하진 않는다.
    
    • 쓰기 스키마 : 정적 타입 확인, RDB의 방식. 이게 없다면 임의의 키와 값을 자유롭게 추가
    • 읽기 스키마 : 동적 타입 확인, 문서DB의 방식. 이게 없다면 필드의 존재여부가 보장되지 않음
  • 즉, 어플리케이션은 데이터를 읽는 코드가 있으므로 읽기 스키마를 어느정도 가정하고 사용한다.
  • 예를들어, fullname 을 저장하고 있다가, 성과 이름을 분리하는 작업이 있다고 가정하면,
    • 문서 모델 : firstName, lastName 을 그냥 추가해서 저장하면 된다. 과거 데이터를 읽은 경우를 처리하는 코드만 있으면 된다.
    • 관계 모델 : ALTER TABLE users ADD COLUMN firstName VARCHAR(20) 으로 쓰기스키마를 변경하고 마이그레이션을 해줘야한다. 중단시간이 발생할 수도 있다
  • 읽기 스키마 방식은 컬렉션 내 문서들이 모종의 이유로 동일한 구조가 아닐 때 유리하다.
    • 하위에 여러 유형의 Object들이 있을 때, 각 유형마다 table을 만드는 것은 실용적이지 않다.
    • 개발자가 정적으로 제어하는게 아니라, 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정될 수 있다.
• 질의를 위한 데이터 지역성(storage locality)
  • 관련 데이터를 함께 그룹화하는 개념
  • 문서는 json, xml 로 부호화된 문자열이나 BSON 같은 바이너리로 저장된다.
  • 문서 중 일부만을 접근경로로 꺼내서 사용하지 않고, 전체를 잘 사용한다면 지역성의 이점을 누렸다고 볼 수 있다. (낭비가 없었으므로)
    • 전체를 찾아야한다면 RDB는 multi table 을 join 해야하므로 이런 지역성 관점에선 좋지않다.

 

4. 데이터를 위한 질의 언어

• 명령형 언어: 특정 순서로 특정 연산을 수행하라고 일일이 모두 정의하고 지시한다.
  • 결과를 결정하기 위한 알고리즘을 모두 지정
  • 멀티 코어 병렬 처리가 어려움
  • cf) 네트워크 모델류의 DB와 IMS 가 이런 형태를 사용함
  • ex) 특정 html태그를 javascript로 DOM API 를 사용해서 스타일링하는 것. 더 좋은 api를 사용하려면 코드바꿔야함
• 선언형 언어: 결과를 충족해야하는 조건과 변환을 지정해주기만 하면 된다.
  • 내부적으로 어떤 순서로 어떤 연산을 수행할지는 쿼리 최적화기가 알아서 한다.
  • 상세 구현이 숨겨져있어 질의를 변경하지 않고도 데이터베이스 시스템의 성능을 향상시킬 수 있다.
  • 멀티 코어 병렬 처리도 알아서 활용
  • ex) 특정 html태그를 css(선언형)로 꾸미는것. 브라우저 벤더가 알아서 최적화함.

4.1. 맵리듀스(MapReduce) 질의

• 많은 컴퓨터에서 대량의 데이터를 처리하기 위한프로그래밍 모델
  
  • 일부 NoSQL은 제한된 형태의 맵리듀스를 지원한다.

5. 그래프형 데이터 모델

• N대M 관계가 일반적일 때 사용
• 그래프 = 정점(=노드, 엔티티, vertex) + 간선(관계, 호, edge)
• 그래프형 데이터 모델의 예
  • 소셜 그래프 : vertex = 사람 , edge = 사람들이 서로 알고 있음
  • 웹 그래프 : vertex = 웹페이지 , edge = 다른 페이지로의 링크
  • 교통 네트워크 : vertex = 교차로 , edge = 교차로 간 도로, 철도
• 그래프 모델
  • 속성 그래프 모델 : Neo4j, Titan, InfiniteGraph
  • 트리플 저장소 모델 : Datomic, AllegroGraph
• 그래프 질의 언어
  • 선언형 질의 언어 : 사이퍼(Cypher), 스파클(SPARQL), 데이터로그(Datalog)
  • 명령형 질의 언어 : 그렘린(Gremlin)
• 그래프 처리 프레임워크 : 프리글(Pregel)

5.1. 속성 그래프 모델

• vertex의 요소
  • 고유한 식별자
  • 유출(outgoing edge) 간선 집합 : 이 vertex 에서 나가는 간선들
  • 유입(incoming edge) 간선 집합 : 이 vertex 로 들어오는 간선들
  • 속성 컬렉션(key-value 쌍)
• edge의 요소
  • 고유한 식별자
  • 간선이 시작하는 정점(꼬리 정점)
  • 간선이 끝나는 정점(머리 정점)
  • 두 정점 간 관계 유형을 설명하는 레이블
  • 속성 컬렉션(key-value 쌍)

5.1.1. SQL 에서 Graph 질의

• 관계형 스키마로 표현
• SQL 에서는 질의에 필요한 join 을 미리 알고 있어야하지만,
  • 그래프 질의에서는 찾고자 하는 vertex 를 찾기 전에 가변적인 여러 edge 를 순회해야 한다. 따라서, 미리 join 수를 알 수가 없다.
  • SQL 에서 굳이 어렵게라도 하려면, 재귀 공통 테이블식(recursive common table expression)을 통해 구현할 수 있다.
• 책에서는 RDBMS 에서 그래프 데이터 모델을 권장하고 있진 않지만, 스토리지엔진으로 InnoDB 대신 그래프 엔진을 선택하면 위에보단 나은 성능을 가져간다.
  •  

5.1.2. 문서DB 에서 Graph 질의

• 일반적인 graph 유즈케이스의 70% 정도를 커버

•