特許 7030767 列状データの不均一なページネーション

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

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

(11)【特許番号】

(24)【登録日】2022-02-25

(45)【発行日】2022-03-07

(54)【発明の名称】列状データの不均一なページネーション

(51)【国際特許分類】

   G06F 16/17 20190101AFI20220228BHJP

   G06F 12/04 20060101ALI20220228BHJP

   G06F 16/13 20190101ALI20220228BHJP

【ＦＩ】

G06F16/17 100

G06F12/04 530

G06F16/13 110

【請求項の数】 16

【外国語出願】

(21)【出願番号】P 2019221382

(22)【出願日】2019-12-06

(65)【公開番号】P2020098593

(43)【公開日】2020-06-25

【審査請求日】2020-12-16

(31)【優先権主張番号】16/215,276

(32)【優先日】2018-12-10

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】300015447

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

【住所又は居所原語表記】Ｄｉｅｔｍａｒ－Ｈｏｐｐ－Ａｌｌｅｅ １６， ６９１９０ Ｗａｌｌｄｏｒｆ， Ｇｅｒｍａｎｙ

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】ゲイリー・リン

(72)【発明者】

【氏名】レザ・シェルカット

(72)【発明者】

【氏名】ジョン・スミルニオス

【審査官】鹿野 博嗣

(56)【参考文献】

【文献】特開２０１３－０８５０７１（ＪＰ，Ａ）

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

【文献】SHERKAT, Reza, et al.，Page As You Go: Piecewise Columnar Access In SAP HANA，Intenational Conference on Management of Data, SIGMOD'16，米国，ACM，2016年06月，p.1295-1306，[検索日：２０２１年６月２２日] <URL:https//doi.org/10.1145/2882903.2903729>

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

Ｇ０６Ｆ １６／１７

Ｇ０６Ｆ １２／０４

Ｇ０６Ｆ １６／１３

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

【請求項1】

インメモリデータベース用のメモリ管理のコンピュータ実装方法であって、
ページングデータベクトルを二次記憶装置内に記憶するステップであって、前記ページングデータベクトルが、複数のチャンクを含み、前記複数のチャンクが、不均一圧縮を使用して圧縮され、前記複数のチャンクが、複数のページとして前記ページングデータベクトル内に論理的に配置される、記憶するステップと、
データ要求を受信するステップと、
前記データ要求に関する前記複数のページのサブセットを識別するステップと、
前記データ要求に関するとして識別されている前記複数のページの前記サブセットの少なくとも1つのページを前記二次記憶装置からメインメモリにロードするステップと、
前記メインメモリ内の前記複数のページの前記サブセットの前記少なくとも1つのページを使用して、前記データ要求を実行するステップと
を含み、
前記ページングデータベクトルが、
データベクトルに関するチャンクサイズを計算するステップと、
前記ページングデータベクトルに対応するページング均一区分ツリーデータ構造を形成するために、前記チャンクサイズに従って前記データベクトルを符号化するステップと
を含む方法によって生成され、
前記データベクトルを前記符号化するステップが、
ルートノードをページチェーンとして構築し、前記複数のチャンクを形成するために、前記チャンクサイズに従って前記データベクトルを区分し、それぞれの選択された圧縮タイプを使用して、前記複数のチャンクの各々を一時的データ構造に符号化するステップであって、前記ページチェーンが、当初、空のページチェーンである、符号化するステップと、
正規サイズを有する前記複数のチャンクの各々を前記一時的データ構造から最小適合ページ内に移動させ、各最小適合ページを前記ページチェーン上に添付するステップであって、前記正規サイズを有するチャンクは、利用可能な最大ページサイズの空間よりも多くの空間を必要としないチャンクであり、特大であるチャンクは、利用可能な最大ページサイズの空間よりも多くの空間を必要とするチャンクである、ステップと
を含む、方法。

【請求項2】

前記不均一圧縮の場合、少なくとも第1のチャンクが、第1の圧縮タイプを使用して圧縮され、少なくとも第2のチャンクが、第2の圧縮タイプを使用して圧縮され、前記第1のチャンクが前記第2のチャンクとは異なり、前記第1の圧縮タイプが前記第2の圧縮タイプとは異なる、請求項1に記載の方法。

【請求項3】

前記チャンクサイズを前記計算するステップが、
初期チャンクサイズを選択するステップと、
前記初期チャンクサイズに従って、前記データベクトルを複数の予備チャンクに区分するステップと、
それぞれの選択された圧縮タイプを使用して、前記複数の予備チャンクの各々を圧縮し、複数の圧縮率を計算するステップと、
前記圧縮率と誤差許容値の比較に基づいて、ターゲット圧縮率を設定するステップと、
前記圧縮率に基づいて、ターゲット空間量を計算し、前記ターゲット空間量に適合する最小適合ページに基づいて、ページサイズを計算するステップと
を含み、
前記チャンクサイズが、前記ターゲット圧縮率を最小限にターゲットにするように計算される、請求項1に記載の方法。

【請求項4】

前記データベクトルを前記符号化するステップが、
特大である前記複数のチャンクの各々に対する空きページを、子ノードを参照して前記ページチェーン上に添付するステップと、
特大である前記複数のチャンクの各々をそれぞれの子ノード内に再帰的に記憶するステップと
を含む、請求項1に記載の方法。

【請求項5】

前記データ要求に関する前記複数のページの前記サブセットを前記識別するステップが、
前記ページングデータベクトル内で、ルートノードから始めて一度に1つずつ前記複数のチャンクをトラバースするステップ
を含む、請求項1に記載の方法。

【請求項6】

前記ページングデータベクトルが、ルートノードおよび少なくとも1つの子ノードを有する、請求項1に記載の方法。

【請求項7】

前記ルートノードが、前記複数のチャンクの論理表現に対応し、子ノードが、前記ルートノードの前記複数のチャンクの単一のチャンクに対応する、請求項6に記載の方法。

【請求項8】

前記少なくとも1つの子ノードが、少なくとも1つの特大チャンクに対応し、特定の子ノードが、特定の特大チャンクに対応する、請求項6に記載の方法。

【請求項9】

前記少なくとも1つの子ノードが、第1の子ノードおよび第2の子ノードを含む複数の子ノードに対応し、前記第2の子ノードが、前記第1の子ノードの子である、請求項6に記載の方法。

【請求項10】

前記ページングデータベクトルが、前記複数のチャンクを含む単一のノードであるルートノードを有する、請求項1に記載の方法。

【請求項11】

インメモリデータベース用のメモリ管理のための処理を実行するためのコンピュータシステムを制御するためのコンピュータプログラムを記憶した非一時的コンピュータ可読媒体であって、前記処理が、
ページングデータベクトルを二次記憶装置内に記憶することであって、前記ページングデータベクトルが、複数のチャンクを含み、前記複数のチャンクが、不均一圧縮を使用して圧縮され、前記複数のチャンクが、複数のページとして前記ページングデータベクトル内に論理的に配置される、記憶することと、
データ要求を受信することと、
前記データ要求に関する前記複数のページのサブセットを識別することと、
前記データ要求に関するとして識別されている前記複数のページの前記サブセットの少なくとも1つのページを前記二次記憶装置からメインメモリにロードすることと、
前記メインメモリ内の前記複数のページの前記サブセットの前記少なくとも1つのページを使用して、前記データ要求を実行することと
を含み、
前記ページングデータベクトルが、
データベクトルに関するチャンクサイズを計算することと、
前記ページングデータベクトルに対応するページング均一区分ツリーデータ構造を形成するために、前記チャンクサイズに従って前記データベクトルを符号化することと
を含む処理によって生成され、
前記データベクトルを前記符号化することが、
ルートノードをページチェーンとして構築し、前記複数のチャンクを形成するために、前記チャンクサイズに従って前記データベクトルを区分し、それぞれの選択された圧縮タイプを使用して、前記複数のチャンクの各々を一時的データ構造に符号化することであって、前記ページチェーンが、当初、空のページチェーンである、符号化することと、
正規サイズを有する前記複数のチャンクの各々を前記一時的データ構造から最小適合ページ内に移動させ、各最小適合ページを前記ページチェーン上に添付することであって、前記正規サイズを有するチャンクは、利用可能な最大ページサイズの空間よりも多くの空間を必要としないチャンクであり、特大であるチャンクは、利用可能な最大ページサイズの空間よりも多くの空間を必要とするチャンクである、ことと
を含む、非一時的コンピュータ可読媒体。

【請求項12】

前記不均一圧縮の場合、少なくとも第1のチャンクが、第1の圧縮タイプを使用して圧縮され、少なくとも第2のチャンクが、第2の圧縮タイプを使用して圧縮され、前記第1のチャンクが前記第2のチャンクとは異なり、前記第1の圧縮タイプが前記第2の圧縮タイプとは異なる、請求項11に記載の非一時的コンピュータ可読媒体。

【請求項13】

前記チャンクサイズを前記計算することが、
初期チャンクサイズを選択することと、
前記初期チャンクサイズに従って、前記データベクトルを複数の予備チャンクに区分することと、
それぞれの選択された圧縮タイプを使用して、前記複数の予備チャンクの各々を圧縮し、複数の圧縮率を計算することと、
前記圧縮率と誤差許容値の比較に基づいて、ターゲット圧縮率を設定することと、
前記圧縮率に基づいて、ターゲット空間量を計算し、前記ターゲット空間量に適合する最小適合ページに基づいて、ページサイズを計算することと
を含み、
前記チャンクサイズが、前記ターゲット圧縮率を最小限にターゲットにするように計算される、請求項11に記載の非一時的コンピュータ可読媒体。

【請求項14】

インメモリデータベース用のメモリ管理のためのシステムであって、
データ要求を受信するように前記システムを制御するように構成された少なくとも1つのプロセッサと、
メインメモリと、
ページングデータベクトルを記憶するように構成された二次記憶装置であって、前記ページングデータベクトルが、複数のチャンクを含み、前記複数のチャンクが、不均一圧縮を使用して圧縮され、前記複数のチャンクが、複数のページとして、前記ページングデータベクトル内で論理的に配置される、二次記憶装置と、
前記データ要求に関する前記複数のページのサブセットを識別するように構成されたデコーダ構成要素と、
前記データ要求に関係するとして識別されている前記複数のページの前記サブセットの少なくとも1つのページを前記二次記憶装置から前記メインメモリにロードするように構成されたページローダ構成要素と
を含み、
前記少なくとも1つのプロセッサが、前記メインメモリ内の前記複数のページの前記サブセットの前記少なくとも1つのページを使用して、前記データ要求を実行するように前記システムを制御するように構成され、
前記システムは、
データベクトルに関するチャンクサイズを計算するように構成されたチャンクサイズ計算構成要素と、
前記ページングデータベクトルに対応するページング均一区分ツリーデータ構造を形成するために、前記チャンクサイズに従って前記データベクトルを符号化するように構成されたエンコーダ構成要素と
をさらに含み、
前記データベクトルを前記符号化することが、
ルートノードをページチェーンとして構築し、前記複数のチャンクを形成するために、前記チャンクサイズに従って前記データベクトルを区分し、それぞれの選択された圧縮タイプを使用して、前記複数のチャンクの各々を一時的データ構造に符号化することであって、前記ページチェーンが、当初、空のページチェーンである、符号化することと、
正規サイズを有する前記複数のチャンクの各々を前記一時的データ構造から最小適合ページ内に移動させ、各最小適合ページを前記ページチェーン上に添付することであって、前記正規サイズを有するチャンクは、利用可能な最大ページサイズの空間よりも多くの空間を必要としないチャンクであり、特大であるチャンクは、利用可能な最大ページサイズの空間よりも多くの空間を必要とするチャンクである、ことと
を含む
システム。

【請求項15】

前記不均一圧縮の場合、少なくとも第1のチャンクが、第1の圧縮タイプを使用して圧縮され、少なくとも第2のチャンクが、第2の圧縮タイプを使用して圧縮され、前記第1のチャンクが前記第2のチャンクとは異なり、前記第1の圧縮タイプが前記第2の圧縮タイプとは異なる、請求項14に記載のシステム。

【請求項16】

前記チャンクサイズを前記計算することが、
初期チャンクサイズを選択することと、
前記初期チャンクサイズに従って、前記データベクトルを複数の予備チャンクに区分することと、
それぞれの選択された圧縮タイプを使用して、前記複数の予備チャンクの各々を圧縮し、複数の圧縮率を計算することと、
前記圧縮率と誤差許容値の比較に基づいて、ターゲット圧縮率を設定することと、
前記圧縮率に基づいて、ターゲット空間量を計算し、前記ターゲット空間量に適合する最小適合ページに基づいて、ページサイズを計算することと
を含み、
前記チャンクサイズが、前記ターゲット圧縮率を最小限にターゲットにするように計算される、請求項14に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
該当なし。

【0002】

本発明は、インメモリデータベースシステムに関し、詳細には、インメモリデータベースシステム用のメモリ管理に関する。

【背景技術】

【0003】

本明細書で別段の指示がない限り、このセクションで説明する手法は、本出願の特許請求の範囲に対する先行技術ではなく、このセクションに含めることにより先行技術になると認められない。

【0004】

データベースは、電子的に記憶およびアクセスされる、データの編成された収集物である。データベース設計者は、一般に、情報を必要とするプロセスをサポートする方法でデータを現実のモデル態様に編成する。

【0005】

データベース管理システム(DBMS)は、データをキャプチャして分析するために、エンドユーザ、アプリケーション、およびデータベース自体と対話するソフトウェアである。汎用DBMSは、データベースの定義、作成、クエリ、更新、および管理を可能にする。データベース、DBMS、およびその関連するアプリケーションの全体は、「データベースシステム」と呼ばれることがある。「データベース」という用語はしばしば、DBMS、データベースシステム、またはデータベースに関連するアプリケーションのいずれかを大まかに指すために使用される。

【0006】

インメモリデータベースシステム(IMDBSまたはIMDB(in-memory data base system)、またメインメモリデータベースシステム(MMDBS:main memory database system)またはメモリ常駐データベース(MRDB:memory resident database))は、コンピュータデータ記憶のためにメインメモリに主に依拠するデータベース管理システムである。このデータベースは、ディスク記憶機構に依拠するデータベース管理システムと対比される。インメモリデータベースは、ディスク最適化データベースよりも高速であるが、これは、ディスクアクセスはメモリアクセスよりも遅く、内部最適化アルゴリズムは、より単純であり、より少数のCPU命令を実行するためである。メモリ内のデータへのアクセスは、データを問い合わせるときの探索時間を除去し、これは、ディスクよりも高速かつより予測可能な性能を提供する。IMDBのメモリは、揮発性(たとえば、ランダムアクセスメモリ)または不揮発性(たとえば、フラッシュメモリ)であってよい。IMDBは、それが「メインメモリに主に依拠する」という側面により注目に値するが、IMDBは、ディスクまたは他の永続的記憶装置を(たとえば、バックアップ目的で)含むこともできる。(当然、非IMDBシステムとIMDBシステムは両方ともメモリを有するが、内部最適化アルゴリズムは異なるため、非IMDBシステム用に開発された特徴をIMDBシステムに適用することは、まったく簡単ではないことを当業者は諒解されよう。)例示的なIMDBは、米国特許出願公開第2009/0240663号に記載されている。例示的な商用のIMDBは、SAP SEからのSAP HANA(登録商標)インメモリデータプラットフォームである。

【0007】

データのサイズがメモリのサイズを超えるときのIMDBの場合、IMDBは、所与の時点でメインメモリ内に存在する、データの部分を管理するためのメモリ管理システムを含み得る。概して、メモリ管理システムは、メインメモリと、ディスクシステムなどの別の構成要素との間のデータの記憶を調整する。メモリ管理システムは、この調整を管理するためのいくつかの方策を使用し得る。1つの方策は、データをユニット(たとえば、ページ)に区分し、必要なときに、特定のユニットをメインメモリ内にロードし、それらのユニットを、必要に応じて、メインメモリ内の他のページと置換することである。IMDBに関する例示的なメモリ管理システムは、米国特許出願公開第2016/0012089号に記載されている。

【先行技術文献】

【特許文献】

【0008】

【文献】米国特許出願公開第2009/0240663号

【文献】米国特許出願公開第2016/0012089号

【発明の概要】

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

【0009】

上記を仮定して、いくつかの課題が提示される。1つの課題は、データがユニットに区分されているとき、メモリ管理システムによるアクセスの容易さがしばしば空間効率よりも選好されることである。メモリ管理システムは、どのユニットが特定のデータ記録を含むかを正確に判定しなければならないため、データを各ユニットに区分するとき、概して、同じ圧縮(均一圧縮と呼ばれる)がデータに適用される。結果として、異なるタイプの圧縮が特定のユニットに対してより良好な圧縮をもたらす可能性があるとしても、均一圧縮は全体としてデータに適用可能であるため、均一圧縮が選好される。均一圧縮システムの一例は、値識別子のセット全体に対してその圧縮(辞書圧縮およびnビット圧縮)を適用することによって、均一圧縮を実装する、米国特許出願公開第2016/0012089号に記載されている。メモリ管理システムによるアクセスの容易さを依然として可能にしながら、各ユニットがその独自の適切な圧縮に従って圧縮され得るように、不均一圧縮を可能にするための技術的解決策が必要である。

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

【0010】

実施形態は、以下でより詳細に論じるように、上記の課題、および他の課題に対処することに関する。結果として、実施形態は、均一圧縮のみを実装する多くの既存のシステムと比較して、アクセスの容易さを依然として有しながら、より効率的なデータ記憶を可能にするために不均一圧縮を使用する。

【0011】

1つの実施形態では、方法は、インメモリデータベース用のメモリ管理を実行する。この方法は、ページングデータベクトル(paged data vector)を二次記憶装置内に記憶するステップを含む。ページングデータベクトルは、複数のチャンクを含み、複数のチャンクは、不均一圧縮を使用して圧縮され、複数のチャンクは、複数のページとしてページングデータベクトル内で論理的に配置される。この方法は、データ要求を受信するステップをさらに含む。この方法は、データ要求に関する複数のページのサブセットを識別するステップをさらに含む。この方法は、データ要求に関するとして識別されている複数のページのサブセットの少なくとも1つのページを二次記憶装置からメインメモリにロードするステップをさらに含む。この方法は、メインメモリ内の複数のページのサブセットの少なくとも1つのページを使用して、データ要求を実行するステップをさらに含む。

【0012】

不均一圧縮の場合、少なくとも第1のチャンクは、第1の圧縮タイプを使用して圧縮され得、少なくとも第2のチャンクは、第2の圧縮タイプを使用して圧縮され得る。(第1のチャンクは第2のチャンクとは異なり、第1の圧縮タイプは第2の圧縮タイプとは異なる。)

【0013】

ページングデータベクトルは、データベクトルに関するチャンクサイズを計算するステップと、ページングデータベクトルに対応するページング均一区分ツリーデータ構造(paged uniform-partition tree data structure)を形成するために、チャンクサイズに従ってデータベクトルを符号化するステップとを含む方法によって生成され得る。

【0014】

チャンクサイズを計算するステップは、初期チャンクサイズを選択するステップと、データベクトルを複数の予備チャンクに区分するステップとを含み得る。チャンクサイズを計算するステップは、それぞれの選択された圧縮タイプを使用して、複数の予備チャンクの各々を圧縮し、複数の圧縮率を計算するステップをさらに含み得る。チャンクサイズを計算するステップは、圧縮率と誤差許容値の比較に基づいて、ターゲット圧縮率を設定するステップをさらに含み得る。チャンクサイズを計算するステップは、圧縮率に基づいて、ターゲット空間量を計算し、ターゲット空間量に適合する最小適合ページに基づいて、ページサイズを計算するステップをさらに含み得る。チャンクサイズは、ターゲット圧縮率を最小限にターゲットにするように計算される。

【0015】

データベクトルを符号化するステップは、ルートノードをページチェーンとして構築し、複数のチャンクを形成するために、チャンクサイズに従って、データベクトルを区分し、それぞれの選択された圧縮タイプを使用して、複数のチャンクの各々を一時的データ構造に符号化するステップであって、ページチェーンが、当初、空のページチェーンである、符号化するステップを含み得る。データベクトルを符号化するステップは、正規サイズを有する複数のチャンクの各々を一時的データ構造から最小適合ページ内に移動させ、各最小適合ページをページチェーン上に添付するステップをさらに含み得る。

【0016】

データベクトルを符号化するステップは、特大である複数のチャンクの各々に対する空きページを、子ノードを参照してページチェーン上に添付するステップと、特大である複数のチャンクの各々をそれぞれの子ノード内に再帰的に記憶するステップとをさらに含み得る。

【0017】

データ要求に関する複数のページのサブセットを識別するステップは、複数のチャンクを、ページングデータ構造内で、ルートノードから始めて一度に1つずつ複数のチャンクをトラバースする(traversing)ステップを含み得る。

【0018】

ページングデータベクトルは、ルートノードおよび少なくとも1つの子ノードを有し得る。ルートノードは、複数のチャンクの論理表現に対応し得、子ノードは、ルートノードの複数のチャンクの単一のチャンクに対応し得る。少なくとも1つの子ノードは、少なくとも1つの特大チャンクに対応し得、ここで、特定の子ノードは、特定の特大チャンクに対応し得る。少なくとも1つの子ノードは、第1の子ノードおよび第2の子ノードを含む複数の子ノードに対応し得、ここで、第2の子ノードは、第1の子ノードの子であってよい。

【0019】

ページングデータベクトルは、複数のチャンクを含む単一のノードであるルートノードを有し得る。

【0020】

コンピュータ可読媒体は、上記の方法の1つまたは複数のステップを実装するようにコンピュータを制御するためのコンピュータプログラムを記憶することができる。

【0021】

このシステムは、インメモリデータベース用のメモリ管理を実行するためのコンピュータ(たとえば、サーバコンピュータ、データベースシステム、クライアントコンピュータなど)を使用して、上記の方法の1つまたは複数のステップを実装することができる。このシステムは、少なくとも1つのプロセッサと、メインメモリと、二次記憶装置と、デコーダ構成要素と、ページローダ構成要素とを含み得る。このシステムは、チャンクサイズ計算構成要素とエンコーダ構成要素とをさらに含み得る。

【0022】

以下の詳細な説明および添付の図面は、本発明の性質および利点のより良い理解を提供する。

【図面の簡単な説明】

【0023】

【図1】インメモリデータベースシステム(IMDBS)100を実装するコンピュータシステムのブロック図である。

【図2】インメモリデータベース用のメモリ管理の方法200のフローチャートである。

【図3】均一区分ツリー(UPT)300の論理表現のブロック図である。

【図4】インメモリデータベース用のメモリ管理の方法400のフローチャートである。

【図5】ページングデータベクトルを生成する方法500のフローチャートである。

【図6】コードリスティング600である。

【図7】コードリスティング700である。

【図8】上記で説明した様々な実施形態を実装するための例示的なコンピュータシステム800のブロック図である。

【図9】上記で説明した様々な実施形態を実装するためのクラウドコンピューティングシステム900のブロック図である。

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

【0024】

本明細書で説明するのは、インメモリデータベースシステム内のメモリ管理のための技法である。以下の記述では、説明のために、本明細書で説明するシステムおよび方法の十分な理解を提供するために、様々な例および特定の詳細が記載される。しかしながら、特許請求の範囲によって定義される本発明は、これらの例における特徴のいくつかまたはすべてを単独でまたは以下で説明する他の特徴と組み合わせて含んでよく、本明細書で説明する特徴および概念の修正および均等物をさらに含んでよいことが当業者には明らかになるであろう。

【0025】

本文書では、様々な方法、プロセス、および手順が詳述される。特定のステップが一定の順序で説明されることがあるが、そのような順序は、主に便宜および明快のためである。特定のステップは、2回以上繰り返されることがあり、他のステップの前または後に生じることがあり(それらのステップが、場合によっては、別の順序で説明されることがあるとしても)、他のステップと並行して生じることもある。第2のステップは、第1のステップが第2のステップが開始される前に完了しなければならないときのみ、第1のステップの後に生じることが必要とされる。そのような状況は、文脈から明らかでないとき、具体的に指摘されることになる。

【0026】

本文書では、「および」、「または」、または「および/または」と言う用語が使用される。そのような用語は、包含的な意味を有するとして読み取られるべきである。たとえば、「AおよびB」は、少なくとも以下、すなわち、「AとBの両方」、「少なくともAとBの両方」を意味し得る。別の例として、「AまたはB」は、少なくとも以下、すなわち、「少なくともA」、「少なくともB」、「AとBの両方」、「少なくともAとBの両方」を意味し得る。別の例として、「Aおよび/またはB」は、少なくとも以下、すなわち、「AおよびB」、「AまたはB」を意味し得る。排他的な「または」が意図されるとき、そのような排他的な「または」は、具体的に述べられることになる(たとえば、「AまたはBのいずれか」、「AおよびBのうちのせいぜい1つ」)。

【0027】

本文書では、「サーバ」という用語が使用される。概して、サーバは、ハードウェアデバイスであり、「ハードウェア」という記述は、ハードウェアサーバの議論において省かれる場合がある。サーバは、サーバの機能性を制御するコンピュータプログラムを実装または実行することができる。そのようなコンピュータプログラムは、機能的にサーバと呼ばれることもあるか、またはサーバ機能を実装するとして説明される場合もある。しかしながら、サーバ機能性を実装するかまたはハードウェアサーバを制御するコンピュータプログラムは、より正確には「ソフトウェアサーバ」、「サーバ構成要素」、または「サーバコンピュータプログラム」と呼ばれることを理解されたい。

【0028】

本文書では、「データベース」という用語が使用される。概して、データベースは、大量のデータを容易に編成し、記憶し、取り出すためのデータ構造である。データベースは、データストアと呼ばれることもある。データベースという用語は、概して、データが表形式で記憶され、データ同士の間の関係も表形式でやはり記憶される、リレーショナルデータベースを指すために使用され得る。データベース管理システム(DBMS)は、概して、データベースを実装する、ハードウェアコンピュータシステム(たとえば、ディスクドライブまたはフラッシュドライブなどの永続的メモリ、ランダムアクセスメモリなどの揮発性メモリ、プロセッサなど)を指す。

【0029】

本文書では、「記憶する」、「記憶された」、および「記憶している」という用語が使用される。概して、これらの用語は、能動態動詞(たとえば、記憶するプロセス、または記憶されていない状態から記憶された状態への変化)、存在状態(たとえば、記憶されている状態)、または両方を指すために使用される場合がある。たとえば、「データ記録を記憶している」は、記憶しているプロセス(たとえば、記憶されていない状態から記憶された状態へのデータ記録遷移)を記述するために使用される場合がある。別の例として、「データ記録を記憶している」は、データ記録の現状(たとえば、データ記録が、前に記憶されている結果として、記憶された状態で現在存在すること)を記述するために使用される場合がある。単一の解釈のみを意味するとき、そのような意味は、文脈から明らかになるであろう。

【0030】

図1は、インメモリデータベースシステム(IMDBS)100を実装するコンピュータシステムのブロック図である。コンピュータシステムは、1つまたは複数のハードウェア構成要素を含んでよく、その詳細については、後続の図面において論じる。IMDBS100は、1つまたは複数のコンピュータプログラムを実行することによって、コンピュータシステムによって実装され得る。IMDBS100は、メインメモリ110と、二次記憶装置120と、メモリ管理システム130と、データ処理システム140とを含む。IMDBS100は、(簡単のために)詳述されない他の構成要素(たとえば、永続層など)を含んでもよい。

【0031】

メインメモリ110は、概して、上記で説明した他のメインメモリデータベースシステムに関するのと同様の方法で、IMDBS100のためのメインメモリとして動作する。メインメモリ110は、揮発性メモリ構成要素または不揮発性メモリ構成要素とともに実装され得る。好適な揮発性メモリ構成要素は、スタティックRAM(SRAM)または動的RAM(DRAM)など、ランダムアクセスメモリ(RAM)を含む。好適な不揮発性メモリ構成要素は、フラッシュメモリを含む。

【0032】

二次記憶装置120は、概して、そのサイズがメインメモリ110の容量を超えるデータを記憶するために、メインメモリ110と協調して動作する。これは、メインメモリ110が、サイズ削減され、それでもなお、大きなデータセット上で動作可能であることを可能にする。概して、二次記憶装置120は、メインメモリ110よりも遅く、かつ(データサイズ単位で)コストが低い。たとえば、メインメモリ110がSRAMとともに実装される場合、二次記憶装置120は、DRAM、フラッシュメモリ、またはハードディスクシステムとともに実装され得る。

【0033】

メモリ管理システム130は、概して、メインメモリ110と二次記憶装置120との間のデータの記憶装置を調整する。たとえば、IMDBS100が特定のデータ記録を必要とするとき、メモリ管理システム130は、その特定のデータ記録を二次記憶装置120からメインメモリ110にロードする。メモリ管理システム130は、チャンクサイズ計算機132と、エンコーダ構成要素134と、デコーダ構成要素136と、ページローダ138とを含む。

【0034】

チャンクサイズ計算機132は、IMDBS100によって記憶され処理されるデータに関するチャンクサイズを計算する。以下でより詳細に論じるように、データのチャンクは、ページと呼ばれるデータ構造内に記憶される。概して、データは、二次記憶装置120からメインメモリ110にチャンク内にロードされ、チャンクサイズ計算機132は、この目的でデータを配置する一環としてチャンクサイズを計算する。チャンクサイズ、およびチャンクサイズ計算機132については、後続のセクションでより詳細に論じる。

【0035】

エンコーダ構成要素134は、IMDBS100によって記憶され処理されるデータに対して圧縮を実行する。たとえば、IMDBS100は、列状データに対して動作し、特定の列内のデータ値が(様々な技法を使用して)圧縮されて、メモリ内に記憶される必要があるデータのサイズを削減し得る。エンコーダ構成要素134は、以下で詳細に論じる均一区分ツリー(UPT)など、IMDBS100によって使用される他のデータ構造をやはり生成する。概して、エンコーダ構成要素134が、チャンク単位ベースで圧縮を実行し得る。これは、エンコーダ構成要素134が、異なるチャンクに異なる圧縮タイプ(たとえば、不均一圧縮)を適用することを可能にする。(そのような動作は、同じ圧縮をデータ列全体に適用する均一圧縮と対比され得る。)圧縮、およびエンコーダ構成要素134については、後続のセクションでより詳細に論じる。

【0036】

デコーダ構成要素136は、所与のデータ記録を含む特定のチャンク(ページ)を識別する。チャンクは異なる圧縮タイプを使用して圧縮されている可能性があるため、特定のチャンクの識別は、重要なプロセスである。識別されたページがすでにメインメモリ110内にある場合、IMDBS100は、そのチャンクに対してその処理を実行することができる。そうでない場合、デコーダ構成要素136は、識別されたページの情報をページローダ138に提供する。この復号プロセス、およびデコーダ構成要素136については、後続のセクションでより詳細に論じる。

【0037】

ページローダ138は、デコーダ構成要素136によって識別されたページを二次記憶装置120からメインメモリ110にロードする。このように、ページローダ138は、データの記憶を二次記憶装置120からメインメモリ110内に調整する。ページローディング、およびページローダ138については、後続のセクションでより詳細に論じる。

【0038】

データ処理システム140は、概して、メインメモリ110内にロードされたデータに対してデータ処理を実行する。データ処理は、たとえば、データ記録を追加、削除、コピー、修正、または更新するためのトランザクションデータ処理であってよい。データ処理は、たとえば、1つまたは複数のデータ記録に対してクエリを実行するための、解析データ処理であってよい。

【0039】

IMDBS100は、概して、以下のように動作する。IMDBSは、表データを記憶するための完全メモリ常駐列(fully memory-resident column)タイプの代替として、ページロード可能列(page loadable column)タイプを使用する選択肢を提供する。後者の手法は、列全体からの表ロード単位をページと呼ばれるデータの固定サイズの連続ブロックに低減することを可能にする。これは、概して、特に、より大きな作業負荷の下で、より少ないメモリ使用をもたらす。これは、各列に関連する主要なデータ構造のページング可能バージョン、すなわち、符号化列コンテンツ、その辞書、および場合によっては、その反転インデックス(inverted index)を用いて実装される。データベクトルと呼ばれる、主な列コンテンツは、列のデータ記録に対応し、列のメモリ使用の大部分をなす。

【0040】

多くの既存のシステムに関して上記で論じたように、データベクトルは、そのページング可能な相対物に変換されるとき、深刻な空間オーバーヘッドを受けることがある。これは、値のアクセス可能性(すなわち、行からページへの変換)の容易さが空間効率よりも選好され、これらの既存のシステムでは、均一圧縮のみがページロード可能な列に対して可能にされるためである。符号化値を含むページの識別を容易にするために、ページに対するすべての値が識別可能であるとしても、またはページ単位の値が十分に圧縮するとしても、すべてのデータページは同じサイズを有する。これは、ページングデータベクトルのメモリフットプリントを増大させる。

【0041】

上記の問題に対処するために、IMDBS100は、データベクトルの等しいサイズのセクションに対して不均一なページネーションを使用する、ページングデータベクトルのロスレス(lossless)圧縮を用いた新規の永続レイアウトを実装する。この手法は、ページング均一区分ツリー符号化(PUPTE:paged uniform-partition tree encoding)と呼ばれる。PUPTEは、不均一圧縮を実行するためにエンコーダ構成要素134およびデコーダ構成要素136によって実装される、新しい符号化プロセスおよび復号プロセスを必要とする。多くの既存のシステムと比較して、IMDBS100は、実際に、ページングデータベクトルの所望の効率的なランダムページアクセス属性を依然として維持しながら、空間消費を削減する。これは、列位置に対応するページの識別が均一圧縮に非常に近い一方で、特にデータベクトルが十分に圧縮するときにメモリ消費がかなり低い可能性があることを意味する。

【0042】

概要

【0043】

IMDBS100は、データベース表列を記憶する3つの方法:(1)完全メモリ常駐列、(2)ページロード可能列、および(3)ページング均一区分ツリー符号化(PUPTE)をサポートする。

【0044】

1.完全メモリ常駐列

【0045】

完全メモリ常駐列を使用するとき、列全体が処理のためにメインメモリ110内にロードされる。IMDBSは、メモリフットプリントを削減するために列の全体に対して辞書圧縮およびnビット符号化を使用して列を圧縮し得る。

【0046】

2.ページロード可能列

【0047】

ページロード可能列は、概して、完全メモリ常駐列を使用するよりも、さらに少ないメモリ利用を可能にし得る。ページロード可能列方法は、二次記憶装置120からメインメモリ110に、ページと呼ばれるデータの固定サイズ連続部分のみを一度に1つの列からロードおよびアンロードすることによって達成される。この方策を用いると、能動的に必要とされる表の列のページのみがメインメモリ110に維持されることになり、これにより、貴重なメインメモリのシステム使用を最適化する。これは、特に、メモリ圧力の増大が存在する、低いカーディナリティまたは低いダイバーシティを有する非常に大きなデータセットに対する高性能を目的とするときに重要な場合がある。表全体をメインメモリ110内に適合させることは不必要に高価であり得る、または時には、不可能ですらあり得る。ページロード可能列は、辞書圧縮を用いてインメモリ列を符号化するために使用された主データ構造および補助データ構造にページング可能な相対物を提供することによって実装され得る。問題は、データ構造のすべてのページングバージョンには追加の欠点が伴うものの、データベクトルと呼ばれるバージョンが特に被害を受けることである。データベクトルは、本質的に、制限されたサイズの整数のアレイである。

【0048】

列の読取り専用部分の場合、IMDBS100は、様々な高度圧縮方法をサポートするが、ページロード可能列は、均一圧縮のみを適用する。読取り専用ページングデータベクトルは、辞書圧縮およびnビット符号化を使用するに過ぎず、これは、各値を文字通り記憶するために、最大値を記憶するために必要とされるのと同数のビットのみを使用する。議論のために、辞書圧縮とnビット符号化データベクトルの組合せは、均一圧縮である。これは、ページングデータベクトルの性能劣化の原因である。これらは、概して、より少ないメモリを能動的に使用するが、ディスク空間をやはり明らかにする場合、総空間使用は、圧縮されたインメモリデータベクトルの総空間使用よりもかなり大きい可能性がある。ページングデータベクトルが、現在、どんなさらなる圧縮もサポートしない理由は、値にアクセスする簡単さと空間効率との間の固有のトレードオフによる。

【0049】

実際に、これは、IMDBS100がサポートする高度圧縮方法にも当てはまる。各値は可変数のビットを使用して符号化され得るため、多くの既存のシステムは、任意の符号化値の正確なロケーションをもはや判定することができない。したがって、可変長の値が使用されるとき、効率的なランダムアクセスの能力は失われる。圧縮データから値を復号することは、一般に、順次走査(sequential traversal)を必要とする。しかしながら、これは、ページングデータベクトルの場合には選択肢ではない。メモリ圧力を最小限に抑えるためには、表全体または列全体をロードせずに、任意の値にアクセスし、その値が記憶されているページのみをロードすることが可能であることが必要である。しかしながら、そのデータがどのページ内に記憶されているかを見つけ出すことができない場合、最悪の場合、列内のすべてのページをロードすることになる可能性がある。対照的に、均一に圧縮されたnビットデータベクトルはランダムアクセスをサポートし、したがって、任意の値がどのページ内に存在するかを容易に判定することができる。これは、所望の行位置を、ページ単位で適合する値の数で除算して、ページ番号を識別することによって行われる。しかしながら、すべてのランダムアクセスを有することは不要である。値が記憶されている正確な位置を知る必要はなく、その値が記憶されているページのみを知る必要がある。ページ単位で準ランダムアクセス形式である、発明者らがランダムページアクセスと呼ぶものを有するだけで十分である。

【0050】

3.ページング均一区分ツリー符号化(PUPTE)

【0051】

第3の方法、PUPTEは、ランダムページアクセスを依然としてサポートすることと、データを圧縮することとの間のページングデータベクトルに対する良好な均衡を見出すことに関する。これは、固定-可変コーディング(fixed-to-variable coding)を有するフレキシビリティを提供する。PUPTEは、データベクトルを固定サイズのチャンクに均一に区分し、IMDBS100がサポートする圧縮方法を使用して、各チャンクをその独自のページに符号化する。結果として、チャンクは、その特定のチャンクに最も適した圧縮タイプを用いて圧縮され得る。これは、不均一圧縮と呼ばれる。(対照的に、ページロード可能列の場合、均一圧縮は、列全体に対して実行される。)各チャンクは等しい数の値を含むため、IMDBS100は、どのチャンクの中に任意の値があるかを容易に判定することができ、各チャンクは1つのページ内に記憶されるため、どのページ内に各値が記憶されているかを判定し得ることに留意されたい。同時に、IMDBS100は、所望されるように、値の圧縮を可能にし続ける。IMDBS100は、PUPTE(第3の方法)を用いて符号化されたページングデータベクトルが、基底表現が異なるだけで、ページロード可能列(第2の方法)と同様に機能するように、符号化アルゴリズムおよび復号アルゴリズムを実装する。

【0052】

IMDBS100によって実装されるPUPTEのさらなる詳細は、以下で提供される。

【0053】

追加の詳細

【0054】

IMDBS100は、列状インメモリデータベースを実装する。インメモリデータは、ヒープ割振りメモリ上に(方法1)、より効率的なメモリ割振りのためのページと呼ばれる、メモリの固定サイズブロック上に記憶されたページロード可能データを用いたページロード可能列内に(方法2)、またはPUPTE(方法3)を用いて、連続的に記憶され得る。サポートされるページサイズは4KiBから1MiBに及び、各々は、前のページサイズクラスよりも2倍または4倍のいずれかの大きさである。各ページは、メタデータ用のページヘッダと、その後に、実際のコンテンツにアクセスするためのスロットとを含む。ページは、ページチェーンと呼ばれるリンクリスト内に編成され得る。データの耐久性のために、永続層によって処理される、ページが残存し得るディスク記憶装置がやはり存在し得る。ページは、ディスクからメモリ内へロードされ、そこからページバッファと呼ばれるバッファプール内へとロードされ得るが、ページバッファがすでにフルである場合、空間を作るために、ページバッファ内の数ページが最初に排除されなければならない。

【0055】

IMDBS100は、データベース表の記憶を管理する。表は、列のセットとして表され、各列は2つのセクションからなる。第1は、メインフラグメントと呼ばれる、読取り最適化セクションである。第2は、デルタフラグメントと呼ばれる、書込み最適化セクションである。変更は所定の位置にあるデータを変更せず、むしろ、新しい列をデルタフラグメントに添付する。変更は後に、デルタマージと呼ばれる動作において、デルタフラグメントからメインフラグメントに持ち込まれ、この動作は、本質的に、新しいデータベクトルを再構成する。メインフラグメントは、実際には決して修正または追加されず、再構築されるのみであり、したがって、読取り専用であると言える。列フラグメントは両方とも、効率的な記憶のために辞書圧縮を使用する。これは、値識別子と呼ばれる、一意の整数を列内のそれぞれの一意の値に割り当てることを必要とする。実際の列は、次いで、発明者らがデータベクトルと呼ぶ値IDのベクトル、または、1つの値が列内の各行に対する値IDアレイ、および値IDをそれが指す値にマッピングする辞書として記憶される。反転インデックスと呼ばれる、別のデータ構造も、随意に、効率的なクエリを可能にするように構築され得る。

【0056】

列は、完全メモリ常駐(方法1)、ページロード可能(方法2)、またはPUPTE(方法3)であってよい。ページロード可能列は、列に対するクエリの実行がメインメモリ内の列全体を必要としないように設計される。データはディスク上のページ内に記憶され、必要なデータを保持するページのみがクエリの間にページバッファ内にロードされる。ページロード可能列を実装するために、列の3つの補助データ構造は、ページの単位ごとに記憶およびアクセスされ得るページロード可能相対物として設計された。

【0057】

メインフラグメントはしばしば、デルタフラグメントよりもかなり大きいため、メインフラグメントは、圧縮のための自然な候補である。完全メモリ常駐列の場合、IMDBS100は、メインデータベクトルに対する5つの高度圧縮方法、すなわち、(1)プレフィックス符号化、(2)ランレングス符号化、(3)クラスタ符号化、(4)スパース符号化、および(5)間接符号化をサポートする。しかしながら、ページングデータベクトルの場合、これらの圧縮方法の組合せを使用することは、圧縮がもたらす、効率的なランダムページアクセスにおける課題により、(辞書圧縮およびnビット符号化を用いた均一圧縮を除いて)実現不可能である。これは、当然、PUPTEの解決対象とされる問題である。

【0058】

本文書の残りの部分は、以下の表記法を使用する:
n － データベクトル内の最大値のビット長。
S_min － 任意のチャンクが使用すべき最小空間量。
enc(n) － IMDBS100がサポートする最も遅い圧縮方法を使用してデータを符号化するランタイムであり、nは、データの長さである。
dec(n) － IMDBS100がサポートする最も遅い圧縮方法を使用して圧縮されたデータからの値を復号するランタイムであり、nは、データの長さである。

【0059】

図2は、インメモリデータベース用のメモリ管理の方法200のフローチャートである。方法200は、IMDBS100(図1を参照)によって、たとえば、メモリ管理システム130によって実行され得る。

【0060】

202において、データ列をページングデータベクトルに変換する。ページングデータベクトルは、上記で論じたように(また、以下でさらに詳述するように)に、PUPTEに従って生成される。手短に言えば、データベクトルはチャンクに分割され、チャンクは、ページと呼ばれるデータ構造内に記憶され、ページは、ページングデータベクトルを形成するように配置される。以下でさらに詳述するように、チャンクサイズ計算機132およびエンコーダ構成要素134(図1を参照)がこの変換を実装し得る。ページングデータベクトルは、二次記憶装置120内に記憶される。

【0061】

204において、ページングデータベクトル(202において生成された)からデータを読み取る。概して、これは、ページングデータベクトル内の適切なページを識別するステップ(デコーダ構成要素136によって実行され得る)と、識別されたページを二次記憶装置120からメインメモリ110内にローディングするステップ(ページローダ構成要素138によって実行され得る)とを必要とする。

【0062】

ステップ202は、たとえば、デルタマージ(以下でより詳細に論じる)の間の、またはデータベクトルがページングデータベクトルに変換される任意の他の時点における予備ステップまたはセットアップステップと見なされ得る。ステップ204は、たとえば、IMDBS100が、トランザクションデータ処理、解析データ処理など、そのデータ処理動作を実行する一環としての、動作ステップと見なされ得る。

【0063】

均一区分ツリー

【0064】

図3は、ページング均一区分ツリー(PUPT)とも呼ばれる、均一区分ツリー(UPT)300の論理表現のブロック図である。UPT300は、PUPTEメモリ管理プロセスにおいて使用されるデータ構造である。図3に示す特定のUPT300は、一例であり、ノード、参照、およびチャンクの特定の配置は、データベクトルの特質に応じて異なり得る。

【0065】

概して、UPT300は、データベクトルをツリーとして論理的に表す。ツリーは、ルートノード302を有し、子ノード304、306、308、310、312、および314としてここで示す、いくつかの子ノード(サブノードとも呼ばれる)を有し得る。UPTの各ノードは、データベクトル320のセグメントに対応し、さらに、データベクトル320が参照するデータを固定サイズのチャンクに均一に区分する。各チャンクは、選択されたサイズを有する。たとえば、データベクトル320は、16,000,000の長さの記録を有し、ノード302、304、306、308、310、312、および314は、4,000,000、1,000,000、1,500,000、200,000、500,000、500,000、および30,000のそれぞれのチャンクサイズを有する。ノードの最後のチャンクは、選択されたサイズよりも少数の値IDを有することが可能にされる。(ここで、子ノード306の最後のチャンクは、1,000,000値IDを有し、子ノード314の最後のチャンクは、20,000値IDを有する)。各ノードのコンテンツは、そのノードが表すデータのチャンクのリストである。特殊な事例では(以下で説明する)、1個のノード(親ノードと呼ばれる)のチャンクは、追加のノード(子ノード)によって表される。親ノードは、子ノードに対するリンクを有し、このリンクは、実線矢印によって表される。たとえば、ノード304は、ルートノード302の子ノードであり、ノード310は、ノード304の子ノードである。ルートノード302は、データベクトル全体に対応し、後続のノードは、前のノードのチャンクに対応する。本質的に、その場合、IMDBS100(図1を参照)は、データベクトル320全体を固定サイズのチャンクに均一に区分し、いくつかのチャンクは、(以下で詳述するように)必要な場合、さらに均一に区分され得る。無限の再帰を防ぐために、任意のサブノードは、サブノード内に少なくとも2個のチャンクが存在するように、その親のチャンクサイズ未満のチャンクサイズを使用する。反対に、データベクトル全体に対応するルートノード302は、1個のチャンクのみが存在するように、データベクトル全体のサイズに等しいチャンクサイズを使用し得る。そのような場合、IMDBS100は、上記で説明した均一圧縮(方法2)を使用してページロード可能列を実装し得る。

【0066】

UPT300の各ノードは、関連するチャンクサイズNを有し、場合によっては、各ノード内の最後のチャンク(ここでは、ノード306および314の最後のチャンク)を除いて、同じサイズのデータベクトル320のチャンクを含む。チャンクサイズは、ノードの深度とともに厳密に減少する。ノードのチャンク(実線矢印の先端における)は、そのチャンクが、まとまって、データベクトル320全体を形成するルートノード302を除いて、まとまって、(同じ矢印の末尾において)それが対応する、その親ノード内のチャンクをやはり形成する。例示的なUPT300内のノードは、多くのチャンクを含まないが、実際には、単一のノードは、数千のチャンクでないとしても、数百のチャンクを含む場合がある。

【0067】

各ノードを記憶するために、IMDBS100は、各チャンクに対して1つのページを割り振る。別のノードに対応しないチャンクの場合、IMDBS100は、そのチャンクに最適な符号化方式を使用して、そのチャンクを個々に圧縮し、圧縮されたチャンクを、そのチャンクに割り振られたページ内に記憶する。符号化方式全体をチャンクに対して使用される圧縮方法と区別するために、後者は、2次圧縮と呼ばれることがある。各ページ内に、IMDBS100は、いずれの他のページもロードせずに、そのチャンク内の任意の値を復号するために十分な情報を記憶する。次に、異なるチャンクは、(異なるチャンクサイズおよび異なる圧縮タイプにより)異なる空間量を通常必要とすることになり、各チャンクにページ全体を一度に割り振らなければならないことは、内部フラグメンテーションにより、すべてのチャンクに効率的に対応することを困難にする。幸い、IMDBSは、マルチサイズのページを使用して、圧縮されたコンテンツに適合するために十分大きな、利用可能な最小サイズのものである最も良く適合するページを各チャンクに使用させることによって、この課題を緩和するのを助ける。各ノードは、これにより、各チャンクに対して1つ、ページのシーケンスとして記憶される。UPT300全体を記憶するために、IMDBS100は、すべてのノードに対するすべてのページのシーケンスを一緒に単一のページチェーンに添付する。

【0068】

IMDBS100が、特定のチャンクに対して子ノードを使用することができる理由は、その特定のチャンクが、利用可能な最大ページサイズ内ですら適合し得る空間よりも多くの空間を必要とすることを記憶することである。そのようなチャンクは、特大と呼ばれる。たとえば、チャンク302a、302b、304a、304b、306a、および308aは、特大チャンクである。他のチャンクは、正規または正規サイズと呼ばれる。特大チャンクの場合、チャンクのデータをそのチャンクが属するノードとともに記憶する代わりに、IMDBS100は、特大チャンクに対して新しいノードを作成し、これにより、そのデータをページの別個のシーケンス内に再帰的に記憶する。たとえば、子ノード304は、特大チャンク302aに対して作成される。

【0069】

UPTは大きな高さ(たとえば、子ノードの複数のレベル)を有し得るため、どのノード内に行の値IDが記憶されているかを判定することは、ルートノードから開始して、親ノードから子ノードを繰り返し参照することを必要とすべきではない。これは、推定上、それぞれのそのような参照は、次のページにリダイレクトするためにディスクからページをロードすることを必要とし得るためである。これは、大きなメモリオーバーヘッドを用いる高価な動作である。代わりに、IMDBS100は、すべての非ルートノードがルートノードからアクセスされ得るように、特大チャンクのページ内の参照をルートノード内に記憶する。これらの参照は、図3において、ルートノード302からルートノード302に対する直接リンク(実線矢印によって示される)を有さない様々な子ノードへの破線矢印によって示される。

【0070】

さらなる実装詳細については、以下で論じる。

【0071】

ここでも、IMDBS100は、特大チャンクをサポートするために、ルートノード302に加えて子ノードを使用する。これらは、データベクトル320のうちのいくつかの部分が他の部分よりもかなり、具体的には、最大ページサイズと最小ページサイズとの間の比率よりも大きな倍率でより良く圧縮されている可能性があるときにのみ存在すべきであるが、これはまったく一般的ではない。したがって、多くの事例の場合、おそらく、データベクトルに対するUPTは、1個のノード(たとえば、ルートノード302)のみを有し、データベクトルは、一度のみ均一に区分され、これは、さらに単純な符号化および復号を伴う。特大チャンク処理を含めることは、PUPTEの実装がすべての例外事例を処理するようにするためである。IMDBS100が特大チャンクに遭遇するとき、IMDBS100は、複数のページを使用してそれを記憶するが、IMDBS100はまた、良好な圧縮率を維持し、同時に少数のページにアクセスし続けることになる。これは、PUPTEが、正にデータベクトル全体に対して、解決対象としたことであることを思い起こされたい。これは、符号化方式を再帰的にする動機であった。

【0072】

全体として、PUPTEプロセスは、先に説明したトレードオフを損なう。PUPTEプロセスの注目すべき特徴は、均一区分である。固定サイズのチャンクを有することは、IMDBS100が、単純な演算を用いて、どのチャンク内に任意の行の値IDが記憶されているかを判定することができることを意味する。各チャンクを1つのページ内に記憶することは、IMDBS100が、どのページをロードすべきかを直ちに判定することができることを意味する。同時に、IMDBS100は、値IDの2次圧縮方法を使用し続ける。

【0073】

最後に、辞書圧縮は、列が、浮動小数点型または可変長の文字列(varchar)など、異なるデータタイプを有する場合ですら、各データベクトルが実際には整数のみからなることを保証することを思い起こされたい。PUPTEは、(整数アレイである)データベクトルを圧縮するために具体的に考案されたが、固定サイズ値がそれらに対して使用するのに適している圧縮方法を有する場合、PUPTEは、固定サイズ値の任意のアレイと協働するように一般化され得る。

【0074】

図4は、インメモリデータベース用のメモリ管理の方法400のフローチャートである。方法400は、IMDBS100(図1を参照)によって、たとえば、メモリ管理システム130および他の構成要素によって実行され得る。方法200(図2を参照)と比較して、方法400は、動作中のIMDBS100を説明することにより関する。

【0075】

402において、ページングデータベクトルを二次記憶装置内に記憶する。(上述したように、この表現は、ページングデータベクトルが記憶されている、存在状態であることをやはり含む。たとえば、ページングデータベクトルが図2の202におけるように、前に生成されているとき。)たとえば、IMDBS100は、ページングデータベクトルを二次記憶装置120内に記憶することができる。ページングデータベクトルは、不均一圧縮を使用して圧縮されたいくつかのチャンクを含む。不均一圧縮については、以下でより詳細に論じるが、概して、少なくとも1個のチャンクは第1の圧縮タイプを使用して圧縮され、少なくとも1つの他のチャンクは第2の圧縮タイプを使用して圧縮される。(第1の圧縮タイプは、第2の圧縮タイプとは異なり得る。)たとえば、1個のチャンクは、プレフィックス符号化を使用して圧縮され得、別のチャンクは、クラスタ符号化を使用して圧縮され得る。これらのチャンクは、ページの数としてページングデータベクトル内に論理的に配置される(以下でさらに詳細に説明する)。ページングデータベクトルは、UPT300データ構造(図3を参照)に対応し得る。

【0076】

404において、データ要求を受信する。たとえば、データ処理構成要素140がデータ要求を受信し得る。データ要求は、トランザクション要求(たとえば、特定のデータ記録を編集、追加、削除するなどのための)、解析要求(たとえば、1つまたは複数のデータ記録に対するクエリを実行するための)などであってよい。

【0077】

406において、データ要求に関する複数のページのサブセットを識別する。たとえば、復号構成要素136が、データ要求に関する、二次記憶装置120内に記憶されたページングデータベクトル内の1つまたは複数のページを識別し得る。上述し、以下でより詳細に論じるように、列の異なる部分(たとえば、チャンク)が異なる圧縮タイプを使用して圧縮されるとき、これは不均一圧縮をもたらす。列が不均一に圧縮されているとき、特定のデータ記録を含むページの識別は、以下でさらに詳述するように、重要なプロセスである。

【0078】

408において、(406において識別された)複数のページのサブセットの少なくとも1つのページを二次記憶装置からメインメモリ内にロードする。たとえば、ページローダ構成要素138が、二次記憶装置120内に記憶されたページングデータベクトルからページをメインメモリ110内にロードし得る。

【0079】

410において、(408においてロードされた)メインメモリからの少なくとも1つのページを使用して、データ要求を実行する。たとえば、データ処理構成要素140が、データ要求を実行するために、メインメモリ110内にロードされたページ内のデータにアクセスし得る。データ処理構成要素140は、次いで、データ要求の結果(たとえば、クエリの出力など)をIMDBS100または他の構成要素に提供することができる。

【0080】

図5は、ページングデータベクトルを生成する方法500のフローチャートである。方法500は、202(図2を参照)のステップまたはサブステップとして実行され得る。方法500は、メモリ管理システム130(図1を参照)によって、たとえば、チャンクサイズ計算機132およびエンコーダ構成要素134を使用することによって、実行され得る。

【0081】

502において、データベクトルに関するチャンクサイズを計算する。データベクトルは、概して、列のデータ記録に対応し、二次記憶装置120内に記憶され得る。各チャンクは、データベクトルのセグメント(たとえば、1000個の行またはデータ記録)に対応する。チャンクサイズの計算は、サブステップ502a～502eを含む。

【0082】

502aにおいて、初期チャンクサイズを選択する。一例として、初期チャンクサイズは、データベクトルのサイズ全体の10%に設定され得る。初期チャンクサイズは、IMDBS100の構成要素の特性および性能に従って、必要に応じて調整され得る。チャンクサイズ計算機132が初期チャンクサイズを選択し得る。

【0083】

502bにおいて、ノードと呼ばれるデータ構造を形成するために(初期チャンクサイズに従って)データベクトルをチャンクに区分する。データベクトルがチャンクに等しく分割されていない場合、最後のチャンクは、チャンクサイズよりも小さくてよい。エンコーダ構成要素134が、データベクトルをチャンクに区分し得る。

【0084】

502cにおいて、各チャンクに対して好適な圧縮タイプを選択し、選択された圧縮タイプを使用して各チャンクを圧縮し、圧縮されたチャンクに対して様々な圧縮率を計算する。様々な圧縮率は、各チャンクに対する平均圧縮率R_avg、最小圧縮率R_min、および最大圧縮率R_maxを含み得る。この時点で選択される圧縮タイプは、(必要に応じて、初期チャンクサイズが最終チャンクサイズに調整されると)符号化プロセス全体をシミュレートするための初期圧縮である。概して、好適な圧縮タイプは、その特定のチャンクに対して最も適切な(たとえば、最高圧縮率をもたらす)圧縮タイプに対応する。たとえば、圧縮タイプのセットがチャンクに適用されてよく、最高圧縮率を有する圧縮タイプが選択されてよい。エンコーダ構成要素134が、好適な圧縮タイプを選択し、各チャンクを圧縮し、圧縮率を計算し得る。

【0085】

502dにおいて、圧縮率(502cにおいて計算された)を誤差許容値と比較する。この比較に基づいて、誤差許容値が満たされる場合、ターゲット圧縮率R_tarを最小圧縮率に設定し、またはさもなければ、ターゲット圧縮率を1に設定する。エンコーダ構成要素134が、誤差許容値を評価し、ターゲット圧縮率を設定し得る。

【0086】

502eにおいて、最大圧縮率R_maxおよび圧縮率Rに基づいて、ターゲット空間量S_tarを計算し、ターゲット空間量S_tarに適合する最小適合ページに基づいて、ページサイズMを計算する。次いで、ターゲット圧縮率R_tarを最小限にターゲットするように、チャンクサイズを計算する。

【0087】

504において、ページング均一区分ツリー(PUPT)データ構造(UPTデータ構造とも呼ばれる、図3を参照)を形成するために、チャンクサイズ(502において計算された)に従って、データベクトルを符号化する。符号化構成要素134(図1を参照)が、データベクトルを符号化し得る。データベクトルの符号化は、サブステップ504a～504dを含む。

【0088】

504aにおいて、ルートノードを空のページチェーンとして構築し、チャンクサイズ(502において計算された)に従ってデータベクトルを区分し、選択された圧縮タイプを使用して、各チャンクを一時的データ構造に符号化する。

【0089】

504bにおいて、特定のチャンクが正規サイズを有する場合(以下でさらに説明するように)、符号化データを一時的データ構造から最小適合ページ内に移動させ、そのページをページチェーンに添付する。

【0090】

504cにおいて、特定のチャンクが特大である場合(以下でさらに説明するように)、子ノードを参照して、空きページをページチェーンに添付する。

【0091】

ステップ504bおよび504cは、すべてのチャンクが処理されるまで続く。すべてのチャンクが処理されると、すべての正規サイズのチャンクは、一時的データ構造から移動されることになり(504bを参照)、特大チャンクのみが一時的データ構造内にある。

【0092】

504dにおいて、各特大チャンクを一時的データ構造から子ノード内に移動させることによって、各特大チャンクを再帰的に記憶する。以下でより詳細に説明するように、各子ノードがルートノードと同様に生成される(504a～504c)が、(データベクトル全体の代わりに)各特定の特大チャンクに適用される。

【0093】

これらのステップの結果として、ルートノード(および、任意の子ノード)は、図3のUPT300など、ページング均一区分ツリー(PUPT)に対応するページチェーンを形成する。

【0094】

チャンクサイズ選択

【0095】

このセクションは、チャンクサイズの判定(図5の502を参照)に関するさらなる詳細を提供する。チャンクサイズの選択に影響を及ぼす要因は、一般に、2つのカテゴリー、すなわち、(1)大きさ、および(2)整合に該当する。

【0096】

1.大きさ

【0097】

大きさ要因に関しては、より小さなチャンクサイズを選定するいくつかの理由は、以下の通りである。第1に、チャンクサイズは、明らかにノードの長さを超えてはならない。その上、特大チャンクを有する可能性がある場合、IMDBS100(図1を参照)は、無限の再帰を防ぐために、チャンクサイズが厳密にノードのサイズ未満であることを確実にする必要がある。これらは、いかなる状況の下でも破られるべきではない、厳密な上限である。

【0098】

第2に、より小さなチャンクサイズは、IMDBS100が一貫性のないパターンを有するデータを利用することを可能にする。システムが大きなチャンクを使用する場合、チャンク内のデータは、共通点を何も有さない可能性があり、圧縮を困難にする。代わりに、データベクトルを通して散在することを見出すことが可能な、短く、局在化されたどのようなパターンをも最適化して外すことを試行することのほうが良い可能性がある。このために、システムは、個々のチャンクが相関し、したがって、圧縮される可能性が高いように、より小さなチャンクを望むことになる。

【0099】

第3に、ロケーションオフセットまたは長さが記憶される符号化方式では、IMDBS100は、データベクトルまたはノードの開始の代わりに、チャンクの開始から参照することを選定することができる。より小さなチャンクサイズの使用は、これらの値を記憶するためにより少数のビットを必要とすることになる。

【0100】

より大きなチャンクサイズを選定するいくつかの理由は、以下の通りである。第1に、より小さなチャンクサイズは、より多くのチャンクの使用をもたらし、これは、より多くのページの使用をもたらすことが認められる。したがって、より小さなチャンクの使用は、より小さなページが使用された場合のみ有利であり得る。しかしながら、チャンクサイズが小さすぎて、チャンクが利用可能な最小ページサイズを使用することができない場合、チャンクサイズのさらなる削減には何の利点もないことになる。そうすることは、同じサイズのページを使用し続けさせることになるが、より多くのページを有することは、空間を不要に無駄にする。したがって、システムは、理想的には、どのチャンクも小さすぎる空間を必要としないように、チャンクサイズが十分大きいことを確実にすることを望むことになる。

【0101】

第2に、チャンクサイズが小さすぎる場合、システムは、潜在的に非常に良く圧縮される可能性があるデータセットに対してそれほど空間を節約することができないことになる。たとえば、システムが、1個のチャンクの空間を使用するために、10,000の値ごとに圧縮することができると仮定する。システムが1,000のチャンクサイズを使用する場合、同じ空間量を節約するためには、単に0.1値を用いる1,000の値ごとに記憶する必要があり、本発明者らは、これは不可能であると仮定し得る。概して、より大きなチャンクサイズの使用は、チャンクの最大圧縮率を増大させる。

【0102】

要約すれば、以下の点は明らかである。第1に、チャンクサイズに対して厳密な上限が存在する。この上限は、データベクトルの長さ以下でなければならず、特大チャンクが存在する場合、厳密にデータベクトルの長さ未満でなければならない。

【0103】

第2に、チャンクサイズに対して好ましい下限が存在する。この下限は、最も圧縮されたチャンクが小さすぎる空間を使い尽くさないように十分大きくあるべきでる。これは、小さなチャンクサイズに関する両方の懸念事項に偶然対処する。

【0104】

第3に、より小さなチャンクサイズを使用する一般的な理由が存在する。低い相関を有するデータは、より良く圧縮される可能性が高いが、これは、個々のより小さなチャンクは、それらの中に共通のパターンを有する可能性が高いためである。また、位置および長さなど、一定の量は、より大きなコンテナ(たとえば、チャンク、ノード、またはデータベクトル)より小さなコンテナを参照するとき、より少数のビットが記憶される必要がある。

【0105】

考慮に入れられていない多くの他の懸念事項が存在し得るが、これらの少数の懸念事項は、目指す一般的なガイドラインをIMDBS100に提供し、ほぼすべてを偶然同時に満たす。システムは、上限および下限内の最小チャンクサイズを利用することを目指すべきであり、上限および下限が競合する場合、上限が優先される。これは、データが良く圧縮されないとき、より小さなチャンクサイズを選ぶことに利点がないためである。

【0106】

2.整合

【0107】

整合要件に関しては、データベクトルのデータ分布に応じて、IMDBS100は、IMDBS100がいかにチャンクサイズを判定しようと、ノード内の多くのチャンクは、およそ同じ空間量を必要とすることを見出すことができる。そのような場合、IMDBS100は、メモリオーバーヘッドを最小限に抑えるために、各チャンクの空間が利用可能ページサイズのうちの1つを事実上満たすことを確実にするために、その選択肢を若干調整することができる。このプロセスは、整合と呼ばれる。異なるチャンクによって使用される空間内に大きな差異が存在する場合ですら、IMDBS100は、圧縮不可能なチャンクに対して依然として整合を使用することを試みる場合があるが、これは、IMDBS100がこれらのチャンクは常にサイズの点で固定されていることを認識しているためである。IMDBS100は、この整合を行うとき、すべてのチャンクをやはり明らかにすべきであることに留意されたい。IMDBS100は、平均空間を必要とするチャンクが整合されることを必ずしも望むとは限らない場合があるが、これは、それよりもやや多くの空間を使用するいずれのチャンクも次に大きなページサイズを使用することになるためである。

【0108】

要約すれば、優先順位で満たされなければならない基準は以下の通りである。基準1:IMDBS100は、チャンクサイズが、ノードの長さ未満であり、特大チャンクが存在する場合には厳密にノードの長さ未満である、上限を満たすことを確実にすべきである。基準2:IMDBS100は、大部分のチャンクがそれらのチャンクが割り振られたページをほぼ最大限に満たすような整合を使用すべきである。基準3:IMDBS100は、最小量の空間を使用するチャンクですらそれらのチャンクが割り振られたページのかなりの割合を満たすことを確実にすべきである。基準4:IMDBS100は、他の懸念事項が同じであるとき、より大きなチャンクサイズと比較してより小さなチャンクサイズを選好すべきである。

【0109】

基準2(整合)を満たすことがどういう意味であるかを理解するために以下の定義を使用する。

【0110】

定義:ページに整合する。チャンクサイズNは、チャンクがサイズMのページ内をほぼ完全に満たす場合、圧縮率Rに対して、サイズMのページに整合される。方程式としては:

【0111】

【数1】

【0112】

チャンクによって使用される正確な空間の代わりに、圧縮率(非圧縮/圧縮)を扱うほうがより好都合であるが、これは、IMDBS100がチャンクサイズを変更するとき、使用される空間も変更するためである。他方で、圧縮率は、チャンクサイズと無関係である(大部分に関しては、以下の代替実施形態を参照されたい)。

【0113】

本発明者らは、次に、基準3(空間量)を満たすための要件を審査する。以下のTABLE 1(表1)は、必要とされる空間の異なる範囲に対して使用される空間パーセンタイルの範囲を要約する。

【0114】

【表1】

【0115】

TABLE 1(表1)から、最小ページサイズが割り振られているときのみ、ページの25%未満が使用される機会が存在する(利用可能ページサイズの粒度に基づいて、より良い結果すら達成され得る)ことが分かる。したがって、IMDBS100は、すべてのチャンク、詳細には、大部分の圧縮可能なチャンクによって使用される最小空間が最小ページサイズの少なくとも25%であることを確実にするためのインセンティブを有する。任意のチャンクに対する最小許容空間は、以下の方程式に従って計算される。
S_min=25%×4kB=1kB

【0116】

したがって、少なくとも
S_unc=R_maxS_min
を使用するために、非圧縮チャンクが必要である。

【0117】

概して、Rの圧縮率を有するチャンクは、少なくとも

【0118】

【数2】

【0119】

を使用すべきである。

【0120】

定義:圧縮率を最小限にターゲットにする。圧縮率R、R_maxおよびS_minを仮定すると、チャンクがサイズMのページにほぼ完全に適合するページサイズMが存在する場合、チャンクサイズNは圧縮率Rをターゲットにする。その上、本発明者らは、圧縮率R_maxを有するチャンクが、少なくともS_min空間を使用し、可能な最小のそのようなチャンクサイズであるという最低要件をやはり保証する場合、Nは、Rを最小限にターゲットにすると断言する。このNを判定するために、IMDBS100は、

【0121】

【数3】

【0122】

よりも大きい最小ページサイズMを計算し、次いで、サイズMのページに整合するチャンクサイズを利用する。

【0123】

単に1/Rに圧縮されたチャンクがより大きなページサイズよりも多くの空間を使用するように、R_max>>Rである場合、そのような有効なNは存在しないことに留意されたい。この場合、IMDBS100が、R_maxによって圧縮されたチャンクがあまりにも小さすぎる空間を使用しないことを確実にすることを試行する場合、Rによって圧縮されたチャンクは、特大になる。さもなければ、各Rに対して、1つのそのようなNのみが存在する。

【0124】

S_minを、チャンクに対して対応するページがあまりにも多くの空間を無駄にしない最小空間とする。S_minに対して好適切な候補は、1kBである。

【0125】

チャンクサイズを選択するために、IMDBS100は、まず、データベクトル内の異なるチャンクの平均圧縮率、最小圧縮率、および最大圧縮率、すなわち、R_avg、R_min、およびR_maxのいくつかの測定値をそれぞれ判定する。これを行うために、IMDBS100は、いくつかの初期チャンクサイズを選択し、符号化方式をシミュレートして、最善の圧縮方法を使用して、各チャンクを符号化するために必要とされる空間を計算する。IMDBS100は、次いで、これらの結果を集約して、必要とされる空間の観点から概略測定値を判定し、次いで、圧縮率に対応する相対物を計算する。

【0126】

次に、IMDBS100は、ほとんどが整合を必要とする、いくつかの圧縮率を最小限にターゲットにすることによって、基準2～4を満たすように動作する。チャンクサイズ内に平均からあまりにも大きな差異が存在する場合、IMDBS100は、圧縮不可能なチャンクが最も利益を得るように、整合のためにR=1をターゲットにするように動作する。これは、同じ量の空間を使用することが保証されているチャンクのみが圧縮不可能であるためである。他方で、チャンクサイズ内の差異がかなり小さい場合、IMDBS100は、R_avgに近い、何らかの専用ターゲット率R_tarをターゲットにするように動作する。概して、システムは、平均よりも大きい空間を使用する(または、等しく、平均よりも小さな圧縮率を有する)チャンクに関心があるが、これは、整合を適切に制御しない場合、これらのチャンクが平均チャンクとして、最高で4倍までのページを使用する機会を有するためである。したがって、IMDBS100は、圧縮率のより低い変動(variability)のみを測定する。変動を明らかにする1つの選択肢は、平均からの圧縮率の最大下位偏差R_error=R_avg-R_minを測定することである。R_errorがかなり小さいとき、IMDBS100は、最大チャンクが最も整合を受けることになるように、R_tar=R_minを利用するが、R_avgによって圧縮された平均チャンクは、大きく外れすぎるべきでもない。次に、R_errorが増大するにつれ、R_avgはR_minからさらに増大し、R_avg圧縮性を有するチャンクはより少なく満たされ、それらのページも減り、これは望ましくない。IMDBS100は、概して、整合を使用しない場合よりも、整合がより多くの空間を節約することになる場合、R_errorは整合を使用するために十分小さいと見なすことができる。すべてのページは少なくとも25%から100%満たされるべきであり、したがって、平均で62.5%満たされるべきであること思い起こされたい。圧縮性R_minを有するチャンクがそれらのページを満たすと仮定すると、本発明者らは、以下を望む:

【0127】

【数4】

【0128】

最後に、R_tarを最小限にターゲットにするチャンクサイズが存在する場合、IMDBS100は、チャンクサイズとノードの長さとの間で最小値になるNを利用する(基準1)。さもなければ、1/R_tar以下に圧縮されたチャンクは特大でなければならず、したがって、IMDBS100は、わざわざ整合を行わない。整合は使用しないが、最小サイズ要件を依然として満たし、可能な限り小さな区分サイズ(基準3および4)は、以下の通りである。

【0129】

【数5】

【0130】

チャンクは特大であり得るため、IMDBS100は、専用の上限を実装して、ノードの長さの半分とこの値の間の最小値を利用することによって、無限の再帰を防ぐ。

【0131】

図6は、コードリスティング600である。コードリスティング600は、チャンクサイズ選択プロセス(上記で、また図5の502においても説明した)の完全記述を疑似コードで提供する。

【0132】

上記で説明したプロセスによるチャンクサイズ選択は、チャンクに直接的に圧縮方法を本質的に適用することによって、各チャンクがどの程度の空間を使用することになるかの判断を必要とする。これらの結果および他の演算を集約する次のステップは、すべて一定時間を使用する。

【0133】

各チャンクはサイズNを有し、

【0134】

【数6】

【0135】

個のチャンクが存在する。したがって、すべてのチャンクを記憶することは、以下の方程式を仮定すると、時間的な複雑性を有する。

【0136】

【数7】

【0137】

符号化は、データベクトルの各値を少なくとも一度考察することを必要とするため、以下であることが分かる:
enc(n)∈Ω(n)

【0138】

したがって、あまり正確ではないが、より便利には、Nにかかわらず、チャンクを記憶することは以下であると言うことができる:
O(enc(L))

【0139】

NはL以下であるため、上記は、データベクトル全体を符号化する実行時間に等しいことを示唆する。これはまた、チャンクサイズ選択の実行時間でもある。

【0140】

符号化

【0141】

このセクションは、符号化プロセス(図5の504を参照)に関するさらなる詳細を提供する。上述のように、この符号化プロセスの結果は、データベクトルを含むPUPTEデータ構造(図3を参照)である。

【0142】

IMDBS100(図1を参照)は、ルートノード(図3の302を参照)から開始して、一度に1個のノード単位でデータ構造の符号化を実行する。IMDBS100は、空のページチェーンから開始する。各ノードに関して、IMDBS100は、まず、上記で説明したプロセス(たとえば、図5の502、図6のリスティング600、および関連テキスト)を使用して、ノードに関するチャンクサイズを選択する。次いで、ノード内の各チャンクに対して、IMDBS100は、それに対して使用され得る最適圧縮方法を用いて、任意に大きくてよい一時的データ構造にチャンクを符号化する。(図の504aをやはり参照。)次いで、IMDBS100は、この符号化チャンクがどの程度の空間を使用するかを測定し(このチャンクが正規であるかまたは特大であるかを判定するために)、それがどのタイプであるかを指示するビットフラグを設定する。チャンクが正規である場合、IMDBS100は、符号化データを一時的データ構造の最小適合ページ内にコピーし、このページを実行ページチェーンに添付する。(図5の504bをやはり参照。)さもなければ、IMDBS100は、空きページをチェーンに添付し、このチャンクが、特大であったこと、およびより小さなチャンクを使用して後で再帰的に記憶される必要があることを記録する(キューに添付する)。(図5の504cをやはり参照。)現在のノードがルートノードである場合、最終的に、IMDBS100は、このページ内の他のノードに対する参照を記憶することになる。さもなければ、この空きページは、ほとんどの部分に対して未使用であり得るが、これは、実際のデータがページの別のシーケンス内に記憶されることになるためである。このページをデータ構造で均一に維持させることは依然として有用である。これは一定の空間を無駄にする可能性があるが、このチャンクが特大であり、最大ページにすら適合し得ないことを仮定すると、その空間は、使用される量の割にはあまり多くない可能性がある。IMDBS100は、他のメタデータをこのページ上に記憶することによって、この課題を軽減し得る。

【0143】

ノード内のすべてのチャンクが処理された後で、IMDBS100は、返信用に標示された各特大チャンクの再帰的な記憶に進む。(図5の504dをやはり参照。)現在のノードがルートノードでない場合、IMDBS100はまた、このノードに対する参照をルートノード内の正確なページ内に添付する必要がある。このページは、その対応するチャンクがこのノードに対応する(サブ)チャンクを含むページであるべきである。この参照は、形式のタプル(s、e、N、p)であり得、ここで、sおよびeは、ノードの開始行および終了行であり、Nは、ノードのチャンクサイズであり、pは、ノードの論理ページ数である。復号のための情報を提供するために、代替形態が使用されてもよい。参照をこのノードに追加することは、このノードのすべての子ノードが再帰的に符号化された後に生じるべきである。このように、子ノードに対する参照は、親ノードの参照前に生じる。最終的に、挿入の順序により、ルートノード内のノード参照リストは、降順でソートされる1次キーとしてe、および、昇順でソートされる2次キーとしてsを用いて順序付けされるべきである。この順序は、(1)先行ノードが、ソート順序で次に来るノードの前に生じること、および(2)子ノードが親ノードの前に生じることを確実にする。

【0144】

ページチェーンに関するメタデータは、少なくとも、N_root、L、およびn、すなわち、ルートチャンクサイズ、データベクトルの長さ、およびビット長からなり得る。

【0145】

図7は、コードリスティング700である。コードリスティング700は、符号化プロセス(上記で、また図5の504においても説明した)の完全記述を疑似コードで提供する。

【0146】

符号化に関する複雑性解析

【0147】

このセクションは、空間目的と時間目的の両方で、PUPTEページ生成プロセス(図5の500、および上記の関連テキストを参照)の複雑性について論じる。

【0148】

空間に関しては、PUPTEがどの程度の空間を節約できるかの正確な測定値を提供することは困難であるが、これは、データ分布および採用される圧縮方式に大きく左右されるためである。しかしながら、最悪の場合ですら、PUPTEを使用したIMDBS100(図1を参照)の空間消費は、ページロード可能列プロセス(上記で論じた方法2)の空間消費未満になると予想されるが、これは、PUPTEプロセスが、最悪の場合、ページロード可能列にフォールバックし得るためである。最悪の場合、何のチャンクも圧縮され得ず、したがって、IMDBS100は、非圧縮チャンクに対して整合されたチャンクサイズを選ぶ。結果は、すべてが可能な限り非圧縮nビット符号化値で満たされた同じサイズのページである。これは、データベクトル全体にわたるnビット符号化に等しい。一般的な事例では、当然、PUPTEは、ページロード可能列プロセスよりも良い性能を提供するが、これは、IMDBS100が、可能なときはいつでも、データベクトルのチャンクに(たとえば、圧縮を介して)2次符号化方式を適用するためである。圧縮チャンクが非圧縮チャンクよりも小さなページに適合し得る限り、これは空間を節約する。ここでも、使用される正確な空間量は、データおよび圧縮方法に依拠するが、これは、ページロード可能列(均一圧縮を使用し、ゆえに、2次圧縮を使用しない)の大きさ未満の大きさ程度であってよい。

【0149】

PUPTEでは、データは、ページ上に一度に記憶されなければならないため、節約される平均空間量は低減され、潜在的に、多くの内部フラグメンテーションをもたらすが、チャンクサイズの選択肢がこの軽減に役立つ。データベクトルの長さが、チャンクサイズの正しい選択肢により、IMDBS100がすべてのチャンクがそれらの割り振られたページ内の空間の少なくとも最小しきい値を使い尽くすという所望の条件を満たすことが可能であるために十分長いと仮定しよう。本発明者らの事例では、発明者らは、すべてのページが少なくとも25%満たされていることを望んだ。これは、割り振られた空間が要求される空間の4倍以下であることを意味する。したがって、PUPTEにおける圧縮率の効果は、依然として、いずれのページ内でも、何の空間も無駄にされなかった場合にそれらの圧縮率が理論的に効果的であり得る率の少なくとも25%である。たとえば、データベクトルが1/20に圧縮され得る場合、PUPTE符号化方式を適用するとき、最悪の場合、少なくとも1/5の圧縮を予想することができる。

【0150】

本発明者らは、多くの事例において、より良い結果を予想する。IMDBS100は整合を使用するため、異なるチャンクの圧縮性が異なりすぎない場合、チャンクのほとんどはそれらのページ全体をほぼ満たすはずである。圧縮性に一貫性がない場合ですら、PUPTEプロセスは、依然として、非常に良い性能を有し得るが、これは、1個のチャンクが十分に圧縮され得ない場合、これが圧縮されるべき別のチャンク能力に直接的に影響を及ぼさないように、IMDBS100がチャンクを別個に圧縮するためである。実際に、IMDBS100は、ページングを必要としないページロード可能列を用いるよりもさらに良く実行することができる。これは、ページロード可能列プロセスを用いた符号化は、データベクトル全体にわたって単一の圧縮方法を使用し、データベクトルの別個の部分に対して異なる圧縮方法を使用することが好ましいことになる状況において不十分であり得るためである。また、概して、IMDBS100における2次圧縮方法のうちのいくつかは、長さまたは位置オフセットの記憶に依拠する。これらの値がデータベクトル全体ではなくより小さなチャンクを参照するとした場合、これらの値は、より少数のビットの記憶を必要とすることになる。

【0151】

時間に関して、データベースシステム内のディスクI/Oは、メモリI/Oよりもかなり高価であり、したがって、構築ランタイムにおいてディスクへの書込みは障害である。ディスクに書き込む時間は、符号化PUPTEデータ構造によってどの程度のページ空間が使用されるかに左右される。これは、使用されるすべてのページの総サイズまたは使用されるページの総数の組合せであってよい。PUPTE符号化方式は、最終的に、データを圧縮し、空間を節約するため、これは、ページ書込み時間をやはり削減する。

【0152】

メインメモリ上で動作するプロセスの残りに関しては、各チャンクを符号化することは、まずチャンクサイズを選択すること(図5の502を参照)と、その後に、実際のコンテンツを記憶すること(図5の504を参照)とを必要とする。チャンクサイズ選択の一部は実際のコンテンツの記憶に似ているが、まったく同一ではなく、その理由は、チャンクサイズ選択は再帰的記憶の複雑性を回避するためであり、これは、再帰的記憶は必要とされる空間の近似値を求める必要がないことによる。ツリー構造(図3を参照)の各レベルにおいて、どういうわけかすべてのノード内のすべてのチャンクが特大であった場合、レベル内の各ノード内のチャンクは、データベクトル全体を作り上げるための組合せほど悪くない可能性がある。これは、時間解析に関して上記で説明したように、チャンクサイズの選択と、実際のコンテンツの記憶の両方のために、各レベルにO(enc(L))の追加時間を加える。その上、UPTは制限された高さを有するため、これが生じ得る回数は有限である。サブチャンクサイズは常に前のチャンクサイズのせいぜい半分であることを思い起こされたい。また、必要とされる最大チャンク空間と必要とされる最小空間との間の比率が、それらの例示的なページサイズの場合は1024である、許容最大空間(最大ページサイズ、たとえば、1MB)と許容最小空間(たとえば、1kB)との間の比率を超える場合、特大チャンクのみを有し得ることを思い起こされたい。次いで、チャンクサイズが1024未満である場合、それ以上の特大チャンクを有することは決してないはずである。最後に、一実施形態では、データベクトルの最大長は2³²であってよい。したがって、最大高さは、以下である:
log₂ L-log₂ 1024≦32-10=22

【0153】

したがって、符号化は、0(enc(L)・logL)である。

【0154】

復号

【0155】

このセクションは、PUPTデータ構造からの読取り(図4の406～408を参照)に関するさらなる詳細を提供する。このプロセスは、復号と呼ばれる。PUPTデータ構造からの読取りは、概して、所与の行位置における値を見出すことを必要とする。このプロセスは、概して、次の通りである。第1に、IMDBS100(図1を参照)は、所与の行位置における値を含む、PUPTデータ構造内のチャンクを判定する。第2に、IMDBS100は、そのチャンクを有するページをロードする。第3に、IMDBS100は、ロードされたページから値を読み取る。

【0156】

より具体的には、IMDBS100は、以下のプロセスを使用して、所与の行に対する値IDを取り出すことができる。IMDBS100はセットR内のすべての行に対する符号化データベクトル内の値IDを取得するように命令されると仮定する。これを効率的に行うためには、IMDBS100がいずれかの(サブ)チャンクPに関するページをロードして、何らかの行に関する値r∈P∩Rを取得するたびに、IMDBS100は、rに関する値IDを取得するだけではなく、P∩R内のすべての行も取得する。このように、IMDBS100は、Pに対するページを複数回ロードしなくてよい。

【0157】

IMDBS100は、ルートノード(たとえば、302)からPUPTデータ構造を一度に1個のチャンク単位でトラバースすること(図3を参照)によって開始する。IMDBS100は、まだ問い合わされていない最小行rを探し、その行と同じチャンクP内のすべての行に対する値を取得し、繰り返す。

【0158】

Pが正規のチャンクである場合、P内に含まれるすべての行は、IMDBS100がロードしたばかりのページ上に記憶されるべきであり、したがって、所望の値をロードすることは非常に容易である。

【0159】

さもなければ、Pは特大チャンクであり、その値は、ノードおよびページの階層内に記憶され得る。行に対してロードすべき正確なページは、任意のノードのページのシーケンス内の任意の深度にあってよく、IMDBS100は、以下のプロセスを実行して、どのページかを判定する。

【0160】

Pはルートノード内にあるため、ロードされたばかりのページは、Pのすべてのサブノードの参照タプルのリストを含む(符号化セクションにおいて上記で述べたように)。その上、このリストは、その境界が所与の行を包含する第1のノードが、その行が記憶されるノードであるようにソートされる。これは、親ノードの境界は子ノード内に記憶された行をやはり包含するが、PUPTデータ構造内で、子ノードは、常に、本発明者らの参照リスト(チャンクサイズ選択セクションにおける上記の議論を参照)内でそれらの親の前に生じるためである。概して、行の値は、その境界がその行を包含する最深ノード内に記憶される。正確な参照タプルを見出すために、IMDBS100は、その開始行が、IMDBS100が探索している行以下である第1のノードに達するまで、順方向に連続的に反復する。IMDBS100は、ノード参照から、そのノードが記憶されているどのページから開始するかを知る。

【0161】

したがって、特大チャンクP内のすべての行を探索するためのこのプロセスは、データベクトル全体にわたる探索と同様であるが、1つの決定的な違いは、IMDBS100は、常に、その行を実際に記憶するノードを調査するため、IMDBS100は、それ以上特大チャンクに遭遇すべきでない点である。第1に、IMDBS100は、まだ問い合わされていないP∩R内の最小行を探す。次いで、IMDBS100は、その行が記憶されているノードLおよびL内のチャンクP'を判定する。次いで、IMDBS100は、P'を表すページをロードし、P'∩R内のすべての行に関する値を取得する。次いで、IMDBS100がP∩R内のすべての行に関する値を取得するまで、IMDBS100はこれらのステップを繰り返す。

【0162】

ページから値を取得するとき、IMDBS100は、そのチャンク上で使用されたどの圧縮方法にも固有の既存の復号アルゴリズムに従ってこれを行う。これらは、IMDBS100が探索している行のセットが範囲である場合に最適化され得る。値がどのように符号化されるかに応じて、このプロセスは、ランダムアクセスよりもシーケンシャルアクセスに対してはるかに効率的であり得る。

【0163】

全体的な複雑性解析

【0164】

このセクションは、ページロード可能列プロセスなど、他の既存のプロセスと比較して、PUPTEプロセスにおける性能について論じる。

【0165】

まず、単一の行に関する値IDを取得する性能を評価する。上記の符号化に関する複雑性解析のセクションにおける説明と同様、行アクセスの間の障害となる動作は、ページのロードである。上記の復号セクションにおいて説明したプロセスを参照すると、これは、1つのページロードまたは2つのページロードのいずれかを要する。IMDBS100(図1を参照)は、まず、ルートノードから1つのページをロードし、これは、すでに所望の行を記憶する正確なページであり得る。さもなければ、IMDBS100がロードしたページは、1つの追加ページロードを伴う、正確なページにIMDBS100を導くディレクトリページに対応する。しかしながらしばしば、特大チャンクを有することはあまり一般的ではないため、UPTツリー構造(図3を参照)は、単一のノードのみを有することになり、この場合、常に1つのページロードのみで十分である。しかしながら、比較すると、既存のページロード可能列プロセスは、すべての事例に対して1つのページロードが十分であることを保証する。

【0166】

次に、ローディング動作を考慮せずに、ランタイムを解析する。最悪の場合、行が記憶されたノードを識別することは、ディレクトリページ内の参照リストから索引付けすることを必要とする。これは、参照タプルの一般的なロケーションを与えるために二分探索と、その後に、探索範囲を絞るための線形探索とを必要とする。二分探索はすべてのノード参照タプルにわたり、これは、ノードの数に対して対数的な(logarithmic to)時間的複雑性を有する。線形探索は、最悪の場合、ツリー内のすべてのノードにわたってのみ実行され得る。上記の符号化に関する複雑性解析のセクションでは、本発明者らは、ツリーの高さはO(logL)であることを示したが、これは、ノードの数がO(L)であることを示す。したがって、ノードに対する総探索時間は、0(L)である。IMDBS100がノードを識別した後で、IMDBS100は、0(1)算術を有するチャンクを判定することができる。最後のステップは、O(dec(N))、または単にO(dec(L))である、チャンク内の値を復号することである。したがって、全体として、単一の行の値を取得するための時間的複雑性は以下の通りである:
O(L)+O(dec(L))

【0167】

概して、ノードの数は、小さな一定値にはるかに近いことになり、したがって、平均性能はむしろ以下のようになる:
O(dec(L))

【0168】

しかしながら、IMDBS100が複数の値を一度に問い合わせる場合、ページロード数と一般的な時間的複雑性の両方においてさらにより良い性能を期待することができる。復号プロセスは、IMDBS100が同じページに2度アクセスする必要がないことを確実にし、さもなければ、ページが最初に使用された後でページバッファから排除され、後で再度ロードされた場合、性能悪化のリスクがあり得る。現在のページングデータベクトルもここからやはり利益を得るが、クエリ値の多くが同じページ内に記憶されている場合、特に、各ページ上により多くの値を圧縮することができるPUPTEプロセスの場合、より有益である。行がどのページ上にあるかを判定し、そのページをロードするコストは、複数の行にわたって共有されることになり、どの行が同じページ上にあるかを判定するわずかな追加コストがこれに伴う。特に、たとえば、範囲走査を行う場合のように、IMDBS100が問い合わせている行が連続する場合、ページ内の値を復号する平均ランタイムを改善することもできる。多くの行を読み取ることで、シーケンシャルアクセスにさらなる用途が存在し、その用途は、ページに対応するチャンクに対して使用される圧縮方法に応じて、ランダムアクセスよりもはるかに効率的であり得る。

【0169】

代替実施形態

【0170】

このセクションは、IMDBS100(図1を参照)に関する様々な代替実施形態について論じる。

【0171】

第1に、結果としてもたらされる、向上された簡単さ、および最悪の場合のよりわずかに良い符号化性能および復号性能により、PUPTデータ構造(図3を参照)に常に1個のノードのみを使用させることが好ましい場合がある。これは、最大または最小の圧縮可能なチャンクのみを有するチャンクサイズを選択することを念頭に入れ、最大ページサイズ内に適合することが可能になることを確実にすることによって達成され得る。このように、ルートノード内のどのチャンクも特大ではあり得ない。チャンク同士の間で必要とされる空間の範囲があまりにも大きすぎるとき、これは、効率的な記憶装置を提供しないという代償を伴う。きわめて小さい可能性があるチャンクは、それらのチャンクが実際にはそれよりもはるかに少ない空間を必要とする場合ですら、依然として、少なくとも最小ページサイズを使用しなければならないことになる。比較して、上記で論じたチャンクサイズ選択プロセス(図5の502、図6、および関連テキスト)は、最小チャンクを念頭に入れ、それらのチャンクが、特大チャンクを可能にする代償を伴って、あまりにも多くの空間を無駄にしないことを確実にする。

【0172】

次に、ノード内のチャンクが特大である場合、その実際のコンテンツが異なるノード内に記憶されることになるとしても、依然として、そのチャンクにはノード内のすべての他のチャンクのようにページが割り振られる。このチャンクがルートノード内にない限り、そのチャンクに割り振られるページは、記憶するものを何も有さない。実際に、復号プロセスの一環としてそのページは必要でないため、そのページは決してロードされることすらないことになる。これは、当然、空間の無駄をもたらす。あるいは、IMDBS100は、チャンクが対応することになる子ノードに関するものなど、ページ内にいくつかの剰余メタデータを記憶することができる。別の解決策は、IMDBS100が、ページチェーン内にヌル参照またはヌルポインタなどの空きページを有することであるが、この実現可能性は、ページングシステムの実装に左右される。最終的に、IMDBS100は、子ノードが記憶するために1つ少ないページを有するように、子ノードのいくつかの(たとえば、第1の)サブチャンクをこのページ内に記憶することができる。これは、復号プロセスをさらに複雑にする可能性があるが、それぞれの追加ノードに対して空間の1つのページを節約すべきであり、より多くのページロードまたは他の劇的な性能影響をもたらすべきではない。

【0173】

別の考慮事項は、より少ない空間を必要とするチャンクは、使用すべきより小さなページが存在する場合のみ空間を節約することである。したがって、無駄にされる空間を最小限に抑えることは、ページサイズの可用性の主な問題である。これは、範囲と粒度の両方に関する。範囲は、最小利用可能ページサイズおよび最大利用可能ページサイズの大きさを指す。あまり多くの空間を使用しないチャンクに不要に大きなページを使用させないように、最小ページサイズはより小さいほうが良い。データ構造を再帰的かつより複雑にする特大チャンクを有するより小さな機会が存在するように、最小ページサイズと最大ページサイズとの間に大きな差異があるほうが、やはりよりわずかに良い。他方で、粒度は、連続するページサイズのサイズの差異がどの程度小さいかを指す。単にわずかに小さい場合であっても、チャンクがより良いページサイズを使用することができるように、ページサイズの粒度は高いほうが良い。たとえば、既存のインメモリデータベースシステムによれば、最初のいくつかのページサイズは、前のページサイズよりも4倍大きい。その場合、チャンクがこれらのページ上に記憶された別のチャンクよりも3倍小さい場合ですら、そのチャンクが同じページサイズを使用することは可能である。そのチャンクがより小さなページを使用することができる前に、最高で4倍小さくなる必要がある。これらの課題を解決するために、IMDBS100の代替実施形態は、より多くのページサイズを追加し、これは、基礎となるページングシステムを変更する。

【0174】

最後に、上記で論じたチャンクサイズ選択プロセス(たとえば、図5の502、図6、および関連テキスト)には非効率が存在する。PUPTEプロセスの背景にある発想は、まず、任意の初期チャンクサイズを選び(図5の502aを参照)、次いで、ノードをそのチャンクサイズで区分した場合、チャンクがどの程度圧縮可能であるかについての概要統計を集約した(502dを参照)ことを思い起こされたい。IMDBS100は、次いで、それらの概要統計に最も適したチャンクサイズを選ぶ(502eを参照)。しかしながら、実際には、異なるチャンクサイズの使用は、各チャンクのコンテンツを変更させる。したがって、1つのチャンクサイズに関する圧縮率は、常にもう1つのチャンクサイズに関する圧縮率を良好に推定するとは限らない。PUPTEプロセスは、IMDBS100がチャンクサイズを変更するにつれて、チャンクの圧縮率は一定状態にとどまるという仮定の下で最大限に有効である。これは、多くのデータ分布の下で有効であり得るが、当然、すべての場合ではない。これは、初期チャンクサイズがデータベクトルのグローバル圧縮率の不良反映をもたらす場合、特に問題である。簡単な例として、100,000分の1に圧縮され得るデータベクトルを考慮する。IMDBS100が単に1000の初期チャンクサイズを選ぶことによってデータベクトルを解析する場合、各チャンクは、おそらく、1000分の1を超えて圧縮され得ず、これは、データベクトル全体が十分に圧縮され得る程度からかけ離れている。この課題に対処するために、IMDBS100は、複数の初期チャンクサイズを用いて符号化プロセスを複数回実行し、最高圧縮を有する結果を選択することができる。

【0175】

結論

【0176】

要約すれば、上記で説明したPUPTEプロセスは、IMDBS100(図1を参照)においてページングデータベクトルを圧縮するための解決策を提供する。このプロセスは、ページングデータベクトルが、データベクトルからのローディング値がデータ構造全体を一度にローディングするのとは対照的に、ページ単位で生じる既存のページロード可能列プロセスと同様の方法で機能し続けることを可能にする。同時に、PUPTEプロセスは、データに対して使用される不均一圧縮を追加し、これは、空間オーバーヘッドを低減し、したがって、所有権の総コストを低減し得る。

【0177】

図8は、上記で説明した様々な実施形態を実装するための例示的なコンピュータシステム800のブロック図である。たとえば、コンピュータシステム800は、IMDBS100(図1を参照)を実装するために使用され得る。コンピュータシステム800は、デスクトップコンピュータ、ラップトップ、サーバコンピュータ、もしくは任意の他のタイプのコンピュータシステム、またはそれらの組合せであってよい。メモリ管理システム130、データ処理システム140、またはそれらの組合せのうちのいくつかまたはすべての要素は、コンピュータシステム800内に含まれ得るか、またはその中で実装され得る。加えて、コンピュータシステム800は、上記で説明した動作、方法、および/またはプロセス(たとえば、図2の方法200、図4の方法400など)の多くを実装し得る。図8に示すように、コンピュータシステム800は、バスサブシステム826を介して、入出力(I/O)サブシステム808、記憶サブシステム810、および通信サブシステム824と通信する処理サブシステム802を含む。

【0178】

バスサブシステム826は、コンピュータシステム800の様々な構成要素およびサブシステムの間の通信を円滑にするように構成される。バスサブシステム826は、図8において単一のバスとして示されているが、バスサブシステム826は複数のバスとして実装されてもよいことを当業者は理解されよう。バスサブシステム826は、様々なバスアーキテクチャのうちのいずれかを使用する、いくつかのタイプのバス構造(たとえば、メモリバスまたはメモリコントローラ、周辺バス、ローカルバスなど)のうちのいずれかであってよい。バスアーキテクチャの例は、業界標準アーキテクチャ(ISA:Industry Standard Architecture)バス、マイクロチャネルアーキテクチャ(MCA:Micro Channel Architecture)バス、拡張ISA(EISA:Enhanced ISA)バス、ビデオエレクトロニクススタンダーズアソシエーション(VESA:Video Electronics Standards Association)ローカルバス、周辺構成要素相互接続(PCI)バス、ユニバーサルシリアルバス(USB)などを含み得る。

【0179】

1つまたは複数の集積回路(たとえば、従来のマイクロプロセッサまたはマイクロコントローラ)として実装され得る処理サブシステム802は、コンピュータシステム800の動作を制御する。処理サブシステム802は、1つまたは複数のプロセッサ804を含み得る。各プロセッサ804は、1つの処理ユニット806(たとえば、プロセッサ804aなどの単一のコアプロセッサ)またはいくつかの処理ユニット806(たとえば、プロセッサ804bなどのマルチコアプロセッサ)を含み得る。いくつかの実施形態では、処理サブシステム802のプロセッサ804は、独立したプロセッサとして実装され得るが、他の実施形態では、処理サブシステム802のプロセッサ804は、単一のチップまたは複数のチップ内に統合された複数のプロセッサとして実装され得る。さらに、いくつかの実施形態では、処理サブシステム802のプロセッサ804は、独立したプロセッサと単一のチップまたは複数のチップ内に統合された複数のプロセッサの組合せとして実装され得る。

【0180】

いくつかの実施形態では、処理サブシステム802は、プログラムコードに応じて、様々なプログラムまたはプロセスを実行することができ、複数の同時実行プログラムまたはプロセスを維持し得る。任意の所与の時点で、実行されることになるプログラムコードのうちのいくつかまたはすべては、処理サブシステム802内または記憶サブシステム810内に常駐し得る。好適なプログラミングを通して、処理サブシステム802は、方法200(図2を参照)、方法400(図4を参照)、方法500(図5を参照)などを参照することによって、上記で説明した機能性など、様々な機能を提供することができる。

【0181】

I/Oサブシステム808は、任意の数のユーザインターフェース入力デバイスおよび/またはユーザインターフェース出力デバイスを含み得る。ユーザインターフェース入力デバイスは、キーボード、ポインティングデバイス(たとえば、マウス、トラックボールなど)、タッチパッド、ディスプレイ内に統合されたタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声認識システムを備えたオーディオ入力デバイス、マイクロフォン、画像/ビデオキャプチャデバイス(たとえば、ウェブカム、画像スキャナ、バーコードリーダなど)、動き感知デバイス、ジェスチャ認識デバイス、アイジェスチャ(たとえば、瞬き)認識デバイス、バイオメトリクス入力デバイス、または他のタイプの入力デバイスを含み得る。

【0182】

ユーザインターフェース出力デバイスは、視覚出力デバイス(たとえば、ディスプレイサブシステム、インジケータライトなど)、オーディオ出力デバイス(たとえば、スピーカ、ヘッドフォンなど)などを含み得る。ディスプレイサブシステムの例は、陰極線管(CRT)、フラットパネルデバイス(たとえば、液晶ディスプレイ(LCD)、プラズマディスプレイなど)、投影デバイス、タッチスクリーン、またはコンピュータシステム800からユーザデバイスまたは別のデバイス(たとえば、プリンタ)に情報を出力するための他のタイプのデバイスおよび機構を含み得る。

【0183】

図8に示すように、記憶サブシステム810は、システムメモリ812、コンピュータ可読記憶媒体820、およびコンピュータ可読記憶媒体リーダ822を含む。記憶サブシステム810は、メインメモリ110または二次記憶装置120(図1を参照)を実装し得る。システムメモリ812は、処理サブシステム802によってロード可能かつ実行可能なプログラム命令、ならびにプログラム命令の実行の間に生成されるデータの形でソフトウェアを記憶するように構成され得る。いくつかの実施形態では、システムメモリ812は、揮発性メモリ(たとえば、ランダムアクセスメモリ(RAM))および/または不揮発性メモリ(たとえば、読取り専用メモリ(ROM)、プログラマブル読取り専用メモリ(PROM)、消去可能プログラマブル読取り専用メモリ(EPROM)、電子的に消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリなど)を含み得る。システムメモリ812は、静的ランダムアクセスメモリ(SRAM)および/または動的ランダムアクセスメモリ(DRAM)など、異なるタイプのメモリを含み得る。システムメモリ812は、いくつかの実施形態では、(たとえば、起動の間に)コンピュータシステム800内の要素同士の間の情報の転送を円滑にするための基本的ルーチンを記憶するように構成された基本入出力システム(BIOS)を含み得る。そのようなBIOSは、ROM(たとえば、ROMチップ)、フラッシュメモリ、またはBIOSを記憶するように構成され得る別のタイプのメモリ内に記憶され得る。

【0184】

図8に示すように、システムメモリ812は、アプリケーションプログラム814(たとえば、図1のメモリ管理システム130またはデータ処理システム140を実装する)、プログラムデータ816、およびオペレーティングシステム(OS)818を含む。OS818は、Microsoft Windows、Apple Mac OS、Apple OS X、Apple macOS、および/またはLinux(登録商標)のオペレーティングシステムの様々なバージョンのうちの1つ、様々な市販のUNIX(登録商標)オペレーティングシステムまたはUNIX(登録商標)のようなオペレーティングシステム(限定なしに、様々なGNU/Linux(登録商標)オペレーティングシステム、Google Chrome(登録商標)OSなどを含む)および/またはApple iOS、Windows Phone、Windows Mobile、Android、BlackBerry OS、Blackberry 10、Palm OS、およびWebOSのオペレーティングシステムなど、モバイルオペレーティングシステムであってよい。

【0185】

コンピュータ可読記憶媒体820は、ソフトウェア(たとえば、プログラム、コードモジュール、データ構造、命令など)を記憶するように構成された非一時的コンピュータ可読媒体であってよい。上記で説明した構成要素(たとえば、図1のメモリ管理システム130またはデータ処理システム140など)またはプロセス(たとえば、図2の方法200、図4の方法400、図5の方法500など)の多くは、プロセッサまたは処理ユニット(たとえば、処理サブシステム802のプロセッサまたは処理ユニット)によって実行されると、そのような構成要素および/またはプロセスの動作を実行するソフトウェアとして実装され得る。記憶サブシステム810は、ソフトウェアの実行のために使用されるか、またはその間に生成されるデータを記憶することも可能である。

【0186】

記憶サブシステム810は、コンピュータ可読記憶媒体820と通信するように構成されたコンピュータ可読記憶媒体リーダ822をやはり含み得る。システムメモリ812とともに、また随意に、システムメモリ812と組み合わせて、コンピュータ可読記憶媒体820は、コンピュータ可読情報を一時的におよび/またはより永続的に包含し、記憶し、送信し、取り出すためのリモート、ローカル、固定、および/またはリムーバブルな記憶装置デバイスおよび記憶媒体を包括的に表し得る。

【0187】

コンピュータ可読記憶媒体820は、情報の記憶および/または送信のための任意の方法または技術で実装される、揮発性媒体、不揮発性媒体、リムーバブル媒体、非リムーバブル媒体などの記憶媒体を含む、当技術分野で知られているかまたは使用される任意の適切な媒体であってよい。そのような記憶媒体の例には、RAM、ROM、EEPROM、フラッシュメモリもしくは他のメモリ技術、コンパクトディスク読取り専用メモリ(CD-ROM)、デジタル多用途ディスク(DVD)、Blu-ray Disc(BD)、磁気カセット、磁気テープ、磁気ディスク記憶装置(たとえば、ハードディスクドライブ)、Zipドライブ、固体ドライブ(SSD)、フラッシュメモリカード(たとえば、セキュアデジタル(SD)カード、CompactFlashカードなど)、USBフラッシュドライブ、または他のタイプのコンピュータ可読記憶媒体もしくはコンピュータ可読記憶装置がある。

【0188】

通信サブシステム824は、他のデバイス、コンピュータシステム、およびネットワークからデータを受信し、それらにデータを送信するためのインターフェースとしてサービスする。たとえば、通信サブシステム824は、コンピュータシステム800が、ネットワーク(たとえば、パーソナルエリアネットワーク(PAN)、ローカルエリアネットワーク(LAN)、ストレージエリアネットワーク(SAN)、キャンパスエリアネットワーク(CAN)、メトロポリタンエリアネットワーク(MAN)、広域ネットワーク(WAN)、グローバルエリアネットワーク(GAN)、イントラネット、インターネット、任意の数の異なるタイプのネットワークのネットワークなど)を介して1つまたは複数のデバイスに接続することを可能にし得る。通信サブシステム824は、任意の数の異なる通信構成要素を含み得る。そのような構成要素の例は、(たとえば、2G、3G、4G、5Gなどのセルラー技術、Wi-Fi、Bluetooth(登録商標)、ZigBeeなどのワイヤレスデータ技術、またはそれらの任意の組合せを使用して)ワイヤレス音声および/またはデータネットワークにアクセスするための無線周波数(RF)トランシーバ構成要素、全地球測位システム(GPS)受信機構成要素、または他の構成要素を含み得る。いくつかの実施形態では、通信サブシステム824は、ワイヤレス通信のために構成された構成要素に加えて、またはその代わりに、ワイヤード通信(たとえば、Ethernet)のために構成された構成要素を提供し得る。

【0189】

図8に示すアーキテクチャは、コンピュータシステム800の単なる1つの例示的なアーキテクチャであり、コンピュータシステム800は、示したものよりも多数のまたは少数の構成要素、または構成要素の異なる構成を有し得ることを当業者は了解されよう。図8に示す様々な構成要素は、1つまたは複数の信号処理および/または特定用途向け集積回路を含めて、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。

【0190】

図9は、上記で説明した様々な実施形態を実装するためのクラウドコンピューティングシステム900のブロック図である。たとえば、クライアントデバイス902～908のうちの1つは、IMDBS100(図1を参照)にアクセスするためにクライアントデバイスを実装するために使用され得、システム900のクラウドコンピューティングシステム912は、IMDBS100自体を実装するために使用され得る。示すように、システム900は、クライアントデバイス902～908、1つまたは複数のネットワーク910、およびクラウドコンピューティングシステム912を含む。クラウドコンピューティングシステム912は、ネットワーク910を介してクライアントデバイス902～908にリソースおよびデータを提供するように構成される。いくつかの実施形態では、クラウドコンピューティングシステム900は、任意の数の異なるユーザ(たとえば、カスタマ、テナント、組織など)にリソースを提供する。クラウドコンピューティングシステム912は、1つまたは複数のコンピュータシステム(たとえば、サーバ)、コンピュータシステム上で動作する仮想マシン、またはそれらの組合せによって実装され得る。

【0191】

示すように、クラウドコンピューティングシステム912は、1つまたは複数のアプリケーション914、1つまたは複数のサービス916、および1つまたは複数のデータベース918を含む。クラウドコンピューティングシステム900は、セルフサービス方法で、加入ベースの方法で、弾性的にスケーラブルな方法で、確実な方法で、非常に利用可能な方法で、またセキュアな方法で、アプリケーション914、サービス916、およびデータベース918を任意の数の異なるカスタマに提供し得る。

【0192】

いくつかの実施形態では、クラウドコンピューティングシステム900は、クラウドコンピューティングシステム900によって提供されるサービスに対するカスタマの加入を自動的に提供、管理、および追跡するように適合され得る。クラウドコンピューティングシステム900は、異なる展開モデルを介してクラウドサービスを提供し得る。たとえば、クラウドサービスは、クラウドコンピューティングシステム900がクラウドサービスを販売する組織によって所有され、クラウドサービスが公共企業または異なる業界企業に利用可能にされる、パブリッククラウドモデルに基づいて提供され得る。別の例として、クラウドサービスは、クラウドコンピューティングシステム900が、単一の組織に対してのみ動作し、その組織内の1つまたは複数のエンティティにクラウドサービスを提供することができる、プライベートクラウドモデルに基づいて提供され得る。クラウドサービスはまた、クラウドコンピューティングシステム900およびクラウドコンピューティングシステム900によって提供されるクラウドサービスが関連するコミュニティ内のいくつかの組織によって共有される、コミュニティクラウドモデルに基づいて提供され得る。クラウドサービスはまた、前述の異なるモデルのうちの2つ以上の組合せである、ハイブリッドクラウドモデルに基づいて提供され得る。

【0193】

場合によっては、クラウドコンピューティングシステム900からネットワーク910を介してクライアントデバイス902～908に利用可能にされるアプリケーション914、サービス916、およびデータベース918のうちのいずれか1つは、「クラウドサービス」と呼ばれる。一般に、クラウドコンピューティングシステム900を構成するサーバおよびシステムは、カスタマの構内サーバおよび構内システムとは異なる。たとえば、クラウドコンピューティングシステム900は、アプリケーションをホストすることができ、クライアントデバイス902～908のうちの1つのユーザは、ネットワーク910を介してアプリケーションを注文および使用することができる。

【0194】

アプリケーション914は、クラウドコンピューティングシステム912(たとえば、コンピュータシステムまたはコンピュータシステム上で動作している仮想マシン)上で実行するように構成され、クライアントデバイス902～908を介してアクセス、制御、管理などされるソフトウェアアプリケーションを含み得る。いくつかの実施形態では、アプリケーション914は、サーバアプリケーションおよび/またはミッドティア(mid-tier)アプリケーション(たとえば、HTTP(ハイパーテキストトランスポートプロトコル)サーバアプリケーション、FTP(ファイルトランスファープロトコル)サーバアプリケーション、CGI(コモンゲートウェイインターフェース)サーバアプリケーション、JAVA(登録商標)サーバアプリケーションなど)を含み得る。サービス916は、クラウドコンピューティングシステム912上で実行し、ネットワーク910を介してクライアントデバイス902～908に機能性を提供するように構成された、ソフトウェア構成要素、モジュール、アプリケーションなどである。サービス916は、ウェブベースサービスまたはオンデマンドクラウドサービスであってよい。

【0195】

データベース918は、アプリケーション914、サービス916、またはクライアントデバイス902～908によってアクセスされるデータを記憶および/または管理するように構成される。たとえば、UPT構造300(図3を参照)は、データベース918内に記憶され得る。データベース918は、クラウドコンピューティングシステム912に対してローカルな(および/またはその中の常駐する)非一時的記憶媒体上に、ストレージエリアネットワーク(SAN)内に、またはクラウドコンピューティングシステム912からリモートに位置する非一時的記憶媒体上に常駐し得る。いくつかの実施形態では、データベース918は、リレーショナルデータベース管理システム(RDBMS)などによって管理されるリレーショナルデータベースであってよい。データベース918は、列指向データベース、行指向データベース、またはそれらの組合せであってよい。いくつかの実施形態では、データベース918のうちのいくつかまたはすべては、インメモリデータベースである。すなわち、いくつかのそのような実施形態では、データベース918用のデータは、メモリ(たとえば、ランダムアクセスメモリ(RAM))内に記憶されその中で管理される。

【0196】

クライアントデバイス902～908は、ネットワーク910を介してアプリケーション914、サービス916、またはデータベース918と通信する、クライアントアプリケーション(たとえば、ウェブブラウザ、プロプライエタリクライアントアプリケーションなど)を実行して動作させるように構成される。このようにして、クライアントデバイス902～908は、アプリケーション914、サービス916、およびデータベース918によって提供される様々な機能性にアクセスすることができ、アプリケーション914、サービス916、およびデータベース918は、クラウドコンピューティングシステム900上で動作している(たとえば、ホストされている)。クライアントデバイス902～908は、コンピュータシステム800(図8を参照)であってよい。システム900は4つのクライアントデバイスで示されているが、任意の数のクライアントデバイスがサポートされ得る。

【0197】

ネットワーク910は、様々なネットワークプロトコルのうちのいずれかを使用して、クライアントデバイス902～908およびクラウドコンピューティングシステム912の間でデータ通信を円滑にするように構成された任意のタイプのネットワークであってよい。ネットワーク910は、パーソナルエリアネットワーク(PAN)、ローカルエリアネットワーク(LAN)、ストレージエリアネットワーク(SAN)、キャンパスエリアネットワーク(CAN)、メトロポリタンエリアネットワーク(MAN)、広域ネットワーク(WAN)、グローバルエリアネットワーク(GAN)、イントラネット、インターネット、任意の数の異なるタイプのネットワークのネットワークなどであってよい。

【0198】

上記の説明は、本発明の態様がどのように実装され得るかの例とともに、本発明の様々な実施形態を示す。上記の説明および実施形態は、唯一の実施形態と見なされるべきではなく、以下の特許請求の範囲によって定義される本発明のフレキシビリティおよび利点を示すために提示されている。上記の開示および以下の特許請求の範囲に基づいて、他の配置、実施形態、実装形態、および均等物が、当業者に明らかになるであろうし、特許請求の範囲によって定義される本発明の趣旨および範囲から逸脱せずに採用され得る。

【符号の説明】

【0199】

100 インメモリデータベースシステム(IMDBS)
110 メインメモリ
120 二次記憶装置
130 メモリ管理システム
132 チャンクサイズ計算機
134 エンコーダ構成要素
136 デコーダ構成要素
138 ページローダ
140 データ処理システム
200 方法
300 均一区分ツリー(UPT)
302 ルートノード
304 子ノード、ノード
306 子ノード、ノード
308 子ノード、ノード
310 子ノード、ノード
312 子ノード、ノード
314 子ノード、ノード
320 データベクトル
400 方法
500 方法
600 コードリスティング
700 コードリスティング
800 コンピュータシステム
802 処理サブシステム
804 プロセッサ
804a プロセッサ
804b プロセッサ
806 処理ユニット
808 入出力(I/O)サブシステム
810 記憶サブシステム
812 システムメモリ
814 アプリケーションプログラム
816 プログラムデータ
818 オペレーティングシステム(OS)
820 コンピュータ可読記憶媒体
822 コンピュータ可読記憶媒体リーダ
824 通信サブシステム
826 バスサブシステム
900 クラウドコンピューティングシステム、システム
902～908 クライアントデバイス
910 ネットワーク
912 クラウドコンピューティングシステム
914 アプリケーション
916 サービス
918 データベース

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】