KilJaeeun commented 1 year ago

파트

3장. 저장소와 검색 끝 까지
발표자
송현주
발표 기간
- 4월 12일 오후 10시
  마감기한
4월 11일 오후 11시 59분
참고 링크
일정표 : https://clever-bull-d00.notion.site/bd201441d8a44c83a70375001278c850
책 : http://www.yes24.com/Product/Goods/59566585

jasonkang14 commented 1 year ago

https://jasonkang14.github.io/cs/column-oriented-storage

diana-jinhyeon commented 1 year ago

https://diana-an.tistory.com/49

hyunju-song commented 1 year ago

https://hazel-developer.tistory.com/310

KilJaeeun commented 1 year ago

https://fringe-viscount-cee.notion.site/3-5e25db54245a4132a22f208c9430bad5

dns02023 commented 1 year ago

https://quill-clutch-d78.notion.site/03-a824ea33565d46d998cde2927926c3b7

JSYoo5B commented 1 year ago

트랜잭션

비즈니스 데이터 처리는 데이터베이스 쓰기가 보통 커머셜 트랜잭션에 해당했음. (책에 좀 생략되어 있는데, 읽은 데이터를 바탕으로 쓰고, 다수 레코드/테이블에 영향을 주는 쓰기를 뜻하는 듯)

일부 레코드가 사용자 입력을 기반으로 삽입/갱신됨 -> 온라인 트랜잭션(OLTP)이라 했음
요청을 잘 처리만 하면 되던 OLTP에서, 그 요청 정보들을 분석하는 데이터 분석이 요구됨
데이터 분석은 많은 레코드를 읽어서, 가공한 데이터를 제공 (ex. 통계, 평균, 합 등 가공)
트랜잭션과 구분하기 위해 온라인 분석 처리(OLAP)라 불림

데이터 웨어하우징

OLTP는 low latency, high availability를 지향하도록 최적화 OLAP는 latency에 대한 jitter도 별로 안 높을테고, 넓은 레코드 범위 지향. 최적화 방식이 다름 이론상 둘이 같은 DBMS를 쓰는 것 같지만, 성능까지 적합한지 여부는 별개임

분석용 스키마

한 테이블을 기준으로 각 attribute가 다른 테이블의 외래키가 됨 -> 하나를 중심으로 -> 별모양 스키마 참조하는 테이블의 종류가 다양 -> 별의 가지가 갈라지는 것 같다 -> 눈꽃송이 스키마

칼럼 지향 저장소

분석을 할 때는 일부 칼럼(attribute)만 사용. 모든 레코드의 내용이 불필요한 경우가 많음 결국 레코드의 내용이 길어지면 locality가 떨어질 가능성이 높다 -> 아예 저장을 column 위주로 -> 칼럼 지향 저장소

칼럼 압축

칼럼 지향 -> 같은 속성의 다른 값들을 보관 -> 인코딩(압축) 가능

비트맵 색인: 자주 등장하는 값들을 보관하고, 각 값에 대해 비트맵으로 레코드를 표현 -> 주요 값 검색에 유리
평균 분포에 유리할 경우: 평균값과 그 차이 수준으로 표현 범위 축소 (이전 하둡 책에서 본듯?)

칼럼 위주로 저장하면 비슷한 데이터를 한번에 처리하기 쉬워지고, SIMD 등으로 성능 최적화가 가능 (이 부분 필요하면 미팅에서 설명해드림)

칼럼 지향 저장소의 순서 정렬

현재 칼럼을 기반으로 저번에 했던 SS테이블 등의 순서 도입하여 정렬이 가능함 ~~이거 읽긴 했는데 이해 안되서 다시 보고 정리할게요~~

morebo2ks / Designing_Data_Intensive_Application

4주차 스터디 #5

파트

발표자

발표 기간

마감기한