以下の説明は、テンポラル−リレーショナルデータベースを有するリレーショナルデータベース管理システムにおけるクエリプランの生成および実行のための方法および装置について説明する。以下の説明において、本発明のより完全な理解をもたらすために、リソース分割/共有/複製の実装、システムコンポーネントのタイプおよび相互関係、ならびに論理分割/統合の選択などの多数の特定の詳細について述べる。しかしながら、当業者は、本発明をそのような特定の詳細なしで実施してもよいことを理解するだろう。他の事例において、本発明を不明瞭にしないために、制御構造、論理実装、オペコード、オペランドを特定する手段、および完全なソフトウェア命令シーケンスは、詳細に図示されていない。当業者は、含まれる説明により、必要以上の実験を行うことなく本発明を実施することができるだろう。
本明細書における「一実施形態」、「実施形態」、「例示的実施形態」などへの言及は、記載される実施形態が特定の特徴、構造、または特性を含むことができるが、すべての実施形態がその特定の特徴、構造、または特性を必ずしも含まなくてよいことを示す。さらに、そのような表現は必ずしも同一の実施形態を指すものではない。さらに、特定の特徴、構造、または特性が実施形態に関連して記載されるとき、そのような特徴、構造、または特性を他の実施形態に関連させることは、明記されていてもいなくても、当業者の知識の範囲内であると思われる。
本明細書において、括弧書きの文言および破線の枠を有するブロック(例えば、大きい破線、小さい破線、鎖線、および点線)を使用して、一部の実施形態にさらなる特徴を追加するオプションの動作および/または構造を示すことができる。しかしながら、そのような表記は、これらが単にオプションまたはオプションの動作であること、および/または実線の枠を有するブロックが、ある実施形態においてオプションでないことを意味するものと解釈すべきではない。
以下の説明および特許請求の範囲において、「結合される」という用語およびその派生語を使用することができる。「結合される」は、2つ以上の要素が互いに協働するまたは相互作用することを示すために使用され、これらの要素は、互いに直接物理的または電気的に接触していても接触していなくてもよい。
フロー図の動作は、他の図の例示的な実施形態を参照して説明される。しかしながら、フロー図の動作を、これらの他の図を参照して説明するもの以外の実施形態により実行してもよく、これらの他の図を参照して説明する実施形態は、フロー図を参照して説明するものと異なる動作を実行してもよい。
本明細書において、「クライアント」という用語が、いくつかの文脈で「データベースクライアント」(RDBMSクライアントとしても知られる)、「BIクライアント」、および「エンドユーザクライアント」を指すためにも使用される。データベースクライアントはRDBMSのクライアントであり、BIクライアントはBIサービスのクライアントである。エンドユーザクライアントはデータベースクライアントであってよく、エンドユーザクライアントはBIクライアントであってよく(BIサービスがデータベースクライアントである状態で)、かつ/またはエンドユーザクライアントはデータベースクライアントおよびBIクライアント(BIサービスがデータベースクライアントである状態で)の両方であってよい。
概略
図1は、一実施形態による、テンポラル−リレーショナルデータベースを有するリレーショナルデータベース管理システム(RDBMS)におけるクエリプランの生成および実行のフロー図である。ブロック100で、リレーショナルデータベース管理システムは、リレーショナルデータベース管理システムにより管理されたテンポラルデータベースのテンポラルテーブルのデータへのアクセスを必要とする複数の構造化クエリ言語(SQL)クエリを受信する。前述したように、テンポラルテーブルは、論理的には行と列とを有するテーブルであると考えられるが、テンポラルテーブルのコンテンツをメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に異なる方法(例えば、前記論理ビューをまねた「行指向」構成(「行指向」テンポラルテーブルと称することもある)、「列指向」(「カラム型」としても知られる)構成(「列指向」テンポラルテーブルと称することがある)など)で保存することができる。一実施形態において、テンポラルテーブルに保存された各データレコードは、対のタイムスタンプ、すなわち、レコードが有効な最も早い時間に対応する第1のタイムスタンプ(例えば、「valid_from」列に対応するvalid_fromフィールドに保存される)、およびレコードが有効な(かつ時間が未知の場合に無限大(INF)に設定される)最も遅い時間に対応する第2のタイムスタンプ(例えば、「valid_to」列に対応するvalid_toフィールドに保存される)と関連付けられる。本明細書において、前記論理ビューに関して、かつ(当技術分野で時々使用されるように)valid_to列およびvalid_from列という用語を使用して実施形態について説明するが、代替実施形態は、テンポラルテーブルを異なって実装してもよい(例えば、テンポラルテーブルのコンテンツを異なる方法で(例えば、行指向構成を使用して、列指向構成を使用して、1つまたは複数のテンポラルテーブルの行指向構成および列指向構成の両方を使用して、1つまたは複数のテンポラルテーブルの行指向構成を使用し1つまたは複数の他のテンポラルテーブルの列指向構成を使用してなど)保存する、データレコードのタイムスタンプ情報を別の方法で(例えば、より多いまたは少ないフィールドを使用して)保存する、様々な用語によりタイムスタンプ情報を参照するなど)。ブロック100の複数のSQLクエリを同時に受信する必要はないことに留意すべきである。ブロック100から、制御はブロック110へ進む。
ブロック110で、SQLクエリの各々についてのクエリ結果を生成するように複数のSQLクエリのうちのSQLクエリを実行する。一実施形態において、この実行はブロック120、次いでブロック130を含む。ブロック120は、実行後にメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に保存される複数のクエリプランの生成および実行を含み、複数のクエリプランの各々は、エッジにより連結されたノードの有向グラフを含む。有向グラフの各々は、複数のSQLクエリのうちの1つについてのクエリ結果(「結果セット」とも称する)を実行時に生成するクエリプラン演算子の順序セットを表し、有向グラフのノードの各々はクエリプラン演算子のうちの1つを表す。有向グラフのノードにより表されたクエリプラン演算子の各々は、クエリプランの一部として実行される演算のタイプを表す。したがって、本明細書で使用されるとき、「クエリプラン演算子」は、クエリプランの一部として実行される演算のタイプ(例えば、リレーショナル演算のタイプ(例えば、PROJECT、SELECT、JOIN、TABLEなど)または他の演算のタイプ(例えば、RENAMEなど))を表す。そのようなクエリプラン演算子がテンポラルテーブル上のリレーショナル演算を表すとき、この演算をテンポラル−リレーショナル演算と称する。有向グラフは、エッジがそのエッジに関連付けられた方向を有するグラフである。有向グラフの各々におけるノードは親子関係を有し、すなわち、1つのノードを別のノードに連結するエッジは、これらのノードがそれぞれ互いに親ノードおよび子ノードであり、子ノードの結果に親ノードがアクセスできることを表す。複数のSQLクエリをブロック110で同時に実行する必要はないことに留意すべきである。
図示した例では、SQLクエリは、有向グラフの各々がそのノードの少なくとも1つを別の有向グラフと共有するようになっている(有向グラフの各々がそのエッジのうちの少なくとも1つにより別の有向グラフの少なくとも1つのノードに連結されて、それらの有向グラフが少なくとも1つのノードを共有するようになっている)。言い換えると、有向グラフの各々は、別の有向グラフのノードに連結されたエッジを含み、少なくともそのノードがそれらの有向グラフによって共有されるようになっている。したがって、クエリプランは、少なくとも1つのノードを共有するという点で結合される(「重複する」とも称する)。クエリプランは、2つ以上のノード(例えば、2つ以上のノードおよび1つまたは複数のエッジのサブグラフ)を共有することもできる。1つまたは複数の共有されたノードが存在するように、少なくとも1つのクエリプラン演算が2つ以上のクエリプランにおいて同一でなければならない。一実施形態は、別のクエリプランが生成および実行される前に生成および実行されるクエリプランのうちの1つをサポートする。例えば、一実施形態において、1つの有向グラフを生成および実行することは、生成中の1つの有向グラフのエッジを先に生成された1つの有向グラフのノードに連結して、少なくとも先に生成された1つの有向グラフのノードを再利用することにより(より詳細には、組み込むことにより)、生成中の1つの有向グラフが、少なくとも先に生成された1つの有向グラフとノードを共有することを含む。したがって、第1のクエリプランが既に生成され、実行後にメモリに保存されている場合には、第2のクエリプランの生成は、第1のクエリプランに既に存在し、かつ同一であるため共有可能な1つまたは複数のノード(および場合により、ノードおよびエッジの1つまたは複数のサブグラフ)の生成を必要としない。第2のクエリプランの生成は、同一である1つまたは複数のノード(および場合により、1つまたは複数のサブグラフ)を第1のクエリプランから再利用する(より詳細には、「組み込む」)。
図1において、SQLクエリは、有向グラフの各々が、そのエッジのうちの少なくとも1つにより、別の有向グラフの少なくとも1つのノードに連結されるようになっている(例えば、そのようなクエリプランを必要とするSQLクエリが送信されており、クエリプランは同時にメモリに存在する)。言い換えると、図1は、本明細書で後述するように、SQLクエリ、および結果として得られる、ある特性およびタイミング(SQLクエリは同時にまたは異なる時間に送信することができるが、クエリプランは同時にメモリに存在する)を共有するクエリプランに依存する能力を示す。実施形態はこの能力を有するが、実施形態は、異なる時点で以下もサポートする。1)メモリにクエリプランを有していない、2)実行後に1つのクエリプランをメモリに有する、3)実行後に複数のクエリプランをメモリに有するが、各々がメモリ内の別のクエリプランと結合していない(いずれのノードも共有していない)という点で独立している、4)実行後に複数のクエリプランをメモリに有し、1つまたは複数が独立し、グループが結合されている、5)実行後にクエリプランの複数のグループをメモリに有し、各グループのクエリプランが結合されるが、所与のグループのクエリプランは別のグループのクエリプランに結合されていない(異なるグループが独立している)など。
加えてまたはあるいは、一実施形態は、有向グラフの各々がルートノードを含み、かつ有向グラフの少なくとも一部がルートノードを共有しない(言い換えると、結果として得られるクエリプランは、これらの特定の有向グラフの各々のルートノードが別の有向グラフと共有されないようになっている)ことをサポートする。加えてまたはあるいは、一実施形態は、少なくとも2つの有向グラフが、ルートノード、少なくとも1つまたは複数のリーフノード、および1つまたは複数の中間ノードを各々含み、中間ノードは1つまたは複数の親ノードおよび1つまたは複数の子ノードの両方を有するノードであり(ルートノードは少なくとも1つの中間ノードに連結され、各中間ノードは少なくとも別の中間ノードまたは1つのリーフノードに連結され)、これら2つの有向グラフが、少なくとも1つの中間ノードおよびその子孫ノードを共有することをサポートする。言い換えると、一実施形態は、少なくとも2つのクエリプランがノードおよびエッジのサブグラフを共有することをサポートする。加えてまたはあるいは、一実施形態は、少なくとも2つの有向グラフが各々ルートノードおよび1つまたは複数のリーフノードを含み、これら2つの有向グラフのうちの第1のグラフが第2のグラフのサブグラフである(言い換えると、第1のグラフのルートノードおよび中間ノードが第2のグラフの中間ノードであり、第1のグラフのリーフノードが第2のグラフのリーフノードでもある)ことをサポートする。
有向グラフの各々のノードのうちの少なくとも1つは、テンポラルデータベースのテンポラルテーブルのうちの1つを特定し、有向グラフの各々のノードのうちの少なくとも別の1つは、実行後にメモリに保存され、かつそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定する。加えてまたはあるいは、一実施形態において、有向グラフによって共有されたノードのうちの少なくとも1つは、実行後にメモリに保存され、かつそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定する。加えてまたはあるいは、有向グラフのノードの各々は、テンポラル−リレーショナルデータベースのテンポラルテーブルのうちの1つ、またはそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルのうちの1つを特定する。加えてまたはあるいは、クエリプラン演算子のうちの1つを実行した結果を保存するテンポラルテーブルの各々は、少なくともそのテンポラルテーブルを特定するノードが実行後にメモリに保存される限り、実行後にメモリに保存される。加えてまたはあるいは、一実施形態において、クエリプランは実行後にメモリに保存されるため、有向グラフのノードおよびサブグラフは潜在的な再利用のために使用可能になる。加えてまたはあるいは、一実施形態において、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルの各々は、潜在的な再利用のために実行後にメモリに保存されている。加えてまたはあるいは、一実施形態において、第2のクエリプランが、1つまたは複数の同一のクエリプラン演算(すなわち、同一のパラメータを有する同一の入力テンポラルテーブルに作用する同一のクエリプラン演算子)を、既に実行された第1のクエリプランとして含む場合、第2のクエリプランは、第1のクエリプランと共通のテンポラルテーブルを、必要に応じて増分更新して再利用することができる。テンポラルテーブルを増分更新することは、既存のデータレコードのタイムスタンプの変更および/または(既存のレコードを単に編集または削除するのとは対照的な)新しいデータレコードの作成によって変更を反映する上記の方法を指す。ノードにより特定されたテンポラルテーブルを増分更新することは、そのノードにより表されたクエリプラン演算子が実行されている(増分実行であっても完全実行であっても)ことに応答してそのテンポラルテーブルを増分更新することを指す。ノードにより特定されたテンポラルテーブルを増分更新することは、そのノードにより表されたクエリプラン演算子の実行が不要であるとき(例えば、その実行を避けることができることを示す最適化があるとき)には不要であってよい。したがって、ノードにより特定されたテンポラルテーブルを必要に応じて増分更新することは、そのノードにより表されたクエリプラン演算子を実行する(増分実行であっても完全再実行であっても)こと、および、実行を避けることができることを示す最適化がないとき(したがって、そのような最適化を実装しない実施形態を含むとき、またはそのような最適化を実装するが、最適化により実行および増分更新を避けることができない実施形態において)テンポラルテーブルを増分更新することを指す。加えてまたはあるいは、一部の実施形態において、変更が行われなかった場合、ノードを既存のクエリプランと共有する、新たに送信されたクエリプランは、そのノードにより表されたクエリプラン演算子を再実行することなく、共有されたノードにより特定されたテンポラルテーブルを再利用することができる。しかしながら、クエリプラン演算子の入力テンポラルテーブルの変更は、クエリプラン演算子の実行(増分または完全)を必要とすることがある。
クエリプランによりノードを共有すること、ならびに実行後にクエリプランおよびテンポラルテーブルをメモリに保存すること(特に、有向グラフの各々のノードのうちの少なくとも1つが、実行後にメモリに保存され、かつそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定する場合)により、一部の実施形態は、大量のデータを扱うときを含む、略リアルタイムのストリーミングの実行をサポートすることができる。これは、一部には以下の理由による。1)実行後にクエリプランをメモリに保存し、これらのクエリプランにノードを共有させ(可能であれば)、したがってそれらの共有されたノードが特定するテンポラルテーブルを共有させ、必要なメモリ、計算リソース、および計算時間を減少させる、2)テンポラルテーブルを使用すること、および実行後にテンポラルテーブルをメモリに保存することにより、ある実施形態は、1つまたは複数のクエリプラン演算子を実装して、「増分実行」(「差分」のみで実行、「増分クエリ処理」および「増分再計算」とも称する)を行い、それらのクエリプラン演算子を表すノードにより特定されたテンポラルテーブルを必要に応じて増分更新する(増分実行により、クエリプラン演算子へのテンポラルテーブル入力の各々の全体におけるクエリプラン演算子の再実行/再計算(本明細書において「完全再実行」と称する)と比較して、必要な計算リソースおよび計算時間が減少する)。したがって、1つまたは複数のテンポラルテーブルのセットを入力として有するクエリプラン演算子の実行が、それらのテンポラルテーブルの少なくとも1つから、増分挿入および削除されたデータレコードのみ(すべてのデータレコードとは対照的に、差分)にアクセスすることを含む場合には、実行は「増分実行」となる。それに対して、1つまたは複数のテンポラルテーブルのセットを入力として有するクエリプラン演算子の実行が、セットのテンポラルテーブルのすべてから有効なデータレコードのすべてにアクセスすることを必要とする場合には、実行は「完全実行」となる。所与のクエリプラン演算子を実装して、増分実行、完全実行、または両方(両方の場合には、可能であれば増分実行を行う)を行うことができる。加えてまたはあるいは、一実施形態において、ブロック120における生成および実行は、少なくとも、有向グラフのうちの2つによって共有された1つのノードにより表されたクエリプラン演算子を増分実行することを含む。例えば、第1のクエリプランが既に生成および実行されており、そのノードおよびノードが特定するテンポラルテーブルが実行後にメモリに保存されている場合には、第2のクエリプランの生成は、ノードを共有することができるため、既に第1のクエリプランに存在する、第2のクエリプランに必要な1つまたは複数のノード(および場合により、ノードおよびエッジの1つまたは複数のサブグラフ)を作成することを必要とせず、第2のクエリプランの実行は、更新が必要なテンポラルテーブルにおいて、それらの共有されたノードにより表されたクエリプラン演算子を増分実行することを含むことができる。
ブロック130は、複数のSQLクエリの各々についてのクエリ結果を、そのSQLクエリをリレーショナルデータベース管理システムに送信したクライアントに送信することを含む。本明細書において、「クライアント」という用語はRDBMSのクライアントを指し、したがって、そのようなクライアントを「データベースクライアント」または「RDBMSクライアント」と称することもできる。
加えてまたはあるいは、一実施形態において、生成および実行は、有向グラフのうちの1つを生成することの一部として、1)先に生成された1つの有向グラフの一部であり、かつ再利用(より詳細には、組込み)可能な少なくとも1つのノードを特定すること、および2)先に生成された1つの有向グラフの一部であるノードのうちの1つに連結されたエッジを、有向グラフのうちの1つに追加することを含むことができる。加えて、一実施形態において、追加されたエッジが連結される1つのノードは、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定するノードのうちの1つであってよく、生成および実行は、有向グラフのうちの1つを実行することの一部として、追加されたエッジが連結された1つのノードにより特定されたテンポラルテーブルを必要に応じて増分更新することを含んで、再利用することを含むことができる。これは、そのテンポラルテーブルを再作成するよりも効率的であり、さらに、更新が必要な場合、そのノードにより表されたクエリプラン演算子を増分実行することができるときに(そのノードの子ノードにより特定されたテンポラルテーブル全体において、そのノードにより表されたクエリプラン演算子を再実行するのとは対照的に(すなわち、完全再実行とは対照的に))、効率がさらに向上する。あるいは、一実施形態において、生成および実行は、1)現在生成中の他の有向グラフの一部として再利用可能な、既に生成された有向グラフの一部を特定すること、および2)それらの特定された部分を再作成するのではなく、それらの特定された部分を他の有向グラフの生成において再利用することを含むことができる。加えて、一実施形態において、再利用された部分は、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように各々作成されたテンポラルテーブルを特定する1つまたは複数のノードを含むことができ、生成および実行は、再利用された部分の1つまたは複数のノードにより特定されたテンポラルテーブルを必要に応じて増分更新することを含んで、再利用することを含むことができる。これは、再利用された部分の1つまたは複数のノードにより特定された1つまたは複数のテンポラルテーブルを再作成するよりも効率的であり、さらに、更新が必要な場合、再利用された部分の1つまたは複数のノードにより表された1つまたは複数のクエリプラン演算子を増分実行することができるときに(そのノードの各子ノードにより特定されたテンポラルテーブルの有効行において、そのようなノードのクエリプラン演算子を再実行する(完全再実行)のとは対照的に)、効率がさらに向上する。
異なる実施形態は、異なる技術を使用して、クエリプランのいずれかの部分(ノードおよびノードに連結されたエッジのうちの1つまたは複数)または全体および対応するテンポラルテーブル(TT)が、実行後にどのくらい長くメモリに保存されるかを判定することができる。クエリプランの各々について、1)クエリプランが依然として必要とされる間(例えば、クライアントのいずれかが、クエリプランを生成したSQLクエリに対する更新を受信する予定である間)の潜在的な再利用のために、および/または2)1つまたは複数の他のクエリプランの生成および実行において再利用の機会を提供するために、有向グラフ(またはその一部)のノードおよびエッジならびに対応するTTが実行後にメモリに保存される。クエリプランまたはその一部を実行後にメモリに保存してこの機会を提供する時間の長さは、別のクエリプランの生成および実行がクエリプラン(および対応するTT)の一部または全体を再利用することができることに備えて必要なメモリを使用する価値があると思われる時間(例えば、一定の時間、プログラム可能な時間、(i)そのクエリプランの一部またはすべての再利用の可能性、(ii)ノードおよびエッジが実行後にメモリに保存されること(例えば、ノードと他のノードとの連結、ノードのタイプ、過去のノードの使用などをベースとして、メモリ消費と再利用の機会とのバランスを取るために)、(iii)他のSQLクエリの到着率、および/または(iv)使用可能なリソース(例えば、メモリ内のクエリプランおよび対応するTTがメモリの閾値量を超えたとき))をベースとして計算された時間)をベースとすることができる。加えてまたはあるいは、一実施形態において、「アクティブ」または「非アクティブ」の特定は、クエリプランの各々について維持され(例えば、特定はクエリプランの各々の有向グラフのルートノードに関連付けられる)、「アクティブ」クエリプランの一部ではないノード(およびノードが特定するTT)は、メモリへの保存から除去される候補である。異なる実施形態は、いつ「非アクティブ」表示を異なって行うか(例えば、そのSQLクエリに対応する接続がクローズされた、そのSQLクエリを送信したクライアントが、クエリに興味がなくなっていることを示した、一定時間またはプログラム可能な時間が経過した)を判定することができる。また、異なる実施形態は、異なる時間に(例えば、直ちに、また、一定時間またはプログラム可能な時間の後、メモリ内のクエリプランおよびTTがメモリの閾値量を超えたとき、通常のガベージコレクション動作の一部として)実際の除去を行うことができる。代替実施形態は、「アクティブ」および「非アクティブ」表示をせず、クライアント接続がクローズされているかどうかを確認して、いずれかの対応するクエリプランが除去の候補であるかどうかを判定することができる。
加えてまたはあるいは、一実施形態において、有向グラフのうちの少なくとも2つは、ルートノードから始まり、1つまたは複数の中間ノードを含み、1つまたは複数のリーフノードで終わることができ、各有向グラフのルートノードおよび1つまたは複数の中間ノードは各々、そのノードについて、その有向グラフの1つまたは複数の他のノードを子ノードとして特定する。さらに、ルートノードおよび中間ノードの各々により表されたクエリプラン演算子の各々は、そのノードの1つまたは複数の子ノードにより特定されたテンポラルテーブルのうちの1つまたは複数(またはそのビューもしくはコピー)に作用する。加えてまたはあるいは、一実施形態において、1つまたは複数のリーフノードの各々により表されたクエリプラン演算子の実行により、テンポラル−リレーショナルデータベースのテンポラルテーブルのうちの1つからデータを検索する(例えば、テンポラルテーブルのうちの1つへの参照(またはそのビューもしくはコピー)を返す)。加えて、一実施形態において、ノード(例えば、ルートおよび中間ノード)により表された1つまたは複数のクエリプラン演算子は、テンポラル−リレーショナル代数演算(テンポラル−リレーショナル代数演算は、テンポラルテーブルで実行されるリレーショナル代数演算である)を実行することができる。
加えてまたはあるいは、一実施形態において、RDBMSは、複数の、実際には多数の「重複」クエリプランを一度にサポートするように設計される。複数の重複クエリプランが存在するのには様々な理由がある。例えば、ある使用事例は、クエリプランが比較的大きい「クエリ深さ」を有するSQLクエリを必要とし、所与のクエリプランのクエリ深さは、ルートノードとリーフノードとの間の経路上の連続するノード間のエッジの最大数により測定される。一実施形態において、大きいクエリ深さを有するクエリプランは11以上のノードを有する経路を含むものであるが、代替実施形態は、50〜100のノードの閾値を使用することができる。比較的大きいクエリ深さを有するクエリプランを生成することにより、比較的多数のノード、したがってより大きい重複の機会が生じる。さらに、大きいクエリ深さを有するクエリプランを必要とするSQLクエリは、最初からやり直すための重要な処理を必要とすることがあるので、データベースがクエリプラン演算子を増分実行することができることは、効率をさらに向上させる(例えば、クエリ結果の生成に必要な時間を減少させると共に処理リソースの所要電力を減少させる、処理リソースを他のタスクに使用できるようにする、データベースがより多くのクエリを同時にサポートできるようにする、メモリの読取り/書込み動作の数を減少させるなど)という利点を有する。特定の例により、一実施形態において、リレーショナルデータベース管理システムを複雑な解析処理に使用することができ、使用事例は、クエリプランが比較的大きいクエリ深さを有するSQLクエリを必要とする。
実施形態は、本明細書に記載されるように、増分更新、レイジー更新、スキップ更新、およびこれらの組合せをサポートすることができる。増分更新をサポートする一実施形態において、テンポラル−リレーショナルデータベースの一部であり、かつSQLクエリがデータへのアクセスを必要とする、テンポラルテーブルのうちの少なくとも所与の1つのコンテンツを修正したことに応答して、以下が実行される。1)少なくともその修正されたテンポラル−リレーショナルデータベーステーブルを特定するノードの先祖により特定されたテンポラルテーブルを増分更新する(可能であれば増分実行により)(SQLクエリのクエリプランの有向グラフのノードであり、かつテンポラルテーブルのうちの所与の1つを特定するノードに直接的または間接的に依存するノードにより特定されたテンポラルテーブルを増分更新する)、2)SQLクエリを送信したクライアントに、SQLクエリについてのクエリ結果に対する増分更新(「増分クエリ結果」とも称する)を送信する。レイジー更新をサポートする実施形態においては、クエリプラン演算子を実行した結果を保存するように作成されたTTが、(SQLクエリのうちの少なくとも1つがデータへのアクセスを必要とする)テンポラル−リレーショナルデータベースのテンポラルテーブルのうちの1つのコンテンツが修正されたことに応答して、直ちに更新されない。むしろ、1つまたは複数の事象が発生する(例えば、クエリ結果(例えば、初期または増分)をクライアントに送る必要がある、一定時間が経過する、プログラム可能な時間が経過する、ノードおよびエッジをベースとして(例えば、ノードと他のノードとの連結、ノードのタイプ、過去のノードの使用などをベースとして)計算された時間が経過する、他のSQLクエリの到着率が閾値を超える、および/または使用可能な計算リソースが閾値を下回る)まで更新を遅延させて、他の修正を受信した場合にバッチ処理を可能にする。ノードにより特定されたテンポラルテーブルの増分更新は、そのノードにより表されたクエリプラン演算子の実行が不要であるとき(例えば、実行を避けることができることを示すスキップ更新などの最適化が存在するとき)には不要であってよい。様々なタイプのスキップ更新があり、実施形態は、そのいずれもサポートしなくてもよく、1つまたは2つ以上をサポートしてもよい。したがって、加えてまたはあるいは、一部の実施形態は、1)その後に修正されたテンポラルテーブルを特定するノードに直接的または間接的に依存しない、かつ/または2)最近十分に実行された(本明細書において、最近十分に「リフレッシュされた」と称する)(例えば、これは、クエリプランの実行を並行してサポートし、かつ/またはクエリ実行を「過去の日付で」サポートする実施形態において行うことができる)ノードにより表されたクエリプラン演算子の実行を避けることのできるスキップ更新の最適化をサポートする。例えば、スキップ更新の最適化をサポートする一部の実施形態において、テンポラル−リレーショナルデータベースの一部であり、かつSQLクエリのうちの少なくとも1つがデータへのアクセスを必要とする、テンポラルテーブルのうちの少なくとも所与の1つのコンテンツを修正したことに応答して、実行中のクエリプランの一部であり、かつ修正されたテンポラルテーブルのうちの所与の1つを特定するノードに直接的または間接的に依存しないノードにより表されたクエリプラン演算の実行がスキップされる(増分実行であっても完全再実行であっても)。別の例として、スキップ更新の最適化をサポートする一部の実施形態において、クエリプランの実行時に、実行中のクエリプランの一部であり、かつ最近十分に実行された(本明細書では、最近十分にリフレッシュされたとも称する)ノードにより表されたクエリプラン演算子の実行が避けられる。したがって、ノードにより特定されたテンポラルテーブルを必要に応じて増分更新することは、そのノードにより表されたクエリプラン演算子を実行すること(増分実行であっても完全再実行であっても)、および、実行を避けることができることを示す最適化が存在しないとき(したがって、そのような最適化を実装しない実施形態を含むとき、またはそのような最適化を実装するが、最適化により実行および増分更新を避けることができない状況の実施形態において)テンポラルテーブルを増分更新することを指す。
加えてまたはあるいは、一実施形態において、ブロック110のSQLクエリは、リレーショナルデータベース管理システムにより受信された第1のSQLクエリおよび第2のSQLクエリを含むことができる。さらに、ブロック120の生成および実行は、第1のSQLクエリの第1のクエリプランおよび第2のSQLクエリの第2のクエリプランを生成することを含み、第2のクエリプランの有向グラフは、そのエッジのうちの少なくとも1つにより、第1のクエリプランの有向グラフの少なくとも1つのノードに連結されて、それらの有向グラフが少なくとも1つのノードを共有するようになっている。加えてまたはあるいは、一実施形態において、第1のクエリプランおよび第2のクエリプランの有向グラフによって共有された少なくとも1つのノードは、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたノードである。加えてまたはあるいは、一実施形態において、第2のクエリプランの生成および実行は、少なくとも、第1のクエリプランおよび第2のクエリプランの有向グラフによって共有された少なくとも1つのノードにより表されたクエリプラン演算子を増分実行することを含む。加えてまたはあるいは、第1のSQLクエリおよび第2のSQLクエリは、リレーショナルデータベース管理システムにより受信されて、第1のダッシュボードコンテンツ要素および第2のダッシュボードコンテンツ要素をそれぞれ入力する。加えて、一実施形態において、第1のダッシュボードコンテンツ要素および第2のダッシュボードコンテンツ要素は、異なるエンドユーザクライアントにより表示される異なるダッシュボードの部分であってよい。あるいは、一実施形態において、第1のダッシュボードコンテンツ要素および第2のダッシュボードコンテンツ要素は、表示される同一のダッシュボードの部分であってよい。
一部の実施形態は、加えてまたはあるいは、クライアントがクエリ結果に対する更新を受信することのできるSQLクエリであるサブスクリプションSQLクエリをサポートする。一実施形態において、クライアントがサブスクリプションSQLクエリを送信すると、RDBMSは最初に、サブスクリプションSQLクエリが最初に実行されたときのデータを表す初期クエリ結果をクライアントに送信する。その後、RDBMSは、サブスクリプションSQLクエリがデータへのアクセスを必要とするテンポラル−リレーショナルデータベースのいずれかのテンポラルテーブルのコンテンツの修正により生じるそれらのクエリ結果に対する更新を、クライアントに送信する。一実施形態において、サブスクリプションSQLクエリ(およびクエリプランのノードにより特定されたテンポラルテーブル)のクエリプランは、少なくともそのサブスクリプションSQLクエリを送信したクライアントがそのサブスクリプションSQLクエリについてのクローズサブスクリプションメッセージを送信するまで、実行後にメモリに保存される。このようにして、RDBMSがさらなるSQLクエリを受信すると、サブスクリプションSQLクエリの使用により、複数の重複クエリプランが存在する機会が増加する(すなわち、既存のクエリプランが実行後にメモリに長く保存されるほど、後で生成されたクエリプランが既存のクエリプランと重複する機会が増加する)。場合により、サブスクリプションSQLクエリのクエリプランの再利用は、クエリプランの1つまたは複数のノードにより表されたクエリプラン演算子のうちの1つまたは複数を増分実行して、それらの1つまたは複数のノードが特定する既存のテンポラルテーブルを増分更新すること(完全再実行とは対照的に)を含むことができる。SQLクエリおよびサブスクリプションSQLクエリの両方をサポートする異なる実施形態は、異なる技術(例えば、サブスクリプションSQLクエリの前に、「subscribe to」などのフレーズ/プレフィックスを付けることができる)を使用して2つを区別することができる。加えて、サブスクリプションSQLクエリのみをサポートする一実施形態において、RDBMSは、送信された各SQLクエリをサブスクリプションSQLクエリとして扱い、そのようなフレーズ/プレフィックスを必要としない。一実施形態において、ブロック110のSQLクエリは、サブスクリプションSQLクエリである第1のSQLクエリを含むことができ、ブロック120は、第1のSQLクエリの第1のクエリプランを生成することを含む。さらに、ブロック110のSQLクエリは、第1のSQLクエリがサブスクリプションSQLクエリであるため、第1のSQLクエリプランが生成された後、第1のクエリプランが実行後にメモリに保存されている間に受信される第2のSQLクエリを含むことができる。「潜在的な再利用のため」という表現は、既存のクエリプランのノード(およびノードが特定するテンポラルテーブル)が実行後にメモリに保存されるため、実施形態が以下の1つまたは複数をサポートすることができることを意味する。1)それらの既存のクエリプラン(またはそれらの既存のクエリプランのうちの1つまたは複数)の1つまたは複数の部分(ノードおよび/またはサブグラフ)を現在生成中のクエリプランに組み込むこと、2)ノードのうちの少なくとも1つがそのように組み込まれたときに、そのノードにより特定されたテンポラルテーブルを可能なときにそのまま使用すること(そのテンポラルテーブルを特定するノードにより表されたクエリプラン演算の再実行を必要とするのとは対照的に)、3)ノードのうちの少なくとも1つがそのように組み込まれたときに、そのノードにより表されたクエリプラン演算子を増分実行して、そのノードにより特定された既存のテンポラルテーブルを増分更新すること(完全再実行とは対照的に)、4)ノードのうちの少なくとも1つがそのように組み込まれたときに、そのノードにより表されたクエリプラン演算子を完全再実行して、そのノードにより特定された既存のテンポラルテーブルを増分更新すること、5)サブスクリプションSQLクエリの既存のクエリプランのリーフノードにより表されたテンポラルテーブルのコンテンツが更新されたときに、その既存のクエリプランを再利用すること、および/または、6)サブスクリプションSQLクエリの既存のクエリプランのリーフノードにより表されたテンポラルテーブルのコンテンツが更新されたときに、その既存のクエリプランのノードにより表されたクエリプラン演算子のうちの少なくとも1つを増分実行して、そのクエリプラン演算子の結果を保存している既存のテンポラルテーブルを増分更新すること(完全再実行とは対照的に)。
図2は、一実施形態によるリレーショナルデータベース管理システムを示すブロック図である。図2は、クライアント側200とサーバ側210とに分けられている。クライアント側200は、1つまたは複数のクライアント(図示せず)を含み、各クライアントは、データベースドライバ204のうちの1つ(リモートプロシージャコール(RPC)モジュールとしても知られる)および当技術分野で公知の他のコンポーネント(図示せず)を含む。
サーバ側210は、リレーショナルデータベース管理システム(RDBMS)212を含む。RDBMS212は、テンポラル−リレーショナルデータベース262を含み、クライアントはそこにデータを保存し、そこからデータを検索する。RDBMS212は、RDBMSに共通して見られるコンポーネントにより名付けられたコンポーネント(例えば、Joseph M. Hellerstein、Michael Stonebraker、およびJames Hamilton、「Architecture of a Database」、Foundations and Trends in Databases、Vol.1、No.2(2007)、141〜259ページ、Joseph M. HellersteinおよびMichael Stonebraker、「Anatomy of a Database」、Readings in Database Systems、第4版、The MIT Press(2005)、42〜95ページ)、例えば、プロセスクライアント通信マネージャ(PCCM)214、パーサ218、クエリリライタ224、クエリオプティマイザ230、およびクエリエグゼキュータ240(エグゼキュータまたはクエリプランエグゼキュータとしても知られる)を含む。「クエリプロセッサ」という用語は、パーサ218、クエリリライタ224、クエリオプティマイザ230、およびクエリエグゼキュータ240の組合せを指すために使用されることがある。図1に関連して、一実施形態において、PCCM214はブロック100、130を実行し、クエリプロセッサはブロック110の残りを実行する(クエリオプティマイザ230とクエリエグゼキュータ240との組合せがブロック120を実行する)。
プロセスクライアント通信マネージャ214(一部の実施形態において、別個のマネージャとして実装され、単にプロセスマネージャと称することもある)は、1)クライアントに対する接続状態を確立および保存し、SQLステートメント216の形式のクライアント要求に応答し、クエリ結果217を返すこと、および/または2)RDBMS212の様々なタスク(アドミッション制御の実行を含む)をカプセル化およびスケジューリングすることを含む、様々なタスクを実行することができる。クライアントのデータベースドライバ204とプロセスクライアント通信マネージャ214との間で接続が確立される。データベースドライバ204は、SQLステートメント216をPCCM214に送信する。
PCCM214は、SQLステートメント216をパーサ218に提供する。一実施形態において、パーサ218のタスクは、SQLステートメント216を内部表現220(例えば、抽象構文木(AST))に変換することを含む。決定ブロック222は、SQLクエリであるSQLステートメント216をSQLクエリではないSQLステートメント216から区別することを示す。この決定をRDBMS212内の1つまたは複数の異なる位置(例えば、図示した位置、および/またはクエリオプティマイザ230とクエリエグゼキュータ240との間、および/またはクエリエグゼキュータ240の一部として)で行うことができるため、決定ブロック222は破線で示される。図示した位置で、SQLクエリであるSQLステートメント216から生成された内部表現220はクエリリライタ224に提供され、SQLクエリでないSQLステートメント216から生成された内部表現220は非クエリエグゼキュータ228に提供される。
クエリリライタ224は、SQLクエリの内部表現220を単純化および正規化して、書換え済み内部表現226(例えば、クエリ文字列の構造およびコンテンツを表す書換え済みAST)を生成し、これがクエリオプティマイザ230に提供される。クエリリライタ224は別個のコンポーネントとして示されているが、一部の実施形態において、一部の商用RDBMSのように、クエリリライタ224はパーサ218またはクエリオプティマイザ230の一部である。
クエリオプティマイザ230は、書換え済み内部表現226からクエリプランを生成する(クエリプラン最適化の実行を含むことができる)。一部の実施形態において、書換え済み内部表現226の各々について、クエリオプティマイザ230は、物理クエリプラン242において「物理クエリプラン」(「完全特定クエリプラン」としても知られる)を作成する前に、「論理クエリプラン」(本明細書でさらに後述する)を最初に作成する。異なる実施形態は、論理クエリプランを当技術分野で周知のものを含む異なる方法で生成することができる(例えば、Van den Bussche、J.、Vansummeren、S.、Translating SQL into the Relational Algebra、https://cs.ulb.ac.be/public/_media/teaching/infoh417/sql2alg_eng.pdfで利用可能、2016年10月に検索、Kifer、M.他、Database Systems:Application Oriented Approach、Complete Version 第2版、ISBN−13:978−0321268457、2005年3月26日)。例えば、一実施形態において、ASTをたどり、クエリプラン演算子(例えば、「select」ステートメントのPROJECT、「where」句のJOINまたはSELECTなど)に対応するASTからノードを作成することにより、論理クエリプランが書換え済み内部表現から作成される。
クエリエグゼキュータ240は、SQLクエリに対応する物理クエリプラン242を実行する。これは、テンポラル−リレーショナルデータベース262の特定のテンポラルテーブルの特定のデータにアクセスすること、それらの物理クエリプランにより特定されたクエリプラン演算を実行すること、結果をプロセスクライアント通信マネージャ214に提供し、次いでプロセスクライアント通信マネージャ214が、それらの結果(クエリ結果217として示す)を、それぞれのSQLクエリを送信した各クライアントに提供することを含む。
物理クエリプラン242の各々は、エッジにより連結されたノードの有向グラフを含み、有向グラフの各々は、実行時にSQLクエリについてのクエリ結果を提供するクエリプラン演算子の順序セットを表す。クエリオプティマイザ230はクエリプランコネクタ232を含む。一実施形態において、論理クエリプランの各々について、クエリプランコネクタ232は、実行後に現在メモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に保存されている物理クエリプラン242に既に存在する1つまたは複数のノードおよび/またはサブグラフ(ならびに一部の実施形態において、有向グラフ全体)を再利用する、または必要な物理クエリプランに組み込むことにより、必要な物理クエリプランを生成することができるかどうかを判定する。クエリプランコネクタ232が、所与の論理クエリプランについて再利用または組込みが可能であると判定した場合には、物理クエリプランの欠けている部分(1つまたは複数のノード、エッジ、および/またはサブグラフ)(あれば)のみが物理クエリプラン242に追加され、1つまたは複数のエッジにより、再利用可能であると判定された1つまたは複数のノードおよび/またはサブグラフ(ならびに、一部の実施形態において、有向グラフ全体)に連結される。クエリプランコネクタ232の演算を、クエリプラン最適化と共に実行しても、クエリプラン最適化後に(最適化されたクエリプラン上で)実行しても、両方であってもよい。
一実施形態において、クエリプランコネクタ232は、物理クエリプラン242の対応するノードに対するノードキーのマッピングを保存するためのキャッシュ234(ノードキー対ノードキャッシュとも称する)を含む。一実施形態において、物理クエリプラン242のノードの各々は、キャッシュ234のエントリを有し、ノードの各々のエントリは、ノードキーと、そのノードを物理クエリプラン242に位置決めするために使用する参照とを保存する。データ構造(例えば、ノード)の位置決めに使用する「参照」は、様々な方法(例えば、ポインタ、インデックス、ハンドル、キー、識別子など)で実装することができる。ノードキーは、クエリプランコネクタ232が、論理クエリプランの各ノードについて、前記判定(実行後に現在メモリに保存されている物理クエリプラン242に既に存在する1つまたは複数のノード、サブグラフ、および/または有向グラフ全体を再利用するまたは組み込むことにより、必要な物理クエリプランを生成することができるかどうか)を行うことができるようになっている。加えてまたはあるいは、一実施形態において、論理クエリプランは、キャッシュ234に保存されているものに関係なく作成され、その後、その論理クエリプレイを使用して、必要に応じてノードキーを生成し、既にキャッシュ234に存在するノードキーと比較する。キャッシュヒットは、そのエントリで参照されたノードを再利用する/組み込むことができることを意味する。グラフのエッジがグラフのノード内に保存される実施形態について説明したが、代替実施形態は、代わりにエッジをキャッシュ234に保存してもよい。
一実施形態において、クエリオプティマイザ230はまた、クエリプランを機械コードまたは解釈可能なクエリプラン(クロスプラットフォームの移植性を可能にするためのもので、軽量(例えば、注釈付きリレーショナル代数表現)または低級言語(例えば、Javaバイトコード)であり得る)にコンパイルするクエリコンパイラ236を含む。
物理クエリプラン242の有向グラフのノードの各々は、物理クエリプラン242のクエリプラン演算子のうちの1つを表す。物理クエリプラン242のノードを「ノード」または「物理クエリプランノード」(PQPN)と称することができる。
さらに、有向グラフの各々のノードのうちの少なくとも1つは、実行後にメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に保存され、かつそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定し、有向グラフの各々のノードのうちの少なくとも1つは、テンポラル−リレーショナルデータベース262のテンポラルテーブルのうちの1つを特定する。加えてまたはあるいは、一実施形態において、有向グラフによって共有されたノードのうちの少なくとも1つは、実行後にメモリに保存され、かつそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定する。加えてまたはあるいは、一実施形態において、物理クエリプランは実行後にメモリに保存されるため、有向グラフのノードおよびサブグラフは潜在的な再利用のために使用可能になる。加えてまたはあるいは、一実施形態において、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルの各々は、潜在的な再利用のために実行後にメモリに保存されている。加えてまたはあるいは、一実施形態において、第2のクエリプランが、1つまたは複数の同一のクエリプラン演算(同一のパラメータを有する同一の入力テンポラルテーブルに作用する同一のクエリプラン演算子)を、既に実行された第1のクエリプランとして含む場合、第2のクエリプランは、第1のクエリプランと共通のテンポラルテーブルを、必要に応じて増分更新して再利用することができる。加えてまたはあるいは、一実施形態において、有向グラフのうちの1つの生成は、1)先に生成された1つの有向グラフの一部であり、かつ再利用可能な少なくとも1つのノードを特定すること、および2)先に生成された1つの有向グラフの一部である1つのノードに連結されたエッジを、有向グラフのうちの1つに追加することを含む。加えて、一実施形態において、追加されたエッジが連結される1つのノードは、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定するノードのうちの1つであってよく、有向グラフのうちの1つを実行することは、追加されたエッジが連結された1つのノードにより特定されたテンポラルテーブルを必要に応じて増分更新することを含んで、再利用することを含むことができる。これは、そのテンポラルテーブルを再作成するよりも効率的であり、さらに、更新が必要な場合、そのノードにより表されたクエリプラン演算子を増分実行することができるときに(そのノードの各子ノードにより特定されたテンポラルテーブルの有効行において、そのノードにより表されたクエリプラン演算子を再実行する(完全再実行)のとは対照的に)、効率がさらに向上する。あるいは、一実施形態において、生成は、1)現在生成中の他の有向グラフの一部として再利用可能な既に生成された有向グラフの一部を特定すること、および2)それらの特定された部分を再作成するのではなく、それらの特定された部分を他の有向グラフの生成において再利用することを含むことができる。加えて、一実施形態において、再利用された部分は、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定する1つまたは複数のノードを含むことができ、実行は、再利用された部分の1つまたは複数のノードにより特定されたテンポラルテーブルを必要に応じて増分更新することを含んで、再利用することを含むことができる。これは、再利用された部分の1つまたは複数のノードにより特定された1つまたは複数のテンポラルテーブルを再作成するよりも効率的であり、さらに、更新が必要な場合、再利用された部分の1つまたは複数のノードにより表された1つまたは複数のクエリプラン演算子を増分実行することができるときに(そのノードの各子ノードにより特定されたテンポラルテーブルの有効行において、そのようなノードのクエリプラン演算子を再実行する(完全再実行)のとは対照的に)、効率がさらに向上する。
加えてまたはあるいは、一実施形態において、有向グラフのノードの各々は、テンポラル−リレーショナルデータベースのテンポラルテーブルのうちの1つ、またはそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルのうちの1つを特定する。加えてまたはあるいは、一実施形態において、有向グラフの各々は、ルートノードから始まり、1つまたは複数の中間ノードを含むことができ、1つまたは複数のリーフノードで終わり、各有向グラフのルートノードおよび1つまたは複数の中間ノードは各々、そのノードについて、その有向グラフの1つまたは複数の他のノードを子ノードとして特定する。加えてまたはあるいは、ルートノードおよび中間ノードの各々により表されたクエリプラン演算子の各々は、そのノードの1つまたは複数の子ノードにより特定されたテンポラルテーブルのうちの1つまたは複数(またはそのビューもしくはコピー)に作用する。加えてまたはあるいは、一実施形態において、1つまたは複数のリーフノードの各々により表されたクエリプラン演算子の実行により、テンポラル−リレーショナルデータベース262のテンポラルテーブルのうちの1つからデータを検索する。加えてまたはあるいは、一実施形態において、物理クエリプラン242のノードの各々についてキャッシュ234に維持されたノードキーは、そのノードおよびそのノードの0以上の特定された子ノードをベースとする。別の実施形態において、物理クエリプラン242のルートノードおよび中間ノードの各々についてキャッシュ234に維持されたノードキーは、そのノードおよびそのノードの特定された子ノードをベースとする。さらに別の実施形態において、物理クエリプラン242のノードの各々についてキャッシュ234に維持されたノードキーは、そのノードおよびその子孫(子ノード、孫ノードなど)(あれば)を含むクエリプランの部分を表すが、そのノードの先祖ノード(親ノード、祖父母ノードなど)により表されたクエリプランの部分を表さない。一実施形態において、物理クエリプラン242のルートノードおよび中間ノードの各々についてキャッシュ234に維持されたノードキーは、そのノードおよびそのノードの特定された子ノード(ある場合)のキーをベースとする。
図2の実施形態において、テンポラルテーブル(TT)の各々は、オブジェクトによりカプセル化され、これらのオブジェクトは、テンポラル−リレーショナルデータベース262内のベーステンポラルテーブル(BTT)260と、ノードの各々により表されたクエリプラン演算子を実行した結果を保存する派生テンポラルテーブル(DTT)264とに分割される。前述したように、異なる実施形態は、TTのコンテンツをメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に異なる方法で保存することができる(例えば、カラム型(列指向としても知られる)構成を使用して、列指向構成を使用して、1つまたは複数のテンポラルテーブルの行指向構成および列指向構成の両方を使用して、1つまたは複数のテンポラルテーブルの行指向構成および1つまたは複数の他のテンポラルテーブルの列指向構成を使用してなどにより、コンテンツを保存することができる)。一実施形態において、BTT260およびDTT264は、比較的速い読み書き時間でメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に保存され(例えば、ダイナミックランダムアクセスメモリ(DRAM)、スタティックランダムアクセスメモリ(SRAM)、および/または相変化メモリ)、代替実施形態において、BTT260および/またはDTT264の一部を、比較的遅い読み書き時間でメモリに保存することができる(例えば、フラッシュ、SSD、磁気ディスク)。
一部の実施形態において、物理クエリプラン242の物理クエリプランノード(PQPN)を「テンポラルテーブルノード」(TTN)と称し、このテンポラルテーブルノードは、派生テンポラルテーブルノード(DTTN)244とベーステンポラルテーブルノード(BTTN)246とに分割される。BTTN246は、物理クエリプラン242の有向グラフのリーフノードを指し(したがって、データベースクライアントがシステムに対して発行するSQLクエリにおいて参照可能であるという点で、「データベースクライアントに見える」テンポラルテーブルを指し)、DTTN244は、物理クエリプラン242の有向グラフのルートノードおよび中間ノードを指す(したがって、「データベースクライアントに見えない」テンポラルテーブルを指す)。一部の実施形態において、BTTNおよびDTTNという用語は、リーフノードであるPQPNをルートノードまたは中間ノードであるPQPNから単に区別する(例えば、同一のオブジェクト指向クラスを使用してBTTNおよびDTTNを実装する)が、他の実施形態において、BTTNおよびDTTNという用語はまた、(例えば、BTTNおよびDTTNについて異なるオブジェクト指向クラスを使用して)実装の方法を区別する。一実施形態において、PQPNの各々は、対応する1つのBTT260または対応する1つのDTT264を位置決めするために使用される参照を含む(例えば、PQPN252A〜252Nの各々はBTTNであり、対応する1つのBTT254A〜254Mを位置決めするために使用される参照を含み、PQPN250A〜250Rの各々はDTTNであり、対応する1つのDTT258A〜258Rを位置決めするために使用される参照を含む)が、代替実施形態は、これらの対応を別の方法で保存することができる(例えば、1つまたは複数の他のデータ構造を使用してこれらの対応を保存する)。図2に省略記号で示すように、中間ノードおよびルートノードとして機能する多くのDTTN244(高レベルDTTNとも称する)が存在することがあると予想される。したがって、DTTN244であるPQPNの各々は、子ノードである1つまたは複数の他のPQPNのそれぞれに連結する1つまたは複数のエッジを有し、一実施形態において、DTTN244であるPQPNの各々は、1つまたは複数の他のPQPNを位置決めするために使用される参照を含む(そのような各参照は、PQPNから子ノードである1つまたは複数の他のPQPNのそれぞれへのエッジを形成する)が、代替実施形態は、これらのエッジを別の方法で保存することができる(例えば、1つまたは複数の他のデータ構造を使用してこれらのエッジを保存する)。通常、一部のPQPN250A〜250Rは、対応する1つのPQPN252A〜252N(BTTN)に連結するエッジを有し、一部のPQPN250A〜250Rは、1つまたは複数の他のPQPN250A〜250R(他のDTTN)に連結するエッジを有する。ある実施形態はまた、1つまたは複数の他のDTTNおよび子ノードである1つまたは複数のBTTNを有するDTTNをサポートする。
非クエリエグゼキュータ228は、INSERT演算(すなわち、1つまたは複数のデータレコードをテンポラル−リレーショナルデータベースのテンポラルテーブルに挿入する)、UPDATE演算(すなわち、新しいデータレコードを挿入し、修正されたデータレコードのタイムスタンプを変更する(例えば、valid_to列の値を更新時間に設定する)ことにより、テンポラル−リレーショナルデータベースの1つまたは複数のテンポラルテーブルの1つまたは複数のデータレコードのコンテンツを変更する)、DELETE演算(すなわち、「削除された」データレコードのタイムスタンプを変更する(例えば、valid_to列の値を更新時間に設定する)ことにより、テンポラル−リレーショナルデータベースの1つまたは複数のテンポラルテーブルの1つまたは複数データレコードを削除する)を実行することができ、データレコードの追加、データレコードの削除、および/または既存のデータレコードのコンテンツの変更によりテンポラルテーブルのコンテンツを修正する他の演算を実行してもよく、かつ少なくともCREATE TABLEを実行し、テンポラルテーブルのコンテンツではなく、テンポラルテーブル自体(例えば、スキーマ)を変更する他のデータ定義言語(DDL)の演算を実行してもよい。BTTN246を含む実施形態において、非クエリエグゼキュータ228はBTTN252A〜252Nとインターフェース接続し、BTTN252A〜252Nは対応する1つのBTT254A〜254Mにおいてこれらの演算を実行する。
BTT254からPQPN252への曲線矢印により示すように、PQPN252A〜252Nの各々は対応するBTT254A〜254Mにアクセスできる。PQPN252A〜252Nから異なるPQPN250A〜250Rへの曲線矢印により示すように、一部のPQPN250A〜250Rは、PQPN252A〜252Nが参照するBTT254A〜254Mにアクセスできる(例えば、PQPN250Aは、PQPN252Aが参照するBTT254Aにアクセスできる)。高レベルのPQPN250A〜250Rは、その子PQPN250が参照するDTT264にアクセスできる。したがって、1つのノードを別のノードに連結するエッジは、これらのノードがそれぞれ互いに親ノードおよび子ノードであり、子ノードの結果に親ノードがアクセスできることを表す。一実施形態において、このアクセスは、子ノードがその子ノードのDTT/BTTの読取専用ビューまたは読取専用コピーへの参照を親ノードに渡し、その後、親ノードが参照を使用してTTから必要なレコード(テンポラルテーブルのデータレコードのすべてではなく一部のみの場合も、テーブル全体の場合もある)にアクセスする形式であるが、代替実施形態は異なって実装することができる(例えば、TT全体を渡すことができる)。
一実施形態において、RDBMS演算は、クエリプラン(論理もしくは物理)またはTTがメモリに保存されていない(すなわち、物理クエリプラン242、BTT260、およびDTT264が空であるまたはインスタンス化されていない)状態、およびキャッシュ234が空であるまたはインスタンス化されていない状態で始まる。SQLステートメント216の1つまたは複数のCREATE TABLEステートメントに応答して、1つまたは複数のリーフノード(例えば、BTTN246)および対応するTT(例えば、BTT260)が作成される。第1のSQLクエリを受信したことに応答して、第1の物理クエリプランが生成および実行され、第1のSQLクエリを送信したクライアントにクエリ結果が返される。第1の物理クエリプランの生成は、必要な有向グラフの生成を含み、これは、1つまたは複数の必要な中間ノードおよびルートノード(例えば、DTTN244)を作成すること、および必要なエッジを追加することを含む(前述したように、一実施形態において、親ノードとして機能するPQPNの各々に、その親ノードの子ノードへの参照を保存することによって、これらのエッジを保存することができるが、代替実施形態は、これらのエッジを別の方法で保存することができる(例えば、1つまたは複数の他のデータ構造を使用してこれらのエッジを保存する))。この有向グラフは、実行後に、潜在的な再利用のために少なくともしばらくの間メモリに保存される。さらに、有向グラフのノードの各々について、キャッシュ234にノードキーおよびノード参照ペアが入力される(ノードキーはノード参照に関連付けられる)。第1の物理クエリプランの実行は、有向グラフのノード(DTTN244)の各々により特定されたクエリプラン演算を実行することを含み、これは、いずれかの子ノードのTTにアクセスすること、クエリプラン演算を実行すること、各ノードの対応するTT(例えば、1つのDTT264)を入力することを含む。有向グラフのルートノードが参照するTT(例えば、1つのDTT264)を使用して、クエリ結果を提供する。
この例を続けると、第2のSQLクエリを受信したことに応答して、第2の物理クエリプランが生成および実行され、第2のSQLクエリを送信したクライアントにクエリ結果が返される。しかしながら、第2の物理クエリプランの生成は、第1の物理クエリプランに既に存在し、かつ同一であるため共有可能な1つまたは複数のノード(および場合により、ノードおよびエッジの1つまたは複数のサブグラフ)を作成する必要がない。第2のクエリプランの生成は、第1の物理クエリプランから同一である1つまたは複数のノード(および場合により、1つまたは複数のサブグラフ)を再利用する(「組み込む」とも称する)。図2を参照すると、クエリプランコネクタ232は、実行後に現在メモリに保存されている物理クエリプラン242に既に存在する1つまたは複数のノードおよび/またはサブグラフ(ならびに、一部の実施形態において、有向グラフ全体)を再利用する/組み込むことにより、必要な第2の物理クエリプランを生成することができるかどうかを判定する。クエリプランコネクタ232が再利用/組込みが可能であると判定した場合には、第2の物理クエリプランの欠けている部分(ノードおよびエッジ、サブグラフなど)のみが物理クエリプラン242に追加され、1つまたは複数のエッジにより、再利用可能であると判定された1つまたは複数のノードおよび/またはサブグラフ(ならびに、一部の実施形態において、有向グラフ全体)に連結される。前述したように、一実施形態において、クエリプランコネクタ232は、第2のSQLクエリの論理クエリプランおよび(第1の物理クエリプランの生成に応答して先に入力された)キャッシュ234のノードキーを使用する。そのような再利用/組込みが実行されると、第1のSQLクエリおよび第2のSQLクエリは、有向グラフの各々がそのエッジのうちの少なくとも1つにより他の有向グラフの少なくとも1つのノードに連結されて、それらの有向グラフが少なくとも1つのノードを共有するようになっている。したがって、クエリプランは、少なくとも1つのノードを共有し、より多く(例えば、2つ以上のノードおよび1つまたは複数のエッジのサブグラフ)を共有することができるという点で連結される(「重複する」とも称する)。一方、クエリプランコネクタ232が再利用/組込みが不可能であると判定した場合には、第2の物理クエリプランの有向グラフのノードおよびエッジが物理クエリプラン242に追加される。
前述したように、物理クエリプランによりノード(中間ノードおよび場合によりルートノードを含む)を共有すること、ならびに物理クエリプランおよびテンポラルテーブル(特に、クエリプラン演算子を実行する有向グラフの各々のノードにより入力されたTT(例えば、DTTN244が参照するDTT264))をメモリに保存することにより、一部の実施形態は、大量のデータを扱うときを含む、略リアルタイムのストリーミングの実行をサポートすることができる。再び、これは、一部には以下の理由による。1)実行後に物理クエリプランをメモリに保存し、これらのクエリプランにノードを共有させ(可能であれば)、したがってそれらの共有されたノードが特定するテンポラルテーブルを共有させ、必要なメモリ、計算リソース、および計算時間を減少させる、2)テンポラルテーブルを使用すること、およびテンポラルテーブルをメモリに保存することにより、ある実施形態は、1つまたは複数のクエリプラン演算子を実装して、「増分実行」(「差分」のみで実行、「増分クエリ処理」および「増分再計算」とも称する)を行い、それらのクエリプラン演算子を表すノードにより特定されたテンポラルテーブルを必要に応じて増分更新する(増分実行により、クエリプラン演算子へのテンポラルテーブル入力の各々の全体におけるクエリプラン演算子の再実行/再計算(本明細書において「完全再実行」と称する)と比較して、必要な計算リソースおよび計算時間が減少する)。したがって、加えてまたはあるいは、一実施形態において、第2のクエリプランの生成および実行は、少なくとも、第1のクエリプランの有向グラフに存在し、かつ第2のクエリプランの有向グラフによって共有された1つのノードにより表されたクエリプラン演算子を増分実行することを含むことができる。
図2のPCCM214、パーサ218、クエリリライタ224、クエリオプティマイザ230、クエリエグゼキュータ240、および非クエリエグゼキュータ228の間の矢印線は、データフローおよび/または接続などの何らかのタイプの結合を表す。例えば、一部の実施形態において、PCCM214は、パーサ218、クエリリライタ224、クエリオプティマイザ230、クエリエグゼキュータ240、および非クエリエグゼキュータ228の各々を、SQLステートメント216の実行を調整するように呼び出し、したがって、矢印線は、例えば、パーサ218がクエリリライタ224を呼び出すのとは対照的に順序を表す。
前述したように、異なる実施形態は、異なる技術を使用して、クエリプランのノードの各々およびTTの各々が実行後にどのくらい長くメモリに保存されるかを判定することができる。一実施形態において、「アクティブ」または「非アクティブ」の特定は、クエリプランの各々について維持され(例えば、特定はクエリプランの各々の有向グラフのルートノードに関連付けることができる)、「アクティブ」クエリプランの一部ではないノード(およびノードが参照するTT)は、メモリへの保存から除去される候補である。特定の例により、Java Development Kit(JDK)は、「弱参照」ジェネリックタイプを提供する。このタイプのインスタンスにより、ベースとなるオブジェクトのメモリを、Java仮想マシンのガベージコレクタにより、デフォルトのJava参照(「強参照」と称する)を使用する場合よりも、積極的に解放することができる。Javaで実装された一実施形態において、キャッシュ234におけるルートノードおよびリーフノードへの参照は強参照タイプであり、キャッシュ234における中間ノードへの参照は弱参照タイプであり、キャッシュ234において所与のルートノードが解放されると、Java仮想マシンのガベージコレクタは、そのルートノードから延びる有向グラフにより消費されたメモリを解放することができる。したがって、キャッシュ234におけるルートノードへの強参照は、それらのルートノードから始まるクエリプランが「アクティブ」であり、そのようなルートノードが解放されると、そのルートノードで始まるクエリプランが「非アクティブ」に切り替わることを示す。
実施例
図3Aは、一実施形態による、時間T=0における「CUSTOMERS」と名付けた例示的なテンポラルテーブルを示す図である。図3Bは、一実施形態による、時間T=0における「ORDERS」と名付けた例示的なテンポラルテーブルを示す図である。図3A、図3Bのテンポラルテーブルは、各フィールドが、対応するデータレコードが有効な最も早い時間に対応するvalid_from列(valid_fromタイムスタンプと称することもできる)と、各フィールドが、データレコードが有効な(かつ時間が未知の場合に無限大(INF)に設定される)最も遅い時間に対応するvalid_to列(valid_toタイムスタンプと称することもできる)とを含む。前述したように、本明細書において、前記論理ビューに関して、かつ(当技術分野で時々使用されるように)valid_to列およびvalid_from列という用語を使用して実施形態について説明するが、代替実施形態は、テンポラルテーブルを異なって実装してもよい(例えば、テンポラルテーブルのコンテンツを異なる方法で保存する(例えば、行指向構成を使用して、列指向構成を使用して、1つまたは複数のテンポラルテーブルの行指向構成および列指向構成の両方を使用して、1つまたは複数のテンポラルテーブルの行指向構成および1つまたは複数の他のテンポラルテーブルの列指向構成を使用してなどにより、コンテンツを保存することができる)、データレコードのタイムスタンプ情報を別の方法で(例えば、より多いまたは少ないフィールドを使用して)保存する、異なる用語によりタイムスタンプ情報を参照するなど)。
図3Aでは、他の列は、「CustomerID」、「Name」、および「PostalCode」と名付けられている。図3Bでは、他の列は、「OrderID」「CustomerID」「Price」、および「Quantity」と名付けられている。「CustomerID」が両方のテンポラルテーブルに見られるため、当技術分野で公知のように、CustomerIDは2つのテンポラルテーブルを関連付けるキーとして働くことができる。時間T=0において、各テンポラルテーブルのコンテンツは2つのデータレコードを含む。
図3Cは、一実施形態による例示的なSQLクエリを示す。詳細には、例示的なSQLクエリ310は、「select*from CUSTOMERS, ORDERS where ORDERS.CustomerID=CUSTOMERS.CustomerID and CUSTOMERS.PostalCode=10001 and ORDERS.Quantity>4」である。
図4は、一実施形態による、例示的なSQLクエリ310の異なる部分と、例示的なテキスト表現440を介した例示的な論理クエリプラン464との関係を示す図である。図4は、例示的なSQLクエリ310を以下の通り別々の要素として示す。「select」402、「*」404、「from」406、「CUSTOMERS」408、「ORDERS」410、「where」412、「ORDERS.CustomerID」414、「=」416、「CUSTOMERS.CustomerID」418、「and」420、「CUSTOMERS.PostalCode」422、「=」424、「10001」426、「and」428、「ORDERS.Quantity」430、「>」432、および「4」434。
前述したように、一部の実施形態は論理クエリプランを生成する。一実施形態において、SQLクエリ(例えば、例示的なSQLクエリ310)の論理クエリプラン(例えば、例示的な論理クエリプラン464)は、当技術分野で公知のように、ノード(本明細書において「論理クエリプランノード」(LQPN)と称する)およびそれらのノードを連結するエッジからなる有向グラフである。有向グラフは、ルート論理クエリプランノード(例えば、ルートLQPN470A)から始まり、0以上の中間LQPN(例えば、中間LQPN470B〜470D)を含み、1つまたは複数のリーフLQPN(例えば、リーフLQPN470E〜470F)で終わる。
例示的なテキスト表現440(人間が読める形式の例示的なクエリプランを形成するために文字列として書き出された例示的なSQLクエリプラン310のノードである)は、説明のためのものであり、ある実施形態によっては生成する必要がない。さらに、代替実施形態は、例示的なSQLクエリ310について、例示的なテキスト表現440により表されたものとは異なるクエリプランを生成することができる。
例示的なテキスト表現440は、複数のタイプの「クエリプラン演算子」(例えば、PROJECT、SELECT、JOIN、およびTABLE)ならびにそれらの「パラメータ」を含む。各LQPN470A〜470Fの「クエリプラン演算子タイプ」(または「演算子タイプ」)は、LQPNが特定可能な複数のタイプのクエリプラン演算子のうちの特定の1つを特定する。一部の実施形態は、1つまたは複数のクエリプラン演算子について複数の異なる実装を有し、一部のそのような実施形態は、「演算子タイプ」が特定の1つのクエリプラン演算子およびそのクエリプラン演算子の特定の1つの実装を特定するように構成することができ、他のそのような実施形態は、「演算子タイプ」が特定の実装を参照することなく特定の1つのクエリプラン演算子を特定するように構成することができる。PROJECTおよびTABLEの両方のクエリプラン演算子は、それらが作用するテンポラルテーブル(入力テンポラルテーブル)のデータレコードを効果的に返す。
例示的なSQLクエリ310の「from」406句のテンポラルテーブル「CUSTOMERS」408および「ORDERS」410は、例示的なテキスト表現440の「TABLE(CUSTOMERS)」456および「TABLE(ORDERS)」448をそれぞれ表すLQPN470FおよびLQPN470Eにそれぞれマッピングされる。
比較述語は、テンポラルテーブル(例えば、「ORDERS.Quantity」430)の列への参照、比較演算子(例えば、=、>、<)、およびテーブルの列への別の参照、直定数(例えば、「4」434)、または式(例えば、「10001+1」)の組合せである。一実施形態において、比較述語が「<列参照><比較演算><直定数>」の形式である場合には、比較述語はSELECTにマッピングされる。これは、LQPN470CおよびLQPN470Dにそれぞれマッピングされている比較述語「ORDERS.Quantity>4」480および比較述語「CUSTOMERS.PostalCode=10001」482を含み、LQPN470Cは、その子LQPN470E(「TABLE(ORDERS)」448を実行する)の結果の「SELECT(」446および比較述語「,ORDERS.Quantity>4)」450(演算490)を表し、LQPN470Dは、その子LQPN470F(「TABLE(CUSTOMER)」456を実行する)の結果の「SELECT(」454および比較述語「,CUSTOMERS.PostalCode=10001」458(演算492)を表す。
一実施形態において、比較述語が「<列参照>=<列参照>」の形式である場合には、比較述語はJOINにマッピングされる。これは、LQPN470Bにマッピングされている比較述語「ORDERS.CustomerID=CUSTOMERS.CustomerID」484を含み、LQPN470Bは、その子LQPN470C、470D(それぞれ「SELECT(TABLE(ORDERS),ORDERS.Quantity>4)およびSELECT(TABLE(CUSTOMERS),CUSTOMERS.PostalCode=10001)」を実行する)の結果の「JOIN(」444および比較述語460(486を付した「where」412句を完成させる演算496)を表す。図示した例は、JOINが比較述語「ORDERS.CustomerID=CUSTOMERS.CustomerID」460および2つのSELECT演算(490、492)の結果に作用するように最適化されているが、代替実施形態は、異なって最適化されていても、まったく最適化されていなくてもよい。
SELECTステートメント(「select」402および「*」404を含む)がLQPN470Aにマッピングされ、LQPN470Aは、その子LQPNB(「JOIN(SELECT(TABLE(ORDERS),ORDERS.Quantity>4),SELECT(TABLE(CUSTOMERS),CUSTOMERS.PostalCode=10001),ORDERS.CustomerID=CUSTOMERS.CustomerID」を実行する)、および列の一覧「CUSTOMERS.CustomerID,CUSTOMERS.Name,CUSTOMERS.PostalCode,ORDERS.OrderID,ORDERS.CustomerID,ORDERS.Price,ORDERS.Quantity)」462(演算498)の結果において、「PROJECT)」442を表す。
本明細書において、「パラメータ」という用語は、「演算子タイプ」(例えば、「ORDERS」または「CUSTOMERS」のようなテーブル参照、「ORDERS.Quantity>4」、「CUSTOMERS.PostalCode=10001」、または「ORDERS.CustomerID=CUSTOMERS.CustomerID」のような比較述語、「CUSTOMERS.CustomerID,CUSTOMERS.Name,CUSTOMERS.PostalCode、ORDERS.OrderID,ORDERS.CustomerID,ORDERS.Price,ORDERS.Quantity」のような列の一覧など)に対応する演算を実行するのに必要な追加の情報を指すために使用される。
一実施形態において、LQPN470A〜470Fの各々にデータ構造が実装され、このデータ構造は、1)いずれかの子ノード(例えば、LQPN470Bの子ノードはLQPN470CおよびLQPN470Dである)への参照を保存する「子参照フィールド」、ならびに2)演算の演算子タイプおよびその1つまたは複数のパラメータを保存する1つまたは複数の「記述子フィールド」のセットを含む。一実施形態において、1)演算子タイプの表示を保存する「演算子タイプフィールド」、および2)パラメータを保存する「他のパラメータフィールド」の2つの記述子フィールドがある。別の実施形態において、LQPN470A〜470Fの各々は、演算子タイプおよびその1つまたは複数のパラメータを含むノードキー全体を保存する記述子フィールドを実装する。一部の実施形態は、論理クエリプランを「軽量グラフ」(すなわち、クエリプランを表すための最小の情報を含むグラフ)として実装する。軽量グラフは、物理クエリプランの生成を容易にするために生成される。代替実施形態は、論理クエリプランのより多い、少ない、および/または異なる情報を含んでもよく、かつ/または論理クエリプランを生成しなくてもよい。
図5Aは、一実施形態による、例示的なテキスト表現440の異なる部分と例示的な物理クエリプランとの関係を示す図である。図5Aは、図2の物理クエリプラン242およびベーステンポラルテーブル260、ならびに例示的なテキスト表現440および図4の演算490、492、496、498を特定するラベルを再現する。図4に関し、例示的なテキスト表現440(人間が読める形式の例示的なクエリプランを形成するために文字列として書き出された例示的なクエリプランのノードである)は、説明のためのものであり、ある実施形態によっては生成する必要がない。さらに、代替実施形態は、例示的なSQLクエリ310について、例示的なテキスト表現440により表されたものとは異なるクエリプランを生成することができる。例示的なテキスト表現440および異なる演算490、492、498は、実行時にPQPN570A〜570Fの各々が実行するクエリプラン演算(演算子タイプおよびパラメータを含む)を特定するように示される。各PQPN570A〜570Fの「演算子タイプ」は、そのPQPNが実行する複数のタイプのクエリプラン演算子のうちの特定の1つを特定する。再び、一部の実施形態は、1つまたは複数のクエリプラン演算子について異なる実装を有し、一部のそのような実施形態は、「演算子タイプ」が特定の1つのクエリプラン演算子およびそのクエリプラン演算子の特定の1つの実装を特定するように構成することができ、他のそのような実施形態は、「演算子タイプ」が特定の実装を参照することなく特定の1つのクエリプラン演算子を特定するように構成することができる。
前述したように、一実施形態において、演算は、クエリプラン(論理もしくは物理)またはTTがメモリに保存されていない(物理クエリプラン242、BTT260、およびDTT264が空である)状態、およびキャッシュ234が空である状態で始まる。例として、SQLステートメント(2つのCREATE TABLE SQLステートメントおよび2つのINSERT SQLステートメントを含む)に応答して、BTT作成および入力502が行われることにより、1)リーフPQPN570Eおよび対応するBTT554Aが作成され、2)リーフPQPN570Fおよび対応するBTT554Bが作成される。図2の実施形態において、キャッシュ234のPQPN570EおよびPQPN570Fの各々についてエントリが作成される。
例示的なSQLクエリ310を受信したことに応答して、504で例示的な物理クエリプラン564が生成される。例示的な物理クエリプラン564を生成することは、1つまたは複数の必要な中間ノードおよびルートノード(PQPN570A〜570D)を作成すること、ならびに必要なエッジを追加してそれらのノードを適切に連結し、有向グラフを形成すること(エッジをリーフPQPN570E〜570Fに追加することを含む)を含む。この例では、PQPN570EおよびPQPN570Fが既に物理クエリプラン242に存在し、これらを物理クエリプラン564に組み込むことができると判定され、また、PQPN570A〜570Dを物理クエリプラン242に追加し、1つまたは複数のエッジによりPQPN570EおよびPQPN570Fに連結して、有向グラフを形成しなければならないと判定される。図2の実施形態において、これらの判定は、キャッシュ234にキャッシュヒットがあるかどうかを判定することにより行われる。
論理クエリプラン(例えば、例示的な論理クエリプラン464)を最初に実装する実施形態において、論理クエリプランは有向グラフを表すことができ、この有向グラフは、物理クエリプラン(例えば、物理クエリプラン564は、同一の演算(演算子タイプおよびパラメータ)を担い、かつ同一数のエッジにより連結される同一数のノードを有して、例示的な論理クエリプラン464と同一の形状を形成し、したがって、PQPN570A〜570Fの同一文字のノードはLQPN470A〜470Fの同一文字のノードに対応する)として生成され、実行後に現在メモリに保存されている物理クエリプラン242に既に存在する1つまたは複数のノードおよび/またはサブグラフ(ならびに、一部の実施形態において、有向グラフ全体)を再利用するまたは組み込むことにより、必要な物理クエリプランを生成することができるかどうかを判定するために使用される。例において、LQPN470EおよびLQPN470Fを、物理クエリプラン242に既に存在するPQPN570EおよびPQPN570Fによりそれぞれ実行することができ、したがって物理クエリプラン564に組み込むことができると判定され、また、PQPN570A〜570Dを物理クエリプラン242に追加し、再利用可能であると判定されたPQPN570EおよびPQPN570Fにエッジにより連結しなければならないと判定される。論理クエリプランを最初に生成しキャッシュ234を使用する実施形態において、これらの判定は、論理クエリプランの有向グラフをベースにして、ノードキーが、1つまたは複数のノードおよび/またはサブグラフ(ならびに、一部の実施形態において、有向グラフ全体)についてキャッシュ234に既に存在するかどうかを判定することにより行われ、物理クエリプラン242にまだ存在しないPQPNおよびエッジのみが作成される。
本明細書で使用されるとき、「クエリプラン」という用語は、「論理クエリプラン」または「物理クエリプラン」を指すことができ、「ノード」または「クエリプランノード」(QPN)という用語は、「LQPN」または「PQPN」を指すことができる。
図5Bは、一実施形態による例示的な物理クエリプラン564の実行を示す図である。図5Bは、図2の物理クエリプラン242、ベーステンポラルテーブル260、および派生テンポラルテーブル264、ならびに図5Aの例示的な物理クエリプラン564(PQPN570A〜570Fからなる有向グラフを含む)およびBTT554A、554Bを再現する。前述したように、各固有のクエリのクエリプランは、ルートノード(例えば、PQPN570A)で始まり、0以上のレベルの中間ノード(例えば、PQPN570B〜570D)を含み、1つまたは複数のリーフノード(例えば、PQPN570E、570F)で終わる有向グラフからなる。実行中、ルートノードからリーフノードへ再帰呼出しが行われ、この実行の結果として生成されたデータがリーフノードから中間ノードを通ってルートノードへ流れ(曲線矢印により示す)、したがって、実行により、データがリーフからルートへ流れる。一実施形態において、ルートノード(PQPN570A)に対して呼出しを行ってそのクエリプラン演算を実行することにより、ルートノードの子ノード(例えば、PQPN570B)を呼び出すなど、リーフノードまで再帰的に呼び出す(例えば、PQPN570BはPQPN570C、570Dを呼び出し、PQPN570CはPQPN570Eを呼び出し、PQPN570DはPQPN570Fを呼び出す)。所与のノードの実行が完了すると、結果がその親ノード(あれば)に提供される。所与の親ノードのすべての子ノードが実行を完了し、その結果をその所与の親ノードに提供したときには、その親ノードが実行してその結果をその親ノード(あれば)に提供する。
ルートおよび中間PQPN570A〜570Dの各々は、潜在的な再利用のために保存された派生テンポラルテーブル264においてDTT558A〜558Dを特定する。ルートおよび中間PQPN570A〜570Dの各々が実行されると、PQPNが特定するDTT558A〜558Dの対応する1つを更新する。クエリ結果は、ルートPQPN570Aにより特定されたDTT588Aから生成される。
一実施形態において、BTT260およびDTT264はTTクラスのオブジェクトであり、TTクラスのオブジェクトは、1)テンポラルテーブルのデータレコードのデータ、および2)そのTTからデータレコードにアクセスする1つまたは複数のメソッドを含む。一実施形態において、各PQPNは、1)テンポラルテーブル(例えば、BTTまたはDTTを特定する参照を有する)を特定する、2)クエリプラン演算子およびその1つまたは複数のパラメータ(例えば、TABLE(ORDERS)、TABLEはクエリプラン演算子であり、ORDERSはそのパラメータである)により特定されたクエリプラン演算を実行し、特定されたテンポラルテーブルのデータレコードを返す(例えば、特定されたテンポラルテーブルのデータレコードにアクセスするために親ノードが使用することのできる、特定されたBTTまたはDTTに参照を返す)Evaluateメソッドを含む。コピーの作成には費用がかかる(特に大きいテーブルの場合)ことがあるため、PQPNにより特定されたDTT/BTTの読取専用ビューまたは読取専用コピーへの参照を、そのPQPNのEvaluateメソッドにより返して、そのメソッドを呼び出した呼出し元(例えば、親ノード)が、その後、返されたTTから必要なレコードにアクセスできるようにする(場合により増分のみ、他の場合にはテーブル全体)。
物理クエリプラン242のノードが「テンポラルテーブルノード」(TTN)として実装され、図2を参照して説明した派生テンポラルテーブルノード(DTTN)244およびベーステンポラルテーブルノード(BTTN)246として分類可能な実施形態において、PQPN570A〜570DはDTTN244として実装され、PQPN570E、570FはBTTN246として実装される。言い換えると、DTTN244は、物理クエリプラン242の有向グラフのルートノードおよび中間ノードを含み、BTTN246は物理クエリプラン242の有向グラフのリーフノードを含む。一実施形態において、DTTN244およびBTTN246は、それぞれDTTNクラスおよびBTTNクラスのオブジェクトであり、両クラスは、1)TT参照フィールド、および2)Evaluateメソッド(それぞれDTTN.EvaluateおよびBTTN.Evaluateと称する)を含む。親ノードは、子ノードのEvaluateメソッドを呼び出し、子ノードのEvaluateメソッドは、その子ノードにより特定されたDTT264またはBTT260の一方の読取専用ビューまたは読取専用コピーへの参照を返し、その後、親ノードはそのDTTまたはBTTのメソッドを呼び出して、DTTまたはBTTによりカプセル化されたテンポラルテーブルのデータレコード(一部のクエリプラン演算についてはすべてのデータレコード、その他については最新の更新以後の差分であってよい)にアクセスすることができる。DTTNクラスのインスタンスのDTTN.Evaluateメソッドの実行は、そのノードのクエリプラン演算を実行し、そのDTTNのTT参照フィールドにより特定されたDTTのうちの1つに結果を保存し、そのDTTの読取専用ビューまたは読取専用コピーへの参照を返す。BTTNクラスのインスタンスのBTTN.Evaluateメソッドの実行は、そのBTTNが参照したBTT260のうちの1つの読取専用ビューまたは読取専用コピーへの参照を返す。したがって、PQPN570Aを実装するDTTNのDTTN.Evaluateメソッドの実行は、1)DTT558Bの読取専用ビューまたは読取専用コピーを返す子DTTN(PQPN570B)のDTTN.Evaluateメソッドへの呼出し、およびその後の、演算への入力としてのDTT558Bのデータレコードにアクセスするメソッドへの呼出し、2)適切なクエリプラン演算の実行、3)TT参照フィールドにより特定されたDTT558Aへの、そのクエリプラン演算の結果の保存、ならびに4)DTT558Aの読取専用ビューまたは読取専用コピーへの参照の返しを含む。PQPN570Bを実装するDTTNのDTTN.Evaluateメソッドの実行は、1)DTT558C〜558Dの読取専用ビューまたは読取専用コピーを返す子DTTN(PQPN570C〜570D)のDTTN.Evaluateメソッドへの呼出し、およびその後の、演算への入力としてのDTT558C〜558Dのデータレコードにアクセスするメソッドへの呼出し、2)適切なクエリプラン演算の実行、3)TT参照フィールドにより特定されたDTT558Bへの、そのクエリプラン演算の結果の保存、ならびに4)DTT558Bの読取専用ビューまたは読取専用コピーへの参照の返しを含む。最低レベルのDTTN(例えば、PQPN570C、570D)の各々のDTTN.Evaluateメソッドの実行は、1)BTTN(例えば、BTT554A)が参照したBTTの読取専用ビューまたは読取専用コピーを返すDTTN(例えば、PQPN570E)が参照したBTTNのBTTN.Evaluateメソッドへの呼出し、およびその後の、そのBTT(例えば、BTT554A)のデータレコードにアクセスするメソッドへの呼出し、2)適切なクエリプラン演算の実行、3)TT参照フィールド(例えば、DTT558C)により特定されたDTT264のうちの1つへの、そのクエリプラン演算の結果の保存、4)そのDTT(例えば、DTT558C)の読取専用ビューまたは読取専用コピーへの参照の返しを含む。有向グラフの構造がどのノードを並行して実行することができるか(例えば、親ノードの子ノード)を示していることが、当業者に明らかであろう。例示の目的で、物理クエリプラン242のノードをTTN(より詳細には、DTTN244およびBTTN246)として実装する一実施形態について説明したが、代替実施形態は、物理クエリプラン242のノードを異なって実装してもよい。
図6は、一実施形態による例示的な重複物理クエリプランを示す。図6は、例示的なSQLクエリ310、例示的なテキスト表現440、物理クエリプラン242における物理クエリプラン564(PQPN570A〜570Fを含む)、およびベーステンポラルテーブル260におけるBTT554A〜554Bを示す。図6はまた、一実施形態による、追加の例示的なSQLクエリ、それらのSQLクエリのクエリプランの例示的なテキスト表現、およびそれらのSQLクエリの例示的な物理クエリプランを示す。追加の例示的なSQLクエリ602、604、606、608の各々について、図6は、例示的なSQLクエリ310と同一のSQLクエリの部分、および異なる部分の省略記号を示す(例えば、追加の例示的なSQLクエリ602は、「select*from…,ORDERS,…where…」として示される)。加えて、図6は、追加の例示的なSQLクエリ602、604、606、608のそれぞれの例示的なテキスト表現612、614、616、618を示す。例示的なテキスト表現612、614、616、618の各々について、図6は、例示的なテキスト表現440と同一のテキスト表現の部分、および異なる部分の省略記号を示す(例えば、例示的なテキスト表現612は、「PROJECT(…TABLE(ORDERS)…)」として示される)。
加えて、図6は、例示的なテキスト表現612、614、616、618の各々について、それぞれの物理クエリプラン622、624、626、628の各々の一部を示す。図示したそれぞれの物理クエリプラン622、624、626、628の各々の一部は、1)物理クエリプラン564と共有される第1のサブパート(ノードまたはサブグラフ)、および2)共有されないが、1つのエッジにより第1のサブパートに連結された少なくとも1つのノードを含む第2のサブパートを含む。したがって、図6は、物理クエリプラン564、622、624、626、628の有向グラフが、少なくとも1つのノード、ならびに場合により、2つ以上のノードおよび1つまたは複数のエッジのサブグラフを共有するという点で連結される(「重複する」とも称する)ことを示す。例えば、物理クエリプラン622は、PQPN570Eを子ノードとして有する(PQPN670AをPQPN570Eに連結するするエッジが存在する)PQPN670A(共有されない)を含み、したがって、PQPN570Eは、物理クエリプラン622と物理クエリプラン564との間で共有されるノード(リーフノード)である。物理クエリプラン628は、PQPN570B(中間ノード)を子ノードとして有するPQPN670F(共有されないルートノード)を含み、したがって、PQPN570B〜570Fのサブグラフ(すなわち、PQPN570Bおよびその子孫ノード、すなわちPQPN570B、PQPN570C、570D、およびPQPN570E、570Fのサブグラフ)は、物理クエリプラン628と物理クエリプラン564との間で共有されるサブグラフである。物理クエリプラン624は、PQPN670C(共有されない)およびPQPN570C(中間ノード)を子ノードとして有するPQPN670B(共有されない)を含み、したがって、PQPN570C〜570Eのサブグラフは、物理クエリプラン624と物理クエリプラン564との間で共有されるサブグラフである。物理クエリプラン626は、PQPN670E(共有されない)およびPQPN570B(中間ノード)を子ノードとして有するPQPN670D(共有されない)を含み、したがって、PQPN570B〜570Fのサブグラフは、物理クエリプラン626と物理クエリプラン564との間で共有されるサブグラフである。
図示した例において、クエリプラン演算が2つ以上のクエリプランで同一であるときにノードが共有される。言い換えると、クエリプラン演算が2つ(以上)のクエリプランで同一である場合には、そのクエリプラン演算を表すノード(およびいずれかの子孫ノード、すなわち、親から子へ繰り返し進むことにより到達可能ないずれかのノード)を共有することができる。
前述したように、第1のクエリプランが既に生成され、実行後にメモリに保存されている場合(例えば、物理クエリプラン564)には、第2のクエリプラン(例えば、物理クエリプラン622、624、626、628のいずれか)の生成は、第1のクエリプラン(例えば、物理クエリプラン564)に既に存在し、かつそれらの必要なノードと同一であるため共有可能な、第2のクエリプランに必要な1つまたは複数のノード(および場合により、ノードおよびエッジの1つまたは複数サブグラフ)の生成を必要とせず、第2のクエリプラン(例えば、物理クエリプラン622、624、626、628のいずれか)の生成は、第2のクエリプランに必要なものと同一の1つまたは複数のノード(および場合により、1つまたは複数のサブグラフ)を第1のクエリプラン(例えば、物理クエリプラン564)から再利用する(「組み込む」とも称する)。さらに、第1のクエリプランが既に生成され、実行後にメモリに保存されている場合(例えば、物理クエリプラン564)には、第1の物理クエリプランに対応する第2の論理クエリプランの生成は、第1の物理クエリプラン(ノードおよびエッジを含む有向グラフ全体)を再利用できるため、いずれのノードの作成も必要としない。
したがって、図示した例において、共有されたノードは、SQLクエリの句または句の一部が同一である例示的なSQLクエリの一部を実装し、したがって、SQLクエリは一部を共有して(「重複する」とも称する)、それらのSQLクエリを実装するように生成されたクエリプランがノードを共有する(「重複する」とも称する)ことができるようにする。図6は重複する例示的なSQLクエリを示すが、一部の実施形態において、2つのSQLクエリの物理クエリプランは、それらのSQLクエリが重複することなく重複してもよいことを理解すべきである。加えて、クエリプランを生成する際に適用されるクエリプラン最適化により、2つ以上のSQLクエリの物理クエリプランに、より多いまたは少ない重複が生じることがあり、または重複がないことがある。
増分更新および増分実行
図7Aは、一実施形態による、テンポラル−リレーショナルデータベースのテンポラルテーブルのうちの少なくとも1つを修正したことに応答してテンポラルテーブルを増分更新することを示すフロー図である。前述したように、テンポラルテーブルに作用する一般的なリレーショナルデータベースの演算子(例えば、PROJECT、JOIN、SELECT、TABLE)の実装が、当技術分野で公知である(例えば、D. PfoserおよびC.S. Jensen、「Incremental Join of Time−Oriented Data」、In Proc. 11th Intl. Conf. Scientific and Statistical Database Management、232〜243ページ、1999、Jun YangおよびJennifer Widom、「Maintaining Temporal Views Over Non−Temporal Information Sources For Data Warehousing」、In EDBT ’98 Proc. 6th Intl. Conf. on Extending Database Technology:Advances in Database Technology、389〜403ページ、1998)。一実施形態において、クエリプラン演算子のうちの1つ、いくつか、ほとんど、またはすべてが実装されて、完全再実行/再計算ではなく、増分実行をサポートしてテンポラルテーブルを増分更新する。図7Aのフロー図は、図1のフロー図の後に行うことができる。
図7Aのブロック702で、テンポラル−リレーショナルデータベースの一部であり、かつSQLクエリのうちの少なくとも1つがデータへのアクセスを必要とするテンポラルテーブルの少なくとも所与の1つのコンテンツが修正される。例えば、これは、RDBMSがINSERT、UPDATE、もしくはDELETE SQLステートメント、またはデータレコードの追加、データレコードの削除、および/または既存のデータレコードのコンテンツの変更によりテンポラルテーブルのコンテンツを修正する他の同様のSQLステートメントを受信したことに応答して行うことができる。前述したように、そのような演算は、SQLステートメント216に含まれ、非クエリエグゼキュータ228によりBTT254のうちの1つを修正するように実行することができる。ブロック702から、制御はブロック704へ進む。
ブロック704で、修正されたテンポラル−リレーショナルデータベーステーブル(SQLクエリのうちの少なくとも1つのクエリプランの有向グラフのノードであり、かつテンポラルテーブルのうちの所与の1つを特定するノードに直接的または間接的に依存するノードにより特定されたテンポラルテーブル)を特定するノードの先祖によって特定されたテンポラルテーブルが、更新される。このような更新は、可能であれば(例えば、実施形態が、クエリプラン演算を増分実行可能なEvaluateメソッドを実装する場合)、増分実行により行われる。ブロック702に対してブロック704を実行するタイミングは、異なる実施形態において異なって判定することができる(例えば、前述したように、直ちに、レイジー更新をサポートする実施形態においては、1つまたは複数の事象が発生する(例えば、クエリ結果をクライアントに送る必要がある、一定時間が経過する、プログラム可能な時間が経過する、ノードおよびエッジをベースとして(例えば、ノードと他のノードとの連結、ノードのタイプ、過去のノードの使用などをベースとして)計算された時間が経過する、他のSQLクエリの到着率が閾値を超える、および/または使用可能な計算リソースが閾値を下回る)まで遅延される)。ブロック704から、制御はブロック706へ進む。
スキップ更新をサポートする一部の実施形態において、ブロック702で修正されたテンポラルテーブルを特定するノードに直接的または間接的に依存するノードにより実行されるクエリプラン演算のみが実行される(他のノードはスキップされ(例えば、一実施形態において、他のノードはEvaluateメソッドを呼び出すが、クエリプラン演算を実行せず、その子ノード(あれば)のEvaluateを呼び出さない)、したがって、修正により影響されなかったテンポラルテーブルの更新を実行しないというさらなるパフォーマンスの利点が得られる)。代替実施形態において、複数のSQLクエリのうちの少なくとも1つのクエリプランの有向グラフのノードのすべてにより実行されたクエリプラン演算が、(可能であれば増分実行により)実行される(かつ実装される)。
ブロック706に示すように、複数のSQLクエリのうちの少なくとも1つについてのクエリ結果に対する増分更新が、複数のSQLクエリのうちの少なくとも1つを送信したクライアントに送信される。したがって、一実施形態は、クエリ結果に対する増分更新を送信する(すなわち、「差分」のみを送信することにより、クエリ結果全体の送信を避ける)。
例えば、クライアントがSQLクエリを送信したことに応答して、RDBMSが物理クエリプランを生成し、クエリ結果をクライアントに送信したと仮定すると、有向グラフのリーフノードにより特定されたベーステンポラルテーブルのコンテンツが修正される(ブロック702)。クエリプランおよびテンポラルテーブルが、潜在的な再利用のために、依然として実行後にメモリに保存されている場合、RDBMSは増分更新し(ブロック704)、先に送信したクエリ結果に対する増分更新をクライアントに送信することができる(すなわち、クライアントに既に送信されたクエリ結果の一部を送信するのではなく、クライアントに最後にクエリ結果が送信された以後の、SQLクエリを満たすクエリ結果に対する変更を特定するデータをクライアントに送信する)(ブロック706)。当然、クエリプランおよびテンポラルテーブルが、潜在的な再利用のために依然として実行後にメモリに保存されている間に第2のクライアントが同一のSQLクエリを送信した場合、RDBMSは増分更新し(ブロック704)、完全クエリ結果を第2のクライアントに送信することができる。
図7Bは、一実施形態による、例示的な物理クエリプラン564および例示的な物理クエリプラン628に対する増分実行および増分更新を示す図である。図7Bは、1)図2の物理クエリプラン242、ベーステンポラルテーブル260、および派生テンポラルテーブル264、2)例示的な物理クエリプラン564(PQPN570A〜570Fからなる有向グラフを含む)、および図5A、図5B、図6のBTT554A、554B、3)図5BのようにそれぞれのPQPN570A〜570Dにより特定されたDTT558A〜558D、ならびに4)物理クエリプラン628(PQPN670FおよびPQPN570B〜570Fからなる有向グラフを含む)を再現する。図7Bはまた、PQPN670Fにより特定されたDTT758Aを示す。物理クエリプラン564、628が先に実行され、クエリ結果が第1のクライアントおよび第2のクライアントにそれぞれ提供されたと仮定する。710で、BTT554Aのコンテンツが修正される(例えば、ブロック702)。720で、ブロック710に応答してクエリプランのノードが増分実行される(例えば、可能なタイミングについてのブロック704の説明を参照)。物理クエリプラン564のみを更新する予定であると仮定すると、第1の実施形態は、曲線矢印722、724、728により示すように、PQPN570E、570C、570B、570Aのみを増分実行する(かつDTT558A〜558Cのみが更新され、増分更新740により反映されるように単に増分更新される)。第2の実施形態は、第1の実施形態と同一に行うが、PQPN670Fも増分実行する。これは、破線の曲線矢印730により示すように、PQPN670FがBTT554Aに間接的に依存するからである(DTT758Aも更新され、増分更新744より反映されるように単に増分更新される)。第3の実施形態は、第1の実施形態と同一に行うが、破線の曲線矢印736、732により示すように、PQPN570D、570Fも増分実行する。これは、PQPN570D、570Fが例示的な物理クエリプラン564の一部であるからである(しかしながら、DTT558Dは、直接的または間接的に影響する変更がなかったため更新されない)。第4の実施形態は、第1の演算、第2の演算、および第3の演算を行う。これらの実施形態のすべてにおいて、DTTは単に増分更新され、したがって、テンポラルテーブルを増分更新することに関して前述した利点を有する。
上記の段落において、第1の実施形態および第2の実施形態は、PQPN570D、570Fにより実行されるクエリプラン演算の実行(増分実行であっても完全再実行であっても)を避ける(本明細書において、スキップ更新と称する)。これは、異なる実施形態において異なって実現することができる。スキップ更新をサポートする一実施形態において、各クエリプランは双方向グラフとして生成され、これは各親ノードがその子ノード(あれば)を特定し、そのような各子ノードがその親ノードを特定することを意味する。双方向グラフおよびクエリプランの重複/連結(ノード共有)を使用することにより、別の観点では、その各リーフノード(例えば、PQPN570E、570F)も、「ダーティ通知有向グラフ」、「ベーステーブル有向グラフ」、または「BTTN有向グラフ」と称する別の有向グラフのルートノードとなる。各「ダーティ通知有向グラフ」はそのルートノード(例えば、PQPN570E)で始まり、1つまたは複数のレベルの中間ノード(例えば、PQPN570C、570B)を含み、その「ダーティ通知有向グラフ」の1つまたは複数のリーフノード(例えば、PQPN570AおよびPQPN670F)(これらは、クエリプラン、例えば、物理クエリプラン564、628の各ルートノードである)で終わる。「ダーティ通知有向グラフ」を使用して、ダーティ通知有向グラフのルートノード(例えば、PQPN570E)からそのダーティ通知有向グラフのリーフノード(例えば、物理クエリプラン564、628のルートノードであるPQPN570A、PQPN670F)まで再帰呼出しを行うことにより、BTTの変更によって影響された各ノードを追跡することができ、これにより、そのダーティ通知有向グラフのルートノード(例えば、PQPN570E)から、中間ノード(例えば、PQPN570C、570B)を通って、BTTを消費するクエリプランのルートノード(例えば、物理クエリプラン564、628のルートノードであるPQPN570A、PQPN670F)まで、ダーティ表示が流れることができる。遅延した更新を追跡する機構を提供するという点で、これらのダーティ表示をレイジー更新と共に使用することができ、どのノードについてクエリプラン演算を実行すべきか(増分実行であっても完全再実行であっても)を追跡する機構を提供するという点で、これらのダーティ表示をスキップ更新に使用することができる。言い換えると、ダーティであると示されているそれらのノードすべてが、BTTの修正により(直接的または間接的に)影響されたDTTの次の更新で実行されるバッチに含まれることになっており、ダーティであると示されているそれらのノードのみについてのクエリプラン演算が、BTTの修正により(直接的または間接的に)影響されたDTTの次の更新で実行されることになっている(増分実行であっても完全再実行であっても)(ダーティであると示されていないノードの実行はスキップされる)。
重複クエリプランおよび増分実行
図8は、一実施形態による、重複クエリプランと増分実行との組合せを示すフロー図である。ブロック802は、リレーショナルデータベース管理システムにおいて、新たに送信された構造化クエリ言語(SQL)クエリを受信することを示し、制御はブロック804へ進む。
ブロック804は、実行後にメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に保存されている既存のクエリプランの少なくとも一部を再利用することにより、新たに送信されたSQLクエリのクエリプランを生成することを示す。前述したように、リレーショナルデータベース管理システムは、テンポラルテーブルを含むテンポラル−リレーショナルデータベースを管理する。既存のクエリプランは、エッジにより連結されたノードの有向グラフを含み、この有向グラフは、テンポラル−リレーショナルデータベースのデータへのアクセスを必要とした先に送信されたSQLクエリについてのクエリ結果を実行時に生成するクエリプラン演算子の順序セットを表す。新たに送信されたSQLクエリのクエリプランは、エッジにより連結されたノードの有向グラフを含み、この有向グラフは、新たに送信されたSQLクエリについてのクエリ結果を実行時に生成するクエリプラン演算子の順序セットを表す。新たに送信されたSQLクエリの有向グラフは、そのエッジの少なくとも1つにより、先に送信されたSQLクエリの有向グラフの少なくとも1つのノードに連結されて、有向グラフが少なくとも1つのノードを共有するようになっており、有向グラフのノードの各々はクエリプラン演算子のうちの1つを表す。さらに、有向グラフの各々のノードのうちの少なくとも1つは、テンポラル−リレーショナルデータベースのテンポラルテーブルのうちの1つを特定し、有向グラフによって共有されたノードのうちの少なくとも1つは、実行後にメモリに保存され、かつそのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルを特定する。ブロック804から、制御はブロック806へ進む。
破線のブロック806は、テンポラル−リレーショナルデータベースの一部であり、かつ少なくとも既存のSQLクエリがデータへのアクセスを必要とするテンポラルテーブルのうちの所与の1つのコンテンツを修正した後、クエリプラン演算子を実行した結果を保存し、かつテンポラルテーブルのうちの所与の1つを特定するノードに直接的または間接的に依存する既存のクエリプランのノードにより特定されたテンポラルテーブルを増分更新することを示す。この増分更新が、テンポラルテーブルのうちの所与の1つを特定するノードに直接的または間接的に依存する既存のクエリプランの1つまたは複数のノードにより表された1つまたは複数のクエリプラン演算子を増分実行することを含む(そのノードの各子ノードにより特定されたテンポラルテーブルの有効行において、そのようなノードのクエリプラン演算子を再実行する(完全再実行)のとは対照的に)実施形態において、効率がさらに向上する。ブロック806から、制御はブロック808へ進む。
破線のブロック808は、既存のクエリプランの有向グラフのノードのうちのルートノードにより特定されたテンポラルテーブルに対する増分更新を特定するデータを、先に送信されたSQLクエリを送信したクライアントに送信することを示す。
ブロック806、808に加えてまたはその代わりに、一実施形態は、1)有向グラフによって共有された少なくとも1つのノードにより特定されたテンポラルテーブルを必要に応じて増分更新することを含んで、再利用することにより、新たに送信されたSQLクエリのクエリプランを実行する、かつ2)新たに送信されたSQLクエリについてのクエリ結果を、新たに送信されたSQLクエリを送信したクライアントに送信する。ブロック806、808に加えてまたはその代わりに、一実施形態は、1)新たに送信されたSQLクエリのクエリプランの実行の一部として、有向グラフによって共有された少なくとも1つのノードにより表されたクエリプラン演算子を増分実行する、かつ2)新たに送信されたSQLクエリについてのクエリ結果を、新たに送信されたSQLクエリを送信したクライアントに送信する。加えてまたはあるいは、一実施形態において、既存のクエリプランは実行後にメモリに保存されているため、有向グラフのノードおよびサブグラフは潜在的な再利用のために使用可能である。加えてまたはあるいは、一実施形態において、そのノードにより表されたクエリプラン演算子を実行した結果を保存するように作成されたテンポラルテーブルの各々は、潜在的な再利用のために実行後にメモリに保存されている。加えてまたはあるいは、一実施形態において、生成は、1)既存のクエリプランの有向グラフのノードのうちの少なくとも1つを再利用可能であると特定すること、および2)特定されたノードに連結されたエッジを、新たに送信されたSQLクエリのクエリプランの有向グラフに追加することを含む。加えてまたはあるいは、生成は、1)再利用可能な既存のクエリプランの部分があることを特定し、特定された部分が、共有される有向グラフの少なくとも1つのノードを含むこと、および2)特定された部分を再作成するのではなく、新たに送信されたSQLクエリのクエリプランにおいて特定された部分を再利用することを含むことができる。リレーショナルデータベース管理システムは、新たに送信されたSQLクエリについてのクエリ結果をその同一のクライアントおよび/または異なるクライアントに送信することもできる。加えてまたはあるいは、一実施形態において、1つまたは複数のクエリプラン演算子は、テンポラル−リレーショナル代数演算を実行する。加えてまたはあるいは、一実施形態は、ルートノード、少なくとも1つまたは複数のリーフノード、および少なくとも1つまたは複数の中間ノードを各々含む有向グラフをサポートし、中間ノードは1つまたは複数の親ノードおよび1つまたは複数の子ノードの両方を有するノードであり(ルートノードは少なくとも1つの中間ノードに連結され、中間ノードの各々は少なくとも別の中間ノードまたは1つのリーフノードに連結され)、これら2つの有向グラフは、少なくとも1つの中間ノードおよびその子孫ノードを共有する。加えてまたはあるいは、一実施形態は、ノードおよびエッジのサブグラフを共有するクエリプランをサポートする。
加えてまたはあるいは、一実施形態において、先に送信されたSQLクエリは、クライアントによりサブスクリプションSQLクエリとして送信され、新たに送信されたSQLクエリは、サブスクリプションSQLクエリであるため、既存のクエリプランが実行後にメモリに保存されている間に、リレーショナルデータベース管理システムにより受信される。また、図1を参照して説明した様々な実施形態が概して図8に当てはまる。
ノードキー対ノードキャッシュ
図9は、一実施形態によるキャッシュ234を示すブロック図である。図9は、1)図2のキャッシュ234、物理クエリプラン242、およびベーステンポラルテーブル260、ならびに2)例示的な物理クエリプラン564(PQPN570A〜570Fからなる有向グラフを含む)および図5A、図5B、図6、図7BのBTT554A、554Bを再現する。図9はまた、ノードキー910のセットおよびノード参照920のセットを含むデータ構造を有するキャッシュ234を示す。図9では、物理クエリプラン564の各ノードがキャッシュ234のデータ構造内にエントリを有し、各ノードのエントリは、そのノードのノードキーをセット910に保存し、物理クエリプラン242内でそのノードを位置決めするために使用する参照をセット920に保存する。詳細には、図9は、PQPN570A〜570Fをそれぞれ特定するノードキー912A〜912Fおよびそれぞれの関連する参照922A〜922Fを示す。図9はテーブル形式のデータ構造を示すが、他の実施形態は異なるデータ構造(例えば、渡される各キーのハッシュをデフォルトで作成するハッシュマップ、グラフ構造など)を使用してもよい。
前述したように、生成中の新しいクエリプランのすべておよび/または一部を各々表す1つまたは複数のノードキーをキャッシュ234のノードキーと比較して、新しい物理クエリプランの生成が、1つまたは複数の既存の物理クエリプラン(例えば、物理クエリプラン564)の1つまたは複数の部分(各部分はノードまたはノードおよびエッジのサブグラフである)を再利用する/組み込むことができるかどうかを判定する。したがって、PQPNの各々についてノードキーが存在し、その意味で、各PQPNは1つのノードキーにより表される。新しい物理クエリプランに先立って論理クエリプランを最初に生成する実施形態において、論理クエリプランを使用して必要なノードキーを生成することができる。さらに、論理クエリプランを生成する実施形態において、LQPNから生成されたノードキーは、そのLQPN、および最終的にそのLQPNを実装するために使用されるPQPNを表す。
一部の実施形態において、所与のノードのノードキーは、単にそのノードを含むクエリプランの部分を表すが、そのノードの先祖(親ノード、祖父母ノードなど)(あれば)を含むクエリプランの部分を表さない。一部のそのような実施形態において、所与のノードのノードキーは、単にそのノードおよびその子孫(子ノード、孫ノードなど)(あれば)を含むクエリプランの部分を表すが、そのノードの先祖(親ノード、祖父母ノードなど)(あれば)を含むクエリプランの部分を表さない。例えば、1)一実施形態において、各ノードのノードキーは、そのノードおよびそのノードの子孫(あれば)をベースとし(例えば、そのノードのクエリプラン演算子およびパラメータ、ならびにそのノードの子孫(あれば)の各々をベースとし)、2)別の実施形態において、各ノードのノードキーは、そのノード(例えば、そのノードのクエリプラン演算子タイプおよびパラメータ)およびそのノードの子孫のキー(あれば)をベースとする(注:本実施形態において、各低レベルキーがそれ自身の子孫のすべてを既に表すため、一部の情報は複製される)。したがって、所与のクエリプランについて、1)そのクエリプランのルートノードのノードキーは、クエリプラン全体を表す、2)各リーフノード(例えば、BTTN)のノードキーは、リーフノードが参照するBTTを特定するクエリプランの部分を単に表す、3)クエリプランに1つまたは複数の中間ノードが存在する場合には、a)リーフノードに連結されたノード(リーフノードを子として有するノード)の各々のノードキーは、そのノード(例えば、クエリプラン演算子タイプおよびそのパラメータ(例えば、比較述語))およびその子孫ノード(例えば、リーフノード)を含むクエリプランの部分を単に表し、b)各高レベルノード(あれば)のノードキーは、高レベルノード(例えば、そのノードの子ノードにより提供された結果においてノードが実行するクエリプラン演算子およびそのパラメータ(例えば、比較述語))およびその子孫ノード(例えば、他の中間ノードおよびリーフノード)を含むクエリプランの部分を単に表す。特定の実施形態により、1)リーフノードは、テーブル参照に作用するTABLEクエリプラン演算子を表し、そのノードキーは、TABLEクエリプラン演算子タイプおよびそれが作用するテーブル参照(例えば、TABLE(CUSTOMERS))をベースとし、2)第2レベルノードは、テーブルクエリプラン演算子の結果に作用するクエリプラン演算子(例えば、SELECT)を表し、そのノードキーは、そのクエリプラン演算子タイプ、そのパラメータ(例えば、そのクエリプラン演算子の比較述語)、およびそのノードキーが依存するリーフノード(例えば、TABLE(CUSTOMERS)を表すリーフノード)をベースとし、3)高レベルノードは、その子ノードの結果に作用するクエリプラン演算子(例えば、JOIN)を表し、そのノードキーは、そのクエリプラン演算子タイプ、そのパラメータ(例えば、そのクエリプラン演算子の比較述語)、および子孫ノードをベースとし、4)ルートノードは、その子ノードの結果に作用するPROJECTクエリプラン演算子を表し、そのノードキーは、クエリプラン全体を表し、PROJECTクエリプラン演算子タイプ、そのパラメータ(例えば、そのPROJECTクエリプラン演算子の列名の一覧)、およびその子孫ノードをベースとする。
別の実施形態において、各ノードのノードキーは、そのノード(例えば、そのノードのクエリプラン演算子タイプおよびパラメータをベースとする)、およびそのノードの子ノード(あれば)のキー(子ノードキーは、それ自体、その子ノード(あれば)のキーをベースとする)などをベースとする(注:本実施形態は前記複製を避けることができる)。さらに別の実施形態において、各ノードのノードキーは、そのノード(例えば、そのノードのクエリプラン演算子タイプおよびパラメータをベースとする)およびそのノードの0以上の子ノード(例えば、子ノード(あれば)のクエリプラン演算子およびパラメータをベースとする)をベースとする。
特定の例により、図9は、論理クエリプランを最初に生成し、論理クエリプランからノードキーを生成し、各ノードのノードキーはそのノードおよびそのノードの子孫(あれば)をベースとする(例えば、そのノードのクエリプラン演算子およびパラメータ、およびそのノードの子孫(あれば)の各々をベースとする)実施形態を示す。したがって、ノードキー912Fは、リーフLQPN470F(子孫を有していない)の表現(例えば「TABLE(CUSTOMERS)」)であり、ノードキー912Eは、リーフLQPN470E(子孫を有していない)の表現(例えば「TABLE(ORDERS)」)であり、ノードキー912Dは、中間LQPN470Dおよびその子孫LQPN470Fの表現(例えば「SELECT(TABLE(ORDERS),ORDERS.Quantity>4)」)であり、ノードキー912Cは、中間LQPN470Cおよびその子孫LQPN470Eの表現(例えば、「SELECT(TABLE(CUSTOMERS),CUSTOMERS.PostalCode=10001)」)であり、ノードキー912Bは、中間LQPN470Cおよびその子孫LQPN470C〜470Fの表現(例えば、「JOIN(SELECT(TABLE(ORDERS),ORDERS.Quantity>4),SELECT(TABLE(CUSTOMERS),CUSTOMERS.PostalCode=10001),ORDERS.CustomerID=CUSTOMERS.CustomerID)」)であり、ノードキー912Aは、ルートLQPN470Aおよびその子孫のすべてLQPN470B〜470Fの表現(例えば、「PROJECT(JOIN(SELECT(TABLE(ORDERS),ORDERS.Quantity>4),SELECT(TABLE(CUSTOMERS),CUSTOMERS.PostalCode=10001),ORDERS.CustomerID=CUSTOMERS.CustomerID),CUSTOMERS.CustomerID,CUSTOMERS.Name,CUSTOMERS.PostalCode,ORDERS.OrderID,ORDERS.CustomerID,ORDERS.Price,ORDERS.Quantity)」)である。
上記の例では、ノードキーを文字列として説明したが、他の実施形態は異なるデータタイプをキーとして使用してもよい(例えば、一実施形態において、キーは文字列以外のオブジェクトであってもよく、別の実施形態において、キーを「ハッシュ」して、結果として得られるハッシュ値を使用する)。例えば、一部の実施形態において、プリティプリンタ(特定のノードから始まりその子孫を含むサブグラフの文字列表現を生成するために使用可能な周知のソフトウェアコンポーネント)の出力、またはそのハッシュを使用してキーを作成する。別の例として、一部の実施形態において、所与のLQPNのキーが、LQPNの子ノードのハッシュからの情報、再帰的に、LQPNの演算子タイプフィールドのデータ、LQPNの他のパラメータフィールド(あれば)のデータを使用して(例えば、ハッシュを生成することにより)作成される。
前述したように、グラフのエッジがグラフのノード内に保存される実施形態について説明したが、代わりに、代替実施形態はエッジをキャッシュ234に保存してもよい。
前述したように、異なる実施形態は、異なる技術を使用して、クエリプランのノードおよびTTの各々が実行後にどのくらい長くメモリに保存されるかを判定することができる。一実施形態において、「アクティブ」または「非アクティブ」の特定は、クエリプランの各々について維持され(例えば、特定は各クエリプランの有向グラフのルートノードに関連付けることができる)、「アクティブ」クエリプランの一部ではないノード(およびノードが参照するTT)は、実行後にメモリへの保存から除去される候補である。前述したように、Javaで実装された一実施形態において、キャッシュ234におけるルートノードおよびリーフノードへの参照(例えば、922A、922E、922F)は強参照タイプであり、キャッシュ234における中間ノード(例えば、922B、922C、922D)への参照は弱参照タイプであり、キャッシュ234において所与のルートノードが解放されると、Java仮想マシンのガベージコレクタは、そのルートノードから延びる有向グラフにより消費されたメモリを解放することができる。
ベーステンポラルテーブルのロード
図10は、ある実施形態による、ベーステンポラルテーブルのデータを入力可能な方法を示すブロック図である。図10は、図2のデータベースドライバ204およびRDBMS212の一部を再現する。一実施形態において、データが1つまたは複数の他のソースからRDBMS212にロードされる。例えば、図10は、破線のボックス1004が、リアルタイムストリーミングソース、第2のRDBMSシステム(Redwood Shores、CaliforniaのOracle Corporationにより製造されたOracle(登録商標)RDBMSなど)、スプレッドシート、計算サーバなどのソースであることを示す。ブロック1002は、ソース1004から受信したデータの抽出、変換、およびロード(ETL)演算を実行し、SQLステートメント(例えば、CREATE TABLEおよびINSERT)をプロセスクライアント通信マネージャ214に提供して、変換されたデータをロードする周知の技術を表す。前述したように、そのようなステートメントは、パーサ218に提供され、内部表現220の形式で非クエリエグゼキュータ228に到達し、これに応答して、必要なベーステンポラルテーブル260が作成されて入力される。そのような一実施形態において、RDBMS212は、1つまたは複数のソース上で動作するイン−メモリRDBMSであり、他のそのような実施形態において、RDBMS212は、オン−ディスクシステム、またはハイブリッドイン−メモリおよびオン−ディスクシステムである。図示した実施形態において、ETL1002は、データベースドライバを介してプロセスクライアント通信マネージャ214と対話するが、代替実施形態は異なって動作してもよい(例えば、ETLの代わりに、データを生成または計算する(抽出および変換とはとは対照的に)クライアントが、データベースドライバを使用して、SQLステートメント(例えば、CREATE TABLEおよびINSERT)をプロセスクライアント通信マネージャ214に提供してデータをロードしてもよい)。
別の実施形態において、RDBMS212はイン−メモリおよびオンディスクの組合せシステムであり、ベーステンポラルテーブルは、エンドユーザがアクセス可能なデータを保存する(したがって、データを別のソースからロードする必要がない)。例えば、一実施形態において、イン−メモリおよびオン−ディスクシステムである既存のRDBMSは、本発明の特徴を含むように拡張される。本明細書で使用するとき、「イン−メモリ」および「オン−ディスク」は、比較的速い読み書き時間を有する揮発性メインメモリ(例えば、ダイナミックランダムアクセスメモリ(DRAM))へのコード/データの保存を、より遅い読み書き時間を有する不揮発性の長期記憶装置(例えば、磁気ディスク、フラッシュメモリ、相変化メモリ、ソリッドステートドライブ(SSD))と区別するために使用される周知の用語である。しかしながら、本明細書で説明したように、より速い読み書き時間を有する不揮発性メモリ(例えば、相変化メモリ)を採用することにより、揮発性メインメモリと不揮発性の長期記憶装置との過去の区別は古いものとなる。したがって、本明細書における「インメモリ」(すなわち、ハイフンなし)という用語の使用は、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せへの保存を指す。
ユーザインターフェース
前述したように、複数の重複クエリが同時に存在する様々な理由がある。別のそのような理由は、異なる電子デバイス上で動作するエンドユーザクライアントを通して、複数の、しばしば多数のエンドユーザに共通のユーザインターフェース(例えば、ダッシュボード)を提供するユーザインターフェース層を使用することである。図11は、一実施形態によるRDBMS212上のユーザインターフェース層を示す。図11は、1)図2の物理クエリプラン242、ベーステンポラルテーブル260、および派生テンポラルテーブル264、2)例示的な物理クエリプラン564(PQPN570A〜570Fからなる有向グラフを含む)および図5A、図5B、図6のBTT554A、554B、ならびに3)例示的な物理クエリプラン622〜628(PQPN670A〜670Fを含む)を再現する。図11では、ユーザインターフェース層1100は、異なるエンドユーザ電子デバイス上で動作するエンドユーザクライアント(エンドユーザクライアント1104A〜1104N)を通して、ユーザインターフェースを複数のエンドユーザに提供する。一実施形態において、ユーザインターフェース層は「ダッシュボード」を提供する。例えば、エンドユーザクライアント1104A〜1104Mは、同一のダッシュボード(表示されたダッシュボード1110A〜1110Mとして示す)のインスタンスを各々表示し、エンドユーザクライアント1104Nは異なるダッシュボード1110Nを表示する。図示した例では、2つの異なるダッシュボードのみが例示の目的で示される(表示されたダッシュボード1110A〜1110Mと表示されたダッシュボード1110N)が、実施形態はより多いまたは少ないダッシュボードをサポートすることができる。
ダッシュボードは、通常、しばしば単一のウェブページまたはアプリケーションウィンドウ(キャンバスとも称する)に適合し、かつ電子デバイスを通してエンドユーザに表示するためのものであるボックスの集合(しばしば矩形で、タイルまたはパネルと称する)であり、実際には、通常、所与のダッシュボードは複数の電子デバイスを通して多数のエンドユーザに表示するためのものである。ダッシュボードの各ボックスは、データセットからのデータを表す(またはこのデータをベースとする)コンテンツ要素(例えば、チャート、グラフ、画像(例えば、色分けされたマップ)、スプレッドシート、ピボットテーブル、一覧、テーブル、ウィジェットであり、これらの一部を「ビュー」または「ビジュアル」と称することがある)を含む。ダッシュボードおよび/またはボックスの1つ、複数、もしくはすべては、ユーザがダッシュボードおよび/またはボックスと対話できるようにする「メニューバー」または他のタイプの表示アイテムを含むことができる。データセットは、コンテンツ要素を作成するために使用されるデータの集合であり、1つのデータ点、または単一のデータソースからのデータ(フィルタリング可能)、または複数のソース(例えば、Excelワークブックの1つまたは複数のテーブル、1つまたは複数のデータベース(例えば、SQLデータベース)、ウェブサイト、ソフトウェアサービス(例えば、セールスフォース)など)からのデータ(フィルタリング可能)であってよい。一実施形態において、ユーザインターフェース層1100は、RDBMS212に送信されたSQLクエリを生成し、RDBMS212は、データセットを形成するクエリ結果により応答し、そこからコンテンツ要素が入力される。図11の文脈において、エンドユーザクライアント1104A〜1104Nは、SQLステートメント(SQLクエリを含む)を送信して、コンテンツ要素1112A〜1112Dのデータセット(図示せず)を生成し、リレーショナルデータベース管理システム212は、コンテンツ要素1112A〜1112Dの適切なエンドユーザクライアントに提供されるデータセットであるクエリ結果により、SQLクエリに応答する。このようにして、エンドユーザクライアントは、RDBMS212のクライアントであり(データベースクライアントまたはRDBMSクライアントと称することができる)、各々データベースドライバ204を含む。他の実施形態において、ユーザインターフェース層1100は、式または「BIクエリ言語」(例えば、データ解析式(DAX)言語、多次元式(MDX)言語、独自の言語など)で要求を生成し、エンドユーザクライアント1104A〜1104NとRDBMS212との間のBIサービス1102は、1)エンドユーザクライアント1104A〜1104Nからの要求を、RDBMS212に提供するSQLクエリ(一部の実施形態において、サブスクリプションSQLクエリ)に翻訳し、2)RDBMS212からの応答クエリ結果を、ユーザインターフェース層1100によりコンテンツ要素を入力するために使用されるデータセットに翻訳する。図11の文脈において、エンドユーザ電子デバイス上で動作するエンドユーザクライアント1104A〜1104N(BIサービス1102(例えば、API、ウェブブラウザ、ネイティブクライアント、BIポータル、コマンドラインインターフェースなど)とインターフェース接続するソフトウェア(図示せず)を含む)は、BIサービス1102によりコンテンツ要素1112A〜1112Dのデータセット(図示せず)を生成するように設計されたSQLステートメント(SQLクエリを含む)に翻訳された要求(図示せず)を送信する。BIサービス1102は、データベースドライバ204を含み、これらのSQLステートメントをRDBMS212に送信する。RDBMS212は、クエリ結果をBIサービス1102に送ることによりSQLクエリに応答し、BIサービス1102は、このクエリ結果を、コンテンツ要素1112A〜1112Dの適切なエンドユーザクライアントに提供されるデータセットに翻訳する。このように、エンドユーザクライアント1104A〜1104NはBIサービス1102のクライアント(BIクライアントと称することができる)であり、BIサービスはRDBMS212のクライアント(データベースクライアントまたはRDBMSクライアントと称することができる)である。さらに他の実施形態は、両タイプのエンドユーザクライアントを有する(例えば、RDBMSクライアントである(したがって、データベースドライバ204のうちの1つを有する)エンドユーザクライアント、ならびにBIクライアントである(したがってBIサービス1102(例えば、API、ウェブブラウザ、ネイティブクライアント、BIポータル、コマンドラインインターフェースなど)とインターフェース接続するソフトウェアを有し、次いでRDBMSクライアントとなり、データベースドライバ204を含む)他のエンドユーザクライアント、またはさらにはBIクライアントおよびRDBMSクライアントの両方である(したがって、BIサービスおよびデータベースドライバ204のうちの1つとインターフェース接続する両ソフトウェアを含む)エンドユーザクライアントを有することができる)。
図11では、コンテンツ要素1112A、1112Bのデータセットは、物理クエリプラン622、564からのクエリ結果によりそれぞれ提供され、コンテンツ要素1112Cのデータセットは物理クエリプラン624、626のクエリ結果により提供され、コンテンツ要素1112Dのデータセットは物理クエリプラン628のクエリ結果により提供される。図11では、コンテンツ要素1112A〜1112Dのデータセットについてのクエリ結果を提供するクエリプランはすべて重複する。異なるダッシュボードの異なるコンテンツ要素についてのデータセットを提供するクエリプランは、重複することができる(例えば、物理クエリプラン628の有向グラフは、そのエッジのうちの少なくとも1つにより、物理クエリプラン564の有向グラフの少なくとも1つのノード(PQPN570B)に連結されて、それらの有向グラフが少なくとも1つのノード(少なくともPQPN570B)を共有するようになっており、物理クエリプラン564、628はそれぞれ第1のSQLクエリおよび第2のSQLクエリについて生成および実行されて、それぞれ第1のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112B)および第2のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112D)を入力し、第1のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112B)および第2のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112D)は、異なるエンドユーザクライアントにより表示される異なるダッシュボード(エンドユーザクライアント1104A、1104Nによりそれぞれ表示されるダッシュボード1110A、1110N)の一部である。したがって、1つのダッシュボードのコンテンツ要素が別のダッシュボードのコンテンツ要素と同一となり得ない場合でも、それらのコンテンツ要素について送信されたSQLクエリは、重複するクエリプランを生じさせることができる。
さらに、同一のダッシュボードの異なるコンテンツ要素についてのデータセットを提供するクエリプランは、重複することができる(例えば、物理クエリプラン622の有向グラフは、そのエッジのうちの少なくとも1つにより、物理クエリプラン564の有向グラフの少なくとも1つのノード(PQPN570E)に連結されて、それらの有向グラフが少なくとも1つのノードを共有するようになっており、物理クエリプラン564、622はそれぞれ第1のSQLクエリおよび第2のSQLクエリについて生成および実行されて、それぞれ第1のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112B)および第2のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112A)を入力し、第1のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112A)および第2のダッシュボードコンテンツ要素(例えば、コンテンツ要素1112B)は、異なるエンドユーザクライアントによりそのインスタンスが表示される同一のダッシュボード(例えば、エンドユーザクライアント1104A、1104Mによりそれぞれ表示されるダッシュボード1110A、1110M)の一部である。図11の例は、コンテンツ要素1112A〜1112Dのデータセットについてのクエリ結果を提供するクエリプランがすべて重複しているときを示すが、これは常に必要というわけではない(他の別個の物理クエリプラン、互いに重複する物理クエリプランの他の別個のセットなどがあってもよい)。
一部の実施形態において、ダッシュボードは通常、しばらくの間表示され、コンテンツ要素が略リアルタイムで更新されることが望まれるため、リレーショナルデータベース管理システム212に送信されたSQLクエリは、サブスクリプションSQLクエリとして送信することができる。前述したように、一部の実施形態は、クエリプラン演算子を増分実行することができ、これにより、完全再実行と比較して効率が向上する。したがって、サブスクリプションSQLクエリを使用して、増分実行と組み合わせてダッシュボードのコンテンツ要素についてのクエリ結果を提供することにより、そのSQLクエリ結果が依存するデータの変更に応答する更新がより速くなる。
さらに、一部の実施形態において、クライアントのうちの少なくとも1つが、クエリプランを生成したSQLクエリに対する更新を受信するようにサブスクライブされている限り、サブスクリプションSQLクエリのクエリプランは実行後にメモリに保存され、第1のクライアントによるサブスクリプションSQLクエリの使用により、そのサブスクリプションSQLクエリのクエリプラン(およびそのノードが特定するテンポラルテーブル)が潜在的な再利用のために実行後にメモリに保存される時間窓、したがって、別のクライアントが重複するまたは同一のSQLクエリ(非サブスクリプションまたはサブスクリプション)を送信することのできる時間窓を延長し、RDBMSは、既存のクエリプランを再利用できることを検出することができる(すなわち、リレーショナルデータベース管理システム212は、別のクライアントにより送信されたSQLクエリのクエリプランが、第1のクライアントにより送信されたサブスクリプションSQLクエリについて実行後にメモリに既に保存されている既存のクエリプランと完全にまたは部分的に重複することを検出する)。
同一の時間に異なる電子デバイス上の異なるエンドユーザが同一のダッシュボードを使用することにより、そのような各電子デバイスは、ダッシュボードのコンテンツ要素ごとに同一のSQLクエリを発行して、そのコンテンツ要素を入力する。例えば、所与のダッシュボードがX個の電子デバイスにより表示されている場合、そのダッシュボードの所与のコンテンツ要素を入力するために使用されるSQLクエリを、X回発行することができる(X個の電子デバイスの各々につき1回)。前述したように、実施形態は重複クエリプランを生成することができるため、複数のクライアントが同一のSQLクエリを送信することによって、その同一のSQLクエリについて単一のクエリプランを生成し共有することができる(これは、クエリプランが完全に重複して、単一のクエリプランのみが実行後にメモリに保存される場合に当てはまる)。したがって、同一の時間に複数のエンドユーザクライアントが共通のダッシュボードを使用することにより、その共通のダッシュボードのコンテンツ要素について同一の1つまたは複数のSQLクエリを送信することができ(エンドユーザクライアントがRDBMSクライアントである場合には、送信は直接であり、エンドユーザクライアントが、RDBMSクライアントであってクエリの複製に自身で対処しないBIサービスのクライアントである場合には、送信は間接的である)、これにより、RDBMSによって、その共通のダッシュボードについて1つまたは複数の完全に重複するクエリプランを再利用することになる。要するに、一実施形態において、同一のダッシュボードを同時に使用する複数のエンドユーザクライアントにより、サブスクリプションSQLクエリの同一のセットを(場合により異なる時間に)RDBMSに送信することができ、RDBMSは、サブスクリプションSQLクエリのクエリプランの単一のセットを生成し、クエリ結果をサブスクライブクライアントの各々に提供する(すべての有効なデータレコードを含む初期クエリ結果および経時的な増分クエリ結果(例えば、変更一覧の形式)の両方を、サブスクライブクライアントの各々にサブスクライブ中に提供する)。したがって、複数のエンドユーザクライアントがダッシュボードの同一のコンテンツ要素を使用することと組み合わせて、サブスクリプションSQLクエリを使用してダッシュボードのコンテンツ要素についてのクエリ結果を提供することにより、そのサブスクリプションSQLクエリのクエリプランが潜在的な再利用のために実行後にメモリに保存される時間窓、したがって別のクライアントが同一のSQLクエリを送信できる時間窓が大きくなり、リレーショナルデータベース管理システムは既存のクエリプランを再利用できることを検出することができる。
また、ある実施形態におけるユーザインターフェースにより、エンドユーザは1つまたは複数のコンテンツ要素と対話することができ、コンテンツ要素を入力するように発行されたSQLクエリが異なるエンドユーザクライアントについて同一ではなく重複するようになっている。例えば、第1のエンドユーザおよび第2のエンドユーザのエンドユーザクライアントは、単一のクエリプランが生成および実行された同一のSQLクエリに依拠する同一のコンテンツ要素を表示することができる。しかしながら、第1のエンドユーザは、異なるクエリプランを必要とするようにベースとなるSQLクエリを変更する方法で、ダッシュボードのコンテンツ要素と対話することができるが、異なるクエリプランは、依然として、第2のエンドユーザに対して表示されているコンテンツ要素についてのクエリプランと部分的に重複する。
また、一部の実施形態において、ダッシュボードを提供するユーザインターフェースは、使用可能なダッシュボードが比較的一定であるようになっているが、他の実施形態において、ユーザインターフェースにより、エンドユーザはダッシュボードを作成、編集し、他のエンドユーザと共有することができる。これを可能にする既存のユーザインターフェース(ビジネスインテリジェンスツールと称することがある)がある。ダッシュボードを作成および/または編集する能力を、セルフサービスダッシュボードまたはユーザカスタマイズ可能なダッシュボードと称することがある。この能力により、「データディスカバリ」の周知の概念が可能になる。データディスカバリは、データセットを理解するユーザ主導型プロセスであり、データセット内のパターンまたは特定のアイテムを検索することを含む。データディスカバリアプリケーションは、パターンまたは特定のアイテムを見つけるプロセスを迅速かつ直感的にするために、しばしば視覚ツール(例えば、マップ、ピボットテーブル)を使用する。データディスカバリは、これらの目標を達成するために統計技術およびデータマイニング技術を活用することができる。ベースとなるデータベースの応答性が高くなるほど、データディスカバリが効率的および実用的なるため、増分実行およびクエリプランの再利用をサポートするリレーショナルデータベース管理システム212により、複数のクライアントおよびより効率的なデータディスカバリをサポートするより応答性の高いテンポラル−リレーショナルデータベースが可能になる。詳細には、データディスカバリにより、エンドユーザがデータセット内のパターンおよびアイテムを検索するときに一連の重複クエリを発行することができるため、増分実行およびクエリプランの再利用を実行するリレーショナルデータベース管理システム212の能力によって、リレーショナルデータベース管理システム212は比較的迅速に応答できるようになり、より効率的なデータディスカバリが可能になる。
要するに、一部の実施形態は、リレーショナルデータベース管理システム212上にユーザインターフェース層1100を有し、1)ユーザインターフェース層は、エンドユーザがダッシュボードを作成、編集、共有できるようにするセルフサービスエンドユーザダッシュボードを提供し、必要なSQLクエリ(適宜サブスクリプションSQLクエリを含む)をリレーショナルデータベース管理システムに送信し、2)テンポラル−リレーショナルデータベースを管理し、かつ同時SQLクエリ(サブスクリプションSQLクエリを含む)をサポートするリレーショナルデータベース管理システムは、(a)重複クエリプランをサポートし、(b)クエリプランを実行後にメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に保存し、(c)それらのクエリプランの中間ノードおよびルートノードにより特定されたテンポラルテーブルを実行後にメモリに保存し、(d)増分実行を行って、それらのテンポラルテーブル、および最終的に、必要なSQLクエリについてのクエリ結果を増分更新する。
例示的な実装
以下で、クラスのインスタンス/オブジェクトを使用し、双方向クエリプラングラフを生成してダーティ通知有向グラフを生成してもよい実施形態について説明する。
図12は、一実施形態によるDTTNクラスのブロック図である。図12は、DTTNクラス1202が、1つまたは複数の記述子フィールド1204のセット、TT参照フィールド1206、子参照フィールド1208、最新リフレッシュ時間フィールド1210、およびEvaluateメソッド1212を含むことを示す。記述子フィールド1204のセットは、図4のLQPNについて説明したものと同様の方法で実装することができる。前述したように、各ルートノードおよび中間ノードはDTTNクラス1202のインスタンス/オブジェクトであり、TT参照フィールド1206は、そのノードにより実行されたクエリプラン演算の結果を保存するテンポラルテーブルをカプセル化する派生テンポラルテーブルオブジェクトのうちの1つを特定する参照を保存するためのものである。子参照フィールド1208は、図4のLQPNについて説明したものと同様の方法で実装することができる(例えば、子ノード(すなわち、直系の子孫)への参照の一覧)。最新リフレッシュ時間フィールド1210は、クエリプラン演算が最後に実行された時間(言い換えると、クエリプランのノードであるDTTNクラス1202の所与のインスタンス/オブジェクトについて、Evaluateメソッド1212に渡され、最新リフレッシュ時間フィールドに保存された最新のタイムスタンプ値を反映するタイムスタンプ)を保存するためのものである。
Evaluateメソッド1212は、DTTNクラス1202の所与のインスタンス/オブジェクト(各ルートノードおよび中間ノードはDTTNクラス1202のインスタンス/オブジェクトである)により表されたクエリプラン演算(テンポラルテーブルに作用、少なくとも場合により、テーブルのテンポラルコンテンツ(例えば、一部の実施形態において、valid_from列および/またはvalid_to列のコンテンツの少なくとも一部)を使用するという点でテンポラル−リレーショナル代数演算を実行する)を行うように実行される。一実施形態において、Evaluateメソッド1212は、評価開始時間を渡され、クエリプラン演算を実行する必要があると決定されると、1)その子ノードのEvaluateメソッドを呼び出し、2)これらの呼出しからの返しにおいて、その子ノードのBTT/DTTにアクセスして(または、一部の実施形態において、そのようなBTT/DTTの読取専用ビューもしくは読取専用コピーを参照して)必要なデータレコードを入手し、3)そのTT参照フィールド1206を参照して特定されたそれ自身のDTTに対する更新を実行し、4)そのDTTの読取専用ビューまたは読取専用コピーに参照を返す。Javaなどの一部のプログラミング言語では、オブジェクトはデフォルトで参照により渡されるため、参照によりオブジェクトを渡すのに特別なプログラミングは必要ない。
加えて、図12は、破線のボックスにより、DTTNクラス1202が、親参照フィールド1214、最新更新時間フィールド1216(ダーティタイムスタンプフィールドとも称する)、Add Parentメソッド1218、およびNotify Dirtyメソッド1220を含んでもよいことを示す。これら破線のボックスは、双方向クエリプラングラフを生成してダーティ通知有向グラフを作成する例示的な実装において使用される。親参照フィールド1214は、親ノード(すなわち、直系の先祖)への参照の一覧を保存するためのものである。最新更新時間フィールド1216は、クエリプラン演算が(直接的または間接的に)依存するBTTが最後に更新された時間(言い換えると、クエリプランのノードであるDTTNクラス1202の所与のインスタンス/オブジェクトについて、そのノードが依拠するBTTがダーティになった(修正された)ときを反映するタイムスタンプ)を保存するためのものである。Add Parentメソッド1218は、親ノードにより、その親ノードを参照して(その親ノードの初期化中に)呼び出され、このメソッドは親ノードへの参照を親参照フィールド1214に保存する。したがって、親ノードの初期化中、各子ノードのこのメソッドを呼び出して親ノードへの参照を渡し、各子ノードのこのメソッドは、この親ノードへの参照をその子ノードの親参照フィールド1214に挿入し、これにより、双方向クエリプラングラフの作成を助けてダーティ通知有向グラフを生成する。所与のノードのNotify Dirtyメソッド1220は子ノードにより呼び出され、その実行により、その所与のノードの最新更新時間フィールド1216を更新し、所与のノードの親参照フィールド1214にリストされた所与のノードの親ノード(あれば)のNotify Dirtyメソッド1220を呼び出す。動作中、BTTが修正されると、ダーティ通知有向グラフを使用して、そのダーティ通知有向グラフのルートノード(例えば、修正されたBTTをカプセル化するBTTN)からそのダーティ通知有向グラフのリーフノード(クエリプランのルートノード)まで再帰呼出しを行うことにより、変更によって影響された各ノードを特定し、これにより、ダーティ表示が、中間ノードを通ってそのBTTを消費するクエリプランのルートノードまで流れることができる。
図13は、一実施形態によるBTTNクラスのブロック図である。図13は、BTTNクラス1302が、1つまたは複数の記述子フィールド1304のセット、TT参照フィールド1306、Evaluateメソッド1312、およびメソッド1322を含むことを示す。記述子フィールド1304フィールドのセットは、図4のLQPNについて説明したものと同様の方法で実装することができる。前述したように、各リーフノードはBTTNクラス1302のインスタンス/オブジェクトであり、TT参照フィールド1306は、そのリーフノードのテンポラルテーブル(すなわち、テンポラル−リレーショナルデータベースのテンポラルテーブル)をカプセル化するベーステンポラルテーブルオブジェクトのうちの1つを特定する参照を保存するためのものである。
BTTNクラス1302の所与のインスタンス/オブジェクトのEvaluateメソッド1312は、所与のインスタンス/オブジェクトのTT参照フィールド1306で特定されたBTTの読取専用ビューまたは読取専用コピーへの参照を返す。
メソッド1322は、データレコードの追加、データレコードの削除、および/または既存のデータレコードのコンテンツの変更(例えば、INSERT、UPDATE、DELETE、および他の同様の演算でもよい)によって、そのノードにより特定されたテンポラルテーブルのコンテンツを修正するメソッド(各リーフノードはBTTNクラス1302のインスタンス/オブジェクトであり、テンポラルテーブルは、そのリーフノードのTT参照フィールド1306により特定されたベーステンポラルテーブルオブジェクトによってカプセル化される)、ならびにテーブルを作成するメソッドを含み、テーブルのコンテンツではなくテーブル自体を変更する他のデータ定義言語(DDL)の演算を含んでもよい。
加えて、図13は、BTTNクラス1302が親参照フィールド1314およびAdd Parentメソッド1318を含んでもよいことを示す。親参照フィールド1314は、親ノード(すなわち、直系の先祖)への参照の一覧を保存するためのものである。Add Parentメソッド1318は、親ノードにより、その親ノードを参照して(その親ノードの初期化中に)呼び出され、このメソッドは親参照フィールド1314の親ノードへの参照を保存する。したがって、親ノードの初期化中、各子ノードのこのメソッドを呼び出して親ノードへの参照を渡し、各子ノードのこのメソッドは、この親ノードへの参照をその子ノードの親参照フィールド1314に挿入し、これにより、双方向クエリプラングラフの作成を助けてダーティ通知有向グラフを生成する。
図14は、一実施形態によるTTクラスのブロック図である。図14は、TTクラス1402が、TTフィールド1406、1つまたは複数のget rowメソッドのセット(図示した実施形態において、Get Valid Rowsメソッド1424、Get Inserted Rowsメソッド1426、およびGet Deleted Rowsメソッド1428を含む)、ならびにメソッド1422を含むことを示す。各テンポラルテーブルがTTクラス1402のインスタンス/オブジェクト(本明細書において、派生テンポラルテーブル(DTT)またはベーステンポラルテーブル(BTT)と称する)によりカプセル化される場合、TTフィールド1406はそのテンポラルテーブルを保存するためのものである。「Get…Rows」メソッドは、TTフィールド1406のテンポラルテーブルのデータにアクセスするために呼び出される。Get Valid Rowsメソッド1424は、タイムスタンプを渡され、そのタイムスタンプにより表された時間に有効なすべてのデータレコードを返し、初期クエリ結果を提供するためのものである。クエリプラン演算および/またはサブスクリプションSQLクエリの増分実行をサポートする一実施形態において、Get Inserted Rowsメソッド1426およびGet Deleted Rowsメソッド1428を使用して、テンポラルテーブルへの変更(または「差分」)のみを返す。一実施形態において、これらのメソッドの各々は、2つのタイムスタンプを渡され、それらのタイムスタンプ間の時間にそれぞれ挿入または削除されたデータレコードを返す。Get Inserted Rowsメソッド1426は、2つのタイムスタンプを渡され、タイムスタンプにより表された2つの時間の間で挿入されたデータレコードを返し、Get Deleted Rowsメソッド1428は、2つのタイムスタンプを渡され、タイムスタンプにより表された2つの時間の間で削除されたデータレコードを返す。一実施形態は、図示した3つの「Get…Rows」メソッドを実装するが、代替実施形態は、より多い、少ない、および/または異なるメソッド(例えば、単一のメソッド)を実装してもよい。上記のvalid_fromおよびvalid_toの概念と同様に、理解を容易にするために、実施形態について、論理ビューおよび「1つまたは複数のget rowメソッドのセット」という用語(Get Valid Rowsメソッド1424、Get Inserted Rowsメソッド1426、およびGet Deleted Rowsメソッド1428として図示)を参照して説明したが、これらの用語の使用は行指向テンポラルテーブルのみを使用する実施形態に限定するものではなく、これらの用語の類義語は、get data recordsメソッド(例えば、Get Valid Data Recordsメソッド、Get Inserted Data Recordsメソッド、およびGet Deleted Data Recordsメソッドを含む)を含む。
メソッド1422は、データレコードの追加、データレコードの削除、および/または既存のデータレコードのコンテンツの変更(例えば、INSERT、UPDATE、DELETE、および他の同様の演算でもよい)によって、TTフィールド1406のテンポラルテーブルのコンテンツを修正するメソッド、ならびにテーブルを作成するメソッドを含み、テーブルのコンテンツではなくテーブル自体を変更する他のデータ定義言語(DDL)の演算を含む。一実施形態において、メソッド1422は、DTTNクラス1202のEvaluateメソッド1212および/またはBTTNクラス1302のメソッド1322により呼び出される。
図15は、一実施形態による図2の非クエリエグゼキュータ228のフロー図である。図15は、異なる非クエリSQLステートメントタイプが区別されるブロック1502から始まる。CREATE TABLEを有するSQLステートメントの場合、制御はブロック1504へ進む。これに対して、データレコードの追加、データレコードの削除、および/または既存のデータレコードのコンテンツの変更によってテーブルのコンテンツを修正するSQLステートメントの場合、制御はブロック1510へ進む。本発明の実施形態は、ブロック1504の非クエリSQLステートメントタイプをさらに区別し、かつ/または追加の非クエリSQLステートメントをサポートすることができる。
ブロック1504では、ベーステンポラルテーブルが作成され、フローが終了する。一実施形態において、ブロック1504を2つの動作に分けてもよく、ベーステンポラルテーブルが作成されてから、ベーステンポラルテーブルノードが作成される。詳細には、ブロック1506で、ベーステンポラルテーブルが作成され(例えば、TTクラス1402のインスタンス/オブジェクトがインスタンス化され)、制御はブロック1508へ進み、そこで、ベーステンポラルテーブルノード(BTTN)が作成され(例えば、BTTNクラス1302のインスタンス/オブジェクトがインスタンス化され、BTTNを初期化するために以下が実行される。1)記述子フィールド1304が入力される、2)ブロック1506で作成されたBTTを参照してTT参照フィールド1306が入力される、3)親参照フィールド1314を実装する実施形態において、「空」を示す値が親参照フィールド1314に保存される)。代替実施形態において、BTTNが最初に作成され、そのBTTを貪欲に(BTTNがインスタンス化されるとき)またはレイジーに(例えば、INSERTによりBTTに書き込む必要があるとき)作成する。
ブロック1510では、データレコードの追加、データレコードの削除、および/または既存のデータレコードのコンテンツの変更によりテーブルのコンテンツを修正するSQLステートメントが実行され、フロー図が終了する。BTTNを実装し、BTTNを通してBTTにアクセスする一実施形態において、ブロック1510はブロック1512を含み、ここでは、BTTNのメソッド1322のうちの適切な1つが呼び出され、これによりBTTのメソッド1422のうちの適切な1つを呼び出す。親参照フィールド1314およびNotify Dirtyメソッド1220を実装する一実施形態において、ブロック1510は、親参照フィールド1314にリストされた親ノードのNotify Dirtyメソッド1220を呼び出すことを含む。
一実施形態において、SQLクエリの送信前に、SQLステートメントを送信してSQLクエリに必要なベーステンポラルテーブル(BTT)を作成(例えば、非クエリエグゼキュータ228によりBTTおよびそれらのBTTのBTTNを作成)すべきであり、そのようなSQLクエリを含むSQLステートメントの1つに応答して、パーサ218のタスクは、必要なBTTが作成されたことを確認することを含む。
図16は、一実施形態による図2のクエリプランコネクタ232のフロー図である。前述したように、一実施形態において、SQLクエリの物理クエリプランの生成前に、そのSQLクエリの論理クエリプランが生成され、論理クエリプランはクエリプランコネクタ232により使用される。そのような実施形態において、図16はブロック1602から始まり、ここでは、論理クエリプランノードが論理クエリプランから現在の論理クエリプランノードとして選択される。
制御はブロック1604へ進み、そこで、選択された論理クエリプランノードのノードキーがキャッシュ234にあるかどうかを判定する。一実施形態において、選択された論理クエリプランノードのノードキーが生成され、その後、そのノードキーがキャッシュ234にある(再利用/組込み可能な物理クエリプランノード、および場合によりサブグラフが既に存在することを示す)かどうかを判定する。ノードキーがキャッシュ234にある場合には、制御はブロック1612へ進み、そこで、すべての論理クエリプランノードが考慮されたかどうかを判定する。すべての論理クエリプランノードが考慮された場合には、制御はブロック1614へ進み、そこでフロー図は終了する。すべての論理クエリプランノードが考慮されていない場合には、制御はブロック1602に戻り、そこで、別の論理クエリプランノードが現在の論理クエリプランノードとして選択される。異なる実施形態は、論理クエリプランノードを異なる順序で選択することができる。例えば、一実施形態は、論理クエリプランのリーフノードの親ノードを選択することにより始まり、次いで、選択された論理クエリプランのノードの親ノードを選択するなどして、論理クエリプランのルートノードに到達する。したがって、この実施形態は「論理クエリプランを上にたどる」。別の実施形態は、論理クエリプランのルートノードを選択することにより始まり、その論理クエリプランノードのノードキーがキャッシュ234にある場合には、SQLクエリの物理クエリプランが既にメモリに存在するため物理クエリプランを生成する必要がないが、ノードキーがキャッシュ234にない場合には、論理クエリプランのリーフノードの親ノードを選択し、次いで、選択された論理クエリプランのノードの親ノードを選択するなどして、論理クエリプランのルートノードに到達する。したがって、論理クエリプランのルートノードが見つからない場合、この実施形態も「論理クエリプランを上にたどる」。別の実施形態は、論理クエリプランのルートノードを選択することにより始まり、その論理クエリプランノードのノードキーがキャッシュ234にある場合には、SQLクエリの物理クエリプランが既にメモリに存在するため物理クエリプランを生成する必要がないが、論理クエリプランのルートノードのノードキーがキャッシュ234にない場合には、現在の論理クエリプランノードの子ノードを選択するなどして、論理クエリプランのリーフノードに到達する。この実施形態は、論理クエリプランを「下にたどる」。
ブロック1604で、選択された論理クエリプランノードのノードキーがキャッシュ234にないと判定された場合、制御はブロック1606へ進む。ブロック1606で、物理クエリプランノードがインスタンス化され、制御はブロック1608へ進む。一実施形態において、これは、DTTNクラス1202のオブジェクトのインスタンス化を伴う。
ブロック1608で、物理クエリプランノードが初期化される。DTTNクラス1202のインスタンス/オブジェクトに関し、以下が実行される。1)記述子フィールド1204が入力される、2)TT参照フィールド1306に空を示す値が入力される、3)親参照フィールド1214を実装する実施形態において、空を示す値が親参照フィールド1214に保存される、4)論理クエリプランのノードを上にたどる実施形態において、選択された論理クエリプランノードの子ノードについて生成されたノードキーを使用するキャッシュ234のルックアップをベースとして、子参照フィールド1208が入力される、5)最新リフレッシュ時間フィールド1210に、「なし」を示す値(例えば0)が入力される、6)最新更新時間フィールド1216を実装する実施形態において、現在の時間が入力される、7)上にたどり、かつAdd Parentメソッド1280、1318を実装する実施形態において、子参照フィールド1208の各子ノードのAdd Parentメソッド1218または1318が、初期化されている物理クエリプランノードを参照して呼び出される。論理クエリプランを上にたどる実施形態を参照してブロック1608を説明したが、論理クエリプランノードを選択する他の手法の1つを取る実施形態は、別の時間に動作4および7を必要とする。ブロック1608から、制御はブロック1610へ進む。
ブロック1610で、現在の論理クエリプランのノードキーおよびブロック1604でインスタンス化された物理クエリプランノードへの参照が、キャッシュ234のエントリに保存される。ブロック1610から、制御はブロック1612へ進む。
図17は、一実施形態によるクエリエグゼキュータ240のフロー図である。図17はブロック1702から始まり、ここで、現在のSQLクエリの時間(例えば、クライアントによりSQLクエリが送られた時間(クライアントがこれと通信する方法を有すると仮定する)、SQLクエリがRDBMSにより受信された時間、クエリプランの実行を開始する時間)に設定された評価開始時間を有する現在のクエリプラン(ルートPQPN)のルートノードのEvaluateメソッドが呼び出される。物理クエリプランのルートノード(DTTNクラス1202のインスタンス/オブジェクト)のEvaluateメソッド1212への呼出しにより、リーフPQPN(BTTNクラス1302のインスタンス/オブジェクト)に到達するまで、物理クエリプランのPQPNの再帰呼出しが行われ(各親がその子ノード(あれば)のEvaluateメソッドを呼び出す)、そのような呼出しは、前述したように、DTT/BTTのノードの読取専用ビューまたは読取専用コピーへの参照を返す。したがって、物理クエリプランのルートノードのEvaluateメソッド1212は、最終的にルートノードのDTTの読取専用ビューまたは読取専用コピーへの参照を返す。ブロック1702から、制御はブロック1704へ進む。
ブロック1704で、現在のクエリプランのルートノードのEvaluateメソッド1212により参照が返されたDTTのGet Valid Rowsメソッド1424(Get Valid Data Recordsメソッドとも称することができる)を呼び出して、評価開始時間を渡す。ブロック1704から、制御はブロック1706へ進み、そこで、クライアントに送る初期クエリ結果が作成される。一実施形態において、ブロック1706は、Get Valid Rowsメソッド(Get Valid Data Recordsメソッドとも称することができる)によるデータレコードからテーブルのvalid_from列およびvalid_to列を除去(すなわちvalid_fromフィールドおよびvalid_toフィールドを除去)して初期クエリ結果を作成することを含む。
ブロック1706から、制御はブロック1708へ進み、そこで、現在の物理クエリプランのルートノードへの参照および初期クエリ結果が、SQLクエリを送信したクライアントに送るために提供される。一実施形態において、クエリエグゼキュータ240には単一のメソッドが実装され、この単一のメソッドは、現在の物理クエリプランのルートノードへの参照および初期クエリ結果を返す。この単一のメソッドは、1)ルートノードに返された参照が無視される、非サブスクリプションSQLクエリの場合のプロセスクライアント通信マネージャ(PCCM)214、2)サブスクリプションSQLクエリの場合のサブスクリプションマネージャ(本明細書で後述する)により呼び出される。代替実施形態において、複数のメソッドを使用して、クエリエグゼキュータ240を実装することができる。例えば、そのような一実施形態において、クエリエグゼキュータ240は2つの別個のメソッドとして実装され、一方は、非サブスクリプションSQLクエリの場合のPCCM214により呼び出され、初期クエリ結果を返し、現在の物理クエリプランのルートノードへの参照は返さないものであり、他方のメソッドは、サブスクリプションSQLクエリの場合のサブスクリプションマネージャ(本明細書で後述する)により呼び出され、現在の物理クエリプランのルートノードへの参照および初期クエリ結果を返すものである。別のそのような実施形態において、クエリエグゼキュータ240は2つの別個のメソッドとして実装され、一方は、初期クエリ結果を返し、PCCM214およびサブスクリプションマネージャ(本明細書で後述する)の両方により呼び出されるものであり、他方は、現在の物理クエリプランのルートノードへの参照を返し、サブスクリプションマネージャ(PCCM214ではない)により呼び出されるものである。
図18は、一実施形態によるEvaluateメソッド1212のフロー図である。これにより、物理クエリプランの現在のノードのDTTN.Evaluateメソッド1212が呼び出される。前述したように、Evaluateメソッド1212は、呼び出されたときに、評価開始時間を渡される。図18は決定ブロック1802から始まり、ここで、計算が必要であるかどうかを決定する。計算が必要でない場合、制御はブロック1816へ進み、計算が必要な場合には、制御はブロック1808へ進む。ブロック1802は、必要でない場合に実行(増分実行であっても完全再実行であっても)を避ける最適化(上記でスキップ更新と称する)である。
一実施形態において、ブロック1802はブロック1804、1806を含む。ブロック1804で、評価開始時間が最新リフレッシュ時間よりも短い(すなわち、早い時間である)かどうかを判定する(Evaluateメソッド1212に渡された評価開始時間を、現在のノードの最新リフレッシュ時間フィールド1210の時間と比較する)。短い場合には、制御はブロック1816へ進み、短くない場合には、制御はブロック1806へ進む。ブロック1804は、現在のノードのクエリプラン演算の実行を避けると共に、渡された評価開始時間の後に現在のノードがリフレッシュされた場合に、いずれかの子ノードのEvaluateメソッドを呼び出す最適化である。例えば、これは、クエリプランの実行を並行してサポートする、かつ/またはクエリ実行を「過去の日付で」サポートする実施形態において行うことができる。ブロック1806で、最新リフレッシュ時間が最新更新時間よりも短い(すなわち、早い時間である)かどうかを判定する(最新更新時間フィールド1216を実装する実施形態において、現在のノードの最新リフレッシュ時間フィールド1210の時間が最新更新時間フィールド1216の時間よりも短いかどうかを判定する)。短い場合には、制御はブロック1808へ進み、短くない場合には、制御はブロック1816へ進む。ブロック1806は、最後のリフレッシュ後に更新が行われたかどうかを判定する、したがって現在のノードが、ダーティBTTに(直接的または間接的に)依存する(すなわち、ノードの入力が変更されたことがわかっている)ためリフレッシュする必要があるかどうかを判定する最適化である。
ブロック1808で、現在のノードの子参照フィールド1208の各ノードのEvaluateメソッドを呼び出し、評価開始時間を渡す。ブロック1808から、制御はブロック1810へ進む。
ブロック1810に示すように、呼び出された子ノードのEvaluateメソッドにより参照が返されたTTオブジェクトのGet Inserted RowsメソッドおよびGet Deleted Rowsメソッド(Get Inserted Data RecordsメソッドおよびGet Deleted Data Recordsメソッドとも称することができる)の1つまたは複数の呼出しが行われ、それらのメソッドに以下を渡す。1)増分挿入および削除されたデータレコードを検索するための、評価開始時間および現在のノードの最新リフレッシュ時間フィールド1210からの最新リフレッシュ時間(現在のノードがクエリプラン演算の増分実行をサポートする場合)、または2)挿入および削除されたすべてのデータレコードを検索するための、適切に遅い時間(例えば、最大値(評価開始時間、最新更新時間)、無限大)および適切に早い時間(例えば、0)(現在のノードがクエリプラン演算の増分実行をサポートしない場合、またはノードがクエリプラン演算の増分実行をサポートするが、それにもかかわらず、対応するクエリプラン演算(例えば、増分JOIN)を実行するために、挿入および削除されたすべてのデータレコードを必要とする場合)。前述したように、1つまたは複数のテンポラルテーブルのセットを入力として有するクエリプラン演算子の実行が、それらのテンポラルテーブルのうちの少なくとも1つから、増分挿入および削除されたデータレコードのみ(すべてのデータレコードとは対照的に差分)にアクセスすることを含む場合には、実行は「増分実行」となる。これに対して、1つまたは複数のテンポラルテーブルのセットを入力として有するクエリプラン演算子の実行が、セット内のすべてのテンポラルテーブルから、挿入および削除されたすべてのデータレコードにアクセスする必要がある場合には、実行は「完全実行」となる。増分実行、完全実行、または両方(両方の場合、可能であれば増分実行を行う)を行うように、所与のクエリプラン演算子を実装することができる。ブロック1810から、制御はブロック1812へ進む。
ブロック1812で、現在のノードのクエリプラン演算が実行され、現在のノードにより特定された(TT参照フィールド1206において特定された)DTTに結果がマージされる。一実施形態において、現在のノードのTT参照フィールド1206により特定されたDTTのメソッド1322のうちの適切なものを呼び出すことにより、結果がマージされる。ブロック1812から、制御はブロック1814へ進む。
ブロック1814で、現在のノードの最新リフレッシュ時間が、[最新更新時間フィールド1216が実装される場合には最新更新時間、または、実装されない場合には評価開始時間]に設定され、制御はブロック1816へ進む。
ブロック1816で、現在のノードのTT参照フィールド1206において特定されたDTTの読取専用コピーまたは読取専用ビューへの参照が返される。
図19は、一実施形態によるメソッド1322のフロー図である。ブロック1902で、BTTは、テンポラルテーブルのコンテンツを修正することにより更新される。一実施形態において、BTTNは、そのBTTNのTT参照フィールド1306において特定されたBTTのメソッド1422のうちの適切なものを呼び出し、この呼出しに応答して、BTTはTTフィールド1406のデータを更新する。ブロック1902から、制御はブロック1904へ進む。ブロック1904で、Notify Dirtyメソッド1220を実装する実施形態において、BTTNの親参照フィールド1314において特定されたノードのNotify Dirtyメソッド1220を呼び出し、最新更新時間を渡す。
図20は、一実施形態によるNotify Dirtyメソッド1220のフロー図である。ブロック2002では、現在のノードの最新更新時間フィールド1216が、渡された最新更新時間に設定される。ブロック2002から、制御はブロック2004へ進み、そこで、現在のノードの親参照フィールド1214におけるノードのNotify Dirtyメソッドを呼び出し、最新更新時間を渡す。
サブスクリプション
図21は、一実施形態によるサブスクリプションSQLクエリのフロー図である。ブロック2102では、RDBMSは、サブスクリプションSQLクエリを受信したことに応答して、物理クエリプランを生成および実行し、物理クエリプランおよび派生テンポラルテーブルを実行後にメモリ(すなわち、揮発性メモリ、不揮発性メモリ、および/またはこれらの組合せ)に保存する。ブロック2102から、制御はブロック2104へ進み、そこで、サブスクリプションSQLクエリを送信したクライアントに初期クエリ結果が送られる。ブロック2102、2104は前述した方法で実行することができる。ブロック2104から、制御はブロック2106へ進む。
ブロック2106で、サブスクリプション更新の時間であることが判定される。サブスクリプション更新の目的は、テンポラル−リレーショナルデータベースの一部であり、かつサブスクリプションSQLクエリがデータへのアクセスを必要とするテンポラルテーブルのうちの少なくとも所与の1つのコンテンツの修正に応答して、更新を提供することである。しかしながら、前述したように、異なる実施形態は、異なるタイミングで(例えば、前述したように、直ちに、また、レイジー更新をサポートする実施形態においては、1つまたは複数の事象が発生する(例えば、クエリ結果(例えば、初期または増分)をクライアントに送る必要がある、一定時間が経過する、プログラム可能な時間が経過する、ノードおよびエッジをベースとして(例えば、ノードと他のノードとの連結、ノードのタイプ、過去のノードの使用などをベースとして)計算された時間が経過する、他のSQLクエリの到着率が閾値を超える、および/または使用可能な計算リソースが閾値を下回る)まで更新を遅延させる)、そのような修正に応答することができる。さらに、異なる実施形態は、ブロック2106を実行する担当を異なって割り当てることができる。例として、プッシュモデルの実施形態およびプルモデルの実施形態について本明細書で後述する。
ブロック2106から、制御はブロック2108へ進み、そこで、実行後にメモリに保存された物理クエリプランおよび派生テンポラルテーブルを使用して増分クエリ結果が生成される。前述したように、増分実行を使用して、クエリプラン演算の完全再実行を避けることができ、スキップ更新を使用して、あるクエリプラン演算の実行を避けることができる。加えて、一実施形態において、クライアントに送られる増分クエリ結果は、既にクライアントに送られた結果に対する変更のみを含む(本明細書で、例示的な形式について後述する)。
ブロック2108から、制御はブロック2110へ進み、そこで、サブスクリプションについての増分クエリ結果が、サブスクリプションSQLクエリにサブスクライブされているクライアントに送られる。複数のクライアントが同一のSQLクエリに同時にサブスクライブされていることをサポートする実施形態において、サブスクリプションによる増分クエリ結果を複数のクライアントに送ることができる。
図22は、一実施形態による、非サブスクリプションSQLクエリおよびサブスクリプションSQLクエリの両方をサポートするために追加のブロックを有するリレーショナルデータベース管理システム212を示すブロック図である。図22は、図2における1)データベースドライバ204、ならびに2)プロセスクライアント通信マネージャ(PCCM)214、パーサ218、クエリエグゼキュータ240、物理クエリプラン242、テンポラル−リレーショナルデータベース262のベーステンポラルテーブル260、および派生テンポラルテーブル264を含むリレーショナルデータベース管理システム212を再現する。図22はまた、サブスクリプションSQLクエリを含むことのできるSQLステートメント216を再現する。PCCM214は、そのようなサブスクリプションSQLクエリ2218を、Subscribe Toメソッド2222およびIncremental Updateメソッド2224を含むサブスクリプションマネージャ2220に送る。一実施形態において、PCCM214は、サブスクリプションSQLクエリを送っているクライアントのデータベースドライバ204のうちの1つから「Subscribe To」遠隔手続き呼出しを受信し、PCCM214はSubscribe Toメソッド2222を呼び出して、サブスクリプションSQLクエリを渡す。再び、矢印線はデータフローおよび/または接続などの何らかのタイプの結合を表す。
Subscribe Toメソッド2222は、1)サブスクリプションSQLクエリのSQLクエリ部分(2228)をパーサ218に送信することにより、物理クエリプランを生成および実行し、2)結果として得られる初期クエリ結果をクエリエグゼキュータ240から受信し、3)PCCM214により、初期クエリ結果をサブスクリプション識別子(ID)と共に、サブスクリプションSQLクエリを送信したクライアントに送る(クエリ結果およびサブスクリプションID2212参照)。一部の実施形態において、Subscribe Toメソッド2222は、サブスクリプションSQLクエリごとに、現在のサブスクリプションの中で固有のサブスクリプションIDを生成し、そのサブスクリプションIDを(初期クエリ結果と共に)PCCM214に返して、サブスクリプションSQLクエリを送ったクライアントについてのデータベースドライバ204のうちの1つに返し、データベースドライバは、クライアントのサブスクリプションSQLクエリについてのサブスクリプションIDを保持する。代替実施形態において、サブスクリプションSQLクエリが送られた「固有の接続」を特定するデータが、サブスクリプションIDとして使用される(すなわち、データベースドライバ204のうちの所与の1つにより送信されたサブスクリプションSQLクエリごとの固有のTCP接続を使用することなどにより、「固有の接続」はクライアントとサブスクリプションSQLクエリとの組合せを固有に特定する)。さらに、SQLステートメント2226により示したように、PCCM214は、前述の通り、(サブスクリプションSQLクエリ2218のものではない)他のすべてのSQLステートメント216をパーサ218に送信する。パーサ218は、前述の通り、内部表現226を生成する。
Subscribe Toメソッド2222はまた、サブスクリプションSQLクエリごとに、サブスクリプションオブジェクト2230にサブスクリプションオブジェクトを作成する。各サブスクリプションオブジェクト2230は、1)サブスクリプションID(識別子)フィールド2232を含んでもよく、2)ルートノード参照フィールド2234、3)最新サブスクリプション更新時間フィールド2236、4)Subscription Updateメソッド2238、および5)プッシュモデル(ダーティ通知グラフを必要とする)を使用する実施形態において、Notify Dirtyメソッド2240を含む。サブスクリプションIDフィールド2232は、追跡の目的で使用可能な、サブスクリプションのサブスクリプションIDを保存するためのものである。ルートノード参照フィールド2234は、サブスクリプションSQLクエリについて生成された物理クエリプランのルートPQPN(例えば、DTTN)の物理クエリプラン242における位置への参照を保存するためのものである。最新サブスクリプション更新時間フィールド2236は、サブスクリプションが最後に更新された時間を反映するタイムスタンプを保存するためのものである。Subscription Updateメソッド2238は、実行時に、ルートノード参照フィールド2234のルートノードにより特定された物理クエリプランを実行させる。Notify Dirtyメソッド2240は、ルートノード参照フィールド2234において特定されたルートノードからの呼出しに応答して実行され、この呼出しは、サブスクリプションSQLクエリについてデータにアクセスするBTTに対して修正が行われたことを表す。Notify Dirtyメソッド2240の実行により、Subscription Updateメソッド2238が実行される。サブスクリプションオブジェクトを初期化すると、サブスクリプションオブジェクトは、そのサブスクリプションオブジェクトを参照して、ルートノード参照フィールド2234のルートノードのAdd Parentメソッド1218を呼び出し、このAdd Parentメソッド1218は、そのルートノードの親参照フィールド1214におけるサブスクリプションオブジェクトへの参照を保存し、これにより、双方向クエリプラングラフの適切なルートノードの親ノードとしてサブスクリプションオブジェクトを追加することにより、サブスクリプションオブジェクトは生成されたダーティ通知有向グラフの一部となる。動作時に、BTTが修正されると、ダーティ通知有向グラフを使用して、そのダーティ通知有向グラフのルートノード(例えば、修正されたBTTをカプセル化するBTTN)からそのダーティ通知有向グラフのリーフノード(クエリプランの各ルートノードまたはそのルートノード上に追加されたサブスクリプションオブジェクト)まで再帰呼出しを行うことによって、修正により影響された各ノードを特定し、これにより、ダーティ表示が、中間ノードを通って、そのBTTを消費するクエリプランのルートノードおよび/またはサブスクリプションオブジェクトまで流れることができる。
Incremental Updateメソッド2224は、サブスクリプションSQLクエリに対する増分更新の判定を容易にする。データベースドライバ204およびIncremental Updateメソッド2224は、本明細書で後述するプッシュモデルまたはプルモデルを実装する実施形態において異なって実装することができる。例えば、Incremental Updateメソッド2224は、プルモデルを実装する実施形態において、データベースドライバ204のGet More Resultsメソッド(図示せず)により、更新が望まれるたびに、遠隔手続き呼出しによって呼び出すことができ、Incremental Updateメソッド2224は、プッシュモデルを実装する実施形態において、データベースドライバ204のListenメソッド(図示せず)のみによって呼び出すことができる。
前述したように、一実施形態において、サブスクリプションSQLクエリのクエリプラン、およびそのクエリプランのノードにより特定された派生テンポラルテーブルは、少なくとも、そのサブスクリプションSQLクエリを送信したクライアントがそのサブスクリプションSQLクエリについてのクローズサブスクリプションメッセージを送信するまで、実行後にメモリに保存される。そのようなクローズサブスクリプションメッセージは、例えば、クローズするサブスクリプションSQLクエリを特定するサブスクリプションIDを含むことができる。一実施形態において、PCCM214はまた、そのようなクローズサブスクリプションメッセージ(図示せず)をサブスクリプションマネージャ2220に送り、サブスクリプションマネージャ2220は、1)物理クエリプランの1つまたは複数のノードを実行後にメモリに保存する必要がなくなったかどうかを判定し、これらのノードの除去およびキャッシュ234内の対応するエントリの除去(例えば、キャッシュ234からの対応するエントリの除去)を可能にする必要な措置を行い、2)そのサブスクリプションSQLクエリについてのサブスクリプションオブジェクトを削除する。
図23は、一実施形態によるSubscribe Toメソッド2222のフロー図である。ブロック2302で、サブスクリプションSQLクエリが受信され、制御はブロック2304へ進む。ブロック2304で、サブスクリプションSQLクエリのSQLクエリ部分が実行される。一実施形態において、この実行は、例えば、サブスクリプションSQLクエリの初期実行を調整するSubscribe Toメソッド2222からの呼出しに応答して、SQLクエリの物理クエリプランを生成および実行することを含む(パーサ218、クエリリライタ224、クエリオプティマイザ230(クエリプランコネクタ232を含む)、およびクエリエグゼキュータ240を伴い、したがって、生成は、前述した既存のノードおよびエッジの再利用/組込みを含むことができ、実行は増分実行を含むことができる)。ブロック2304から、制御はブロック2306へ進む。
ブロック2306で、クエリエグゼキュータ240からサブスクリプションSQLクエリの物理クエリプランのルートノードへの参照を受信したことに応答して、サブスクリプションオブジェクトが作成され初期化される。一実施形態において、この初期化は、1)実装されると、サブスクリプションIDをサブスクリプションIDフィールド2232に保存する、2)物理クエリプランのルートノードへの参照をルートノード参照フィールド2234に保存する、3)最新サブスクリプション更新時間フィールド2236に十分に早い時間を保存して、最初のサブスクリプション更新時にすべての更新が確実に取り込まれるようにする(例えば、結果テーブルのvalid_fromタイムスタンプおよびvalid_toタイムスタンプの最大値)、ならびに4)Add Parentメソッド1280、1318を実装する実施形態において、ルートノード参照フィールド2234のルートノードのAdd Parentメソッド1218が、初期化されているサブスクリプションオブジェクトを参照して呼び出される。
ブロック2306から、制御はブロック2308へ進む。ブロック2308で、クエリエグゼキュータ240から初期クエリ結果を受信したことに応答して、初期クエリ結果がPCCM214に提供されて、サブスクリプションSQLクエリを送信したクライアントに送られる。
図24Aは、プルモデルを実装する実施形態によるIncremental Updateメソッド2224のフロー図である。本実施形態において、RDBMSクライアントは、先に送信されたサブスクリプションSQLクエリに対する更新が望ましいと判定するたびに、データベースドライバ204のGet More Resultsメソッドを呼び出す。Get More Resultsメソッドにより、サブスクリプションSQLクエリの増分更新のためにRDBMS212への遠隔手続き呼出し(RPC)を行う(サブスクリプションIDがSubscribe Toメソッド2222により生成された値である実施形態において、サブスクリプションIDはデータベースドライバにより送られ、サブスクリプションSQLクエリを送った固有の接続をサブスクリプションIDデータが特定する実施形態において、RPCはその固有の接続を通して行われる。これは、サブスクリプションSQLクエリ送信に関連してクライアントとPCCM214との間に接続が先に確立されているため、接続自体を使用してサブスクリプションSQLクエリを特定することができるからである)。これに応答して、PCCM214はIncremental Updateメソッド2224を呼び出して、サブスクリプションIDを渡す。ブロック2402で、そのような呼出しはPCCM214から受信され、制御はブロック2404へ進む。
ブロック2404で、サブスクリプションIDにより特定されたサブスクリプションオブジェクトのSubscription Updateメソッド2238が呼び出される。一実施形態において、サブスクリプションマネージャ2220は、サブスクリプションIDをサブスクリプションオブジェクト2230にマッピングするデータ構造(例えば、テーブル)を維持するが、代替実施形態は、他のタイプの周知の機構を使用して、サブスクリプションオブジェクト2230のうちの適切な1つを位置決めすることができる。ブロック2404から、制御はブロック2406へ進む。
ブロック2406に示すように、サブスクリプションオブジェクトのSubscription Updateメソッド2238から増分クエリ結果を受信したことに応答して、増分クエリ結果がPCCM214に返されて、先に送信されたサブスクリプションSQLクエリに対する更新を望むクライアントに送られる。一実施形態において、増分クエリ結果がPCCM214(接続を管理し、クライアントにより呼び出された)によりクライアントに送られるが、別の実施形態において、Incremental Updateメソッドは、サブスクリプションSQLクエリを送った固有の接続を介して(例えば、サブスクリプションIDがサブスクリプションSQLクエリを送った固有の接続を特定するデータである実施形態において、サブスクリプションIDを使用して)増分クエリ結果をクライアントに送る。
図24Bは、プッシュモデルを実装する実施形態によるIncremental Updateメソッド2224のフロー図である。第1のそのような実施形態において、サブスクリプションSQLクエリの送信後、クライアントコードは、データベースドライバ204のListenメソッドを一度呼び出して、サブスクリプションSQLクエリに対するプッシュベースの更新を受信する。Listenメソッドは、特定のサブスクリプションSQLクエリについてRDBMS212に対して遠隔手続き呼出し(RPC)を行う(サブスクリプションIDがSubscribe Toメソッド2222により生成された値である実施形態においては、サブスクリプションIDはデータベースドライバ204により送られ、サブスクリプションIDがサブスクリプションSQLクエリを送った固有の接続を特定するデータである実施形態においては、サブスクリプションIDを送る必要がない。これは、サブスクリプションSQLクエリの送信に応答して、クライアントとPCCM214との間に接続が先に確立されているため、接続自体がサブスクリプションSQLクエリを特定するからである)。これに応答して、PCCM214は、サブスクリプションSQLクエリを送った接続を特定するデータ(前述した一部の実施形態においては、サブスクリプションIDであり、サブスクリプションIDがSubscribe Toメソッド2222により生成された値である実施形態においては、サブスクリプションIDも送られる)を含むIncremental Updateメソッド2224を呼び出す。ブロック2412で、そのような呼出しがPCCM214から受信され、制御はブロック2414へ進む。この段落で説明した第1の実施形態において、サブスクリプションIDはSubscribe Toメソッド2222からIncremental Updateメソッド2224へ、クライアントコードを通して間接的に提供されるが、代替実施形態は異なって動作する。例えば、そのような1つの代替実施形態において、ブロック2302は、データベースドライバ内のコールバックメソッド(関数ポインタ、関数オブジェクトなどとしてListenメソッドなどに渡すことのできる「On Data Update」メソッドなど)を特定するデータを含み、ブロック2308は、クライアントコードを通すのとは対照的に、サブスクリプションIDをRDBMS212内でSubscribe Toメソッド2222からIncremental Updateメソッド2224へ(例えば、Incremental Updateメソッドへの引数として、共有メモリの領域を介して、他のプロセス間通信機構を介してなど)提供することを含む。この場合、ブロック2412は、クライアントコードのListenメソッドからのRPCに応答する、PCCMを通したリッスンへの呼出しを伴わない。
ブロック2414で、サブスクリプションオブジェクトおよび接続情報を含むサブスクリプションスレッドが作成され、サブスクリプションスレッドは、1)適切なサブスクリプションオブジェクト2230のルートノード参照フィールド2234におけるルートノードのAdd Parentメソッド1218を呼び出して、参照をそのサブスクリプションオブジェクトに渡し、Add Parentメソッド1219(前述した)は、サブスクリプションオブジェクトへの参照をそのルートノードの親参照フィールド1214に保存し、2)サブスクリプションオブジェクトのNotify Dirtyメソッド1220がルートノードのNotify Dirtyメソッドにより呼び出されるのを待ってスリープ状態となる。ブロック2414から、制御はブロック2416へ進む。
ブロック2416に示すように、ルートノードのNotify Dirtyメソッド1220からサブスクリプションオブジェクトのNotify Dirtyメソッド2240(最新更新時間を渡される)を呼び出すことによりサブスクリプションスレッドを呼び起こすたびに、サブスクリプションスレッドは、サブスクリプションオブジェクトのSubscription Updateメソッド2238を呼び出し(Notify Dirtyメソッド2240により渡された最新更新時間をSubscription Updateメソッド2238に渡し)、その後、Subscription Updateメソッド2238から(例えば、データベースドライバ(例えばRPC)からのブロック呼出しにより、データベースドライバにより確立された固有の接続を通してデータを送ることにより(例えば、RPCストリーミングにより)など)増分クエリ結果を受信したことに応答して、SQLクエリにサブスクライブされたクライアントに対して増分クエリ結果をプッシュし、その後、スリープ状態に戻る。一実施形態において、増分クエリ結果がPCCM214(接続を管理し、クライアントにより呼び出された)によりクライアントに送られるが、別の実施形態において、Incremental Updateメソッド2224は、Incremental Updateメソッド2224への呼出しにおいて特定された固有の接続により(例えば、サブスクリプションIDがサブスクリプションSQLクエリを送った固有の接続を特定するデータである実施形態において、サブスクリプションIDを使用して)、増分クエリ結果をクライアントに送る。ブロック2302がデータベースドライバのコールバックメソッドを特定するデータを含む実施形態において、データベースドライバは、そのコールバックメソッドを呼び出して、増分クエリ結果をそのようなメソッドに提供する。
図25は、一実施形態によるSubscription Updateメソッド2238のフロー図である。このフロー図は、前記プルモデルおよびプッシュモデルを使用する実施形態において使用することができる。ブロック2502で、サブスクリプションオブジェクトのルートノード参照フィールド2234により特定されたルートノードのEvaluateメソッド1212を呼び出して、評価開始時間を渡す。異なる実施形態は、評価開始時間を異なって設定することができる(例えば、現在の時間(例えば、このメソッドを呼び出すシステム時間、クライアントがIncremental Updateメソッドを呼び出す時間(メソッド呼出しが送られる場合)、プルモデルにおいてIncremental Updateメソッドへの呼出しが(例えば、PCCM)により受信される時間)に設定され、かつプッシュモデルにおいて最新更新時間に設定される)。ブロック2502から、制御はブロック2504へ進む。
ブロック2504で、呼び出されたルートノードのEvaluateメソッドにより参照またはビューが返されたTTオブジェクトのGet Inserted RowsメソッドおよびGet Deleted Rowsメソッド(Get Inserted Data RecordメソッドおよびGet Deleted Data Recordメソッドと称することもできる)を呼び出して、それらのメソッドに、評価開始時間およびサブスクリプションオブジェクトの最新サブスクリプション更新時間フィールド2236からの最新サブスクリプション更新時間を渡す。ブロック2504から、制御はブロック2506へ進む。
ブロック2506で、増分クエリ結果が作成される。一実施形態において、増分クエリ結果はクライアントに送られる変更一覧である。一実施形態において、変更一覧は、変更(すなわち、先に計算されたクエリ結果を表す(対応するクエリプランのルートノードにより特定された)テンポラルテーブルに対する変更)ごとに、1)そのようなテンポラルテーブルの対応するデータレコードの各列の値、2)変更タイプ(例えば、挿入または削除)、および3)変更の時間を特定するタイムスタンプを含む。一実施形態において、変更一覧は、1)「valid_from」列および「valid_to」列を除去すること、2)変更タイプを保存する「変更タイプ」列(データレコードが挿入されたか削除されたかをデータレコードごとに示す)を追加すること、および3)変更時間を特定するタイムスタンプ(データレコードがいつ挿入または削除されたかをデータレコードごとに示す)を保存する「変更時間」列を追加することにより、ブロック2504において返されたデータレコードから生成される。ブロック2506から、制御はブロック2508へ進む。
ブロック2508で、サブスクリプションオブジェクトの最新サブスクリプション更新時間フィールド2236が、[プルモデルの実施形態においては評価開始時間、または、プッシュモデルの実施形態においては最新更新時間]に更新される。ブロック2508から、制御はブロック2510へ進む。
ブロック2510で、SQLクエリにサブスクライブされたクライアントに、増分クエリ結果が送られる。プルモデルを使用する実施形態において、Subscription Updateメソッド2238がサブスクリプションマネージャ2220のIncremental Updateメソッド2224により呼び出され、増分クエリ結果が、サブスクリプションマネージャ2220を通してクライアントに送り返される(増分クエリ結果をPCCM214を通してクライアントに送ることができ、またはサブスクリプションマネージャ2220への呼出しにおいて特定された固有の接続によりクライアント自身に送ることができる)。プルモデルを使用する代替実施形態は異なって動作することができる(例えば、Subscription Updateメソッド2238は、増分クエリ結果を、Subscription Updateメソッド2238への呼出しにおいて特定された固有の接続によりクライアント自身に送ることができる)。同様に、プッシュモデルを使用する実施形態において、増分クエリ結果をクライアントに送る担当が変化してもよい(例えば、サブスクリプションスレッドは、増分クエリ結果をPCCM214に送り、PCCM214が増分クエリ結果をクライアントに送ることができる、Subscription Updateメソッド2238は、増分クエリ結果を、Subscription Updateメソッド2238への呼出しにおいて特定された固有の接続によりクライアント自身に送ることができる)。
例示的な使用事例
上記実施形態を様々に組み合わせて、ある使用事例を満たすことができる。例として、1つの使用事例は、金融市場における漸進的リスク集約である。この使用事例は、通常、ダッシュボードを使用する異なるユーザ電子デバイスにおける複数のエンドユーザにより、略リアルタイムのデータと大量の過去のデータ(長期ビューを提供するため)との組合せの複雑な解析を行う必要がある。ある実施形態は、この使用事例を、図11のユーザインターフェース層1100およびリレーショナルデータベース管理システム212によりサポートする。詳細には、ユーザインターフェース層1100は、異なるエンドユーザ電子デバイス上の複数の、実際には多数のエンドユーザに同一のダッシュボードを同時に提示する(これにより、同時に重複する複数のクエリプランが得られる)ことを含むダッシュボードの使用をサポートし、ある実施形態において、ダッシュボードを作成、編集、共有し、データディスカバリを可能にするセルフサービスエンドユーザダッシュボードの使用をサポートする。リレーショナルデータベース管理システム212(ある実施形態において、イン−メモリおよび解析リレーショナルデータベース管理システムである)は、テンポラル−リレーショナルデータベースを管理し、複数のクライアントを同時にサポートするサーバであり、複数のSQLクエリ(サブスクリプションSQLクエリを含む)を同時にサポートし、クエリプラン(ルートPQPNおよび中間PQPNを含む)を実行後にメモリに保存し、それらのクエリプラン(ルートPQPNおよび中間PQPNを含む)の派生テンポラルテーブルを実行後にメモリに保存し、重複クエリプラン(中間PQPNおよびリーフPQPNの共有を含む)をサポートし、少なくともあるクエリプラン演算子についての増分クエリプラン実行をサポートする。したがって、一部のそのような実施形態において、ダッシュボードのコンテンツ要素を略リアルタイムで更新することができる。比較的大きいクエリ深さのSQLクエリについてのものを含むこの略リアルタイムのパフォーマンスは、金融市場における漸進的リスク集約に特に適している。加えてまたはあるいは、一部の実施形態において、RDBMS212はトランザクションRDBMSであり、テンポラルテーブル(BTTおよびDTT)は列指向構成を使用してメモリに保存される。
さらに、あるそのような実施形態において、ユーザインターフェース層1100は、BIクエリ言語に依拠するセルフサービスエンドユーザダッシュボードをサポートし、BIサービス1102は、そのような言語をリレーショナルデータベース管理システム212に送信する前にSQLステートメント(SQLクエリを含む)に変換する。そのような一実施形態において、本明細書に記載されたように、BIクエリ言語およびSQLの両方がサブスクリプションをサポートするように拡張されて、BIクエリ言語サブスクリプションが、リレーショナルデータベース管理システム212に送信されるサブスクリプションSQLクエリに変換されるようになっている。
例示的な電子デバイス
実施形態の1つまたは複数の部分は、ソフトウェア、ファームウェア、および/またはハードウェアの異なる組合せを使用して実装することができる。電子デバイスは、コード(ソフトウェア命令から構成され、コンピュータプログラムコードまたはコンピュータプログラムと称することがある)および/またはデータを、機械可読記憶媒体(例えば、磁気ディスク、光ディスク、読取専用メモリ(ROM)、フラッシュメモリ、相変化メモリ、ソリッドステートドライブ(SSD))、および機械可読伝送媒体(キャリアとも称する)(例えば、電気信号、光信号、無線信号、音響信号、または搬送波、赤外線信号などの他の形式の伝搬信号)などの機械可読媒体(コンピュータ可読媒体とも称する)を使用して、保存し送信する(内部におよび/またはネットワークを通して他の電子デバイスに)ことができる。したがって、電子デバイス(例えば、コンピュータ)は、プロセッサのセットで実行するためのコードを保存し、かつ/またはデータを保存するための1つまたは複数の機械可読記憶媒体に接続された、1つまたは複数のプロセッサのセットなどのハードウェアおよびソフトウェアを含む。例えば、電子デバイスは、コードを含む不揮発性メモリ(より遅い読み書き時間を有する。例えば、磁気ディスク、光ディスク、読取専用メモリ(ROM)、フラッシュメモリ、相変化メモリ、SSD)を含むことができる。これは、電子デバイスをオフにしたとき(電力を除去したとき)でも、不揮発性メモリがコード/データを持続することができるからである。一方、電子デバイスをオンにしたときには、その電子デバイスのプロセッサにより実行されるコードの部分が、電子デバイスの不揮発性メモリから揮発性メモリ(例えば、ダイナミックランダムアクセスメモリ(DRAM)、スタティックランダムアクセスメモリ(SRAM))にコピーされる。これは、揮発性メモリがより速い読み書き時間を有する(演算するすべてのデータのうちの一部もこの揮発性メモリに保存される)からである。別の例として、電子デバイスは、電子デバイスをオフにしたときにコード/データを保存するための不揮発性メモリ(例えば、相変化メモリ)を含むことができ、その同一の不揮発性メモリは、十分に速い読み書き時間を有し、実行されるコードの部分を揮発性メモリにコピーするのではなく、コード/データをプロセッサに直接提供する(例えば、プロセッサのキャッシュにロードする)ことができるようになっている。言い換えると、この不揮発性メモリは長期記憶装置およびメインメモリの両方として動作し、したがって、電子デバイスは、メインメモリとしてDRAMをまったく有していないか、または少しだけ有していればよい。一般的な電子デバイスはまた、他の電子デバイスとのネットワーク接続を確立する(伝搬信号を使用してコードおよび/またはデータを送信および/または受信する)ために、1つまたは複数の物理ネットワークインターフェースのセットを含む。
図26は、一実施形態による電子デバイス2604を示す。図26は、1つまたは複数のプロセッサ2642のセットおよび1つまたは複数のネットワークインターフェース2644(無線および/または有線)のセット、ならびにソフトウェア2650を保存した非一過性の機械可読記憶媒体2648を含む、ハードウェア2640を含む。前述したエンドユーザクライアント、BIサービス、およびリレーショナルデータベース管理システム212の各々は、1つまたは複数の電子デバイス2604に実装することができる。一実施形態において、各エンドユーザクライアントは、別々の電子デバイス2604(例えば、エンドユーザにより操作されるエンドユーザ電子デバイス。この場合、そのような各エンドユーザ電子デバイスのソフトウェア2650は、データベースドライバ204のうちの1つを含む、エンドユーザクライアントのうちの1つを実装するためのソフトウェア、および/またはBIサービス1102(例えば、API、ウェブブラウザ、ネイティブクライアント、BIポータル、コマンドラインインターフェースなど)とインターフェース接続するソフトウェアを含む)に実装され、リレーショナルデータベース管理システム212は、1つまたは複数の電子デバイス2604の別のセットに実装され(この場合、ソフトウェア2650はリレーショナルデータベース管理システム212を実装するためのソフトウェアである)、動作時に、エンドユーザ電子デバイスおよびRDBMSを実装する電子デバイスは、相互に接続され(例えば、ネットワークにより)、デバイス間に(または、1つまたは複数の他の層(例えば、RDBMSを実装する1つまたは複数の電子デバイスのセットとは別個の、これと重複する、またはこれと同一の1つまたは複数の電子デバイスのセットに実装可能なBIサービス(この場合、ソフトウェア2650は、BIサービスを実装するためのソフトウェアを含む))を通して)、SQLクエリをRDBMS212に送信しクエリ結果を返すための前記接続を確立する。電子デバイスの他の構成を他の実施形態(例えば、エンドユーザクライアント、BIサービス(使用する場合)、およびRDBMSが単一の電子デバイスに実装される実施形態)で使用してもよい。
計算仮想化を使用する電子デバイスにおいて、プロセッサ2642は、通常、仮想化層2654およびソフトウェアコンテナ2662A〜2662Rをインスタンス化するためのソフトウェアを実行する(例えば、オペレーティングシステムレベルの仮想化について、仮想化層2654は、1つまたは複数のアプリケーションのセットを実行するために各々使用可能な複数のソフトウェアコンテナ2662A〜2662R(別個のユーザ空間インスタンスおよび呼び出された仮想化エンジン、仮想専用サーバ、またはjailを表す)の作成を可能にするオペレーティングシステムのカーネル(またはベースオペレーティングシステム上で実行するシム)を表す。完全仮想化について、仮想化層2654は、ハイパバイザ(仮想マシンモニタ(VMM)と称することがある)またはホストオペレーティングシステム上で実行するハイパバイザを表し、ソフトウェアコンテナ2662A〜2662Rは、ハイパバイザにより動作し、かつゲストオペレーティングシステムを含むことのできる、仮想マシンと称するしっかりと隔離された形式のソフトウェアコンテナを各々表す。準仮想化について、仮想マシンで動作するオペレーティングシステムまたはアプリケーションは、最適化の目的で仮想化の存在を認識することができる)。再び、計算仮想化を使用する電子デバイスで、動作中、ソフトウェア2650のインスタンス(インスタンス2676Aとして示す)が仮想化層2654のソフトウェアコンテナ2662A内で実行される。計算仮想化を使用しない電子デバイスでは、ホストオペレーティングシステム上のインスタンス2676Aは「ベアメタル」電子デバイス2604上で実行される。インスタンス2676A、ならびに仮想化層2654およびソフトウェアコンテナ2662A〜2662R(実装する場合)のインタンス化を、まとめてソフトウェアインスタンス2652と称する。
電子デバイスの代替実施形態は、前述した実施形態の多数の変形形態を有することができる。例えば、カスタマイズされたハードウェアおよび/またはアクセラレータを電子デバイスにおいて使用してもよい。
代替実施形態
図中のフロー図は、ある実施形態により実行される動作の特定の順序を示すが、そのような順序は例示的なものである(例えば、代替実施形態は、動作を異なる順序で実行する、ある動作を組み合わせる、ある動作を並行して実行するなどしてもよい)。
加えて、本発明についていくつかの実施形態に関して説明したが、本発明は、記載された実施形態に限定されず、添付の特許請求の範囲の精神および範囲内で修正および変更を伴って実施することができることを当業者は理解するだろう。したがって、説明は限定的なものではなく例示的なものであるとみなすべきである。