분석계 처리 및 열 지향 데이터베이스

분석계 처리는 무엇이 어려운가?

• 분석 자체에 너무 시간이 걸려 현실적인 시간 내에 처리를 완료할 수 없다 라는 문제가 자주 발생하는데, 이는 기존의 RDBMS 자신이 데이터웨어 하우스(이하 DWH)와 같은 작업 형태에 반드시 최적화되어 있지 않다는 것도 큰 요인임

• 여기서는 벤치마크 도구인 Star Schema Benchmark를 예를 들어 설명을 진행함

DWH 형의 테이블

• DWH가 성능 문제를 일으키기 쉬운 이유로서 가장 먼저 들 수 있는 것이 데이터 양과 레코드 수가 많아지는 것

• 상품 정보가 구매되는 테이블과 같이 원시 데이터를 축적하여 레코드 수가 많은 유형의 테이블을 팩트 테이블 마스터가 되는 각 테이블을 디멘션 테이블 이라고 함
• 디멘션 테이블의 예로는 Customer, Supplier, 부품 등으로 다양함

• 많은 DWH에서 팩트 테이블의 레코드 수는 억 단위의 거대한 크기가 되는 경우도 많이 볼 수 있음. 따라서 테이블 크기를 최대한 작게 하기 위해서도 각 열의 데이터 형식은 효율적인 것이 사용됨

• 팩트 테이블에는 구매자 ID, 제품 ID, 제조 업체 ID, 날짜 ID 등 다수의 ID가 존재하는 반면에 그것에 대응하는 디멘션 테이블을 개별적으로 필요로 함

select
	sum(lo_extendedprice*lo_discount) as revenue
from 
	lineorder, dates
where
	lo_orderdate = d_datekey
	and d_year = 1993
	and lo_discount between 1 and 3
	and lo_quantity < 25;

• 위의 쿼리 예제를 보면 1993년의 구매 이력을 모두 조회하고 있음 → 액세스하는 데이터의 양이 엄청 큼

레코드와 데이터 사이즈가 크다

• 주문 리스트 와 같은 테이블은 원시 데이터를 축적해 나가기 때문에 레코드 수가 방대해져 데이터 사이즈도 수백 GB ~ 수십 TB가 될 수 있음 → 이정도 데이터 처리 시, 당연히 디스크 I/O 많이 발생, 성능 크게 저하

• DWH 뿐 아니라 데이터베이스 설계 전반에서 말할 수 있는 내용으로 데이터 사이즈를 최대한 작게 만드는 것이 성능상에 있어 매우 중요함
• 얼마나 많은 데이터를 메모리에 캐시해 두어 저속의 디스크 I/O의 비율을 어떻게든 감소시키는 것이 데이터베이스 성능을 생각하는 데 있어 가장 중요한 것이라고 말할 수 있음

• 팩트 테이블의 데이터 형식으로 문자열보다 공간 효율성이 좋은 숫자가 사용되는 것은 주로 사이즈를 줄이기 위한 의도가 있음

• 또한 레코드 사이즈를 줄이기 위해 과거의 오래된 데이터를 삭제하는 것도 자주 추천됨

기존 RDBMS에 있어서의 과제

처리 대상이 아닌 열에도 액세스가 시행됨

• DWH의 SQL을 보면 테이블 정의 상에 많은 열을 가지고 있는 반면, SQL 문에서는 그 중 극히 일부 열 만을 사용함 (분석할 때는 제한된 열만 필요하기 때문에)

• 그러나 기존의 데이터베이스에서는 이러한 대량의 열 중 극히 일부밖에 사용하지 않는다 는 유형의 쿼리 처리 성능이 반드시 좋은 것은 아님

• 기존의 데이터베이스 에서의 처리 단위는 레코드. 열 1~10까지의 경우는 한 개 레코드 내의 각 열의 값이 물리적으로 인접하게 됨
• 한편, 데이터베이스 I/O 단위는 16KB 등의 블록 단위
• 블록 내에는 기본적으로 레코드의 모든 열 값이 포함되어 있음
• 10열 중 한 열만 필요로 하는 경우에도 I/O 단위는 블록이기 때문에 나머지 열도 강제로 I/O 되어 버림

• 웹 애플리케이션과 같이 기본 키 검색으로 1레코드만 처리하도록 하면, 몇 개의 열이 있더라도 한 블록밖에 I/O하지 않기에 성능 면에서 낭비가 없음
• 그러나 DWH는 수백만 레코드를 전체 검사하는 일도 드물지 않기에 그런 경우는 불필요한 열을 읽는 처리가 커다란 낭비

인덱스 설계가 매우 어려움

• 인덱스를 올바로 설계하기 위한 전제 조건이 무엇을 조건으로 검색할 것인지를 인덱스 만들기 전에 명확하게 알아야 한다는 것

• 분석계 쿼리에서는 비즈니스 담당자가 약간의 관점을 바꾸는 것만으로도 다른 인덱스가 필요하게 됨(예: 연별 매출 분석 → 월별 매출 분석 해버리면 (year, month, price) 다중 컬럼인덱스가 필요)

범위 검색으로 대량의 레코드에 매치하기

• 인덱스를 사용한다 해도 속도가 반드시 개선되지 않는 것이 DWH의 난감한 부분

• 인덱스 검색에서는 리프 블록을 읽어 일치하는 열 값의 행 번호를 취득한 다음, 일치하는 행 번호 각각에 대해 실제의 레코드를 읽고 나가는 2단계로 처리됨

• 분석계 쿼리에서의 문제는 검색에 인덱스가 사용 되었다 해도 일치하는 레코드가 너무나도 많아 대량의 랜덤 액세스가 발생하는 경우가 많다는 점임
• 시간 계열의 데이터가 축적된 테이블에서는 레코드가 인접해 있을 가능성이 높아 시퀀셜 리드로서 빠르게 레코드 취할 수 있음
• 그러나 시간 계열이 아닌 관점에서 검색하면 일치하는 팩트 테이블의 레코드가 군데군데 존재할 가능성이 많아 대량의 랜덤 리드가 발생함

• 인덱스 검색은 기본 키 검색과 같이 극히 제한된 수의 레코드만 일치하는 경우에는 신속하게 이뤄지지만, 수만 건 수준에서 대량의 레코드가 매치하면 저속인 HDD의 랜덤 읽기 성능으로 인해 풀 테이블 스캔보다 늦어지게 되는 일이 자주 있음

열 지향 데이터베이스란

• DWH 같은 테이블 구조와 SQL 문의 성질은 기존 데이터베이스와 잘 맞지 않는 경향이 있음 → 열 지향 데이터베이스가 후보가 될 기술

• 기존의 데이터베이스가 행을 처리 단위로 하고 있는 반면, 열 지향 데이터베이스는 열을 처리 단위로 하고 있는 것이 큰 차이임

• 기존의 RDBMS는 인덱스를 활용하는 것을 전제로 만들어져 있음. 인덱스를 사용하여 레코드 단위 기반 액세스를 최적화 할 수 있고, 참조도 갱신도 균형 있게 처리할 수 있음. 인덱스 검색은 랜덤 리드라는 특성상 한 개 레코드만이 일치하는 유형의 검색에서 가장 높은 성능을 낼 수 있음

• 이에 대해 열 지향 데이터베이스는 말 그대로 액세스 단위가 레코드가 아니라 열이 됨

열 지향 DB의 장점

단점

• 제품으로서의 성숙도가 낲다