特許 5976595 統合テーブルクエリ処理

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5976595

(24)【登録日】2016年7月29日

(45)【発行日】2016年8月23日

(54)【発明の名称】統合テーブルクエリ処理

(51)【国際特許分類】

   G06F 17/30 20060101AFI20160809BHJP

   G06F 12/00 20060101ALI20160809BHJP

【ＦＩ】

   G06F17/30 160F

   G06F12/00 505

   G06F12/00 513D

【請求項の数】12

【外国語出願】

【全頁数】23

(21)【出願番号】特願2013-93555(P2013-93555)

(22)【出願日】2013年4月26日

(65)【公開番号】特開2014-13562(P2014-13562A)

(43)【公開日】2014年1月23日

【審査請求日】2015年4月17日

(31)【優先権主張番号】61/640,689

(32)【優先日】2012年4月30日

(33)【優先権主張国】US

(31)【優先権主張番号】61/646,162

(32)【優先日】2012年5月11日

(33)【優先権主張国】US

(31)【優先権主張番号】13/843,898

(32)【優先日】2013年3月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】300015447

【氏名又は名称】エスアーペー エスエー

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100064908

【弁理士】

【氏名又は名称】志賀 正武

(74)【代理人】

【識別番号】100089037

【弁理士】

【氏名又は名称】渡邊 隆

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】フランツ・フェルバー

(72)【発明者】

【氏名】ジュチャン・リー

(72)【発明者】

【氏名】イヴァン・シュレーター

【審査官】 田中 秀樹

(56)【参考文献】

【文献】 米国特許出願公開第２０１１／００１６１５７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１２／００７２６５６（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

マルチレベルストレージアーキテクチャを有するインメモリコンピューティングシステムの統合テーブルアーキテクチャにおける、クエリ処理の方法であって、前記マルチレベルストレージアーキテクチャが、受信したデータ要求をデータ記録として論理行フォーマットで格納するための第1のレベルのストレージ構造、前記データ記録を論理列フォーマットで符号化および格納するための第2のレベルのストレージ構造、および長期的に格納するために、前記符号化されたデータ記録を圧縮および格納するためのメインストアを有し、
前記統合テーブルアーキテクチャに接続された共通クエリ実行エンジンによって、データ記録を指定するクエリを受信するステップと、
前記共通クエリ実行エンジンによって、前記第1のレベルのストレージ構造における前記クエリに基づいて、前記データ記録に関するルックアップを実行するステップと、
前記データ記録が前記第1のレベルのストレージ構造に存在しない場合、前記共通クエリ実行エンジンによって、前記第2のレベルのストレージ構造および前記メインストアのそれぞれの中で別個のルックアップを実行するステップと
を含む方法。

【請求項2】

前記別個のルックアップが同時に実行されて、2つの中間結果を生み出す、請求項1に記載の方法。

【請求項3】

前記2つの中間結果の合併を実行するステップをさらに含む、請求項2に記載の方法。

【請求項4】

前記第1のレベルのストレージ構造に関してオンデマンドミニマージまたはオンデマンド辞書作成をトリガするステップをさらに含む、請求項3に記載の方法。

【請求項5】

コンピュータにおいて実行される方法であって、
マルチレベルストレージアーキテクチャを有する統合テーブルアーキテクチャに接続された共通クエリ実行エンジンによって、データ記録を指定するクエリを受信するステップであって、前記マルチレベルストレージアーキテクチャが、受信したデータ要求をデータ記録として論理行フォーマットで格納するための第1のレベルのストレージ構造、前記データ記録を論理列フォーマットで符号化および格納するための第2のレベルのストレージ構造、および長期的に格納するために、前記符号化されたデータ記録を圧縮および格納するためのメインストアを有する、ステップと、
前記共通クエリ実行エンジンによって、前記第1のレベルのストレージ構造における前記クエリに基づいて、前記データ記録に関するルックアップを実行するステップと、
前記データ記録が前記第1のレベルのストレージ構造に存在しない場合、前記共通クエリ実行エンジンによって、前記第2のレベルのストレージ構造および前記メインストアのそれぞれの中で別個のルックアップを実行するステップと
を含む方法。

【請求項6】

前記別個のルックアップが同時に実行されて、2つの中間結果を生み出す、請求項5に記載の方法。

【請求項7】

前記2つの中間結果の合併を実行するステップをさらに含む、請求項6に記載の方法。

【請求項8】

前記第1のレベルのストレージ構造に関してオンデマンドミニマージまたはオンデマンド辞書作成をトリガするステップをさらに含む、請求項7に記載の方法。

【請求項9】

少なくとも1つのプログラマブルプロセッサ、
マルチレベルストレージアーキテクチャを有する統合テーブルアーキテクチャであって、前記マルチレベルストレージアーキテクチャが、受信したデータ要求をデータ記録として論理行フォーマットで格納するための第1のレベルのストレージ構造、前記データ記録を論理列フォーマットで符号化および格納するための第2のレベルのストレージ構造、および長期的に格納するために、前記符号化されたデータ記録を圧縮および格納するためのメインストアを有する、統合テーブルアーキテクチャ、ならびに
前記少なくとも1つのプログラマブルプロセッサによって実行されたとき、前記少なくとも1つのプログラマブルプロセッサに、
前記統合テーブルアーキテクチャに接続された共通クエリ実行エンジンによって、データ記録を指定するクエリを受信するステップと、
前記共通クエリ実行エンジンによって、前記第1のレベルのストレージ構造における前記クエリに基づいて、前記データ記録に関するルックアップを実行するステップと、
前記データ記録が前記第1のレベルのストレージ構造に存在しない場合、前記共通クエリ実行エンジンによって、前記第2のレベルのストレージ構造および前記メインストアのそれぞれの中で別個のルックアップを実行するステップと
を含む動作を実行させる命令を格納した機械可読記録媒体
を備えたシステム。

【請求項10】

前記別個のルックアップが同時に実行されて、2つの中間結果を生み出す、請求項9に記載のシステム。

【請求項11】

前記動作が、前記2つの中間結果の合併を実行するステップをさらに含む、請求項10に記載のシステム。

【請求項12】

前記動作が、前記第1のレベルのストレージ構造に関してオンデマンドミニマージまたはオンデマンド辞書作成をトリガするステップをさらに含む、請求項11に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、その開示が参照により本明細書に組み込まれているFIXED STRING DICTIONARYという表題の、2012年4月30日に出願した米国仮出願第61/640,689号、およびUNIFIED TABLE USING MULTI-LEVEL STORAGE ARCHITECTUREという表題の、2012年5月11日に出願した米国仮出願第61/646,162号の米国特許法第119条による優先権を主張するものである。

【0002】

本明細書で開示される主題は、マルチレベルストレージを有する統合テーブルアーキテクチャ(unified table architecture)を使用したインメモリデータベースのデータ管理に関し、より詳細には、統合クエリ処理のためのシステムおよび方法に関する。

【背景技術】

【0003】

現代のビジネスアプリケーションにおけるデータ管理は、今日のソフトウェア業界において最も困難な課題のうちの1つである。データは今日のビジネスを促進しているだけでなく、新規性のあるビジネスアイディアまたはビジネスケースを構築するための土台も提供する。データ管理は、あらゆる異なる特色の点で、すべての組織にとって主要な資産になっている。また、データ管理は、現在のビジネスを促進および発展させるための主要手段として、上級経営管理層でかなりの注目を集めている。システムの側面で、データ管理シナリオは、管理するには極めて複合的かつ複雑なものになった。効果的で、柔軟、頑強、かつ費用効率が高いデータ管理層は、今日のビジネス環境において、いくつかの異なるアプリケーションシナリオのコアである。

【0004】

当初、典型的な企業資源計画(enterprise resource planning: ERP)システムは、そのようなアプリケーションシナリオに対処する情報処理バックボーンとして実施された。データベースシステムの観点から、ERPシステムのオンライントランザクション処理(online transaction processing: OLTP)作業量は、通常、数千人の同時ユーザと、高い更新負荷および非常に選択的なポイントクエリを伴うトランザクションとに対処することを必要とする。他方で、通常、OLTPの相対物と見なされるデータウェアハウスシステムは、膨大な量のデータに関して集約クエリを実行するか、またはデータベース内に格納されたアーティファクトを解析するための統計モデルを計算する。残念ながら、データストリーム内の異常またはETLタスク/情報統合タスクを識別するためのリアルタイム解析などのアプリケーションは、現代のビジネスアプリケーションの文脈で、非常に多様な様々な、場合によっては、絶対的に困難な要件をデータ管理層に加える。

【0005】

従来のデータベース管理システムは、もはや、様々な異なる要件に関して全体的な回答を表すことができないと主張している人もいる。特定の問題に関する特化システムが出現するであろう。現在、大規模なデータ管理ソリューションは、異なるアプリケーションシナリオ用の異なる機能を備えた異なるシステムの混在であると通常見なされる。例えば、典型的な行ストア(row-stores)が依然としてOLTP領域を支配している。記録内の論理エンティティと物理表現との間に1:1関係を維持することは、エンティティベースの相互作用モデルの場合、明らかなように思われる。列編成データ構造(Column-organized data structures)は、問い合わされた列の投影を回避して、かなり良好なデータ圧縮率を利用するために、解析領域でますます多くの注目を集めた。キーバリューストア(Key-value stores)は、「大きなデータ」量に対処するためだけでなく、手順コードに関するプラットフォームが並列で行われることを実現するためにも、商用データ管理ソリューションに影響を及ぼし始めている。加えて、安価なストレージ機構と、クラウドのような弾性のための柔軟な並列性とを提供する分散型ファイルシステムは、キーバリューストアをデータ管理アリーナの第一級市民にした。システム過多は、トリプルストア(triple stores)によって完成され、スキーマフレキシブルデータ(schema-flexible data)とグラフベースの編成とに対処する。スキーマはデータが伴うため、システムは、エンティティ間の明示的にモデル化された関係を利用し、解析的なグラフアルゴリズムを実行し、一般に、弱く型付けされた(weakly-typed)エンティティ用のリポジトリを示すための効率的な手段を提供する。

【0006】

特化システムは、パフォーマンスに焦点を当てる最初の試みでは賢明な戦略と見なされるが、システム過多は、異なるシステムをリンクするため、データの複製作業および伝搬作業を実行するため、または複数のシステムを介してクエリシナリオを編成するためには途方もない複雑さを生み出す。加えて、そのような環境をセットアップして、維持することは、複雑、かつエラーを起こし易いだけでなく、かなり高い総所有コスト(total cost of ownership: TCO)ももたらす。ハイレベルな観点から、現在の状況の根本的な誘因を以下のように観察することができる。

【0007】

使用観点:SQLは、もはや、現代のビジネスアプリケーションに関する唯一の適切な相互作用モデルとは見なされていない。ユーザは、アプリケーション層によって完全に遮蔽されているか、または自らのデータベースと直接的に相互作用することを望む。第1の事例では、密結合機構を用いてアプリケーション層を最適にサポートする必要がある。第2の事例では、特定のアプリケーション領域に関する内蔵型データベース特徴を備えたスクリプト言語が必要である。包括的なサポート領域特定言語および所有権を主張できるクエリ言語、ならびにユーザがプログラミングの観点から並列性に直接対処するのを可能にするための機構に対する大きな需要も必要とされている。

【0008】

コスト意識:異なるタイプの作業量および使用パターンに関して統合されたソリューションを提供することによって、ハードウェアからセットアップに至るまでのコストから、運営および保守コストに及ぶ、完全なデータ管理スタックに関するより低いTCOソリューションを提供することに対する明らかな需要が存在する。

【0009】

パフォーマンス:パフォーマンスは、特化システムを使用するための主な理由と識別され続けている。課題は、可能なとき、および必要なときはいつでも、特化演算子またはデータ構造を使用するための能力を備えた柔軟なソリューションを提供することである。

【0010】

様々な作業量特性は特化システムの混在を使用することを十分に正当化しない。ビジネスアプリケーションに対処する当発明者らの過去の経験は、特化演算子群の必要性に関する仮説を支持させるに至った。別個のライフサイクルおよび管理セットアップを備えた個々のシステムに対する偏見が存在する。しかし、単一の閉鎖型システムを提供することはあまりにも限界があり、代わりに、一般的なサービスプリミティブ(service primitives)を備えた、柔軟なデータ管理プラットフォームが好ましい。

【0011】

主に解析DWH作業量の読取りをサポートすることによる大量のトランザクション処理から、ストリーム処理領域の高い更新シナリオに及ぶ様々な作業量特性は、特化システムの混在を選択することを十分に正当化しない。ビジネスアプリケーションに対処する経験は、特化演算子群を必要とさせる。

【発明の概要】

【発明が解決しようとする課題】

【0012】

純粋なデータ処理パフォーマンスに加えて、アプリケーション層とデータ管理層との間に適切な結合機構が欠如していることは、最新システムの主な欠点のうちの1つと識別されている。さらに、別個のライフサイクルと管理セットアップとを備えた個々のシステムは、セットアップと管理とがより困難であるのに対して、単一の閉鎖型システムは一般にあまりにも限界がある。必要とされるのは、一方で、一般的なサービスプリミティブを備え、他方で、個々のクエリ実行ランタイム環境を備えた、柔軟なデータ管理プラットフォームである。

【課題を解決するための手段】

【0013】

本書は、インメモリデータベースプラットフォームを説明し、異なるトランザクション作業量に対処するデータ管理のいくつかの特定の態様の詳細を説明する。

【0014】

一態様では、インメモリコンピューティングシステムの統合テーブルアーキテクチャを提供するステップを含むシステムおよび方法が提供される。統合テーブルアーキテクチャは、着信データ要求をデータ記録として論理行フォーマットで格納するための第1のレベルのストレージ構造と、データ記録を論理列フォーマットで符号化および格納するための第2のレベルのストレージ構造と、長期的に格納するために、符号化されたデータ記録を圧縮および格納するためのメインストアとを有するマルチレベルストレージアーキテクチャを含む。

【0015】

このシステムは、クエリ処理の方法を実行し、この方法は、統合テーブルアーキテクチャに接続された共通クエリ実行エンジンによって、データ記録を指定するクエリを受信するステップを含む。この方法は、共通クエリ実行エンジンによって、第1のレベルのストレージ構造におけるクエリに基づいて、そのデータ記録に関するルックアップを実行するステップをさらに含む。そのデータ記録が第1のレベルのストレージ構造に存在しない場合、この方法は、共通クエリ実行エンジンによって、第2のレベルのストレージ構造およびメインストアのそれぞれの中で別個のルックアップを実行するステップを含む。

【0016】

本主題の実装形態は、説明される1つまたは複数の特徴を含むシステムおよび方法、ならびに1つまたは複数の機械(例えば、コンピュータなど)に本明細書で説明される動作を結果的に引き起こさせるように動作可能な有形に実施された機械可読媒体を備える物品を含むことが可能であるが、これらに限定されない。同様に、1つまたは複数のプロセッサと、1つまたは複数のプロセッサに結合された1つまたは複数のメモリとを含むことが可能なコンピュータシステムも説明される。コンピュータ可読記憶媒体を含みうるメモリは、1つまたは複数のプロセッサに本明細書で説明される動作のうちの1つまたは複数を実行させる、1つまたは複数のプログラムを含むこと、符号化すること、格納することなどが可能である。本主題の1つまたは複数の実装形態と一致するコンピュータ実施方法は、単一のコンピューティングシステム内または複数のコンピューティングシステム内に常駐する1つもしくは複数のデータプロセッサによって実施可能である。そのような複数のコンピューティングシステムは、接続可能であり、ネットワーク(例えば、インターネット、ワイヤレス広域ネットワーク、ローカルエリアネットワーク、広域ネットワーク、有線ネットワークなど)を介した接続、複数のコンピューティングシステムのうちの1つもしくは複数同士の間の直接接続を経由した接続などを含むが、これらに限定されない、1つもしくは複数の接続を介して、データおよび/またはコマンド、あるいはその他の命令などを交換することが可能である。

【0017】

本明細書で説明される主題の1つまたは複数の変形形態の詳細が添付の図面および下の説明に記載される。本明細書で説明される主題のその他の特徴および利点は、説明および図面から、かつ請求項から明らかになるであろう。現在開示されている主題のいくつかの特徴は企業リソースソフトウェアシステムまたはその他のビジネスソフトウェアソリューションもしくはビジネスソフトウェアアーキテクチャに関して例示のために説明されるが、そのような特徴は限定的であることが意図されない点を容易に理解されたい。この開示に続く請求項は、保護される主題の範囲を規定することが意図される。

【0018】

本明細書内に組み込まれ、本明細書の一部を構成する添付の図面は、本明細書で開示される主題のいくつかの態様を示し、明細書と共に、開示される実装形態に関連する原理のうちのいくつかを説明するのに役立つ。

【図面の簡単な説明】

【0019】

【図1】本主題の実装形態と一致する特徴を示すシステムの態様を例示する概略図である。

【図2】本主題の実装形態によるシステムと共に使用するためのデータベース階層アーキテクチャを例示する図である。

【図3】計算モデルグラフを例示する図である。

【図4】統合テーブルストレージアーキテクチャを例示する図である。

【図5】統合テーブルの永続性機構およびセーブポイント(savepoint)機構の概要を示す図である。

【図6】統合テーブルを使用したデルタマージプロセスを例示する図である。

【図7】統合テーブルを使用した別のマージ動作を例示する図である。

【図8】再順序付けとのマージを例示する図である。

【図9】部分的マージ動作を例示する図である。

【図10】統合テーブルの能動メインメモリおよび受動メインメモリに関する範囲クエリ実行を例示する図である。

【図11】本主題の実装形態によるデータベース記録ライフサイクルを例示する図である。

【図12】L2メモリ内またはメインメモリ内のデータに関する削除動作を例示する図である。

【発明を実施するための形態】

【0020】

可能な限り、類似の参照番号は、類似の構造、特徴、または要素を示す。

【0021】

図1は、(以下で、時として、ある例として交換可能に使用される)SAPのHANAデータベースなど、インメモリデータベースシステム(in-memory database system: IMDS)102を有する、データベースシステム100を示す。IMDS102は、インメモリデータベース104と、十分に構造化されたリレーショナルデータから、不規則に構造化されたデータグラフ、非構造化テキストデータに至るまで様々な構造度のデータをサポートする様々なデータ抽象化を提供するマルチエンジンクエリ処理環境とを含む。処理エンジンのこの完全なスペクトルは、様々なタイプのデータの相互運用性および結合を可能にするための基礎的な物理データ表現など、共通テーブル抽象化に基づく。例示的な実装形態では、インメモリデータベースシステム102は、それぞれ、ビジネススイート設計環境120と、ビジネスウェアハウス設計環境122と、第三者設計環境124とインターフェースを取ることが可能なリアルタイム複製サービス108およびデータサービス110をさらに含む。

【0022】

IMDS102は、(OLAPキューブおよび領域特定機能ライブラリなど)特定用途向けビジネスオブジェクト112ならびに論理の表現をデータベースエンジン内で直接サポートする。これは、アプリケーションセマンティックスと、クエリ表現性を増大させ、個々のアプリケーションとデータベースとの間の往復数を削減し、データベース104とアプリケーション114、116との間で転送されるデータの量を削減するために利用されうる基礎的なデータ管理プラットフォームとの交換を可能にする。

【0023】

IMDS102は、一方で、所有権を主張できるアプリケーションサーバとの共有メモリ通信を提供し、他方で、データタイプをデータ管理層内でネイティブに(natively)直接的にサポートすることによって、データベースとアプリケーション層(すなわち、所有権を主張できるアプリケーション114、第三者アプリケーション116、およびビジネスウェアハウスアプリケーション118)との間で効率的に通信することができる。加えて、アプリケーションサーバ技術は、データベースシステムクラスタインフラストラクチャ内に直接的に統合されて、アプリケーション論理およびデータベース管理機能性の複雑な実行を可能にする。

【0024】

データベースシステム100は、高度に最適化された列指向データ表現を活用して、同じ物理データベース上でトランザクション作業量と解析作業量の両方の効率的な処理もサポートする。これは、洗練されたマルチステップ記録ライフサイクル管理手法によって達成される。

【0025】

IMDS102は、データ解析シナリオに関して準備が整ったパッケージを生み出すために、様々なコンポーネントを備えたアプライアンスモデルからなる。いくつかの実装形態では、IMDS102は、ビジネスウェアハウス(BW)システム122にネイティブサポートを提供して、クエリシナリオと変換シナリオとをかなり加速させるが、個々の実現化ステップを完全に省くことも可能にする。この機能を提供するために、IMDS102は、IMDS102を行き来する複雑なデータフローを生み出して、それらを維持するための、データローディングツールおよび変換ツールにモデリングスタジオ106を加えたものを有する。データベースシステム102は、効率的かつ柔軟なデータ格納シナリオとデータ問合せシナリオとを提供する。

【0026】

データベースシステム102は、図2に例示される厳密に階層化されたアーキテクチャに従う。典型的なシステムと同様に、データベースシステム102は、データベース要求のコンパイル時間202とランタイム204とを区別する。また、図2に示されないが、トランザクションマネージャ、許可マネージャ、メタデータマネージャなど、その他のコンポーネントがアーキテクチャ全体を補完することができる。

【0027】

図2に見られるように、様々なクエリ言語206は、外界とのすべてのインフラストラクチャタスクを実行する(JDBCコネクタ、ODBCコネクタなど)共通の接続およびセッション管理層208を経由してシステムに入ることができる。第1のステップで、クエリ文字列は、言語解決エンジン210によって、すべての領域特定言語にとって局所的な(抽象構文木に類似した)内部最適化表現に変換される。第2のステップで、クエリ表現は、計算グラフマッピングエンジン212によって、その構造および動作が下でさらに詳細に説明される、1つまたは複数のカスタマ特定インメモリデータベース218を含めて、IMDSに関する分散型実行フレームワーク216の一部として論理クエリ処理フレームワークの核心を形成する計算グラフ214にマッピングされる。

【0028】

計算グラフモデル

【0029】

計算グラフモデルは、典型的なデータフローグラフ原理に大まかに従う。ソースノードは永続性テーブル構造またはその他の計算グラフの結果を表している。内部ノードは、1つまたは複数の着信データフローを消費する論理演算子を反映し、何らかの任意数の発信データフローを生み出す。さらに、計算グラフ演算子のセットは、2つのグループの演算子タイプに分割可能である。一方で、計算モードは、例えば、集約、投影、結合、合併など、固有演算子のセットを規定する。SQLは、例えば、このクラスの演算子に完全にマッピングされうる。他方で、計算モデルは、通貨換算またはカレンダー機能性などの主要ビジネスアルゴリズムを実施する演算子を提供する。最終的に、計算モデルは、以下のタイプの演算子をサポートする。

【0030】

SQLノード:計算モデル演算子は、着信データフローに関して完全なSQLステートメントを実行することができる。このステートメントは、パラメータであってよく、計算グラフのランタイムにコンパイルおよび実行可能であり、結果として、「入れ子状の計算」モデル形態をもたらす。

【0031】

カスタムノード:カスタムノードは、パフォーマンスのために、領域特定演算子をC++で実施するために使用可能である。例えば、FOXなど、SAP所有権を主張できる言語を有する計画シナリオは、財政計画状況をネイティブにサポートするために、特別な「集約解除」演算子を利用することができる。その他の例は、所有権を主張できるWIPEグラフ言語によるデータグラフ内のグラフ探索およびグラフ解析のための最適化された動作である。

【0032】

Rノード:Rノードは、着信データセットをR実行環境に転送するために使用可能である。次いで、パラメータとして与えられるRスクリプトが、データベースシステムの外部で実行されることになり、結果はさらなる処理のために計算グラフに戻される。

【0033】

Lノード:言語Lは、データベースシステムの内部ランタイム言語を表す。Lは、C言語の安全なサブセットとして設計され、通常、エンドユーザまたはアプリケーションデザイナにとって直接アクセス可能でない。それよりむしろ、Lは、データフローグラフに直接的にマッピング可能でない領域特定言語のすべての構造体、すなわち、あらゆる種類の命令型制御論理用の目標言語である。

【0034】

機能演算子のセットに加えて、計算モデルは、アプリケーション規定データ並列化を可能にするための基本構造体としてデータフローのパーティションを動的に規定して、再分布するために、「分離」演算子と「結合」演算子とを提供する。異なる領域特定言語の個々のコンパイラは、所与のクエリスクリプトから計算グラフへのマッピングの最適化を試みる。SQLの場合、このマッピングは、クエリ表現の明確に規定された論理表現に基づく。一般的な事例では、このマッピングは、入力データの推定サイズなどに応じて、発見的問題解決ベースであってよく、またはコストベースであってもよい。例えば、コンパイラは、ループを正規データフローグラフに展開する(unroll)こと、または特定表現に関してLコードを生成することを決定できる。間違いなく最大かつ最も複雑な部分であり、SAPのP^*Time1システムなどのメインメモリ行指向リレーショナルデータベースシステムから得られる正規SQLの場合、内部表現は、SQLステートメントの意図を捕捉するために事前規定されたセマンティックスを備えた演算子だけを表す計算グラフに直接的にマッピングされる。

【0035】

サンプルの計算モデルグラフ300が図3に示される。計算モデルは、個々の領域特定言語のコンパイラを経由して間接的に作成されるか、またはデータベーススタジオ内で視覚的にモデル化されて、データベースシステムのメタデータリポジトリ内に計算ビューとして登録されうる。このプロセスの裏にある全体的な発想は、実際のクエリ言語とは無関係に、複数のデータベースシナリオにおいて微調整されて、再使用されうる複合ビジネスロジックシナリオの特定の断片をカスタマイズすること、すなわち、計算モデルが仮想テーブルの形で任意の領域特定言語スタックから消費されうることである。計算モデルの収集物は、データベースシステムコンテンツとも呼ばれ、別個の製品ライフサイクルプロセスをたどる。図3に示される計算モデルグラフ300は、リレーショナルデータベースシステム内の正規クエリプランに関する差異のうちのいくつかを概説する。例えば、演算子の結果は、複数の消費者にアプリケーションの観点からすでに共有される共通部分式に関して最適化させることができる。第2に、「スクリプト」とラベル付けされたノードは、計算モデルデザイナまたは領域特定クエリコンパイラによって生成されたシステムから入る命令型言語スニペットをラップする(wraps)。加えて、ノード「conv」は、特定用途向け変換ルーチン、例えば、通貨換算または単位換算を実行するための内蔵型ビジネス機能の使用を示す。

【0036】

計算グラフのコンパイルおよび実行

【0037】

ユーザ規定クエリ表現、またはユーザ規定クエリスクリプトが計算モデル内のデータフローグラフにマッピングされると、オプティマイザは、典型的な規則およびコストベースの最適化手順を実行して、論理的プランを、次いで分散型実行フレームワークによって実行可能な物理的プランに再構成および変換する。

【0038】

実行フレームワークは、実際のデータフローと、物理演算子の分散型実行とを編成する。最適化の間に、論理データフローグラフの断片は、「エンジン層」によって提供される物理演算子にマッピングされる。エンジン層自体は、グローバルプランの断片を実際の物理演算子の詳細に適合するための何らかの局所的最適化論理を備えた異なる物理演算子の収集物からなる。詳細には、データベースシステムは、演算子の以下のセットを提供する。

【0039】

関係演算子:関係演算子の収集物は、典型的な関係クエリグラフ処理に対処する。より詳細に説明されるように、関係演算子は、異なる特徴を示し、例えば、等結合(equi-join)などの演算子のうちのいくつかは、統合テーブルの既存の辞書を直接活用する。

【0040】

OLAP演算子:OLAP演算子は、ファクトテーブルとディメンションテーブルとを用いたスタージョイン(star join)シナリオ用に最適化される。オプティマイザがこのタイプのシナリオを認識すると、対応するコスト推定を有する実行可能な物理プランとして、対応するクエリプラン断片のOLAP演算子に対するマッピングがエニュメレートされる(enumelated)。

【0041】

Lランタイム:内部言語L用のランタイムは、所与の計算グラフのLノード内に表されるLコードを実行するための構成単位を反映する。「分割および結合」演算子ペアを使用して、Lランタイムは事前規定されたパーティションに関する並列作業の際に起動可能である。

【0042】

テキスト演算子:テキスト検索解析演算子のセットは、SAP Enterprise Search製品など、いくつかの製品においてすでに利用可能な、類似性測定からエンティティ解決機能に及ぶ包括的なテキスト解析特徴を実現するための機能性のセットを備える。

【0043】

グラフ演算子:グラフ演算子は、複合リソース計画シナリオまたはソーシャルネットワーク解析タスクを効率的に実施するためのグラフベースのアルゴリズムに関するサポートを提供する。

【0044】

データフローグラフは、(通常、異なる物理ノード上で実行する)複数のサーバインスタンス間だけでなく、異なるタイプの演算子間でも分布されるため、このシステムは、最適なデータ転送および交換フォーマット用のツールのセットを提供する。すべての演算子は標準データ転送プロトコルを実施することが必要とされるが、異なる「収集物」内の演算子または異なる「収集物」を超えた個々の演算子は、高度に特殊化された通信プロトコルを有する場合がある。例えば、関係演算子およびOLAP演算子は、高度に圧縮された、所有権を主張できるフォーマットでデータを交換している。また、Rノードは、R内部データフレームフォーマットに対するマッピングを提供する。

【0045】

異なる物理演算子間の「水平」通信に加えて、これらの演算子は、統合テーブル層に対する共通インターフェースも利用する。以下の項でより詳細に概説されるように、データベースシステムは、異なる演算子に関する様々なアクセス方法を有する抽象表形式ビューを提供する。共通表形式構造は、データエンティティの完全なライフサイクルを実施し、基本的に、最近の修正動作の効果を捕捉するための行ストアと列ストアの結合からなる。データベースシステム内のテーブルは「履歴」とマーキング可能であるため、テーブル層は、アクティブなエンティティの過去の値を捕捉する履歴テーブルの実装形態も提供し、タイムトラベルクエリに関するアクセス方法も提供する。

【0046】

いくつかの実装形態では、データベースシステムは、メインメモリ内に捕捉されたデータベース状態が損失した場合、回復可能性を提供するために永続層に依存する。永続層は、可変サイズのページを用いた仮想ファイル概念に基づく。永続層は、非常に低いリソースオーバヘッドを有する、一貫したスナップショットを提供するために頻繁なセーブポイントに依存する。これらの特徴は、下でさらに詳細に説明される。

【0047】

典型的なシステムと対照的に、本明細書に一致する実装形態によるデータベースシステムは、複数の(所有権を主張できる)領域特定言語をサポートするための柔軟なプラットフォームである。柔軟なデータフローモデル(計算グラフモデル)は、システムの概念的なコアを提供する。一方で、クエリ表現、またはクエリスクリプトはモデルのインスタンスにマッピングされる。他方で、すべての異なる物理演算子は、個々の記録に関して完全なライフサイクル管理を実施する同じテーブル層インターフェースを使用している。ログエリアおよびデータエリアは、永続ストレージ内のメインメモリデータベースのトランザクション上一貫した複写を維持するために使用される。

【0048】

図4に示されるように、統合テーブル構造400は、すべての適用可能な物理演算子に関するデータアクセスを提供する。統合テーブル構造400は、個々のデータベース記録に関するライフサイクル管理を提供する。統合テーブルの技法は、走査ベースの集約クエリに関してだけでなく、非常に選択的なポイントクエリに関しても優れたパフォーマンスを提供するための鍵である。これは、従来の行ベースのデータベースアーキテクチャに主な区別要因(differentiator)を提供する。記録は、概念的に、その存続期間を通して、更新準備が整ったスタイルの(update-in-place-style)データベースシステム内に同じ位置に留まるのに対して、統合テーブル構造400は、物理表現の様々な段階を通じて記録を伝搬する。一般概念として設計されているが、最も一般的なセットアップは、下で説明されるように、正規テーブル内の記録に関する3段階からなる。

【0049】

図4に示されるように、統合テーブル構造400はL1デルタ構造402を含む。「ホットデルタ」(または、短くL1デルタ)とも呼ばれるL1デルタ構造402は、すべての着信データ要求を受け入れて、それらを書込み最適化様式で記録する。すなわち、L1デルタ構造402は、記録の論理行フォーマットを保存し、高速の挿入および削除、フィールド更新、ならびに記録投影のために最適化される。さらに、L1デルタ構造402は、データ圧縮を実行することができる。経験則として、L1デルタ構造402は、作業量特性および利用可能なメモリの量に応じて、単一のテーブルごとに10,000個から100,000個の行を保持することができる。

【0050】

統合テーブル構造400は、L2デルタ構造404をさらに含む。「コールドデルタ」(または、短くL2デルタ)とも呼ばれるL2デルタ構造404は、記録ライフサイクルの第2の段階を表し、列ストアフォーマットで組織化される。L1デルタ構造402と対照的に、L2デルタ構造404は、より良好なメモリ使用を達成するために辞書符号化を用いる。しかし、パフォーマンスのために、この辞書は、ポイントクエリアクセスパターン、例えば、一意制約チェックの高速実行を最適にサポートするための、ソートされていない必要二次索引構造である。L2デルタ構造404は、最高で1,000万個まで、またはそれ以上の行を格納するのに大変適している。

【0051】

統合テーブル構造400は、メインストア406をさらに含む。メインストア406は、最高圧縮率を有するコアデータフォーマットを表し、様々な異なる圧縮方式を利用する。デフォルト設定で、列内のすべての値は、ソートされた辞書内の位置によって表され、個々の値を密にパックできるようにビットパックされた(bit-packed)様式で格納される。辞書は様々なプレフィックス符号化方式を使用して常に圧縮されるものの、メインストアメモリフットプリントをさらに削減するために、単純なランレングス符号化方式からより複雑な圧縮技法に及ぶ様々な圧縮技法の組合せが適用される。

【0052】

統合テーブル構造400を用いるデータベースシステムは、複雑な大量のローディングシナリオを有するOLAP多用事例に関して設計され、このシステムは、L1デルタを迂回して、L2デルタに直接入ることができる効率的なバルク挿入に関する特殊処理を提供する。エントリーの場所とは無関係に、システムに入るときに、任意の着信記録に関するRowIdが生成されることになる。また、ロギングは、行の第1の出現時に、正規の更新動作/挿入動作/削除動作の場合、L1デルタ内に、またはバルクロード動作の場合、L2デルタ内に発生する。

【0053】

統合テーブルアクセス

【0054】

異なるデータ構造は、共通データタイプを共有する。このアクセスは、両方とも、オプションで辞書ベースの行および列のイテレータ(iterator)との共通抽象インターフェースを介して公開される。

【0055】

さらに、物理演算子のうちのいくつかは、パイプライン動作を可能にして、中間結果に関するメモリ要件を可能な限り削減するために従来のONCプロトコルに続いて、記録ごとに、またはベクトル化された様式で(すなわち、ブロックごとに)プルすることができる。その他の物理演算子は、「すべて実現化」戦略を実施して、クエリ実行の間の演算子切替えコストを回避する。オプティマイザは、論理計算モデルに応じて、異なるタイプの演算子の混合物を決定し、すなわち、異なるタイプの演算子は最終的なクエリ実行プラン内で継ぎ目なしに統合される。

【0056】

ソートされた辞書を活用する演算子の場合、統合テーブルアクセスインターフェースは、グローバルにソートされた辞書によってテーブルコンテンツも公開する。2つのデルタ構造の辞書が(L1デルタだけに関して)計算され、(L1デルタとL2デルタの両方に関して)ソートされ、主要な辞書とオンザフライでマージされる。一意制約の効率的な妥当性確認を実施するために、統合テーブルは、デルタ構造と主要構造とに関して逆索引を提供する。

【0057】

記録ライフサイクルは、システムのトランザクション領域(sphere)内で現在実行しているデータベース動作の制御に干渉せずに、システムを通じて個々の記録を非同期的に伝搬するような形で組織化される。現在のデータベースシステムは、「マージステップ」と呼ばれる2つの変換を実現する。

【0058】

L1デルタからL2デルタへのマージ:L1デルタからL2デルタへの変換は、行組織から列組織へのピボットステップ(pivoting step)を意味する。L1デルタの行は、その対応する列値に分割されて、列単位でL2デルタ構造内に挿入される。受信サイドで、システムは、辞書構造内で潜在的に欠けている値を識別するためのルックアップを実行し、オプションで、辞書の終端に新しいエントリーを挿入して、辞書内の任意の主な再構成動作を回避する。第2のステップで、辞書符号化(添付専用(append-only)構造)を使用して、対応する列値が値ベクトルに加えられる。ステップは両方とも並列で実行可能であるが、これは、移動されるべきタプルの数が事前に知られており、符号化を実際に挿入する前に、新しい辞書内に符号化を確保することを可能にするためである。第3のステップで、伝搬されたエントリーはL1デルタから除去される。すべての実行中の動作は、完全なL1デルタと古いデルタ終端の境界に遭遇するか、またはL2デルタの拡張バージョンと共にL1デルタ構造のトランケートされたバージョンに遭遇する。設計によって、L1デルタからL2デルタへの遷移は本質的に増分的であり、すなわち、記録の遷移は、目標構造のデータを再組織化することに関して何の影響も有さない。

【0059】

L2デルタからメインへのマージ:L2デルタおよび既存のメインから新しい主要構造が生み出される。L1デルタからL2デルタへのマージは、実行しているトランザクションに関して最小限に侵襲的であるが、L2デルタからメインへのマージはリソース集約的なタスクであり、これは慎重にスケジュールされて、物理レベルで高度に最適化されなければならない。L2デルタからメインへのマージが開始するとすぐに、現行のL2デルタは更新のために閉鎖され、新しい空のL2デルタ構造が生み出されて、L1デルタからL2デルタへのマージに関する新しい目標として機能する。マージが失敗した場合、システムは、依然として、新しいL2デルタを用いて動作し、L2デルタおよびメインの前のバージョンとのマージを再度試みる。コアアルゴリズム、ならびに列単位のマージまたは部分的マージなど、異なる最適化技法の詳細が下でさらに説明される。

【0060】

上で説明された両方のマージ動作は、テーブル内に含まれたデータに影響を及ぼさないが、テーブルは再組織化される。しかし、マージ動作は、再起動またはバックアップのログ再生に依存しない。

【0061】

永続性マッピング

【0062】

データベースシステムはメインメモリ中心データベースシステムであるが、その完全なACIDサポートは、耐久性を保証すると同様に、極小性と、正規の停止またはシステム障害の後に、システムが再起動する場合、回復とを保証する。データベースシステムの永続性は、複数の永続性概念に基づきうる。図5に見られるように、永続性500は、一時的な再実行ログ502と、短期回復または長期バックアップのためのセーブポイントデータエリア504内のセーブポインティングの組合せに基づく。

【0063】

再実行のためのロギングは、新しいデータがシステムの、L1デルタ内か、またはバルク挿入の場合はL2デルタ内に入るときに一度だけ実行される。記録の新しいバージョンは、L1デルタに入るとき、ロギングされる。L1デルタからL2デルタへの増分的な伝搬の間に発生する変更は、再実行ロギングの対象ではない。それよりむしろ、辞書内、ならびに値索引内の変更は個々のデータページ内に常駐するデータ構造内に加えられ、これらは最終的に次のセーブポイント内の永続ストレージに移される。メインのより長いデルタの古いバージョンは、マージがセーブポイントを通して存続して(persisted)いない場合、再起動時に使用可能である。マージは再組織化であるため、再起動後に、一貫したデータベースの起動を確実にするために、テーブルのコンテンツは依然として同じままである。

【0064】

図6は、永続性マッピングの動作を例示する。辞書と値索引は両方とも基礎となるストレージサブシステムによって管理されたページ化ストレージレイアウト(paged storage layout)に基づく。ダーティなページ、すなわち、追加のエントリーを有する既存のページ、または新しいページは、セーブポインティングインフラストラクチャの制御の下でストレージサブシステムによって流し出される(flushed out)。L2デルタ構造は列ごとに組織化されるが、システムは、メモリ消費用に最適化するために、単一のページ内に複数のL2デルタ列の断片を格納することができる。特に、小さいが広範なテーブルの場合、同じページ内に複数のL2デルタ列を格納することは非常に合理的でありうる。セーブポイントの後に、再実行ログはトランケート可能である。回復の間、システムはL2デルタの最後のスナップショット(セーブポイント)を再ロードし、関連するセーブポイント以来書き込まれた再実行ログエントリーを適用する。

【0065】

同様に、メインの新しいバージョンは、安定したストレージ上に存続することになり、統合テーブルのメインストアを再ロードするために使用されうる。要約すると、前のバージョンの画像が依然として存在するため、L2デルタのトランケーションもメインの変更もログ内に記録されない。典型的なロギング方式は、L1デルタに関して、およびL2デルタ内へのバルクロードに関してだけ用いられる。

【0066】

要約すると、データベースシステム内のテーブルの物理表現は、3つのレベル、すなわち、着信挿入を効率的に捕捉すると同様に、要求を更新および削除するための行ストア(L1デルタ)と、読取り最適化ストアから書込み最適化を結合解除する列フォーマット内の中間構造(L2デルタ)と、メインストア構造とからなる。この第3の構造は、OLAPのようなクエリに非常に適しているが、同時に、逆索引構造を使用することによって、ポイントクエリに効率的に応答するようにうまく調整されている。存続期間の間、記録はストレージ構造を通じて非同期的に伝搬されて、初めに、最も更新効率の高いストア内に入り、その存続期間の残りの間、最も読取り効率の高いストア内に留まることになる。

【0067】

マージ最適化

【0068】

上で説明された統合テーブル手法の主な発想は、両極端を結合解除するために、L2デルタ索引を用いて、書込み最適化ストレージ構造から読取り最適化ストレージ構造に透過的な記録伝搬を行うためである。L1デルタからL2デルタへの遷移は既存のデータ構造の大部分を乱すことなしに実行可能であるが、L2デルタおよびメインのマージは、テーブルのコンテンツの主な再組織化を必要とする。

【0069】

典型的なマージ

【0070】

典型的なマージ動作の第1のステップで、L2デルタの辞書エントリーは、メイン辞書内で辞書編集的にコンパイルされて、特定の列に関してソートされた新しいメイン辞書を生み出す。新しい辞書は、新しいメイン構造の有効エントリーだけを含み、すべての削除または修正された記録のエントリーを廃棄する。辞書のソート順序は、最適圧縮に関する必須要件を提供するだけでなく、辞書符号化された列に直接作用する特化演算子用の基礎でもある。

【0071】

図7は、マージステップの主な段階を示す。ソートされていない辞書を有するL2デルタと、ソートされた辞書を有する古いメインとに基づいて、第1の段階は、新しくソートされた辞書を生成して、(明示的に格納されていないことが明らかな)新しい位置、ならびにメイン内およびL2デルタ内の古い位置からマッピング情報を保存する。図7に見られるように、一部のエントリーは、両方の辞書内の位置(例えば、「Los Gatos」)を示すか、または一部のエントリーは、メイン辞書内もしくはL2デルタ辞書内だけに出現する(例えば、辞書位置マッピングテーブルのデルタ内の値4、メイン側に値-1を有する「Campbell」)。第2の段階で、既存のエントリーおよび新しく追加されたエントリーに関する新しい辞書を指す位置を備えた新しいメイン索引が構成される。例えば、再び図7を参照すると、「Daly City」に関するエントリーは、新しい位置値4を有する新しいメインに転送される。同様に、「Los Gatos」に関するエントリーも、L2デルタ内の位置1、および古いメイン構造内の位置5から新しい位置(このとき6)にマッピングされる。新しいメイン(辞書および値索引)がディスクに書き込まれて、古いデータ構造が解放される。いずれの場合も、依然として古いバージョンを指すオープントランザクションのすべてのデータベース動作がその実行を終えるまで、システムは、列の古いバージョンおよび新しいバージョン(辞書およびメイン索引)をメインメモリ内に維持しなければならない。

【0072】

マージの基本的なバージョンは非常にリソース集約的であるため、データベースシステムはいくつかの異なる最適化を実施する。例えば、L2デルタの辞書がメイン辞書のサブセットである場合、辞書生成の第1の段階は省略され、結果として、メインエントリーの安定位置をもたらす。L2デルタ辞書の値がメイン辞書内の値を超える場合、例えば、タイムスタンプの増大が存在する場合、もう1つの特別事例が存在する。この状況において、辞書値を符号化するためのビット数が基数の拡張に対処するために十分である場合、L2デルタの辞書はメイン辞書に直接追加されうる。より複雑な最適化を再ソートマージ戦略および部分的マージ戦略の直交技法に見ることができる。これらの技法は両方とも下でより詳細に概説される。

【0073】

再ソートマージ

【0074】

L2デルタとメインの間のマージの典型的なバージョンは、辞書エントリーの前の位置を新しい辞書の新しい位置にマッピングすることを必要とする。これらの位置は、次いで、ビットパックされた値索引内の実値を符号化し、すなわち、列の別個の値の数としてCを用いて、システムは、それらの位置を符号化するために[log₂(C)]、すなわち多くのビットを費やす。このマージは、古いメイン値を(同じ数のビットまたは増大した数のビットを有する)新しい辞書位置にマッピングして、L2デルタのエントリーを新しい値索引の終端に追加する。

【0075】

マージの拡張バージョンは、全テーブルのコンテンツを再組織化して、すべての列のデータ分布に関してより高い圧縮可能性を提供するデータレイアウトを生み出すことを目的とする。データベースシステム列ストアは位置アドレス指定方式を利用するため、第k番目の記録の値はすべての列内の第k番目の位置になければならない。最適な圧縮方式を得るために1つの列を再ソートすることは、したがって、テーブル内のすべての他の列の圧縮可能性に直接影響を及ぼす。システムは、新しいメインを作成する前に、メイン構造およびL2デルタ構造からの統計に基づいて、列の「最善の」ソート順序を計算する。

【0076】

図8は、必要なデータ構造を示す。古い辞書位置を新しい辞書内の位置に変換するための辞書用マッピングテーブルに加えて、再ソートマージのバージョンは、個々の列をマージおよび再ソートした後に、行を再構成することができるように行位置のマッピングテーブルをさらに作成する。図8は、マージプロセスの前とマージプロセス中の同じテーブルの列を示し、この場合、列「都市」および「Prod」はすでにマージされており、残りの列(例えば、「時間」など)は、マージの前の状態を依然として反映している。したがって、メインの古いバージョンのエントリーは、古い辞書内の位置に対応し、例えば、「都市」列のエントリー「Los Gatos」は古い辞書の値5と、マージの後のバージョン内の6とを用いて符号化される。したがって、一般に、マージを「都市」列に適用した後で、新しいメイン索引は、新しい辞書の辞書位置、ならびに行の再ソートを示す。

【0077】

例示されるように、第7番目の行を、このとき第2の位置に見出すことができる。「Prod」列も、新しい辞書を構築せずに、マージされており、例えば、辞書位置値が保存される。しかし、「時間」列はまだマージされておらず、依然として、古い辞書と古いソート順序とを指す。すでにマージされた列を有する行構築が必要とされる場合、まだマージされていない列に対するいずれのアクセスも、行位置マッピングテーブルを通して追加の間接ステップを取ることが必要とされる。行位置マッピングテーブルは、すべての列のマージが完了した後で除去されうる。システムは、行位置マッピングテーブルを「積み重ねる」ことによって、アクセスされる頻度が低い列のマージを概念的に遅延させることができるが、システムは、新しいマージ生成を開始する前に、常に、全テーブルに関するマージ動作を完全に完了する。再ソートマージを適用することは、したがって、すべての列に関するマージの間に、列アクセスに関する追加の位置マッピングのオーバヘッドと、結果として生じるより高い圧縮率の可能性との平衡を保つためのコストベースの決定である。個々の列にマージを適用するためのソート基準は、複数の要因、例えば、ポイントアクセスと範囲アクセスの比率、圧縮可能性の改善にも依存する。

【0078】

部分的マージ

【0079】

典型的なマージまたは再ソートマージの主な欠点は、メインの新しいバージョンを作成するためのオーバヘッド全体である。大きなテーブルまたはパーティションの場合、新しい辞書を計算して、メイン索引を再度生成することは、利用可能なCPUリソースとディスクリソースに悪影響を及ぼす。部分的マージは、前のアルゴリズムを一般化することによって、この問題の緩和を試みる。部分的マージ戦略は、飽和列に関して、すなわち、辞書内の新しいエントリーの数が少ない状況で、最善の可能性を示す。

【0080】

部分的マージは、メインを2つの(または、2つを超える)独立メイン構造に分割するように構成される。

【0081】

受動メイン:受動メインは、一般に、マージプロセスの一部ではない、メインストアの安定部分を反映する。

【0082】

能動メイン:能動メインは、動的に伸縮し、L2デルタを用いたマージプロセスに加わる列の一部である。

【0083】

いくつかの実装形態では、部分的マージ戦略内のマージ間隔は、空の能動メインから始まる。受動メインは、ソートされた辞書と対応する値索引とを備えた正規メイン構造を反映する。マージ動作がスケジュールされるときはいつでも、L2デルタは(依然として空の)能動メインとマージし、受動メインはそのままの状態に留まる。完全マージと比較して、部分的マージは1つの小さな例外を示す。能動メインの辞書は、n+1の辞書位置値から始まり、式中、nは、受動メイン辞書の基数である。システムは、このとき、局所的にソートされた辞書を備えた2つのメイン構造を有するが、個々のメイン値索引構造の符号化は重複していない。能動メインの辞書は、受動メインの辞書内にまだ存在しない新しい値だけを保持する。

【0084】

図10は、部分的マージの後の受動メインおよび能動メインのサンプル状況を示す。能動メインの辞書コードは、受動メインの符号化方式が続くように、符号化値n+1=6から始まる。受動メインの対応する値索引構造は受動メイン辞書内のエントリーに対する参照だけを保持するのに対して、能動メインの値索引は受動メインの符号化値を示すことも可能であり、能動メイン辞書を受動メイン辞書に依存させる。

【0085】

ポイントアクセスは、受動的辞書内で解決される。要求される値が見出された場合、受動メイン値索引と能動メイン値索引の両方に関する符号化値として、対応する位置が使用される。並列走査は対応するエントリーを見出すために実行される。しかし、要求された値が見出されない場合、能動メインの辞書が閲覧される。値が存在する場合、結果として生じる行位置を識別するために、能動メイン値索引だけが走査される。範囲アクセスの場合、これらの範囲は両方の辞書内で解決され、両方の構造に関して範囲走査が実行される。能動メインの場合、走査は、一方は受動的辞書の符号化範囲値に関し、もう一方は能動メイン辞書の符号化範囲に関する、2つの部分範囲に分割される。図10は、C%とL%との間の値を用いた範囲クエリに関してこの動きを例示する。トランザクションの一貫性を保証するために、クエリ処理は、LIデルタおよびL2デルタとの類似のマージをさらに必要とする。

【0086】

システムが動作している間、能動メインは、完全マージがスケジュールされるまで、動的に伸縮することができる。この概念の主な利点は、低い処理負荷を伴う状況まで完全マージを遅延させて、L2の(能動)メインへのマージのコストを削減することである。また、能動メインの最大サイズを0に設定して、すべてのステップで(典型的な)完全マージを余儀なくすることによって、典型的なマージ方式として最適化戦略を展開することが可能である。この手順は、局所辞書の依存性に関して論理チェーンを形成する複数の受動メイン構造に拡張可能である。この構成は、ゆっくり変化する辞書または安定な辞書を有する列(例えば、「カスタマ」テーブル内の「国」列)に適している。しかし、列の大部分に関して、このシステムは、1つの受動メインだけを保持することになる。

【0087】

部分的マージ最適化戦略は、データベースシステム統合テーブル概念の一般的な記録ライフサイクル内で追加のステップを実施する。パイプラインの終端に近ければ近いほど、ますます複雑で、ますます時間とリソースを消費する再組織化が記録に適用され、最終的に、従来の列ストアの高度に圧縮されて、読取り最適化されたフォーマットで終わる。加えて、データベースシステムは、記録の前のバージョンを別個のテーブル構造体に透過的に移すために履歴テーブルの概念を提供する。しかし、テーブルは、作成時間の間に「履歴」タイプのものと規定されなければならない。さらに、アプリケーションの観点から、最近のデータセットをより安定したデータセットから分離するために、パーティションで区切る機能性が使用されうる。

【0088】

上で説明されたように、データベースシステムは、トランザクション作業量および解析作業量に効率的なアクセスを提供するために、記録ライフサイクル管理の発想を利用する。図11は、議論されたストレージフォーマットおよび伝搬ステップの様々な特性を明らかにする。L1デルタは、更新集約的な作業量に関して最適化されて、増分的かつ頻繁に、L2デルタ構造にマージされうる。L2デルタ構造は、読取り動作に関してすでに良好に調整されているが、高度に読取り最適化されたメイン構造と比較して、より大きなメモリフットプリントを必要とする。しかし、L2デルタは、L1デルタ行またはバルク挿入の目標として特に良好に機能する。すでに議論されたように、オプションで能動部分と受動部分とに分割されたメインは、最高の圧縮率を示し、走査ベースのクエリパターン用に最適化される。リソース集約的な再組織化タスクにより、能動メインへのマージ、特に、新しいメイン構造を作成するための完全マージは非常に低い頻度でスケジュールされる。L1デルタからL2デルタへのマージは、対照的に、データをL2デルタ辞書と値索引とに添付することによって、増分的に実行可能である。

【0089】

図12は、インメモリコンピューティングシステムの統合テーブルアーキテクチャのL2デルタメモリ604内またはメインメモリ606内のデータに関する動作600を例示する。上で議論されたように、統合テーブルアーキテクチャは、共通クエリ実行エンジン601からの着信データ要求をデータ記録として論理行フォーマットで格納する第1のレベルのストレージ602(L1デルタストレージ)構造を含むマルチレベルストレージアーキテクチャを有する。統合テーブルアーキテクチャは、データ記録を論理列フォーマットで符号化および格納する第2のレベルのストレージ604(L2デルタストレージ)構造と、長期的に格納するために、符号化されたデータ記録を圧縮および格納するためのメインストア606とをさらに含む。

【0090】

データ記録は行IDによって規定される。データ記録の削除動作は、その行IDを使用して、テーブル内のデータ記録に関するルックアップを実行するステップを含む。ルックアップは、まずL1デルタ内で実行される。文書識別子がL1デルタストレージ内に見出されない場合、ルックアップはL2デルタストレージ内で実行される。文書識別子がL2デルタ内に見出されない場合、ルックアップはメインストア内で実行される。行の位置が判断されていないとき、L1デルタ、L2デルタ、またはメインストレージに関するそれぞれの可視性情報は、削除されたとして行をマーキングするような形で修正される。テーブルの様々な部分は、可視行のビットマップおよびトランザクション特定のデルタビットマップのセット、または記録ごとの削除タイムスタンプなど、異なる可視性情報構造を使用することができる。可視性情報が適切に修正された後で、再実行ログエントリーがデータベースの再実行ログ内に書き込まれて、取消ログエントリーがトランザクションの取消ログ内に書き込まれる。トランザクションが確定する(commits)場合、削除された行を潜在的に読み取る一貫性のあるビューが存在しないとき、その取消エントリーは廃棄されて、削除された行のデータスペースはマージ動作の間に取り戻される。トランザクションが中断される場合、その変更を可視性情報にロールバックするための取消動作が実行される。

【0091】

データ記録の更新は、記録の新しいバージョンの挿入と記録の現在のバージョンの削除の組合せによって実現されうる。これは、記録がL2デルタ内またはメインストア内にすでに位置している場合である。記録がL1デルタストア内に位置する場合、記録は、まずその記録を追加のバージョンスペース内で実現し、次いで、バージョンスペースからのバージョンをL1デルタストアに戻して統合することによってその場で更新可能である。圧縮されていないことに加えて、これはL1デルタの主な利点のうちの1つである。更新はその場で行われるため、非キー更新のために二次索引を更新する必要はない。

【0092】

この場合、記録の行IDは、更新動作を通じて変更してよく、または変更しなくてもよい。L2デルタ内およびメイン内の更新は、更新された記録に関して新しいRowIDを常に生成する。新しいバージョンはL1デルタ内に配置される。この場合も、再実行ログエントリーはデータベースの再実行ログに書き込まれ、取消ログエントリーはトランザクションの取消ログ内に書き込まれる。この場合、トランザクションのロールバック(取消動作を実行すること)は、新しい行バージョンおよび古い行バージョンの可視性情報を単に適切にマーキングすること(L2デルタ内またはメイン内の更新)になるか、または、新しいバージョンをバージョンスペースから除去すること(L1デルタの更新)になる。

【0093】

図12は、マルチレベルストレージアーキテクチャ1000上の統合テーブルクエリ処理を例示する。クエリは、それぞれのクエリを処理して、L1デルタデータ1004上、L2デルタデータ1006上、およびメインデータ1008上のクエリに基づいてルックアップを実行する共通クエリ実行エンジン1002によって受信される。これらのクエリは、マルチレベルストレージが適した任意のタイプのアプリケーションに関して処理および構文解析可能である。一実装形態では、第1のクエリタイプに関して、共通クエリ実行エンジン1000は、L1デルタ1004だけに関してまずルックアップを実行する。要求されたデータがL1デルタデータ1004に存在しない場合、共通クエリ実行エンジン1002は、マルチレベルストレージアーキテクチャ1000のL2デルタデータ1006およびメインデータ1008の両方の中で別個にルックアップを実行する。

【0094】

いくつかの実装形態では、第2のクエリタイプに関して、共通クエリ実行エンジン1000は、ルックアップをL1デルタデータ1004に関してまず実行し、次いで、L2デルタデータ1006とメインデータ1008の両方において並列で同時に実行する。共通クエリ実行エンジン1000は、次いで、そのクエリの中間結果を合併させることができる。第2のクエリタイプが成功しなかった場合、共通クエリ実行エンジン1000は、L1デルタ1004に関して、オンデマンドミニマージまたはオンデマンド辞書作成をトリガすることができる。

【0095】

本明細書で説明された主題の1つもしくは複数の態様または特徴は、デジタル電子回路、集積回路、特別に設計された特定用途向け集積回路(application specific integrated circuit: ASIC)、フィールドプログラマブルゲートアレイ(field programmable gate array: FPGA)、コンピュータハードウェア、ファームウェア、ソフトウェア、および/またはそれらの組合せの形で実現されうる。これらの様々な態様または特徴は、ストレージシステム、少なくとも1つの入力デバイス、および少なくとも1つの出力デバイスからデータならびに命令を受信して、それらにデータならびに命令を送信するために結合された、特殊であってよく、または汎用であってもよい、少なくとも1つのプログラマブルプロセッサを含めて、プログラマブルシステム上で実行可能なかつ/あるいは解釈可能な1つもしくは複数のコンピュータプログラムの形での実装形態を含むことが可能である。プログラマブルシステムまたはコンピューティングシステムは、クライアントとサーバとを含むことが可能である。クライアントおよびサーバは、一般に、互いから遠隔であり、通常、通信ネットワークを介して相互作用する。クライアントとサーバの関係は、それぞれのコンピュータ上で実行しており、互いに対してクライアント‐サーバ関係を有するコンピュータプログラムにより生じる。

【0096】

プログラム、ソフトウェア、ソフトウェアアプリケーション、アプリケーション、コンポーネント、またはコードと呼ばれる場合もあるこれらのコンピュータプログラムは、プログラマブルプロセッサ用の機械命令を含み、高級手続き型言語および/もしくはオブジェクト指向プログラミング言語で、かつ/またはアセンブリ言語/機械語で実施可能である。本明細書で使用される場合、「機械可読媒体」という用語は、例えば、機械可読信号として機械命令を受信する機械可読媒体を含めて、機械命令および/またはデータをプログラマブルプロセッサに提供するために使用される、磁気ディスク、光ディスク、メモリ、およびプログラマブル論理デバイス(programmable logic device: PLD)など、任意のコンピュータプログラム製品、装置、ならびに/またはデバイスを指す。「機械可読信号」という用語は、機械命令および/またはデータをプログラマブルプロセッサに提供するために使用される任意の信号を指す。機械可読媒体は、例えば、非一次固体メモリ、もしくは磁気ハードドライブ、または任意の等価記憶媒体が行うように、そのような機械命令を非一時的に格納することが可能である。機械可読媒体は、別法として、または加えて、例えば、1つもしくは複数の物理プロセッサコアと関連付けられたプロセッサキャッシュまたはその他のランダムアクセスメモリが行うように、そのような機械命令を一時的な形で格納することが可能である。

【0097】

ユーザとの相互作用を実現するために、本明細書で開示された主題の1つもしくは複数の態様または特徴は、ユーザに情報を表示するための、例えば、陰極線管(cathode ray tube: CRT)、もしくは液晶ディスプレイ(liquid crystal display: LCD)、または発光ダイオード(light emitting diode: LED)モニタなどのディスプレイデバイスと、それによって、ユーザがコンピュータに入力を提供できる、キーボード、および、例えば、マウスまたはトラックボールなどのポインティングデバイスとを有するコンピュータ上で実施可能である。ユーザとの相互作用を提供するために、その他の種類のデバイスが同様に使用されうる。例えば、ユーザに提供されるフィードバックは、例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックなど、任意の形の感覚フィードバックであってよく、ユーザからの入力は、音響入力、音声入力、または触覚入力を含むが、これらに限定されない、任意の形で受信可能である。その他の考えられる入力デバイスは、タッチスクリーン、あるいは、シングルポイント抵抗式トラックパッドもしくはマルチポイント抵抗式トラックパッド、またはシングルポイント容量式トラックパッドもしくはマルチポイント容量式トラックパッド、音声認識ハードウェアおよび音声認識ソフトウェア、光学式スキャナ、光学式ポインタ、デジタル画像捕捉デバイス、ならびに関連する解釈ソフトウェアなど、その他のタッチ感応デバイスを含むが、これらに限定されない。

【0098】

本明細書で説明された主題は、所望される構成に応じて、システム、装置、方法、および/または物品の形で実施可能である。前述の説明に記載された実装形態は、本明細書で説明された主題に一致するすべての実装形態を表していない。それよりはむしろ、これらの実装形態は、説明された主題に関する態様に一致するいくつかの単なる例である。少数の変形形態が上で詳細に説明されているが、その他の修正形態または追加が可能である。詳細には、さらなる特徴および/または変形形態が、本明細書に記載される特徴ならびに変形形態に加えて提供可能である。例えば、上で説明された実装形態は、開示された特徴の様々な組合せおよびサブコンビネーション、ならびに/または上で開示された、いくつかのさらなる特徴の組合せおよびサブコンビネーションに関する場合がある。加えて、添付の図面で示され、かつ/または本明細書で説明された論理フローは、所望される結果を達成するために、示された特定の順序、または連続的な順序を必要とするとは限らない。その他の実装形態は以下の請求項の範囲内でありうる。

【符号の説明】

【0099】

100 データベースシステム
102 インメモリデータベースシステム(IMDS)
データベースシステム
104 インメモリデータベース
データベース
106 モデリングスタジオ
108 リアルタイム複製サービス
110 データサービス
112 特定用途向けビジネスオブジェクト
114 アプリケーション
所有権を主張できるアプリケーション
116 アプリケーション
第三者アプリケーション
118 ビジネスウェアハウスアプリケーション
120 ビジネススイート設計環境
122 ビジネスウェアハウス設計環境
ビジネスウェアハウスシステム
124 第三者設計環境

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】