[데이터 중심 애플리케이션 설계] 3장 3. OLTP와 OLAP, 데이터 웨어하우스, 정리

인메모리 데이터베이스

디스크는 전원이 꺼져도 데이터가 손실되지 않으며 램보다 가격이 저렴했다.

하지만 램이 점점 저렴해지며 데이터셋 대부분을 메모리에 보관하는 방식이 생겨났다. 혹은 여러 장비 간 분산해서 보관할 수 있는데 이런 이유로 인메모리 데이터베이스가 개발됐다.

인메모리 데이터베이스는 지속성을 목표로 하는데, 이를 위한 방법은

• 특수 하드웨어 사용
• 디스크에 변경 사항의 로그 기록 or 디스크에 주기적인 스냅숏 기록
• 다른 장비에 인메모리 상태 복제

트랜잭션 처리나 분석?

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

보통 애플리케이션은 색인을 사용해 일부 키에 대한 적은 수의 레코드를 찾는다. 레코드는 사용자의 입력을 기반으로 삽입되거나 갱신된다. (사용자 대상)

OLAP(온라인 분석 처리)

데이터베이스를 데이터 분석에도 점점 더 많이 사용하기 시작했다. 많은 수의 레코드를 스캔해 레코드당 일부 칼럼만 읽는 집계통계를 계산해야 한다. (분석가 대상)

데이터 웨어하우스

OLTP 시스템은 사업 운영에 중요하기 때문에 일반적으로 높은 가용성과 낮은 지연 시간을 기대한다. 데이터 웨어하우스는 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스이다.

데이터 웨어하우스는 회사 내의 모든 OLTP 시스템에 있는 데이터의 읽기 전용 복사본이다.

데이터 웨어하우스를 사용하는 큰 장점은 분석 접근 패턴에 맞게 최적화할 수 있다는 점이다.

 

OLTP 데이터베이스와 데이터 웨어하우스의 차이

표면적으로 둘 다 SQL질의 인터페이스를 지원하기 때문에 비슷해 보인다. 하지만 다수의 데이터 베이스 벤더는 트랜잭션 처리와 분석 작업 부하, 둘 중 하나를 최적화하는데 중점을 둔다.

 

분석용 스키마

별 모양 스키마

Star schema는 fact table + dimension table

• fact table의 각 로우 - 특정 시각에 발생한 이벤트에 해당한다.(ex. 구매 이력, 사용자 클릭)
• fact table의 각 칼럼(dimension table과 연결) : 이벤트의 속성인 누가, 언제, 어디서, 무엇을, 어떻게, 왜를 나타낸다.(상품, 가게 등) FK
• 가운데가 사실테이블, 외곽이 차원테이블이라 모양이 star

출처: https://roseline.oopy.io/18caed48-e3b1-4745-a69e-4b6e247cdf1d

눈꽃송이 모양 스키마

눈꽃송이 스키마는 star 스키마의 차원이 하위차원으로 더 세분화 된 것이다.

• star 스키마보다 더 정규화됐지만 분석가들은 star 스키마가 더 쉽다고 좋아한다.

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

 

 

칼럼 지향 저장소

질의에 필요한 칼럼을 디스크에서 읽어 적재하기

사실테이블의 로우가 차원테이블의 로우보다 훨씬 많기 때문에 사실 테이블에 질의하는 것에 집중해보자.

 

대부분의 OLTP 데이터베이스에서 저장소는 로우 지향 방식으로 데이터를 배치한다. 만약 어떤 질의에서, join 절에 해당하는 칼럼에색인이 있어도 모든 로우를 디스크로부터 메모리로 적재한 다음, 필터링을 해야한다. 이 작업은 오랜 시간이 걸릴 수 있다.

 

칼럼 지향 저장소는 각 칼럼을 개별 파일에 저장해 질의에 사용되는 칼럼만 읽고 구분 분석을 한다. 이 방식을 사용하면 작업량이 많이 줄어든다.

 

칼럼 압축

이번엔 데이터를 압축해 디스크 처리량을 더 줄이는 방법을 알아보자.

많은 값이 반복해서 나타나면 압축을 하기 좋다. 칼럼을 압축하는 다양한 방법 중 데이터 웨어하우스에 특히 효과적인 비트맵 부호화을 알아보자.

비트맵 부호화

보통 칼럼에서 고유 값의 수는 로우 수에 비해 적다.(ex. 소매 업체는 수십억개의 판매 거래가 있지만 고유 제품은 단지 십만 개이다.) 그럼 n개의 고유 값을 가진 칼럼을 가져와 n의 개별 비트맵으로 변환할 수 있다. 고유 값의 갯수 n이 너무 크다면 비트맵을 추가적으로 런 렝스 부호화할 수 있다.

출처: https://xonmin.tistory.com/38?category=1044208 ( 해당하면 1, 아니면 0 )

벡터화 처리

한 번에 처리하는 데이터(압축시킨 칼럼 데이터 = 비트맵 부호화한 데이터)의 양을 늘려서 CPU 사용률을 높이고, 처리 속도를 빠르게 하는 기법이다.

 

 

칼럼 저장소의 순서정렬

칼럼 저장소에서 로우가 저장되는 순서가 반드시 중요하지는 않다. 삽입된 순서로 저장하는 방식이 가장 쉽다. 각 칼럼에 대해서 독립적으로 정렬할 수는 없지만 특정 칼럼을 기준으로 각 로우를 정렬하는 것은 가능하다. 그 효과로, 질의 최적화기는 질의에 해당하는 로우만 스캔할 수 있어서 훨씬 빨라진다. 또한 특정 칼럼을 기준으로 정렬했을 때, 그 칼럼의 값이 같다면 다른 칼럼을 기준으로 2차 정렬도 가능하다.

정렬된 순서는 칼럼 압축에 도움이 된다. 기본 정렬 칼럼에 고유 값을 많이 포함하지 않는다면 정렬한 후 기본 정렬 칼럼은 연속해서 같은 값이 길게 반복되기 때문에 칼럼 압축에 좋다. (정렬하고 압축하면 당연히 효과가 좋겠지…)

 

칼럼 저장소에 쓰기

칼럼 지향 저장소, 압축, 정렬은 모두 읽기 질의를 더 빠르게 하지만 쓰기를 어렵게 한다는 단점이 있다. 해결책으로, LSM 트리를 이용해 모든 쓰기는 먼저 인메모리 저장소로 이동해 정렬된 구조에 추가하고 디스크에 쓸 준비를 한다. 충분한 쓰기가 모이면 디스크의 칼럼 파일에 병합하고 대량으로 새로운 파일에 기록한다.

구체화 뷰

데이터웨어하우스의 질의는 보통 SQL에 COUNT, SUM, AVG, MIN, MAX 같은 집계함수를 포함한다.

동일한 집계를 많은 질의에서 사용한다면 낭비이기 때문에 질의가 자주 사용하는 일부 COUNT나 SUM을 캐시해보자. 이런 방법 중 하나가 구체화 뷰다.

구체화 뷰는 디스크에 기록된 질의 결과의 실제 복사본이다. (관계형 데이터 모델의 가상 뷰와는 다르다.)

• 원본 데이터를 변경하면 구체화 뷰를 갱신해야 한다. (복사본이니까)

 

   데이터 큐브 || OLAP 큐브

     구제화 뷰 중 일반 사례.

출처 : https://appchemist.github.io/posts/DDIA-CH3/

각 로우나 칼럼에 같은 집계를 적용할 수 있고 1차원으로 축소한 요약(ex. 날짜와 상관없는 제품별 판매량)을 얻을 수도 있다.

 

장점: 특정 질의를 미리 계산했기 때문에 해당 질의를 수행할 때 매우 빠르다.

단점: 원시데이터에 질의하는 것과 동일한 유연성이 없다는 점.

 

 

정리!

저장소 엔진은 OLTP와 OLAP로 나눌 수 있다. 

---

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

사용자를 대면하여 대량의 요청을 처리. 색인을 사용해 일부 키에 대한 적은 수의 레코드를 찾는다.

LSM 트리

• 파일에 추가와 오래된 파일의 삭제만 허용하고 한번 쓰여진 파일은 절대 갱신하지 않는다.
• HBase, 루씬, 카산드라 등

B 트리

• 제자리 갱신 관점에서 덮어쓰기 할 수 있는 고정 크기 페이지의 셋으로 디스크를 다룬다.
• 주요 관계형 데이터베이스와 많은 비정형 데이터베이스

OLAP(온라인 분석 처리)

비즈니스 분석가가 사용하며 훨씬 더 적은 수의 질의를 다룬다. 하지만 대개 매우 다루기 어렵고 짧은 시간에 수백만 개의 레코드를 스캔해야 한다. 이렇게 많은 로우를 순차적으로 스캔해야 한다면 색인은 적절하지 않다. 대신 스캔할 데이터의 양을 최소화하기 위해 데이터를 매우 작게 부호하하는 것이 중요해졌다. ⇒ 칼럼 지향 저장소