designing-data-intensive-applications

🖍️ 학습 목표

• 데이터 모델은 그 위에서 소프트웨어가 할 수 있는 일과 할 수 없는 일에 영향을 주므로 적합한 모델을 선택하는 것이 중요
• 데이터 저장과 질의를 위한 다양한 범용 데이터 모델 알기
• 관계형 모델(relational model)과 문서 모델(document model), 그래프 기반 데이터 모델(graph-based data mod이)을 비교
• 다양한 질의 언어와 사용 사례 비교

관계형 모델과 문서 모델

• RDB 기반 SQL : 가장 널리 사용되는 데이터 모델
  • 60-70년대 등장, 25-30년간 우위를 차지 (70~80년대 초반에는 네트워크 모델/계층 모델)
  • 데이터는 관계(Relation=table)으로 구성되며, 각 관계는 순서없는 tuple(=row)의 모음
  • 트랜잭션 처리(영업, 은행, 항공, 창고) 및 일괄처리(송장, 급여, 보고)와 같은 비즈니스 데이터 처리에서 근원
  • 웹의 온라인 게시물, 소셜 네트워크, 전자 상거래, 게임, SaaS 생산 등에 대부분 보편적으로 사용
• NoSQL
  • 사용 이유
    • 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성의 필요
    • 상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산
    • 관계형 모델에서 지원하지 않는 특수 질의 동작
    • 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

객체 관계형 불일치

• 임피던스 불일치(Impedance Mismatch) : 데이터를 관계형 Table에 저장하기 위해서는 어플리케이션 코드와 데이터베이스 모델 객체(테이블, 로우, 컬럼) 간의 전환 계층이 필요, 이러한 모델 사이의 분리 이슈
  • 관계형 스키마에서 이력서(링크트인 프로파일)의 표현 // 1대 다
    • 전통적 SQL : 프로필 전체를 고유식별자(user_id)로 식별, 직위.학력.연락처 정보를 개별 테이블에 넣고 Users테이블을 참조
    • 표준 SQL : XML/JSON 등 구조화된 데이터 타입에 대한 지원
    • 직업, 학력. 연락처 정보를 JSON/XML로 부호화해 DB의 텍스트 칼럼에 저장하여 애플리케이션이 구조와 내용을 해석하게 하는 방식

- JSON 표현은 다중 테이블(multi-table) 스키마보다 더 나은 지역성(locality)을 갖음
- 관계형 예제에서 프로필을 가져오려면 다중 질의(각 테이블에 user id로 질의)를 수행하거나 users 테이블과 그 하위 테이블 간에 난잡한 다중 조인을 수행해야 함
- JSON 표현에서는 모든 관련 정보가 한 곳에 있어 질의 하나로 충분 (1대 다 관계=트리구조)

다:1 vs 다:다

• 앞의 예제에서 region_id와 industry_id는 평문인 “그레이터 시애틀 구역”과 “자선활동”이 아 닌 ID로 주어짐
• 지리적 지역과 업계의 표준 목록으로 드롭다운 리스트나 자동 완성 기능을 만들어 사용자가 선택하게 할 때의 장점
  • 모호함 회피
  • 프로필 간 일관된 스타일과 철자
  • 갱신의 편의성
  • 현지화 지원
  • 더 나은 검색
• 중복된 데이터를 정규화하려면 다대일 관계가 필요하나 문서 모델에 적합하지 않음 // 조인에 대한 지원 약함
  • 추천서 라는 새로운 기능이 필요할 때…

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

• 1970년대 비즈니스 데이터 처리를 위해 가장 많이 사용한 데이터베이스는 IBM의 정보 관리 시스템 (information Management System, IMS)
• IMS의 설계는 계층 모델이라 부르는 상당히 간단한 데이터 모델을 사용하며 JSON과 유사
• IMS는 다대다 관계 표현 어렵고 조인 지원 X
• 계층 모델의 한계를 해결하기 위해 다양한 해결책이 제안
• 네트워크 모델 (코다실 모델)
  • 계층 모델의 트리 구조에서 모든 레코드는 정확하게 하나의 부모가 있으나, 네트워크 모델에서 레코드는 다중 부모가 있을 수 있음
  • 네트워크 모델에서 레코드 간 연결은 외래 키보다는 프로그래밍 언어의 포인터와 더 비슷. 레코드에 접근하는 유일한 방법은 최상위 레코드에서부터 연속된 연결 경로를 따르는 방법 (접근 경로)
• 관계형 모델
  • 알려진 모든 데이터를 배치함. 관계(테이블)은 단순히 튜플(로우)의 컬렉션이 전부이므로 복잡한 접근 경로 없음
  • 임의 조건과 일치하는 테이블의 일부 또는 모든 로우를 선택해서 읽을 수 있고 일부 칼럼을 키로 지정해 칼럼과 일치하는 특정 로우를 읽을 수 있음
  • 다른 테이블과의 외래 키 관계에 대해 신경 쓰지 않고 임의 테이블에 새 로우를 삽입할 수 있음
  • 관계형 데이터베이스에서 질의 최적화기(query optimizer)는 질의의 어느 부분을 어떤 순서로 실행할지를 결정하고 사용할 색인을 자동으로 결정하므로 접근 경로를 생각할 필요 없음
  • 따라서 새로운 기능 추가하는 작업이 쉬움
• 문서 데이터베이스와의 비교
  • 문서 데이터베이스는 별도 테이블이 아닌 상위 레코드 내에 중첩된 레코드를 저장
  • 다대일과 다대다 관계를 표현할 때 관계형 데이터베이스와 문서 데이터베이스는 근본적으로 다르지 않음
  • 둘 다 관련 항목은 고유한 식별자로 참조. 관계형 모델에서는 외래 키라 부르고 문서 모델에서는 문서 참조(document reference)라 부름

관계형 DB와 오늘날의 문서DB

• 애플리케이션 코드를 더 간단하게 만드는 모델?
  • 데이터 항목 간에 존재하는 관계 유형에 따라 다름
  • 상호 연결이 많은 데이터의 경우 문서 모델은 곤란 하지만 관계형 모델은 무난. 그래프 모델이 자연스러움
• 문서 모델에서의 스키마 유연성
  • 문서 데이터베이스는 종종 스키마리스(schemaless)로 불리지만 이는 오해의 소지가 있음
  • 쓰기 스키마(schema-on- write)
    • 관계형 데이터베이스의 전통적인 접근 방식으로 스키마는 명시적이고 데이터 베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장
    • 정적(컴파일타임) 타입 확인과 비슷
  • 읽기 스키마(schema-on- read)
    • 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석됨
    • 동적(런타임) 타입 확인과 유사
  • 정적타입이 경우 마이그레이션(update)가 필요
  • 읽기 스키마 접근 방식은 컬렉션 안의 항목이 모두 동일한 구조가 아닐 때(즉 데이터가 여러 다른 유형으로 구성돼 있음) 유리
    • 다른 여러 유형의 오브젝트가 있고 각 유형의 오브젝트별로 자체 테이블에 넣는 방법은 실용적이지 않음
    • 사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정됨
• 질의를 위한 데이터 지역성
  • 웹 페이지 상에 문서를 보여주는 동작처럼 애플리케이션이 자주 전체 문서에 접근해야 할 때 저장소 지역성(storage locality)을 활용하면 성능 이점이 있음 - 한번에 문서의 많은 부분을 필요로 하는 경우에만 적용
  • 문서 데이터베이스와 관계형 데이터베이스의 통합
  • 관계형 DB가 XML과 JSON 지원

데이터를 위한 질의 언어

• 선언형 질의 언어는 일반적으로 명령형 API보다 더 간결하고 쉽게 작업할 수 있으며, 데이터베이스 엔진의 상세 구현이 숨겨져 있어 질의를 변경하지 않고도 데이터베이스 시스템의 성능을 향상시킬 수 있음. 병렬 실행에 적합
• 웹에서의 선언형 질의
  • 웹 브라우저에서 선언형 CSS 스타일을 사용하는 편이 자바스크립트에서 명령형으로 스타일을 다루 기보다 훨씬 나으며, 데이터베이스에서는 SQL 같은 선언형 질의 언어가 명령형 질의 API 보다 훨씬 좋음
• 맵리듀스 질의
  • 많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델
  • 선언형 질의 언어도 완전한 명령형 질의 API도 아닌 그 중간

그래프형 데이터 모델

정점(vertex)=노드나 엔티티 & 간선(edge)=관계나 호(arc)

(소셜 그래프, 웹 그래프, 도로나 철도 네트워크…)

• 속성 그래프
  • 정점
    • 고유한식별자
    • 유출(outgoing) 간선 집합
    • 유입(incoming) 간선 집합
    • 속성 컬렉션(키—값 쌍)
  • 간선
    • 고유한식별자
    • 간선이 시작하는 정점(꼬리 정점)
    • 간선이 끝나는 정점(머리 정점)
    • 두 정점 간 관계 유형을 설명하는 레이블
    • 속성 컬렉션(키—값 쌍)
• 사이퍼 질의 언어
  • 속성 그래프를 위한 선언형 질의 언어
  • 질의 최적화기가 가장 효율적이라고 예측한 전략을 자동으로 선택하므로 수행에 대해 자세히 지정할 필요 없음
• SQL의 그래프 질의
  • 그래프 데이터를 관계형 구조로 넣어도 SQL을 사용해 질의할 수 있을까??
  • WITH RECURSIVE 문을 이용해 가변 순회 경로 질의 가능
• 트리플 저장소와 스파클
  • 모든 정보를 주어, 서술어, 목적어처럼 매 우 간단한 세 부분 구문 형식으로 저장
  • 시맨틱 웹
    • 웹 사이트는 이미 사람이 읽을 수 있는 텍 스트와 그림으로 정보를 게시하고 있으니 컴퓨터가 읽게끔 기계가 판독 가능한 데이터로도 정보를 게시하는 건 어떨까라는 개념
    • 사용은 글쎄…
  • RDF 데이터 모델
    • 인터넷 전체의 데이터 교환을 위해 설계
  • 스파클 질의 언어
    • RDF 데이터 모델을 사용한 트리플 저장소 질의 언어
• 데이터로그
  • 스파클이나 사이퍼보다 훨씬 오래된 언어
  • 데이터로그의 데이터 모델은 트리플 저장소 모델과 유사하지만 조금 더 일반화
  • (주어, 서술어, 목적어)로 트리플을 작성하는 대신 서술어(주어, 목적어)로 작성

정리

• 데이터를 계층 구조(하나의 큰 트리)로 표현하려고 했지만 다대다 관계를 표현하기에 적절하지 않았음
• 이를 해결하기 위해 관계형 모델이 고안됨
• 비관계형 데이터 저장소로써 NoSQL
  • 문서 데이터베이스 : 데이터가 문서 자체에 포함돼 있으면서 하나의 문서와 다른 문서 간 관계가 거의 없는 사용 사례를 대상으로 함
  • 그래프 데이터베이스 : 문서 데이터베이스와는 정반대로 잠재적으로 관련 있다는 사용 사례를 대상으로 함
• 문서 및 그래프 데이터베이스의 공통점 중 하나는 일반적으로 저장할 데이터를 위한 스키마를 강제하지 않아 변화하는 요구사항에 맞춰 애플리케이션을 쉽게 변경할 수 있다는 점
• 하지만 애플리케이션은 데이터가 특정 구조를 갖는다고 가정할 가능성이 높으며,
• 이는 스키마가 명시적인지(쓰기에 강요됨) 암시적인지(읽기에 다뤄짐)의 문제일 뿐
• 각 데이터 모델은 고유한 질의 언어 및 프레임워크를 제공함