KR20200106950A - Sql 질의 플랜들을 최적화하기 위한 차원 콘텍스트 전파 기술들 - Google Patents

Sql 질의 플랜들을 최적화하기 위한 차원 콘텍스트 전파 기술들 Download PDF

Info

Publication number
KR20200106950A
KR20200106950A KR1020207023647A KR20207023647A KR20200106950A KR 20200106950 A KR20200106950 A KR 20200106950A KR 1020207023647 A KR1020207023647 A KR 1020207023647A KR 20207023647 A KR20207023647 A KR 20207023647A KR 20200106950 A KR20200106950 A KR 20200106950A
Authority
KR
South Korea
Prior art keywords
fact
query plan
records
predicate
predicate condition
Prior art date
Application number
KR1020207023647A
Other languages
English (en)
Other versions
KR102627690B1 (ko
Inventor
하리쉬 부타니
Original Assignee
오라클 인터내셔날 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 오라클 인터내셔날 코포레이션 filed Critical 오라클 인터내셔날 코포레이션
Publication of KR20200106950A publication Critical patent/KR20200106950A/ko
Application granted granted Critical
Publication of KR102627690B1 publication Critical patent/KR102627690B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2453Query optimisation
    • G06F16/24534Query rewriting; Transformation
    • G06F16/24542Plan optimisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/248Presentation of query results
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/283Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Operations Research (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

질의들의 효율적인 실행을 위한 기술들. 질의에 대하여 생성된 질의 플랜은, 실행될 때, 더 적은 CPU 사이클을 사용하며 그에 따라서 원래의 질의 플랜보다 더 빠르게 실행되는 향상된 질의 플랜으로서 최적화되고 재작성된다. 따라서, 이에 대하여 향상된 질의 플랜이 생성되는 질의는, 획득된 결과들 또는 질의 중인 데이터를 훼손하지 않고 더 빠르게 실행된다. 최적화는, 원래의 질의 플랜 내의 하나 이상의 팩트 스캔 동작들의 세트를 식별하는 것, 및 그런 다음, 재작성된 향상된 질의 플랜 내에서, 팩트 스캔 동작들의 세트 중 하나 이상과 차원 콘텍스트 술어 조건들을 연관시키는 것을 포함한다. 이는 원래의 질의 플랜에 비하여 향상된 질의 플랜 내에서 팩트 레코드들을 스캔하는 것 및/또는 프로세싱하는 것의 전체 비용을 감소시키며, 향상된 질의 플랜이 원래의 질의 플랜보다 더 빠르게 실행되게 만든다.

Description

SQL 질의 플랜들을 최적화하기 위한 차원 콘텍스트 전파 기술들
다른 출원들에 대한 참조들
본 출원은 다음의 출원들로부터의 이익 및 우선권을 주장하며, 이러한 출원들의 전체 내용은 모든 목적들을 위해 본원에 참조로서 통합된다:
(1) "DIMENSION CONTEXT PROPAGATION TECHNIQUE FOR ANALYTICAL SQL QUERIES"라는 명칭으로 2018년 01월 16일자로 출원된 미국 가특허 출원 제62/617,970호;
(2) "DIMENSION CONTEXT PROPAGATION TECHNIQUE FOR ANALYTICAL SQL QUERIES"라는 명칭으로 2018년 10월 18일자로 출원된 미국 가특허 출원 제62/747,642호; 및
(3) "DIMENSION CONTEXT PROPAGATION TECHNIQUES FOR OPTIMIZING SQL QUERY PLANS"라는 명칭으로 2019년 01월 15일자로 출원된 미국 정규 특허 출원 제16/248,061호.
분석적인 솔루션(solution)들은 기업들이 시간, 공간, 제품들 및 고객들과 같은 차원(dimension)(들)에 걸쳐 그들의 비지니스의 상이한 액티비티들을 더 양호하게 이해하는 것을 가능하게 한다. 이는, 콘텍스트적(contextual) 또는 상관 분석, 성능 관리, 감도 분석들(what-if analyses), 예측, 슬라이싱-앤-다이싱 분석(slicing-and-dicing analysis), 핵심 성과 지표(Key Performance Indicator; KPI)들 및 경향들 분석, 대시-보딩(dash-boarding) 및 유사한 것을 수행하는 것을 포함할 수 있다. 임의의 다차원 분석의 주요 측면은, 분석의 입력 및 분석의 초점 둘 모두를 지정하는 차원적 콘텍스트(dimensional context)이다.
온라인 분석 프로세싱(online analytical processing; OLAP) 데이터베이스 시스템들은 일반적으로 다양한 비지니스-관련 액티비티들에 대한 통찰들을 획득하거나 또는 이에 대한 유용한 패턴들을 추출하기 위하여 데이터를 마이닝(mine)하고 리포트를 생성하기 위하여 사용된다. 예를 들어, OLAP 데이터베이스들은 판매 경향들을 식별하고, 마케팅 캠페인들을 분석하며, 금융 성과를 예측하기 위해 사용될 수 있다. 이는 전형적으로 많은 양의(예를 들어, 수백만개의 레코드들의) 다-차원 데이터베이스 데이터에 대한 분석 질의들을 평가하는 것을 수반한다. 예를 들어, 판매 데이터는 시간, 지리적 영역, 부서, 및/또는 개별적인 제품과 같은 차원들과 관련하여 분석될 수 있다.
분석가들은 일반적으로 그들의 데이터에 대한 의미론적 모델을 염두에 두고 있다. 차원들 및 메트릭(metric)들과 관련하여 데이터를 생각하는 것이 일반적이며, 여기에서 메트릭들은 액티비티(예를 들어, 판매액, 판매 수량)에 대한 세부사항들을 캡처하며, 차원들은 액티비티의 콘텍스트(예를 들어, 판매된 제품의 유형, 판매가 일어난 매장, 매장이 위치한 주(state), 구매한 고객, 등)를 캡처한다. 비지니스 데이터는 일반적으로 다-차원이며 의미론적으로 풍부하다.
많은 수의 데이터 분석 솔루션들은 분석 언어로서 사용되고 있는 SQL(Structured Query Language)과 같은 일부 질의 언어를 갖는 백-엔드(back-end)로서 관계형 데이터베이스 시스템을 사용한다. 다-차원 데이터베이스 데이터는 전형적으로 메트릭들을 저장하는 팩트 레코드(fact record)들(예를 들어, 판매 데이터)을 포함하며, 이들은 차원들 또는 콘텍스트 정보를 저장하는 차원 레코드들(예를 들어, 시간 데이터, 지리적 데이터, 부서 데이터, 제품 데이터)와는 별개로 저장된다. 예를 들어, 팩트 레코드들은 팩트 테이블들에 저장될 수 있으며, 차원 레코드들은 차원 테이블들에 저장될 수 있다.
SQL 영역에서, 분석 솔루션들은 스타 스키마(star schema)들(그들의 엔티티-관계(Entity-Relationship; ER) 다이어그램이 보여지는 방식 때문에 이름에 붙여짐, 도 4 참조)의 상단 상에 구축되며, SQL 질의를 사용하여 질의된다. 전형적인 분석 질의는, 조인(join)들 또는 유니온(union)에 의해 조합되는 몇몇 구성 블록 질의 서브-플랜/공통 테이블 표현들을 수반할 수 있다. 질의에 대한 질의 서브-플랜은 전형적으로 팩트 테이블과 차원 테이블들의 조인을 수반하며, 다차원 공간의 슬라이스(slice) 상의 계산들을 집성(aggregate)한다. 질의를 실행하는 비용의 큰 부분은 전형적으로 팩트 레코드들의 소스들의 스캔이다. 추가로, 차원 레코드들과 관련하여 팩트 레코드들을 분석하는 것은 흔히 팩트 레코드들을 차원 레코드들과 조인하는 것, 예를 들어, 팩트 테이블들을 차원 테이블들과 조인하는 것을 수반한다. 그러나, 팩트 레코드들을 차원 레코드들과 조인하는 것은, 적어도 이것이 상당한 수의 팩트 레코드들을 프로세싱하는 것을 수반하는 이유 때문에 계산 집중적일 수 있다. 일부 기존 기술들은, OLAP 큐브들, 추출물(extract)들 및 구체화된(materialized) 사전-집성된 테이블들을 사용하는 것과 같은 사전-계산을 사용함으로써 질의 실행을 최적화하는데 초점을 맞춘다. 그러나, 이러한 기술들에 의해 제공되는 실행 개선이 여전히 제한적이다. 추가로, 사전-집성은 세분성(granularity)의 손실, 애드-혹(ad-hoc) 질의들의 실행 불능, 및 유사한 것과 같은 몇몇 부정적인 측면들을 갖는다.
계산 오버헤드를 복합화하는 것은, 그 내부에서 데이터베이스 질의들이 흔히 드래프팅(draft)되고 평가되는 방식이다. 데이터베이스 질의들의 드래프팅은 일반적으로, 도메인 또는 콘텍스트적인 지식이 거의 없는 데이터베이스 프로그래머들에게 아웃소싱된다. 추가로, SQL과 같은 언어로 이러한 질의들을 작성하는 것이 상당히 어렵다. 질의의 상이한 부분들은 전형적으로 분리된 방식으로 평가되며, 이는 데이터의 불필요하고 중복적인 프로세싱을 야기할 수 있다. 예를 들어, 질의가 작성(write)되는 방식에 기인하여, 질의에 대한 질의 플랜이 질의 플랜의 후반 스테이지에서 필터 동작을 지정할 수 있다. 필터 동작과 관계 없이 질의 플랜 동작이 질의 플랜의 초기 스테이지에서 수행될 때, 초기 스테이지에서 수행되는 데이터 프로세싱 중 다수가 무효일 있으며, 이는 초기 스테이지에서 프로세싱된 데이터 중 다수가 무관한 데이터로서 후반 스테이지에서 필터링될 수 있기 때문이다.
본 개시는 전반적으로 질의들의 실행에 관한 것이다. 보다 더 구체적으로, 질의 실행 성능을 향상시키기 위한 기술들이 설명된다. 하나 이상의 프로세서들에 의해 실행가능한 프로그램들, 코드, 또는 명령어들을 저장하는 비-일시적인 컴퓨터-판독가능 저장 매체, 방법들, 시스템들, 및 유사한 것을 포함하는 다양한 발명적인 실시예들에 본원에서 설명된다.
본 개시는 전반적으로 애드-혹 데이터베이스 질의들과 같은 분석 질의들의 효율적인 실행을 위한 기술들에 관한 것이다. SQL 애드-혹 질의와 같은 질의에 대하여, 질의에 대하여 생성되는 질의 플랜은 최적화된 또는 향상된 질의 플랜으로서 최적화되고 향상되며 재작성된다. 향상된 질의 플랜은, 실행될 때, 원래의(original) 비-최적화된 질의 플랜보다 더 적은 CPU 사이클들을 사용하여, 그에 따라서 원래의 질의 플랜보다 더 빠르게 실행된다. 결과적으로, 이에 대하여 향상된 질의 플랜이 생성되는 질의는, 획득된 결과들 또는 질의 중인 데이터를 훼손하지 않고 더 빠르게 실행된다. 특정 실시예들에 있어서, 최적화되거나 또는 향상된 질의 플랜은 또한, 실행될 때, 원래의 비-최적화된 질의 플랜보다 더 적은 메모리 자원들을 사용한다.
특정 실시예들에 있어서, 원래의 질의 플랜은, 원래의 질의 플랜 내의 하나 이상의 팩트 스캔 동작들/연산자들의 세트를 식별하는 것, 및 그런 다음, 재작성된 향상된 질의 플랜 내에서, 팩트 스캔 동작들의 세트 중 하나 이상과 차원 콘텍스트를 연관시키는 것에 의해 최적화된다. 특정 실시예들에 있어서, 차원 콘텍스트는, 차원 콘텍스트에 대응하는 하나 이상의 술어(predicate) 조건들(차원 콘텍스트 술어 조건들로서도 지칭됨)과 팩트 스캔 동작의 연관에 의해 팩트 스캔 동작과 연관된다. 팩트 스캔 동작은, 팩트 레코드들의 소스(팩트 소스로도 지칭됨)로부터 팩트들(팩트 레코드들 또는 팩트 로우(row)들로도 지칭됨)을 스캔하거나 또는 판독하도록 구성된 질의 플랜 내의 동작이다. 향상된 질의 플랜 내의 팩트 스캔 동작과 술어 조건의 연관은 또한, 팩트 스캔 동작이 동작하는 팩트 소스로의 술어 조건 또는 차원 콘텍스트의 전파 또는 팩트 스캔 동작으로의 술어 조건 또는 차원 콘텍스트의 전파로서 지칭된다. 연관들 또는 전파들에 기인하여, 향상된 질의 플랜 내에서 팩트 레코드들을 스캔하는 것/판독하는 것 및/또는 프로세싱하는 것의 전체 비용은 원래의 질의 플랜에 비하여 훨씬 더 적다. 결과적으로, 향상된 질의 플랜은, 실행될 때, 원래의 비-최적화된 질의 플랜보다 더 적은 CPU 사이클들을 사용하며, 그에 따라서 원래의 질의 플랜보다 더 빠르게 실행된다.
특정 실시예들에 있어서, 질의 플랜을 최적화하는 프로세스는, 질의 플랜 내에서 어느 하나 이상의 팩트 스캔 동작들이 술어 조건 전파를 위한 후보들인지를 식별하는 것, 각각의 후보 팩트 스캔 동작과 연관될 하나 이상의 술어 조건들을 식별하는 것, 및 그런 다음 연관들을 가지고 질의 플랜을 재작성하는 것을 포함할 수 있다. 질의에 대한 질의 플랜은 연관들을 가지고 실행된다. 본원에서 개시되는 다양하고 상이한 기술들이 이러한 프로세싱을 수행하기 위해 사용될 수 있다.
팩트 스캔 동작과 연관될 술어 조건을 식별하기 위하여 다양하고 상이한 기술들이 사용될 수 있다. 예를 들어, 원래의 질의 플랜의 하나의 부분으로부터의 술어 조건은 재작성된 향상된 질의 플랜 내의 질의 플랜의 다른 부분 내의 팩트 스캔 동작으로 전파될 수 있다. 일 예로서, 질의 플랜의 하나의 부분 내의 차원 테이블에 적용되는 차원 술어 조건은 질의 플랜의 다른 부분 내의 팩트 스캔 동작으로 전파되고 이와 연관될 수 있다. 일부 다른 경우들에 있어서, 특정 술어 조건을 팩트 스캔 동작과 연관시키는 대신에, 새로운 술어 조건이 질의 플랜 내의 원래의 술어 조건으로부터 또는 특정 술어 조건으로부터 추론되며(새로운 술어 조건으로의 특정 술어 조건 또는 원래의 술어 조건의 변환(translation) 또는 매핑으로도 지칭됨), 새로운 술어 조건이 특정 술어 또는 원래의 조건 대신에 팩트 스캔 동작과 연관된다. 새로운 술어 조건은, 새로운 술어 조건을 가지고 팩트 스캔 동작을 실행하는 것의 비용(예를 들어, 실행 시간)이 특정 술어 조건 또는 원래의 술어 조건을 가지고 팩트 스캔 동작을 실행하는 비용보다 더 작게 하는 그런 것이다. 일부 경우들에 있어서, 질의 내에서 참조되는 팩트 테이블로부터 팩트 레코드들을 스캔하는 대신에, OLAP 인덱스들, 사전-집성된 구체화된 뷰(view)들과 같은 다른 물리적인 팩트 구조들(팩트 소스들)이 스캔들을 수행하기 위해 사용될 수 있다.
이상에서 표시된 바와 같이, 향상된 질의 플랜은, 실행될 때, 원래의 비-최적화된 질의 플랜보다 더 적은 CPU 사이클들을 사용하여, 그에 따라서 원래의 질의 플랜보다 더 빠르게 실행된다. 이들이 달성될 수 있는 상이한 방식들이 존재한다. 특정 경우들에 있어서, 질의 플랜 내의 팩트 스캔 동작과 술어 조건의 연관에 기인하여, 재작성된 질의 플랜에 의해 프로세싱되는 팩트 레코드들의 수는 원래의 질의 플랜에 비하여 감소된다. 예를 들어, 팩트 스캔 동작과 연관된 술어 조건의 결과로서, 술어 조건을 충족시키는 팩트 레코드들만이 질의 플랜 내에서 팩트 스캔 동작으로부터 다음 하류측(downstream) 동작으로 제공된다. 이는, 향상된 질의 플랜 내의 하류측 동작들(예를 들어, 팩트 테이블과 차원 테이블 사이의 조인 동작)에 제공되며 이에 의해 프로세싱되어야 할 팩트 레코드들의 수를 감소시킨다. 이는, 향상된 질의 플랜 내에서 하류측 동작들을 수행하는 것과 연관된 계산 오버헤드를 감소시킨다. 술어 조건에 기초하는 팩트 레코드들의 이러한 필터링은 질의 플랜에 의한 팩트 레코드들의 불필요하고 중복적인 프로세싱을 감소시킨다. 질의 플랜에 의해 프로세싱되는 팩트 레코드들의 수의 감소는 질의 플랜에 대한 그리고 그에 따라서 이에 대하여 질의 플랜이 생성되는 질의 자체에 대한 더 빠른 실행 시간을 의미한다. 질의 플랜에 의해 프로세싱되는 팩트 레코드들의 수의 감소는 또한 재작성된 질의 플랜을 실행하기 위해 사용되는 더 적은 메모리 자원들을 의미할 수 있다. 이상에서 설명된 바와 같이, 특정 실시예들에 있어서, 특정 술어 조건으로부터 추론되거나 또는 변환된 새로운 술어 조건이 특정 술어 조건 대신에 팩트 스캔 동작과 연관될 수 있다. 새로운 술어 조건은, 새로운 술어 조건을 가지고 팩트 스캔 동작을 실행하는 것의 비용(예를 들어, 실행 시간)이 특정 술어 조건을 가지고 팩트 스캔 동작을 실행하는 비용보다 더 작게 하는 그런 것이다. 예를 들어, 특정 술어 조건과 연관된 팩트 스캔 동작은 실행하기 위해 2 초를 소요할 수 있으며, 반면 새로운 술어 조건과 연관된 팩트 스캔 동작은 실행하기 위해 단지 1 초만을 소요할 수 있다. 술어 조건을 추론하는 것 또는 변환하는 것은 향상된 질의 플랜 실행을 비-최적화된 질의 플랜보다 더 빠르게 만든다. 추가적으로, 특정 실시예들에 있어서, 더 빠른 실행 시간은, 팩트 표현의 스캔 성능들을 레버리지(leverage)하기 위한 방식으로 OLAP 인덱스들과 같은 이용가능한 대안적인 팩트 표현들에 대하여 팩트 스캔들을 수행함으로써 달성된다. 예를 들어, 일부 경우들에 있어서, 조합이, 팩트 스캔 프로세싱에서 몇 자릿수의 감소를 야기하는, OLAP 인덱스들의 스캔을 스킵하고 빠른 술어 평가를 레버리지할 수 있도록, 일부 술어 "P"에 대하여 OLAP 인덱스 스캔으로 변환된다.
성능 관점으로부터, 향상된 질의 플랜들은 더 빠르게 실행될 수 있으며, 잠재적으로 비-향상된 질의 플랜들보다 더 적은 자원들을 사용할 수 있다. 본원에서 개시되는 교시들에 기초하여 실행되는 상당한 수의 질의들은 비-향상된 질의 플랜들을 갖는 질의들보다 10X, 25X 내지 심지어 100X만큼, 또는 훨씬 더 높은 자릿수들만큼 더 빠르게 실행된다. 이는, 팩트 테이블들이 차원 테이블들보다 몇 자릿수 더 크며, 그에 따라서 팩트 레코드들을 프로세싱하는 것과 연관된 스캔 비용들을 감소시키는 것이 막대한 성능 이득들을 초래하기 때문이다. 예를 들어, 하나의 경우에 있어서, 애드-혹 질의에 대한 질의 실행 시간은 206 초로부터 16 초로 감소되었다.
정보의 다양하고 상이한 피스(piece)들이 본원에서 설명되는 질의 플랜 최적화를 가능하게 하기 위해 사용될 수 있다. 특정 실시예들에 있어서, 데이터베이스 질의들에 대하여 생성되는 질의 플랜들은: 질의의 구조, 질의에 대하여 생성되는 질의 플랜의 구조, 질의되는 데이터베이스에 관한 스키마 정보, 및 질의 플랜 최적화기 및/또는 인핸서(enhancer)에 대하여 이용가능한 의미(semantics) 정보에 기초하여 최적화되고 향상될 수 있다. 예를 들어, 비지니스 의미 또는 비지니스 인텔리전스(business intelligence; BI) 의미 정보가 질의 플랜들을 재작성하기 위해 사용될 수 있다. 의미 정보는 풍부한 가치를 갖는 비지니스 데이터 및 현실 프로세스들, 조직 구조들, 및 유사한 것에 기초하는 구조적 의미를 포함할 수 있다. 의미 정보는 데이터 내의 비지니스 계층들 및 기능적 종속성들과 같은 비지니스 모델에 대한 정보를 포함할 수 있다. 예를 들어, 종속성 정보는 데이터베이스 데이터의 상이한 필드들(예를 들어, 컬럼(column)들) 사이의 (예를 들어, 계층적 또는 비-계층적) 관계들을 설명하는 정보를 포함할 수 있다. 예를 들어, 종속성 메타데이터는 "도시" 컬럼의 값들과 "주" 컬럼의 값들 사이의 계층적 관계를 설명하는 정보를 포함할 수 있다(예를 들어, 샌프란시스코는 캘리포니아 주 내의 도시이다). 계층들의 예들은, 시간 기간 계층들(예를 들어, 일, 주, 달, 분기, 년, 등), 지리적 계층들(예를 들어, 도시, 주, 나라), 및 유사한 것을 포함한다. 특정 실시예들에 있어서, 의미 정보는, 임의의 사용자 입력 없이, 분석되는 데이터를 저장하는 데이터베이스의 구조 및 스키마에 대한 정보를 분석하는 것으로부터 결정될 수 있다. 이러한 분석으로부터 도출되는 추론들은 최적화되고 향상된 질의 플랜을 생성하기 위하여 질의 플랜을 재작성하기 위해 사용될 수 있다.
특정 실시예들에 있어서, 관계형 데이터베이스 내에 저장된 데이터를 질의하기 위한 질의에 대하여 생성된 원래의 질의 플랜이 수신될 수 있다. 원래의 질의 플랜은 팩트 레코드들의 소스로부터 팩트 레코드들을 스캔하도록 구성된 제 1 팩트 스캔 동작을 포함할 수 있다. 원래의 질의 플랜은 제 1 스캔 동작으로부터 레코드들의 세트를 수신하도록 구성된 제 2 동작을 더 포함할 수 있다. 제 1 팩트 스캔 동작과 연관될 제 1 술어 조건이 식별된다. 원래의 질의 플랜은 향상된 질의 플랜을 생성하기 위해 재작성될 수 있으며, 여기에서, 향상된 질의 플랜 내에서, 제 1 술어 조건은 제 1 스캔 동작과 연관되고, 제 2 동작은 술어 조건을 충족시키는 단지 하나 이상의 스캔된 팩트 레코드들만을 수신한다. 향상된 질의 플랜은, 제 1 스캔 동작과 제 1 술어 조건의 연관에 기인하여 원래의 질의 플랜보다 더 빠르게 실행된다. 향상된 질의 플랜은 질의에 대한 레코드들의 결과 세트를 획득하기 위해 실행될 수 있다. 레코드들의 결과 세트는 질의에 대한 응답으로서 제공될 수 있다.
질의에 대하여 질의되는 데이터(또는 이에 대하여 질의가 동작하는 데이터)는 비-사전-집성된 데이터일 수 있다. 분석 플랫폼은 이러한 비-사전-집성된 데이터의 애드-혹 상호작용 질의를 가능하게 한다.
이상에서 표시된 바와 같이, 향상된 질의 플랜은 원래의 질의 플랜보다 더 빠르게 실행된다. 이는, 향상된 질의 플랜이 원래의 질의 플랜에 비하여 더 적은 CPU 사이클들을 소요하기 때문이다. 일부 실시예들에 있어서, 이는, 제 2 동작에 의해 수신되고 프로세싱되는 팩트 레코드들의 수가 원래의 질의 플랜 내에서보다 향상된 질의 플랜 내에서 더 작기 때문이다.
특정 실시예들에 있어서, 제 1 술어 조건을 식별하는 것은, 원래의 질의 플랜 내의 제 1 팩트 테이블에 대하여 동작하는 것으로서 제 1 팩트 스캔 동작을 식별하는 것을 수반한다. 제 1 스캔 동작에서 시작하여, 원래의 질의 플랜은 그런 다음 제 1 팩트 스캔 동작에 대한 하나 이상의 적용가능 술어 조건들의 리스트를 식별하도록 워킹(walk)되며, 적용가능 술어 조건들의 리스트는 제 1 술어 조건을 포함한다.
특정 실시예들에 있어서, 제 1 술어 조건을 식별하는 것은, 원래의 질의 플랜으로부터: 제 1 팩트 스캔 동작이 제 1 팩트 테이블에 대하여 동작하는 것; 제 2 팩트 테이블에 대하여 동작하는 제 2 팩트 스캔 동작; 제 2 팩트 테이블과 차원 테이블 사이의 조인 동작으로서, 여기에서 제 1 술어 조건이 차원 테이블과 연관되는, 조인 동작; 및 제 1 팩트 테이블과 제 2 팩트 테이블 사이의 공통 차원으로서, 여기에서 제 1 술어 조건은 공통 차원으로부터의 속성에 기초하는, 공통 차원을 식별하는 것을 포함한다.
특정 실시예들에 있어서, 제 1 술어 조건을 식별하는 것은 제 1 팩트 스캔 동작에 대하여 적용가능한 복수의 술어 조건들을 식별하는 것을 포함한다. 그런 다음, 순 이득 메트릭(net benefit metric)이 복수의 술어 조건들 내의 각각의 술어 조건에 대하여 계산되며, 여기에서 복수의 술어 조건들 내의 특정 술어 조건에 대한 순 이득 측정은, 팩트 레코드들의 소스로부터 팩트 로우들을 프로세싱하는 비용에서 제 1 팩트 스캔 동작에 특정 술어 조건을 적용하는 비용을 뺀 비용에서의 감소의 측정이다. 그런 다음, 복수의 술어 조건들 내의 술어 조건들이 복수의 술어 조건들에 대한 순 이득 메트릭들에 기초하여 정렬된다. 그러면, 하나 이상의 술어 조건들이 정렬에 기초하여 제 1 팩트 스캔 동작과의 연관을 위해 선택된다. 특정 실시예들에 있어서, 최고 순 이득 메트릭을 갖는 술어 조건이 제 1 팩트 스캔 동작과의 연관을 위해 선택된다.
특정 실시예들에 있어서, 제 1 술어 조건을 식별하는 것은 제 1 팩트 스캔 동작에 대하여 적용가능한 술어 조건을 식별하는 것을 포함한다. 적용가능 술어 조건에 대한 순 이익 메트릭이 계산된다. 적용가능 술어 조건에 대하여 계산된 순 이익 메트릭에 기초하여, 적용가능 술어 조건이 제 1 팩트 스캔 동작과의 연관에 대하여 실행가능하지 않다는 것이 결정된다. 그러면, 제 1 팩트 스캔 동작과 연관될 다른 술어 조건이 기능적 종속성 정보를 사용하여 적용가능 술어 조건으로부터 추론된다.
팩트 레코드들의 소스는 팩트 레코드들을 저장하는 테이블, 구체화된 뷰, 또는 온라인 분석 프로세싱(online analytical processing; OLAP) 인덱스를 포함하는 다수의 유형들일 수 있다.
특정 실시예들에 있어서, 제 1 술어 조건을 식별하는 것은 원래의 질의 플랜 내의 제 3 동작을 식별하는 것을 포함하며, 여기에서 제 1 술어 조건은 제 3 동작과 연관된다. 제 3 동작은 원래의 질의 플랜 내의 차원 테이블과 연관될 수 있다.
특정 실시예들에 있어서, 제 1 술어 조건을 식별하는 것은 제 1 스캔 동작과 연관될 제 2 술어 조건을 식별하는 것, 및 제 2 술어 조건을 제 1 술어 조건으로 변환하는 것을 포함한다. 변환하는 것은 제 2 술어 조건을 제 1 술어 조건으로 변환하기 위하여 기능적 종속성 정보를 사용하는 것을 포함한다. 하나의 경우에 있어서, 제 2 술어 조건은 제 1 차원 필드에 대한 값을 지정하며, 제 1 술어 조건은 제 1 차원 필드와는 상이한 제 2 차원 필드에 대한 값을 지정하고, 여기에서 제 2 차원 필드는 차원 테이블 내의 또는 팩트 레코드들의 소스 내의 컬럼 필드이다.
특정 실시예들에 있어서, 제 1 서브-플랜이 원래의 질의 플랜 내에서 식별될 수 있으며, 제 1 서브-플랜은 제 1 팩트 스캔 동작을 포함하고, 여기에서 제 1 서브-플랜은 하나 이상의 집성, 조인, 프로젝트(project), 필터, 또는 팩트 스캔 동작들을 포함한다. 향상된 질의 플랜은, 생성될 때, 제 1 스캔 동작과 연관되는 제 1 술어 조건을 갖는 제 1 서브-플랜을 포함할 수 있다.
특정 실시예들에 있어서, 프로세싱하는 것은, 스타 스키마에 기초하여, 팩트 레코드들의 소스가 차원 테이블과 조인될 수 있다는 것을 결정하는 것을 포함할 수 있으며, 여기에서, 제 1 술어 조건은 팩트 레코드들의 소스와 조인될 차원 테이블 내의 차원 키(dimension key)와 관련된 조건을 포함한다.
특정 실시예들에 있어서, 팩트 레코드들의 소스는 OLAP 인덱스이며, OLAP 인덱스는 테이블 및 테이블 내의 차원 값들을 인덱싱하는 인덱스를 포함한다. 테이블은 팩트 레코드들을 저장하는 팩트 테이블을 차원 값들을 포함하는 차원 테이블과 조인하는 것으로부터 기인하는 데이터를 포함할 수 있으며, 제 1 술어 조건은 OLAP 인덱스 내의 차원 값들에 대하여 평가된다.
다른 특징들 및 실시예들과 함께 전술한 내용이 다음의 명세서, 청구항들, 및 첨부된 도면들을 참조할 때 더 명백해질 것이다.
도 1a 및 도 1b는 특정 실시예들에 따른 분석 플랫폼의 간략화된 블록도들이다.
도 2는 특정 실시예들에 따른 팩트 및 차원 테이블들의 세트를 도시한다.
도 3은 특정 실시예들에 따른 질의 플랜을 도시한다.
도 4는 특정 실시예들에 따른 스타 스키마를 도시한다.
도 5는 특정 실시예들에 따른 재작성된 질의 실행 플랜을 도시한다.
도 6은 특정 실시예들에 따른 세미-조인(semi-join) 동작을 수행하기 위한 접근 방식을 도시한다.
도 7은 특정 실시예들에 따른 온라인 분석 프로세싱(online analytical processing; OLAP) 인덱스를 도시한다.
도 8a 및 도 8b는 특정 실시예들에 따른 인덱스 세미-조인 동작을 수행하기 위한 접근 방식을 도시한다.
도 9는 특정 실시예들에 따른 기능적 종속성들에 기초하여 술어 조건을 변환하기 위한 접근 방식을 도시한다.
도 10a 및 도 10b는 특정 실시예들에 따른 차원 레코드들의 제 1 세트로부터 차원 레코드들의 제 2 세트에 걸쳐 팩트 레코드들의 세트로 술어 조건을 전파하기 위한 접근 방식을 도시한다.
도 11은 특정 실시예들에 따른 다수의 팩트 테이블들을 포함하는 스키마를 도시한다.
도 12a 내지 도 12c는 특정 실시예들에 따른 (차원 테이블 DT로부터) 차원 레코드들의 세트에 걸쳐 팩트 레코드들의 제 1 세트(팩트 소스 1 "FS1")에 걸쳐 팩트 레코드들의 제 2 세트(팩트 소스 2 "FS2")로 전파하기 위한 접근 방식을 도시한다.
도 13a는 특정 실시예들에 따른 향상된 질의 플랜을 생성하는 방법을 도시하는 간략화된 순서도이다.
도 13b는 특정 실시예들에 따른 향상된 질의 플랜을 생성하는 방법과 관련된 더 많은 세부사항들을 도시하는 간략화된 순서도이다.
도 14는 일 실시예를 구현하기 위한 분산형 시스템의 간략화된 도면을 도시한다.
도 15는 특정 실시예들에 따른 클라우드-기반 시스템 환경의 간략화된 블록도이다.
도 16은 특정 실시예들을 구현하기 위하여 사용될 수 있는 컴퓨터 시스템을 예시한다.
도 17은 특정 실시예들에 따른 다른 스키마를 도시한다.
다음의 설명에 있어서, 설명의 목적들을 위하여, 특정 세부사항들이 특정한 발명적인 실시예들의 완전한 이해를 제공하기 위하여 기술된다. 그러나, 다양한 실시예들이 이러한 특정 세부사항들 없이 실시될 수 있다는 것이 자명할 것이다. 도면들 및 상세한 설명은 제한적인 것으로 의도되지 않는다.
본 개시는 전반적으로 상호작용 애드-혹 데이터베이스 질의들과 같은 분석 질의들의 효율적인 실행을 위한 기술들에 관한 것이다. SQL 애드-혹 질의와 같은 질의에 대하여, 질의에 대하여 생성되는 질의 플랜은 최적화된 또는 향상된 질의 플랜으로서 최적화되고 향상되며 재작성된다. 향상된 질의 플랜은, 실행될 때, 원래의 비-최적화된 질의 플랜보다 더 적은 CPU 사이클들을 사용하여, 그에 따라서 원래의 질의 플랜보다 더 빠르게 실행된다. 결과적으로, 이에 대하여 향상된 질의 플랜이 생성되는 질의는, 획득된 결과들 또는 질의 중인 데이터를 훼손하지 않고 더 빠르게 실행된다. 특정 실시예들에 있어서, 최적화되거나 또는 향상된 질의 플랜은 또한, 실행될 때, 원래의 비-최적화된 질의 플랜보다 더 적은 메모리 자원들을 사용한다.
특정 실시예들에 있어서, 원래의 질의 플랜은, 원래의 질의 플랜 내의 하나 이상의 팩트 스캔 동작들/연산자들의 세트를 식별하는 것, 및 그런 다음, 재작성된 향상된 질의 플랜 내에서, 팩트 스캔 동작들의 세트 중 하나 이상과 차원 콘텍스트를 연관시키는 것에 의해 최적화된다. 특정 실시예들에 있어서, 차원 콘텍스트는, 차원 콘텍스트에 대응하는 하나 이상의 술어(predicate) 조건들(차원 콘텍스트 술어 조건들로서도 지칭됨)과 팩트 스캔 동작의 연관에 의해 팩트 스캔 동작과 연관된다. 팩트 스캔 동작은, 팩트 레코드들의 소스(팩트 소스로도 지칭됨)로부터 팩트들(팩트 레코드들 또는 팩트 로우(row)들로도 지칭됨)을 스캔하거나 또는 판독하도록 구성된 질의 플랜 내의 동작이다. 향상된 질의 플랜 내의 팩트 스캔 동작과 술어 조건의 연관은 또한, 팩트 스캔 동작이 동작하는 팩트 소스로의 술어 조건의 전파 또는 팩트 스캔 동작으로의 술어 조건의 전파로서 지칭된다. 연관들 또는 전파들에 기인하여, 향상된 질의 플랜 내에서 팩트 레코드들을 스캔하는 것/판독하는 것 및/또는 프로세싱하는 것의 전체 비용은 원래의 질의 플랜에 비하여 훨씬 더 적다. 결과적으로, 향상된 질의 플랜은, 실행될 때, 원래의 비-최적화된 질의 플랜보다 더 적은 CPU 사이클들을 사용하며, 그에 따라서 원래의 질의 플랜보다 더 빠르게 실행된다.
특정 실시예들에 있어서, 질의 플랜을 최적화하는 프로세스는, 질의 플랜 내에서 어느 하나 이상의 팩트 스캔 동작들이 술어 조건 전파를 위한 후보들인지를 식별하는 것, 각각의 후보 팩트 스캔 동작과 연관될 하나 이상의 술어 조건들을 식별하는 것, 및 그런 다음 연관들을 가지고 질의 플랜을 재작성하는 것을 포함할 수 있다. 질의에 대한 질의 플랜은 연관들을 가지고 실행된다. 본원에서 개시되는 다양하고 상이한 기술들이 이러한 프로세싱을 수행하기 위해 사용될 수 있다.
팩트 스캔 동작과 연관될 술어 조건을 식별하기 위하여 다양하고 상이한 기술들이 사용될 수 있다. 예를 들어, 원래의 질의 플랜의 하나의 부분으로부터의 술어 조건은 재작성된 향상된 질의 플랜 내의 질의 플랜의 다른 부분 내의 팩트 스캔 동작으로 전파될 수 있다. 일 예로서, 질의 플랜의 하나의 부분 내의 차원 테이블에 적용되는 차원 술어 조건은 질의 플랜의 다른 부분 내의 팩트 스캔 동작으로 전파되고 이와 연관될 수 있다. 일부 다른 경우들에 있어서, 특정 술어 조건을 팩트 스캔 동작과 연관시키는 대신에, 새로운 술어 조건이 질의 플랜 내의 원래의 술어 조건으로부터 또는 특정 술어 조건으로부터 추론되며(새로운 술어 조건으로의 특정 술어 조건의 변환 또는 매핑으로도 지칭됨), 새로운 술어 조건이 특정 술어 조건 대신에 팩트 스캔 동작과 연관된다. 새로운 술어 조건은, 새로운 술어 조건을 가지고 팩트 스캔 동작을 실행하는 것의 비용(예를 들어, 실행 시간)이 특정 술어 조건 또는 원래의 술어 조건을 가지고 팩트 스캔 동작을 실행하는 비용보다 더 작게 하는 그런 것이다. 일부 경우들에 있어서, 질의 내에서 참조되는 팩트 테이블로부터 팩트 레코드들을 스캔하는 대신에, OLAP 인덱스들, 사전-집성된 구체화된 뷰들과 같은 다른 물리적인 팩트 구조체들(팩트 소스들)이 스캔들을 수행하기 위해 사용될 수 있다.
이상에서 표시된 바와 같이, 향상된 질의 플랜은, 실행될 때, 원래의 비-최적화된 질의 플랜보다 더 적은 CPU 사이클들을 사용하여, 그에 따라서 원래의 질의 플랜보다 더 빠르게 실행된다. 이들이 달성될 수 있는 상이한 방식들이 존재한다. 특정 경우들에 있어서, 질의 플랜 내의 팩트 스캔 동작과 술어 조건의 연관에 기인하여, 재작성된 질의 플랜에 의해 프로세싱되는 팩트 레코드들의 수는 원래의 질의 플랜에 비하여 감소된다. 예를 들어, 팩트 스캔 동작과 연관된 술어 조건의 결과로서, 술어 조건을 충족시키는 팩트 레코드들만이 질의 플랜 내에서 팩트 스캔 동작으로부터 다음 하류측(downstream) 동작으로 제공된다. 이는, 향상된 질의 플랜 내의 하류측 동작들(예를 들어, 팩트 테이블과 차원 테이블 사이의 조인 동작)으로 제공되며 이에 의해 프로세싱되어야 할 팩트 레코드들의 수를 감소시킨다. 이는, 향상된 질의 플랜 내에서 하류측 동작들을 수행하는 것과 연관된 계산 오버헤드를 감소시킨다. 술어 조건에 기초하는 팩트 레코드들의 이러한 필터링은 질의 플랜에 의한 팩트 레코드들의 불필요하고 중복적인 프로세싱을 감소시킨다. 질의 플랜에 의해 프로세싱되는 팩트 레코드들의 수의 감소는 질의 플랜에 대한 그리고 그에 따라서 이에 대하여 질의 플랜이 생성되는 질의 자체에 대한 더 빠른 실행 시간을 의미한다. 질의 플랜에 의해 프로세싱되는 팩트 레코드들의 수의 감소는 또한 재작성된 질의 플랜을 실행하기 위해 사용되는 더 적은 메모리 자원들을 의미할 수 있다. 이상에서 설명된 바와 같이, 특정 실시예들에 있어서, 특정 술어 조건으로부터 추론되거나 또는 변환된 새로운 술어 조건이 특정 술어 조건 대신에 팩트 스캔 동작과 연관될 수 있다. 새로운 술어 조건은, 새로운 술어 조건을 가지고 팩트 스캔 동작을 실행하는 것의 비용(예를 들어, 실행 시간)이 특정 술어 조건을 가지고 팩트 스캔 동작을 실행하는 비용보다 더 작게 하는 그런 것이다. 예를 들어, 특정 술어 조건과 연관된 팩트 스캔 동작은 실행하기 위해 2 초를 소요할 수 있으며, 반면 새로운 술어 조건과 연관된 팩트 스캔 동작은 실행하기 위해 단지 1 초만을 소요할 수 있다. 술어 조건을 추론하는 것 또는 변환하는 것은 향상된 질의 플랜 실행을 비-최적화된 질의 플랜보다 더 빠르게 만든다. 추가적으로, 특정 실시예들에 있어서, 더 빠른 실행 시간은, 팩트 표현의 스캔 성능들을 레버리지(leverage)하기 위한 방식으로 OLAP 인덱스들과 같은 이용가능한 대안적인 팩트 표현들에 대하여 팩트 스캔들을 수행함으로써 달성된다. 예를 들어, 일부 경우들에 있어서, 조합이, 팩트 스캔 프로세싱에서 몇 자릿수의 감소를 야기하는, OLAP 인덱스들의 스캔을 스킵하고 빠른 술어 평가를 레버리지할 수 있도록, 일부 술어 "P"에 대하여 OLAP 인덱스 스캔으로 변환된다.
성능 관점으로부터, 향상된 질의 플랜들은 더 빠르게 실행될 수 있으며, 잠재적으로 비-향상된 질의 플랜들보다 더 적은 자원들을 사용할 수 있다. 본원에서 개시되는 교시들에 기초하여 실행되는 상당한 수의 질의들은 비-향상된 질의 플랜들을 갖는 질의들보다 10X, 25X 내지 심지어 100X만큼, 또는 훨씬 더 높은 자릿수들만큼 더 빠르게 실행된다. 이는, 팩트 테이블들이 차원 테이블들보다 몇 자릿수 더 크며, 그에 따라서 팩트 레코드들을 프로세싱하는 것과 연관된 스캔 비용들을 감소시키는 것이 막대한 성능 이득들을 초래하기 때문이다. 예를 들어, 하나의 경우에 있어서, 애드-혹 질의에 대한 질의 실행 시간은 206 초로부터 16 초로 감소되었다. 질의들이 대규모 데이터 세트(예를 들어, 테라바이트 데이터 세트들)에 대하여 1 초 미만의 시간 내에 실행될 수 있다.
정보의 다양하고 상이한 피스(piece)들이 본원에서 설명되는 질의 플랜 최적화를 가능하게 하기 위해 사용될 수 있다. 특정 실시예들에 있어서, 데이터베이스 질의들에 대하여 생성되는 질의 플랜들은: 질의의 구조, 질의에 대하여 생성되는 질의 플랜의 구조, 질의되는 데이터베이스에 관한 스키마 정보, 및 질의 플랜 최적화기 및/또는 인핸서에 대하여 이용가능한 의미(semantics) 정보에 기초하여 최적화되고 향상될 수 있다. 예를 들어, 비지니스 의미 또는 비지니스 인텔리전스(business intelligence; BI) 의미 정보가 질의 플랜들을 재작성하기 위해 사용될 수 있다. 의미 정보는 풍부한 가치를 갖는 비지니스 데이터 및 현실 프로세스들, 조직 구조들, 및 유사한 것에 기초하는 구조적 의미를 포함할 수 있다. 의미 정보는 데이터 내의 비지니스 계층들 및 기능적 종속성들과 같은 비지니스 모델에 대한 정보를 포함할 수 있다. 예를 들어, 종속성 정보는 데이터베이스 데이터의 상이한 필드들(예를 들어, 컬럼(column)들) 사이의 관계들(예를 들어, 계층적 또는 비-계층적)을 설명하는 정보를 포함할 수 있다. 예를 들어, 종속성 메타데이터는 "도시" 컬럼의 값들과 "주" 컬럼의 값들 사이의 계층적 관계를 설명하는 정보를 포함할 수 있다(예를 들어, 샌프란시스코는 캘리포니아 주 내의 도시이다). 계층들의 예들은, 시간 기간 계층들(예를 들어, 일, 주, 달, 분기, 년, 등), 지리적 계층들(예를 들어, 도시, 주, 나라), 및 유사한 것을 포함한다. 의미 정보는 데이터 큐브 모델 의미 정보를 포함할 수 있다. 특정 실시예들에 있어서, 질의 플랜 향상을 위해 사용되는 메타데이터는 분석되는 데이터가 물리적으로 저장되는 방식 및 또한 논리적 정보가 데이터 사이의 관계들을 식별하는 방식에 대한 정보를 포함할 수 있다. 특정 실시예들에 있어서, 의미 정보는, 임의의 사용자 입력 없이, 분석되는 데이터를 저장하는 데이터베이스의 구조 및 스키마에 대한 정보를 분석하는 것으로부터 결정될 수 있다. 이러한 분석으로부터 도출되는 추론들은 최적화되고 향상된 질의 플랜을 생성하기 위하여 질의 플랜을 재작성하기 위해 사용될 수 있다.
예를 들어, 질의에 대하여 생성되는 질의 플랜이 팩트 소스들에 대한 팩트 스캔 동작들을 식별하기 위해 분석될 수 있다. 그런 다음, 의미 정보(예를 들어, 팩트 및 차원 콘텍스트 테이블들의 조인 동작들, 데이터베이스의 컬럼들 사이의 기능적 종속성, 팩트들의 물리적 구체화(materialization))는 재작성된 최적화된 질의 플랜 내의 팩트 스캐닝 동작들에 대한 차원적 콘텍스트 조건들을 능동적으로 식별하고 푸시하기 위해 사용될 수 있다. 이는 재작성된 질의 플랜 내의 팩트 레코드들을 프로세싱하기 위해 수반되는 비용들(예를 들어, 시간)의 상당한 감소를 초래한다. 따라서 재작성된 질의 플랜은 더 빠르게 실행되며(예를 들어, 더 적은 CPU 사이클들을 사용하며), 다수의 경우들에 있어서, 비-최적화된 질의 플랜보다 더 적은 메모리 자원들을 사용할 수 있다. 이는, 더 빠르게 실행되며 잠재적으로 더 적은 메모리 자원들을 사용하는 이에 대하여 질의 플랜이 생성되는 질의로 변환된다.
도 1a는 예시적인 실시예를 통합하는 분석 플랫폼 또는 인프라스트럭처(100)의 간략화된 블록도이다. 분석 플랫폼(100)은 하나 이상의 통신 네트워크들을 통해 서로 통신가능하게 결합된 다수의 시스템들을 포함할 수 있다. 도 1a의 시스템은 하나 이상의 통신 네트워크들을 통해 서로 통신가능하게 결합된 프로세싱 시스템(150) 및 저장 시스템(106)을 포함한다. 통신 네트워크들은 도 1a에 도시된 다양한 시스템들 사이의 통신들을 가능하게 할 수 있다. 통신 네트워크는 다양한 유형들일 수 있으며, 하나 이상의 통신 네트워크들을 포함할 수 있다. 이러한 통신 네트워크의 예들은, 비제한적으로, 인터넷, 광역 네트워크(wide area network; WAN), 근거리 네트워크(local area network; LAN), 이더넷 네트워크, 공중 또는 사설 네트워크, 유선 네트워크, 무선 네트워크, 및 유사한 것, 및 이들의 조합들을 포함한다. IEEE 802.XX 프로토콜 묶음(suite), TCP/IP, IPX, SAN, AppleTalk®, Bluetooth®, 및 다른 프로토콜들과 같은 유선 및 무선 프로토콜들 둘 모두를 포함하는 상이한 통신 프로토콜들이 통신을 가능하게 하기 위하여 사용될 수 있다. 통신 네트워크는, 도 1a에 도시된 다양한 시스템들 사이의 통신들을 가능하게 하는 임의의 인프라스트럭처를 포함할 수 있다.
도 1a에 도시된 분석 플랫폼(100)은 단지 일 예이며, 청구되는 실시예들의 범위를 과도하게 제한하려고 의도되지 않는다. 플랫폼은, 질의되는 데이터의 크기의 변화들 및 작업부하(예를 들어, 병렬로 또는 달리 수행되는 질의들의 수)의 변화들을 수용하기 위하여 요구되는 바와 같이 탄력적으로 스케일링될 수 있다. 당업자는 다수의 가능한 변형예들, 대안예들, 및 수정예들을 인식할 것이다. 예를 들어, 일부 실시예들에 있어서, 분석 플랫폼(100)은 도 1a에 도시된 것보다 더 많거나 또는 더 적은 시스템들 또는 컴포넌트들을 가질 수 있거나, 2개 이상의 시스템들을 결합할 수 있거나, 또는 시스템들의 상이한 구성 또는 배열을 가질 수 있다. 추가로, 도 1a에 도시되고 본원에서 설명되는 인프라스트럭처는, (사설, 공중 및 하이브리드 클라우드 환경들을 포함하는 다양한 유형들의 클라우드들일 수 있는) 사내 또는 클라우드 환경, 사내 환경, 하이브리드 환경, 및 유사한 것으로서, 독립형 또는 클러스터 실시예를 포함하는 다양하고 상이한 환경들에서 구현될 수 있다.
특정 실시예들에 있어서, 분석되거나 또는 질의될 데이터는 저장 시스템(106)에 의해 저장될 수 있다. 저장 시스템(106) 내에 저장된 데이터는 하나 또는 다수의 데이터 소스들로부터 올 수 있다. 데이터는 객체 저장, 블록 저장, 컴퓨터 노드들 상의 디스크들에서와 같은 단지 디스크들의 묶음(jbod), 및 유사한 것, 및 이들의 조합들과 같은 다양한 형태들로 조직되고 저장될 수 있다. 저장 시스템(106)은 데이터를 저장하기 위한 휘발성 메모리 및/또는 비-휘발성 메모리를 포함할 수 있다. 예를 들어, 저장 시스템(106)은, 분석될 비지니스 데이터를 저장하는 데이터베이스를 포함할 수 있다. 비지니스 데이터는 일반적으로 다-차원이며 의미론적으로 풍부하다. 저장 시스템(106)은, 데이터를 유지하며 또한 특정 질의 작업부하들을 최적으로 서비스하는 방식으로 관계/공간/그래프 데이터의 저장을 위한 무수한 데이터 구조체들을 제공하는 소프트웨어를 포함하는 물리적인 저장 컴포넌트들(예를 들어, 회전식 하드 디스크들, SSD들, 메모리 캐시들, 등)을 포함하는 분석 플랫폼(100)의 저장 계층을 나타낸다. 저장 시스템(106) 내의 데이터는 모두 하나의 위치에 할당될 필요는 없으며, 분산형 방식으로 저장될 수 있다. 데이터는 데이터 레이크, 데이터 웨어하우스, 하둡 클러스터, 및 유사한 것과 같은 다양한 저장/컴퓨팅 환경들에서 조직되고 저장될 수 있다.
저장 시스템(106) 및 프로세싱 시스템(150)의 메모리 자원들은 시스템 메모리 및 비-휘발성 메모리를 포함할 수 있다. 시스템 메모리는 하나 이상의 프로세서들에 대한 메모리 자원들을 제공할 수 있다. 시스템 메모리는 전형적으로 휘발성 랜덤 액세스 메모리(random access memory; RAM)(예를 들어, 동적 랜덤 액세스 메모리(dynamic random access memory; DRAM), 동기식 DRAM(Synchronous DRAM; SDRAM), 이중 데이터 레이트 SDRAM(Double Data Rate SDRAM; DDR SDRAM))의 형태이다. 하나 이상의 프로세서들에 의해 실행되는 프로세스들 또는 애플리케이션들 및 운영 시스템에 관한 정보가 시스템 메모리 내에 저장될 수 있다. 예를 들어, 런타임(runtime) 동안, 운영 시스템/커널이 시스템 메모리 내로 로딩될 수 있다. 추가적으로, 런타임 동안, 서버 컴퓨터에 의해 실행되는 하나 이상의 애플리케이션에 관한 데이터가 시스템 메모리 내로 로딩될 수 있다. 예를 들어, 서버 컴퓨터에 의해 실행되는 애플리케이션이 시스템 메모리 내로 로딩되고 하나 이상의 프로세서들에 의해 실행될 수 있다. 서버 컴퓨터는 다수의 애플리케이션을 병렬로 실행할 수 있을 수 있다.
비-휘발성 메모리는 지속될 데이터를 저장하기 위해 사용될 수 있다. 비-휘발성 메모리는, 하드 디스크, 플로피 디스크, 플래시 메모리, 고체-상태 드라이브 또는 디스크(SSD), USB 플래시 드라이브, 메모리 카드, 메모리 스틱, 테이프 카세트, 집 카세트, 컴퓨터 하드 드라이브, CD들, DVD들, 네트워크-부착형 저장부(Network-attached storage; NAS), 저장 영역 네트워크(Storage Area Network; SAN)을 통해 제공되는 메모리 저장부, 및 유사한 것과 같은 상이한 형태들로 제공될 수 있다. 특정 경우들에 있어서, 애플리케이션이 서버 컴퓨터로 배포되거나 또는 서버 컴퓨터 상에 설치될 때, 애플리케이션 관련 정보가 비-휘발성 메모리 내에 저장될 수 있다.
특정 실시예들에 있어서, 저장 시스템(106) 내의 데이터는, 하나 이상의 스타 스키마와 같이 논리적으로 구조화된 테이블들 내에서 또는 다-차원 어레이들(일반적으로 다-차원 큐브들로도 지칭됨)과 같은 특수화된 저장 구조체들을 갖는 시스템들 내에서 관계 데이터베이스 내에 저장될 수 있다. 스타 스키마는 임의의 수의 차원 테이블들을 참조하는 중심 팩트 테이블로 구성된다. 각각의 팩트 테이블들은 팩트 레코드들의 형태로 팩트들 또는 메트릭들을 저장한다. 팩트 테이블들은, 팩트들을 그들의 콘텍스트와 연관시키는 차원 테이블들에 링크될 수 있다. 차원 테이블들은, 팩트 테이블 로우들에 저장된 메트릭 데이터를 설명하는 콘텍스트 정보를 저장한다. 팩트 테이블이 일반적으로 다수의 차원들과 연관되기 때문에, 그래픽적으로 구조체는 스타와 같이 나타나며 그에 따라서 이러한 명칭을 갖는다. 일반적으로 팩트들의 수와 고유 차원 값들의 수 사이에는 자릿수의 차이가 존재하며, 여기에서 팩트들은 차원들보다 수가 훨씬 더 많다. 예를 들어, 기업에 대하여 수억 개의 판매 팩트 레코드들이 존재할 수 있지만, 스토어들, 판매된 주들, 등과 같이 소수의(예를 들어, 수천 개의) 차원들만이 존재한다. 결과적으로, 팩트 테이블들의 크기는 일반적으로 매우 크며, 차원 테이블들보다 자릿수만큼 더 크다.
용어 스타 스키마는 본원에서 다수의 차원 테이블 로우들을 갖는 팩트 로우들 사이의 논리적 관계를 캡처하기 위하여 가장 일반적인 형태로 사용되며; 따라서, 눈송이 스키마들과 같은 변형들이 또한 본 개시에서 사용되는 바와 같은 용어 스타 스키마 하에서 암시되고 포함된다. 눈송이 스키마들은, 팩트 로우들과 차원들 사이의 관계가 간접적일 수 있다는 점에서 스타 스키마들과 구별된다(이는, 예를 들어, 판매 팩트 로우들이 고객 주소 로우에 링크되는 고객 로우에 링크되는 것과 같은, 직접 연관 보다 더 많은 것을 요구함).
분석 데이터를 살펴보기 위한 다른 방식은 n-차원 큐브와 같다. 전형적인 분석은 이러한 방대한 다-차원 공간의 어떤 임의적인 서브공간(슬라이스로도 지칭됨)에 초점을 맞춘다. 임의의 특정 분석의 초점은 다수의 차원들 및 액티비티들에 걸칠 수 있으며, 다수의 단계들을 가지고, 엔티티들과 그들의 액티비티들 사이의 임의적인 링키지들을 수반할 수 있다. 관계형 세계에서, 데이터 큐브들은 스타 스키마들로서 모델링될 수 있다.
관계형 데이터베이스에 있어서, 이벤트 또는 트랜잭션(transaction)(예를 들어, 제품의 판매)은, 다수의 차원 테이블들을 조인하는 큰 팩트 테이블 내에 캡처될 수 있다. 분석 솔루션은, 팩트 테이블들이 차원들의 공통 세트를 갖는, 다수의 이러한 스타 스키마들을 포함할 수 있다. 도 4는 스토어 반품(return)들을 저장하기 위한 트랜잭션들에 관련된 데이터에 대응하는 예시적인 스타 스키마(400)를 도시한다. 스키마(400)는 스토어 반품 트랜잭션들을 캡처하며, 팩트 레코드들과 차원 레코드를 사이의 1-대-다수 관계들을 설명한다. 도 4에 도시된 스키마(400)에 대하여, 스토어_반품(Store_Returns)은 (강조된 테두리를 사용하여 도시된) 스토어 반품 트랜잭션들에 관한 메트릭 정보를 포함하는 팩트 레코드들을 저장하는 팩트 테이블이며, 다른 테이블들(날짜(Date), 스토어(Store), 아이템(Item), 고객(Customer), 고객_주소(Customer_Address))은 팩트 레코드들에 대한 콘텍스트 정보를 저장하는 차원 테이블들이다. 각각의 반품 트랜잭션은, 스토어 식별자, 도시 및 주, 아이템을 반품한 고객에 관한 정보, 트랜잭션의 시간 정보(달, 일, 년)을 포함하여 반품된 스토어에 관한 정보를 포함하는 연관된 콘텍스트를 가지고 레코딩된다. 스타 스키마(400)는, 스토어 반품들이 날짜, 고객, 아이템, 스토어, 및 고객_주소 차원 레코드들에 의해 차원화되며, 스토어_반품 팩트 레코드들과 조인될 수 있다는 것을 나타낸다.
도 2는, 팩트 테이블(202) 및 각기 도 4에 도시된 스타 스키마(400)에 대응하는 팩트 테이블(202)과 관련되는 복수의 차원 테이블들(204-208)을 포함하는 예시적인 데이터베이스 데이터(200)를 도시한다. 팩트 테이블(202)은, 팩트 테이블(202)에 컬럼들을 추가하지만 로우들은 추가하기 않기 위하여, 각기 테이블(204) 내의 1차 키 컬럼(218), 테이블(206) 내의 1차 키 컬럼(226), 및 테이블(208) 내의 1차 키 컬럼(230)과 조인될 수 있는 외래(foreign) 키 컬럼들(210, 212, 및 214)을 포함한다. 도 2가 데이터베이스 데이터(200)를 테이블들로서 도시하지만, 데이터베이스 데이터(200)가 인덱스들, 구체화된 뷰들, 및/또는 임의의 다른 튜플(tuple)들의 세트로서 표현될 수 있다는 것이 이해되어야 한다.
도 2의 예에 있어서, 팩트 테이블(202)은 팩트 메트릭 컬럼(216)(return_amt)을 저장하는 팩트 레코드들을 더 포함한다. 외래 키 컬럼들(210, 212, 및 214)은, 차원 컬럼들(220, 222, 224, 228, 232, 및 234)과 같은 하나 이상의 차원 컬럼들과 관련하여 팩트 메트릭 컬럼(216)이 분석되는 것을 가능하게 한다. 일반적으로, 그리고 도 2에 도시된 바와 같이, 전형적으로 차원 레코드들보다 훨씬 더 많은 팩트 레코드들이 존재한다. 예를 들어, 팩트 레코드는 수백만 개일 수 있으며, 반면 차원 레코드들은 수천 개일 수 있다.
프로세싱 시스템(150)은 저장 시스템(106)에 의해 저장된 데이터의 분석을 가능하게 하도록 구성될 수 있다. 분석은 SQL 질의들과 같은 분석 질의들을 사용하여 수행될 수 있다. 프로세싱 시스템(150)은 하나 이상의 질의들(130)을 수신하도록 구성될 수 있다. 특정 사용 케이스에 있어서, 질의들(130)은 프로세싱 시스템(150)에 의해 제공되는 인터페이스를 사용하여 사용자에 의해 입력될 수 있다. 다른 케이스들에 있어서, 질의들(130)은 다른 애플리케이션들, 시스템들 또는 디바이스들로부터 프로세싱 시스템(150)에 의해 수신될 수 있다. 일부 사용 케이스들에 있어서, 프로세싱 시스템(150)은 그 자체의 질의들을 생성할 수 있다.
특정 실시예들에 있어서, 질의에 대하여, 프로세싱 시스템(150)은 질의에 대한 향상된 질의 플랜을 생성하도록 구성된다. 이하에서 더 상세하게 설명되는 다양하고 상이한 기술들이 향상된 질의 플랜을 생성하기 위해 사용될 수 있다. 그런 다음, 프로세싱 시스템(150)은 저장 시스템(106)에 의해 저장된 데이터에 대하여 향상된 질의 플랜을 실행하고 결과 세트를 생성할 수 있다. 그런 다음, 프로세싱 시스템(150)은 수신된 질의에 대한 응답으로서 결과 세트를 출력할 수 있다.
도 1a에 도시된 실시예에서와 같이, OLAP 인덱싱(126)(예를 들어, OLAP 인덱스들)이 관계형 데이터베이스 내에서 팩트 소스들로부터 매우 빠르게 팩트들을 스캔/판독하기 위하여 제공될 수 있다. 특정 실시예들에 있어서, 프로세싱 시스템(150)은 OLAP 인덱스들(126) 중 하나 이상을 생성하도록 구성될 수 있다.
특정 실시예들에 있어서, 도 1a에 도시된 분석 플랫폼(100)은 하나 이상의 컴퓨터들의 클러스터 상에서 실행될 수 있다. 예를 들어, 분석 플랫폼(100)은 Apache Spark 또는 Apache Hadoop에 의해 제공되는 분산형 컴퓨팅 프레임워크를 사용하여 구현될 수 있다. 각각의 컴퓨터는 하나 이상의 프로세서들(또는 중앙 프로세싱 유닛(CPU)들), 메모리, 저장 디바이스들, 네트워크 인터페이스, I/O 디바이스들, 및 유사한 것을 포함할 수 있다. 이러한 컴퓨터의 일 예가 도 16에 도시되며 이하에서 설명된다. 하나 이상의 프로세서들은 단일 또는 다중코어 프로세서들을 포함할 수 있다. 하나 이상의 프로세서들의 예들은, 비제한적으로, 범용 마이크로프로세서들 예컨대, 연관된 메모리 내에 저장된 소프트웨어의 제어 하에서 동작하는 Intel®, AMD®, ARM®, Freescale Semiconductor, Inc., 및 유사한 것에 의해 제공되는 것들을 포함할 수 있다. 분석 플랫폼(100)의 소프트웨어 컴포넌트들은 운영 시스템의 상단 상에서 애플리케이션으로서 실행될 수 있다. 서버 컴퓨터에 의해 실행되는 애플리케이션은 하나 이상의 프로세서들에 의해 실행될 수 있다.
프로세싱 시스템(150)에 의해 생성된 향상된 질의 플랜의 결과로서, 이에 대하여 향상된 질의 플랜이 생성된 질의의 실행이 더 빨라 진다. 이는 질의들에 대한 더 빠른 응답 시간을 의미한다. 이러한 빠른 응답 시간은, 분석되는 데이터의 결과들을 훼손하지 않고 상호작용적인 방식으로 저장 시스템(106) 내에 저장된 다차원 데이터의 분석을 가능하게 한다. 상호작용 질의들은, 예를 들어, 기계 학습 기술들, 클릭 스트림들 및 이벤트/시간-시리즈와 연관된 데이터에 대하여, 그리고 더 일반적으로는 크기 및 복잡도가 빠르게 성장할 수 있는 임의의 데이터세트들에 대하여 실행될 수 있다.
추가로, 질의들은, 임의의 사전-집성된 데이터에 대하여 실행되는 것이 아니라, 저장 시스템(106) 내의 데이터베이스들 내에 저장된 데이터에 대하여 직접적으로 실행된다. 따라서, 질의들은 사전-집성된 데이터 또는 추출물들을 생성할 필요 없이 많은 데이터세트들에서 대하여 제위치에서 실행될 수 있다. 그 대신에, 질의는 실제 원래의 원시(raw) 데이터 자체에 대하여 수행될 수 있다. 특정 실시예들에 있어서, 질의는, 본원에서 설명되는 바와 같은, 완전 분산형 컴퓨터 엔진을 가지고 인-메모리 OLAP 인덱스들을 사용하여 그리고 술어 조건들을 사용함으로써 더 빠르게 이루어진다. 이는 분석 플랫폼(100)이, 사전-집성된 데이터에 대하여 실행될 수 없는 애드-혹 질의들을 용이하게 하는 것을 가능하게 한다. 애드-혹 질의는, 미리-정의되지 않는 것이다. 애드-혹 질의는 일반적으로, 이것이 이용가능하게 될 때 정보를 분석하기 위해 생성된다. 본원에서 설명되는 분석 플랫폼(100)은 매우 비용 효율적인 방식으로 매우 큰(테라바이트 및 그 이상의) 다차원 데이터(예를 들어, 데이터 레이크에 저장된 데이터)에 대한 상호작용 애드-혹 질의들을 실행할 수 있는 능력을 제공하며; 과거에 통상적인 기술들을 사용하여 매우 큰(테라바이트 및 그 이상의) 다차원 데이터에 대하여 이러한 상호작용 질의들을 실행하는 것은 비용이 매우 높았고 스케일링될 수 없었다.
추가로, Apache Spark를 사용하는 분석 플랫폼의 구현은 선천적으로 질의가 규모에 맞게 수행되는 것을 가능하게 한다. 컴퓨터 및 저장부(예를 들어, 분석을 위해 이용가능한 새로운 데이터)가 독립적으로 스케일링될 수 있는 탄력적인 환경이 제공된다.
분석 플랫폼(100)에서, 질의될 데이터는, 이것이 이로부터 하나 이상의 상이한 분석 툴들을 사용하여 분석될 수 있는 중심 위치에 저장된다. 상이한 툴들에 의해 가능하게 하기 위한 데이터의 고유한 준비들이 요구되지 않는다. 상이한 사용자들은, 파이선 또는 R을 실행하는 제플린 또는 주피터 노트북들, 태블로(Tableau)와 같은 BI 툴들, 및 유사한 것을 포함하는 사용자가 선택한 툴들을 가지고 데이터를 액세스할 수 있다.
큰 볼륨의 다차원 데이터에 대하여 대규모로 상호작용 질의를 수행하는 것이 어렵다. 이는, 상호작용 질의가 빠른 응답 시간을 요구하기 때문이다. 많은 양의 다차원 데이터에 대하여, 데이터의 볼륨(예를 들어, 테라바이트의 데이터)이 증가함에 따라 그리고 동시에 데이터세트들을 액세스하려고 시도하는 사용자들의 수가 증가함에 따라 질의 성능이 저하된다. 추가로, 팩트 및 차원 테이블들 사이의 조인들이 추가적인 성능 병목 현상들을 초래할 수 있다. 과거에는, 이러한 문제를 완화하기 위하여 사전-집성 기술들이 사용되었다. 예를 들어, 다차원 데이터의 분석을 가능하게 하기 위하여 OLAP 큐브들, 추출물들, 및 구체화된 사전-집성된 테이블들이 사용되었다.
사전-집성된 데이터(집성된 데이터 또는 집성물들로도 지칭됨)는, 하나 이상의 사전-집성(또는 집성) 기술들을 사용하여 어떤 기초 데이터(원본 또는 원시 데이터로도 지칭됨)로부터 생성된 데이터이다. 데이터 집성 또는 사전-집성 기술들은, 데이터가 요약(summary) 형태로 표현되는 임의의 프로세스를 포함한다. 사전-집성된 데이터는 사전 계산된 또는 요약된 데이터를 포함할 수 있으며, 사전-집성된 테이블들, 추출물들, OLAP 큐브들, 등 내에 저장될 수 있다. 팩트들이 집성될 때, 이는 차원성(dimensionality)을 제거함으로써 또는 팩트들을 롤 업(roll up)된 차원과 연관시킴으로써 수행된다. 따라서, 사전-집성된 데이터는, 이로부터 사전-집성된 데이터가 생성되는 원본 또는 원시 데이터로부터의 모든 세부사항들을 포함하지는 않는다.
그러나, 사전-집성은 몇몇 부정적인 측면들을 갖는다. 모든 사전-집성 기술들을 세분성의 손실을 야기한다. 사전-집성은, 오로지 특정한 미리-결정된 사전-집성들만이 제공되기 때문에 데이터의 세부사항들에서 손실을 야기한다. 예를 들어, 원본 또는 원시 데이터세트는 일별(per day) 단위로 판매 정보를 레코딩할 수 있다. 그런 다음 월 단위에 기초하는 사전-집성이 이러한 데이터에 대하여 수행되는 경우, 일별 또는 일일 정보가 손실된다. 모든 차원들 및 메트릭들의 모든 조합들에 대하여 사전-집성 데이터 세트들 또는 큐브들을 구축하는 것은 비현실적이다. 따라서, 사전-집성은 애드-혹 질의를 수행하기 위한 능력을 제한하며, 이는 더 높은-레벨의 사전-집성된 요약들(예를 들어, 월별 정보) 뒤의 키 정보(예를 들어, 일별 정보)가 이용가능하지 않기 때문이다. 질의들은, 이로부터 사전-집성들이 생성되었던 원본 또는 원시 데이터에 대하여 수행되는 것이 아니라 사전-집성된 데이터에 대하여 수행된다. 따라서, 집성은 분석이 수행될 수 있는 그레인(grain)을 변화시킨다. 팩트들의 그레인은, 이벤트들이 레코딩되는 최저 레벨을 지칭한다. 예를 들어, 제품의 판매는 판매 시간 및 타임스탬프를 가지고 레코딩될 수 있다. 판매들의 집성은 채널 및 제품에 의한 수익 또는 카테고리, 제품, 스토어, 주, 등에 의한 수익과 같이 다수의 레벨들에 걸칠 수 있다. 다수의 세분성들 및 차원들에서 데이터를 탐색(explore)하기 위한 능력이 중요하다. 사전-집성을 위한 올바른 세분성은 미리 예측하기 어렵다. 따라서, 사전-집성된 큐브들 및 구체화된 요약 테이블들은, 이것이 빅 데이터 분석과 관련될 때 고장이 난다.
분석 플랫폼(100)은 사전-집성 기반 분석 기술들과 연관된 다양한 부정적인 측면들을 회피한다. 분석 플랫폼(100)은, 상이한 세분성들 및 차원들에서 대규모 및 고속으로 다차원 데이터의 데이터 분석을 수행하기 위한 프레임워크를 제공한다.
본 출원의 목적들에 대하여, 용어 "비-사전-집성된 데이터"는, 사전-집성된 또는 사전-계산된 데이터를 포함하지 않는 데이터를 지칭하기 위해 사용된다. 특정 실시예들에 있어서, 분석 플랫폼(100)은 질의가 저장 시스템(106) 내에 저장된 비-사전-집성된 데이터에 대하여 수행되는 것을 가능하게 한다. 이는 저장 시스템(106) 내에 저장된 비-사전-집성된 데이터에 대하여 애드-혹 질의가 수행되는 것을 가능하게 한다. 추가적으로, 프로세싱 시스템(150)에 의해 제공되는 질의 플랜 향상들 때문에, 질의에 대한 응답 시간이 극적으로 감소되며, 그에 따라 상호작용 질의들이 실행되는 것을 가능하게 한다. 본원에서 설명되는 분석 플랫폼(100)은 매우 비용 효율적인 방식으로 매우 큰(테라바이트 및 그 이상의) 다차원 데이터(예를 들어, 데이터 레이크에 저장된 데이터)에 대한 상호작용 애드-혹 질의들을 실행할 수 있는 능력을 제공하며; 과거에 통상적인 기술들을 사용하여 매우 큰(테라바이트 및 그 이상의) 다차원 데이터에 대하여 이러한 상호작용 질의들을 실행하는 것은 비용이 매우 높았고 스케일링될 수 없었다.
도 1b는 특정 실시예들에 따른 도 1a에 도시된 분석 플랫폼(100)의 더 상세한 도면을 도시하는 간략화된 블록도이다. 도 1b에 도시된 분석 플랫폼(100)은 단지 일 예이며, 제한적으로 의도되지 않는다. 당업자는 다수의 가능한 변형예들, 대안예들, 및 수정예들을 인식할 것이다. 예를 들어, 일부 실시예들에 있어서, 데이터 분석 플랫폼(100)은 도 1b에 도시된 것보다 더 많거나 또는 더 적은 컴포넌트들을 가질 수 있거나, 2개 이상의 컴포넌트들을 결합할 수 있거나, 또는 컴포넌트들의 상이한 구성 또는 배열을 가질 수 있다. 추가로, 도 1b에 도시되고 본원에서 설명되는 인프라스트럭처는, 독립형 실시예, (사설, 공중 및 하이브리드 클라우드 환경들을 포함하는 다양한 유형들의 클라우드들일 수 있는) 클라우드 환경, 사내 환경, 하이브리드 환경, 및 유사한 것을 포함하는 다양하고 상이한 환경들에서 구현될 수 있다.
도 1b의 예에 있어서, 도 1a에 도시된 프로세싱 시스템(150)은, 서로 그리고 또한 저장 시스템(106)에 통신가능하게 결합될 수 있는 데이터 분석 시스템(102) 및 데이터베이스 관리 시스템(database management system; DBMS)(104)을 포함한다. 일부 실시예들에 있어서, 데이터 분석 시스템(102), DBMS(104), 및 저장 시스템(106)은 OLAP 데이터베이스 시스템의 상이한 논리적 계층들을 나타낼 수 있다. 일부 실시예들에 있어서, 데이터 분석 시스템(102), DBMS(104), 및 저장 시스템(106)은 물리적으로 별개의 시스템들일 수 있다. 다른 실시예들에 있어서, 이들은 하나의 시스템으로 결합될 수 있다. DBMS(104) 및 데이터 분석 시스템(102)은 함께, Apache Spark의 기능들과 비지니스 인텔리전스 기술들을 결합하는 강력한 분석 플랫폼을 제공한다.
저장 시스템(106)은 실제로 분석될 데이터 및 차원 테이블들을 저장할 수 있다. 도 1b에 도시된 바와 같이, 팩트 테이블들(124), OLAP 인덱스들(126), 구체화된 뷰들(128), 및/또는 다른 소스들을 포함하는 팩트 레코드들의 다수의 소스들(108)이 존재할 수 있다. 팩트 테이블(124)은 하나 이상의 로우들 및 하나 이상의 컬럼들을 포함할 수 있으며, 여기에서 각각의 로우는 팩트 레코드들을 나타낼 수 있고 컬럼들은 레코드들의 필드들을 나타낼 수 있다. 일부 실시예들에 있어서, 저장 시스템(106)은 환경(100) 내에서 분산되거나 및/또는 가상화될 수 있다.
저장 시스템(106)은, 하나 이상의 차원 레코드들을 저장하는 하나 이상의 차원 테이블들(110)로서 팩트 레코드들과 연관된 콘텍스트를 또한 저장할 수 있다. 전형적으로, 팩트 레코드들은, 차원 테이블들(110) 내의 차원 레코드들과 관련하여 분석될 수 있는 메트릭에 대한 값들을 저장한다. 예를 들어, 팩트 레코드들은 판매 액수를 포함할 수 있으며, 차원 레코드들은, 이에 따라 판매 액수들이 집성되거나, 필터링되거나, 또는 달리 분석될 수 있는 데이터 값들을 포함할 수 있다. 팩트 레코드 소스들(108)(예를 들어, 팩트 테이블들, OLAP 인덱스들, 및 구체화된 뷰들) 및 차원 테이블들(110) 및 레코드들은 이하에서 더 상세하게 논의된다.
저장 시스템은 메타데이터(109)를 저장할 수 있다. 메타데이터(109)는 테이블들, 컬럼들, 뷰들, 등과 같은 관계형 아티팩트들에 대한 정보를 저장할 수 있다.
도 1b의 예에 있어서, 저장 시스템(106)은 스키마 정보(116) 및 통계 자료 정보(112)와 같은 데이터베이스 관리 시스템과 연관된 정보의 다른 피스들을 추가로 저장할 수 있다. 스키마 정보(116)는 데이터베이스와 연관된 테이블들, 인덱스들, 및 다른 아티팩트들의 구조를 식별할 수 있다. 예를 들어, 스타 스키마에 대하여, 스키마 정보(116)는 팩트 레코드들 및 차원 레코드들 사이의/이들 중의 관계들을 설명하는 정보를 포함할 수 있다. 예를 들어, 스키마 정보(116)는, 판매 데이터가 시간 차원 및 지리적 영역 차원에 따라 질의될 수 있다는 것을 결정하기 위해 사용될 수 있다. 특정 실시예들에 있어서, 스키마 정보(116)는 도메인 전문가 또는 분석가에 의해 정의될 수 있다. 스키마 정보(116)는 도 4 및 도 9에 도시된 스키마들과 같은 스타 스키마를 정의할 수 있다.
통계 자료(112)는 데이터베이스 관리 시스템(104)의 성능 관련 속성들 및 질의 플랜과 관련된 다른 정보 및 팩트 레코드들 또는 차원 레코드들에 대한 정보를 포함할 수 있다. 예를 들어, 통계 자료(112)는 테이블-레벨 통계 자료(예를 들어, 테이블 내의 로우들의 수, 테이블에 대하여 사용되는 데이터 블록들의 수, 또는 테이블 내의 평균 로우 길이) 및/또는 컬럼-레벨 통계 자료(예를 들어, 컬럼 내의 별개의 값들의 수 또는 컬럼 내에서 발견되는 최소/최대 값)를 포함할 수 있다.
DBMS(104)는, 하나 이상의 데이터베이스들이 생성되는 것, 데이터가 데이터베이스에 추가되는 것, 데이터베이스 내에 저장된 데이터가 업데이트되거나 및/또는 삭제되는 것, 및 데이터베이스들 및 저장된 데이터를 관리하는 것과 관련된 다른 기능들을 가능하게 하는 기능성을 제공하도록 구성된다(예를 들어, 하나 이상의 프로세서들에 의해 실행될 때, 이러한 기능성을 가능하게 하는 소프트웨어를 포함한다). DBMS(104)는 또한, 저장 시스템(106) 내에 저장된 데이터를 분석하기 위한 하나 이상의 질의들(130)을 수신하고, 질의들에 대응하는 분석을 수행하며, 질의 결과들(132)을 출력하도록 구성될 수 있다. 질의들(130)은 구조화 질의 언어(Structured Query Language; SQL)와 같은 상이한 언어들 및 형식들일 수 있다.
질의(130)는 DBMS(104)의 사용자와 같은 하나 이상의 소스들로부터, 다른 시스템으로부터, 및 유사한 것으로부터 수신될 수 있다. 예를 들어, 도 1b에 도시된 실시예에 있어서, 특정 경우들에 있어서, 질의는 데이터 분석 시스템(data analytics system; DAS)(102)으로부터 수신될 수 있다. DAS(102)는 저장 시스템(106) 내에 저장된 데이터의 분석을 수행하도록 구성될 수 있다. DAS(102)는, 저장 시스템(106)에 의해 저장된 데이터에 대한 DBMS(104)에 의한 실행을 위하여 분석 질의들을 생성하도록 구성된 소프트웨어를 포함할 수 있다. 예를 들어, 저장 시스템(106)이 판매 레코드들을 저장하는 경우, DAS(102)는 판매 레코드들을 분석하기 위한 질의들(예를 들어, 판매 경향들을 분석하기 위한 질의들, 광고 캠페인들을 분석하기 위한 질의들, 및 비지니스 액티비티들에 대한 유용한 패턴들을 추출하거나 또는 이에 대한 통창들을 획득하기 위한 다른 질의들)을 생성하고 이를 DBMS(104)로 전송할 수 있다. 특정 실시예들에 있어서, DAS(102)는 분석 질의를 생성하기 위하여 저장 시스템(106) 내에 저장된 정보(예를 들어, 스키마 정보(116))를 사용할 수 있다. 예를 들어, 스타 스키마(116)는 시간 차원 및 지리적 영역 차원에 따라 판매 데이터가 질의될 수 있다는 것을 결정하기 위해 사용될 수 있다. DAS(102)로부터 수신된 질의들에 대응하는 DBMS(104)에 의해 검색된 결과들이 DBMS(104)에 의해 DAS(102)로 제공될 수 있다.
도 1b에 도시된 바와 같이, DBMS(104)는 질의들(130)을 수신하기 위한 인터페이스(122)를 제공할 수 있다. 파서(parser)(120)는 수신된 질의의 구문(syntactic) 및 의미 분석을 수행하도록 구성될 수 있다. 예를 들어, SQL 질의에 대하여, 파서(120)는, 정확한 구문에 대하여 질의 내의 SQL 문(SQL statement)들을 체크하고 질의 내에서 참조되는 데이터베이스 객체들 및 다른 객체 속성들이 정확한지 여부를 체크하도록 구성될 수 있다.
질의가 파서(120)에 의해 수행된 구문 및 의미 체크들을 통과한 이후에, 최적화기(optimizer)(114)는 질의를 효율적으로 실행하기 위한 질의 플랜을 결정하도록 구성될 수 있다. 최적화기(114)는 질의를 최적으로 실행하기 위한 질의 플랜을 출력할 수 있다. 특정 실시예들에 있어서, 실행 플랜은 실행될 동작들/연산자들의 시리즈 또는 파이프라인을 포함한다. 실행 플랜은 루트형(rooted) 트리 또는 그래프에 의해 표현될 수 있으며, 여기에서 트리 또는 그래프의 노드들은 개별적인 동작들/연산자들을 나타낸다. 질의 플랜 그래프는 일반적으로 그래프의 리프(leaf)들로부터 시작하여 루트를 향해 진행하도록 실행된다. 질의 플랜의 리프들은 전형적으로 제 1 스캔 동작들을 나타내며, 여기에서 팩트 레코드들 또는 로우들이 팩트 테이블과 같은 팩트 소스로부터 스캔되거나 또는 판독된다. 질의 플랜 내의 임의의 관계형 연산자의 출력은 계산된 데이터세트이다. 질의 플랜 내의 동작에 의해 반환되는 계산된 데이터세트(예를 들어, 로우들 또는 레코드들의 세트)는 질의 플랜 파이프라인 내의 다음 동작(부모 동작 또는 하류측 동작으로도 지칭됨)으로 입력으로서 제공되고 이에 의해 소비된다. 질의 플랜 파이프라인 내의 마지막 동작(질의 플랜 그래프의 루트)에서, 팩트 로우들이 SQL 질의의 결과로서 반환된다. 따라서, 질의 플랜 내의 특정 동작에 의해 반환되는 로우들은 질의 플랜 파이프라인 내의 다음 동작(특정 동작의 부모 동작 또는 하류측 동작)에 대한 입력 로우들이 된다. 동작에 의해 반환되는 로우들의 세트는 로우 세트로서 지칭되며, 로우 세트를 생성하는 질의 플랜 내의 노드는 로우 소스로서 지칭된다. 따라서, 질의 플랜은 하나의 동작으로부터 다른 동작으로의 로우 소스들의 흐름을 나타낸다. 질의 플랜 내의 각각의 동작은 데이터베이스로부터 로우들을 검색하거나 또는 하나 이상의 다른 자식 또는 상류측 동작들(또는 로우 소스들)로부터 로우들을 수리(accept)한다.
특정 실시예들에 있어서, 최적화기(114)는 질의 플랜을 새성하기 위하여 비용-기반 최적화를 수행할 수 있다. 특정 실시예들에 있어서, 최적화기(114)는, I/O, CPU 자원들, 및 메모리 자원들의 최소 양(최적 스루풋)을 사용하여 질의를 실행할 수 있는, 질의에 대한 질의 플랜을 생성하기 위해 노력할 수 있다. 최적화기(114)는, 질의 플랜을 생성하기 위하여, 팩트 소스들(108), 스키마 정보(116), 힌트들, 및 통계 자료(112)에 대한 정보와 같은 정보의 다양한 피스들을 사용할 수 있다. 특정 실시예들에 있어서, 최적화기(114)는 잠재적인 플랜들의 세트를 생성하고 각각의 플랜에 대한 비용을 추정할 수 있으며, 여기에서 플랜에 대한 비용은 플랜을 실행하기 위해 필요한 예상되는 자원 사용에 비례하는 추정된 값이다. 플랜에 대한 비용은 플랜 내의 액세스 경로들, 동작들(예를 들어, 조인 동작들)에 기초할 수 있다. 액세스 경로들은, 데이터베이스로부터 데이터가 검색되는 방식들이다. 팩트 테이블 내의 로우 또는 레코드는 완전 테이블 스캔(예를 들어, 스캔은 팩트 테이블 내의 모든 로우들/레코드들을 판독하고, 선택 기준을 충족시키지 않는 것들을 필터링하여 제거함), 인덱스를 사용하는 것(예를 들어, 로우는, 인덱싱된 컬럼 값들을 사용하여 인덱스를 검토(traverse)함으로써 검색됨), 구체화된 뷰들 또는 로우아이디(rowid) 스캔들을 사용하는 것에 의해 검색될 수 있다. 그러면, 최적화기(114)는 플랜들의 비용을 비교하고 최저 비용을 갖는 플랜을 선택할 수 있다.
특정 실시예들에 있어서, 인핸서(103)는 최적화기(114)에 의해 선택된 질의를 추가로 향상시키거나/최적화하고, 향상되고 최적화된 질의 플랜을 생성하도록 구성된다. 인핸서(103)에 의해 생성된 향상된 질의 플랜은 최적화기(114)에 의해 생성된 질의 플랜보다 더 양호하며, 이는 이것이 비-향상된 질의 플랜보다 더 빠르게 실행되고, 다수의 경우들에 있어서, 비-향상된 질의 플랜보다 더 적은 메모리 자원들을 사용할 수 있기 때문이다.
그런 다음, 인핸서(103)에 의해 생성된 최적화되고 향상된 질의 플랜이 실행기 서브시스템(105)에 제공될 수 있으며, 이는 저장 시스템(106) 내에 저장된 데이터에 대하여 질의 플랜을 실행하도록 구성된다. 그런 다음, 인핸서(103)로부터 수신된 질의 플랜을 실행하는 것으로부터 실행기(105)에 의해 획득된 결과들이 입력 질의에 대한 결과 응답으로서 DBMS(104)에 의해 반환될 수 있다. 실행기(105)는, 이들에게 제공된 향상된 질의 플랜에 기초하여 질의들을 프로세싱하는 런타임 프로세스들의 실행 계층을 나타낼 수 있다. 이들은, 데이터 튜플 스트림들에 대하여 동작하고 이들을 특정 방식들로 변환하는 연산자/동작 구현예(예를 들어, SQL, 그래프, 공간(Spatial), 등)를 포함할 수 있다.
인핸서(103)는 최적화기(114)에 의해 생성된 질의 플랜으로부터 향상된 질의 플랜을 생성하기 위해 다양한 기술들을 사용할 수 있다. 특정 실시예들에 있어서, 인핸서(103)는 최적화기(114)에 의해 생성된 질의 플랜을 추가로 최적화하고 향상시키기 위하여 DAS(102)에 의해 저장된 메타데이터/의미 정보(117)를 사용할 수 있다. 예를 들어, (예를 들어, 스타 스키마 의미 모델로부터) 스타 스키마에 대하여 이용가능한 의미 정보에 기초하여, 인핸서(103)는, 팩트 레코드들의 소스의 스캔 동작 동안 적용가능한 최적화기(114)에 의해 생성된 질의 플랜 내의 차원 콘텍스트/술어 조건들을 추론하도록 구성될 수 있다. 이러한 추론된 정보는 최적화기(114)에 의해 생성된 질의 플랜을 추가로 최적화하기 위하여 인핸서(103)에 의해 사용될 수 잇다. 특정 실시예들에 있어서, 인핸서(103)는, (예를 들어, 스타 스키마 또는 큐브의 의미 모델 내의) 의미 데이터에서 정의된 필드/컬럼 기능적 종속성들을 사용하여, 팩트 레코드들의 소스에 대한 스캔 동작에 대하여 적용가능한 술어 조건들로서 추론된 차원 콘텍스트/술어들을 변환하는 방법을 수행한다. 특정 경우들에 있어서, 인핸서(103)는, 인덱스 내의 데이터 구조체들을 레버리지하는 팩트 레코드들의 인덱스 소스(예를 들어, OLAP 인덱스 팩트 소스)에 대하여 추론된 차원 콘텍스트/술어 조건들을 적용할 수 있다.
일반적으로, 본 출원의 목적들을 위하여, 용어 팩트 소스는 팩트 레코드들의 소스를 지칭하기 위해 사용된다. 팩트 소스는, 팩트의(예를 들어, 팩트 레코드의) 소스인 임의의 관계일 수 있다. 팩트 소스는 원래의 팩트 테이블 또는 팩트들의 어떤 다른 구체화일 수 있다. 일반적인 구체화 기술들은 OLAP 인덱스들과 같은 큐브 표현 및 사전-집성된 뷰들을 포함한다. 예를 들어, 팩트 소스는, 팩트 테이블(예를 들어, 스타 스키마에 기초하는 관계형 데이터 베이스 내의 팩트 테이블), 인덱스(예를 들어, 다차원 공간의 임의의 임의적인 서브-영역에 대한 팩트들을 빠르게 액세스하기 위한 능력을 제공하는 미리-조인된 인덱스와 같은 스타 스키마 또는 큐브 상의 OLAP 인덱스), 또는 구체화된 뷰(예를 들어, 스타 스키마에 대한 어떤 집성 레벨에서 구체화된 뷰)일 수 있다. 팩트 소스는, 팩트 레코드들(예를 들어, 비지니스 팩트들)의 소소인 임의의 데이터세트 또는 테이블을 나타낸다. 팩트들은 특정 차원 그레인 일 수 있다.
이상에서 표시된 바와 같이, 인핸서(103)는 차원 콘텍스트/술어 조건들을 추론하기 위하여 메타데이터/의미 정보(117)를 사용할 수 있다. 의미 정보(117)는 비지니스 인텔리전스 정보를 포함할 수 있다. 예를 들어, 의미 정보(117)는 풍부한 가치를 갖는 비지니스 데이터 및 현실 프로세스들, 조직 구조들, 큐브 정보, 및 유사한 것에 기초하는 구조적 의미를 포함할 수 있다. 의미 정보는 데이터 내의 비지니스 계층들 및 기능적 종속성들과 같은 비지니스 모델에 대한 정보를 포함할 수 있다. 이러한 계층 및 종속성 정보는, 향상된 질의 플랜을 생성하여 질의들의 실행을 가속하는 결과를 야기하기 위해 인핸서(103)에 의해 사용된다. 예를 들어, 종속성 메타데이터 정보는 데이터베이스 데이터의 상이한 필드들(예를 들어, 컬럼들) 사이의 (예를 들어, 계층적 또는 비-계층적) 관계들을 설명하는 정보를 포함할 수 있다. 예를 들어, 종속성 메타데이터는 "도시" 필드 컬럼의 값들과 "주" 필드 컬럼의 값들 사이의 계층적 관계를 설명하는 정보를 포함할 수 있다(예를 들어, 샌프란시스코는 캘리포니아 주 내의 도시이다). 인핸서(103)는, 질의 서브-플랜들 내의 팩트 소스 스캔들에 대한 술어 조건 적용가능성을 추론하기 위하여, 질의 서브-플랜들의 세분성과 함께, 종속성 메타데이터를 사용할 수 있다. 특정 실시예들에 있어서, 의미 정보는, 임의의 사용자 입력 없이, 질의에 의해 분석되는 데이터를 저장하는 데이터베이스의 구조 및 스키마에 대한 정보를 분석하는 것으로부터 결정될 수 있다.
질의 플랜을 향상시키기 위해 인핸서(103)에 의해 사용되는 의미 정보는 다수의 소스들로부터 이용가능할 수 있거나 이들로부터 확인될 수 있다. 일 예로서, 의미 정보는 비지니스 인텔리전스(BI) 데이터 소스들로부터 이용가능할 수 있다. 예를 들어, 도 1b에 도시된 실시예에서 도시되는 바와 같이, DAS(102)는 의미 정보(117)를 포함하는 BI 정보를 저장하는 다양한 데이터 소스들을 포함할 수 있거나 또는 이에 대한 액세스를 가질 수 있다. 다른 실시예들에 있어서, 의미 정보는, 데이터를 저장하기 위해 사용되는 데이터 구조들 및 분석되는 데이터의 구조일 수 있다. 예를 들어, 분석되는 데이터를 저장하는 데이터베이스에 대하여, 데이터베이스에 대한 스키마 정보(116)는 의미 정보를 결정하기 위해 사용될 수 있다. 인핸서(103)는 술어 조건 적용들을 추론하기 위하여 그리고 입력 질의 내의 술어들에 기초하여 추가로 술어 조건들을 추론하기 위하여 스키마 정보(116)를 사용할 수 있다.
최적화기(114) 및 인핸서(103)가 도 1b에서 별개의 서브시스템들로 도시되었지만, 이는 제한적으로 의도되지 않는다. 대안적인 실시예들에 있어서, 인핸서(103)는 최적화기(114)의 부분일 수 있다. 이러한 실시예에 있어서, 최적화기(114)가 질의 플랜을 선택하며, 그런 다음 본 개시에서 설명되는 기술들을 사용하여 이를 향상시킨다. 특정 실시예들에 있어서, 인핸서(103)는 DBMS(104) 대신에 DAS(102)의 부분일 수 있다. 이러한 시나리오에서, DBMS(104)는 향상된 질의 플랜을 생성하기 위해 DAS(102)와 함께-동작하도록 작동할 수 있다. 특정 실시예들에 있어서, 파서(120), 최적화기(114), 인핸서(103), 및 실행기(105)는 집합적으로 DBMS(104)의 질의 엔진으로서 지칭될 수 있다.
이상에서 표시된 바와 같이, 그런 다음, 도 2에 도시된 예와 같은 데이터 레코드들을 저장하는 데이터베이스는 SQL 질의들과 같은 분석 질의들을 사용하여 분석될 수 있다. 전형적인 질의는, 차원 테이블들과 그리고 서로 결합된 하나 이상의 팩트 소스들을 수반할 수 있다. 특정 실시예들에 있어서, 본원에서 개시되는 바와 같이, 인핸서(103)는, 프로세싱되는 팩트 로우들의 수가 상당히 감소되도록 및/또는 스캔 동작을 수행하는 전체 비용이 감소되도록, 각각의 팩트 소스 스캔의 관점으로부터 질의에 대하여 최적화기에 의해 생성된 질의 플랜을 분석하며, 팩트 로우들에 대하여 적용될 수 있는 차원 콘텍스트(예를 들어, 차원 필터들)를 추론하려고 시도한다. 스타-조인들(그들의 차원 콘텍스트와 팩트 소스들의 결합을 나타내는 조인들)의 경우에 있어서, 하기의 내용이 추론되고 팩트 소스들에 적용될 다양한 차원 콘텍스트들을 식별하기 위해 사용될 수 있다:
● 스타 스키마의 에지들을 따른 조인들이 무손실 분해(decomposition)의 결합(따라서, 어떠한 새로운 팩트들도 도입되지 않음)을 나타내는 팩트가 사용될 수 있다.
● 스타 스키마의 의미 모델 내의 기능적 종속성들이 사용될 수 있다.
● OLAP 인덱스 팩트 소스들의 경우에 있어서, 재작성들이 수행될 수 있다.
팩트 소스가 그들의 차원들과의 사전-조인 팩트들일 수 있기 때문에, 스타 스키마 내의 조인들은 팩트 소스의 콘텍스트 내의 팩트 소스 조인들로서 분류된다. 스타 스키마 조인들은, 팩트 소스를 형성할 때 검토되는 것들이다.
데이터베이스(200) 내에 저장된 데이터를 분석하기 위하여 데이터베이스 데이터(200)에 대하여 실행될 분석 질의가 수신될 수 있다. 이러한 질의의 일 예가 질의 A로서 이하에서 도시된다:
질의 A
1) WITH customer_total_return AS
2) ( SELECT
3) customer_key AS ctr_customer_key,
4) store_key AS ctr_store_key,
5) SUM(return_amt) AS ctr_total_return
6) FROM store_returns sr, date d
7) WHERE sr.date_key = d.date_key AND year = 2000
8) GROUP BY customer_key, store_key)
9) SELECT customer_id
10) FROM customer_total_return ctr1, store s, customer c
11) WHERE ctr1.ctr_total_return >
12) (SELECT AVG(ctr_total_return) * 1.2
13) FROM customer_total_return ctr2
14) WHERE ctr1.ctr_store_key = ctr2.ctr_store_key)
15) AND store_key = ctr1.ctr_store_key
16) AND state = 'TN'
17) AND ctr1.ctr_customer_key = customer_key
18) ORDER BY customer_id
19) LIMIT 100
질의 A와 등가의 자연 언어는 "'문제가 되는' 고객-스토어와 관계들을 식별하되, 여기에서 '문제가 되는'은 스토어에 대하여 평균의 20%를 초과하는 반품 액수를 갖는 관계들로서 정의되는" 것이다. 질문은 고객들 및 이들이 방문하는 스토어들의 관계에 관한 것이며, 전체 고객 거동에 관한 것이 아니다. 추가로, 분석은 테네시 주에 대하여 이루어졌다.
이상에서 도시된 질의 A와 같은 질의의 수신 시에, 데이터베이스 관리 시스템은 질의를 파싱하고 그런 다음 질의에 대한 질의 플랜을 생성하도록 구성된다. 그런 다음, 데이터베이스 관리 시스템에 의해 질의 플랜이 질의에 관한 결과들을 획득하기 위하여 저장된 데이터 레코드들에 대하여 수행된다. 도 3은, 질의 A에 의해 생성될 수 있는 질의 플랜(300)의 논리적 트리 또는 그래픽 표현이다. 질의 플랜(300)은 최적화기(114)에 의해 생성되고 선택된 질의 플랜을 나타낼 수 있다. 질의 플랜(300)은, 관계 테이블들 내의 데이터들 대하여 동작하는 방식의 논리적 흐름 그래프를 나타낸다. 이상에서 설명된 바와 같이, 질의 플랜은 질의 플랜 파이프라인 내에서 하나의 동작으로부터 다른 동작으로의 로우 소스들의 흐름을 나타낸다. 질의 플랜 내의 각각의 동작은 데이터베이스로부터 로우들을 검색하거나 또는 하나 이상의 다른 동작들(또는 로우 소스들)로부터 로우들을 수리한다.
질의 플랜(300)은, 팩트 또는 차원 테이블들을 나타내는 4개의 리프 노드들을 포함한다. 질의 플랜 내의 비-리프 노드들은 다양한 관계 연산자들을 나타낸다. 도 3에 도시된 예들은 필터 연산자, 조인 연산자, 집성 연산자, 및 프로젝트 연산자를 포함한다. 비-리프 노드는 입력들로서 그것의 자식 노드들에 의한 로우 출력들을 취하며 비-리프 노드에 의해 출력되는 로우들은 비-리프 노드의 부모 노드들에 대한 입력으로서 제공되거나, 또는, 비-리프 노드가 루트 노드인 경우, 루트 노드에 의해 출력되는 로우들 또는 레코드들이 질의 실행의 결과로서 제공된다. 예를 들어, 도 3에서, 노드(310)는 입력들로서 노드들(308 및 304)에 의해 출력되는 로우들을 취하며, 노드(308)는 입력으로서 노드(306)에 의해 출력되는 로우들을 취하고, 노드(304)는 입력으로서 스토어 테이블의 스캔에 의해 반환되는 로우들 또는 레코드들을 취한다.
질의 플랜(300) 내에서, 좌측 집성 서브-플랜(302)은 고객 및 스토어 그레인들에서 반품 액수를 계산하는 것을 수반하며, 우측 집성 서브-플랜(312)은 스토어 그레인에서 반품 액수들을 계산한다. 그런 다은, 이들은, 그들의 반품 액수가 대응하는 스토어 평균을 20%만큼 초과하는 고객, 스토어 조합들에 대한 정보를 추출하기 위해 조인된다. 그 이후에, 스토어의 주가 테네시인 것에 대하여 로우들이 필터링된다.
질의들은 일반적으로 다수의 계층들을 수반하며, 이들 중 일부는 원시 팩트들로부터 값들을 계산하는 빌딩 블록(building block) 계층들이다. 예를 들어, 분석 질의는, 세트들 중 상단/하단-n개의 조인, 유니온, 배열 및 취하는 것과 같은 동작들에 의해 결합되는 다차원 계산들의 계층으로서 생각될 수 있다. 심지어 질의 A에 의해 제거되는 상대적으로 간단한 질문도 질의 플랜(300) 내에 도시된 바와 같은 스토어 반품 스타 스키마에 대하여 다수의 집성-조인(Aggregate-Join) 패스(pass)들을 수행하는 것을 수반한다. 각각의 집성-조인은 매우 큰 팩트 테이블들을 스캔하는 것을 수반하며 하나 이상의 차원 테이블과 조인하고, 여기에서 차원 테이블들 중 대부분은 팩트 테이블에 비하여 작다.
도 3에 도시된 질의 플랜(300)은, 질의 A의 라인2-8의 서브질의에 대응하는 서브-플랜(302)을 포함한다. 도 3의 예에서, 서브 플랜(302)이 서브질의에 대응하지만, 질의 서브-플랜이 서브질의들에 한정되지 않는다는 것이 이해되어야 한다. 오히려, 질의 서브-플랜은 데이터베이스 질의의 임의의 부분에 대응할 수 있다.
서브-플랜(302)은 질의 A의 라인 7의 술어를 평가하기 위한 필터 동작 및 조인 동작을 포함한다. 플랜(300)에 따르면, 술어 조건 "년 = 2000"은 "날짜" 차원 레코드들에 대하여 평가될 것이며, 그럼으로써 이들을 필터링한다. 그 후에, 술어 조건 "sr.날짜_키 = d.날짜_키"가 "스토어_반품" 팩트 레코드들을 필터링된 "날짜" 차원 레코드들과 조인함으로써 평가될 것이다. 그러나, 조인 동작을 수행하는 것은 계산 집중적일 수 있으며, 이는 이것이 전형적으로 많은 수의(예를 들어, 수백만 개의) 팩트 레코드들의 프로세싱을 수반하기 때문이다.
서브-플랜(302)에 연결되지 않은 질의 플랜(300)의 별개의 브랜치(branch)에서, 플랜(300)은 추가로, 질의 A의 라인 16에 대응하는 필터 동작(304)(주 = 'TN'에 대한 필터링)을 더 포함한다. 플랜(300)에 따르면, 필터 동작(304)은 서브-플랜(302)의 동작들과는 별개로 수행될 것이다. 그 후에, 필터링된 "스토어" 차원 레코드들은 노드들(306 및 308)을 통과한 이후에 서브-플랜(302) 내의 동작들을 실행한 결과들 중 일부와 조인될 것이다.
플랜(300)은 팩트 테이블 스토어_반환에 대한 2개의 팩트 스캔들을 수반한다. 그러나, 전체 질의의 콘텍스트는 테네시 주 및 2000 년이다. 그러나, 플랜(300) 내에서, 팩트 소스 스토어_반품의 스캔을 포함하는 서브-플랜(302)은 주가 테네시인 것들로만 레코드들을 제한하지 않는다. 결과적으로, 비-테네시 레코드들이 또한 서브-플랜(302) 내에서 조인 동작에 대한 프로세싱을 위하여 그리고 서브-플랜(302)으로부터 조인 동작(306)으로 제공된다. 따라서, 이러한 팩트 레코드들(즉, 모든 주들에 대하여 2000 년의 스토어 반품들)이 불필요하게 동작들(306, 308, 및 310)로 이월(carry forward)될 것이며, 이는, 310에서, TN 내에 있지 않은 이러한 팩트 레코드들이 조인되지 않고 필터링될 것이기 때문이다. 306, 308, 및 310을 통해 이러한 불필요한 레코드들을 전달하는 것은, 질의 플랜 내에서 이월되는 레코드들의 수에 기인하여 질의 플랜(300)의 실행을 위해 필요한 자원들과 관련하여 낭비적이며, 질의 플랜(300)의 실행을 위해 필요한 시간을 추가한다(즉, 질의 실행이 더 많은 시간을 소요한다). 이는 상당한 낭비되는 계산 자원들을 야기하며, 증가된 실행 시간을 초래한다.
특정 실시예들에 있어서, 인핸서(103)는, 질의 플랜의 하나의 부분으로부터 TN 필터 조건을 추론하고, 전체 질의 플랜의 실행을 통해 전달되는 팩트 레코드들의 수를 감소시키기 위하여 및/또는 스캔 동작을 수행하는 전체 비용을 감소시키기 위하여 추론된 조건이 질의 플랜의 다른 관련되지 않은 부분에 적용되도록 질의 플랜을 변화시키도록 구성된다. 질의 플랜을 재작성하는 것은 팩트 레코드들의 불필요한 프로세싱 및 이월을 방지하는 것을 돕는다. 질의 플랜(300)은 스타 스키마 정보(116) 및/또는 의미 메타데이터(117)로부터 도출된 추론들을 사용하여 재작성될 수 있다. 인핸서(103)는 질의 플랜(300)을 재작성하기 위해 스타 스키마(116) 및/또는 의미 메타데이터(117)를 사용할 수 있다.
예를 들어, 도 4에 도시된 바와 같이, 스타 스키마(400)는, "스토어" 차원 레코드들이 "스토어-반품" 팩트 레코드들과 조인될 수 있다는 것을 나타낸다. 따라서, 인핸서(103)는, "스토어" 차원 레코드들을 필터링하기 위한 술어 조건이 또한 "스토어_반품" 팩트 레코드들을 필터링하기 위하여 사용될 수 있다는 것을 추론할 수 있다.
스타 스키마(116) 및/또는 의미 메타데이터(117)로부터 도출된 추론들에 기초하여, 인핸서(103)는, 질의 플랜 내에서 질의 서브-플랜 외부로부터 질의 서브-플랜 내부로 질의 플랜 내의 술어 조건을 전파함으로써 질의 플랜(300)을 재작성하고 향상시킬 수 있다. 질의 플랜의 서브-부분 또는 서브-플랜에 연결되지 않은 술어 조건은, 재작성 이후에 서브-플랜으로부터 출력되는 팩트 레코드들의 수가 재작성 이전의 서브-플랜으로부터 출력되는 팩트 레코드들의 수보다 더 작아지도록 및/또는 서브-플랜 내에서 스캔 동작을 수행하는 전체 비용이, 질의 실행으로부터 획득되는 전체 질의 결과들에 영향을 주지 않으면서 감소되도록, 서브-플랜 또는 서브-부분 내로 삽입되거나 또는 이와 연관된다. 이러한 방식으로, 재작성의 결과로서, 원래의 질의 플랜들에서 이후의 동작 동안 필터링 될 것이었던 무관한 팩트 레코드들은, 재작성의 결과로서, 질의 플랜 내에서 더 일찍 지금 필터링되어 제거되며, 그럼으로써 질의 플랜의 실행 시에 이월되어야 하는 팩트 레코드들의 수를 감소시키고 불필요한 후속 프로세싱을 회피한다. 이상에서 표시된 바와 같이, 팩트 레코드들은 수백만 개일 수 있다. 따라서, 질의 플랜 파이프라인에서 질의 플랜 내의 하나의 동작으로부터 질의 플랜 내의 다른 동작으로 이월되어야 하는 팩트 레코드들의 수를 감소시키는 것이 전체 질의 실행을 상당히 개선하며(즉, 이를 더 빠르게 만들며), 상당한 양의 계산 자원들(예를 들어, I/O 자원들, 프로세싱(예를 들어, CPU) 자원들, 및 메모리 자원들)의 낭비를 감소시킨다.
도 5는, 특정 실시예들에 따른 질의 A를 실행하기 위해 인핸서(103)에 의해 생성될 수 있는 재작성된 향상된 질의 플랜(500)의 논리적 트리 또는 그래픽 표현이다. 플랜(500)은 도 3에 도시된 플랜(300)의 재작성된 버전을 나타낸다. 플랜(500)은, 질의 A의 라인2-8의 서브질의에 대응하는 서브-플랜(502)을 포함한다. 도 5에서, 도 3의 서브-플랜(302)은 서브-플랜(502)으로 재작성되었다. 서브-플랜(302)과 비교하면, 재작성된 서브-플랜(502)은 "년 = 2000" 조건을 가질 뿐만 아니라, 이제는 추가적인 조건("주 = TN")을 갖는다. 이러한 방식으로, 질의 플랜(300) 내의 동작(304)으로부터의 "주 = TN" 술어 조건은 (년 = 2000에 더하여) 추가적인 조건으로서 서브-플랜(502) 내의 필터 동작으로 전파되었다. 2개의 조건들 모두를 갖는 이러한 재작성된 필터 동작(504)은 "스토어-반품" 팩트 테이블로부터 스캔된 팩트 레코드들에 적용된다. 따라서, 서브-플랜(302)(또는 더 구체적으로, 필터 동작(304))은, 도 3의 필터 동작(304)으로부터의 필터 조건을 서브-플랜(502) 내의 필터 동작(504)으로 전파함으로써 인핸서(103)에 의해 서브-플랜(502)으로 재작성되었다.
유사한 방식으로, 도 5에서, 도 3의 서브-플랜(312)은 서브-플랜(512)으로 재작성되었다. 서브-플랜(312)과 비교하면, 재작성된 서브-플랜(512)은 "년 = 2000" 조건을 가질 뿐만 아니라, 이제는 추가적인 조건("주 = TN")을 갖는다. 이러한 방식으로, 질의 플랜(300) 내의 동작(304)으로부터의 "주 = TN" 술어 조건은 (년 = 2000에 더하여) 추가적인 조건으로서 서브-플랜(512) 내의 필터 동작으로 전파되었다. 2개의 조건들 모두를 갖는 이러한 재작성된 필터 동작(506)은 "스토어-반품" 팩트 테이블로부터 스캔된 팩트 레코드들에 적용된다. 따라서, 서브-플랜(312)(또는 더 구체적으로, 필터 동작(304))은, 도 3의 필터 동작(304)으로부터의 필터 조건을 서브-플랜(512) 내의 필터 동작(506)으로 전파함으로써 인핸서(103)에 의해 서브-플랜(512)으로 재작성되었다.
이상에서 설명된 방식으로 질의 플랜을 재작성하는 것은, 계산 자원들이 무관한 팩트 레코드들의 추가적인 프로세싱에서 낭비되지 않도록 팩트 소스 스토어_반품으로부터 테네시와 무관한 임의의 팩트 레코드들을 필터링하여 제거하는 것을 가능하게 한다. 서브-플랜(302)과 비교해 보면, 필터 동작(504) 및 서브-플랜(502)에 의해 출력되며 프로젝트 플랜(500) 내의 추가적인 동작들(예를 들어, 조인 동작(508))에 대하여 이용가능하게 된 팩트 레코드들의 수는, 서브-플랜(302)에 의해(특히, 서브-플랜(302) 내의 조인 동작에 의해) 출력되며 질의 플랜(300) 내의 다음 동작에 대하여 이용가능하게 된 레코드들의 수보다 훨씬 더 적다. 이는, TN 조건에 매칭되는 레코드들만이 플랜(500) 내의 하류측 동작들(예를 들어, 서브-플랜(502)에 의해 출력되는 팩트 레코드들을 획득하는 조인 동작)로 필터 동작(504) 및 서브-플랜(502)에 의해 출력되며; 비-테네시 레코드들이 필터링되어 제거되기 때문이다. 유사한 방식으로, 서브-플랜(312)과 비교해 보면, 필터 동작(506) 및 서브-플랜(512)에 의해 출력되며 프로젝트 플랜(500) 내의 추가적인 동작들(예를 들어, 조인 동작(508))에 대하여 이용가능하게 된 팩트 레코드들의 수는, 서브-플랜(312)에 의해(특히, 서브-플랜(312) 내의 조인 동작에 의해) 출력되며 질의 플랜(300) 내의 다음 동작에 대하여 이용가능하게 된 레코드들의 수보다 훨씬 더 적다. 이는, TN 조건에 매칭되는 레코드들만이 플랜(500) 내의 하류측 동작들(예를 들어, 서브-플랜(512)에 의해 출력되는 팩트 레코드들을 획득하는 조인 동작(508))로 필터 동작(506) 및 서브-플랜(512)에 의해 출력되며; 비-테네시 레코드들이 필터링되어 제거되기 때문이다. 이는 조인 동작에 제공되는 레코드들의 수의 상당한 감소를 야기할 수 있으며; 팩트 테이블의 크기에 따라 팩트 레코드들의 수의 감소는 100X 또는 그 이상이다. 서브-플랜들(502 및 512), 플랜(500)에 의해 출력되는 팩트 레코드들의 수의 이러한 감소의 결과로서 그리고 (실행을 위한 더 적은 CPU 사이클들을 요구하는 것에 기인하여) 결과적으로 이에 대하여 질의 플랜(500)이 생성되는 대응한 질의가 더 빠르게 실행되며, 다수의 경우들에 있어서, 이는 동일한 데이터를 분석하고 동일한 질의 결과들을 반환하면서 비-향상된 질의 플랜(300)보다 더 적은 메모리 자원들을 사용할 수 있다.
도 3 및 도 5에 도시된 예에 있어서, 질의 플랜의 하나의 부분으로부터의 조건이 질의 플랜의 다른 부분으로 전파된다. 이러한 예에 있어서, 술어 조건(주 = TN에 기초하는 필터)이 질의 플랜의 하나의 부분으로부터(예를 들어, 도 3의 필터 동작(304)으로부터) 질의 플랜의 다른 부분으로(예를 들어, 도 5의 필터 동작들(504 및 506)으로) 전파된다. 이러한 예에 있어서, 술어 조건이 전파되는 질의 플랜 그래프의 동작들 또는 부분들은, 이로부터 술어 조건이 전파되는 트리의 부분의 자손도 아니고 조상도 아니며, 즉, 필터 동작들(504 및 506)은 질의 플랜(300 또는 500) 내의 필터 동작(304)의 자손들 또는 조상들이 아니다.
도 5의 예에 있어서, 재작성된 서브-플랜들(502 및 512)을 생성하기 위해 필터 동작(304)으로부터 술어 조건이 서브-플랜들(302 및 312) 내로 전파되지만, 이것이 단지 예라는 것이 이해되어야 한다. 일반적으로, 질의 플랜 그래프 내의 제 1 동작으로부터의 술어 조건은 최적화되고 향상되며, 재작성된 질의 플랜을 생성하기 위하여 질의 플랜 내의 상이한 부분 또는 동작으로 전파되고 이와 연관될 수 있다. 이는 이용가능한 데이터 구조들(예를 들어, 구체화된 뷰들)에 의존할 수 있다.
특정 실시예들에 있어서, 질의 플랜(300)을 분석하는 것의 부분으로서, 인핸서(103)는 집성-조인 서브-플랜들에 초점을 맞추며, 이들은, 오로지 집성, 조인, 프로젝트, 필터 또는 스캔 연산자들/동작들만을 포함하는 전체 질의 플랜 내의 서브-플랜들이다. 이들의 예들은 도 3에 도시된 서브-플랜들(302 및 312)이다. 인핸서(103)의 목적은, 이러한 서브-플랜들 내의 팩트 소스 관계들의 스캔들로 푸시될 수 있는 술어 조건들 또는 필터들을 찾는 것이다.
특정 실시예들에 있어서, 인핸서(103)가 찾는 일반적인 패턴(패턴 A)은 다음과 같다:
- 팩트 소스 스캔(fs)와 어떤 다른 테이블 스캔(ot) 사이에 조인 조건을 정의하는 조인 동작을 나타내는 질의 플랜 내의 노드("조인 노드"). 조인 조건들은, 다른 테이블과 팩트 소스의 컬럼들 사이의 동일성 체크들의 리스트로서 표현될 수 있다(fs.col1 = ot.col1 및 fs.col2 = ot.col2 및 ...).
- 팩트 소스 측은 널-공급(null-supplying)이 아니어야 하며, 즉, 팩트 소스 스캔으로부터 고려 중인 조인(j1)까지의 경로를 따라 널-공급인 팩트 소스-측을 갖는 다른 조인(j2)이 존재하지 않아야 한다(즉, fs는 j2의 자식의 자손일 수 없으며, 여기에서 j2는 외부 조인이고, c1은 j2 내의 널-공급 측이다).
패턴 A는 이하와 같이 도시된다. 패턴 A의 라인 2 및 라인 4는 집성/조인/프로젝트/필터 동작들의 임의의 조합을 대신한다.
1. Join (fs.col1 = ot.col1 and fs.col2 = ot.col2 and ... )
2. project/filter/aggregate operations
3. fact source scan (fs)
4. project/filter/aggregate operations
5. OtherTable scan (ot)
이상의 패턴 A와 매칭되는 전체 질의 플랜 내의 서브-플랜이 발견되는 경우, '세미조인' 제한이 팩트 소스의 조이닝(joining) 컬럼들 상에 적용될 수 있다(패턴 A 내의 fs.col1, fs.col2, ...). 팩트 소스 로우들은, 그들의 조이닝 컬럼 값들이 다른 테이블 내의 동일한 로우에 매칭되는 것들로 제한될 수 있다(ot.col1, ot.col2...). 추가로, 다른 테이블이 유효한 어떤 필터를 갖는 경우, 팩트 소스 관계 스캔은, 아래와 같이 재작성될 수 있다:
1. Left-Semi Join (fs.col1 = ot.col1 and fs.col2 = ot.col2 and ... )
2. fact source scan (fs)
3. Select distinct ot.col1, ot.col2, ...
4. Filter
5. OtherTable scan (ot)
이러한 재작성의 잠재적인 장점은 질의 플랜 파이프라인의 후속 연산자들에서 프로세싱되는 팩트 소스 로우들에서의 감소이다. 팩트 소스 로우들 내의 감소는 비공식적으로(informally) 다른 테이블 상의 필터의 선택성에 의존한다. 필터의 선택성이 높을 수록(예를 들어, 많은 수의 별개의 값들을 갖는 컬럼 상의 동일성 조건) 팩트 소스 로우들 내의 감소가 커질 가능성이 높아진다. 스타 스키마 조인들의 경우에 있어서, 조인들이 무손실 분해 상에 존재하며(어떠한 새로운 팩트들도 조인들에 의해 추가되지 않음), 따라서, 스캔된 팩트들 상의 차원 필터의 이득은 필터의 선택성에 직접적으로 비례할 가능성이 높다.
이러한 재작성의 비용은 세미-조인 동작이 수행되는 방식에 기초한다. 일반적인 경우에 있어서, 이는, 전형적으로 조인 물리적 플랜을 수반할 레프트 세미-조인(Left Semi-Join) 연산자를 사용하여 이루어진다.
질의 플랜 내에서 술어 조건을 효율적으로 전파하기 위하여 이용가능한 다양한 기술들이 존재한다. 사용되는 특정 기술은, 비제한적으로, 추정된 계산 절감들 및/또는 특정 데이터 구조들의 이용가능성을 포함하는 다양한 인자들에 기초하여 선택될 수 있다.
하나의 기술은 팩트 레코드들과 차원 레코드들 사이에 세미-조인 동작을 수행하는 것을 수반한다. 이는, 술어 조건을 충족시키는 차원 키들의 세트를 결정하기 위해 차원 레코드들에 대하여 술어 조건을 평가하는 것에 기초하여 달성될 수 있다. 차원 키들의 이러한 세트는 본원에서 "키 인-리스트(key in-list)"로서 지칭된다.
도 6은 질의 A를 효율적으로 평가하기 위해 사용될 수 있는 키 인-리스트들(602 및 604)을 생성하기 위한 예시적인 프로세싱(600)을 도시한다. 보다 더 구체적으로, 술어 조건 "년 = 2000"은 키 인-리스트(602)를 결정하기 위해 차원 테이블(204)에 대하여 평가되며, 술어 조건 "주 = 'TN'"은 키 인-리스트(604)를 결정하기 위해 차원 테이블(208)에 대하여 평가된다. 키 인-리스트는, 술어 조건을 충족시키는 차원 테이블 내의 차원 레코드들로부터의 외래 키들의 리스트이다. 예를 들어, 날짜 차원 테이블(204)에 대하여, "년 = 2000"은 도 6에 도시된 제 1 레코드에 의해 충족되며, 날짜_키 = 1은 그 레코드로부터의 외래 키이다. 키 인-리스트들(602 및 604)은 팩트 레코드들을 스캔하고 필터링하기 위해 사용될 수 있으며, 그럼으로써 술어 조건들을 팩트 레코드들로 전파한다.
그러나, 세미-조인 동작을 수행하는 것은 상당한 양의 계산 오버헤드를 초래할 수 있다. 팩트 레코드들을 스캔하는 것은 계산 집중적일 수 있으며, 이는 전형적으로 많은 수의 팩트 레코드들이 존재하기 때문이다. 추가로, 키 인-리스트를 생성하는 것이 세미-조인 동작을 수행하는 계산 오버헤드에 추가된다. 가치가 있으려면, 이러한 오버헤드는, 그렇지 않았다면 불필요하게 프로세싱되었을 팩트 레코드들(예를 들어, 테네시와 무관한 팩트 레코드들)의 감소에 의해 초과되어야 한다. 따라서, 인핸서(103)는 세미-조인 동작을 포함하도록 질의 플랜을 재작성하기 이전에 계산 절감을 추정할 수 있다.
다수의 술어 조건들의 경우에 있어서, 질의 인핸서(103)는 세미-조인 동작을 연속적으로 수행하는 것의 증분(incremental) 절감들을 분석할 수 있다. 이는, 각각의 술어 조건을 분리하여 적용하는 것으로부터 기인할 계산 절감들의 감소 순서로 술어 조건들을 위치시키는 것을 수반할 수 있다. 그런 다음, 인핸서(103)는 연속적으로 술어 조건들을 적용하는 것으로부터의 증분 절감들을 추정하기 위하여 이러한 순서로 술어 조건들을 분석할 수 있다. 따라서, 세미-조인 동작은, 증분 절감들이 무의미하지 않는 한 연속적인 술어 조건을 적용하기 위해 지정될 수 있다.
술어 조건을 팩트 레코드들로 효율적으로 전파하기 위한 다른 기술은 차원 값들과 조인된 팩트 값들(예를 들어, 팩트 테이블로부터의 팩트 메트릭 값들 또는 임의의 다른 값들)의 표로 나타낸 표현을 수반한다. 구체화된 뷰 내에 포함된 차원 값들의 메모리 위치들에 대한 효율적인 액세스를 가능하게 하는 하나 이상의 인덱스들(예를 들어, 반전된 인덱스들(inverted indices))이 또한 수반된다. 집합적으로, 하나 이상의 인덱스들을 갖는 표로 나타낸 표현이 본원에서 "OLAP 인덱스"로서 지칭된다. 전형적으로 OLAP 인덱스는, 스캔 최적화 컬럼 인코딩, 메모리 최적화 컬럼형(columnar) 레이아웃, 벡터화된 스캔 동작들, 등과 같은 기술들을 사용하는, 제공된 술어 조건들에 기초하여 로우들의 임의적인 서브세트들을 스캔하기 위해 최적화된 단일 복합 데이터 레이아웃 포맷이며; 술어 평가가 또한, 예를 들어, 비트세트 동작들의 세트로서 고도로 최적화된다. 이러한 특징들이 OLAP 인덱스들을 애드-혹 분석 작업부하에 대하여 이상적으로 적절하게 만든다.
도 7은 차원 인덱스들(704 및 706)을 포함하는 예시적인 OLAP 인덱스(700)를 도시한다. OLAP 인덱스(700)는 차원 테이블들(204 및 208)과 팩트 테이블(202)을 조인하는 것으로부터 기인하는 데이터를 포함하는 테이블(702)을 더 포함한다. 도 7에 도시된 바와 같은 OLAP 인덱스는 차원 값들에 대하여 하나 이상의 반전된 인덱스들과 함께 컬럼형 포맷의 데이터를 포함한다. 각각의 차원 값에 대하여, 포지션 비트맵이 유지된다.
다수의 데이터베이스들 내에서, 필드(예를 들어, 컬럼(708 또는 710)) 내의 값들은 메모리 어드레스들의 범위 내에 인접하여 저장된다. 예를 들어, 데이터가 저장부로부터 시스템 메모리 내로 판독될 때, 컬럼(710)의 값들은, 효율적으로 액세스될 수 있는 컬럼형 데이터베이스로서 휘발성 메모리 내에 인접하여 저장될 수 있다. 특정 컬럼 값들을 액세스하는 효율을 증가시키기 위하여, 인덱스(예를 들어, 차원 인덱스)는 필드 값들과 메모리 위치들 사이의 매핑을 저장할 수 있다. 도 7의 예에 있어서, 차원 인덱스(704)는 컬럼(710)의 "주" 차원 값들(712)에 대한 메모리 위치들(714)을 나타내며, 차원 인덱스(706)는 컬럼(708)의 "년" 차원 값들(716)에 대한 메모리 위치들(718)을 나타낸다.
따라서, OLAP 인덱스는 계산 자원들의 보존을 가능하게 한다. OLAP 인덱스가 차원 값들을 포함하기 때문에, 술어 조건들은 인-리스트들을 생성하지 않고 OLAP 인덱스에 대하여 직접적으로 평가될 수 있다. 추가로, 차원 값 비트맵들은 차원 값으로부터 차원 값을 갖는 팩트 로우들의 서브세트로의 매핑들을 나타내며; 각각의 차원 술어 조건은 비트맵 또는 비트맵 조합에 대하여 매핑될 수 있고; 예를 들어, 주 = 'TN'은 'TN' 값 비트맵 내의 팩트 로우들이며, 주 > 'TN'은 > 'TN'인 모든 주 값들에 대한 모든 비트맵들의 OR에 의해 조합함으로써 획득되는 비트맵 내의 팩트 로우들이고; 다수의 차원 술어 조건들의 추가적인 평가는 또한 실제 팩트 데이터를 스캔할 필요 없이 AND, OR, NOT과 같은 매우 빠른 비트맵 조합 함수들로서 평가될 수 있다. 도 7에 도시된 바와 같은 인덱스는 '주 = "테네시"' 및 '날짜 = "2000"'과 같은 술어 조건이 빠른 방식으로 계산되는 것을 가능하게 한다. OLAP 인덱스 구체화는 매우 효율적인 "스킵 스캔들'이 수행되는 것을 가능하게 한다. 술어 조건들(예를 들어, '주 = "테네시"' 또는 '날짜 = "2000"')의 평가는 로우 식별자들의 리스트를 야기하며, 이는 술어 조건과 매칭되는 날짜를 갖는 팩트 로우들을 식별한다. 예를 들어, 로우 식별자들(1, 4, 5, 7, 9, 10, 13, 15, 17, 19, 20, 23, 및 24)은, '주 = "테네시"' 조건이 충족되는 팩트 레코드들에 대응한다. 다른 예로서, 로우 식별자들(1, 2, 3, 4, 5, 6, 7, 및 8)은 '날짜 = "2000"' 조건이 충족되는 팩트 레코드들에 대응한다. 로우아이디 리스트는 팩트 스캔 동작 동안 많은 수의 팩트 레코드 로우들을 스킵하기 위해 사용될 수 있다. 전형적으로, 분석 질의들은 방대한 다차원 공간의 작은 영역에 초점을 맞추며, 따라서 스킵 스캔들은, 모든 팩트 레코드들(또는 팩트 로우들)을 스캔하고 그런 다음 필터 술어 조건을 충족시키지 못하는 것들을 제거하는 것보다 상당히 더 빠르게 실행된다. 따라서, 술어 조건과 함께 OLAP 인덱스의 사용은 팩트 스캔 동작을 훨씬 더 빠르게 만든다.
도 7이 명료성을 위하여 10진 값들로서 메모리 위치들(714 및 718)을 도시하지만, 메모리 위치들(714 및 718)은 2진 값들, 16진 값들, 또는 유사한 것으로 표현될 수 있다는 것이 이해되어야 한다. 일부 실시예들에 있어서, 메모리 위치들(714 및 718)은 포지션 비트맵들로서 유지될 수 있으며, 그럼으로써 팩트 레코드들로 다수의 술어 조건들을 동시에 전파하기 위하여 계산적으로 싸고 빠른 비트맵 AND 연산들을 가능하게 한다. 추가로, 도 7이 명료성을 위하여 메모리 위치들(714 및 718)을 상대적인 어드레스들(예를 들어, 바이트 오프셋들)로서 도시하지만, 메모리 위치들(714 및 718)은 일부 실시예들에서 절대적인 어드레스들로 표현될 수 있다는 것이 이해되어야 한다.
일반적으로, OLAP 인덱스에 대하여 술어 조건을 평가하는 것의 이득들이 항상 임의의 계산 비용들 초과해야 한다. 따라서, 인핸서(103)가 비용-편익 분석을 수행할 필요가 없다. 그러나, 적절한 OLAP 인덱스가 항상 이용가능한 것은 아닐 수 있다. 예를 들어, 이에 대하여 술어 조건 "주 = 'TN'"이 평가될 수 있는 "주" 차원 값들을 포함하는 OLAP 인덱스가 존재하지 않을 수 있다.
술어 조건을 팩트 레코드들로 효율적으로 전파하기 위한 또 다른 기술은 전술한 기술들의 하이브리드를 수반하며, 이는 본원에서 "인덱스 세미-조인" 기술로서 지칭된다. 그것의 명칭에 의해 제안되는 바와 같이, 인덱스 세미-조인 동작은, 비록 OLAP 인덱스가 술어 조건을 직접적으로 평가하는데 적절하지 않더라도, OLAP 인덱스를 수반하는 특정 유형의 세미-조인 동작이다.
도 8a는 테이블(802) 및 차원 인덱스(804)를 포함하는 예시적인 OLAP 인덱스(800)를 도시한다. 테이블(802)은 팩트 테이블 스토어_반품(202)을 차원 스토어 테이블(208)과 조인하는 것으로부터 기인하는 데이터를 포함한다. 컬럼(806)의 값들은 컬럼형 데이터베이스 데이터로서 휘발성 메모리 내에 인접하여 저장될 수 있으며, 차원 인덱스(804)는 특정 컬럼 값들을 효율적으로 액세스하기 위해 사용될 수 있다. 보다 더 구체적으로, 차원 인덱스(804)는 "도시" 차원 값들(808)을 테이블 내의 메모리 위치들(810)에 매핑한다.
도 8a가 명료성을 위하여 10진 값들로서 메모리 위치들(810)을 도시하지만, 메모리 위치들(810)은 2진 값들, 16진 값들, 또는 유사한 것으로서 표현될 수 있다는 것이 이해되어야 한다. 일부 실시예들에 있어서, 메모리 위치들(810)은 포지션 비트맵들로서 유지될 수 있으며, 그럼으로써 팩트 레코드들로 다수의 술어 조건들을 동시에 전파하기 위하여 계산적으로 싸고 빠른 비트맵 AND 연산들을 가능하게 한다. 추가로, 도 8a가 명료성을 위하여 메모리 위치들(810)을 상대적인 어드레스들(예를 들어, 바이트 오프셋들)로서 도시하지만, 메모리 위치들(810)은 일부 실시예들에서 절대적인 어드레스들로 표현될 수 있다는 것이 이해되어야 한다.
그러나, 차원 인덱스(804)는 술어 조건 "주 = 'TN'"을 직접적으로 평가하는데 적절하지 않다. 이는, 차원 인덱스(804)가 "주" 값들이 아니라 "도시" 값들에 기초하기 때문이다.
그럼에도 불구하고, 차원 인덱스(804)는 여전히 인덱스 세미-조인 동작에 기초하여 팩트 레코드들로 술어 조건"주 = 'TN'"을 전파하기 위해 사용될 수 있다. 이는, 차원 인덱스(804) 내에 포함되며 술어 조건을 충족시키는 차원 값들(예를 들어, 비-키 값들)의 세트를 결정하기 위해 차원 레코드들에 대하여 술어 조건을 평가하는 것을 수반할 수 있다. 차원 값들의 이러한 세트는 본원에서 "값 인-리스트(value in-list)"로서 지칭된다.
도 8b는, 차원 인덱스(804)에 대하여 술어 조건 "주 = 'TN'"을 평가하기 위해 사용될 수 있는 값 인-리스트(822)를 생성하기 위한 예시적인 프로세싱(820)을 도시한다. 보다 더 구체적으로, 술어 조건 "주 = 'TN'"은 하나 이상의 "도시" 값들을 포함하는 값 인-리스트(822)를 결정하기 위해 차원 테이블(208)에 대하여 평가된다. 도 8b의 예에 있어서, 이는 단일 도시 값 "내슈빌"을 반환한다. 그러면, 값 인-리스트(822)(예를 들어, "내슈빌")는 테이블(802) 내의 관련 레코드들에 대응하는 메모리 위치들(예를 들어, 내슈빌에 대하여 위치들(1, 4, 5, 7, 9, 10, 13, 15, 17, 19, 20, 23, 및 24))에 대하여 차원 인덱스(804)를 스캔하기 위해 사용될 수 있으며, 그럼으로써 이들 전부를 스캔하지 않고 테이블(802)의 레코드들을 필터링한다.
인덱스 세미-조인 동작을 수행하는 것이 모든 팩트 레코드들을 스캔하는 것을 회피함으로써 계산 자원을 보존하지만, 이는 값 인-리스트를 생성하는 것과 연관된 계산 오버헤드를 야기한다. 가치가 있으려면, 이러한 오버헤드는, 그렇지 않았다면 불필요하게 프로세싱되었을 팩트 레코드들(예를 들어, 테네시와 무관한 팩트 레코드들)의 감소에 의해 초과되어야 한다. 따라서, 인핸서(103)는 인덱스 세미-조인 동작을 포함하도록 질의 플랜을 재작성하기 이전에 계산 절감을 추정할 수 있다.
다수의 술어 조건들의 경우에 있어서, 인핸서(103)는 인덱스 세미-조인 동작을 연속적으로 수행하는 것의 증분 절감들을 분석할 수 있다. 이는, 각각의 술어 조건을 분리하여 적용하는 것으로부터 기인할 계산 절감들의 감소 순서로 술어 조건들을 위치시키는 것을 수반할 수 있다. 그런 다음, 인핸서(103)는 연속적으로 술어 조건들을 적용하는 것으로부터의 증분 절감들을 추정하기 위하여 이러한 순서로 술어 조건들을 분석할 수 있다. 따라서, 인덱스 세미-조인 동작은, 증분 절감들이 무의미하지 않는 한 연속적인 술어 조건을 적용하기 위해 지정될 수 있다.
이상에서 표시된 바와 같이, 스타 스키마 정보(116)로부터 추론들이 도출될 수 있을 뿐만 아니라, 이들은 또한 의미 메타데이터(117)로부터 도출될 수도 있다. 의미 메타데이터(117)로부터 도출된 추론은, 이것이 팩트 레코드들로 전파될 수 있도록 술어 조건을 변환하기 위해 사용될 수 있다. 예를 들어, 의미 메타데이터(117)는 주, 달 4분기, 등의 용어로 표현되는 시간 값들 사이의 계층적 관계를 나타내는 정보를 포함할 수 있다. 그러면, 도 2에 도시된 날짜 차원 테이블(204)이 달, 일, 및 년 필드들을 포함하지만 4분기에 대한 필드는 포함하지 않기 때문에, 술어 조건이 "달" 값들에 대하여 평가될 수 있도록 이러한 정보는 "4분기 = 2"와 같은 조건을 "4월 내지 6월 사이의 달"로 변환하기 위해 사용될 수 있다. 이러한 방식으로, 차원 테이블 내의 컬럼이 아닌 값에 기초하는 술어 조건이 차원 테이블 내의 컬럼인 값으로 변환될 수 있다.
도 9는 특정 실시예들에 따른 기능적 종속성들에 기초하여 술어 조건을 팩트 레코드들로 전파하기 위한 예(900)를 도시한다. 도 9의 예에 있어서, "4분기 = 2"는, 테이블(908) 및 차원 인덱스(910)를 포함하는 도 9에 도시된 OLAP 인덱스(909)로 전파하기 위하여 식별될 수 있는 변환되지 않은 술어 조건(904)이다. 그러나, 테이블(908) 내의 컬럼들(912, 914, 916, 또는 918) 중 어떤 것도 "4분기" 컬럼이 아니며, 이는 OLAP 인덱스(910)에 대하여 술어 조건(904)을 평가하는 것을 어렵게 만든다.
그럼에도 불구하고, 의미 메타데이터(901)는, 인덱스(910) 내의 차원 속성에 기초하여 술어 조건(904)을 술어 조건(906)으로 변환하기 위해 사용될 수 있는 종속성 메타데이터를 포함할 수 있다. 보다 더 구체적으로, 의미 메타데이터(901)는, 술어 조건 "4분기 = 2"를 달-기반 술어 조건 "4월 내지 6월 사이의 달"으로 변환하기 위해 사용될 수 있는 날짜 계층들(902)(예를 들어, 달 대 4분기, 4분기 대 년)을 포함할 수 있다. 그 후에, 변환된 술어 조건(906)은 차원 인덱스(910)에 대하여 평가될 수 있으며, 이는 달 값들(920)을 메모리 위치들(922)에 매핑한다. 이러한 예에 있어서, 4 월, 5 월 및 6 월은 술어 조건을 충족시키며, 이들은 그들의 메모리 위치들(또는 로우아이디들)에 매핑된다. 도 9가 OLAP 인덱스를 수반하는 예시적인 프로세싱(900)을 도시하지만, 변환된 술어 조건이 본원에서 설명되는 임의의 적절한 기술을 사용하여 팩트 레코드들의 임의의 소스로 전파될 수 있다는 것이 이해되어야 한다.
도 9에 도시되며 이상에서 설명된 예에 있어서, 4분기에 기초하는 술어 조건은 달에 기초하는 술어 조건을 제약하는 것에 의해 대체된다. 술어 조건을 제약하는 대체는 원래의 술어 조건의 등가물일 필요가 없으며; 이는 단지 그것이 대체하는 술어 조건에 의해 반환되는 모든 로우들(팩트 레코드들)을 반환해야 할 따름이다. 동일성 및 경계 조건들(=, !=, <, >, <=, >=, 내, 사이)에 대한 대체 전력은 레벨-기반 계층들에 대하여 사용된다. 합리적인 크기의 계층들에 대하여, 계층들의 인-메모리 표현은, 향상된 질의 플랜의 생성 동안 대체 술어 조건을 계산하기 위하여 인핸서(103)에 의해 유지되고 사용될 수 있다.
목적이 질의 플랜의 실행에 의해 프로세싱되는 팩트 레코드들의 수를 감소시키거나 및/또는 질의 플랜 내에서 스캔 동작들을 수행하는 전체 비용을 감소시키는 것이기 때문에, 술어 조건들의 적용은 이러한 목적을 달성하는데 있어서 상당한 역할을 수행한다. 도 9에 도시되고 이상에서 설명된 예에 있어서, 질의("4분기 = 2") 내에서 제공되는 술어 조건은, 제공된 술어 조건을 대체하는 술어 조건("4월 내지 6월 사이의 달")과는 상이하다. 설사 2개의 술어 조건들이 상이하더라도, 대체 술어 조건의 적용은, 공급된 술어 조건에 의해 반환되는 임의의 로우가 또한 대체 술어 조건에 의해 반환되는 것을 보장한다. 이는 질의 및 질의 플랜의 성능과 관련하여 막대한 이득을 제공한다. 대체 술어 조건들은 기능적 종속성들을 검토함으로써 추론될 수 있다. 따라서, 4분기 -> 달 -> 주 날짜 계층에 있어서, 우리가 주에 대한 술어 조건을 갖는 경우, 주 컬럼이 팩트 소스로 푸시가 가능하지 않지만 반면 팩트 소스는 4분기 술어 조건들을 핸들링할 수 있는 경우에, 우리는 대응하는 4분기 술어 조건들을 푸시할 수 있으며, 예를 들어, 주 = 1이 4분기 = 1로 푸시될 수 있고, 주 > 25는 4분기 > 2로서 푸시될 수 있는 등이다. 술어 조건 변환은, 컬럼들 사이의 종속성을 정의하는 관계 트리를 검토하는 것에 기초한다. 이러한 트리들이 인-메모리 구조들로서 유지되는 경우, 변환이 매우 빠르며, 플랜화에 많은 오버헤드를 추가하지 않을 것이다. 이는 물론 계층들의 경우이며, 여기에서 인-메모리 데이터 구조들을 통한 멤버 네비게이션(navigation)을 지원하는 것이 일반적이다.
도 9가 변환되지 않은 술어 조건(904) 내에 지정된 필드와 변환된 술어 조건(906) 내에 지정된 필드 사이의 계층적 관계를 수반하는 예를 도시하지만, 본원에서 설명되는 기술들이 계층적 관계들을 나타내는 필드들에 한정되지 않는다는 것이 이해되어야 한다. 예를 들어, 의미 메타데이터(901)는, 술어 조건들의 변환을 수행하기 위해 사용될 수 있는 다른 유형들의 정보를 포함할 수 있다. 예를 들어, 의미 정보는, 남쪽의 스토어들이 겨울 의류를 판매하지 않는다는 것을 나타내는 정보를 포함할 수 있으며, 그럼으로써 겨울 의류에 관하여 표현되는 술어 조건이 지리적 영역에 관하여 표현되는 술어 조건으로 변환되는 것을 가능하게 한다.
본 개시에서 설명되는 기술들 중 임의의 기술은 술어 조건을 팩트 레코드들로 전파하기 위해 사용될 수 있다. 술어 조건을 전파하는 것은, 술어 조건이 직접적으로 팩트 레코드들과 조인되지 못할 수 있는 차원 레코드들로부터 팩트 레코드들로 전파될 수 있다는 점에 있어서 전이적(transitive) 속성을 나타낸다. 예를 들어, 술어 조건은 다수의 차원 테이블들에 걸쳐 또는 다른 팩트 테이블에 걸쳐 전파될 수 있다.
일부 실시예들에 있어서, 술어 조건은 차원 레코드들의 제 1 세트로부터 차원 레코드들의 제 2 세트에 걸쳐 팩트 레코드들의 세트로 전파될 수 있다. 이는 도 10a에 도시된 예를 참조하여 예시될 수 있다. 도 10a는 "스토어_반품" 팩트 테이블(202)의 축약된 버전, "고객" 차원 테이블(1002), 및 "고객_주소" 차원 테이블(1004)을 포함하는 예시적인 데이터베이스 데이터(1000)를 도시한다. "스토어_반품" 팩트 테이블(202)은 컬럼들(212 및 1006)에 기초하여 "고객" 차원 테이블(1002)과 직접적으로 조인될 수 있으며, "고객" 차원 테이블(1002)은 컬럼들(1008 및 1010)에 기초하여 "고객_주소" 차원 테이블(1004)과 직접적으로 조인될 수 있다. 그러나, 도 10a의 예에 있어서, "스토어_반품" 팩트 테이블(202)을 "고객_주소" 차원 테이블(1004)과 직접적으로 조인하기 위해 사용될 수 있는 컬럼들이 존재하지 않는다.
그럼에도 불구하고, 인핸서(103)는, 술어 조건 "주 = 'TN'"이 "고객_주소" 차원 테이블(1004)로부터 "스토어_반품" 팩트 테이블(202)로 전파될 수 있다는 것을 추론하기 위해 스타 스키마 정보(116)를 사용할 수 있으며, 이는 이들이 각기 "고객" 차원 테이블(1002)에 관련되기 때문이다. 이러한 추론에 기초하여, 인핸서(103)는, "스토어_반품" 팩트 테이블(202)의 컬럼을 "고객_주소" 차원 테이블(1004)에 컬럼에 관련시키는 테이블(또는 팩트 레코드들의 임의의 다른 소스)을 체크할 수 있다.
도 10b는 바로 이러한 테이블(1020)을 도시한다. 도 10b의 예에 있어서, 테이블(1020)은, 컬럼들(212 및 1006)을 사용하는 "스토어_반품" 팩트 테이블(202) 및 "고객_주소" 차원 테이블(1004)을 수반하며, 및 컬럼들(1008 및 1010)을 사용하는 "고객" 차원 테이블(1002)과 "고객_주소" 차원 테이블(1004) 사이의 조인 동작으로부터 기인하는 데이터를 포함한다. 따라서, 테이블(1020)은, "고객_주소" 차원 테이블(1004)의 "주" 컬럼(1012)에 대응하는 "주" 컬럼(1022)을 포함한다.
본원에서 설명되는 기술들 중 임의의 기술이 술어 조건 "주 = 'TN'"을 테이블(1020)로 전파하기 위해 사용될 수 있다. 예를 들어, 테이블(1020) 내의 컬럼(1022)의 값들에 대한 반전된 인덱스가 존재하는 경우, 술어 조건은, "주 = 'TN'" 술어 조건을 충족시키는 팩트 로우들만을 스캔하도록 테이블(1020)을 필터링하기 위해 반전된 인덱스에 대하여 평가될 수 있다.
도 10a 및 도 10b에 도시된 예에 대하여, 다음의 조건들이 충족되는 경우 술어 조건이 전파될 수 있다:
● 팩트 소스 스토어_반품 테이블(202)(FS1)이 차원 테이블 고객(1002)(T1)의 필터들에 기초하여 감소될 수 있음이 이미 추론되었다.
● FS1과 T1 사이의 조인은 스타 스키마 내의 스타 스키마 조인이다. 이는, 조인 동작이 임의의 입력 팩트 레코드들을 조인에 추가하거나 또는 제거하지 않음을 암시한다.
● T1과 차원 테이블 고객_주소(1004)(T2)사이의 조인은,
- T1 측 상의 널-공급이 아니며
- FS1.스타스키마 내의 스타 스키마 조인이고,
그러면: 조인 T1 - T2에서 T1 내의 각각의 T1 조이닝 컬럼(jc)에 대하여 FS1 내에 동등한 컬럼(eci)이 존재하는 경우, 우리는 FS1 내의 eci 컬럼들에 대하여 세미조인 제한을 적용할 수 있다.
일부 실시예들에 있어서, 술어 조건은 차원 레코드들의 세트로부터(차원 테이블 DT로부터) 팩트 레코드들의 제 1 세트(팩트 소스 1 "FS1")에 걸쳐 팩트 레코드들의 제 2 세트(팩트 소스 2 "FS2")로 전파될 수 있다. 예를 들어, 이는, 스타 스키마가 팩트 레코드들의 다수의 세트들을 포함할 때 가능할 수 있다. 도 11은 이러한 스키마(1100)의 일 예를 도시한다. 스키마(1100)는 (강조된 경계들을 가지고 도시된) 2개의 팩트 테이블들: "스토어_반품" 팩트 레코드 테이블(1102) 및 "스토어_판매" 팩트 레코드 테이블(1104)을 포함한다. 다른 테이블들(날짜, 스토어, 아이템, 고객, 고객_주소)은 팩트 레코드들에 대한 콘텍스트 정보를 저장하는 차원 테이블들이다. 2개의 팩트 테이블은 각기 차원 테이블과, 예컨대 "스토어" 차원 레코드 테이블(1106)과 조인될 수 있다.
도 12a는, 스키마(1100)에서 설명될 수 있는 예시적인 데이터베이스 데이터(1200)를 도시한다. 데이터베이스 데이터(1200)는 "스토어_반품" 팩트 테이블(1202), "스토어" 차원 테이블(1204), 및 "스토어_판매" 팩트 테이블(1206)을 포함한다. 도 12가 데이터베이스 데이터(1200)를 테이블들로서 도시하지만, 데이터베이스 데이터(1200)가 인덱스들, 구체화된 뷰들, 및/또는 임의의 다른 튜플들의 세트로서 표현될 수 있다는 것이 이해되어야 한다.
"스토어_반품" 팩트 테이블(1202) 및 "스토어" 차원 테이블(1204)은, 외래 키-1차 키 관계를 나타내는 컬럼들(1208 및 1210)에 기초하여 조인될 수 있다. 따라서, 컬럼들(1212 및 1214) 중 임의의 컬럼을 수반하는 술어 조건(예를 들어, "주 = 'TN'")이 본원에서 설명되는 기술들 중 임의의 기술을 사용하여 "스토어" 차원 테이블(1204)로부터 "스토어_반품" 팩트 테이블(1202)로 전파될 수 있다.
그러나, "스토어_판매" 팩트 테이블(1206)이 또한 "스토어" 차원 테이블(1204)과 조인될 수 있다. 이는, 컬럼들(1216 및 1210)이 또한 외래 키-1차 키 관계를 나타내기 때문이다. 따라서, 도 11에 도시된 스키마(1100)에 기초하여, 인핸서(103)는, "스토어_반품" 팩트 테이블(1202)의 임의의 필터링이 또한 본원에서 설명되는 기술들 중 임의의 기술을 사용하여 "스토어_판매" 팩트 테이블(1206)에 적용될 수 있다.
도 12b는 질의 서브-플랜들(1222, 1224, 및 1226)을 포함하는 예시적인 논리적인 질의 플랜(1220)을 도시한다. 질의 플랜(1220)에 따르면, 조인 동작(1230)은 서브-플랜(1222) 내의 동작들을 수행하는 것의 결과들과 서브-플랜(1224) 내의 동작들을 수행하는 것의 결과들 사이에 수행된다. 추가로, 플랜(1220)은 조인 동작(1230)을 수행하는 것의 결과들과 서브-플랜(1226) 내의 동작들을 수행하는 것의 결과들 사이에 조인 동작(1232)을 수행하는 것을 지정한다.
필터 동작(1228)은 서브-플랜(1222) 내에 포함되지만, 필터 동작(1228)은 서브 플랜들(1224 및 1226) 내에 포함되지 않는다. 이는, 조인 동작(1230)을 수행할 때 "스토어_반품" 팩트 테이블(1202)로부터 모든 팩트 레코드들의 상당한 양의 불필요한 프로세싱을 야기할 수 있다. 유사한 방식으로, 서브-플랜(1226)으로부터 "스토어_판매" 팩트 레코드(1206)로부터 반환된 모든 팩트 레코드들에 대하여 조인 동작(1232)을 수행할 때 상당한 양의 불필요한 프로세싱이 수행될 수 있다. 이러한 불필요한 프로세싱은 질의 플랜(1220)을 실행하기 위해 소요되는 총 시간을 크게 증가시킬 수 있다.
도 12c는, 질의 플랜에 의해 프로세싱되는 팩트 레코드들의 수를 감소시키기 위하여 질의 플랜(1220)에 기초하여 재작성된, 예시적인 재작성된 향상된 질의 플랜(1240)을 도시한다. 플랜(1240)에 따르면, 필터 동작(1228) 내의 술어 조건 "주 = 'TN'"은 필터 동작(1242)으로서 서브-플랜(1224) 내로 전파될 뿐만 아니라, 필터 동작(1224)로서 서브-플랜(1226) 내로 전파된다. 이것의 결과로서, 서브-플랜(1224)에 의해 출력되고 조인 동작(1230)에 제공되는 팩트 레코드들의 수는, 질의 플랜(1220) 내의 조인 동작(1230)에 제공되는 팩트 레코드들보다 더 적다(스토어_반품 테이블은 주가 TN이 아닌 레코드들을 홀딩하는 것으로 가정한다). 이는, 플랜(1240) 내에서, 플랜(1220) 내의 모든 팩트 레코드들 대신에 팩트 테이블 스토어_반품으로부터 "주 = 'TN'" 술어 조건을 충족시키는 이러한 팩트 레코드들만이 조인 동작(1230)에 제공되기 때문이다. 유사한 방식으로, 서브-플랜(1226)에 의해 출력되고 조인 동작(1232)에 제공되는 팩트 레코드들의 수는, 질의 플랜(1220) 내의 조인 동작(1232)에 제공되는 팩트 레코드들보다 더 적다(스토어_판매 테이블은 주가 TN이 아닌 레코드들을 홀딩하는 것으로 가정한다). 이는, 플랜(1240) 내에서, 플랜(1220) 내의 모든 팩트 레코드들 대신에 팩트 테이블 스토어_판매로부터 "주 = 'TN'" 술어 조건을 충족시키는 이러한 팩트 레코드들만이 조인 동작(1232)에 제공되기 때문이다. 이의 결과로서, 조인 동작들(1230 및 1232)를 수행하는 계산 오버헤드는, 먼저 차원 술어 조건 "주 = 'TN'"을 충족시키지 않는 "스토어_반품" 팩트 테이블(1202) 및 "스토어_판매" 팩트 테이블(1206)의 임의의 로우들을 필터링하여 제거함으로써 상당히 감소될 수 있다. 따라서 질의 플랜(1240)은 더 빠르게 실행되며(예를 들어, 더 적은 CPU 사이클들을 사용하며), 다수의 경우들에 있어서, 비-향상된 질의 플랜(1220)보다 더 적은 메모리 자원들을 사용할 수 있다.
이상에서 설명된 바와 같이, 특정 실시예들에 있어서, 기술들은 동일한(팩트의 다수의 그레인들의 분석을 수반하는 질의들) 또는 상이한 팩트들(예를 들어, 상이한 액티비티들을 비교하는 것/조합한 것을 수반하는 질의들)을 수반하는 서브-질의들에 걸쳐 콘텍스트의 전이적 전파를 위해 개시된다. 특정 실시예들에 있어서, 이러한 기술들은, 다음의 조건들을 홀딩하는 경우 적용될 수 있다:
● 차원 테이블(DT)에 기초하는 팩트 소스(FS2)에 대한 차원 콘텍스트 적용이 결정되었다.
● DT의 키 컬럼들 상의 FS2와 다른 팩트 소스(FS1)의 조인이 존재하며, DT는 또한 FS2의 스타 스키마 내의 차원 테이블이다.
이상의 조건들이 홀딩되는 경우, DT로부터의 차원 콘텍스트가 FS1에 대하여 적용될 수 있다.
도 13a는 특정 실시예들에 따른 향상된 질의 플랜을 생성하는 방법을 도시하는 간략화된 순서도(1300)이다. 프로세싱(1300)은 개별적인 시스템들, 하드웨어, 또는 이들의 조합의 하나 이상의 프로세싱 유닛들(예를 들어, 프로세서들, 코어들)에 의해 실행되는 소프트웨어(예를 들어, 코드, 명령어들, 프로그램)로 구현될 수 있다. 소프트웨어는 비-일시적인 저장 매체 상에(예를 들어, 메모리 디바이스 상에) 저장될 수 있다. 도 13에 표현되고 이하에서 설명되는 방법은 예시적으로 그리고 비-제한적으로 의도된다. 도 13이 특성 시퀀스 또는 순서로 발생하는 다양한 프로세싱 단계들을 도시하지만, 이는 제한적으로 의도되지 않는다. 특정한 대안적인 실시예들에 있어서, 단계들은 어떤 상이한 순서로 수행될 수 있으며, 일부 단계들이 또한 병렬로 수행될 수 있다.
1302에서, 제 1 또는 원래의 질의 플랜이 수신될 수 있다. 원래의 질의 플랜은, 도 1a 및 도 1b에 도시된 분석 플랫폼(100)에 제공되는 데이터베이스 질의(예를 들어, SQL 질의)에 대하여 생성된 플랜일 수 있다. 질의는 데이터베이스 내에 저장된 비-사전-집성된 데이터에 대하여 실행될 애드-혹 질의일 수 있다. 도 1b에 도시된 실시예를 참조하면, 원래의 질의 플랜은 최적화기(114)에 의해 생성될 수 있다.
원래의 질의 플랜은 동작들(또는 연산자들)의 파이프라인을 포함할 수 있다. 동작들(연산자들)은, 예를 들어, 팩트 스캔(때때로 간단하게 스캔 동작으로서 지칭됨), 필터, 조인, 집성, 프로젝션, 및 다른 동작들을 포함할 수 있다. 원래의 질의 플랜 내의 동작들은, 동작들의 출력들이 다른 하류측 동작(들)에 대한 입력들로서 제공되도록 파이프라인 내에서 계층적으로 조직될 수 있다. 질의 플랜은, 부모 및 자식 노드들을 포함하는 루트형 트리로서 계층적으로 표현될 수 있다. 이러한 표현에 있어서, 동작들은 트리의 리프 노드들에 의해 표현되는 동작들을 가지고 시작하여 수행된다. 그런 다음, 루트 노드까지 리프 노드들로부터의 출력들이 부모 노드들에 제공되고, 부모 노드들로부터의 출력들이 그들의 부모 노드들에 제공되는 등이며, 여기에서 루트 노드로부터의 출력은 이에 대하여 질의 플랜이 생성된 질의의 결과로서 제공된다. 예를 들어, 1302에서 수신된 원래의 질의 플랜은 도 3 및 /또는 도 12b에 도시된 것과 같을 수 있다.
원래의 질의 플랜 내의 하나 이상의 동작들이 서브-플랜들을 형성하도록 그룹화될 수 있다. 예를 들어, 원래의 질의 플랜은, 팩트 레코드들의 소스(예를 들어, 팩트 테이블)를 스캔하는 것을 수반하는 팩트 테이블 스캔 동작을 포함하는 제 1 서브-플랜을 포함할 수 있다. 제 1 서브-플랜은 또한 필터, 조인, 집성, 프로젝션 동작들과 같은 다른 0 또는 그 이상의 다른 동작들을 포함할 수 있다. 예를 들어, 도 3에 도시된 서브-플랜(302), 및 도 12에 도시된 서브-플랜들(1222, 1224, 및 1226). 원래의 질의 플랜 내에서, 제 1 서브-플랜에 의해 출력되는 팩트 레코드들(즉, 제 1 서브-플랜 내에서 수행되는 동작들의 결과로서 제 1 서브-플랜으로부터의 출력)은 원래의 질의 플랜 파이프라인 내의 부모 동작에 대한 입력으로서 제공된다.
1304에서, 원래의 질의 플랜을 재작성함으로써 향상된 질의 플랜이 생성된다. 재작성의 결과로서, 결과적인 향상된 질의 플랜 내에서, 적어도 하나의 차원 술어 조건의 평가가 향상된 질의 플랜 내의 팩트 스캔 동작으로 전파되고 이와 연관되며, 여기에서 술어 조건은 원래의 질의 플랜 내에서 동일한 팩트 스캔 동작과 연관되지 않았었다. 예를 들어, 술어 조건은 제 1 서브-플랜 내로 삽입될 수 있으며, 제 1 서브-플랜 내의 적어도 하나의 제 1 팩트 스캔 동작과 연관될 수 있다. 향상된 질의 플랜 내에서, 술어 조건의 평가는, 팩트 테이블로 술어 조건을 전파하는 것에 기초하여 서브-플랜의 부분으로서 이루어진다. 제 1 술어 조건의 전파 및 제 1 술어 조건의 1 서브-플랜 및 팩트 스캔 동작과의 연관의 결과로서, 향상된 질의 플랜은 원래의 질의 플랜보다 더 빠르게 실행된다. 예를 들어, 일부 경우들에 있어서, 술어 조건을 제 1 스캔 동작과 연관시키는 것의 결과로서, 원래의 질의 플랜에 비하여 더 적은 팩트 로우들/레코드들이 향상된 질의 플랜에 의해 프로세싱된다. 이는, 술어 조건을 충족시키는 이러한 팩트 레코드들만이 질의 플랜 파이프라인 내의 부모 또는 하류측 동작들에 대하여 제공되며; 술어 조건을 충족시키지 않은 팩트 레코드들은 필터링되어 제거되고, 예를 들어, 조인 동작일 수 있는 부모 동작에 제공되지 않기 때문이다. 이는 질의 플랜 파이프라인 내의 다음 그리고 후속 동작들로 제공되는 팩트 레코드들의 감소된 수를 야기한다. 이는, 그 후에 질의 플랜 파이프라인 내에서 조인 동작 및 다른 후속 동작들을 수행하는 것과 연관된 계산 오버헤드를 감소시킨다. 질의 플랜 파이프라인 내에서 더 적은 팩트 레코드들이 프로세싱되고 이월되기 때문에, 향상된 질의 플랜은 원래의 질의 플랜보다 더 빠르게 실행되며 더 적은 자원들(예를 들어, 프로세싱 자원들, 메모리 자원들)을 사용한다.
일부 다른 경우들에 있어서, 팩트 스캔 동작과 연관된 술어 조건은, 심지어 질의 플랜 파이프라인 내에서 팩트 스캔 동작으로부터 하류측 동작들로 출력되는 팩트 레코드들의 총 수가 감소되지 않을 수 있더라도, 팩트 스캔 동작을 수행하는 것과 연관된 비용(예를 들어, 팩트 스캔 동작을 수행하기 위해 요구되는 CPU 사이클 또는 시간)이 원래의 질의 플랜 내의 동일한 팩트 스캔 동작에 비하여 감소되도록 하는 그런 것이다.
결과적으로, 1304에서 재작성된 향상된 질의는 1302에서 수신된 원래의 질의 플랜보다 더 빠르게 실행된다. 결과적으로, 이에 대하여 질의 플랜이 생성되는 질의는 더 빠르게 실행되며 잠재적으로 더 적은 메모리 자원들을 사용한다. 따라서, 향상된 질의 플랜은 원래의 질의 플랜 이상의 향상 및 개선이다. 도 1b에 도시된 실시예에 있어서, 1304에서의 프로세싱은 인핸서(103)에 의해 수행될 수 있다.
1306에서, 1304에서 생성된 향상된 질의 플랜이 실행될 수 있다. 이상에서 표시된 바와 같이, 질의 플랜 내에서 하나 이상의 동작들로의 하나 이상의 술어 조건들의 전파에 기인하여, 향상된 질의 플랜이 (예를 들어, 더 적은 시간을 사용하여) 더 빠르게 실행되며, 다수의 경우들에 있어서, 비-향상된 원래의 질의 플랜보다 더 적은 메모리 자원들을 사용할 수 있다.
1308에서, 1306에서 향상된 질의 플랜의 실행의 결과로서 데이터베이스로부터 검색된 팩트 레코드들은, 이에 대하여 원래의 및 향상된 질의 플랜들이 생성되었던 질의에 대한 응답으로서 출력될 수 있다. 도 1b에 도시된 실시예에 있어서, 1306 및 1308에서의 프로세싱은 실행기(105)에 의해 수행될 수 있다.
도 13b는 특정 실시예들에 따른 향상된 질의 플랜을 생성하는 방법을 도시하는 간략화된 순서도(1320)이다. 도 13b의 프로세싱은 개별적인 시스템들, 하드웨어, 또는 이들의 조합의 하나 이상의 프로세싱 유닛들(예를 들어, 프로세서들, 코어들)에 의해 실행되는 소프트웨어(예를 들어, 코드, 명령어들, 프로그램)로 구현될 수 있다. 소프트웨어는 비-일시적인 저장 매체 상에(예를 들어, 메모리 디바이스 상에) 저장될 수 있다. 도 13b에 표현되고 이하에서 설명되는 방법은 예시적으로 그리고 비-제한적으로 의도된다. 도 13b가 특성 시퀀스 또는 순서로 발생하는 다양한 프로세싱 단계들을 도시하지만, 이는 제한적으로 의도되지 않는다. 특정한 대안적인 실시예들에 있어서, 단계들은 어떤 상이한 순서로 수행될 수 있으며, 일부 단계들이 또한 병렬로 수행될 수 있다.
특정 실시예들에 있어서, 도 13b에 도시된 프로세싱은 도 13a에서 1304에서 수행되는 프로세싱의 부분으로서 수행될 수 있다. 도 1b에 도시된 실시예에 대하여, 도 13b에 도시된 프로세싱은 인핸서(103)에 의해 수행될 수 있다. 인핸서(103)에 대한 입력들은 질의에 대하여 생성된 원래의 질의 플랜, 예를 들어, SQL 질의에 대하여 생성된 SQL 질의 플랜을 포함한다. 인핸서(103)는 또한 메타데이터 정보 및 스키마 정보 예컨대 관계형 스키마들에 관한 정보, 스타 스키마 정의들, 테이블의 컬럼들 사이의 기능적 종속성들, 데이터의 이용가능한 물리적 구조들 예컨대 스타 스키마들에 대한 OLAP 인덱스들, 및 유사한 것에 대한 액세스를 갖는다. 도 13b 및 첨부된 설명의 목적들에 대하여, 메타데이터 및 스키마 정보는 메타스토어(metastore) 내에 저장된다. 도 13b에 도시된 프로세싱의 출력은, 원래의 질의 플랜보다 더 빠르게 실행되며, 일부 경우들에 있어서, 원래의 질의 플랜과 동일한 결과들을 반환하면서 원래의 질의 플랜보다 더 적은 자원들을 사용하는 향상된 질의 플랜이다. 이상에서 설명된 바와 같이, 향상된 질의 플랜은 원래의 질의 플랜보다 더 빠르게 실행되며, 이는, 이것이 원래의 질의 플랜보다 더 적은 수의 팩트 레코드들을 프로세싱하기 때문이거나 및/또는 팩트 레코드들이 더 효율적으로 프로세싱되기 때문에 향상된 질의 플랜 내의 팩트 레코드들을 프로세싱하는 비용이 원래의 질의 플랜에서 보다 더 적기 때문이다.
도 13b에 도시된 바와 같이, 1322에서, 원래의 질의 플랜은 원래의 질의 플랜 내의 팩트 테이블들을 식별하기 위해 분석된다. 이는 다양하고 상이한 기술들을 사용하여 수행될 수 있다. 예를 들어, 원래의 질의 플랜 내의 팩트 테이블들은, 메타스토어 내의 팩트 테이블들에 대하여 원래의 질의 플랜 내의 테이블들을 매칭시킴으로써, 질의 레벨 또는 세션/연결 레벨에서의 사용자 힌트들을 통해, 및 다른 기술들에 의해 식별될 수 있다.
1324에서, 1322에서 식별된 각각의 팩트 테이블에 대하여, 이러한 팩트 스캔 동작과 확인 조인(confirming join)들의 세트를 계산하기 위하여 그리고 임의의 적용가능 차원 콘텍스트 술어 조건들을 식별하기 위하여, 질의 플랜 워크(walk)가 식별된 팩트 테이블에 대하여 매 팩트 스캔 연산자에 대해 원래의 질의 플랜 내에서 수행된다. 특정 실시예들에 있어서, 원래의 질의 플랜 내의 팩트 테이블 스캔 연산자에 대한 워크는 팩트 스캔 연산자로부터 시작하여 원래의 질의 플랜의 루트 노드에 도달할 때까지 원래의 질의 플랜에 이르기까지 검토하는 것을 수반한다. 예를 들어, 도 3에 도시된 질의 플랜에 대하여, 서브-플랜(302) 내의 스토어_반품 팩트 테이블 스캔 동작에 대한 워크는 이러한 노드(320)로부터 시작하여, 루트 노드(326)까지 포함하는 그것의 모든 조상 노드들: 노드(322), 노드(324), 노드(306), 등을 방문하는 것을 수반한다.
워크 동안 팩트 테이블에 대한 팩트 스캔 동작에 대한 적용가능 차원 콘텍스트 술어 조건들을 식별하고/추론하기 위하여, 인핸서(103)는 각각의 방문된 노드 동작/연산자의 출력의 '그레인'을 유지한다. 질의 플랜 내의 임의의 관계형 연산자의 출력은 계산된 데이터세트이다. 임의의 테이블(베이스 데이터세트) 또는 계산된 데이터세트의 "그레인"은 그것의 스키마 내의 차원 컬럼들의 세트이다. 팩트 테이블에 대하여, 그것의 그레인은 모든 연관된 차원 키들을 포함한다. 예를 들어, 도 4에서, 스토어_반품의 그레인은 날짜_키, 아이템_키, 스토어_키, 고객_키이다. 매 차원에 대하여, 모든 속성들이 키 속성에 의해 기능적으로 결정가능하기 때문에, 이들은 모드 팩트 테이블의 그레인에서 유효하다. 따라서, 예를 들어, 년, 4분기, 달, 등은 날짜_키에 의해 결정가능하며, 따라서 이들은 스토어_반품 그레인에서 유효하다. 유사한 인수들을 적용하면, 도 4의 모든 차원 컬럼들은 스토어_반품 테이블의 그레인에서 유효하다.
이제 도 3에서, 집성기 동작/연산자(324)는 고객_키, 스토어_키에 의해 로우들을 출력하며, 따라서 동작(324)에 의해 정의된 데이터세트의 그레인은 스토어_키, 고객_키이다. 그러나 다시 말하지만, 기능적 종속성에 의해 모든 고객 및 스토어 컬럼들은 그것의 그레인에서 유효하다. 따라서, 팩트 테이블 스토어_반품에 대하여, 스키마를 가지고 도 4에 도시된 스타 스키마 상에서 정의된 데이터세트: (고객_이름, 아이템_카테고리, 스토어_명칭, Qty)는 (고객_이름, 아이템_카테고리, 스토어_명칭)의 그레인을 가질 수 있다.
워크의 시작에서, 팩트 스캔 동작에 대한 팩트 테이블에 대한 그레인은 모두 팩트 테이블의 연관된 차원들 내의 속성들이다. 따라서, 도 3에서, 서브-플랜(302) 내의 스토어_반품에 대하여, 이는 날짜, 아이템, 스토어 및 고객 차원 테이블들로부터의 컬럼들 전부일 것이며, 고객_주소 차원 테이블로부터의 보조 고객 속성들이 또한 포함된다. 이는 도 4에서 팩트 테이블에 대하여 정의된 스타 스키마에 기초한다.
1324에서의 워크 동안, 조인 동작에 대응하는 노드를 만나면 특수 프로세싱이 수행된다. 이는, 팩트 테이블과의 확인 조인들을 캡처하는 것, 및 조인의 "다른-측"으로부터 팩트 스캔 동작 측 또는 "팩트-측"으로 전파될 수 있는 적용가능 콘텍스트를 추론하려고 시도하는 것을 수반한다. 예를 들어, 도 3에서, 조인 동작 노드(322)에 대하여, 팩트-측은 스토어_반품 노드(320)일 것이며, 다른-측은 필터 동작 노드(328)일 것이다. 다른 예로서, 도 3에서, 노드(306)에 대하여, 팩트-측은 좌측 서브-트리(302)일 것이며, 다른-측은 우측 서브-트리(312)일 것이다.
확인 조인은, 조인이 팩트-측의 그레인을 변화시키지 않는다는 것을 의미한다. 예를 들어, 가장 일반적인 확인 패턴 중 하나는 스타 스키마의 에지 상의 조건과 동일한 조인 조건을 수반한다. 따라서, 도 4에 도시된 스타 스키마를 수반하는 질의에 대하여, 조인은 반드시 스토어_반품과 스토어 키 상의 스토어 사이에서, 또는 스토어_반품과 고객_키 사이에서 있어야 하는 등이다. 대조적으로, 비-확인 조인들의 예들은, 스토어_반품 구체화(예컨대 구체화된 뷰 또는 OLAP 인덱스)와 고객_명칭 상의 고객 사이에, 또는 고객_반품과 스토어_명칭 상의 스토어_렌트(Store_Rent) 테이블 사이의 조인을 포함할 것이며; 여기에서 스토어_렌트는 스타 스키마의 부분이 아니다.
확인 조인을 만나면, 추론 로직은 확인 조인들에 대한 다음의 추가적인 조건들을 체크한다: 팩트-측 그레인은 조인되는 차원 그레인을 포함해야만 한다. 이것이 그러한 케이스인 경우에, 조이닝 그레인에 의해 기능적으로 결정되는 다른-측 상의 임의의 콘텍스트(술어 조건들)가 팩트 측에 대하여 그리고 그에 따라서 팩트 테이블에 대하여 적용가능하다. 예를 들어, 도 3에 도시된 질의 플랜에 대하여, 가장 좌측의 '날짜_키에 대한 조인' 노드(322)에 대해, 조인 연산자의 좌측 팩트-측 서브트리는 그레인 '고객, 아이템, 날짜, 스토어'를 가지며, 다른-측에 대한 조인은 날짜 차원에 대한 것이고; 따라서, 이는 날짜 키의 그레인에서 확인 조인이다. 모든 날짜 속성들은 날짜 키에 의해 결정될 수 있으며, 따라서 년에 대한 술어는 노드(320)에 의해 표현되는 팩트 테이블 스토어_반품에 대한 팩트 스캔 동작으로 전파될 수 있다. 유사한 분석이 스토어_반품 핀(fin) 서브-플랜(312)에 대한 팩트 스캔 동작을 위해 수행될 수 있다.
적용가능 그레인에 관한 정보는 워크 동안 유지되고 업데이트된다. 시작에서, 그레인 내의 모든 차원 속성들이 식별된다. 집성 동작/연산자(예를 들어, 도 3의 노드들(324 및 330))의 검토 시에, 그레인은 그룹화 컬럼들로 변화한다. 예를 들어, 도 3에서, 노드(324)에서의 집성 동작/연산자의 검토 시에, 그레인은 (고객_키, 스토어_키)가 된다. 특정 실시예들에 있어서, 질의 플랜 내에서 발견되는 상이한 유형의 관계형 동작들/연산자들의 검토 시에 그레인이 수정되는 방식에 대한 규칙들이 구성되고 유지된다.
1324에서의 워크의 부분으로서, 각각의 팩트 테이블 스캔 연산자에 대하여, 수반된 조이닝 테이블과의 확인 조인들의 리스트, 그 팩트 스캔동작에 대하여 식별되거나 추론된 적용가능한 하나 이상의 차원 콘텍스트 술어 조건들의 리스트를 포함하는 정보가 인핸서(103)에 의해 유지된다. 팩트 스캔 동작에 대한 워크의 말미에서, 워킹되는 팩트 스캔 연산자는 적용가능한 하나 이상의 차원 콘텍스트들(술어 조건들) 및 확인 조인들의 후보 리스트를 갖는다.
1326에서, 술어 조건들의 전이적 팩트-대-팩트 추론이 수행된다. 이러한 프로세싱은 동일한 팩트들 또는 상이한 팩트들에 걸친 술어 조건들의 전이적 추론을 수반한다. 팩트 스캔 연산자의 각각의 쌍, 즉 "fs1"(팩트 테이블 ft1에 대한 팩트 스캔) 및 "fs2"(팩트 테이블 ft2에 대한 팩트 스캔)에 대하여, 인핸서(103)는, 조인 조건이 조이닝 속성 D1.ja을 갖는 차원 D1 상에 있도록 조인 연산자를 찾으며, 그 결과 D1은 ft1 및 ft2 둘 모두의 스타 스키마 내에 존재한다.
예를 들어, 도 12b에서:
- fs1은 스토어_반품 스캔(박스(1224))이며;
- fs2는 스토어_판매 스캔(박스(1226)이고;
- 2개의 팩트 테이블들을 조인하는 조인은 노드(1232)이며;
- 공통 차원 D1은 스토어 차원이고; 및
- 조인은 스토어의 스토어_키 속성에 대한 것이다.
이러한 패턴의 발견 시에, 관련된 팩트 테이블들 둘 모두가 조이닝 속성들 D1.ja의 그레인에 있는 경우, 인핸서(103)는, fs1로부터 fs2로 그리고 이의 역으로 조이닝 그레인에 의해 기능적으로 결정되는 차원 D1에 대한 임의의 추론된 차원 콘텍스트를 전파할 수 있다. 따라서, 도 12b에서, 스토어_반품 스캔(박스(1224))으로부터 추론된 콘텍스트 술어 조건 '주 = TN'이 박스(1232)에서 스토어_키에 대한 조인을 통해 스토어_판매 스캔(노드(1226))으로 전파될 수 있다. 이러한 팩트-대-팩트 추론은 전이적이며; 따라서 차원 콘텍스트는 (ft1에 대한)fs1으로부터 (ft2에 대한)fs2, (ft3에 대한)f3 등으로 전파될 수 있다.
1328에서, 술어 조건들의 전이적 팩트-대-차원 추론이 수행된다. 스타 스키마들이 눈송이 스키마들일 수 있기 때문에, 차원 테이블로부터 스타 스키마 내의 팩트 테이블까지의 조인 경로의 길이는 1을 초과할 수 있다. 1328에서의 프로세싱은 도 17에 도시된 스키마(1700)를 사용하여 설명될 수 있다. 도 17에서, 스토어_반품은 팩트 테이블이며, 다른 테이블들은 모두 차원 테이블들이다(스키마(1700)가 도 4에 도시된 스키마(400)의 약간의 변형임을 유의해야 한다). 도 4에서, 수입_밴드(Income_Band)는 오로지 4개의 테이블 조인을 통해서만 스토어_반품과 연관된다: 수입_밴드 조인 고객_인구통계자료(Customer_Demographics) 조인 고객 조인 스토어_반품. 수입_밴드 속성들을 포함하는 스토어_반품의 물리적인 표현, 예를 들어, 수입_상부_경계(income_upper_bound) 속성을 포함하는 스토어_반품 상의 OLAP 인덱스가 존재하는 경우, 수입_상부_경계 술어를 이것에 적용하는 것이 가능할 수 있다. 인핸서(103)가 OLAP 인덱스 팩트 소스에 대해 수입_상부_경계 콘텍스트(술어)의 적용을 추론하기 위하여, 이는 수입_밴드 차원 테이블을 팩트 테이블과 연결하는 3개의 조인을 통해 전파해야 한다: 수입_밴드 조인 고객_인구통계자료, 고객_인구통계자료 조인 고객, 및 고객 조인 스토어_반품. 이는 팩트 스캔 연산자의 확인 조인들의 리스트를 재귀적으로 구축함으로써 이루어질 수 있으며, 새로운 적용가능 확인 조인을 만날 때마다, 1324에서와 같이 다른-측으로부터 임의의 이용가능 차원 콘텍스트를 전파하기 위한 시도가 이루어진다.
1330에서, 하나 이상의 추론된 차원 콘텍스트 술어 조건들이 팩트 스캔 동작에 적용되고 이와 연관된다. 이러한 포인트에서, 적용이 가능한 경우, 원래의 질의 플랜 내에서 식별된 각각의 팩트 스캔 동작/연산자(또는 일반적으로, 팩트 소스 스캔 동작)는 하나 이상의 적용가능 콘텍스트 술어 조건들의 리스트 또는 세트와 연관된다. 1330에서 프로세싱의 부분으로서, 각각의 팩트 스캔 동작에 대하여 식별된 술어 조건들이 그들의 순 이득에 기초하여 졍렬되며, 여기에서 술어 조건에 대한 순 이득은, 술어 조건을 적용한 이후의 팩트 로우들을 프로세싱하는 비용에서 술어 조건을 적용하는 비용을 뺀 비용에서의 감소이다.
따라서, 1330의 부분으로서, 각각의 팩트 스캔 동작에 대하여, 순 이득 메트릭은, 그 팩트 스캔 동작에 대하여 결정된 적용가능 술어 조건들의 리스트 내의 각각의 술어 조건에 대하여 인핸서(103)에 의해 계산될 수 있다. 순 이득 메트릭을 계산하기 위하여 그리고 다음과같이 정렬을 수행하기 위하여 몇몇 인자들이 인핸서(103)에 의해 고려될 수 있다:
- OLAP 인덱스 내의 컬럼들 및 팩트들에 대한 OLAP 인덱스의 이용가능성과 같은 팩트들의 이용가능한 물리적 표현들. 차원 컬럼들 모두가 OLAP 인덱스 내에 존재해야만 하는 것은 아니라는 것을 유의해야 한다.
- 추론된 차원 콘텍스트의 선택성; 고도로 선택적인 술어들이 덜 선택적인 술어들보다 더 선호된다.
- 차원 콘텍스트 술어 조건을 적용하는 비용. 예를 들어, 술어들을 OLAP 인덱스 스캔들로 푸시하는 것은 추가적인 비용을 거의 초래하지 않으며 선호된다; 인덱스 세미 조인들이 매우 효율적으로 인덱스 스캔 동작들/연산자들에서 스캔들을 스킵할 수 있는 능력을 레버리지하기 때문에 인덱스 세미 조인이 전통적인 세미-조인보다 더 선호된다.
1330의 부분으로서, 정렬 이후에, 각각의 팩트 스캔 동작에 대하여, 정렬에 기초하여 팩트 스캔과 연관시키기 위해 술어 조건들의 리스트로부터 하나 이상의 술어 조건들이 결정된다. 특정 실시예들에 있어서, 팩트 스캔 동작에 대하여, 팩트 스캔 동작과 연관될 최상의 순 포지티브 이득을 제공하는 술어 조건이 리스트로부터 선택된다.
특정 실시예들에 있어서, 팩트 스캔 동작에 대하여, 그 팩트 스캔 동작에 대하여 술어 조건들의 리스트로부터 2개 이상의 술어 조건들이 팩트 스캔 동작과 연관될 수 있다. 이러한 시나리오에 있어서, 최고 순 이득을 제공하는 술어 조건이 팩트 스캔 동작과 연관된 이후에, 정렬된 리스트 내의 각각의 추가적인 술어 조건에 대하여, 다음 최고 순 이득을 제공하는 술어 조건으로 시작하여, 추가적인 술어 조건이 팩트 스캔 동작과 연관될지 여부를 결정하기 위하여 그 팩트 스캔 동작에 대한 이전에 연관된 모든 술어 조건들 및 그 추가적인 술어 조건의 연관을 고려하여 순 이득 분석이 이루어진다. 다수의 술어 조건들이 팩트 스캔 동작과 연관될 때, 추가적인 술어 조건들을 적용하는 이득들은 전형적으로 연관되는 술어 조건들의 수에 따라 감소한다.
1330에서의 프로세싱 이후에, 특정 팩트 스캔 동작에 대하여, 그 팩트 스캔 동작에 적용가능한 것으로서 식별된 하나 이상의 술어 조건들 중 어떤 것도 순 이득을 제공하지 않을 수 있다. 이러한 경우에 있어서, 어떠한 술어 조건도 팩트 스캔 동작과 연관되지 않을 수 있다.
1332에서, 인핸서(103)는, 팩트 스캔 동작들과 연관된 기존의 술어 조건들에 기초하여 질의 플랜 내의 하나 이상의 팩트 스캔 동작들에 대하여 임의의 새로운 하나 이상의 술어 조건들을 추론함으로써 질의 플랜의 실행이 추가로 최적화될 수 있는지 여부를 결정하기 위한 프로세싱을 수행한다. 팩트 스캔 동작에 대한 기존 술어 조건은 원래의 질의 플랜 내에서 팩트 스캔 동작과 연관된 술어 조건(원래의 술어 조건) 및/또는 1330에서 수행된 프로세싱 이후에 팩트 스캔 동작과 연관된 술어 조건일 수 있다. 따라서, 1332에서 수행된 프로세싱의 부분으로서, 인핸서(103)는, 새로운 술어 조건이 원래의 술어 조건보다 팩트 스캔 동작에 대하여 더 큰 순 이득을 제공하는 경우, 팩트 스캔 동작과 연관된 원래의 술어 조건에 기초하여 새로운 변환된 술어 조건을 찾으려고 시도할 수 있다. 유사한 방식으로, 1330에서 팩트 스캔과 연관된 술어 조건에 대하여, 인핸서(103)는, 새로운 술어 조건이 1330에서 팩트 스캔 동작과 연관된 술어 조건보다 팩트 스캔 동작에 대하여 더 큰 순 이득을 제공하는 경우, 연관된 술어 조건에 기초하여 새로운 변환된 술어 조건을 찾으려고 시도할 수 있다.
특정 실시예들에 있어서, 1322의 부분으로서, 인핸서(103)는 차원 속성들 사이에서의 기능적 종속성들에 기초하여 식별된/추론된 술어들로부터 암시된 술어를 찾으려고 시도한다. 예를 들어, 도 3에 도시된 질의 플랜에 대하여, 우리는 도 5의 박스(502)에서 좌측 스토어_반품에 대한 술어 조건 '주=TN'의 적용을 보여준다. '주=TN'의 이러한 적용이 비용 효율적이 아니었다고 가정하면, 아마도 이는 이용가능한 OLAP 인덱스가 주 속성을 갖지 않았었기 때문일 것이다. 이러한 경우에 있어서, 인핸서(103)는 새로운 술어 조건을 추론하기 위해 다음의 메타데이터 정보를 사용할 수 있다:
- 주 및 도시 컬럼들이 계층 내에 존재한다;
- 'TN'은 데이터베이스 내에 리스트된 2개의 도시들만을 갖는다; 및
- 도시 컬럼이 OLAP 인덱스 내에 존재한다.
이상의 정보는, 아마도 '주=TN' 차원 콘텍스트가 '도시=멤피스 또는 도시=내슈빌'로서 적용될 수 있다는 것을 추론하기 위하여 사용될 수 있으며, 여기에서 추론된 술어 조건의 적용은 매우 빠른 OLAP 인덱스 스캔을 수반한다. 이러한 추론된 술어 조건의 적용은 전체 향상된 질의 플랜의 실행을 향해 순 이득들을 제공할 수 있다. 변환된 술어 조건의 다른 예가 도 9에 도시되고 이상에서 설명되었다.
특정 실시예들에 있어서, 1322에서의 프로세싱은 오로지 다음과 같은 경우에만 질의 플랜 내의 팩트 스캔 동작에 대하여 수행된다: 팩트 스캔 동작과 연관된 (즉, 원래의 질의 플랜 내의) 원래의 술어 조건이 존재하지 않는 경우; 1324, ,1326, 및 1328에서 수행된 프로세싱에 기초하여 팩트 스캔 동작과의 연관을 위해 적합한 술어 조건들의 리스트 내에서 적어도 하나의 술어 조건이 식별된 경우; 및 1330에서 수행된 프로세싱에 기초하여, 팩트 스캔 동작에 대하여 결정된 리스트 내의 술어 조건들 중 어떤 것도 팩트 스캔 동작에 대하여 임의의 포지티브 순 이득을 제공하지 않으며 그에 따라서 1330에서 팩트 스캔 동작과 연관되지 않았던 경우. 이러한 시나리오에 있어서, 인핸서(103)는, 임의의 이러한 변환된 새로운 술어 조건이 팩트 스캔 동작에 대하여 포지티브 순 이득들을 제공하는지 여부를 확인하기 위하여, 팩트 스캔 동작에 대하여 식별된 술어 조건들의 리스트 내의 하나 이상의 술어 조건들에 대하여 1332에서 프로세싱을 수행할 수 있다. 이러한 변환된 새로운 술어 조건이 발견되는 경우, 이는 인핸서(103)에 의해 1332에서 팩트 스캔 동작과 연관될 수 있다. 그러나 이는 제한적으로 의도되지 않는다. 일부 다른 실시예들에 있어서, 1332에서의 프로세싱은 1330에서 팩트 스캔 동작과 연관된 임의의 술어 조건 및/또는 임의의 원래의 술어 조건에 대하여 수행될 수 있다.
1334에서, 향상된 질의 플랜은 하나 이상의 팩트 스캔 동작들과 연관된 하나 이상의 술어 조건들을 갖는 원래의 질의 플랜에 기초하여 생성된다. 특정 실시예들에 있어서, 원래의 질의 플랜은, 향상된 질의 플랜 내에서, 하나 이상의 팩트 스캔 동작들과 연관되도록 식별된 하나 이상의 술어 조건들이 실제로 팩트 스캔 동작들과 연관되도록 향상된 질의 플랜으로서 재작성된다. 따라서, 1308에서 향상된 질의 플랜이 질의를 실행하는 것의 부분으로서 실행될 때, 연관된 술어 조건들은, 이들이 연관된 팩트 스캔 동작에 대하여 평가된다.
본원에 개시된 교시들에 기초하여 생성된 향상된 질의 플랜들은 통상적인 기술들을 뛰어 넘는 몇몇 이득들을 제공한다. 이상에서 설명된 바와 같이, SQL 질의들과 같은 분석 질의들은 전형적으로 다수의 차원들에 대한 계산들을 수반하며, 차원적 연관들을 네비게이션함으로써 조합되는 하나 이상의 팩트 테이블들에 대한 다수의 계산들의 계층들을 수반한다. 일 예로서, 차원적 연관의 일반적인 예는 년-4분기-달 또는 국가-주-도시 등과 같은 계층이다. 도 3에 도시된 예에 있어서, 서브-플랜(302)은 각각의 스토어에서의 고객들의 스토어 반품에 대한 계산을 수반하며, 서브-플랜(312)은 스토어의 모든 고객들에 대하여 스토어에서의 집성 반품들에 대한 계산을 수반한다. 노드(306)에서, 이러한 2개가 '문제' 고객들을 발견하기 위해 조합된다. 이러한 테라바이트(또는 훨씬 더 큰) 규모 및 이를 넘는 데이터베이스들에 대한 다중-계층 계산들은 매우 계산 집중적이며, '생각-시간(think-time)' 내에 임의적인 질의들에 대답하는 것이 매우 어렵다. 본원에서 개시되는 다양한 발명적인 기술들은, 비제한적으로 OLAP 인덱싱, 및 스케일링-아웃(scale-out) 비공유형 아키텍처(scale-out shared nothing architecture)들을 포함하여 이러한 규모로 애드-혹 질의들에 대한 상호작용 경험을 가능하게 하는 분석 플랫폼을 제공한다. 본원에서 설명되는 분석 플랫폼은 매우 비용 효율적인 방식으로 매우 큰(테라바이트 및 그 이상의) 다차원 데이터(예를 들어, 데이터 레이크에 저장된 데이터)에 대한 상호작용 애드-혹 질의들을 실행할 수 있는 능력을 제공하며; 과거에 통상적인 기술들을 사용하여 매우 큰(테라바이트 및 그 이상의) 다차원 데이터에 대하여 이러한 상호작용 질의들을 실행하는 것은 비용이 매우 높았고 스케일링될 수 없었다.
흔히, 질의에 대하여, 분석가의 의도는 방대한 다-차원 공간의 작은 영역에 초점을 맞추는 것이다. 도 3의 예에 대하여, 분석의 초점은 테네시 주에 맞춰진다. 그러나 SQL과 같은 질의 언어를 이용하면, 관계형 대수 연산자들을 사용하여 이러한 다차원 계산을 작성하는 것이 어려울 수 있기 때문에 이러한 분석 콘텍스트가 모호해질 수 있다. 추가로, SQL 작성은 흔히 SQL 생성 툴들을 통해 또는 도메인 전문가들이 아닌 데이터 엔지니어들에 의해 이루어지며 - 그들의 목적은 정확한 답변을 제공하는 SQL을 생성하는 것이고; 이들은, SQL 질의 엔진이 불필요한 팩트 프로세싱을 회피하는 질의 플랜을 생성하는 것을 용이하게 만드는 방식으로 '테네시 주'에 대한 분석과 같은 의미 정보를 전달하는데 관심이 없다. 통상적인 관계형 질의 최적화기들은 관계형 스키마들에 대하여 동작하며, 따라서 분석 질문들이 표현되는 방식의 기초가 되는 매우 가치가 있는 다차원 큐브 의미 모델에 대한 지식을 결여하고; 모든 분석가는 그의/그녀의 머리 속에 이러한 모델을 갖는다. 본원에 개시되는 분석 플랫폼은, 다차원 큐브 의미 모델에서 정의된 관계들을 레버리지함으로써 질의 플랜의 구조로부터 분석의 콘텍스트를 역 엔지니어링(reverse engineer)하기 위한 프로세싱을 수행한다. 다수의 경우들에 있어서, 이는 팩트들을 프로세싱하기 위해 필요한 자원들을 상당히 감소시키는 적용가능 차원 콘텍스트(술어 조건들)을 추론하는 것을 야기한다. 큰 크기의 데이터 규모(예를 들어, 테라바이트 규모) 및 그 이상에서, 본원에서 설명되는 바와 같는 팩트 프로세싱 비용의 감소는 애드-혹 질의들을 상호작용식으로 프로세싱하기 위한 능력에 대하여 큰 영향을 미친다.
이상에서 설명된 바와 같이, 분석 질의 실행을 보다 더 효율적으로 만드는 분석 플랫폼이 제공된다. 특정 실시예들에 있어서, Apache Spark 네이티브 분석 플랫폼이 제공된다. 분석 질의들(예를 들어, SQL 질의들)에 대하여 생성되는 질의 플랜들은 최적화되고 향상된 질의 플랜을 생성하도록 최적화된다. 비지니스 데이터 및 비지니스 인텔리전스 데이터와 같은 의미 정보가 향상된 질의 플랜들을 생성하기 위해 사용된다. 도메인 의미들이 보다 더 효율적인 질의 플랜들을 생성하기 위해 사용된다. 비지니스 의미들은 질의 실행 최적화를 위해 사용된다.
성능 관점에서, 향상된 질의 플랜들은 (이들이 그들의 실행을 완료하기 위하여 더 적은 CPU 사이클들을 필요로 하기 때문에) 더 빠르게 실행되며, 다수의 경우들에 있어서, 비-향상된 질의 플랜들보다 더 적은 메모리 자원들을 사용할 수 있다. 재작성된 질의 플랜들의 결과로서, 대응하는 질의들은 재작성 이전보다 자릿수만큼 더 빠르게(예를 들어, 10X, 25X, 100X, 등) 실행될 수 있다. 이는, 팩트 테이블들이 차원 테이블들보다 몇 자릿수 더 크며, 그에 따라서 팩트 레코드들을 프로세싱하는 것과 연관된 스캔 비용들을 감소시키는 것이 막대한 성능 이득들을 초래하기 때문이다.
이상에서 표시된 바와 같이, 본원에서 설명되는 분석 플랫폼은 Spark 클러스터를 사용하여 Apache Spark 네이티브 솔루션으로서 구현될 수 있다. 따라서, 이는 Apache Spark 및, 코어 컴포넌트들, 스케일 인-아웃 메모리 런타임, 촉진 컴포넌트들, JDBC, 메타스토어 등과 같은 그것의 생태계의 파워를 완전히 사용한다.
본원에서 설명되는 바와 같이, 향상된 질의 플랜에 의해 팩트 레코드들을 스캔하고 프로세싱하는 비용이 향상되지 않은 질의 플랜에 비하여 감소되는 최적화된 질의 플랜을 생성하기 위한 기술이 설명된다. 분석 액티비티는 흔히 전체 데이터세트에 대해서가 아니라 특정 서브-집단 또는 서브-콘텍스트에 초점이 맞춰진다. 의미 정보로부터 질의에 적용가능한 콘텍스트를 추론하는 것 및 (예를 들어, 콘텍스트 또는 술어 조건 전파에 의해) 콘텍스트를 질의에 적용하는 것은 질의 플랜 및 결과적으로 이에 대하여 질의 플랜이 생성된 질의의 실행에 있어서 상당한 성능 개선을 초래할 수 있다. 분석 도메인 또는 분석 액티비티에 관계없이, 분석의 콘텍스트를 결정하기 위해 식별될 수 있는 일반적인 패턴들이 존재한다. 특정 실시예들에 있어서, 이러한 패턴들을 식별하고 최적화되고 향상된 질의 플랜들을 생성하기 위한 기술들이 제공된다.
도 14는 일 실시예를 구현하기 위한 분산형 시스템(1400)의 간략화된 도면을 도시한다. 예시된 실시예에 있어서, 분산형 시스템(1400)은 하나 이상의 통신 네트워크들(1410)을 통해 서버(1412)에 결합된 하나 이상의 클라이언트 컴퓨팅 디바이스들(1402, 1404, 1406, 및 1408)을 포함한다. 클라이언트 컴퓨팅 디바이스들(1402, 1404, 1406, 및 1408)은 하나 이상의 애플리케이션들을 실행하도록 구성될 수 있다.
다양한 실시예들에 있어서, 서버(1412)는 이상에서 설명된 분석 질의들의 실행을 가능하게 하는 하나 이상의 서비스들 또는 소프트웨어 애플리케이션들을 실행하도록 맞춰질 수 있다.
특정 실시예들에 있어서, 서버(1412)는 또한 비-가상 및 가상 환경들을 포함할 수 있는 다른 서비스들 또는 소프트웨어 애플리케이션들을 제공할 수 있다. 일부 실시예들에 있어서, 이러한 서비스들은 웹-기반으로 또는 클라우드 서비스들로서, 예컨대 서비스형 소프트웨어(Software as a Service; SaaS) 모델 하에서 클라이언트 컴퓨팅 디바이스들(1402, 1404, 1406, 및/또는 1408)의 사용자들에게 제공될 수 있다. 클라이언트 컴퓨팅 디바이스들(1402, 1404, 1406, 및/또는 1408)을 조작하는 사용자들은 결과적으로 이러한 컴포넌트들에 의해 제공되는 서비스들을 사용하기 위하여 서버(1412)와 상호작용하는 하나 이상의 클라이언트 애플리케이션들을 사용할 수 있다.
도 14에 도시된 구성에 있어서, 서버(1412)는, 서버(1412)에 의해 수행되는 기능들을 구현하는 하나 이상의 컴포넌트들(1418, 1420 및 1422)을 포함할 수 있다. 이러한 컴포넌트들은, 하나 이상의 프로세서들, 하드웨어 컴포넌트들, 또는 이들의 조합들에 의해 실행될 수 있는 소프트웨어 컴포넌트들을 포함할 수 있다. 분산형 시스템(1400)과 상이할 수 있는 다양하고 상이한 시스템 구성들이 가능하다는 것이 이해되어야만 한다. 따라서, 도 14에 도시된 실시예는 일 실시예의 시스템을 구현하기 위한 분산형 시스템의 일 예이며, 제한하는 것으로 의도되지 않는다.
사용자들은 본 개시의 교시들에 따라 분석 질의들을 제출하기 위하여 클라이언트 컴퓨팅 디바이스들(1402, 1404, 1406, 및/또는 1408)을 사용할 수 있다. 클라이언트 디바이스는, 클라이언트 디바이스의 사용자가 클라이언트 디바이스와 상호작용하는 것을 가능하게 하는 인터페이스를 제공할 수 있다. 클라이언트 디바이스는 또한 이러한 인터페이스를 통해 사용자에게 정보를 출력할 수 있다. 예를 들어, 질의 결과들이 클라이언트 디바이스에 의해 제공되는 인터페이스를 통해 사용자에게 출력될 수 있다. 도 14가 단지 4개의 클라이언트 컴퓨팅 디바이스들을 도시하지만, 임의의 수의 클라이언트 컴퓨팅 디바이스들이 지원될 수 있다.
클라이언트 디바이스들은 다양한 유형들의 컴퓨팅 시스템들 예컨대 휴대용 핸드헬드 디바이스들, 범용 컴퓨터들 예컨대 개인용 컴퓨터들 및 랩탑들, 워크스테이션 컴퓨터들, 착용형 디바이스들, 게이밍 시스템들, 씬(thin) 클라이언트들, 다양한 메시징 디바이스들, 센서들 또는 다른 센싱 디바이스들, 및 유사한 것을 포함할 수 있다. 이러한 컴퓨팅 디바이스들은, 다양한 모바일 운영 시스템들(예를 들어, Microsoft Windows Mobile®, iOS®, Windows Phone®, Android™, BlackBerry®, Palm OS®)을 포함하여, 다양한 유형들 및 버전들의 애플리케이션들 및 운영 시스템들(예를 들어, Microsoft Windows®, Apple Macintosh®, UNIX® 또는 UNIX-유사 운영 시스템들, Linux 또는 Linux-유사 운영 시스템들 예컨대 Google Chrome™ OS)을 실행할 수 있다. 휴대용 핸드헬드 디바이스들은 무선 전화기들, 스마트폰들(예를 들어, iPhone®), 태블릿들(예를 들어, iPad®), 개인용 디지털 보조기기(personal digital assistant; PDA), 및 유사한 것을 포함할 수 있다. 웨어러블(wearable) 디바이스들은 Google Glass® 머리 착용형 디스플레이, 및 다른 디바이스들을 포함할 수 있다. 게이밍 시스템들은 다양한 핸드헬드 게이밍 디바이스들, 인터넷-가능형 게이밍 디바이스들(예를 들어, Kinect® 제스처 입력 디바이스를 갖거나 또는 갖지 않는 Microsoft Xbox® 게이밍 콘솔, Sony PlayStation® 시스템, Nintendo®에 의해 제공되는 다양한 게이밍 시스템들, 및 다른 것들), 및 유사한 것을 포함할 수 있다. 클라이언트 디바이스들은, 다양한 인터넷-관련 앱들, 통신 애플리케이션들(예를 들어, 이-메일 애플리케이션들, 단문 메시지 서비스(short message service; SMS) 애플리케이션들)과 같은 다양하고 상이한 애플리케이션들을 실행할 수 있으며, 다양한 통신 프로토콜들을 사용할 수 있다.
네트워크(들)(1410)는, 비제한적으로, TCP/IP(transmission control protocol/Internet protocol), SNA(systems network architecture), IPX(Internet packet exchange), AppleTalk®, 및 유사한 것을 포함하는 다양한 이용가능 프로토콜들 중 임의의 것을 사용하여 데이터 통신을 지원할 수 있는 당업자들에게 익숙한 임의의 유형의 네트워크일 수 있다. 단지 예로서, 네트워크(들)(1410)는, 근거리 네트워크(local area network; LAN), 이더넷 기반 네트워크들, 토큰-링(Token-Ring), 광역 네트워크(wide-area network; WAN), 인터넷, 가상 네트워크, 가상 사설 네트워크(virtual private network; VPN), 인트라넷, 엑스트라넷, 공중 교환 전화 네트워크(public switched telephone network; PSTN), 적외선 네트워크, 무선 네트워크(예를 들어, 전기 전자 기술자 협회(Institute of Electrical and Electronics; IEEE) 1002.11 프로토콜들의 묶음, Bluetooth®, 및/또는 임의의 다른 무선 프로토콜 중 임의의 것 하에서 동작하는 네트워크), 및/또는 이들 및/또는 다른 네트워크들의 임의의 조합일 수 있다.
서버(1412)는, 하나 이상의 범용 컴퓨터들, 특수 서버 컴퓨터들(예로서, PC(personal computer) 서버들, UNIX® 서버들, 중급 서버(mid-range server)들, 메인프레임 컴퓨터들, 랙-장착형 서버들, 등을 포함함), 서버 팜(server farm)들, 서버 클러스터(server cluster)들, 또는 임의의 다른 적절한 배열 및/또는 조합으로 구성될 수 있다. 서버들(1412)은, 서버에 대한 가상 저장 디바이스를 유지하기 위해 가상화될 수 있는 논리적인 저장 디바이스들의 하나 이상의 유연한 풀(pool)들과 같은 가상화를 수반하는 다른 컴퓨팅 아키텍처들 또는 가상 운영 시스템들을 실행하는 하나 이상의 가상 머신들을 포함할 수 있다. 다양한 실시예들에 있어서, 서버(1412)는 이상의 개시에서 설명된 기능을 제공하는 하나 이상의 서비스들 또는 소프트웨어 애플리케이션들을 실행하도록 맞춰질 수 있다.
서버(1412) 내의 컴퓨팅 시스템들은, 임의의 상용 이용가능 서버 운영 시스템뿐만 아니라 이상에서 논의된 것들 중 임의의 것을 포함하는 하나 이상의 운영 시스템들을 실행할 수 있다. 서버(1412)는 또한, HTTP(hypertext transport protocol) 서버들, FTP(file transfer protocol) 서버들, CGI(common gateway interface) 서버들, JAVA® 서버들, 데이터베이스 서버들, 및 유사한 것을 포함하는 다양한 추가적인 서버 애플리케이션들 및/또는 중간-계층(mid-tier) 애플리케이션들 중 임의의 것을 실행할 수 있다. 예시적인 데이터베이스 서버들은 비제한적으로, Oracle®, Microsoft®, Sybase®, IBM(International Business Machines)®, 및 유사한 것으로부터 상용적으로 이용가능한 것들을 포함한다.
일부 구현예들에 있어서, 서버(1412)는, 클라이언트 컴퓨팅 디바이스들(1402, 1404, 1406, 및 1408)의 사용자들로부터 수신되는 데이터 피드(data feed)들 및/또는 이벤트 업데이트들을 분석하고 통합하기 위한 하나 이상의 애플리케이션들을 포함할 수 있다. 일 예로서, 데이터 피드들 및/또는 이벤트 업데이트들은 비제한적으로, Twitter® 피드들, Facebook® 업데이트들 또는 하나 이상의 제 3 자 정보 소스들 및 연속적인 데이터 스트림들로부터 수신되는 실-시간 업데이트들을 포함할 수 있으며, 이들은 센서 데이터 애플리케이션들, 금융 시세표시기들, 네트워크 성능 측정 툴들(예를 들어, 네트워크 모니터링 및 트래픽 관리 애플리케이션들), 클릭스트림(clickstream) 분석 툴들, 자동차 트래픽 모니터링, 및 유사한 것과 연관된 실-시간 이벤트들을 포함할 수 있다. 서버(1412)는 또한 클라이언트 컴퓨팅 디바이스들(1402, 1404, 1406, 및 1408)의 하나 이상의 디스플레이 디바이스들을 통해 데이터 피드들 및/또는 실-시간 이벤트들을 디스플레이하기 위한 하나 이상의 애플리케이션을 포함할 수 있다.
분산형 시스템(1400)은 또한 하나 이상의 데이터 저장소들(1414, 1416)을 포함할 수 있다. 이러한 데이터 저장소들은 특정 실시예들에 있어서 데이터 및 다른 정보를 저장하기 위해 사용될 수 있다. 예를 들어, 데이터 저장소들(1414, 1416) 중 하나 이상이 데이터베이스 데이터, 메타데이터, 등을 저장하기 위해 사용될 수 있다. 데이터 저장소들(1414, 1416)은 다양한 위치들에 존재할 수 있다. 예를 들어, 서버(1412)에 의해 사용되는 데이터 저장소는 서버(1412)에 대하여 로컬에 존재할 수 있거나 또는 서버(1412)로부터 원격에 존재하고 네트워크-기반 또는 전용 연결을 통해 서버(1412)와 통신할 수 있다. 데이터 저장소들(1414, 1416)은 상이한 유형들일 수 있다. 특정 실시예들에 있어서, 서버(1412)에 의해 사용되는 데이터 저장소는 데이터베이스, 예를 들어, 관계형 데이터베이스, 예컨대 Oracle Corporation® 및 다른 판매사에 의해 제공되는 데이터베이스들일 수 있다. 이러한 데이터베이스들 중 하나 이상이 SQL-포맷형 명령들에 응답하여 데이터베이스로 그리고 데이터베이스로부터 데이터의 저장, 업데이트, 및 검색을 가능하게 하도록 맞춰질 수 있다.
특정 실시예들에 있어서, 데이터 저장소들(1414, 1416) 중 하나 이상이 또한 애플리케이션 데이터를 저장하기 위해 애플리케이션들에 의해 사용될 수 있다. 애플리케이션들에 의해 사용되는 데이터 저장소들은, 예를 들어, 키-값 저장 저장소, 객체 저장 저장소, 또는 파일 시스템에 의해 지원되는 범용 저장 저장소와 같은 상이한 유형들일 수 있다.
특정 실시예들에 있어서, 본 개시에서 설명된 분석 플랫폼 제공형 기능들은 클라우드 환경을 통한 서비스들로서 제공될 수 있다. 도 15는, 특정 실시예들에 따른, 그 내부에서 서비스들이 클라우드 서비스들로서 제공될 수 있는 클라우드-기반 시스템 환경의 간략화된 블록도이다. 도 15에 도시된 실시예에 있어서, 클라우드 인프라스트럭처 시스템(1502)은, 하나 이상의 클라이언트 컴퓨팅 디바이스들(1504, 1506, 및 1508)을 사용하여 사용자들에 의해 요청될 수 있는 하나 이상의 클라우드 서비스들을 제공할 수 있다. 클라우드 인프라스트럭처 시스템(1502)은 서버(1412)에 대하여 이상에서 설명된 것들을 포함할 수 있는 하나 이상의 서버들 및/또는 컴퓨터들을 포함할 수 있다. 클라우드 인프라스트럭처 시스템(1502) 내의 컴퓨터들은, 범용 컴퓨터들, 특수 서버 컴퓨터들, 서버 팜들, 서버 클러스터들, 또는 임의의 다른 적절한 배열 및/또는 조합으로서 조직될 수 있다.
네트워크(들)(1510)는 클라이언트들(1504, 1506, 및 1508)과 클라우드 인프라스트럭처 시스템(1502) 사이의 데이터의 교환 및 통신을 가능하게 할 수 있다. 네트워크(들)(1510)는 하나 이상의 네트워크들을 포함할 수 있다. 네트워크들은 동일하거나 또는 상이한 유형들일 수 있다. 네트워크(들)(1510)는, 통신들을 가능하게 하기 위하여, 무선 및/또는 유선 프로토콜들을 포함하는 하나 이상의 통신 프로토콜들을 지원할 수 있다.
도 15에 도시된 실시예는 단지 클라우드 인프라스트럭처 시스템의 일 예이며, 제한하는 것으로 의도되지 않는다. 일부 다른 실시예들에 있어서, 클라우드 인프라스트럭처 시스템(1502)은 도 15에 도시된 것보다 더 많거나 또는 더 적은 컴포넌트들을 가질 수 있거나, 2개 이상의 컴포넌트들을 결합할 수 있거나, 또는 컴포넌트들의 상이한 구성 또는 배열을 가질 수 있다. 예를 들어, 도 15가 3개의 클라이언트 컴퓨팅 디바이스들을 도시하지만, 대안적인 실시예들에 있어서 임의의 수의 클라이언트 컴퓨팅 디바이스들이 지원될 수 있다.
용어 클라우드 서비스는 일반적으로, 주문식으로 그리고 서비스 제공자의 시스템들(예를 들어, 클라우드 인프라스트럭처 시스템(1502))에 의해 인터넷과 같은 통신 네트워크를 통해 사용자들이 이용할 수 있게 되는 서비스를 지칭하기 위해 사용된다. 전형적으로, 공중 클라우드 환경에 있어서, 클라우드 서비스 제공자의 시스템을 구성하는 서버들 및 시스템들은 고객의 자체적인 사내(on-premise) 서버들 및 시스템들과는 상이하다. 클라우드 서비스 제공자의 시스템들은 클라우드 서비스 제공자에 의해 관리된다. 따라서, 고객들은, 서비스들에 대한 별개의 라이센스들, 지원들, 또는 하드웨어 및 소프트웨어 자원들을 구매할 필요 없이 클라우드 서비스 제공자에 의해 제공되는 클라우드 서비스들 자체를 이용할 수 있다. 예를 들어, 클라우드 서비스 제공자의 시스템은 애플리케이션을 호스팅할 수 있으며, 사용자는, 사용자가 애플리케이션을 실행하기 위하여 인프라스트럭처 자원들을 구매할 필요 없이 인터넷을 통해 애플리케이션을 주문식으로, 주문 및 사용할 수 있다. 클라우드 서비스들은 애플리케이션들, 자원들 및 서비스들에 대한 용이한 스케일러블(scalable) 액세스를 제공하도록 설계된다. 몇몇 제공자들이 클라우드 서비스들을 제공한다. 예를 들어, 미들웨어 서비스들, 데이터베이스 서비스들, 자바 클라우드 서비스들 및 다른 것들과 같은 몇몇 클라우드 서비스들은, 캘리포니아, 레드우드 쇼어 소재의 Oracle Corporation®에 의해 제공된다.
특정 실시예들에 있어서, 클라우드 인프라스트럭처 시스템(1502)은, 예컨대, 하이브리드 서비스 모델들을 포함하여, 서비스형 소프트웨어(Software as a Service; SaaS) 모델, 서비스형 플랫폼(Platform as a Service; PaaS) 모델, 서비스형 인프라스트럭처(Infrastructure as a Service; IaaS) 모델, 및 다른 것들 하에서 상이한 모델들을 사용하여 하나 이상의 클라우드 서비스들을 제공할 수 있다. 클라우드 인프라스트럭처 시스템(1502)은, 다양한 클라우드 서비스들의 프로비전(provision)을 가능하게 하는 애플리케이션들, 미들웨어, 데이터베이스들, 및 다른 자원들의 묶음을 포함할 수 있다.
SaaS 모델은, 고객이 기초(underlying) 애플리케이션에 대한 하드웨어 또는 소프트웨어를 구매할 필요 없이, 애플리케이션 또는 소프트웨어가 서비스로서 인터넷과 같은 통신 네트워크를 통해 고객에게 전달되는 것을 가능하게 한다. 예를 들어, SaaS 모델은, 고객에게 클라우드 인프라스트럭처 시스템(1502)에 의해 호스팅되는 주문형 애플리케이션들에 대한 액세스를 제공하기 위해 사용될 수 있다. Oracle Corporation®에 의해 제공되는 SaaS 서비스들의 예들은, 비제한적으로, 인사/자본 관리, 고객 관계 관리(customer relationship management; CRM), 전사적 자원 관리(enterprise resource planning; ERP), 공급망 관리(supply chain management; SCM), 전사적 성과 관리(enterprise performance management; EPM), 분석 서비스, 소셜 애플리케이션들, 및 다른 것들에 대한 다양한 서비스들을 포함한다.
IaaS 모델은 일반적으로, 탄력적인 컴퓨팅 및 자원 성능들을 제공하기 위한 클라우드 서비스로서 고객에게 인프라스트럭처 자원들(예를 들어, 서버들, 저장부들, 하드웨어 및 네트워킹 자원들)을 제공하기 위해 사용된다. Oracle Corporation®에 의해 다양한 IaaS 서비스들에 제공된다.
PaaS 모델은 일반적으로, 고객이 이러한 자원들을 입수하거나, 구축하거나, 또는 유지할 필요 없이, 고객들이 애플리케이션들 및 서비스들을 개발하고, 실행하며, 관리하는 것을 가능하게 하는 플랫폼 및 환경을 서비스로서 제공하기 위해 사용된다. Oracle Corporation®에 의해 제공되는 PaaS 서비스들의 예들은, 비제한적으로, 오라클 자바 클라우드 서비스(Java Cloud Service; JCS), 오라클 데이터베이스 클라우드 서비스(Database Cloud Service; DBCS), 데이터 관리 클라우드 서비스, 다양한 애플리케이션 개발 솔루션 서비스들, 및 다른 것들을 포함한다.
클라우드 서비스들은 일반적으로, 주문형 셀프-서비스 기반의, 가입-기반의, 탄력적으로 스케일러블하고, 신뢰할 수 있으며, 고도로 이용성이 높고 안전한 방식으로 제공된다. 예를 들어, 가입 주문을 통해, 고객은 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 하나 이상의 서비스들을 주문할 수 있다. 그러면, 클라우드 인프라스트럭처 시스템(1502)은 고객의 가입 주문에서 요청되는 서비스들을 제공하기 위하여 프로세싱을 수행한다. 예를 들어, 시스템(1502)은 본 개시에서 설명되는 바와 같은 분석 질의들을 서비스하기 위하여 서비스할 수 있다. 클라우드 인프라스트럭처 시스템(1502)은 하나 또는 심지어 다수의 클라우드 서비스들을 제공하도록 구성될 수 있다.
클라우드 인프라스트럭처 시스템(1502)은 상이한 배포(deployment) 모델들을 통해 클라우드 서비스들을 제공할 수 있다. 공개 클라우드 모델에 있어서, 클라우드 인프라스트럭처 시스템(1502)은 제 3 자 클라우드 서비스 제공자에 의해 소유될 수 있으며, 클라우드 서비스들은 임의의 일반적인 공개 고객에게 제공될 수 있고, 여기에서 고객은 개인 또는 기업일 수 있다. 특정한 다른 실시예들에 있어서, 사설 클라우드 모델 하에서, 클라우드 인프라스트럭처 시스템(1502)은 조직 내에서(예를 들어, 기업 조직 내에서) 운영될 수 있으며, 서비스들은 조직 내의 고객들에게 제공될 수 있다. 예를 들어, 고객들은 인사 부서, 경리 부서, 등과 같은 기업의 다양한 부서들 또는 심지어 기업 내의 개인들일 수 있다. 특정한 다른 실시예들에 있어서, 커뮤니티(community) 클라우드 모델 하에서, 클라우드 인프라스트럭처 시스템(1502) 및 제공되는 서비스들은 연관된 커뮤니티 내의 몇몇 조직들에 의해 공유될 수 있다. 이상에서 언급된 모델들의 하이브리드와 같은 다양한 다른 모델들이 또한 사용될 수 있다.
클라이언트 컴퓨팅 디바이스들(1504, 1506, 및 1508)은 (도 14에 도시된 디바이스들(1402, 1404, 1406, 및 1408)과 같이) 상이한 유형들일 수 있으며, 하나 이상의 클라이언트 애플리케이션들을 동작시킬 수 있다. 사용자는, 클라우드 인프라스트럭처 시스템(1502)과 상호작용하기 위하여, 예컨대 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 서비스를 요청하기 위하여 클라이언트 디바이스를 사용할 수 있다.
일부 실시예들에 있어서, 클라우드 서비스들을 제공하기 위해 클라우드 인프라스트럭처 시스템(1502)에 의해 수행되는 프로세싱은 빅 데이터 분석을 수반할 수 있다. 이러한 분석은, 데이터 내에서 다양한 경향들, 거동들, 관계들 등을 검출하고 시각화하기 위하여 큰 데이터 세트들을 사용하고, 분석하며, 조작하는 것을 수반할 수 있다. 이러한 분석은, 아마도 데이터를 병렬로 프로세싱하며, 데이터를 사용하여 시뮬레이션들을 수행하고, 유사한 것을 수행하는 하나 이상의 프로세서들에 의해 수행될 수 있다. 이러한 분석을 위해 사용되는 데이터는, 구조화된 데이터(예를 들어, 데이터베이스 내에 저장되거나 또는 구조화 모델에 따라 구조화된 데이터) 및/또는 구조화되지 않은 데이터(예를 들어, 데이터 블랍(data blob)들(이진 대형 객체들))를 포함할 수 있다.
도 15의 실시예에서 도시된 바와 같이, 클라우드 인프라스트럭처 시스템(1502)은, 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 다양한 클라우드 서비스들의 프로비전을 가능하게 하기 위하여 사용되는 인프라스트럭처 자원들(1530)을 포함할 수 있다. 인프라스트럭처 자원들(1530)은, 예를 들어, 프로세싱 자원들, 저장 또는 메모리 자원들, 네트워킹 자원들, 및 유사한 것을 포함할 수 있다.
특정 실시예들에 있어서, 상이한 고객들에 대하여 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 다양한 클라우드 서비스들을 지원하기 위한 이러한 자원들의 효율적인 프로비저닝을 가능하게 하기 위해, 자원들은 자원들의 세트들 또는 자원 모듈들("포드(pod)들"로서도 지칭됨)으로 번들(bundle)될 수 있다. 각각의 자원 모듈 또는 포드는 하나 이상의 유형들의 자원들의 미리-통합되고 최적화된 조합을 포함할 수 있다. 특정 실시예들에 있어서, 상이한 포드들이 상이한 유형들의 클라우드 서비스들에 대하여 미리-프로비저닝될 수 있다. 예를 들어, 포드들의 제 1 세트는 데이터베이스 서비스를 위해 프로비저닝될 수 있으며, 포드들의 제 1 세트 내의 포드와는 상이한 자원들의 조합을 포함할 수 있는 포드들의 제 2 세트는 자바 서비스를 위해 프로비저닝될 수 있는 등이다. 일부 서비스들에 대하여, 서비스들을 프로비저닝하기 위해 할당된 자원들이 서비스들 사이에서 공유될 수 있다.
클라우드 인프라스트럭처 시스템(1502)은 자체적으로, 클라우드 인프라스트럭처 시스템(1502)의 상이한 컴포넌트들에 의해 공유되며 클라우드 인프라스트럭처 시스템(1502)에 의한 서비스들의 프로비저닝을 가능하게 하는 서비스들(1532)을 내부적으로 사용할 수 있다. 이러한 내부 공유형 서비스들은, 비제한적으로, 보안 및 신원(identity) 서비스, 통합 서비스, 기업 저장소 서비스, 기업 관리자 서비스, 바이러스 스캐닝 및 화이트 리스트(white list) 서비스, 고 이용가능성, 백업 및 복원 서비스, 클라우드 지원을 가능하게 하기 위한 서비스, 이메일 서비스, 통지 서비스, 파일 전송 서비스, 및 유사한 것을 포함할 수 있다.
클라우드 인프라스트럭처 시스템(1502)은 다수의 서브시스템들을 포함할 수 있다. 이러한 서브시스템들은 소프트웨어, 또는 하드웨어, 또는 이들의 조합들로 구현될 수 있다. 도 15에 도시된 바와 같이, 서브시스템들은, 클라우드 인프라스트럭처 시스템(1502)의 고객들 또는 사용자들이 클라우드 인프라스트럭처 시스템(1502)와 상호작용하는 것을 가능하게 하는 사용자 인터페이스 서브시스템(1512)을 포함할 수 있다. 사용자 인터페이스 서브시스템(1512)은 웹 인터페이스(1514), 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 클라우드 서비스들이 광고되고 고객에 의해 구매될 수 있는 온라인 스토어 인터페이스(1516), 및 다른 인터페이스들(1518)과 같은 다양하고 상이한 인터페이스들을 포함할 수 있다. 예를 들어, 고객은 클라이언트 디바이스를 사용하여, 인터페이스들(1514, 1516, 및 1518) 중 하나 이상을 사용하여 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 하나 이상의 서비스들을 요청(서비스 요청(1534))할 수 있다. 예를 들어, 고객은 온라인 스토어에 액세스하고, 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 클라우드 서비스들을 브라우징하며, 고객이 가입하기를 원하는 클라우드 인프라스트럭처 시스템(1502)에 의해 제공되는 하나 이상의 서비스들에 대한 가입 주문을 할 수 있다. 서비스 요청은, 고객을 및 고객이 가입하기를 원하는 하나 이상의 서비스들을 식별하는 정보를 포함할 수 있다.
도 15에 도시된 바와 같은, 특정 실시예들에 있어서, 클라우드 인프라스트럭처 시스템(1502)은, 신규 주문을 프로세싱하도록 구성된 주문 관리 서브시스템(order management subsystem; OMS)(1520)을 포함할 수 있다. 이러한 프로세싱의 부분으로서, OMS(1520)은: 이전에 수행되지 않은 경우 고객에 대한 계정을 생성하고; 요청된 서비스를 고객에게 제공하기 위하여 고객에게 과금하기 위해 사용될 고객에 대한 과금 및/또는 회계 정보를 수신하며; 고객 정보를 검증하고; 검증 시에, 고객에 대한 주문을 예약(book)하며; 및 프로비저닝하기 위해 주문을 준비하기 위한 다양한 작업흐름들을 편성(orchestrate)하도록 구성될 수 있다.
일단 적절하게 검증되면, OMS(1520)은, 프로세싱, 메모리, 및 네트워킹 자원들을 포함하는 주문에 대한 자원들을 프로비저닝하도록 구성된 주문 프로비저닝 서브시스템(order provisioning subsystem; OPS)(1524)을 호출할 수 있다. 프로비저닝은, 주문에 대하여 자원들을 할당하는 것 및 고객 주문에 의해 요청된 서비스를 가능하게 하기 위하여 자원들을 구성하는 것을 포함할 수 있다. 주문에 대하여 자원들이 프로비저닝되는 방식 및 프로비저닝되는 자원들의 유형은, 고객에 의해 주문된 클라우드 서비스의 유형에 의존할 수 있다. 예를 들어, 하나의 작업흐름에 따르면, OPS(1524)는 요청되는 특정 클라우드 서비스를 결정하고, 그 특정 클라우드 서비스에 대하여 미리-구성되었을 수 있는 다수의 포드들을 식별하도록 구성될 수 있다. 주문에 대하여 할당되는 포드들의 수는 요청된 서비스의 크기/양/레벨/범위에 의존할 수 있다. 예를 들어, 할당될 포드들의 수는 서비스에 의해 지원될 사용자들의 수, 서비스가 요청되는 시간의 지속 기간, 및 유사한 것에 의존하여 결정될 수 있다. 그런 다음, 할당된 포드들은 요청된 서비스를 제공하기 위하여 특정한 요청 고객에 대하여 맞춤화될 수 있다.
클라우드 인프라스트럭처 시스템(1502)은, 요청된 서비스가 이제 사용할 준비가 된 때를 나타내기 위해 요청 고객에게 응답 또는 통지(1544)를 전송할 수 있다. 일부 경우들에 있어서, 고객이 요청된 서비스들의 사용을 시작하는 것 및 요청된 서비스들의 장점들을 이용하는 것을 가능하게 하는 정보(예를 들어, 링크)가 고객에게 전송될 수 있다.
클라우드 인프라스트럭처 시스템(1502)은 다수의 고객들에게 서비스들을 제공할 수 있다. 각각의 고객에 대하여, 클라우드 인프라스트럭처 시스템(1502)은 고객으로부터 수신된 하나 이상의 가입 주문들과 관련된 정보를 관리하는 것, 주문과 관련된 고객 데이터를 관리하는 것, 및 요청된 서비스들을 고객에게 제공하는 것을 담당한다. 클라우드 인프라스트럭처 시스템(1502)은 또한 가입된 서비스들의 고객들의 사용에 관한 사용 통계자료를 수집할 수 있다. 예를 들어, 통계자료는, 사용되는 저장소의 양, 전송되는 데이터의 양, 사용자들의 수, 및 시스템 사용 시간(system up time)과 시스템 정지 시간(system down time)의 양, 및 유사한 것에 대하여 수집될 수 있다. 이러한 사용 정보는 고객에게 과금하기 위하여 사용될 수 있다. 과금은, 예를 들어, 월 단위로 이루어질 수 있다.
클라우드 인프라스트럭처 시스템(1502)은 다수의 고객들에게 병렬로 서비스들을 제공할 수 있다. 클라우드 인프라스트럭처 시스템(1502)은, 어쩌면 재산권적 정보를 포함하는, 이러한 고객들에 대한 정보를 저장할 수 있다. 특정 실시예들에 있어서, 클라우드 인프라스트럭처 시스템(1502)은, 고객 정보를 관리하고, 하나의 고객에 관한 정보가 다른 고객에 의해 액세스가능하지 않도록 관리되는 정보의 분리를 제공하도록 구성된 신원 관리 서브시스템(identity management subsystem; IMS)(1528)을 포함한다. IMS(1528)는, 다양한 보안-관련 서비스들 예컨대 신원 서비스들, 예컨대 정보 액세스 관리, 인증 및 인가 서비스들, 고객 신원들 및 역할들 및 관련된 기능들을 관리하기 위한 서비스들 및 유사한 것을 제공하도록 구성될 수 있다.
도 16은 특정 실시예들을 구현하기 위하여 사용될 수 있는 예시적인 컴퓨터 시스템(1600)을 예시한다. 예를 들어, 일부 실시예들에 있어서, 컴퓨터 시스템(1600)은 도 1a 및 도 1b에서 도시된 시스템들 중 임의의 것을 구현하기 위하여 사용될 수 있다. 도 16에 도시된 바와 같이, 컴퓨터 시스템(1600)은, 버스 서브시스템(1602)을 통해 복수의 다른 서브시스템들과 통신하는 프로세싱 서브시스템(1604)을 포함하는 다양한 서브시스템들을 포함한다. 이러한 다른 서브시스템들은 프로세싱 가속 유닛(1606), I/O 서브시스템(1608), 저장 서브시스템(1618) 및 통신 서브시스템(1624)을 포함할 수 있다. 저장 서브시스템(1618)은 시스템 메모리(1610) 및 저장 매체(1622)를 포함하는 비-일시적인 컴퓨터-판독가능 저장 매체를 포함할 수 있다.
버스 서브시스템(1602)은 컴퓨터 시스템(1600)의 다양한 컴포넌트들 및 서브시스템들이 의도된 바와 같이 서로 통신하는 것을 가능하게 하기 위한 메커니즘을 제공한다. 버스 서브시스템(1602)이 단일 버스로서 개략적으로 도시되었지만, 버스 서브시스템의 대안적인 실시예들은 복수의 버스들을 사용할 수 있다. 버스 서브시스템(1602)은, 다양한 버스 아키텍처들 중 임의의 것을 사용하는 메모리 버스 또는 메모리 제어기, 주변기기 버스, 로컬 버스, 및 유사한 것을 포함하는 몇몇 유형들의 버스 구조들 중 임의의 버스 구조일 수 있다. 예를 들어, 이러한 아키텍처들은, 산업 표준 아키텍처(Industry Standard Architecture; ISA) 버스, 마이크로 채널 아키텍처(Micro Channel Architecture; MCA) 버스, 개량 ISA(Enhanced ISA; EISA) 버스, 비디오 전자공학 표준 위원회(Video Electronics Standards Association; VESA) 로컬 버스, 및 주변 컴포넌트 상호연결(Peripheral Component Interconnect; PCI) 버스를 포함할 수 있으며, 이들은 IEEE P1386.1 표준에 대하여 제조되는 메자닌 버스(Mezzanine bus) 및 유사한 것으로서 구현될 수 있다.
프로세싱 서브시스템(1604)은 컴퓨터 시스템(1600)의 동작을 제어하며, 하나 이상의 프로세서들, 애플리케이션 특정 집적 회로(application specific integrated circuit; ASIC)들, 또는 필드 프로그램가능 게이트 어레이(field programmable gate array; FPGA)들을 포함할 수 있다. 프로세서들은 단일 코어 또는 다중코어 프로세서들을 포함할 수 있다. 컴퓨터 시스템(1600)의 프로세싱 자원들은 하나 이상의 프로세싱 유닛들(1632, 1634), 등으로 조직될 수 있다. 프로세싱 유닛은 하나 이상의 프로세서들, 동일하거나 또는 상이한 프로세서들로부터의 하나 이상의 코어들, 코어들 및 프로세서들의 조합, 또는 코어들 및 프로세서들의 다른 조합들을 포함할 수 있다. 일부 실시예들에 있어서, 프로세싱 서브시스템(1604)은 하나 이상의 특수 목적 코-프로세서들, 예컨대 그래픽 프로세서들, 디지털 신호 프로세서(digital signal processor; DSP)들, 또는 유사한 것을 포함할 수 있다. 일부 실시예들에 있어서, 프로세싱 서브시스템(1604)의 프로세싱 유닛들 중 일부 또는 전부는, 애플리케이션 특정 집적 회로(application specific integrated circuit; ASIC)들, 또는 필드 프로그램가능 게이트 어레이(field programmable gate array; FPGA)들과 같은 맞춤형 회로들을 사용하여 구현될 수 있다.
일부 실시예들에 있어서, 프로세싱 서브시스템(1604) 내의 프로세싱 유닛들은 시스템 메모리(1610) 내에 또는 컴퓨터 판독가능 저장 매체들(1622) 상에 저장된 명령어들을 실행할 수 있다. 다양한 실시예들에 있어서, 프로세싱 유닛들은 다양한 프로그램 프로그램들 또는 코들 명령어들을 실행할 수 있으며, 프로그램들 또는 프로세스들의 동시 다중 실행을 유지할 수 있다. 임의의 주어진 시점에, 실행될 프로그램 코드의 전부 또는 일부가 잠재적으로 하나 이상의 저장 디바이스들 상에서를 포함하여 시스템 메모리(1610) 및/또는 컴퓨터-판독가능 저장 매체(1622) 내에 상주할 수 있다. 적절한 프로그래밍을 통하여, 프로세싱 서브시스템(1604)는 이상에서 설명된 다양한 기능들을 제공할 수 있다. 컴퓨터 시스템(1600)이 하나 이상의 가상 머신들을 실행하는 경우들에 있어서, 하나 이상의 프로세싱 유닛들이 각각의 가상 머신에 할당될 수 있다.
특정 실시예들에 있어서, 프로세싱 가속 유닛(1606)은 선택적으로, 컴퓨터 시스템(1600)에 의해 수행되는 전체 프로세싱을 가속하기 위하여 프로세싱 서브시스템(1604)에 의해 수행되는 프로세싱 중 일부를 오프-로딩(off-load)하기 위해서 또는 맞춤화된 프로세싱을 수행하기 위하여 제공될 수 있다.
I/O 서브시스템(1608)은 컴퓨터 시스템(1600)으로 정보를 입력하기 위한 및/또는 컴퓨터 시스템(1600)으로부터 또는 이를 통해 정보를 출력하기 위한 디바이스들 및 메커니즘들을 포함할 수 있다. 일반적으로, 용어 입력 디바이스의 사용은 컴퓨터 시스템(1600)으로 정보를 입력하기 위한 모든 가능한 유형들의 디바이스들 및 메커니즘들을 포함하도록 의도된다. 사용자 인터페이스 입력 디바이스들은, 예를 들어, 키보드, 포인팅 디바이스들 예컨대 마우스 또는 트랙볼, 터치패드 또는 디스플레이 내에 통합된 터치 스크린, 스크롤 휠, 클릭 휠, 다이얼, 버튼, 스위치, 키패드, 음성 명령 인식 시스템들을 가진 오디오 입력 디바이스들, 마이크들, 및 다른 유형들의 입력 디바이스들을 포함할 수 있다. 사용자 인터페이스 입력 디바이스들은 또한, 사용자들이 제스처들 및 구두(spoken) 명령들을 사용하는 입력을 수신하기 위한 인터페이스를 제공하는, 입력 디바이스, Microsoft Xbox® 360 게임 제어기, 디바이스들을 제어하고 이와 상호작용하는 것을 가능하게 하는 Microsoft Kinect® 모션 센서와 같은 모션 센싱 및/또는 제스처 인식 디바이스들을 포함할 수 있다. 사용자 인터페이스 입력 디바이스들은 또한, 사용자들로부터 눈 움직임(eye activity)(예를 들어, 사진을 찍는 동안의 및/또는 메뉴를 선택하는 동안의 '깜박임')을 검출하고 눈 제스처들을 입력 디바이스(예를 들어, Google Glass®)로의 입력으로서 변환하는 Google Glass® 눈 깜박임 검출기와 같은 눈 제스처 인식 디바이스들을 포함할 수 있다. 추가적으로, 사용자 인터페이스 입력 디바이스들은, 사용자들이 음성 명령들을 통하여 음성 인식 시스템(예를 들어, Siri® 네비게이터(navigator))과 상호작용하는 것을 가능하게 하는 음성 인식 센싱 디바이스들을 포함할 수 있다.
사용자 인터페이스 입력 디바이스들의 다른 예들은, 비제한적으로, 3차원(3D) 마우스들, 조이스틱들 또는 포인팅 스틱들, 게임패드들 및 그래픽 태블릿들, 및 음향/시각 디바이스들 예컨대 스피커들, 디지털 카메라들, 디지털 캠코더들, 휴대용 매체 플레이어들, 웹캠들, 이미지 스캐너들, 핑거프린트 스캐너들, 바코드 리더 3D 스캐너들, 3D 프린터들, 레이저 거리계들, 및 시선 추적 디바이스들을 포함할 수 있다. 추가적으로, 사용자 인터페이스 입력 디바이스들은, 예를 들어, 의료 이미징 입력 디바이스들 예컨대 컴퓨터 단층촬영, 자기 공명 이미징, 양전자 방출 단층촬영, 및 의료 초음파 검사 디바이스들을 포함할 수 있다. 사용자 인터페이스 입력 디바이스들은 또한, 예를 들어, 오디오 입력 디바이스들 예컨대 MIDI 키보드들, 디지털 악기들, 및 유사한 것을 포함할 수 있다.
일반적으로, 용어 출력 디바이스의 사용은 컴퓨터 시스템(1600)으로부터 사용자 또는 다른 컴퓨터로 정보를 출력하기 위한 모든 가능한 유형들의 디바이스들 및 메커니즘들을 포함하도록 의도된다. 사용자 인터페이스 출력 디바이스들은 디스플레이 서브시스템, 표시등들, 또는 비-시각적 디스플레이들 예컨대 오디오 출력 디바이스들, 등을 포함할 수 있다. 디스플레이 서브시스템은 음극선관(cathode ray tube; CRT), 액정 디스플레이(liquid crystal display; LCD) 또는 플라즈마 디스플레이를 사용하는 것과 같은 평면-패널 디바이스, 프로젝션 디바이스, 터치 스크린, 및 유사한 것일 수 있다. 예를 들어, 사용자 인터페이스 출력 디바이스들은, 비제한적으로, 시각적으로 텍스트, 그래픽들 및 오디오/비디오 정보를 전달하는 다양한 디스플레이 디바이스들, 예컨대 모니터들, 프린터들, 스피커들, 헤드폰들, 자동차 네비게이션 시스템들, 플로터(plotter)들, 음성 출력 디바이스들, 및 모뎀들을 포함할 수 있다.
저장 서브시스템(1618)은 컴퓨터 시스템(1600)에 의해 사용되는 정보 및 데이터를 저장하기 위한 데이터 저장부 또는 저장소를 제공한다. 저장 서브시스템(1618)은 일부 실시예들의 기능을 제공하는 기본 프로그래밍 및 데이터 구성물들을 저장하기 위한 유형적이고 비-일시적인 컴퓨터-판독가능 저장 매체를 제공한다. 저장 서브시스템(1618)은, 프로세싱 서브시스템(1604)에 의해 실행될 때 이상에서 설명된 기능을 제공하는 소프트웨어(예를 들어, 프로그램들, 코드 모듈들, 명령어들)를 저장할 수 있다. 소프트웨어는 프로세싱 서브시스템(1604)의 하나 이상의 프로세싱 유닛들에 의해 실행될 수 있다. 저장 서브시스템(1618)은 또한 본 개시의 교시들에 따라 사용되는 데이터를 저장하기 위한 저장소를 제공할 수 있다.
저장 서브시스템(1618)은 휘발성 및 비-휘발성 메모리 디바이스들을 포함하는 하나 이상의 비-일시적인 메모리 디바이스들을 포함할 수 있다. 도 16에 도시된 바와 같이, 저장 서브시스템(1618)은 시스템 메모리(1610) 및 컴퓨터-판독가능 저장 매체(1622)를 포함한다. 시스템 메모리(1610)는, 프로그램 실행 동안 명령어들 및 데이터의 저장을 위한 휘발성 메인 랜덤 액세스 메모리(random access memory; RAM) 및 그 내부에 고정된 명령어들이 저장되는 비-휘발성 판독 전용 메모리(read only memory; ROM) 또는 플래시 메모리를 포함하는 복수의 메모리들을 포함할 수 있다. 일부 구현예들에 있어서, 예컨대 기동 동안에 컴퓨터 시스템(1600) 내의 엘리먼트들 사이에서 정보를 전송하는 것을 돕는 기본 루틴들을 포함하는 기본 입력/출력 시스템(basic input/output system; BIOS)은 전형적으로 ROM 내에 저장될 수 있다. RAM은 전형적으로 프로세싱 서브시스템(1604)에 의해 현재 실행되며 동작되고 있는 데이터 및/또는 프로그램 모듈들을 포함한다. 일부 구현예들에 있어서, 시스템 메모리(1610)는 복수의 상이한 유형들의 메모리들, 예컨대 정적 랜덤 액세스 메모리(static random access memory; SRAM), 동적 랜덤 액세스 메모리(dynamic random access memory; DRAM), 및 유사한 것을 포함할 수 있다.
예로서 그리고 비제한적으로, 도 16에 도시된 바와 같이, 시스템 메모리(1610)는, 웹 브라우저들, 중간-계층 애플리케이션들, 관계형 데이터 베이스 관리 시스템(relational database management system; RDBMS)들, 등을 포함할 수 있는 다양한 애플리케이션들을 포함할 수 있는 실행되는 애플리케이션 프로그램들(1612), 프로그램 데이터(1614), 및 운영 시스템(1616)을 로딩할 수 있다. 예로서, 운영 시스템(1616)은, 다양한 버전들의 Microsoft Windows®, Apple Macintosh®, 및/또는 리눅스 운영 시스템들, (비제한적으로 다양한 GNU/리눅스 운영 시스템들, Google Chrome® OS, 및 유사한 것을 포함하는) 다양한 상용-이용가능 UNIX® 또는 UNIX-유사 운영 시스템들 및/또는 모바일 운영 시스템들 예컨대 iOS, Windows® Phone, Android® OS, BlackBerry® OS, 및 Palm® OS 운영 시스템들, 및 다른 것들을 포함할 수 있다.
컴퓨터-판독가능 저장 매체(1622)는 일부 실시예들의 기능을 제공하는 프로그래밍 및 데이터 구성물들을 저장할 수 있다. 컴퓨터-판독가능 매체(1622)는 컴퓨터-판독가능 명령어들, 데이터 구조들, 프로그램 모듈들, 및 컴퓨터 시스템(1600)에 대한 다른 데이터의 저장을 제공할 수 있다. 프로세싱 서브시스템(1604)에 의해 실행될 때 이상에서 설명된 기능을 제공하는 소프트웨어(프로그램들, 코드 모듈들, 명령어들)가 저장 서브시스템(1618) 내에 저장될 수 있다. 예로서, 컴퓨터-판독가능 저장 매체(1622)는 비-휘발성 메모리 예컨대 하드 디스크 드라이브, 자기 디스크 드라이브, 광 디스크 드라이브 예컨대 CD ROM, DVD, Blu-Ray® 디스크, 또는 다른 광 매체를 포함할 수 있다. 컴퓨터-판독가능 저장 매체(1622)는, 비제한적으로, Zip® 드라이브들, 플래시 메모리 카드들, 범용 직렬 버스(universal serial bus; USB) 플래시 드라이브들, 보안 디지털(secure digital; SD) 카드들, DVD 디스크들, 디지털 비디오 테이프, 및 유사한 것을 포함할 수 있다. 컴퓨터-판독가능 저장 매체(1622)는 또한, 비-휘발성 메모리 기반 고체-상태 드라이브(solid-state drive; SSD)들 예컨대 플래시-메모리 기반 SSD들, 기업 플래시 드라이브들, 고체 상태 ROM, 및 유사한 것, 휘발성 메모리 기반 SSD들 예컨대 고체 상태 RAM, 동적 RAM, 정적 RAM, DRAM-기반 SSD들, 자기저항성 RAM(magnetoresistive RAM; MRAM) SSD들, 및 DRAM 및 플래시 메모리 기반 SSD들의 조합을 사용하는 하이브리드 SSD들을 포함할 수 있다.
특정 실시예들에 있어서, 저장 서브시스템(1618)은 또한, 추가적으로 컴퓨터-판독가능 저장 매체(1622)에 연결될 수 있는 컴퓨터-판독가능 저장 매체 리더(1620)를 포함할 수 있다. 리더(1620)는 디스크, 플래시 드라이브, 등과 같은 메모리 디바이스로부터 데이터를 수신하고 이를 판독하도록 구성될 수 있다.
특정 실시예들에 있어서, 컴퓨터 시스템(1600)은, 비제한적으로 프로세싱 및 메모리 자원들의 가상화를 포함하는, 가상화 기술들을 지원할 수 있다. 예를 들어, 컴퓨터 시스템(1600)은 하나 이상의 가상 머신들을 실행하기 위한 지원을 제공할 수 있다. 특정 실시예들에 있어서, 컴퓨터 시스템(1600)은 가상 머신들의 구성 및 관리를 가능하는 하이퍼바이저(hypervisor)로서 프로그램을 실행할 수 있다. 각각의 가상 머신은 할당된 메모리, 연산부(예를 들어, 프로세서들, 코어들), I/O, 및 네트워킹 자원들일 수 있다. 각각의 가상 머신은 일반적으로 다른 가상 머신들과 독립적으로 실행된다. 가상 머신은 전형적으로 자체적인 운영 시스템을 실행하며, 이는 컴퓨터 시스템(1600)에 의해 실행되는 다른 가상 머신들에 의해 실행되는 운영 시스템들과 동일하거나 또는 상이할 수 있다. 따라서, 복수의 운영 시스템들이 잠재적으로 컴퓨터 시스템(1600)에 의해 동시에 실행될 수 있다.
통신 서브시스템(1624)은 다른 컴퓨터 시스템들 및 네트워크들에 대한 인터페이스를 제공한다. 통신 서브시스템(1624)은 컴퓨터 시스템(1600)으로부터 다른 시스템들로 데이터를 송신하고 이로부터 데이터를 수신하기 위한 인터페이스로서 역할한다. 예를 들어, 통신 서브시스템(1624)은, 컴퓨터 시스템(1600)이 인터넷을 통해 클라이언트 디바이스들로부터 정보를 수신하고 클라이언트 디바이스들로 정보를 전송하기 위한 하나 이상의 클라이언트 디바이스들로의 통신 채널을 수립하는 것을 가능하게 한다.
통신 서브시스템(1624)은 유선 및/또는 무선 통신 프로토콜들 둘 모두를 지원할 수 있다. 예를 들어, 특정 실시예들에 있어서, 통신 서브시스템(1624)은 (예를 들어, 셀룰러 전화기 기술, 진보된 데이터 네트워크 기술, 예컨대 3G, 4G 또는 EDGE(enhanced data rates for global evolution), WiFi(IEEE 802.XX 패밀리 표준들, 또는 다른 모바일 통신 기술들, 또는 이들의 임의의 조합)을 사용하여) 무선 음성 및/또는 데이터 네트워크들에 액세스하기 위한 라디오 주파수(radio frequency; RF) 트랜시버 컴포넌트들, 위성 위치확인 시스템(global positioning system; GPS) 수신기 컴포넌트들, 및/또는 다른 컴포넌트들을 포함할 수 있다. 일부 실시예들에 있어서, 통신 서브시스템(1624)은 무선 인터페이스에 더하여 또는 그 대신에 유선 네트워크 연결(예를 들어, 이더넷)을 제공할 수 있다.
통신 서브시스템(1624)는 다양한 형식들의 데이터를 수신하고 송신할 수 있다. 예를 들어, 일부 실시예들에 있어서, 다른 형태들에 더하여, 통신 서브시스템(1624)은 구조화된 및/또는 구조화되지 않은 데이터 피드들(1626), 이벤트 스트림들(1628), 이벤트 업데이트들(1630), 및 그와 유사한 것의 형태의 입력 통신을 수신할 수 있다. 예를 들어, 통신 서브시스템(1624)은 소셜 네트워크들 및/또는 다른 통신 서비스들의 사용자들로부터의 실-시간 데이터 피드들(1626) 예컨대 Twitter® 피드들, Facebook® 업데이트들, 웹 피드들 예컨대 리치 사이트 서머리(Rich Site Summary; RSS) 피드들, 및/또는 하나 이상의 제 3 자 정보 소스들로부터의 실-시간 업데이트들을 수신(또는 전송)하도록 구성될 수 있다.
특정 실시예들에 있어서, 통신 서브시스템(1624)은, 사실상 명시적인 종료를 갖지 않는 제한이 없거나 또는 연속적일 수 있는 실-시간 이벤트들 및/또는 이벤트 업데이트들(1630)의 이벤트 스트림들(1628)을 포함할 수 있는 연속적인 데이터 스트림들의 형태로 데이터를 수신하도록 구성될 수 있다. 연속적인 데이터를 생성하는 애플리케이션들의 예들은, 예를 들어, 센서 데이터 애플리케이션들, 금융 시세표시기들, 네트워크 성능 측정 툴들(예를 들어, 네트워크 모니터링 및 트래픽 관리 애플리케이션들), 클릭스트림 분석 툴들, 자동차 트래픽 모니터링, 및 유사한 것을 포함할 수 있다.
통신 서브시스템(1624)은 또한 컴퓨터 시스템(1600)으로부터 다른 컴퓨터 시스템들 또는 네트워크들로 데이터를 통신하도록 구성될 수 있다. 데이터는, 구조화되거나 및/또는 구조화되지 않은 데이터 피드들(1626), 이벤트 스트림들(1628), 이벤트 업데이트들(1630), 및 유사한 것과 같은 다양한 형태들로, 컴퓨터 시스템(1600)에 결합된 하나 이상의 스트리밍 데이터 소스 컴퓨터들과 통신하고 있을 수 있는 하나 이상의 데이터베이스들로 통신될 수 있다.
컴퓨터 시스템(1600)은, 핸드헬드 휴대용 디바이스(예를 들어, iPhone® 셀룰러 폰, iPad® 컴퓨팅 태블릿, PDA), 웨어러블 디바이스(예를 들어, Google Glass® 머리 착용형 디스플레이), 개인용 컴퓨터, 워크스테이션, 메인프레임, 키오스크, 서버 랙, 또는 임의의 다른 데이터 프로세싱 시스템을 포함하는 다양한 유형들 중 임의의 유형일 수 있다. 컴퓨터들 및 네트워크들의 계속해서 변화하는 성질에 기인하여, 도 16에 도시된 컴퓨터 시스템(1600)의 설명은 오로지 특정한 일 예로서만 의도된다. 도 16에 도시된 시스템보다 더 많거나 또는 더 적은 컴포넌트들을 갖는 다수의 다른 구성들이 가능하다. 본원에 제공되는 개시 및 교시들에 기초하여, 당업자는 다양한 실시예들을 구현하기 위한 다른 방식들 및/또는 방법들을 인식할 것이다.
특정 실시예들이 설명되었지만, 다양한 수정예들, 대안예들, 대안적인 구성들, 및 등가물들이 또한 가능하다. 예를 들어, 특정 예들이 SQL 질의들을 사용하여 설명되었지만, 이는 제한적으로 의도되지 않는다. 대안적인 실시예들에 있어서, 본원에서 개시된 교시는 또한 SQL 질의들이 아닌 다른 질의들에 적용될 수 있다. 실시예들은 정확한 특정 데이터 프로세싱 환경들 내에서 동작하도록 제한되는 것이 아니라, 복수의 데이터 프로세싱 환경들 내에서 자유롭게 동작할 수 있다. 추가적으로, 특정 실시예들이 특정한 일련의 트랜잭션(transaction)들 및 단계들을 사용하여 설명되었지만, 이것이 제한적으로 의도되지 않는다는 것이 당업자들에게 명백할 것이다. 어떤 순서도들이 순차적인 프로세스로서 동작들을 설명할 수 있지만, 동작들 중 다수는 병렬로 또는 동시에 수행될 수 있다. 이에 더하여, 동작들의 순서는 재배열될 수 있다. 프로세스는 도면에 포함되지 않은 추가적인 단계들을 가질 수 있다. 이상에서 설명된 실시예들의 다양한 특징들 및 측면들이 개별적으로 또는 함께 사용될 수 있다.
추가로, 특정 실시예들이 하드웨어 및 소프트웨어의 특정한 조합을 사용하여 설명되었지만, 하드웨어 및 소프트웨어의 다른 조합들이 또한 가능하다는 것이 이해되어야만 한다. 특정 실시예들은 오로지 하드웨어로만, 또는 오로지 소프트웨어로만, 또는 이들의 조합들을 사용하여 구현될 수 있다. 본원에서 설명된 다양한 프로세스들은 동일한 프로세서 또는 임의의 조합의 상이한 프로세서들 상에 구현될 수 있다.
컴포넌트들 또는 모듈들이 특정 동작들 또는 기능들을 수행하도록 구성된 것으로 설명되는 경우, 이러한 구성은, 예를 들어, 동작을 수행하기 위한 전자 회로들을 설계함으로써, 동작을 수행하기 위하여 프로그램가능 전자 회로들(예컨대 마이크로프로세서들)을 프로그래밍함으로써 예컨대 컴퓨터 명령어들 또는 코드, 또는 비-일시적인 메모리 매체 상에 저장된 코드 또는 명령어들을 실행하도록 프로그래밍된 프로세서들 또는 코어들을 실행함으로써, 또는 이들의 임의의 조합에 의해 달성될 수 있다. 프로세스들은 비제한적으로 프로세스-간 통신을 위한 통상적을 기술을 포함하는 다양한 기술들을 사용하여 통신할 수 있으며, 프로세스들의 상이한 쌍들이 상이한 기술들을 사용할 수 있거나, 또는 프로세스들의 동일한 쌍이 상이한 시점에 상이한 기술들을 사용할 수 있다.
다수의 특정 세부사항들이 실시예들의 완전한 이해를 제공하기 위하여 본 개시에서 주어진다. 그러나, 실시예들은 이러한 특정 세부사항들 없이 실시될 수 있다. 예를 들어, 잘 알려진 회로들, 프로세스들, 알고리즘들, 구조들, 및 기술들은 실시예들을 모호하게 하는 것을 회피하기 위하여 불필요한 세부사항 없이 도시되었다. 이러한 설명은 오로지 예시적인 실시예들만을 제공하며, 다른 실시예들의 범위, 적용가능성, 또는 구성을 제한하도록 의도되지 않는다. 오히려, 실시예들의 이상의 설명은 당업자들에게 다양한 실시예들을 구현하기 위한 사용 가능한 설명을 제공할 것이다. 엘리먼트들의 기능 및 배열에 있어서 다양한 변화들이 이루어질 수 있다.
따라서, 본 명세서 및 도면들은 제한적인 의미가 아니라 예시적인 것으로서 간주되어야 한다. 그러나, 청구항들에 기술되는 바와 같은 광범위한 사상 및 범위로부터 벗어나지 않고 이에 대한 추가들, 대체들, 삭제들, 및 다른 수정들 및 변화들이 이루이질 수 있다는 것이 명백할 것이다. 따라서, 특정 실시예들이 설명되었지만, 이들은 제한적인 것으로 의도되지 않는다. 다양한 수정예들 및 등가물들이 다음의 청구항들의 범위 내에 속한다.

Claims (20)

  1. 방법으로서,
    컴퓨팅 시스템에 의해, 관계형 데이터베이스 내에 저장된 데이터를 질의하기 위한 질의에 대하여 생성된 원래의 질의 플랜(query plan)을 수신하는 단계로서, 상기 원래의 질의 플랜은 팩트 레코드(fact record)들의 소스로부터 팩트 레코드들을 스캔(scan)하도록 구성된 제 1 팩트 스캔 동작을 포함하며, 상기 원래의 질의 플랜은 상기 제 1 스캔 동작으로부터 레코드들의 세트를 수신하도록 구성된 제 2 동작을 더 포함하는, 단계;
    상기 컴퓨팅 시스템에 의해, 상기 제 1 팩트 스캔 동작과 연관될 제 1 술어 조건(predicate condition)을 식별하는 단계; 및
    상기 컴퓨팅 시스템에 의해, 향상된 질의 플랜을 생성하기 위해 상기 원래의 질의 플랜을 재작성하는 단계로서, 상기 향상된 질의 플랜 내에서, 상기 제 1 술어 조건은 상기 제 1 스캔 동작과 연관되고, 상기 제 2 동작은 상기 술어 조건을 충족시키는 하나 이상의 스캔된 팩트 레코드들만을 수신하는, 단계를 포함하며,
    상기 향상된 질의 플랜은, 상기 제 1 스캔 동작과 상기 제 1 술어 조건의 연관에 기인하여 상기 원래의 질의 플랜보다 더 빠르게 실행되는, 방법.
  2. 청구항 1에 있어서,
    질의하기 위한 상기 데이터는 비-사전-집성된(non-pre-aggregated) 데이터인, 방법.
  3. 청구항 1 또는 청구항 2에 있어서,
    상기 방법은,
    상기 질의에 대한 레코드들의 결과 세트를 획득하기 위해 상기 향상된 질의 플랜을 실행하는 단계; 및
    상기 질의에 대한 응답으로서 상기 레코드들의 결과 세트를 제공하는 단계를 더 포함하는, 방법.
  4. 청구항 1 내지 청구항 3 중 어느 한 항에 있어서,
    상기 향상된 질의 플랜의 실행은 상기 원래의 질의 플랜의 실행보다 더 적은 중앙 프로세싱 유닛(central processing unit; CPU) 사이클들을 소요하는, 방법.
  5. 청구항 1 내지 청구항 4 중 어느 한 항에 있어서,
    상기 제 2 동작에 의해 수신되고 프로세싱되는 팩트 레코드들의 수는 상기 원래의 질의 플랜 내에서보다 상기 향상된 질의 플랜 내에서 더 적은, 방법.
  6. 청구항 1 내지 청구항 5 중 어느 한 항에 있어서,
    상기 식별하는 단계는,
    상기 원래의 질의 플랜 내에서 상기 제 1 팩트 스캔 동작을 식별하는 단계로서, 상기 제 1 팩트 스캔 동작은 제 1 팩트 테이블에 대해 동작하는, 단계; 및
    상기 제 1 스캔 동작에서 시작하여, 상기 제 1 팩트 스캔 동작에 대한 하나 이상의 적용가능한 술어 조건들의 리스트를 식별하기 위해 상기 원래의 질의 플랜을 워킹(walk)하는 단계로서, 상기 적용가능한 술어 조건들의 리스트는 상기 제 1 술어 조건을 포함하는, 단계를 포함하는, 방법.
  7. 청구항 1 내지 청구항 5 중 어느 한 항에 있어서,
    상기 식별하는 단계는,
    상기 원래의 질의 플랜 내에서 제 1 팩트 테이블에 대하여 동작하는 상기 제 1 팩트 스캔 동작을 식별하는 단계;
    상기 원래의 질의 플랜 내에서, 제 2 팩트 테이블에 대하여 동작하는 제 2 팩트 스캔 동작을 식별하는 단계;
    상기 원래의 질의 플랜 내에서, 상기 제 2 팩트 테이블과 차원 테이블(dimension table) 사이의 조인(join) 동작을 식별하는 단계로서, 상기 제 1 술어 조건은 상기 차원 테이블과 연관되는, 단계; 및
    상기 제 1 팩트 테이블과 상기 제 2 팩트 테이블 사이의 공통 차원을 식별하는 단계를 포함하며,
    상기 제 1 술어 조건은 상기 공통 차원으로부터의 속성에 기초하는, 방법.
  8. 청구항 1 내지 청구항 5 중 어느 한 항에 있어서,
    상기 식별하는 단계는,
    상기 제 1 팩트 스캔 동작에 대하여 적용가능한 복수의 술어 조건들을 식별하는 단계;
    상기 복수의 술어 조건들 내의 각각의 술어 조건에 대하여 순 이득 메트릭(net benefit metric)을 계산하는 단계로서, 상기 복수의 술어 조건들 내의 특정 술어 조건에 대한 순 이득 측정은, 상기 팩트 레코드들의 소스로부터 팩트 로우(row)들을 프로세싱하는 비용에서 상기 제 1 팩트 스캔 동작에 상기 특정 술어 조건을 적용하는 비용을 뺀 비용에서의 감소의 측정인, 단계;
    상기 복수의 술어 조건들에 대하여 계산된 상기 순 이득 메트릭들에 기초하여 상기 제 1 팩트 스캔 동작에 대하여 상기 복수의 술어 조건들을 정렬하는 단계; 및
    상기 복수의 술어 조건들로부터, 상기 정렬하는 단계에 기초하여 상기 제 1 팩트 스캔 동작과 연관될 술어 조건을 선택하는 단계를 포함하는, 방법.
  9. 청구항 1 내지 청구항 5 중 어느 한 항에 있어서,
    상기 식별하는 단계는,
    상기 제 1 팩트 스캔 동작에 대하여 적용가능한 술어 조건을 식별하는 단계;
    상기 적용가능한 술어 조건에 대한 순 이득 메트릭을 계산하는 단계;
    상기 적용가능한 술어 조건에 대하여 계산된 상기 순 이익 메트릭에 기초하여, 상기 적용가능한 술어 조건이 상기 제 1 팩트 스캔 동작과 연관되지 않을 것을 결정하는 단계; 및
    기능적 종속성 정보를 사용하여 상기 적용가능한 술어 조건으로부터 상기 제 1 술어 조건을 추론하는 단계를 포함하는, 방법.
  10. 청구항 1 내지 청구항 9 중 어느 한 항에 있어서,
    상기 팩트 레코드들의 소스는 팩트 레코드들을 저장하는 테이블, 구체화된 뷰(materialized view), 또는 온라인 분석 프로세싱(online analytical processing; OLAP) 인덱스인, 방법.
  11. 청구항 1 내지 청구항 5 중 어느 한 항에 있어서,
    상기 제 1 술어 조건을 식별하는 단계는,
    상기 원래의 질의 플랜 내의 제 3 동작을 식별하는 단계를 포함하며, 상기 제 1 술어 조건은 상기 제 3 동작과 연관되는, 방법.
  12. 청구항 11에 있어서,
    상기 제 3 동작은 차원 테이블과 연관되는, 방법.
  13. 청구항 1 내지 청구항 5 중 어느 한 항에 있어서,
    상기 제 1 술어 조건을 식별하는 단계는,
    상기 제 1 팩트 스캔 동작과 연관될 제 2 술어 조건을 식별하는 단계; 및
    상기 제 2 술어 조건을 상기 제 1 술어 조건으로 변환하는 단계를 포함하는, 방법.
  14. 청구항 13에 있어서,
    상기 변환하는 단계는 상기 제 2 술어 조건을 상기 제 1 술어 조건으로 변환하기 위하여 기능적 종속성 정보를 사용하는 단계를 포함하는, 방법.
  15. 청구항 13 또는 청구항 14에 있어서,
    상기 제 2 술어 조건은 상기 제 1 차원 필드에 대한 값을 지정하며, 상기 제 1 술어 조건은 상기 제 1 차원 필드와는 상이한 제 2 차원 필드에 대한 값을 지정하고, 상기 제 2 차원 필드는 차원 테이블 내의 또는 상기 팩트 레코드들의 소스 내의 컬럼 필드인, 방법.
  16. 청구항 1, 청구항 2, 청구항 3, 청구항 4, 청구항 5, 또는 청구항 10에 있어서,
    상기 방법은,
    상기 원래의 질의 플랜 내에서 제 1 서브-플랜을 식별하는 단계로서, 상기 제 1 서브-플랜은 상기 제 1 팩트 스캔 동작을 포함하고, 상기 제 1 서브-플랜은 하나 이상의 집성, 조인, 프로젝트(project), 필터, 또는 팩트 스캔 동작들을 포함하는, 단계를 더 포함하며,
    상기 향상된 질의 플랜은 상기 제 1 스캔 동작과 연관되는 상기 제 1 술어 조건을 갖는 상기 제 1 서브-플랜을 포함하는, 방법.
  17. 청구항 1, 청구항 2, 청구항 3, 청구항 4, 청구항 5, 또는 청구항 10에 있어서,
    상기 방법은,
    스타 스키마(star schema)에 기초하여, 상기 팩트 레코드들의 소스가 차원 테이블과 조인될 수 있다는 것을 결정하는 단계를 더 포함하며,
    상기 제 1 술어 조건은 상기 팩트 레코드들의 소스와 조인될 상기 차원 테이블 내의 차원 키에 관련된 조건을 포함하는, 방법.
  18. 청구항 1 내지 청구항 5, 청구항 8, 또는 청구항 9 중 어느 한 항에 있어서,
    상기 팩트 레코드들의 소스는 OLAP 인덱스이며, 상기 OLAP 인덱스는 테이블 및 상기 테이블 내의 차원 값들을 인덱싱하는 인덱스를 포함하고;
    상기 테이블은 팩트 레코드들을 저장하는 팩트 테이블을 상기 차원 값들을 포함하는 차원 테이블과 조인하는 것으로부터 기인하는 데이터를 포함하며; 및
    상기 제 1 술어 조건은 상기 OLAP 인덱스 내의 상기 차원 값들에 대하여 평가되는, 방법.
  19. 하나 이상의 프로세서들에 의해 실행가능한 복수의 명령어들을 저장하는 비-일시적인 컴퓨터-판독가능 메모리로서, 상기 복수의 명령어들은 상기 하나 이상의 프로세서들에 의해 실행될 때 상기 하나 이상의 프로세서들이 하기의 동작들을 수행하게끔 하며, 상기 동작들은,
    관계형 데이터베이스 내에 저장된 데이터를 질의하기 위한 질의에 대하여 생성된 원래의 질의 플랜을 수신하는 동작으로서, 상기 원래의 질의 플랜은 팩트 레코드들의 소스로부터 팩트 레코드들을 스캔하도록 구성된 제 1 팩트 스캔 동작을 포함하며, 상기 원래의 질의 플랜은 상기 제 1 스캔 동작으로부터 레코드들의 세트를 수신하도록 구성된 제 2 동작을 더 포함하는, 동작;
    상기 제 1 팩트 스캔 동작과 연관될 제 1 술어 조건을 식별하는 동작; 및
    향상된 질의 플랜을 생성하기 위해 상기 원래의 질의 플랜을 재작성하는 동작으로서, 상기 향상된 질의 플랜 내에서, 상기 제 1 술어 조건은 상기 제 1 스캔 동작과 연관되고, 상기 제 2 동작은 상기 술어 조건을 충족시키는 하나 이상의 스캔된 팩트 레코드들만을 수신하는, 동작;
    상기 질의에 대한 레코드들의 결과 세트를 획득하기 위하여 상기 향상된 질의 플랜을 실행하는 동작으로서, 상기 향상된 질의 플랜은, 상기 제 1 스캔 동작과 상기 제 1 술어 조건의 연관에 기인하여 상기 원래의 질의 플랜보다 더 빠르게 실행되는, 동작; 및
    상기 질의에 대한 응답으로서 상기 레코드들의 결과 세트를 제공하는 동작을 포함하는, 비-일시적인 컴퓨터-판독가능 메모리.
  20. 시스템으로서,
    하나 이상의 프로세서들; 및
    상기 하나 이상의 프로세서들에 결합되는 메모리로서, 상기 메모리는 상기 하나 이상의 프로세서들에 의해 실행가능한 복수의 명령어들을 저장하며, 상기 복수의 명령어들은 상기 하나 이상의 프로세서들에 의해 실행될 때 상기 하나 이상의 프로세서들이 하기의 동작들을 수행하게끔 하며, 상기 동작들은,
    관계형 데이터베이스 내에 저장된 데이터를 질의하기 위한 질의에 대하여 생성된 원래의 질의 플랜을 수신하는 동작으로서, 상기 원래의 질의 플랜은 팩트 레코드들의 소스로부터 팩트 레코드들을 스캔하도록 구성된 제 1 팩트 스캔 동작을 포함하며, 상기 원래의 질의 플랜은 상기 제 1 스캔 동작으로부터 레코드들의 세트를 수신하도록 구성된 제 2 동작을 더 포함하는, 동작;
    상기 제 1 팩트 스캔 동작과 연관될 제 1 술어 조건을 식별하는 동작; 및
    향상된 질의 플랜을 생성하기 위해 상기 원래의 질의 플랜을 재작성하는 동작으로서, 상기 향상된 질의 플랜 내에서, 상기 제 1 술어 조건은 상기 제 1 스캔 동작과 연관되고, 상기 제 2 동작은 상기 술어 조건을 충족시키는 하나 이상의 스캔된 팩트 레코드들만을 수신하는, 동작;
    상기 질의에 대한 레코드들의 결과 세트를 획득하기 위하여 상기 향상된 질의 플랜을 실행하는 동작으로서, 상기 향상된 질의 플랜은, 상기 제 1 스캔 동작과 상기 제 1 술어 조건의 연관에 기인하여 상기 원래의 질의 플랜보다 더 빠르게 실행되는, 동작; 및
    상기 질의에 대한 응답으로서 상기 레코드들의 결과 세트를 제공하는 동작을 포함하는, 시스템.
KR1020207023647A 2018-01-16 2019-01-16 Sql 질의 플랜들을 최적화하기 위한 차원 콘텍스트 전파 기술들 KR102627690B1 (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201862617970P 2018-01-16 2018-01-16
US62/617,970 2018-01-16
US201862747642P 2018-10-18 2018-10-18
US62/747,642 2018-10-18
US16/248,061 US11036735B2 (en) 2018-01-16 2019-01-15 Dimension context propagation techniques for optimizing SQL query plans
US16/248,061 2019-01-15
PCT/US2019/013827 WO2019143705A1 (en) 2018-01-16 2019-01-16 Dimension context propagation techniques for optimizing sql query plans

Publications (2)

Publication Number Publication Date
KR20200106950A true KR20200106950A (ko) 2020-09-15
KR102627690B1 KR102627690B1 (ko) 2024-01-23

Family

ID=67212927

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020207023647A KR102627690B1 (ko) 2018-01-16 2019-01-16 Sql 질의 플랜들을 최적화하기 위한 차원 콘텍스트 전파 기술들

Country Status (6)

Country Link
US (1) US11036735B2 (ko)
EP (1) EP3740880A1 (ko)
JP (1) JP7273045B2 (ko)
KR (1) KR102627690B1 (ko)
CN (1) CN111971666A (ko)
WO (1) WO2019143705A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20230146162A (ko) 2022-04-11 2023-10-19 주식회사 이노와이어리스 사용자의 쿼리 패턴을 이용한 쿼리 성능 향상 방법
KR102649770B1 (ko) * 2023-01-10 2024-03-21 쿠팡 주식회사 정보를 제공하는 방법 및 이를 지원하는 전자 장치

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11494378B2 (en) * 2018-06-19 2022-11-08 Salesforce, Inc. Runtime optimization of grouping operators
US11392592B2 (en) * 2018-11-05 2022-07-19 Sindice Limited Method for efficient backend evaluation of aggregates on composite relationships in a relationally mapped ER model
US11599539B2 (en) * 2018-12-26 2023-03-07 Palantir Technologies Inc. Column lineage and metadata propagation
US10970272B2 (en) * 2019-01-31 2021-04-06 Sap Se Data cloud—platform for data enrichment
CN110263105B (zh) * 2019-05-21 2021-09-10 北京百度网讯科技有限公司 查询处理方法、查询处理系统、服务器和计算机可读介质
CN113906409A (zh) * 2019-05-29 2022-01-07 西格玛计算机有限公司 行级工作表安全
US11194793B1 (en) 2019-06-25 2021-12-07 Amazon Technologies, Inc. Dynamically materialized views for sheets based data
US11086894B1 (en) * 2019-06-25 2021-08-10 Amazon Technologies, Inc. Dynamically updated data sheets using row links
WO2021030524A1 (en) * 2019-08-15 2021-02-18 Telepathy Labs, Inc. System and method for querying multiple data sources
CA3153691A1 (en) * 2019-09-13 2021-03-18 Tableau Software, LLC Utilizing appropriate measure aggregation for generating data visualizations of multi-fact datasets
US11449796B2 (en) * 2019-09-20 2022-09-20 Amazon Technologies, Inc. Machine learning inference calls for database query processing
US11263220B2 (en) 2019-09-27 2022-03-01 Amazon Technologies, Inc. On-demand execution of object transformation code in output path of object storage service
US11656892B1 (en) * 2019-09-27 2023-05-23 Amazon Technologies, Inc. Sequential execution of user-submitted code and native functions
US11550944B2 (en) 2019-09-27 2023-01-10 Amazon Technologies, Inc. Code execution environment customization system for object storage service
CN110968895B (zh) * 2019-11-29 2022-04-05 北京百度网讯科技有限公司 一种数据的处理方法、装置、电子设备及存储介质
US11681708B2 (en) 2019-12-26 2023-06-20 Snowflake Inc. Indexed regular expression search with N-grams
US10997179B1 (en) 2019-12-26 2021-05-04 Snowflake Inc. Pruning index for optimization of pattern matching queries
US11372860B2 (en) * 2019-12-26 2022-06-28 Snowflake Inc. Processing techniques for queries where predicate values are unknown until runtime
US11567939B2 (en) 2019-12-26 2023-01-31 Snowflake Inc. Lazy reassembling of semi-structured data
US10769150B1 (en) 2019-12-26 2020-09-08 Snowflake Inc. Pruning indexes to enhance database query processing
US11308090B2 (en) 2019-12-26 2022-04-19 Snowflake Inc. Pruning index to support semi-structured data types
US11144527B2 (en) * 2020-01-14 2021-10-12 International Business Machines Corporation Optimizing database table scans in the presence of ordered data
US11392607B2 (en) * 2020-01-30 2022-07-19 International Business Machines Corporation Automatic feature engineering during online scoring phase
US20210248121A1 (en) * 2020-02-12 2021-08-12 Nextworld Llc Realtime data summarization and aggregation with cubes
US20210311942A1 (en) * 2020-04-02 2021-10-07 International Business Machines Corporation Dynamically altering a query access plan
CN111597209B (zh) * 2020-04-30 2023-11-14 清华大学 一种数据库物化视图构建系统、方法以及系统创建方法
US11301517B2 (en) * 2020-05-07 2022-04-12 Ebay Inc. Method and system for identifying, managing, and monitoring data dependencies
US11288271B2 (en) * 2020-05-28 2022-03-29 Microsoft Technology Licensing, Llc Data lake workload optimization through explaining and optimizing index recommendations
US11468102B2 (en) * 2020-06-05 2022-10-11 Teradata Us, Inc. Optimizing limit queries over analytical functions
US20220012238A1 (en) * 2020-07-07 2022-01-13 AtScale, Inc. Datacube access connectors
US20220012242A1 (en) * 2020-07-07 2022-01-13 AtScale, Inc Hierarchical datacube query plan generation
US11216462B1 (en) * 2020-08-14 2022-01-04 Snowflake Inc. Transient materialized view rewrite
US11379485B2 (en) * 2020-12-08 2022-07-05 Sap Se Inferred predicates for query optimization
EP4275133A1 (en) * 2021-01-07 2023-11-15 Telepathy Labs, Inc. System and method for analysis of data from multiple data sources
CN115599811A (zh) * 2021-07-09 2023-01-13 华为技术有限公司(Cn) 数据处理的方法、装置和计算系统
US20230081212A1 (en) * 2021-08-27 2023-03-16 Oracle International Corporation System and method for providing multi-hub datasets for use with data analytics environments
CN113792079B (zh) * 2021-11-17 2022-02-08 腾讯科技(深圳)有限公司 数据查询方法、装置、计算机设备和存储介质
US11960463B2 (en) * 2022-05-23 2024-04-16 Sap Se Multi-fragment index scan
US20230394041A1 (en) * 2022-06-06 2023-12-07 Microsoft Technology Licensing, Llc Systems and methods for accelerating and optimizing groupwise comparison in relational databases
US11893016B1 (en) * 2022-10-26 2024-02-06 Snowflake Inc. Secure predicate derivation of queries using metadata
US11880369B1 (en) 2022-11-21 2024-01-23 Snowflake Inc. Pruning data based on state of top K operator
CN116303833B (zh) * 2023-05-18 2023-07-21 联通沃音乐文化有限公司 一种基于olap的向量化数据混合存储方法
CN117520385B (zh) * 2024-01-05 2024-04-16 凯美瑞德(苏州)信息科技股份有限公司 一种基于探索价值和查询代价的数据库查询优化方法
CN117591547A (zh) * 2024-01-18 2024-02-23 中昊芯英(杭州)科技有限公司 数据库的查询方法、装置、终端设备以及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7080062B1 (en) * 1999-05-18 2006-07-18 International Business Machines Corporation Optimizing database queries using query execution plans derived from automatic summary table determining cost based queries
US20130173528A1 (en) * 2011-12-29 2013-07-04 International Business Machines Corporation Multi-fact query processing in data processing system

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6014656A (en) 1996-06-21 2000-01-11 Oracle Corporation Using overlapping partitions of data for query optimization
ATE246824T1 (de) * 1999-07-21 2003-08-15 Torben Bach Pedersen Verfahren und systeme um olap hierarchien zusammenfassbar zu machen
JP2001243242A (ja) * 2000-02-25 2001-09-07 Hitachi Ltd 問合せ処理方法およびそれを実施するデータベース管理システムその処理プログラムを格納した記録媒体
JP2002007435A (ja) * 2000-06-20 2002-01-11 Nec Corp 対話的分析データベースシステム及び対話的分析プログラムを記録した記録媒体
US6567802B1 (en) * 2000-09-06 2003-05-20 The Trustees Of The University Of Pennsylvania Systematic approach to query optimization
US7383246B2 (en) * 2003-10-31 2008-06-03 International Business Machines Corporation System, method, and computer program product for progressive query processing
US8108399B2 (en) * 2007-05-18 2012-01-31 Microsoft Corporation Filtering of multi attribute data via on-demand indexing
US8352458B2 (en) * 2008-05-07 2013-01-08 Oracle International Corporation Techniques for transforming and loading data into a fact table in a data warehouse
US8161035B2 (en) * 2009-06-04 2012-04-17 Oracle International Corporation Query optimization by specifying path-based predicate evaluation in a path-based query operator
US9043310B2 (en) * 2011-11-08 2015-05-26 International Business Machines Corporation Accessing a dimensional data model when processing a query
US8762407B2 (en) 2012-04-17 2014-06-24 Renmin University Of China Concurrent OLAP-oriented database query processing method
US20150088919A1 (en) * 2013-09-20 2015-03-26 Oracle International Corporation Transforming a query to reuse stored data
US9747331B2 (en) 2014-10-06 2017-08-29 International Business Machines Corporation Limiting scans of loosely ordered and/or grouped relations in a database
US10133778B2 (en) * 2015-11-20 2018-11-20 Sap Se Query optimization using join cardinality
US10762037B2 (en) * 2016-03-25 2020-09-01 Hitachi, Ltd Data processing system
US10528599B1 (en) * 2016-12-16 2020-01-07 Amazon Technologies, Inc. Tiered data processing for distributed data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7080062B1 (en) * 1999-05-18 2006-07-18 International Business Machines Corporation Optimizing database queries using query execution plans derived from automatic summary table determining cost based queries
US20130173528A1 (en) * 2011-12-29 2013-07-04 International Business Machines Corporation Multi-fact query processing in data processing system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20230146162A (ko) 2022-04-11 2023-10-19 주식회사 이노와이어리스 사용자의 쿼리 패턴을 이용한 쿼리 성능 향상 방법
KR102649770B1 (ko) * 2023-01-10 2024-03-21 쿠팡 주식회사 정보를 제공하는 방법 및 이를 지원하는 전자 장치

Also Published As

Publication number Publication date
US11036735B2 (en) 2021-06-15
EP3740880A1 (en) 2020-11-25
JP2021511582A (ja) 2021-05-06
CN111971666A (zh) 2020-11-20
US20190220464A1 (en) 2019-07-18
KR102627690B1 (ko) 2024-01-23
WO2019143705A1 (en) 2019-07-25
JP7273045B2 (ja) 2023-05-12

Similar Documents

Publication Publication Date Title
KR102627690B1 (ko) Sql 질의 플랜들을 최적화하기 위한 차원 콘텍스트 전파 기술들
JP6617117B2 (ja) 半構造データのためのスケーラブルな分析プラットフォーム
US20220035815A1 (en) Processing database queries using format conversion
US10860598B2 (en) Systems and methods for interest-driven business intelligence systems including event-oriented data
JP6416194B2 (ja) 半構造データのためのスケーラブルな分析プラットフォーム
US10242061B2 (en) Distributed execution of expressions in a query
US20140279074A1 (en) Data management platform for digital advertising
WO2016018942A1 (en) Systems and methods for an sql-driven distributed operating system
Jewell et al. Performance and capacity implications for big data
Löser et al. Situational business intelligence
Caldarola et al. Big data: A survey-the new paradigms, methodologies and tools
CN114730312A (zh) 从异构数据源创建的受管物化视图
US10776368B1 (en) Deriving cardinality values from approximate quantile summaries
US8250024B2 (en) Search relevance in business intelligence systems through networked ranking
Schwalb et al. Leveraging in-memory technology for interactive analyses of point-of-sales data
Reniers et al. Schema design support for semi-structured data: Finding the sweet spot between NF and De-NF
Monica et al. Survey on big data by coordinating mapreduce to integrate variety of data
Bharti et al. Identifying requirements for Big Data analytics and mapping to Hadoop tools
Khatiwada Architectural issues in real-time business intelligence
Dhanapal et al. Emerging Big Data storage architectures: A new paradigm
Alam et al. Survey on Data Warehouse from Traditional to Realtime and Society Impact of Real Time Data
Aye et al. Big Data Analytics on Large Scale Shared Storage System
Chaudhuri et al. An Overview of Business Intelligence Technology BI technologies are essential to running today's businesses and this technology is going through sea changes.

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant