데이터 중심 애플리케이션 설계 2장 정리
정리
이거는 다른사람도 꼭 알아야 한다.(아주 중요)
데이터 베이스 질의는 명령형(절차 기술)이 아닌 선언(패턴 지정)형!
디비 엔진의 상세 구현이 숨겨져있어서(선언형 질의의 장점) 질의를 변경하지 않고도 성능을 향상시킬 수 있는 이유..
명령형이 쓰였을 때 안좋은 케이스: css 한줄의 코드를 DOM api 로 작성했을때 여러가지 (예상치 못한 삭제, 태그 변경 등) 상황에 따라 코드를 재 작성 해야 함
선언형 방식은 순서보장이 되지 않는 등 디테일한 조작은 불가능하지만, 그래서 최적화가 가능한 것 —> sql 이 기능적으로 더 제한적이라는 사실은 .. 최적화할 수 있는 여지를 더 많이 준다는 의미
이거는 알면 좋을 것 같다.(빨간거 다음으로 중요
관계형 데이터 베이스와 문서 데이터베이스는 시간이 지남에 따라 점점 더 비슷해지고 있다
반 관계형 데이터베이스, 구글 스패너
sql 에서 이곳 저곳 테이블을 스캔할 때 데이터를 적재,저장하는 데이터가 불필요하게 많아지는 문제를 이렇게 nosql처럼 데이터를 저장해놓고 접근할 때 지역성의 이득을 본다. 그렇게 하기 위해 테이블간의 계층을 미리 지정해서 아래와 같이 여러 테이블에 분산된 데이터를 정렬한다.
이거는 내가 개인적으로 흥미로웠다.(마음에 들었다)
text 문자를 테이블로 따로 떼서 id 로 나타내는 것의 장점 <33p>
2장
대부분 애플리케이션은 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 둬서 만듬
- 그래서 데이터 저장과 질의를 위한 다양한 범용 데이터 모델을 살펴본다.
관계형 모델과 문서 모델
Relation
- 각 관계는 순서 없는 tuple 모임
- 근원은 비즈니스 데이터 처리(트랜잭션이나 일괄처리)
NoSQL
- Not Only SQL
- RDB에서 지원하지 않는 특수 질의
- RDB보다 동적이고 표현력이 풍부한 데이터 모델 요구 등
객체 관계형 불일치
보통은 개발이 객체지향 프로그래밍으로 이루어짐
임피던스 불일치에의 문제
- 관계형 <-> 객체 사이의 전환 계층을 필요로 하는것
- ORM은 이러한 보일러플레이트 양을 줄여주지만 차이를 완벽히 숨길수는 없음
예시
이력서 같은걸 생각해보면 JSON표현으로 적합
- JSON을 쓰면 모든 정보가 한곳에 있어서 한번 가져오면 싹다 들고옴
다대일, 다대다 관계
- 지역이나 회사같은것들은 그냥 평문이 아니라 ID값을 가지고 있으면 여러 장점이 있다.
- 일관된 문자 저장
- 모호함 회피(동명의 다른거)
- 갱신의 편리함
- 현지화 지원(한 ID에 여러 언어를 저장한다면)
- 더 나은 검색 가능
- ID는 변경 필요X
- documentDB는 조인 지원이 약함(JSON같은거는 위에서 아래를 찾아가기는 쉽지만 하위를 통해 상위를 찾기는 힘드니까)
- 다대일 관계 적합하지 않다는것
- 하려면 DB가 아니라 애플리케이션에서 데이터를 가져와서 처리해야한다.
- 보면 처음에는 Join이 없어도 됐어도 구현하다보면 필요해질수 있다. 어떻게 하지?
- 네트워크 모델
- == 코다실 모델
- 얘는 다중 부모가 있을 수 있다.
- 아까 이력서같은걸로 생각해보면 지역->그지역사람 전체 이렇게 사람밑에 있으면서 동시에 지역밑에 있는 느낌
- 요런 식으로 하면 다대일, 다대다 모델링 가능
- 아까 이력서같은걸로 생각해보면 지역->그지역사람 전체 이렇게 사람밑에 있으면서 동시에 지역밑에 있는 느낌
- 레코드 접근을 하려면 최상위부터 쫘라락 내려가는 수밖에 없음
- 딱봐도 변경을 하거나 하면 모든 부모를 찾아가는 복잡한 문제가 있어 유연성 떨어짐
- 관계형 모델
- 얘는 우리가 아는 그 RDB같은걸로 단순히 튜플의 컬렉션이 다임
- 네트워크 모델
- 다대일 관계 적합하지 않다는것
- 지역이나 회사같은것들은 그냥 평문이 아니라 ID값을 가지고 있으면 여러 장점이 있다.
정리하자면 documentDB는 별도 테이블이 아닌 상위 레코드 내에 중첩된 레코드(일대다)를 저장함.
그러나 다대일과 다대다의 경우 RDB와 동일하고, 거기서는 FK라고 부르던걸 여기서는 Document Reference 즉 문서 참조라고 부른다.
RDB와 요즘의 documentDB
일단 차이만 집중하면
- documentDB의 장점
- 스키마 유연성, 지역성에 기인한 더 나은 성능
- 특정 애플리케이션의 경우 그곳의 데이터 구조와 비슷
- RDB
- 조인, 다대일, 다대다를 더 잘 지원함
- documentDB의 장점
보통 한번에 데이터를 가져오기만 하는 문서같은 느낌에는 documentDB
다대다같은걸 쓰면 RDB가 좋지
document의 스키마 유연성
JSON은 문서의 데이터에 어떤 스키마를 강요하지 않는다.
문서형데이터베이스는 종종 스키마리스로 불리지만 오해의 소지가 있다.
- 암묵적인 스키마가 있기는 한데 DB가 이를 강요하지 않음
- 읽기 스키마 : 데이터 구조는 암묵적으로 데이터를 읽을 때에만 해석된다.
- 쓰기 스키마 : RDB의 전통적인 방법이고 DB는 데이터가 스키마를 따르고 있음을 보장
- 그러니까 오브젝트별로 유형이 다르거나, 관계에 의해 변경하는 구조가 아니면 documentDB가 아주 좋음
질의를 위한 데이터 지역성
애플리케이션이 자주 전체 문서에 접근해야 할 때 저장소 지역성을 활용하면 성능 이점이 있다.
- 한번에 많은것을 요구한다면 이게 좋은거지 다가져오니까
구글 스패너, 오라클 다중 테이블 색인 클러스터 테이블, 빅테이블데이터모델의 칼럼 패밀리개념 등등
- 이거 신기하다... 데이터를 저장할 때에 아예 부모 및에 데이터를 저장시키는 식으로 지역성을 확보
RDB와 documentDB의 통합
RDB는 Json지원, document는 관계형 조인 지원
둘은 비슷해지고 있다.
데이터를 위한 질의 언어
SQL : 선언형
IMS, 코다실 : 명령형
프로그래밍언어는 보통 명령형이다.
- 명령형은 보통 순서랑 연산을 수행하도록 컴퓨터에게 지시한다.
SQL은 어떻게 가져와라! 하는 방법이 아니라 그 결과에 필요한 조건과 데이터 변환(정렬, 그룹화, 집계)를 지정하기만 하면 된다. -> 선언하는거니까
- 그러면 최적화는 최적화기가 알아서 해줌^~^
- 이 장점은 명령형보다 간결하고, 특히 중요한것은 상세 구현이 숨겨져있어 질의 변경 없이 성능 향상이 가능하다는것
- 병렬 실행에도 적합하다.
- 얘는 명령의 순서가 있는것도 아니라 그냥 조건대로 가져만 와라 하는거라 병렬에 더 좋음
웹에서의 선언형 질의
CSS같은것도 선언형이다(어디가 어떻게 변경되는걸 원하고 뭐 어찌 되는지는 관심없)
- 그거를 javascipt의 코어DOM 명령형을 쓰면 삭제되거나 태그 변경 등에 따라 코드를 바꾸어 주어야하거나 코드도 굉장히 길고 난해해진다.
맵리듀스 질의
이거 자바에서 스트림할때도 봤지
읽기 전용 질의를 수행할 때에 사용된다.
여기서는 몽고DB모델 사용에 대해서
- 선언형도 아니고 명령형도 아닌 어딘가
- 처리 프레임워크가 반복적으로 호출하는 조각 코드
- map, reduce함수 기반
제약사항이 있는데, 순수함수여야한다(입력으로 전달된 데이터만 사용가능, 추가적인 데이터베이스 질의 수행 불가, 사이드이펙트 없음)
- 요런 제약이 있어서 DB가 임의 순서로 어디서나 이 함수를 실행가능. 또 장애가 있어도 함수 재실행 가능
참고로 이거 좋긴 한데 이것만 쓸수 있는것도 아니고 작성이 어려울수도 있다.
JSON기반을 쓰는 집계 파이프라인이라는것도 있다.
GraphDB
오랜만에 본다...
다대다가 많으면 GraphDB를 쓴다.
그래프디비는 정점(노드 혹은 엔티티)랑 간선(관계 혹은 호)
속성 그래프 모델
- 네오포제이, 타이탄, 인피니티그래프 등
트리플 저장소 모델
- Datomic, 알레그로그래프 등
속성 그래프
정점
- 고유 식별자
- 유출 간선 집합
- 유입 간선 집합
- 속성 컬렉션(키-값 쌍)
간선
- 고유 식별자
- 간선이 시작하는 정점(꼬리정점)
- 간선이 끝나는 정점(머리 정점)
- 두 정점 간 관계 유형 설명하는 레이블
- 속성 컬렉션(키-값 쌍)
정점은 다른 정점과 간선으로 연결된다. 특정 유형과 관련 여부를 제한하는 스키마는 없다.
정점이 주어지면 정점의 유입과 유출 간선을 효율적으로 찾을 수 있고 그래프를 순회할 수 있다. 즉 일련의 정점을 따라 앞뒤 방향으로 순회
다른 유형의 관계에 서로 다른 레이블을 사용하면 단일 그래프에 다른 유형의 정보를 저장하면서도 데이터 모델을 깔끔하게 유지 가능
국가마다 지역 구조가 다른것같은 RDB로 보여주기 힘든것도 얘는 쉽게 보여줄 수 있음
사이퍼 질의 언어
속성 그래프를 위한 선언형 질의 언어
예를 들어
미국에서 유럽으로 이민 온 모든 사람들의 이름 찾기를 한다면?- person에서 name이 US인 속성을 갖는 location이 될 때 까지 born_in간선을 따라감
- person에서 name이 eurpe인 속성을 갖는 location이 될 때 까지 live_in간선을 따라감
- 이거 두개가 MATCH되면 됨
이런 식으로 하면 수행의 상세한 것을 지시하지 않아도 최적화된 방법을 알아서 찾아간다(선언형)
SQL의 그래프 질의
RDB도 가능하다. 근데 어렵다.
재귀 공통 테이블 식? 을 쓴다고 한다..
트리플 저장소와 스파클
속성 그래프 모델과 거의 동등하다.
이거는 모든 정보를 주어, 서술어, 목적어처럼 간단한 세 부분 구문형식으로 저장한다.
주어
- 정점과 동등
목적어
- 문자열이나 숫자 등의 원시 데이터타입의 값
- 그래프의 다른 정점
시맨틱 웹
이미 사람이 읽을 수 있는 텍스트와 그림으로 정보를 게시하고 있으니 컴퓨터가 읽게끔 기계가 판독 가능한 데이터로도 정보를 게시하는건 어떨까? 하는 개념
자원기술프레임워크(RDF)는 서로 다른 웹사이트가 일관된 형식으로 데이터를 게시하기 위한 방법 제안
일단 지금은 잘 안쓰기는 한데 좋은 작업이 있음.
RDF데이터 모델
이거는 결국 인터넷에 있는 정보 교환을 위해 설계하는 것이다.
그래서 주어, 서술어, 목적어는 주로 URL이다.
스파클 질의 언어
구조적으로 사이퍼랑 비슷
얘는 근데 속성이랑 간선을 따로 구분하지 않고 서술어를 사용하기 떄문에 보기 더 쉽고 동일한 구문 사용 가능
데이터로그
질의 언어의 기반이 되는 초석을 제공하는 오래된 녀석
얘는 (주어, 서술어, 목적어) 형태의 트리플과는 다르게
서술어(주어, 목적어) 로 작성한다.
정리
요구사항에 맞춰서 어떤걸 쓸지 찾아보는게 중요
NoSQL
- 문서형 : 서로 연관은 없고 데이터가 문서 자체인 경우 좋음
- 그래프 : 서로 연관이 있을거라고 잠재적으로 생각하고 ㄱㄱ
### 3색 정리
- 이거는 다른사람도 꼭 알아야 한다.(아주 중요)
- ID는 아무런 의미가 없기 때문에 변경할 필요가 없다(34p)
- 예전에 공부했던 내용중 자연키vs인조키 관련인데 이거 은근 중요한 내용이라 생각해서 적었다.
- 선언형 / 명령형 언어에 대해(43p~)
- java stream에 대해 처음 배울 때에도 선언형에 대해 배웠는데, 실제로 장점을 알 수 있었다.
- 그래서 인덱스 생성이랑 질의가 달라도 옵티마이저가 알아서 최적화를 잘 해주는걸까? 싶은 느낌
- 근데 약간의 블랙박스 너낌
- 이거는 알면 좋을 것 같다.(빨간거 다음으로 중요)
- 문서형 데이터베이스와 관계형 데이터베이스의 통합(42p)
- 둘이 점점 비슷해지는게 있어보인다.
- RDB에 json같은거 넣을 수 있는게 기억난다
- 그리고 RDB에서도 join이 많은것을 지양해서 집계테이블을 만들고 있는데, 두개를 합치면 되게 좋아보임
- 예를 들어 책(좋아요한사람-json, 댓글상위몇명-json, 댓글갯수총합-int 등)
- 이거는 내가 개인적으로 흥미로웠다.(마음에 들었다)
- 데이터 지역성(41p ~)
- 아예 저장할때 부모 밑에 넣어버리는 방식인게 신기했다.
- 근데 이거는 좀 궁금한게 몇개 있는데
1. 여러 부모에게 소속되는 경우(예를들어 악어가죽 → 가방, 지갑 등에서 사용 등..)
1. 이런거는 가장 많이 사용되는 부모 아래에 일단 두는게 맞을것같기도 한데 모르겠다.
2. 만약 변경된다면??
1. 내가 이직을 하면 현대차→류찬 에서 카카오→류찬 이렇게 바뀔텐데 RDB의 업데이트는 주소를 그대로 두고 변경하지 않나 싶어서 지역성이 깨지지는 않을까? 싶었다.