[데이터설계] 3장, 저장소와 검색 - 트랜잭션

트랜잭션

OLTP(온라인 트랜잭션 처리)

애플리케이션이 일부 키에 대한 적은 수의 레코드를 찾는 대화 형식의 접근 패턴

- 사용자 대면이므로 대량의 요청을 받을 수 있음

- 부하 처리를 위해 애플리케이션이 작은 수의 레코드만 사용

- 애플리케이션은 키의 일부만 사용하는 레코드 요청, 저장소 엔진은 요청한 키의 데이터를 찾기 위해 색인 사용 (디스크 탐색 병목)

 

OLAP(온라인 분석 처리)

비즈니스 인텔리전스에 필요한 데이터베이스 패턴

- 비즈니스 인텔리전스: 비즈니스 분석가가 회사 경영진의 더 나은 의사결정을 돕도록 하는 질의

- OLTP보다 적은 수의 질의를 다룸

- 짧은 시간에 많은 수의 레코드 탐색 (디스크 대역폭 병목)

 

데이터 웨어하우스

- OLTP 시스템의 읽기 전용 복사본

- 데이터 분석가가 즉석 분석 질의를 하기 위해

- ETL: 데이터 웨어하우스로 데이터를 가져오는 과정

  > OLTP 데이터베이스에서 추출하고 분석 친화적인 스키마로 변환하여 데이터 웨어하우스에 적재

- 적은 양의 데이터는 일반적인 SQL 데이터베이스에 질의하거나 스프레이드 시트에서 분석 가능

---

별 모양 스키마(차원 모델링)

- 사실 테이블: 각 로우가 이벤트를 나타냄

- 차원 테이블: 누가, 언제, 어디서, 무엇을, 어떻게, 왜

- 분석의 유연성 극대화: 사실 테이블이 가운데에 있고 차원 테이블로 둘러싸고 있는 것

 

눈꽃송이 모양 스키마

- 별 모양 스키마에서 하위차원으로 더 세분화

 

---

로우 지향 방식
- 테이블에서 한 로우의 모든 값은 서로 인접하게 저장됨
- OLTP에서 사용
- 문서 데이터베이스와 유사, 하나의 연속된 바이트 열로 저장

칼럼 지향 저장소

- 각 칼럼별로 모든 값을 함께 저장

- 질의에 사용되는 칼럼만 읽고 구분 분석

- 사실 테이블: 100개 이상의 칼럼이 존재하지만, 일반적인 데이터 웨어하우스 질의는 한번에 4~5개의 칼럼에만 접근

 

- 각 컬럼 파일에 포함된 로우가 모두 같은 순서인 점에 의존

 

칼럼 압축

- 칼럼 지향 저장소는 칼럼 압축에 적합

 

비트맵 부호화

- 데이터 웨어하우스에서 효과적

- 고유 값의 수 < 로우 수 -> n개의 고유 값을 가진 칼럼을 가져와 n개의 개별 비트맵으로 변환

- 고유 값 하나가 하나의 비트맵, 각 로우는 한 비트를 가짐(값이 있으면 1, 없으면 0)

 

벡터화 처리

- 압축된 칼럼 데이터 덩어리를 AND와 OR 같은 연산자로 연산하도록 설계하는 것

 

칼럼 저장소의 순서 정렬

- 로우가 저장되는 순서는 중요하지 않음, 그러나 순서를 도입하면 색인 매커니즘으로 사용 가능

 ex) 시간 범위를 목표로 하면 지난 달에 해당하는 로우만 스캔 가능

- 칼럼 압축에 도움

 연속해서 같은 값이 길게 반복 -> 런 렝스 부호화

 첫 번째 정렬 키에서 가장 강력함

 

다양한 순서 정렬

- 복제 데이터를 서로 다른 방식으로 정렬하여 저장

- 데이터를 가리키는 포인터가 없고, 값을 포함한 컬럼만 존재함

 

칼럼 지향 저장소에 쓰기

- 칼럼 지향 저장소, 압축, 정렬: 읽기를 빠르게 하지만 쓰기를 어렵게 함

B 트리와 같은 제자리 갱신 접근 방식은 압축된 컬럼에서 불가능
  > 정렬된 테이블 중간에 있는 로우에 삽입을 원하는 경우 모든 칼럼 파일을 재작성해야하기 때문

- LSM 트리: 인메모리 저장소로 이동해 정렬 구조에 추가하여 디스크에 씀

 

집계: 데이터 큐브와 구체화 뷰

구체화 집계: COUNT, SUM 등을 캐시하여 만드는 것

- 구체화뷰: 디스크에 기록된 질의 결과의 실제 복사본

 > 원본 데이터 변경 시, 구체화 뷰 갱신 -> 쓰기 비용이 비쌈

- 가상뷰: 질의를 작성하는 단축키

 

데이터 큐브(= OLAP 큐브, 구체화 뷰)

- 원시 데이터에 질의하는 것과 동일한 유연성이 없음

- 가능한 한 많은 원시 데이터 유지 필요

- 특정 질의에 대한 성능 향상시에만 사용