KR101544560B1 - 대용량 데이터를 처리하기 위하여 ｓｑｌ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법 - Google Patents

Abstract

본 발명은 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 분석처리 서버의 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 관한 것으로서, (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계; (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계; (c) 상기 기초 쿼리의 결과 데이터를 상기 서버의 서버 캐시에서 검색하는 단계; (d) 상기 서버 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 서버 캐시에 저장하는 단계; 및, (e) 상기 확장 쿼리를 상기 기초 쿼리의 결과 데이터에 적용하여 상기 확장 쿼리의 결과 데이터를 획득하고, 획득된 결과 데이터를 상기 클라이언트로 전송하는 단계를 포함하는 구성을 마련한다.
상기와 같은 방법에 의하여, 요청된 쿼리 중 기본 쿼리의 데이터를 캐싱함으로써, 비즈니스 인텔리전스의 분석 환경에서 쿼리 실행 속도를 획기적으로 개선하여 사용자에게 분석처리 결과를 실시간으로 제공해줄 수 있다.

Description

대용량 데이터를 처리하기 위하여 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법 { An online analytical processing system for big data by caching the results and generating 2-level queries by SQL parsing }

본 발명은 클라이언트가 질의요청시 SQL파싱을 통해 기초 쿼리(Base Query)와 확장 쿼리(Extend Query)로 단계를 분리하여, 대용량 데이터 또는 빅데이터를 저장하는 데이터베이스로부터 상기 기초 쿼리에 의한 데이터를 가져와서 인메모리기반 서버 캐시에 저장하고, 상기 서버 캐시의 데이터로부터 확장 쿼리를 실행하여 필요 데이터를 추출하는, ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 관한 것이다.

일반적으로 비즈니스 인텔리전스(BI, Business Intelligence)는 기업의 방대한 데이터를 통계분석과 같은 정형 또는 비정형적인 방법으로 다양하게 분석하여 주거나 분석된 정보를 이해하기 쉽고 보기 좋은 보고서 형태로 가공하여, 비즈니스를 보다 합리적으로 진행시킬 수 있도록 지원하는 일련의 도구들을 말한다.

기업이 비즈니스를 하면서 쌓이는 데이터는 수없이 많다. 이러한 데이터는 비즈니스 현장의 생생한 내용을 전달하는 것으로서, 제대로 분석된다면 그 안에서 비즈니스에 필요한 정보를 뽑아낼 수 있다. 그러나 현장에서 축적된 상당량의 데이터로부터 의미가 있는 분석결과를 도출한다는 것은 그리 쉬운 작업이 아니다.

이러한 분석을 위해 많은 도구들이 개별적으로 개발되어 왔다. 예를 들어, 데이터 추출 및 변형(ETT) 도구, 다차원 데이터 분석을 위한 온라인 분석처리(OLAP) 도구, 보고서 작성을 위한 리포팅 도구, 데이터간의 숨겨진 연관성을 찾아주는 데이터 마이닝 도구 등이 대표적이다. 이들 일련의 도구들을 하나의 소프트웨어 제품군으로 형성한 것이 일종의 비즈니스 인텔리전스(BI)이다.

그러나 종래의 비즈니스 인텔리전스(BI)는 다양한 분석도구들을 모아 놓았으나, 사용자들은 다양한 분석도구들을 다루기 위해서 숙련된 지식을 갖추어야 했기 때문에 특정 분석이외에는 보편적으로 이용되기 어려웠다. 이런 점들을 개선하여, 웹 환경에서 데이터베이스를 조회하여 분석하는 레포팅 기술들이 제시되고 있다[특허문헌 1]. 또한, 온라인상에서 엑셀 인터페이스를 기반으로 하는 분석 보고서 작성 시스템 등도 제시되고 있다[특허문헌 2].

그런데, 최근, SNS, 쇼셜 미디어 등의 데이터에 대한 분석의 중요성이 계속적으로 커지면서 기업체의 제품에 대한 고객관리나 제품 홍보 등을 위한 빅데이터(Big data)를 수집하여 분석을 필요로 하는 기업들이 많아지고 있다. 빅데이터라는 용어는, 어느 정도 경과한 시간 내에 속한 데이터를 수집, 관리, 저장, 검색, 공유, 분석, 및 시각화하기 위한 보통의 소프트웨어 툴 및 컴퓨터 시스템으로는 다루기 어려운 수준의 데이터양을 갖는 데이터 셋(data set)에 대하여 주로 적용된다. 빅데이터의 사이즈 테라바이트, 엑사바이트, 또는 제타바이트의 범위를 가질 수도 있다. 빅데이터는 다양한 분야에 존재할 수 있는데, 웹로그(web logs), RFID, 센서 네트워크, 소셜 네트워크, 소셜 데이터, 인터넷 텍스트와 문서, 인터넷 검색 인덱싱, POS(point of sales) 데이터, 판매 기록, 의료 기록, 사진 기록, 비디오 기록, 및 전자상거래 등이 그 예이다.

이러한 빅데이터를 이용하여 분석하기 위하여 온라인 분석 프로세싱(OLAP; on-line analytical processing) 시스템이 도입되고 사용되는데, 이때 발생되는 가장 큰 문제점 중 하나는 데이터 처리 속도의 지연이다. 즉, 수많은 데이터를 처리하기 위한 시간이 길어짐으로 인해, 온라인 상에서 사용자가 체감적으로 굉장히 긴 시간을 기다린다.

도 1에서 보는 바와 같이, 종래 기술에 의한 온라인 분석 프로세싱 시스템은 사용자 단말에 설치되는 클라이언트, 상기 클라이언트의 데이터 요구사항을 처리하는 BI 서버, 및, 빅데이터를 저장하는 데이터베이스로 구성된다.

사용자는 웹브라우저 상에서 클라이언트를 통해 보고서 형태(또는 템플릿)를 만들고 해당 보고서 형태에 들어갈 데이터를 BI 서버에 요청한다(① 단계). 즉, 상기 클라이언트에서 작성된 보고서에서 추출한 데이터베이스 코드(DB코드), 쿼리(SQL 쿼리) 등 필요한 정보를 BI 서버로 전송한다. 다음으로, BI 서버는 데이터베이스를 연결하여 필요한 데이터를 요청한다(② 단계). 데이터베이스는 요청된 데이터의 셋(또는 쿼리 결과, 큐브 데이터 셋) 등을 검색하고 추출하여, 추출된 결과 데이터를 BI 서버로 전송한다(③ 단계). BI 서버는 데이터베이스로부터 수신한 필드 정보와 데이터를 압축하여 클라이언트로 전송한다(④ 단계).

상기와 같은 종래 온라인 분석 프로세싱 시스템은 원천 데이터가 천만 건이 넘는 순간부터, 앞서 쿼리 결과를 수신하기 위하여 10분 이상이 소요되는 경우가 빈번히 발생한다. 예를 들어, 특정 사이트의 경우, 4억 건 결과 조회만으로 5분이 넘게 소요된다. 데이터베이스의 데이터를 포맷하는 데에도 15~30초 사이의 시간이 소요된다.

이와 같이 데이터 처리 속도가 느린 이유는 데이터베이스에 요청하는 처리 속도가 급격히 떨어지기 때문이다. 데이터베이스는 통상 상용화되어 표준적인 DB(Database) 기능을 처리하는 데이터 서버를 이용한다. 이러한 상용화된 데이터베이스는 원천 테이블이 거대한 경우, 예를 들어, 데이터가 1억 개 이상되는 경우, 많은 데이터를 처리하기 위해 쿼리 처리 속도가 급격히 떨어진다.

특히, 뷰(View)의 기능을 사용하는 경우에도, 쿼리 처리 속도가 매우 느려진다. 일반적으로 뷰(View)란 하나 이상의 테이블로부터 데이터를 부분집합을 논리적으로 표현하는 것으로 실제 데이터를 가지고 있는 것이 아니라 결과를 하나의 SQL로 가지고 있다. 뷰(View)는 액세스를 제한하기 위해 사용하거나 복잡한 질의를 쉽게 만들 수 있지만 요청할 때마다 내부적으로 SQL를 실행한다. 따라서 원천의 뷰(View)가 거대하거나 복잡한 경우, 연결된 뷰(View)도 느려지는 경우가 발생한다. 또한, 쿼리 내에 조인(Join) 함수 등의 기능을 사용하여 쿼리 자체가 복잡한 경우에도, 그 처리 속도가 매우 느려진다.

상용화된 데이터베이스는 상기와 같은 문제점을 해결하고자 자체적으로 쿼리를 튜닝하여 보다 빠르게 쿼리를 처리하는 솔루션을 가지고 있다. 그러나 이러한 튜닝도 일반적인 상황을 대비한 것이므로, 자체 시스템에 대한 튜닝만으로는 어느 정도 한계를 갖기 때문에, 쿼리 속도 자체를 획기적으로 개선할 수 없다.

예를 들어, 상용화된 데이터베이스는 일반적이고 표준화된 경우만을 대처하기 때문에, 동일하거나 비슷한 쿼리 요청에 대해서 동일한 작업을 반복적으로 수행한다.

상기와 같은 문제로 인해, 종래기술에 의한 온라인 분석 프로세싱(OLAP) 시스템은 온라인 상에서 매우 긴 대기 시간을 발생시키고, 사용자에게 사용상 큰 불편함을 야기한다.

[특허문헌 1] 한국등록특허 제10-0497811호 (2005.06.18.공고) [특허문헌 2] 한국등록특허 제10-0969656호 (2010.07.14.공고)

본 발명의 목적은 상술한 바와 같은 문제점을 해결하기 위한 것으로, 클라이언트가 질의 요청시 SQL 파싱을 통해 기초 쿼리와 확장 쿼리로 분리하여, 대용량 데이터 또는 빅데이터를 저장하는 데이터베이스로부터 상기 기초 쿼리에 의한 데이터를 가져와서 인메모리 기반 서버 캐시에 저장하고, 상기 서버 캐시의 데이터로부터 확장 쿼리를 실행하여 의해 필요 데이터를 추출하는, ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 제공하는 것이다.

상기 목적을 달성하기 위해, 본 발명은 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 분석처리 서버의 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 관한 것으로서, (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계; (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계; (c) 상기 기초 쿼리의 결과 데이터를 상기 서버의 서버 캐시에서 검색하는 단계; (d) 상기 서버 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 서버 캐시에 저장하는 단계; 및, (e) 상기 확장 쿼리를 상기 기초 쿼리의 결과 데이터에 적용하여 상기 확장 쿼리의 결과 데이터를 획득하고, 획득된 결과 데이터를 상기 클라이언트로 전송하는 단계를 포함하는 것을 특징으로 한다.

또한, 본 발명은 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 분석처리 서버의 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 관한 것으로서, (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계; (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계; (c) 상기 기초 쿼리의 결과 데이터를 상기 서버의 서버 캐시에서 검색하는 단계; (d) 상기 서버 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 요청 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 요청 쿼리의 결과 데이터를 상기 클라이언트로 전송하는 단계; 및, (e) 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 서버 캐시에 저장하는 단계를 포함하는 것을 특징으로 한다.

또한, 본 발명은 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서, 상기 서버는 상기 확장 쿼리의 결과 데이터를 캐시파일로 상기 서버 캐시에 저장하고, 상기 방법은, (f) 상기 (b)단계 이후, 상기 확장 쿼리의 캐시파일이 상기 서버 캐시에서 검색되는 경우, 검색된 캐시 파일을 클라이언트로 전송하는 단계를 더 포함하는 것을 특징으로 한다.

또한, 본 발명은 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서, 상기 (a)단계에서, 상기 컬럼명을 식별할 수 있는 고유키를 생성하고, 상기 (b)단계에서, 상기 기초 쿼리의 참조항목 절에서 상기 컬럼명에 대하여 상기 고유키로 앨리어스(alias)를 정의하고, 상기 확장 쿼리는 상기 앨리어스를 이용하여 컬럼을 참조하는 것을 특징으로 한다.

또한, 본 발명은 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서, 상기 고유키는 해당 컬럼명의 데이터베이스의 이름, 참조 테이블의 이름, 및 컬럼명을 해쉬하여 구하는 것을 특징으로 한다.

또한, 본 발명은 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서, 상기 (b)단계에서, 상기 기초 쿼리는 참조항목 절, 테이블 참조 절, 및 조건 절로 구성되고, 상기 기초 쿼리의 테이블 참조 절과 조건 절은 상기 요청 쿼리의 테이블 참조 절과 조건 절과 동일한 구조를 갖는 것을 특징으로 한다.

또한, 본 발명은 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서, 상기 (b)단계에서, 상기 확장 쿼리는 테이블 참조 절에서 상기 기초 쿼리 또는 상기 기초쿼리의 결과 데이터를 참조하고, 상기 테이블 참조 절 이외의 절이 상기 요청 쿼리의 절과 동일한 구조를 갖도록 생성되는 것을 특징으로 한다.

또한, 본 발명은 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서, 상기 (b)단계에서, 상기 요청 쿼리에서 테이블에 대한 앨리어스(alias)가 정의된 경우, 상기 테이블의 앨리어스를 삭제하고 상기 테이블의 앨리어스를 상기 테이블의 이름으로 대체하여 상기 확장 쿼리를 생성하는 것을 특징으로 한다.

또한, 본 발명은 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서, 상기 서버 캐시는 인메모리 스토리지와 캐시 디스크로 구성되고,상기 요청 기초 쿼리의 결과 데이터를 상기 인메모리 스토리지에 저장하는 특징으로 한다.

상술한 바와 같이, 본 발명에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 의하면, 요청된 쿼리 중 기본 쿼리의 데이터를 캐싱함으로써, 비즈니스 인텔리전스의 분석 환경에서 쿼리 실행 속도를 획기적으로 개선하여 사용자에게 분석처리 결과를 실시간으로 제공해줄 수 있는 효과가 얻어진다.

도 1은 종래 기술에 따른 온라인 분석 프로세싱 시스템의 구성도.
도 2는 본 발명에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 실시하기 위한 전체 시스템의 구성에 대한 블록도.
도 3은 본 발명의 제1 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 설명하는 흐름도.
도 4는 본 발명의 제1 실시예에 따른 요청 쿼리의 일례.
도 5는 본 발명의 제1 실시예에 따른 기초 쿼리 및 확장 쿼리의 일례.
도 6은 본 발명의 제2 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 설명하는 흐름도.
도 7은 본 발명의 제3 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 설명하는 흐름도.
도 8은 본 발명의 제4 실시예에 따른 서버 캐시의 구성도.
도 9는 본 발명에 따른 제1 상황을 설명하기 위한 흐름도.
도 10은 본 발명에 따른 제2 상황을 설명하기 위한 흐름도.
도 11은 본 발명에 따른 제3 상황을 설명하기 위한 흐름도.
도 12는 본 발명의 상황에 따른 처리 결과에 대한 비교 표.

이하, 본 발명의 실시를 위한 구체적인 내용을 도면에 따라서 설명한다.

또한, 본 발명을 설명하는데 있어서 동일 부분은 동일 부호를 붙이고, 그 반복 설명은 생략한다.

먼저, 본 발명에 따른 기초 쿼리의 결과 캐싱 기반 온라인 분석 프로세싱 시스템 및 방법을 실시하기 위한 전체 시스템을 도 2를 참조하여 설명한다.

도 2에서 보는 바와 같이, 본 발명을 실시하기 위한 전체 시스템은 클라이언트(20), 분석처리 서버(30), BI 서버(50), 및 데이터베이스(60)로 구성된다. 특히, 분석처리 서버(30)는 데이터베이스(60)로부터 수신한 일부 데이터를 저장하기 위한 서버 캐시(40)를 구비한다.

클라이언트(20)는 사용자 단말(10)에 설치되는 클라이언트용 프로그램 시스템으로서, 웹브라우저를 통해 사용자 인터페이스를 갖는다. 즉, 사용자는 웹브라우저 또는 웹브라우저와 같은 화면의 인터페이스를 통해, 온라인상으로 데이터 분석 처리 작업을 수행한다. 이때, 클라이언트(10)는 사용자의 명령 등을 입력받아 해당 명령을 수행하고, 처리 결과를 화면 상 또는 웹브라우저 상에 표시한다. 한편, 사용자 단말(10)은 개인용 컴퓨터(PC), PDA, 스마트폰 등 컴퓨팅 기능을 가지는 컴퓨터 단말이다.

또한, 클라이언트(20)는 데이터 요청, 데이터 분석 등 온라인 상으로 분석 처리하는 작업을 분석처리 서버(30)에 요청하고, 그 결과를 서버(30)로부터 가져와서 웹브라우저 상에 표시한다.

다음으로, 분석처리 서버(30)는 온라인 분석 프로세싱(OLAP)을 처리하는 서버로서, 클라이언트(20)로부터 데이터 분석에 대한 요청을 수신하여, 해당 분석 요청을 처리하여 그 결과를 클라이언트(20)로 전송하는 서버이다.

특히, 분석처리 서버(30)는 데이터를 요청하는 쿼리를 이용하여, 데이터베이스(50)에 저장된 데이터를 가져온다. 쿼리는 데이터베이스에 저장된 데이터의 검색 또는 갱신 시 발생하는 질문 또는 문의를 기술하는 데이터 조작언어를 의미하며, 데이터베이스에서 쿼리는 일종의 명령어와 같은 역할을 수행한다. 관계 데이터베이스의 구조적 질의 언어(Structured Query Language : 이하 SQL)의 형식으로 표현되지만, 경우에 따라서는 SQL 이외의 형식으로 표현될 수도 있다.

또한, 분석처리 서버(30)는 서버 캐시(40)를 구비하여, 데이터베이스(60)로부터 가져온 데이터 전체 또는 일부를 임시로 저장한다. 서버 캐시(40)는 분석처리 서버의 메모리(RAM 등) 상에 구현되어 캐시 메모리로서 구성되거나, 하드 디스크 또는 SSD(solid state disk) 디스크 등으로 구현되어 캐시 디스크로 구성될 수 있다. 또는 모든 데이터를 디스크로 저장하고, 일부의 데이터, 즉, 필요한 데이터를 캐시 메모리로 올려놓고 사용할 수 있다.

다음으로, BI 서버(50)는 데이터베이스(50)를 중계하는 데이터베이스(DB) 인터페이스 서버 역할을 수행한다. 즉, BI 서버(50)는 분석처리 서버(30)로부터 쿼리를 수신하여, 해당 쿼리를 이용하여 데이터베이스(60)의 데이터를 가져온다. 또는 데이터베이스(60)의 DBMS에 요청하여 해당 데이터를 가져온다.

또한, BI 서버(50)는 이질적인 다수의 데이터베이스(60)로 구성되더라도 해당 데이터베이스와의 인터페이스 방식에 맞추어, 쿼리를 요청하거나 데이터를 수신한다. 또한, BI 서버(50)는 데이터를 송수신할 때 암호화하거나, 데이터 압축, 또는 파일 압축 등 데이터 송수신을 위한 부가적인 작업들도 수행한다.

다음으로, 데이터베이스(60)는 데이터를 저장하기 위한 통상의 데이터베이스(DB)로서, 데이터를 관리하기 위한 DBMS를 구비하고, 데이터의 저장, 삭제, 검색 등의 작업들을 쿼리를 통해 수행한다. 특히, 데이터베이스(60)는 상용화된 데이터베이스로서, 데이터를 처리하기 위한 일반적인 쿼리 기능을 이용하여, 데이터 쿼리 서비스를 수행한다.

특히, 데이터베이스(60)는 빅데이터를 저장하는 데이터베이스이다. 또한, 바람직하게는, 데이터베이스(60)는 관계형 데이터베이스(RDB)로 구성된다.

다음으로, 본 발명의 제1 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 도 3을 참조하여 보다 구체적으로 설명한다.

도 3에서 보는 바와 같이, 본 발명의 제1 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법은 (a) 요청 쿼리를 수신하여 파싱하는 단계(S11); (b) 기초 쿼리 및 확장 쿼리를 생성하는 단계(S12); (c) 기초 쿼리의 결과를 서버 캐시에서 검색하는 단계(S13); (d) 검색되지 않으면, 기초 쿼리를 데이터베이스에서 가져와서 서버 캐시에 저장하는 단계(S14); (e) 상기 기초 쿼리의 결과에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득하는 단계(S15); 및, (f) 요청 쿼리의 결과를 전송하는 단계(S16)로 구성된다.

먼저, 요청 쿼리를 수신하여 파싱하는 단계(S11)를 설명한다. 분석처리 서버(30)는 클라이언트(20)로부터 요청 쿼리를 수신하고, 상기 요청 쿼리를 파싱한다(S11).

사용자 단말(10)에 설치된 클라이언트(20)에서, 필요한 데이터를 쿼리로 분석처리 서버(30)에 요청한다. 바람직하게는 요청 쿼리는 SQL 쿼리로 작성된다. 도 4는 요청 쿼리의 일례를 나타내고 있다.

SQL 쿼리로 작성된 요청 쿼리는 참조항목 절(SELECT 절), 테이블 절 및 조인 절(FROM 절), 조건 절(WHERE 절), 그룹 절(GROUP BY), 순서 절(ORDER BY) 등으로 구성된다. 참조항목 절(select list)은 원하는 데이터 테이블의 필드/컬럼을 정의하는 절이고, 테이블 절(table reference)은 데이터를 가져올 테이블을 정의하는 절이고, 조인 절(join clause)은 테이블 간의 조인을 정의하는 절이고, 조건 절(where clause)는 조건을 정의하는 절이다. 그리고 그룹 절(group by) 이나 순서 절(order by clause)는 집계나 표시 형태를 정의하는 절이다. 요청 쿼리에서 정의된 데이터 필드, 참조 테이블, 조건문에서의 변수 등은 모두 데이터베이스(60)에 있는 원천 데이터의 필드, 테이블 등을 참조한 것이다.

요청 SQL 쿼리의 파싱은 요청 SQL 쿼리의 구문을 분석하여, 컬럼 리스트(select list), 테이블 참조(table reference), 조인 절(join clause), 조건 절(where clause), 그룹 절(group by clause), 순서 절(order by clause) 등을 집합 형태로 추출하는 것이다.

특히, SELECT 절(또는 참조항목 절)의 참조항목에서 컬럼명을 추출한다. 또한, 조인 절, 조건 절, 그룹 절, 순서 절 등에서 참조하는 컬럼명들을 모두 추출한다.

요청 쿼리가 SQL 쿼리인 경우, 파싱을 위한 SQL 구문은 다음과 같다.

query_block

: (subquery_factoring_clause)?

SELECT (((DISTINCT | UNIQUE)| ALL)?) select_list

FROM ( table_reference | join_clause) (COMMA (table_reference | join_clause))*

where_clause?

hierarchical_query_clause?

group_by_clause?

order_by_clause?

| query_block ((UNION ALL?) | (INTERSECT | S_MINUS)) query_block

| LPAREN query_block RPAREN

특히, 참조항목이 계산식인 경우에 계산식 내에 포함된 컬럼명을 추출한다. 또한, 조건 절 등 다른 절에서 참조하는 조건이나 수식 등에서 사용되는 컬럼명들도 추출한다.

또한, 추출된 컬럼명에 대하여 다른 컬럼명과 식별할 수 있는 식별자 또는 고유키를 생성한다. 이때의 고유키는 컬럼의 절대이름에 대한 식별자(또는 고유키)이다. 절대이름이란 참조 데이터베이스의 이름, 참조 테이블의 이름, 컬럼명으로 구성된 이름을 말한다. 따라서 컬럼의 절대이름은 다음과 같이 표현될 수 있다.

컬럼의 절대이름 = <데이터베이스의 이름>.<테이블의 이름>.<컬럼명>

또는 데이터베이스를 굳이 식별하지 않으면 다음과 같이 표현될 수도 있다.

컬럼의 절대이름 = <테이블의 이름>.<컬럼명>

절대이름과 대비하여, 컬럼명을 컬럼의 상대이름이라고도 부르기로 한다.

컬럼명의 고유키는 컬럼명의 절대이름을 이용하여 해싱을 통해 구한다. 고유키를 생성하는 수식은 다음과 같다.

[수학식 1]

고유키 = hash( (domain name) + database name + table name + column name + function name)

따라서 컬럼명의 고유키는 컬럼들을 식별할 수 있는 식별자의 기능을 수행한다. 즉, 고유키로 컬럼을 식별할 수 있다.

컬럼명의 고유키는 기초쿼리 또는 요청쿼리를 생성할 때 앨리어싱(aliasing, 별칭)을 통해 각 컬럼명을 식별하는데 이용된다. 컬럼명의 고유키를 이용하여 기초쿼리의 컬럼명을 모두 별칭(alias)으로 기재하여, 기초쿼리에 의한 결과 데이터의 테이블에서의 컬럼명을 모두 고유키로 생성되도록 한다. 즉, 컬럼명을 식별자(또는 고유키)로 앨리어스(alias)하는 이유는 자동 생성된 쿼리에서 컬럼을 식별하기 위한 것이다.

예를 들면, 1번 쿼리과 2번 쿼리가 다음과 같다고 가정한다.

[1번 쿼리]

select t1. customer

from matirx_demo t1

[2번 쿼리]

select m.customer

from matrix_demo m

이 경우, 1번과 2번 쿼리에서 customer는 동일한 테이블의 동일한 컬럼이다. 하지만 alias키가 없기 때문에 t1.customer와 m.customer를 다르다고 판단할 수 있다.

또한, 1번과 2번 쿼리가 다음과 같다고 가정한다.

[1번 쿼리]

select t.id

from matrix_demo1 t

[2번 쿼리]

select t.id

from matrix_demo2 t

이 경우에도, 앨리어스(alias, 별칭)의 고유키가 없기 때문에 같게 보이나 실제로는 다른 컬럼들이다.

이때, 고유키를 적용하여 앨리어싱하면 다음과 같이 쿼리가 생성된다.

[1번 쿼리]

select t1. customer C9A59FD7B

from matirx_demo t1

[2번 쿼리]

2번 쿼리

select m.customer C9A59FD7B

from matrix_demo m

따라서, 고유키 “C9A59FD7B“만 보면 동일 데이터베이스명, 동일 테이블명, 동일 컬럼명, 동일 함수명인 것을 확인할 수 있다.

또한, 바람직하게는, 테이블 절에서 테이블명의 앨리어스(alias)를 제거하고, 테이블명의 앨리어스(alias)로 명명된 구문을 모두 원래의 테이블명으로 변경한다. 예를 들어, 앞서의 예에서, MATRIX_DEMO가 T로 앨리어스(alias)되어 명명되어 있다면 원테이블명(MATRIX_DEMO)으로 변경한다.

또한, 바람직하게는, 다수의 데이터베이스를 이용하는 경우, 테이블 참조절에서의 각 테이블명에 대한 테이블의 절대이름을 구한다. 테이블의 절대이름은 데이터베이스 이름과 테이블 이름으로 구성되고, <데이터베이스 이름>.<테이블 이름>으로 표현된다.

한편, 테이블 절과 조인(join) 절은 SQL 구문에서 "FROM"절에 포함된다. 즉, FROM 절은 테이블을 참조하기 위한 절로서, 테이블과 조인으로 구성된다. 따라서 이하에서 테이블 절과 조인 절을 포함된 절을 "테이블 참조 절"이라 부르기로 한다.

다음으로, 분석처리 서버(30)는 파싱한 요청 쿼리를 이용하여, 기초 쿼리와 확장 쿼리를 생성한다(S12).

기초 쿼리는 데이터베이스(60)의 데이터를 참조하여 요청하는 쿼리이고, 확장 쿼리는 기초 쿼리에 의해 추출된 데이터(또는 기초 쿼리의 결과 데이터)를 참조하여 요청하는 쿼리이다. 기초 쿼리와 확장 쿼리의 일례가 도 5에 도시되고 있다.

도 5에서 보는 바와 같이, 기초 쿼리(BaseSQL)에서, SELECT문에 기재된 "CUSTOMER", "PRODUCT", "C", "C2" 등 데이터 필드의 명칭나, "MATRIX_DEMO" 등 참조 테이블의 명칭이나, "YYYY" 등의 조건문의 변수(또는 데이터 필드의 변수)는 모두 데이터베이스(60)의 원천 데이터를 직접 참조한다.

먼저, 기초쿼리는 다음과 같이 생성한다.

SQL 파싱에서 추출한 컬럼명(또는 컬럼 리스트)으로 참조항목을 만든다. 이때, 바람직하게는, 요청쿼리의 참조항목이 계산식인 경우, 요청쿼리의 계산식에 포함된 컬럼명으로 기초쿼리의 참조항목을 생성한다. 또한, 조건 절 등 다른 절에서 참조하는 컬럼명들도 기초쿼리의 참조항목으로 생성한다.

도 4의 예에서, 요청쿼리의 3번째 참조항목은 "SUM(T.H_VAL)"의 계산식이다. 또한, 조건 절(where clause)에서 "T.YYYY = '2013'"은 조건이나 그 조건 내에 "T.YYYY" 컬럼명이 포함되어 있다. 따라서 도 5의 기초쿼리에서의 참조항목에는 계산식 "SUM(T.H_VAL)" 내의 컬럼명 "T.H_VAL"과, 조건 "T.YYYY = '2013'" 내의 컬럼명 "T.YYYY"을 참조항목 절의 참조항목으로 생성한다.

또한, 참조항목들에 컬럼명의 고유키를 앨리어싱(aliasing)을 한다. 즉, 고유키를 별칭으로 정의한다.

그리고 기초쿼리의 테이블 절(또는 테이블 참조절), 조인 절, 조건 절은 요청쿼리의 테이블 절, 조인 절, 조건 절과 동일하게 구성한다.

다만, 바람직하게는, 요청쿼리의 테이블 절에서 테이블명이 앨리어스(alias)되어 있으면, 앨리어스된 별칭을 삭제한다. 그리고 참조항목 절, 조인절, 조건 절에서 별칭이 기재된 테이블명을 모두 테이블의 이름(또는 절대이름)으로 변경한다.

예를 들어, 요청쿼리가 다음과 같은 경우를 설명한다.

[요청쿼리 1]

select t.customer, sum(t.h_val)

from matrix_demo t

where t.yyyy = ‘2013’

group by t.cusomer

이때, 상기 요청쿼리 1로부터 생성한 기초쿼리는 다음과 같다.

[기초쿼리 1]

SELECT MATRIX_DEMO.CUSTOMER C9A59FD7B, MATRIX_DEMO.YYYY CEB41FFF7, MATRIX_DEMO.H_VAL CB165E5C5

FROM MATRIX.MATRIX_DEMO

WHERE MATRIX_DEMO.YYYY = '2013’

즉, 요청쿼리에서 테이블 matrix_demo의 별칭(alias)을 "t"로 선언하였는데, 기초쿼리에서는 모두 테이블의 이름인 matrix_demo로 변경되었다.

다음으로, 확장쿼리를 생성한다.

확장쿼리는 테이블 절을 제외하고 요청쿼리와 동일한 구조를 갖고, 테이블 절에서 참조하는 테이블 대신 기초쿼리 또는 기초쿼리의 결과 데이터 테이블(기초쿼리가 원천 데이터베이스에서 쿼리하여 가져온 결과 테이블)을 참조한다.

또한, 컬럼명들을 모두 컬럼들의 고유키로 변환한다. 즉, 확장쿼리가 참조하는 테이블이 기초쿼리의 결과 테이블이므로, 참조하는 테이블의 컬럼들은 모두 기초쿼리에서 선언한 고유키로 참조하여야 한다.

앞서 [요청쿼리 1]과 [기초쿼리 1]에 의한 확장쿼리는 다음과 같다.

[확장쿼리 1]

SELECT MHC.C9A59FD7B, SUM(MHC.CB165E5C5) AS "CB165E5C5"

FROM ( {@ORIGINAL_SQL@} ) MHC

WHERE MHC.CEB41FFF7 = '2013'

GROUP BY

MHC.C9A59FD7B

여기서, "{@ORIGINAL_SQL@}" 는 기초쿼리 또는, 기초쿼리의 결과 테이블을 참조하는 것을 표시한다.

따라서 기초 쿼리에 의해 추출된 데이터가 획득되면, 확장 쿼리는 획득된 기초 쿼리의 결과 데이터를 참조하여 요청되는 쿼리이다. 확장 쿼리에 의해 구해지는 결과는 원래 요청 쿼리에 의해 구해지는 결과와 동일하다. 또한, 확장 쿼리에 의해 구해지는 결과 데이터의 집합은 항상 기초 쿼리에 의해 구해지는 결과 데이터의 집합 보다 작다. 즉, 확장 쿼리의 데이터 집합은 기초 쿼리의 데이터 집합의 부분 집합이라 할 수 있다.

또한, 기초쿼리의 결과 데이터가 없는 경우, [확장쿼리 1]에서, {@ORIGINAL_SQL@}에 기초쿼리를 대치하고 원천 데이비베이스의 질의하면, 요청쿼리의 결과를 얻을 수 있다.

다음으로, 기초 쿼리의 결과 데이터가 서버 캐시(40)에 저장되어 있는지를 검색한다(S13).

기초 쿼리에 의해 데이터베이스(60)로부터 가져온 데이터(또는 기초 쿼리의 결과 데이터)는 서버 캐시(40)에 저장하여 보관된다. 분석처리 서버(30)는 앞서 구한 기초 쿼리를 서버 캐시(40)에서 검색한다. 즉, 저장해둔 기초쿼리에 앞서 구한 기초쿼리가 존재하는지를 검색한다.

검색을 위한 비교 과정을 설명하면, 참조항목 절, 테이블 절/조인 절, 및, 조건 절이 동일한지 여부로 판단한다. 다면, 참조하는 테이블들(또는 테이블간의 조인도 포함됨)이 동일한 경우에는, 참조항목 절(SELECT 절)과 조건 절(where clasue)만 동일한가를 비교한다. 특히, 참조항목 절에서는 컬럼명의 고유키들만 비교하면 된다. 즉, 앨리어스(alias)들이 동일한지만 비교한다.

예를 들어, 본 출원인의 매트릭스(matrix)에서 사용되는 SQL는 메타를 이용해서 자동 생성된 SQL이다. 메타 아이템1과 메타 아이템 2를 선택했다면, 이미 해당 메타 아이템의 테이블 코드, 컬럼 코드, 조인 조건을 자동으로 생성할 수 있다. 같은 메타에서 자동 생성된 SQL는 필드 alias 비교만으로도 같다는 것을 알 수 있다. 즉, 추가로 조건 비교만 수행하면 기초쿼리를 재사용 여부를 체크할 수 있다. 하지만, 메타 없이 쿼리만 비교한다면 테이블 및 그들간의 조인 관계도 비교해야 한다.

다음으로, 기초 쿼리의 결과 데이터가 서버 캐시에 저장되어 있지 않으면, 상기 기초 쿼리로 데이터베이스(60)에 데이터를 요청하고, 기초 쿼리의 결과 데이터를 수신하면, 이를 서버 캐시(40)에 저장한다(S14).

앞서 설명한 바와 같이, 기초 쿼리는 데이터베이스(60)에 저장된 데이터를 직접 참조하는 쿼리이므로, 해당 기초 쿼리로 데이터베이스(60)에 쿼리 요청을 한다. 쿼리 요청은 BI 서버(50)를 통해 데이터베이스(60)에 요청되고, 데이터베이스(60)에서 상기 기초 쿼리에 의해 추출된 데이터는 BI 서버(50)를 통해 분석처리 서버(30)로 리턴된다. 분석처리 서버(30)는 수신한 상기 기초 쿼리의 결과 데이터를 서버 캐시(50)에 저장한다.

한편, 기초 쿼리의 결과 데이터는 데이터베이스(60)의 데이터 구조와 동일한 형태 또는 동일한 구조로 저장된다. 즉, 데이터베이스(60)의 데이터들이 테이블 형태로 저장된다면, 기초 쿼리의 결과 데이터도 테이블 형식으로 저장된다. 또한, 서버 캐시(40)에서 저장되는 결과 데이터의 각 필드의 타입이나 크기 등이 데이터베이스(60)에서 구성된 필드의 타입이나 크기와 동일하게 구성된다. 이것은 확장 쿼리가 데이터베이스(60)에 저장된 데이터 대신, 기초 쿼리의 결과 데이터를 참조하여도 쿼리가 실행되게 하기 위함이다.

이때, 결과 테이블의 컬럼명은 컬럼의 고유키로 변환된다.

다음으로, 분석처리 서버(30)는 기초 쿼리의 결과에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득한다(S15).

확장 쿼리는 요청 쿼리와 동일한 구조를 가지고 데이터베이스(60)를 참조하는 대신 기초 쿼리를 참조하는 쿼리이다. 따라서 확장 쿼리에서 데이터베이스(60)를 참조하는 명칭(이하 데이터베이스 참조 명칭)들을 기초 쿼리의 결과 데이터를 참조하는 명칭(이하 기초 쿼리 참조 명칭)들로 변경하여 생성된다. 앞서 설명한 바와 같이, 확장 쿼리에서 참조하는 테이블의 명칭은 기초 쿼리에 의해 생성된 테이블(또는 결과 테이블)을 참조하도록 모두 변경되고, 확장 쿼리에서 참조하는 데이터 필드의 명칭(또는 컬럼명)은 모두 기초 쿼리에 의해 생성된 데이터 필드의 명칭(또는 컬럼명의 고유키)들로 모두 변경된다.

앞서 S13 단계에서, 기초 쿼리의 결과 데이터가 서버 캐시(40)에 저장되어 있을 수도 있고, 없을 수도 있다. 그러나 저장되어 있지 않은 경우, S14 단계에서, 기초 쿼리로 데이터베이스(60)에 쿼리 요청하여 데이터를 받아 서버 캐시(40)에 저장한다. 따라서 이번 단계(S15)에서는, 기초 쿼리의 결과 데이터는 서버 캐시(40)에 반드시 저장되어 있다.

또한, 확장 쿼리는 기초 쿼리의 데이터들을 참조하는 쿼리이다. 따라서 확장 쿼리를 기초 쿼리의 결과 데이터에 적용할 수 있다. 기초 쿼리의 결과 데이터를 참조하여 확장 쿼리를 적용하면, 원래 요청된 요청 쿼리의 결과 데이터를 구할 수 있다.

마지막으로, 앞서 확장 쿼리를 적용하여 구한 결과 데이터를 요청 쿼리의 결과로서, 클라이언트(20)에 전송한다(S16).

다음으로, 본 발명의 제2 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 도 6을 참조하여 보다 구체적으로 설명한다.

도 6에서 보는 바와 같이, 본 발명의 제2 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법은 (a) 요청 쿼리를 수신하여 파싱하는 단계(S21); (b) 기초 쿼리와 확장 쿼리를 생성하는 단계(S22); (c) 기초 쿼리의 결과를 서버 캐시에서 검색하는 단계(S23); (d) 검색되지 않으면, 요청 쿼리를 데이터베이스에서 가져와서 전송하는 단계(S24); (h) 기초 쿼리를 데이터베이스에서 가져와서 서버 캐시에 저장하는 단계(S28); (e) 검색되면, 확장 쿼리를 실행하는 단계(S25); (f) 상기 기초 쿼리의 결과에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득하는 단계(S26); 및, (g) 요청 쿼리의 결과를 전송하는 단계(S27)로 구성된다.

앞서 설명한 제1 실시예와 비교하면, 기초 쿼리를 서버 캐시에 검색하였을 때, 서버 캐시에서 기초 쿼리를 검색하지 못하면 요청 쿼리로 데이터베이스(60)에 요청하여 그 결과를 바로 클라이언트(20)에 전송하는 점(S24)에서 차이가 있다. 그리고 요청쿼리의 결과 데이터를 전송한 후, 기초 쿼리를 다시 데이터베이스(60)에 요청하여 기초 쿼리의 결과 데이터를 서버 캐시(40)에 저장한다(S28). 이하에서, 설명 중 생략된 부분은 앞서 설명한 제1 실시예의 설명을 참조한다.

먼저, 분석처리 서버(30)는 클라이언트(20)로부터 요청 쿼리를 수신하여 파싱한다(S21). 앞서 제1 실시예와 동일하다. 다음으로, 분석처리 서버(30)는 파싱 결과를 이용하여 기초 쿼리 및 확장 쿼리를 생성한다(S22).

그리고 기초 쿼리의 결과 데이터가 서버 캐시(40)에 저장되어 있는지를 검색한다(S23). 기초 쿼리에 의해 데이터베이스(60)로부터 가져온 데이터(또는 기초 쿼리의 결과 데이터)는 서버 캐시(40)에 저장하여 보관된다. 분석처리 서버(30)는 앞서 구한 기초 쿼리를, 서버 캐시(40)에 결과 데이터를 저장해둔 기초 쿼리들과 대비하여, 검색한다.

다음으로, 기초 쿼리의 결과 데이터가 서버 캐시에 저장되어 있지 않으면, 상기 요청 쿼리로 데이터베이스(60)에 데이터를 요청하고, 상기 요청 쿼리의 결과 데이터를 수신하면, 이를 클라이언트(20)에 전송한다(S24). 이때, 확장 쿼리 내에서 테이블 절을 기초쿼리로 대치한 후, 확장쿼리를 바로 데이터베이스(60)에 요청하여도, 원하는 결과 데이터(또는 결과 테이블)를 획득할 수 있다.

클라이언트(20)에 요청 쿼리의 결과 데이터를 전송한 후, 분석처리 서버(30)는 상기 기초 쿼리로 데이터베이스(60)에 데이터를 요청하고, 기초 쿼리의 결과 데이터를 수신하면, 이를 서버 캐시(40)에 저장한다(S28). 특히, 분석처리 서버(30)는 스케쥴러에 의해, 데이터베이스(60)의 요청이 많지 않고 트래픽에 여유가 있는 시간에 상기 기초 쿼리에 대한 데이터를 요청하여 그 결과를 서버 캐시(40)에 저장한다.

다음으로, 기초 쿼리의 결과 데이터가 서버 캐시에 저장된 경우를 설명한다. 분석처리 서버(30)는 기초 쿼리의 결과 데이터에 확장 쿼리를 적용하여 요청 쿼리의 결과를 획득한다(S25). 획득된 결과 데이터를 클라이언트(20)에 전송한다(S26).

다음으로, 본 발명의 제3 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 도 7를 참조하여 보다 구체적으로 설명한다.

도 3에서 보는 바와 같이, 본 발명의 제3 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법은 (a) 요청 쿼리를 수신하여 파싱하는 단계(S31); (b) 기초 쿼리와 확장 쿼리로 생성하는 단계(S31); (c) 상기 기초 쿼리와 확장 쿼리를 조합하여 캐시파일에서 검색하는 단계(S32); (d) 검색되면, 캐시파일을 클라이언트로 전송하는 단계(S33); (e) 검색되지 않으면, 제1 또는 제2 실시예를 수행하는 단계(34); 및 (f) 요청 쿼리의 결과 데이터를 캐시파일로 저장하는 단계(S35)로 구성된다.

본 발명의 제3 실시예는 앞서 설명한 제1 또는 제2 실시예를 보완하는 실시예이다. 즉, 요청 쿼리의 결과 데이터를 캐시파일로 바이너리 형태로 저장하였다가 동일한 쿼리로 다시 요청되면, 해당 캐시파일을 바로 클라이언트(20)에 전송한다.

캐시파일이란 요청 쿼리의 결과 데이터를 파일로 저장한 것을 말한다. 분석처리 서버(30)가 클라이언트(20)가 요청한 결과 데이터를 만들어 최종적으로 전송할 때, 파일 형태로 전송한다. 캐시파일은 전송할 때와 동일한 파일이다. 따라서 캐시파일의 쿼리와 동일한 요청 쿼리로 요청하면, 해당 캐시파일을 바로 전송해주면 된다.

바람직하게는, 캐시파일은 분석처리 서버(40)의 서버 캐시(40)에 저장된다.

구체적으로, 분석처리 서버(30)는 클라이언트(20)로부터 요청 쿼리를 수신하여 파싱한다(S30). 앞서 제1 또는 제2 실시예와 동일하다. 분석처리 서버(30)는 기초쿼리와 확장쿼리를 조합하여, 저장된 캐시파일의 쿼리를 비교하여, 동일한 쿼리가 있는지를 검색한다(S32).

만약 동일한 쿼리가 캐시파일에 있다면, 검색된 캐시파일을 바로 클라이언트(20)에 전송한다(S33).

만약 동일한 쿼리가 없다면, 앞서 설명한 제1 또는 제2 실시예의 3번째 검색 단계(S13,S23)를 수행한다(S34). 즉, 서버 캐시에 기초 쿼리의 결과 데이터가 있는지를 검색한다. 서버 캐시에 기초 쿼리의 결과 데이터가 있으면, 기초 쿼리를 대상으로 확장쿼리를 만들어 결과 데이터를 획득한다. 획득된 결과 데이터를 클라이언트에 전송한다. 서버 캐시에 기초 쿼리의 결과 데이터가 없으면, 기초 쿼리 또는 요청 쿼리로 데이터베이스(60)로부터 결과 데이터를 가져온다. 가져온 결과 데이터가 기초쿼리 데이터이면 확장 쿼리를 통해 요청 쿼리의 결과 데이터를 생성한다. 최종적으로 요청 쿼리의 결과 데이터를 클라이언트(20)에 전송한다.

제1 또는 제2 실시예를 완료하면, 생성된 기초쿼리 및 확장쿼리의 조합의 결과 데이터(또는 클라이언트에 전송한 결과 데이터)를 캐시파일로 서버 캐시(40)에 저장한다(S36).

다음으로, 본 발명의 제4 실시예에 따른 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법을 도 8을 참조하여 구체적으로 설명한다.

본 발명의 제4 실시예는 앞서 설명한 제1 내지 제3 실시예와 동일한 구성을 가진다. 다만, 서버 캐시(40)의 구성이 보다 세분화된다.

도 8에서 보는 바와 같이, 본 발명의 제4 실시예는 서버 캐시(40)를 캐시 메모리(41)와 캐시 디스크(42)로 구성한다.

캐시 메모리(41)는 분석처리 서버(30)의 RAM(Random access memory)으로 구성된다. 특히, 캐시 메모리(41)는 인메모리 스토리지로 구성된다. 캐시 디스크(42)는 분석처리 서버(30)의 하드 디스크 또는 SSD(Solid State Disk) 등으로 구성된다.

앞서 본 발명의 제1 내지 제3 실시예에서, 서버 캐시(40)에 저장되는 기초 쿼리의 결과 데이터는 모두 캐시 메모리(41)에 저장된다. 다만, 캐시 메모리(41)의 저장 용량 보다 기초 쿼리의 결과 데이터가 더 많은 경우, 캐시 메모리의 용량을 초과하는 결과 데이터는 캐시 디스크(42)에 저장된다.

이때, 캐시 디스크(42)로 옮겨지는 기초 쿼리의 결과 데이터는 사전에 정해진 정책에 의해 선별된다. 선별 정책의 예로서, 결과 데이터에 대한 접근 빈도, 최근 접근 시각 등을 기초로 하여, 접근 빈도가 낮거나 최근 접근 시각이 가장 오래된 결과 데이들을 선별한다.

또한, 제3 실시예의 캐시파일은 캐시 디스크(42)에 저장된다.

본 발명의 효과를 도 9 내지 도 12를 참조하여 보다 구체적으로 설명한다.

본 발명은 비즈니스 인텔리전스(BI, Business Intelligence) 기반의 빅데이터를 처리를 위한 플랫폼에 관한 것이다. 특히, 빅데이터를 요청하였을 때 응답시간을 10초 이내의 빠른 시간 내에 처리함으로써, 실시간에 가까운 처리를 위한 것이다. 본 발명은 실시간에 가까운 처리를 위한 캐시 파일과 캐시 메모리 테이블을 사용한다. 이를 위해 요청 퀴리를 파싱하여, 기초 쿼리와 확장 쿼리로 분리한다.

또한, 메모리의 한계에 따른 파일 형태의 로딩/저장/필터링의 구조를 정의한다. 예를 들면 1억 건 정도 메모리 테이블에 로딩하는데 5G 정도 소요된다면, 32G 서버 환경이라면 10억 건 정도를 메모리에 가지고 있을 수 없다. 그러므로 일부 데이터를 파일 형태로 빠르게 저장하고 필요시 다시 메모리로 로딩하는 구조가 필요하다. 파일 자체에 조건(필터링과 쿼리를 파싱하여 해당 컬럼에서 조건 추출)으로 원하는 데이터만 처리한다.

또한, 요청 쿼리를 기초 쿼리(BaseSQL)와 확장 쿼리로 단계를 분리하는 이유는 상대적으로 속도가 떨어지는 관계형 데이터베이스(RDB)를 사용하는 것이 아니라, 분석처리 서버(30)에 구비된 서버 캐시(인메모리 데이터베이스)를 사용하기 위해서다. 이를 통해, 속도가 획기적으로 개선된다. 인메모리 데이터베이스(In-memory Database)는 데이터 스토리지의 메인 메모리에 설치되어 운영되는 방식의 데이터베이스 관리 시스템이다. 디스크에 설치되는 방식에 비해 처리 속도가 빠르다.

구체적으로, 본 발명의 제1 내지 제4 실시예를 적용하는 경우, 각 상황에서의 처리 속도를 설명한다.

먼저, 제1 상황은 기초 쿼리와 확장 쿼리가 모두 불일치하는 경우이다. 즉, 제1 상황은 최초로 쿼리가 실행되는 경우에 해당되며, 전체 처리속도는 종래 기술에 의한 시스템과 동일하게 소요된다.

도 9에서 보는 바와 같이, 먼저, 매트릭스(Matrix) 보고서에서 추출한 DB 코드, SQL 정보를 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)로 분리하여 분석처리 서버(SOLAP 서버)에 요청한다(① 단계). 일치하는 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)가 없기 때문에, 쿼리를 원래 요청 쿼리로 하여 BI 서버(Matrix Server)에 요청한다(② 단계). BI 서버에서 타겟 DB를 연결하여 데이터를 요청한다(③ 단계). 타겟 DB에서 큐브(cube) 데이터를 보내 준다(④ 단계). 그리고 필드 정보와 데이터를 압축해서 보내 준다(⑤ 단계). 보내준 파일을 캐시 파일로 저장한다(⑥ 단계). 캐시 파일을 브라우저(또는 클라이언트)에 보내 준다(⑦ 단계). 마지막으로, 스케줄러가 기초 쿼리(BaseSQL)를 원천 DB에서 실행하여 캐시 메모리(40)에 저장(Background 실행)한다(⑧ 단계).

다음으로, 제2 상황은 기초 쿼리는 일치하고, 확장 쿼리는 불일치하는 경우이다. 기초 쿼리(BaseSQL)에 해당하는 캐시 메모리 테이블을 생성된 경우에 해당되며 속도는 10초 내외 로서, 제1 상황(또는 종래 기술)에 비하여 10 ~ 50배 향상된다.

도 10에서 보는 바와 같이, 먼저, 매트릭스(Matrix) 보고서에서 추출한 DB 코드, SQL 정보를 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)로 분리하여 SOLAP 서버에 요청한다(① 단계). 기초 쿼리(BaseSQL)가 일치하고 확장 쿼리(ExtendSQL)가 없는 경우 확장 쿼리(ExtendSQL)의 타겟 테이블은 서버 캐시에 저장된 테이블 명으로 변경하여 실행한다(② 단계). 그리고 서버 캐시에서 cube 데이터를 보내준다(③ 단계). 보내준 파일을 캐시 파일로 저장한다(④ 단계). 마지막으로,캐시 파일을 브라우저에 보내준다(⑤ 단계).

다음으로, 제3 상황은 기초 쿼리와 확장 쿼리가 모두 일치하는 경우이다. 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL) 모두 일치하는 경우에 해당되며 속도는 3초 내외로서, 제1 상황 또는 종래 기술에 비하여, 100배 이상 향상된다.

도 11에서 보는 바와 같이, Matrix 보고서에서 추출한 DB코드, SQL 정보를 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)로 분리하여 분석처리 서버에 요청한다(① 단계). 기초 쿼리(BaseSQL)와 확장 쿼리(ExtendSQL)가 모두 일치하는 경우 해시키값이 존재한다(② 단계). 그리고 캐시 파일을 브라우저에 보내준다(③ 단계).

상기 제1 내지 제3 상황의 처리 속도 등을 비교한 표가 도 12에 도시되고 있다. 동일한 쿼리가 실행되면 상태가 자동으로 넘어간다. 즉, 제1 상황에서, 제2 상황으로, 제2 상황에서 제3 상황으로 넘어간다. 또한, 동시 사용자 수가 증가하면 캐시 파일 사용 빈도가 급격하게 증가한다(90% 이상으로 예상된다). 대다수의 사용자들은 5분에서 3초로 쿼리 시간 감소를 경험하게 된다. 또한, 최초의 실행에서, 기초 쿼리에 대한 데이터는 스케줄러로 실행할 수 있다. 즉, 스케줄러를 통해 여유있는 시간에 데이터를 가져올 수 있어, 체감 속도에 영향을 주지 않는다.

이상, 본 발명자에 의해서 이루어진 발명을 실시 예에 따라 구체적으로 설명하였지만, 본 발명은 실시 예에 한정되는 것은 아니고, 그 요지를 이탈하지 않는 범위에서 여러 가지로 변경 가능한 것은 물론이다.

10 : 사용자 단말 20 : 클라이언트
30 : 분석처리 서버 40 : 서버 캐시
41 : 캐시 메모리 42 : 캐시 디스크
50 : BI 서버 60 : 데이터베이스

Claims (9)

1. 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 분석처리 서버의 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서,
   (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계;
   (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계;
   (c) 상기 기초 쿼리의 결과 데이터를 상기 서버의 서버 캐시에서 검색하는 단계;
   (d) 상기 서버 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 서버 캐시에 저장하는 단계; 및,
   (e) 상기 확장 쿼리를 상기 기초 쿼리의 결과 데이터에 적용하여 상기 확장 쿼리의 결과 데이터를 획득하고, 획득된 결과 데이터를 상기 클라이언트로 전송하는 단계를 포함하는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
2. 클라이언트가 요청하는 데이터베이스에 대한 요청 쿼리를 처리하는 분석처리 서버의 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법에 있어서,
   (a) 상기 요청 쿼리를 파싱하여, 상기 요청 쿼리에 포함된 컬럼명을 추출하는 단계;
   (b) 추출된 컬럼명을 참조항목으로 하여 상기 요청 쿼리가 참조하는 테이블과 동일한 테이블을 참조하는 쿼리(이하 기초 쿼리)와, 상기 기초 쿼리의 결과 데이터를 참조하여 상기 요청 쿼리가 요청하는 결과 데이터를 가져오는 확장 쿼리를 생성하는 단계;
   (c) 상기 기초 쿼리의 결과 데이터를 상기 서버의 서버 캐시에서 검색하는 단계;
   (d) 상기 서버 캐시에 기초 쿼리의 결과 데이터가 없으면, 상기 요청 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 요청 쿼리의 결과 데이터를 상기 클라이언트로 전송하는 단계; 및,
   (e) 상기 기초 쿼리로 상기 데이터베이스에 데이터를 요청하고, 수신한 기초 쿼리의 결과 데이터를 상기 서버 캐시에 저장하는 단계를 포함하고,
   상기 서버는 상기 확장 쿼리의 결과 데이터를 캐시파일로 상기 서버 캐시에 저장하고,
   상기 방법은, (f) 상기 (b)단계 이후, 상기 확장 쿼리의 캐시파일이 상기 서버 캐시에서 검색되는 경우, 검색된 캐시 파일을 클라이언트로 전송하는 단계를 더 포함하는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
3. 제1항에 있어서,
   상기 서버는 상기 확장 쿼리의 결과 데이터를 캐시파일로 상기 서버 캐시에 저장하고,
   상기 방법은,
   (f) 상기 (b)단계 이후, 상기 확장 쿼리의 캐시파일이 상기 서버 캐시에서 검색되는 경우, 검색된 캐시 파일을 클라이언트로 전송하는 단계를 더 포함하는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
4. 제1항 또는 제2항에 있어서,
   상기 (a)단계에서, 상기 컬럼명을 식별할 수 있는 고유키를 생성하고,
   상기 (b)단계에서, 상기 기초 쿼리의 참조항목 절에서 상기 컬럼명에 대하여 상기 고유키로 앨리어스(alias)를 정의하고, 상기 확장 쿼리는 상기 앨리어스를 이용하여 컬럼을 참조하는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
5. 제4항에 있어서,
   상기 고유키는 해당 컬럼명의 데이터베이스의 이름, 참조 테이블의 이름, 및 컬럼명을 해쉬하여 구하는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
6. 제1항 또는 제2항에 있어서,
   상기 (b)단계에서, 상기 기초 쿼리는 참조항목 절, 테이블 참조 절, 및 조건 절로 구성되고, 상기 기초 쿼리의 테이블 참조 절과 조건 절은 상기 요청 쿼리의 테이블 참조 절과 조건 절과 동일한 구조를 갖는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
7. 제6항에 있어서,
   상기 (b)단계에서, 상기 확장 쿼리는 테이블 참조 절에서 상기 기초 쿼리 또는 상기 기초쿼리의 결과 데이터를 참조하고, 상기 테이블 참조 절 이외의 절이 상기 요청 쿼리의 절과 동일한 구조를 갖도록 생성되는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
8. 제7항에 있어서,
   상기 (b)단계에서, 상기 요청 쿼리에서 테이블에 대한 앨리어스(alias)가 정의된 경우, 상기 테이블의 앨리어스를 삭제하고 상기 테이블의 앨리어스를 상기 테이블의 이름으로 대체하여 상기 확장 쿼리를 생성하는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   
9. 제1항 또는 제2항에 있어서,
   상기 서버 캐시는 인메모리 스토리지와 캐시 디스크로 구성되고,
   상기 기초 쿼리의 결과 데이터를 상기 인메모리 스토리지에 저장하는 것을 특징으로 하는 ＳＱＬ 파싱에 의한 2단계 쿼리 및 결과 캐싱을 이용한 온라인 분석 프로세싱 방법.
   

Images