特許 7580371 トライデータ構造ベースのデータベースのための効率的なインメモリマルチバージョン同時実行制御

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-31

(45)【発行日】2024-11-11

(54)【発明の名称】トライデータ構造ベースのデータベースのための効率的なインメモリマルチバージョン同時実行制御

(51)【国際特許分類】

   G06F 16/28 20190101AFI20241101BHJP

【ＦＩ】

G06F16/28

【請求項の数】 12

(21)【出願番号】P 2021515453

(86)(22)【出願日】2019-09-18

(65)【公表番号】

(43)【公表日】2022-01-11

(86)【国際出願番号】 EP2019074932

(87)【国際公開番号】W WO2020058300

(87)【国際公開日】2020-03-26

【審査請求日】2022-08-02

(31)【優先権主張番号】18195454.6

(32)【優先日】2018-09-19

(33)【優先権主張国・地域又は機関】EP

(73)【特許権者】

【識別番号】519314836

【氏名又は名称】センシェア ゲーエムベーハー

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】バウアー，ウォルター

【審査官】甲斐 哲雄

(56)【参考文献】

【文献】特開２０１４－１９１６７２（ＪＰ，Ａ）

【文献】特開２０００－２２７９２１（ＪＰ，Ａ）

【文献】特開２０１２－０７３９４３（ＪＰ，Ａ）

【文献】特開２００８－０６５７６４（ＪＰ，Ａ）

【文献】特表２０１８－５０９６８３（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１０／１４６００４（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１２／２２１５３８（ＵＳ，Ａ１）

【文献】米国特許第８８３８１２２（ＵＳ，Ｂ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

(57)【特許請求の範囲】

【請求項1】

特定のバージョンのデータベースオブジェクトの格納場所を判定するための、電子データベースアプリケーションまたは情報検索システムにより実行される、コンピュータ実装方法であって、前記データベースオブジェクトの各バージョンのインデックスが、前記特定のバージョンに対応するルートノードを有するトライに格納され、前記方法が、
前記特定のバージョンに対応するトライの前記ルートノードにアクセスすることにより、前記特定のバージョンに対応する前記トライを判定することと、
検索キーとして、前記データベースオブジェクトに関連する２次キーを使用して、前記特定のバージョンに対応する前記トライをトラバースすることにより、前記データベースオブジェクトのオブジェクト識別子を判定することと、
検索キーとして、前記判定されたオブジェクト識別子を使用して、前記特定のバージョンに対応する前記トライをトラバースすることにより、前記データベースオブジェクトの前記格納場所を判定することと、を含む、コンピュータ実装方法。

【請求項2】

検索キーがオブジェクト識別子であるかどうか、またはデータベースオブジェクトに関連する２次キーであるかどうかの情報が、前記検索キーに含まれる、請求項１に記載の方法。

【請求項3】

２次キーが、前記２次キー内に符号化された１つ以上のプロパティに関する情報を含む、請求項１～２のいずれか一項に記載の方法。

【請求項4】

前記２次キー内に符号化された前記１つ以上のプロパティが、名前、及びアドレスのうちの１つを含む、請求項３に記載の方法。

【請求項5】

インデックスが、キーおよび値を有するものとして定義される、請求項１～４のいずれか一項に記載の方法。

【請求項6】

第１のインデックスが、前記２次キーをキーとして、かつ前記オブジェクト識別子を値として有することによって定義され、第２のインデックスが、前記オブジェクト識別子をキーとして、かつ前記データベースオブジェクトの前記格納場所を値として有することによって定義される、請求項１～５のいずれか一項に記載の方法。

【請求項7】

前記特定のバージョンに対応するルートノードを有する前記トライが、前記特定のバージョンに対する新しいルートノードを作成することと、以前のバージョンに対応するルートノードを有する以前のトライのノードに関して補正された前記ノードをコピーし、変更することと、補正されていない前記以前のトライの前記ノードを指す参照を作成することと、によって作成される、請求項１～６のいずれか一項に記載の方法。

【請求項8】

前記特定のバージョンに対応するルートノードを有する前記トライを作成することが、トランザクション中に実行され、前記特定のバージョンが、前記トランザクションに関連付けられている、請求項７に記載の方法。

【請求項9】

前記トランザクションが、トランザクション識別子によって識別される、請求項８に記載の方法。

【請求項10】

請求項１～９のいずれか一項に記載の方法を実行するための命令を含む、コンピュータプログラム。

【請求項11】

請求項１～９のいずれか一項に記載の方法を実行するように構成されている、１つ以上のプロセッサおよびメモリを含むデータ処理デバイスまたはシステム。

【請求項12】

請求項１０に記載のコンピュータプログラムをその上に格納している、非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、概して、バージョンストレージ、ガベージコレクション、およびインデックス管理を含むマルチバージョン同時実行制御（ＭＶＣＣ）のためのデータベースおよび情報検索システムにおけるトライデータ構造の効率的な使用に関する。

【0002】

国際特許出願ＰＣＴ／ＥＰ２０１８／０５６５９２が参照され、これは、参照によりその全体が本明細書に組み込まれる。

【背景技術】

【0003】

マルチバージョン同時実行制御（ＭＶＣＣ）は、データベース管理システム（ＤＢＭＳ）における一般的なトランザクション管理スキームである。それは、典型的に、トランザクション処理中に必要な直列化可能性を維持しながら、並列処理を向上させる。マルチバージョニングは、複数の読み取り専用トランザクションが、複数のレコードの一貫したスナップショットでも、書き込みトランザクションが新しいバージョンを同時に生成することを妨げることなく、現在または古いバージョンのレコードに同時にアクセスすることを可能にする。

【0004】

ＭＶＣＣをサポートするには、データベースは、各オブジェクトの複数の物理バージョンを維持する必要がある。リレーショナルデータベースでは、これらのオブジェクトはタプル（レコード）であり、ドキュメント指向データベースでは、これらは、ドキュメントであり、キー－バリュー型データベースでは、オブジェクトは、（不透明な）値である。ＭＶＣＣを使用することにより、オブジェクトへの更新は、オブジェクトまたはその一部を新しいデータでオーバーライドするのではなく、前記オブジェクトの新しいバージョンを作成する。

【0005】

ＭＶＣＣを使用すると、複数のバージョンの格納の実行方法、読み取りアクセス中に適切なバージョンを見つける方法（バージョンストレージ）、使われておらず、かつ二度と読み取られないバージョンを削除する方法（ガベージコレクション）に関連するいくつかの困難が発生する。また、データベースがクエリのパフォーマンスを改善させるためにインデックスを必要とするため、ＭＶＣＣ対応のインデックス更新を実現する方法、およびインデックスを使用してクエリを実行する方法（インデックス管理）にさらに困難がある。

【0006】

同時実行制御プロトコルは、同時読み取りおよび書き込みトランザクションの実行を調整する。各トランザクションが見るまたはアクセスを有するバージョンは、ＭＶＣＣによって実装された分離レベルに依存する。実装される一般的な分離レベルは、スナップショット分離であり、トランザクションは、トランザクションが開始されたときのデータの状態にアクセスすることができる。以下の説明では、スナップショット分離に焦点を当てる。

【0007】

バージョンストレージ
図１Ａは、複数のバージョンを格納するための異なるバージョンの格納スキームを例示する。

【0008】

付加専用スキーマ１０１、１０２では、更新のために、オブジェクトがコピーされ、変更され、新しいバージョンがストレージスペースに付加される。バージョンのチェーンは、オブジェクトごとに維持する必要がある。このアプローチの欠点は、適切なバージョンを見つけるために、潜在的に長いチェーンをトラバースする必要があることである。使われていないバージョンは、パフォーマンスを維持するために頻繁にプルーニングする必要がある。このチェーンのヘッドバージョンは、実装に応じて最も古いバージョンまたは最新のバージョンになる可能性がある。ヘッドが最も古いバージョンを指している場合はガベージコレクション中に、またはヘッドが新しいバージョンを指している場合は更新後に、インデックスを更新する必要がある。代替的に、二重リンクチェーンを使用することができるが、これは、さらに、メンテナンスのオーバーヘッドを引き起こす。

【0009】

タイムトラベルストレージ１０３は、付加専用スキーマに類似しているが、バージョンは、別個のタイムトラベルストレージスペースに格納されている。メインストレージスペースでは、マスターバージョンは、タイムトラベルストレージスペース内のバージョンチェーンを参照して保持される。更新の場合、新しいオブジェクトがタイムトラベルストレージスペースにコピーされる。マスターバージョンは、実装に応じて最も古いバージョンまたは最新バージョンになる可能性があり、これに応じて、タイムトラベルストレージスペース内の新しいコピーまたはマスターバージョンのいずれかが更新によって変更される。インデックスは、マスターバージョンを指し、影響を受けない。

【0010】

デルタストレージ１０４では、マスターバージョンは、格納場所、典型的には、現在のバージョンで維持される。更新の変更は、例えば、レコードの変更された属性など、元のバージョンまたはその一部への変更を格納するロールバックセグメントと呼ばれるデルタストレージ内に記録される。これにより、元のオブジェクトを取得し、ログに記録された変更を適用して結果のオブジェクトバージョンを取得する必要があるため、読み取りアクセス中のオーバーヘッドが高くなる。

【0011】

上記のすべてのバリアントは、オブジェクトバージョンのチェーンを作成し、現在のオブジェクトバージョンまたは最初に依然として保持されているバージョンのいずれかがチェーンの先頭であり、インデックスは常に、オブジェクトの１つのバージョンのみを指す。

【0012】

ガベージコレクション
ＭＶＣＣによる更新中にトランザクションが新しいオブジェクトバージョンを作成するため、システムのスペースが不足しないように、使われていないバージョンのスペースを再利用する必要がある。また、上で言及されるように、あまりにも多くのバージョンを保持しすぎると、場合によっては、パフォーマンスが低下する可能性がある。

【0013】

まず、ガベージコレクションは、使われていないバージョンを検出できる必要がある。オブジェクトバージョンが新しい（現在の）バージョンに置き換えられ、スナップショット分離の場合、古いバージョンが依然として可視であるアクティブなトランザクションがない場合、オブジェクトバージョンは使われていない。これは、トランザクションごとに単調に増加するＩＤを有することによって検出することができ、置き換えられた各オブジェクトは、それを置き換えたトランザクションのＩＤでマークされる。すべてのアクティブなトランザクションの任意のＩＤよりも小さい置換ＩＤを有するすべてのオブジェクトを削除し、そのストレージスペースを再利用することができる。

【0014】

バージョンストレージスキームに応じて、オブジェクトは、チェーンからリンク解除され、コピーされ、インデックスが更新される必要がある。次いで、物理的スペースを再利用することができる。インメモリデータベースの場合、これは、一般的なメモリ管理の問題につながる。

【0015】

ガベージコレクションを実行する一般的なアプローチは、ルーチンの「バキューム」によるものである。バックグラウンドスレッドは、データベースを定期的にスキャンして、期限切れのオブジェクトバージョンを探す。しかしながら、データベース全体をスキャンすることは、より大きいデータベースにはスケールしない。これを軽減するために、トランザクションは置き換えられたオブジェクトをマークまたは登録し、ガベージコレクションは、これらのオブジェクトを考慮して、それらが使われていないかどうかを確認する。

【0016】

インデックス管理
Ｙｉｎｇｊｕｎ Ｗｕ，Ｊｏｙ Ａｒｕｌｒａｊ，Ｊｉｅｘｉ Ｌｉｎ，Ｒａｎ Ｘｉａｎ，ａｎｄ Ａｎｄｒｅｗ Ｐａｖｌｏ．２０１７．Ａｎ ｅｍｐｉｒｉｃａｌ ｅｖａｌｕａｔｉｏｎ ｏｆ ｉｎ ｍｅｍｏｒｙ ｍｕｌｔｉ－ｖｅｒｓｉｏｎ ｃｏｎｃｕｒｒｅｎｃｙ ｃｏｎｔｒｏｌ．Ｐｒｏｃ．ＶＬＤＢ Ｅｎｄｏｗ．１０，７（Ｍａｒｃｈ ２０１７），７８１－７９２．ＤＯＩ：ｈｔｔｐｓ：／／ｄｏｉ．ｏｒｇ／１０．１４７７８／３０６７４２１．３０６７４２７＞によると、先行技術によるＭＶＣＣデータベース管理システムは、データベースのバージョン情報をインデックスから分離する。これは、インデックスにキーが存在するということは、そのキーを有する何らかのバージョンが存在することを意味するが、インデックスエントリは、バージョンに関する情報を含まないことを暗示する。

【0017】

したがって、キーには常に何らかのバージョンが存在するため、インデックスルックアップで誤検知が発生することはないが、インデックスが特定のトランザクションから可視ではないキーのバージョンを指す可能性があるため、誤検知が発生する可能性がある。これは、誤検知の一致を削除するためにインデックスを使用したクエリの結果をフィルタリングする必要があるため、パフォーマンスが低下するオーバーヘッドをもたらす。

【0018】

図１Ｂは、インデックスがオブジェクトを参照する方法の２つの一般的なアプローチ、論理ポインタ１１１の使用、および物理ポインタ１１０の使用を示す。論理ポインタを使用するインデックスは、固定オブジェクト識別子（オブジェクトＩＤ）を物理オブジェクトストレージにマップする間接層を使用する。バージョンストレージに応じて、これは、バージョンチェーンまたはマスターバージョンの先頭になる。このアプローチにより、変更が発生するたびに新しい物理的な場所を指すようにすべてのインデックスを更新する必要があるという問題が回避される。

【発明の概要】

【0019】

前述の目的の１つ以上は、独立クレームの主題によって達成される。好ましい実施形態は、従属請求項の対象である。

【0020】

本発明の第１の実施形態は、電子データベースアプリケーションまたは情報検索システムにおいて、特定のバージョンのデータベースオブジェクトの格納場所を判定するためのコンピュータ実装方法であり、データベースオブジェクトの各バージョンのインデックスは、特定のバージョンに対応するルートノードを有するトライに格納され、この方法は、特定のバージョンに対応するトライのルートノードにアクセスすることにより、特定のバージョンに対応するトライを判定することと、検索キーとして、データベースオブジェクトに関連する２次キーを使用して、特定のバージョンに対応するトライをトラバースすることにより、データベースオブジェクトのオブジェクト識別子を判定することと、検索キーとして、判定されたオブジェクト識別子を使用して、特定のバージョンに対応するトライをトラバースすることにより、データベースオブジェクトの格納場所を判定することと、を含む。

【0021】

第２の実施形態によれば、第１の実施形態において、検索キーがオブジェクト識別子であるかどうか、またはデータベースオブジェクトに関連する２次キーであるかどうかの情報が、検索キーに含まれる。

【0022】

第３の実施形態によれば、第１～第２の実施形態のいずれか１つにおいて、２次キーが、２次キー内に符号化された１つ以上のプロパティに関する情報を含む。

【0023】

第４の実施形態によれば、第３の実施形態において、２次キー内に符号化された１つ以上のプロパティが、名前、アドレスなどのうちの１つを含む。

【0024】

第５の実施形態によれば、第１～第４の実施形態のいずれか１つにおいて、インデックスが、キーおよび値を有するものとして定義される。

【0025】

第６の実施形態によれば、第１～第５の実施形態のいずれか１つにおいて、第１のインデックスが、２次キーをキーとして、かつオブジェクト識別子を値として有することによって定義され、第２のインデックスが、オブジェクト識別子をキーとして、かつデータベースオブジェクトの格納場所を値として有することによって定義される。

【0026】

第７の実施形態によれば、第１～第６の実施形態のいずれか１つにおいて、特定のバージョンに対応するルートノードを有するトライが、特定のバージョンに対する新しいルートノードを作成することと、以前のバージョンに対応するルートノードを有する以前のトライのノードに関して補正されたノードをコピーし、変更することと、補正されていない以前のトライのノードを指す参照を作成することと、によって作成される。

【0027】

第８の実施形態によれば、第７の実施形態において、特定のバージョンに対応するルートノードを有するトライを作成することが、トランザクション中に実行され、特定のバージョンが、トランザクションに関連付けられている。

【0028】

第９の実施形態によれば、第８の実施形態において、トランザクションが、トランザクション識別子によって識別される。

【0029】

本発明の第１０の実施形態は、電子データベースアプリケーションまたは情報検索システムのデータベースインデックスを含む、１つ以上のトライのトライノードによって占有されている、解放される未使用メモリを識別するためのコンピュータ実装方法であって、方法が、１つ以上のチャンクを含むアレイを格納することであって、チャンクが、トライノードを格納するように構成され、アレイが、第１のトライノードを含む少なくとも第１のチャンクを含む、格納することと、アレイのどのチャンクが新しいトライノードを格納するために空いているかを示す空きチャンクリストを格納することと、第１のトランザクション中に第１のトライノードを更新している間、第１のトライノードが第１のトランザクション中に作成されたかどうかを判定することと、判定の結果に応じて、第１のトライノードを含む第１のチャンクを空きチャンクリストに追加することと、を含む。

【0030】

第１１の実施形態によれば、第１０の実施形態では、第１のトライノードが第１のトランザクション中に作成されたと判定される場合、方法が、第１のトライノードを含む第１のチャンクを空きチャンクリストに追加することをさらに含む。

【0031】

第１２の実施形態によれば、第１０～１１の実施形態のいずれか１つにおいて、第１のトライノードが第２のトランザクション中に作成されたかどうかを判定することと、第１のトライノードが第１のトランザクションの前の第２のトランザクション中に作成されたと判定される場合、保留中の空きチャンクリストに、第１のトライノードを含む第１のチャンクを追加すること。

【0032】

第１３の実施形態によれば、第１２の実施形態において、保留中の空きチャンクリストに、第１のトライノードを含む第１のチャンクを追加することが、第１のトランザクションに関連付けられており、かつ第１のチャンクへの参照を含む、保留中の空きチャンクリスト内に、リストエントリを生成することを含む。

【0033】

第１４の実施形態によれば、第１３の実施形態では、第１のトランザクションに関連付けられている保留中の空きチャンクリスト内のリストエントリが、第１のトランザクションの前の１つ以上のトランザクション中に作成され、かつ第１のトランザクション中に更新されたすべてのチャンクを参照することを可能にする。

【0034】

第１５の実施形態によれば、第１４の実施形態において、第１のトランザクションの前の１つ以上のトランザクション中に作成され、かつ第１のトランザクション中に更新されたすべてのチャンクを参照することが、第１のトランザクションの前の１つ以上のトランザクション中に作成され、かつ第１のトランザクションで更新されたチャンクのチェーンを指す第１のトランザクションに関連付けられたポインタで実現される。

【0035】

第１６の実施形態によれば、第１２～第１５の実施形態のいずれか１つにおいて、方法が、アクティブなデータベーストランザクションを含むトランザクションリストを格納することと、保留中の空きチャンクリストが、トランザクションリスト内の最も古いトランザクションよりも古いトランザクションに関連付けられた１つ以上のエントリを含むかどうかを判定することと、保留中の空きチャンクリストが、トランザクションリスト内の最も古いトランザクションよりも古いトランザクションに関連付けられた１つ以上のエントリを含むと判定される場合、１つ以上のエントリに関連付けられたチャンクを空きチャンクリストに移動させることと、をさらに含む。

【0036】

第１７の実施形態によれば、第１０～第１６の実施形態のいずれか１つにおいて、各チャンクが、ペイロード値と、それが作成されている間にトランザクションを識別する値とを含む。

【0037】

第１８の実施形態によれば、第１０～第１７の実施形態のいずれか１つにおいて、第１のトランザクション中に第１のトライノードを更新することが、更新された値を有する第１のトライノードのコピーとして第２のトライノードを作成することを含む。

【0038】

第１９の実施形態によれば、第１７～第１８の実施形態のいずれか１つにおいて、第１のトランザクション中に第１のトライノードを更新することが、第２のトライノードを含む第２のチャンクを作成することを含み、チャンクが作成される間にトランザクションを識別する値が、第１のトランザクションに対応する。

【0039】

第２０の実施形態によれば、第１７～第１９の実施形態のいずれか１つにおいて、ノードが作成される間にトランザクションを識別する値が、トランザクション識別子である。

【0040】

第２１の実施形態によれば、第２０の実施形態において、第１のトライノードが第１のトランザクション中に作成されたかどうかの判定が、第１のトランザクションのトランザクション識別子を第１のチャンクのトランザクション識別子と比較することによって実行される。

【0041】

第２２の実施形態によれば、第２０～第２１の実施形態のいずれか１つにおいて、トランザクションがトランザクションリスト内の最も古いトランザクションよりも古いかどうかの判定が、トランザクション識別子を比較することによって実行され、より古いトランザクションが、より新しいトランザクションよりも低いトランザクション識別子を有する。

【0042】

第２３の実施形態によれば、第１０～第２２の実施形態のいずれか１つにおいて、アレイが、チャンクによって占有されていない空き空間をさらに含む。

【0043】

第２４の実施形態によれば、第１０～第２３の実施形態のいずれか１つにおいて、アレイ上の各ノードが、長整数として格納される。

【0044】

第２５の実施形態によれば、第１０～第２４の実施形態のいずれか１つにおいて、トライ内の各ノードが、アレイ内のノードのインデックスを含むポインタによって参照される。

【0045】

第２６の実施形態によれば、第１０～第２５の実施形態のいずれか１つにおいて、アレイのサイズが制限される。

【0046】

第２７実施形態によれば、第１０～第２６の実施形態のいずれか１つにおいて、１つ以上のチャンクが、異なるサイズを有するチャンクおよび同じサイズを有するチャンクを含み、異なるサイズの各チャンクが、空きチャンクリストに格納されたポインタによって参照され、空きチャンクリストに格納されているポインタによって参照されるチャンクが、それ自体と同じサイズのチャンクへのポインタを含む。

【0047】

第２８の実施形態によれば、第２７の実施形態において、１つ以上のチャンクが、６４の異なるサイズのチャンクを含む。

【0048】

第２９の実施形態によれば、第２７～第２８の実施形態のいずれか１つにおいて、異なるサイズが、子ノードを指す各ノードに含まれるポインタの数に関連付けられている。

【0049】

第３０の実施形態によれば、第２７～第２９の実施形態のいずれか１つにおいて、同じサイズのチャンクが、ポインタによって互いにリンクされている。

【0050】

本発明の第３１の実施形態は、電子データベースアプリケーションまたは情報検索システムのデータベースインデックスを格納するトライノードによって占有されている、解放される未使用メモリを識別するためのコンピュータ実装方法であって、方法は、１つ以上のアレイ、およびトライノードを格納するように構成されたアクティブアレイを格納することであって、各トライノードが、現在のトランザクションに対応する現在のトライルートノードおよび／または以前のトランザクションに対応する１つ以上の以前のトライルートノードに関連付けられている、格納することと、エビクショントランザクション中に、１つ以上のアレイの１つが基準を満たすかどうかを判定し、１つ以上のアレイの１つが基準を満たすと判定される場合、基準を満たすアレイを選択するステップと、選択されたアレイが現在のトライルートノードに関連付けられている１つ以上のノードを含む場合、現在のトライルートノードに関連付けられている選択されたアレイの１つ以上のノードをアクティブアレイにコピーするステップと、選択されたアレイによって占有されているメモリを、解放される未使用のメモリとして識別するステップと、を実行することであって、現在のトライルートノードに関連付けられている選択されたアレイの１つ以上のノードをアクティブアレイにコピーするステップが、
現在のトライルートノードに関連付けられているノードをトラバースすることと、ノードをトラバースしている間、選択されたアレイに格納されているノードをコピーし、選択されたアレイに格納されていないノードを無視することと、選択されたアレイの前に作成されたアレイに格納されているノードの子ノードおよびノードをトラバースしないことと、を含む、実行することと、を含む。

【0051】

第３２の実施形態によれば、第３１の実施形態において、現在のトライルートノードに関連付けられている選択されたアレイの１つ以上のノードをアクティブアレイにコピーすることが、現在のトライルートノードに関連付けられているノードをトラバースしている間、選択されたアレイがアクティブアレイになった後に作成された以前のトライルートノードに関連付けられているノードを同時にトラバースすることと、現在のトライルートノードに関連付けられているノードを、以前のトライルートノードに関連付けられているノードと上から下へレベルごとに比較することと、ノードが現在のトライルートノードには関連付けられているが、以前のトライルートノードには関連付けられていないことが比較によって判定される場合、ノードおよびノードの子ノードをトラバースしないことと、をさらに含む。

【0052】

第３３実施形態によれば、第３２の実施形態において、選択されたアレイがアクティブアレイになった後に作成された以前のトライルートノードが、選択されたアレイがアクティブアレイになった後に作成された第１のトライルートノードである。

【0053】

第３４の実施形態によれば、第３２～第３３の実施形態のいずれか１つにおいて、現在のトライルートノードに関連付けられているノードを、以前のトライルートノードに関連付けられているノードと上から下へレベルごとに比較することが、ノードの子ノードへの参照を比較することを含む。

【0054】

第３５の実施形態によれば、第３４の実施形態において、ノードの子ノードへの参照が、ＡＮＤ演算によって比較される。

【0055】

第３６の実施形態によれば、第３５の実施形態において、ノードの子ノードへの参照が、ビットマップによって示され、比較が、ビット単位のＡＮＤ演算によって実行される。

【0056】

第３７の実施形態によれば、第３１～第３６の実施形態のいずれか１つにおいて、方法が、選択されたアレイによって占有されるメモリを、解放される未使用のメモリとして識別する前に、選択されたアレイが、１つ以上の保留中のトランザクションで使用されている１つ以上の以前のトライルートノードに関連付けられた１つ以上のノードを含むかどうかを判定することと、選択されたアレイが、１つ以上の保留中のトランザクションで使用されている１つ以上の以前のトライルートノードの一部である１つ以上のノードを含むと判定される場合、保留中のトランザクションが終了するまで待機することと、をさらに含む。

【0057】

第３８の実施形態によれば、第３７の実施形態において、保留中のトランザクションが終了するかどうかの判定が、保留中のトランザクションを、エビクショントランザクションと比較することによって実行され、保留中のトランザクションがエビクショントランザクションより古いトランザクションを含まないと判定される場合、保留中のトランザクションが終了すると判定する。

【0058】

第３９の実施形態によれば、第３１～第３８の実施形態のいずれか１つにおいて、アクティブアレイが、第１０～第３０の実施形態に定義されるようなアレイである。

【0059】

第４０の実施形態によれば、第３１～第３９の実施形態のいずれか１つにおいて、方法は、現在のトライルートノードの一部である選択されたアレイの１つ以上のノードをアクティブアレイにコピーする前に、アクティブアレイがノードを包含するのに十分な空き空間があるかどうかを判定することと、アクティブアレイが十分な空き空間を有していないと判定される場合、アクティブアレイとなる新しいアレイを作成することであって、以前のアクティブアレイが１つ以上のアレイの１つになる、作成することと、をさらに含む。

【0060】

第４１の実施形態によれば、第３１～第４０の実施形態のいずれか１つにおいて、アクティブアレイおよび１つ以上のアレイが制限されたサイズを有する。

【0061】

第４２の実施形態によれば、第３１～第４１の実施形態のいずれか１つにおいて、基準が、現在アレイを使用しているトランザクションの数、および／またはアレイに含まれる１つ以上の以前のトライのノードの数を含む。

【0062】

第４３の実施形態によれば、第３１～第４２の実施形態のいずれか１つにおいて、基準が、置き換えられたアレイ内のノードの量およびサイズを含む。

【0063】

第４４の実施形態によれば、第３１～第４３の実施形態のいずれか１つにおいて、トライ内の各ノードが、それぞれのアレイへの参照およびアレイ内のノードのインデックスを含むポインタによって参照される。

【0064】

本発明の第４５の実施形態は、第１～第４４のいずれか１つの方法を実行するための命令を含む、コンピュータプログラム、特に、データベースアプリケーションまたは情報検索システムプログラムである。

【0065】

本発明の第４６の実施形態は、１つ以上のプロセッサおよびメモリを含むデータ処理デバイスまたはシステムであり、データ処理デバイスまたはシステムは、第１～第４４の実施形態のいずれか１つの方法を実行するように構成されている。

【0066】

本発明の第４７の実施形態は、第４５の実施形態のコンピュータプログラムをその上に格納した、好ましくは非一時的コンピュータ可読媒体である。

【図面の簡単な説明】

【0067】

【図1A】複数のバージョンを格納するための異なるバージョンの格納スキームを例示する。

【図1B】インデックスがオブジェクトを参照する方法の２つの一般的なアプローチを示す。

【図2】先行技術による論理的ポインタアプローチを例示する。

【図3a-3b】先行技術に従ってバージョンストレージガベージコレクションがどのように達成され得るかの基本原理を示す。

【図4】トライのコピーオンライトアプローチを、２つの異なるトライルートノードを有する２つのトライを示す例で例示する。

【図5】本発明による２次インデックスの論理ポインタおよびコピーオンライトアプローチを実装する一実施形態を例示する。

【図6】先行技術によるｇｌｉｂｃ－ｍａｌｌｏｃの例を示す。

【図7】本発明によるトライメモリ管理を示す。

【図8】本発明による複数のアレイのガベージコレクションを効率的に行うための一実施形態を例示する。

【図9】図８による複数のアレイのガベージコレクションの一例を例示する。

【発明を実施するための形態】

【0068】

ＭＶＣＣをサポートするには、データベースは、各オブジェクトの複数のバージョンを維持する必要がある。

【0069】

図２は、特定のオブジェクトＩＤおよび特定のバージョンのポインタがストレージ内のオブジェクトの物理的な場所にマッピングされる、先行技術による論理ポインタアプローチを示す。

【0070】

図２に示される実施形態では、オブジェクト２０６、２０９は、１つ以上のファイルおよび／または永続メモリであり得る永続ストレージ２０２に格納される。オブジェクトを格納するために、ログ構造化ストレージの概念が適用される。これは、ストレージ２０２の最後に使用された位置２１０の後に新しいオブジェクトが付加されることを意味する。

【0071】

すべてのオブジェクトは、主キーまたはＩＤによって識別され、例えば、リレーショナルデータベースまたはドキュメント指向データベースの場合はレコードＩＤまたはドキュメントＩＤである。ＩＤから物理的な場所へのマップ（インデックス）は、所与のＩＤについて、ストレージ２０２内のオブジェクトの物理的位置を導出するために使用される。本明細書全体にわたって、インデックスは、キー／値のペアとして定義されている。

【0072】

図２の実施形態では、オブジェクトは、トランザクションによって変更することができる。トランザクションでオブジェクトを変更する場合、オブジェクトのコピーが作成され、コピーされたオブジェクトに対して補正が実行される。元のオブジェクトは、補正または上書きされない。

【0073】

オブジェクトを変更または作成するすべてのトランザクションは、作成または変更されたオブジェクトの新しいバージョン、およびストレージ２０２内のオブジェクトの物理的位置を導出するためのＩＤから物理的な場所へのマップの新しいバージョンを作成する。

【0074】

図２に示されるように、オブジェクトＩＤ「１」を有する第１のオブジェクト２０６、および、同じくオブジェクトＩＤ「１」を有する第２のオブジェクト２０９が存在する。第１のオブジェクトは、第１のバージョンであり、第２のオブジェクトは、オブジェクトの第２のバージョンである。上で言及されるように、オブジェクトが変更されると、オブジェクトのコピーが作成され、オブジェクトのコピーが変更される。したがって、ストレージ２０２は、オブジェクトの２つのバージョンを含む。

【0075】

また、このような変更は、ＩＤから物理的な場所へのマップの２つのバージョン、すなわち、２０４および２０８をもたらす。オブジェクトＩＤ「１」を有するオブジェクトの第１のバージョン「バージョン１」のルックアップは、マップ２０４を指すポインタ２０３を使用することによって実現することができ、これは、オブジェクトの第１のバージョンの格納位置２０５につながる。同じオブジェクトＩＤの、しかし第２のバージョン「バージョン２」のルックアップは、オブジェクト２０９の第２のバージョンの格納位置につながる後のまたはより新しいトランザクションに対応するマップ２０８を指すポインタ２０７を使用することによって実現することができる。

【0076】

対応するスナップショットビュー（ポインタ２０３によって参照されるバージョン）および対応するオブジェクトバージョンを使用して保留中のトランザクションがある限り、マップ２０４が依然としてアクセス可能であることが重要である。

【0077】

図３ａおよび図３ｂは、先行技術に従ってバージョンストレージガベージコレクションがどのように達成され得るかの基本原理を示す。

【0078】

図３ａおよび図３ｂの例では、すべてのファイルは、所定のファイル長またはサイズに制限されている。新しいデータの付加中にファイルの長さに達した場合、書き込むべき新しい「アクティブな」ファイルが作成され、古いファイルはもはや変更されなくなる。

【0079】

図３ａは、ガベージコレクションの開始状況を示す。このような例は、異なるオブジェクトを有する２つのファイル、ファイル１およびファイル２を含み得、ファイル１はその長さ制限に達し、ファイル２は付加するためのスペースを依然として有し、したがって、アクティブファイルである。ファイル１は、異なるオブジェクトＩＤを有する３つのオブジェクトを格納している。オブジェクトＩＤ１を有するオブジェクトは、２つのバージョン（ｖ１およびｖ２）、およびしたがって、２つのオブジェクトをファイルに格納する。オブジェクトＩＤ２を有するオブジェクトは、第１のバージョン（ｖ１）、およびオブジェクトがファイルから削除されたことを示すトゥームストーンを格納する。ファイル２は、オブジェクトＩＤ３を有する最新バージョンのオブジェクトを含む。オブジェクトの現在のバージョンは、「ＩＤ ｔｏ ｐｏｓ ｍａｐ ｔ１」によって参照される。「ｔ１」は、トランザクションｉｄ １を有するトランザクションのマップであることを示す。

【0080】

図３ｂは、バージョンストレージのガベージコレクションが原則としてどのように機能するかを示す。コピーガベージコレクション方法（エビクション）が適用される。第１のステップは、ファイル１を「クリーン」にすることであり、これは、ファイルが現在のバージョンのオブジェクトを含む場合、それらは現在のマップ「ＩＤ ｔｏ ｐｏｓ ｍａｐ ｔ１」によって依然として使用され、参照され、アクティブファイルに転送される必要がある。したがって、ファイルがスキャンされ、例えばオブジェクトＩＤを使用することによるルックアップが、オブジェクトの最新バージョンの物理的位置を含む現在のＩＤから物理的な場所へのマップ「ＩＤ ｔｏ ｐｏｓ ｍａｐ ｔ１」で実行される。

【0081】

ルックアップから取得されたこの場所がファイルスキャンから導出された位置と依然として同じである場合、オブジェクトは、アクティブなファイル、すなわち、ファイル２にコピー（書き込み）される。この例では、オブジェクトＩＤ１およびバージョン２のオブジェクトを、ファイル１からファイル２にコピーする必要がある。マップが同じＩＤを有するが新しいバージョンのオブジェクトを含むため、オブジェクトＩＤ１およびバージョン１のオブジェクトは無視できる。したがって、スキャンから取得された場所は、ファイルスキャンの場所とは異なる。また、オブジェクトＩＤ２およびバージョン１のオブジェクトは削除されており、マップにまったく表示されないため、無視できる。最新バージョンはファイル１にはなく、すでにアクティブファイル２にあるため、オブジェクトＩＤ３を有するオブジェクトをコピーする必要はない。

【0082】

どのオブジェクトバージョンのストアファイルがエビクション（本出願ではガベージコレクションとも呼ばれる）に好適な候補であるかを知るために、各ファイルの統計が維持される。このような統計は、新しいバージョンに置き換えられた、または削除されたオブジェクトの量およびサイズを含み得る。ファイルが、一定量未満の依然として現在のオブジェクトバージョンを含む場合、それは、ガベージコレクションの対象になり、これは、対応するメモリが解放されるメモリとして識別されることを意味する。次いで、このようなメモリは、他のデータによって書き換えまたは上書きすることができる。解放するメモリがあるファイルの場合、ファイルを削除できる。ファイルを削除する前に、例えば、ファイルに格納されているバージョンからデータを読み取るなど、依然としてファイルにアクセスする必要のある保留中のトランザクションがないことを確認する必要がある。

【0083】

図３ａおよび図３ｂで説明されているモデルでは、トランザクションごとにマップの新しい変更されたコピーを作成する必要がある。このようなマップの作成は、作成に多くの追加のメモリ空間および処理時間が消費されるため、実行不可能で非効率的である。

【0084】

本発明の目的は、そのようなマップを格納するための空間および性能効率の高い永続データ構造を提供することである。永続データ構造は、変更されたときに常に以前のバージョンを保持するデータ構造である。

【0085】

このソリューションは、国際特許出願ＰＣＴ／ＥＰ２０１８／０５６５９２に記載されているトライを拡張して、スペースおよびパフォーマンスの効率的な永続データ構造として機能することで達成される。

【0086】

ツリーベースの構造は、ルートノードまでの変更ごとにツリーの部分的なコピーを作成することにより、永続データ構造として簡単に使用できる。

【0087】

図４は、トライのコピーオンライトアプローチを、２つの異なるトライルートノードを有する２つのトライを示す一例で例示する。

【0088】

変更前、トライ構造４０１は、トライルートノード４０２および４０６での２つのトライを含む。トライルートノード４０２および４０６は両方とも、２つの異なるバージョンに対応し、これは、例えば、２つの異なるトランザクション中に作成することができる。トライルードノード４０２によって参照される第１のトライは、子ノード４０３、４０４、および４０５によって符号化されるキー「００７」および「０４２」を含む。

【0089】

１つのトランザクションにおけるキー「０４２」の除去およびキー「０４５」の追加は、新しいトライルートノード４０６によって参照される第２のトライをもたらす。変更されたノードがコピーされ、変更される。ノード４０７は、ノード４０３の変更されたコピーであり、ノード４０９は、ノード４０５の変更されたコピーである。変更されていないノード４０４は、新しいノード４０７によって４０８で参照される。

【0090】

例えば、ツリーを使用する典型的な永続マップの実装は、Ｏ（ｌｏｇ ｎ）アクセス時間の複雑さを有するため、典型的には、論理ポインタの使用は、非常に高価になる。アクセス時間はマップ内のエントリの量に依存しないため、トライは、一定のＯ（１）時間の複雑さを有する。

【0091】

これまでに記載されたアプローチの発明の組み合わせに基づいて、本発明は、序論で言及された多くの問題を解決する。複数のオブジェクトバージョンを格納する方法、および読み取りアクセス（スナップショット分離）中に適切なバージョンを見つける方法に関する問題は、トランザクション全体を通じてトランザクション開始時にトライの現在のルートポインタを使用することで解決される。

【0092】

さらに、記載されたアプローチの本発明の組み合わせは、クエリが、ＭＶＣＣアウェアでもあるインデックスを使用することを可能にする。これは、オブジェクト識別子（ＩＤ）を指す２次インデックスもバージョン化されるという利点がある。この概念は、図５に関してより詳細に説明される。

【0093】

図５は、本発明による２次インデックスの論理ポインタおよびコピーオンライトアプローチを実装する一実施形態を示す。

【0094】

図５の実施形態では、２次インデックスの論理ポインタおよびコピーオンライトアプローチは、ＩＤから物理的な場所へのマップトライインデックス５０３、５０８および他の２次インデックストライ５０４、５０９を１つの結合された物理的なトライに格納することによって実現される。これは、国際特許出願ＰＣＴ／ＥＰ２０１８／０５６５９２で詳細に記載されているように、トライの複合キー機能を使用することによって達成される。

【0095】

複合キー（本出願では「検索キー」とも呼ばれる）がオブジェクト識別子（ＩＤ）であるか、データベースオブジェクトに関連する２次キーであるかに関する情報は、検索キーに含まれる。

【0096】

この結合されたトライのルートは、オブジェクトバージョンの一貫した（スナップショット）ビューを提供する。このようなオブジェクトは、データベースで維持され、データベーストランザクションによって作成および補正される場合があるため、データベースオブジェクトと呼ばれることもある。２次キーを使用してオブジェクトにアクセスするために、２次キー５０４を使用してオブジェクトＩＤ５０５を導出し、次いで、オブジェクトＩＤ５０５を使用して物理的オブジェクト位置を判定する。トランザクション内でトライルートノード５０２によって参照されるトライを変更すると、新しいトライルートノード５０７を有するトライの新しい部分コピーがもたらされ、これにより、すべてのオブジェクトバージョンおよびインデックスの一貫したビューが再び提供される。

【0097】

このアプローチは、現在のソリューションのバージョンストレージ、オブジェクトガベージコレクション、およびインデックス管理の欠点を解決する。

【0098】

上で言及されるように、先行技術に関して、検索インデックスおよび間接層（論理－物理マッピング）は、典型的に、異なるデータ構造である。一般に、このような分離された構造では、インデックスは、１つのバージョンのみを指し、これは、要求されたバージョンである場合とそうでない場合がある。インデックスによって参照されるバージョンが要求されたバージョンではない場合、要求されたバージョンを見つけるためにバージョンチェーンをトラバースする必要がある。「要求されたバージョン」は、オブジェクトを要求するトランザクションについて正しく可視であるバージョンであるため、「可視バージョン」と呼ばれることもあり得る。

【0099】

本発明は、間接層および検索インデックスを常にスナップショットの一貫性がある１つの物理的トライに結合することによって、バージョンチェーンを追加的にトラバースするという欠点を解決する。

【0100】

例を挙げると、２つのバージョン「１」および「２」を有する論理ＩＤ「１」のオブジェクトが考えられる。第１のバージョンは、物理的な場所５０６に格納され、第２のバージョンは、物理的な場所５１１に格納される。

【0101】

加えて、オブジェクトのプロパティ「名前」に検索インデックスがある場合がある。第１のオブジェクトバージョンは、名前として値「Ｐｅｔｅｒ」を含み、第２のオブジェクトバージョンは、変更された値、すなわち、名前「Ｍａｔｔ」を含む。

【0102】

複合キーの機能により、次いで、ルートノート４０２で示されるトライは、「ＩＤ－Ｍａｐ、１、５０６」および「名前、『Ｐｅｔｅｒ』、１」の２つのエントリを含む。第１のエントリは、ＩＤー物理的格納場所５０３に対応し、第２のエントリは、２次キー５０４に対応する。更新後、トライルートノード５０７によって参照されるトライは、「ＩＤ－Ｍａｐ、１、５１１」および「名前、『Ｍａｔｔ』、１」を含む。

【0103】

そのため、２次キーは、値「Ｐｅｔｅｒ」でプロパティ「名前」を検索することができ、オブジェクトＩＤ「１」を返す。次いで、オブジェクトＩＤ「１」を使用して物理的な格納場所「５０６」を見つけるために、トライがトラバースされる。したがって、間接層（論理－物理マッピング）は、トライが含む一連の検索インデックス内の別の検索インデックスにすぎない。第１のキー部分のＩＤ－Ｍａｐおよび名前は、文字列または整数（列挙）としてトライに物理的に格納される可能性があり、例えば、ＩＤ－Ｍａｐは「１」、名前は「２」である可能性があり、次のエントリ：「１、１、５０６」および「２、『Ｐｅｔｅｒ』、１」が得られることに留意されたい。例えば、「名前、『Ｐｅｔｅｒ』、年齢、３０、１」など、同じキーに複数のパラメータがあり得ることにも留意されたい。また、すでに上で言及されるように、トライは、異なる２次キーを含み得る。そのため、同じトライに含まれるキー「年齢、３０、１」も存在する可能性がある。

【0104】

上記の例は、原理の単なる例示であり、保護の範囲は、特定の値およびパラメータに限定されないことに留意されたい。

【0105】

本発明のさらなる目的は、効率的なノード割り当ておよび割り当て解除を備えた実用的で使用可能かつ効率的なマルチバージョントライを提供することであり、したがって、使われておらず二度と読み取られないバージョンがどのように削除されるかという前述の問題を解決する（ガベージコレクション）。

【0106】

先行技術は、ノードの割り当ておよび割り当て解除を効率的に実行する方法について言及していない。先行技術は、一般に割り当ておよび割り当て解除を実行し得る方法も、複数のバージョンをサポートしながら使われていないノードおよびそれらの物理的スペースのガベージコレクションを実行し得る方法も開示していない。

【0107】

上記のように、トライのコピーオンライトアプローチは、メモリ需要の増加につながる。したがって、使われていないノードを破棄し、トライ内のスペースを再利用するためのソリューションが必要である。

【0108】

国際特許出願ＰＣＴ／ＥＰ２０１８／０５６５９２にも開示されているように、第１の態様は、ノードをメモリに個別に割り当てるのではなく、ノードをアレイに格納することである（図７も参照）。ノードは、ノードのメモリポインタを使用する代わりに、長整数のアレイに格納され得る。このような例では、現在のノードをこのアレイへのインデックスによって指定され得る。子ポインタは、アレイ内のノード位置のインデックスであり得る。トライをトラバースするとき、現在のノードインデックスに基づいて子ノードのインデックスを見つけるためのオフセットは、次いで、現在のノードが占めるスペースに基づいて判定され得る。子ノードは、現在のノードの後に続く場合があり、したがって、アレイ内の現在のノードの隣（または後ろ）に格納され得る。国際特許出願ＰＣＴ／ＥＰ２０１８／０５６５９２に記載されているノード構造に関して、アレイ内の子ノードの位置は、ターゲット位置の前のビットマップに設定された最下位ビットの量にビットマップの１を加えた量であり得る。

【0109】

好ましい実施形態は、いくつかのそのようなアレイで機能する（図８も参照）。このような場合、ノードへのポインタは、２つの部分を含み得る。第１の部分、例えば、ポインタの下部は、アレイ内のインデックスであり得、ポインタの第２の部分、例えば、上部は、アレイへの参照である。任意の大きいサイズのアレイを常に割り当てることができるとは限らないため、メモリ管理上の理由から、複数のアレイを使用する必要がある場合がある。例えば、Ｊａｖａでは、アレイのサイズは、３２ビット整数に制限されており、２^３１（正の値のみ）＝２，１４７，４８３，６４８エントリのアレイサイズになる。しかしながら、実世界のアプリケーションの多くは、さらに多くのエントリを含むアレイを必要とする。

【0110】

当技術分野で知られているような古典的なメモリ割り当ておよび割り当て解除方法は、複数のバージョンを考慮しない。これは、アプリケーションのアドレス空間で割り当てられたメモリを管理するためのよく知られたライブラリであるｇｌｉｂｃ－ｍａｌｌｏｃの例で例示されており、これについては、図６で簡単に説明する。

【0111】

図６は、先行技術によるｇｌｉｂｃ－ｍａｌｌｏｃの例を示す。ｇｌｉｂｃ－ｍａｌｌｏｃでは、メモリは、「ヒープ」５０１と呼ばれるメモリのより大きい領域からチャンクに分割される。未使用の（空いている／利用可能な）チャンクは、チェーンにリンクされる。アプリケーションに一定量のメモリを割り当てるには、好適な未使用のチャンクを見つける必要がある。要求されたサイズの空きチャンクが利用できない場合、より大きい空きチャンクが選択されて部分に分割され、いわゆるメモリの断片化が発生する。したがって、目的は、好適なサイズの未使用のチャンクを見つけることである。

【0112】

チェーンリストが１つしかない場合、好適なサイズのチャンクを見つけるのは費用がかかる。したがって、特定のサイズ（サイズａの場合は６０３、６０４、サイズｂの場合は６０５）のチャンクをチェーンするビン（空きリストビン）６０２がある。一例として、チャンク６０５が割り当て要求に対して正しいサイズｂである場合、チャンクは、空きリストチェーンからリンク解除され、利用可能なペイロード６０７へのポインタ６０６が返される。ポインタ６０６は、アプリケーションに返されるメモリポインタであるが、チャンクは、サイズおよび他のメモリ管理情報を含むヘッダを依然として有している。例えば、チャンクは、チャンクが空いているか使用されているかを示すフラグを有する場合がある。

【0113】

アプリケーションによって割り当て解除されると、チャンクは、未使用のチャンクの適切なチェーンに返される。断片化を低減するために、いわゆる合体が行われ、これは、隣接するチャンクがより大きいチャンクに結合されることを意味する。

【0114】

図７は、本発明によるトライメモリ管理を示す。

【0115】

トライメモリ管理を実装するとき、次の側面を考慮する必要がある。トランザクション中にトライを更新することは、新しいノードにスペースを割り当てるか、コピーオンライト戦略の一部として、既存のノードをコピーし、変更する必要がある。保留中のトランザクションがノードにアクセスできる必要が依然としてあるため、既存のノードのメモリ空間をすぐに再利用することはできない。

【0116】

上で言及されるように、かつ国際特許出願に記載されているように、ＰＣＴ／ＥＰ２０１８／０５６５９２ノードは、複数のアレイに保持され得る。図７に示される実施形態は、単一のアレイ７０１に基づくトライメモリ管理を例示する。

【0117】

図７に示される実施形態では、トライの各ノードは、それぞれのチャンク７０３、７０５、７０６、および７０７に格納され得る。空きではなく、したがって、ノードを含む各チャンクは、ノード７０６を含むペイロード値と、それが作成される間にトランザクションを識別する値と、を含む（図７のトランザクションＩＤを参照）。

【0118】

トライノードにスペースを割り当てるために、空きリストビン（「空きチャンクリスト」とも呼ばれる）７０２が最初にチェックされる。トライには、異なるサイズを有する異なるノードが格納されている場合がある。異なるノードの例は、国際特許出願ＰＣＴ／ＥＰ２０１８／０５６５９２に詳細に記載されている。そのような例は、対応するビットマップおよびポインタを有する通常のノード、連結された最適化ノード、または端末の最適化ノードを含み得る。

【0119】

空きリストビン６０２に要求されたサイズの空きチャンクがない場合、ビンは、倍のサイズの空きチャンクについてチェックされる。ダブルサイズのチャンクが見つかった場合、ダブルサイズの空きチャンクは、２つのチャンクに分割される。

【0120】

通常のノードは、１～６４個の子ノードを有するので、対応するサイズを有する６４のビン（６４の異なるチャンクサイズ）を有することが好適かつ効率的なアプローチであることを、実証テストが示した。アレイは、連続的に満たされ、空きポインタ７０８は、さらにチャンクを割り当てるための次に利用可能な空き空間を指す。したがって、空きチャンクが空きリストビン（「空きチャンクリスト」）７０２を介して利用できない場合、割り当ては、空きポインタ７０８によって示される位置でそれぞれのノードに新しいチャンクを付加する。

【0121】

本発明の好ましい実施形態では、アレイは、（この場合もバージョンストレージとして）メモリマップトファイルを使用して耐久性のある形で格納される。これを実現するには、アレイを定期的にファイルに書き込む必要がある。トライへのすべての変更が永続ストレージにすぐに書き込まれる場合、パフォーマンスが大幅に低下することになる。しかしながら、システムクラッシュは、各変更後にトライが格納されないため、一貫性のない状態になる。一貫性のない状態を回避するために、次のクラッシュリカバリプロセスが適用される。最後に保存された状態のトライおよび先行書き込みログとして機能するオブジェクトストアが読み取られ、オブジェクトストアに存在するすべての変更が、最後に永続化されたバージョンのトライに適用される。

【0122】

ＰＣＴ／ＥＰ２０１８／０５６５９２で説明されているデータ構造およびアルゴリズムは、ペイロード７０９へのインデックスポインタを使用し、チャンクサイズおよびトランザクション情報を維持するチャンク７０７のヘッダ情報を認識しないことに留意されたい。

【0123】

上で言及されるように、本発明の目的は、効率的なノード割り当ておよび割り当て解除を備えた実用的で使用可能かつ効率的なマルチバージョントライを提供することである。しかしながら、ｇｌｉｂｃ－ｍａｌｌｏｃなど、当技術分野で知られている割り当ておよび割り当て解除の技術は、オブジェクトの異なるバージョンを考慮しないため、ノードを含むチャンクの割り当てを解除できるかどうかにかかわらず、トランザクション情報に基づいて判定しない場合がある。

【0124】

トランザクション中に、次のトライ操作が発生する可能性がある。

【0125】

新しいトライノードが作成され得る。
この場合、新しいノードに必要なサイズのチャンクが選択され得、ノードは、このチャンクに格納される。新しいノードを収容するために選択されたチャンクは、空きチャンクのリスト（空きリストビン）７０２から削除される。上で言及されるように、必要なサイズの空きチャンクが利用できない場合、最初に新しいチャンクを割り当てる必要がある。各チャンクは、ヘッダ情報、例えば、そのサイズ、他のチャンクへのポインタ、およびノードをチャンクに格納することによってチャンクを補正したトランザクション識別子を含む。したがって、ノードをチャンクに挿入するとき、ノードをチャンクに格納したトランザクション識別子を更新する必要がある。

【0126】

以前のトランザクションによって作成されたトライノードが更新される。

【0127】

この場合、ノードのコピーが作成され、そのコピーが変更される可能性がある。特に、新しいチャンクが作成され得、ペイロード値が変更されたノードを含むように適合される。また、チャンクのトランザクションを識別する値（トランザクションＩＤ）は、チャンクを作成したトランザクション識別子に設定される。

【0128】

しかしながら、特定の「置き換えられたノード」へのアクセスを依然として必要とする保留中のトランザクションが存在する可能性があるため、「置き換えられた」ノードはすぐには削除されない場合がある。しかしながら、「置き換えられたノード」が占有するメモリをできるだけ早く再利用できるようにするために、ノードを必要とするトランザクションが残っていない場合はすぐにノードの割り当てを解除するものとする。

【0129】

「置き換えられたノード」を含むそのようなチャンクを識別および監視するために、チャンクは、保留中の空きチャンクリスト７０３（「保留中の空きリスト」とも呼ばれる）に追加され得る。例えば、保留中の空きチャンクリスト７０３は、異なるエントリを有することができ、各エントリは、特定のトランザクションに関連付けられ、特定のトランザクション中に置き換えられたノードを含むチャンクを参照する。例えば、エントリは、そのエントリのトランザクションによって置き換えられたノードを含むチャンクのチェーンを指す参照を有し得る。チェーンは、リンクリストによって実現され得、エントリは、リストの第１のチャンクを指し、各チャンクは、リストの次のチャンクを指す（チャンク７０６の「次のチャンク」を参照）。一実施形態では、図７にも示されているように、チャンクが保留中の空きチャンクリスト７０３に追加されると、トランザクションＩＤフィールドは、次のチャンクへのポインタによって置き換えられる。

【0130】

保留中の空きチャンクリスト７０３内にチャンクを保持することにより、ペイロード（ノード）は、ＭＶＣＣ要件に従って保留中のトランザクションをサポートするための有効な情報を依然として含むので、「置き換えられたノード」を有するチャンクのペイロードにアクセスすることが依然として可能であり、同時に、近い将来に割り当てを解除する必要があるノードを追跡する。

【0131】

置き換えられたノードが保留中のトランザクションによってもはや不要になった場合、ノードを含むチャンクは、保留中の空きチャンクリスト７０３から空きチャンクリスト７０２（「空きリストビン」とも呼ばれる）に移動され、したがって、新しいノードに対応するために再利用できる空きチャンクとして（または解放される未使用のメモリとして）識別される。

【0132】

好ましい実施形態では、ノードが保留中のトランザクションによって依然として必要であるかどうかのそのような判定は、ノードごとに個別に実行されるのではなく、特定のトランザクションで置き換えられたすべてのノードに対して実行される。詳細には、このような判定は、保留中のトランザクション識別子を、ノードを置き換えた特定のトランザクションの識別子と比較することによって実現され得る。このような比較では、保留中のトランザクション識別子が使用可能であり、メモリ管理システムがアクセスできる必要がある。例えば、保留中のトランザクション識別子は、保留中のトランザクションリストに格納され得る。次いで、保留中のトランザクションリストが特定のトランザクションよりも古いトランザクションを含むかどうかを判定することによって、比較が達成され得る。古いトランザクションが保留中のトランザクションリストに含まれているかどうかの判定は、例えば、単調に増加するトランザクション識別子、すなわち、古いトランザクションよりも高い識別子番号を有する新しいトランザクションを使用することによって達成され得る。したがって、保留中のトランザクションリストは、ノードを置き換えた特定のトランザクションのトランザクション識別子よりも低いトランザクション識別子を有するトランザクションを含まないと判定され得る。保留中のトランザクションがこれ以上ないと判定される場合、特定のトランザクションに関連付けられた（または参照された）すべてのチャンクは、保留中の空きチャンクリスト７０３から空きチャンクリスト６０２に移動される。対応するチャンクは、それぞれのサイズに従って、空きチャンクリスト７０２に付加される（チャンクが、図７に示されるように、リンクリストに編成されるとき）。

【0133】

同じトランザクションによって作成されたトライノードが更新される。
この場合、補正されたノードのサイズが元のノードと同じである場合、ノードは上書きされ得るか、または新しいノードが作成され、他のトランザクションはそれにアクセスできないので、置き換えられたノードはすぐに空きチャンクリスト７０２に戻され得る。このケースは、更新するノードを含むチャンクのトランザクションＩＤを、それを更新するトランザクションのＩＤと比較することで検出され得る。両方のＩＤが同じである場合、同じトランザクションがノードを作成したと判定される。

【0134】

チャンクの割り当てを解除するとき、チャンクは、それらのサイズに従って、空きチャンクリスト７０２に分配される。空きチャンクリスト７０２が特定のチャンクのサイズのエントリ（ビン）を有していない場合、チャンクのサイズを補正する必要があり得る。チャンクが使用可能なサイズよりも大きい場合、チャンクは小さいチャンクに分割される。チャンクが使用可能なサイズよりも小さい場合、チャンクは隣接するチャンクと結合される。隣接するチャンクと結合するとき（合体とも呼ばれる）、隣接するチャンクのチャンクフラグが評価されて、チャンクが未使用であり、結合に利用可能であることが確認される。

【0135】

図７に示される実施形態は、単一のアレイまたはエポック内のメモリ管理についてのみ説明している。しかしながら、上で言及されるように、プログラミング言語のアレイのサイズは通常制限されている。したがって、複数のアレイおよびアレイファイル（エポック）のガベージコレクションを効率的に実行するためのソリューションが必要である。

【0136】

図８は、本発明による複数のアレイのガベージコレクションを効率的に行うための一実施形態を例示する。
図８は、異なるトライからのノードを含む複数のアレイを示す。複数のアレイは、アレイのサイズが制限されているという事実から生じる。したがって、追加のノードを格納する必要がある場合、新しいアレイを作成する必要がある。このような新しいアレイは、新しい「エポック」とも呼ばれる。新しいアレイが作成されると、このアレイはアクティブアレイになり、トライの新しいノードおよび変更されたノードを格納するために使用される。したがって、図７に関して上で言及されるリスト、空きチャンクリスト７０２、および保留中の空きチャンクリスト７０３が、アクティブアレイに対して維持される。

【0137】

アクティブアレイ以外のアレイは、閉じていると見なされ、もはや補正されなくなる。トランザクション中にノードが変更または追加された場合、これらのノードのコピーがアクティブアレイに格納される。

【0138】

図８に示されるように、トライノードを保持するアクティブアレイに加えて、いくつかのアレイがある。各トライノードは、現在のトランザクションに対応する現在のトライルートノードおよび／または以前のトランザクションに対応する１つ以上の以前のトライルートノードに関連付けられている。図８には、「古いルート」および「現在のルート」の２つのトライルートノードがある。

【0139】

データベースインデックスを含む１つ以上のトライのトライノードによって占有されている、解放される未使用のメモリを識別するために、ガベージコレクションされるアレイをエビクショントランザクションで判定する必要がある。このような判定は、１つ以上の基準に基づき得る。基準は、事前に定義されているか、または実行時に適合され得る。１つ以上の基準は、現在アレイを使用しているトランザクションの数、および／またはアレイに含まれる１つ以上の以前のトライのノードの数を含み得る。バージョンストアファイルと同様に、ガベージコレクションの対象となるトライアレイを表す候補ファイルも、そのファイル内の置き換えられたノードの量およびサイズを追跡することによって判定され得る。

【0140】

アレイの１つが基準を満たしていると判定された場合、前記アレイが選択される。次のステップでは、選択されたアレイが、現在のトライルートノードに関連付けられている（したがって、依然として使用されている）１つ以上のノードを含んでいるかどうかを判定する必要がある。選択されたアレイがこのようなノードを含む場合、ノードを保持するために、ノードをアクティブアレイにコピーする必要がある。

【0141】

現在のトライルートノードに関連付けられている選択されたアレイの１つ以上のノードをアクティブアレイにコピーすることが、現在のトライルートノードに関連付けられているノードをトラバースすることと、ノードをトラバースしている間、選択されたアレイに格納されているノードをコピーし、選択されたアレイに格納されていないノードを無視することと、を含む。

【0142】

ノードをコピーする必要があるかどうかの判定を加速するために、選択されたアレイの前に作成されたアレイに格納されているノードの子ノードは無視され、したがって、トラバースされない。ノードは、同じアレイ内、または、前のアレイへのノードのみを指すことができ、後で割り当てられたアレイへのノードを指すことはできないことに留意されたい。したがって、選択されたアレイの前に作成されたアレイからのノードは、選択されたアレイを指すことができない。これらのブランチを回避すると、評価する必要のあるノードが少なくなるため（選択されたアレイに配置されているかどうかに関係なく）、パフォーマンスが向上する。

【0143】

また、現在のトライルートノードに関連付けられているノードをトラバースしながら、選択されたアレイがアクティブアレイになった後に作成された以前のトライルートノードに関連付けられているノードを同時にトラバースし、現在のトライルートノードに関連付けられているノードを、以前のトライルートノードに関連付けられているノードと上から下へレベルごとに比較することができる。ノードが現在のトライルートノードには関連付けられているが、以前のトライルートノードには関連付けられていないことが比較によって判定される場合、前記ノードおよび前記ノードの子ノードをトラバースしない。これらのノードを回避すると、現在のアレイと選択されたアレイとの間にあるアレイ（図８の「アレイからＧＣ」）に格納されているノードを回避できるため、トラバースされるノードの数が大幅に低減し得る。

【0144】

好ましい実施形態では、比較を実行するために選択される以前のトライルートノードは、選択されたアレイがアクティブアレイになった後に作成された最初のトライルートノードであってもよく、これは、選択されたアレイが閉じられ、もはや補正されないことを意味する。この切り替えの直後に作成されたトライルートノードは、選択されたアレイと現在／アクティブアレイとの間にほとんどのノードが作成されないようにするため、最良の開始点と見なされ得る。

【0145】

現在のトライルートノードに関連付けられているノードの、以前のトライルートノードに関連付けられているノードとの上から下へレベルごとの前述の比較は、ノードの子ノードへの参照を比較することを含む。そのような参照は、国際特許出願ＰＣＴ／ＥＰ２０１８／０５６５９２に詳細に記載されているように、ビットマップおよびポインタを含み得る。好ましい実施形態では、ビットマップは、ビットワイゼのＡＮＤ演算子で比較される。

【0146】

ノードのコピー後、選択されたアレイが占有しているメモリは、解放される未使用のメモリとして識別され得る。

【0147】

しかしながら、選択されたアレイ内のノードへのアクセスを依然として必要とする保留中のトランザクションがある場合、解放される未使用メモリとしての識別は、保留中のすべてのトランザクションが終了した後にのみ発生する。エビクション（ガベージコレクション）自体は、トランザクション内で実行される。以前に開始されたすべてのトランザクションが終了するまで、選択されたアレイを保持する必要がある。保留中のトランザクションが終了するかどうかの判定が、保留中のトランザクションを、エビクショントランザクションと比較することによって実行され得、保留中のトランザクションがエビクショントランザクションより古いトランザクションを含まないと判定される場合、保留中のトランザクションが終了すると判定する。言い換えると、アレイを破棄できるエビクション（ガベージコレクション）のトランザクション識別子よりも小さいトランザクション識別子を有する保留中のトランザクションは、これ以上存在しない。

【0148】

アレイが耐久性のあるストレージ（例えば、ファイル）に格納されている場合、現在のアレイおよびガベージコレクショントランザクション後の新しいルートポインタが耐久性のあるストレージに確実にフラッシュされた場合にのみ、耐久性のあるストレージを破棄することができる。パフォーマンス上の理由から、フラッシュは、個々のトランザクションごとに実行されないことに留意されたい。

【0149】

図９は、図８による複数のアレイのガベージコレクションの一例を例示する。好ましい実施形態では、トライは、３２変数、６４変数である。したがって、子ノードへのポインタを参照するビットマップは、３２ビットまたは６４ビットを含み得る。簡単にするために、図９は、４変数トライを示す。

【0150】

図９の例は、３つのトライルートノード９０１、９０２、および９０３を含む。トライルートノード９０１は、トライの第１のバージョンへのルートであり、ルートノードは、ガベージコレクションの対象となる「アレイ２」にある（「アレイ２」は「選択されたアレイ」である）。トライルートノード９０２は、現在の（アクティブな）アレイとして「アレイ２」から「アレイ３」に切り替えた後に発生する第１のトランザクションから生じるトライの何らかの後の第２のバージョンへのルートノードである。トライルートノード９０３は、トライの現在のルートである。

【0151】

「アレイ２」のエビクションのために、トライルートノード９０２および９０３から始まるトライノードが比較される。上で言及されるように、図８に関して、比較は、ノードのビットマップのビット単位のＡＮＤによって（レベルごとおよび上から下へ）実行され得る。

【0152】

第１のステップでは、ビットマップ９０４および９０５がビット単位のＡＮＤ演算を使用して比較される。比較の結果、ノード９０７（キー「２」）は現在のトライにもはや存在せず、エビクト（現在のアレイにコピー）する必要がないことがわかる。

【0153】

次のステップでは、ノード９１２および９１３の次のレベル９１０、９１１上のビットマップが比較され、キー「０１２」の一部であるノード９０６が両方のトライに存在するが、「アレイ２」の前のアレイ（「アレイ１」）内に格納されていると判定される。したがって、「アレイ１」はガベージコレクションの対象ではないため、ノードはトラバース（無視）されず、現在のアレイにコピーする必要はない。ノードおよびその子ノードは、選択されたアレイの前に格納されているアレイにあるため無視できるかどうかを評価するために、ビットマップの比較は必要ない。この評価は、例えば、１つのトライのみがトラバースされる場合にも実行できる。上で言及されるように、ノードは、２つの部分を有するポインタによって参照され得、第１の部分は、すべてのアレイのリスト内のインデックスを使用してアレイを指し、第２の部分は、その特定のアレイ内のインデックスを保持する。したがって、ノードが選択されたアレイまたは以前のアレイに格納されているかどうかの評価は、ポインタの第１の部分を評価することによって実行されてもよい。

【0154】

さらに、同じビットマップ９１０、９１１を比較することによって、キープレフィックス「０３」がトライルートノード９０２によって参照されるトライに存在しないので、ノード９１４へのパスはたどられない。

【0155】

さらに、同じビットマップ９１０、９１１を比較することにより、キー「０２３」の一部であるノード９０８および９０９は、現在のトライから依然として到達可能であり、したがって、現在のアレイにエビクトされる（コピーされる）必要があることが明らかになる。

【図1A】

【図1B】

【図2】

【図3a】

【図3b】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】