JP2021511582A - Ｓｑｌクエリプランを最適化するための次元コンテキスト伝搬技術 - Google Patents

Ｓｑｌクエリプランを最適化するための次元コンテキスト伝搬技術 Download PDF

Info

Publication number
JP2021511582A
JP2021511582A JP2020539091A JP2020539091A JP2021511582A JP 2021511582 A JP2021511582 A JP 2021511582A JP 2020539091 A JP2020539091 A JP 2020539091A JP 2020539091 A JP2020539091 A JP 2020539091A JP 2021511582 A JP2021511582 A JP 2021511582A
Authority
JP
Japan
Prior art keywords
fact
query plan
predicate
predicate condition
records
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2020539091A
Other languages
English (en)
Other versions
JP7273045B2 (ja
JP2021511582A5 (ja
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 JP2021511582A publication Critical patent/JP2021511582A/ja
Publication of JP2021511582A5 publication Critical patent/JP2021511582A5/ja
Application granted granted Critical
Publication of JP7273045B2 publication Critical patent/JP7273045B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24542—Plan optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/248—Presentation of query results
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/283—Multi-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

クエリを効率的に実行するための技術を提供する。クエリのために生成されたクエリプランは最適化されて、高度化クエリプランとして書換えられる。高度化クエリプランは、実行時に、使用するＣＰＵサイクルがより少ないので、オリジナルのクエリプランよりも高速で実行される。したがって、高度化クエリプランが生成されるクエリは、得られた結果またはクエリされているデータを損なうことなく、より高速で実行される。最適化は、オリジナルのクエリプランにおける１つ以上のファクトスキャンオペレーションのセットを識別し、次いで、書換えられた高度化クエリプランにおいて、１つ以上の次元コンテキスト述語条件をファクトスキャンオペレーションのセットのうちの１つ以上に関連付けることを含む。これにより、オリジナルのクエリプランと比較して、高度化クエリプランにおけるファクトレコードをスキャンおよび／または処理するコスト全体が削減されるとともに、高度化クエリプランがオリジナルのクエリプランよりも高速で実行される。

Description

他の出願の参照
本願は以下の出願の利益および優先権を主張するものであって、それらの内容全体が、あらゆる目的のために引用により本明細書に援用されている。
（１）２０１８年１月１６日に提出された、「DIMENSION CONTEXT PROPAGATION TECHNIQUE FOR ANALYTICAL SQL QUERIES（分析ＳＱＬクエリのための次元コンテキスト伝搬技術）」と題された米国仮出願第６２／６１７，９７０号；
（２）２０１８年１０月１８日に提出された、「DIMENSION CONTEXT PROPAGATION TECHNIQUE FOR ANALYTICAL SQL QUERIES（分析ＳＱＬクエリのための次元コンテキスト伝搬技術）」と題された米国仮出願第６２／７４７，６４２号；および、
（３）２０１９年１月１５日に提出された、「DIMENSION CONTEXT PROPAGATION TECHNIQUES FOR OPTIMIZING SQL QUERY PLANS（ＳＱＬクエリプランを最適化するための次元コンテキスト伝搬技術）」と題された米国非仮出願第１６／２４８，０６１号。
背景
分析ソリューションは、企業が、時間、空間、製品および顧客などの次元に対する彼らのビジネスのさまざまな活動をよりよく理解することを可能にする。これは、コンテキスト分析または相関分析、性能管理、ｗｈａｔ−ｉｆ分析、予測、スライシング・ダイシング（slicing-and-dicing）分析、キーパフォーマンス指標（Key Performance Indicator：ＫＰＩ）、およびトレンド分析、ダッシュボーディングなどを実行することを含み得る。任意の多次元分析の重要な局面は、分析の焦点および分析の入力の両方を指定する次元コンテキストである。
オンライン分析処理（online analytical processing：ＯＬＡＰ）データベースシステムは、多くの場合、さまざまなビジネス関連活動に関する見込みを得るかまたは有用なパターンを抽出するために、データをマイニングしてレポートを生成するために用いられる。たとえば、ＯＬＡＰデータベースは、販売傾向を識別し、マーケティングキャンペーンを分析し、財務業績を予測するのに用いることができる。これは、典型的には、大量の（たとえば、数百万の記録の）多次元データベースデータに対して分析クエリを評価することを伴う。たとえば、販売データは、時間、地理的地域、部門および／または個々の製品などの次元の観点から分析することができる。
アナリストは、一般に、自身のデータを考慮に入れたセマンティックモデルを有する。データは次元およびメトリクスの観点からを検討することが一般的である。この場合、メトリクスが活動（たとえば、売上高、販売数量）に関する詳細を記録しており、次元が活動のコンテキスト（たとえば、販売された製品の種類、販売が行われた店舗、店舗が置かれた状態、購入した顧客等）を記録している。ビジネスデータは一般に多次元であり、意味論的にリッチである。
多数のデータ分析ソリューションは、ＳＱＬ（構造化照会言語：Structured Query language）などの何らかのクエリ言語が分析言語として用いられているバックエンドとしてリレーショナルデータベースシステムを用いる。多次元データベースデータは、典型的には、次元またはコンテキスト情報を格納する次元レコード（たとえば、時間データ、地理的データ、部門データ、製品データ）とは別個に格納されるメトリクスを格納するファクトレコード（たとえば、販売データ）を含む。たとえば、ファクトレコードはファクトテーブルに格納されてもよく、次元レコードは次元テーブルに格納されてもよい。
ＳＱＬ領域では、分析ソリューションはスタースキーマ（エンティティ・リレーションシップ（Entity-Relationship：ＥＲ）ダイアグラムの見え方に応じて命名：図４を参照）の上に構築され、ＳＱＬクエリを用いてクエリされる。典型的な分析クエリは、結合または一体化によって組合わされたいくつかの構築ブロッククエリサブプラン／共通テーブル表現を含み得る。クエリのためのクエリサブプランは、典型的には、多次元空間のスライス上の次元テーブルおよび集約計算とのファクトテーブルの結合を伴う。クエリを実行するコストの大部分は、典型的には、ファクトレコードのソースのスキャンである。さらに、次元レコードの観点からファクトレコードを分析することは、しばしば、ファクトレコードを次元レコードと結合すること、たとえば、ファクトテーブルを次元テーブルと結合することを伴う。しかしながら、ファクトレコードを次元レコードと結合することは、少なくとも相当な数のファクトレコードを処理することが必要になるという理由のために、計算集約的であり得る。いくつかの既存の技術は、ＯＬＡＰキューブ、抽出物、および実体化された事前集約型テーブルを用いるなど、事前演算を用いることによってクエリ実行を最適化することに焦点を合わせている。しかしながら、これらの技術によって提供される改善の実行は依然として制限されている。加えて、事前集約は、粒度の損失、アドホッククエリの実行不可などのいくつかの欠点を有する。
演算オーバーヘッドを組合わせることは、多くの場合にデータベースクエリが立案されて評価される方法である。データベースクエリの立案は、一般に、ドメインまたはコンテキストの知識をほとんど持たないデータベースプログラマにアウトソースされる。さらに、このようなクエリをＳＱＬなどの言語で立案することは極めて困難である。クエリのさまざまな部分は典型的には別個の方法で評価されるが、これにより、結果として、データが不必要に重複して処理されてしまう可能性がある。たとえば、クエリが書込まれる態様により、クエリのためのクエリプランは、クエリプランの後半段階でフィルタオペレーションを特定し得る。フィルタオペレーションに関係なく、クエリプランの前半段階でクエリプランオペレーションが実行される場合、前半段階で実行されるデータ処理の多くが無駄になってしまう可能性がある。なぜなら、前半段階で処理されるデータの多くは、後半段階で無関係なデータとしてフィルタリングして除去される可能性があるからである。
概要
本開示は概してクエリを実行することに関する。より特定的には、クエリ実行性能を高めるための技術を説明する。本明細書では、方法、システム、１つ以上のプロセッサによって実行可能なプログラム、コードまたは命令を格納する非一時的なコンピュータ読取り可能記憶媒体などを含むさまざまな発明実施形態について説明する。
本開示は、概して、アドホックデータベースクエリなどの分析クエリを効率的に実行するための技術に関する。ＳＱＬアドホッククエリなどのクエリの場合、クエリのために生成されたクエリプランは、最適化されるとともに高度化されて、最適化または高度化クエリプランとして書換えられる。高度化クエリプランは、実行時に、用いるＣＰＵサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。結果として、高度化クエリプランが生成されるクエリは、得られた結果またはクエリされているデータを損なうことなく、より高速で実行される。特定の実施形態では、最適化または高度化クエリプランはまた、実行時に、用いるメモリリソースがオリジナルの非最適化クエリプランよりも少ない。
特定の実施形態では、オリジナルのクエリプランは、オリジナルのクエリプランにおける１つ以上のファクトスキャンオペレーション／オペレータのセットを識別し、次いで、書換えられた高度化クエリプランにおいて、次元コンテキストをファクトスキャンオペレーションのセットのうちの１つ以上に関連付けることによって最適化される。特定の実施形態では、次元コンテキストは、次元コンテキストに対応する１つ以上の述語条件（次元コンテキスト述語条件とも称される）をファクトスキャンオペレーションに関連付けることによって、ファクトスキャンオペレーションに関連付けられる。ファクトスキャンオペレーションは、ファクトレコードのソース（ファクトソースとも称される）からファクト（ファクトレコードまたはファクト行とも称される）をスキャンするかまたは読取るように構成されたクエリプランにおけるオペレーションである。高度化クエリプランにおけるファクトスキャンオペレーションの述語条件との関連付けはまた、ファクトスキャンオペレーションへの述語条件もしくは次元コンテキストの伝搬、またはファクトスキャンオペレーションが動作するファクトソースへの述語条件もしくは次元コンテキストの伝搬とも称される。関連付けまたは伝搬されているので、高度化クエリプランにおけるファクトレコードのスキャン／読取りおよび／または処理の全体的コストはオリジナルのクエリプランと比較すると非常に少ない。結果として、高度化クエリプランは、実行時に、用いるＣＰＵサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。
特定の実施形態では、クエリプランを最適化するプロセスは、クエリプラン内におけるどの１つ以上のファクトスキャンオペレーションが述語条件伝搬の候補であるかを識別することと、各々の候補ファクトスキャンオペレーションに関連付けられるべき１つ以上の述語条件を識別することと、さらに、当該関連付けを用いてクエリプランを書換えることとを含み得る。クエリについてのクエリプランは、当該関連付けを用いて実行される。本明細書中に開示される多種多様な技術がこの処理を実行するために用いられてもよい。
多種多様な技術を用いて、ファクトスキャンオペレーションに関連付けられるべき述語条件が識別され得る。たとえば、オリジナルのクエリプランの一部分からの述語条件は、書換えられた高度化クエリプランにおけるクエリプランの別の部分におけるファクトスキャンオペレーションに伝搬されてもよい。一例として、クエリプランの一部分における次元テーブルに適用される次元述語条件が伝搬されて、クエリプランの別の部分におけるファクトスキャンオペレーションに関連付けられてもよい。他のいくつかの事例では、特定の述語条件をファクトスキャンオペレーションに関連付けるのではなく、クエリプラン内の特定の述語条件またはオリジナルの述語条件から新しい述語条件が推論される（特定の述語条件またはオリジナルの述語条件の新しい述語条件への変換またはマッピングとも称される）とともに、新しい述語条件が特定の述語条件またはオリジナルの条件ではなくファクトスキャンオペレーションに関連付けられる。新しい述語条件は、新しい述語条件でファクトスキャンオペレーションを実行するコスト（たとえば、実行時間）が特定の述語条件またはオリジナルの述語条件でファクトスキャンオペレーションを実行するコストよりも小さくなるような条件である。いくつかの事例では、クエリにおいて参照されるファクトテーブルからファクトレコードをスキャンするのではなく、ＯＬＡＰインデックス、事前集約された実体化されたビューなどの他の物理的なファクト構造（ファクトソース）がスキャンの実行のために用いられてもよい。
上述したように、高度化クエリプランは、実行時に、用いるＣＰＵサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。これを達成し得るさまざまな方法がある。場合によっては、クエリプランにおいて述語条件とファクトスキャンオペレーションとが関連付けられていることにより、書換えられたクエリプランによって処理されるファクトレコードの数はオリジナルのクエリプランと比べると少なくなっている。たとえば、述語条件をファクトスキャンオペレーションに関連付けた結果、述語条件を満たすファクトレコードだけがクエリプランにおけるファクトスキャンオペレーションから次の下流オペレーションに提供される。これにより、高度化クエリプランにおける下流オペレーション（たとえば、ファクトテーブルと次元テーブルとの間の結合オペレーション）に提供されるとともに当該下流オペレーションによって処理されなければならないファクトレコードの数が低減される。これにより、高度化クエリプランにおける下流オペレーションの実行に関連付けられる演算オーバーヘッドが低減される。述語条件に基づくファクトレコードのこのフィルタリングにより、クエリプランによるファクトレコードの不要な重複処理が低減される。クエリプランによって処理されるファクトレコードの数が減ると、クエリプランとこれによりクエリプランが生成されるクエリ自体とについて実行時間がより速くなる。クエリプランによって処理されるファクトレコードの数が減ると、書換えられたクエリプランを実行するために用いられるメモリリソースも、より少なくなり得る。上述のように、特定の実施形態では、特定の述語条件から推論されるかまたは変換される新しい述語条件は、特定の述語条件ではなくファクトスキャンオペレーションに関連付けられてもよい。新しい述語条件は、新しい述語条件でファクトスキャンオペレーションを実行するコスト（たとえば、実行時間）が、特定の述語条件でファクトスキャンオペレーションを実行するコストよりも低くなるような条件である。たとえば、特定の述語条件に関連するファクトスキャンオペレーションは実行するのに２秒かかる可能性がある一方で、新しい述語条件に関連する同じファクトスキャンオペレーションは実行するのに１秒しかかからない可能性がある。述語条件を推論または変換することで、高度化クエリプランが非最適化クエリプランよりも高速で実行される。さらに、特定の実施形態では、より高速の実行時間は、ＯＬＡＰインデックスなどの利用可能な代替的なファクト表現に対して、当該ファクト表現のスキャン能力を活用するようにファクトスキャンを実行することによって達成される。たとえば、何らかの述語「Ｐ」に関してＯＬＡＰインデックススキャンに変換することにより、その組合わせがＯＬＡＰインデックスの迅速な述語評価およびスキップスキャンを活用することができるようになり、結果として、場合によってはファクトスキャン処理が桁違いに低減されることとなる。
性能の観点から、高度化クエリプランは、非高度化クエリプランよりも高速で実行され得るとともに、場合によっては、より少ないリソースを用い得る。本明細書中に開示される教示に基づいて実行されるかなりの数のクエリは、非高度化クエリプランでのクエリよりも１０倍、２５倍、１００倍速く、またはさらに桁違いに高い速度で実行され得る。これは、ファクトテーブルが次元テーブルよりも桁違いに大きく、このため、ファクトレコードの処理に関連するスキャンコストを低減することが、大幅な性能向上につながるからである。たとえば、一例では、アドホッククエリのクエリ実行時間は２０６秒から１６秒に短縮された。
多種多様な情報を用いることで、本明細書中に記載されるクエリプラン最適化が容易になり得る。特定の実施形態では、データベースクエリのために生成されるクエリプランは、クエリの構造、クエリのために生成されるクエリプランの構造、クエリされているデータベースに関連するスキーマ情報、およびクエリプランオプティマイザおよび／またはエンハンサが利用できるセマンティクス情報に基づいて最適化および高度化されてもよい。たとえば、ビジネスセマンティクスまたはビジネスインテリジェンス（business intelligence：ＢＩ）セマンティクス情報を用いて、クエリプランを書換えてもよい。セマンティクス情報は、実世界のプロセス、組織構造などに基づくリッチ値および構造セマンティクスを有するビジネスデータを含み得る。セマンティクス情報は、データ中のビジネス階層および機能依存性などのビジネスモデルについての情報を含み得る。たとえば、依存性情報は、データベースデータのさまざまなフィールド（たとえば、列）間の関係（たとえば、階層的または非階層的）を記述する情報を含み得る。たとえば、依存性メタデータは、「市」列の値と「州」列の値との間の階層関係を記述する情報（たとえば、サンフランシスコはカリフォルニアという州内の市である）を含み得る。階層の例は、時間の階層（たとえば、日、週、月、四半期、年など）、地理的階層（たとえば、市、州、国）などを含む。特定の実施形態では、セマンティクス情報は、いかなるユーザ入力もなしに、分析されているデータを格納するデータベースの構造およびスキーマについての情報を分析することによって判断されてもよい。このような分析から導き出される推論は、最適化され高度化されたクエリプランを生成するようにクエリプランを書換えるために用いられてもよい。
特定の実施形態では、リレーショナルデータベースに格納されたデータをクエリするためのクエリのために生成されたオリジナルのクエリプランが受信され得る。オリジナルのクエリプランは、ファクトレコードのソースからファクトレコードをスキャンするように構成された第１のファクトスキャンオペレーションを含み得る。オリジナルのクエリプランはさらに、第１のスキャンオペレーションからレコードのセットを受信するように構成された第２のオペレーションを含んでもよい。第１のファクトスキャンオペレーションに関連付けられるべき第１の述語条件が識別される。オリジナルのクエリプランは、高度化クエリプランを生成するように書換えられてもよく、この場合、高度化クエリプランにおいては、第１の述語条件が第１のスキャンオペレーションに関連付けられており、第２のオペレーションが述語条件を満たす１つ以上のスキャンされたファクトレコードだけを受信する。第１の述語条件が第１のスキャンオペレーションに関連付けられていることで、高度化クエリプランはオリジナルのクエリプランよりも高速で実行される。高度化クエリプランは、クエリについてのレコードの結果セットを得るために実行されてもよい。レコードの結果セットは、クエリに対する応答として提供されてもよい。
クエリによってクエリされている（または、それに対してクエリが動作している）データは、事前集約されていないデータであってもよい。分析プラットフォームは、このような事前集約されていないデータのアドホックな対話型クエリを可能にする。
上述したように、高度化クエリプランはオリジナルのクエリプランよりも高速で実行される。これは、高度化クエリプランは、実行するのに必要なＣＰＵサイクルがオリジナルのクエリプランと比べてより少ないからである。いくつかの実施形態では、これは、第２のオペレーションによって受信されて処理されるファクトレコードの数がオリジナルのクエリプランよりも高度化クエリプランの方がより少ないからである。
特定の実施形態では、第１の述語条件を識別することは、第１のファクトスキャンオペレーションを、オリジナルのクエリプラン内の第１のファクトテーブル上で動作するものとして識別することを含む。第１のスキャンオペレーションから始まって、オリジナルのクエリプランは、第１のファクトスキャンオペレーションについての１つ以上の適用可能な述語条件のリストを識別するためにウォークされる。適用可能な述語条件のリストは第１の述語条件を含む。
特定の実施形態では、第１の述語条件を識別することは、オリジナルのクエリプランから、第１のファクトスキャンオペレーションが第１のファクトテーブル上で動作することと、第２のファクトスキャンオペレーションが第２のファクトテーブル上で動作することと、第２のファクトテーブルと次元テーブルとの間の結合オペレーション（第１の述語条件は次元テーブルに関連付けられている）と、第１のファクトテーブルと第２のファクトテーブルとの間の共通次元（前記第１の述語条件は共通次元からの属性に基づいている）とを識別することを含む。
特定の実施形態では、第１の述語条件を識別することは、第１のファクトスキャンオペレーションに適用可能な複数の述語条件を識別することを含む。次いで、複数の述語条件における各述語条件ごとに純便益メトリックが演算される。この場合、複数の述語条件における特定の述語条件についての純便益基準は、ファクトレコードのソースからのファクト行を処理するコストから、特定の述語条件を第１のファクトスキャンオペレーションに適用するコストを差引いた、減少分である。さらに、複数の述語条件における述語条件は、複数の述語条件について演算される純便益メトリックに基づいて順序付けられる。次いで、順序付けに基づいて第１のファクトスキャンオペレーションに関連付けるための１つ以上の述語条件が選択される。特定の実施形態では、第１のファクトスキャンオペレーションに関連付けるための最高の純便益メトリックでの述語条件が選択される。
特定の実施形態では、第１の述語条件を識別することは、第１のファクトスキャンオペレーションについての適用可能な述語条件を識別することを含む。適用可能な述語条件について純便益メトリックが演算される。適用可能な述語条件について演算された純便益メトリックに基づいて、第１のファクトスキャンオペレーションに関連付けるために当該適用可能な述語条件が実現可能ではないと判断される。次いで、第１のファクトスキャンオペレーションに関連付けられるべき別の述語条件が、機能依存性情報を用いて、適用可能な述語条件から推論される。
ファクトレコードのソースは、ファクトレコードを格納するテーブル、実体化されたビュー、またはオンライン分析処理（online analytical processing：ＯＬＡＰ）インデックスを含む、複数のタイプのソースであってもよい。
特定の実施形態では、第１の述語条件を識別することは、オリジナルのクエリプランにおける第３のオペレーションを識別することを含み、第１の述語条件は第３のオペレーションに関連付けられている。第３のオペレーションは、オリジナルのクエリプランにおける次元テーブルに関連付けられていてもよい。
特定の実施形態では、第１の述語条件を識別することは、第１のスキャンオペレーションに関連付けられるべき第２の述語条件を識別することと、第２の述語条件を第１の述語条件に変換することとを含む。当該変換することは、機能依存性情報を用いて、第２の述語条件を第１の述語条件に変換することを含み得る。一例では、第２の述語条件は、第１の次元フィールドについての値を特定し、第１の述語条件は、第１の次元フィールドとは異なる第２の次元フィールドについての値を特定し、第２の次元フィールドは、次元テーブルまたはファクトレコードのソースにおける列フィールドである。
特定の実施形態では、第１のサブプランはオリジナルのクエリプランにおいて識別されてもよく、第１のサブプランは第１のファクトスキャンオペレーションを含み、第１のサブプランだけが、１つ以上の集約オペレーション、結合オペレーション、プロジェクトオペレーション、フィルタオペレーション、またはファクトスキャンオペレーションを含む。高度化クエリプランは、生成されたとき、第１の述語条件が第１のスキャンオペレーションに関連付けられている第１のサブプランを含み得る。
特定の実施形態では、処理は、スタースキーマに基づいて、ファクトレコードのソースが次元テーブルと結合可能であると判断することを含み得る。ここで、第１の述語条件は、次元テーブルのうち、ファクトレコードのソースと結合されるべき次元キーに関連する条件を含む。
特定の実施形態では、ファクトレコードのソースはＯＬＡＰインデックスであり、ＯＬＡＰインデックスは、テーブルと、テーブル内の次元値をインデックス付けするインデックスとを含む。テーブルは、ファクトレコードを格納するファクトテーブルを次元値を含む次元テーブルと結合することによって得られるデータを含み得る。第１の述語条件は、ＯＬＡＰインデックスにおける次元値に対して評価される。
上述は、他の特徴および実施形態とともに、以下の明細書、添付の特許請求の範囲、および添付の図面を参照することによって、より明らかとなるだろう。
特定の実施形態に従った分析プラットフォームを示す簡略ブロック図である。 特定の実施形態に従った分析プラットフォームを示す簡略ブロック図である。 特定の実施形態に従った、ファクトテーブルおよび次元テーブルのセットを示す図である。 特定の実施形態に従ったクエリプランを示す図である。 特定の実施形態に従ったスタースキーマを示す図である。 特定の実施形態に従った、書換えられたクエリ実行プランを示す図である。 特定の実施形態に従った、セミ結合オペレーションを実行するためのアプローチを示す図である。 特定の実施形態に従ったオンライン分析処理（ＯＬＡＰ）インデックスを示す図である。 特定の実施形態に従った、インデックス・セミ結合オペレーションを実行するためのアプローチを示す図である。 特定の実施形態に従った、インデックス・セミ結合オペレーションを実行するためのアプローチを示す図である。 特定の実施形態に従った、機能依存性に基づいて述語条件を変換するためのアプローチを示す図である。 特定の実施形態に従った、述語条件を次元レコードの第１のセットから次元レコードの第２のセットにわたってファクトレコードのセットに伝搬するためのアプローチを示す図である。 特定の実施形態に従った、述語条件を次元レコードの第１のセットから次元レコードの第２のセットにわたってファクトレコードのセットに伝搬するためのアプローチを示す図である。 特定の実施形態に従った、複数のファクトテーブルを含むスキーマを示す図である。 特定の実施形態に従った、述語条件を次元レコードのセットにわたり（次元テーブルＤＴから）ファクトレコードの第１のセット（ファクトソース１「ＦＳ１」）にわたってファクトレコードの第２のセット（ファクトソース２「ＦＳ２」）に伝搬するためのアプローチを示す図である。 特定の実施形態に従った、述語条件を次元レコードのセットにわたり（次元テーブルＤＴから）ファクトレコードの第１のセット（ファクトソース１「ＦＳ１」）にわたってファクトレコードの第２のセット（ファクトソース２「ＦＳ２」）に伝搬するためのアプローチを示す図である。 特定の実施形態に従った、述語条件を次元レコードのセットにわたり（次元テーブルＤＴから）ファクトレコードの第１のセット（ファクトソース１「ＦＳ１」）にわたってファクトレコードの第２のセット（ファクトソース２「ＦＳ２」）に伝搬するためのアプローチを示す図である。 特定の実施形態に従った高度化クエリプランを生成する方法を示す簡略フローチャートである。 特定の実施形態に従った高度化クエリプランを生成する方法に関連するさらなる詳細を示す簡略フローチャートである。 一実施形態を実現するための分散型システムを示す簡略図である。 特定の実施形態に従ったクラウドベースのシステム環境を示す簡略ブロック図である。 特定の実施形態を実現するために用いられ得るコンピュータシステムを示す図である。 特定の実施形態に従った別のスキーマを示す図である。
詳細な説明
以下の記載では、説明を目的として、いくつかの発明実施形態を完全に理解できるようにするために特定の詳細が記載される。しかしながら、これらの具体的な詳細がなくてもさまざまな実施形態が実施され得ることは明らかであるだろう。添付の図面および以下の説明は限定的であるよう意図されたものではない。
本開示は、概して、対話型アドホックデータベースクエリなどの分析クエリを効率的に実行するための技術に関する。ＳＱＬアドホッククエリなどのクエリの場合、クエリのために生成されたクエリプランが最適化されるとともに高度化されることで、最適化クエリプランまたは高度化クエリプランとして書換えられる。高度化クエリプランは、実行時に、用いるＣＰＵサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。結果として、高度化クエリプランが生成されるクエリは、得られた結果またはクエリされているデータを損なうことなく、より高速で実行される。特定の実施形態では、最適化クエリプランまたは高度化クエリプランはまた、実行時に、用いるメモリリソースがオリジナルの非最適化クエリプランよりも少ない。
特定の実施形態では、オリジナルのクエリプランは、オリジナルのクエリプランにおける１つ以上のファクトスキャンオペレーション／オペレータのセットを識別し、次いで、書換えられた高度化クエリプランにおいて、次元コンテキストをファクトスキャンオペレーションのセットのうちの１つ以上に関連付けることによって最適化される。特定の実施形態では、次元コンテキストは、次元コンテキストに対応する１つ以上の述語条件（次元コンテキスト述語条件とも称される）をファクトスキャンオペレーションに関連付けることによって、ファクトスキャンオペレーションに関連付けられる。ファクトスキャンオペレーションは、ファクトレコードのソース（ファクトソースとも称される）からファクト（ファクトレコードまたはファクト行とも称される）をスキャンするかまたは読取るように構成されたクエリプランにおけるオペレーションである。高度化クエリプランにおける述語条件とファクトスキャンオペレーションとの関連付けはまた、ファクトスキャンオペレーションへの述語条件の伝搬、または、ファクトスキャンオペレーションが動作するファクトソースへの述語条件の伝搬とも称される。関連付けまたは伝搬されているので、高度化クエリプランにおけるファクトレコードのスキャン／読取りおよび／または処理の全体的コストはオリジナルのクエリプランと比較すると非常に少ない。結果として、高度化クエリプランは、実行時に、用いるＣＰＵサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。
特定の実施形態では、クエリプランを最適化するプロセスは、クエリプラン内でどの１つ以上のファクトスキャンオペレーションが述語条件伝搬の候補であるかを識別することと、各々の候補ファクトスキャンオペレーションに関連付けられるべき１つ以上の述語条件を識別することと、さらに、当該関連付けを用いてクエリプランを書換えることとを含み得る。クエリについてのクエリプランは、当該関連付けを用いて実行される。この処理を実行するために、本明細書中に開示される多種多様な技術が用いられてもよい。
多種多様な技術を用いて、ファクトスキャンオペレーションに関連付けられるべき述語条件が識別され得る。たとえば、オリジナルのクエリプランの一部分からの述語条件は、書換えられた高度化クエリプランにおけるクエリプランの別の部分におけるファクトスキャンオペレーションに伝搬されてもよい。一例として、クエリプランの一部分における次元テーブルに適用される次元述語条件が伝搬されて、クエリプランの別の部分におけるファクトスキャンオペレーションに関連付けられてもよい。他のいくつかの事例では、特定の述語条件をファクトスキャンオペレーションに関連付けるのではなく、クエリプラン内の特定の述語条件またはオリジナルの述語条件から新しい述語条件が推論される（特定の述語条件の新しい述語条件への変換またはマッピングとも称される）とともに、新しい述語条件が特定のまたは述語条件ではなくファクトスキャンオペレーションに関連付けられる。新しい述語条件は、新しい述語条件でファクトスキャンオペレーションを実行するコスト（たとえば、実行時間）が特定の述語条件またはオリジナルの述語条件でファクトスキャンオペレーションを実行するコストよりも小さくなるような条件である。いくつかの事例では、クエリにおいて参照されるファクトテーブルからファクトレコードをスキャンするのではなく、ＯＬＡＰインデックス、事前集約された実体化されたビューなどの他の物理的なファクト構造（ファクトソース）がスキャンの実行のために用いられてもよい。
上述したように、高度化クエリプランは、実行時に、用いるＣＰＵサイクルがオリジナルの非最適化クエリプランよりも少ないので、オリジナルのクエリプランよりも高速で実行される。これを達成し得るさまざまな方法がある。場合によっては、クエリプランにおいて述語条件とファクトスキャンオペレーションとが関連付けられていることにより、書換えられたクエリプランによって処理されるファクトレコードの数はオリジナルのクエリプランと比較して低減される。たとえば、述語条件をファクトスキャンオペレーションに関連付けた結果、述語条件を満たすファクトレコードだけがクエリプランにおけるファクトスキャンオペレーションから次の下流オペレーションに提供される。これにより、高度化クエリプランにおける下流オペレーション（たとえば、ファクトテーブルと次元テーブルとの間の結合オペレーション）に提供されるとともに当該下流オペレーションによって処理されなければならないファクトレコードの数が低減される。これにより、高度化クエリプランにおける下流オペレーションの実行に関連付けられた演算オーバーヘッドが低減される。述語条件に基づくファクトレコードのこのフィルタリングにより、クエリプランによるファクトレコードの不要な重複処理が低減される。クエリプランによって処理されるファクトレコードの数が減ると、クエリプランとこれによりクエリプランが生成されるクエリ自体とについて実行時間がより高速になる。クエリプランによって処理されるファクトレコードの数が減ると、書換えられたクエリプランを実行するために用いられるメモリリソースも、より少なくなり得る。上述のように、特定の実施形態では、特定の述語条件から推論されるかまたは変換される新しい述語条件は、特定の述語条件ではなくファクトスキャンオペレーションに関連付けられてもよい。新しい述語条件は、新しい述語条件でファクトスキャンオペレーションを実行するコスト（たとえば、実行時間）が、特定の述語条件でファクトスキャンオペレーションを実行するコストよりも低くなるような条件である。たとえば、特定の述語条件に関連するファクトスキャンオペレーションは実行するのに２秒かかる可能性がある一方で、新しい述語条件に関連する同じファクトスキャンオペレーションは実行するのに１秒しかかからない可能性がある。述語条件を推論または変換することで、高度化クエリプランを非最適化クエリプランよりも高速で実行させる。さらに、特定の実施形態では、より高速の実行時間は、ＯＬＡＰインデックスなどの利用可能な代替的なファクト表現に対して、当該ファクト表現のスキャン能力を活用するようにファクトスキャンを実行することによって達成される。たとえば、何らかの述語「Ｐ」に関してＯＬＡＰインデックススキャンに変換することにより、その組合わせがＯＬＡＰインデックスの迅速な述語評価およびスキップスキャンを活用することができるようになり、結果として、場合によってはファクトスキャン処理が桁違いに低減されることとなる。
性能の観点から、高度化クエリプランは、非高度化クエリプランよりも高速で実行され得るとともに、場合によっては、より少ないリソースを用い得る。本明細書中に開示される教示に基づいて実行されるかなりの数のクエリは、非高度化クエリプランでのクエリよりも１０倍、２５倍、１００倍速く、またはさらに桁違いに高い速度で実行され得る。これは、ファクトテーブルが次元テーブルよりも桁違いに大きく、このため、ファクトレコードの処理に関連するスキャンコストを低減することが、大幅な性能向上につながるからである。たとえば、一例では、アドホッククエリのクエリ実行時間は２０６秒から１６秒に短縮された。クエリは、大きなデータセット（たとえば、テラバイトデータセット）上でサブ秒で実行することができる。
多種多様な情報を用いることで、本明細書中に記載されるクエリプラン最適化が容易になり得る。特定の実施形態では、データベースクエリのために生成されるクエリプランは、クエリの構造、クエリのために生成されるクエリプランの構造、クエリされているデータベースに関連するスキーマ情報、およびクエリプランオプティマイザおよび／またはエンハンサが利用できるセマンティクス情報に基づいて最適化および高度化されてもよい。たとえば、ビジネスセマンティクスまたはビジネスインテリジェンス（business intelligence：ＢＩ）セマンティクス情報を用いて、クエリプランを書換えてもよい。セマンティクス情報は、実世界のプロセス、組織構造などに基づいてリッチ値および構造セマンティクスを有するビジネスデータを含み得る。セマンティクス情報は、データ中のビジネス階層および機能依存性のようなビジネスモデルについての情報を含み得る。たとえば、依存性情報は、データベースデータのさまざまなフィールド（たとえば、列）間の関係（たとえば、階層的または非階層的）を記述する情報を含み得る。たとえば、依存性メタデータは、「市」列の値と「州」列の値との間の階層関係を記述する情報（たとえば、サンフランシスコはカリフォルニアという州内の市である）を含み得る。階層の例は、時間の階層（たとえば、日、週、月、四半期、年など）、地理的階層（たとえば、市、州、国）などを含む。セマンティクス情報は、データキューブモデルセマンティクス情報を含み得る。特定の実施形態では、クエリプランの高度化のために用いられるメタデータは、分析されているデータが如何に物理的に格納されているかについての情報と、データ間の関係を識別する論理情報とを含み得る。特定の実施形態では、セマンティクス情報は、いかなるユーザ入力もなしに、分析されているデータを格納するデータベースの構造およびスキーマについての情報を分析することによって判断されてもよい。このような分析から導き出される推論は、最適化されるとともに高度化されたクエリプランを生成するようにクエリプランを書換えるために用いられてもよい。
たとえば、クエリのために生成されたクエリプランは、ファクトソースに対するファクトスキャンオペレーションを識別するために分析されてもよい。次いで、セマンティクス情報（たとえば、ファクトおよび次元コンテキストテーブルの結合オペレーション、データベースの列間の機能依存性、ファクトの物理的実体化）を用いて、書換えられた最適化クエリプランにおけるファクトスキャンオペレーションについての次元コンテキスト条件を能動的に識別してプッシュし得る。これは、書換えられたクエリプラン内のファクトレコードを処理するのに必要なコスト（たとえば、時間）の大幅な削減につながる。したがって、書換えられたクエリプランはより高速で実行される（たとえば、より少ないＣＰＵサイクルを用いる）とともに、多くの場合用いるメモリリソースが非最適化クエリプランよりも少ないくなり得る。これにより得られるクエリについては、より高速で実行されるとともに場合によってはより少ないメモリリソースを用いるクエリプランが生成されることとなる。
図１Ａは、例示的な実施形態を組込んだ分析プラットフォームまたはインフラストラクチャ１００の簡略ブロック図である。分析プラットフォーム１００は、１つ以上の通信ネットワークを介して互いに通信可能に連結された複数のシステムを含み得る。図１Ａのシステムは、１つ以上の通信ネットワークを介して互いに通信可能に連結された処理システム１５０およびストレージシステム１０６を含む。通信ネットワークは、図１Ａに示すさまざまなシステム間の通信を容易にし得る。通信ネットワークは、さまざまなタイプのネットワークであり得るとともに、１つ以上の通信ネットワークを含み得る。このような通信ネットワークの例は、インターネット、ワイドエリアネットワーク（wide area network：ＷＡＮ）、ローカルエリアネットワーク（local area network：ＬＡＮ）、イーサネット（登録商標）ネットワーク、パブリックまたはプライベートネットワーク、有線ネットワーク、無線ネットワークなど、およびこれらの組合わせを含むが、これらに限定されない。ＩＥＥＥ８０２．ＸＸプロトコルスイート、ＴＣＰ／ＩＰ、ＳＡＮ、Apple Talk（登録商標）、Bluetooth（登録商標）、および他のプロトコルなどの有線プロトコルおよび無線プロトコルの双方を含むさまざまな通信プロトコルを用いて通信を容易にしてもよい。通信ネットワークは、図１Ａに示すさまざまなシステム間の通信を容易にする任意のインフラストラクチャを含み得る。
図１Ａに示す分析プラットフォーム１００は、単なる一例にすぎず、主張される実施形態の範囲を必要以上に限定することを意図するものではない。プラットフォームは、クエリされているデータのサイズの変化および作業負荷の変化（たとえば、並列またはそれ以外の態様で実行されているクエリの数）に対処するために必要に応じて弾性的にスケールアウトすることができる。当業者であれば、多くの実現可能な変形例、代替例および変更例を認識するであろう。たとえば、いくつかの実現例では、分析プラットフォーム１００は、図１Ａに示されるよりも多いかもしくは少ないシステムもしくはコンポーネントを有していてもよく、２つ以上のシステムを組合わせてもよく、または、異なる構成または配置のシステムを有していてもよい。さらに、図１Ａに示されるとともに本明細書中に説明されるインフラストラクチャは、スタンドアロンまたはクラスタの実施形態を含む多種多様な環境において、オンプレミスまたはクラウド環境（プライベート、パブリックおよびハイブリッドのクラウド環境を含むさまざまなタイプのクラウドであり得る）、オンプレミス環境、ハイブリッド環境など、として実現され得る。
特定の実施形態では、分析またはクエリされるべきデータは、ストレージシステム１０６によって格納されてもよい。ストレージシステム１０６に格納されるデータは、１つまたは複数のデータソースから得られてもよい。データは、コンピューティングノード上のディスクにおけるように、オブジェクト店舗、ブロック店舗、ただのディスクの束（ｊｂｏｄ）など、およびそれらの組合わせなどのさまざまな形態で編成および格納され得る。ストレージシステム１０６は、データを格納するための揮発性メモリおよび／または不揮発性メモリを備えてもよい。たとえば、ストレージシステム１０６は、分析されるべきビジネスデータを格納するデータベースを含み得る。ビジネスデータは一般に多次元であり、セマンティックにリッチである。ストレージシステム１０６は、データを維持する物理的ストレージコンポーネント（たとえば、回転ハードディスク、ＳＳＤ、メモリキャッシュなど）を含む分析プラットフォーム１００のストレージ層を表すとともに、特定のクエリ作業負荷に最適に役立つ態様でリレーショナルデータ／空間データ／グラフデータを格納するための無数のデータ構造を提供するソフトウェアも含む。ストレージシステム１０６内のデータは、すべて１つの場所に配置されている必要はなく、分散して格納されていてもよい。データは、データレーキ、データウェアハウス、Ｈａｄｏｏｐクラスタなどのさまざまなストレージ／コンピューティング環境において編成および格納され得る。
ストレージシステム１０６および処理システム１５０のメモリリソースは、システムメモリおよび不揮発性メモリを含み得る。システムメモリは、１つ以上のプロセッサのためのメモリリソースを備えてもよい。システムメモリは、典型的には揮発性ランダムアクセスメモリ（random access memory：ＲＡＭ）（たとえば、ダイナミックランダムアクセスメモリ（dynamic random access memory：ＤＲＡＭ）、シンクロナスＤＲＡＭ（Synchronous DRAM：ＳＤＲＡＭ）、ダブルデータレートＳＤＲＡＭ（Double Data Rate SDRAM：ＤＤＲ ＳＤＲＡＭ））の形態である。オペレーティングシステムに関連する情報および１つ以上のプロセッサによって実行されるアプリケーションまたはプロセスはシステムメモリに格納され得る。たとえば、実行時、オペレーティング・システム／カーネルをシステムメモリにロードしてもよい。加えて、実行時、サーバコンピュータによって実行される１つ以上のアプリケーションに関連するデータがシステムメモリにロードされ得る。たとえば、サーバコンピュータによって実行されているアプリケーションがシステムメモリにロードされて、１つ以上のプロセッサによって実行されてもよい。サーバコンピュータは複数のアプリケーションを並列に実行可能であってもよい。
不揮発性メモリを用いて、持続すべきデータを格納してもよい。不揮発性メモリは、ハードディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、ソリッドステートドライブまたはディスク（ＳＳＤ）、ＵＳＢフラッシュドライブ、メモリカード、メモリスティック、テープカセット、ジップカセット、コンピュータハードドライブ、ＣＤ、ＤＶＤ、ネットワーク接続ストレージ（network-attached storage：ＮＡＳ）、ストレージエリアネットワーク（storage area network：ＳＡＮ）を介して提供されるメモリストレージなどのさまざまな形態を取る可能性もある。いくつかの事例では、アプリケーションがサーバコンピュータに配備されるかまたはサーバコンピュータにインストールされるとき、アプリケーションに関連する情報が不揮発性メモリに格納されてもよい。
特定の実施形態では、ストレージシステム１０６内のデータは、１つ以上のスタースキーマとして論理的に構造化されるテーブル内の関係データベースに格納され得るか、または、多次元アレイ（一般に多次元キューブとも称される）などの専用ストレージ構造を備えたシステムに格納され得る。スタースキーマは、任意の数の次元テーブルを参照する中央ファクトテーブルを含む。各ファクトテーブルは、ファクトレコードの形でファクトまたはメトリックを格納する。ファクトテーブルは、ファクトをそれらのコンテキストに関連付ける次元テーブルにリンクされ得る。次元テーブルは、ファクトテーブル行に格納されたメトリックデータを記述するコンテキスト情報を格納している。ファクトテーブルは通常多くの次元に関連付けられているので、構造は図式的に星のように見え、このためそのような名称が付けられている。一般に、ファクトの数と一意の次元値の数との間に桁違いの差があり、ファクトの数が次元の数を大幅に上回っている。たとえば、企業の場合には何億もの販売ファクトレコードがあり得るが、販売されている店舗、州などのわずか数次元（たとえば、数千）の場合もある。結果として、ファクトテーブルのサイズは一般に非常に大きく、次元テーブルよりも桁違いに大きい。
スタースキーマという語は、ここでは、多くの次元テーブル行を有するファクト行間の論理関係を取込むために、その最も一般的な形態で用いられる。このため、スノーフレークスキーマのような変形例がまた、示唆されるともに本開示で用いられるスタースキーマという語の下に含まれる。スノーフレークスキーマは、ファクト行と次元との間の関係が間接的であり得る（直接的な関連付け以上のものを必要とする；たとえば、販売ファクト行は顧客・アドレス行にリンクする顧客行にリンクする）点でスタースキーマと区別される。
分析データを調べる別の方法としてｎ次元キューブがある。典型的な分析では、この大規模な多次元空間のいくつかの任意の部分空間（スライスとも称される）に焦点を合わせる。特定の任意の分析の焦点は、複数の次元および活動にわたり得るとともに、複数のステップを有し得るとともに、エンティティとそれらの活動との間に任意のリンクを含み得る。リレーショナルワールドでは、データキューブはスタースキーマとしてモデル化され得る。
リレーショナルデータベースにおいて、イベントまたはトランザクション（たとえば、製品の販売）は、多くの次元テーブルに結合する大きなファクトテーブルに取込まれてもよい。分析ソリューションは、ファクトテーブルが共通の次元セットを有する多くのこのようなスタースキーマを含み得る。図４は、店舗への返品のためのトランザクションに関連するデータに対応する例示的なスタースキーマ４００を示す。スキーマ４００は、店舗返品トランザクションを取込むとともに、ファクトレコードと次元レコードとの間の１対多の関係を記述する。図４に示されるスキーマ４００によれば、Store_Returnは、店舗返品トランザクションに関連するメトリック情報を含むファクトレコードを格納する（強調された境界線を用いて示される）ファクトテーブルであり、他のテーブル（Date（日付）、Store（店舗）、Item（商品）、Customer（顧客）、Customer_Address）は、ファクトレコードについてのコンテキスト情報を格納する次元テーブルである。各々の返品トランザクションは、店舗識別子、市および州を含む返品がなされた店舗についての情報と、商品を復帰した顧客についての情報と、トランザクションの時間情報（月、日、年）とを含む関連付けられたコンテキストと共に記録される。スタースキーマ４００は、店舗への返品が、Date（日付け）、Customer（顧客）、Item（商品）、Store（店舗）およびCustomer_Addressの次元レコードによって次元化され、Store_Returnsファクトレコードと結合され得ることを示す。
図２は、ファクトテーブル２０２と、図４に示されるスタースキーマ４００に対応するファクトテーブル２０２にそれぞれ関連する複数の次元テーブル２０４〜２０８とを備える例示的なデータベースデータ２００を示す。ファクトテーブル２０２は、テーブル２０４の一次キー列２１８、テーブル２０６の一次キー列２２６、およびテーブル２０８の一次キー列２３０とそれぞれ結合して、行ではなく列をファクトテーブル２０２に追加することができる外部キー列２１０、２１２および２１４を含む。図２は、データベースデータ２００をテーブルとして示しているが、当該データベースデータ２００がインデックス、実体化されたビューおよび／またはタプルの他の任意のセットとして表現され得ることが認識されるはずである。
図２の例では、ファクトテーブル２０２はさらに、ファクトメトリック列２１６（return_amt）を格納するファクトレコードを含む。外部キー列２１０、２１２および２１４は、次元列２２０、２２２、２２４、２２８、２３２および２３４などの１つ以上の次元列の観点からファクトメトリック列２１６を分析することを可能にする。一般に、図２に示されるように、典型的には、次元レコードよりも多くのファクトレコードが存在する。たとえば、ファクトレコードの数は数百万になり得る一方で、次元レコードの数は数千となり得る。
処理システム１５０は、ストレージシステム１０６によって格納されたデータの分析を可能にするように構成されてもよい。分析は、ＳＱＬクエリなどの分析クエリを用いて実行されてもよい。処理システム１５０は１つ以上のクエリ１３０を受信するように構成されてもよい。特定の使用事例において、クエリ１３０は、処理システム１５０によって提供されるインターフェイスを用いてユーザによって入力され得る。他の場合、クエリ１３０は、他のアプリケーション、システムまたはデバイスから処理システム１５０によって受信されてもよい。いくつかの使用事例において、処理システム１５０はそれ自体のクエリを生成し得る。
特定の実施形態では、クエリに対して、処理システム１５０は、クエリに対する高度化クエリプランを生成するように構成される。以下においてより詳細に説明される多種多様な技術を用いて、高度化クエリプランが生成され得る。次いで、処理システム１５０は、ストレージシステム１０６によって格納されたデータに対して高度化クエリプランを実行し、結果セットを生成し得る。次いで、処理システム１５０は、結果セットを、受信されたクエリに対する応答として出力し得る。
図１Ａに示される実施形態と同様に、リレーショナルデータベース内のファクトソースからファクトを非常に高速でスキャン／読取りするために、ＯＬＡＰインデックス付け１２６（たとえば、ＯＬＡＰインデックス）が提供されてもよい。特定の実施形態では、処理システム１５０は、ＯＬＡＰインデックス１２６のうち１つ以上を生成するように構成されてもよい。
特定の実施形態では、図１Ａに示す分析プラットフォーム１００は、１つ以上のコンピュータのクラスタ上で実行され得る。たとえば、分析プラットフォーム１００は、Ａｐａｃｈｅ ＳｐａｒｋまたはＡｐａｃｈｅ Ｈａｄｏｏｐによって提供される分散型コンピューティングフレームワークを用いて実現されてもよい。各コンピュータは、１つ以上のプロセッサ（または中央処理ユニット（central processing unit:ＣＰＵ））、メモリ、記憶装置、ネットワークインターフェイス、Ｉ／Ｏデバイスなどを備え得る。このようなコンピュータの例が図１６に示されるとともに以下に説明される。１つ以上のプロセッサは、シングルコアまたはマルチコアのプロセッサを備え得る。１つ以上のプロセッサの例は、関連メモリに格納されたソフトウェアの制御下で動作する、Intel（登録商標）、AMD（登録商標）、ARM（登録商標）、Freescale Semiconductor、Inc.などによって提供されるような汎用のマイクロプロセッサを含み得るが、これらに限定されない。分析プラットフォーム１００のソフトウェアコンポーネントは、オペレーティングシステム上のアプリケーションとして動作してもよい。サーバコンピュータによって実行されるアプリケーションは１つ以上のプロセッサによって実行され得る。
処理システム１５０によって生成される高度化クエリプランの結果として、高度化クエリプランが生成されるクエリの実行がより高速にされる。これにより、クエリのための応答時間がより高速となる。これらの高速の応答時間は、分析されている結果またはデータを損なわずに、対話的に、ストレージシステム１０６に格納された多次元データの分析を可能にする。対話型クエリは、たとえば、機械学習技術、クリックストリームおよびイベント／時系列に関連付けられたデータに対して、より一般的には、サイズおよび複雑さが急速に増大する可能性のある任意のデータセットに対して、実行されてもよい。
さらに、クエリは、ストレージシステム１０６内のデータベースに格納されたデータに対して直接実行されるが、事前集約されたデータに対しては実行されない。したがって、クエリは、事前集約データまたは抽出物を作成する必要なしに、所定の位置で大きなデータセットに対して実行することができる。代わりに、クエリは実際の元の生データ自体に対して実行され得る。特定の実施形態では、クエリは、本明細書中で説明するとおり、述語条件を用いるとともに、完全分散型演算エンジンでのメモリ内ＯＬＡＰインデックスを用いることによって、より高速で行われる。これにより、分析プラットフォーム１００が、事前集約されたデータに対して実行することができないアドホッククエリを促進することが可能となる。アドホッククエリは、事前に定義されていないクエリである。アドホッククエリは、一般に、情報が利用可能になると当該情報を分析するために作成される。本明細書で説明される分析プラットフォーム１００は、非常に大きな（テラバイト以上の）多次元データ（たとえば、データレーキに格納されたデータ）に対して対話型アドホッククエリを、非常にコスト効率良く、実行する能力を提供する。従来の技術を用いて過去に非常に大きな（テラバイト以上の）多次元データに対してこのような対話型アドホッククエリを実行することは、法外な費用がかかるものであって、スケーリングしていなかった。
さらに、Ａｐａｃｈｅ Ｓｐａｒｋを用いる分析プラットフォームの実装により、本質的に、クエリを大規模に実行することが可能になる。コンピュータおよびストレージ（たとえば、新しいデータが分析のために利用可能である）が独立してスケーリング可能である弾性環境が提供される。
分析プラットフォーム１００では、クエリされるべきデータは、１つ以上のさまざまな分析ツールを用いて分析することができる中央位置に格納されている。さまざまなツールにより可能化すべきデータを固有に準備する必要はない。さまざまなユーザが、PythonまたはRを実行するZeppelinまたはJupyterノートブック、TableauのようなＢＩツール等を含む選択されたツールでデータにアクセスすることができる。
大量の多次元データの場合、対話型のクエリを大規模に実行することは困難である。これは、対話型のクエリが高速の応答時間を必要とするからである。大量の多次元データの場合、データの量（たとえば、テラバイトのデータ）が増加するにつれて、かつデータセットにアクセスしようとするユーザの数が増加するにつれて、クエリ性能が低下する。さらに、ファクトテーブルと次元テーブルとの間の結合は、付加的な性能ボトルネックを引起こす可能性がある。これまで、この問題を軽減するために事前集約技術が用いられてきた。多次元データの分析を容易にするために、たとえば、ＯＬＡＰキューブ、抽出物、および実体化された事前集約型テーブルが用いられてきた。
事前集約されたデータ（集約データまたは集約物とも称する）は、１つ以上の事前集約（または集約）技術を用いていくつかの基礎となるデータ（元データまたは生データと称する）から生成されたデータである。データ集約または事前集約技術は、データが集計形式で表現される任意のプロセスを含む。事前集約されたデータは、予め演算されたデータまたは集計されたデータを含み得るとともに、事前集約されたテーブル、抽出物、ＯＬＡＰキューブなどに格納され得る。ファクトが集約される場合、これは次元性を排除することによって、またはファクトをロールアップされた次元に関連付けることによって行われる。したがって、事前集約されたデータは、事前集約されたデータ生成の基となる元データまたは生データからの詳細をすべて含むわけではない。
しかしながら、事前集約はいくつかの欠点を有する。すべての事前集約技術は粒度の損失をもたらす。事前集約では、特定の予め定められた事前集約物だけが提供されるので、データの詳細が失われてしまう。たとえば、元データセットまたは生データセットは販売情報を日単位で記録し得る。このデータに対して月単位の事前集約が実行されると、日単位または日ごとの情報が失われてしまう。すべての次元およびメトリックからなるすべての組合わせに対して事前集約データセットまたはキューブを構築することは非現実的である。このように、事前集約はアドホックのクエリを実行する能力を制限してしまう。なぜなら、より高いレベルの事前集約された集計（たとえば、１月当たりの情報）の背後にあるキー情報（たとえば、１日当たりの情報）が利用できないからである。クエリは事前集約されたデータに対して実行されるが、事前集約の生成の基となった元データまたは生データに対して実行されるものではない。したがって、集約は、分析が実行され得るグレインを変化させる。ファクトのグレインは、イベントが記録される最低レベルを指している。たとえば、製品の販売は、販売時間およびタイムスタンプを用いて記録されてもよい。販売の集約は、チャネルおよび製品ごとの収入、またはカテゴリ、製品、店舗、州ごとの収入など、複数のレベルにわたってなされてもよい。複数の粒度および次元でデータを調査する能力が重要となる。事前集約のための正しい粒度は予め予測するのが困難である。したがって、事前集約されたキューブおよび実体化された集計テーブルは、ビッグデータ分析の場合には上手く機能しない。
分析プラットフォーム１００によれば、事前集約ベースの分析技術に関連付けられたさまざまな欠点が回避される。分析プラットフォーム１００は、大規模かつ高速でさまざまな粒度および寸法の多次元データのデータ分析を実行するためのフレームワークを提供する。
本願の目的のために、「事前集約されていないデータ」という語は、事前集約されたデータまたは事前演算されたデータを含まないデータを指すのに用いられる。特定の実施形態では、分析プラットフォーム１００は、ストレージシステム１０６に格納された事前集約されていないデータに対してクエリが実行されることを可能にする。これにより、ストレージシステム１０６に格納された事前集約されていないデータに対してアドホックのクエリを行うことが可能となる。加えて、処理システム１５０によって提供されるクエリプランが高度化されているので、クエリのための応答時間が劇的に減少し、これにより、対話型クエリの実行が可能となる。本明細書に記載される分析プラットフォーム１００は、非常に大きな（テラバイト以上の）多次元データ（たとえば、データレーキに格納されたデータ）に対して対話型アドホッククエリを、非常にコスト効率良く、実行する能力を提供する。従来の技術を用いて過去に非常に大きな（テラバイト以上の）多次元データに対してこのような対話型アドホッククエリを実行することは、法外な費用がかかるものであって、スケーリングしていなかった。
図１Ｂは、特定の実施形態に従った、図１Ａに示す分析プラットフォーム１００のより詳細な図を示す簡略ブロック図である。図１Ｂに示す分析プラットフォーム１００は、単なる一例にすぎず、限定するように意図されるものではない。当業者であれば、多くの実現可能な変形例、代替例および変更例を認識するであろう。たとえば、いくつかの実現例では、データ分析プラットフォーム１００は、図１Ｂに示されるよりも多くのコンポーネントもしくは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組合わせてもよく、または、異なる構成または配置のコンポーネントを有していてもよい。さらに、図１Ｂに示されるとともに本明細書中に説明されるインフラストラクチャは、スタンドアロンの実施形態を含む多種多様な環境、クラウド環境（プライベート、パブリック、ハイブリッドのクラウド環境を含むさまざまなタイプのクラウドであり得る）、オンプレミス環境、ハイブリッド環境などで、実現され得る。
図１Ｂの例では、図１Ａに示す処理システム１５０は、データ分析システム１０２およびデータベース管理システム（ＤＢＭＳ）１０４を備える。データ分析システム１０２およびデータベース管理システム（ＤＢＭＳ）１０４は互いに、かつストレージシステム１０６にも通信可能に連結され得る。いくつかの実施形態では、データ分析システム１０２、ＤＢＭＳ１０４、およびストレージシステム１０６は、ＯＬＡＰデータベースシステムのさまざまな論理層を表わし得る。いくつかの実施形態では、データ分析システム１０２、ＤＢＭＳ１０４、およびストレージシステム１０６は物理的に別個のシステムであり得る。他の実施形態では、これらは１つのシステムに組合わされてもよい。ＤＢＭＳ１０４およびデータ分析システム１０２はともに、ビジネスインテリジェンス技術をＡｐａｃｈｅ Ｓｐａｒｋの能力と組合わせる強力な分析プラットフォームを提供する。
ストレージシステム１０６は、分析されるべきデータをファクトテーブルおよび次元テーブルに格納し得る。図１Ｂに示されるように、ファクトテーブル１２４、ＯＬＡＰインデックス１２６、実体化されたビュー１２８および／または他のソースを含むファクトレコードの複数のソース１０８が存在し得る。ファクトテーブル１２４は１つ以上の行および１つ以上の列を備え得る。この場合、各々の行はファクトレコードを表わし得るとともに、列はレコードのフィールドを表わし得る。いくつかの実施形態では、ストレージシステム１０６は、環境１００内で分散および／または仮想化されてもよい。
ストレージシステム１０６はまた、１つ以上の次元レコードを格納する１つ以上の次元テーブル１１０として、ファクトレコードに関連付けられたコンテキストを格納し得る。典型的には、ファクトレコードは、次元テーブル１１０内の次元レコードに関して分析することができるメトリックの値を格納する。たとえば、ファクトレコードは売上高を含み得るとともに、次元レコードは日付け値を含み得る。この日付け値に従って、売上高が集約、フィルタリングまたは分析され得る。ファクトレコードソース１０８（たとえば、ファクトテーブル、ＯＬＡＰインデックス、および実体化されたビュー）ならびに次元テーブル１１０およびレコードについては以下でより詳細に説明する。
ストレージシステムはメタデータ１０９を格納し得る。メタデータ１０９は、テーブル、列、ビューなどのリレーショナルアーチファクトについての情報を含み得る。
図１Ｂの例では、ストレージシステム１０６は、スキーマ情報１１６および統計情報１１２などのデータベース管理システムに関連付けられた他の情報をさらに格納し得る。スキーマ情報１１６は、データベースに関連付けられたテーブル、インデックスおよび他のアーチファクトの構造を識別し得る。たとえば、スタースキーマの場合、スキーマ情報１１６は、ファクトレコードと次元レコードとの間の関係を記述する情報を含み得る。たとえば、スキーマ情報１１６は、販売データが時間次元および地理的領域次元に従って問合わされ得ることを判断するために用いられてもよい。特定の実施形態では、スキーマ情報１１６は、ドメインエキスパートまたはアナリストによって定義されてもよい。スキーマ情報１１６は、図４および図９に示されるスキーマなどのスタースキーマを定義し得る。
統計１１２は、ファクトレコードまたは次元レコードについての情報、ならびにデータベース管理システム１０４のクエリプランおよび性能関連属性に関する他の情報を含み得る。たとえば、統計１１２は、テーブルレベル統計（たとえば、テーブル中の行の数、テーブルのために用いられるデータブロックの数、もしくはテーブルの平均行長）および／または列レベル統計（たとえば、列中の別個の値の数、または列中に発見される最小値／最大値）を含み得る。
ＤＢＭＳ１０４は、１つ以上のデータベースを作成すること、データベースにデータを追加すること、データベースに格納されたデータを更新および／または削除すること、ならびに、データベースおよび格納されたデータを管理することに関連する他の機能、を可能にする機能を提供するように構成され得る（たとえば、１つ以上のプロセッサによって実行されたときに機能を可能にするソフトウェアを備え得る）。ＤＢＭＳ１０４はまた、ストレージシステム１０６に格納されたデータを分析するための１つ以上のクエリ１３０を受信し、クエリに対応する分析を実行し、クエリ結果１３２を出力するように構成され得る。クエリ１３０は、構造化クエリ言語（Structured Query Language：ＳＱＬ）などのさまざまな形態および言語であってもよい。
クエリ１３０は、ＤＢＭＳ１０４のユーザなどの１つ以上のソースや別のシステムなどから受信され得る。たとえば、図１Ｂに示される実施形態では、特定の事例において、クエリは、データ分析システム（data analytics system：ＤＡＳ）１０２から受信されてもよい。ＤＡＳ１０２は、ストレージシステム１０６に格納されたデータの分析を実行するように構成され得る。ＤＡＳ１０２は、ストレージシステム１０６によって格納されたデータに対してＤＢＭＳ１０４によって実行される分析クエリを生成するように構成されたソフトウェアを含み得る。たとえば、ストレージシステム１０６が販売レコードを格納している場合、ＤＡＳ１０２は、販売レコードを分析するためのクエリ（たとえば、販売傾向を分析するためのクエリ、広告キャンペーンを分析するためのクエリ、およびビジネス活動に関する見通しを得るかまたは有用なパターンを抽出するための他のクエリ）を生成して、ＤＢＭＳ１０４に送信してもよい。特定の実施形態では、ＤＡＳ１０２は、分析クエリを生成するために、ストレージシステム１０６に格納された情報（たとえば、スキーマ情報１１６）を用い得る。たとえば、スタースキーマ１１６を用いて、販売データが時間次元および地理的領域次元に従って問合わせされ得ることを判断してもよい。ＤＡＳ１０２から受信したクエリに対応するとともにＤＢＭＳ１０４によって検索された結果は、ＤＢＭＳ１０４によってＤＡＳ１０２に提供され得る。
図１Ｂに示されるように、ＤＢＭＳ１０４は、クエリ１３０を受信するためのインターフェイス１２２を提供し得る。パーサ１２０は、受信されたクエリの構文分析およびセマンティックス分析を実行するように構成され得る。たとえば、ＳＱＬクエリの場合、パーサ１２０は、クエリ中のＳＱＬステートメントが正しい構文であるかどうかチェックするとともに、クエリ中で参照されるデータベースオブジェクトおよび他のオブジェクト属性が正しいかどうかをチェックするように構成され得る。
クエリが、パーサ１２０によって実行される構文チェックおよびセマンティックチェックにパスした後、オプティマイザ１１４は、クエリを効率的に実行するためのクエリプランを決定するように構成され得る。オプティマイザ１１４は、クエリを最適に実行するためのクエリプランを出力し得る。特定の実施形態では、実行プランは、実行されるべきオペレーション／オペレータの連なりまたはパイプラインを含む。実行プランは、個々のオペレーション／オペレータを表すツリーまたはグラフのノードを備えたルートツリーまたはグラフによって表されてもよい。クエリプラングラフは、一般に、グラフのリーフから始まってルートに向かって進むように実行される。クエリプランのリーフは、典型的には、ファクトレコードまたは行がファクトテーブルなどのファクトソースからスキャンまたは読取られるファクトスキャンオペレーションを表す。クエリプランにおける任意のリレーショナルオペレータの出力は、演算されたデータセットである。クエリプランにおけるオペレーションによって返される演算されたデータセット（たとえば、行またはレコードのセット）は、クエリプランパイプラインにおける次のオペレーション（親オペレーションまたは下流オペレーションとも称される）への入力として提供され、次のオペレーションによって消費される。クエリプランパイプラインにおける最後のオペレーション（クエリプラングラフのルート）において、ファクト行がＳＱＬクエリの結果として返される。したがって、クエリプランにおける特定のオペレーションによって返される行は、クエリプランパイプラインにおける次のオペレーション（特定のオペレーションの親オペレーションまたは下流オペレーション）への入力行となる。オペレーションによって返される行のセットはしばしば行セットと称され、行セットを生成するクエリプラン内のノードは行ソースと称される。したがって、クエリプランは、あるオペレーションから別のオペレーションへの複数の行ソースの流れを表す。クエリプランの各オペレーションは、データベースから行を検索するか、または１つ以上の他の子オペレーションもしくは上流オペレーション（もしくは行ソース）から行を受け入れる。
特定の実施形態では、オプティマイザ１１４は、クエリプランを生成するためにコストベースの最適化を実行し得る。いくつかの実施形態では、オプティマイザ１１４は、Ｉ／Ｏ、ＣＰＵリソース、およびメモリリソース（最適なスループット）を含む最小量のリソースを用いてクエリを実行することができる、クエリのためのクエリプランを生成しようとしてもよい。オプティマイザ１１４は、クエリプランを生成するために、ファクトソース１０８、スキーマ情報１１６、ヒント、および統計１１２についての情報などのさまざまな情報を用いてもよい。特定の実施形態では、オプティマイザ１１４は、潜在的なプランのセットを生成し、各プランに対するコストを推定し得る。この場合、プランのためのコストは、プランを実行するのに必要な予想されるリソース使用に比例する推定値である。プランのためのコストは、アクセス経路、プランにおけるオペレーション（たとえば、結合オペレーション）に基づいていてもよい。アクセス経路は、データがデータベースから検索される手段である。ファクトテーブル内の行またはレコードは、フルテーブルスキャン（たとえば、スキャンによって、ファクトテーブル内のすべての行／レコードが読取られ、選択基準を満たさないものがフィルタリングによって除去される）により、インデックス（たとえば、インデックス付けされた列値を用いて、インデックスを詳細に検討することによって行が検索される）を用いて、実体化されたビューまたは行ｉｄ（rowid）スキャンを用いて、検索され得る。次いで、オプティマイザ１１４は、プランのコスト同士を比較し、最低コストのプランを選択し得る。
特定の実施形態では、エンハンサ１０３は、オプティマイザ１１４によって選択されたクエリプランをさらに高度化／最適化し、高度化されて最適化されたクエリプランを生成するように構成される。エンハンサ１０３によって生成される高度化クエリプランはオプティマイザ１１４によって生成されるクエリプランよりも優れている。なぜなら、この高度化クエリプランは、非高度化クエリプランよりも高速で実行されるとともに、多くの場合、非高度化クエリプランよりも少ないメモリリソースを使用し得るからである。
エンハンサ１０３によって生成された最適化された高度化クエリプランは、次いで、ストレージシステム１０６に格納されたデータに対してクエリプランを実行するように構成されたエグゼキュータサブシステム１０５に提供されてもよい。エンハンサ１０３から受信されたクエリプランを実行することによりエグゼキュータ１０５によって得られた結果は、次いで、入力クエリに対する結果応答としてＤＢＭＳ１０４によって返されてもよい。エグゼキュータ１０５は実行時プロセスの実行層を表わしている。実行時プロセスの実行層は、実行時プロセスに提供された高度化クエリプランに基づいてクエリを処理する。これらは、データタプルストリームに対して動作するとともにこれらを特定の方法で変換するオペレータ／オペレーションの実現例（たとえば、SQL、Graph、Spatialなど）を含み得る。
エンハンサ１０３は、オプティマイザ１１４によって生成されたクエリプランから高度化クエリプランを生成するためにさまざまな技術を用い得る。特定の実施形態では、エンハンサ１０３は、ＤＡＳ１０２によって格納されるメタデータ／セマンティクス情報１１７を用いて、オプティマイザ１１４によって生成されるクエリプランをさらに最適化および高度化し得る。たとえば、スタースキーマのために利用可能な（たとえば、スタースキーマセマンティックモデルからの）セマンティクス情報に基づいて、エンハンサ１０３は、オプティマイザ１１４によって生成されるクエリプラン中の、ファクトレコードのソースのスキャンオペレーション中に適用可能である次元コンテキスト／述語条件を推論するように構成されてもよい。この推論された情報は、オプティマイザ１１４によって生成されたクエリプランをさらに最適化するためにエンハンサ１０３によって用いられてもよい。特定の実施形態では、エンハンサ１０３は、（たとえば、スタースキーマまたはキューブのセマンティックモデルにおける）セマンティックデータにおいて定義されたフィールド／列機能依存を利用して、ファクトレコードのソースに対するスキャンオペレーションについての適用可能な述語条件として、推論された次元コンテキスト／述語を変換する方法を実行する。いくつかの事例では、エンハンサ１０３は、インデックス内のデータ構造を活用するファクトレコードのインデックスソース（たとえば、ＯＬＡＰインデックスファクトソース）についての、推論された次元コンテキスト／述語条件を適用してもよい。
一般に、本願の目的のために、ファクトソースという語は、ファクトレコードのソースを指すために用いられる。ファクトソースは、（たとえばファクトレコードの）ファクトのソースである任意の関係であり得る。ファクトソースは、元ファクトテーブルまたは複数ファクトについての他の何らかの実体化であり得る。一般的な実体化技術は、事前集約されたビューおよびキューブ表現、たとえばＯＬＡＰインデックスなどを含む。たとえば、ファクトソースは、ファクトテーブル（たとえば、スタースキーマに基づくリレーショナルデータベースにおけるファクトテーブル）、インデックス（たとえば、多次元空間の任意のサブ領域についてのファクトに直ちにアクセスする能力を提供する事前結合インデックスなどの、スタースキーマまたはキューブ上のＯＬＡＰインデックス）、または、実体化されたビュー（たとえば、スタースキーマのための何らかの集約レベルでの実体化されたビュー）であり得る。ファクトソースは、ファクトレコード（たとえば、ビジネスファクト）のソースである任意のデータセットまたはテーブルを表す。ファクトは特定の次元グレインであり得る。
上述したように、エンハンサ１０３は、次元コンテキスト／述語条件を推論するためにメタデータ／セマンティクス情報１１７を用い得る。セマンティクス情報１１７は、ビジネスインテリジェンス情報を含み得る。たとえば、セマンティクス情報１１７は、実世プロセス、組織構造、キューブ情報などに基づくリッチ値および構造セマンティクスを有するビジネスデータを含み得る。セマンティクス情報は、データ中のビジネス階層および機能依存性のようなビジネスモデルに関する情報を含み得る。この階層および依存性情報は、高度化クエリプランを生成するためにエンハンサ１０３によって用いられ、結果として、クエリの実行が高速化されることとなる。たとえば、依存性メタデータ情報は、データベースデータのさまざまなフィールド（たとえば、列）間の関係（たとえば、階層的または非階層的）を記述する情報を含み得る。たとえば、依存性メタデータは、「市」フィールド列の値と「州」フィールド列の値との間の階層関係を記述する情報（たとえば、サンフランシスコはカリフォルニアという州の市である）を含み得る。エンハンサ１０３は、クエリサブプランの結果の粒度と共に依存性メタデータを用いて、クエリサブプラン内のファクトソーススキャンに関する述語条件適用性を推論してもよい。特定の実施形態では、セマンティクス情報は、ユーザ入力なしに、クエリによって分析されているデータを格納するデータベースの構造およびスキーマに関する情報を分析することによって判断されてもよい。
クエリプランを高度化するためにエンハンサ１０３によって用いられるセマンティクス情報は、複数のソースから利用可能であり得るかまたは確認され得る。一例として、セマンティクス情報は、ビジネスインテリジェンス（ＢＩ）データソースから利用可能であり得る。たとえば、図１Ｂに示される実施形態に示されるように、ＤＡＳ１０２は、セマンティクス情報１１７を含むＢＩ情報を格納するさまざまなデータソースを含み得るかまたはそれらにアクセスし得る。他の実施形態では、セマンティクス情報は、分析されるデータの構造であり得るとともにデータを格納するのに用いられるデータ構造であり得る。たとえば、分析されるデータを格納するデータベースの場合、データベースについてのスキーマ情報１１６を用いてセマンティクス情報を判断してもよい。エンハンサ１０３は、スキーマ情報１１６を用いて、入力されたクエリ内の述語に基づいて述語条件アプリケーションと、さらに別の述語条件とを推論してもよい。
オプティマイザ１１４およびエンハンサ１０３は、図１Ｂでは別個のサブシステムとして示されているが、これは限定を意図したものではない。代替的な実施形態では、エンハンサ１０３はオプティマイザ１１４の一部であってもよい。このような実施形態では、オプティマイザ１１４は、クエリプランを選択し、次いで、本開示で説明する技術を用いてクエリプランを高度化する。特定の実施形態では、エンハンサ１０３は、ＤＢＭＳ１０４ではなくＤＡＳ１０２の一部であってもよい。このようなシナリオでは、ＤＢＭＳ１０４は、ＤＡＳ１０２と協働的に機能して、高度化クエリプランを生成し得る。特定の実施形態では、パーサ１２０、オプティマイザ１１４、エンハンサ１０３およびエグゼキュータ１０５は、ＤＢＭＳ１０４のクエリエンジンと総称されてもよい。
上述のように、図２に示される例などのデータレコードを格納するデータベースが、ＳＱＬクエリなどの分析クエリを用いてさらに分析され得る。典型的なクエリは、次元テーブルと組合わされるとともに互いに組合わされる１つ以上のファクトソースを含み得る。特定の実施形態では、本明細書に開示されるように、エンハンサ１０３は、各ファクトソーススキャンの観点から、クエリについて、オプティマイザによって生成されたクエリプランを分析するとともに、処理されるファクト行の数が著しく減少するように、および／またはスキャンオペレーションを実行する全体的コストが削減されるように、ファクト行に適用され得る次元コンテキスト（たとえば、次元フィルタ）を推論しようと試みる。スター結合（ファクトソースとそれらの次元コンテキストとの組合せを表す結合）の場合、以下のものを用いることで、推論されるとともにファクトソースに適用されるべきさまざまな次元コンテキストを識別することができる。
・ スタースキーマのエッジに沿った結合が無損失分解の組合せを表す（したがって、新しいファクトが導入されない）というファクトを利用することができる。
・ スタースキーマのセマンティックモデルにおける関数依存性を利用することができる。
・ ＯＬＡＰインデックスファクトソースの場合、書換えを行うことができる。
ファクトソースがそれぞれの次元でファクトを事前結合することができるため、スタースキーマにおける結合は、ファクトソースのコンテキストにおけるファクトソース結合として分類される。スタースキーマ結合は、ファクトソースを形成する際に詳細に検討される結合である。
データベース２００に格納されたデータを分析するために、分析クエリが、データベースデータ２００に対して実行されるべく受信され得る。このようなクエリの例がクエリＡとして以下に示される。
クエリＡ
Figure 2021511582
クエリＡと同等の自然言語は、「「問題となる」顧客と店舗との関係を識別するためのものである。ここで「問題となる」とは、店舗の平均の２０％を超える返品量を有するものとして定義されている」。質問は、顧客とこれら顧客が訪問した店舗との関係に関するものであって、顧客行動全体に関するものではない。さらに、テネシー州（Tennessee）についての分析が行われる。
上述のクエリＡなどのクエリを受信すると、データベース管理システムは、クエリをパースし、次いで、クエリについてのクエリプランを生成するように構成される。次いで、クエリプランが、格納されたデータレコードに対してデータベース管理システムによって実行されて、クエリに関する結果が得られる。図３は、クエリＡのために生成され得るクエリプラン３００の論理ツリーまたはグラフ図である。クエリプラン３００はオプティマイザ１１４によって生成されて選択されるクエリプランを表わしている。クエリプラン３００は、関係性テーブル内のデータがどのように演算されるかについての論理フローグラフを表す。前述したように、クエリプランは、クエリプランパイプラインにおける或るオペレーションから別のオペレーションへの行ソースの流れを表す。クエリプランの各オペレーションは、データベースから行を検索するか、または１つ以上の他のオペレーション（または行ソース）から行を受取る。
クエリプラン３００は、ファクトテーブルまたは次元テーブルを表す４つのリーフノードを含む。クエリプランにおける非リーフノードはさまざまなリレーショナルオペレータを表す。図３に示す例は、フィルタオペレータ、結合オペレータ、集約オペレータ、プロジェクトオペレータを含む。非リーフノードは、その子ノードが出力した行を入力とし、非リーフノードが出力した行を非リーフノードの親ノードへの入力として提供されるものとするか、または、非リーフノードがルートノードであれば、ルートノードが出力した行またはレコードをクエリ実行の結果として提供する。たとえば、図３において、ノード３１０は、ノード３０８および３０４によって出力される行を入力とし、ノード３０８は、ノード３０６によって出力される行を入力とし、ノード３０４は、店舗テーブルのスキャンによって返される行またはレコードを入力とする。
クエリプラン３００では、左側の集約サブプラン３０２は、Customer（顧客）グレインおよびStore（店舗）グレインでの返品量を演算することを含み、右側の集約サブプラン３１２は、Store（店舗）グレインでの返品量を演算する。次いで、これらを結合して、返品量が対応する店舗平均を２０％上回っているCustomer（顧客）とStore（店舗）との組合わせについての情報を抽出する。この後、行は、テネシー州にある店舗に対してフィルタリングされる。
クエリは一般に複数の層を含み、そのうちのいくつかは、未処理のファクトから値を演算する構築ブロック層である。たとえば、分析クエリは、セットの上からｎ個／下からｎ個を結合、集合、順序付け、および採用するといったオペレーションによって組合わされる多次元計算の層と考えることができる。クエリＡによって提示される比較的単純な質問であっても、クエリプラン３００に示されるように、店舗返品スタースキーマに対して複数のAggregate（集約）−Join（結合）パスを実行することを伴う。Aggregate（集約）−Join（結合）は各々は、非常に大型のファクトテーブルをスキャンすることを含むとともに、１つ以上の次元テーブルと結合する。この場合、次元テーブルの大部分はファクトテーブルと比べて小さい。
図３に示すクエリプラン３００は、クエリＡのライン２〜８におけるサブクエリに対応するサブプラン３０２を含む。図３の例では、サブプラン３０２はサブクエリに対応するが、クエリサブプランはサブクエリに限定されないことが認識されるはずである。むしろ、クエリサブプランは、データベースクエリのいずれの部分にも対応し得る。
サブプラン３０２は、クエリＡのライン７における述語を評価するためのフィルタオペレーションおよび結合オペレーションを含む。プラン３００によれば、述語条件「年＝２０００」は、「Date（日付け）」次元レコードに対して評価され、これによりこれら「Date（日付け）」次元レコードをフィルタリングするためのものである。その後、「Store_Returns」ファクトレコードをフィルタリングされた「Date（日付け）」次元レコードと結合することによって、述語条件「sr.date_key = d.date_key」が評価される。しかしながら、結合オペレーションを実行することは、典型的には多数の（たとえば、数百万の）ファクトレコードの処理を伴うので、計算集約的であり得る。
サブプラン３０２に接続されていないクエリプラン３００の別個のブランチにおいて、プラン３００は、クエリＡのライン１６に対応するフィルタオペレーション３０４（州＝「ＴＮ」に対するフィルタ）をさらに含む。プラン３００によれば、フィルタオペレーション３０４はサブプラン３０２のオペレーションとは別個に実行されることとなる。その後、フィルタリングされた「Store（店舗）」次元レコードは、ノード３０６および３０８を通過した後にサブプラン３０２におけるオペレーションを実行する結果のうちいくつかと結合されることとなる。
プラン３００は、ファクトテーブルStore_Returns上の２つのファクトスキャンを含む。しかしながら、クエリ全体のコンテキストは、テネシーという州および年２０００である。しかしながら、プラン３００では、ファクトソースStore_Returnsのスキャンを含むサブプラン３０２は、州がテネシーであるものにしかレコードを制限しない。結果として、テネシー以外のレコードも、処理のために、サブプラン３０２における結合オペレーションに対して、かつ、サブプラン３０２から結合オペレーション３０６に対して提供される。したがって、これらのファクトレコード（すなわち、すべての州についての２０００年の店舗返品）がオペレーション３０６、３０８および３１０に不必要に送り進められることとなるだろう。なぜなら、３１０において、ＴＮにはないこれらのファクトレコードが結合されず除外されることとなるからである。また、３０６、３０８および３１０を通じてこれらの不要なレコードを伝達することは、クエリプランで送り進められるレコードの数に起因してクエリプラン３００の実行に必要とされるリソースの観点から見れば無駄であり、かつ、クエリプラン３００の実行に必要な時間を増やしてしまう（すなわち、クエリの実行により多くの時間がかかる）。この結果、演算リソースが著しく無駄になり、実行時間が長くなってしまう。
特定の実施形態では、エンハンサ１０３は、クエリプランの一部からＴＮフィルタ条件を推論するとともに、クエリプランの別の無関係な部分に推論条件が適用されるようにクエリプランを変更し、これにより、クエリプラン全体の実行中に搬送されるファクトレコードの数を低減するように、および／または、スキャンオペレーションを実行するコスト全体を削減するように構成されている。クエリプランの書換えは、不必要な処理とファクトレコードを送り進めることとを回避するのに役立つ。クエリプラン３００は、スタースキーマ情報１１６および／またはセマンティクスメタデータ１１７から導き出された推論を用いて書換えられてもよい。エンハンサ１０３は、スタースキーマ１１６および／またはセマンティクスメタデータ１１７を用いてクエリプラン３００を書換えてもよい。
たとえば、図４に示されるように、スタースキーマ４００は、「Store（店舗）」次元レコードが「Store_Returns」ファクトレコードと結合され得ることを示す。したがって、エンハンサ１０３は、「Store（店舗）」次元レコードをフィルタリングするための述語条件を用いて「Store_Returns」ファクトレコードをフィルタリングすることもできると推論することができる。
スタースキーマ１１６および／またはセマンティクスメタデータ１１７から導き出された推論に基づいて、エンハンサ１０３は、クエリプラン内の述語条件をクエリプラン内のクエリサブプランの外側からクエリサブプランの内側へ伝搬することによって、クエリプラン３００を書換えて高度化してもよい。クエリプランのサブプランまたはサブ部分に接続されていない述語条件は、書換え後にサブプランから出力されるファクトレコードの数が書換え前にサブプランから出力されるファクトレコードの数よりも少なくなるように、および／または、サブプランにおけるスキャンオペレーションを実行するコスト全体が削減されるように、かつ、クエリ実行から得られるクエリ結果全体に影響をおよぼすことなく、サブプランまたはサブ部分に挿入されるかまたは関連付けられる。このような態様では、書換えの結果、オリジナルのクエリプランにおける後半のオペレーション中に除去されることとなる無関係なファクトレコードがこのとき、書換えの結果、クエリプランの前半のうちに除去され、これにより、クエリプランの実行時に送り進めるべきファクトレコードの数が減らされ、その後の不要な処理が回避される。上述したように、ファクトレコードの数は数百万にも上る可能性がある。したがって、クエリプランパイプラインにおいて、クエリプラン中の或るオペレーションからクエリプラン中の別のオペレーションへと送り進めなければならないファクトレコードの数をこのように減らすことにより、全体的なクエリ実行を著しく改善させ（すなわち、より高速にし）、かなりの量の演算リソース（たとえば、Ｉ／Ｏリソース、処理（たとえば、ＣＰＵ）リソース、およびメモリリソース）の無駄を低減させる。
図５は、特定の実施形態に従った、クエリＡを実行するためにエンハンサ１０３によって生成され得る書換え済みの高度化クエリプラン５００の論理ツリーまたはグラフ図である。プラン５００は、図３に示すプラン３００を書換えたバージョンを表わしている。プラン５００はサブプラン５０２を含み、サブプラン５０２はクエリＡのライン２〜８のサブクエリに対応する。図５では、図３のサブプラン３０２がサブプラン５０２として書換えられている。サブプラン３０２と比較すると、書換えられたサブプラン５０２は、「年＝２０００」条件を有するだけでなく、追加条件「州＝ＴＮ」も有している。このような態様では、クエリプラン３００におけるオペレーション３０４からの「州＝ＴＮ」述語条件は、追加条件（年＝２０００に加えて）としてサブプラン５０２におけるフィルタオペレーションに伝搬されている。両方の条件を備えたこの書換えられたフィルタオペレーション５０４は、「Store_Returns」ファクトテーブルからスキャンされたファクトレコードに適用される。こうして、サブプラン３０２（またはより具体的には、フィルタオペレーション３０４）は、フィルタ条件を図３のフィルタオペレーション３０４からサブプラン５０２中のフィルタオペレーション５０４に伝搬させることによって、エンハンサ１０３によりサブプラン５０２として書換えられている。
同様の態様で、図５では、図３のサブプラン３１２がサブプラン５１２として書換えられている。サブプラン３１２と比較すると、書換えられたサブプラン５１２は、「年＝２０００」条件を有するだけでなく、付加的な条件「州＝ＴＮ」も有している。このような態様では、クエリプラン３００におけるオペレーション３０４からの「州＝ＴＮ」述語条件が、（年＝２０００に加えて）追加の条件としてサブプラン５１２におけるフィルタオペレーションに伝搬されている。両方の条件を備えたこの書換えられたフィルタオペレーション５０６は、「Store_Returns」ファクトテーブルからスキャンされたファクトレコードに適用される。したがって、サブプラン３１２（またはより具体的には、フィルタオペレーション３０４）は、フィルタ条件を図３のフィルタオペレーション３０４からサブプラン５１２のフィルタオペレーション５０６に伝搬させることによって、エンハンサ１０３によりサブプラン５１２に書換えられている。
上述の態様でクエリプランを書換えることにより、テネシーに無関係なファクトソースStore_Returnsから任意のファクトレコードをフィルタリングして除去することが可能となり、これにより、このような無関係なファクトレコードをさらに処理する際に演算リソースが無駄にならない。サブプラン３０２と比較すると、フィルタオペレーション５０４およびサブプラン５０２によって出力されるとともにプロジェクトプラン５００におけるさらなるオペレーション（たとえば、結合オペレーション５０８）に利用可能にされるファクトレコードの数は、サブプラン３０２によって（具体的には、サブプラン３０２における結合オペレーションによって）出力されるとともにクエリプラン３００における次のオペレーションに利用可能にされるレコードの数よりも大幅に少ない。これは、ＴＮ条件に合致するレコードのみが、フィルタオペレーション５０４およびサブプラン５０２によって、プラン５００内の下流オペレーション（たとえば、サブプラン５０２によって出力されるファクトレコードを得る結合オペレーション）に出力されるからである。テネシー以外のレコードはフィルタリングして除去される。同様の態様で、サブプラン３１２と比較すると、フィルタオペレーション５０６およびサブプラン５１２によって出力されるとともにプロジェクトプラン５００におけるさらなるオペレーション（たとえば、結合オペレーション５０８）にとって利用可能にされるファクトレコードの数は、サブプラン３１２によって（具体的には、サブプラン３１２における結合オペレーションによって）出力されるとともにクエリプラン３００における次のオペレーションにとって利用可能にされるレコードの数よりも大幅に少ない。これは、ＴＮ条件に合致するレコードのみが、フィルタオペレーション５０６およびサブプラン５１２によって、プラン５００内の下流オペレーション（たとえば、サブプラン５１２によって出力されるファクトレコードを得る結合オペレーション５０８）に出力されるからである。テネシー以外のレコードはフィルタリングして除去される。これにより、結果として、結合オペレーションに提供されるレコードの数が大幅に削減され得る。ファクトテーブルのサイズに応じて、１００倍と同程度またはそれ以上、ファクトレコードの数が減少する。サブプラン５０２および５１２によって出力されるファクトレコードの数がこのように減少した結果、プラン５００と、これにより、クエリプラン５００が生成される対応するクエリとが（より少ないＣＰＵサイクルだけで実行できるので）より高速で実行され、多くの場合、用いるメモリリソースが非高度化クエリプラン３００よりも少なくなり得るが、同じデータを分析するとともに同じクエリを返し得る。
図３および図５に示される例では、クエリプランの一部分から条件がクエリプランの別の部分に伝搬される。この例では、述語条件（State（州）＝ＴＮに基づくフィルタ）は、クエリプランの一部分から（たとえば、図３のフィルタオペレーション３０４から）クエリプランの別の部分（たとえば、図５のフィルタオペレーション５０４および５０６）に伝搬される。この例においては、述語条件が伝搬されるクエリプラングラフのオペレーションまたは部分は、ツリーのうち述語条件が伝搬される部分の子孫でも先祖でもない。すなわち、フィルタオペレーション５０４および５０６は、クエリプラン３００または５００におけるフィルタオペレーション３０４の子孫でも先祖でもない。
図５の例では、フィルタオペレーション３０４からの述語条件がサブプラン３０２および３１２に伝搬されて、書換えられたサブプラン５０２および５１２が生成されるが、これは単なる一例に過ぎないことが認識されるはずである。一般に、クエリプラングラフにおける第１のオペレーションからの述語条件が伝搬されて、クエリプラン内の別の部分またはオペレーションに関連付けられて、最適化されて高度化された書換え済みクエリプランが生成され得る。これは利用可能なデータ構造（たとえば、実体化されたビュー）に依存し得る。
特定の実施形態では、クエリプラン３００の分析の一環として、エンハンサ１０３は、Aggregate（集約）、Join（結合）、Project（プロジェクト）、Filter（フィルタ）またはScan（スキャン）のオペレータ／オペレーションのみを含むクエリプラン全体内のサブプランであるAggregate（集約）−Join（結合）サブプランに焦点を合わせている。これらの例は図３に示されるサブプラン３０２および３１２である。エンハンサ１０３の目的は、これらのサブプラン内のファクトソース関係のスキャンにプッシュされ得る述語条件またはフィルタを見出すことである。
特定の実施形態では、エンハンサ１０３が探索する一般的なパターン（パターンＡ）は、以下のとおりである。
− ファクトソーススキャン（ｆｓ）と他の何らかのテーブルスキャン（ｏｔ）との間の結合条件を定義するJoin（結合）オペレーション（「結合ノード」）を表すクエリプラン内のノード。結合条件は、ファクトソースの列と他のテーブルの列との間の同等性チェックのリストとして表され得る（fs.coll=ot.collおよびfs.col2=ot.col2、など）。
− ファクトソース側はヌル供給であるべきではない。すなわち、ファクトソーススキャンから検討中の結合（ｊ１）までの経路に沿って、ファクトソース側がヌル供給となる別の結合（ｊ２）があってはならない（すなわち、ｆｓはｊ２の子ｃ１の子孫ではあり得ない。ここで、ｊ２は外側の結合であり、ｃ１はｊ２のヌル供給側である）。
パターンＡを以下に示す。パターンＡのライン２および４は、Aggregate／Join／Project／Filterオペレーションの任意の組合わせの代わりとなる。
１．Join（結合）（fs.col1 = ot.col1およびfs.col2 = ot.col2、など)
２．project/filter/aggregateオペレーション
３．ファクトソーススキャン（ｆｓ）
４．project/filter/aggregateオペレーション
５．OtherTableスキャン（ｏｔ）
上記パターンＡと一致するクエリプラン全体におけるサブプランが見つかれば、「semiJoin」制限をファクトソースの結合列に適用することができる（パターンＡにおけるfs.col1、fs.col2、…）。ファクトソース行は、（ot.col1、ot.col2…上の）OtherTable内の何らかの行と一致する結合列値を有するものに限定され得る。さらに、OtherTableが実質的に何らかのフィルタを有する場合、以下のとおり、ファクトソース関係スキャンを書換えることができる：
１．Left-Semi Join（左側のセミ結合）（fs.coll = ot.coll、fs.col2 = ot.col2、…）。
２．ファクトソーススキャン（ｆｓ）
３．別個のot.col1、ot.col2、…を選択
４．フィルタ
５．OtherTableスキャン（ｏｔ）
この書換えの潜在的な利点は、クエリプランパイプラインの後続のオペレータにおいて処理されるファクトソース行が減少することである。ファクトソース行の減少は、OtherTable上のフィルタの選択性に非公式に依存する。フィルタの選択性が高ければ高いほど（たとえば、多数の別個の値を有する列上の同等性条件）、ファクトソース行の減少が大きくなる可能性が高くなる。スタースキーマ結合の場合、結合は無損失分解であり（結合によって新しいファクトが追加されない）、このため、スキャンされるファクトに対する次元フィルタの利点がフィルタの選択性に正比例する可能性が非常に高くなる。
この書換えのコストはセミ結合オペレーションが如何に実行されるかに基づいている。一般的な場合、これは、典型的には物理的な結合プランを伴うであろうLeft Semi-Join（左側のセミ結合）オペレータを用いて行われる。
クエリプラン内で述語条件を効率的に伝搬するために利用可能なさまざまな技術がある。用いられる特定の技術は、推定される演算節約分および／または特定のデータ構造の利用可能性を含むがこれらに限定されないさまざまな要因に基づいて選択され得る。
１つの技術は、ファクトレコードと次元レコードとの間でセミ結合オペレーションを実行することを含む。これは、述語条件を満たす次元キーのセットを決定するために述語条件を次元レコードに対して評価することに基づいて達成され得る。この次元キーのセットは、本明細書では「リスト内のキー（key in-list）」と称される。
図６は、クエリＡを効率的に評価するために用いることができるリスト内のキー６０２および６０４を生成するための例示的な処理６００を示す。より具体的には、述語条件「年＝２０００」は、リスト内のキー６０２を決定するために次元テーブル２０４に対して評価され、述語条件「州＝「ＴＮ」」は、リスト内のキー６０４を決定するために次元テーブル２０８に対して評価される。リスト内のキーは、述語条件を満たす次元テーブルにおける次元レコードからの外部キーのリストである。たとえば、Date（日付）次元テーブル２０４の場合、「年＝２０００」は、図６に示される最初のレコードによって満たされ、date_key＝１は、そのレコードからの外部キーである。リスト内のキー６０２および６０４を用いて、ファクトレコードをスキャンおよびフィルタすることができ、これにより、述語条件をファクトレコードに伝搬することができる。
しかしながら、セミ結合オペレーションを実行することは、かなりの量の演算オーバーヘッドを引起こす可能性がある。ファクトレコードのスキャンは、典型的には多数のファクトレコードが存在するので計算集約的となる可能性がある。さらに、リスト内のキーを生成することにより、セミ結合オペレーションを実行する演算オーバーヘッドが増大する。このオーバーヘッドは、有意義なものにするためには、不必要に処理される可能性のあるファクトレコード（たとえば、テネシーとは無関係のファクトレコード）の低減によって超過されなければならない。したがって、エンハンサ１０３は、セミ結合オペレーションを含むようにクエリプランを書換える前に演算節約分を推定し得る。
複数の述語条件の場合、クエリエンハンサ１０３は、セミ結合オペレーションを連続的に実行する場合の増加節約分を分析してもよい。これは、各々の述語条件を別個に適用することに起因するであろう演算節約分の高いものから順に述語条件を配置することを含み得る。次いで、エンハンサ１０３は、この順序で述語条件を分析して、述語条件を連続して適用することによる増加節約分を推定し得る。したがって、増加節約分が重要でない限り、連続的な述語条件を適用するためのセミ結合オペレーションが指定され得る。
述語条件をファクトレコードに効率的に伝搬するための別の技術は、次元値と結合されたファクト値（たとえば、ファクトテーブルからのファクトメトリック値または他の任意の値）の表形式表現を含む。また、実体化されたビューに含まれる次元値のメモリ位置への効率的なアクセスを可能にする１つ以上のインデックス（たとえば、反転されたインデックス）が含まれる。集合的に、１つ以上のインデックスを有する表形式表現は、本明細書中では「ＯＬＡＰインデックス」と称される。典型的には、ＯＬＡＰインデックスは、スキャン最適化された列符号化、メモリ最適化された列形式レイアウト、ベクトル化されたスキャンオペレーションなどの技術を用いる、提供される述語条件に基づいて行の任意のサブセットをスキャンするために最適化される単一の複合データレイアウトフォーマットである。述語評価もまた、たとえばビットセットオペレーションのセットとして高度に最適化される。これらの特徴は、ＯＬＡＰインデックスをアドホック分析用作業負荷に理想的に適合させる。
図７は、次元インデックス７０４および７０６を備える例示的なＯＬＡＰインデックス７００を示す。ＯＬＡＰインデックス７００はさらに、ファクトテーブル２０２を次元テーブル２０４および２０８と結合することによって得られるデータを含むテーブル７０２を含む。図７に示されるように、ＯＬＡＰインデックスは、次元値上の１つ以上の反転インデックスと共にデータを列形式で含む。次元値ごとに、位置ビットマップが維持される。
多くのデータベースでは、フィールド（たとえば、列７０８または７１０）内の値は、メモリアドレスの範囲内で連続的に格納されている。たとえば、データがストレージからシステムメモリに読出されると、列７１０の値は、効率的にアクセスされ得る列指向データベースデータとして揮発性メモリに連続的に格納され得る。特定の列値にアクセスする効率を高めるために、インデックス（たとえば、次元インデックス）は、フィールド値とメモリ位置との間のマッピングを格納し得る。図７の例では、次元インデックス７０４は、列７１０の「州」次元値７１２についてのメモリ位置７１４を示し、次元インデックス７０６は、列７０８の「年」次元値７１６のメモリ位置７１８を示す。
したがって、ＯＬＡＰインデックスは、演算リソースの節約を可能にする。ＯＬＡＰインデックスは次元値を含んでいるので、述語条件は、リスト内に生成することなくＯＬＡＰインデックスに対して直接評価され得る。さらに、次元値ビットマップは、次元値から、次元値を有するファクト行のサブセットへのマッピングを表わしている。各々の次元述語条件は、ビットマップまたはビットマップの組合わせにマッピングされ得る。たとえば、State（州）＝「ＴＮ」は、「ＴＮ」値ビットマップ内のファクト行であり、State（州）＞「ＴＮ」は、＞「ＴＮ」であるすべてのState（州）値についてのすべてのビットマップをＯＲによって組合わせることによって得られるビットマップ内のファクト行である。複数の次元述語条件のさらなる評価はまた、実際のファクトデータをスキャンする必要なしに、ＡＮＤ、ＯＲ、ＮＯＴのような超高速ビットマップ組合せ関数として評価され得る。図７に示すようなインデックスは、「州＝「テネシー」」および「日付け＝「２０００」」などの述語条件を高速で演算することを可能にする。ＯＬＡＰインデックス実体化は、非常に効率的な「スキップスキャン」の実行を可能にする。述語条件の評価（たとえば、州＝「テネシー」または日付け＝「２０００」）により、結果として行識別子のリストが得られ、述語条件に一致するデータを有するファクト行が識別される。たとえば、行識別子１、４、５、７、９、１０、１３、１５、１７、１９、２０、２３、および２４は、「州＝「テネシー」」の条件が満たされているファクトレコードに対応する。別の例として、行識別子１、２、３、４、５、６、７、および８は、「日付＝「２０００」」の条件が満たされているファクトレコードに対応する。行ｉｄ（rowid）リストは、ファクトスキャンオペレーション中に多数のファクトレコード行をスキップするために用いることができる。典型的には、分析クエリは、広大な多次元空間のうちの小さな領域に焦点を合わせており、このため、スキップスキャンが、すべてのファクトレコード（またはファクト行）をスキャンしてフィルタ述語条件を満たさないものを除去するよりも、著しく高速で実行される。したがって、ＯＬＡＰインデックスを述語条件と共に用いることにより、ファクトスキャンオペレーションがさらに一層高速になる。
図７は、明確にするためにメモリ位置７１４および７１８を１０進値として示しているが、メモリ位置７１４および７１８が２進値、１６進値などと表現され得ることが認識されるはずである。いくつかの実施形態では、メモリ位置７１４および７１８は、位置ビットマップとして維持されてもよく、これにより、計算上安価で高速なビットマップＡＮＤ演算が可能となって、複数の述語条件がファクトレコードに同時に伝搬され得る。さらに、図７は、明確にするために、メモリ位置７１４および７１８を相対アドレス（たとえば、バイトオフセット）として示しているが、いくつかの実施形態では、メモリ位置７１４および７１８が絶対アドレスとして表現され得ることが認識されるはずである。
一般に、ＯＬＡＰインデックスに対して述語条件を評価する利点は、演算コストをいずれも常に上回るものでなければならない。したがって、エンハンサ１０３は、費用便益分析を実行する必要がない。しかしながら、適切なＯＬＡＰインデックスが常に利用可能とならない可能性もある。たとえば、述語条件「州＝「ＴＮ」」が評価され得る対象となる「州」次元値を含むＯＬＡＰインデックスが存在しない可能性もある。
述語条件をファクトレコードに効率的に伝搬するためのさらに別の技術は、前述の技術の組合せを含み、本明細書では「インデックス・セミ結合」技術と称される。この名称によって示唆されるように、インデックス・セミ結合オペレーションは、ＯＬＡＰインデックスを含む特定のタイプのセミ結合オペレーションであるが、ＯＬＡＰインデックスは述語条件を直接評価するのに不適切である。
図８Ａは、テーブル８０２および次元インデックス８０４を含む例示的なＯＬＡＰインデックス８００を示す。テーブル８０２は、ファクトテーブルStore_Returns２０２を次元Store（店舗）テーブル２０８と結合した結果得られるデータを含む。列８０６の値は、列指向データベースデータとして揮発性メモリに連続的に格納されてもよく、次元インデックス８０４は、特定の列値に効率的にアクセスするために用いられてもよい。より具体的には、次元インデックス８０４は、「市」次元値８０８をテーブル内のメモリ位置８１０にマッピングする。
図８Ａは、明確にするためにメモリ位置８１０を１０進値として示しているが、メモリ位置８１０が２進値、１６進値などと表現され得ることが認識されるはずである。いくつかの実施形態では、メモリ位置８１０は、位置ビットマップとして維持されてもよく、これにより、計算上安価で高速なビットマップＡＮＤ演算が可能となり、複数の述語条件がファクトレコードに同時に伝搬され得る。さらに、図８Ａは、明確にするためにメモリ位置８１０を相対アドレス（たとえば、バイトオフセット）として示しているが、いくつかの実施形態では、メモリ位置８１０が絶対アドレスとして表現され得ることが認識されるはずである。
しかしながら、次元インデックス８０４は、述語条件「州＝「ＴＮ」」を直接評価するのに適していない。これは、次元インデックス８０４が「州」値ではなく「市」値に基づいているからである。
それにも関わらず、次元インデックス８０４は依然として、インデックス・セミ結合オペレーションに基づいて述語条件「州＝「ＴＮ」」をファクトレコードに伝搬するために用いられてもよい。これは、述語条件を満たすとともに次元インデックス８０４に含まれている次元値（たとえば、非キー値）のセットを決定するために述語条件を次元レコードに対して評価することを含み得る。この次元値のセットは、本明細書では「リスト内の値（value in-list）」と称される。
図８Ｂは、次元インデックス８０４に対する述語条件「州＝「ＴＮ」」を評価するのに用いることができるリスト内の値８２２を生成するための例示的な処理８２０を示す。より具体的には、述語条件「州＝「ＴＮ」」は、１つ以上の「市」値を含むリスト内の値８２２を決定するために次元テーブル２０８に対して評価される。図８Ｂの例では、これは単一の市値「ナッシュビル（Nashville）」を返す。次いで、リスト内の値８２２（たとえば、「ナッシュビル」）を用いて、テーブル８０２内の関連レコードに対応するメモリ位置（たとえば、ナッシュビルについての位置１、４、５、７、９、１０、１３、１５、１７、１９、２０、２３、および２４）についての次元インデックス８０４をスキャンし、これにより、それらのすべてをスキャンすることなく、テーブル８０２のレコードをフィルタリングすることができる。
インデックスセミ結合オペレーションを実行することで、すべてのファクトレコードのスキャンを回避することによって演算リソースが節約されるが、リスト内の値を生成することに関連する演算オーバーヘッドが生じる。このオーバーヘッドは、有意義なものにするために、不必要に処理される可能性のあるファクトレコード（たとえば、テネシーとは無関係なファクトレコード）の低減によって超過されなければならない。したがって、エンハンサ１０３は、インデックスセミ結合オペレーションを含むようにクエリプランを書換える前に演算節約分を推定し得る。
複数の述語条件の場合、エンハンサ１０３は、インデックスセミ結合オペレーションを連続的に実行する場合の増加節約分を分析してもよい。これは、各々の述語条件を別個に適用することに起因し得る演算節約分の高いものから順に述語条件を配置することを含み得る。次いで、エンハンサ１０３は、この順序で述語条件を分析して、述語条件を連続して適用することによる増加節約分を推定し得る。したがって、増加節約分が重要でない限り、連続的な述語条件を適用するためのインデックスセミ結合オペレーションが指定され得る。
上述のように、推論はスタースキーマ情報１１６から導き出され得るだけでなく、セマンティクスメタデータ１１７からも導き出され得る。セマンティクスメタデータ１１７から導き出される推論は、ファクトレコードに伝搬され得るように述語条件を変換するのに用いることができる。たとえば、セマンティクスメタデータ１１７は、週、月、四半期などの観点から表わされる時間値の間の階層関係を示す情報を含み得る。次いで、この情報を用いて、述語条件「四半期＝２」などの条件を「４と６と間の月（month BETWEEN 4 AND 6）」に変換することができ、これにより、述語条件が「月」の値に対して評価され得る。なぜなら、図２に示すDate（日付け）次元テーブル２０４は、月、日、および年のフィールドを含むが、四半期のフィールドは含まないからである。このような態様で、次元テーブル内の列ではない値に基づく述語条件を、次元テーブル内の列である値に変換することができる。
図９は、特定の実施形態に従った、機能依存性に基づいて述語条件をファクトレコードに伝搬するための例９００を示す。図９の例では、「四半期＝２」は、テーブル９０８および次元インデックス９１０を含む、図９に示されるＯＬＡＰインデックス９０９への伝搬のために識別され得る未変換の述語条件９０４である。しかしながら、テーブル９０８の列９１２、９１４、９１６、または９１８はいずれも「４半期」の列ではないので、ＯＬＡＰインデックス９１０に対して述語条件９０４を評価するのは困難である。
それにもかかわらず、セマンティクスメタデータ９０１は、インデックス９１０における次元属性に基づいて述語条件９０４を述語条件９０６に変換するために用いられ得る依存性メタデータを含み得る。より具体的には、セマンティクスメタデータ９０１は日付け階層９０２（たとえば、月から四半期、四半期から年）を含み得る。この日付け階層９０２は、述語条件「四半期＝２」を月ベースの述語条件「４と６との間の月（month BETWEEN 4 AND 6）」に変換するために用いることができる。その後、変換済みの述語条件９０６は、月値９２０をメモリ位置９２２にマッピングする次元インデックス９１０に対して評価することができる。この例では、４、５および６の月が述語条件を満たしており、それらのメモリ位置（または行ｉｄ）にマッピングされる。図９は、ＯＬＡＰインデックスを必要とする例示的な処理９００を示すが、変換された述語条件が本明細書中に記載される任意の適切な技術を用いてファクトレコードの任意のソースに伝搬され得ることが認識されるはずである。
図９に示されるとともに上述された例では、４半期に基づく述語条件は、月に基づく制約述語条件と置換えられる。制約述語条件の置換えは、オリジナルの述語条件と等価である必要はなく、単に、置換する述語条件によって返されるすべての行（ファクトレコード）を返さなければならないだけである。レベルベースの階層のために、同等性条件および範囲条件（=、！=、＜、＞、≦、≧、内（in）、間（between））に関する置換え戦略が用いられる。妥当なサイズの階層のために、階層のメモリ内表現が、エンハンサ１０３によって維持および使用されて、高度化クエリプランの生成中に置換え述語条件が演算され得る。
その目標は、クエリプランの実行によって処理されるファクトレコードの数を低減すること、および／または、クエリプランにおいてスキャンオペレーションを実行する全体的コストを削減することであるので、述語条件の適用はこの目標を達成するのに重要な役割を果たす。図９に示されるとともに上述された例では、クエリにおいて提供される述語条件（「四半期＝２」）は、提供された述語条件を置換える述語条件（「４と６との間の月」）とは異なっている。２つの述語条件が異なっていても、置換述語条件を適用することで、供給された述語条件によって返されるいずれの行も置換述語条件によって返されることが確実にされる。これは、クエリプランおよびクエリの性能の点で大きな利点を提供する。置換述語条件は、機能依存性を詳細に検討することによって推論することができる。従って、４半期→月→週の日付けという階層において、１週間についての述語条件を有する場合、週列がファクトソースにプッシュ可能ではない場合、ファクトソースは４半期の述語条件を処理することができ、たとえば、対応する４半期述語条件をプッシュすることができる。週＝１が４半期＝１としてプッシュされ得るとともに、週＞２５が４半期＞２としてプッシュされ得る等々である。述語条件の変換は、列同士の間の依存性を定義する関係ツリーを詳細に検討することに基づいている。これらのツリーがメモリ内構造として維持される場合、変換は非常に高速となり、計画に多くのオーバーヘッドが追加されなくなるだろう。これは、メモリ内データ構造を通じてメンバーナビゲーションをサポートすることが一般的である階層の場合に確実に該当する。
図９は、未変換の述語条件９０４において指定されるフィールドと変換済み述語条件９０６において指定されるフィールドとの間の階層関係を含む例を示しているが、本明細書で説明する技術は階層関係を呈するフィールドに限定されないことが認識されるはずである。たとえば、セマンティクスメタデータ９０１は、述語条件の変換を実行するために用いられ得る他の種類の情報を含んでいてもよい。たとえば、セマンティクス情報は、南部の店舗では冬用衣類を販売しないことを示す情報を含んでいてもよく、これにより、冬用衣類の用語で表現される述語条件を地理的地域の用語で表現される述語条件に変換することが可能となり得る。
本開示で説明する技術のいずれかを用いて、述語条件をファクトレコードに伝搬し得る。述語条件を伝搬することは、述語条件がファクトレコードと直接結合されない可能性がある次元レコードからファクトレコードに伝搬され得るという点で、推移特性を示す。たとえば、述語条件は、複数の次元テーブルにわたって、または別のファクトテーブルにわたって伝搬されてもよい。
いくつかの実施形態では、述語条件は、次元レコードの第１のセットから次元レコードの第２のセットにわたってファクトレコードのセットに伝搬され得る。これは、図１０Ａに示される例を参照しつつ説明することができる。図１０Ａは、簡略バージョンの「Store_Returns"」ファクトテーブル２０２と、「顧客（Customer）」次元テーブル１００２と、「Customer_Address」次元テーブル１００４とを含む例示的なデータベースデータ１０００を示す。「Store_Returns"」ファクトテーブル２０２は、列２１２および１００６に基づいて「顧客（Customer）」次元テーブル１００２と直接結合することができ、「顧客（Customer）」次元テーブル１００２は、列１００８および１０１０に基づいて「Customer_Address」次元テーブル１００４と直接結合することができる。しかしながら、図１０Ａの例では、「Store_Returns」ファクトテーブル２０２を「Customer_Address」次元テーブル１００４と直接結合するために用いることができる列は存在しない。
それにも関わらず、エンハンサ１０３は、スタースキーマ情報１１６を用いて、述語条件「州＝「ＴＮ」」が「Customer_Address」次元テーブル１００４から「Store_Returns」ファクトテーブル２０２に伝搬され得ることを推論し得る。なぜなら、これらは各々が「顧客（Customer）」次元テーブル１００２に関連しているからである。この推論に基づいて、エンハンサ１０３は、「Store_Returns」ファクトテーブル２０２の列を「Customer_Address」次元テーブル１００４の列に関連付けるテーブル（またはファクトレコードの任意の他のソース）をチェックしてもよい。
図１０Ｂは、このようなテーブル１０２０のみを示す。図１０Ｂの例では、テーブル１０２０は、列２１２および列１００６を用いる「Store_Returns」ファクトテーブル２０２および「Customer_Address」次元テーブル１００４を含むとともに、列１００８および列１０１０を用いる「顧客（Customer）」次元テーブル１００２と「Customer_Address」次元テーブル１００４との間における結合オペレーションから得られたデータを含む。したがって、テーブル１０２０は、「Customer_Address」次元テーブル１００４の「州」列１０１２に対応する「州」列１０２２を含む。
本明細書で説明する技術のいずれかを用いて、述語条件「州＝「ＴＮ」」をテーブル１０２０に伝搬し得る。たとえば、テーブル１０２０中の列１０２２の値についての反転インデックスが存在する場合、述語条件は、「州＝「ＴＮ」」述語条件を満たすファクト行をスキャンするためだけにテーブル１０２０をフィルタリングするために、反転インデックスに対して評価され得る。
図１０Ａおよび図１０Ｂに示す例の場合、以下の条件が満たされれば述語条件を伝搬させることができる。
・ 次元テーブルCustomer（顧客）１００２（Ｔ１）のフィルタに基づいてStore_Returnsテーブル２０２（ＦＳ１）を削減できることが既に推論されている。
・ ＦＳ１とＴ１との間の結合は、スタースキーマにおけるスタースキーマJoin（結合）である。これは、この結合オペレーションにより、結合に対する任意の入力ファクトレコードの追加または除去がなされないことを示唆している。
・ Ｔ１と次元テーブルCustomer_Address１００４（Ｔ２）との結合が、
− Ｔ１側でヌル供給ではなく、
− FS1.StarSchemaにおけるスタースキーマJoin（結合）である。
さらに、結合Ｔ１−Ｔ２におけるＴ１の列ｊｃを結合するＴ１ごとに、ＦＳ１において同等の列ｅｃｉが存在する場合、ＦＳ１のｅｃｉ列にsemiJoin制限を適用することができる。
いくつかの実施形態では、述語条件の評価は、次元レコードのセットから（次元テーブルＤＴから）ファクトレコードの第１のセット（ファクトソース１「ＦＳ１」）にわたってファクトレコードの第２のセット（ファクトソース２「ＦＳ２」）に伝搬され得る。たとえば、これは、スタースキーマがファクトレコードの複数のセットを含む場合に可能であり得る。図１１はこのようなスキーマ１１００の例を示す。スキーマ１１００は、（強調された境界線で示される）２つのファクトテーブル、すなわち、「Store_Returns」ファクトレコードテーブル１１０２および「Store_Sales」ファクトレコードテーブル１１０４、を含む。他のテーブル（Date（日付け）、Store（店舗）、Item（商品）、Customer（顧客）、Customer_Address）は、ファクトレコードについてのコンテキスト情報を格納する次元テーブルである。２つのファクトテーブルは各々、「Store（店舗）」次元レコードテーブル１１０６などの次元テーブルと結合することができる。
図１２Ａは、スキーマ１１００に記述され得る例示的なデータベースデータ１２００を示す。データベースデータ１２００は、「Store_Returns」ファクトテーブル１２０２、「Store（店舗）」次元テーブル１２０４、および「Store_Sales」ファクトテーブル１２０６を含む。図１２は、データベースデータ１２００をテーブルとして示しているが、データベースデータ１２００がインデックス、実体化されたビューおよび／またはタプルの他の任意のセットとして表現され得ることが認識されるはずである。
「Store_Returns」ファクトテーブル１２０２および「Store（店舗）」次元テーブル１２０４は、外部キーと一次キーとの関係を示す列１２０８および列１２１０に基づいて結合することができる。したがって、列１２１２および列１２１４のいずれかを伴う述語条件（たとえば、「州＝「ＴＮ」」）は、本明細書で説明する技術のいずれかを用いて、「Store（店舗）」次元テーブル１２０４から「Store_Returns」ファクトテーブル１２０２に伝搬され得る。
しかしながら、「Store_Sales」ファクトテーブル１２０６は、「Store（店舗）」次元テーブル１２０４と結合することもできる。これは、列１２１６および列１２１０も外部キーと一次キーとの関係を示しているからである。したがって、図１１に示すスキーマ１１００に基づいて、エンハンサ１０３は、本明細書で説明する技術のいずれかを用いて「Store_Returns」ファクトテーブル１２０２の任意のフィルタリングを「Store_Sales」ファクトテーブル１２０６にも適用することができると推論し得る。
図１２Ｂは、クエリサブプラン１２２２、１２２４、および１２２６を備える例示的な論理クエリプラン１２２０を示す。クエリプラン１２２０に従うと、サブプラン１２２２におけるオペレーションの実行結果とサブプラン１２２４におけるオペレーションの実行結果との間の結合オペレーション１２３０が実行される。さらに、プラン１２２０は、結合オペレーション１２３０の実行結果とサブプラン１２２６におけるオペレーションの実行結果との間の結合オペレーション１２３２の実行を指定する。
フィルタオペレーション１２２８はサブプラン１２２２に含まれるが、フィルタオペレーション１２２８はサブプラン１２２４および１２２６には含まれない。この結果、結合オペレーション１２３０を実行するとき、「Store_Returns」ファクトテーブル１２０２からのすべてのファクトレコードについて相当量の不要な処理が行われる可能性がある。同様に、サブプラン１２２６からの「Store_Sales」ファクトテーブル１２０６から返されるすべてのファクトレコードに対して結合オペレーション１２３２を実行するとき、相当量の不要な処理が実行される可能性がある。この不要な処理は、クエリプラン１２２０を実行するのにかかる合計時間を大幅に増やしてしまう可能性がある。
図１２Ｃは、クエリプランによって処理されるファクトレコードの数を減らすためにクエリプラン１２２０に基づいて書換えられた例示的な書換え済み高度化クエリプラン１２４０を示す。プラン１２４０に従うと、フィルタオペレーション１２２８における述語条件「州＝ＴＮ」は、フィルタオペレーション１２４２としてサブプラン１２２４に伝搬されるだけでなく、フィルタオペレーション１２４４としてサブプラン１２２６にも伝搬される。この結果、サブプラン１２２４によって出力されるとともに結合オペレーション１２３０に提供されるファクトレコードの数が、（州がＴＮでないレコードをStore_Returnsテーブルが保持していると想定すると）クエリプラン１２２０における結合オペレーション１２３０に提供されるファクトレコードよりも少なくなる。これは、プラン１２４０において、「州＝「ＴＮ」」述語条件を満たすファクトテーブルStore_Returnsからのファクトレコードのみが、プラン１２２０内のすべてのファクトレコードの代わりに、結合オペレーション１２３０に提供されるからである。同様に、サブプラン１２２６によって出力されるとともに結合オペレーション１２３２に提供されるファクトレコードの数は、（州がＴＮでないレコードをStore_Salesテーブルが保持すると想定すると）クエリプラン１２２０における結合オペレーション１２３２に提供されるファクトレコードよりも少ない。これは、プラン１２４０において、「州＝「ＴＮ」」条件を満たすファクトテーブルStore_Salesからのファクトレコードのみが、プラン１２２０内のすべてのファクトレコードの代わりに、結合オペレーション１２３２に提供されるからである。この結果、次元述語条件「州＝「ＴＮ」」を満たさない「Store_Returns」ファクトテーブル１２０２および「Store_Sales」ファクトテーブル１２０６のいずれかの行を最初にフィルタリングして除去することによって、結合オペレーション１２３０および１２３２を実行する演算オーバーヘッドが大幅に低減され得る。したがって、クエリプラン１２４０は、非高度化クエリプラン１２２０よりもはるかに高速で実行される（たとえば、より少ないＣＰＵサイクルを使用する）とともに、多くの場合、より少ないメモリリソースを用い得る。
上述のように、特定の実施形態では、同じファクト（或るファクトの複数のグレインの分析を伴うクエリ）または異なるファクト（たとえば、さまざまな活動の比較／組合わせを伴うクエリ）を含むサブクエリにわたってコンテキストの推移伝搬のための技術が開示される。特定の実施形態では、これらの技術は、以下の条件が成り立つ場合に適用され得る。
・ 次元テーブルＤＴに基づくファクトソースＦＳ２に対する次元コンテキスト適用が決定されている。
・ ＤＴのキー列上に別のファクトソースＦＳ１とＦＳ２との結合が存在しており、ＤＴもＦＳ２のスタースキーマにおける次元テーブルである。
上述の条件が成立した場合、ＤＴからの次元コンテキストをＦＳ１に適用することができる。
図１３Ａは、特定の実施形態に従った高度化クエリプランを生成する方法を示す簡略フローチャート１３００である。処理１３００は、それぞれのシステムの１つ以上の処理ユニット（たとえばプロセッサ、コア）によって実行されるソフトウェア（たとえばコード、命令、プログラム）、ハードウェア、またはそれらの組合わせで実現され得る。ソフトウェアは非一時的な記憶媒体（たとえばメモリデバイス）に格納されてもよい。図１３に示されるとともに以下で説明される方法は、限定ではなく例示を意図している。図１３は特定のシーケンスまたは順序で行われるさまざまな処理ステップを示すが、これは限定を意図したものではない。特定の代替的実施形態において、ステップはいくつかの異なる順序で実行されてもよく、いくつかのステップは並列に実行されてもよい。
１３０２において、第１またはオリジナルのクエリプランが受信され得る。オリジナルのクエリプランは、図１Ａおよび図１Ｂに示される分析プラットフォーム１００に提供されるデータベースクエリ（たとえば、ＳＱＬクエリ）のために生成されるプランであってもよい。クエリは、データベースに格納された事前集約されていないデータに対して実行されるアドホッククエリであってもよい。図１Ｂに示す実施形態を参照すると、オリジナルのクエリプランは、オプティマイザ１１４によって生成されてもよい。
オリジナルのクエリプランは、オペレーション（またはオペレータ）のパイプラインを含み得る。オペレーション（オペレータ）は、たとえば、ファクトスキャン（単にスキャンオペレーションと称されることもある）、フィルタ、結合、集約、計画、および他のオペレーションを含み得る。オリジナルのクエリプランにおけるオペレーションは、オペレーションの出力が他の下流オペレーションへの入力として提供されるようにパイプラインにおいて階層的に編成されてもよい。クエリプランは、親ノードおよび子ノードを含むルートツリーとして階層的に表現され得る。このような表現では、オペレーションは、ツリーのリーフノードによって表されるオペレーションから実行される。次いで、リーフノードからの出力が親ノードに与えられ、親ノードからの出力がそれらの親ノードに与えられる等の処理が、ルートノードからの出力が与えられるルートノードがクエリプランが生成されるクエリの結果になるまで、同様に続けられる。たとえば、１３０２において受信されるオリジナルのクエリプランは図３および／または図１２Ｂに示す通りであり得る。
オリジナルのクエリプランにおける１つ以上のオペレーションは、サブプランを形成するためにグループ化され得る。たとえば、オリジナルのクエリプランは、ファクトレコードのソース（たとえば、ファクトテーブル）をスキャンすることを伴うファクトテーブルスキャンオペレーションを含む第１のサブプランを含み得る。第１のサブプランはまた、フィルタオペレーション、結合オペレーション、集約オペレーション、計画オペレーションなどの他のゼロ以上のオペレーションを含み得る。たとえば、図３に示されるサブプラン３０２、および図１２Ｂに示されるサブプラン１２２２、１２２４および１２２６がある。オリジナルのクエリプランにおいて、第１のサブプランによって出力される（すなわち、第１のサブプランにおいて実行されるオペレーションの結果として第１のサブプランから出力される）ファクトレコードは、オリジナルのクエリプランパイプラインにおける親オペレーションへの入力として提供される。
１３０４において、オリジナルのクエリプランを書換えることによって高度化クエリプランが生成される。書換えの結果、結果として得られる高度化クエリプランにおいて、少なくとも１つの次元述語条件の評価が、高度化クエリプランにおけるファクトスキャンオペレーションに伝搬されて、それに関連付けられる。ここで、述語条件は、オリジナルのクエリプランにおける同じファクトスキャンオペレーションには関連付けられていなかった。たとえば、述語条件は第１のサブプランに挿入されて、第１のサブプランにおける少なくとも１つのファクトスキャンオペレーションに関連付けられてもよい。高度化クエリプランでは、述語条件の評価は、述語条件をファクトテーブルに伝搬することに基づいてサブプランの一部として行われる。述語条件を伝搬して第１のサブプランおよびファクトスキャンオペレーションと関連付けた結果、高度化クエリプランはオリジナルのクエリプランよりも高速で実行される。たとえば、場合によっては、述語条件をファクトスキャンオペレーションに関連付けた結果、オリジナルのクエリプランと比べて、より少ないファクト行／レコードが高度化クエリプランによって処理される。これは、述語条件を満たすそれらのファクトレコードだけがクエリプランパイプラインにおける親オペレーションまたは下流オペレーションのために提供される一方で、述語条件を満たさないファクトレコードはフィルタリングして除去されて、たとえば結合オペレーションであり得る親オペレーションには提供されないからである。この結果、クエリプランパイプラインにおける次のオペレーションおよび後続のオペレーションに提供されているファクトレコードの数が少なくなる。これにより、クエリプランパイプラインにおける結合オペレーションおよび他の後続オペレーションをその後実行することに関連する演算オーバーヘッドを低減させる。クエリプランパイプラインにおいてより少ないファクトレコードが処理されて送り進められる必要があるので、高度化クエリプランは、オリジナルのクエリプランよりも高速で実行されるとともに、より少ないリソース（たとえば、処理リソース、メモリリソース）を用いる。
他のいくつかの例では、ファクトスキャンオペレーションに関連付けられた述語条件は、クエリプランパイプラインにおけるファクトスキャンオペレーションから下流オペレーションに出力されるファクトレコードの総数が減らされない可能性があっても、ファクトスキャンオペレーションの実行に関連するコスト（たとえば、ファクトスキャンオペレーションを実行するのに必要なＣＰＵサイクルまたは時間）がオリジナルのクエリプランにおける同じファクトスキャンオペレーションと比べて削減されるような条件である。
結果として、１３０４で書換えられた高度化クエリは、１３０２で受信されたオリジナルのクエリプランよりも高速で実行される。その結果、高度化クエリプランが生成されるクエリは、より高速で実行され、場合によってはより少ないメモリリソースを用いる。したがって、高度化クエリプランは、オリジナルのクエリプランと比べて高度化および改善されている。図１Ｂに示される実施形態では、１３０４における処理はエンハンサ１０３によって実行されてもよい。
１３０６において、１３０４で生成された高度化クエリプランが実行され得る。上述のように、クエリプランでは１つ以上の述語条件を１つ以上のオペレーションに伝搬するので、高度化クエリプランは、より高速で（すなわち、より短い時間を用いて）実行されるとともに、多くの場合、オリジナルの非高度化クエリプランよりも少ないメモリリソースを使用し得る。
１３０８において、１３０６で高度化クエリプランを実行した結果データベースから取り出されたファクトレコードは、オリジナルのクエリプランおよび高度化クエリプランが生成されたクエリに対する応答として出力され得る。図１Ｂに示す実施形態では、１３０６および１３０８の処理はエグゼキュータ１０５によって実行され得る。
図１３Ｂは、特定の実施形態に従った高度化クエリプランを生成する方法を示す簡略フローチャート１３２０である。図１３Ｂの処理は、それぞれのシステムの１つ以上の処理ユニット（たとえばプロセッサ、コア）によって実行されるソフトウェア（たとえばコード、命令、プログラム）、ハードウェア、またはそれらの組み合わせで実現することができる。ソフトウェアは非一時的な記憶媒体（たとえばメモリデバイス）に格納されていてもよい。図１３Ｂに示されるとともに以下で説明される方法は、限定ではなく例示を意図している。図１３Ｂは特定のシーケンスまたは順序で行われるさまざまな処理ステップを示すが、これは限定を意図したものではない。特定の代替的実施形態において、ステップはいくつかの異なる順序で実行されてもよく、いくつかのステップは並列に実行されてもよい。
特定の実施形態では、図１３Ｂに示す処理は、図１３Ａの１３０４において実行される処理の一部として実行されてもよい。図１Ｂに示される実施形態について、図１３Ｂに示される処理はエンハンサ１０３によって実行されてもよい。エンハンサ１０３への入力は、クエリのために生成されたオリジナルのクエリプラン、たとえば、ＳＱＬクエリのために生成されたＳＱＬクエリプラン、を含む。エンハンサ１０３はまた、リレーショナルスキーマ、スタースキーマ定義、テーブルの列間の機能依存性、スタースキーマ上のＯＬＡＰインデックスなどのデータの利用可能な物理的構造などについての情報などのメタデータ情報およびスキーマ情報にアクセスできる。図１３Ｂおよび付随する説明のために、メタデータおよびスキーマ情報はメタ店舗に格納されているものと想定される。図１３Ｂに示される処理の出力は、オリジナルのクエリプランよりも高速で実行されるとともに、多くの場合、オリジナルのクエリプランよりも少ないリソースを用いる一方で、オリジナルのクエリプランと同じ結果を返す高度化クエリプランである。上述したように、高度化クエリプランは、オリジナルのクエリプランよりも少ない数のファクトレコードを処理するのでオリジナルのクエリプランよりも高速で実行され、および／または、高度化クエリプランにおけるファクトレコードを処理するコストは、ファクトレコードがより効率的に処理されるのでオリジナルのクエリプランよりも少なくなる。
図１３Ｂに示されるように、１３２２において、オリジナルのクエリプランを分析して、オリジナルのクエリプランにおけるファクトテーブルを識別する。これは多種多様な技術を用いて実行され得る。たとえば、オリジナルのクエリプランにおけるファクトテーブルは、クエリレベルまたはセッション／接続レベルにおけるユーザヒント、および他の技術を通じて、オリジナルのクエリプランにおけるテーブルをメタ店舗におけるファクトテーブルと照合することによって識別されてもよい。
１３２４において、１３２２において識別された各ファクトテーブルごとに、オリジナルのクエリプランにおいて、識別されたファクトテーブル上のすべてのファクトスキャンオペレータに対して、クエリプランウォークが実行されて、このファクトスキャンオペレータとの確認結合のセットを演算するとともに、任意の適用可能な次元コンテキスト述語条件を識別／推論する。特定の実施形態では、オリジナルのクエリプランにおけるファクトテーブルスキャンオペレータのウォークは、ファクトスキャンオペレータから開始され、オリジナルのクエリプランのルートノードに到達するまでオリジナルのクエリプランを詳細に検討することを含む。たとえば、図３に示すクエリプランの場合、サブプラン３０２におけるStore_Returnsファクトテーブルスキャンオペレーションのウォークは、このノード３２０から開始され、その祖先ノードのすべて（ノード３２２、ノード３２４、ノード３０６からルートノード３２６まで）を訪問することを含む。
ウォーク中にファクトテーブルのためのファクトスキャンオペレーションについての適用可能な次元コンテキスト述語条件を識別／推論するために、エンハンサ１０３は、訪問された各々のノードオペレーション／オペレータの出力の「グレイン」を維持する。クエリプランにおける任意のリレーショナルオペレータの出力は演算されたデータセットである。任意のテーブル（ベースデータセット）または演算されたデータセットの「グレイン」はそのスキーマにおける次元列のセットである。ファクトテーブルの場合、そのグレインは、関連付けられたすべての次元キーを含む。たとえば、図４において、Store_Returnsのグレインは、Date_key、Item_key、Store_key、Customer_keyである。さらに、すべての次元について、すべての属性は、キー属性によって機能的に決定可能であるので、ファクトテーブルのグレインにおいて有効である。従って、たとえば、Year（年）、Quarter（四半期）、Month（月）等は、Date_keyによって決定可能であるので、Store_Returnsグレインにおいて有効である。同様の論拠を適用すると、図４のすべての次元列はStore_Returnsテーブルのグレインにおいて有効である。
ここで図３において、アグリゲータオペレーション／オペレータ３２４は、Customer_key、Store_keyによる行を出力し、このため、オペレーション３２４によって定義されるデータセットのグレインはStore_key、Customer_keyである。しかし、ここでも、機能依存性により、すべてのCustomer（顧客）列およびStore（店舗）列は、そのグレインにおいて有効である。したがって、ファクトテーブルStore_Returnsの場合、スキーマ：（Cust_Name，Item_Category，Store_Name，Qty）を用いて図４に示すスタースキーマに関して定義されたデータセットは、（Cust_Name， Stream_Category，Store_Name）のグレインを有し得る。
ウォークの開始時に、ファクトスキャンオペレーションのためのファクトテーブルについてのグレインは、ファクトテーブルの関連する次元におけるすべての属性である。したがって、図３では、サブプラン３０２におけるStore_Returnsについて、これは、Date（日付け）、Item（商品）、Store（店舗）、およびCustomer（顧客）の次元テーブルからのすべての列となる可能性があるとともに、Customer_Address次元テーブルからの副次的なCustomer（顧客）属性が含まれている。これは、図４のファクトテーブルについて定義されているスタースキーマに基づいている。
１３２４におけるウォーク中、Join（結合）オペレーションに対応するノードに遭遇すると、特別な処理が実行される。これは、ファクトテーブルとの確認結合を捕捉することと、Join（結合）の「他方側」からファクトスキャンオペレーション側または「ファクト側」に伝搬され得る適用可能なコンテキストを推論しようと試みることとを伴う。たとえば、図３において、Join（結合）オペレーションノード３２２の場合、ファクト側がStore_Returnsノード３２０であり得るとともに、他方側がFilter（フィルタ）オペレーションノード３２８であり得る。別の例として、図３において、ノード３０６の場合、ファクト側は左側のサブツリー３０２であり、他方側は右側のサブツリー３１２である。
確認結合は、結合がファクト側のグレインを変化させないことを暗示している。たとえば、最も一般的な確認パターンの一つとして、スタースキーマにおけるエッジについての条件と同じ結合条件がある。したがって、図４に示すスタースキーマを伴うクエリの場合、結合は、Store_ReturnsとStore_keyについてのStore（店舗）との間、または、Store_ReturnsとCustomer_keyとの間などでなければならない。対照的に、非確認結合の例は、Store_Returns実体化（実体化されたビューまたはＯＬＡＰインデックスなど）とcustomer_nameについてのCustomer（顧客）との間、または、Store_Returnsとstore_nameについてのStore_Rentテーブルとの間の結合を含み得る。このStore_Rentはスタースキーマの一部ではない。
確認結合に遭遇すると、推論論理は次に、確認結合についのて以下の追加条件をチェックする。ファクト側グレインは、結合されている次元グレインを含んでいなければならない。これに該当する場合、結合グレインによって機能的に決定される結合の他方側の任意のコンテキスト（述語条件）は、ファクト側、したがってファクトテーブルに適用可能である。たとえば、図３に示されるクエリプランの場合、最も左側の「Join on Date Key」ノード３２２の場合、Join（結合）オペレータの左側のファクト側サブツリーは、グレイン「Customer（顧客），Item（商品），Date（日付け），Store（店舗）」を有しており、他方側の結合はDate（日付け）次元にある。従って、これは、Date Keyのグレインでの確認結合である。すべてのDate（日付け）属性は、Date_keyによって決定することができるので、Year（年）についての述語は、ノード３２０によって表現されるファクトテーブルStore_Returnsについてのファクトスキャンオペレーションに伝搬することができる。同様の分析を、サブプラン３１２におけるStore_Returnsについてのファクトスキャンオペレーションのために実行することができる。
適用可能なグレインに関する情報は、ウォーク中に維持されて更新される。初めに、グレインにおけるすべてのDimension（次元）属性が識別される。集約オペレーション／オペレータ（たとえば、図３におけるノード３２４および３３０）を詳細に検討すると、グレインがグループ分けの列に変化する。たとえば、図３において、ノード３２４において集約オペレーション／オペレータを詳細に検討すると、グレインは（Customer_key，Store_key）になる。特定の実施形態では、クエリプランにおいて見出されるさまざまな種類のリレーショナルオペレーション／オペレータを詳細に検討してグレインがどのように修正されるかについてのルールが構成されて維持される。
１３２４におけるウォークの一部として、各ファクトテーブルスキャンオペレータごとに、関与する結合テーブルとの確認結合のリスト、そのファクトスキャンオペレーションのために識別または推論された適用可能な１つ以上の次元コンテキスト述語条件のリストを含む情報がエンハンサ１０３によって維持される。ファクトスキャンオペレーションのためのウォークの終了時に、ウォークされているファクトスキャンオペレータは、適用可能な１つ以上の次元コンテキスト（述語条件）および確認結合の候補リストを有している。
１３２６において、述語条件の推移的なファクト間の推論が実行される。この処理は、同じファクトまたは異なるファクトにわたる述語条件の推移的推論を伴う。ファクトスキャンオペレータの対（たとえば「ｆｓ１」（ファクトテーブルｆｔ１についてのファクトスキャン）および「ｆｓ２」（ファクトテーブルｆｔ２についてのファクトスキャン））ごとに、エンハンサ１０３は、Ｄ１がｆｔ１およびｆｔ２の両方のスタースキーマにあるように、結合条件が結合属性Ｄ１．ｊａを有する次元Ｄ１に対するものになるような結合オペレータを捜す。
たとえば、図１２Ｂにおいて、
− ｆｓｌは、Store_Retunsスキャン（ボックス１２２４）であり、
− ｆｓ２は、Store_Salesスキャン（ボックス１２２６）であり、
− ２つのファクトテーブルを結合する結合はノード１２３２であり、
− 共通次元Ｄ１はStore（店舗）次元であり、
− 結合はStore（店舗）のStore_key属性にある。
このようなパターンを見つけると、関与する両方のファクトテーブルが結合属性Ｄｌ．ｊａのグレインにある場合、エンハンサ１０３は、ｆｓ１からｆｓ２への（逆の場合も同様に可能）結合グレインによって機能的に決定される次元Ｄ１についての任意の推論された次元コンテキストを伝搬することができる。したがって、図１２Ｂでは、Store_Returnsスキャン（ボックス１２２４）からの推論されたコンテキスト述語条件「State（州）＝ＴＮ」は、ボックス１２３２におけるStore_keyについての結合によりStore_Salesスキャン（ノード１２２６）に伝搬され得る。このようなファクト間の推論は推移的であるので、次元コンテキストは、ｆｓ１（ｆｔ１上）からｆｓ２（ｆｔ２上）に、さらにはｆ３（ｆｔ３上）等に伝搬することができる。
１３２８において、述語条件の推移的な次元とファクトとの間の推論が実行される。スタースキーマはスノーフレークスキーマであり得るので、スタースキーマにおける次元テーブルからファクトテーブルまでの結合経路の長さは１以上であり得る。１３２８における処理は、図１７に示されるスキーマ１７００を用いて説明され得る。図１７において、Store_Returnsはファクトテーブルであり、他のテーブルはすべての次元テーブルである（なお、スキーマ１７００は、図４に示されるスキーマ４００をわずかに変形させた例であることに留意されたい）。図４において、Income_Bandは、４テーブル結合（Income_Band join Customer_Demographics join Customer join Store_Returns）を通じてのみStore_Returnsに関連付けられている。Income_Band属性を含むStore_Returnsの物理的表現、たとえば、income_upper_bound属性を含むStore_ReturnsについてのＯＬＡＰインデックス、が存在する場合、income_upper_bound述語をこれに適用することも可能であり得る。ＯＬＡＰインデックスファクトソースに対するincome_upper_boundコンテキスト（述語）の適用をエンハンサ１０３が推論するために、これは、Income_Band次元テーブルをファクトテーブルに接続する３つの結合（Income_Band join Customer_Demographic, Customer_Demographic join Customer, Customer join Store_returns）によって伝搬しなければならない。これは、ファクトスキャンオペレータの確認結合のリストを再帰的に構築することによって行われてもよく、新しい適用可能な確認結合に遭遇するたびに、１３２４と同様に他方側から任意の利用可能な次元コンテキストを伝搬する試みが行われる。
１３３０において、１つ以上の推論された次元コンテキスト述語条件が適用され、ファクトスキャンオペレーションに関連付けられる。このポイントにより、適用可能であれば、オリジナルのクエリプランにおいて識別される各ファクトテーブルスキャンオペレーション／オペレータ（または一般に、ファクトソーススキャンオペレーション）が、１つ以上の適用可能な次元コンテキスト述語条件のリストまたはセットに関連付けられる。１３３０における処理の一環として、ファクトスキャンオペレーションごとに識別された述語条件は、それらの純便益に基づいて順序付けられる。この場合、述語条件に関する純便益は、述語条件を適用した後にファクト行を処理するコストから述語条件を適用するコストを差引いた減少分である。
したがって、１３３０の一環として、ファクトスキャンオペレーションごとに、そのファクトスキャンオペレーションのために決定された適用可能な述語条件のリスト内の各述語条件について、エンハンサ１０３によって純便益メトリックが演算され得る。エンハンサ１０３は、純便益メトリックを演算するため、および以下のような順序付けを実行するために、いくつかの要因を考慮に入れてもよい。
− ＯＬＡＰインデックスにおけるファクトおよび列についてのＯＬＡＰインデックスの利用可能性などのファクトの利用可能な物理的表現。なお、すべての次元列がＯＬＡＰインデックスにある必要はないことに留意されたい。
− 推論された次元コンテキストの選択性；選択性の高い述語は選択性の低い述語よりも好ましい。
− 次元コンテキスト述語条件を適用するコスト。たとえば、ＯＬＡＰインデックススキャンへの述語のプッシュは、追加のコストをほとんど引起こさないので好ましい；Index Semi Join（インデックスセミ結合）は従来のSemi-Join（セミ結合）よりも好ましい。なぜなら、Index Semi Join（インデックスセミ結合）は、インデックススキャンオペレーション／オペレータにおいて非常に効率的なスキップスキャンを行う能力を活用するからである。
１３３０の一環として、順序付けの後、ファクトスキャンオペレーションごとに、述語条件のリストからの１つ以上の述語条件が、順序付けに基づいてファクトスキャンに関連付けるために決定される。特定の実施形態では、ファクトスキャンオペレーションのために、最適なプラスの純便益を提供するリストからの述語条件がファクトスキャンオペレーションに関連付けられるように選択される。
特定の実施形態では、ファクトスキャンオペレーションのために、そのファクトスキャンオペレーションについての述語条件の順序付けられたリストからの２つ以上の述語条件がファクトスキャンオペレーションに関連付けられてもよい。このようなシナリオでは、最高の純便益を提供する述語条件がファクトスキャンオペレーションに関連付けられた後、順序付けられたリストにおける追加の述語条件ごとに、次に最適な純便益を提供する述語条件から開始して、純便益分析が行われるが、この分析は、追加の述語条件がファクトスキャンオペレーションに関連付けられるべきかどうかを判断するために、当該追加の述語条件と、そのファクトスキャンオペレーションについての事前に関連付けられたすべての述語条件との関連付けを考慮して行なわれる。複数の述語条件がファクトスキャンオペレーションに関連付けられると、追加の述語条件を適用することの利点が、典型的には、関連付けられる述語条件の数と共に減少する。
１３３０における処理の後、特定のファクトスキャンオペレーションのために、そのファクトスキャンオペレーションに適用可能であると識別された１つ以上の述語条件がいずれも純便益を提供しない可能性がある。この場合、そのファクトスキャンオペレーションにはどの述語条件も関連付けられない可能性がある。
１３３２において、エンハンサ１０３は、ファクトスキャンオペレーションに関連付けられた既存の述語条件に基づいてクエリプランにおける１つ以上のファクトスキャンオペレーションについての新しいいずれかの１つ以上の述語条件を推論することによって、クエリプランの実行がさらに最適化され得るかどうかを判断する処理を実行する。ファクトスキャンオペレーションについての既存の述語条件は、オリジナルのクエリプランにおけるファクトスキャンオペレーションに関連付けられた述語条件（オリジナルの述語条件）、および／または、１３３０で実行された処理後のファクトスキャンオペレーションに関連付けられた述語条件であってもよい。したがって、１３３２において実行される処理の一環として、エンハンサ１０３は、新しい述語条件がオリジナルの述語条件よりもファクトスキャンオペレーションのためにより高い純便益を提供する場合、ファクトスキャンオペレーションに関連付けられたオリジナルの述語条件に基づいて新し変換済みの述語条件を見つけ出そうと試みてもよい。同様に、１３３０におけるファクトスキャンオペレーションに関連付けられた述語条件に関して、エンハンサ１０３は、新しい述語条件の方が１３３０におけるファクトスキャンオペレーションに関連付けられた述語条件よりもファクトスキャンオペレーションのためにより高い純便益を提供する場合、関連付けられた述語条件に基づいて新しい変換済みの述語条件を見つけ出そうとを試みてもよい。
特定の実施形態では、１３２２の一環として、エンハンサ１０３は、次元属性間の機能依存性に基づいて、識別された／推論された述語から暗示される述語を見つけ出そうと試みる。たとえば、図３に示されるクエリプランの場合、図５のボックス５０２において、左側のStore_Returnsに対する述語条件「State（州）＝ＴＮ」の適用が示される。この「State（州）＝ＴＮ」の適用は、場合によっては利用可能なＯＬＡＰインデックスがState（州）属性を持たなかったせいで、コスト効率が良くなかったと想定される。この場合、エンハンサ１０３は、以下のメタデータ情報を用いて新しい述語条件を推論し得る。
− State（州）列およびCity（市）列が階層にあり、
− 「ＴＮ」がデータベースに列挙された２つの市だけを有し、
− City（市）列がＯＬＡＰインデックスにある。
上述の情報を用いることで、「State（州）＝ＴＮ」次元コンテキストが「City（市）＝Memphis（メンフィス）またはCity（市）＝Nashville（ナッシュビル）」として適用され得ることが推論される可能性があり得る。この場合、推論された述語条件の適用は、非常に高速のＯＬＡＰインデックススキャンを伴う。この推論された述語条件の適用は、高度化クエリプラン全体の実行に対する純便益を提供することができる。変換済みの述語条件の別の例が、図９に示されるとともに上述されている。
特定の実施形態では、１３２２における処理は、以下の場合にのみクエリプランにおけるファクトスキャンオペレーションのために実行される。以下の場合とは、すなわち、ファクトスキャンオペレーションに関連付けられたオリジナルの述語条件が（すなわち、オリジナルのクエリプランに）ない場合、少なくとも１つの述語条件が、１３２４、１３２６および１３２８において実行される処理に基づいてファクトスキャンオペレーションとの関連付けに適格な述語条件のリストにおいて識別された場合、ならびに、１３３０で実行された処理に基づいて、ファクトスキャンオペレーションについて判断されたリスト内の述語条件がいずれもプラスの純便益を提供せず、このため、１３３０においてファクトスキャンオペレーションに関連付けられなかったと判断された場合、を含む。このようなシナリオでは、このような変換済みの新しい述語条件のいずれかがファクトスキャンオペレーションに対してプラスの純便益を提供するかどうかを調べるために、エンハンサ１０３は、ファクトスキャンオペレーションのために識別される述語条件のリスト内の１つ以上の述語条件に対して１３３２における処理を実行してもよい。このような変換済みの新しい述語条件が見つけ出された場合、この条件が、１３３２において、エンハンサ１０３によってファクトスキャンオペレーションに関連付けられてもよい。しかしながら、これは限定するよう意図されたものではない。他のいくつかの実施形態では、１３３２における処理は、１３３０におけるファクトスキャンオペレーションに関連付けられた任意のオリジナルの述語条件および／または任意の述語条件のために実行されてもよい。
１３３４において、高度化クエリプランは、１つ以上のファクトスキャンオペレーションに関連付けられた１つ以上の述語条件を有するオリジナルのクエリプランに基づいて、生成される。特定の実施形態では、高度化クエリプランにおいて、１つ以上のファクトスキャンオペレーションに関連付けられるように識別された１つ以上の述語条件がファクトスキャンオペレーションに実際に関連付けられるように、オリジナルのクエリプランが高度化クエリプランとして書換えられる。したがって、高度化クエリプランが１３０８においてクエリ実行の一環として実行されると、関連付けられた述語条件は、それらが関連付けられるファクトスキャンオペレーションに対して評価される。
本明細書中に開示される教示に基づいて生成される高度化クエリプランは、従来の技術に勝るいくつかの利点を提供する。上述のように、ＳＱＬクエリなどの分析クエリは、典型的には、複数の次元に対する計算を含み、次元の関連付けをナビゲートすることによって組合わされる１つ以上のファクトテーブルに対する計算の複数層を伴う。一例として、次元の関連付けの一般的な例は、Year（年）−Quarter（四半期）−Month（月）またはCountry（国）−State（州）−City（市）などのような階層である。図３に示される例において、サブプラン３０２は、各Store（店舗）におけるCustomer（顧客）のStore Returns（店舗への返品）についての計算を含み、サブプラン３１２は、Store（店舗）のすべてのCustomer（顧客）のためにStore（店舗）における集約返品についての計算を含む。ノード３０６では、これらの２つが組合わされて、「問題」となる顧客を発見する。テラバイト（さらにはそれ以上）の規模での、データベースを超えるこのような多層計算は、極めて計算集約的であり、「think-time」内に任意のクエリに応答することは非常に難しい。本明細書中に開示されるさまざまな発明技術は、ＯＬＡＰインデックス付け、およびスケールアウト・シェアードナッシング・アーキテクチャを含むがこれらに限定されない、このようなスケールでのアドホッククエリのための対話型経験を可能にする分析プラットフォームを提供する。本明細書中で説明される分析プラットフォームは、非常に大きな（テラバイト以上の）多次元データ（たとえば、データレーキに格納されたデータ）に対して、非常にコスト効率良く、対話型アドホッククエリを実行する能力を提供する。従来の技術を用いて過去に非常に大きな（テラバイト以上の）多次元データに対してこのような対話型アドホッククエリを実行することは、法外な費用がかかるものであって、スケーリングしていなかった。
クエリの場合、しばしば、アナリストの意図は、広大な多次元空間の小さな領域に焦点を合わせることである。たとえば、図３では、分析の焦点はテネシーの州に合わされている。しかし、ＳＱＬのようなクエリ言語では、この分析コンテキストは不明瞭になる可能性がある。なぜなら、関係代数オペレータを用いてこのような多次元計算を書き込むことは厄介であるからである。さらなるＳＱＬ書き込みは、しばしば、ＳＱＬジェネレータツールを介して、またはドメインエキスパートではないデータエンジニアによって行われる。これらの目標は、正しい回答を与えるＳＱＬを生成することである。これらは、不要なファクト処理を回避するクエリプランをＳＱＬクエリエンジンが生成することを容易にする態様で「テネシーの州」についての分析のようなセマンティック情報を搬送することには関係していない。従来のリレーショナルクエリオプティマイザはリレーショナルスキーマで動作するものであって、このため、分析質問がどのように表現されるかに基づく非常に有益な多次元キューブセマンティックモデルについての知識に欠けている。すべてのアナリストは自身の頭の中にこのモデルを記憶している。本明細書に開示される分析プラットフォームは、多次元キューブセマンティックモデルにおいて定義される関係を活用することによって、エンジニアに、分析のコンテキストをクエリプランの構造から反転させる処理を実行する。多くの場合、これにより、ファクトを処理するのに必要なリソースを大幅に削減する適用可能な次元コンテキスト（述語条件）が推論されることとなる。サイズが大きいデータスケール（たとえば、テラバイトスケール）では、さらにこれを超える大きさでは、ファクト処理コストの削減は、この明細書中で説明するように、アドホッククエリを対話的に処理する能力に大きな影響を及ぼす。
上述したように、分析クエリをより効率的に実行するための分析プラットフォームが提供される。特定の実施形態では、Ａｐａｃｈｅ Ｓｐａｒｋネイティブ分析プラットフォームが提供される。分析クエリ（たとえば、ＳＱＬクエリ）のために生成されるクエリプランは、最適化されるとともに高度化されたクエリプランを作成するように最適化される。ビジネスデータおよびビジネスインテリジェンスデータなどのセマンティクス情報は、高度化クエリプランを生成するために用いられる。ドメインセマンティクスは、より効率的なクエリプランを生成するために用いられる。ビジネスセマンティクスは、クエリ実行最適化に用いられる。
性能の観点から、高度化クエリプランは、（実行を完了するために必要なＣＰＵサイクルがより少ないため）より高速で実行され、多くの場合、非高度化クエリプランよりも、用いるメモリリソースが少なくて済む可能性がある。クエリプランを書換えた結果、対応するクエリは、書換え前よりも桁違い（たとえば、１０倍、２５倍、１００倍など）に高速で実行することができる。これは、ファクトテーブルが次元テーブルよりも桁違いに大きく、したがって、ファクトレコードを処理することに関連するスキャンコストを削減することで、性能利得が莫大になるからである。
前述したように、本明細書中に記載される分析プラットフォームは、Ｓｐａｒｋクラスタを用いてＡｐａｃｈｅ Ｓｐａｒｋネイティブソリューションとして実現され得る。したがって、Ａｐａｃｈｅ Ｓｐａｒｋおよびそのエコシステム、たとえば、コアコンポーネント、スケールイン・アウトメモリランタイム、触媒コンポーネント、ＪＤＢＣ、メタ店舗等のパワーを十分に利用している。
本明細書中に説明されるように、高度化クエリプランによってファクトレコードを処理およびスキャンするコストが非高度化クエリプランと比較して削減される最適化クエリプランを生成するための技術が説明される。分析活動は、しばしば、データセット全体ではなく、特定のサブ集団またはサブコンテキストに焦点を合わされている。セマンティクス情報からクエリに適用可能なコンテキストを推論し、（たとえば、コンテキストまたは述語条件伝搬によって）当該コンテキストをクエリプランに適用することにより、クエリプランと、結果として当該クエリプランが生成されるクエリとの実行について大幅な性能向上をもたらし得る。分析ドメインまたは分析活動に拘わらず、分析のコンテキストを判断するために識別され得る共通のパターンが存在する。特定の実施形態では、これらのパターンを識別するとともに、最適化された高度化クエリプランを生成するための技術が提供される。
図１４は、ある実施形態を実現するための分散型システム１４００の簡略図を示す。図示される実施形態において、分散型システム１４００は、１つ以上の通信ネットワーク１４１０を介してサーバ１４１２に結合された１つ以上のクライアントコンピューティングデバイス１４０２、１４０４、１４０６、および１４０８を含む。クライアントコンピューティングデバイス１４０２、１４０４、１４０６、および１４０８は、１つ以上のアプリケーションを実行するように構成され得る。
さまざまな実施形態において、サーバ１４１２は、上述の分析クエリの実行を可能にする１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合され得る。
特定の実施形態では、サーバ１４１２はまた、非仮想環境および仮想環境を含み得る他のサービスまたはソフトウェアアプリケーションを提供し得る。いくつかの実施形態では、これらのサービスは、クライアントコンピューティングデバイス１４０２、１４０４、１４０６および／または１４０８のユーザに対して、サービスとしてのソフトウェア（Software as a Service：ＳａａＳ）モデルのようなウェブベースのサービスまたはクラウドサービスとして提供され得る。クライアントコンピューティングデバイス１４０２、１４０４、１４０６および／または１４０８を操作するユーザは、１つ以上のクライアントアプリケーションを利用してサーバ１４１２とやり取りすることで、これらのコンポーネントによって提供されるサービスを利用し得る。
図１４に示される構成では、サーバ１４１２は、サーバ１４１２によって実行される機能を実現する１つ以上のコンポーネント１４１８、１４２０および１４２２を含み得る。これらのコンポーネントは、１つ以上のプロセッサ、ハードウェアコンポーネント、またはそれらの組合わせによって実行され得るソフトウェアコンポーネントを含み得る。分散型システム１４００とは異なり得る多種多様なシステム構成が可能であることが認識されるはずである。したがって、図１４に示される実施形態は、実施形態のシステムを実現するための分散型システムの一例であり、限定するよう意図されたものではない。
ユーザは、クライアントコンピューティングデバイス１４０２、１４０４、１４０６および／または１４０８を用いて、本開示の教示に従って分析クエリを提出してもよい。クライアントデバイスは、当該クライアントデバイスのユーザが当該クライアントデバイスと対話することを可能にするインターフェイスを提供し得る。クライアントデバイスはまた、このインターフェイスを介してユーザに情報を出力してもよい。たとえば、クエリ結果は、クライアントデバイスによって提供されるインターフェイスを介してユーザに出力され得る。図１４は４つのクライアントコンピューティングデバイスだけを示しているが、任意の数のクライアントコンピューティングデバイスがサポートされ得る。
クライアントデバイスは、ポータブルハンドヘルドデバイス、パーソナルコンピュータおよびラップトップのような汎用コンピュータ、ワークステーションコンピュータ、ウェアラブルデバイス、ゲームシステム、シンクライアント、各種メッセージングデバイス、センサまたはその他のセンシングデバイスなどの、さまざまな種類のコンピューティングシステムを含み得る。これらのコンピューティングデバイスは、さまざまな種類およびバージョンのソフトウェアアプリケーションおよびオペレーティングシステム（たとえばＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）、ＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステム、Ｌｉｎｕｘ（登録商標）またはＬｉｎｕｘ系オペレーティングシステム、たとえば、各種モバイルオペレーティングシステム（たとえばＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ（登録商標）、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、ＢｌａｃｋＢｅｒｒｙ（登録商標）、Ｐａｌｍ ＯＳ（登録商標））を含むＧｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳ）を含み得る。ポータブルハンドヘルドデバイスは、セルラーフォン、スマートフォン（たとえばｉＰｈｏｎｅ（登録商標））、タブレット（たとえばｉＰａｄ（登録商標））、携帯情報端末（ＰＤＡ）などを含み得る。ウェアラブルデバイスは、Ｇｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイおよびその他のデバイスを含み得る。ゲームシステムは、各種ハンドヘルドゲームデバイス、インターネット接続可能なゲームデバイス（たとえばＫｉｎｅｃｔ（登録商標）ジェスチャ入力デバイス付き／無しのＭｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）ゲーム機、Ｓｏｎｙ ＰｌａｙＳｔａｔｉｏｎ（登録商標）システム、Ｎｉｎｔｅｎｄｏ（登録商標）が提供する各種ゲームシステムなど）を含み得る。クライアントデバイスは、各種インターネット関連アプリケーション、通信アプリケーション（たとえばＥメールアプリケーション、ショートメッセージサービス（ＳＭＳ）アプリケーション）のような多種多様なアプリケーションを実行可能であってもよく、各種通信プロトコルを使用してもよい。
ネットワーク１４１０は、利用可能な多様なプロトコルのうちのいずれかを用いてデータ通信をサポートできる、当該技術の当業者には周知のいずれかの種類のネットワークであればよく、上記プロトコルは、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、ＡｐｐｌｅＴａｌｋ（登録商標）などを含むがこれらに限定されない。単に一例として、ネットワーク１４１０は、ローカルエリアネットワーク（ＬＡＮ）、Ｅｔｈｅｒｎｅｔ（登録商標）に基づくネットワーク、トークンリング、ワイドエリアネットワーク（ＷＡＮ）、インターネット、仮想ネットワーク、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば電気電子学会（ＩＥＥＥ）８０２．１１プロトコルスイートのいずれかの下で動作する無線ネットワーク、Ｂｌｕｅｔｏｏｔｈおよび／または任意の他の無線プロトコル）、および／またはこれらおよび／または他のネットワークの任意の組み合わせを含み得る。
サーバ１４１２は、１つ以上の汎用コンピュータ、専用サーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な構成および／または組み合わせで構成されてもよい。サーバ１４１２は、仮想オペレーティングシステムを実行する１つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。これはたとえば、サーバに対して仮想記憶装置を維持するように仮想化できる論理記憶装置の１つ以上のフレキシブルプールなどである。各種実施形態において、サーバ１４１２を、上記開示に記載の機能を提供する１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合させてもよい。
サーバ１４１２内のコンピューティングシステムは、上記オペレーティングシステムのうちのいずれかを含む１つ以上のオペレーティングシステム、および、市販されているサーバオペレーティングシステムを実行し得る。また、サーバ１４１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含むさまざまなさらに他のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかを実行し得る。例示的なデータベースサーバは、Ｏｒａｃｌｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ（登録商標）、Ｓｙｂａｓｅ（登録商標）、ＩＢＭ（登録商標）（International Business Machines）などから市販されているものを含むが、それらに限定されない。
いくつかの実現例において、サーバ１４１２は、クライアントコンピューティングデバイス１４０２、１４０４、１４０６および１４０８のユーザから受信したデータフィードおよび／またはイベントアップデートを解析および整理統合するための１つ以上のアプリケーションを含み得る。一例として、データフィードおよび／またはイベントアップデートは、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通モニタリングなどに関連するリアルタイムのイベントを含んでもよい、１つ以上の第三者情報源および連続データストリームから受信される、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）アップデートまたはリアルタイムのアップデートを含み得るが、それらに限定されない。サーバ１４１２は、データフィードおよび／またはリアルタイムのイベントをクライアントコンピューティングデバイス１４０２、１４０４、１４０６および１４０８の１つ以上の表示デバイスを介して表示するための１つ以上のアプリケーションも含み得る。
分散型システム１４００はまた、１つ以上のデータリポジトリ１４１４、１４１６を含み得る。特定の実施形態において、これらのデータリポジトリを用いてデータおよびその他の情報を格納することができる。たとえば、データリポジトリ１４１４、１４１６のうちの１つ以上を用いて、データベースデータ、メタデータなどを格納することができる。データリポジトリ１４１４、１４１６は、さまざまな場所に存在し得る。たとえば、サーバ１４１２が使用するデータリポジトリは、サーバ１４１２のローカル位置にあってもよく、またはサーバ１４１２から遠隔の位置にあってもよく、ネットワークベースの接続または専用接続を介してサーバ１４１２と通信する。データリポジトリ１４１４、１４１６は、異なる種類であってもよい。特定の実施形態において、サーバ１４１２が使用するデータリポジトリは、データベース、たとえば、Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）および他の製造業者が提供するデータベースのようなリレーショナルデータベースであってもよい。これらのデータベースのうちの１つ以上を、ＳＱＬフォーマットのコマンドに応じて、データの格納、アップデート、およびデータベースとの間での取り出しを可能にするように適合させてもよい。
特定の実施形態では、データレポジトリ１４１４、１４１６のうちの１つ以上は、アプリケーションデータを格納するためにアプリケーションによって用いられてもよい。アプリケーションが使用するデータリポジトリは、たとえば、キー値ストアリポジトリ、オブジェクトストアリポジトリ、またはファイルシステムがサポートする汎用ストレージリポジトリのようなさまざまな種類のものであってもよい。
特定の実施形態において、本開示に記載される機能により提供される分析プラットフォームは、クラウド環境を介してサービスとして提供され得る。図１５は、特定の実施形態に係る、各種サービスをクラウドサービスとして提供し得るクラウドベースのシステム環境の簡略化されたブロック図である。図１５に示される実施形態において、クラウドインフラストラクチャシステム１５０２は、ユーザが１つ以上のクライアントコンピューティングデバイス１５０４、１５０６および１５０８を用いて要求し得る１つ以上のクラウドサービスを提供し得る。クラウドインフラストラクチャシステム１５０２は、サーバ１４１２に関して先に述べたものを含み得る１つ以上のコンピュータおよび／またはサーバを含み得る。クラウドインフラストラクチャシステム１５０２内のコンピュータは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、またはその他任意の適切な配置および／または組み合わせとして編成され得る。
ネットワーク１５１０は、クライアント１５０４、１５０６、および１５０８と、クラウドインフラストラクチャシステム１５０２との間におけるデータの通信および交換を容易にし得る。ネットワーク１５１０は、１つ以上のネットワークを含み得る。ネットワークは同じ種類であっても異なる種類であってもよい。ネットワーク１５１０は、通信を容易にするために、有線および／または無線プロトコルを含む、１つ以上の通信プロトコルをサポートし得る。
図１５に示される実施形態は、クラウドインフラストラクチャシステムの一例にすぎず、限定を意図したものではない。なお、その他いくつかの実施形態において、クラウドインフラストラクチャシステム１５０２が、図１５に示されるものよりも多くのコンポーネントもしくは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、または、異なる構成または配置のコンポーネントを有していてもよいことが、理解されるはずである。たとえば、図１５は３つのクライアントコンピューティングデバイスを示しているが、代替実施形態においては、任意の数のクライアントコンピューティングデバイスがサポートされ得る。
クラウドサービスという用語は一般に、サービスプロバイダのシステム（たとえばクラウドインフラストラクチャシステム１５０２）により、インターネット等の通信ネットワークを介してオンデマンドでユーザにとって利用可能にされるサービスを指すのに使用される。典型的に、パブリッククラウド環境では、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客自身のオンプレミスサーバおよびシステムとは異なる。クラウドサービスプロバイダのシステムは、クラウドサービスプロバイダによって管理される。よって、顧客は、別途ライセンス、サポート、またはハードウェアおよびソフトウェアリソースをサービスのために購入しなくても、クラウドサービスプロバイダが提供するクラウドサービスを利用できる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションをホストし得るとともに、ユーザは、アプリケーションを実行するためにインフラストラクチャリソースを購入しなくても、インターネットを介してオンデマンドでアプリケーションをオーダーして使用し得る。クラウドサービスは、アプリケーション、リソースおよびサービスに対する容易でスケーラブルなアクセスを提供するように設計される。いくつかのプロバイダがクラウドサービスを提供する。たとえば、ミドルウェアサービス、データベースサービス、Ｊａｖａ（登録商標）クラウドサービスなどのいくつかのクラウドサービスが、カリフォルニア州レッドウッド・ショアーズのＯｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）から提供される。
特定の実施形態において、クラウドインフラストラクチャシステム１５０２は、ハイブリッドサービスモデルを含む、サービスとしてのソフトウェア（ＳａａＳ）モデル、サービスとしてのプラットフォーム（ＰａａＳ）モデル、サービスとしてのインフラストラクチャ（ＩａａＳ）モデルなどのさまざまなモデルを使用して、１つ以上のクラウドサービスを提供し得る。クラウドインフラストラクチャシステム１５０２は、各種クラウドサービスのプロビジョンを可能にする、アプリケーション、ミドルウェア、データベース、およびその他のリソースのスイートを含み得る。
ＳａａＳモデルは、アプリケーションまたはソフトウェアを、インターネットのような通信ネットワークを通して、顧客が基本となるアプリケーションのためのハードウェアまたはソフトウェアを購入しなくても、サービスとして顧客に配信することを可能にする。たとえば、ＳａａＳモデルを用いることにより、クラウドインフラストラクチャシステム１５０２がホストするオンデマンドアプリケーションに顧客がアクセスできるようにし得る。Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）が提供するＳａａＳサービスの例は、人的資源／資本管理のための各種サービス、カスタマー・リレーションシップ・マネジメント（ＣＲＭ）、エンタープライズ・リソース・プランニング（ＥＲＰ）、サプライチェーン・マネジメント（ＳＣＭ）、エンタープライズ・パフォーマンス・マネジメント（ＥＰＭ）、解析サービス、ソーシャルアプリケーションなどを含むがこれらに限定されない。
ＩａａＳモデルは一般に、インフラストラクチャリソース（たとえばサーバ、ストレージ、ハードウェアおよびネットワーキングリソース）を、クラウドサービスとして顧客に提供することにより、柔軟な計算およびストレージ機能を提供するために使用される。各種ＩａａＳサービスがＯｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）から提供される。
ＰａａＳモデルは一般に、顧客が、環境リソースを調達、構築、または管理しなくても、アプリケーションおよびサービスを開発、実行、および管理することを可能にするプラットフォームおよび環境リソースをサービスとして提供するために使用される。Ｏｒａｃｌｅ Ｃｏｒｐｏｒａｔｉｏｎ（登録商標）が提供するＰａａＳサービスの例は、Oracle Java Cloud Service（ＪＣＳ）、Oracle Database Cloud Service（ＤＢＣＳ）、データ管理クラウドサービス、各種アプリケーション開発ソリューションサービスなどを含むがこれらに限定されない。
クラウドサービスは一般に、オンデマンドのセルフサービスベースで、サブスクリプションベースで、柔軟にスケーラブルで、信頼性が高く、可用性が高い、安全なやり方で提供される。たとえば、顧客は、サブスクリプションオーダーを介し、クラウドインフラストラクチャシステム１５０２が提供する１つ以上のサービスをオーダーしてもよい。次いで、クラウドインフラストラクチャシステム１５０２は、処理を実行することにより、顧客のサブスクリプションオーダーで要求されたサービスを提供する。たとえば、システム１５０２は、この開示に記載されるように分析クエリのために機能するように機能する。クラウドインフラストラクチャシステム１５０２を、１つまたは複数のクラウドサービスを提供するように構成してもよい。
クラウドインフラストラクチャシステム１５０２は、さまざまなデプロイメントモデルを介してクラウドサービスを提供し得る。パブリッククラウドモデルにおいて、クラウドインフラストラクチャシステム１５０２は、第三者クラウドサービスプロバイダによって所有されていてもよく、クラウドサービスは一般のパブリックカスタマーに提供される。このカスタマーは個人でも企業でもよい。その他の特定の実施形態において、プライベートクラウドモデルでは、クラウドインフラストラクチャシステム１５０２がある組織内で（たとえば企業組織内で）機能してもよく、サービスはこの組織内の顧客に提供される。たとえば、この顧客は、人事部、給与部などの企業のさまざまな部署であってもよく、企業内の個人であってもよい。その他の特定の実施形態において、コミュニティクラウドモデルでは、クラウドインフラストラクチャシステム１５０２および提供されるサービスは、関連コミュニティ内のさまざまな組織で共有されてもよい。上記モデルの混成モデルなどのその他各種モデルが用いられてもよい。
クライアントコンピューティングデバイス１５０４、１５０６、および１５０８は、異なるタイプであってもよく（たとえば図１４に示されるデバイス１４０２、１４０４、１４０６および１４０８）、１つ以上のクライアントアプリケーションを操作可能であってもよい。ユーザは、クライアントデバイスを用いることにより、クラウドインフラストラクチャシステム１５０２が提供するサービスを要求することなど、クラウドインフラストラクチャシステム１５０２とのやり取りを行い得る。
いくつかの実施形態において、クラウドインフラストラクチャシステム１５０２が、クラウドサービスを提供するために実行する処理は、ビッグデータ解析を含み得る。この解析は、大きなデータセットを使用し、解析し、処理することにより、このデータ内のさまざまな傾向、挙動、関係などを検出し可視化することを含み得る。この解析は、１つ以上のプロセッサが、場合によっては、データを並列に処理し、データを用いてシミュレーションを実行するなどして、実行してもよい。この解析に使用されるデータは、構造化データ（たとえばデータベースに格納されたデータもしくは構造化モデルに従って構造化されたデータ）および／または非構造化データ（たとえばデータブロブ（blob）（binary large object：バイナリ・ラージ・オブジェクト））を含み得る。
図１５の実施形態に示されるように、クラウドインフラストラクチャシステム１５０２は、クラウドインフラストラクチャシステム１５０２が提供する各種クラウドサービスのプロビジョンを容易にするために利用されるインフラストラクチャリソース１５３０を含み得る。インフラストラクチャリソース１５３０は、たとえば、処理リソース、ストレージまたはメモリリソース、ネットワーキングリソースなどを含み得る。
特定の実施形態において、異なる顧客に対しクラウドインフラストラクチャシステム１５０２が提供する各種クラウドサービスをサポートするためのこれらのリソースを効率的にプロビジョニングし易くするために、リソースを、リソースのセットまたはリソースモジュール（「ポッド」とも処される）にまとめてもよい。各リソースモジュールまたはポッドは、１種類以上のリソースを予め一体化し最適化した組み合わせを含み得る。特定の実施形態において、異なるポッドを異なる種類のクラウドサービスに対して予めプロビジョニングしてもよい。たとえば、第１のポッドセットをデータベースサービスのためにプロビジョニングしてもよく、第１のポッドセット内のポッドと異なるリソースの組み合わせを含み得る第２のポッドセットをＪａｖａサービスなどのためにプロビジョニングしてもよい。いくつかのサービスについて、これらのサービスをプロビジョニングするために割り当てられたリソースをサービス間で共有してもよい。
クラウドインフラストラクチャシステム１５０２自体が、クラウドインフラストラクチャシステム１５０２の異なるコンポーネントによって共有されるとともにクラウドインフラストラクチャシステム１５０２によるサービスのプロビジョニングを容易にするサービス１５３２を、内部で使用してもよい。これらの内部共有サービスは、セキュリティ・アイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウィルススキャン・ホワイトリストサービス、高可用性、バックアップリカバリサービス、クラウドサポートを可能にするサービス、Ｅメールサービス、通知サービス、ファイル転送サービスなどを含み得るが、これらに限定されない。
クラウドインフラストラクチャシステム１５０２は複数のサブシステムを含み得る。これらのサブシステムは、ソフトウェア、またはハードウェア、またはそれらの組み合わせで実現され得る。図１５に示されるように、サブシステムは、クラウドインフラストラクチャシステム１５０２のユーザまたは顧客がクラウドインフラストラクチャシステム１５０２とやり取りすることを可能にするユーザインターフェイスサブシステム１５１２を含み得る。ユーザインターフェイスサブシステム１５１２は、ウェブインターフェイス１５１４、クラウドインフラストラクチャシステム１５０２が提供するクラウドサービスが宣伝広告され消費者による購入が可能なオンラインストアインターフェイス１５１６、およびその他のインターフェイス１５１８などの、各種異なるインターフェイスを含み得る。たとえば、顧客は、クライアントデバイスを用いて、クラウドインフラストラクチャシステム１５０２がインターフェイス１５１４、１５１６、および１５１８のうちの１つ以上を用いて提供する１つ以上のサービスを要求（サービス要求１５３４）してもよい。たとえば、顧客は、オンラインストアにアクセスし、クラウドインフラストラクチャシステム１５０２が提供するクラウドサービスをブラウズし、クラウドインフラストラクチャシステム１５０２が提供するとともに顧客が申し込むことを所望する１つ以上のサービスについてサブスクリプションオーダーを行い得る。このサービス要求は、顧客と、顧客が申しむことを所望する１つ以上のサービスを識別する情報を含んでいてもよい。
図１５に示される実施形態のような特定の実施形態において、クラウドインフラストラクチャシステム１５０２は、新しいオーダーを処理するように構成されたオーダー管理サブシステム（order management subsystem：ＯＭＳ）１５２０を含み得る。この処理の一部として、ＯＭＳ１５２０は、既に作成されていなければ顧客のアカウントを作成し、要求されたサービスを顧客に提供するために顧客に対して課金するのに使用する課金および／またはアカウント情報を顧客から受け、顧客情報を検証し、検証後、顧客のためにこのオーダーを予約し、各種ワークフローを調整することにより、プロビジョニングのためにオーダーを準備するように、構成されてもよい。
適切に妥当性確認がなされると、ＯＭＳ１５２０は、処理、メモリ、およびネットワーキングリソースを含む、このオーダーのためのリソースをプロビジョニングするように構成されたオーダープロビジョニングサブシステム（ＯＰＳ）１５２４を呼び出し得る。プロビジョニングは、オーダーのためのリソースを割り当てることと、顧客オーダーが要求するサービスを容易にするようにリソースを構成することとを含み得る。オーダーのためにリソースをプロビジョニングするやり方およびプロビジョニングされるリソースのタイプは、顧客がオーダーしたクラウドサービスのタイプに依存し得る。たとえば、あるワークフローに従うと、ＯＰＳ１５２４を、要求されている特定のクラウドサービスを判断し、この特定のクラウドサービスのために予め構成されたであろうポッドの数を特定するように構成されてもよい。あるオーダーのために割り当てられるポッドの数は、要求されたサービスのサイズ／量／レベル／範囲に依存し得る。たとえば、割り当てるポッドの数は、サービスがサポートすべきユーザの数、サービスが要求されている期間などに基づいて決定してもよい。次に、割り当てられたポッドを、要求されたサービスを提供するために、要求している特定の顧客に合わせてカスタマイズしてもよい。
クラウドインフラストラクチャシステム１５０２は、要求されたサービスがいつ使用できるようになるかを示すために、レスポンスまたは通知１５４４を、要求している顧客に送ってもよい。いくつかの例において、顧客が、要求したサービスの利益の使用および利用を開始できるようにする情報（たとえばリンク）を顧客に送信してもよい。
クラウドインフラストラクチャシステム１５０２はサービスを複数の顧客に提供し得る。各顧客ごとに、クラウドインフラストラクチャシステム１５０２は、顧客から受けた１つ以上のサブスクリプションオーダーに関連する情報を管理し、オーダーに関連する顧客データを維持し、要求されたサービスを顧客に提供する役割を果たす。また、クラウドインフラストラクチャシステム１５０２は、申し込まれたサービスの顧客による使用に関する使用統計を収集してもよい。たとえば、統計は、使用されたストレージの量、転送されたデータの量、ユーザの数、ならびにシステムアップタイムおよびシステムダウンタイムの量などについて、収集されてもよい。この使用情報を用いて顧客に課金してもよい。課金はたとえば月ごとに行ってもよい。
クラウドインフラストラクチャシステム１５０２は、サービスを複数の顧客に並列に提供してもよい。クラウドインフラストラクチャシステム１５０２は、場合によっては著作権情報を含む、これらの顧客についての情報を格納してもよい。特定の実施形態において、クラウドインフラストラクチャシステム１５０２は、顧客の情報を管理するとともに管理される情報を分離することで、ある顧客に関する情報が別の顧客に関する情報からアクセスされないようにするように構成された、アイデンティティ管理サブシステム（ＩＭＳ）１５２８を含む。ＩＭＳ１５２８は、アイデンティティサービス、たとえば情報アクセス管理、認証および許可サービス、顧客のアイデンティティおよび役割ならびに関連する能力などを管理するためのサービスなどの、各種セキュリティ関連サービスを提供するように構成されてもよい。
図１６は、特定の実施形態を実現するために用いられ得る例示的なコンピュータシステム１６００を示す。たとえば、いくつかの実施形態では、コンピュータシステム１６００は、図１Ａおよび図１Ｂに示されるシステムのいずれかを実現するために用いられ得る。図１６に示されるように、コンピュータシステム１６００は、バスサブシステム１６０２を介して他のいくつかのサブシステムと通信する処理サブシステム１６０４を含むさまざまなサブシステムを含む。これらの他のサブシステムは、処理加速ユニット１６０６、Ｉ／Ｏサブシステム１６０８、ストレージサブシステム１６１８、および通信サブシステム１６２４を含み得る。ストレージサブシステム１６１８は、記憶媒体１６２２およびシステムメモリ１６１０を含む非一時的なコンピュータ読取り可能記憶媒体を含み得る。
バスサブシステム１６０２は、コンピュータシステム１６００のさまざまなコンポーネントおよびサブシステムに意図されるように互いに通信させるための機構を提供する。バスサブシステム１６０２は単一のバスとして概略的に示されているが、バスサブシステムの代替実施形態は複数のバスを利用してもよい。バスサブシステム１６０２は、さまざまなバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスなどを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、このようなアーキテクチャは、業界標準アーキテクチャ（Industry Standard Architecture：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Micro Channel Architecture：ＭＣＡ）バス、エンハンストＩＳＡ（Enhanced ISA：ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Video Electronics Standards Association：ＶＥＳＡ）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１規格に従って製造されるメザニンバスとして実現可能な周辺コンポーネントインターコネクト（Peripheral Component Interconnect：ＰＣＩ）バスなどを含み得る。
処理サブシステム１６０４は、コンピュータシステム１６００の動作を制御し、１つ以上のプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含み得る。プロセッサは、シングルコアまたはマルチコアプロセッサを含み得る。コンピュータシステム１６００の処理リソースを、１つ以上の処理ユニット１６３２、１６３４などに組織することができる。処理ユニットは、１つ以上のプロセッサ、同一のまたは異なるプロセッサからの１つ以上のコア、コアとプロセッサとの組み合わせ、またはコアとプロセッサとのその他の組み合わせを含み得る。いくつかの実施形態において、処理サブシステム１６０４は、グラフィックスプロセッサ、デジタル信号プロセッサ（ＤＳＰ）などのような１つ以上の専用コプロセッサを含み得る。いくつかの実施形態では、処理サブシステム１６０４の処理ユニットの一部または全部は、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのカスタマイズされた回路を使用して実現することができる。
いくつかの実施形態において、処理サブシステム１６０４内の処理ユニットは、システムメモリ１６１０またはコンピュータ読取り可能記憶媒体１６２２に格納された命令を実行することができる。さまざまな実施形態において、処理ユニットはさまざまなプログラムまたはコード命令を実行するとともに、同時に実行する複数のプログラムまたはプロセスを維持することができる。任意の所定の時点で、実行されるべきプログラムコードの一部または全部は、システムメモリ１６１０および／または潜在的に１つ以上の記憶装置を含むコンピュータ読取り可能記憶媒体１６２２に常駐していてもよい。適切なプログラミングを介して、処理サブシステム１６０４は、上述のさまざまな機能を提供することができる。コンピュータシステム１６００が１つ以上の仮想マシンを実行している例において、１つ以上の処理ユニットが各仮想マシンに割り当ててもよい。
特定の実施形態において、コンピュータシステム１６００によって実行される全体的な処理を加速するように、カスタマイズされた処理を実行するために、または処理サブシステム１６０４によって実行される処理の一部をオフロードするために、処理加速ユニット１６０６を任意に設けることができる。
Ｉ／Ｏサブシステム１６０８は、コンピュータシステム１６００に情報を入力するための、および／またはコンピュータシステム１６００から、もしくはコンピュータシステム１６００を介して、情報を出力するための、デバイスおよび機構を含むことができる。一般に、「入力デバイス」という語の使用は、コンピュータシステム１６００に情報を入力するためのすべての考えられ得るタイプのデバイスおよび機構を含むよう意図される。ユーザインターフェイス入力デバイスは、たとえば、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、ユーザが入力デバイスを制御しそれと対話することを可能にするＭｉｃｒｏｓｏｆｔ Ｋｉｎｅｃｔ（登録商標）モーションセンサ、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）３６０ゲームコントローラ、ジェスチャおよび音声コマンドを用いる入力を受信するためのインターフェイスを提供するデバイスなど、モーションセンシングおよび／またはジェスチャ認識デバイスも含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き（たとえば、写真を撮っている間および／またはメニュー選択を行っている間の「まばたき」）を検出し、アイジェスチャを入力デバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標））への入力として変換するＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。また、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム（たとえばＳｉｒｉ（登録商標）ナビゲータ）と対話することを可能にする音声認識感知デバイスを含んでもよい。
ユーザインターフェイス入力デバイスの他の例は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚／視覚デバイスも含んでもよいが、それらに限定されない。また、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、および医療用超音波検査デバイスなどの医療用画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力デバイスも含んでもよい。
一般に、出力デバイスという語の使用は、コンピュータシステム１６００からユーザまたは他のコンピュータに情報を出力するための考えられるすべてのタイプのデバイスおよび機構を含むことを意図している。ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどのような非ビジュアルディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使うものなどのフラットパネルデバイス、計画デバイス、タッチスクリーンなどであってもよい。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されない。
ストレージサブシステム１６１８は、コンピュータシステム１６００によって使用される情報およびデータを格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム１６１８は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構成を格納するための有形の非一時的なコンピュータ読取り可能記憶媒体を提供する。処理サブシステム１６０４によって実行されると上述の機能を提供するソフトウェア（たとえばプログラム、コードモジュール、命令）が、ストレージサブシステム１６１８に格納されてもよい。ソフトウェアは、処理サブシステム１６０４の１つ以上の処理ユニットによって実行されてもよい。ストレージサブシステム１６１８はまた、本開示の教示に従って使用されるデータを格納するためのリポジトリを提供してもよい。
ストレージサブシステム１６１８は、揮発性および不揮発性メモリデバイスを含む１つ以上の非一時的メモリデバイスを含み得る。図１６に示すように、ストレージサブシステム１６１８は、システムメモリ１６１０およびコンピュータ読取り可能記憶媒体１６２２を含む。システムメモリ１６１０は、プログラム実行中に命令およびデータを格納するための揮発性主ランダムアクセスメモリ（ＲＡＭ）と、固定命令が格納される不揮発性読取り専用メモリ（ＲＯＭ）またはフラッシュメモリとを含む、いくつかのメモリを含み得る。いくつかの実現例において、起動中などにコンピュータシステム１６００内の要素間における情報の転送を助ける基本的なルーチンを含むベーシックインプット／アウトプットシステム（basic input/output system：ＢＩＯＳ）は、典型的には、ＲＯＭに格納されてもよい。典型的に、ＲＡＭは、処理サブシステム１６０４によって現在操作および実行されているデータおよび／またはプログラムモジュールを含む。いくつかの実現例において、システムメモリ１６１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）などのような複数の異なるタイプのメモリを含み得る。
一例として、限定を伴うことなく、図１６に示されるように、システムメモリ１６１０は、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などのような各種アプリケーションを含み得る、実行中のアプリケーションプログラム１６１２、プログラムデータ１６１４、およびオペレーティングシステム１６１６を、ロードしてもよい。一例として、オペレーティングシステム１６１６は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）および／またはＬｉｎｕｘオペレーティングシステム、市販されているさまざまなＵＮＩＸ（登録商標）またはＵＮＩＸ系オペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むがそれらに限定されない）、および／または、ｉＯＳ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標） Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標） ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標） ＯＳ、Ｐａｌｍ（登録商標） ＯＳオペレーティングシステムのようなさまざまなバージョンのモバイルオペレーティングシステムなどを、含み得る。
コンピュータ読取り可能記憶媒体１６２２は、いくつかの実施形態の機能を提供するプログラミングおよびデータ構成を格納することができる。コンピュータ読取り可能記憶媒体１６２２は、コンピュータシステム１６００のための、コンピュータ読取り可能命令、データ構造、プログラムモジュール、および他のデータのストレージを提供することができる。処理サブシステム１６０４によって実行されると上記機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム１６１８に格納されてもよい。一例として、コンピュータ読取り可能記憶媒体１６２２は、ハードディスクドライブ、磁気ディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤ、Ｂｌｕ−Ｒａｙ（登録商標）ディスクなどの光ディスクドライブ、またはその他の光学媒体のような不揮発性メモリを含み得る。コンピュータ読取り可能記憶媒体１６２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、それらに限定されない。コンピュータ読取り可能記憶媒体１６２２は、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどのような不揮発性メモリに基づくソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭのような揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤも含み得る。
特定の実施形態において、ストレージサブシステム１６１８は、コンピュータ読取り可能記憶媒体１６２２にさらに接続可能なコンピュータ読取り可能記憶媒体リーダ１６２０も含み得る。リーダ１６２０は、ディスク、フラッシュドライブなどのようなメモリデバイスからデータを受け、読取るように構成されてもよい。
特定の実施形態において、コンピュータシステム１６００は、処理およびメモリリソースの仮想化を含むがこれに限定されない仮想化技術をサポートし得る。たとえば、コンピュータシステム１６００は、１つ以上の仮想マシンを実行するためのサポートを提供し得る。特定の実施形態において、コンピュータシステム１６００は、仮想マシンの構成および管理を容易にするハイパーバイザなどのプログラムを実行し得る。各仮想マシンには、メモリ、演算（たとえばプロセッサ、コア）、Ｉ／Ｏ、およびネットワーキングリソースを割り当てられてもよい。各仮想マシンは通常、他の仮想マシンから独立して実行される。仮想マシンは、典型的には、コンピュータシステム１６００によって実行される他の仮想マシンによって実行されるオペレーティングシステムと同じであり得るかまたは異なり得るそれ自体のオペレーティングシステムを実行する。したがって、潜在的に複数のオペレーティングシステムがコンピュータシステム１６００によって同時に実行され得る。
通信サブシステム１６２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム１６２４は、他のシステムとコンピュータシステム１６００との間のデータの送受のためのインターフェイスとして機能する。たとえば、通信サブシステム１６２４は、コンピュータシステム１６００が、１つ以上のクライアントデバイスとの間で情報を送受信するために、インターネットを介して１つ以上のクライアントデバイスへの通信チャネルを確立することを可能にし得る。
通信サブシステム１６２４は、有線および／または無線通信プロトコルの両方をサポートし得る。たとえば、ある実施形態において、通信サブシステム１６２４は、（たとえば、セルラー電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（グローバル進化のための高速データレート）などの先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ８０２．ＸＸファミリー規格、もしくは他のモバイル通信技術、またはそれらのいずれかの組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）送受信機コンポーネント、グローバルポジショニングシステム（ＧＰＳ）受信機コンポーネント、および／または他のコンポーネントを含み得る。いくつかの実施形態において、通信サブシステム１６２４は、無線インターフェイスに加えてまたはその代わりに、有線ネットワーク接続（たとえばEthernet（登録商標））を提供することができる。
通信サブシステム１６２４は、さまざまな形式でデータを受信および送信することができる。たとえば、いくつかの実施形態において、通信サブシステム１６２４は、他の形式に加えて、構造化データフィードおよび／または非構造化データフィード１６２６、イベントストリーム１６２８、イベントアップデート１６３０などの形式で入力通信を受信してもよい。たとえば、通信サブシステム１６２４は、ソーシャルメディアネットワークおよび／またはＴｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）アップデート、Ｒｉｃｈ Ｓｉｔｅ Ｓｕｍｍａｒｙ（ＲＳＳ）フィードなどのウェブフィード、および／または１つ以上の第三者情報源からのリアルタイムアップデートなどのような他の通信サービスのユーザから、リアルタイムでデータフィード１６２６を受信（または送信）するように構成されてもよい。
特定の実施形態において、通信サブシステム１６２４は、連続データストリームの形式でデータを受信するように構成されてもよく、当該連続データストリームは、明確な終端を持たない、本来は連続的または無限であり得るリアルタイムイベントのイベントストリーム１６２８および／またはイベントアップデート１６３０を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえばネットワークモニタリングおよびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通モニタリングなどを挙げることができる。
通信サブシステム１６２４は、コンピュータシステム１６００からのデータを他のコンピュータシステムまたはネットワークに伝えるように構成されてもよい。このデータは、構造化および／または非構造化データフィード１６２６、イベントストリーム１６２８、イベントアップデート１６３０などのような各種異なる形式で、コンピュータシステム１６００に結合された１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに、伝えられてもよい。
コンピュータシステム１６００は、ハンドヘルドポータブルデバイス（たとえばｉＰｈｏｎｅ（登録商標）セルラーフォン、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）ヘッドマウントディスプレイ）、パーソナルコンピュータ、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのうちの１つであればよい。コンピュータおよびネットワークの性質が常に変化しているため、図１６に示されるコンピュータシステム１６００の記載は、具体的な例として意図されているに過ぎない。図１６に示されるシステムよりも多くのコンポーネントまたは少ないコンポーネントを有するその他多くの構成が可能である。当業者であれば、本明細書における開示および教示に基づいて、さまざまな実施形態を実現するための他の態様および／または方法を認識するだろう。
特定の実施形態について説明したが、さまざまな変形、変更、代替構成、および均等物が可能である。たとえば、いくつかの例をＳＱＬクエリを用いて説明してきたが、これは限定するよう意図したものではない。代替的な実施形態では、本明細書中に記載される教示は、ＳＱＬクエリ以外のクエリにも適用することができる。実施形態は、特定のデータ処理環境内の動作に限定されず、複数のデータ処理環境内で自由に動作させることができる。さらに、実施形態を特定の一連のトランザクションおよびステップを使用して説明したが、これが限定を意図しているのではないことは当業者には明らかであるはずである。いくつかのフローチャートは動作を逐次的プロセスとして説明しているが、これらの動作のうちの多くは並列または同時に実行できる。加えて、動作の順序を再指定してもよい。プロセスは図に含まれない追加のステップを有し得る。上記実施形態の各種特徴および局面は、個別に使用されてもよく、またはともに使用されてもよい。
さらに、特定の実施形態をハードウェアとソフトウェアとの特定の組み合わせを用いて説明してきたが、ハードウェアとソフトウェアとの他の組み合わせも可能であることが理解されるはずである。特定の実施形態は、ハードウェアでのみ、またはソフトウェアでのみ、またはそれらの組み合わせを用いて実現されてもよい。本明細書に記載されたさまざまなプロセスは、同じプロセッサまたは任意の組み合わせの異なるプロセッサ上で実現できる。
デバイス、システム、コンポーネントまたはモジュールが特定の動作または機能を実行するように構成されると記載されている場合、そのような構成は、たとえば、動作を実行するように電子回路を設計することにより、動作を実行するようにプログラミング可能な電子回路（マイクロプロセッサなど）をプログラミングすることにより、たとえば、非一時的なメモリ媒体に格納されたコードもしくは命令またはそれらの任意の組み合わせを実行するようにプログラミングされたコンピュータ命令もしくはコード、またはプロセッサもしくはコアを実行するなどにより、達成され得る。プロセスは、プロセス間通信のための従来の技術を含むがこれに限定されないさまざまな技術を使用して通信することができ、異なる対のプロセスは異なる技術を使用してもよく、同じ対のプロセスは異なる時間に異なる技術を使用してもよい。
本開示では具体的な詳細を示すことにより実施形態が十分に理解されるようにしている。しかしながら、実施形態はこれらの具体的な詳細がなくとも実施し得るものである。たとえば、周知の回路、プロセス、アルゴリズム、構造、および技術は、実施形態が曖昧にならないようにするために不必要な詳細事項なしで示している。本明細書は例示的な実施形態のみを提供し、他の実施形態の範囲、適用可能性、または構成を限定するよう意図されたものではない。むしろ、実施形態の上記説明は、各種実施形態を実現することを可能にする説明を当業者に提供する。要素の機能および構成の範囲内でさまざまな変更が可能である。
したがって、明細書および図面は、限定的な意味ではなく例示的なものとみなされるべきである。しかしながら、請求項に記載されているより広範な精神および範囲から逸脱することなく、追加、削減、削除、ならびに他の修正および変更がこれらになされ得ることは明らかであろう。このように、具体的な実施形態を説明してきたが、これらは限定を意図するものではない。さまざまな変形例および同等例は添付の特許請求の範囲内にある。

Claims (20)

  1. 方法であって、
    コンピューティングシステムが、リレーショナルデータベースに格納されたデータをクエリするためのクエリのために生成されたオリジナルのクエリプランを受信するステップを含み、前記オリジナルのクエリプランは、ファクトレコードのソースからファクトレコードをスキャンするように構成された第１のファクトスキャンオペレーションを含み、前記オリジナルのクエリプランはさらに、前記第１のスキャンオペレーションからレコードのセットを受信するように構成された第２のオペレーションを含み、前記方法はさらに、
    前記コンピューティングシステムが、前記第１のファクトスキャンオペレーションに関連付けられるべき第１の述語条件を識別するステップと、
    前記コンピューティングシステムが、高度化クエリプランを生成するように前記オリジナルのクエリプランを書換えるステップとを含み、前記高度化クエリプランにおいて、前記第１の述語条件は前記第１のスキャンオペレーションに関連付けられており、前記第２のオペレーションは、前記述語条件を満たす１つ以上のスキャンされたファクトレコードだけを受信し、
    前記高度化クエリプランは、前記第１の述語条件が前記第１のスキャンオペレーションに関連付けられていることで、前記オリジナルのクエリプランよりも高速で実行される、方法。
  2. 問合わせのための前記データは、事前集約されていないデータである、請求項１に記載の方法。
  3. 前記クエリについてのレコードの結果セットを得るために前記高度化クエリプランを実行するステップと、
    前記レコードの結果セットを前記クエリに対する応答として提供するステップとをさらに含む、請求項１または２に記載の方法。
  4. 前記高度化クエリプランの実行は、前記オリジナルのクエリプランの実行よりも、少ない中央処理ユニット（ＣＰＵ）サイクルを要する、請求項１、２または３に記載の方法。
  5. 前記第２のオペレーションによって受信されて処理されるファクトレコードの数は、前記オリジナルのクエリプランよりも前記高度化クエリプランの方が少ない、請求項１、２、３または４に記載の方法。
  6. 前記識別するステップは、
    前記オリジナルのクエリプランにおける前記第１のファクトスキャンオペレーションを識別するステップを含み、前記第１のファクトスキャンオペレーションは第１のファクトテーブル上で動作し、前記識別するステップはさらに、
    前記第１のスキャンオペレーションから始まって、前記オリジナルのクエリプランをウォークして、前記第１のファクトスキャンオペレーションについての１つ以上の適用可能な述語条件のリストを識別するステップを含み、前記適用可能な述語条件のリストは前記第１の述語条件を含む、請求項１、２、３、４または５に記載の方法。
  7. 前記識別するステップは、
    前記オリジナルのクエリプランにおいて、第１のファクトテーブル上で動作する前記第１のファクトスキャンオペレーションを識別するステップと、
    前記オリジナルのクエリプランにおいて、第２のファクトテーブル上で動作する第２のファクトスキャンオペレーションを識別するステップと、
    前記オリジナルのクエリプランにおいて、前記第２のファクトテーブルと次元テーブルとの間の結合オペレーションを識別するステップとを含み、前記第１の述語条件は前記次元テーブルに関連付けられており、前記識別するステップはさらに、
    前記第１のファクトテーブルと前記第２のファクトテーブルとの間の共通次元を識別するステップを含み、
    前記第１の述語条件は、前記共通次元からの属性に基づいている、請求項１、２、３、４または５に記載の方法。
  8. 前記識別するステップは、
    前記第１のファクトスキャンオペレーションのために適用可能な複数の述語条件を識別するステップと、
    前記複数の述語条件における各々の述語条件についての純便益メトリックを演算するステップとを含み、前記複数の述語条件における特定の述語条件についての前記純便益メトリックは、前記ファクトレコードのソースからのファクト行を処理するコストから、前記特定の述語条件を前記第１のファクトスキャンオペレーションに適用するコストを差引いた減少分であり、前記識別するステップはさらに、
    前記複数の述語条件について演算された前記純便益メトリックに基づいて、前記第１のファクトスキャンオペレーションについての前記複数の述語条件を順序付けるステップと、
    前記順序付けに基づいて前記第１のファクトスキャンオペレーションに関連付けられるべき述語条件を前記複数の述語条件から選択するステップとを含む、請求項１、２、３、４または５に記載の方法。
  9. 前記識別するステップは、
    前記第１のファクトスキャンオペレーションについての適用可能な述語条件を識別するステップと、
    前記適用可能な述語条件についての純便益メトリックを演算するステップと、
    前記適用可能な述語条件について演算された前記純便益メトリックに基づいて、前記適用可能な述語条件が前記第１のファクトスキャンオペレーションに関連付けられるべきでないと判断するステップと、
    機能依存性情報を用いて、前記適用可能な述語条件から前記第１の述語条件を推論するステップとを含む、請求項１、２、３、４または５に記載の方法。
  10. 前記ファクトレコードのソースは、ファクトレコード、実体化されたビュー、またはオンライン分析処理（ＯＬＡＰ）インデックスを格納するテーブルである、請求項１〜９のいずれか１項に記載の方法。
  11. 前記第１の述語条件を識別するステップはさらに、
    前記オリジナルのクエリプランにおける第３のオペレーションを識別するステップを含み、前記第１の述語条件は前記第３のオペレーションに関連付けられている、請求項１、２、３、４または５に記載の方法。
  12. 前記第３のオペレーションは次元テーブルに関連付けられている、請求項１１に記載の方法。
  13. 前記第１の述語条件を識別するステップは、
    前記第１のスキャンオペレーションに関連付けられるべき第２の述語条件を識別するステップと、
    前記第２の述語条件を前記第１の述語条件に変換するステップとを含む、請求項１、２、３、４または５に記載の方法。
  14. 前記変換するステップは、機能依存性情報を用いて、前記第２の述語条件を前記第１の述語条件に変換するステップを含む、請求項１３に記載の方法。
  15. 前記第２の述語条件は第１の次元フィールドについての値を特定し、前記第１の述語条件は、前記第１の次元フィールドとは異なる第２の次元フィールドについての値を特定し、前記第２次元フィールドは、次元テーブルまたは前記ファクトレコードのソースにおける列フィールドである、請求項１３または１４に記載の方法。
  16. 前記オリジナルのクエリプランにおける第１のサブプランを識別するステップをさらに含み、前記第１のサブプランは前記第１のファクトスキャンオペレーションを含み、前記第１のサブプランだけが、１つ以上の集約オペレーション、結合オペレーション、プロジェクトオペレーション、フィルタオペレーション、またはファクトスキャンオペレーションを含み、
    前記高度化クエリプランは、前記第１の述語条件が前記第１のスキャンオペレーションに関連付けられている前記第１のサブプランを含む、請求項１、２、３、４、５、または１０に記載の方法。
  17. スタースキーマに基づいて、前記ファクトレコードのソースが次元テーブルと結合可能であると判断するステップをさらに含み、
    前記第１の述語条件は、前記次元テーブルのうち、前記ファクトレコードのソースと結合されるべき次元キーに関連する条件を含む、請求項１、２、３、４、５、または１０に記載の方法。
  18. 前記ファクトレコードのソースはＯＬＡＰインデックスであり、前記ＯＬＡＰインデックスは、テーブルと、前記テーブル内の次元値をインデックス付けするインデックスとを含み、
    前記テーブルは、ファクトレコードを格納するファクトテーブルを前記次元値を含む次元テーブルと結合することによって得られるデータを含み、
    前記第１の述語条件は、前記ＯＬＡＰインデックスにおける前記次元値に対して評価される、請求項１から５、８または９のいずれか１項に記載の方法。
  19. １つ以上のプロセッサによって実行可能な複数の命令を格納する非一時的なコンピュータ読取り可能メモリであって、前記複数の命令は、前記１つ以上のプロセッサによって実行されると前記１つ以上のプロセッサに以下の処理を実行させる命令を含み、前記以下の処理は、
    リレーショナルデータベースに格納されたデータをクエリするためのクエリのために生成されたオリジナルのクエリプランを受信する処理を含み、前記オリジナルのクエリプランは、ファクトレコードのソースからファクトレコードをスキャンするように構成された第１のファクトスキャンオペレーションを含み、前記オリジナルのクエリプランはさらに、前記第１のスキャンオペレーションからレコードのセットを受信するように構成された第２のオペレーションを含み、前記以下の処理はさらに、
    前記第１のファクトスキャンオペレーションに関連付けられるべき第１の述語条件を識別する処理と、
    高度化クエリプランを生成するように前記オリジナルのクエリプランを書換える処理とを含み、前記高度化クエリプランにおいて、前記第１の述語条件は前記第１のスキャンオペレーションに関連付けられており、前記第２のオペレーションは前記述語条件を満たす１つ以上のスキャンされたファクトレコードだけを受信し、前記以下の処理はさらに、
    前記クエリについてのレコードの結果セットを得るために前記高度化クエリプランを実行する処理を含み、前記高度化クエリプランは、前記第１の述語条件が前記第１のスキャンオペレーションに関連付けられていることで、前記オリジナルのクエリプランよりも高速で実行され、前記以下の処理はさらに、
    前記レコードの結果セットを前記クエリに対する応答として提供する処理を含む、非一時的なコンピュータ読取り可能メモリ。
  20. システムであって、
    １つ以上のプロセッサと、
    前記１つ以上のプロセッサに連結されたメモリとを含み、前記メモリは前記１つ以上のプロセッサによって実行可能な複数の命令を格納し、前記複数の命令は、前記１つ以上のプロセッサによって実行されると、前記１つ以上のプロセッサに以下の処理を実行させる命令を含み、前記以下の処理は、
    リレーショナルデータベースに格納されたデータをクエリするためのクエリのために生成されたオリジナルのクエリプランを受信する処理を含み、前記オリジナルのクエリプランは、ファクトレコードのソースからファクトレコードをスキャンするように構成された第１のファクトスキャンオペレーションを含み、前記オリジナルのクエリプランはさらに、前記第１のスキャンオペレーションからレコードのセットを受信するように構成された第２のオペレーションを含み、前記以下の処理はさらに、
    前記第１のファクトスキャンオペレーションに関連付けられるべき第１の述語条件を識別する処理と、
    高度化クエリプランを生成するように前記オリジナルのクエリプランを書換える処理とを含み、前記高度化クエリプランにおいて、前記第１の述語条件は前記第１のスキャンオペレーションに関連付けられており、前記第２のオペレーションは前記述語条件を満たす１つ以上のスキャンされたファクトレコードだけを受信し、前記以下の処理はさらに、
    前記クエリについてのレコードの結果セットを得るために前記高度化クエリプランを実行する処理を含み、前記高度化クエリプランは、第１の述語条件が前記第１のスキャンオペレーションに関連付けられていることで、前記オリジナルのクエリプランよりも高速で実行され、前記以下の処理はさらに、
    前記レコードの結果セットを前記クエリに対する応答として提供する処理を含む、システム。
JP2020539091A 2018-01-16 2019-01-16 Ｓｑｌクエリプランを最適化するための次元コンテキスト伝搬技術 Active JP7273045B2 (ja)

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 (3)

Publication Number Publication Date
JP2021511582A true JP2021511582A (ja) 2021-05-06
JP2021511582A5 JP2021511582A5 (ja) 2021-10-07
JP7273045B2 JP7273045B2 (ja) 2023-05-12

Family

ID=67212927

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020539091A Active JP7273045B2 (ja) 2018-01-16 2019-01-16 Ｓｑｌクエリプランを最適化するための次元コンテキスト伝搬技術

Country Status (6)

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

Families Citing this family (46)

* 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 北京百度网讯科技有限公司 查询处理方法、查询处理系统、服务器和计算机可读介质
WO2020242764A1 (en) * 2019-05-29 2020-12-03 Sigma Computing, Inc. Row-level worksheet security
US11086894B1 (en) * 2019-06-25 2021-08-10 Amazon Technologies, Inc. Dynamically updated data sheets using row links
US11194793B1 (en) 2019-06-25 2021-12-07 Amazon Technologies, Inc. Dynamically materialized views for sheets based data
EP4014126A4 (en) * 2019-08-15 2023-08-16 Telepathy Labs, Inc. SYSTEM AND PROCEDURES FOR REQUESTING MULTIPLE DATA SOURCES
JP7383799B2 (ja) * 2019-09-13 2023-11-20 タブロー ソフトウェア，エルエルシー マルチファクトデータセットのデータ視覚化を生成するための適切な測度集計の活用
US11449796B2 (en) * 2019-09-20 2022-09-20 Amazon Technologies, Inc. Machine learning inference calls for database query processing
US11550944B2 (en) 2019-09-27 2023-01-10 Amazon Technologies, Inc. Code execution environment customization system for object storage service
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
CN110968895B (zh) * 2019-11-29 2022-04-05 北京百度网讯科技有限公司 一种数据的处理方法、装置、电子设备及存储介质
US11567939B2 (en) 2019-12-26 2023-01-31 Snowflake Inc. Lazy reassembling of semi-structured data
US11372860B2 (en) * 2019-12-26 2022-06-28 Snowflake Inc. Processing techniques for queries where predicate values are unknown until runtime
US10997179B1 (en) 2019-12-26 2021-05-04 Snowflake Inc. Pruning index for optimization of pattern matching queries
US11681708B2 (en) 2019-12-26 2023-06-20 Snowflake Inc. Indexed regular expression search with N-grams
US11308090B2 (en) 2019-12-26 2022-04-19 Snowflake Inc. Pruning index to support semi-structured data types
US10769150B1 (en) 2019-12-26 2020-09-08 Snowflake Inc. Pruning indexes to enhance database query processing
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
US12026161B2 (en) * 2020-07-07 2024-07-02 AtScale, Inc. Hierarchical datacube query plan generation
US20220012238A1 (en) * 2020-07-07 2022-01-13 AtScale, Inc. Datacube access connectors
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
WO2022150357A1 (en) * 2021-01-07 2022-07-14 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 腾讯科技（深圳）有限公司 数据查询方法、装置、计算机设备和存储介质
KR20230146162A (ko) 2022-04-11 2023-10-19 주식회사 이노와이어리스 사용자의 쿼리 패턴을 이용한 쿼리 성능 향상 방법
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
KR102649770B1 (ko) * 2023-01-10 2024-03-21 쿠팡 주식회사 정보를 제공하는 방법 및 이를 지원하는 전자 장치
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 (10)

* 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
JP2001243242A (ja) * 2000-02-25 2001-09-07 Hitachi Ltd 問合せ処理方法およびそれを実施するデータベース管理システムその処理プログラムを格納した記録媒体
JP2002007435A (ja) * 2000-06-20 2002-01-11 Nec Corp 対話的分析データベースシステム及び対話的分析プログラムを記録した記録媒体
US20100312756A1 (en) * 2009-06-04 2010-12-09 Oracle International Corporation Query Optimization by Specifying Path-Based Predicate Evaluation in a Path-Based Query Operator
US20130173528A1 (en) * 2011-12-29 2013-07-04 International Business Machines Corporation Multi-fact query processing in data processing system
US20130275364A1 (en) * 2012-04-17 2013-10-17 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
US20160098446A1 (en) * 2014-10-06 2016-04-07 International Business Machines Corporation Limiting scans of loosely ordered and/or grouped relations in a database
US20170147644A1 (en) * 2015-11-20 2017-05-25 Sap Se Query optimization using join cardinality
WO2017163393A1 (ja) * 2016-03-25 2017-09-28 株式会社日立製作所 データ処理システム

Family Cites Families (8)

* 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
DE60004385T2 (de) * 1999-07-21 2004-06-24 Torben Bach Pedersen Verfahren und systeme um olap hierarchien zusammenfassbar zu machen
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
US9043310B2 (en) * 2011-11-08 2015-05-26 International Business Machines Corporation Accessing a dimensional data model when processing a query
US10528599B1 (en) * 2016-12-16 2020-01-07 Amazon Technologies, Inc. Tiered data processing for distributed data

Patent Citations (10)

* 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
JP2001243242A (ja) * 2000-02-25 2001-09-07 Hitachi Ltd 問合せ処理方法およびそれを実施するデータベース管理システムその処理プログラムを格納した記録媒体
JP2002007435A (ja) * 2000-06-20 2002-01-11 Nec Corp 対話的分析データベースシステム及び対話的分析プログラムを記録した記録媒体
US20100312756A1 (en) * 2009-06-04 2010-12-09 Oracle International Corporation Query Optimization by Specifying Path-Based Predicate Evaluation in a Path-Based Query Operator
US20130173528A1 (en) * 2011-12-29 2013-07-04 International Business Machines Corporation Multi-fact query processing in data processing system
US20130275364A1 (en) * 2012-04-17 2013-10-17 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
US20160098446A1 (en) * 2014-10-06 2016-04-07 International Business Machines Corporation Limiting scans of loosely ordered and/or grouped relations in a database
US20170147644A1 (en) * 2015-11-20 2017-05-25 Sap Se Query optimization using join cardinality
WO2017163393A1 (ja) * 2016-03-25 2017-09-28 株式会社日立製作所 データ処理システム

Also Published As

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

Similar Documents

Publication Publication Date Title
JP7273045B2 (ja) Ｓｑｌクエリプランを最適化するための次元コンテキスト伝搬技術
JP7333424B2 (ja) 分散イベント処理システムのためのグラフ生成
JP6617117B2 (ja) 半構造データのためのスケーラブルな分析プラットフォーム
US10409782B2 (en) Platform, system, process for distributed graph databases and computing
US11822545B2 (en) Search integration
US10169433B2 (en) Systems and methods for an SQL-driven distributed operating system
US20180210934A1 (en) Systems and methods for interest-driven business intelligence systems including event-oriented data
US9747331B2 (en) Limiting scans of loosely ordered and/or grouped relations in a database
US20200012638A1 (en) Search integration
US11055352B1 (en) Engine independent query plan optimization
Simmen et al. Large-scale graph analytics in aster 6: bringing context to big data discovery
US10909114B1 (en) Predicting partitions of a database table for processing a database query
US20150081353A1 (en) Systems and Methods for Interest-Driven Business Intelligence Systems Including Segment Data
US20170371922A1 (en) Database Management for Mobile Devices
US10157234B1 (en) Systems and methods for transforming datasets
US11762907B2 (en) Contract library data structures and uses thereof
CN114730312A (zh) 从异构数据源创建的受管物化视图
US10776368B1 (en) Deriving cardinality values from approximate quantile summaries
Khan et al. Storage solutions for big data systems: A qualitative study and comparison
US20180174164A1 (en) Predictive Analysis of Transactional Data
US20220114483A1 (en) Unified machine learning feature data pipeline
Zhu et al. Building Big Data and Analytics Solutions in the Cloud
US20230297550A1 (en) Dynamic data views
US20240119045A1 (en) Systems and Methods for Intelligent Database Report Generation
da Silva Costa Advancing the Design and Implementation of Big Data Warehousing Systems

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210824

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210824

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220826

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220927

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221129

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230404

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230427

R150 Certificate of patent or registration of utility model

Ref document number: 7273045

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150