JP2022098496A - データベース状態のツリーの作成 - Google Patents

Abstract

【課題】データベースの状態のツリーを作成するためのコンピュータ実装方法、プログラム、記憶媒体及びデータベースを提供する。【解決手段】方法は、データベースの状態のブランチを少なくとも１つ有するデータベースを提供しＳ１０、データベースの識別状態に適用される１つ以上の書き込みイベントをデータベースが受け取りＳ２０、データベースからデータベースの識別状態を回復しＳ３０と、識別状態の参照とともに、データベースの識別状態の代替状態として新規のパッチを作成することにより、新規のブランチを作成するＳ４０。【選択図】図１

Description

本発明は、コンピュータプログラム及びシステムの分野、より具体的には、データベースの状態のツリーを作成して、データベースの代替状態を作成、クエリ、及び比較する性能を提供するための方法、システム、及びプログラムに関する。

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

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

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

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

特に、クリエイティブなオーサリングアプリケーションの場合、データベースの代替状態を作成、クエリ、及び比較してクリエイティブオーサリングアプリケーションのワークフローに準拠する性能を提供するために、データベースのどのブランチのどの状態に対してもトランザクションを開けるようにすることが望ましく、これは、データセットのバージョン管理の考え方である。データベースのバージョン管理の概念は、ソフトウェア開発のバージョン管理開発に似ているが、データベースのバージョン管理では、ソフトウェアコードを追跡するのではなく、データセットの状態を追跡する。データベースに１つ以上の上記性能を提供するために、既知のデータベースシステムにはさまざまな戦略が存在する。

Bhardwajらによる、「DataHub: Collaborative Data Science & Dataset Version Management at Scale」（7th Biennial Conference on Innovative Data Systems Research, 2015）では、このバージョン管理システムに基づいて共同データ分析を実行する性能がユーザーに提供される。この目標を達成するために、バージョンファースト表現とレコードファースト表現の２つの主要なデータ表現が使用される。バージョンベースの表現では、特定のブランチに対応するデータが専用の場所（つまり、ＳＱＬテーブル）に保存されるが、レコードファーストの表現では、データはレコードのリストとして保存され、それぞれのリストに、属するバージョンのアノテーションが付けられる。

これら２つの表現の一般的な欠点は、代替、つまり「バージョン」の概念がデータレベルにあることである。したがって、データベース内の各データ構造がこの概念を認識している必要があり、ソフトウェアの開発と維持にコストがかかる。さらに、クエリに回答するには、特定の代替状態のデータ構造を再構築する（又はマテリアライズした状態を再利用する）必要があり、それに対応するリソースのコストがかかる。リソースが必要となる、という欠点は、これらのツールをビッグデータに適用したり、クリエイティブなオーサリングアプリケーションに適用して、タイムトラベル的な方法で変更の履歴をナビゲートしたりする際にさらに悪化する。

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

したがって、データベースの状態のツリーを作成するためのコンピュータ実装方法が提供され、この方法は、データベースの状態のブランチを少なくとも１つ有するデータベースを提供するステップ、データベースの識別状態に適用される１つ以上の書き込みイベントをデータベースが受け取るステップ、データベースからデータベースの識別状態を回復するステップ、及び、識別状態の参照とともに、データベースの識別状態の代替状態として新規のパッチを作成することにより、新規のブランチを作成するステップを含む。

データベースの状態のツリーを作成するためのコンピュータ実装方法は、以下のうちの１つ以上を含んでもよい：
－データベースの識別状態を回復するステップは、
・データベースストレージから、データベースの状態のシーケンスで、識別状態のブランチのパッチを取得するステップ（Ｓ２１０）、
・取得されたパッチと識別状態との間に発生したログ記録された書き込みイベントのリストを取得するステップ（Ｓ２２０）、
・ログ記録された書き込みイベントのリストを、取得したパッチに適用するステップ（Ｓ２３０）を含む、
－新規のパッチを作成することにより、新規のブランチを作成するステップは、それぞれの代替状態のデータベースの状態がデータベースストレージに保存されたパッチでない場合、データベースストレージにバッファをフラッシュするステップをさらに含む、
－識別状態の参照は：
・識別状態がパッチで表されている場合は、取得されたパッチの参照、及び、
・識別状態がパッチで表されていない場合は、バッファリングされたページがデータベースストレージにフラッシュされた後に作成されたパッチの参照、を含む、
－新規のパッチは、新規の書き込みイベントによって変更又は作成された新規のページのリストを含み、それによって、一部の状態がそれぞれ対応するパッチを有する、状態のシーケンスを取得する、
－新規のパッチは、バッファリングされたページの物理アドレスとデータベースのデータ構造層にあるページの論理アドレスとの間のマッピングを含むマッピング表をさらに含む、
－ログ記録された各書き込みイベントは、既存のマッピング表を複製し、目的のログ記録された書き込みイベントまでローカルマッピングを適用することにより、マッピング表を有する、
－新規のパッチはさらに：
－ディスクリプタを含み、当該ディスクリプタは：
・新規の書き込みイベントによって変更又は作成された物理ページの数、
・ディスクリプタの整合性を確認するためのメタデータ、
・新規の書き込みイベントのタイムスタンプ、
・データベースの対応する識別状態の参照
のうち、を少なくとも１つ含む、
－データベースストレージは追加専用である;
－この方法はさらに、ログ記録された書き込みイベントのリストを取得する前に、データベースが受け取った１つ以上の書き込みイベントをそれぞれログストレージ上にログ記録し、データベースストレージへのフラッシュ前のトランザクションである中間トランザクションのために、ログストレージに変更の履歴をイベントのログとして書き込むステップを含む、
－ログストレージは追加専用である。

本方法を実行するための命令を含むコンピュータプログラムがさらに提供される。

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

さらに、当該コンピュータプログラムを記録したコンピュータ可読ストレージが提供される。

さらに、当該データベースを含むコンピュータ化されたシステムが提供される。
次に、本発明の実施形態を、非限定的な例をもとに添付の図面を参照して説明する。

データベースの状態のツリーを作成する方法の一例のフローチャートを示す。 データベースからデータベースの識別状態を回復する方法の一例のフローチャートを示す。 データページを変更し、変更されたデータページを追加専用ストレージに記録する例の概略図を示す。 新規のブランチを作成する例を示す。 システムの一例を示す。

図１のフローチャートを参照すると、データベースの状態のツリーを作成するためのコンピュータ実装方法が提案されている。本方法は、データベースの状態のブランチを少なくとも１つ有するデータベースを提供するステップ（Ｓ１０）を含む。

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

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

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

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

データベースの各ブランチは、データベースの状態のシーケンスと見なすことができ、ブランチ内の各データベースの状態は、同じブランチ内でそれ以前の別のデータベースを変更することによって取得される。フォークは、第１のブランチから第２のブランチを作成する行為であり、第２のブランチと第１のブランチ間の関係を表す。代替状態とは、データベースの異なるブランチ上でアクセスされるデータベースの状態である。

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

本方法は、データベースからデータベースの識別状態を回復するステップ（Ｓ３０）をさらに含む。データベースから識別状態を回復するということは、データベースストレージから識別状態の値を取得、つまり復元することを意味する。識別状態は、データベースストレージから直接取得できるか、データベースストレージに保存されるさまざまなアイテムの情報を組み合わせて復元できる。後者の例としては、ログ記録戦略のような保存されたログファイルからデータベースの状態を復元することであり、ログ記録戦略では、変更は最初にログファイルに記録されて、不揮発性ストレージに書き込まれる。ログファイルは、行為の時系列の記録を保存するファイルである。

この方法は、識別状態の参照とともに、データベースの回復した識別状態の代替状態として新規のパッチを作成することにより、新規のブランチを作成するステップ（Ｓ４０）をさらに含む。パッチを作成するステップは、パッチを計算することを意味する。パッチは、１つ以上の新規の書き込みイベントによって変更又は作成された新規のページのリストを含む。一例として、新規のパッチ（最後に計算されたパッチ）は、新規のパッチと現在のパッチ、つまり、新規のパッチが計算される前に得られた最後のパッチとの違いをリスト化する。参照とは、状態を識別するエンコードされた情報の一部である。状態は、代替状態の識別状態であってもよい。

本方法は、インメモリのＲＤＦサービスといったグラフデータベースシステムなどのさまざまな種類のデータベースで使用できる。本方法により、データベースのさまざまな代替状態を作成、クエリ、及び比較する性能が改善される。これは、タイムトラベル性能を備えたＳＱＬやＳＰＡＲＱＬなどの言語へのＧｉｔのような性能として理解できる。この方法によるブランチ性能は、すべてのソフトウェアスタックを使用してストレージ層レベルで適用されるが、従来は、データ構造層レベルである。したがって、既存又は新規のすべてのデータ構造が、このデータ構造の「バージョン可能」版が存在しない場合でも、認識せずにこのブランチ性能を持つことができる。バージョン可能なデータ構造であるということは、データ構造が永続性を有する、つまり、変更されたときに以前のバージョンそのものを保持する、ということである。この性能は、安価なＣＰＵ及びメモリコストで提供され、また、ソフトウェアの開発と維持も低コストで提供される。本方法は、クエリとアルゴリズムが、実行しているブランチという概念を持たず、すべてのブランチで同じように実行されるため、データ構造に影響を与えずに、データベースの代替状態を作成、クエリ、及び比較するためのブランチ性能を提供する。ストレージのコストは、各ブランチでの新規変更に制限されており、データやページの重複はない。その結果、トランザクション作成のＣＰＵとメモリのコストは、ブランチ性能がない場合と同じコストと同じになる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、ステップＳ３０で、データベースの識別状態がデータベースから回復される。データベースから識別状態を回復することは、データベースからその値を取得することを意味する。この識別状態は、ユーザーがクエリを行ってもよく、コンピュータが自動的にクエリを行ってもよい。識別状態の回復は、データベースの状態をデータベースストレージに保存する方法によって変わってもよい。データベースの状態をデータベースストレージに保存する好ましい例について説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

したがって、好ましい例は、一方ではメモリ書き込みバッファと組み合わせたページバージョンのマッピング表、他方ではイベントログストレージの２つの間でストレージ方法に対してハイブリッドな選択をする。

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

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

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

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

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

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

図１に戻ると、次のステップＳ４０で、識別状態の参照とともに、識別状態の代替状態として新規のパッチを作成することにより、新規のブランチが作成される。識別状態がバッファのフラッシュの結果としてディスク上に存在せず、時系列的に２つの保存されたパッチ間の状態である場合、新規のパッチの作成には、データベースストレージへのバッファのフラッシュがさらに含まれる。新規のブランチのそれぞれの状態をデータベースにフラッシュすることにより、本方法はログファイルを使用して、このブランチに対応する中間状態をそれぞれ再構築できる。

識別状態の参照は、データベースが、代替状態がどのブランチを参照しているかを検出できるように、新規のブランチの新しく作成された各パッチに追加される。この対応するブランチを見つけることは、新規のブランチのデータベースの状態のクエリを見つけるために重要である。識別状態の参照は、識別状態がパッチによって表される場合は取得されたパッチの参照を含み、識別状態がパッチによって表されない場合はバッファリングされたページがデータベースストレージにフラッシュされた後に作成されたパッチの参照を含む。

図４は、本方法に従った、代替状態としてのデータベースの状態のツリーを作成する例を示しており、データベースの状態はデータのツリーを保存する。データ構造層のツリーの情報は、ストレージ層の一部のデータページに保存される。図４に示すように、タイムスタンプＴ１において、マッピング表は、論理アドレス（１、２、３）をストレージ内の物理アドレス（ａｄｒ＃１、ａｄｒ＃２、ａｄｒ＃３）にそれぞれマップする。タイムスタンプＴ２の場合、書き込みイベントはページ１と３を変更し、対応する新規のパッチが、変更されたページ、つまりページ１とページ３のみを含み、データベースストレージに作成される。この変更の結果、マッピング表が更新され、論理アドレス（１、２、３）をデータベースストレージ内の物理アドレス（ａｄｒ＃１、ａｄｒ＃２、ａｄｒ＃２）にそれぞれマップする。パッチ内のアドレスはパッチに対してローカルであり、グローバルアドレスではない。タイムスタンプＴ１とタイムスタンプＴ２の対応するパッチは、Ｂ１という名前の同じブランチ上にあると見なされる。タイムスタンプＴ４で、タイムスタンプＴ１でのデータベースの履歴にフォークが適用され、タイムスタンプＴ１に対応するデータベースの状態からＢ２という名前の新規のブランチが作成される。この新規のブランチでは、タイムスタンプＴ１の識別状態と比較して、ページ３が変更され、対応する新規のパッチが、変更されたページ３と一緒にデータベースストレージに作成される。いくつかの例では、新規のブランチの作成はタイムスタンプＴ３で実行され、ページ３の変更はタイムスタンプＴ４で実行されてもよい。このシナリオでは、タイムスタンプＴ３で作成されたブランチＢ２は既存のパッチを指しているため、パッチはタイムスタンプＴ４でのみ作成される。対応する新規のパッチのマッピング表が更新され、論理アドレス（１、２、３）を物理アドレス（ａｄｒ＃１、ａｄｒ＃２、ａｄｒ＃１）にマップする。上記のとおり、パッチ内のアドレスはパッチに対してローカルであり、グローバルアドレスではない。ブランチのタイムスタンプＴ２のパッチの参照は、ブランチＢ２のタイムスタンプＴ４のパッチのディスクリプタに書き込んでもよい。

本発明では、ページの論理識別子のみを操作することにより、データ構造に影響を与えることなく、新規のブランチのデータベースの代替状態が作成される。この戦略は、データ構造レベルではなく、データベースストレージレベルで実装されるため、本方法のブランチ性能はデータベースのすべてのデータ構造に適用可能である。これらのデータ構造で実行されるクエリとアルゴリズムは、クエリとアルゴリズムが存在するブランチからは独立して実行されるため、ソフトウェア開発と維持のコストなしで利用できる。

さらに、２つのブランチ間でデータやページの重複がないため、必要なリソースのコストが削減される。この方法では、特定のブランチでトランザクションを開くと、単一のブランチでマッピング表を作成するのと同じ方法で、対応するマッピング表を作成することになる。違いは、別のストレージアイテムにいつフォークしてジャンプするかを知る必要があることであり、これは、識別状態の参照を介して提供される。参照はパッチのディスクリプタに含まれてもよい。したがって、ＣＰＵとメモリのコストは、ブランチ１つだけの場合と複数のブランチの場合で同じである。オーバーヘッドとストレージのコストは、新規のブランチで変更されたページのストレージコストに制限される。

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

Claims (14)

1. データベースの状態のツリーを作成するためのコンピュータ実装方法であって、
   データベースの状態のブランチを少なくとも１つ有するデータベースを提供するステップ（Ｓ１０）と、
   前記データベースの識別状態に適用される１つ以上の書き込みイベントを前記データベースが受け取るステップ（Ｓ２０）と、
   前記データベースから前記データベースの識別状態を回復するステップ（Ｓ３０）と、
   前記識別状態の参照とともに、前記データベースの識別状態の代替状態として新規のパッチを作成することにより、新規のブランチを作成するステップ（Ｓ４０）と
   を有するコンピュータ実装方法。
2. 前記データベースの識別状態を回復するステップは、
   データベースストレージから、前記データベースの状態のシーケンスで、前記識別状態のブランチのパッチを取得するステップ（Ｓ２１０）と、
   取得されたパッチと前記識別状態との間に発生したログ記録された書き込みイベントのリストを取得するステップ（Ｓ２２０）と、
   前記ログ記録された書き込みイベントのリストを、前記取得されたパッチに適用するステップ（Ｓ２３０）と
   を含む
   請求項１に記載のコンピュータ実装方法。
3. 前記新規のパッチを作成することにより前記新規のブランチを作成するステップは、それぞれの前記代替状態の前記データベースの状態が前記データベースストレージに保存されたパッチでない場合、前記データベースストレージにバッファをフラッシュするステップをさらに含む
   請求項１または２に記載のコンピュータ実装方法。
4. 前記識別状態の参照は、
   前記識別状態がパッチで表されている場合に、前記取得されたパッチを参照することと、
   前記識別状態がパッチで表されていない場合に、バッファリングされたページが前記データベースストレージにフラッシュされた後に作成されたパッチを参照することと
   を含む
   請求項３に記載のコンピュータ実装方法。
5. 前記新規のパッチは、新規の書き込みイベントによって変更又は作成された新規のページのリストを有し、
   一部の状態がそれぞれ対応するパッチを有する状態のシーケンスを取得する
   請求項３から４のいずれか一項に記載のコンピュータ実装方法。
6. 前記新規のパッチは、前記バッファリングされたページの物理アドレスと前記データベースのデータ構造層にあるページの論理アドレスとの間のマッピングを含むマッピング表をさらに有する
   請求項５に記載のコンピュータ実装方法。
7. 前記ログ記録された書き込みイベントは、それぞれ既存のマッピング表を複製して目的のログ記録された書き込みイベントへローカルマッピングを適用することにより生成されたマッピング表を有する
   請求項６に記載のコンピュータ実装方法。
8. 前記新規のパッチはディスクリプタをさらに含み、
   前記ディスクリプタは、
   ・新規の書き込みイベントによって変更又は作成された物理ページの数、
   ・ディスクリプタの整合性を確認するためのメタデータ、
   ・新規の書き込みイベントのタイムスタンプ、
   ・データベースの対応する識別状態の参照
   のうち少なくとも１つを含む
   請求項３から７のいずれか一項に記載のコンピュータ実装方法。
9. 前記データベースストレージは追加専用である
   請求項１から８のいずれか一項に記載のコンピュータ実装方法。
10. 前記ログ記録された書き込みイベントのリストを取得する前に、前記データベースが受け取った１つ以上の書き込みイベントをそれぞれログストレージ上にログ記録し、前記データベースストレージへのフラッシュ前のトランザクションである中間トランザクションのために、前記ログストレージに変更の履歴をイベントのログとして書き込むステップをさらに含む
    請求項２から９のいずれか一項に記載のコンピュータ実装方法。
11. 前記ログストレージは追加専用である
    請求項１０に記載のコンピュータ実装方法。
12. 請求項１から１１の何れか一項に記載の方法を実行するための命令を含むコンピュータプログラム。
13. 請求項１２に記載のコンピュータプログラムを記録したコンピュータ可読記憶媒体。
14. 請求項１２に記載のコンピュータプログラムを記録したコンピュータ可読記憶媒体を含むデータベース。

Images