데이터중심 애플리케이션 설계 - 3장 [저장소와 검색] 리뷰 - 3 : 트랜잭션 처리 / 분석

트랜잭션 처리나 분석

• 데이터베이스를 트랜잭션 처리 뿐만이 아니라 데이터 분석에도 점점 더 사용하기 시작
• OLTP (Online Transcation Processing) / OLAP (Online Analytic Processing) 
• 초반에는 트랜잭션 처리와 분석 질의를 위해 동일한 데이터베이스를 사용
• OLTP 시스템을 분석 목적으로 사용하지 않고 개별 데이터 베이스에서 분석을 수행하려 함 
  • 이 개별 데이터베이스를 데이터 웨어하우스라고 부름

 

데이터 웨어하우징

• OLTP 시스템 사업 운영에 대단히 중요 - 일반적으로 높은 가용성 /  낮은 지연시간의 트랜잭션 처리를 기대
• 이 때문에 비즈니스 분석가가 OLTP 데이터베이스에 즉석 분석 질의(ad hoc anaytic query)를 실행하는 것을 꺼려함
• 데이터 웨어하우스는 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스
• 데이터 웨어하우스는 회사 내의 모든 다양한 OLTP 시스템에 있는 데이터의 읽기 전용 복사본
• 데이터 웨어하우스로 데이터를 가져오는 과정을 ETL(Extract-Transform-Load)라고 함

 

분석용 스키마: 별 모양 스키마 / 눈꽃송이 모양 스키마

• 대다수의 데이터 웨어하우스는 star schema로 알려진 방식을 사용 -> 정형화 방식 
• star schema는 fact table + dimension tablefact table
  • fact table의 각 로우 - 특정 시각에 발생한 이벤트에 해당(구매 이력)
  • fact table의 각 칼럼 - dimension table 
    : 이벤트의 속성인 누가, 언제, 어디서, 무엇을, 어떻게, 왜를 나타냄(상품, 가게 등)

https://docs.microsoft.com/ko-kr/power-bi/guidance/star-schema

• 눈꽃스키마(snowflake schema) -  dimension이 하위 dimension으로 더 세분화 됨

https://unabated.tistory.com/entry/%EB%8B%A4%EC%B0%A8%EC%9B%90-%EB%AA%A8%EB%8D%B8%EB%A7%8112

• 눈꽃 스키마는 star schema보다 더 정규화 됐지만 분석가들은 더 쉽다는 이유로 star schema를 더 선호함

칼럼 지향 저장소

• fact table에 대량의 로우와 페타바이트 데이터가 있다면 효율적으로 저장하고 질의하기 어려움
• 일반적인 데이터 웨어하우스 질의는 한 번에 4개 또는 5개 정도의 칼럼만 접근
• 대부분의 OLTP 데이터베이스에서 저장소는 로우 지향 방식으로 데이터를 배치
• 문서 데이터베이스에서 전체 문서는 보통 하나의 연속된 바이트 열로 저장
• 칼럼 지향 저장소의 기본 개념 - 각 칼럼별로 모든 값을 함께 저장함(모든 값을 하나의 로우에 저장하지 않음 )
• 칼럼 지향 저장소 배치는 칵 컬럼 파일에 포함된 로우가 모두 같은 순서
  • 로우의 전체 값을 다시 모으려면 개별 칼럼 파일의 n번째 항목을 가져온 다음 테이블의 n번째 로우 형태로 함께 모아 구성이 가능

칼럼 지향 저장소의 특징

• 칼럼 압축률 향상
  • 칼럼 별로 데이터를 저장하기 때문에 비슷한 크기의 데이터가 반복해서 나타남
  • 이는 압축을 하기에 매우 좋음

압축된 단일 칼럼 : 비트맵 색인 저장소

• 메모리 대역폭과 벡터화 처리
  • CPU 주기를 효율적으로 사용하기에 적합
  • 칼럼 압축을 사용하면 같은 양의 L1 캐시에 칼럼의 더 많은 로우를 저장 가능

칼럼 저장소의 순서 정렬

• 칼럼 저장소에서 로우가 저장되는 순서가 중요하지 않음
• 하지만 순서를 도입해 이를 색인 매커니즘으로 사용 가능
• 각 컬럼을 독립적으로 정렬해 버리면 더 이상 칼럼의 어떤 항목이 동일한 로우에 속하는지 알 수 없게 됨
• 데이터베이스 관리자는 테이블에서 정렬해야 하는 칼럼을 선택할 수 있음
• 예를 들어 질의가 지난 달처럼 시간 범위를 목표로 한다면 1차 정렬 키를 date_key로 해야 함
• 그러면 질의 최적화기는 지난 달에 해당하는 로우만 스캔할 수 있으며 모든 로우를 스캔하기보다 훨씬 빠름
• 기본 정렬 칼럼에 고유 값을 많이 포함하지 않는다면 정렬한 후 기본 정렬 칼럼은 연속해서 같은 값이 길게 반복되기 때문에 칼럼 압축에 좋음

구체화 뷰

• 대부분의 데이터 웨어하우스 질의는 보통 COUNT, SUM, AVG, MIN, MAX 같은 집계 함수를 포함
• 동일한 집계를 다양한 질의에서 사용하는 것은 낭비이기 때문에 질의가 자주 사용하는 COUNT나 SUM을 캐시하는 방법 -> 
• 이런 캐시를 만드는 방법이 구체화 뷰(materialized view)
• 관계형 데이터 모델에서는 이런 캐시를 일반적으로 표준(가상) 뷰로 정의함
• 원본 데이터를 변경하면 구체화 뷰를 갱신해야 하는데 이런 갱신으로 인한 쓰기는 비용이 비싸기 때문에 OLTP 데이터베이스에서는 구체화 뷰를 자주 사용하지 않음
• 집계 값은 특정 질의에 대한 성능 향상에만 사용하고 데이터 웨어하우스는 가능한 한 많은 원시 데이터를 유지하려고 함

 

직접 접해본 내용들이 없어서 그런지 굉장히 생소하고 현재는 수박 겉핥기하는 느낌이다. 
이런 개념들이 있고, 이런 이유 때문에 사용하는 구나라고 인식만 할 수 있지,
해당 내용에 대해서 논의하고 다시 상기하는 데도 어려울 것 같다. 
추후에 다시 정독해볼 필요가 있을 것 같다.