내용 정리
1. 개요
•
데이터 모델은 그위에 소프트웨어가 할 수 있는 일과 할 수 없는 일에 지대한 영향을 주므로 애플리케이션에 적합한 데이터 모델을 선택하는 작업은 상당히 중요하다.
•
데이터 모델 종류
◦
관계형 모델
◦
문서 모델
◦
그래프 기반 데이터 모델
2. 관계형 모델과 문서 모델
2.1. 관계형 모델 vs 문서 모델
•
관계형 모델
◦
데이터는 관계(relation)으로 구성됨
▪
관계는 순서없는 튜플(row)의 모음
◦
임피던스 불일치 (impedance mismatch)
▪
애플리케이션 코드와 데이터 베이스 모델 객체 사이의 분리가 필요
▪
ORM
◦
Join, 다대일, 다대다 관계지원
◦
쿼리 옵티마이저를 통해 질의 방식과 순서를 자동으로 결정
•
문서 모델
◦
NoSQL (Not Only SQL)
▪
대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 DB 보다 쉽게할 수 있는 확장성 필요
▪
관계형 모델에서 지원하지 않는 특수 질의 동작
▪
관계형 스키마 제한에 대한 유연함
◦
특징
▪
스키마의 유연성
▪
저장소 지역성
▪
애플리케이션에서 사용하는 데이터 구조와의 일치성이 높음
▪
데이터가 문서와 비슷한 형태에 적합
•
다대일 관계(트리 구조 데이터) / 레코드 간 관계가 없다면 문서 모델이 적합
2.2. 스키마의 유연성
•
쓰기 스키마 (schema-on-write)
◦
관계형 데이터베이스의 전통적 접근 방식
◦
스키마는 명시적
◦
데이터 베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장
◦
마이그레이션 필요
•
읽기 스키마 (schema-on-read)
◦
스키마는 암묵적
◦
데이터를 읽을때만 해석됨
◦
컬렉션 내 항목이 어떤 이유로 모두 동일한 구조가 아닐때 유리
▪
다른 여러 유형의 객체가 있고, 각 유형 객체 별로 자체 테이블을 넣는 방식은 실용적이지 않음
▪
사용자가 제어할 수 없고, 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정
2.3. 질의를 위한 데이터 지역성
•
저장소 지역성
◦
자주 전체 문서에 접근해야할 때 성능 이점
◦
한번에 문서의 많은 부분이 필요로 하는 경우만 적용됨
▪
그렇지 않은 경우 낭비
•
데이터 지역성의 응용
◦
문서 모델에만 국한되지 앟음
◦
오라클 - 다중 테이블 색인 클러스터 테이블
◦
빅데이블 - 칼럼 패밀리 개념
3. 데이터를 위한 질의 언어
3.1. 선언형 vs 명령형
•
선언형 질의 언어
◦
목표를 달성하기 위한 방법이 아니라 알고자 하는 데이터의 패턴 만 지정
◦
결과를 충족해야 하는 조건과 데이터를 어떻게 변환(정렬, 그룹화, 집계)할지만 지정
◦
상세 구현은 DB 엔진에 위임.
SELECT * FROM animals WHERE family = 'Sharks
SQL
복사
•
명령형 질의 언어
◦
특정 순서로 특정 연산을 수행하게끔 컴퓨터에게 지시
function getSharks() {
var sharks = [];
for (var i = 0; i < animals.length; i++) {
if (animals[i].family === "Sharks") {
sharks.push(animals[i]);
}
}
return sharks;
}
JavaScript
복사
3.2. 맵리듀스 질의
•
클러스터 환경에서 분산 실행을 위한 프로그래밍 모델
◦
많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 언어
◦
많은 문서를 대상으로 읽기 전용 질의를 수행할 때 사용
•
저수준 프로그래밍 모델
•
함수
◦
map, reduce
◦
순수 함수
▪
입력된 전달된 데이터만 사용
▪
추가적인 데이터 질의 불가
▪
부수 효과 없음
4. 그래프형 데이터 모델
•
다대다 관계가 일반적인 경우 그래프로 데이터 모델링
•
구성
◦
정점(vertex; 노드, 엔티티)
▪
구성
•
고유한 식별자
•
유출(outgoing) 간선 집합
•
유입(incoming) 간선 집합
•
속성 컬렉션(키-값 쌍)
◦
간선(edge; 관계, 호)
▪
구성
•
고유한 식별자
•
간선이 시작하는 정점 (꼬리 정점)
•
간선이 끝나는 정점 (머리 정점)
•
두 정점 간 관계 유형을 설명하는 레이블
•
속성 컬렉션 (키-값 쌍)
•
특징
◦
모두 같은 유형(동종 데이터)에 국한되지 않고도 간선으로 연결 가능
◦
단일 데이터 저장소에 완전히 다른 유형의 객체를 일관성 있게 저장할 수 있는 강력한 방법을 제공
▪
다른 유형의 관계에 서로 다른 레이블 사용
◦
정점은 다른 정점과 간선으로 연결됨
▪
특정 유형과 관련 여부를 제한하는 스키마는 없음
◦
정점이 주어지면 정점의 유입과 유출 간선을 효율적으로 찾을 수 있고 그래프를 순회 할 수 있음
▪
일련의 정점을 따라 앞뒤 방향으로 순회 가능
•
예시
◦
소설 그래프
▪
정점 - 사람
▪
간선 - 사람들끼리 알고 있음을 의미
◦
웹 그래프
▪
정점 - 웹 페이지
▪
간선 - 다른 페이지에 대한 HTML 링크
•
종류
◦
속성 그래프 모델
◦
트리플 저장소 모델
•
언어 종류
◦
사이퍼
▪
그래프를 위한 선언형 질의 언어
◦
SQL의 그래프 질의
▪
가능 하나 어려움
▪
그래프 질의에서 찾고자 하는 정점을 찾기 전에 가변 순회 경로 파악 필요
▪
재귀 공통 테이블식
◦
트리플 저장소와 스파클
▪
모든 정보를 세 부분 구문 형식으로 저장
•
주어 (subject)
•
서술어 (predicate)
•
목적어 (object)
◦
시맨틱 웹
스터디
1. 질문만들기
1.1. matthew
1. 꼬리 지연 시간이란 무엇이며 이것이 왜 중요한 지표일까요?
2. 데이터 모델은 어떠한 종류가 있습니까
3. 각 데이터 모델은 어떠한 상황에서 적합한가요
1.2. Harry
1. 그래프형 데이터 모델과 문서형 모델의 차이가 무엇인가요?
2. 선언형 질의 언어와 명령형 질의 언어의 특징을 설명해주세요
3. 쓰기 스키마와 읽기 스키마를 서술해주세요
2. 핵심 질문에 답하기
•
1번 항목에서 답변 완료
3. 책 같이 살펴보기
•
완료
4. 완전한 문장으로 만들기
•
관계형 DB vs 문서형 DB(no sql)
◦
harry) 문서형 DB 의 경우 너무 자유도가 높은 나머지 format 이 개별로 될 수 있어서 사이드 이펙트가 발생 가능하다는점이 우려됨
•
ES 는 어떠한 형태인가? 관계형? 문서형?
◦
•
데이터 지역성
◦
정의
▪
전체 데이터를 갖고오는 경우에는 장점이 있으나 일부 데이터만 접근하는 경우는 되려 낭비가 될 수 있다.
◦
이론적으로는 이해되나, 실무적으로는 잘 와닿지 않음
◦
우리가 정의한 데이터 모델이 전체 데이터만 갖고 오는 경우가 있을지?
•
데이터 모델이 중요한 이유
◦
(Harry)
▪
데이터 모델을 어떻게 정의하냐에 따라 우리가 뭘 할 수 있느냐가 달라짐
▪
요구사항이 최초에 정의 되긴 하지만, 어떻게 확장 될 지 모르므로 항상 어떤 방식을 선택해야하는지가 쉽지 않다.
▪
최초의 요구사항으로 바탕으로 우리가 예측가능한 수준까지는 예측하여 잘 정의할 수 밖에 없다.
•
일반적인 레벨에서의 기본 값 = 쓰기 스키마 = 관계형 모델
•
변경될 수 있는 값 = 읽기 스키마 = 문서형 모델
▪
끊임없이 유지보수하면서 그때마다 최적의 방법을 찾고 개선해나갈 수 밖에 없을지?
◦
(Matthew)
▪
유지보수의 편의성