JP6982049B2 - インデックスを管理するための方法、装置、設備及び記憶媒体 - Google Patents

Description

本開示の実施例は主にコンピュータ分野に関し、さらに具体的に、インデックスを管理するための方法、装置、設備及びコンピュータ読み取り可能な記憶媒体に関する。

さまざまな分野のデータに対する需要が高まるにつれて、データベース技術がますます広く使用されるようになっている。必要なデータをさらに便利にクエリーするために、データベースにセカンダリインデックスを構築する必要がある。データの持続的な更新に伴い、構築されたインデックスの一部はそれが示すデータに適用しなくなる可能性があり、このようなインデックスはクリーンアップする必要がある。そのため、データベースの性能を高めるために、これらのインデックスを効率的に管理する必要がある。ところが、インデックス管理の従来方式において、各処理すべきインデックス及びそれが示すデータに対して一連の動作を実行しなければ該インデックスがクリーンアップされるべきか否かを判定できないため、データベースの性能が低下する。

本開示の例示的な実施例により、インデックスを管理するための解決手段を提供する。

本開示の第１態様において、インデックスを管理する方法を提供する。該方法は、データベースに格納されている目標データについての目標インデックスを確定するステップであって、目標インデックスは、目標インデックスの記憶バージョンを識別するための対応するインデックスマークを含む、ステップを含む。該方法は、目標インデックスに基づいて、データベースに格納されている目標データを取得するステップであって、目標データは、目標データの記憶バージョンを識別するための対応するデータマークを含む、ステップをさらに含む。該方法は、インデックスマークとデータマークとがマッチングしていないことに応答して、目標インデックスに関連付けられる動作を決定するステップをさらに含む。

本開示の第２態様において、インデックスを管理するための装置を提供する。該装置は、データベースに格納されている目標データについての目標インデックスを確定するように構成されるインデックス確定モジュールであって、目標インデックスは、目標インデックスの記憶バージョンを識別するための対応するインデックスマークを含む、インデックス確定モジュールを備える。該装置は、目標インデックスに基づいて、データベースに格納されている目標データを取得するように構成されるデータ取得モジュールであって、目標データは、目標データの記憶バージョンを識別するための対応するデータマークを含む、データ取得モジュールをさらに備える。該装置は、インデックスマークとデータマークとがマッチングしていないことに応答して、目標インデックスに関連付けられる動作を決定するように構成される動作決定モジュールをさらに備える。

本開示の第３態様において、１つ又は複数のプロセッサと、１つ又は複数のプログラムを格納するための記憶装置であって、１つ又は複数のプログラムが１つ又は複数のプロセッサにより実行されると、１つ又は複数のプロセッサに本開示の第１態様に記載の方法を実行させる記憶装置とを備える設備を提供する。

本開示の第４態様において、コンピュータプログラムが格納されているコンピュータ読み取り可能な媒体であって、該プログラムがプロセッサにより実行されると、本開示の第１態様に記載の方法が実行される媒体を提供する。

発明の概要の部分に説明した内容は、本開示の実施例の肝要又は重要な特徴を制限するものではなく、本開示の範囲を制限するものでもないことを理解すべきである。本開示のほかの特徴は以下の説明を通して容易に理解される。

図面及び以下の詳しい説明を参照して、本開示の各実施例の上記及びほかの特徴、メリット及び態様がさらに明らかになる。図面において、同じ又は類似する図面の記号は同じ又は類似する要素を示す。

本開示の実施例が実行される例示的な環境の概略図を示す。 本開示の実施例によるインデックスを管理するプロセスのフローチャートを示す。 図示した本開示の一部の実施例によるデータ記憶構造の概略図を示す。 図示した本開示の一部の実施例によるインデックスマークとデータマークを記憶するテーブルの概略図を示す。 図示した本開示の一部の実施例による介入フィールドの概略図を示す。 本開示の一部の実施例による目標インデックスに関連付けられる動作を決定するプロセスのフローチャートを示す。 本開示の実施例によるインデックスを管理するための装置の概略ブロック図を示す。 本開示の複数の実施例を実施できるコンピューティングデバイスのブロック図を示す。

次に図面を参照して本開示の実施例をさらに詳しく説明する。図面には本開示の一部の実施例を示したが、本開示は様々な形式で実施でき、ここで説明した実施例に制限されると解釈すべきではなく、逆に本開示をさらに明確且つ完全に理解させるためにこれらの実施例を提供するものであることを理解すべきである。本開示の図面及び実施例は例示的な作用のみに用いられ、本開示の保護範囲を制限するためのものではないと理解すべきである。

本開示の実施例の説明において、「含む」又は「備える」という用語及び類似する用語は、非限定（ｏｐｅｎ−ｅｎｄｅｄ）の表現であると理解すべきであり、即ち、「それらを含むが、それらに限定されない」という意味である。「基づく」という用語は、「少なくとも部分的に基づく」として理解すべきである。「１つの実施例」又は「当該実施例」という用語は、「少なくとも１つの実施例」として理解すべきである。「第１」、「第２」などの用語は、異なる又は同じ対象を指してもよい。次の内容はほかの明確又は暗黙的な定義を含み得る。

前文に記載したとおり、データクエリーリクエストにさらによく応答するように、場合によっては、データベースにセカンダリインデックスを構築する必要がある。次にデータベースＨＢａｓｅを例として説明する。ＨＢａｓｅは高信頼性、高性能、列向けの拡張可能な分散型記憶システムである。ユーザは行キー（ｒｏｗｋｅｙ）と行キーの範囲を通してデータの検索と主キークエリー（行キーを主キーとする）を行い、性能を高めて大量データから目標データをクエリーすることができる。ところが、実際の使用においては、非主キーに対するクエリーの需要が多い。ＨＢａｓｅは非主キーをスキャンするためのフィルタリングの方式を提供したが、このような方式に必要なデータは全テーブルスキャンを必要とし、クラスター全体の性能に対して消耗が多く、且つクエリー性能が低く、データ量が非常に多い場合に適用されない。

非主キークエリーを使用するために、現在では、通常ＨＢａｓｅソースデータテーブルにおけるデータに対して転置インデックス（即ち、セカンダリインデックス）を構築し、次に、転置インデックスにおける行キーを通して対応するＨＢａｓｅソースデータテーブルの行キー情報を取得し、さらに目標データを特定する。転置インデックスの記憶は設計に関連し、ＨＢａｓｅソースデータテーブルと同一テーブルにしてもよく、別のテーブルにしてもよい。

ストリーミングデータ制作中、ＨＢａｓｅソースデータテーブルにおけるデータが持続的に更新されるため、転置インデックスのうち、それが示すデータに適用しないインデックス（本明細書ではダーティインデックス（Ｄｉｒｔｙ Ｉｎｄｅｘ）とも称される）の存在をもたらす。この場合、ダーティインデックスをクリーンアップするために消去動作を実行する必要がある。データを書き込む時にダーティインデックスをクリーンアップすることは書き込み速度の低下につながる。書き込み性能が高いシステムは、通常、該動作を遅延してデータを読み取る際に行うようにする。

従来、セカンダリインデックスの消去遅延は２種類の解決手段を用いる。第１の解決手段はバッチ消去遅延である。当該解決手段において、データを読み取るとともにデータのすべてのセカンダリインデックスに対して消去ロジック判断を行うことにより、あるセカンダリインデックスをクリーンアップするか否かを判定する。第２の解決手段はオンデマンド遅延消去である。当該解決手段において、データを読み取るとともにクエリーによりヒットしたセカンダリインデックスのみに対して消去ロジック判断を行い、多くともヒットしたインデックスデータに影響を与える。

ところが、これらの２種類の従来の解決手段において、いずれも各処理すべきインデックスに対して一連の動作（即ち、消去ロジック判断）を実行しなければ該インデックスがクリーンアップされるべきか否かを判定できないので、データベースの性能が低下してしまう。そのほか、これらの２種類の従来の解決手段は使用の場面が異なるため、もたらす問題と欠陥も異なる。第１の解決手段はインデックスへのアクセスが集中する場合のみに応用でき、応用範囲が限られる。バッチ消去遅延は、多数の無関係なインデックスも消去する可能性があり、性能の低下を引き起こす。第２の解決手段は需要に応じてインデックスデータを消去できるが、クエリーを行う度にヒットしたインデックスをクリーンアップする必要があるか否かを判断する必要があるため、性能の低下につながる。

本開示の実施例により、インデックスを管理する解決手段を提供する。該解決手段において、目標インデックスの記憶バージョンを識別するためのインデックスマークと、目標データの記憶バージョンを識別するためのデータマークを設定し、インデックスマークとデータマークを比較することにより、目標インデックスに関連付けられる動作を決定することができる。この方式により、目標インデックスが削除されるべきか否かを判定することに必要な動作を減少することができる。そのため、本開示の解決手段は、データベースインデックスの効果的な管理を実現し、後続の呼び出しに必要なタイムオーバヘッド（ｔｉｍｅ ｏｖｅｒｈｅａｄ）を低減し、且つデータ読み取りの性能を高めることができる。

次に図面を参照して本開示の実施例を詳しく説明する。

図１は本開示の実施例が実行される例示的な環境１００の概略図を示す。該例示的な環境１００において、データベース１０１にデータ１２１、１２３が記憶されるが、データはデータの記憶バージョンを識別するための対応するデータマーク１２２、１２４を含む。データマークは、データの記憶バージョンを識別できるようなタイムスタンプ、又は所定ルールに基づいて定義した一連の数値であってもよい。インデックス１１１、１１３は、インデックスの記憶バージョンを識別するための対応するインデックスマーク１１２、１１４を含む。インデックスマークは、タイムスタンプ、所定ルールに基づいて定義した一連の数値、或いは所定マークであってもよい。次に、図３及び図４を参照してデータマークとインデックスマークを詳しく説明する。

インデックス１１１、１１３は、データベース１０１に記憶された、対象とするデータを示すことができ、例えば、その対象とするデータのデータベース１０１における記憶位置を利用してデータを示すことができる。例えば、インデックス１１１はデータ１２１を対象とするインデックスであってもよい。インデックス１１１、１１３は、データベース１０１に記憶されたデータの現在バージョン或いは以前のバージョンに基づいて生成されてもよい。例えば、インデックス１１１、１１３はセカンダリインデックス又は転置インデックスであってもよい。

前文に記載したとおり、データベース１０１に記憶されたデータの更新につれて、一部のインデックス（例えば、データの以前のバージョンに基づいて生成したインデックス）は、元々対象としたデータを示すのに適さなくなる場合がある。この場合、コンピューティングデバイス１０２でインデックス（例えば、インデックス１１１、１１３）を管理し、例えば、その中のダーティインデックスをクリーンアップする。図１に示された環境１００は例示的なものであり、さらに複数のコンピューティングデバイスを用いてデータベース１０１の中のインデックスを決定して管理できることを理解すべきである。コンピューティングデバイス１０２は、固定型コンピューティングデバイスであってもよく、携帯電話、タブレットコンピュータなどのポータブルコンピューティングデバイスであってもよいことを理解すべきである。

データベース１０１は、コンピューティングデバイス１０２の中に記憶されてもよく、コンピューティングデバイス１０２に遠隔で記憶されてもよい。コンピューティングデバイス１０２はクライアント側に構成されてもよく、サーバ側に構成されてもよく、本開示の範囲はこの面で制限されない。図１においてインデックス１１１、１１３をデータ１２１、１２３とともに同一データベース１０１の中に記憶することを示したが、インデックス１１１、１１３は、データ１２１、１２３とは別に記憶してもよく、例えば、ほかのデータベースに記憶してもよいことを理解すべきである。

本開示の実施例により提供されるインデックス管理の解決手段をさらに明確に理解できるように、図２を参照して本開示の実施例をさらに説明する。図２は本開示の実施例によるインデックスを管理するプロセス２００のフローチャートを示す。プロセス２００は、図１のコンピューティングデバイス１０２により実行され得る。分かりやすくするために、図１を参照してプロセス２００を説明する。

ブロック２１０では、コンピューティングデバイス１０２は、データベース１０１に記憶された目標データを対象とする目標インデックスを確定する。分かりやすくするために、次にインデックス１１１を目標インデックスとして説明し、且つ目標インデックス１１１が対象とする目標データはデータ１２１であると仮定する。目標インデックス１１１は、目標インデックス１１１の記憶バージョンを識別するための対応するインデックスマーク１１２を含む。インデックスマーク１１２は、タイムスタンプ、一連の数値の１つ、或いは所定マークであってもよい。

一部の実施例において、プロセス２００はデータクエリーのプロセスと組み合わせてもよい。コンピューティングデバイス１０２は、目標データ１２１を対象とするクエリーリクエストなどのクエリーリクエストを受信し、且つ、クエリーリクエストにおけるキーワードに基づいて目標インデックス１１１を確定することができる。例えば、コンピューティングデバイス１０２は、ユーザからのクエリーリクエストを受信し、且つ該クエリーリクエストを解析することにより、目標インデックス１１１をヒットする。

一部の実施例において、プロセス２００は定期的に実行されてもよく、即ち、コンピューティングデバイス１０２はインデックスを定期的に管理することができる。プロセス２００は、ユーザからの指令などに応答して開始してもよい。そのような実施例において、データベース１０１における各インデックスに対してプロセス２００を実行することができ、目標インデックス１１１は任意のインデックスであってもよい。

ブロック２２０では、コンピューティングデバイス１０２は、目標インデックス１１１に基づいて、データベース１０１に記憶された目標データ１２１を取得するが、目標データ１２１は、目標データ１２１の記憶バージョンを識別するための対応するデータマーク１２２を含む。データマーク１２２は、目標データ１２１の書き込み又は更新に関連するタイムスタンプ、一連の数値の１つなどであってもよい。

一部の実施例において、コンピューティングデバイス１０２は、目標インデックス１１１に基づいて目標データ１２１のデータベース１０１における記憶位置を確定し、且つ、確定された記憶位置に基づいてデータベース１０１から目標データ１２１を取得することができる。例えば、目標インデックス１１１と目標データ１２１がデータベース１０１の同一テーブルの中に記憶される場合、目標インデックス１１１は目標データ１２１の該テーブルにおける行を示すことができ、目標インデックス１１１と目標データ１２１が異なるテーブルの中に記憶される場合、目標インデックス１１１は目標データ１２１を記憶するテーブルと目標データ１２１の該テーブルにおける行を示すことができる。

次に、図３及び図４を参照して例示的に目標インデックス、インデックスマーク、目標データ及びデータマークの間の関係をさらに詳しく説明する。図３は図示した本開示の一部の実施例によるデータ記憶構造３００の概略図を示す。図３はＨＢａｓｅのデータ記憶構造を例として説明しており、それは例示的なものであることを理解すべきである。本開示の実施例は任意の構造で記憶されたデータとインデックスに応用できる。

図３に示されるように、要素３１０は、該行の要素がそれぞれの列ファミリー（Ｃｏｌｕｍｎ Ｆａｍｉｌｙ、ＣＦ）を表すことを識別し、要素３２０は、該行の要素が個々の列を表すことを識別する。データ記憶構造３００は、ｄ列ファミリー（ＣＦ：ｄと示されてもよい）、ｓ列ファミリー３１２（ＣＦ：ｓと示されてもよい）及びｉ列ファミリー３１３（ＣＦ：ｉと示されてもよい）という３つの列ファミリーを含む。ｄ列ファミリー３１１は、フォーマットがｊｓｏｎであるソースデータなどを記憶するための１つのｄ：＠ｃｎｔ列３２１だけを含む。

ｓ列ファミリー３１２は、ソースデータに関連するシステムフィールドを記憶することに用いられる。例えば、ｓ：＠ｔｓ列３２２は、ｄ：＠ｃｎｔ列３２１におけるデータの更新時間を記憶することができる。ｓ：＠ｔａｇ列３２３は、データ（ｄ列ファミリー３１１とｓ列ファミリー３１２のデータが含まれてもよい）の記憶バージョンを識別するためのデータマークを記憶することができる。

ｉ列ファミリー３１３は、インデックスマーク１１２などのインデックスのインデックスマークが記憶されるｉ：＠ｔａｇ列３２５を含む。その例示において、行３３０がインデックスに関連する情報を記憶することに用いられる場合、ｄ列ファミリー３１１とｓ列ファミリー３１２はブランクであってもよく、行３３０がデータに関連する情報を記憶することに用いられる場合、ｉ列ファミリーはブランクであってもよい。該例示において、インデックスとデータに異なる列ファミリーを割り当てることにより、物理ストレージにそれらを隔離することで、インデックスにアクセスする際に、この列に可能な限り少ないデータアクセスが指定され、アクセス速度を高めることができる。

次に図４を参照して１つの具体的な例を説明する。図４は図示した本開示の一部の実施例によるインデックスマークとデータマークを記憶するテーブル４００の概略図を示す。テーブル４００の上の部分はインデックスに関連する情報を記憶することに用いられ、下の部分はデータに関連する情報を記憶することに用いられる。行４３０はデータの行キー４２１（該例において１５とされる）、ソースデータ４２２、更新時間４２３（Ｔ１）及びデータマーク４２４（Ｔ１）を含む。該例において、データマーク４２４はソースデータ４２２の書き込みに対応するタイムスタンプである。行４３０に記憶されたデータは図１における目標データ１２１の１つの具体的な例であり、データマーク４２４は図１におけるデータマーク１２２の１つの具体的な例である。

インデックス４１１と４１３は、行４３０に記憶されたデータ（例えば、ソースデータ４２２）に基づき、予め定義したルールによって生成される。インデックス４１１と４１３は、それぞれ対応するインデックスマーク４１２と４１４を含む。インデックス４１１を例とし、｀Ａｃｔ＿＠ｔｙｐｅ＿１５は、それが対象とする目標データに対して、「ｔｙｐｅ」という属性に対応する属性値が「Ａｃｔ」であり、且つ該目標データが行キー１５の行の中に記憶されることを示す。図４の例において、インデックス４１１と４１３は、ソースデータ４２２を書き込む時に生成され、そのため、データマーク４２４にマッチングするインデックスマークを含み、即ち、いずれもタイムスタンプＴ１である。インデックス４１１と４１３は図１における目標インデックス１１１の具体的な例であり、インデックスマーク４１２と４１４は図１におけるインデックスマーク１１２の具体的な例である。

時間Ｔ２に、行４３０におけるデータが更新され、例えば「ｔｙｐｅ」という属性の属性値が［“Ａｃｔ１”，“ＴＶＰｌａｙ１”］に修正される場合、データマーク４２４がタイムスタンプＴ２に更新される。同時に、｀Ａｃｔ１＿＠ｔｙｐｅ＿１５と｀ＴＶＰｌａｙ１＿＠ｔｙｐｅ＿１５などの新しいインデックスが生成され、且つこれらの２つの新しいインデックスに対応するインデックスマークがタイムスタンプＴ２に設定される。この場合、インデックス４１１と４１３は行４３０に記憶されたデータを示すことに適せず、且つインデックスマーク４１２と４１４もデータマーク４２４にマッチングしない。本開示の実施例において、データマークとインデックスマークはそれぞれデータトラストマークとインデックストラストマーク（トラストマーク（Ｔｒｕｓｔ Ｍａｒｋ）と総称される場合がある）と称される。

図４の例において、データマークとインデックスマークはタイムスタンプの形式を用いる。タイムスタンプは逓増するフィールドであり、且つデータが変化する時、タイムスタンプが変更されるため、データトラストマークとインデックストラストマークがマッチングしなくなり、したがってダーティインデックスの削除（又は消去）メカニズムをトリガーする。そのため、タイムスタンプをトラストマークとして使用することによって、データとインデックスの記憶バージョンを容易に識別することができる。

さらに、予め定義した逓増数列などのほかの形式のデータマークとインデックスマークを用いることができる。例を挙げると、公差ｄの等差数列をトラストマークとして使用できる。データをデータベース１０１に最初に書き込む時、データマークをａに設定し、同時に、生成されたインデックスのインデックスマークもａとする。データが変更される時、データマークがｄずつ逓増し、ａ＋ｄになり、同時に生成された新しいインデックスのインデックスマークがａ＋ｄとされる。この場合、古いインデックスのインデックスマーク（値がａとされる）とデータマーク（ａ＋ｄ）が異なり、それらがマッチングしていないと判定される。他の例示として、公差２の等差数列をトラストマークとして使用できる。データをデータベース１０１に最初に書き込む時、データマークをｂに設定し、同時に、生成されたインデックスのインデックスマークをｂ＋１に設定する。データが変更される時、データマークが２ずつ逓増し、ｂ＋２になり、同時に生成された新しいインデックスのインデックスマークが（ｂ＋１）＋２に設定される。

図３と図４の例において、データ及びそのインデックスが同一テーブルに記憶され、且つ、異なる列ファミリーで区別される。ＨＢａｓｅなどのデータベースに対して、指定された列ファミリーでデータを取得することができる。そのため、そのようなトラストマークの記憶設計は、その１つのメリットとして、データを取得すると同時に、列ファミリーにおける＠ｔｒｕｓｔ列（即ち、トラストマーク）を取得し、予定以外のリクエストを追加する必要がない。本開示の実施例はデータ及びそのインデックスが異なるテーブルに記憶される場合にも適用されることを理解すべきである。

一部の実施例において、ｄ：＠ｃｎｔ列３２１におけるソースデータを容易に変更するために、ｓ列ファミリー３１２は、ｄ：＠ｃｎｔ列３２１におけるソースデータを変更するための１つ又は複数のフィールド（本明細書では介入フィールドとも称される）が記憶される１つ又は複数のｓ：＠ｐｒｏｐ列３２４（図３を参照）を含んでもよい。この場合、最終的に出力したデータは、ｄ列ファミリー３１１とｓ列ファミリー３１２を合併した後に生成された最終的なデータであり、同時に同じフィールドのデータはＣＦ：ｓを基準とする。次に図５を参照して説明する。

図５は図示した本開示の一部の実施例による介入フィールドの概略図５００を示す。図５に示されたｓ：＠ｔｙｐｅ列５２４は、ｓ：＠ｐｒｏｐ列３２４の１つの具体的な実装であると認められ、それはソースデータ４２２の中の属性「ｔｙｐｅ」の属性値を修正するか、或いはそれに介入することに用いられる。図に示されるように、介入フィールド５０１が［“Ａｃｔ２”，“ＴＶＰｌａｙ２”］である場合、最終的に出力する結果５０２はソースデータ４２２とは異なる。介入フィールドはソースデータよりも高い優先度を有する。

そのような実施例において、インデックスマークはタイムスタンプ又は等差数列以外の所定マークをさらに含んでもよく、該所定マークは目標インデックスと目標データの相関性が不明確であることを示すことができる。例えば、所定マークは文字ＮＵＬＬであってもよい。例えば、ソースデータ４２２が更新されたが、介入フィールド５０１が更新されていない場合、生成したインデックスのインデックスマークが、ＮＵＬＬなどの所定マークに設定される。

引き続き、図２を参照して説明する。ブロック２３０では、コンピューティングデバイス１０２は、インデックスマーク１１２とデータマーク１２２がマッチングするか否かを判定する。インデックスマーク１１２とデータマーク１２２が同じフォーマットのタイムスタンプである場合、インデックスマーク１１２とデータマーク１２２が同じであれば、それらがマッチングしていると判定され、インデックスマーク１１２とデータマーク１２２が異なれば、それらがマッチングしていないと判定される。インデックスマーク１１２とデータマーク１２２がいずれもタイムスタンプであるが、フォーマットが異なる場合、インデックスマーク１１２とデータマーク１２２が同じ時間を示すならば、それらがマッチングしていると判定され、インデックスマーク１１２とデータマーク１２２が異なる時間を示すならば、それらがマッチングしていないと判定される。

インデックスマーク１１２とデータマーク１２２が前文に記載の公差ｄの等差数列を用いる場合、インデックスマーク１１２とデータマーク１２２が同じであれば、それらがマッチングしていると判定され、インデックスマーク１１２とデータマーク１２２が異なれば、それらがマッチングしていないと判定される。インデックスマーク１１２とデータマーク１２２が前文に記載の公差２の等差数列を用いる場合、インデックスマーク１１２がデータマーク１２２より１大きければ、それらがマッチングしていると判定され、そうでなければ、それらがマッチングしていないと判定される。

前文に記載したようなインデックスマークがＮＵＬＬなどの所定マークを含む実施例において、インデックスマーク１１２が所定マークであれば、インデックスマーク１１２とデータマーク１２２がマッチングしていないと判定される。

ブロック２３０では、インデックスマーク１１２とデータマーク１２２がマッチングしていないと判定された場合、プロセス２００はブロック２４０まで進む。ブロック２４０では、コンピューティングデバイス１０２は、目標インデックス１１１に関連付けられる動作を決定する。例えば、コンピューティングデバイス１０２は、目標インデックス１１１が削除されるべきか否かを判定するように、目標インデックス１１１を対象とする消去ロジック処理を実行することができる。次に、図６を参照してそのプロセスを説明する。

ブロック２３０でインデックスマーク１１２とデータマーク１２２がマッチングしていると判定された場合、目標インデックス１１１と目標データ１２１が相関性を有することを意味し、目標データ１２１を示すことに用いられる。この場合、目標インデックス１１１及びそのインデックスマーク１１２が保持される。

（ブロック２１０を参照して上述したように）プロセス２００とデータクエリープロセスを合わせた実施例において、インデックスマーク１１２とデータマーク１２２がマッチングしていると判定された場合、コンピューティングデバイス１０２は目標データ１２１に基づいてクエリーリクエストに対する応答を提供することができる。例えば、コンピューティングデバイス１０２は目標データ１２１に基づいてクエリーの結果を確定し、クエリーの結果を提供してクエリーリクエストへの応答とすることができる。上記介入フィールドがない場合、コンピューティングデバイス１０２は目標データ１２１の対応する部分（例えば、ソースデータ４２２）をクエリーの結果として提供することができる。上記介入フィールド（例えば、介入フィールド５０１）がある場合、コンピューティングデバイス１０２はソースデータ４２２と介入フィールド５０１に基づいてクエリーの結果５０２（図５を参照）を確定し、クエリーの結果５０２をクエリーリクエストへの応答として提供することができる。

以上、本開示の実施例によるインデックスを管理するプロセス２００を説明した。この方式により、データマークとインデックスマークを利用して目標インデックスと目標データの間の相関性を示し、且つそれに基づいて目標インデックスが除去されるか否かを判定することができる。そのため、本開示の解決手段は、データベースインデックスを効果的に管理でき、したがって、後続の呼び出しに必要なタイムオーバヘッドを低減し、且つデータ読み取りの性能を高める。

図６は、本開示の一部の実施例による目標インデックスに関連付けられる動作を決定するプロセス６００のフローチャートを示す。プロセス６００は、図１のコンピューティングデバイス１０２により実行され、図２におけるブロック２４０の１つの具体的な実装として認められる。

インデックスマーク１１２とデータマーク１２２がマッチングしていないと判定された場合、ブロック６１０で、コンピューティングデバイス１０２は、目標データ１２１に関連付けられる１組のインデックスを生成する。コンピューティングデバイス１０２は目標データ１２１を解析し、目標インデックス１１１の生成と同じである所定ルールに基づいて該組のインデックスを生成することができる。例を挙げると、コンピューティングデバイス１０２は目標データ１２１を解析し、属性「ｔｙｐｅ」について該組のインデックスを生成することができる。目標データ１２１がソースデータと介入フィールドを含む場合、該組のインデックスを生成する時、コンピューティングデバイス１０２は先にソースデータと介入フィールドを合併し、合併後のデータに基づいて該組のインデックスを生成する。

ブロック６２０では、コンピューティングデバイス１０２はブロック６１０に生成した該組のインデックスが目標インデックス１１１を含むか否かを判定する。該組のインデックスが目標インデックス１１１を含む場合、目標インデックス１１１と目標データ１２１が関連することを意味し、プロセス６００はブロック６３０まで進む。ブロック６３０では、コンピューティングデバイス１０２はデータマーク１２２に基づいてインデックスマーク１１２を修正することにより、インデックスマーク１１２とデータマーク１２２をマッチングさせる。例えば、トラストマークがタイムスタンプである場合、コンピューティングデバイス１０２はインデックスマーク１１２をデータマーク１２２と同じであるタイムスタンプに変更することができる。

目標データ１２１がソースデータと介入フィールドを含む場合、インデックスマークはさらにＮＵＬＬなどの所定マークであってもよい。そのため、一部の実施例において、コンピューティングデバイス１０２はインデックスマーク１１２が所定マークであるか否かを判定することができ、所定マークは目標インデックス１１１と目標データ１２１の相関性が不明確であることを示す。インデックスマーク１１２が所定マークであると判定された場合、コンピューティングデバイス１０２はインデックスマーク１１２をデータマーク１２２に変更することができる。

（ブロック２１０を参照して上述したように）データクエリープロセスを合わせた実施例において、ブロック６３０では、コンピューティングデバイス１０２は目標データ１２１に基づいてクエリーへの応答を提供することができる。例えば、上記図２に説明したものと同様に、コンピューティングデバイス１０２は目標データ１２１に基づいてクエリーの結果を確定し、クエリーの結果をクエリーリクエストへの応答として提供することができる。

コンピューティングデバイス１０２がブロック６２０で該組のインデックスに目標インデックス１１２が含まれないことを確定した場合、目標インデックス１１１は目標データ１２１をもはや示すべきではなく、即ち、目標インデックス１１１はクリーンアップすべきダーティインデックスになる。この場合、プロセス６００はブロック６４０まで進行する。ブロック６４０では、コンピューティングデバイス１０２は目標インデックス１１１とインデックスマーク１１２を削除する。即ち、コンピューティングデバイス１０２はダーティインデックス消去動作を実行する。

本明細書において、図６を参照しながら説明されたプロセス６００は消去ロジック処理と称されてもよい。前文に記載したとおり、データクエリーのプロセス中、データマークとインデックスマークがマッチングしている場合、消去ロジック処理を実行せずに、クエリーの結果を直接提供することができる。これにより、主に従来のオンデマンド消去手段における２つの問題が解決された。１つは、クエリーを行う度にデータを解析する必要があること、もう１つは、クエリーを行う度に目標インデックスが目標データにより生成したインデックスの中にあるか否かを判断する必要があること、である。そのため、そのような実施例において、データマークとインデックスマークの使用により、データクエリーの効率とデータベースの読み取り性能を高めることができる。

インデックスマークとデータマークを使用するために、コンピューティングデバイス１０２は、目標データ１２１に基づいて目標インデックス１１１とインデックスマーク１１２を生成する必要がある。目標データ１２１に介入フィールドが含まれていない場合、目標データ１２１をデータベース１０１に書き込もうとするか、或いは書き込んだと判定された場合、コンピューティングデバイス１０２は目標インデックス１１１とデータマーク１２２を生成し、生成したデータマーク１２２に基づいてインデックスマーク１１２を確定することができる。例えば、目標データ１２１がデータベース１０１に最初に書き込まれる時、或いは、目標データ１２１の更新がインデックスに関連するフィールド（インデックスの構成フィールド）に関わる時、目標インデックス１１１とデータマーク１２２を生成し、例えば、データマーク１２２は、最初に書き込むか或いは目標データ１２１を更新する時のタイムスタンプである。コンピューティングデバイス１０２は、その後、データマーク１２２に基づいてインデックスマーク１１２を修正することにより、両者をマッチングさせることができる。例えば、コンピューティングデバイス１０２は、インデックスマーク１１２をデータマーク１２２と同じであるタイムスタンプに設定することができる。

次に、（図５に示されるように）目標データ１２１がソースデータとソースデータを修正するための介入フィールドとを含む場合を考慮する。目標インデックス１１１が目標データ１２１をデータベース１０１に最初に書き込む時に生成される場合、インデックスマーク１１２の設定は介入フィールドが含まれない場合と同じように、即ち、データマーク１２２にマッチングするように設定される。目標インデックス１１１が目標データ１２１を更新する時に生成される場合、更新されるのはソースデータであるか、介入フィールドであるかを考慮する必要がある。目標データ１２１のソースデータが更新されようとするか、或いはすでに更新されたと判定された場合、コンピューティングデバイス１０２は目標インデックス１１１（インデックスに関連するフィールドを更新する場合）を生成し、対応するインデックスマーク１１２をＮＵＬＬなどの所定マークとして確定することができ、所定マークは、目標インデックス１１１と目標データ１２１の相関性が不明確であることを示す。それは、介入フィールドがソースデータよりも高い優先度を有し、ソースデータを更新する時に介入フィールドを読み取らないことが原因で、目標インデックスと目標データの間の相関性が不明確になってしまうためである。

引き続き、図３、図４及び図５における例を参照して、目標データにソースデータと介入フィールドの両部分が含まれる場合を説明する。データマークの更新は、ｄ列ファミリー３１１とｓ列ファミリー３１２という２つの列ファミリーの更新に分けられる。（１）ｄ列ファミリー３１１（即ちｄ：＠ｃｎｔ列３２１）を更新する時、即ち、ソースデータを更新する時、データマークを更新し、ｄ列ファミリー３１１が元の加工データを保存するため、修正があればデータマークが必ず更新される。（２）ｓ列ファミリー３１２を更新する時、更新されるフィールドがインデックスに関連するフィールドに含まれる時だけ、データマークが更新され、そうでなければ処理されない。図４における例に対して、更新されるフィールドが「ｔｙｐｅ」フィールドに関連する時だけデータマークを更新し、更新されるフィールドが「ｎａｍｅ」である場合はデータマークを更新しない。

インデックスマークの更新は以下の３種類の状況がある。（１）ｄ列ファミリー３１１のデータ初期化が行われる時、データマークにマッチングされるインデックスマークを直接書き込む。（２）ｄ列ファミリー３１１の更新によるインデックス書き込み（即ち、更新はインデックスに関連するフィールドに関わる）の場合、書き込み性能を高めるように、データを書き込む時に古いデータのｓ列ファミリー３１２を読み取って合併しなかったため、インデックスとデータの相関性が不明確になってしまい、そのため、生成したインデックスに対応するインデックスマークがＮＵＬＬなどの所定マークに設定される。（３）ｓ列ファミリー３１２の更新によるインデックスの書き込みの場合、更新されるフィールドはインデックスに関連するフィールドに関わり、インデックスマークをデータマークにマッチングするように設定し、そうでなければ処理しない。

図７は本開示の実施例によるインデックスを管理するための装置７００の概略ブロック図を示す。図７に示されるように、装置７００は、データベースに格納されている目標データについての目標インデックスを確定するように構成されるインデックス確定モジュール７１０であって、目標インデックスは、目標インデックスの記憶バージョンを識別するための対応するインデックスマークを含む、インデックス確定モジュールと、目標インデックスに基づいて、データベースに記憶された目標データを取得するように構成されるデータ取得モジュール７２０であって、目標データは、目標データの記憶バージョンを識別するための対応するデータマークを含む、データ取得モジュールと、インデックスマークとデータマークがマッチングしていないと判定されたことに応答して、目標インデックスに関連付けられる動作を決定するように構成される動作決定モジュール７３０とを備える。

一部の実施例において、動作決定モジュール７３０は、目標データに関連する１組のインデックスを生成するように構成されるデータ解析モジュールと、１組のインデックスが目標インデックスを含むか否かを判定するように構成されるインデックス判断モジュールと、１組のインデックスに目標インデックスが含まれることに応答して、インデックスマークとデータマークをマッチングさせるようにデータマークに基づいてインデックスマークを修正するように構成されるマーク修正モジュールとを備える。

一部の実施例において、マーク修正モジュールは、インデックスマークが目標インデックスと目標データの相関性が不明確であることを示す所定マークであるか否かを判定するように構成されるマーク判定モジュールと、インデックスマークが所定マークであることに応答して、インデックスマークをデータマークに修正するように構成される所定修正モジュールとを備える。

一部の実施例において、装置７００は、１組のインデックスに目標インデックスが含まれないことに応答して、目標インデックスとインデックスマークを削除するように構成されるインデックス削除モジュールをさらに備える。

一部の実施例において、インデックス確定モジュール７１０は、目標データを対象とするクエリーリクエストを受信するように構成されるリクエスト受信モジュールと、クエリーリクエストにおけるキーワードに基づいて、目標インデックスを確定するように構成される目標確定モジュールとを備える。

一部の実施例において、装置７００は、インデックスマークとデータマークがマッチングしていることに応答し、目標データに基づいて、クエリーの結果を確定するように構成される結果確定モジュールと、クエリーの結果をクエリーリクエストへの応答として提供するように構成される結果提供モジュールとをさらに備える。

一部の実施例において、データ取得モジュール７２０は、目標インデックスに基づいて、目標データのデータベースにおける記憶位置を確定するように構成される位置確定モジュールと、記憶位置に基づいて、データベースから目標データを取得するように構成される目標取得モジュールとを備える。

一部の実施例において、装置７００は、目標データに基づいて、目標インデックスとインデックスマークを生成するように構成されるマーク生成モジュールをさらに備える。

一部の実施例において、マーク生成モジュールは、目標データがデータベースに書き込まれるべきと判定されたことに応答して、目標インデックスとデータマークを生成するように構成される第１インデックス生成モジュールと、生成したデータマークに基づいてインデックスマークを確定するように構成されるインデックスマーク確定モジュールとを備える。

一部の実施例において、目標データは、ソースデータとソースデータを修正するための介入フィールドとを含み、マーク生成モジュールは、目標データのソースデータが更新されるべきと判定されたことに応答して、目標インデックスを生成するように構成される第２インデックス生成モジュールと、インデックスマークを、目標インデックスと目標データの相関性が不明確であることを示す所定マークとして確定するように構成される所定マーク確定モジュールとを備える。

図８は、本開示の実施例を実施できる例示的な設備８００の概略ブロック図を示す。設備８００は図１のコンピューティングデバイス１０２を実行することに用いられる。図に示されるように、設備８００は中央処理装置（ＣＰＵ）８０１を含み、それは、読み取り専用メモリ（ＲＯＭ）８０２に格納されたコンピュータプログラム命令、又は記憶ユニット８０８からランダムアクセスメモリ（ＲＡＭ）８０３にローディングされたコンピュータプログラム命令により、様々な適切な動作と処理を実行することができる。ＲＡＭ８０３において、設備８００の動作に必要な様々なプログラムとデータをさらに格納することができる。ＣＰＵ８０１、ＲＯＭ８０２及びＲＡＭ８０３はバス８０４を介して互いに接続される。入力／出力（Ｉ／Ｏ）インターフェース８０５もバス８０４に接続される。

設備８００において、キーボード、マウスなどの入力ユニット８０６、様々なタイプのディスプレー、スピーカなどの出力ユニット８０７、磁気ディスク、光ディスクなどの記憶ユニット８０８、及び、ネットワークカード、モデム、無線通信トランシーバーなどの通信ユニット８０９を備える複数のコンポーネントがＩ／Ｏインターフェース５０５に接続される。通信ユニット８０９は、設備８００がインターネットなどのコンピュータネットワーク及び／又は様々な通信ネットワークを介してほかの設備と情報／データを交換することを許可する。

処理ユニット８０１は、プロセス２００及び６００のいずれかなど、前文に記載の各方法及び処理を実行する。例えば、一部の実施例において、プロセス２００及び６００のいずれかはコンピュータソフトウェアプログラムとして実装され、それは記憶ユニット８０８などの機械可読媒体に具体的に包含される。一部の実施例において、コンピュータプログラムの一部又は全部はＲＯＭ８０２及び／又は通信ユニット８０９によって設備８００にローディング及び／又はインストールされる。コンピュータプログラムがＲＡＭ８０３にローディングされ、且つＣＰＵ８０１により実行される場合、前文に記載のプロセス２００又は６００の１つ又は複数のステップを実行することができる。必要に応じて、ほかの実施例において、ＣＰＵ８０１は、ほかの任意の適切な方式（例えば、ファームウェア）により、プロセス２００及び６００のいずれかを実行するように構成される。

本明細書において以上で記載した機能は少なくとも部分的に１つ又は複数のハードウェアロジックコンポーネントにより実行される。例えば、使用される例示的なハードウェアロジック部材には、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け標準部品（ＡＳＳＰ）、システムオンチップ（ＳＯＣ）、コンプレックスプログラマブルロジックデバイス（ＣＰＬＤ）などが含まれるが、これらに限定されない。

本開示の方法を実施するためのプログラムコードは、１つ又は複数のプログラミング言語のいずれかの組み合わせを用いて作成することができる。これらのプログラムコードは、汎用コンピュータ、専用コンピュータ又はその他のプログラマブルデータ処理装置のプロセッサ又はコントローラに提供され、それにより、プログラムコードがプロセッサ又はコントローラにより実行される時に、フローチャート及び／又はブロック図に規定された機能／動作を実施させる。プログラムコードは完全に或いは部分的に機器で実行され、独立したソフトウェアパッケージとして機器で部分的に実行され、部分的或いは完全に遠隔機器又はサーバで実行される。

本開示の文脈により、機械可読媒体は、命令実行システム、装置又は設備に使用されるか、或いは命令実行システム、装置又は設備と合わせて使用されるプログラムを含むか、或いは格納することができる有形の媒体であってもよい。機械可読媒体は機械可読信号媒体又は機械可読記憶媒体であってもよい。機械可読媒体としては、電子、磁気、光学、電磁気、赤外線又は半導体システム、装置又は設備、又はこれらのあらゆる適切な組み合わせが挙げられるが、それらに限定されない。機械可読記憶媒体のさらに具体的な例として、１本又は複数のケーブルに基づく電気的接続、ポータブルコンピュータディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバ、ポータブルＣＤ読み取り専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶設備、又はこれらのあらゆる適切な組み合わせが挙げられる。

また、特定順序により各動作を説明したが、これらの動作を示された特定順序や順番で実行することが要求されるか、或いは、期待されている結果を取得できるように、すべての図示された動作が実行されることが要求されることを理解すべきである。一定の環境において、マルチタスクと並列処理が有利である場合がある。同様に、前文の説明に複数の具体的な実装の詳細が含まれているが、これらは本開示の範囲を制限するものとして解釈すべきではない。単独的な実施例の文脈に記載した一部の特徴はさらに組み合わせて単一の実装に実装することができる。逆に、単独的な実装の文脈に記載した様々な特徴を、単独的に、或いはあらゆる適切な組み合わせの方式で複数の実装に実装することができる。

構造の特徴及び／又は方法のロジック動作の特定言語で本テーマを説明したが、添付した特許請求の範囲に規定されたテーマは前文に記載した特定の特徴又は動作に制限されないことを理解すべきである。むしろ、前文に記載した特定の特徴と動作は特許請求の範囲を実装するための例示的な形態にすぎない。

Claims (19)

1. インデックスを管理するための方法であって、
   データベースに格納されている目標データについての目標インデックスを確定するステップであって、前記目標インデックスは、目標インデックスの記憶バージョンを識別するための対応するインデックスマークを含む、ステップと、
   前記目標インデックスに基づいて、前記データベースに格納されている前記目標データを取得するステップであって、前記目標データは、前記目標データの記憶バージョンを識別するための対応するデータマークを含む、ステップと、
   前記インデックスマークと前記データマークとがマッチングしていない場合、
   前記目標データに関連付けられる１組のインデックスを生成するステップと、
   前記１組のインデックスに前記目標インデックスが含まれていることに応答して、前記インデックスマークが、前記目標インデックスと前記目標データの相関性が不明確であることを示す所定マークであるか否かを判定するステップと、
   前記インデックスマークが前記所定マークであることに応答して、前記インデックスマークと前記データマークとがマッチングするように、前記インデックスマークを前記データマークに修正するステップとを含む方法。
2. 前記１組のインデックスに前記目標インデックスが含まれていないことに応答して、前記目標インデックスと前記インデックスマークを削除することをさらに含む請求項１に記載の方法。
3. 前記目標インデックスを確定するステップは、
   前記目標データについてのクエリーリクエストを受信することと、
   前記クエリーリクエストにおけるキーワードに基づいて、前記目標インデックスを確定することとを含む請求項１に記載の方法。
4. 前記インデックスマークと前記データマークとがマッチングしていることに応答して、前記目標データに基づいてクエリー結果を確定することと、
   前記クエリー結果を前記クエリーリクエストへの応答として提供することとをさらに含む請求項３に記載の方法。
5. 前記目標データを取得するステップは、
   前記目標インデックスに基づいて、前記目標データの前記データベースにおける記憶位置を確定することと、
   前記記憶位置に基づいて、前記データベースから前記目標データを取得することとを含む請求項１に記載の方法。
6. 前記目標データに基づいて、前記目標インデックスと前記インデックスマークを生成するステップをさらに含む請求項１に記載の方法。
7. 前記目標インデックスと前記インデックスマークを生成するステップは、
   前記目標データを前記データベースに書き込もうとする場合、前記目標インデックスと前記データマークを生成することと、
   生成された前記データマークに基づいて前記インデックスマークを確定することとを含む請求項６に記載の方法。
8. 前記目標データはソースデータと介入フィールドとを含む場合、前記ソースデータと前記介入フィールドを合併し、合併後のデータを目標データとして目標インデックスを生成するステップであって、前記介入フィールドは前記ソースデータの中の属性を修正するためのものである、ステップと、
   前記目標データの前記ソースデータにおけるインデックスに関連するフィールドを更新する場合、前記目標インデックスを生成し、前記インデックスマークを、前記目標インデックスと前記目標データの相関性が不明確であることを示す所定マークにするステップとを、さらに含む請求項６に記載の方法。
9. データベースに格納されている目標データについての目標インデックスを確定するように構成されるインデックス確定モジュールであって、前記目標インデックスは、目標インデックスの記憶バージョンを識別するための対応するインデックスマークを含む、インデックス確定モジュールと、
   前記目標インデックスに基づいて、前記データベースに格納されている前記目標データを取得するように構成されるデータ取得モジュールであって、前記目標データは、前記目標データの記憶バージョンを識別するための対応するデータマークを含む、データ取得モジュールと、
   前記インデックスマークと前記データマークとがマッチングしていない場合、前記目標データに関連付けられる１組のインデックスをデータ解析モジュールによって生成し、
   前記１組のインデックスに前記目標インデックスが含まれていることに応答して、前記インデックスマークが、前記目標インデックスと前記目標データの相関性が不明確であることを示す所定マークであるか否かを、マーク判定モジュールによって判定し、
   前記インデックスマークが前記所定マークであることに応答して、前記インデックスマークと前記データマークとがマッチングするように、所定修正モジュールによって前記インデックスマークを前記データマークに修正するように構成される動作決定モジュールと
   を備える、インデックスを管理するための装置。
10. 前記１組のインデックスに前記目標インデックスが含まれていないことに応答して、前記目標インデックスと前記インデックスマークを削除するように構成されるインデックス削除モジュールをさらに備える請求項９に記載の装置。
11. 前記インデックス確定モジュールは、
    前記目標データについてのクエリーリクエストを受信するように構成されるリクエスト受信モジュールと、
    前記クエリーリクエストにおけるキーワードに基づいて、前記目標インデックスを確定するように構成される目標確定モジュールとを備える請求項９に記載の装置。
12. 前記インデックスマークと前記データマークとがマッチングしていることに応答して、前記目標データに基づいてクエリー結果を確定するように構成される結果確定モジュールと、
    前記クエリー結果を前記クエリーリクエストへの応答として提供するように構成される結果提供モジュールとをさらに備える請求項１１に記載の装置。
13. 前記データ取得モジュールは、
    前記目標インデックスに基づいて、前記目標データの前記データベースにおける記憶位置を確定するように構成される位置確定モジュールと、
    前記記憶位置に基づいて、前記データベースから前記目標データを取得するように構成される目標取得モジュールとを備える請求項９に記載の装置。
14. 前記目標データに基づいて、前記目標インデックスと前記インデックスマークを生成するように構成されるマーク生成モジュールをさらに備える請求項９に記載の装置。
15. 前記マーク生成モジュールは、
    前記目標データを前記データベースに書き込もうとする場合、前記目標インデックスと前記データマークを生成するように構成される第１インデックス生成モジュールと、
    生成された前記データマークに基づいて前記インデックスマークを確定するように構成されるインデックスマーク確定モジュールとを備える請求項１４に記載の装置。
16. 前記目標データはソースデータと前記ソースデータを修正するための介入フィールドとを含む場合、前記ソースデータと前記介入フィールドを合併し、合併後のデータを目標データとして目標インデックスを生成し、前記介入フィールドは前記ソースデータの中の属性を修正するためのものであり、
    前記マーク生成モジュールは、
    前記目標データの前記ソースデータにおけるインデックスに関連するフィールドを更新する場合、前記目標インデックスを生成するように構成される第２インデックス生成モジュールと、
    前記インデックスマークを、前記目標インデックスと前記目標データの相関性が不明確であることを示す所定マークにするように構成される所定マーク確定モジュールとを備える請求項１４に記載の装置。
17. １つ又は複数のプロセッサと、
    １つ又は複数のプログラムを格納するための記憶装置であって、前記１つ又は複数のプログラムが前記１つ又は複数のプロセッサにより実行されると、前記１つ又は複数のプロセッサに請求項１〜８のいずれか１項に記載の方法を実行させる記憶装置と
    を備える設備。
18. コンピュータプログラムが格納されているコンピュータ読み取り可能な記憶媒体であって、
    前記プログラムがプロセッサにより実行されると、請求項１〜８のいずれか１項に記載の方法が実行される記憶媒体。
19. コンピュータプログラムであって、
    前記コンピュータプログラムがプロセッサにより実行されると、請求項１〜８のいずれか１項に記載の方法が実行されるコンピュータプログラム。

Images