JP2014510985A - キャッシュメモリ構造および方法 - Google Patents

Abstract

本発明は、データへのアクセスを制御するためのキャッシュメモリおよび方法に関する。本発明に従い、データ領域（４１０）から分離して有利に形成された管理領域がキャッシュ内に格納されたデータへのアクセスを制御するために提供され、アプリケーティブプロセスによって読み出される。管理領域はオフセット（４４２）つきの少なくとも１つのリリース領域（４３０）と、データバージョン定義セクション（４５２、４５４、４５６）を備える。クライアントサーバアーキテクチャのための共有メモリへ適用される。

Description

本発明は、一般的にはデータ処理の分野に関し、特に、データキャッシュファイルが、マスタデータベースから複数のミドルウェア処理ノードにわたって分散される、分散クライアント／サーバソフトウェアアーキテクチャに関する。より詳細には、本発明は、それらを使用するミドルウェアアプリケーティブプロセス（applicative process）のために、分散されたキャッシュファイルのバージョンを特に管理しつづけるための方法およびシステムに関する。

１９８０年代後半に登場したクライアント／サーバモデルは、当時一般的であった、集中型、メインフレーム型、タイムシェアリング型コンピューティングと比較して、使いやすさ(usability)、フレキシビリティ(flexibility)、相互運用性（interoperability）、およびスケーラビリティ（scalability）を改善するために考案された、多目的かつモジュール式のソフトウェアアーキテクチャである。クライアント／サーバアーキテクチャは、以来、全ての知性が中央ホストコンピュータの中にあり、ユーザは、ダム端末（dumb terminal）を介してホストと対話する、先のメインフレームソフトウェアアーキテクチャを、徐々に完全に置き換えてきた。メインフレームも未だ使用されてはいるが、様々なクライアント／サーバアーキテクチャ内の強力なサーバとしてのみであり、ダム端末もまた、サーバからのデータ受信およびサーバへのデータ送信を自己で処理することが可能な知性的なグラフィカルユーザインターフェース（ＧＵＩ）によって置換されている。

現代のデータ処理システムにおいて、クライアント／サーバアーキテクチャは広く使用され、多数のリモートに位置するクライアントがいわゆる３層（3-tier）アーキテクチャをサポートすることが可能である。このようなアーキテクチャの例を図１に示す。データ層１００は、おそらく商業的および管理的操作の全てのソートを処理するために、いかなるビジネス組織、会社、または事業体の日々の操作への必要な全てデータの多くのまたは非常に多くのリポジトリ、であるマスタデータベースシステム１２０の周辺に伝統的に構築される。データベースは、大部分はリレーショナル型、すなわちリレーショナルデータベース管理システムまたはＲＤＢＭＳの管理下にある。それは典型的には、１つまたはそれ以上のマスタサーバ１１２を介し、データ処理システムの管理者によって、ＧＵＩ１４０から管理される。管理者は、一般的に直接データベースの内容を更新する権限を与えられたシステムの唯一のユーザである。

図１の例示的な３層システムの中位（intermediate）または中間層（middle）は、データ処理システムの所有者である組織の全ての特定のソフトウェアアプリケーション２４０がそこから実行される、アプリケーション層２００である。特定のアプリケーションの集合は、しばしばミドルウェアソフトウェアとしてグローバルに参照され、組織が所有するソフトウェアである。マスタサーバ１１０を介して、そのデータのリポジトリ１２０から、組織の全てのリモートクライアントにサービスするのに使用される。リモートクライアントは３層アーキテクチャの第３層を形成する。クライアント層３００からのクエリは、中間層２００の特定のアプリケーションによって、データ層１００からフェッチされたデータに対し、処理され、応答される。

３層アーキテクチャにおいて、より多数のリモートクライアントがサービスを受ける必要がある場合、グローバルな性能を維持するためのシステムのスケーラビリティは、データ処理システムの全体の処理能力を増大させるために、中間層において独立した処理ノードを追加することによって取得される。従って、アプリケーション層２００は、一般的に、以下の説明でスレーブノード２１０として参照されるいくつかの独立した処理ノードから構成される。また、データ層１００が、増加するスレーブノードからの過度のデータ要求によって圧倒されることを防止するための一般的なプラクティスは、必要な限り、アプリケーティブプロセス２４０にマスタデータベースから持ってきて、かつそれぞれのアプリケーションノードに格納された、データを処理させることである。図１に示す例示的なシステムにおいて、これはアプリケーティブプロセス２４０が必要なときにいつでもマスタサーバを介してマスタデータベースから手に入れるための大きな遅延を受けなければならないことがなく動作可能である、キャッシュファイル２５０の形式を取る。このようなデータ処理システムにおいて、処理能力とソフトウェアアプリケーションは、以下のように分散、すなわち、システムの全てのリモートクライアント３００にサービスを提供するために必要な処理能力のレベルに達するために必要な数のノード２１０上に複製される。これが分散キャッシュファイル２５０である。それぞれのノードにおいて、キャッシュファイルは、典型的にはノード上で実行中の全てのアプリケーティブプロセス２４０の間で共有される。この目的を達成するため、キャッシュファイル２５０は、全てのアプリケーティブプロセスが、マスタデータベースから来て、それにより処理すべきデータへの高速にアクセスさせるために、共有メモリ２３０内のメモリマップドファイルとして格納される。

スレーブノードオペレーティングシステムは、メモリマップドファイルが、作成時にそのサイズが与えられることを課している。このため、ファイルサイズは、キャッシュファイルの寿命の間ずっと同じである。図２に示すように、キャッシュファイル２５０は、メモリマップドファイル１０として実装され、２つの部分で構成される。第１の部分は、メモリマップドファイルの全てのアプリケーティブデータコンテンツを格納するデータ領域２０であり、第２の部分は、管理データを保持する管理領域（control area）３０である。データ領域は、データブロックの２つのリンクリスト（linked list）として編成された２つの部分にさらに分割される。リンクリスト２３の１つは前のレベルのデータ、すなわち、非アクティブデータブロック２４の形式にある古いデータを保持する。他方のリンクリスト２１は、アクティブデータブロック２２の現在のレベルのデータを格納する。しかし、アクティブおよび非アクティブのリンクされたデータブロックは、同一のメモリマップドファイル領域、すなわちデータ領域２０を共有する。

管理領域３０は、どのリンクリストがアクティブデータを含んでいるのかを示す。フリップフロップメカニズムは、管理領域の一部であり、メモリマップドファイルを読み出す、いかなるアプリケーティブプロセスも最新のデータへのアクセスが常に与えられるように、データブロックのリンクリストへのアクティブ３１および非アクティブ３２ポインタの間をトグルすることを許可する。従って、マスタデータベースからのデータの複製中、非アクティブ部分のデータブロックは、新しく入ってくるデータで満たされるように、最初にクリアされる。新しいデータの挿入が完了すると、管理領域は、上記フリップフロップメカニズムが、メモリ共有されたファイルのデータ領域内のアクティブおよび非アクティブ部分を反転するように編集される。しかし、上記の現在のメカニズムでは、２つの問題が発生する。

第１の問題は、メモリマップドファイルの実際のサイズに対して格納される新しいデータの量を扱う。上記で既に説明したように、メモリマップドファイルのサイズは、格納するデータの増加または減少に追従して、動的に変更されることができない。従って、格納するデータの量が利用可能なサイズを超えて増加した場合、メモリマップドファイルは、現実に更新不可能である。従って、対応するキャッシュファイルの内容は期限切れとなってしまう。このとき手動の作業で、問題を修正することが要求される。メモリマップドファイルのサイズは、複製を再開する前に増加されなければならない。逆に、メモリマップファイルが、オーバーサイズ（over-size）である場合、多くのメモリリソースが浪費される。また、格納するデータの量が減少すると、現在のメカニズムは、メモリマップドファイルのサイズを減少させるという、その利点を得ることができない。

第２の問題は、複製中に、何らかの理由で処理が正常に完了しなかった場合に発生する。アクティブおよび非アクティブデータブロックは、同一のデータ領域を共有しているため、データ領域の非アクティブ領域への書き込みはまた、メモリマップドファイルのアクティブ部分を破損させる可能性もある。複製処理がデータブロックの完全なリストの書き込みに失敗した場合、対応するリンクリストが確かに破損する。アクティブ部分のアドレッシングするブロックが、アクティブ部と非アクティブ部との間のデータ領域分割を破壊するような、予測不可能な結果を生む可能性もある。

上記２つの問題は、発生すると避けられないサービスの停止のきっかけとなるため、クライアントアプリケーションにとって致命的な影響がある。影響を受けたクライアントに通知可能に、かつデータ破損がさらに伝搬するのを防ぐため、複製処理の標準プラクティスは、データを書き込む前にメモリマップドファイルをロックすることに帰着する。複製が正常に終了しない限り、ロックは複製の最後で解除される。ロックメカニズムは、データの破損がさらに伝搬するのを防ぎ、かつ破損ファイルを表示する可能性をクライアントに提供するが、それは自動的な方法で復旧する助けにはならはない。

現在の複製処理は、上記で議論したように、
・メモリマップドファイルのサイズは、手動で設定される必要があり、アプリケーションにとってオーバーサイズである場合、多くのメモリリソースの浪費につながる、スタティックなパラメータであり、
・共有されたデータ領域内のファイルの間のフリップフロップメカニズムは、リンクリストの破損が発生してするのを防ぐことはできず、
・ロックメカニズムは、自動化された方法で復元されない
という復元力の欠如に苦慮しており、手動操作を必要とする。

従って、本発明の一般的な目的は、マスタデータベースからミドルウェア処理ノードの共有メモリ内への、キャッシュファイルの現在の複製メカニズムの上記の欠点および制限の少なくともいくつかの解決をもたらすことである。本発明の特定の目的は、キャッシュファイルの複製が、複製操作が時折失敗または期待通り完了しなかったとしても、既存のキャッシュファイルにとって無条件で破損のない処理となることを達成することである。

本発明の他の目的は、データのバージョンが簡単な方法で管理可能な新しいキャッシュの構造を提供することである。

本発明のさらなる目的、特徴および利点は、添付の図面を参照し、以下の図面を検討することで、当業者に明らかとなるであろう。任意の追加の利点は、本明細書に組み込まれることが意図されている。

データセットの１つのバージョンをそれぞれ格納する複数のキャッシュファイルを有するデータ領域と、
少なくとも１つのリリース領域を備える管理領域であって、リリース領域は、バージョンセクションと同じ数のオフセットである、１つのシングルキャッシュファイルの少なくとも１つのキーアドレッシングデータをそれぞれ格納する複数のバージョンセクションを有する、少なくとも１つのバージョン領域を備え、それぞれのオフセットが１つのバージョンセクションを指し示す管理領域とを備えるキャッシュ構造に関する。

このように、中間構造は、データ領域とは分離して形成されている。

本発明の一態様において、例示的な実施形態は、管理領域がデータ領域と分離したファイルであることを提供し、それにより、データ部分に対する管理部分のより良い保護が提供される。

いくつかの実施形態の別の態様として、３つのオフセットと、３つのバージョンセクションが提供され、従来型のフリップフロップメカニズムと異なる、指し示す（pointing）ステップを有効にする。３つのオフセットの使用は、バージョン間のシフトをより安全にし、更新ステージの間に破損が発生した場合であっても、アプリケーティブプロセスによるデータの可用性を維持する。さらに、３つのオフセットの１つが、たとえ一時的であっても、置換されたバージョンセクションへのアクセスを維持するのに使用されてもよく、その結果、１つ前の、現在の（current）バージョンセクションで動作を開始したアプリケーティブプロセスは、新しいバージョンセクションが導入されたとしても操作を継続可能であり、効果的である（すなわち、現在のバージョンセクションとしてアクセス可能である）。新バージョンへのシフトは、そのバージョンセクションのメモリをリセットすることによって、常に開始される。バージョンセクションを介したキーロケーション値（key location value）へのアクセスは不可分（atomic）（マップキーを発見するように）ではないので、基本的なフリップフロップメカニズムを使用した、２つの高速な成功する連続のバージョンのシフトは、キー読み出しで衝突（conflict）するであろう。３つのオフセットの使用によって提供される一時的なアクセスは、これに対処する。

本発明はまた、更新ステージ中のキャッシュメモリ内に格納されたデータへのアクセスを制御するための方法に関し、
本発明のキャッシュメモリ構造を使用するステップと、
１つの別個のオフセットでそれぞれのバージョンセクションを指し示すステップと、
１つのオフセットを、現在のバージョンセクションとして定義される１つのバージョンセクションを指し示す、現在のオフセットとして定義し、かつ現在のデータとして定義されるデータセットのバージョンをアドレッシングするステップを備える。

本発明は、好ましい実施形態を図示する目的のため、図面を参照して詳細に説明される。

図１は、本発明が実施される、従来技術の３層コンピューティングアーキテクチャを示す図である。 図２は、先行技術のキャッシュファイル構造を示す図である。 図３は、３層コンピューティングアーキテクチャの中間層においてバージョン管理ファイルの補助によって、本発明がどのように実施されるかを示す図である。 図４は、バージョン管理ファイルの基本構造を示す図である。 図５Ａは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｂは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｃは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｄは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｅは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｆは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｇは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｈは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図５Ｉは、共有メモリにおける新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。 図６は、更新処理を最適化し、同時（concurrent）書き込みを扱うためのバージョン管理ファイルの基本構造をもたらす第１の拡張を示す図である。 図７Ａは、バージョン管理ファイルの拡張された構造における新しいキーの追加について説明する図である。 図７Ｂは、バージョン管理ファイルの拡張された構造における新しいキーの追加について説明する図である。 図７Ｃは、バージョン管理ファイルの拡張された構造における新しいキーの追加について説明する図である。 図７Ｄは、バージョン管理ファイルの拡張された構造における新しいキーの追加について説明する図である。 図８は、必要に応じてリリース領域のメモリサイズを増やすのを許可するバージョン構造をもたらす第２の拡張について議論する図である。

以下の説明で使用される、いくつかの用語の定義が以下に与えられる。

「データ領域」は、ここでは、データが格納される、キャッシュメモリの部分を意味し、処理によってアクセスされたときの読み出しまたは書き込み操作の対象となっている。好ましい一実施形態では、書き込み操作は管理者のタスクであるのに対し、読み出し操作はアプリケーティブプロセスによってなされる。データが管理者のコンピュータ装置によって更新/置換/作成されると、データが読み出し目的のためのアプリケーティブプロセスに利用可能にされる。好ましい一実施形態において、データは、それぞれがオブジェクトの定義を表す、データセットに編成される。一例として、航空会社のコンピュータシステムのルールまたは運賃定義またはフライトスケジュールデータのリストは、オブジェクトとして用いることができる。オブジェクトはまた、１つのデータフィールドの内容に帰着することが可能である。データセットによって定義されるオブジェクトは、典型的にはデータセットが更新または置換する必要があることを意味し、管理者によってマスタデータベースにおいてなされた変更を通常反映する、修正の対象となる。これはまた、本発明が複数のデータセットのバージョンが同じオブジェクトに対して共存するために、複数のバージョンのオブジェクトを扱わなければならないことに関係する。オブジェクトは、パッケージによってグループ化することが可能である。一例として、フライトスケジュールを扱う異なるルールのリストは、フライトスケジュールパッケージにグループ化することが可能である。しかし、それでもパッケージは単一のオブジェクト、すなわちデータセットとして表示することが可能である。スナップショットという用語もまた、１つのオブジェクト、またはオブジェクトのセットの所与のバージョンを定義するデータセットの１つのバージョンに対応するものとして説明において使用される。１つのキャッシュファイルは、有利に、しかし非限定的にデータセットのそれぞれのスナップショットまたはバージョン専用である。典型的に、データ領域のデータは、少なくとも１つのアプリケーティブプロセス（ここでは、少なくとも１つのコンピュータ装置の少なくとも１つのプロセッサによって実行される、何らかのコンピュータ処理を意味する）によるアクセスのためであり、これらのデータは、その補助となる。アプリケーティブプロセスは、旅行業界のグローバル配信システムで使用される運賃検索エンジンのような、検索エンジンの読み出し処理を備えてもよい。従来のハードウェア手段は、本発明のキャッシュをサポートするために実施することが可能である。データアクセスモードは、共有メモリの現在の技術と、データの物理ストレージおよびこれらのデータのアプリケーティブプロセスビューとの間の対応を可能にする、メモリマップドファイルのコンセプトとに依存可能である。

ここで、「管理領域」は、上述のデータ領域のデータへの処理によるアクセスを制御するために使用されるキャッシュの部分を意味する。管理領域は、好ましくは、データ領域から分離した、１つまたは複数のキャッシュ専用ファイル内に含まれる。上記ファイルは以降、管理ファイル（control file）またはバージョン管理ファイル（version control file）と呼ばれる。管理領域は、エントリポイント領域が実装されている実施形態において、他の制御手段を作用共存してもよいことを後述する。また、複数の管理領域は、有利にはそれぞれ別のファイルで使用可能である。

（管理領域、データ領域、またはエントリポイント領域として使用される）「領域」は、広義にキャッシュメモリの一部として参照され、上記メモリの連続的なセグメントではなくてもよい。

「キー」は、格納されたデータのアドレスを特定する、小さなサイズのデータを表現する。キーの値は、対応する格納されたデータの位置を提供する。キーは、必ずしも同じサイズのデータセットをアドレッシングするわけではなく、キーはより大きなオブジェクトを説明する、データセットにおける特定のフィールドにアクセスするために使用可能である。異なるキーは、オブジェクトのデータの１つデータセットの領域、または複数の領域にアクセスするために使用可能である。他のキーは、オブジェクトの前のスナップショットにアクセスするために使用可能である。キーのセットは、同一のオブジェクトの異なるスナップショットにアクセスするために使用可能である。データ領域におけるそれぞれのデータセットは、キーによって一意に識別される。複数のキーは、キーは、好ましくは小さく維持されているが、任意のサイズを有することが可能である。唯一の制約は、それぞれのデータセットは固有の固定のキーに関連付けられなければならないことである。

バージョン管理領域の目的は、それぞれのキーを、例えばメモリアドレスにリンクすることにより、データセットへアクセスする方法に具現化することである。従って、キーは、本発明の理解のためにアドレスまたはアクセスリンクに相当するとみなされるかもしれない。

図面を参照して、本発明の詳細な好ましい実施形態を説明する前に、いくつかの本発明の付随する特徴が以下で導入され、これらは、代替的にまたは累積的に、使用される。

・バージョンセクションは、キーの追加または削除を許可する、（マップのような）構造を含む。
・データのスナップショットは、ドメインによってグループ化可能である。同じ制御構造がドメインレベルで適用される。
・管理領域は、メインバージョンセクションとともに、メインリリース領域を備え、上記バージョンセクションのそれぞれは、それぞれのドメインに対して、ドメインリリース領域と言われる、専用のリリース領域へのアクセスリンクを含む、ドメイン定義データを含む。
・メインリリース領域は、メインバージョンセクションと同じ数のメインオフセットを備え、それぞれのドメインリリース領域はドメインバージョンセクションと同じ数のドメインオフセットを備える。
・上記は、共有メモリ内に格納される。
・管理領域もまた、リリース領域のコンセプトを使用して管理可能である。エントリポイント管理領域は、以下を備える。
- 複数の管理領域
- それぞれが１つの分離した管理領域へのアクセスリンクを定義する、エントリバージョンセクションを備える、エントリポイントリリース領域
- それぞれのエントリポイント管理領域は、エントリバージョンセクションと同じ数のエントリオフセットを備え、それぞれのエントリオフセットは、１つのエントリバージョンセクションを指し示す。

好ましい実施形態に従えば、本方法は、以下のステップの少なくとも１つを含んでもよい。
・現在のバージョンセクションと異なる、新しい（ｎｅｗ）バージョンセクションとして定義される１つのバージョンセクションを指し示す、１つのオフセットを新しいオフセットとして定義するステップ
・新しいバージョンセクションをクリアするステップ
・データ領域のキャッシュファイル内の少なくとも１つのデータセットの新しいバージョンを格納するステップ
・新しいバージョンセクション内の新しいバージョン情報を格納するステップ
・現在のオフセットが新しいバージョンセクションを指し示すようにするステップ
・３つのオフセットと、３つのバージョンセクションとを使用して、リリース領域を提供するステップ
・１つの別個のオフセットで、それぞれのバージョンセクションを指し示すステップ
・現在のバージョンセクションとして定義される、１つのバージョンセクションを指し示す、第１のオフセットを現在のオフセットとして定義するとともに、現在のデータとして定義されるデータセットのバージョンをアドレッシングするステップ
・現在のバージョンセクションと異なる、新しいバージョンセクションとして定義される、１つのバージョンセクションを指し示す、第２のオフセットを、新しいオフセットとして定義するステップ
・古いバージョンセクションとして定義される、１つのバージョンセクションを指し示す、第３のオフセットを、古いオフセットとして定義するステップ
・新しいバージョンセクションをクリアするステップ
・古いオフセットが現在のバージョンセクションを指し示すようにするステップ
・現在のオフセットが新しいバージョンセクションを指し示すようにするステップ
・新しいオフセットが古いバージョンセクションを指し示すようにするステップ
・古いオフセットが現在のバージョンセクションを指し示すようにするステップの後に、アプリケーティブプロセスによって、古いオフセットによって指し示される、バージョンセクションによってアドレッシングされるキャッシュファイルのデータへのアクセスを有効化するステップ
・アクセスを有限時間で有効化するステップ
・キャッシュメモリ構造を使用するステップ
・現在のエントリセクションとして定義される、１つのエントリセクションを指し示す、１つのエントリオフセットを現在のオフセットとして定義するステップ
・現在のエントリオフセットによってアドレッシングされる管理領域へのアプリケーティブプロセスによって、アクセスを有効化するステップ

本発明はまた、本発明はまた、本発明の方法を実行するように構成された命令を含む、コンピュータプログラムを記録したコンピュータプログラム製品に向けられている。プログラムは、任意のコンピュータ読み取り可能なメモリのような、任意の一時的媒体に記録可能である。

図３は、背景技術の欄で説明された３層アーキテクチャ環境において、本発明がバージョン管理ファイルを使用してどのように実施されるかを示す。

その目的を達成するために、本発明は、それぞれの共有メモリ２３０内で、中間キャッシュファイル２２０を使用する。このファイルは、「管理ファイル」として参照され、アプリケーティブプロセス２４０から、共有メモリ内に格納された様々なレベルのキャッシュファイル２５０への全てのアクセスを管理するのに使用される。図示するように、全てのアプリケーティブプロセス２４０は、キャッシュファイル２５０にアクセスするために、バージョン管理ファイル２２０を介し、破損のない複製メカニズムを実施する。

バージョン管理ファイル２２０を用いて実施される管理領域は、キーがバージョンづけられた（versioned）データであり、データの所与のバージョンの位置の値であるマップ構造として表示されることが可能である。キャッシュバージョン管理は、以下の方法でアクセス可能である。

読み出しから書き込みへの割合が高いという、本発明の好ましい状況において、書き込みアクセスは、いかなる読み出しアクセスに対しても影響を与えてはならない。言い換えれば、書き込み操作が実行されるいかなる場合でも、全てのキーの値は、読み出しのためにアクセス可能でなければならない。以下の図で説明するように、本発明は、以下の問題を管理して解決する。
・キャッシュメモリへのキーおよび値の書き込みは、不可分な操作であることができない。そうであるにもかかわらず、読み出し操作は、書き込み操作中に保留されない。代わりにキャッシュファイルへの書き込み操作は、割り込み可能である。不完全な書き込み操作は、読み出しの完了で再開することが可能となる。
・いったんキャッシュのバージョン管理が初期化されると、有限量のキーを含む。この有限量に達したとき、新しいキーを追加する必要がある場合はいつでも、本発明は、共有メモリ内の新しい領域を割り当てるようにする。
・同時書き込みは、書き込み操作に排他的なアクセス権を付与することにより処理される。

図４は、管理ファイル２２０に対応する管理領域の基本的な構造を示す図である。

いくつかの書き込み操作のグループの最小単位（atomicity）は、書き込みに対する読み出し専用（read-only）操作の優先順位を維持しながら、すなわち、読み出しサービスを中断することなく、バージョン管理を以下で説明するように体系づけ、共有メモリにおいて獲得される。
・データ領域４１０という名称の共有メモリのデータのパーティションが、任意の時点で受信されたデータの全てのスナップショットを格納するために充てられる。
・それぞれのデータのスナップショットは、共有メモリのそれ自身の専用領域４２０内に格納され、そのような専用領域４２０は、好ましくは図３に示す１つのキャッシュファイル２５０である。
・リリース領域４３０という名称の共有メモリの領域は、受信したデータのスナップショットのバージョンを管理する、すなわち、データのスナップショットが現在のものであるかを示すことを目的とする。
・新しいデータのスナップショットの追加は、不可分な方法で実行される。本発明は、共有メモリ内のオフセット、すなわち整数値の更新は不可分な操作であるものと仮定する。

共有メモリのデータ領域４２０は、予め決められたサイズでなければならないわけではない。サイズは、共有メモリを使用してソフトウェアアプリケーションの要求を満たすために構築時間で計算される。一方、共有メモリのリリース領域は、以下のような４つのサブ領域に分割され、固定のサイズを有する。
・領域４４０はバージョン領域４５０内に含まれる３つのバージョンセクションをアドレッシングするためのオフセット４４２を含む。３つのバージョンセクションは、以下からなる。
・それぞれのデータセットの現在のスナップショットのアドレス（言い換えれば、キー）を含む、現在のバージョンセクション４５４
・データセットの新しい、または最新のデータのスナップショットのアドレスを含む、新しいバージョンセクション４５６
・以前に現在のものであると識別されたそれぞれのデータのスナップショットのアドレスを含む、古いバージョンセクション４５２

それぞれのバージョンセクションは固定のサイズを有し、有限の最大数のスナップショットのみを扱うことができる。これは、スナップショットをアドレッシングする有限の数のキーを扱うことが可能であることを意味する。

図５Ａから図５Ｉは、共有メモリ内の新しいデータのスナップショットを不可分な方法で追加するための方法のステップを示す図である。

図５Ａに示すように、領域４４０におけるオフセットの正当性をチェックし、必要に応じて修正を適用した後、以下に説明する予備的なステップである、第１の後続するステップまたはステップ２は、新しいバージョンセクション４５６をクリアする、すなわち全てのビットを０に設定する（４５７）ステップからなる。次に、新しいバージョンセクション４５６が初期化される（４５８）、すなわち、＜キー、ロケーション値＞の組を含む内部構造が次のステップ３で生成される。この後半のステップは図５Ｂで示される。

図５ｃで示される次のステップ４は、データ領域４１０の新しい領域内に、新しいデータのスナップショットを格納するステップからなる。これは、完全に新しいデータのスナップショットを格納することにより、または、最初に現在のデータのスナップショットを取り出して、それに更新を適用することによって行われる。しかし、両方の場合において、スナップショットは新しいデータ領域４２０に有利に格納される。

次に、ステップ５で、現在のバージョンセクション４５４の内容が、新しいバージョンセクション４５６にコピーされ、キーリンク４５５は、現在のバージョンセクション４５４のスナップショットと同じデータのスナップショットをアドレッシングする。これは、図５Ｄに示される。図５Ｅに示す次のステップ６で、新しいバージョンセクション４５６は、新しいデータのスナップショットを含むデータ領域４２０の代わりに、（リンク４５９を）アドレッシングするように変更される。

その後、ステップ７で、データ領域４４０のオフセット４４２は、以下のように変更される。
・ステップ７１で、古いオフセットが現在のセクション４５４をアドレッシングする
・ステップ７２で、現在のオフセットが新しいセクション４５６をアドレッシングする
・ステップ７３で、新しいオフセットが古いセクション４５２をアドレッシングする

上述の予備的なステップ、またはステップ１は、領域４４０におけるオフセット４４２の正当性がチェックされる間、領域４４０内の書き込み操作中に発生する可能性がある、故障のケースを取り扱うことを目的とする。

図５Ｇに示すように、２つのオフセットは、故障の発生後、同じバージョンセクションをアドレッシングする（参照符号４５１を参照）。この場合、領域４４０の新しい、または古いオフセットは、この手当をするために単に修正されることが可能である。修正は、現在のセクションもまたターゲットにする、新しいまたは古いオフセットのうちの１つに単に適用される。

更新処理がステップ２から６の実行の間に失敗した場合、新しいデータのスナップショットの追加は、変更されたバージョンセクションが新しいセクション４５６だけであるためにキャンセルされる。このセクションは読み出し操作によってアクセスされない。読み出し操作は、現在のバージョンセクションに使用されるだけである。従って、上述のように、共有メモリを更新しようとする試みの失敗は、次の書き込み時に、新しいバージョンセクションが消去され、最初から（scratch）初期化されるため、副作用がない。新しいデータ領域４２０もまた、リリース領域４３０によってまだ参照されていないため、再利用される。

ステップ７１および７２の実行中に処理が失敗した場合、読み出し操作が未だ現在のバージョンセクションをターゲットとしているため、スナップショットの追加もまたキャンセルされる。上記の失敗は、上述のように、新しいデータのスナップショットを追加するための次の試み時に、新しいバージョンセクションが消去され、最初から初期化されるため、副作用を有さない。現在のバージョンセクションをアドレッシングする、古いオフセットを有することは問題とはならない。正当性および正確なオフセッを確認する予備的なステップは、これを考慮している。図５Ｇは、データ領域４１０内の新しいデータのスナップショット４２０を追加しようとする試みの間に、失敗がデータ領域４４０を破損後、リリース領域４３０が残される状態の例を示す図である。オフセット４４２が復元された後の状況は、図５Ｅに示されるものと等価である。

ステップ７２および７３の間に処理が失敗した場合、スナップショットの追加はキャンセルされず、正常に完了したものとみなされる。確かに、読み出し操作は、ちょうど新しく作られたバージョンセクション４５６である、現在のバージョンセクションをターゲットとすることが可能である。しかし、更新操作は、正常に完了していないため、領域４４０の新しいオフセットは、現在のバージョンセクション４５６をアドレッシングする（４５３を参照のこと）。次の書き込み操作のステップ１が、新しく作られたバージョンセクションを消去するのを防ぐため、このセクションもまた現在のセクションであることに基づくと、オフセットの正当性がチェックされなければならず、修正がステップ１で適用される。オフセットの非正当性は、新しいオフセットと現在のオフセットとが同じバージョンセクション４５６をアドレッシングする（４５３）ため、容易に検出可能である。これは失敗がステップ７２のちょうど後で発生したことを示している。失敗から完全に復元するために、新しいオフセットは、前の古いバージョンセクション、すなわち、どのオフセットによってもアドレッシングされていない残りのバージョンセクション、この例では４５２をアドレッシングするように設定される。

図５Ｈは、新しいスナップショット４２２を追加する処理が、ステップ７２の後に失敗する例を示す。ステップ１が実行されたオフセットの復元の後、リリース領域の状態は、図５Ｉに示される。新しい管理セクションは、正しいバージョンセクション、すなわちこの例では４５２をアドレッシングする（４５５を参照）ように修正される。ステップ７３の後に処理が失敗した場合、不可分なスナップショットの追加が既に完了しているため、これは不利益な結果にならないことに注目すべきである。

図４および図５で上述された、バージョン管理ファイルの基本的な構造とその操作のモードは、以下の問題に対処するためのバリエーションの対象となることが可能である。
・グローバルなロックメカニズムが使用されているため、同時書き込みはサポートされていない
・リリース領域のサイズは固定である

以下の図は、上記の残る問題に対処するための基本的なバージョン管理ファイルにもたらされる拡張について図示し、議論する。

図６は更新処理を最適化し、同時書き込みを扱うための第１の拡張を示す。

本発明は、新しいキー挿入の数が、特定のキーの値の更新の数と比較して、通常小さい環境で操作する。この状況において、図４および図５で上述された、バージョン管理の基本的な構造の操作は、１つの制限に苦慮する。ステップ４で上述したように、毎回キーの値は、リリース領域４３０のセクション４５２、４５４、および４５６で変更されなければならず、全体のバージョンマップ（すなわち、全てのキーのデータ）は、少なくとも１回最初にコピーされなければならない。この欠点を克服するため、本発明は、挿入されたキーの値を特別に扱う、メインリリース領域４３６および、複数のリリース領域４３２、４３４を生成するのに上述のキャッシュ管理構造を拡張し、メインリリース領域４３６は、ドメインリリース領域という名称の、これらのリリース領域にアクセスするための、ドメインキーの定義を保持する。

本実施形態に従い、データ領域のデータ（または少なくともそれらの一部）は、様々なドメインに分散される。ドメインは、通常、同一のサイズでなく、それぞれがデータセットのグループに対応し、その性質は、いくつかの共通点を共有する。例として、ドメインは、１つの航空会社のためのルールに割り当てられることが可能であり、他のドメインは、他の航空会社のためのルールに割り当てられることが可能である。

図６は、リリース領域の基本的な構造がどのように拡張されるかの例を示す。先に議論したリリース領域４３０は、ここで、本例において、それぞれが自身のバージョンである、２つのドメインキー、すなわち１Ａ−ＰＯＳおよびＡＦ−ＭＫＴを保持するメインリリース領域４３６と一緒に使用される、リリース領域４３２、４３４によって置き換えられる。この拡張された構造において、メインリリース領域４３６は、この例においてそれぞれ４３４、４３２である、自身のリリース領域に関連付けられた、格納されたキーを参照するために単に使用される。値リリース領域のへのリンクは、６１０を参照して示される。この拡張された構造に基づいて、１つのドメインキーを追加（これは特に、新しいオブジェクトがキャッシュ内に追加されるときに発生する可能性がある）し、キーの値を変更する処理は、以下に説明される。

図７Ａ〜７Ｄは、図６の拡張された構造における、新しいドメインキーの追加を説明する。メインリリース領域４３６およびリリース領域４３２において、どのように新しいドメインキー定義データおよび値がそれぞれ追加されるかが示される。

管理ファイル２２０を生成するとき、メインリリース領域４３６および４３２、４３４のようなある一定数の値のリリース領域が事前に作成される。メモリを管理する最も効果的な方法は、リリース領域の数がメインリリース領域４３６の最大の容量とマッチするように割り当てることである。

図７Ａは、メインリリース領域４３６が、１つのドメインキー、すなわち１Ａ−ＰＯＳだけを保持する処理の最初のステップ、すなわちステップ１０を示す図である。この拡張された構造において、メインリリース領域４３６は、それぞれがこの依存するドメインリリース領域の古い、現在の、および新しいドメインバージョン領域である、１Ａ−ＰＯＳバージョン２、３、および４という名称のオブジェクト１Ａ−ＰＯＳの様々なスナップショットのバージョンのロケーション／キーを保持する、ドメインリリース領域「１Ａ−ＰＯＳリリース領域」４３４をアドレッシングする、メイン管理セクションＡ、Ｂ、Ｃを備える。特定のリンク６１２は、メインリリース領域、および依存するリリース領域４３４との間で作成される。ドメインリリース領域４３４は、本発明の第１の実施形態を参照して上述されたように、オフセットを備える。これはまた、メインリリース領域４３６の場合もそうである。図６および図７は、メインリリース領域４３６もまた、ここではメインオフセットと呼ばれるオフセットを含むことを示している。例において、メインリリース領域４３６およびリリース領域４３２、４３４の構造は同様であるが、オフセットの数と、メインオフセットは異なっていてもよい。しかし、本例では、両方の場合において、３つのオフセットを使用する。

以下のステップ１１が図７Ｂに示され、ここで新しいドメインキー、すなわちＡＦ−ＭＫＴがメインリリース領域内に追加され、対応する値リリース領域４３２が属性づけられる（attributed）。この目的を達成するため、この新しいドメインキーの定義データは、依存したドメインリリース領域４３２をアドレッシングする、特定のリンク６１４を提供するために、メインリリース領域４３６内に定義される。

次に、図７Ｃに示されるステップ１２で、図５で説明された処理が適用される。オフセットは変更され、依存するドメインリリース領域４３２内の新しい挿入されたドメインキーＡＦ−ＭＫＴ Ｖ１が現在のキー（６２０）となる。

同様に、メインリリース領域の４３６のメインオフセットは、６３０において現在のキーのパスとなるように、キーメインバージョンセクションＣを指定するように変更される。これはステップ１３で行われ、結果は図７Ｄに示される。このステップの完了で、書き込み操作、すなわち新しいドメインキーの追加は、成功して完了する。

オブジェクトの更新は、図５において説明されたように行われる。次にドメインリリース領域４３２、４３４のレベルのみで、これらの値の操作を要求する、特定の値だけが更新される必要がある。その結果、この操作の間メインリリース領域４３６のセクション全体のコピーが回避される。

バージョン管理の拡張された構造において、更新された領域が共有メモリ内で完全に隔離されているため、同時書き込みが可能になる。また、以下の操作を同時に実行することが可能となる。
・メインリリース領域４３６内に、１つのドメインキーを追加すること
・異なるドメインリリース領域の値／オブジェクトを更新すること

従って、同時書き込みを特徴とする実施において、１つのミューテックス（mutex）、すなわち、処理によって共通の資源の同時使用を回避するために考案されたコードの部分は、値による書き込みアクセスおよびメインリリース領域のために１つ、権限を生成する。上述した処理は、書き込み操作の最初で関連するミューテックスを取得することで再入可能（re-entrant）となる。

図８は、メモリが固定サイズであることの上述した問題を解決するために、リリース領域のメモリサイズが増加することを許可するバージョン構造にもたらされる、第２の拡張を議論する。

割り当てる空間が十分であるときに、新しいデータの追加が簡単である場合、新しいデータセットおよびその管理手段が割り当てられなければならないときは、事案がより複雑になる。本発明は、間接的なレベルを追加することによって、この問題を回避するように管理する。この目的を達成するため、キャッシュのメモリセグメントであることが可能な、エントリポイント領域７１０が使用される。エントリポイント領域７１０の役割は、それぞれ有利に管理データを保持する管理ファイル２２０からなる、いくつかの管理領域を参照することである。エントリポイント領域７１０は、それ自身がエントリセクション７１５、７１６、および７１７を備えるエントリポイントリリース領域を含む、好ましくは別のキャッシュファイルである。エントリセクションは、図によって上述した１つのバージョン管理領域構造、すなわち本例における７２０および７３０を実際に保持する、１つの管理ファイルの位置および最大容量７１２をそれぞれ含む。エントリポイント領域７１０は、リリース領域と同じグローバル構造を好ましくは有し、ここではエントリオフセットと呼ばれるオフセットもまた有する。

キーを追加するとき、書き込み処理は以下のステップを実行する。
１．現在の管理領域に十分なメモリ空間が残っているかどうかを確認する。十分な空間が残っている場合、書き込みは上述のように発生する。しかし、残りの空間が十分でない場合、
２．新しい管理領域が増加したサイズで作成される。例えば、図８において、７３０のようなファイルが作成される。
３．現在の管理領域からのデータが新しい管理領域へコピーされる。付随的に、古い値を回収する必要がある場合、キャッシュの値の内容全体がコピーされ、そうでない場合、現在の値だけがコピーされる。
４．キーが新しい管理領域７３０に追加される。
５．現在のエントリオフセット７１９が作成された管理領域７３０を指し示すエントリセクション（７１７）へ切り替えられる。
６．データの非推奨（deprecated）バージョンは、資源の節約のために消去される。

エントリポイント領域７１０は、図４および図５で説明された構造を使用し、読み出しアクセスを妨げることなく現在の管理領域が切り替えられるのを許可する。

エントリポイントが固定サイズの構造を含む必要だけがあるため、新しい割り当てを要求せず、固定のエントリポイントとして動作することが可能である。

新しい管理領域の容量を計算するためのポリシーは、自由に適用されてよく、この処理が適用される必要がある回数と、全体のメモリ空間のとの間の折衷案の結果となるべきである。

読み出しアクセスは、現在の管理領域を回収するために、エントリポイント領域を最初に読み出す。後者は、メインリリース領域で、現在のメインバージョンセクションを特定する、現在のメインオフセットに達する。現在のメインバージョンセクションは、正しいドメインリリース領域に到達するために、キーリンクを提供する。このレベルで、ドメインリリース領域の現在のオフセットは、アクセスされるデータ領域４２０をアドレッシングする、ドメインバージョンセクションを指し示す。

本発明の例示した実施形態は、添付の図面を参照して詳細に説明されてきたが、本発明は、これらの正確な実施形態に限定されて理解されるべきものではなく、かつ変更および改良が本発明の範囲および精神から逸脱することなく、当業者によって行われてもよいことが理解されるであろう。

１０ メモリマップドファイル
２０ データ領域
２１ リンクリスト
２２ アクティブデータブロック
２３ リンクリスト
２４ 非アクティブデータブロック
３０ 管理領域
３１ アクティブポインタ
３２ 非アクティブポインタ
１００ データ層
１１０ マスタサーバ
１２０ マスタデータベースシステム
２００ アプリケーション層
２１０ スレーブノード
２２０ バージョン管理ファイル
２３０ 共有メモリ
２４０ アプリケーティブプロセス
２５０ キャッシュファイル
３００ クライアント層
４１０ データ領域
４３０、４３２、４３４ リリース領域
４３６ メインリリース領域
４４０ 領域
４４２ オフセット
４５０ バージョン領域
４５２、４５４、４５６ バージョンセクション
７１０ エントリポイント領域

Claims (17)

1. それぞれのキャッシュファイル（２５０）が同一のデータセットの１つのバージョンを格納する、複数のキャッシュファイル（２５０）を有するデータ領域（４１０）と、
   どのバージョンのデータセットが現在のデータとして定義されるかを示すように構成されるとともに、少なくとも１つのリリース領域（４３０）を備える管理領域とを備え、
   前記リリース領域（４３０、４３２、４３４）は、
   １つのシングルキャッシュファイル（２５０）のうちの少なくとも１つのキーアドレッシングデータをそれぞれが格納する、複数のバージョンセクション（４５２、４５４、４５６）を有する少なくとも１つのバージョン領域（４５０）と、
   それぞれのオフセット（４４２）が１つのバージョンセクション（４５２、４５４、４５６）を指し示す、バージョンセクション（４５２、４５４、４５６）と同じ数のオフセット（４４２）と
   を備える、キャッシュメモリ構造。
2. 前記管理領域は、データ領域（４１０）と分離した少なくとも１つのファイル（２２０）内にある、請求項１に記載のキャッシュメモリ構造。
3. ３つのオフセット（４２２）と、３つのバージョンセクション（４５２、４５４、４５６）を備える、請求項１または２に記載のキャッシュメモリ構造。
4. それぞれのバージョンセクション（４５２、４５４、４５６）が、前記キーに割り当てられたデータセットの１つのバージョンを格納する１つのキャッシュファイル（２５０）にアクセスするために、１つのシングルキーに関連付けられた値を格納し、
   前記データセットは、複数のドメイン内に分散され、
   前記管理領域は、メインバージョンセクション（６２０、６３０、６４０）を有するメインリリース領域（４３６）を備え、前記メインバージョンセクション（６２０、６３０、６４０）のそれぞれは、それぞれのドメインに対して前記ドメインに関連付けられたリリース領域（４３２、４３４）へのアクセスリンク（６１０）を備える、請求項１から３のいずれか一項に記載のキャッシュメモリ構造。
5. 前記管理領域は、メインバージョンセクション（６２０、６３０、６４０）と同じ数のメインオフセット（６０５）を備え、それぞれのメインオフセット（６０５）は、メインリリース領域（４３６）の１つのメインバージョンセクション（６２０、６３０、６４０）を指し示す、請求項１から４のいずれか一項に記載のキャッシュメモリ構造。
6. 前記管理領域は、３つのメインオフセット（６０５）と、３つのメインバージョンセクション（６２０、６３０、６４０）と、それぞれのドメインリリース領域（４３２、４３４）に対して、３つのドメインオフセットと３つのドメインバージョンセクションと、を備える、請求項１から５のいずれか一項に記載のキャッシュメモリ構造。
7. 請求項１から６のいずれか一項に記載のキャッシュメモリ構造は、共有メモリ内（２３０）に存在する、キャッシュメモリ構造。
8. 複数の管理領域（７２０、７３０）と、
   １つの分離した管理領域（７２０、７３０）へのアクセスリンクをそれぞれ定義するエントリセクション（７１５、７１６、７１７）を備えるエントリポイント領域（７１０）とを備える、請求項１から７のいずれか一項に記載のキャッシュメモリ構造。
9. 前記管理領域は、それぞれのエントリオフセット（７１９）が１つのエントリセクション（７１５、７１６、７１７）を指し示す、エントリセクション（７１５、７１６、７１７）と同じ数のエントリオフセット（７１９）を備える、請求項１から８のいずれか一項に記載のキャッシュメモリ構造。
10. 請求項１から９のいずれか一項に記載のキャッシュメモリ構造を使用してステージを更新する間、キャッシュメモリに格納されたデータへのアクセスを制御する方法。
11. １つの別個のオフセット（４４２）でそれぞれのバージョンセクション（４５２、４５４、４５６）を指し示すステップと、
    現在のバージョンセクションとして定義される１つのバージョンセクション（４５４）を指し示す、１つのオフセット（４４２）を現在のオフセットとして定義するとともに、現在のデータとして定義されるデータセットの少なくとも１つのバージョンでアドレッシングするステップと、
    前記現在のオフセットによって指し示される前記バージョンセクションによってアドレッシングされるキャッシュファイル（２５０）のデータへのアプリケーティブプロセスによってアクセスを有効化するステップと
    を備える、請求項１０に記載の方法。
12. 前記現在のバージョンセクションと異なる、新しいバージョンセクションとして定義される１つのバージョンセクション（４５６）を指し示す、１つのオフセット（４４２）を新しいオフセットとして定義するステップと、
    前記新しいバージョンセクションをクリアするステップと、
    前記データ領域のキャッシュファイル（２５０）内の少なくとも１つのデータセットの新しいバージョンを格納するステップと、
    前記新しいバージョンセクション内の新しいデータバージョン定義情報を格納するステップと、
    前記現在のオフセット（４４２）が前記新しいバージョンセクションを指し示すようにするステップと
    を備える、請求項１０または１１に記載の方法。
13. ３つのオフセット（４４２）と、３つのバージョンセクションとを使用して、リリース領域を提供するステップと、
    １つの別個のオフセット（４４２）で、それぞれのバージョンセクション（４５２、４５４、４５６）を指し示すステップと、
    現在のバージョンセクションとして定義される、１つのバージョンセクション（４５４）を指し示す、第１のオフセット（４４２）を現在のオフセットとして定義するとともに、現在のデータとして定義される少なくとも１つのデータセットの少なくとも１つのバージョンでアドレッシングするステップと、
    前記現在のバージョンセクションと異なる、新しいバージョンセクションとして定義される、１つのバージョンセクション（４５６）を指し示す、第２のオフセットを新しいオフセットとして定義するステップと、
    古いバージョンセクションとして定義される、１つのバージョンセクション（４５２）を指し示す、第３のオフセットを、古いオフセットとして定義するステップと、
    前記新しいバージョンセクションをクリアするステップと、
    前記データ領域のキャッシュファイル（２５０）内の少なくとも１つのデータセットの新しいバージョンを格納するステップと、
    前記新しいバージョンセクション内の新しいデータバージョン定義情報を格納するステップと、
    前記古いオフセットが現在のバージョンセクションを指し示すようにするステップと、
    前記現在のオフセット（４４２）が前記新しいバージョンセクションを指し示すようにするステップと、
    前記新しいオフセット（４４２）が前記古いバージョンセクションを指し示すようにするステップと
    をさらに備える、請求項１０から１２のいずれか一項に記載の方法。
14. 前記古いオフセットが前記現在のバージョンセクションを指し示すようにするステップの後に、アプリケーティブプロセスによって、前記古いオフセットによって指し示される、前記バージョンセクションによってアドレッシングされるキャッシュファイル（２５０）のデータへのアクセスを有効化するステップを備える、請求項１３に記載の方法。
15. 前記アクセスを有効化するステップは、有限時間である、請求項１０から１４のいずれか一項に記載の方法。
16. 請求項９に従うキャッシュメモリ構造を使用するステップと、
    現在のエントリセクションとして定義される、１つのエントリセクション（７１５、７１６、７１７）を指し示す、１つのエントリオフセットを現在のオフセットとして定義するステップと、
    前記現在のオフセットによってアドレッシングされる前記管理領域へのアプリケーティブプロセスによって、アクセスを有効化するステップと
    を備える、請求項１０から１５のいずれか一項に記載の方法。
17. コンピュータ読み取り可能なメモリ媒体に格納され、請求項１０から１６のいずれか一項に記載の方法を実行するための命令を備えるコンピュータプログラム製品。