JP2022098495A - データベースを保存するためのハイブリッドシャドウページング - Google Patents

Abstract

【課題】データベースの状態を保存するためのハイブリッドシャドウページングのための方法、システム及びプログラムを提供する。【解決手段】方法は、データベースを提供するステップ、データベースによって１つ以上の書き込みイベントを受け取るステップ、各書き込みイベントをログ記録し、ログ記録された各書き込みイベントがデータベースに新たな状態を形成するステップ、書き込みイベントによって変更又は作成されたページをバッファ内に保持するステップ及び閾値に達した場合にバッファ内に保持されたページをデータベースストレージにフラッシュすることでパッチを作成するステップを含む。【選択図】図１

Description

本発明は、コンピュータプログラム及びシステムの分野、より具体的には、データベースを保存するためのハイブリッドシャドウページングのための方法、システム、及びプログラムに関する。

市場には、オブジェクトの設計、エンジニアリング、製造用に、多数のシステム及びプログラムが提供されている。ＣＡＤは、コンピュータ支援設計（Computer-Aided Design）の頭字語であり、たとえば、オブジェクトを設計するためのソフトウェアソリューションに関する。ＣＡＥは、コンピュータ支援エンジニアリング（Computer-Aided Engineering）の頭字語であり、たとえば、将来の製品の物理的挙動をシミュレートするためのソフトウェアソリューションに関する。ＣＡＭはコンピュータ支援製造（Computer-Aided Manufacturing）の頭字語であり、たとえば、製造プロセスや操作を定義するためのソフトウェアソリューションに関する。このようなコンピュータ支援設計システムでは、技術の効率の点でグラフィカルユーザーインターフェイスが重要な役割を果たす。これらの技術は、製品ライフサイクル管理（ＰＬＭ）システム内に組み込まれ得る。ＰＬＭとは、企業が製品データを共有し、共通の処理を適用し、企業知識を活用して、拡張エンタープライズの概念にわたって、コンセプトから生涯にわたる製品の開発に役立てることを支援するビジネス戦略のことをいう。ダッソー・システムズが（ＣＡＴＩＡ、ＥＮＯＶＩＡ、ＤＥＬＭＩＡの商標のもと）提供するＰＬＭソリューションでは、製品エンジニアリングの知識を編成するエンジニアリングハブと、製造エンジニアリングの知識を管理する製造ハブと、エンジニアリングハブ及び製造ハブへの企業の統合及び接続とを可能にする企業ハブが提供される。これらを合わせたシステムは、製品定義、製造準備、生産、及びサービスの最適化を促進するダイナミックかつ知識ベースの製品作成及び意思決定サポートを可能にするために、製品、プロセス、リソースをリンクするオープンオブジェクトモデルを提供する。

これらのアプリケーションは、「クリエイティブなオーサリングアプリケーション」の例であり、クリエイティブなオーサリングアプリケーションとは、ユーザーが互いに離れた状態で作業したり、さまざまなソリューションを探索したり、色々な状態の作業にアクセス及び「タイムトラベル」的な方法で変更の履歴をナビゲートすることにより、インクリメンタルな方法で問題を解決したりする性能をユーザーに提供する。「タイムトラベル」とは、データベースの過去の状態に効率的（つまり、すべての状態に対して一定と見なされる制御された経過時間で）にアクセスし、これらの状態に対して読み取り専用クエリを実行できることを意味する。変更の履歴を保存し、タイムトラベル方式でデータベースの過去の状態にアクセスすることは、航空分野では既存である、過去に行われた変更をその文脈で監査及び理解するプロセスといった認証プロセスでも重要になる場合がある。

このようなクリエイティブなオーサリングアプリケーションは、短時間トランザクションとは対照的に、長時間トランザクションを含む。長時間実行トランザクションとも呼ばれる長時間トランザクションとは、非ローカルリソースのロックを回避し、補償を用いて不具合を処理し、通常はコーディネーターを使用してトランザクションを完了又は中断するコンピュータデータベーストランザクションのことである。補償では、元の状態又は同等の状態が復元される。したがって、特にデータベースに複数のユーザーが同時にアクセスする場合、エラーや電源の不具合などが発生した場合でもデータベースに保存されるデータの正確性と整合性を保証するために、トランザクションは、いわゆるＡＣＩＤ特性、つまり、不可分性、一貫性、独立性、永続性を尊重する必要がある。データベースという背景では、ＡＣＩＤ特性を満たすデータベースへの一連の演算（これら演算はデータへの単一の論理演算として認識されてよい）がトランザクションと呼ばれる。たとえば、ある銀行口座から別の銀行口座への資金の移動は、ある口座からの引き落としや別の口座への追加など、複数の変更を伴う場合でも、単一のトランザクションである。

ＡＣＩＤ特性のうち、一貫性はアプリケーションが定義する意味（セマンティック）に関連させて定義する必要があり、一般的なデータベースについては議論できない。

特に、クリエイティブなオーサリングアプリケーションの場合、読み取りトランザクションと書き込みトランザクションの混合ワークロードに対して最高のパフォーマンスを提供することが望ましく、通常はユーザーが複数回の試行を繰り返し行ってさまざまなシナリオをテスト及び検証するインクリメンタルな方法でのユーザーアクティビティを提供するために、トランザクションはデータベースのどの状態に対しても作成可能である必要がある。さらに、クリエイティブなオーサリングアプリケーションに準拠するように、データベースのすべての状態に効率的に同じコストでアクセスできる必要がある。つまり、すべてのデータベースの状態は同等と見なされる。

データベースにおいて１つ以上のＡＣＩＤ特性を提供するため、データベースシステムには従来さまざまな戦略が存在する。

最初の戦略はシャドウページングであり、シャドウページングとは、追加専用ストレージシステムを使用して、ファイルレベルでトランザクションの不可分性、一貫性、永続性を提供しつつ、ＣＡＤアプリケーションなどの長時間トランザクションをサポートするために導入された戦略である。シャドウページングでは、シャドウバージョンと現在バージョンの２つのバージョンのファイルが維持され、変更されるのは現在バージョンのファイルで、シャドウバージョンは変更されることがない。シャドウバージョンは、不可分性、一貫性、及び永続性を提供するために使用される。

シャドウページングの欠点は使用されるＩ／Ｏリソースの量であり、これは、コミットする前にすべてのページがディスクに書き込まれるのを待つ必要があるためである。さらに、シャドウページングを採用してリリースされているデータベースライブラリでは、バージョン数が２つに制限されており、これはオーサリングアプリケーションにはかなり不十分であり、これに関しては文献「Gray et al., The recovery manager of the System R database manager, ACM Computing Surveys (CSUR), 1981, Vol. 13, No. 2, pages 223-242」及び「Chu, MDB: A memory-mapped database and backend for OpenLDAP, Proceedings of the 3rd International Conference on LDAP, Heidelberg, Germany, 2011, page 35」で議論されている。

２つめの戦略は、不可分性と永続性を維持するためのログ先行書き込み（ＷＡＬ）によるログ戦略である。この手法では、変更は最初にログに記録され、データベースに書き込まれる前に不揮発性ストレージに書き込まれる。この戦略の利点は、Ｉ／Ｏコストの効率性である。ただし、オーサリングシステムでの長時間トランザクションの場合、変更の履歴をログとして保持することは、目的のデータベースの状態を再構築するために膨大なＣＰＵコストがかかることを意味する。

こういった背景のなか、計算リソースやＩ／Ｏによって生成されるメモリを削減しつつ、オーサリングシステムのタイムトラベル特性と長時間トランザクションの性能を組み合わせたデータベースを得るための改良された方法が依然として必要である。

したがって、データベースの状態を保存するためのコンピュータ実装方法が提供される。本方法は、データベースを提供するステップを含む。本方法はさらに、データベースによって１つ以上の書き込みイベントを受け取るステップ、各書き込みイベントをログ記録し、ログ記録された各書き込みイベントがデータベースに新たな状態を形成するステップを含む。本方法はさらに、書き込みイベントによって変更又は作成されたページをバッファ内に保持するステップ、及び、閾値に達した場合に、バッファ内に保持されたページをデータベースストレージにフラッシュすることでパッチを作成するステップを含む。

データベースを保存するためのコンピュータ実装方法は、以下のうちの１つ以上を含んでもよい：
－本方法は、さらに以下を含む：
・データベースが新たな書き込みイベントを受け取った後、閾値に達するたびに作成するステップを繰り返す。作成するステップの各繰り返しは、データベースが受け取った新たな書き込みイベントによって変更又は作成された新たなページのリストを作成し、それによって、一部の状態がそれぞれ対応するパッチを有する、状態のシーケンスを取得するステップを含む、
－作成された新たな各パッチは、バッファ内に保持されたページの物理アドレスとデータベースのデータ構造層にあるページの論理アドレスとの間のマッピングを含むマッピング表をさらに含む、
－ログ記録された各書き込みイベントは、バッファ内の既存のマッピング表を複製し、目的のログ記録された書き込みイベントまでローカルマッピングを適用することにより、ローカルマッピング表を有する、
－マッピング表は、ロックフリーのコンペア・アンド・スワップ配列に基づく、
－作成されたパッチは、次のうち少なくとも１つを含むディスクリプタをさらに含む：
・新たな書き込みイベントによって変更又は作成された物理ページの数、
・ディスクリプタの整合性を確認するためのメタデータ、
・新たな書き込みイベントのタイムスタンプ、
－ディスクリプタが存在する場合、ログ記録された書き込みイベントはメモリバッファに正常にコミットされており、そうでない場合、ログ記録された書き込みイベントは破棄されることになる、
－閾値は、イベントログのサイズ及び／又はバッファ内に保持されたページのサイズ及び／又はログからの再構築の時間及び／又は最後のフラッシュが実行されてから経過した時間である、
－データページのデータベースストレージは追加専用である、
－各書き込みイベントをログ記録するステップは、データベースストレージへのフラッシュ前のトランザクションである中間トランザクションのために、ディスク上のログストレージに変更の履歴をイベントのログとして書き込むステップを含む、及び／又は
－ログストレージは追加専用である。

さらに、データベースの状態にアクセスするためのコンピュータ実装方法が提供される。この方法は、データベースの状態を保存する方法に従って保存された少なくとも２つのデータベースの状態を有するデータベースを提供するステップを含む。データベースの状態にアクセスする方法はさらに、識別状態に対する読み取りイベントをデータベースによって受け取るステップ、データベースストレージから状態のシーケンスのパッチを取得するステップ、取得されたパッチと識別状態との間に発生したログ記録された書き込みイベントのリストを取得するステップ、そして、ログ記録された書き込みイベントのリストを取得されたパッチに適用し、それによってデータベースの識別状態を回復するステップ、を含む。

データベースの状態にアクセスするためのコンピュータ実装方法において、取得されたパッチは、取得されたパッチとデータベースの識別状態の間に発生したログ記録された書き込みイベントのリストの長さ又はサイズを最小化するパッチであってよい。

データベースの状態を保存する方法及び／又はデータベースの状態にアクセスする方法を実行するための命令を含むコンピュータプログラムがさらに提供される。

さらに、当該コンピュータプログラムを記録したコンピュータ可読記憶媒体を含むデータベースが提供される。

データベースは、データ構造をストレージ層のトランザクションにリンクし、コミットを調整（オーケストレーション）するトランザクションマネージャを含んでもよく、ここで：
－データ構造層のトランザクションマネージャは、イベントログをストレージ層に送り、
－ログストレージ上のイベントログの永続性が、ストレージ層によって承認され、
－承認後、トランザクションマネージャはストレージ層のトランザクションを閉じ、変更されたページをメモリバッファに送信する。

次に、本発明の実施形態を、限定するものではない例をもとに添付の図面を参照して説明する。
データベースの状態を保存する方法の一例のフローチャートを示す。 データベースの状態にアクセスする方法の一例のフローチャートを示す。 データページを変更し、変更されたデータページを追加専用ストレージに記録する例の略図を示す。 パッチ及び共有変更状態のマッピング表におけるアドレス指定の例、並びにログファイルの一例の構造を示す。 本方法のコミットのシーケンスの一例を示す。 システムの一例を示す。

図１のフローチャートを参照すると、データベースの状態を保存するためのコンピュータ実装方法が提案されている。本方法は、データベースを提供するステップＳ１０を含む。

「データベース」とは、検索及び取得用に編成されたデータ（つまり情報）の集まりを意味する（たとえば、ＳＱＬなどの所定の構造化言語に基づくリレーショナルデータベース）。データベースがメモリに保存されていると、コンピュータによる迅速な検索と取得が可能になる。実際に、データベースは、さまざまなデータ処理演算と組み合わせて、データの保存、取得、変更、及び削除が容易になるように構成される。データベースは、レコードに分割できるファイル又はファイルのセットで構成されてもよく、各レコードは１つ以上のフィールドで構成される。フィールドは、データストレージの基本単位である。フィールドはページとも呼ばれる。データベースのページは、データベースファイル内のデータを整理するための内部の基本構造である。ページはＩ／Ｏ演算の基本単位である。ページのサイズは、データベースの実装によって異なり、たとえば、ＳＱＬデータベースサーバーでは、ページのサイズは８ｋＢである。

ユーザーは、主にクエリを介してデータベースのデータを取得してもよい。ユーザーは、キーワードや並べ替えコマンドを使用して、多数のレコードのフィールドをすばやく検索、再配置、グループ化、及び選択して、使用されているデータベース管理システムのルールに従って、データの特定の集計に関するレポートを取得又は作成できる。

データベースの状態とは、特定の時点で保存されるデータのセットである。データベースは常に、１つの特定の状態にある。データベースに保存される情報を追加、削除、又は変更すると、その状態が変わる。たとえば、データベースには、長さ及び／又は形状などのパラメータによって特徴付けられるＣＡＤモデルの色々な設計に関する情報が含まれてよい。一例として、設計プロセス中にこれらのパラメータのいずれかを変更し、新たなパラメータのセットをデータベースに保存すると、その状態は変更される。

データベースは、いくつかの抽象化層又はレベルを有する概念モデルとして表すことができ、各抽象化層は、特定の実装からは独立し得る概念モデル又はアルゴリズムを提供する。一例として、データベースは、データ構造層及びストレージ層を含んでよい。ストレージ層（物理レベルとも呼ぶ）とは、データをたとえばハードドライブといった永続的メモリに保存する役割を果たす。ストレージ層は、データを保存するために揮発性及び／又は永続的（すなわち、不揮発性）メモリを使用してよい。データ構造層（論理レベルとも呼ぶ）とは、データ構造を使用してデータがデータベースにどのように保存されるかを記述する役割を果たす。データ構造は、特定の目的、たとえばデータを永続的に保存するためにどのようにデータをモデル化及び編成するかを定め、データに許可される演算とデータ型の実装は、このレベルで最もデータベースに特有である。

本方法は、データベースによって１つ以上の書き込みイベントを受け取るステップＳ２０をさらに含む。書き込みイベントとは、データベースと通信可能に結合されたシステムによる、データベースに情報を書き込むための要求であり、たとえば、当該システムは、ＣＡＤアプリケーションを実行するコンピュータである。データベースに情報を書き込むことには、データベースへ新たなデータを追加する、及び／又はデータベースにすでに保存されている情報を取り除く（つまり、削除する）、及び／又は、データベースにすでに保存されているデータを変更することが含まれる。データベースは、データベースで作業する複数のユーザーが、書き込み要求を同時又は実質的に同時に送信することを可能にし得る。データベースは、複数の書き込み要求をキューに入れ、それらを順番に実行してもよい。したがって、書き込みイベントとは、データベースによる実行後にデータベースの状態を変更する演算であり、データベースによる実行とは、書き込みイベントを含むトランザクションのコミットのことである。

本方法は、データベースが受け取った各書き込みイベントをログ記録するステップＳ３０をさらに含む。したがって、ログ記録された各書き込みイベントは、データベース上の新たな状態を形成し、つまり、書き込みイベントを含む書き込みトランザクションのコミットにより、データベースの新たな状態が形成される。書き込みイベントをログ記録するステップは、ログを不揮発性メモリに保持する演算である。任意の種類の不揮発性メモリ（長期永続的ストレージとも呼ぶ）を使用してよいことが理解される。ログファイルとは、たとえばデータベースと通信可能に結合されたシステムの要求に応じて、データベースによって実行される演算の時系列の記録を保存するファイルである。したがって、書き込みイベントをログ記録するということは、データベースが受け取った書き込みイベントのシーケンスにおいて、時点ｔ－１に受け取った直前の書き込みイベントの後に、時点ｔにデータベースが受け取った書き込みイベントをログファイルに保存することを意味する。したがって、ログファイルは、データベースが受け取った書き込みイベントのセットを含む。ログファイルには、書き込みトランザクションをコミットするプロセス中に、保存されたデータに適用される変更（書き込みイベント）が含まれ、ここで、書き込みイベントは書き込みトランザクション内にある。書き込みトランザクションとは、データの整合性を維持しながら行われるデータベースの読み取り／書き込みイベントの単位である。トランザクション自体は、データベースの状態を更新するための一連の情報で構成される。目的のデータベースの状態の実際の情報は、既知の状態から、ログに記録された変更（つまり、書き込みイベント）を適用することによって再構築できる。書き込みイベントは、書き込みトランザクションから見たデータベースの状態を変更する。

本方法はさらに、１つ以上の書き込みイベントによって変更又は作成されたページをバッファ内に保持するステップ（Ｓ４０）を含む。前述のとおり、データベースのページは、データベースファイル内のデータを整理するための内部の基本構造であり、ページはＩ／Ｏ演算の基本単位である。データベースのページは、データベース管理のためのデータの最小単位としてのデータベースメモリの連続したブロックである。データベースのアーキテクチャは、既存又は新規のすべてのデータ構造を割り当て、データ構造の特定の情報をページ内に保存する。一例として、ページには、ストレージハードウェア（ページが物理的に存在するところ）における物理的な識別、及び、ページが時間の経過とともに変化して物理的な識別が異なる場合でも、そのページの固定識別子を持つように使用される論理的な識別がある。一例として、ストレージ層は、データ構造層として機能するファイルシステムのアロケータである。論理ページと物理ページの間のこのようなマッピングは、データ構造をストレージ層の並行性制御モデルから分離する。概念上必要となるのは、特定の識別子で実行されるトランザクションのページすべてに関して一貫したマッピングを持つことである。いくつかの一例として、識別子はタイムスタンプであってよい。タイムスタンプとは、特定のイベントがいつ発生したかを識別する文字列でコードされた情報である。他の一例として、識別子は、データベースの状態（例えば、「バージョン１．０」）を示すフラグであってよい。バッファ内に保持するステップとは、バッファと呼ばれる物理メモリの特定の領域にデータを一時的に保存することである。以下、このバッファを共有変更状態と呼ぶ。これらの２つの用語は、同じ意味かつ互換的に使用されてよい。共有変更状態とは、トランザクション間で共有される変更されたページの状態である。したがって、共有変更状態は、トランザクションから生まれ、トランザクションなしで存続でき、また、別の共有変更状態と結合し、新たな共有変更状態を作成でき、これは、概念的に、２つのトランザクションの結合に対応する。したがって、トランザクションが正常にコミット又は中断されるまで、共有変更状態をトランザクションにリンクしてもよい。トランザクションが中断された場合、共有変更状態は破棄されてよい。最初のトランザクションがコミットされると、その共有変更状態は最初のトランザクションにこれ以上リンクされなくなり、２番目以降のトランザクションで使用可能になってもよい。そして、この共有変更状態は、以前のパッチ以降のすべての変更されたページと見なされるようになる（つまり、意味が変更されたということである：「特定のトランザクションによって変更されたページ」ではなく、「以前のパッチ以降に変更されたページ」となる）。

本方法はさらに、閾値に達した場合にはバッファ内に保持されたページをデータベースストレージにフラッシュすることでパッチを作成するステップＳ５０を含む。パッチを作成するステップは、パッチを計算することを意味する。パッチは、１つ以上の新たな書き込みイベントによって変更又は作成された新たなページのリストを含む。一例として、新たなパッチ（最後に計算されたパッチ）は、新たなパッチと現在のパッチ、つまり、新たなパッチが計算される前に得られた最後のパッチとの違いをリスト化する。フラッシュするという行為は、共有変更状態を空にし、その内容を不揮発性メモリに書き込むということである。このフラッシュの閾値は、たとえば、ログのサイズ及び／又はバッファ内に保持されたページのサイズ及び／又はログからの再構築の時間及び／又は最後のフラッシュが実行されてから経過した時間であってよい。ログからの再構築の時間とは、イベントログストレージに記録されたイベントを再適用して、識別状態を再構築するためにかかる見積もり時間である。

このような方法は、シャドウページングとログという２つの選択肢のハイブリッドという選択を利用し、計算リソースやＩ／Ｏによって生成されるメモリを削減しつつ、タイムトラベル特性と長時間トランザクションの性能（オーサリングシステム）を組み合わせたデータベースを得るための方法を改良する。このハイブリッド戦略では、一方ではメモリ書き込みバッファと組み合わせたページバージョンのマッピング表を使用し、他方では追加専用のイベントログストレージを使用する。この方法では、データベースストレージは、ログを含むイベントログストレージとデータページを含むデータストレージに分割される。したがって、イベントログは、時間の経過とともにコミットされた（又はコミットされる予定の）演算を表す書き込みイベントのシーケンスであり、純粋な順次構造である。データベースストレージは、インデックス付きの状態を表す。したがって、変更をコミットするたびに、データストレージは常に増大するとは限らないが、ログは増大する。

本方法は、インメモリのＲＤＦサービスといったグラフデータベースシステムなどのさまざまな種類のデータベースで使用できる。より具体的には、データベースの４つの基本的なＡＣＩＤ特性のうち３つ：不可分性、独立性、永続性を実装することが基本戦略である。

特に、本方法は、追加専用ストレージ戦略によって書き込みトランザクションの不可分性を提供し、Ｉ／Ｏコストを可能な限り低く抑えつつもマルチバージョン並行性制御によって読み取り及び書き込みトランザクション両方の独立性を提供し、そして、書き込みトランザクションの永続性を提供する。本方法は、トランザクションのコミットを受け入れる前に、変更されたページ又は新しく作成されたページがディスクにフラッシュされるのを待たなくてもよく、代わりに変更のログに基づいてもよい。これにより、待ち時間が大幅に削減され、全体的なパフォーマンスが向上する。したがって、この方法は、作成とコミットの待ち時間の点で低コストのトランザクションを提供する。ライターがリーダーをブロックせず、リーダーがライターをブロックしない追加専用戦略は、読み取りトランザクションと書き込みトランザクションの混合ワークロードに適している。これらのトランザクションは、制御及び制限された待ち時間コストでデータベースの任意の状態に対して作成されてよく、このＩ／Ｏコストの削減を利用して、たとえばクリエイティブなオーサリングアプリケーションのために、データベース内で行われた変更の履歴へ「タイムトラベル」的にアクセスすることが可能になる。

さらに、この戦略は、データ構造レベルではなく、データベースストレージレベルで実装されるため、データベースのすべてのデータ構造にこれらの特性が自由に提供される。新たなデータ構造は、前のセクションで説明した特性を利用するためにコストを支払うことなく、設計できる。

この方法はコンピュータで実施される。つまり、方法のステップ（又は実質的にすべてのステップ）が、少なくとも１台のコンピュータ又は任意の同様のシステムによって実行されることを意味する。したがって、本方法のステップは、可能性としては完全自動で、又は半自動で、コンピュータによって実行される。一例として、本方法の少なくともいくつかのステップの始動は、ユーザーとコンピュータのインタラクションを介して実行されてもよい。必要なユーザーとコンピュータのインタラクションのレベルは、予測される自動化のレベルに依存し、ユーザーの希望を実施する必要性とバランスが取られてもよい。一例として、このレベルはユーザー定義及び／又は事前に定義されてもよい。

図６は、システムの一例を示しており、システムは、サーバーであり、例えば、データベースをホストするサーバーである。

この例のサーバーは、内部通信ＢＵＳ１０００に接続された中央処理装置（ＣＰＵ）１０１０と、同じくＢＵＳに接続されたランダムアクセスメモリ（ＲＡＭ）１０７０とを備える。サーバーはさらに、ＢＵＳに接続されたビデオランダムアクセスメモリ１１００と関連するグラフィックプロセッシングユニット（ＧＰＵ）１１１０を備えてもよい。ビデオＲＡＭ１１００は、当技術分野ではフレームバッファとしても知られる。大容量記憶装置コントローラ１０２０は、ハードドライブ１０３０などの大容量記憶装置へのアクセスを管理する。コンピュータプログラムの命令及びデータを有形に具体化するのに適した大容量記憶装置にはあらゆる形態の不揮発性メモリが含まれ、一例として、ＥＰＲＯＭ、ＥＥＰＲＯＭ、及びフラッシュメモリデバイスなどの半導体メモリデバイス、内蔵ハードディスクやリムーバブルディスクなどの磁気ディスク、光磁気ディスク、及びＣＤ－ＲＯＭディスク１０４０が挙げられる。前述したものはいずれも、特別に設計されたＡＳＩＣ（特定用途向け集積回路）によって補完されるか、又はその中に組み込まれてもよい。データベースのストレージ層を実装するために、１つ以上の大容量記憶装置デバイスを使用してもよい。ネットワークアダプタ１０５０は、ネットワーク１０６０へのアクセスを管理する。サーバーはまた、カーソル制御デバイス、キーボードなどのようなハプティックデバイス１０９０を含んでもよい。カーソル制御デバイスは、ユーザーがディスプレイ１０８０上の任意の所望の位置にカーソルを選択的に配置できるよう、サーバーで使用される。さらに、カーソル制御デバイスにより、ユーザーはさまざまなコマンドを選択し、制御信号を入力することが可能となる。カーソル制御デバイスは、システムに制御信号を入力するためのいくつかの信号生成装置を含む。通常、カーソル制御デバイスはマウスであってもよく、マウスのボタンは信号を生成するために使用される。代替的又は追加的に、サーバーシステムは、感圧パッド、及び／又は感圧スクリーンを含んでもよい。

コンピュータプログラムは、コンピュータによって実行可能な命令を含んでもよく、命令は、上記のシステムに本方法を実行させるための手段を含む。プログラムは、システムのメモリを含む任意のデータ記憶媒体に記録可能であってもよい。プログラムは、たとえば、デジタル電子回路、又はコンピュータハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせに実装されてもよい。プログラムは、たとえば、プログラム可能なプロセッサによる実行のために機械可読記憶装置に有形に具体化された製品などの装置として実装されてもよい。本方法のステップは、入力データについて動作し出力を生成して本方法の機能を実行するように命令のプログラムを実行する、プログラム可能なプロセッサによって実行されてもよい。したがって、プロセッサは、データ記憶システム、少なくとも１つの入力デバイス、及び少なくとも１つの出力デバイスからデータ及び命令を受信し、これらにデータ及び命令を送信するように、プログラム可能であるか、結合されてもよい。適用プログラムは、必要に応じて高レベルの手続き型プログラミング言語又はオブジェクト指向プログラミング言語、あるいは、アセンブリ言語又は機械語で実施されてもよい。いずれの場合も、言語はコンパイル型又はインタプリタ型言語であってもよい。プログラムは、フルインストールプログラム又は更新プログラムであってもよい。いずれにせよシステム上でのプログラムの適用は、本方法を実行するための命令をもたらす。

本方法をコンピュータが実施する典型的な例は、この目的に適応したシステム、たとえばサーバーで本方法を実行することである。システムはメモリに結合したプロセッサを含んでもよく、メモリは、本方法を実行するための命令を含むコンピュータプログラムを記録する。メモリはデータベースを格納してもよい。メモリは、そのような格納に適応した任意のハードウェアであり、場合により物理的に異なる部品をいくつか含む（たとえば、プログラム用に１つ、場合によりデータベース用に１つ）。

一例として、本方法は、オーサリングアプリケーションを使用してモデル化オブジェクトを一般的に操作するプロセスで使用される。モデル化オブジェクトとは、たとえばデータベース内に保存されるデータによって定義される任意のオブジェクトである。ひいては、「モデルオブジェクト」という表現は、データ自体を示す。システムの種類に応じて、モデル化オブジェクトはさまざまな種類のデータによって定義されてもよい。システムは、実際に、ＣＡＤシステム、ＣＡＥシステム、ＣＡＭシステム、ＰＤＭシステム、及び／又はＰＬＭシステムの任意の組み合わせであり得る。これらの様々なシステムで、モデル化オブジェクトは対応するデータによって定義される。したがって、ＣＡＤオブジェクト、ＰＬＭオブジェクト、ＰＤＭオブジェクト、ＣＡＥオブジェクト、ＣＡＭオブジェクト、ＣＡＤデータ、ＰＬＭデータ、ＰＤＭデータ、ＣＡＭデータ、ＣＡＥデータが議論され得る。ただし、モデル化オブジェクトはこれらのシステムの任意の組み合わせに対応するデータによって定義され得るため、これらのシステムは他のシステムに対して排他的ではない。したがって、システムはＣＡＤシステムとＰＬＭシステムの両方であってもよい。

説明のため、ここでは、ＣＡＤシステムで採用される方法の例を議論する。

ＣＡＤシステムという用語は、ＣＡＴＩＡといった、モデル化オブジェクトのグラフィック表現に基づいて、少なくともモデル化オブジェクトを設計するために適合されたシステムをさらに意味する。この場合、モデル化オブジェクトを定義するデータは、モデル化オブジェクトの表現を可能にするデータを含む。ＣＡＤシステムは、たとえば、エッジ又は線を使用し、特定の場合には面又は表面も用いた、ＣＡＤのモデル化オブジェクトを表現したものを提供し得る。線、エッジ、又は表面は、さまざまな方法で表されてもよく、非一様有理Ｂスプライン（ＮＵＲＢＳ）が例として挙げられる。具体的には、ＣＡＤファイルには仕様が含まれており、そこからジオメトリーが生成されてもよく、これにより、表現するものの生成が可能になる。モデル化オブジェクトの仕様は、単一のＣＡＤファイル又は複数のＣＡＤファイルに保存されてもよい。ＣＡＤシステムでモデル化オブジェクトを表すファイルの一般的なサイズは、１部品ごとに１メガバイトの範囲である。また、モデル化オブジェクトは通常、数千の部品のアセンブリであり得る。

ＣＡＤの背景では、モデル化オブジェクトは通常、３Ｄのモデル化オブジェクトであってもよく、３Ｄのモデル化オブジェクトは、部品や部品のアセンブリといった製品、又は、場合によっては製品のアセンブリを表す。「３Ｄのモデル化オブジェクト」とは、３Ｄでの表現を可能にするデータによってモデル化されるオブジェクトを意味する。３Ｄでの表現により、すべての角度から部品を見ることが可能になる。たとえば、３Ｄのモデル化オブジェクトは、３Ｄで表現されている場合、そのいずれかの軸、又は、表示されている画面の任意の軸まわりに、処理及び回転されてもよい。これによって、特に、３Ｄにモデル化されていない２Ｄアイコンが除外される。３Ｄ表現の表示により、設計が容易になる（つまり、設計者が統計的にタスクを実行する速度が向上する）。製品の設計は製造プロセスの一部であるため、これにより産業界での製造プロセスがスピードアップする。

３Ｄのモデル化オブジェクトは、たとえばＣＡＤソフトウェアソリューション又はＣＡＤシステムによって現実世界で製造される製品の仮想設計が完成後、当該製品のジオメトリーを表してもよく、当該製品は、（たとえば機械的）部品又は部品のアセンブリ（部品のアセンブリは、本方法の観点から部品自体と見なされ得る、又は、本方法はアセンブリの各部品に独立して適用され得るため、部品と部品のアセンブリは同等である）、又は、より一般的には、任意の剛体のアセンブリ（たとえば、可動機構）が例として挙げられる。ＣＡＤソフトウェアソリューションにより、航空宇宙、建築、建設、消費財、ハイテク機器、産業機器、輸送、海洋、及び／又は沖合の石油／ガス生産又は輸送など、制限なくさまざまな産業分野で製品を設計することが可能になる。本方法で設計される３Ｄのモデル化オブジェクトは、任意の機械部品であり得る産業製品であってよく、たとえば、陸上車両の部品（たとえば、自動車及び軽トラック機器、レーシングカー、オートバイ、トラック及びモーター機器、トラック及びバス、列車などを含む）、航空車両の部品（たとえば、機体機器、航空宇宙機器、推進機器、防衛製品、航空機器、宇宙機器などを含む）、海上車両の部品（海軍機器、商用船、沖合機器、ヨット及び作業船、船舶機器などを含む）、一般的な機械部品（たとえば、産業用製造機械、重機用機械又は機器、設置機器、産業用機器製品、金属加工製品、タイヤ製造製品などを含む）、電気機械又は電子部品（たとえば、家電機器、セキュリティ及び／又は制御及び／又は計測製品、コンピューティング及び通信機器、半導体、医療装置及び機器などを含む）、消費財（たとえば、家具、家庭及び庭用製品、レジャー用品、ファッション製品、耐久消費財小売業者の製品、織物類小売業者の製品などを含む）、パッケージ（たとえば、食品及び飲料及びタバコ、美容及びパーソナルケア、家庭用品の包装などを含む）である。

ＣＡＤの設計プロセスは通常、共同作業であり、複数の人が互いに独立して、又は相互に協力して作業する必要がある。こういった文脈では、ＣＡＤシステムのデータベースによって、すべてのユーザーにデータベースの状態の独立性と整合性が提供されることが重要である。このような設計アプリケーションでは、クリエイティブなオーサリングが必要であり、クリエイティブなオーサリングでは、インクリメンタルな方法で様々な設計の可能性を調査し、タイムトラベル的な方法で変更の履歴をナビゲートすることが必要となる。本発明の方法の例は、ＣＡＤオーサリングアプリケーションを背景に説明している。これらの例は、ＣＡＤオーサリングアプリケーションに限定されず、任意のオーサリングアプリケーションに適用できることを理解されたい。より一般的には、本方法のこれらの例は、オーサリングアプリケーションの特定の分野に限定されず、つまり、この方法の例は、データベースの状態を保存する任意のデータベースに適用できる。

図１を再度参照し、さらに詳しく説明する。データベースがステップＳ１０で提供される。たとえば、このデータベースには、設計者１人又はＣＡＤモデルに並行して作業してもよい複数の設計者が、インクリメンタルな方法のクリエイティブなアプリケーションを介して収集したＣＡＤモデル設計の情報が含まれてよい。データベースは、前述のように、最小単位としてデータページのセットを含んでもよいが、データベースファイル内のデータを編成するための任意の他の内部基本構造を使用してもよいことを理解されたい。

一例として、データベースストレージはレコードをページに保存し、また、データベースストレージは追加専用である。したがって、データベースは不変であり、たとえば、すべてのトランザクションの履歴全体がイベントログストレージに保存される場合がある。これは、監査と履歴クエリを容易にするために役立つ。

次に、ステップＳ２０で、１つ以上の書き込みイベントがデータベースによって受け取られる。書き込みイベントは、データベースに情報を書き込み、１つ以上の新たなデータを追加したり、データベースにすでに保存されている既存のデータを１つ以上変更したりするユーザーの要求である。各書き込みイベントは、データベースの状態を更新するための一連の情報を含む。書き込みイベントは、アプリケーションプログラミングインターフェイス（ＡＰＩ）を介して、又は、通常はパイプ、ソケット若しくは共有メモリを使用するリモートプロシージャコール（ＲＰＣ）を介して送られてよい。たとえば、同じ製品に取り組んでいる設計者のグループが、製品を形成する部品のアセンブリの３Ｄ部品を同時に変更すると、１人以上の設計者が実行した部品の各変更（つまり、受け取られた書き込みイベント）により、データベースを更新するために適用される前記一連の情報が生成される。

次に、ステップＳ３０で、データベースが受け取った各書き込みイベントがログ記録される。ログ記録は、永続性のあるストレージ手段を使用して実行できる。一例として、ログ記録は、少なくとも１つの書き込みイベントのプロセスにおいて、保存されたデータになされた変更の履歴を保存する１つ以上のファイル（ログファイルとも呼ばれる）を維持することによって実行される。他の例としては、ログ記録は、共有ログキュー又は分散ファイルシステムを使用して実行されてよい。ログには、データベースが受け取ったすべての書き込みイベント含め、１つ以上の連続する書き込みイベントによって発生したすべての変更の履歴が保存される。ログ記録された各書き込みイベントは、データベースに新たな状態を作成し、したがって、ログファイルには新たな状態の回復を可能にする情報が保存され、言い方を変えると、ログには、受け取った書き込みイベントによって発生したデータベースのトランザクションが保存される。トランザクションがコミットされた状態は、タイムトラベル的にアクセス可能であることを理解されたい。まだコミットされていない状態の変更は、メモリ内にログイベントを作成し、メモリ内に新たなページを作成する書き込み演算によって行われる。コミット時、ログイベントはディスクに書き込まれ、ページはバッファ内に保持されるか、ディスクに書き込まれる。

一例として、各書き込みイベントをログ記録するステップは、受け取った書き込みイベントによって発生した変更の履歴を、イベントのログとして（イベントのログという形式で）、データベースストレージ（たとえばディスク上）へのフラッシュ前のトランザクションである中間トランザクションのために、メモリ上のイベントログストレージに書き込むステップを含む。中間トランザクション（未フラッシュのトランザクションとも呼ぶ）とは、受け取った書き込みイベントによって引き起こされ、ログに保存されているが、データベースの永続的な状態にまだ関連付けられていないトランザクションである。この状況では、ログ記録は、受け取った書き込みイベントによって発生したすべてのトランザクションの完全な収集として機能し、データベースのデータベースストレージにまだフラッシュされていない１つ以上のトランザクションが中間トランザクションとして保存される。

一例として、イベントログストレージは追加専用、つまり、新たなログは、既存のデータを置き換えるのではなく、常にイベントログストレージに追加される。追加専用のログストレージは、ファイルの最後に各変更を書き込むことによって発生するデータ変更を記録する。この際に、追加専用ログを最初から最後まで再生することにより、受け取った書き込みイベントのセット全体を回復できる。一例として、１つ以上の過去の書き込みイベント（ディスクにフラッシュされるかログ記録される）は、追加専用イベントログストレージに保存された１つ以上のトランザクション及び／又は１つ以上の中間トランザクションを再生することによって再度実行される。

次に、ステップＳ４０において、受け取った書き込みイベントによって変更又は作成されたページがバッファ内に保持される。たとえば、これらの変更又は作成されたページは、製品に対する設計者グループのユーザーインタラクションの結果として得られたものであり、設計者グループが行った製品の変更は保存されている。バッファ内に保持するとは、受け取った書き込みイベントによって変更又は作成されたページがメモリに保存され、システムがこれらのページを後の段階で処理できるようにすることを意味する。したがって、書き込みイベントのページの変更バージョンは、メモリ書き込みバッファでキューに入れられ、後の段階でフラッシュされる。これらのページの変更バージョンは、共有変更状態と呼ばれるページのセットである。データベースのページは説明を目的として選択されるだけであり、Ｉ／Ｏ演算の他のデータベース基本単位が使用されてもよいことを理解されたい。

受け取った書き込みイベントによって変更又は作成されたこれらのページは、閾値に達するまでバッファメモリに残り、閾値に達すると、バッファメモリはステップＳ５０でフラッシュされる。バッファメモリのフラッシュの結果として起こるパッチの作成について、以下で説明する。

一例として、閾値はイベントログのサイズであってよい。したがって、イベントログのサイズが閾値を超える又は閾値に等しい場合、バッファメモリがフラッシュされる。イベントログは、すでに説明したようにログファイルであってよい。イベントログのサイズは、イベントログに保存された受け取った書き込みイベント数、及び／又はイベントログを保存するストレージ媒体上のイベントログが占有するスペース（たとえば、メガバイト（ＭＢ）、ギガバイト（ＧＢ）で測定）を含んでいてよい。たとえば、閾値を１６ＭＢに設定してもよく、この場合、イベントログのサイズが１６ＭＢ以上になると、バッファ内に保持されたページがフラッシュされる。

一例として、閾値はバッファ内に保持されたページのサイズであってもよい。したがって、バッファ内に保持されたページのサイズが閾値を超える又は閾値に等しい場合、バッファメモリがフラッシュされる。バッファ内に保持されたページのサイズは、バッファに保存されたページ数及び／又はバッファ上のバッファ内に保持されたページが占有するスペース（たとえば、メガバイト（ＭＢ）、ギガバイト（ＧＢ）で測定）を含んでいてよい。たとえば、閾値を１ＧＢに設定してもよく、この場合、バッファ内に保持されて保存されたページが１ＧＢに等しくなると、バッファ内に保持されたページがフラッシュされる。

一例として、閾値は、最後にフラッシュが実行されてから経過した時間を含んでもよい。したがって、メモリのフラッシュは定期的に実行され、たとえば、ｎ秒又はｎ分又はｎ時間又はｎ日又はｎ週間又はｎか月ごとに実行される。

一例として、閾値は、ログからの再構築の時間を含んでもよい。再構築の時間とは、ログ記録されるイベントの一部又は全体を再生するために必要な時間の見積もりであり、したがって、再構築の時間は、発生した、又はログ記録されたトランザクションのセットを再計算するための時間である。この際に、追加専用ログを最初から最後まで再生することにより、受け取った書き込みイベントのセット全体を回復することができる。一例として、（データストレージにフラッシュされた、又は、されていない）１つ以上の過去の書き込みイベントは、追加専用イベントログストレージに保存された１つ以上のトランザクション及び／又は１つ以上の中間トランザクションを再生することによって再度実行される。最後のフラッシュからの再構築の時間は、最後にフラッシュが実行されて以降のイベントログストレージ内のログイベントの数に基づいて見積もってよい。

ステップＳ５０は、バッファに保存される書き込みイベントによって変更又は作成されたページがデータベースストレージにフラッシュされた後、これらページのパッチを作成するステップを含む。作成されたパッチは、データベースを管理するシステムが、バッファ内に保持されたページのフラッシュの結果、以前に得た既存のパッチを少なくとも１つ含む場合があるため、新たなパッチと呼ばれることもある。作成された各パッチは、識別子（タイムスタンプや昇順の整数インデックスなど）を割り当てて識別可能であってもよく、その結果、作成されたすべてのパッチを作成順に並べて、パッチのシーケンスを形成できる。このように、フラッシュされたパッチは、それぞれの識別子を割り当てることにより、フラッシュされた時系列順になる。したがって、新たなパッチは、ファイルの最後に作成及び保存された最新のパッチである。新たなパッチは、最後に受け取った書き込みイベントによって変更又は作成された１つ以上のページのリストを含む。新たなパッチは、新たなパッチと、バッファ内に保持されたページの最後から２番目のフラッシュの結果として取得された最後から２番目のパッチとの間のページの変更のみをリスト化する。これにより、メモリ使用量とＩ／Ｏコストが向上する。

したがって、新たなパッチの作成は、データベースが１つ以上の書き込みイベントを受け取った後、閾値に達するたびに実行される。作成を繰り返すたびに、データベースが受け取った新たな書き込みイベントにより変更又は作成された新たなページのリストが作成される。したがって、一部の状態がそれぞれ対応するパッチを有する、状態のシーケンスが得られる。実際に、少なくともパッチの作成は、閾値に達することで引き起こされる、バッファ内に保持されたページのデータベースへのフラッシュに依存するため、パッチがある状態を表すという保証はない。したがって、パッチは、データベースのある状態、又はデータベースの１つ以上の状態の組み合わせ、及び／又はデータベースの１つ以上の状態の一部を表し得る。状態は再帰的にパッチで作られる。パッチｉのページのセットＤｉから再構築されるページのセットＰｉは、再帰的に再構築される。これは次のように表記できる。

たとえば、疑似表記を使用して、最初のパッチをＰ１すると、データベースの状態はＰ１のみで作られ、状態（Ｐ１）＝［Ｐ１］と表記される。２番目のパッチＰ２の場合、状態（Ｐ２）＝［Ｐ２］＋状態（Ｐ１）であると表記できる。同様に、３番目のパッチＰ３は、状態（Ｐ３）＝［Ｐ３］＋状態（Ｐ２）＝［Ｐ１］＋［Ｐ２］＋［Ｐ３］と表記できる。したがって、あるパッチ（Ｐ２など）は、状態Ｐ３のデータベースの状態の一部である。データベースの状態は、パッチの順序付けられたシーケンスで作られ、たとえば、［Ｐ１］＋［Ｐ２］＋［Ｐ３］、そして、シーケンス中、［Ｐ１］及び［Ｐ１］＋［Ｐ２］もデータベースの状態を表する。ただし、状態（Ｐ３）は、Ｐ２でも変更されたパッチＰ１のページは確かめず、最新のページ（つまり、Ｐ２からのページ）のみを確かめる。

このように、本方法の例は繰り返してもよく、つまり、たとえばＣＡＤ設計プロセスの過程でステップＳ１０からＳ５０を繰り返し、データベースがさらに書き込みイベントを受け取ってから閾値に達するたびに新たなパッチが作成され、データベースストレージにフラッシュされる。新たな各パッチは、その新たな書き込みイベントによって変更又は作成された新たなページのリストを含む。新たな各パッチはまた、後述する通り、マッピング表及び／又はディスクリプタをさらに含んでもよい。したがって、一部の状態がデータベースストレージにそれぞれ対応するパッチを有し、その対応する状態は、たとえば対応するマッピング表を介して直接取得可能であるような、状態のシーケンスが得られる。データベースストレージ内のパッチに対応しないデータベースの状態は、データベースストレージにフラッシュする前のトランザクション、つまり未フラッシュのトランザクションの結果である。これらのトランザクションは、イベントログストレージに書き込まれることで永続的になる。

データベースの概念モデルはすでに上で説明した通りである。一例として、データベースはストレージ層を含み、このストレージ層ではメモリを割り当て、変更し、変更を保存できる。ステップＳ３０～Ｓ５０は、ストレージレベルで実現されてもよい。データベースはさらにデータ構造層を含み、データ構造層では、データ構造（Ｂ木など）は、ストレージ層にメモリを割り当て、そのメモリ領域を変更して必要な構造を作成することで作成される。ステップＳ１０～Ｓ２０は、データ構造レベルで実現されてもよい。図５は、データ構造層とストレージ層間の関係の例を示す。図５を、以下で説明する。

ここで図３を参照して、新たなパッチの作成の概略例を説明する。この例は、追加専用データストレージに保存された３つのデータページから始まり、これらの３つのページはすでにデータベースでフラッシュされており、従来のシャドウページングアーキテクチャと同様に、ｎページがディスクにフラッシュされると、ｎページのパッチが作成される。これら各ページには、各ページが物理的に存在するストレージ層内におけるデータの物理的な識別があり、たとえば、各ページには、ディスクドライブなどの記憶媒体上での物理アドレスがある。一例として、データベースは、物理的な識別の変化の影響を受けない論理的な識別によってデータページを参照し、たとえば、各ページには、データベース観点の論理アドレスがある。これらの３つのページは、既にフラッシュされているため、既存のパッチで「参照」される。その目的のために、パッチはマッピング表を含んでもよい。上記の論理的な識別と物理的な識別の間のマッピングを確立するために、マッピング表を事前に定義する必要がある。ディスク上のファイルにアクセスするためには、マッピング表を使用する以外の技術が使用されてもよいことを理解されたい。３ページのフラッシュ後に作成されたパッチは、マッピング表を含む。マッピング表は、理論上のマルチバージョンインデックスと見なすことができる。マッピング表は、理論上のマルチバージョンインデックスと同じ機能を実行するものの、パフォーマンス向上のために完全なマルチバージョンインデックスを実際に実行することはない。図３に示すように、タイムスタンプＴ１に関して、マッピング表は、論理アドレス（１、２、３）をストレージ内の物理アドレス（ａｄｒ＃１、ａｄｒ＃２、ａｄｒ＃３）にそれぞれマップする。タイムスタンプＴ２に関して、ページ１と３が変更される。論理アドレスは変更されず、代わりに、新たなマッピング表はＴ１のページ２の古い物理アドレスとＴ２のページ２及び３の新たな物理アドレスを指す。データベースでトランザクションが作成される（又は開かれる）と、このマッピング表は、論理ページと物理ページ間に、メモリ内で構築又はインスタンス化される。したがって、データ構造は、物理ページの知識なしで論理ページのみを認識し、データ構造は、物理ページの知識なしで論理ページのみを認識する。マッピング表がメモリにすでに存在する場合、新たなマッピング表は、既存のマッピング表、たとえば、前のタイムスタンプのマッピング表を複製し、目的のトランザクションとデータベースの状態までローカルマッピングを適用することによって作成される。マッピング表が存在しない場合は、たとえば、タイムスタンプＴ２のパッチのディスクリプタからタイムスタンプＴ１のパッチのディスクリプタに戻るなど、ディスクリプタからディスクリプタへ戻って全パッチがスキャンされ、使用のために選択された最初のディスクリプタによって定義される、全ページの最新バージョンを得る。このマッピング表戦略により、単一のマルチバージョンインデックスのメモリコストとその高いロック競合が削減される。マッピング表の実装は、整数と整数／ポインタの間の関連付けが最も速い表を取得するよう選択してもよい。一例として、マッピング表は、当技術分野で公知のように、ロックフリーのコンペア・アンド・スワップ配列に基づいてパフォーマンス効率よく作成してもよい。他の一例として、マッピング表は、ユーザー空間のリード・コピー・アップデート（ＲＣＵ）同期機構に基づいて作成してもよい。

図３の一例として、パッチは、新たな書き込みイベントによって変更又は作成された１つ以上の新たなページのリストを含み、さらにディスクリプタも含む。ページのセットを表すパッチは、マップされたメモリを利用できるようにするために、いくつかの配置的な制約を適用してもよい。たとえば、１ページあたり４ｋバイトがＩｎｔｅｌ（著作権）及びＡｒｍ（著作権）プロセッサの仮想メモリに割り当てられる、別の一例として、Ｗｉｎｄｏｗｓ（著作権）の仮想メモリのマネージャは、パッチが６４ｋバイトのブロックで配置されるように課し、したがって、パッチは６４ｋｂブロックの倍数であり、ディスクリプタは最後の６４ｋｂブロックの最後に書き込まれる。ディスクリプタは、不可分性をサポートするために、パッチのページを含むメモリブロックの最後に書き込まれる最後の要素として追加できる：ディスクリプタの存在は、ページが正常にコミットされたことを示し、言い換えれば、最後にこのディスクリプタを書くことによって、パッチ全体が正しく登録されていることを確認する簡単な方法が提供される。それ以外の場合では、前のディスクリプタの後に見つかるすべてのデータは無視、つまり、破棄される。一例として、ディスクリプタは、以下のうちの少なくとも１つを含んでもよい：
－新たな書き込みイベントによって変更又は作成された物理ページの数。したがって、現在のパッチの始まりを見つけることができ、そして、その前のパッチを見つけてパッチに関連付けられたメモリリソースの事前割り当てを簡単にすることができる。

－ディスクリプタの整合性をチェックするためのメタデータ、これによって、ディスクリプタが破損していないことを確認する。

－パッチによって表される書き込みイベントのタイムスタンプ。パッチのコミット（つまり、そのフラッシュ）の順序は、ディスクリプタから取得できる。これにより、必要に応じてデータベースの再構築が改良される。

ディスクリプタの存在は、ページマッピングのアルゴリズムに確実な停止条件を提供してもよい。図３の例を再度参照すると、パッチは、最後に受け取った書き込みイベントによって変更又は作成された１つ以上の新たなページのリスト及びディスクリプタを含む。パッチは、図４に示すようなマッピング表をさらに含んでもよく、マッピング表は、前記論理的な識別と物理的な識別との間のマッピングを含む。

目的のデータベースの状態、特にデータベースストレージ内のパッチに対応しない状態の実際の情報は、既知の状態、すなわち、データベースストレージ内の対応するパッチを有する状態から、イベントログストレージに記録されたイベントログファイルに記録される変更の適用と組み合わせて再構築できる。

図２は、上記の図１の方法の例に従って保存されたデータベースの状態の１つにアクセスして取得する例を示すフローチャートである。この一例として、その方法に従って、データベースの少なくとも２つの状態が既にバッファからフラッシュされ、ディスクに保存されている。したがって、少なくとも２つのデータベースの状態を含むデータベースが、ステップＳ２１０で提供される。ステップＳ２２０において、識別状態に関するデータを取得するためにデータベースによって読み取りイベントが受け取られる。この識別状態は、ユーザーがクエリを行ってもよく、コンピュータが自動的にクエリを行ってもよい。この識別状態は、バッファへのフラッシュの結果としてディスク上にすでに存在するデータベースの状態であるか、時系列的に２つの保存されたパッチ間に存在する状態であり得る。いずれの場合も、本方法は、ステップＳ２２１において、データベースストレージから状態のシーケンスのパッチを取得する。前に説明したように、データベースの状態を構築するために取得されたパッチは、パッチは一般にそれ自体では十分ではないため、先行するパッチの取得を含む。前者の場合、この取得されたパッチは、書き込みイベントの結果としてディスクにフラッシュされたデータベースの状態の対応するパッチである。後者の場合、本方法は、取得されたパッチと識別状態の間に発生したログ記録された書き込みイベントのリストを取得する。一例として、取得されたパッチは、時系列で識別状態の前にくる最初のパッチである。別の例としては、取得されたパッチは、時系列で識別状態の後にくる最初のパッチである。さらに別の例としては、取得されたパッチは、時系列で識別状態に最も近いパッチであり、つまり、取得されたパッチとデータベースの識別状態の間に発生したログ記録された書き込みイベントのリストの長さを最小化するパッチである。次に、ステップＳ２２２において、本方法は、取得されたパッチとデータベースの識別状態との間に発生したログ記録された書き込みイベントのリストを取得する。これらのログファイルは、データページの変更の履歴を保持する。ステップＳ２２３において、識別されたデータベースは、ログ記録された書き込みイベントのリストを、取得したパッチに適用することによって回復される。

図５は、本方法によるコミットのシーケンスの例を示す。トランザクションマネージャは、イベントログに保存された一連のコマンド１、コマンド２として１つ以上の書き込みイベントを受け取る。トランザクションマネージャの役割は、データ構造をストレージ層のトランザクションにリンクし、イベントログのコマンドのコミットを調整することである。コミットは、受け取った各イベントをイベントログに保存するように命令するトランザクションマネージャ（１）から始まる。この命令の結果として、イベントは追加専用のイベントログストレージであってもよいイベントログに書き込まれ、ストレージ層は、イベントが保存されたことをトランザクションマネージャに承認する（２）。変更又は作成されたページをデータベースに直接保存するのではなく、受け取った書き込みイベントをイベントログに保存することで、Ｉ／Ｏボリュームが大幅に減少するため、ストレージ層の潜在的な過負荷が減少する。ステップ（１）及び（２）は、待ち時間の影響を受ける可能性があるが、受け取ったすべての書き込みイベントはデータベースによって認知及びログ記録されており、受け取った書き込みイベントは後の段階でデータベースでコミットできるため、問題とはならない。

トランザクションが承認された後、トランザクションマネージャはトランザクションを閉じる、トランザクションマネージャの観点からは、これは、受け取った書き込みイベントがデータベースによって処理されているとトランザクションマネージャによって見なされることを意味する。

次に、トランザクションマネージャは、ストレージ層に命令を送信（３）して、バッファに変更されたページを保存（４）し、閾値に達したときにフラッシュ（５）される。

変更がコミットされるたびに、データベースストレージにフラッシュされる前に変更されたデータページがメモリバッファに保持されるため、イベントログストレージのサイズは必然的に大きくなるが、データストレージのサイズはコミットとそれに続くフラッシュでのみ大きくなる。

図４及び図５を参照すると、本方法によるコミットのシーケンスの例は、図３に示される２つのタイムスタンプＴ１及びＴ２にわたって説明できる。タイムスタンプＴ３で、図４に示すように、トランザクションマネージャは書き込みイベントのコマンドを受け取る。書き込みイベントは、スレッド１によって要求されたデータページ２を変更する。受け取った書き込みイベントは、トランザクションマネージャの注文により、ストレージ層によってイベントログストレージに記録される。

図４にログファイルの例を示す。ログ記録は、既知の技術手法によって実行される。一例として、ログファイルはトランザクションのコンテキストを含む。トランザクションのコンテキストとは、その状態を表す疑似オブジェクトであり、トランザクションの重要なスレッド（スレッド１）、トランザクションの開始タイムスタンプ（Ｔ３）、及びトランザクションの終了タイムスタンプを含んでもよい。終了タイムスタンプとは、トランザクションのコミット時間を指し、トランザクションがコミットされたときに計算される。コミットはシリアル化され、つまり、変更のトランザクションは互いに続く。たとえば、Ａが書き込みトランザクションを開始し、Ｂが書き込みトランザクションを開く場合、ＢはＡの書き込みトランザクションが完了（たとえば、中断／コミット）したときに実際に開始し、Ａが完了する前にＢが開始したとしても、Ｂの書き込みトランザクションは、Ａの後に開始したようになる。

図５に戻ると、受け取ったイベントの正しいログの承認（２）の後、トランザクションマネージャは変更されたページをバッファに送信（３）する。トランザクションマネージャはさらに、物理メモリのａｄｒ＃７の共有変更状態に新たなデータページ２を書き込む。トランザクションマネージャは、変更したページ２との新たなパスに対応するマッピング表も更新する。このマッピング表は、（ａｄｒ＃４、ａｄｒ＃７、ａｄｒ＃５）として読み取られるデータベースストレージの最後のタイムスタンプ（Ｔ２）のパッチのマッピング表に対応するマッピング表を最初に複製することによって作成される。

図５に戻ると、閾値に達すると、メモリバッファは定期的にディスクにフラッシュ（５）される。このフラッシュの閾値は、たとえば、ログのサイズ及び／又はバッファ内に保持されたページのサイズ及び／又はログからの再構築の時間及び／又は最後のフラッシュが実行されてから経過した時間であってよい。このコミットのシーケンスの一例として、フラッシュの閾値に達した場合、バッファ内に保持されたデータ（ａｄｒ＃７）をデータベースストレージにフラッシュすることによって新たなパッチが作成される。新たなパッチは、更新されたマッピング表（ａｄｒ＃４、ａｄｒ＃７、ａｄｒ＃５）と、パッチのそれぞれのタイムスタンプ（Ｔ３）を含むディスクリプタをさらに含む。

図４及び図５を参照すると、本方法は、正常にコミットされた各パッチの最後にディスクリプタを提供することにより、データページの追加専用ストレージへの保存を通して不可分性をサポートすることが分かる。さらに、データページのさまざまなバージョンにさまざまなマッピング表を提供することにより、読み取りトランザクションと書き込みトランザクションの独立性がサポートされる。ストレージ層のこの設計により、トランザクションが適切にコミットされてその変更が見えるか、又はその変更は見えないことを保証する。さらに、すべてのトランザクションはディスクに書き込まれるため、永続性を持つようになり、一部のトランザクションの対応する状態は、パッチとしてデータベースストレージにフラッシュされ、中間トランザクションの対応する状態は、保存されたパッチとともにイベントログストレージに保存された変更の履歴を使用して再構築できる。このようなログ記録とディスクへのページの定期的なフラッシュの組み合わせにより、最適化されたパフォーマンスがサポートされる。

本方法は、トランザクションのコミットを受け入れる前に、変更されたページ又は新しく作成されたページがディスクにフラッシュされるのを待たず、したがって、待ち時間が大幅に削減される。代わりに、本方法は変更のログに基づいて保存されていないデータベースの状態を回復し、これは、全体的なパフォーマンスの点でより興味深いものである。この方法は、作成とコミットの待ち時間の点で低コストのトランザクションを提供する。

各リーダーと各ライターは独自のマッピング表とメモリ書き込みバッファを使用するため、ライターがリーダーをブロックせず、リーダーがライターをブロックしない追加専用戦略は、読み取りトランザクションと書き込みトランザクションの混合ワークロードに対して最適化されたパフォーマンスを提供する。これらのトランザクションは、削減されたＩ／Ｏコストを生かして、制御及び制限された待ち時間コストでデータベースの任意の状態に対して作成できる。一方で、ディスク上で利用可能な最も近いデータページと、目的のデータベースの状態までイベントログを再適用することを組み合わせることで、データベースのどの状態にもほぼ同じようにアクセスできる。アクセスのコストは、最悪の場合で、メモリマップデータファイルにマッピング表を作成するコストと、ディスク上のページをフラッシュする閾値に到達するために必要なページ数を生成したログを再生するコストの合計に等しくなる。したがって、本方法は、クリエイティブなオーサリングアプリケーションのために、データベース内で行われた変更の履歴へのタイムトラベルな方法のアクセス機能を提供する。

さらに、この戦略は、データ構造レベルではなく、データベースストレージレベルで実装されるため、データベースのすべてのデータ構造にこれらの特性が自由に提供される。本方法で示される特性を利用するためにコストを支払うことなく、新たなデータ構造を設計できる。

本発明の好ましい実施形態を記載してきた。本発明の趣旨及び範囲から逸脱することなく、様々な修正を行うことができることが理解される。したがって、他の実装も、以下の特許請求の範囲内にある。

Claims (16)

1. データベースの状態を保存するためのコンピュータ実装方法であって、
   データベースを提供するステップ（Ｓ１０）と、
   前記データベースによって１つ以上の書き込みイベントを受け取るステップ（Ｓ２０）と、
   各書き込みイベントをログ記録するステップ（Ｓ３０）であって、ログ記録された前記各書き込みイベントが前記データベースに新たな状態を形成するステップ（Ｓ３０）と、
   前記書き込みイベントによって変更又は作成されたページをバッファ内に保持するステップ（Ｓ４０）と、
   閾値に達した場合に、前記バッファ内に保持されたページをデータベースストレージにフラッシュすることでパッチを作成するステップ（Ｓ５０）と
   を含む、コンピュータ実装方法。
2. 前記データベースが新たな書き込みイベントを受け取った後、前記閾値に達するたびに前記作成するステップを繰り返すステップをさらに含み、
   当該作成するステップの各繰り返しは、前記データベースが受け取った新たな書き込みイベントによって変更又は作成された新たなページのリストを作成し、それによって、一部の状態がそれぞれ対応するパッチを有する、状態のシーケンスを取得することを含む、
   請求項１に記載のコンピュータ実装方法。
3. 作成された新たな前記パッチは、それぞれ、前記バッファ内に保持されたページの物理アドレスと前記データベースのデータ構造層にあるページの論理アドレスとの間のマッピングを含むマッピング表をさらに含む、
   請求項２に記載のコンピュータ実装方法。
4. 前記ログ記録された書き込みイベントは、それぞれ、前記バッファ内の既存のマッピング表を複製し、目的のログ記録された書き込みイベントまでローカルマッピングを適用することによって得られる、ローカルマッピング表を有する
   請求項３に記載のコンピュータ実装方法。
5. 前記マッピング表は、ロックフリーのコンペア・アンド・スワップ配列に基づく
   請求項２から４のいずれか一項に記載のコンピュータ実装方法。
6. 作成された前記パッチはディスクリプタをさらに含み、
   前記ディスクリプタは、
   新たな書き込みイベントによって変更又は作成された物理ページの数、
   ディスクリプタの整合性を確認するためのメタデータ、
   新たな書き込みイベントのタイムスタンプ、
   のうち少なくとも１つを含む
   請求項２から５のいずれか一項に記載のコンピュータ実装方法。
7. 前記ディスクリプタが存在する場合、前記ログ記録された書き込みイベントはメモリバッファに正常にコミットされており、そうでない場合、前記ログ記録された書き込みイベントは破棄される
   請求項６に記載のコンピュータ実装方法。
8. 前記閾値は、イベントログのサイズ及び／又はバッファ内に保持されたページのサイズ及び／又はログからの再構築の時間及び／又は最後のフラッシュが実行されてから経過した時間である
   請求項１から７のいずれか一項に記載のコンピュータ実装方法。
9. データページの前記データベースストレージが追加専用である
   請求項１から８のいずれか一項に記載のコンピュータ実装方法。
10. 前記各書き込みイベントをログ記録するステップが、前記データベースストレージへのフラッシュ前のトランザクションである中間トランザクションのために、ディスク上のログストレージに変更の履歴をイベントのログとして書き込むことを含む
    請求項１から９のいずれか一項に記載のコンピュータ実装方法。
11. 前記ログストレージが追加専用である
    請求項１０に記載のコンピュータ実装方法。
12. データベースの状態にアクセスするためのコンピュータ実装方法であって、
    請求項１から１１のいずれか一項に記載の方法に従って保存された少なくとも２つのデータベースの状態を有するデータベースを提供するステップ（Ｓ２１０）、
    識別状態に対する読み取りイベントを前記データベースによって受け取るステップ、
    前記データベースストレージから前記状態のシーケンスのパッチを取得するステップ（Ｓ２２１）、
    前記取得されたパッチと前記識別状態との間に発生したログ記録された書き込みイベントのリストを取得するステップ（Ｓ２２２）、
    前記ログ記録された書き込みイベントのリストを前記取得されたパッチに適用し、それによって前記データベースの識別状態を回復するステップ（Ｓ２２３）
    を含む方法。
13. 前記取得されたパッチは、前記取得されたパッチと前記データベースの識別状態の間に発生したログ記録された書き込みイベントのリストの長さ又はサイズを最小化するパッチである
    請求項１２に記載のコンピュータ実装方法。
14. 請求項１から１１のいずれか一項に記載の方法及び／又は請求項１２から１３のいずれか一項に記載の方法を実行するための命令を含むコンピュータプログラム。
15. 請求項１４に記載のコンピュータプログラムを記録したコンピュータ可読記憶媒体を含むデータベース。
16. 前記データベースは、データ構造をストレージ層のトランザクションにリンクし、コミットを調整するトランザクションマネージャをさらに含み、
    前記データ構造層の前記トランザクションマネージャは、イベントログを前記ストレージ層に供給し、
    ログストレージ上の前記イベントログの永続性は、前記ストレージ層によって承認され、
    承認後、前記トランザクションマネージャは、前記ストレージ層のトランザクションを閉じ、変更されたページをメモリバッファに送信する
    請求項１５に記載のデータベース。

Images