저장소와 검색 (2)

트랜잭션 처리와 분산

 

일반적인 온라인 어플리케이션에서는 여러 종류의 데이터가 사용자 입력을 기반으로 삽입되거나 갱신된다. 이는 클라이언트와 서버 간의 대화식이기에, 이 접근 패턴을 온라인 트랜잭션 처리( online transaction processing, OLTP )라고 한다. OLTP는 이익을 산출하는 비즈니스에 맞닿아 있기에 대부분의 데이터 베이스는 OLTP 에 맞추어 설계되고 발전되었다. 

 

하지만 시간이 지남에 따라 사람들은 데이터 베이스를 "데이터 분석 ( data analytic )" 목적으로도 많이 사용하기 시작했다. 데이터 분석은 기존 트랜잭션과 접근 패턴이 매우 다르다. 분석에 사용되는 쿼리는 사용자에게 원시 데이터만을 반환하지 않고, 많은 수의 레코드에 대한 집계 통계를 계산해야 했기 때문이다. 이러한 분석은 회사 경영진이 더 나은 의사결정을 하게끔 돕는 보고서를 제공한다. ( 이를 비즈니스 인텔리전스라고 한다 ) 이런 데이터베이스 사용 패턴을 트랜잭션 처리와 구별하기 위해 온라인 분석 처리( online analytic processing, OLAP )라고 한다.

 

처음에는 트랜잭션 처리와 분석 쿼리를 위해 동일한 데이터베이스를 사용했다. 그러나 1980년대 후반과 1990년대 초반 회사들은 OLTP 시스템을 분석 목적으로 사용하지 않고, 개별 데이터베이스에서 분석을 수행하는 경향을 보였다. 이 개별 데이터베이스를 데이터 웨어하우스( data warehouse )라고 부른다.

 

데이터 웨어하우징

 

OLTP 시스템은 대개 사업 운영에 대단히 중요하기에, 일반적으로 높은 가용성과 낮은 지연 시간의 트랜잭션 처리를 기대한다. 반면, 데이터 웨어하우스는 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스다. 그래서 보통 OLTP 시스템으로부터 데이터를 추출-변환하여 분석 친화적인 스카마에 적재한다. 이 과정을 ETL ( Extract-Transform-Load ) 라고 지칭한다.

 

ETL 도식도

 

SQL 은 일반적으로 분석 질의에 적합하기 때문에 데이터 웨어하우스의 데이터 모델은 가장 일반적인 관계형 모델을 사용한다. 표면적으로 데이터 웨어하우스와 관계형 OLTP는 동일한 SQL 인터페이스를 사용하기에 유사해보일 수 있다. 하지만 각각은 서로 다른 질의 패턴에 맞게 최적화되었기에 시스템의 내부는 완전히 다르게 동작한다. 

 

현재 재직 중인 회사에서 사용 중인 AWS 의 Redshift의 경우, 파르에이셀(ParAccel) 이라는 데이터 웨어하우스 벤더의 운영 버전이다. 파르에이셀 이외에도 테라데이터(Teradata), 버티카 (Vertica), SAP 하나 등도 데이터 웨어하우스 벤더들이다. 공통점은 값이 비싸다.

 

 

분석용 스키마

 

많은 데이터 웨어하우스는 별 모양 스키마( star schema ) (또는 차원 모델링 dimensional modeling )로 알려진 정형화된 방식을 사용한다. 스키마들의 중심에는 사실 테이블 ( fact table )이 존재한다. 비즈니스의 핵심이 되는 정보의 집합체 같은 존재이다. 사실 테이블은 여러 외래키를 지니는데, 외래키가 가리키는 다른 참조 테이블들을 차원 테이블 ( dimension table )이라고 한다.

 

별 모양 스키마 예시

 

위 예시에서, `fact_sales_table`은 사실 테이블이고, 이 테이블의 컬럼들이 참조하는 테이블은 차원 테이블이 되는 셈이다. 보통 사실 테이블은 개별 이벤트를 담는다. 이는 나중에 분석의 유연성을 극대화하기 위함이다. 물론 이것은 사실 테이블의 크기가 매우 커질 수 있다는 의미기도 하다. 실제로 애플, 월마트, 이마트 같은 대기업은 데이터 웨어하우스의 수십 페타바이트의 트랜잭션 내역이 있고, 이 중 대부분이 사실 테이블이다.

 

"별 모양 스키마"란 테이블 관계가 시각화될 때, 사실 테이블이 가운데에 있고 차원 테이블로 둘러싸고 있다는 사실로부터 비롯되었다. 이 템플릿의 변형을 눈꽃송이 모양 스키마 ( snowflake schema )라고 하며 차원이 하위차원으로 더 세분화된다.

 

칼럼 지향 저장소

 

사실 테이블에 엄청난 개수의 로우와 페타바이트 데이터가 있다면 효율적으로 저장하고 질의하기는 어렵다. 이 문제를 어떻게 해결할 수 있을까?

 

대부분의 OLTP 데이터베이스에서 저장소는 로우 지향 방식으로 데이터를 배치하지만, 데이터 웨어하우스는 칼럼 지향 방식으로 데이터를 배치한다. 칼럼 지향 저장소의 기본 개념은 간단하다. 모든 값을 하나의 로우에 함께 저장하지 않는 대신 각 칼럼별로 모든 값을 함께 저장한다. 그러면 질의에 사용된 칼럼만 읽고 구문 분석하면 된다.

 

칼럼 압축

 

칼럼 지향 저장소는 압축에 용의하다. 다양한 압축 기법이 있지만, 데이터 웨어하우스에서 특히 효과적인 방법은 비트맵 부호화 ( bitmap encoding ) 이다. 

 

보통 칼럼에서 고유 값의 수는 로우 수에 비해 적다. 고유 값 하나가 하나의 비트맵으로 맵핑되고, 각 로우는 한 비트를 가진다. 만약 로우가 해당 값을 가지면 비트는 1이고, 그렇지 않으면 0이다.