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

데이터 모델과 질의 언어

데이터 모델

• 소프트웨어 개발에서 제일 중요한 부분
• SW가 어떻게 작성되었는지, 해결하려는 문제를 어껗게 생각해야하는 지에 대한 영향

대부분의 어플리케이션 : 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 둬서 생성
각 계층의 핵심적인 문제 : 하위 계층 관점에서 데이터 모델을 표현하는 방법

• ex:
  • 개발자는 현실을 통해 객체/자료구조/데이터 구조를 다루는 API를 모델링 -> 이러한 구조는 어플리케이션에 특화
  • 데이터 구조 저장 : JSON, XML, RDB Table, Graph Model과 같은 범용 데이터 모델로 표현
• 각 계층은 명확한 데이터 모델을 제공하여 하위 계층의 복잡성을 숨긴다. 추상화
• 다양한 데이터 모델 -> 각 데이터 모델은 사용 방법에 대한 가정을 나타낸다.
• 어플리케이션에 적합한 데이터 모델을 선택하는 것이 중요한 이유 : 데이터 모델 위에 SW가 할 수 있는 일에 대한 영향

02.1 관계형 모델과 문서 모델

관계형 모델

가장 널리 사용되는 데이터 모델 : RDB 기반의 SQL

• 데이터 구성 : 관계(테이블),
  • 관계의 구성은 tuple(로우)의 모음
• RDB의 근원 : 1960/70에 수행된 비즈니스 데이터 처리 (트랜잭션 처리 / 일괄(batch) 처리)
• RDB의 목표 : 정리된 인터페이스의 뒤로 구현 세부 사항을 숨기는 것

수년 동안 데이터 저장/질의에 대한 접근 방식의 경쟁

• 70/80 : 네트워크 모델/계층 모델
• 80/90 : 객체 DB
• 2000 : XML DB
• 하지만 결국 RDB가 오랜시간 우위를 점함
• 2010 : NoSQL 이 탄생하게 된다.
• 현재는 네트워크 및 컴퓨터의 발전으로 다양한 목적을 위해 RDB 로 넓은 사용 사례를 가지고 있다.

NoSQL의 탄생

• NoSQL :
  • 대규모 데이터 셋 / 뛰어난 확장성의 요구
  • write 처리량이 필요할 때
  • 무료 오픈소스 소프트웨어에 대한 선호도 확산
  • Realation Model에서 지원하지 않는 특수 질의 동작
  • 스키마리스 및 동적이고 자유로운 데이터 모델
  • 다중 저장소 지속성(polyglot persistence)
    • 어플리케이션 요구사항에 맞추어 다양한 데이터 저장소를 동시 사용
    • ex) RDB + NoSQL

객체 관계형 불일치

배경 : 객체지향 프로그래밍 언어를 통한 어플리케이션 개발

• 하지만 데이터를 관계형 Table에 저장하기 위해서는 어플리케이션 level 코드와 DB Model 간의 전환 계층이 필요
• 이러한 모델 사이의 분리 : 임피던스 불일치(Impedance Mismatch)
  • ORM 프레임 워크를 통해 전환계층에서 필요한 상용구 코드(boilerplate code)의 양을 줄이긴 하지만 두 모델간의 간극은 존재
    • ex_ ( Hibernate , ActiveRecord )
• 모델마다 다른 스키마를 가지는 (사람 - 다양한 정보(약력, ...)) OneToMany 와 같은 관계를 지닐 때 :
  이력서처럼 모든 내용을 갖춘 문서 형태의 데이터 구조 json 구조가 적합
• 문서 지향 DB (Document-oriendted DB) 
  • JSON format 지원 
    • ex_ MongoDB, RethinkDB, CouchDB, Espresso
• JSON Presentation
  • 특징 : 임피던스 불일치 감소, 스키마 유연성, 더 나은 지역성
  • 1 : N 관계 - 데이터 트리 구조 
  • 하지만, 데이터 부호화 형식으로서 가지는 문제가 존재한다. 

N:1 관계  &  N : M 관계 

• Text 저장 vs ID 사용 
  
  • text - 사용하는 모든 레코드에서 중복 저장 
  • ID - 의미있는 정보에 대해서는 한 곳에만 저장 [참조는 모두 ID를 사용]
    • 중복 제거와 변경시 이상 문제 ↓
• 정규화 (Normalization)
  • N:1 (다대일) 관계에서 필요
  • 다대일 관계에선 document-model 보다 Relation-model에서 적합 (∵ JOIN)
• Document-model 에서의 JOIN
  • 보통 지원하지 않는다. (트리구조이기 때문에 조인이 필요하지 않다.)
  • cf) DB가 join을 지원하지 않는다면 다중 질의(multiple Query)를 통해 join과 유사한 처리
• if) join-free인 상황이 적합하다면
  • 어플리케이션이 발전함에 따라, 기능이 추가되면 데이터는 결국 상호연결 ( N : M 관계 )
  • 따라서 참조 표현 / 질의를 위한 조인이 필요할 수도..

N : M 관계 표현 

• RDB : 애초에 다대다 관계와 조인을 사용하고 있었음
• NoSQL : X
• Document DB : X 

기존 70년대에는 IMS(Information Management System)에서는 계층 모델(Json과 비슷)로 간단한 데이터 모델 사용 

- 모든 데이터를 레코드 내에 중첩된 레코드 트리로 표현 

• 1 : N 관계는 잘 표현하지만 N : M / Join 이 X 
• 이러한 한계를 극복하기 위해 두가지 솔루션이 나오게 된다.
  • 관계형 모델 (SQL)
  • 네트워크 모델 

• 계층 모델 ( 1 : N )
  부모 노드는 여러 자식 노드를 가질 수 있음 
  하지만 자식 노드는 여러 부모 노드를 가질 수 없음 
  
  
• 네트워크 모델 
  - 레코드는 다중 부모 가능  ->  N : 1 / N : M 가능 
  • 레코드 접근 방법 : root에서 연결된 레코드간 연결 경로를 따라간다. 
  • N : M 에선 다양한 경로가 가능하므로, developer가 경로 선택 / 탐색을 해줘야함 (복잡성)
• 관계형 모델 
  • 관계는 단순하게 튜플의 모음 
  • 외래키 관계일 경우 새로운 레코드를 쉽게 생성 
  • join / 1 : N / N : M 관계 모두 가능 
  • 네트워크 모델과 달리 접근 경로를 신경쓰지 않아도 된다. query Optimize는 자동 
    • Query-Optimize : 질의 내 순서, 사용될 색인 자동 결정 ( 접근 경로 설정 )
• 문서 데이터 모델 (문서 지향 DB)
  • 테이블이 아닌 상위 레코드 내에 중첩된 레코드를 저장 
  • RDB와 관계 표현 유사 (외래키와 같이 고유 식별자 - 문서 참조[Document Reference]) 
  • 스키마 유연성, 지역성에 기인한 더 나은 성능(어플리케이션 내 데이터 모델과 가장 가까움)

 

문서 모델의 스키마 유연성 

스키마리스로 불리지만, 암묵적 스키마가 존재  & DB는 이를 강요하지 않을 뿐

• 쓰기 스키마(schema-on-write) :
  - 데이터를 저장할 때 스키마를 정의하고 데이터 저장 
  - 정적(컴파일 타임) 타입 확인 
  - 데이터 타입 변경 시 : 마이그레이션 필요 (중단 발생)
• 읽기 스키마(schema-on-read) :
  - 데이터를 읽을 때 스키마 정의되어 읽음 
  - 동적(런타임) 타입 확인 
  - application에서 기존 기록된 document에 대해 처리 코드 추가 
  
  

출처 : https://jangseongwoo.github.io/hadoop/schema-on-read-schema-on-write/

 

질의를 위한 데이터 지역성 

저장소 지역성(Storage locality) 

- 한 번에 특정 document의 많은 부분이 필요할 때  이점으로 적용된다 

• Document Model 
  • document의 작은 부분 접근 시 Document의 전체를 적재 (Disk에서 mem)
  • document Update 시 전체 재작성해야한다. 
  • 따라서 document 작게 유지하면서 크기가 커지는 write은 지향 
• RDB 
  • oracle - 다중 테이블 색인 클러스터 테이블(multi-table index cluster table) 를 통해 지역성 제공 
    • http://www.dba-oracle.com/oracle_tip_hash_index_cluster_table.htm

Reduce I/O with Oracle cluster tables

---

 

데이터를 위한 질의 언어 

명령형 언어  Vs  선언형 언어 

출처 : https://medium.com/@kimdohun0104/%EC%82%AC%EB%9E%8C%EB%93%A4%EC%9D%80-%EC%99%9C-%EC%84%A0%EC%96%B8%ED%98%95-ui%EC%97%90-%EC%97%B4%EA%B4%91%ED%95%A0%EA%B9%8C-1440d03f4e49

• 명령형 언어 : How - 어떻게 할지를 기술한다. 
  • 특정 순서로 특정 연산 수행 
  • 목표를 달성하기 위한 방법
  • 일반적인 개발 언어 (Java, C ...)
• 선언형 언어 : What - 무엇인지(무엇을 보여줄 것인지) 기술한다. 
  • 결과를 충족할 조건 지정
  • 데이터가 어떻게 변환되어야하는지 [정렬 / 그룹화 / aggregation]
  • SQL , 관계대수, CSS, 함수형 언어, 논리형 언어 

선언형 질의 언어의 장점

• 선언형보다 가독성 및 쉬운 작업 처리
• 질의 변경 없이 성능 향상 가능 
  • DB 엔진에서의 캡슐화로 상세 구현이 숨겨져 있다
• 실행 순서를 보장하지 않는다 따라서 종종 병렬 실행에 적합하다. 
  • 결과의 패턴만 지정하기 때문

---

 

맵리듀스 질의 

 

MapReduce :

출처 : https://m.blog.naver.com/jevida/140199795866

한 컴퓨터에서 수행할 작업을 여러 컴퓨터에 분산하여 처리하는 프로그래밍 모델
연산을 수행할 작업을 여러 컴퓨터에 자동으로 작업을 분할하고, 작업을 위한 네트워크 통신을 수행하는데 사용 
Ex) 맵리듀스 - 그리드 프로그램(토렌트, 웹하드)

• 선언형 질의 언어도 완전한 질의 API도 아닌 중간에 위치함 
• 질의 로직 - 처리 프레임워크가 반복적으로 호출하는 조각 코드로써 표현 
• 두 함수를 기반으로 한다. 
  • map() : 분할한 데이터를 가공하는 Apply 기능 수행 
  • reduce() : map() 함수로 가공한 데이터를 기준에 따라 데이터를 하나로 다시 병합하는 기능 
• 클러스터 환경에서 분산 실행을 위한 프로그래밍 모델 : 저수준 프로그래밍 모델
  • cf) SQL 고수준 질의 언어 

몽고DB의 map / reduce

• 두 함수는 순수함수여야 한다. (side-effect가 없어야함) 
• 임의 순서로 실행이 가능하기 때문에, 재실행이 가능하다. 
• 선언형 질의 언어에서는 질의 최적화기가 질의 성능을 높일 수 있는 기회를 제공
  • 몽고 DB에서는 aggregation pipeline을 통해 선언형 질의 언어 지원을 추가 
    • JSON 기반 구문
    • 맵리듀스 함수 작성의 어려움 해소
    • Optimizer 최적화 여지 높임