アライメントトラップ軽減のために列を自動で並べ替える方法
並列処理データベースシステムにおける高速スキャンのために列値を適切なバイト境界に自動でアライメントする方法である。フィールドの論理的順序を有するテーブル定義を受信する（２０１）。フィールドを並べ替えてフィールドの物理的順序を作成する（２０６−２２０）。フィールドの物理的順序は、相互に隣接して最大サイズから最小サイズまで降順で配置するという同一のバイトアライメント要求を有する固定長フィールドを有し、物理的順序における第１の固定長フィールドを適切なバイト境界上にアライメントする。更に、その他の実施形態、様態および特徴を開示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、一般的にはコンピュータシステムおよびソフトウェアシステムに関する。より詳細には、本出願はデータベースシステムに関する。
【背景技術】
【０００２】
ビジネスインテリジェンス（ＢＩ）データベースは、多数のディスク上の大容量データを超並列処理（ＭＰＰ）システム内で処理する。ＢＩデータベース用に記憶されるデータ量はかなりの割合で増加しており、ＢＩデータベースは、ますます多くのデータをスキャンする必要がある。テーブルデータは、テーブルデータの並列スキャンおよびフィルタリングを可能にするため、多数のディスクにわたって分割される。更に、データの増加に伴って更に多くのディスクが追加され、より高速なスキャンが必要となる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ビジネスインテリジェンス（ＢＩ）データベース内で処理する必要のあるデータ量はかなりの割合で増加している。したがって、効率的な方法で大容量データのスキャンおよびデータ列のフィルタリングを行う必要があるということは、ＢＩデータベースが直面する大きな課題である。データのスキャン方法を改善すれば、システムにおける全クエリの全体的なスループットを実質的に向上させることが可能である。
【０００４】
データベースは通常、最終的には破棄されるシステム周辺の大容量データのコピーを軽減するため、可能な場合、スキャン述語を最下層で適用する。データアクセスマネージャ層内のデータにおけるスキャン述語を効率的に評価するため、列値は一般的に適切なバイト境界上にある必要がある。
【０００５】
適切なバイト境界上にない数値列の値は、いわゆるアライメントトラップ（アライメント修正）の原因となる。アライメントトラップにおいては、データを評価する前に、アライメントされたバッファにコピーする必要がある。したがって、アライメントトラップは性能ペナルティの原因となる。各列は独立して処理されるため、フィルタ述語を作成する列が多いほど、コストが高くなる。
【０００６】
ＢＩシナリオにおいては多数の列を有する多数のテーブルが存在するため、ユーザが適切にアライメントしようとすると非常に時間を要することになる。ＢＩの顧客は、理論上は列が可能な限り適切にアライメントされるようテーブルを定義することができるが、これは、顧客がある程度までの下層レイアウトおよび列の型毎に必要な適切なアライメントを理解していることが前提となる。更に、テーブル定義はデータベース毎に異なる可能性が非常に高いため、顧客が、作成されるテーブル毎に上述のようにアライメントするよう努力することが前提となる。更に、テーブルが可変長フィールドを含む場合、記憶されるのは値の最大長ではなく実際のバイト数のみであるため、ユーザは必ずしもデータ列の全てをアライメントされた境界から開始させることはできない。
【０００７】
本出願は、列を適切なバイト境界にアライメントする技術に関する。列を適切なバイト境界にアライメントする単純な技術によれば、データレコードの全フィールドがテーブル作成命令により指定される順序でアライメントされる。しかしながら、この場合、異なるデータ型を有する列値間にパディングを挿入することが暗黙的に求められ、そのため、付加されるパディングを収容するためにテーブルデータを展開および拡張するためのディスクスペースが更に必要となる。
【０００８】
また、全フィールドをオフセット配列する技術がある。この技術は、全フィールドをテーブル定義内で指定される論理的順序と同一の順序で保持する。この技術においては、ハードウェア又はファームウェアがミスアライメントされたデータを検出し、検出したデータを適切にアライメントするよう構成するか、又はデータアクセスマネージャ層がミスアライメントを検出および訂正するよう構成する必要がある。
【０００９】
列を適切なバイト境界にアライメントするための他の技術として、レコードの固定長フィールドの全てを強固にパックする、というものがある。その後、スキャン述語の評価中に、ポインタがフィールドに対して適切なバイト境界にあるかどうかチェックしてもよい。ポインタがフィールドに対して適切なバイト境界にない場合、データをサイドバッファにコピーして評価に利用する。この技術のフローチャートを図１に示す。図１に示すとおり、列値が適切なバイト境界にアライメントされているか決定する（１０２）。適切にアライメントされている場合、列値を評価してもよい（１０６）。適切にアライメントされていない場合、列値をアライメントされたバッファ（サイドバッファ）にコピーする（１０４）工程が更に必要となる。その後、（アライメントされたバッファ内の）列値を評価（１０６）してもよい。その決定（１０２）は、各行における評価対象の列毎に実行しなければならない。
【課題を解決するための手段】
【００１０】
本出願は列を適切なバイト境界にアライメントするための新規な技術を開示しており、この技術によれば、テーブル定義により指定される列をアライメントトラップの発生を軽減するために有益な方法で並べ替える。すなわち、スキャン述語の評価を向上させるため、テーブル作成命令により指定される列の論理的順序を各フィールドの適切なバイトアライメントに基づいて並べ替え、その後、この物理的順序でディスク上のデータレコード内に記憶する。このフィールドの並べ替えはテーブルの作成時およびレコードの挿入、更新、削除、およびスキャン時に自動的に実行される。したがってこの技術によれば、顧客が手動でそのようなタスクを実行することなく、また列値間に暗黙的なパディングを付加することなく、列の適切なバイト境界へのアライメントを向上させることができる。
【図面の簡単な説明】
【００１１】
【図１】図１は、アライメントされたバッファを用いてアライメントトラップに対処する従来の方法を示すフローチャートである。
【図２】図２は、本発明の実施形態による、アライメントトラップ軽減のために自動で並べ替えを実行する方法を示すフローチャートである。
【図３】図３は、データベースのデータ列におけるフィールド（列）の論理的順序を指定するテーブル作成命令の一例を示す。
【図４】図４は、本発明の実施形態による、ディスク上の物理記憶のためのフィールドの並べ替えを示す。
【図５Ａ】図５Ａは、本発明の実施形態による、テーブル作成命令の受信と、ディスク上にデータを記憶するための物理的順序を生成する決定論的方法の使用とを示すフローチャートである。
【図５Ｂ】図５Ｂは、本発明の実施形態による、データベースクエリの受信およびディスクからのデータにアクセスするための物理的順序の再計算を示すフローチャートである。
【図５Ｃ】図５Ｃは、本発明の実施形態による、様々なスキーマを試験した際の経路の向上を示す実験結果である。
【図６】図６は、本発明の実施形態による方法を実行可能に構成されたコンピュータ装置の一例を示す概略図である。
【発明を実施するための形態】
【００１２】
図２は、本発明の実施形態による、アライメントトラップ軽減のために自動で並べ替えを実行する方法を示すフローチャートである。本方法は、コンピュータ読取り可能な媒体上（すなわちディスク上）に記憶する物理的順序を決定する。本方法は、データベーステーブルに対してフィールドの論理的順序を指定又は定義するテーブル作成命令を受信した後に実行される（ブロック２０１参照）。
【００１３】
従来、列の物理的順序は通常、テーブル作成命令により指定される論理的順序と同一である。本出願は対称的に、ディスク上に記憶される列の物理的順序がテーブル作成命令により指定される論理的順序と大幅に異なってもよいように列を自動で並べ替える方法を開示する。図２に示す工程を用いて列（フィールド）を並べ替え、ディスク上に記憶する物理的順序およびデータ列の各フィールドの固定オフセットを決定する。
【００１４】
バイトアライメントを必要とする固定長フィールドは、評価される前に適切なバイト境界へのアライメントを必要とするフィールドである（上述の図１に関連した説明を参照）。説明した典型的なデータベースシステムにおいては、例えば数値フィールドおよび整数値フィールドがバイトアライメントを必要とする固定長フィールドである。バイトアライメントを必要とする固定長フィールドは２N（２のＮ乗）バイト境界へアライメントする必要があり、この場合Ｎは整数である。
【００１５】
第１の工程２０６において、最大の（又は最大と同等の）バイトアライメント要求を有する（すなわちＮの最大値を有する）固定長フィールドを選択する。次の工程２０８において、選択したフィールドを物理的順序において次に配置する（パックされる）。
【００１６】
その後、２Nバイト境界へのバイトアライメントを必要とするフィールドが残存するか（未選択であるか）否か決定する（２１０）。そのようなフィールドが少なくとも１個の残存する（未選択である）場合、残存するフィールドのうち１個を工程２１２において選択し、本方法は工程２０８に戻って、選択したフィールドを物理的順序において次に配置する（パックされる）。
【００１７】
一方、２Nバイト境界へのバイトアライメントを必要とするフィールドが残存しない（未選択である）と決定（２１０）された場合、更に、Ｎがゼロであるか否か決定（２１４）してもよい。Ｎがゼロではない場合、工程２１６においてＮを１だけ減少させ、本方法は工程２１０に戻って、減少したＮ値に基づいて、２Nバイト境界へのバイトアライメントを必要とするフィールドが残存するか否か決定する。
【００１８】
一方、Ｎがゼロであると決定（２１４）された場合、バイトアライメントを必要とするフィールドは残存しないため本方法は進行し、工程２２０において、（テーブル作成命令により指定されるとおりの）論理的順序における可変長フィールドを選択し、選択した可変長フィールドを物理的順序において次に配置する。
【００１９】
次の工程２３０において、必要な調整スペースを決定する。各データレコードの先頭におけるこの調整スペースをゼロパディングし、その後、データレコードの作成時に適切なヘッダ情報を付加する。この調整スペースを（ゼロパディングにより）拡張し、最初のフィールドを確実に適切にアライメントする。
【００２０】
その後、本方法は工程２４０において、並べ替えた固定フィールドを処理し、それらの各々に対してオフセットを割り当てる。並べ替えはアライメントされたフィールドのうち最長のものから開始されるため、並べ替えた固定長フィールドの全てがパックされる。
【００２１】
その後、本方法は工程２５０において、可変長フィールドを処理し、固定長フィールドに対する全オフセットの後に、可変長フィールドの各々に対してオフセットを割り当てる。最後に、工程２６０において、可変長列の最大サイズを推定して全フィールドからなる全長を適切なサイズに拡張する。
【００２２】
なお、レコードの挿入又は更新時に、１番目の固定長フィールドの前およびデータレコードの終端にパディングを付加する。
【００２３】
図３において、テーブル作成命令の一例を示す。図３の命令文の例において、テーブル名ＣＵＳＴＯＭＥＲを有するテーブルを定義する。テーブルのフィールド又は列を、論理的順序において、ｃｕｓｔＫｅｙ、ｎａｍｅ、ａｄｄｒｅｓｓ、ｎａｔｉｏｎＫｅｙ、ｐｈｏｎｅ、ａｃｃｔＢａｌ、ｍｋｔＳｅｇ、およびｃｏｍｍｅｎｔと定義する。
【００２４】
テーブル作成命令はまた、各列に対するフィールド型を定義する。図３の例に示すように、ｃｕｓｔＫｅｙフィールドは整数値フィールドであり、ｎａｍｅ列は２５バイト長までの可変文字フィールドであり、ａｄｄｒｅｓｓ列は４０バイト長までの可変文字フィールドであり、ｎａｔｉｏｎＫｅｙフィールドは整数値フィールドであり、ｐｈｏｎｅ列は１５バイト長までの固定文字フィールドであり、ａｃｃｔＢａｌ列は８バイトで記憶される幅１２および少数位２を有する数値フィールドであり、ｍｋｔＳｅｇ列は１０バイト長の固定文字フィールドであり、ｃｏｍｍｅｎｔ列は１１７バイト長までの可変文字フィールドである。テーブル作成命令はまた、テーブルの主キー、デフォルト値、フィールドがドロップ可能か否か等、その他の特性を定義する。当然ながら図３は、テーブル作成命令の説明を目的とした一例を示しているにすぎない。
【００２５】
図４は、図３に示すテーブル作成命令の例に対して図２に関連して上述した並べ替え方法を用いた、ディスク上の物理記憶のフィールド順序を示す。図４の上の部分は物理記憶のために並べ替えた列を示し、下の部分はレコード内の対応するバイト数を示す。
【００２６】
図４に示すとおり、並べ替えたレコードにおける１番目の列は、図２の工程２３０で決定されたスペースに配置される、レコード先頭の調整バイト又は固定サイズのオーバヘッドである。本実施例においては、ＦＦは、データレコードの１番目の固定長フィールドに対するオフセットを示す値又はゼロ（存在しない場合）を含む２バイトのフィールドであり、ＢＯは、ヌルビットマップ（以下で説明する）が存在する場合はそのヌルビットマップに対するオフセットを示す値又はゼロ（存在しない場合）を含む２バイトのフィールドである。
【００２７】
可変長フィールドはバイトの最大数ではなく、使用されるバイト数のみ記憶する。したがって、各可変長フィールドの実際の長さを記憶する必要がある。この場合、長さは各可変長フィールドの値に先行して隣接して記憶される。ＶＯkフィールドは可変長フィールドに対するオフセットを示す。この場合、ＶＯ1は１番目の可変長フィールドに対するオフセットを示す２バイトのフィールドであり、ＶＯ2は２番目の可変長フィールドに対するオフセットを示す２バイトのフィールドであり、ＶＯ3は３番目の可変長フィールドに対するオフセットを示す２バイトのフィールドである。
【００２８】
ｂｉｔｍａｐフィールドは上述のヌルビットマップを記憶する４バイトのフィールドである。ヌルビットマップは、空値可能フィールド１個に対して１ビットで、各フィールドのヌル条件を含む。その他のシステムにおいては、任意の列値に対するヌルインジケータは一般的にその列値の前に置かれる。これにより、（ヌルインジケータが１バイト、２バイトのどちらであっても）列値に対する適切なバイト順序が乱されることになる。したがって本発明の実施形態によれば、任意の列に対するヌルインジケータを、列値自体からは分離して記憶されるヌルビットマップフィールドに記憶する。
【００２９】
なお、ｂｉｔｍａｐフィールドの後に続く／／／は、調整バイトの後ろにパックされるパディング（ゼロパディングされる）を示す。本実施例においては、次のフィールドがバイト１６（８バイト境界）から開始するよう、２バイトのパディングが存在する。ここで必要となるパディング量は、テーブルの固定長フィールドが必要とする境界アライメントによって異なる。
【００３０】
１番目のバイトアライメントを必要とする固定長フィールドをパディングの直後に配置する。この場合、１番目のバイトアライメントを必要とする固定長フィールドは８バイト（Ｎ＝３）のａｃｔＢａｌ数値フィールドであり、図２の工程２０６において、最長の固定長フィールドであるため最初に選択される。８バイト境界アライメントを必要とする固定長フィールドは他には存在しないため、図２の工程２１６において、Ｎを３から２に減少させる。
【００３１】
続くバイトアライメントを必要とする固定長フィールドを、１番目のバイトアライメントを必要とする固定長フィールドの直後に配置する。この場合、２番目のバイトアライメントを必要とする固定長フィールドは４バイト（Ｎ＝２）のｃｕｓｔＫｅｙ整数値フィールドであり、３番目の固定長フィールドは４バイト（同様にＮ＝２）のｎａｔｉｏｎＫｅｙ整数値フィールドである。４バイト境界アライメントを必要とする固定長フィールドは他には存在しない。更に、２バイト（Ｎ＝１）の境界アライメントを必要とする固定長フィールドは存在しない。
【００３２】
次に、１バイト（Ｎ＝０）の境界アライメントを必要とする固定長フィールドを順に選択および配置する。例えば、文字列フィールドは１バイト境界アライメントを必要とする固定長フィールドである。この場合、次の列は１５バイト長の文字列フィールドであるｐｈｏｎｅフィールドであり、バイト番号３２から開始し、続く列は１０バイト長の文字列フィールドであるｍｋｔＳｅｇフィールドであり、バイト番号４７から開始する。
【００３３】
その後、図２の工程２２０において、可変長フィールドを論理的順序において選択し、順に配置する。本実施形態において、各可変長フィールドの最初の部分（図４において｜｜で示す）は、そのフィールドに記憶される値の実際の長さを表す２バイトである。その後、可変長値の実際のバイトを配置する。
【００３４】
この場合、１番目の可変長フィールドはｎａｍｅフィールドであり、バイト番号５７から開始する。この、１番目の可変長フィールドのバイト番号５７に対するオフセットは上述したＶＯ1フィールドの値で示されている。上述したように、フィールドの最初の２バイトは実際の長さを示し、残りのバイトはフィールドに記憶される実際のデータである。同様に、２番目の可変長フィールドはａｄｄｒｅｓｓフィールドであり、バイトｖ2（先行する１番目の可変長フィールドの長さにより異なる）から開始し、３番目の可変長フィールドはｃｏｍｍｅｎｔフィールドであり、バイトｖ3（先行する１番目および２番目の可変長フィールドの長さにより異なる）から開始する。
【００３５】
なお、レコードを記憶する際、次のデータレコードが適切なアライメントで開始されるよう、必要に応じてレコードの終端にパッドバイト（／／／で示す）を付加する。本実施例においては、次のレコードが４バイト境界から開始するよう、１〜３のパッドバイトを終端に配置してもよい。レコード毎のパッドバイトの数は、最初の固定オフセットＦＦの一部として上位２ビットで記憶する。
【００３６】
図５Ａは、本発明の実施形態による、テーブル作成命令の受信およびディスク上にデータを記憶するための物理的順序を生成する決定論的方法の使用を示すフローチャートである。図示のように、ユーザからテーブル作成命令を受信する（ブロック５０２）。テーブル作成命令はデータベーステーブルの列（フィールド）に対する論理的順序を定義する。その後、上述のような決定論的アルゴリズムを用いて、テーブル作成命令により指定される論理的順序とは異なる物理的順序を作成する（ブロック５０４）。この物理的順序を用いて、データレコードをディスク上に記憶する（ブロック５０６）。
【００３７】
望ましいことに、論理的順序から物理的順序への並べ替えは決定論的に行われる。したがって、実際の物理的順序に関する情報は必ずしも保存される必要はなく、クエリプラン生成の際に再計算してもよい。図５Ｂは、本発明の実施形態による、データベースクエリの受信およびディスクのデータにアクセスするための物理的順序の再計算を示すフローチャートである。図示のように、データベースクエリを受信する（ブロック５１２）。それに応じて、クエリプランを生成する（ブロック５１４）。本発明の実施形態によれば、クエリプラン生成手順の一部として、物理的順序を再計算する（ブロック５１６）。その後、各列値に対するオフセットを保存（ブロック５１８）してもよい。その後、クエリ実行（ブロック５２０）の際に列値に対するオフセットを用いてもよい。
【００３８】
図５Ｃは、本発明の実施形態による、様々なスキーマを試験した際の経路の向上を示す実験結果である。各行（ａｃｘｉｏ０３２＿ｂ６＿ｍ、ｄｗｐ２ｘ１＿ｂ６＿ｓ等）は特定のスキーマ（すなわち特定のデータベーステーブル定義）を示す。
【００３９】
このテーブルは、アライメントされていないクエリ（未アライメント）および本出願により自動でアライメントされたクエリ（アライメント済）の時間当たりクエリ数（ＱＰＨ）を示す。ＱＰＨは高いほど好ましい。また、ＱＰＨの割合が増加（変化率（％））していることが分かる。図示のとおり、本出願による自動アライメントにより、ＱＰＨの増加率は８％を超える。
【００４０】
テーブルはまた、アライメントされていないクエリ（未アライメント）および本出願により自動でアライメントされたクエリ（アライメント済）毎にかかるＣＰＵ秒（クエリ当たりＣＰＵ秒）を示す。クエリ当たりＣＰＵ秒は低いほど好ましい。また、クエリ当たりＣＰＵ秒の割合が減少（変化率（％））していることが分かる。図示のとおり、本出願による自動アライメントにより、減少した割合は７％を超える。
【００４１】
図６は、本発明の実施形態による方法を実行可能に構成されたコンピュータ装置の一例を示す概略図である。本実施例においては、コンピュータ装置は超並列処理システムを備える。一実施形態において、コンピュータ装置は、対称型マルチプロセッシング（ＳＭＰ）ノード６０６に強固に組込まれる複数のプロセッサ６０２を備えていてもよい。各ＳＭＰノード６０６のプロセッサはメモリ６０４の共用部分に接続されていてもよい。相互接続ネットワーク６０８はＳＭＰノード６０６を接続する。その他の実施形態において、コンピュータ装置にその他のアーキテクチャを用いてもよい。
【００４２】
本発明の実施形態によれば、上述の工程は、コンピュータ読取り可能な媒体又はコンピュータ読取り可能なメモリに記憶される、プロセッサ実行可能な命令として実装される。このプロセッサ実行可能な命令は例えば、図６に示すようなコンピュータ装置上で実行してもよい。
【００４３】
上述の説明において、本発明の実施形態を十分に理解してもらうために様々な具体的詳細を提示した。しかしながら、本発明における図示の実施形態についての上述の説明は、網羅的でなく本発明を開示した形態そのものに限定することを意図するものではない。当業者は、一つ又は複数の本発明は具体的な詳細なしに、また、他の方法、構成要素等を用いて実施可能であると理解するものとする。また、本発明の様態を不明瞭にすることのないよう、公知の構造又は工程は詳細に図示又は説明しない。本発明の特定の実施形態および実施例を説明を目的として記述したが、当業者が理解するとおり、本発明の範囲内において様々な均等な変更が可能である。
【００４４】
本発明に対するこれらの変更は、上述の詳細な説明を考慮して行ってもよい。以下の特許請求の範囲において用いられる用語は、本発明を本明細書および特許請求の範囲に開示される特定の実施形態に制限すると解釈されるべきではない。本発明の範囲はむしろ、請求項解釈の確立された教義に基づいて解釈されるべき以下の特許請求の範囲により決定されるものとする。
【技術分野】
【０００１】
本出願は、一般的にはコンピュータシステムおよびソフトウェアシステムに関する。より詳細には、本出願はデータベースシステムに関する。
【背景技術】
【０００２】
ビジネスインテリジェンス（ＢＩ）データベースは、多数のディスク上の大容量データを超並列処理（ＭＰＰ）システム内で処理する。ＢＩデータベース用に記憶されるデータ量はかなりの割合で増加しており、ＢＩデータベースは、ますます多くのデータをスキャンする必要がある。テーブルデータは、テーブルデータの並列スキャンおよびフィルタリングを可能にするため、多数のディスクにわたって分割される。更に、データの増加に伴って更に多くのディスクが追加され、より高速なスキャンが必要となる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
ビジネスインテリジェンス（ＢＩ）データベース内で処理する必要のあるデータ量はかなりの割合で増加している。したがって、効率的な方法で大容量データのスキャンおよびデータ列のフィルタリングを行う必要があるということは、ＢＩデータベースが直面する大きな課題である。データのスキャン方法を改善すれば、システムにおける全クエリの全体的なスループットを実質的に向上させることが可能である。
【０００４】
データベースは通常、最終的には破棄されるシステム周辺の大容量データのコピーを軽減するため、可能な場合、スキャン述語を最下層で適用する。データアクセスマネージャ層内のデータにおけるスキャン述語を効率的に評価するため、列値は一般的に適切なバイト境界上にある必要がある。
【０００５】
適切なバイト境界上にない数値列の値は、いわゆるアライメントトラップ（アライメント修正）の原因となる。アライメントトラップにおいては、データを評価する前に、アライメントされたバッファにコピーする必要がある。したがって、アライメントトラップは性能ペナルティの原因となる。各列は独立して処理されるため、フィルタ述語を作成する列が多いほど、コストが高くなる。
【０００６】
ＢＩシナリオにおいては多数の列を有する多数のテーブルが存在するため、ユーザが適切にアライメントしようとすると非常に時間を要することになる。ＢＩの顧客は、理論上は列が可能な限り適切にアライメントされるようテーブルを定義することができるが、これは、顧客がある程度までの下層レイアウトおよび列の型毎に必要な適切なアライメントを理解していることが前提となる。更に、テーブル定義はデータベース毎に異なる可能性が非常に高いため、顧客が、作成されるテーブル毎に上述のようにアライメントするよう努力することが前提となる。更に、テーブルが可変長フィールドを含む場合、記憶されるのは値の最大長ではなく実際のバイト数のみであるため、ユーザは必ずしもデータ列の全てをアライメントされた境界から開始させることはできない。
【０００７】
本出願は、列を適切なバイト境界にアライメントする技術に関する。列を適切なバイト境界にアライメントする単純な技術によれば、データレコードの全フィールドがテーブル作成命令により指定される順序でアライメントされる。しかしながら、この場合、異なるデータ型を有する列値間にパディングを挿入することが暗黙的に求められ、そのため、付加されるパディングを収容するためにテーブルデータを展開および拡張するためのディスクスペースが更に必要となる。
【０００８】
また、全フィールドをオフセット配列する技術がある。この技術は、全フィールドをテーブル定義内で指定される論理的順序と同一の順序で保持する。この技術においては、ハードウェア又はファームウェアがミスアライメントされたデータを検出し、検出したデータを適切にアライメントするよう構成するか、又はデータアクセスマネージャ層がミスアライメントを検出および訂正するよう構成する必要がある。
【０００９】
列を適切なバイト境界にアライメントするための他の技術として、レコードの固定長フィールドの全てを強固にパックする、というものがある。その後、スキャン述語の評価中に、ポインタがフィールドに対して適切なバイト境界にあるかどうかチェックしてもよい。ポインタがフィールドに対して適切なバイト境界にない場合、データをサイドバッファにコピーして評価に利用する。この技術のフローチャートを図１に示す。図１に示すとおり、列値が適切なバイト境界にアライメントされているか決定する（１０２）。適切にアライメントされている場合、列値を評価してもよい（１０６）。適切にアライメントされていない場合、列値をアライメントされたバッファ（サイドバッファ）にコピーする（１０４）工程が更に必要となる。その後、（アライメントされたバッファ内の）列値を評価（１０６）してもよい。その決定（１０２）は、各行における評価対象の列毎に実行しなければならない。
【課題を解決するための手段】
【００１０】
本出願は列を適切なバイト境界にアライメントするための新規な技術を開示しており、この技術によれば、テーブル定義により指定される列をアライメントトラップの発生を軽減するために有益な方法で並べ替える。すなわち、スキャン述語の評価を向上させるため、テーブル作成命令により指定される列の論理的順序を各フィールドの適切なバイトアライメントに基づいて並べ替え、その後、この物理的順序でディスク上のデータレコード内に記憶する。このフィールドの並べ替えはテーブルの作成時およびレコードの挿入、更新、削除、およびスキャン時に自動的に実行される。したがってこの技術によれば、顧客が手動でそのようなタスクを実行することなく、また列値間に暗黙的なパディングを付加することなく、列の適切なバイト境界へのアライメントを向上させることができる。
【図面の簡単な説明】
【００１１】
【図１】図１は、アライメントされたバッファを用いてアライメントトラップに対処する従来の方法を示すフローチャートである。
【図２】図２は、本発明の実施形態による、アライメントトラップ軽減のために自動で並べ替えを実行する方法を示すフローチャートである。
【図３】図３は、データベースのデータ列におけるフィールド（列）の論理的順序を指定するテーブル作成命令の一例を示す。
【図４】図４は、本発明の実施形態による、ディスク上の物理記憶のためのフィールドの並べ替えを示す。
【図５Ａ】図５Ａは、本発明の実施形態による、テーブル作成命令の受信と、ディスク上にデータを記憶するための物理的順序を生成する決定論的方法の使用とを示すフローチャートである。
【図５Ｂ】図５Ｂは、本発明の実施形態による、データベースクエリの受信およびディスクからのデータにアクセスするための物理的順序の再計算を示すフローチャートである。
【図５Ｃ】図５Ｃは、本発明の実施形態による、様々なスキーマを試験した際の経路の向上を示す実験結果である。
【図６】図６は、本発明の実施形態による方法を実行可能に構成されたコンピュータ装置の一例を示す概略図である。
【発明を実施するための形態】
【００１２】
図２は、本発明の実施形態による、アライメントトラップ軽減のために自動で並べ替えを実行する方法を示すフローチャートである。本方法は、コンピュータ読取り可能な媒体上（すなわちディスク上）に記憶する物理的順序を決定する。本方法は、データベーステーブルに対してフィールドの論理的順序を指定又は定義するテーブル作成命令を受信した後に実行される（ブロック２０１参照）。
【００１３】
従来、列の物理的順序は通常、テーブル作成命令により指定される論理的順序と同一である。本出願は対称的に、ディスク上に記憶される列の物理的順序がテーブル作成命令により指定される論理的順序と大幅に異なってもよいように列を自動で並べ替える方法を開示する。図２に示す工程を用いて列（フィールド）を並べ替え、ディスク上に記憶する物理的順序およびデータ列の各フィールドの固定オフセットを決定する。
【００１４】
バイトアライメントを必要とする固定長フィールドは、評価される前に適切なバイト境界へのアライメントを必要とするフィールドである（上述の図１に関連した説明を参照）。説明した典型的なデータベースシステムにおいては、例えば数値フィールドおよび整数値フィールドがバイトアライメントを必要とする固定長フィールドである。バイトアライメントを必要とする固定長フィールドは２N（２のＮ乗）バイト境界へアライメントする必要があり、この場合Ｎは整数である。
【００１５】
第１の工程２０６において、最大の（又は最大と同等の）バイトアライメント要求を有する（すなわちＮの最大値を有する）固定長フィールドを選択する。次の工程２０８において、選択したフィールドを物理的順序において次に配置する（パックされる）。
【００１６】
その後、２Nバイト境界へのバイトアライメントを必要とするフィールドが残存するか（未選択であるか）否か決定する（２１０）。そのようなフィールドが少なくとも１個の残存する（未選択である）場合、残存するフィールドのうち１個を工程２１２において選択し、本方法は工程２０８に戻って、選択したフィールドを物理的順序において次に配置する（パックされる）。
【００１７】
一方、２Nバイト境界へのバイトアライメントを必要とするフィールドが残存しない（未選択である）と決定（２１０）された場合、更に、Ｎがゼロであるか否か決定（２１４）してもよい。Ｎがゼロではない場合、工程２１６においてＮを１だけ減少させ、本方法は工程２１０に戻って、減少したＮ値に基づいて、２Nバイト境界へのバイトアライメントを必要とするフィールドが残存するか否か決定する。
【００１８】
一方、Ｎがゼロであると決定（２１４）された場合、バイトアライメントを必要とするフィールドは残存しないため本方法は進行し、工程２２０において、（テーブル作成命令により指定されるとおりの）論理的順序における可変長フィールドを選択し、選択した可変長フィールドを物理的順序において次に配置する。
【００１９】
次の工程２３０において、必要な調整スペースを決定する。各データレコードの先頭におけるこの調整スペースをゼロパディングし、その後、データレコードの作成時に適切なヘッダ情報を付加する。この調整スペースを（ゼロパディングにより）拡張し、最初のフィールドを確実に適切にアライメントする。
【００２０】
その後、本方法は工程２４０において、並べ替えた固定フィールドを処理し、それらの各々に対してオフセットを割り当てる。並べ替えはアライメントされたフィールドのうち最長のものから開始されるため、並べ替えた固定長フィールドの全てがパックされる。
【００２１】
その後、本方法は工程２５０において、可変長フィールドを処理し、固定長フィールドに対する全オフセットの後に、可変長フィールドの各々に対してオフセットを割り当てる。最後に、工程２６０において、可変長列の最大サイズを推定して全フィールドからなる全長を適切なサイズに拡張する。
【００２２】
なお、レコードの挿入又は更新時に、１番目の固定長フィールドの前およびデータレコードの終端にパディングを付加する。
【００２３】
図３において、テーブル作成命令の一例を示す。図３の命令文の例において、テーブル名ＣＵＳＴＯＭＥＲを有するテーブルを定義する。テーブルのフィールド又は列を、論理的順序において、ｃｕｓｔＫｅｙ、ｎａｍｅ、ａｄｄｒｅｓｓ、ｎａｔｉｏｎＫｅｙ、ｐｈｏｎｅ、ａｃｃｔＢａｌ、ｍｋｔＳｅｇ、およびｃｏｍｍｅｎｔと定義する。
【００２４】
テーブル作成命令はまた、各列に対するフィールド型を定義する。図３の例に示すように、ｃｕｓｔＫｅｙフィールドは整数値フィールドであり、ｎａｍｅ列は２５バイト長までの可変文字フィールドであり、ａｄｄｒｅｓｓ列は４０バイト長までの可変文字フィールドであり、ｎａｔｉｏｎＫｅｙフィールドは整数値フィールドであり、ｐｈｏｎｅ列は１５バイト長までの固定文字フィールドであり、ａｃｃｔＢａｌ列は８バイトで記憶される幅１２および少数位２を有する数値フィールドであり、ｍｋｔＳｅｇ列は１０バイト長の固定文字フィールドであり、ｃｏｍｍｅｎｔ列は１１７バイト長までの可変文字フィールドである。テーブル作成命令はまた、テーブルの主キー、デフォルト値、フィールドがドロップ可能か否か等、その他の特性を定義する。当然ながら図３は、テーブル作成命令の説明を目的とした一例を示しているにすぎない。
【００２５】
図４は、図３に示すテーブル作成命令の例に対して図２に関連して上述した並べ替え方法を用いた、ディスク上の物理記憶のフィールド順序を示す。図４の上の部分は物理記憶のために並べ替えた列を示し、下の部分はレコード内の対応するバイト数を示す。
【００２６】
図４に示すとおり、並べ替えたレコードにおける１番目の列は、図２の工程２３０で決定されたスペースに配置される、レコード先頭の調整バイト又は固定サイズのオーバヘッドである。本実施例においては、ＦＦは、データレコードの１番目の固定長フィールドに対するオフセットを示す値又はゼロ（存在しない場合）を含む２バイトのフィールドであり、ＢＯは、ヌルビットマップ（以下で説明する）が存在する場合はそのヌルビットマップに対するオフセットを示す値又はゼロ（存在しない場合）を含む２バイトのフィールドである。
【００２７】
可変長フィールドはバイトの最大数ではなく、使用されるバイト数のみ記憶する。したがって、各可変長フィールドの実際の長さを記憶する必要がある。この場合、長さは各可変長フィールドの値に先行して隣接して記憶される。ＶＯkフィールドは可変長フィールドに対するオフセットを示す。この場合、ＶＯ1は１番目の可変長フィールドに対するオフセットを示す２バイトのフィールドであり、ＶＯ2は２番目の可変長フィールドに対するオフセットを示す２バイトのフィールドであり、ＶＯ3は３番目の可変長フィールドに対するオフセットを示す２バイトのフィールドである。
【００２８】
ｂｉｔｍａｐフィールドは上述のヌルビットマップを記憶する４バイトのフィールドである。ヌルビットマップは、空値可能フィールド１個に対して１ビットで、各フィールドのヌル条件を含む。その他のシステムにおいては、任意の列値に対するヌルインジケータは一般的にその列値の前に置かれる。これにより、（ヌルインジケータが１バイト、２バイトのどちらであっても）列値に対する適切なバイト順序が乱されることになる。したがって本発明の実施形態によれば、任意の列に対するヌルインジケータを、列値自体からは分離して記憶されるヌルビットマップフィールドに記憶する。
【００２９】
なお、ｂｉｔｍａｐフィールドの後に続く／／／は、調整バイトの後ろにパックされるパディング（ゼロパディングされる）を示す。本実施例においては、次のフィールドがバイト１６（８バイト境界）から開始するよう、２バイトのパディングが存在する。ここで必要となるパディング量は、テーブルの固定長フィールドが必要とする境界アライメントによって異なる。
【００３０】
１番目のバイトアライメントを必要とする固定長フィールドをパディングの直後に配置する。この場合、１番目のバイトアライメントを必要とする固定長フィールドは８バイト（Ｎ＝３）のａｃｔＢａｌ数値フィールドであり、図２の工程２０６において、最長の固定長フィールドであるため最初に選択される。８バイト境界アライメントを必要とする固定長フィールドは他には存在しないため、図２の工程２１６において、Ｎを３から２に減少させる。
【００３１】
続くバイトアライメントを必要とする固定長フィールドを、１番目のバイトアライメントを必要とする固定長フィールドの直後に配置する。この場合、２番目のバイトアライメントを必要とする固定長フィールドは４バイト（Ｎ＝２）のｃｕｓｔＫｅｙ整数値フィールドであり、３番目の固定長フィールドは４バイト（同様にＮ＝２）のｎａｔｉｏｎＫｅｙ整数値フィールドである。４バイト境界アライメントを必要とする固定長フィールドは他には存在しない。更に、２バイト（Ｎ＝１）の境界アライメントを必要とする固定長フィールドは存在しない。
【００３２】
次に、１バイト（Ｎ＝０）の境界アライメントを必要とする固定長フィールドを順に選択および配置する。例えば、文字列フィールドは１バイト境界アライメントを必要とする固定長フィールドである。この場合、次の列は１５バイト長の文字列フィールドであるｐｈｏｎｅフィールドであり、バイト番号３２から開始し、続く列は１０バイト長の文字列フィールドであるｍｋｔＳｅｇフィールドであり、バイト番号４７から開始する。
【００３３】
その後、図２の工程２２０において、可変長フィールドを論理的順序において選択し、順に配置する。本実施形態において、各可変長フィールドの最初の部分（図４において｜｜で示す）は、そのフィールドに記憶される値の実際の長さを表す２バイトである。その後、可変長値の実際のバイトを配置する。
【００３４】
この場合、１番目の可変長フィールドはｎａｍｅフィールドであり、バイト番号５７から開始する。この、１番目の可変長フィールドのバイト番号５７に対するオフセットは上述したＶＯ1フィールドの値で示されている。上述したように、フィールドの最初の２バイトは実際の長さを示し、残りのバイトはフィールドに記憶される実際のデータである。同様に、２番目の可変長フィールドはａｄｄｒｅｓｓフィールドであり、バイトｖ2（先行する１番目の可変長フィールドの長さにより異なる）から開始し、３番目の可変長フィールドはｃｏｍｍｅｎｔフィールドであり、バイトｖ3（先行する１番目および２番目の可変長フィールドの長さにより異なる）から開始する。
【００３５】
なお、レコードを記憶する際、次のデータレコードが適切なアライメントで開始されるよう、必要に応じてレコードの終端にパッドバイト（／／／で示す）を付加する。本実施例においては、次のレコードが４バイト境界から開始するよう、１〜３のパッドバイトを終端に配置してもよい。レコード毎のパッドバイトの数は、最初の固定オフセットＦＦの一部として上位２ビットで記憶する。
【００３６】
図５Ａは、本発明の実施形態による、テーブル作成命令の受信およびディスク上にデータを記憶するための物理的順序を生成する決定論的方法の使用を示すフローチャートである。図示のように、ユーザからテーブル作成命令を受信する（ブロック５０２）。テーブル作成命令はデータベーステーブルの列（フィールド）に対する論理的順序を定義する。その後、上述のような決定論的アルゴリズムを用いて、テーブル作成命令により指定される論理的順序とは異なる物理的順序を作成する（ブロック５０４）。この物理的順序を用いて、データレコードをディスク上に記憶する（ブロック５０６）。
【００３７】
望ましいことに、論理的順序から物理的順序への並べ替えは決定論的に行われる。したがって、実際の物理的順序に関する情報は必ずしも保存される必要はなく、クエリプラン生成の際に再計算してもよい。図５Ｂは、本発明の実施形態による、データベースクエリの受信およびディスクのデータにアクセスするための物理的順序の再計算を示すフローチャートである。図示のように、データベースクエリを受信する（ブロック５１２）。それに応じて、クエリプランを生成する（ブロック５１４）。本発明の実施形態によれば、クエリプラン生成手順の一部として、物理的順序を再計算する（ブロック５１６）。その後、各列値に対するオフセットを保存（ブロック５１８）してもよい。その後、クエリ実行（ブロック５２０）の際に列値に対するオフセットを用いてもよい。
【００３８】
図５Ｃは、本発明の実施形態による、様々なスキーマを試験した際の経路の向上を示す実験結果である。各行（ａｃｘｉｏ０３２＿ｂ６＿ｍ、ｄｗｐ２ｘ１＿ｂ６＿ｓ等）は特定のスキーマ（すなわち特定のデータベーステーブル定義）を示す。
【００３９】
このテーブルは、アライメントされていないクエリ（未アライメント）および本出願により自動でアライメントされたクエリ（アライメント済）の時間当たりクエリ数（ＱＰＨ）を示す。ＱＰＨは高いほど好ましい。また、ＱＰＨの割合が増加（変化率（％））していることが分かる。図示のとおり、本出願による自動アライメントにより、ＱＰＨの増加率は８％を超える。
【００４０】
テーブルはまた、アライメントされていないクエリ（未アライメント）および本出願により自動でアライメントされたクエリ（アライメント済）毎にかかるＣＰＵ秒（クエリ当たりＣＰＵ秒）を示す。クエリ当たりＣＰＵ秒は低いほど好ましい。また、クエリ当たりＣＰＵ秒の割合が減少（変化率（％））していることが分かる。図示のとおり、本出願による自動アライメントにより、減少した割合は７％を超える。
【００４１】
図６は、本発明の実施形態による方法を実行可能に構成されたコンピュータ装置の一例を示す概略図である。本実施例においては、コンピュータ装置は超並列処理システムを備える。一実施形態において、コンピュータ装置は、対称型マルチプロセッシング（ＳＭＰ）ノード６０６に強固に組込まれる複数のプロセッサ６０２を備えていてもよい。各ＳＭＰノード６０６のプロセッサはメモリ６０４の共用部分に接続されていてもよい。相互接続ネットワーク６０８はＳＭＰノード６０６を接続する。その他の実施形態において、コンピュータ装置にその他のアーキテクチャを用いてもよい。
【００４２】
本発明の実施形態によれば、上述の工程は、コンピュータ読取り可能な媒体又はコンピュータ読取り可能なメモリに記憶される、プロセッサ実行可能な命令として実装される。このプロセッサ実行可能な命令は例えば、図６に示すようなコンピュータ装置上で実行してもよい。
【００４３】
上述の説明において、本発明の実施形態を十分に理解してもらうために様々な具体的詳細を提示した。しかしながら、本発明における図示の実施形態についての上述の説明は、網羅的でなく本発明を開示した形態そのものに限定することを意図するものではない。当業者は、一つ又は複数の本発明は具体的な詳細なしに、また、他の方法、構成要素等を用いて実施可能であると理解するものとする。また、本発明の様態を不明瞭にすることのないよう、公知の構造又は工程は詳細に図示又は説明しない。本発明の特定の実施形態および実施例を説明を目的として記述したが、当業者が理解するとおり、本発明の範囲内において様々な均等な変更が可能である。
【００４４】
本発明に対するこれらの変更は、上述の詳細な説明を考慮して行ってもよい。以下の特許請求の範囲において用いられる用語は、本発明を本明細書および特許請求の範囲に開示される特定の実施形態に制限すると解釈されるべきではない。本発明の範囲はむしろ、請求項解釈の確立された教義に基づいて解釈されるべき以下の特許請求の範囲により決定されるものとする。
【特許請求の範囲】
【請求項１】
並列処理データベースシステムにおける高速スキャンのために列値を適切なバイト境界に自動でアライメントする方法であって、
フィールドの論理的順序を含むテーブル定義を受信し、
前記フィールドを並べ替えてフィールドの物理的順序を作成することを含み、
前記フィールドの物理的順序は、相互に隣接して最大サイズから最小サイズまで降順で配置するという同一のバイトアライメント要求を有する固定長フィールドを有し、前記物理的順序における第１の固定長は適切なバイト境界上にアライメントされることを特徴とする方法。
【請求項２】
バイトアライメント要求は、フィールド先頭を２Nバイト境界にアライメントすることを要求し、
Ｎは整数であることを特徴とする請求項１に記載の方法。
【請求項３】
レコードの先頭に調整フィールドを配置し、
レコードを記憶する際、前記調整フィールドにゼロパディングが追加されて前記第１の固定長フィールドをアライメントすることを特徴とすることを特徴とする請求項１に記載の方法。
【請求項４】
バイトアライメント要求を有する最後の固定長フィールドの後ろに可変長フィールドが配置されることを特徴とする請求項１に記載の方法。
【請求項５】
レコードを記憶する際、次のレコードが適切なバイト境界にアライメントされるよう、必要に応じて最後の可変長フィールドの後ろにゼロパディングが追加されることを特徴とする請求項５に記載の方法。
【請求項６】
並列処理データベースシステムにおける高速スキャンのために列値を適切なバイト境界にアライメントするコンピュータ読取り可能な命令を記憶するコンピュータ読取り可能な媒体であって、
フィールドの論理的順序を含むテーブル定義を受信するよう構成されたコンピュータ読取り可能な命令と、
前記フィールドを並べ替てフィールドの物理的順序を作成するよう構成されたコンピュータ読取り可能な命令とを備え、
前記フィールドの物理的順序は、相互に隣接して最大サイズから最小サイズまで降順で配置するという同一のバイトアライメント要求を有する固定長フィールドを有し、
前記物理的順序における第１の固定長フィールドを適切なバイト境界上にアライメントすることを特徴とする媒体。
【請求項７】
バイトアライメント要求はフィールド先頭を２Nバイト境界にアライメントすることを要求し、
Ｎは整数であることを特徴とする請求項６に記載の媒体。
【請求項８】
レコードの先頭に調整フィールドが配置され、
レコードを記憶する際、前記調整フィールドにゼロパディングが追加されて前記第１の固定長フィールドをアライメントすることを特徴とする請求項６に記載の媒体。
【請求項９】
バイトアライメント要求を有する最後の固定長フィールドの後ろに可変長フィールドが配置されることを特徴とする請求項６に記載の媒体。
【請求項１０】
レコードを記憶する際、次のレコードが適切なバイト境界にアライメントされるよう、必要に応じて最後の可変長フィールドの後ろにゼロパディングが追加されることを特徴とする請求項６に記載の媒体。
【請求項１１】
並列処理データベースシステムにおける高速スキャンのために列値を適切なバイト境界にアライメントするコンピュータ装置であって、
コンピュータ読取り可能な命令を実行する複数のプロセッサと、
前記コンピュータ読取り可能な命令およびデータを記憶するメモリとを備え、
前記コンピュータ読取り可能な命令はフィールドの論理的順序を含むテーブル定義を受信し、前記フィールドを並べ替えてフィールドの物理的順序を作成し、
更に、前記フィールドの物理的順序は、相互に隣接して最大サイズから最小サイズまで降順で配置するという同一のバイトアライメント要求を有する固定長フィールドを有し、
前記物理的順序における第１の固定長フィールドを適切なバイト境界上にアライメントすることを特徴とする装置。
【請求項１２】
バイトアライメント要求はフィールド先頭を２Nバイト境界にアライメントすることを要求し、
Ｎは整数であることを特徴とする請求項１１に記載のコンピュータ装置。
【請求項１３】
レコードの先頭に調整フィールドを配置し、
レコードを記憶する際、前記調整フィールドにゼロパディングが追加されて前記第１の固定長フィールドをアライメントすることを特徴とする請求項１１に記載のコンピュータ装置。
【請求項１４】
バイトアライメント要求を有する最後の固定長フィールドの後ろに可変長フィールドを配置することを特徴とする請求項１１に記載のコンピュータ装置。
【請求項１５】
レコードを記憶する際、次のレコードが適切なバイト境界にアライメントされるよう、必要に応じて最後の可変長フィールドの後ろにゼロパディングが追加されることを特徴とする請求項１４に記載のコンピュータ装置。
【請求項１】
並列処理データベースシステムにおける高速スキャンのために列値を適切なバイト境界に自動でアライメントする方法であって、
フィールドの論理的順序を含むテーブル定義を受信し、
前記フィールドを並べ替えてフィールドの物理的順序を作成することを含み、
前記フィールドの物理的順序は、相互に隣接して最大サイズから最小サイズまで降順で配置するという同一のバイトアライメント要求を有する固定長フィールドを有し、前記物理的順序における第１の固定長は適切なバイト境界上にアライメントされることを特徴とする方法。
【請求項２】
バイトアライメント要求は、フィールド先頭を２Nバイト境界にアライメントすることを要求し、
Ｎは整数であることを特徴とする請求項１に記載の方法。
【請求項３】
レコードの先頭に調整フィールドを配置し、
レコードを記憶する際、前記調整フィールドにゼロパディングが追加されて前記第１の固定長フィールドをアライメントすることを特徴とすることを特徴とする請求項１に記載の方法。
【請求項４】
バイトアライメント要求を有する最後の固定長フィールドの後ろに可変長フィールドが配置されることを特徴とする請求項１に記載の方法。
【請求項５】
レコードを記憶する際、次のレコードが適切なバイト境界にアライメントされるよう、必要に応じて最後の可変長フィールドの後ろにゼロパディングが追加されることを特徴とする請求項５に記載の方法。
【請求項６】
並列処理データベースシステムにおける高速スキャンのために列値を適切なバイト境界にアライメントするコンピュータ読取り可能な命令を記憶するコンピュータ読取り可能な媒体であって、
フィールドの論理的順序を含むテーブル定義を受信するよう構成されたコンピュータ読取り可能な命令と、
前記フィールドを並べ替てフィールドの物理的順序を作成するよう構成されたコンピュータ読取り可能な命令とを備え、
前記フィールドの物理的順序は、相互に隣接して最大サイズから最小サイズまで降順で配置するという同一のバイトアライメント要求を有する固定長フィールドを有し、
前記物理的順序における第１の固定長フィールドを適切なバイト境界上にアライメントすることを特徴とする媒体。
【請求項７】
バイトアライメント要求はフィールド先頭を２Nバイト境界にアライメントすることを要求し、
Ｎは整数であることを特徴とする請求項６に記載の媒体。
【請求項８】
レコードの先頭に調整フィールドが配置され、
レコードを記憶する際、前記調整フィールドにゼロパディングが追加されて前記第１の固定長フィールドをアライメントすることを特徴とする請求項６に記載の媒体。
【請求項９】
バイトアライメント要求を有する最後の固定長フィールドの後ろに可変長フィールドが配置されることを特徴とする請求項６に記載の媒体。
【請求項１０】
レコードを記憶する際、次のレコードが適切なバイト境界にアライメントされるよう、必要に応じて最後の可変長フィールドの後ろにゼロパディングが追加されることを特徴とする請求項６に記載の媒体。
【請求項１１】
並列処理データベースシステムにおける高速スキャンのために列値を適切なバイト境界にアライメントするコンピュータ装置であって、
コンピュータ読取り可能な命令を実行する複数のプロセッサと、
前記コンピュータ読取り可能な命令およびデータを記憶するメモリとを備え、
前記コンピュータ読取り可能な命令はフィールドの論理的順序を含むテーブル定義を受信し、前記フィールドを並べ替えてフィールドの物理的順序を作成し、
更に、前記フィールドの物理的順序は、相互に隣接して最大サイズから最小サイズまで降順で配置するという同一のバイトアライメント要求を有する固定長フィールドを有し、
前記物理的順序における第１の固定長フィールドを適切なバイト境界上にアライメントすることを特徴とする装置。
【請求項１２】
バイトアライメント要求はフィールド先頭を２Nバイト境界にアライメントすることを要求し、
Ｎは整数であることを特徴とする請求項１１に記載のコンピュータ装置。
【請求項１３】
レコードの先頭に調整フィールドを配置し、
レコードを記憶する際、前記調整フィールドにゼロパディングが追加されて前記第１の固定長フィールドをアライメントすることを特徴とする請求項１１に記載のコンピュータ装置。
【請求項１４】
バイトアライメント要求を有する最後の固定長フィールドの後ろに可変長フィールドを配置することを特徴とする請求項１１に記載のコンピュータ装置。
【請求項１５】
レコードを記憶する際、次のレコードが適切なバイト境界にアライメントされるよう、必要に応じて最後の可変長フィールドの後ろにゼロパディングが追加されることを特徴とする請求項１４に記載のコンピュータ装置。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６】
【公表番号】特表２０１１−５０４２７３（Ｐ２０１１−５０４２７３Ａ）
【公表日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願番号】特願２０１０−５３５００７（Ｐ２０１０−５３５００７）
【出願日】平成２０年１１月１３日（２００８．１１．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０８３４０８
【国際公開番号】ＷＯ２００９／０６７３８０
【国際公開日】平成２１年５月２８日（２００９．５．２８）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
【公表日】平成２３年２月３日（２０１１．２．３）
【国際特許分類】
【出願日】平成２０年１１月１３日（２００８．１１．１３）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０８３４０８
【国際公開番号】ＷＯ２００９／０６７３８０
【国際公開日】平成２１年５月２８日（２００９．５．２８）
【出願人】（５０３００３８５４）ヒューレット−パッカード デベロップメント カンパニー エル．ピー． (1,145)
【Ｆターム（参考）】
[ Back to top ]