JP6362316B2 - バッファ・プールをメモリ常駐型データのための常在インメモリ・ストレージとして用いた、ハイブリッド・テーブル実装のための方法、システム、およびコンピュータ・プログラム製品 - Google Patents

Description

本開示は、一般にデータベースの検索およびストレージの分野に関し、さらに具体的には、バッファ・プールをメモリ常駐型データのための常在インメモリ・ストレージとして用いたハイブリッド・テーブル実装に関する。

大規模データベースの多くは主としてディスクに格納される。これらディスク・ベースのデータベースは、多くの場合、パフォーマンスを向上するために、新しくアクセスされるデータを読み出すためのバッファを用いる。ディスク・ベースのデータベースは、多くの場合、システムのスペースを最適化しパフォーマンスを向上するために、バッファ・スペースを共用する。しかしながら、このバッファのプーリングは、データを送信または受信する際にパフォーマンスのボトルネックを発生させ、多くの場合、これらはディスク入力／出力（Ｉ／Ｏ：ｉｎｐｕｔ−ｏｕｔｐｕｔ）への要求事項に起因する。

かかるボトルネックを低減し、パフォーマンス問題を回避するため、時としてインメモリ・データベースが使われる。インメモリ・データベースでは、データの主たる記憶場所は、物理または常在メモリの中にある。ほとんどのインメモリ・データベースは、メモリに最適化されたデータ構造体とアクセス方法とによって特徴付けられる。指定されたデータ全体を、ディスク・ベースに頼ることなく、インメモリでソートし、格納し、読み出すことによってパフォーマンスが大きく向上する。インメモリ・データベースを使用することによって、コード・パス中にもたらされる上記のディスクＩ／Ｏボトルネックに対処せずに、アクセス要求を実行することが可能になる。

しかしながら、インメモリ・データベース・スキームの使用は、インメモリ・データベースのデータ・ユニット当たりのストレージ・コストがディスク・メモリ・スキームよりも高くなるなど、多くのトレードオフを有する。これは、コストの低いハード・ディスクで、より多くのメモリの代替が可能なことによる。さらに、インメモリ・データベース・スキームに用いられるランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）チップは、小型ハード・ドライブの記録密度に達し得ない。インメモリ・データベースに関する別の問題は、一部のアプリケーションにおいて、スペース上の制約から、大規模データベースに対するマイニングは、インメモリ・ストレージの中では行えないことである。一つの対処策は、「ｄ（ディスク）」および「ｍ（メモリ）」双方の型のデータベースを用いる、データベースのハイブリッド検索インデックスを使用することである。

諸実施形態は、データ・マネジメントのための方法、システム、およびコンピュータ・プログラム製品を含む。一つの実施形態において、データベースに対する検索インデックスが生成され、該検索インデックスは、データを第一メモリまたは第二メモリ中のストレージ場所にそれぞれ関連付ける第一または第二型の参照値を有する。データ読み出し要求に応じて、この参照値を使って第一または第二メモリのデータへのアクセスが行われる。第一メモリと第二メモリとの間で、データの移行が行われた場合、検索インデックスの参照値は再計算され変更される。

本開示の技法を介してさらなる特徴および利点が実現される。本明細書で、本開示の他の実施形態および態様が詳細に説明される。本開示の利点および特徴についてより良く理解するために、説明および図面を参照されたい。

発明と見なされる主題は、具体的に指摘され、本明細書に添付の特許請求の範囲で明確に請求されている。本開示の前述および他の特徴および利点は、添付の図面と併せ以下の詳細な説明を理解することによって明らかになろう。

ある実施形態によるフローチャート図である。 ある実施形態による、データへのメモリ・アクセスおよびバッファを表すブロック図を示す。

データベースのハイブリッド検索インデキシングは、フレキシビリティを具えている。ハイブリッド検索インデックスのデータベースは、インメモリおよびディスク・ベース・データベースの両方を使用する。この２つの型のデータ記憶場所の区分はテーブル・レベルで行われる。テーブルは、そのテーブルの全内容がメモリ中に格納されている場合はインメモリ・テーブル（ｍテーブル）として設定することができ、あるいは、データが主としてディスクに格納されている場合はテーブルをディスク・ベース（ｄテーブル）とすることもできる。インメモリ・ストレージおよびディスク・ストレージの両方を使用することによって、パフォーマンスとコストとの間のバランスを達成することができる。

ほとんどのデータベースにおいて、データ読み出しのためにテーブル群がセットアップされ使用される。一つのテーブルは、水平方向の行および垂直方向の列に編成されたデータ・エレメントまたは値のセットであって、行と列との交差個所に複数のセルを有する。慣例的に、テーブルは指定された数の列を有するが、行の数は任意である。各行は、一意的キー・インデックスとして識別された特定の列サブセット中に現れる値によって識別される。データ読み出しオペレーションの速度を向上させるために、データベース・インデックスが使われる。これらインデックスは、データベース・テーブルの一つ以上の列を使って生成でき、迅速なランダム・ルックアップおよび順序付けられたレコードへの効率的アクセスの両方に対するベースを提供する。

ハイブリッド検索インデキシングを用いる際に、単一の設定に２つの異なるデータベースの型を使うこの二分法は、これらのデータベースが相異なる要件を必要とするので、これも難題をもたらす。考えられる対処策の一つに、新規インデックスを（別個のｍ部分およびｄ部分のインデックスの上に）交互に重ねるスキームを採ることがある。しかし、この対処策も、データにアクセスする際に、２つの別個のテーブルのｍ部分とｄ部分との間での連続的な切り替えを強いるので非効率的となり得る。これは、リソース消費的にも時間消費的にもなり得る。さらに、かかるインデックスは、ほとんどのメモリで利用可能なストレージに対しては過大なものとなり得る、フットプリント要求を有する可能性がある。

図１は、リソースおよび検索時間を最適化するハイブリッド・データベースが用いられている一つの実施形態のフローチャート実装を示す。図１に示されるように、例えば一つの実施形態では、ディスク・ストレージ・メモリおよびインメモリなど、２つの型のメモリが使われているが、参照値とバッファ・プールと使用の組み合わせによって、ディスク・ストレージまたはインメモリ・ストレージ中のデータのストレージの識別が可能なので、恒常的な切り替えは必要がない。図２を参照することによって、バッファ・プールへの、そしてディスクもしくはインメモリ・ストレージまたはその両方へのアクセスをより良く理解することができよう。

図２は、図１のフローチャートに従って使用可能な、一つの実施形態によるブロック図を示す。図２において、ストレージ・データベースへのメモリ・アクセスは、インメモリまたは常在メモリ・ストレージ２４０およびディスク・メモリ・ストレージ２３０と処理通信をしているバッファ２２０の使用を介して最適化される。図２に示された実施形態において、インメモリまたは常在メモリは検索エンジン２１０を介してバッファ２２０と処理通信しているが、別の実施形態では、直接の処理アクセスを設けることもできる。なお、常在ストレージ、物理ストレージ、およびインメモリ・ストレージは、互換可能に用いられ、同じ型のメモリ・ストレージを意味する。一つの実施形態において、検索エンジン２１０を介して両方のメモリ・ストレージへのメモリ・アクセスを実現することができ、該エンジンは一つ以上のプロセッサを用いて実装することが可能である。検索エンジン２１０を用いるデジタル・デバイスは、当業者ならよく理解できるように、例えば、以下に限らないが、携帯デバイス、パソコン、またはサーバなど、さまざまなデジタル・デバイスを表すことができ、さらに、ディスプレイ、プリンタ、または他のコンポーネントを含み得、またはそれらと処理通信状態であり得る。他の実施形態において、当業者ならよく理解できるように、バッファ２２０およびディスク・メモリ・ストレージ２３０並びにインメモリ・ストレージ２４０は、単一のデバイスの一部とすることができ、別個の検索エンジン２１０の有無にかかわらず、直接プロセッサまたはコンピュータによるものなど、これらへの直接のアクセスを遂行することができる。

慣例的に、バッファは、データが一つの場所から別の場所に移動される際に、一時的にそのデータを保持するために使われる、物理メモリ・ストレージの或る領域である。このように、バッファは、ディスク・ストレージからのアクセス・データについての情報を保持できるが、これでは、ディスク・ストレージ・データの限られた量だけがバッファリング可能である。図２では、バッファ２２０はバッファ・プールであり、一つの実施形態において、これにはバッファ・プール・マネージャを含めることができる。その結果、当業者ならよく理解しているように、バッファ・プールを、メモリ常駐データに対する常在ストレージとして使いながら、通常の方法でディスク常駐型データをバッファリングすることによって、データベースへの最適化されたアクセスが実現される。

図１および２に関連させて説明した最適化アクセスは、当業者には既知の多くの型の検索インデックス構造体による使用が可能である。この一例として、一組のリンク・ノード群を使って階層ツリーをシミュレートするツリー構造体があろう。一つのノードは、値または状態を包含でき、または別個のデータ構造体を代表でき、さらにはそれ自体をツリーとすることもできる。ツリー中の各ノードは、ゼロ個以上の子ノードを有し、これらはツリー中でそのノードの下にある。子を持つノードは、その子の親ノード（または先行ノード（ａｎｃｅｓｔｏｒ ｎｏｄｅ）、または上位ノード（ｓｕｐｅｒｉｏｒ））と呼ばれる。ノードは親を一つだけ有する。中間ノード（ｉｎｔｅｒｎａｌ ｎｏｄｅ）（内部ノード（ｉｎｎｅｒ ｎｏｄｅ）または分岐ノード（ｂｒａｎｃｈ ｎｏｄｅ）としても知られる）は、子ノードを有する、ツリーの任意のノードである。同様に、外側ノード（ｏｕｔｅｒ ｎｏｄｅ）、葉ノード（ｌｅａｆ ｎｏｄｅ）、または終端ノード（ｔｅｒｍｉｎａｌ ｎｏｄｅ）としても知られる、外部ノード（ｅｘｔｅｒｎａｌ ｎｏｄｅ）は、子ノードを持たない、ツリーの任意のノードである。同様に、バイナリまたはＢツリー構造を使ったツリー構造体にも、図１および２に関連して説明した最適化アクセスを併せ用いることができる。バイナリ・ツリー（Ｂツリー）データ構造体は、ソートされたデータを保持し、検索、シーケンシャル・アクセス、挿入、および削除を対数時間で可能にする。Ｂツリーは、多くの場合、２より多い子を有し、大きなデータ・ブロックを読み取り、書き込みするシステムに向けて最適化されている。

分かり易くするため、図１のフローチャート実施形態は、葉ノードを有するツリー構造体を示しているが、前述のように、別の実施形態では他の検索構造体を使用することができる。再度図１を参照すると、データにアクセスすることが必要なとき、検索は、まずそのデータに関連付けられたデータベースを見出すことから開始される。一つの実施形態において、これは、データベース検索インデックスの中で、行および関連するキーなど、そのインデックス中の所在場所を識別することによって開始することができる。

再度図１を参照すると、一つの実施形態では、次いで、検索インデックス・テーブルがセットアップされ、データ行（ブロック１１０）が該テーブルのｍ部分中にあることが判明した場合、ポインタ（前記インデックス・ツリーの葉ノード中に格納されている）を介して当該ページへのアクセスが行われ、前記データがテーブルのｄ部分に見出された場合は、バッファ・プール・マネージャを呼び出し、ディスク・アドレスを解決し、ページのバッファへのロードを開始することによってアクセスが行われる。この概念を、図１のフローチャートのブロックをさらに詳細に検証しながら以下に説明する。

ブロック１１０から開始され、この事例の検索インデックス・テーブルは、特定のキーを有する特定の行を検索することによって、この事例におけるエントリを見出そうとし、一例として、キー＝ｘ（例えば、数字または文字のストリング）が選択される。ブロック１２０に示されるように、この検索は、該インデックス構造体の葉レベルまで行われる。ブロック１２５に示されるように、次いで、キーに対する参照内容が検定され、参照内容がページ・ポインタかまたはページのディスク・アドレスかが判定される。参照内容がページ・ポインタの場合、そのページ・ポインタを使って、インメモリ・ストレージ（図２の２４０）中にあるｍ部分ページへのアクセス１３０が行われる。次いで、ブロック１６０において、検索で使われたキーと一致するデータを包含する行が、アクセスされたｍ部分ページから読み出される。また一方、参照内容（ｘ）１２５がページのディスク・アドレス１２７の場合、そのディスク・アドレスを解決１４０するためさらなる処理を遂行することができる。さらに、ブロック１５０において、ページのディスク・アドレスが検定され、参照されたページがバッファ・プールの中に存在しているかどうかが判定される。しかして、１５０において、「バッファ・プール・ミス」がなければ（すなわち、当該データがバッファ・プール中に存在する）、１５７に示されるように、バッファ・プールからページのディスク・アドレスに対応するｄ部分ページへのアクセスが行われる。他方、１５０でバッファ・プール・ミスがあった場合、このときは１５５に示されるように、ディスク・メモリ・ストレージ２３０（図２）の参照されたページへのアクセスが行われる。一つの実施形態において、このとき、バッファ・プール・マネージャが呼び出され、参照されたページを包含するデータのチャンクが、ディスク・メモリ・ストレージからバッファ・プールの中に転送される。１６０に示されるように、いずれの場合においても、次いで、検索に使われたキーに一致するデータを包含する行がアクセスされたｄ部分ページから取得される。

図２に関連して説明した最適化アクセスは、大きなメモリ・フットプリントの必要性を必然化しない。慣例的に、ｍテーブル・インデックスはデンス（ｄｅｎｓｅ（密））であり、これは、データベースが、データ・ファイル中のレコード毎にキーとポインタとのペアを有するファイルが存在するように構築されることを意味する。言い換えれば、このファイル中のあらゆるキーは、ソートされたデータ・ファイル中のレコードに対する特定のポインタに関連付けられる。重複キーを有するクラスタ化インデックスでは、デンス・インデックスはそのキーを有する第一レコードをポイントする。ほとんどの場合、インデックス中には、各行に対する一意的なキーおよび参照内容がある。これに反して、ｄテーブル・インデックスは、多くの場合スパース（ｓｐａｒｓｅ（疎））であり、データ・ファイル中のブロック毎にキーとポインタとのペアを有するファイルが設けられるように構築される。このファイル中のあらゆるキーは、ソートされたデータ・ファイル中のブロックに対する特定のポインタに関連付けられる。スパース・インデックスにおいては、キー値のある範囲が単一のデータ・ページにマップされる。これは、キー値がクラスタ化されている（近隣の値が同一のページに配置されている）ので可能である。

結果的に、スパースなデータベースを持つことには、フットプリントのサイズに関してはるかに多くの利点がある。というのは、ハイブリッド・テーブルの全ての行のデンス・インデキシングは、過大なスペースを必要とし、単一のハイブリッド・テーブルを維持するための難題となり得るからである。さらに、単一のハイブリッド・テーブルの使用において、処理のためｄ部分データ・ブロックをメモリ中に効率的にロードするために、一般的なページのバッファ・プール対処法をなお保持する必要がある。別の課題は、「ｍ」部分と「ｄ」部分との間でのデータの容易な移行を促進することであった。しかしながら、メモリ・インデックスとしてのｍ部分へのアクセスに効率的であり、スパース・インデックスを含むことによってスペースを節約する、単一テーブル・インデックスではあるが、ｍ部分とｄ部分との間でのデータの移行がなおリソース消費的であり得るので、十分なものではない。この原因は、かかる移行には、ｍ部分からｄ部分へ物理的に転送されるデータのコピーが必要とされることである。データ移行の必要性は、通常、データの経時的処理をもたらし、これは、高い頻度では使われず、より低速の媒体に移行すべきより古いデータを処理することを意味する。

図２に関連して説明した最適化アクセスにおいて、スパース・インデックスを使うことが可能で、単に、参照内容の型を変更し参照値を再計算することによって、ｍ部分とｄ部分との間でデータを移行することができる。ページの内容を変更する必要はない。一つの実施形態において、この移行は明示的に行うことができ、またはこれに換えて、ＬＲＵ（ｌｅａｓｔ ｒｅｃｅｎｔｌｙ ｕｓｅｄ（最長時間未使用法））待ち行列のようなページ置き換えメカニズムに関連付けることも可能である。最近使用されていないｍ部分ページは、ｄ部分の変更ページに変えることができ、これは移行を効率的に実施させる。このやり方は、ｍ部分とｄ部分と間での容易なデータ移行を提供する。加えて、ｍテーブルの行へのアクセスの効率は維持され、テーブルの行は、インメモリ・インデックスおよびメモリ・ポインタを介してアクセスされる。この事例では、ディスクのページ・アドレスを解決するためにバッファ・プール・マネージャを呼び出す必要があるので、ｍ部分の行へのアクセスはｄ部分の行へのアクセスよりも効率的であり得る。バッファ・プール・マネージャが、ディスクのページ・アドレスを変換してページ・ヒットおよびページ・ミスを生じ、それらに基づき適切に動作できるようにすることによって、ｄ部分の大容量が維持される。これは、前述のように、特に、データがメモリ自体に収まらず、相異なる型の別個のテーブル中に分割しなければならない場合など、メモリに収めるのに大きすぎ、柔軟性がなく、検索にコストのかかるインデックス・テーブルを使用することに関連する多くの問題に対処する。

本明細書で使用する用語は、単に特定の実施形態を説明する目的のためのものであり、本開示を限定することは意図されていない。本明細書で用いられる、単数形「ある（“ａ”、“ａｎ”）」、および「該（“ｔｈｅ”）」は、文脈上明確に別途に示されていなければ、複数形も同じように含むことが意図されている。さらに、当然のことながら本明細書で用いられる「含む（“ｃｏｍｐｒｉｓｅ”）」もしくは「含んでいる（“ｃｏｍｐｒｉｓｉｎｇ”）」またはその両方は、述べられた機能、完全体、ステップ、オペレーション、エレメント、もしくはコンポーネント、またはこれらの組み合わせの存在を特定するが、一つ以上の他の機能、完全体、ステップ、オペレーション、エレメント、コンポーネント、もしくはその群、またはこれらの組み合わせの存在または追加を排除するものではない。

添付の特許請求の範囲中のミーンズ・プラス・ファンクションまたはステップ・プラス・ファンクションの要素全ての、対応する構造、材料、動作および均等物は、具体的に請求された他の請求要素と組み合わせてその機能を遂行するための、一切の構造、材料または動作を包含することが意図されている。本開示の記述は、例示および説明の目的で提示されたもので、網羅的であることも、または本発明を開示した形態に限定することも意図されていない。当業者には、本開示の範囲および趣旨から逸脱することのない多くの修改および変形が明白であろう。本実施形態は、本開示の原理および実際的な応用を最善に説明し、他の当業者が、意図する特定の用途に適したさまざまな修改を加えたさまざまな実施形態に関して、本開示を理解できるように選択し説明されたものである。

さらに、当業者ならよく理解しているように、本開示の態様は、システム、方法、またはコンピュータ・プログラム製品として具現することができる。従って、本開示の態様は、全体がハードウェアの実施形態、全体がソフトウェアの実施形態（ファームウエア、常駐ソフトウェア、マイクロコードなどを含む）、あるいは、本明細書では全て一般的に「回路」、「モジュール」、または「システム」といわれることもある、ソフトウェアおよびハードウェア態様を組み合わせた実施形態の形を取ることができる。さらに、本開示の態様は、具体化されたコンピュータ可読プログラム・コードを有する一つ以上のコンピュータ可読媒体（群）中に具現されたコンピュータ・プログラム製品の形を取ることもできる。

一つ以上のコンピュータ可読媒体（群）の任意の組み合わせを用いることができる。コンピュータ可読媒体は、コンピュータ可読信号媒体、またはコンピュータ可読ストレージ媒体とすることができる。コンピュータ可読ストレージ媒体は、例えば、以下に限らないが、電子的、磁気的、光学的、電磁気的、赤外的、または半導体の、システム、装置、もしくはデバイス、あるいはこれらの任意の適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のさらに具体的な例（非包括的リスト）には、一つ以上の配線を有する電気接続、携帯型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）またはフラッシュ・メモリ）、光ファイバ、携帯型コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ：ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ−ｏｎｌｙ ｍｅｍｏｒｙ）、光ストレージ・デバイス、磁気ストレージ・デバイス、または前述の任意の適切な組み合わせが含まれよう。本文書の文脈において、コンピュータ可読ストレージ媒体は、命令実行システム、装置、またはデバイスによって、あるいはこれらに関連させて使用するためのプログラムを包含または格納できる任意の有形媒体とすることができる。

コンピュータ可読信号媒体には、例えばベースバンド中にまたは搬送波の一部として具現化されたコンピュータ可読プログラム・コードを有する、伝播データ信号を含めることができる。かかる伝播信号は、以下に限らないが、電磁気的、光学的、またはこれらの任意の適切な組み合わせを含め、さまざまな形態の任意の形を取ることが可能である。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではないが、命令実行システム、装置、またはデバイスによってまたはこれらに関連させて使用するためのプログラムを通信、伝播、または伝送が可能な任意のコンピュータ可読媒体であり得る。

コンピュータ可読媒体中に具現化されたプログラム・コードは、以下に限らないが、無線、有線、光ファイバ・ケーブル、ＲＦなど、または前述の任意の適した組み合わせを含め、任意の適切な媒体を用いて送信することができる。

本開示の態様のオペレーションを実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋などのオブジェクト指向プログラミング言語、および、“Ｃ”プログラミング言語または類似のプログラミング言語などの従来式手続き型プログラミング言語を含め、一つ以上のプログラミング言語の任意の組み合わせで記述することができる。このプログラム・コードは、スタンドアロン・ソフトウェア・パッケージとしてユーザのコンピュータで専ら実行することも、ユーザのコンピュータで部分的に実行することもでき、一部をユーザのコンピュータで一部を遠隔コンピュータで実行することもでき、あるいは遠隔のコンピュータまたはサーバで専ら実行することもできる。後者の場合は、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）または広域ネットワーク（ＷＡＮ：ｗｉｄｅａｒｅａ ｎｅｔｗｏｒｋ）を含む任意の種類のネットワークを介して、遠隔コンピュータをユーザのコンピュータに接続することもでき、あるいは（例えばインターネット・サービス・プロバイダを使いインターネットを介し）外部のコンピュータへの接続を行うこともできる。

本開示の実施形態による方法、装置（システム）およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照しながら、本開示の態様を上記で説明してきた。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、および、フローチャート図もしくはブロック図またはその両方中のブロックの組み合わせは、コンピュータ・プログラム命令によって実装することが可能である。これらのコンピュータ・プログラム命令を、汎用コンピュータ、特殊用途コンピュータ、またはマシンを形成する他のプログラム可能データ処理装置のプロセッサに供給し、そのコンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行されるこれらの命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に規定された機能群／動作群を実装するための手段を生成するようにすることができる。

また、これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスに対し特定の仕方で機能するよう命令することができるコンピュータ可読媒体に格納し、そのコンピュータ可読媒体に格納された命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に規定された機能／動作を実装する命令群を包含する製造品を生成するようにすることができる。

さらに、コンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードし、当該コンピュータ上、他のプログラム可能装置上、または他のデバイス上で一連のオペレーション・ステップを実行させて、コンピュータ実装のプロセスを生成し、当該コンピュータ上または他のプログラム可能装置上で実行される命令が、フローチャートもしくはブロック図またはその両方のブロックまたはブロック群中に規定された機能群／動作群を実装するためのプロセスを提供するようにすることも可能である。

図中のフローチャートおよびブロック図は、本開示のさまざまな実施形態による、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、およびオペレーションを例示している。この点に関し、フローチャートまたはブロック図中の各ブロックは、規定の論理機能（群）を実装するための一つ以上の実行可能命令を含む、モジュール、セグメント、またはコードの部分を表し得る。また、一部の別の実装においては、ブロック中に記載された機能が、図に記載された順序を外れて行われ得ることに留意すべきである。例えば、連続して示された２つのブロックが、関与する機能によって実際にはほぼ同時に実行されることがあり、時にはこれらのブロックが逆の順序で実行されることもあり得る。さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方中のブロック群の組み合わせは、特定の機能または動作を実施する、専用ハードウェア・ベースのシステム、または専用ハードウェアとコンピュータ命令との組み合わせによって実装可能なことにも留意すべきである。

２１０ 検索エンジン
２２０ バッファ
２３０ ディスク・メモリ・ストレージ
２４０ インメモリ・ストレージ

Claims (17)

1. 一つ以上のプロセッサを用いて実装される検索エンジンが、データベースに対する検索インデックスを生成するステップであって、前記検索インデックスは、データを第一メモリまたは第二メモリ中のストレージ場所にそれぞれ関連付ける第一型の参照値または第二型の参照値を有する、前記生成するステップと、
   前記検索エンジンが、データ読み出し要求に応じ、前記参照値を使って、前記第一メモリまたは前記第二メモリのデータにアクセスするステップと、
   前記検索エンジンが、前記検索インデックスの参照内容の型を変更し参照値を再計算することによって、前記第一メモリと第二メモリとの間でデータを移行するステップと、
   を含む、データ・マネジメントの方法。
2. 前記第一メモリがインメモリ・ストレージであり、前記第二メモリがディスク・メモリ・ストレージである、請求項１に記載の方法。
3. 前記データ読み出し要求の対象である特定のデータのアドレスが前記ディスク・メモリ・ストレージのアドレスであって、前記特定のデータがバッファ・プールにおいてアクセス可能であると判定された場合、前記第二型の前記参照値を使って、前記バッファ・プールの前記特定のデータにアクセスするステップをさらに含む、請求項２に記載の方法。
4. 前記検索インデックスがツリー構造のインデックスである、請求項３に記載の方法。
5. 前記ツリーが葉ノードを有する、請求項４に記載の方法。
6. 前記第一型の前記参照値はインメモリ・ストレージへのページ・ポインタであり、前記第二型の前記参照値はページのディスク・アドレスである、請求項５に記載の方法。
7. 与えられた前記参照値による前記ページ・ポインタまたは前記ページのディスク・アドレスを用いて、データ・アクセスが提供される、請求項６に記載の方法。
8. インメモリ中のメモリ・データに対する前記葉ノードのインデキシング参照値は、前記バッファ・プール中のページへのポインタであり、ディスク・データに対する前記葉ノードのインデキシング参照値は、ディスク・アドレスである、請求項５に記載の方法。
9. 前記検索インデックスが、バイナリ（Ｂツリー）インデックス構造体である、請求項５に記載の方法。
10. 前記検索インデックスは複数の行および列を有し、前記行は関連付けられたキーを有する、請求項６に記載の方法。
11. 前記キーの順序付けが、前記行の順序付けに対応する、請求項１０に記載の方法。
12. データ・マネジメントのためのコンピュータ・プログラムであって、前記コンピュータ・プログラムが、コンピュータに、データベースに対する検索インデックスを生成するステップであって、前記検索インデックスは、データを第一メモリまたは第二メモリ中のストレージ場所にそれぞれ関連付ける第一型の参照値または第二型の参照値を有する、前記生成するステップと、
    データ読み出し要求に応じ、前記参照値を使って、前記第一メモリまたは前記第二メモリのデータにアクセスするステップと、
    前記検索インデックスの参照内容の型を変更し参照値を再計算することによって、前記第一メモリと第二メモリとの間でデータを移行するステップと、
    を実行させる、コンピュータ・プログラム。
13. 前記検索インデックスは複数の行および列を有し、前記インデックスは各行に対応する関連付けられたキーを有する、請求項１２に記載のコンピュータ・プログラム。
14. インデキシングの粒度はページであり、前記検索インデックスは、追加のオンページ・アクセスを持つことができるようにされた、請求項１３に記載のコンピュータ・プログラム。
15. 前記第一メモリがインメモリ・ストレージであり、前記第二メモリがディスク・メモリ・ストレージである、請求項１４に記載のコンピュータ・プログラム。
16. 前記検索インデックスが、スパース・インデックスであり、ディスク・ページとメモリ・ページとは、内容を除いて構造が同一である、請求項１４に記載のコンピュータ・プログラム。
17. インメモリ・ストレージと、
    前記インメモリ・ストレージと処理通信をしているディスク・メモリ・ストレージと、
    前記インメモリ・ストレージおよび前記ディスク・メモリ・ストレージと処理通信をしているバッファであって、前記バッファはバッファ・プールを取り扱うためのバッファ・プール・マネージャを含む、前記バッファと、
    データ検索インデックス構造体を管理するための少なくとも一つのプロセッサを有するデータベース検索エンジンであって、前記検索インデックスはデータを前記インメモリ・ストレージおよび前記ディスク・メモリ・ストレージに関連付ける第一型の参照値または第二型の参照値を有する、前記検索エンジンと、
    を含むシステムであって、
    前記第一型の参照値は、前記バッファ・プール中の、インメモリ・ストレージへのページ・ポインタであり、前記第二型の参照値は、前記バッファ・プールによって処理されるページのディスク・アドレスであり、
    前記検索エンジンは、前記検索インデックスの参照内容の型を変更し参照値を再計算することによって、前記インメモリ・ストレージと前記ディスク・メモリ・ストレージとの間でデータを移行する、システム。

Images