데이터중심 애플리케이션 설계 #3 - 저장소와 검색

OLTP

초창기 비즈니스 데이터 처리는 커머셜 트랜잭션(commercial transaction)에 해당했다. 금전 거래가 아닌 영역으로 데이터베이스가 확장되었음에도 트랜잭션이라는 용어는 변하지 않고 논리 단위 형태로서 읽기와 쓰기 그룹을 나타내고 있다.

이러한 애플리케이션은 대화식이기 때문에 이 접근 패턴을 온라인 트랜잭션 처리 (OLTP)라고 한다.

OLAP

데이터베이스를 데이터 분석에도 점점 더 많이 사용하기 시작했고, 몇가지 전형적인 특성이 OLTP와 달라 특성에 맞춰 개발되었다. 우선 몇가지 전형적인 특성은 다음과 같다.

특성	OLTP	OLAP
주요 읽기 패턴	질의당 적은 수의 레코드, 키 기준으로 가져옴	많은 레코드에 대한 집계
주요 쓰기 패턴	임의 접근, 사용자 입력을 낮은 지연 시간으로 기록	대규모 불러오기(bulk import, ETL) 또는 이벤트 스트림
주요 사용처	웹 애플리케이션을 통한 최종 사용자/소비자	의사결정 지원을 위한 내부 분석가
데이터 표현	데이터의 최신 상태(현재 시점)	시간이 지나며 일어난 이벤트 이력
데이터셋 크기	기가바이트에서 테라바이트	테라바이트에서 페타바이트

데이터 웨어하우징

OLAP를 위한 데이터베이스를 데이터 웨어하우스라고 부른다.

OLTP 대개 사업 운영에 대단히 중요하기 때문에 일반적으로 높은 가용성과 낮은 지연 시간의 트랜잭션 처리를 기대한다. 그래서 데이터베이스 관리자는 OLTP 데이터베이스를 철저하게 보호하려고 한다. 그래서 비즈니스 분석가가 OLTP 데이터베이스에 즉석 분석 질의를 실행하는 것을 꺼려한다.

데이터 웨어하우스는 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별데이터베이스다. 

둘은 표면적으로 비슷해보이지만 내부적으로는 완전히 다르다.

분석용 스키마: star schema, snow flake schema

star schema: log 형태의 fact 테이블에 dimension 테이블들을 참조할 수 있도록 하는 스키마이다.

snow flake schema: star schema보다 더 정규화된 스키마이지만, 사용하기에는 조금 더 복잡할 수 있어 star schema가 더 선호된다.

칼럼 지향 저장소

대부분의 OLTP 데이터베이스에서 저장소는 로우 지향 방식으로 데이터를 배치한다. 하지만 OLAP에는 전체 데이터를 select * 형식으로 가져오는 경우가 적어 컬럼 방식으로 데이터를 배치하는 저장소를 많이 사용한다.

칼럼 지향 저장소는 칼럼 압축에 적합하다. 비트맵 부호화 같은 기법으로 데이터를 쉽게 압축할 수 있다. 데이터를 압축하면 같은 양의 L1 캐시에 칼럼의 더 많은 로우를 저장할 수 있고, 비트 AND와 OR 같은 연산자는 압축된 칼럼 데이터 덩어리를 바로 연살할 수 있게 설계할 수 있다. 이런 기법을 벡터화 처리라고 한다

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

질의를 빠르게 처리하는 다양한 방법이 있는데, materialized view나 data cube등이 있다. 

materialized view: 질의가 자주 사용하는 일부 count나 sum 정보를 집계해서 캐시해 둘 수 있다. 원본 데이터를 변경하면 구체화 뷰를 갱신해야한다. 원본데이터의 비정규화딘 복사본이기 때문이다.

data cube: OLAP 큐브라고도 하는데, 일반화된 구체화 뷰의 특별 사례이다. 특정 질의를 효과적으로 미리 계산했기 때문에 해당 질의를 수행할 때 매우 빠르다.