JP6777673B2 - インプレーススナップショット - Google Patents

Description

ソフトウェアスタックの多様な構成要素の分散は、いくつかの場合、（例えば複製によって）フォルトトレランス、より高い耐久性、及び（例えば、より少ない大型の高価な構成要素よりむしろ、多くのより小型でより安価な構成要素を使用することにより）より安価な解決策を提供する（または支援する）ことができる。ただし、データベースは、従来、分散の影響を最も受けにくいソフトウェアスタックの構成要素の中にある。例えば、データベースが提供すると期待されているいわゆるＡＣＩＤプロパティ（例えば、原子性、一貫性、独立性、及び永続性）を保証しつつもデータベースを分散することは困難であることがある。

大部分の既存のリレーショナルデータベースは分散化されていないが、いくつかの既存のデータベースは、２つの共通モデル、つまり「シェアードナッシング」モデル及び「シェアードディスク」モデルの内の１つを使用して（より大型のモノリシックシステムを単に利用することによって「スケールアップ」されることと対照的に）「スケールアウト」される。一般的に、「シェアードナッシング」モデルでは、受信されたクエリーは（それぞれがクエリーの構成要素を含む）データベースシャードに分解され、これらのシャードはクエリー処理のために異なる計算ノードに送られ、結果は、結果が返される前に収集され、統合される。一般的に「シェアードディスク」モデルでは、クラスタのあらゆる計算ノードは同じ基礎的データにアクセスできる。このモデルを利用するシステムでは、キャッシュコヒーレンシーを管理するために細心の注意を払う必要がある。これらのモデルの両方において、大型のモノリシックデータベースは（スタンドアロンデータベースインスタンスの機能性のすべてを含んだ）複数のノードで複製され、それらを縫い合わせるために「グルー」ロジックが追加される。例えば、「シェアードナッシング」モデルでは、グルーロジックは、クエリーを再分割し、クエリーを複数の計算ノードに送信し、次いで結果を結合するディスパッチャーの機能性を提供してよい。「シェアードディスク」モデルでは、グルーロジックが（例えば、キャッシング層でコヒーレンシーを管理するために）複数のノードのキャッシュをともに融合させるのに役立ってよい。これらの「シェアードナッシング」データベースシステム及び「シェアードディスク」データベースシステムは配備するのが高価であり、維持するのが複雑であり、多くのデータベース使用ケースにサービスを提供しすぎる（ｏｖｅｒ−ｓｅｒｖｅ）ことがある。

実施形態は、いくつかの実施形態及び例示的な図面について一例として本明細書に説明されているが、当業者は実施形態が説明されている実施形態または図面に制限されないことを認識する。図面及び図面に対する詳細な説明は、開示されている特定の形式に実施形態を制限することを目的とするのではなく、逆に、添付の特許請求の範囲によって定められる精神及び範囲に入るすべての修正形態、同等物、及び変更形態を対象とすることを目的とすることが理解されるべきである。本明細書に使用される見出しは編成のためだけであり、明細書または特許請求項の範囲を制限するために使用されることを意図していない。本願を通して使用されるように、単語「してよい」は、強制の意味（つまり、しなければならないを意味する）よりむしろ、許可の意味（つまり、する可能性を有することを意味する）で使用される。同様に、単語「含む」、「含んだ」、及び「含む」はオープンエンド関係を示すため、含むが、これに限定されるものではないことを意味する。同様に、単語「有する」、「有している」、及び「有する」もオープンエンド関係を示すため、有するが、これに限定されるものではない。本明細書で使用される用語「第1の」、「第２の」、「第３の」等は、それらが前に来る名詞に対するラベルとして使用され、いかなるタイプの順序付け（例えば、空間的、時間的、論理的等）も、係る順序付けがはっきりと特記されない限り暗示しない。

多様な構成要素は、１つまたは複数のタスクを実行する「ように構成される」として説明されてよい。係る文脈では、「ように構成される」は、動作中に１つまたは複数のタスクを実行する「構造を有する」を概して意味する大まかな記述である。したがって、構成要素は、現在そのタスクを実行していなくてもタスクを実行するように構成できる（例えば、コンピュータシステムは、動作が現在実行されていなくても動作を実行するように構成されてよい）。いくつかの文脈では、「ように構成される」は、動作中に１つまたは複数のタスクを実行する「回路網を有する」を概して意味する構造の大まかな記述であってよい。したがって、構成要素は、構成要素が現在オンでなくてもタスクを実行するように構成できる。一般的に、「ように構成される」に対応する構造を形成する回路網はハードウェア回路を含んでよい。

多様な構成要素は、説明での便宜上、１つまたは複数のタスクを実行すると記述されてよい。係る説明は、言い回し「ように構成される」を含んでいるとして解釈されるべきである。１つ以上のタスクを実行するように構成される構成要素を記述することは、特許法第１１２条、第６項、その構成要素に対する解釈を行使することを明白に目的としていない。

「に基づく」。本明細書に使用されるように、この用語は、決定に影響を及ぼす１つまたは複数の要因を説明するために使用される。この用語は、決定に影響を及ぼすことがある追加の要因を除外しない。すなわち、決定は、それらの要因だけに基づいてよい、または少なくとも部分的にそれらの要因に基づいてよい。言い回し「Ｂに基ついてＡを決定する」を考える。ＢがＡの決定に影響を及ぼす要因であることがある一方、係る言い回しは、Ａの決定がＣにも基づいていることを除外しない。他の例では、ＡはＢだけに基づいて決定されてよい。

本開示の範囲は、本明細書に（明示的または暗示的のどちらかで）開示される任意の特徴または特徴の組合せまたはその任意の一般論を、それが本明細書で扱われる課題のいずれかまたはすべてを軽減するか否かに関わらず含む。したがって、特徴の係る任意の組合せに対して、本願（または本単に対する優先権を主張する出願）の手続き処理中に新しい特許請求の範囲が策定されることがある。特に、添付特許請求項に関して、従属請求項からの特徴は独立請求項の特徴と組み合されてよく、それぞれの独立請求項からの特徴は任意の適切な方法で、及び単に添付の特許請求の範囲に列挙される特定の組合せでではなく、組み合されてよい。

一実施形態に係るデータベースソフトウェアスタックの多様な構成要素を示すブロック図である。 いくつかの実施形態に従って、ウェブサービスベースのデータベースサービスを実装するように構成されてよいサービスシステムアーキテクチャを示すブロック図である。 一実施形態に係る、データベースエンジン、及び別個の分散型データベースストレージサービスを含むデータベースシステムの多様な構成要素を示すブロック図である。 一実施形態に係る、分散型データベース最適化ストレージシステムを示すブロック図である。 一実施形態に係る、データベースシステムでの別個の分散型データベース最適化ストレージシステムの使用を示すブロック図である。 一実施形態に係る、分散型データベース最適化ストレージシステムの所与のノードにデータ及びメタデータがどのように記憶されてよいのかを示すブロック図である。 一実施形態に係る、データベースボリュームの例の構成を示すブロック図である。 ウェブサービスベースのデータベースサービスでスナップショットを作成する及び／または使用するための方法の一実施形態を示す流れ図である。 ウェブサービスベースのデータベースサービスでログレコードを操作するための方法の一実施形態を示す流れ図である。 多様な実施形態に従って、データベースエンジン、及び別個の分散型データベースストレージサービスを含むデータベースシステムの少なくとも一部を実装するように構成されるコンピュータシステムを示すブロック図である。

スナップショット生成の多様な実施形態が開示される。本実施形態の内の多様な実施形態は、複数のログレコードを維持するデータベースサービスの分散型ストレージシステムを含んでよい。ログレコードは、データベースサービスによって記憶されるデータに対するそれぞれの変更と関連付けられてよい。本実施形態の内の多様な実施形態は、スナップショットに対応する状態の時点のデータを読み取るために使用できるスナップショットを生成する分散型ストレージシステムを含んでよい。スナップショットを生成することは、ログレコードの内の特定のログレコードの特定のログ識別子（例えば、ログシーケンス番号、タイムスタンプ等）を示すメタデータを生成することを含んでよい。いくつかの実施形態では、メタデータはスナップショット識別子を示してもよい。開示されているスナップショット生成技法は、スナップショット生成の一部としてデータページを読み取る、コピーする、または書き込むことなしに実行されてよい。

ログレコード操作の多様な実施形態も開示される。本実施形態の内の多様な実施形態は、複数のログレコードを受信するデータベースサービスの分散型ストレージシステムを含んでよい。また、本実施形態の内の多様な実施形態は、分散型ストレージシステムの複数のストレージノードの中で複数のログレコードを記憶する分散型ストレージシステムを含んでもよい。本実施形態の内の多様な実施形態は、複数のログレコードを変形させる分散型ストレージシステムをさらに含んでよい。変形は、他の変形の中で、レコードをトリミングすること、切り取ること、削減すること、融合させること、及び／またはそれ以外の場合、削除すること、マージすること、もしくは追加することを含んでよい。

明細書は、まず、開示されているスナップショット動作（例えば、作成、削除、使用、操作等）及びログレコード操作技法を実装するように構成される例のウェブサービスベースのデータベースサービスを説明する。例のウェブサービスベースのデータベースサービスの説明に含まれているのは、データベースエンジン及び別個の分散型データベースストレージサービス等の、例のウェブサービスベースのデータベースサービスの多様な態様である。明細書は、次いでスナップショット動作及びログレコード操作のための方法の多様な実施形態のフローチャートを説明する。次に、明細書は、開示されている技法を実装してよい例のシステムを説明する。明細書を通して多様な例が提供される。

本明細書に説明されるシステムは、いくつかの実施形態では、クライアント（例えば、加入者）がクラウドコンピューティング環境でデータストレージシステムを操作できるようにするウェブサービスを実装してよい。いくつかの実施形態では、データストレージシステムは、高度にスケーラブル且つ拡張可能である企業クラスのデータベースシステムであってよい。いくつかの実施形態では、クエリーは複数の物理リソース全体で分散されるデータベースストレージに向けられてよく、データベースシステムは必要に応じてスケールアップ、またはスケールダウンされてよい。データベースシステムは、異なる実施形態で、多様なタイプ及び／または編成のデータベーススキーマと効果的に機能してよい。いくつかの実施形態では、クライアント／加入者は、例えばＳＱＬインタフェースを介してデータベースシステムに対話的に等、いくつかの方法でクエリーを提出してよい。他の実施形態では、外部アプリケーション及びプログラムは、データベースシステムにオープンデータベースコネクティビティ（ＯＤＢＣ）ドライバインタフェース及び／またはＪａｖａデータベースコネクティビティ（ＪＤＢＣ）ドライバインタフェースを使用してクエリーを提出してよい。

すなわち、本明細書に説明されるシステムは、いくつかの実施形態では、単一のデータベースシステムの多様な機能構成要素が本質的に分散されるサービス指向型データベースアーキテクチャを実装してよい。これらのシステムは、例えば、（それぞれが、アプリケーションサーバ、サーチ機能性、またはデータベースのコア機能を提供するために必要とされる機能性を超える他の機能性等の外来の機能性を含んでよい）複数の完全でモノリシックなデータベースインスタンスを束ねるよりむしろ、データベースの基本的な動作（例えば、クエリー処理、トランザクション管理、キャッシング、及び記憶）を、個々に且つ無関係にスケーラブルであってよい階層に編成してよい。例えば、いくつかの実施形態では、本明細書に説明されるシステムの各データベースインスタンスは、（単一のデータベースエンジンヘッドノード及びクライアント側ストレージシステムドライバを含んでよい）データベース階層、及び（既存のシステムのデータベース階層で従来実行される動作のいくつかを集合的に実行する複数のストレージノードを含んでよい）別個の分散されたストレージシステムを含んでよい。

本明細書により詳細に説明されるように、いくつかの実施形態では、データベースの最低レベルの動作（例えば、バックアップ動作、復元動作、スナップショット動作、回復動作、ログレコード操作動作、及び／または多様なスペース管理動作）のいくつかは、データベースエンジンからストレージ層にオフロードされ、複数のノード及びストレージデバイス全体で分散されてよい。例えば、いくつかの実施形態では、データベースエンジンがデータベーステーブル（またはデータベーステーブルのデータページ）に変更を適用し、次いで修正されたデータページをストレージ層に送信するよりむしろ、記憶されているデータベーステーブル（及びデータベーステーブルのデータページ）に対する変更の適用は、ストレージ層自体の責任であってよい。係る実施形態では、修正されたデータページよりむしろ、リドゥログレコードがストレージ層に送信されてよく、その後リドゥ処理（例えば、リドゥログレコードの適用）はいくぶんゆったりと且つ（例えば、バックグラウンドプロセスによって等）分散された方法で実行されてよい。いくつかの実施形態では、クラッシュ回復（例えば、記憶されているリドゥログレコードからのデータページの再構築）は、ストレージ層によって実行されてもよく、分散された（及び、いくつかの場合、ゆったりとした）バックグラウンドプロセスによって実行されてもよい。

いくつかの実施形態では、リドゥログだけ（及び修正されたデータページではない）がストレージ層に送信されるため、データベース階層とストレージ層との間にあるネットワークトラフィックは、既存のデータベースシステムにおいてよりもはるかに少なくてよい。いくつかの実施形態では、各リドゥログは、各リドゥログが変更を指定する対応するデータページのサイズのほぼ１０分の１であってよい。データベース階層及び分散型ストレージシステムから送信される要求が非同期であってよいこと、及び複数の係る要求が一度に送信中であってよいことに留意されたい。

一般的に、１個のデータを与えられた後、データベースの主要な要件は、最終的のその１個のデータを返すことができることである。これを行うために、データベースはそれぞれが異なる機能を実行するいくつかの異なる構成要素（または階層）含んでよい。例えば、従来のデータベースは３つの階層、つまりクエリーパーシング、最適化、及び実行を実行するための第１の階層、トランザクション性（ｔｒａｎｓａｃｔｉｏｎａｌｉｔｙ）、回復、及び耐久性を提供するための第２の階層、及びローカルでアタッチされたディスクでまたはネットワークでアタッチされたストレージのどちらかでストレージを提供する第３の階層を有すると見なされてよい。上述されたように、従来のデータベースをスケーリングしようとする以前の試みは、通常、データベースの３つすべての階層を複製し、それらの複製されたデータベースインスタンスを複数のマシン全体で分散することを伴っていた。

いくつかの実施形態では、本明細書に説明されるシステムは、従来のデータベースにおいてとは異なってデータベースシステムの機能性を仕切ってよく、スケーリングを実装するために複数のマシン全体で（完全なデータベースインスタンスよりもむしろ）機能構成要素のサブセットだけを分散してよい。例えば、いくつかの実施形態では、クライアントが面する階層は、どのデータが記憶されるべきなのか、または取り出されるべきなのかを指定するが、どのようにしてデータを記憶するのか、または取り出すのかは指定しない要求を受信するように構成されてよい。この階層は、要求のパーシング及び／または最適化（例えば、ＳＱＬのパーシング及び要求）を実行してよい。一方、別の階層が、クエリーの実行に責任を負ってよい。いくつかの実施形態では、第３の階層が結果のトランザクション性及び一貫性を提供することに責任を負ってよい。例えば、この階層は、いわゆるＡＣＩＤプロパティのいくらか、特にデータベースをターゲットとするトランザクションの原子性を強化するよう構成されてよく、データベースの中で一貫性を維持し、データベースをターゲットとするトランザクション間で独立性を保証する。いくつかの実施形態では、第４の階層が次いで多様な種類の障害が存在する場合に記憶されているデータの耐久性を提供することに責任を負ってよい。例えば、この階層は、ロギングの変更、データベースクラッシュからの回復、基礎的な記憶ボリュームに対するアクセスの管理、及び／または基礎的な記憶ボリュームにおけるスペース管理に責任を負ってよい。

ここで図を参照すると、図１は、一実施形態に係る、データベースソフトウェアスタックの多様な構成要素を示すブロック図である。この例に示されるように、データベースインスタンスは、それぞれがデータベースインスタンスの機能性の一部を提供する、複数の機能構成要素（または層）を含んでよい。この例では、データベースインスタンス１００は、（１１０として示される）クエリーパーシング及びクエリー最適化層、（１２０として示される）クエリー実行層、（１３０として示される）トランザクション性及び一貫性管理層、並びに（１４０として示される）耐久性及びスペース管理層を含む。上述されたように、いくつかの既存のデータベースシステムでは、データベースインスタンスのスケーリングは、（図１に示される層のすべてを含んだ）データベースインスタンス全体を１回または複数回複製して、次いで層を互いに縫い合わせるためにグルーロジックを追加することを含んでよい。いくつかの実施形態では、本明細書に説明されるシステムは、代わりにデータベース階層から別個のストレージ層に耐久性及びスペース管理層１４０の機能性をオフロードしてよく、その機能性をストレージ層の複数のストレージノード全体で分散してよい。

いくつかの実施形態では、本明細書に説明されるデータベースシステムは、図１に示されるデータベースインスタンスの上半分の構造の多くを保持してよいが、バックアップ動作、復元動作、スナップショット動作、回復動作、及び／または多様なスペース管理動作の少なくとも部分に対する責任を記憶階層に再配分してよい。このようにして機能性を再配分し、データベース階層と記憶階層との間でログ処理をしっかりと結合することは、スケーラブルデータベースを提供する以前の手法と比較されるときに性能を改善し、可用性を高め、コストを削減してよい。例えば、（実際のデータページよりもサイズがはるかに小さい）リドゥログレコードだけがノード全体で送り出される、または書込み動作のレーテンシパスの中で持続してよいので、ネットワーク及び入出力帯域幅の要件が削減されてよい。さらに、データページの生成は、入信書込み動作を遮ることなく、（フォアグラウンド処理が許すので）各ストレージノードでバックグラウンドで独立して実行できる。いくつかの実施形態では、ログ構造化された非上書きストレージの使用が、例えばデータページの移動またはコピーよりむしろメタデータ操作を使用することによって、バックアップ動作、復元動作、スナップショット動作、ポイントインタイムリカバリ動作、及びボリューム増大動作をより効率的に実行できるようにしてよい。いくつかの実施形態では、ストレージ層は、複数のストレージノード全体でクライアントの代わりに記憶されたデータの複製（及び／またはリドゥログレコード等の、そのデータと関連付けられたメタデータ）に対する責任を負ってもよい。例えば、データ（及び／またはメタデータ）は、（例えば、ストレージノードの集合体が独自の物理的に別個の独立したインフラストラクチャで実行する単一の「可用性ゾーン」の中で等）ローカルに、及び／または単一の領域のもしくは異なる領域の可用性ゾーン全体で複製されてよい。

多様な実施形態では、本明細書に説明されるデータベースシステムは、さまざまなデータベース動作のために標準的なまたはカスタムのアプリケーションプログラミングインタフェース（ＡＰＩ）をサポートしてよい。例えば、ＡＰＩは、データベースの作成、テーブルの作成、テーブルの改変、ユーザーの作成、ユーザーの削除、テーブルでの１行または複数行の挿入、値のコピー、テーブルの中からのデータの選択（例えば、テーブルの問合せ）、クエリーの取消しまたはアボート、スナップショットの作成のための動作、及び／または他の動作をサポートしてよい。

いくつかの実施形態では、データベースインスタンスのデータベース階層は、多様なクライアントプログラム（例えば、アプリケーション）及び／または加入者（ユーザー）からの読取り要求及び／または書込み要求を受信し、次いで要求をパースし、関連付けられたデータベース動作（複数の場合がある）実施するための実行計画を作成するデータベースエンジンヘッドノードサーバを含んでよい。例えば、データベースエンジンヘッドノードは、複雑なクエリー及び接合の結果を得るために必要な一連のステップを作成してよい。いくつかの実施形態では、データベースエンジンヘッドノードは、データベース階層と別個の分散型データベース最適化ストレージシステムとの間の通信だけではなく、データベースシステムのデータベース階層とクライアント／加入者との間の通信も管理してよい。

いくつかの実施形態では、データベースエンジンヘッドノードは、ＪＤＢＣインタフェースまたはＯＤＢＣインタフェースを通してエンドクライアントからＳＱＬ要求を受信すること、及びローカルでＳＱＬ処理及び（ロッキングを含んでよい）トランザクション管理を実行することに責任を負ってよい。ただし、データベースエンジンヘッドノード（またはデータベースエンジンヘッドノードの多様な構成要素）は、データページをローカルで生成するよりむしろ、リドゥログレコードを生成してよく、リドゥログレコードを別個の分散型ストレージシステムの適切なノードに送り出してよい。いくつかの実施形態では、分散型ストレージシステムのためのクライアント側ドライバは、データベースエンジンヘッドノードでホストされてよく、それらのリドゥログレコードが向けられるセグメント（またはセグメントのデータページ）を記憶する１つのストレージシステムノード（または複数のストレージシステムノード）にリドゥログレコードを送ることに責任を負ってよい。例えば、いくつかの実施形態では、各セグメントは保護グループを形成する複数のストレージシステムノードでミラーリングされてよい（またはそれ以外の場合、耐久的にされてよい）。係る実施形態では、クライアント側ドライバは、各セグメントが記憶されるノードを追跡調査してよく、クライアント要求が受信されるときに（例えば非同期で、及び実質的にほぼ同時に並列で）セグメントが記憶されるノードのすべてにリドゥログを送ってよい。クライアント側ドライバが（リドゥログレコードがストレージノードに書き込まれていることを示すことがある）保護グループのストレージノードの書込み選抜グループ（ｑｕｏｒｕｍ）から肯定応答を受信するとすぐに、クライアント側ドライバはデータベース階層に（例えば、データベースエンジンヘッドノードに）要求された変更の肯定応答を送信してよい。例えば、データが保護グループを使用することによって耐久的にされる実施形態では、データベースエンジンヘッドノードは、クライアント側ドライバが書込み選抜グループを構成するために十分なストレージノードインスタンスから回答を受信するまで及び受信しない限り、トランザクションをコミットできないことがある。同様に、特定のセグメントに向けられる読取り要求の場合、クライアント側ドライバは、（例えば非同期で、及び実質的に同時に並列で）セグメントが記憶されるノードのすべてに読取り要求を送ってよい。クライアント側ドライバは保護グループのストレージノードの読取り選抜グループから要求されたデータを受信するとすぐに、クライアント側ドライバはデータベース階層に（例えば、データベースエンジンヘッドノードに）要求されたデータを返してよい。

いくつかの実施形態では、データベース階層（またはより詳細には、データベースエンジンヘッドノード）は、最近アクセスされたデータページが一時的に保持されるキャッシュを含んでよい。係る実施形態では、係るキャッシュに保持されるデータページをターゲットとする書込み要求が受信されると、対応するリドゥログレコードをストレージ層に送り出すことに加えて、データベースエンジンはそのキャッシュに保持されているデータページのコピーに変更を適用してよい。ただし、他のデータベースシステムにおいてとは異なり、このキャッシュに保持されるデータページはストレージ層にフラッシュされることはなく、該データページはいつでも（例えば、キャッシュに入れられたコピーに最も最近に適用された書込み要求のリドゥログレコードがストレージ層に送信され、肯定応答された後のいつでも）廃棄されてよい。キャッシュは、異なる実施形態で、一度に多くても一人の書込み者（または複数の読取り者）によるキャッシュへのアクセスを制御するための多様なロッキング機構のいずれかを実装してよい。ただし、係るキャッシュを含む実施形態では、キャッシュは複数のノード全体で分散れるのではなく、所与のデータベースインスタンスのためにデータベースエンジンヘッドノードだけに存在してよいことに留意されたい。したがって、管理するキャッシュコヒーレンシーまたは一貫性問題がないことがある。

いくつかの実施形態では、データベース階層は、例えば、読取り要求を送ることができるデータベース階層の異なるノードでのデータの読取り専用コピー等、システムでの同期または非同期の読取りレプリカの使用をサポートしてよい。係る実施形態では、所与のデータベーステーブルのデータベースエンジンヘッドノードが特定のデータページに向けられる読取り要求を受信すると、データベースエンジンヘッドノードはこれらの読取り専用コピーの内のいずれか１つ（または特定の１つ）に要求を送ってよい。いくつかの実施形態では、データベースエンジンヘッドノードのクライアント側ドライバは、（例えば、これらの他のノードにそのキャッシュを無効にするように促すために）キャッシュに入れられたデータページに対する更新及び／または失効についてこれらの他のノードに通知するように構成されてよい（その後これらの他のノードはストレージ層から更新されたデータページの更新済みのコピーを要求してよい）。

いくつかの実施形態では、データベースエンジンヘッドノードで実行中のクライアント側ドライバは、記憶階層にプライベートインタフェースを曝露してよい。いくつかの実施形態では、クライアント側ドライバは従来のｉＳＣＳＩインタフェースを１つまたは複数の他の構成要素（例えば、他のデータベースエンジンまたは仮想コンピューティングサービス構成要素）に曝露してもよい。いくつかの実施形態では、記憶階層でのデータベースインスタンスのためのストレージは、制限なくサイズを増大することがあり、それと関連付けられた、制限されない数のＩＯＰＳを有することがある単一のボリュームとしてモデル化されてよい。ボリュームが作成されるとき、ボリュームは特定のサイズで、（例えば、ボリュームがどのように複製されるのかを指定する）特定の可用性／耐久性特徴で、及び／またはボリュームと関連付けられたＩＯＰＳレートで（例えば、ピークと持続の両方）作成されてよい。例えば、いくつかの実施形態では、さまざまな異なる耐久性モデルがサポートされてよく、ユーザー／加入者は自らのデータベーステーブルのために、複製コピー、ゾーン、もしくは領域の数、及び／またはその耐久性、性能、及びコストの目的に基づいて複製が同期であるのか、それとも非同期であるのかを指定できてよい。

いくつかの実施形態では、クライアント側ドライバはボリュームについてのメタデータを維持してよく、ストレージノード間で追加のホップを必要とすることなく、読取り要求及び書込み要求を実行するために必要なストレージノードのそれぞれに非同期要求を直接的に送信してよい。例えば、いくつかの実施形態で、データベーステーブルに対する変更を行う要求に応えて、クライアント側ドライバは、ターゲットとされたデータページのストレージを実装している１つまたは複数のノードを決定し、それらのストレージノードに対するその変更を指定するリドゥログレコード（複数の場合がある）を送るように構成されてよい。ストレージノードは、次いで、リドゥログレコードに指定される変更を将来のある時点でターゲットとされたデータページに適用することに責任を負ってよい。書込みはクライアント側ドライバに肯定応答されるので、クライアント側ドライバは、ボリュームが耐久的となる点を先に進めてよく、データベース階層に対してコミットを肯定応答してよい。上述されたように、いくつかの実施形態では、クライアント側ドライバはストレージノードサーバにデータページを絶対に送信しないことがある。これは、ネットワークトラフィックを削減するだけではなく、チェックポイントまたは以前のデータベースシステムでのフォアグラウンド処理スループットを制約するバックグラウンド書込み者スレッドの必要性を削除してもよい。

いくつかの実施形態では、多くの読取り要求がデータベースエンジンヘッドノードキャッシュによって提供されてよい。ただし、大規模故障イベントは一般的すぎて、メモリ内複製だけを許可できないので、書込み要求は耐久性を必要としてよい。したがって、本明細書に説明されるシステムは、記憶階層内のデータストレージを２つの領域、つまりリドゥログレコードがデータベース階層から受信されるときにリドゥログレコードが書き込まれる小さなアペンド専用ログ構造化領域、及びバックグラウンドでデータページの新しいバージョンを作成するために、ログレコードがともに合体するより大きな領域として実装することによって、フォアグラウンドレーテンシパス内にあるリドゥログレコード書込み動作のコストを最小限に抑えるように構成されてよい。いくつかの実施形態では、メモリ内構造は、インスタンス化されたデータブロックが参照されるまで連鎖ログレコード後方へ、データページの前回のリドゥログレコードを指すデータページごとに維持される。この手法は、読取りがおもにキャッシュに入れられるアプリケーション内を含んで、混合した読取り‐書込みワークロードに優れた性能を提供してよい。

いくつかの実施形態では、リドゥログレコードのためのログ構造化データストレージへのアクセスは、（ランダム入出力動作よりむしろ）一連の順次入出力動作から構成されてよいため、行われている変更は互いに密接にパックされてよい。データページに変更するたびに、永続データストレージに対する２つの入出力動作（リドゥログのための動作及び修正されたデータページ自体のための動作）が生じる既存のシステムとは対照的に、いくつかの実施形態では、本明細書に説明されるシステムはリドゥログレコードの受信に基づいて分散型ストレージシステムのストレージノードでデータページを合体させることによってこの「書込み増幅」を回避してよい。

上述されたように、いくつかの実施形態では、データベースシステムの記憶階層はデータベーススナップショットを撮ることに責任を負ってよい。ただし、記憶階層はログ構造化ストレージを実装するため、データページ（例えば、データブロック）のスナップショットを撮ることはデータページ／ブロックに最も最近適用されたリドゥログレコードと関連付けられたタイムスタンプ（またはデータページ／ブロックの新しいバージョンを作成するために複数のリドゥログレコードを合体させるための最も最近の動作と関連付けられたタイムスタンプ）を記録すること、並びにページ／ブロックの以前のバージョン及び時間内に記録された点までのあらゆる以後のログエントリのガベージコレクションを妨げることを含んでよい。係る実施形態では、データベーススナップショットを撮ることは、オフボリュームバックアップ戦略を利用するときに必要とされるだろう、データブロックの読取り、コピー、または書込みを必要としないことがある。いくつかの実施形態では、ユーザー／加入者はアクティブデータセットに加えてオンボリュームスナップショットのためにどれほど多くの追加スペースを保つことを希望するのかを選ぶことができることがあるが、修正されたデータだけが追加のスペースを必要とするので、スナップショットのスペース要件は最小であってよい。異なる実施形態では、スナップショットは、不連続（例えば、各スナップショットは時間の特定の時点のデータページ内のデータのすべてに対するアクセスを提供してよい）または連続（例えば、各スナップショットは２つの時点の間のデータページに存在するデータのすべてのバージョンに対するアクセスを提供してよい）であってよい。いくつかの実施形態では、以前のスナップショットに戻ることは、そのスナップショット以降のすべてのリドゥログレコード及びデータページが無効であり、ガベージコレクション可能であることを示すためにログレコードを記録すること、及びスナップショット点後のすべてのデータベースキャッシュエントリを廃棄することを含んでよい。係る実施形態では、ストレージシステムは、ストレージシステムが通常の順方向読取り／書込み処理で行うのと同様に、要求されるように、及びすべてのノード全体でバックグラウンドで、ブロック単位でリドゥログレコードをデータブロックに適用するので、前進復帰は必要とされないことがある。クラッシュ回復は、それによってノード全体で並列且つ分散型にされてよい。スナップショットの作成、使用、及び／または操作に関する追加詳細は、図８及び図９で説明される。

ウェブサービスベースのデータベースサービスを実装するように構成されてよいサービスシステムアーキテクチャの一実施形態が図２に示される。示されている実施形態では、（データベースクライアント２５０ａから２５０ｎとして示される）多くのクライアントがネットワーク２６０を介してウェブサービスプラットホーム２００と対話するように構成されてよい。ウェブサービスプラットホーム２００は、データベースサービス２１０、分散型データベース最適化ストレージサービス２２０、及び／または１つまたは複数の他の仮想コンピューティングサービス２３０の１つまたは複数のインスタンスとインタフェースをとるように構成されてよい。所与の構成要素の１つまたは複数が存在してよい場合、本明細書でのその構成要素に対する参照は単数形または複数形のどちらかで行われてよいことが留意される。ただしどちらの形の使用も他方を排除することを目的としていない。

多様な実施形態では、図２に示される構成要素は、コンピュータハードウェア（例えば、マイクロプロセッサもしくはコンピュータシステム）によって直接的にまたは間接的に実行可能な命令として、またはこれらの技法の組合せを使用してコンピュータハードウェアの中で直接的に実装されてよい。例えば、図２の構成要素はそれぞれが図１０に示され、以下に説明されるコンピュータシステム実施形態に類似してよい、いくつかのコンピューティングノード（つまり、単にノード）を含むシステムによって実装されてよい。多様な実装形態では、所与のサービスシステム構成要素（例えば、データベースサービスの構成要素またはストレージサービスの構成要素）の機能性は、特定のノードによって実装されてよい、またはいくつかのノード全体で分散されてよい。いくつかの実施形態では、所与のノードは複数のサービスシステム構成要素（例えば、複数のデータベースサービスシステム構成要素）の機能性を実装してよい。

一般的に言えば、クライアント２５０は、データベースサービスに対する要求（例えば、スナップショットを生成する要求等）を含むウェブサービス要求を、ネットワーク２６０を介してウェブサービスプラットホーム２００に提出するように構成可能な任意のタイプのクライアントを包含してよい。例えば、所与のクライアント２５０は、ウェブブラウザの適切なバージョンを含んでよい、またはウェブブラウザによって提供される実行環境に対する拡張部として、またはウェブブラウザによって提供される実行環境の中で実行するように構成されるプラグインモジュールまたは他のタイプのコードモジュールを含んでよい。代わりに、クライアント２５０（例えば、データベースサービスクライアント）は、データベースアプリケーション（もしくはデータベースアプリケーションのユーザーインタフェース）、メディアアプリケーション、オフィスアプリケーション、または１つまたは複数のデータベーステーブルを記憶する、及び／または１つまたは複数のデータベーステーブルにアクセスするために永続記憶装置リソースを利用してよい任意の他のアプリケーション等のアプリケーションを包含してよい。いくつかの実施形態では、係るアプリケーションは、必ずしもすべてのタイプのウェブベースのデータに対する完全なブラウザサポートを実装しなくてもウェブサービス要求を生成し、処理するための（例えば、ハイパテキスト転送プロトコル（ＨＴＴＰ）の適切なバージョンのための）十分なプロトコルサポートを含んでよい。すなわち、クライアント２５０は、ウェブサービスプラットホーム２００と直接的に対話するように構成されるアプリケーションであってよい。いくつかの実施形態では、クライアント２５０は、表象状態転送（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）（ＲＥＳＴ）様式ウェブサービスアーキテクチャ、ドキュメントベースもしくはメッセージベースのウェブサービスアーキテクチャ、または別の適切なウェブサービスアーキテクチャに従ってウェブサービス要求を生成するよう構成されてよい。

いくつかの実施形態では、クライアント２５０（例えば、データベースサービスクライアント）は、データベーステーブルのウェブサービスベースのストレージへのアクセスを、他のアプリケーションに、それらのアプリケーションにはトランスペアレントな方法で提供するように構成されてよい。例えば、クライアント２５０は、オペレーティングシステムまたはファイルシステムと統合して、本明細書に説明されるストレージモデルの適切な変形に従ってストレージを提供するように構成されてよい。ただし、オペレーティングシステムまたはファイルシステムは、ファイル、ディレクトリ、及び／またはフォルダの従来のファイルシステム階層等の、アプリケーションに異なるストレージインタフェースを提示してよい。係る実施形態では、アプリケーションは図１のストレージシステムサービスモデルを利用するために修正される必要はないことがある。代わりに、ウェブサービスプラットホーム２００へのインタフェースをとることの詳細は、オペレーティングシステム環境の中で実行するアプリケーションの代わりに、クライアント２５０及びオペレーティングシステムまたはファイルシステムによって調整されてよい。

クライアント２５０は、ネットワーク２６０を介してウェブサービスプラットホーム２００にウェブサービス要求（例えば、スナップショット要求、スナップショット要求のパラメータ、読取り要求、スナップショットの復元等）を伝達し、ウェブサービスプラットホーム２００から応答を受信してよい。多様な実施形態では、ネットワーク２６０は、クライアント２５０とプラットホーム２００との間でウェブベースの通信を確立するために必要なネットワーキングハードウェア及びプロトコルの任意の適切な組合せを包含してよい。例えば、ネットワーク２６０は、集合的にインターネットを実装する多様な電気通信ネットワーク及びサービスプロバイダを概して包含してよい。また、ネットワーク２６０は、公衆無線ネットワークまたは構内無線ネットワークだけではなく、ローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）等の構内ネットワークも含んでよい。例えば、所与のクライアント２５０とウェブサービスプラットホーム２００の両方とも、独自の内部ネットワークを有する企業の中でそれぞれプロビジョニングされてよい。係る実施形態では、ネットワーク２６０は、インターネットとウェブサービスプラットホーム２００との間だけではなく、所与のクライアント２５０とインターネットとの間にネットワーキングリンクを確立するために必要なハードウェア（例えば、モデム、ルータ、開閉器、ロードバランサ、プロキシサーバ等）及びソフトウェア（例えば、プロトコルスタック、財務会計ソフト、ファイアウォール／セキュリティソフトウェア等）を含んでよい。いくつかの実施形態では、クライアント２５０は、公衆インターネットよりむしろ構内ネットワークを使用してウェブサービスプラットホーム２００と通信してよい。例えば、クライアント２５０は、データベースサービスシステム（例えば、データベースサービス２１０及び／または分散型データベース最適化ストレージサービス２２０を実装するシステム）と同じ企業の中でプロビジョニングされてよい。係る場合、クライアント２５０は、構内ネットワーク２６０（例えば、インターネットベースの通信プロトコルを使用してよいが、公にアクセス可能ではないＬＡＮまたはＷＡＮ）を通して完全にプラットホーム２００と通信してよい。

一般的に言えば、ウェブサービスプラットホーム２００は、データページ（またはデータページのレコード）にアクセスする要求等のウェブサービス要求を受信し、処理するように構成される１つまたは複数のサービスエンドポイントを実装するように構成されてよい。例えば、ウェブサービスプラットホーム２００は、特定のエンドポイントを実装するように構成されるハードウェア及び／またはソフトウェアを含んでよく、したがってそのエンドポイントに向けられたＨＴＴＰベースのウェブサービス要求は適切に受信され、処理される。一実施形態では、ウェブサービスプラットホーム２００は、クライアント２５０からウェブサービス要求を受信し、ウェブサービス要求を、処理のためにデータベースサービス２１０、分散型データベース最適化ストレージサービス２２０、及び／または別の仮想コンピューティングサービス２３０を実装するシステムの構成要素に転送するように構成されるサーバシステムとして実装されてよい。他の実施形態では、ウェブサービスプラットホーム２００は、大規模なウェブサービス要求処理ロードを動的に管理するように構成されるロードバランス機能及び他の要求管理機能を実装する（例えば、クラスタトポロジの）いくつかの別個のシステムとして構成されてよい。多様な実施形態では、ウェブサービスプラットホーム２００は、ＲＥＳＴ様式またはドキュメントベースの（例えば、ＳＯＡＰベースの）タイプのウェブサービス要求をサポートするように構成されてよい。

いくつかの実施形態では、ウェブサービスプラットホーム２００は、クライアントのウェブサービス要求に対するアドレス可能なエンドポイントとして機能することに加えて、多様なクライアント管理機能を実装してよい。例えば、プラットホーム２００は、例えば要求側クライアント２５０のアイデンティティ、クライアント要求の数及び／または頻度、クライアント２５０の代わりに記憶されているまたは取り出されるデータテーブル（またはデータテーブルのレコード）のサイズ、クライアント２５０によって使用される全体的な記憶帯域幅、クライアント２５０によって要求されるストレージのクラス、または任意の他の測定可能なクライアント使用パラメータを追跡調査することによって、ストレージリソースを含むウェブサービスのクライアント使用の計量及びアカウンティングを調整してよい。プラットホーム２００は、財務会計システム及び請求書作成システムを実装してもよい、またはクライアント使用活動の報告及び請求書作成のために外部システムによって照会され、処理されてよい使用データのデータベースを維持してもよい。特定の実施形態では、プラットホーム２００は、クライアント２５０から受け取られる要求の割合及びタイプ、係る要求によって活用される帯域幅、係る要求のためのシステム処理レーテンシ、システム構成要素活用（例えば、ストレージサービスシステムの中のネットワーク帯域幅及び／またはストレージ活用）、要求から生じるエラーの割合及びタイプ、記憶され、要求されるデータページもしくはそのレコードの特徴（例えば、サイズ、データタイプ等）を反映する測定基準、または任意の他の適切な測定基準等、さまざまなストレージサービスシステム操作測定基準を収集する、監視する、及び／または統合するよう構成されてよい。いくつかの実施形態では、係る測定基準はシステム構成要素を調整し、維持するためにシステム管理者によって使用されてよい。一方、他の実施形態では、係る測定基準（または係る測定基準の関連性のある部分）は、係るクライアントがデータベースサービス２１０、分散型データベース最適化ストレージサービス２２０、及び／または別の仮想コンピューティングサービス２３０（またはそれらのサービスを実装する基礎的なシステム）の使用を監視できるようにするためにクライアント２５０に曝露されてよい。

いくつかの実施形態では、プラットホーム２００は、ユーザー認証手順及びアクセス制御手順も実装してよい。例えば、特定のデータベーステーブルにアクセスする所与のウェブサービス要求の場合、プラットホーム２００は、要求と関連付けられるクライアント２５０が特定のデータベーステーブルにアクセスする権限を与えられているかどうかを確かめるように構成されてよい。プラットホーム２００は、例えばアイデンティティ、パスワード、もしくは他の信用証明書を特定のデータベーステーブルと関連付けられた信用証明書に対して評価する、または特定のデータベーステーブルに対する要求されたアクセスを、特定のデータベーステーブルに対するアクセス制御リストに対して評価することによって係る権限付与を決定してよい。例えば、クライアント２５０が特定のデータベーステーブルにアクセスするほど十分な信用証明書を有していない場合、プラットホーム２００は、例えばエラー状態を示す応答を要求側クライアント２５０に返すことによって対応するウェブサービス要求を拒絶してよい。多様なアクセス制御方針は、データベースサービス２１０、分散型データベース最適化ストレージサービス２２０、及び／または他の仮想コンピューティングサービス２３０によってアクセス制御情報のレコードまたはリストとして記憶されてよい。

ウェブサービスプラットホーム２００が、クライアント２５０がデータベースサービス２１０を実装するデータベースシステムの特徴にそれを通してアクセスしてよい一次インタフェースを表してよいが、ウェブサービスプラットホーム２００が係る特徴に対する単独のインタフェースを表す必要がないことが留意される。例えば、ウェブサービスインタフェースとは別個であってよい代替のＡＰＩは、データベースシステムを提供する企業にとって内部のクライアントがウェブサービスプラットホーム２００を迂回できるようにするために使用されてよい。本明細書に説明される例の多くで、分散型データベース最適化ストレージサービス２２０が、クライアント２５０にデータベースサービスを提供するコンピューティングシステムまたは企業システムにとって内部であってよく、外部クライアント（例えば、ユーザーまたはクライアントアプリケーション）に曝露されないことがあることに留意されたい。係る実施形態では、内部「クライアント」（例えば、データベースサービス２１０）は、（例えば、これらのサービスを実装するシステムの間で直接的にＡＰＩを通して）分散型データベース最適化ストレージサービス２２０とデータベースサービス２１０との間の実線として示されるローカルネットワークまたは構内ネットワーク上で分散型データベース最適化ストレージサービス２２０にアクセスしてよい。係る実施形態では、クライアント２５０の代わりにデータベーステーブルを記憶する上での分散型データベース最適化ストレージサービス２２０の使用はそれらのクライアントにとってトランスペアレントであってよい。他の実施形態では、分散型データベース最適化ストレージサービス２２０は、データベース管理のためにデータベースサービス２１０に依存するアプリケーション以外のアプリケーションに、データベーステーブルまたは他の情報のストレージを提供するために、ウェブサービスプラットホーム２００を通してクライアント２５０に曝露されてよい。これは、ウェブサービスプラットホーム２００と分散型データベース最適化ストレージサービス２２０の間の破線によって図２に示される。係る実施形態では、分散型データベース最適化ストレージサービス２２０のクライアントは、ネットワーク２６０を介して（例えば、インターネット上で）分散型データベース最適化ストレージサービス２２０にアクセスしてよい。いくつかの実施形態では、仮想コンピューティングサービス２３０は、クライアント２５０の代わりにコンピューティングサービス２３０を実行する上で使用されるオブジェクトを記憶するために（例えば、仮想コンピューティングサービス２３０と分散型データベース最適化ストレージサービス２２０との間で直接的にＡＰＩを通して）分散型データベース最適化ストレージサービス２２０からストレージサービスを受信するように構成されてよい。これは、仮想コンピューティングサービス２３０と分散型データベース最適化ストレージサービス２２０との間の破線によって図２に示される。いくつかのケースでは、プラットホーム２００のアカウンティングサービス及び／または信用証明書発行（ｃｒｅｄｅｎｔｉａｌｉｎｇ）サービスは、管理クライアント等の内部クライアントにとって、または同じ企業の中のサービス構成要素間では不必要となってよい。

多様な実施形態では、異なる記憶方針が、データベースサービス２１０及び／または分散型データベース最適化ストレージサービス２２０によって実装されてよいことに留意されたい。係る記憶方針の例は、耐久性方針（例えば、記憶されるデータベーステーブル（またはデータベーステーブルのデータページ）のインスタンスの数、及びデータベーステーブルが記憶される異なるノードの数を示す方針）、及び／または（要求トラフィックを一様にしようとしてデータベーステーブルまたはデータベーステーブルのデータページを、異なるノード、ボリューム、及び／またはディスク全体で分散してよい）ロードバランシング方針を含んでよい。さらに、異なる記憶方針は、サービスの多様な１つによって異なるタイプの記憶された項目に適用されてよい。例えば、いくつかの実施形態では、分散型データベース最適化ストレージサービス２２０は、データページに対するよりもリドゥログレコードに対してより高い耐久性を実装してよい。

図３は、一実施形態に従って、データベースエンジン、及び別個の分散型データベースストレージサービスを含むデータベースシステムの多様な構成要素を示すブロック図である。この例では、データベースシステム３００は、いくつかのデータベーステーブルのそれぞれのためのそれぞれのデータベースエンジンヘッドノード３２０、及び（データベースクライアント３５０ａから３５０ｎとして示されるデータベースシステムのクライアントにとって可視であってよい、または可視でないことがある）分散型データベース最適化ストレージサービス３１０を含む。この例で示されるように、データベースクライアント３５０ａから３５０ｎの内の１つまたは複数は、データベースヘッドノード３２０（例えば、それぞれがそれぞれのデータベースインスタンスの構成要素である、ヘッドノード３２０ａ、ヘッドノード３２０ｂ、またはヘッドノード３２０ｃ）に、ネットワーク３６０を介してアクセスしてよい（例えば、これらの構成要素はネットワークアドレス指定可能且つデータベースクライアント３５０ａから３５０ｎにアクセス可能であってよい）。ただし、データベースクライアント３５０ａから３５０ｎの代わりに、１つまたは複数のデータベーステーブルのデータページ（及びリドゥログレコードおよび／またはそれと関連付けられた他のメタデータ）を記憶し、本明細書に説明されるようにデータベースシステムの他の機能を実行するためにデータベースシステムによって利用されてよい分散型データベース最適化ストレージサービス３１０は、異なる実施形態では、ネットワークアドレス指定可能且つストレージクライアント３５０ａから３５０ｎにアクセス可能であってよい、またはアクセス可能でないことがある。例えば、いくつかの実施形態では、分散型データベース最適化ストレージサービス３１０は、ストレージクライアント３５０ａから３５０ｎに非可視である方法で多様な記憶動作、アクセス動作、ロギング変更動作、回復動作、ログレコード操作動作、及び／またはスペース管理動作を実行してよい。

上述されたように、各データベースインスタンスは、多様なクライアントプログラム（例えばアプリケーション）及び／または加入者（ユーザー）から要求（例えば、スナップショット要求等）を受信し、次いで要求をパースし、要求を最適化し、関連付けられたデータベース動作（複数の場合がある）を実施するための実行計画を作成する単一のデータベースエンジンヘッドノード３２０を含んでよい。図３に示される例では、データベースエンジンヘッドノード３２０ａのクエリーパーシング、最適化、及び実行構成要素３０５は、データベースクライアント３５０ａから受信され、データベースエンジンヘッドノード３２０ａがその構成要素であるデータベースインスタンスをターゲットとするクエリーのためにこれらの機能を実行してよい。いくつかの実施形態では、クエリーパーシング、最適化、及び実行構成要素３０５はデータベースクライアント３５０ａに、書込み肯定応答、要求されたデータページ（及びデータページの部分）、エラーメッセージ、及びまたは他の応答を適宜に含んでよいクエリー応答を返してよい。この例に示されるように、データベースエンジンヘッドノード３２０ａは、分散型データベース最適化ストレージサービス３１０の中で多様なストレージノードに読取り要求及び／またはリドゥログレコードを送り、分散型データベース最適化ストレージサービス３１０から書込み肯定応答を受信し、分散型データベース最適化ストレージサービス３１０から要求されたデータページを受信し、及び／またはデータページ、エラーメッセージ、または他の応答を（同様にそれらをデータベースクライアント３５０ａに返してよい）クエリーパーシング、最適化、及び実行構成要素３０５に返してよい、クライアント側ストレージサービスドライバ３２５も含んでよい。

この例では、データベースエンジンヘッドノード３２０ａは、最近アクセスされたデータページが一時的に保持されてよいデータページキャッシュ３３５を含む。図３に示されるように、データベースエンジンヘッドノード３２０ａは、データベースエンジンヘッドノード３２０ａが構成要素であるデータベースインスタンスでトランザクション性及び一貫性を提供することに責任を負ってよいトランザクション及び一貫性管理構成要素３３０も含んでよい。例えば、この構成要素は、データベースインスタンス及び該データベースインスタンスに向けられるトランザクションの原子性、一貫性、及び独立性のプロパティを保証することに責任を負ってよい。図３に示されるように、データベースエンジンヘッドノード３２０ａは、多様なトランザクションのステータスを追跡調査し、コミットしないトランザクションのあらゆるローカルでキャッシュに入れられた結果をロールバックするためにトランザクション及び一貫性管理構成要素３３０によって利用されてよいトランザクションログ３４０及びアンドゥログ３４５も含んでよい。

図３に示される他のデータベースエンジンヘッドノード３２０（例えば、３２０ｂ及び３２０ｃ）のそれぞれが類似する構成要素を含んでよく、データベースクライアント３５０ａから３５０ｎの内の１つまたは複数によって受信され、それが構成要素であるそれぞれのデータベースインスタンスに向けられるクエリーのために類似する機能を実行してよいことに留意されたい。

いくつかの実施形態では、本明細書に説明される分散型データベース最適化ストレージシステムは、１つまたは複数のストレージノードでの記憶のために多様な論理ボリューム、セグメント、及びページでデータを編成してよい。例えば、いくつかの実施形態では、各データベーステーブルは論理ボリュームによって表され、各論理ボリュームはストレージノードの集合体上でセグメント化される。ストレージノード内の特定のストレージノード上で生きる各セグメントは、隣接ブロックアドレスのセットを含む。いくつかの実施形態では、各データページはセグメントに記憶され、したがって各セグメントは１つまたは複数のデータページの集合体及びそれが記憶する各データページの変更ログ（リドゥログとも呼ばれる）（例えば、リドゥログレコードのログ）を記憶する。本明細書に詳細に説明されるように、ストレージノードは（本明細書でＵＬＲとも呼ばれてよい）リドゥログレコードを受信し、リドゥログレコードを合体させて、（例えば、ゆったりと及び／またはデータページもしくはデータベースクラッシュに対する要求に応えて）対応するデータページ及び／または追加のもしくは代替のログレコードの新しいバージョンを作成するように構成されてよい。いくつかの実施形態では、データページ及び／または変更ログは（クライアントによって指定されてよく、クライアントの代わりにデータベースシステムでデータベーステーブルが維持されている）可変構成に従って複数のストレージノード全体でミラーリングされてよい。例えば、異なる実施形態では、データログまたは変更ログの１つのコピー、２つのコピー、または３つのコピーがデフォルト構成、アプリケーションに特有の耐久性優先度、またはクライアントによって指定される耐久性優先度に従って、１つ、２つ、または３つの異なる可用性ゾーンもしくは領域のそれぞれに記憶されてよい。

本明細書に使用されるように、以下の用語は、多様な実施形態に従って分散型データベース最適化ストレージシステムによってデータの編成を説明するために使用されてよい。

ボリューム：ボリュームは、ストレージシステムのユーザー／クライアント／アプリケーションが理解するストレージのきわめて耐久性のある単位を表す論理概念である。すなわち、ボリュームはデータベーステーブルの多様なユーザーページに対する書込み動作の単一の一貫性がある順序付けられたログとしてユーザー／クライアント／アプリケーションに見える分散型ストアである。各書込み動作は、ボリュームの中で単一のユーザーページのコンテンツに対する論理的な順序付けられた変形を表すユーザーログレコード（ＵＬＲ）で符号化されてよい。上述されたように、ＵＬＲは、本明細書でリドゥログレコードと呼ばれてもよい。各ＵＬＲは、一意の識別子（例えば、論理シーケンス番号（ＬＳＮ）、タイムスタンプ等）を含んでよい。一意の識別子は単調に増加し、ログレコードの内の特定のログレコードに対して一意であってよいことに留意されたい。また、ログレコードに割り当てられる識別子のシーケンスにギャップが存在してよいことにも留意されたい。例えば、ＬＳＮの例では、ＬＳＮ２、３、７、及び８は使用されていない状態で、ＬＳＮ１、４、５、６、及び９が５つのそれぞれのログレコードに割り当てられてよい。各ＵＬＲは、ＵＬＲに高い耐久性及び可用性を提供するために、保護グループ（ＰＧ）を形成する、分散型ストア内の１つまたは複数の同期セグメントに持続してよい。ボリュームは、バイトの可変サイズの連続範囲にＬＳＮ型の読取り／書込みインタフェースを提供してよい。

いくつかの実施形態では、ボリュームはそれぞれが保護グループを通して耐久的にされた複数のエクステントから構成されてよい。係る実施形態では、ボリュームはボリュームエクステントの変わりやすい連続シーケンスから構成されるストレージの単位を表してよい。ボリュームに向けられる読取り及び書込みは、構成するボリュームエクステントに対する対応する読取り及び書込みにマッピングされてよい。いくつかの実施形態では、ボリュームのサイズは、ボリュームエクステントを追加することにより、又は、ボリュームの端部からボリュームエクステントを除去することにより変更されてもよい。

セグメント：セグメントは、単一ストレージノードに割り当てられるストレージの制限される耐久性の単位である。すなわち、セグメントは、特有の固定サイズバイト範囲のデータに、限られたベストエフォート型の耐久性（例えば、ストレージノードである、故障の永続的であるが冗長ではない単一点）を提供する。多様な実施形態では、このデータは、いくつかの場合では、ユーザーアドレス指定可能なデータのミラーであってよい、またはこのデータはボリュームメタデータまたはイレイジャーコーディングされたビット等の他のデータであってよい。所与のセグメントは、正確に１つのストレージノード上で生きてよい。ストレージノードの中で、複数のセグメントが各ＳＳＤ上で生きてよく、各セグメントは１つのＳＳＤに制限されてよい（例えば、セグメントは複数のＳＳＤに及ばないことがある）。いくつかの実施形態では、セグメントはＳＳＤ上で連続領域を占有するように要求されないことがある。むしろ、各ＳＳＤにセグメントのそれぞれによって所有される領域を記述する割当てマップがあってよい。上述されたように、保護グループは複数のストレージノードに渡って拡散される複数のセグメントから構成されてよい。いくつかの実施形態では、セグメントは、（サイズが作成時に定義される）バイトの固定サイズの隣接範囲に、ＬＳＮ型読取り／書込みインタフェースを提供してよい。いくつかの実施形態では、各セグメントはセグメントＵＵＩＤ（例えば、セグメントの汎用一意識別子）によって識別されてよい。

記憶ページ：記憶ページは、概して固定サイズのメモリのブロックである。いくつかの実施形態では、各ページは、オペレーティングシステムによって定義されるサイズのメモリの（例えば、バーチャルメモリ、ディスク、または他の物理メモリの）ブロックであり、本明細書では用語「データブロック」によって参照されてもよい。すなわち、記憶ページは隣接セクタのセットであってよい。記憶ページは、ヘッダ及びメタデータがあるログページでの単位だけではなく、ＳＳＤでの割当ての単位としても役立ってよい。いくつかの実施形態では、及び本明細書に説明されるデータベースシステムの文脈では、用語「ページ」または「記憶ページ」は、通常、４０９６バイト、８１９２バイト、１６３８４バイト、または３２７６８バイト等の２の倍数であってよいデータベース構成によって定義されるサイズの類似したブロックを指してよい。

ログページ：ログページは、ログレコード（例えば、リドゥログレコードまたはアンドゥログレコード）を記憶するために使用される記憶ページのタイプである。いくつかの実施形態では、ログページは、サイズが記憶ページと同一であってよい。各ログページは、例えばそれが属するセグメントを識別するメタデータ等、そのログページについてのメタデータを含むヘッダを含んでよい。ログページが編成の単位であり、必ずしも書込み動作に含まれるデータの単位ではないことがあることに留意されたい。例えば、いくつかの実施形態では、標準的な転送処理の間、書込み動作は、一度の１つのセクタをログの末尾に書き込んでよい。

ログレコード：ログレコード（例えば、ログページの個々の要素）はいくつかの異なるクラスであってよい。例えば、ストレージシステムのユーザー／クライアント／アプリケーションによって作成され、理解されるユーザーログレコード（ＵＬＲ）は、ボリューム内のユーザーデータに対する変更を示すために使用されてよい。ストレージシステムによって生成される制御ログレコード（ＣＬＲ）は、現在の無条件ボリューム耐久性（ｕｎｃｏｎｄｉｔｉｏｎａｌ ｖｏｌｕｍｅ ｄｕｒａｂｌｅ）ＬＳＮ（ＶＤＬ）等のメタデータを追跡調査するために使用される制御情報を含んでよい。ヌルログレコード（ＮＬＲ）は、いくつかの実施形態では、ログセクタまたはログページの未使用のスペースを充填するためのパディングとして使用されてよい。いくつかの実施形態では、これらのクラスのそれぞれの中に多様なタイプのログレコードがあってよく、ログレコードのタイプはログレコードを解釈するために呼び出される必要がある関数に対応してよい。例えば、１つのタイプは特定の圧縮フォーマットを使用する圧縮フォーマットのユーザーページのすべてのデータを表してよく、第２のタイプは、ユーザーページの中のバイト範囲の新しい値を表してよく、第３のタイプは、整数として解釈されるバイトのシーケンスに対する増分動作を表してよく、第４のタイプはページの中の別の場所に１バイト範囲をコピーすることを表してよい。いくつかの実施形態では、特にＵＬＲの場合、ログレコードタイプは、（整数または列挙型によってよりむしろ）バージョニング及び開発を簡略化してよいＧＵＩＤによって識別されてよい。

ペイロード：ログレコードのペイロードは、ログレコードに、または特定のタイプのログレコードに特有であるデータまたはパラメータ値である。例えば、いくつかの実施形態では、大部分（またはすべての）ログレコードが含み、ストレージシステム自体が理解するパラメータまたは属性のセットがあってよい。これらの属性は、セクタサイズに比較して相対的に小さくてよい共通のログレコードヘッダ／構造の部分であってよい。さらに、大部分のログレコードは、そのログレコードタイプに特有の追加のパラメータまたはデータを含んでよく、この追加情報はそのログレコードのペイロードと見なされてよい。いくつかの実施形態では、特定のＵＬＲのペイロードがユーザーページサイズよりも大きい場合、ペイロードは、そのペイロードがユーザーページのためのすべてのデータを含む絶対ＵＬＲ（ＡＵＬＲ）によって置き換えられてよい。これは、ストレージシステムがユーザーページのサイズに等しいＵＬＲのペイロードのサイズに対する上限を課すことができるようにしてよい。

セグメントログでログレコードを記憶する際に、いくつかの実施形態では、ペイロードはログヘッダとともに記憶されてよいことに留意されたい。他の実施形態では、ペイロードは別の場所に記憶されてよく、そのペイロードが記憶される場所に対するポインタはログヘッダとともに記憶されてよい。さらに他の実施形態では、ペイロードの一部はヘッダに記憶されてよく、ペイロードの残りは別個の場所に記憶されてよい。ペイロード全体がログヘッダとともに記憶される場合、これは帯域内ストレージと呼ばれてよい。それ以外の場合、ストレージは帯域外であると呼ばれてよい。いくつかの実施形態では、大部分の大きなＡＵＬＲのペイロードは（以下に説明される）ログのコールドゾーンで帯域外で記憶されてよい。

ユーザーページ：ユーザーページは、（固定サイズの）バイト範囲、及びストレージシステムのユーザー／クライアントに可視である特定のボリュームのためのそのアラインメントである。ユーザーページは論理概念であり、特定のユーザーページのバイトは任意の記憶ページにそのまま記憶されてよい、または記憶されないことがある。特定のボリュームのユーザーページのサイズは、そのボリュームの記憶ページサイズとは無関係であってよい。いくつかの実施形態では、ユーザーページサイズはボリュームごとに設定可能であってよく、ストレージノード上の異なるセグメントは異なるユーザーページサイズを有してよい。いくつかの実施形態では、ユーザーページサイズは、セクタサイズ（例えば、４ＫＢ）の倍数となるように制約されてよく、上限（例えば、６４ＫＢ）を有してよい。他方、記憶ページサイズは、ストレージノード全体にとって固定であってよく、基礎的なハードウェアに対する変更がない限り変化しないことがある。

データページ：データページは、圧縮された形式でユーザーページデータを記憶するために使用される記憶ページのタイプである。いくつかの実施形態では、データページに記憶されるあらゆる１個のデータがログレコードと関連付けられ、各ログレコードは（データセクタとも呼ばれる）データページの中のセクタに対するポインタを含んでよい。いくつかの実施形態では、データページは各セクタによって提供されるメタデータ以外の任意の埋込みメタデータを含まないことがある。データページ内のセクタ間には関係性がなくてよい。代わりに、ページへの編成は、セグメントへのデータの割当ての粒度の表現としてのみ存在してよい。

ストレージノード：ストレージノードは、ストレージノードサーバコードが配備される単一のバーチャルマシンである。各ストレージノードは、複数のローカルにアタッチされたＳＳＤを含んでよく、１つまたは複数のセグメントへのアクセスにネットワークＡＰＩを提供してよい。いくつかの実施形態では、多様なノードはアクティブリスト上または（例えば、ノードが応答するには低速である、またはそれ以外の場合、正常に機能しないが、完全に使用不可ではない場合等）劣化したリスト上にあってよい。いくつかの実施形態では、クライアント側ドライバは、ノードが交換されるべきかどうか、及びいつノードが交換されるべきかを判断するため、及び／または観察された性能に基づいて、いつ及びどのようにして多様なノードの間でデータを再配分するのかを決定するために、ノードをアクティブまたは劣化として分類するのを支援してよい（または、分類するのに責任を負ってよい）

ＳＳＤ：本明細書において参照されるように、用語「ＳＳＤ」は、例えばディスク、ソリッドステートドライブ、電池によって支援されるＲＡＭ、ＮＶＭＲＡＭデバイス（例えば、１つまたは複数のＮＶＤＩＭＭ）、または別のタイプの永続ストレージデバイス等の、その記憶ボリュームによって利用されるストレージのタイプに関わりなく、ストレージノードによって見られるローカルブロック記憶ボリュームを指してよい。ＳＳＤは、必ずしも直接的にハードウェアにマッピングされない。例えば、異なる実施形態では、単一のソリッドステートストレージデバイスは、各ボリュームが複数のセグメントに分割され、複数のセグメントに渡ってストライピングされる複数のローカルボリュームに分けられる可能性がある、及び／または単一ドライブは単に管理の容易さのために複数のボリュームに分割されてよい。いくつかの実施形態では、各ＳＳＤは単一の固定場所で割当てマップを記憶してよい。このマップは、特定のセグメントによってどの記憶ページが所有されているのか、及び（データページと対照的に）これらのページの内のどれがログページであるのかを示してよい。いくつかの実施形態では、記憶ページは、転送処理が割当てを待機する必要がなくてよいように各セグメントに事前に割り当てられてよい。割当てマップに対するあらゆる変更は、新規に割り当てられた記憶ページがセグメントによって使用される前に耐久的にされる必要があることがある。

分散型データベース最適化ストレージシステムの一実施形態は、図４のブロック図によって示される。この例では、データベースシステム４００は、相互接続４６０上でデータベースエンジンヘッドノード４２０と通信する分散型データベース最適化ストレージシステム４１０を含む。図３に示される例でのように、データベースエンジンヘッドノード４２０は、クライアント側ストレージサービスドライバ４２５を含んでよい。この例では、分散型データベース最適化ストレージシステム４１０は（４３０、４４０、及び４５０として示されるストレージシステムサーバノードを含んだ）複数のストレージシステムサーバノードを含み、複数のストレージシステムサーバノードのそれぞれは、それが記憶するセグメント（複数の場合がある）のためのデータページ及びリドゥログのストレージ、多様なセグメント管理機能を実行するように構成されるハードウェア及び／またはソフトウェアを含む。例えば、各ストレージシステムサーバノードは以下の動作、つまり、複製（例えば、ストレージノードの中で等ローカルに）、データページを生成するためのリドゥログの合体、スナップショット（例えば、作成、復元、削除等）、ログ管理（例えば、ログレコードの操作）、クラッシュ回復、及び／または（例えば、セグメントの）スペース管理の内のいずれかまたはすべての少なくとも一部を実行するように構成されるハードウェア及び／またはソフトウェアを含んでよい。各ストレージシステムサーバノードは、データブロックがクライアント（例えば、ユーザー、クライアントアプリケーション、及び／またはデータベースサービス加入者）の代わりに記憶されてよい（例えば、ＳＳＤ等の）複数のアタッチされたストレージデバイスも有してよい。

図４に示される例では、ストレージシステムサーバノード４３０は、データページ（複数の場合がある）４３３、セグメントリドゥログ（複数の場合がある）４３５、セグメント管理機能４３７、及びアタッチされたＳＳＤ４７１から４７８を含む。再び、ラベル「ＳＳＤ」はソリッドステートドライブを指してよい、または指さないこともあるが、基礎的なハードウェアに関わりなく、より概してローカルブロック記憶ボリュームを指してよいことに留意されたい。同様に、ストレージシステムサーバノード４４０は、データページ（複数の場合がある）４４３、セグメントリドゥログ（複数の場合がある）４４５、セグメント管理機能４４７、及びアタッチされたＳＳＤ４８１から４８８を含み、ストレージシステムサーバノード４５０は、データページ（複数の場合がある）４５３、セグメントリドゥログ（複数の場合がある）４５５、セグメント管理機能４５７、及びアタッチされたＳＳＤ４９１から４９８を含む。

上述されたように、いくつかの実施形態では、セクタは、ＳＳＤでのアラインメントの単位であり、書込みが部分的だけに完了されるリスクなしに書き込むことができるＳＳＤでの最大サイズであってよい。例えば、多様なソリッドステートドライブ及びスピニングメディアのセクタサイズは４ＫＢであってよい。本明細書に説明される分散型データベース最適化ストレージシステムのいくつかの実施形態では、ありとあらゆるセクタは、セクタがその一部であるより高レベルのエンティティに関わりなく、セクタの始まりに６４ビット（８バイト）のＣＲＣを含んで有してよい。係る実施形態では、（セクタがＳＳＤから読み取られるたびに確証されてよい）このＣＲＣは破損を検出する際に使用されてよい。いくつかの実施形態では、ありとあらゆるセクタは、その値がセクタをログセクタ、データセクタ、または初期化されていないセクタとして該セクタを識別する「セクタタイプ」バイトを含んでもよい。例えば、いくつかの実施形態では、０のセクタタイプバイト値は、セクタが初期化されていないことを示してよい。

いくつかの実施形態では、分散型データベース最適化ストレージシステムのストレージシステムサーバノードのそれぞれは、例えばリドゥログを受信し、データページ等を送り返すために、データベースエンジンヘッドノードとの通信を管理するノードサーバのオペレーティングシステムで実行中のプロセスのセットを実装してよい。いくつかの実施形態では、分散型データベース最適化ストレージシステムに書き込まれるすべてのデータブロックは、（例えば、リモートキー値耐久性バックアップストレージシステムで）長期の及び／またはアーカイブのストレージにバックアップされてよい。

図５は、一実施形態に係る、データベースシステムでの別個の分散型データベース最適化ストレージシステムの使用を示すブロック図である。この例では、１つまたは複数のクライアントプロセス５１０が、データベースエンジン５２０及び分散型データベース最適化ストレージシステム５３０を含むデータベースシステムによって維持される１つまたは複数のデータベーステーブルにデータを記憶してよい。図５に示される例では、データベースエンジン５２０がデータベース階層構成要素５６０、及び（分散型データベース最適化ストレージシステム５３０とデータベース階層構成要素５６０との間のインタフェースとして働く）クライアント側ドライバ５４０を含む。いくつかの実施形態では、データベース階層構成要素５６０は、図３のクエリーパーシング、最適化、及び実行構成要素３０５、並びにトランザクション及び一貫性管理構成要素３３０によって実行される機能等の機能を実行してよい、及び／またはデータページ、トランザクションログ、及び／またはアンドゥログ（例えば、図３のデータページキャッシュ３３５、トランザクションログ３４０、及びアンドゥログ３４５によって記憶されるもの）を記憶してよい。

この例では、１つまたは複数のクライアントプロセス５１０は、データベース階層構成要素５６０に（ストレージノード５３５ａから５３５ｎの内の１つまたは複数に記憶されるデータをターゲットとする読取り要求及び／または書込み要求を含んでよい）データベースクエリー要求５１５を送信してよく、データベース階層構成要素５６０からデータベースクエリー応答５１７（例えば、書込み肯定応答及び／または要求されたデータを含む応答）を受信してよい。データページに書き込む要求を含む各データベースクエリー要求５１５は、分散型データベース最適化ストレージシステム５３０への以後のルーティングのためにクライアント側ドライバ５４０に送信されてよい、１つまたは複数のレコード書込み要求５４１を生成するためにパースされ、最適化されてよい。この例では、クライアント側ドライバ５４０は、それぞれのレコード書込み要求５４１に対応する１つまたは複数のリドゥログレコード５３１を生成してよく、リドゥログレコード５３１を分散型データベース最適化ストレージシステム５３０のストレージノード５３５の特定のストレージノードに送信してよい。分散型データベース最適化ストレージシステム５３０は、データベースエンジン５２０に（具体的には、クライアント側ドライバ５４０に）各リドゥログレコード５３１の対応する書込み肯定応答５３２を返してよい。クライアント側ドライバ５４０は、これらの書込み肯定応答をデータベース階層構成要素５６０に（書込み応答５４２として）渡してよく、データベース階層構成要素５６０は次いでデータベースクエリー応答５１７の内の１つとして１つまたは複数のクライアントプロセス５１０に対応する応答（例えば、書込み肯定応答）を送信してよい。

この例では、データページを読み込む要求を含む各データベースクエリー要求５１５は、１つまたは複数のレコード読取り要求５４３を生成するためにパースされ、最適化されてよく、レコード読取り要求５４３は分散型データベース最適化ストレージシステム５３０への以後のルーティングのためにクライアント側ドライバ５４０に送信されてよい。この例では、クライアント側ドライバ５４０は、分散型データベース最適化ストレージシステム５３０のストレージノード５３５の特定のストレージノードにこれらの要求を送信してよく、分散型データベース最適化ストレージシステム５３０はデータベースエンジン５２０に（具体的には、クライアント側ドライバ５４０に）要求されたデータページ５３３を返してよい。クライアント側ドライバ５４０は、戻りデータレコード５４４としてデータベース階層構成要素５６０に返されたデータページを送信してよく、データベース階層構成要素５６０は次いでデータベースクエリー応答５１７として１つまたは複数のクライアントプロセス５１０にデータページを送信してよい。

いくつかの実施形態では、多様なエラーメッセージ及び／またはデータ損失メッセージ５３４が、分散型データベース最適化ストレージシステム５３０からデータベースエンジン５２０に（具体的には、クライアント側ドライバ５４０に）送信されてよい。これらのメッセージは、クライアント側ドライバ５４０から、エラー報告メッセージ及び／または損失報告メッセージ５４５として、データベース階層構成要素５６０に、及び次いで１つまたは複数のクライアントプロセス５１０に、データベースクエリー応答５１７とともに（または代わりに）渡されてよい。

いくつかの実施形態では、分散型データベース最適化ストレージシステム５３０のＡＰＩ５３１から５３４、及びクライアント側ドライバ５４０のＡＰＩ５４１から５４５は、データベースエンジン５２０が分散型データベース最適化ストレージシステム５３０のクライアントであるかのように、分散型データベース最適化ストレージシステム５３０の機能性をデータベースエンジン５２０に曝露してよい。例えば、データベースエンジン５２０は、データベースエンジン５２０及び分散型データベース最適化ストレージシステム５３０の組合せによって実装されるデータベースシステムの多様な動作（例えば、記憶動作、アクセス動作、ロギング変更動作、回復動作、及び／またはスペース管理動作）を実行するために（またはそれらの実行を容易にするために）（クライアント側ドライバ５４０を通して）リドゥログレコードまたは要求データページをこれらのＡＰＩを通して書き込んでよい。図５に示されるように、分散型データベース最適化ストレージシステム５３０は、それぞれが複数のアタッチされたＳＳＤを有してよいストレージノード５３５ａから５３５ｎにデータブロックを記憶してよい。いくつかの実施形態では、分散型データベース最適化ストレージシステム５３０は、多様なタイプの冗長性方式の適用によって、記憶されているデータブロックに高い耐久性を提供してよい。

多様な実施形態では、図５のデータベースエンジン５２０と分散型データベース最適化ストレージシステム５３０との間のＡＰＩ呼出し及び応答（例えば、ＡＰＩ５３１から５３４）、及び／またはクライアント側ドライバ５４０とデータベース階層構成要素５６０との間のＡＰＩ呼出し及び応答（例えば、ＡＰＩ５４１から５４５）は、（例えば、ゲートウェイ制御プレーンによって管理される）安全なプロキシ接続上で実行されてよい、または公衆ネットワーク上でもしくは代わりにバーチャルプライベートネットワーク（ＶＰＮ）接続等のプライベートチャネル上で実行されてよいことに留意されたい。本明細書に説明されるデータベースシステムの構成要素への、及びデータベースシステムの構成要素の間のこれらの及び他のＡＰＩは、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）技術及び表象状態転送（ＲＥＳＴ）技術を含むが、これに限定されるものではない異なる技術に従って実装されてよい。例えば、これらのＡＰＩは、ＳＯＡＰ ＡＰＩまたはＲＥＳＴｆｕｌ ＡＰＩとして実装されてよいが、必ずしも実装されない。ＳＯＡＰは、ウェブベースのサービスとの関連で情報を交換するためのプロトコルである。ＲＥＳＴは分散型ハイパーメディアシステム用のアーキテクチャスタイルである。（ＲＥＳＴｆｕｌウェブサービスとも呼ばれてよい）ＲＥＳＴｆｕｌ ＡＰＩは、ＨＴＴＰ及びＲＥＳＴ技術を使用して実装されるウェブサービスＡＰＩである。本明細書に説明されるＡＰＩは、いくつかの実施形態では、データベースエンジン５２０及び／または分散型データベース最適化ストレージシステム５３０との統合をサポートするために、Ｃ、Ｃ＋＋、Ｊａｖａ、Ｃ＃、及びＰｅｒｌを含むが、これに限定されるものではない多様な言語でクライアントライブラリでラップされてよい。

上述されたように、いくつかの実施形態では、データベースシステムの機能構成要素は、データベースエンジンによって実行される構成要素と、別個の分散されたデータベース最適化ストレージシステムで実行される構成要素との間で仕切られてよい。１つの特定の例では、（例えば、単一のデータブロックを、そのデータブロックにレコードを追加することによって更新するために）何かをデータベーステーブルに挿入する要求をクライアントプロセス（またはクライアントプロセスのスレッド）から受信することに応えて、データベースエンジンヘッドノードの１つまたは複数の構成要素は、クエリーパーシング、最適化、及び実行を実行してよく、クエリーの各部分をトランザクション及び一貫性管理構成要素に送信してよい。トランザクション及び一貫性管理構成要素は、他のクライアントプロセス（またはクライアントプロセスのスレッド）が同時に同じ行を修正しようとしていないことを保証してよい。例えば、トランザクション及び一貫性管理構成要素は、この変更がデータベースにおいて原子的に、一貫して、耐久的に、及び独立して実行されることを保証することに責任を負ってよい。例えば、トランザクション及び一貫性管理構成要素は、分散型データベース最適化ストレージサービスのノードの１つに送信されるリドゥログレコードを生成し、ＡＣＩＤプロパティがこのトランザクションについて満たされていることを保証する順序で及び／またはタイミングでリドゥログレコードを（他のクライアント要求に応えて生成される他のリドゥログとともに）分散型データベース最適化ストレージサービスに送信するために、データベースエンジンヘッドノードのクライアント側ストレージサービスドライバとともに機能してよい。対応するストレージノードは、（更新レコードとも呼ばれてよい）リドゥログレコードを受信すると、データブロックを更新し、データブロックのリドゥログを更新してよい（例えば、データブロックに向けられるすべての変更のレコード）。いくつかの実施形態では、データベースエンジンは、この変更のためにアンドゥログレコードを生成することに責任を負ってよく、アンドゥログのためのリドゥログレコードを生成することにも責任を負ってよく、この両方ともトランザクション性を保証するために（データベース階層で）ローカルに使用されてよい。ただし、従来のデータベースシステムにおいてとは異なり、本明細書に説明されるシステムは、（変更をデータベース階層で適用し、修正されたデータブロックをストレージシステムに送るよりむしろ）データブロックに変更を適用するための責任をストレージシステムに移してよい。さらに、図８から図９で本明細書に説明されるように、多様な実施形態では、スナップショット動作及び／またはログ操作はストレージシステムによっても実行されてよい。

異なる実施形態で、さまざまな割当てモデルがＳＳＤのために実装されてよい。例えば、いくつかの実施形態では、ログエントリページ及び物理アプリケーションページが、ＳＳＤデバイスと関連付けられたページの単一のヒープから割り当てられてよい。この手法は、未指定のままとなるために、および自動的に使用に適合するためにログページ及びデータページによって消費される相対的な記憶量を残すという優位点を有してよい。また、手法は、ページが使用され、準備なしに随意に転用されるまでページを準備されないままにできるという優位点も有してよい。他の実施形態では、割当てモデルはストレージデバイスをログエントリ及びデータページのための別々のスペースに仕切ってよい。一度係る割当てモデルが図６のブロック図に示され、以下に説明される。

図６は、一実施形態に係る、分散型データベース最適化ストレージシステムの所与のストレージノード（または永続ストレージデバイス）にデータ及びメタデータがどのように記憶されてよいのかを示すブロック図である。この例では、ＳＳＤストレージスペース６００は、６１０と名前が付けられたスペースの部分にＳＳＤヘッダ及び他の固定メタデータを記憶する。ＳＳＤストレージスペース６００は、６２０と名前が付けられたスペースの部分にログページを記憶し、追加のログページのために初期化され、確保される、６３０と名前が付けられたスペースを含む。（６４０として示される）ＳＳＤストレージスペース６００の一部分は初期化されているが、割り当てられておらず、（６５０として示される）スペースの別の部分は初期化されておらず、割り当てられていない。最後に、６６０と名前が付けられたＳＳＤストレージスペース６００の部分はデータページを記憶する。

この例では、最初の使用可能なログページスロットは６１５として示され、最後の使用されたログページスロット（一時的）は６２５として示される。最後の確保されたログページスロットは６３５として示され、最後の使用可能なログページスロットは６４５として示される。この例では、最初の使用されたデータページスロット（一時的）は６６５として示される。いくつかの実施形態では、ＳＳＤストレージスペース６００の中でのこれらの要素（６１５、６２５、６３５、６４５、及び６６５）のそれぞれの位置は、それぞれのポインタによって識別されてよい。

図６に示される割当て手法では、有効なログページはフラットストレージスペースの始まりにパックされてよい。ログページが解放されるために開く穴は、アドレススペースのさらに先に入る追加のログページスロットが使用される前に再使用されてよい。例えば、最悪の場合、最初のｎ個のログページスロットが有効なログデータを含み、この場合、ｎは今まで同時に存在した有効なログページの最大数である。この例では、有効データページはフラットストレージスペースの最後にパックされてよい。データページが解放されることにより開く穴は、アドレススペースでより下方の追加のデータページスロットが使用される前に再使用されてよい。例えば、最悪の場合、最後のｍのデータページが有効なデータを含み、この場合ｍは今まで同時に存在した有効なデータページの最大数である。

いくつかの実施形態では、ログページスロットが有効なログページエントリの潜在的なセットの部分になることができる前に、ログページスロットは有効な将来のログエントリページのために混同できない値に初期化されなければならない。廃棄されたログページは新しい有効なログページについて絶対に混同されることがないほど十分なメタデータを有するので、これは、リサイクルされるログページスロットに暗黙に当てはまる。ただし、ストレージデバイスが最初に初期化されるとき、またはアプリケーションデータページを記憶するために潜在的に使用されたスペースが再利用されるとき、ログページスロットは、ログページスロットがログページスロットプールに加えられる前に初期化されなければならない。いくつかの実施形態では、ログスペースのバランスを取り戻す／再利用することは、バックグラウンドタスクとして実行されてよい。

図６に示される例では、カレントログページスロットプールは（６１５で）最初の使用可能なログページスロットと最後の確保されたログページスロット（６２５）との間に領域を含む。いくつかの実施形態では、このプールは、（例えば、最後の確保されたログページスロット６３５を識別するポインタに対する更新を持続させることによって）新しいログページスロットの再初期化なしに最後の使用可能なログページスロット（６２５）まで安全に増大してよい。この例では、（ポインタ６４５によって識別される）最後の使用可能なログページスロットを超えて、プールは、初期化されたログページスロットを持続し、最後の使用可能なログページスロット（６４５）のためのポインタを持続的に更新することによって、（ポインタ６６５によって識別される）最初の使用されたデータページスロットまで成長してよい。この例では、６５０として示される、ＳＳＤストレージスペース６００の以前に初期化されておらず、割り当てられていない部分は、ログページを記憶するためにとりあえず利用されてよい。いくつかの実施形態では、カレントログページスロットプールは、最後の確保されたログページスロット（６３５）のポインタに対する更新を持続することによって（ポインタによって識別される）最後の使用されたログページスロットの位置まで縮小されてよい。

図６に示される例では、カレントデータページスロットプールは、（ポインタ６４５によって識別される）最後の使用可能なログページスロットと、ＳＳＤストレージスペース６００の最後との間に領域を含む。いくつかの実施形態では、データページプールは、最後の使用可能なログページスロット（６４５）のポインタに対する更新を持続するによって、最後の確保されたログページスロット（６３５）に対するポインタによって識別される位置まで安全に成長してよい。この例では、６４０として示される、ＳＳＤストレージスペース６００の以前に初期化されたが、割り当てられていない部分は、データページを記憶するためにとりあえず利用されてよい。これを超えて、プールは、最後の確保されたログページスロット（６３５）及び最後の使用可能なログページスロット（６４５）のポインタに対する更新を持続し、ログページよりむしろデータページを記憶するために、６３０及び６４０として示されるＳＳＤストレージスペース６００の部分を効果的に割り当てし直すことによって、最後の使用されたログページスロット（６２５）のポインタによって識別される位置まで安全に成長してよい。いくつかの実施形態では、データページスロットプールは、追加のログページスロットを初期化し、最後の使用可能なログページスロット（６４５）のポインタに対する更新を持続することによって、最初の使用されたデータページスロット（６６５）のポインタによって識別される位置まで安全に縮小されてよい。

図６に示される割当て手法を利用する実施形態では、ログページプール及びデータページプールのページサイズは、優れたパッキング挙動を容易にしつつも、独立して選択されてよい。係る実施形態では、有効なログページが、アプリケーションデータによって形成されるスプーフィングされたログページにリンクする可能性はないことがあり、壊れたログと依然として書き込まれていない次のページにリンクする有効なログテールとを区別することが可能なことがある。図６に示される割当て手法を利用する実施形態では、起動時、最後の確保されたログページスロット（６３５）に対するポインタによって識別される位置までのログページスロットのすべてが迅速に且つ連続して読み取られてよく、（推論されるリンキング／順序付けを含む）ログインデックス全体が再構築されてよい。係る実施形態では、すべてはＬＳＮ順序制御制約から推論できるので、ログページ間の明示的なリンキングの必要性がないことがある。

いくつかの実施形態では、セグメントは３つの主要な部分（またはゾーン）、つまり、ホットログを含む部分、コールドログを含む部分、及びユーザーページデータを含む部分から構成されてよい。ゾーンは、必ずしもＳＳＤの隣接領域ではない。むしろ、ゾーンは、記憶ページの粒度で点在することがある。さらに、セグメント及びそのプロパティについてのメタデータを記憶するセグメントごとにルートページがあってよい。例えば、セグメントのルートページはセグメントのためのユーザーページサイズ、セグメント内のユーザーページの数、（フラッシュ番号（ｆｌｕｓｈ ｎｕｍｂｅｒ）の形で記録されてよい）ホットログゾーンの現在の始まり／ヘッド、ボリュームエポック、及び／またはアクセス制御メタデータを記憶してよい。

いくつかの実施形態では、ホットログゾーンは、それらがストレージノードによって受信されるにつれ、クライアントからの新しい書込みを受け入れてよい。ページの以前のバージョンからのデルタの形をとるユーザーページ／データページに対する変更を指定するデルタユーザーログレコード（ＤＵＬＲ）及び完全なユーザーページ／データページのコンテンツを指定する絶対ユーザーログレコード（ＡＵＬＲ）の両方とも、ログに完全に書き込まれてよい。ログレコードは、ほぼ、ログレコードが受信され（例えば、ログレコードがＬＳＮによってソートされるのではない）、それらがログページに渡って広がることがある順序でこのゾーンに追加されてよい。例えばログレコードは独自のサイズの表示を含んでよい等、ログレコードは自己記述的である必要がある。いくつかの実施形態では、ガベージコレクションはこのゾーンで実行されない。代わりに、スペースは、すべての必要とされるログレコードがコールドログにコピーされた後にログの始まりから切り詰めることによって再利用されてよい。ホットゾーンのログセクタは、セクタが作成されるたびに最も最近の既知の無条件ＶＤＬで注釈されてよい。条件付きのＶＤＬ ＣＬＲは、それらが受信されるにつれホットゾーンに書き込まれてよいが、最も最近に書き込まれたＶＤＬ ＣＬＲだけが意味を持ってよい。

いくつかの実施形態では、新しいログページが書き込まれるたびに、新しいログページにはフラッシュ番号が割り当てられる。フラッシュ番号は、各ログページの中のあらゆるセクタの部分として書き込まれてよい。フラッシュ番号は、２つのログページを比較するときに、どのログページが後に書き込まれたのかを決定するために使用されてよい。フラッシュ番号は単調に増加し、ＳＳＤ（またはストレージノード）に対して調べられて（ｓｃｏｐｅｄ）よい。例えば、単調に増加するフラッシュ番号のセットは、ＳＳＤ上のすべてのセグメント（またはストレージノード上のすべてのセグメント）の間で共有される。

いくつかの実施形態では、コールドログゾーンで、ログレコードはそのＬＳＮの昇順で記憶されてよい。このゾーンでは、ＡＵＬＲはそのサイズに応じて必ずしもデータをインラインで記憶しないことがある。例えば、ＡＵＬＲが大きなペイロードを有する場合、ペイロードのすべてまたは一部がデータゾーンに記憶されてよく、ＡＵＬＲはそのデータがデータゾーンのどこに記憶されているのかを指してよい。いくつかの実施形態では、コールドログゾーンのログページは、セクタ単位でよりむしろ、一度に１全ページ、書き込まれてよい。コールドゾーンのログページは一度に全ページ書き込まれるため、全セクタ内のフラッシュ番号が同一ではないコールドゾーンのどのようなログページも不完全に書き込まれたページと見なされてよく、無視されてよい。いくつかの実施形態では、コールドログゾーンでは、ＤＵＬＲは（最大２ログページまで）複数のログページに及ぶことができることがある。しかし、ＡＵＬＲは、例えば合体動作が単一の原子的な書込みでＤＵＬＲをＡＵＬＲで置き換えることができるように、複数のログセクタに及ぶことができないことがある。

いくつかの実施形態では、コールドログゾーンは、ホットログゾーンからログレコードをコピーすることによってポピュレートされる。係る実施形態では、ＬＳＮが現在の無条件ボリューム耐久性ＬＳＮ（ＶＤＬ）以下であるログレコードだけがコールドログゾーンにコピーされる資格があってよい。ホットログゾーンからコールドログゾーンにログレコードを移動するとき、（多くのＣＬＲ等の）いくつかのログレコードは、それらがもはや必要ではないため、コピーされる必要がないことがある。さらにユーザーページのなんらかの追加の合体がこの点で実行されてよく、このことが必要とされるコピーの量を削減してよい。いくつかの実施形態では、いったん所与のホットゾーンログページが完全に書き込まれ、もはや最新のホットゾーンログページではなく、ホットゾーンログページ上のすべてのＵＬＲがコールドログゾーンに無事にコピーされると、ホットゾーンログページは解放され、再使用されてよい。

いくつかの実施形態では、例えば記憶階層のＳＳＤにもはや記憶される必要のないログレコード等、もはやサポートされていないログレコードによって占められているスペースを再利用するために、ガベージコレクションがコールドログゾーンで行われてよい。例えば、ログレコードは同じユーザーページに対する以後のＡＵＬＲがあるときにサポートされなくなってよく、ログレコードによって表されるユーザーページのバージョンはＳＳＤでの保持に必要とされない。いくつかの実施形態では、ガベージコレクションプロセスは、２つ以上の隣接するログページをマージし、２つ以上の隣接するログページをそれらのページが置き換えているログページからの旧式ではないログレコードのすべてを含むより少ない新しいログページで置き換えることによってスペースを再利用してよい。新しいログページには、それらが置き換えているログページのフラッシュ番号よりも大きい新しいフラッシュ番号が割り当てられてよい。これらの新しいログページの書込みが完了した後に、置き換えられたログページが空きページプールに加えられてよい。いくつかの実施形態では、あらゆるポインタを使用するログページの明示的な連鎖がないことがあることに留意されたい。代わりに、ログページのシーケンスはそれらのページに対するフラッシュ番号によって暗黙に決定されてよい。ログレコードの複数のコピーが検出されるたびに、最高のフラッシュ番号のログページに存在するログレコードが有効であると見なされてよく、他はもはやサポートされないと見なされてよい。

いくつかの実施形態では、例えば、データゾーン（セクタ）の中で管理されるスペースの粒度がデータゾーン（記憶ページ）の外の粒度とは異なってよいため、なんらかのフラグメンテーションがあってよい。いくつかの実施形態では、このフラグメンテーションを管理するために、システムは各データページによって使用されるセクタの数を追跡調査してよく、ほぼ全データページから優先的に割り当ててよく、ほぼ空のデータページを優先的にガベージコレクトする（データを新しい場所に、それが依然として関連している場合に移動することを必要としてよい）。セグメントに割り当てられるページが、いくつかの実施形態では３つのゾーンの間で転用されてよいことに留意されたい。例えば、セグメントに割り当てられていたページが解放されると、ページはある期間そのセグメントと関連付けられたままとなってよく、後にそのセグメントの３つのゾーンのいずれかで使用されてよい。あらゆるセクタのセクタヘッダは、セクタが属するゾーンを示してよい。いったんページ内のすべてのセクタが空くと、ページは、ゾーンに渡って共有される共通の空き記憶ページプールに返されてよい。この空き記憶ページの共有は、いくつかの実施形態では、フラグメンテーションを削減（または回避）してよい。

いくつかの実施形態では、本明細書に説明される分散型データベース最適化ストレージシステムは、メモリ内に多様なデータ構造を維持してよい。例えば、セグメントに存在するユーザーページごとに、ユーザーページテーブルが、このユーザーページが「クリアされる」かどうか（つまり、このユーザーページがすべてのゼロを含んでいるかどうか）、該ページのためのコールドログゾーンからの最新のログレコードのＬＳＮ、及びページのホットログゾーンからのすべてのログレコードの場所のアレイ／リストを示すビットを記憶してよい。ログレコードごとに、ユーザーページテーブルはセクタ番号、そのセクタの中のログレコードのオフセット、そのログページの中で読み取るセクタの数、（ログレコードが複数のログページに及ぶ場合）第２のログページのセクタ番号、及びそのログページの中で読み取るセクタの数を記憶してよい。いくつかの実施形態では、ユーザーページテーブルは、コールドログゾーンからのあらゆるログレコードのＬＳＮ、及び／またはＡＵＬＲがコールドログゾーンにある場合、最新のＡＵＬＲのペイロードのセクタ番号のアレイを記憶してもよい。

本明細書に説明される分散型データベース最適化ストレージシステムのいくつかの実施形態では、ＬＳＮインデックスはメモリに記憶されてよい。ＬＳＮインデックスは、コールドログゾーンの中のログページにＬＳＮをマッピングしてよい。コールドログゾーンのログレコードがソートされていることを考えれば、それはログページあたり１つのエントリを含むためであってよい。ただし、いくつかの実施形態では、あらゆる旧式ではないＬＳＮがインデックスに記憶され、対応するセクタ番号、オフセット、及びログレコードごとのセクタの数にマッピングされてよい。

本明細書に説明される分散型データベース最適化ストレージシステムのいくつかの実施形態では、ログページテーブルはメモリに記憶されてよく、ログページテーブルはコールドログゾーンのガベージコレクションの間に使用されてよい。例えば、ログページテーブルはどのログレコードがもはやサポートされていないのか（例えば、どのログレコードのガベージコレクションを行うことができるのか）、及び各ログページでどれほど多くの空きスペースが使用できるのかを識別してよい。

本明細書に説明されるストレージシステムでは、エクステントは、ボリュームを表すために他のエクステントと結合できる（連結できる、またはストライピングできるのかのどちらか）ストレージの高度に耐久性の単位を表す論理概念であってよい。各エクステントは、単一の保護グループでのメンバーシップによって耐久的にされてよい。エクステントは、ＬＳＮ型の読取り／書込みインタフェースを、作成時に定義される固定サイズを有する隣接バイトサブレンジに提供してよい。エクステントに対する読取り／書込み動作は、含む側の保護グループによって１つまたは複数の適切なセグメント読取り／書込み動作にマッピングされてよい。本明細書に使用されるように、用語「ボリュームエクステント」は、ボリュームの中のバイトの特有のサブレンジを表すために使用されるエクステントを指してよい。

上述されたように、ボリュームは、それぞれが１つまたは複数のセグメントから構成される保護グループによって表される複数のエクステントから構成されてよい。いくつかの実施形態では、異なるエクステントに向けられるログレコードはインタリーブされたＬＳＮを有してよい。ボリュームに対する変更が特定のＬＳＮまで耐久的となるためには、そのＬＳＮまでのすべてのログレコードが、それらが属しているエクステントに関わりなく耐久的である必要があってよい。いくつかの実施形態では、クライアントは、まだ耐久的にされていない未決ログレコードを追跡調査してよく、いったん特定のＬＳＮまでのすべてのＵＬＲが耐久的にされると、クライアントはボリュームの保護グループの内の１つにボリューム耐久性ＬＳＮ（ＶＤＬ）メッセージを送信してよい。ＶＤＬは、保護グループのすべての同期ミラーセグメントに書き込まれてよい。これは「無条件ＶＤＬ」と呼ばれることがあり、それはセグメントで起こる書込み活動とともに多様なセグメントに（またはより詳細には、多様な保護グループに）周期的に持続されてよい。いくつかの実施形態では、無条件ＶＤＬはログセクタヘッダに記憶されてよい。

多様な実施形態では、セグメントで実行されてよい動作は、（ホットログゾーンの末尾にＤＵＬＲまたはＡＵＬＲを書き込み、次いでユーザーページテーブルを更新することを含んでよい）クライアントから受信されたＤＵＬＲまたはＡＵＬＲを書き込むこと、（ユーザーページのデータセクタの位置を突き止め、あらゆる追加のＤＵＬＲを適用する必要なしにデータセクタを返すことを含んでよい）コールドユーザーページを読み取ること、（ユーザーページの最も最新のＡＵＬＲのデータセクタの位置を突き止めることを含み、ユーザーページに、それを返す前にあらゆる以後のＤＵＬＲを適用してよい）ホットユーザーページを読み取ること、（適用された最後のＤＵＬＲを置き換えるＡＵＬＲを作成するためにユーザーページのＤＵＬＲを合体させることを含んでよい）ＤＵＬＲをＡＵＬＲで置き換えること、ログレコードを操作すること等を含んでよい。本明細書に説明されるように、合体は、ユーザーページのより最近のバージョンを作成するためにユーザーページの初期のバージョンにＤＵＬＲを適用するプロセスである。（別のＤＵＬＲが書き込まれるまで）合体の前に書き込まれたすべてのＤＵＬＲは要求に応じて読み取られ、適用される必要はないことがあるため、ユーザーページを合体させることは読取りレーテンシを削減するのに役立ってよい。また、合体は、（ログレコードが存在することを必要とするスナップショットがないならば）旧いＡＵＬＲ及びＤＵＬＲをもはやサポートされなくすることによってストレージスペースを再利用するのに役立ってよい。いくつかの実施形態では、合体動作は、最も最新のＡＵＬＲを場所を見つけ、ＤＵＬＲのいずれも省略することなく、あらゆる以後のＤＵＬＲを順番に適用することを含んでよい。上述されたように、いくつかの実施形態では、合体はホットログゾーンの中で実行されないことがある。代わりに、合体はコールドログゾーンの中で実行されてよい。いくつかの実施形態では、合体は、ログレコードがホットログゾーンからコールドログゾーンにコピーされるにつれて実行されてもよい。

いくつかの実施形態では、ユーザーページを合体させる決定は、（例えば、ＤＵＬＲチェーンの長さが合体動作の所定の閾値を超える場合、システム全体での方針、アプリケーション特有の方針、またはクライアントによって指定される方針に従って））、またはクライアントに読み取られているユーザーページごとに、ページの未決のＤＵＬＲチェーンのサイズによってトリガされてよい。

図７は、一実施形態に係る、データベースボリューム７１０の例の構成を示すブロック図である。この例では、（アドレス範囲７１５ａから７１５ｅとして示される）多様なアドレス範囲７１５のそれぞれに対応するデータが（セグメント７４５ａから７４５ｎとして示される）異なるセグメント７４５として記憶される。すなわち、多様なアドレス範囲７１５のそれぞれに対応するデータは（エクステント７２５ａから７２５ｂ、及びエクステント７３５ａから７３５ｈとして示される）異なるエクステントに編成されてよく、これらのエクステントの多様なエクステントが、（ストライプセット７２０ａ及びストライプセット７２０ｂとして示されるもの等の）ストライピングを行って、または行わないで（７３０ａから７３０ｆとして示される）異なる保護グループ７３０に含まれてよい。この例では、保護グループ１はイレイジャーコーディングの使用を示す。この例では、保護グループ２及び３、並びに保護グループ６及び７は互いのミラーリングされたデータセットを表す。一方、保護グループ４は単一インスタンス（非冗長）データセットを表す。この例では、保護グループ８は、他の保護グループを結合する複数階層保護グループを表す（例えば、これは複数領域保護グループを表してよい）。この例では、ストライプセット１（７２０ａ）及びストライプセット２（７２０ｂ）は、いくつかの実施形態で、エクステント（例えば、エクステント７２５ａ及び７２５ｂ）がどのようにしてボリュームの中にストライピングされてよいのかを示す。

すなわち、この例では、保護グループ１（７３０ａ）は、それぞれ範囲１から３（７１５ａから７１５ｃ）のデータを含むエクステントａからｃ（７３５ａから７３５ｃ）を含み、これらのエクステントはセグメント１から４（７４５ａから７４５ｄ）にマッピングされる。保護グループ２（７３０ｂ）は、範囲４（７１５ｄ）からストライピングされたデータを含むエクステントｄ（７３５ｄ）を含み、このエクステントはセグメント５から７（７４５ｅから７４５ｇ）にマッピングされる。同様に、保護グループ３（７３０ｃ）は、範囲４（７１５ｄ）からストライピングされたデータを含むエクステントｅ（７３５ｅ）を含み、セグメント８から９（７４５ｈから７４５ｉ）にマッピングされ、保護グループ４（７３０ｄ）は、範囲４（７１５ｄ）からストライピングされたデータを含むエクステントｆ（７３５ｆ）を含み、セグメント１０（７４５ｊ）にマッピングされる。この例では、保護グループ６（７３０ｅ）は、範囲５（７１５ｅ）からストライピングされたデータを含むエクステントｇ（７３５ｇ）を含み、セグメント１１から１２（７４５ｋから７４５ｌ）にマッピングされ、保護グループ７（７３０ｆ）は、やはり範囲５（７１５ｅ）からストライピングされたデータを含むエクステントｈ（７３５ｈ）を含み、セグメント１３−１４（７４５ｍから７４５ｎ）にマッピングされる。

ここで図８を参照すると、多様な実施形態で、データベースシステム４００は、スナップショットを作成する、削除する、修正する、及び／またはそれ以外の場合使用するように構成されてよい。図８の方法は、分散型データベース最適化ストレージシステム４１０（例えば、ストレージシステムサーバノード（複数の場合がある）４３０、４４０、４５０等）のログ構造化ストレージシステムの多様な構成要素によって実行されているとして説明されてよいが、方法はいくつかの場合、いずれの特定の構成要素によっても実行される必要もない。例えば、いくつかの場合、図８の方法は、いくつかの実施形態に従ってなんらかの他の構成要素またはコンピュータシステムによって実行されてよい。また、いくつかの場合、データベースシステム４００の構成要素は、図４の例に示されるのとは異なって組み合されてよい、または存在してよい。多様な実施形態では、図８の方法は分散型データベース最適化ストレージシステムの１台または複数のコンピュータによって実行されてよく、その内の１つは図１０のコンピュータシステムとして示される。図８の方法は、スナップショットの作成、削除、修正、使用等のための方法の１つの例の実装として示される。他の実装では、図８の方法は追加のブロック、または図示されるよりも少ないブロックを含んでよい。

８１０で、それぞれがデータベースサービスによって記憶される／維持されるデータに対するそれぞれの変更と関連付けられている複数のログレコードが維持されてよい。多様な実施形態では、ログレコードによって表される変更は、データベースサービスの分散型データベース最適化ストレージシステムのストレージシステムサービスノード４３０によって記憶されてよい。本明細書に説明されるように、一実施形態では、ログレコードは、データベースサービスのデータベースエンジンヘッドノードから、分散型データベース最適化ストレージシステムによって受信されてよい。他の実施形態では、ログレコードは、分散型データベース最適化ストレージシステムとは別個であるデータベースサービスの別の構成要素から受信されてよい。

一実施形態では、各ログレコードは、本明細書に説明されるように、順次に順序付けられた識別子（例えば、ログシーケンス番号（「ＬＳＮ」）等のそれぞれの識別子と関連付けられてよい。ログレコードは、ログレコードが受信される時刻でそれぞれのＬＳＮと関連付けられてよい、またはストレージシステムは所与のログレコードに、それが受信された順序でＬＳＮを割り当ててよい。

複数のログレコードが対応するデータは、（例えば、図４のデータページ（複数の場合がある）４３３、４４３、もしくは４５３の内の）単一のデータページ、または多くのデータページであってよい。複数のログレコードがＬＳＮ１から４を有する４つのログレコードを含むシナリオを考える。ある例では、ＬＳＮ１から４のそれぞれがデータページＡに関連する。または、別の例では、ＬＳＮ１及びＬＳＮ３がデータページＡに関連し、ＬＳＮ２及び４がデータページＢに関連してよい。この例では、それぞれの特定のログレコードが単一のユーザー／データページと関連付けられてよい（例えば、ＬＳＮ１−ページＡ、ＬＳＮ２−ページＢ等）ことに留意されたい。

多様な実施形態では、ログレコードは図４のストレージシステムサーバノード４３０、４４０、及び４５０等の多様なノード全体で分散して記憶されてよいことに留意されたい。いくつかの実施形態では、ログレコードの単一のコピーが単一のノードに記憶されてよい、または他の例の間では、単一のコピーは複数のノードに記憶されてよい。４つのログレコードの例を上記から続けると、ＬＳＮ１が付いたログレコードはノード４３０及びノード４４０の両方に記憶されてよく、ＬＳＮ２はノード４３０に記憶されてよく、ＬＳＮ３及びＬＳＮ４は３つすべてのノード４３０、４４０、及び４５０に記憶されてよい。係る例では、多様なノード及び／またはミラーのすべてがログレコードの完全なセットにより最新ではないことがある。図９に説明されるように、ログレコード操作は多様なノードに記憶されるログレコード間の差異を調整することを容易にするために実行されてよい。

いくつかの実施形態では、所与のログレコードがどこに記憶されるのか（例えば、どの１つのノードまたは複数のノード）は、データベースエンジンヘッドノードによって決定されてよく、分散型データベース最適化ストレージシステムに提供されるルーティング情報として含まれてよい。代わりにまたは加えて、分散型データベース最適化ストレージシステムは、どの１つのノードまたは複数のノードに所与のログレコードを記憶するのかを決定してよい。一実施形態では、分散型データベース最適化ストレージシステムによる係る決定は、多様なノードの間でログレコードをほぼ釣り合いをとって分散することによって性能を最大限にすることであってよい。一実施形態では、分散型データベース最適化ストレージシステムによる係る決定は、ログレコードの重要さに依存してよい。例えば、あまり重要ではないデータページと関連付けられたＤＵＬＲが単一のノードにしか記憶されないことがあるのに対し、重要な（例えば、頻繁にアクセスされる）データページのＡＵＬＲは複数のノードに記憶されてよい。

本明細書に説明されるように、ログレコードはＤＵＬＲ及びＡＵＬＲを含んでよい。多様な実施形態では、アプリケーション、データベースサービス、及び／またはデータベースサービスのユーザー（または他の構成要素）が、データページに対する所与の変更のためにＤＵＬＲを作成するのか、それともＡＵＬＲを作成するのかを決定してよい。例えば、データベースサービスは、所与のデータページのための１０のログレコードごとに少なくとも１つがＡＵＬＲであることを保証してよい。係る例で、所与のデータページの行の９つのログレコードがＤＵＬＲである場合、次いでデータベースサービスは、次のログレコードがＡＵＬＲであることを指定してよい。

さらに、多様な実施形態では、ボリューム中の各データページがＡＵＬＲを必要とすることがある。したがって、データページの最初の書込みの場合、ログレコードがＡＵＬＲであってよい。一実施形態では、システム開始の一部として、各データページが該データページをＡＵＬＲとして初期化するために、特定の値（例えば、すべてゼロ）に書き込まれることがある。データベースの以後の書込みがＤＵＬＲであってよいように、すべてゼロのＡＵＬＲで十分であってよい。

８２０で示されるように、スナップショットが生成されてよい。多様な実施形態では、スナップショットを生成することは、特定のログレコードのログ識別子（例えば、ＬＳＮ）を示すメタデータを生成することを含んでよい。いくつかの例では、他の特定のログレコードの１つまたは複数の他のログ識別子を示すメタデータも生成されてよい。ログレコード（複数の場合がある）のログ識別子（複数の場合がある）を示す係るメタデータは、それらの特定のログレコードが、そのスナップショットのために（そのスナップショットが削除される、または置き換えられるまで）（例えば、削除されない、またはガベージコレクトされない等）保存されるべきであることを示してよい。

いくつかの実施形態では、生成されたメタデータはスナップショット識別子を示してもよい。例のスナップショット識別子は、スナップショットと関連付けられた連番、名前、時刻の内の１つまたは複数を含んでよい。例えば、特定のスナップショットはＳＮ１と呼ばれてよい、及び／または２００５年１２月２２日、ＧＭＴ１４：００．００（午後２時きっかり）のタイムスタンプを有してよい。

多様な実施形態では、スナップショットと関連付けられるメタデータは、１つまたは複数のログレコードがガベージコレクトされるのを防ぐために使用可能であってよい。例えば、メタデータは、スナップショットと関連付けられたログレコード／ＬＳＮまでの所与のページを作成し直すために必要とされる１つまたは複数のログレコードを示してよい。結果として、メタデータが、データページ（複数の場合がある）がスナップショットと関連付けられたＬＳＮまで生成できることを保証してよい。

多様な実施形態では、メタデータはさまざまな異なる場所に記憶されてよい。例えば、メタデータは各ログレコードの中に記憶されてよく、ガベージコレクションステータスからのそのそれぞれのログレコードの保護を示してよい。例えば、ＬＳＮ２、ＬＳＮ３、及びＬＳＮ４を有するログレコードが特定のスナップショットのためにガベージコレクトされるべきではない場合、次いでＬＳＮ２、ＬＳＮ３、及びＬＳＮ４でのログレコードと関連付けられたメタデータは、ＬＳＮ２、ＬＳＮ３、及びＬＳＮ４でのログレコードがガベージコレクトされるべきではないことを示す必要がある。別の例として、スナップショットメタデータは分散型データベース最適化ストレージシステムのより高いレベルで（例えば、セグメント、ボリューム、又はログレコードのレベルで、または他で等）記憶されてよく、複数のログレコードのガベージコレクションステータスの内のステータスを示してよい。係る例では、メタデータは、スナップショットごとに保持される必要のあるログレコードに対応するＬＳＮのリストを含む。以後のスナップショットを撮ると、保持されるログレコード（複数の場合がある）が変化することがあることに留意されたい。結果として、ログレコードの内の特定のログレコードに対応するメタデータも変化することがある。例えば、ＬＳＮ２、ＬＳＮ３、及びＬＳＮ４は、将来のスナップショットのためにもはや保持される必要はないことがある。したがって、係る例では、メタデータは、ＬＳＮ２、ＬＳＮ３、及びＬＳＮ４に対応するログレコードが保持される必要があることをメタデータがもはや示さないように修正されてよい。

一実施形態では、メタデータは、どのログレコードがガベージコレクション可能ではないのかをはっきりと示してよい、またはメタデータは代わりにスナップショットに対応する特定のＬＳＮとともに（以下に説明される）スナップショットタイプを示してよい。係る実施形態では、分散型データベース最適化ストレージシステムのガベージコレクションプロセスは、スナップショットタイプ及び特定のＬＳＮから、どのログレコードがガベージコレクション可能であるのか、及びどのログレコードがガベージコレクション可能でないのかを決定してよい。例えば、ガベージコレクションプロセスは、特定のＬＳＮと関連付けられたログレコード、及びそのデータページのための以前のＡＵＬＲまで戻る各ＤＵＬＲがガベージコレクション可能ではないと決定してよい。

多様な実施形態では、スナップショットは特定の１つのデータページに特有であってよい、またはスナップショットは複数のデータページ（例えば、セグメント、ボリューム）に特有であってよい。

一実施形態では、メタデータは、本明細書に説明されるように、スナップショットのタイプ（例えば、スナップショットが連続スナップショットであるのか、それとも不連続スナップショットであるのか）を示してよい。スナップショットのタイプはメタデータに直接的に示されてよい（例えば、連続または不連続）、またはスナップショットのタイプは間接的に示されてよい（例えば、どのログレコード（複数の場合がある）がガベージコレクション不可と示されるのかが、スナップショットが連続であるのか、それとも不連続であるのかを示してよい）。例えば、不連続スナップショットがガベージコレクション可能ではないログレコード（複数の場合がある）の異なる（例えば、より小さい）セットを示すことがあるのに対して、連続スナップショットはガベージコレクション可能ではないログレコード（複数の場合がある）の１つのセットを示すことがある。いくつかの状況では、連続スナップショット及び不連続スナップショットはログレコード（複数の場合がある）の同じセットを示すメタデータを有することがある。例えば、ＡＵＬＲに対応する時点で撮られるデータページのスナップショットの場合、連続スナップショット及び不連続スナップショットが、ともにＡＵＬＲだけがガベージコレクションから保護される必要があることを示すメタデータを含むことがある。

連続スナップショットは、連続スナップショットの時刻と、以前の時刻（例えば最も最近のＡＵＬＲ）との間の各時点までデータを復元するために使用できてよい。対照的に、不連続スナップショットは、スナップショットの時点での状態までデータを復元するために再使用可能であってよい。例えば、そのデータページの後に３つのデルタログレコードがあり、続いてデータページ（ＡＵＬＲ）の新しいバージョン及びデータページのその新しいバージョンのためのさらに３つのデルタログレコードが続くデータページ（ＡＵＬＲ）の例を考える。データを復元するためにスナップショットを使用することは、本明細書では、データの以前のバージョンをコピーすることなく、スナップショットの時点のデータを読み取ることを説明するために使用される。不連続スナップショットがエントリのすべて（ＡＵＬＲ及び６つすべてのＤＵＬＲ）の後の時点で撮られる場合には、ガベージコレクション不可として示されてよいログエントリはデータページの新しいバージョン、及びそのデータページの後の３つのログエントリを含む。連続スナップショットが、現在のスナップショットの時点からデータページの最初のバージョンの時点までに撮られる場合には、ガベージコレクション不可として示されてよいログエントリは最初のデータページ及び６つすべてのログレコードを含む。中間のインスタンス化されたブロック（例えば、データページ（ＡＵＬＲ）の新しいバージョン）は、それがデータページの最初のバージョン及び最初の３つのログレコードで作成し直すことができるため、ガベージコレクション不可として示されないことがあることに留意されたい。この例では、不連続スナップショットが、スナップショットの時点まで、及びスナップショットの時点と、スナップショットの前の最も最近のＡＵＬＲとの間の各時点までデータページを復元するために使用できるのに対し、連続スナップショットは、ログレコードが存在する時点のいずれかまでデータページを復元するために使用できることにも留意されたい。

いくつかの実施形態では、スナップショットの生成は、オフボリュームバックアップ戦略を利用するときに必要とされるように、データブロックの追加の読取り、コピー、または書き込みなしで実行されてよい。したがって、スナップショットは、スナップショット生成がデータのバックアップをとることを必要としないようにインプレースで生成されてよい。データがどこか他でも記憶されるデータのバックアップが発生してよいが、係る発生はスナップショット生成プロセスの外で実行されてよいことに留意されたい。例えば、クライアントがデータの複数のコピーが別々の記憶場所に記憶されることを要求することがある。

８３０で示されるように、データはスナップショットに対応する状態の時点で読み取られてよい。例えば、ユーザーがテーブルを削除したが、そのテーブルを戻すことを希望する場合、スナップショットは、テーブルが再び利用できるようにデータ（例えば、データページ、セグメント、ボリューム等）を読み取る／復元するために使用できる。スナップショットを読み取る／復元することが、スナップショットの時点の後に実行されたなんらかのデータ／作業を失うことを含むことがあり、読取り／復元プロセスの一部としてデータの以前のバージョンのコピーを作成することを含まないことがあることに留意されたい。

スナップショットに対応する状態までデータを復元することは、データの以前のバージョンに、メタデータに示される特定のログレコードを含んだログレコードの１つまたは複数を適用することを含んでよい。データの以前のバージョンはＡＵＬＲの形をとってよい、またはデータの以前のバージョンは（ＡＵＬＲ、及び／または該ＤＵＬＲの前の１つまたは複数のＤＵＬＲに適用される）ＤＵＬＲの形をとってよい。

いくつかの実施形態では、データの以前のバージョンに１つまたは複数のログレコードを適用することは、データベースサービスのためのバックグラウンドプロセスとして実行されてよい。一実施形態では、データの以前のバージョンにログレコード（複数の場合がある）を適用することは、データベースサービスの多様なノード全体で分散されてよい。一実施形態では、データの以前のバージョンにログレコード（複数の場合がある）を適用することは、それらの多様なノード全体で並行して実行されてよい。

８４０で示されるように、特定のスナップショットまで復元した後、該スナップショットと関連付けられた１つの時刻よりも遅い関連付けられた複数の時刻の１つまたは複数のログレコードはガベージコレクション可能として示されてよい。例えば、ＬＳＮ１からＬＳＮ６を有するログレコードがＬＳＮ３で撮られたスナップショットを含むデータページについて存在する場合、ＬＳ３で撮られたスナップショットを復元すると、ＬＳＮ４からＬＳＮ６はガベージコレクション可能として示されてよい、または単にガベージコレクション不可の表示を削除され（それによって、それらをガベージコレクション可能にして）よい。したがって、第２のスナップショットがＬＳＮ６で撮られた場合にも、ＬＳＮ３からスナップショットを復元すると、ＬＳＮ６で撮られたスナップショットは、ＬＳＮ６で撮られたスナップショットに対応するログレコードの保護がもはや効力がないように、もはやインプレースではないことがある。また、一実施形態では、第２のスナップショットは以前のスナップショットに復元しても保たれてよい。

多様な実施形態では、ガベージコレクションは、ログレコードを記憶するために使用されるスペースを、将来の他のログレコードのために（または他のデータのために）再利用できるようにするバックグラウンドプロセスであってよい。ガベージコレクションは、ガベージコレクションが分散プロセスとして同時に発生してよいように、多様なノード全体に拡散されてよい。ガベージコレクションプロセスによる再利用は、１つまたは複数のログレコードを削除することを含んでよい。削除するそれらのログレコードは、メタデータに示される特定のログレコード（複数の場合がある）に基づいてガベージコレクションプロセスによって決定されてよい、及び／またはスナップショットのタイプに基づいてよい。または、それぞれの保護されているログレコードがメタデータではっきりと示される一実施形態では、ガベージコレクションプロセスは、メタデータで保護されているとして示されていないログレコードを単に削除してよい。

いくつかの実施形態では、複数のログレコードが、少なくとも部分的にスナップショットに基づいて合体されてよい。例えば、所与のデータページについて、ＡＵＬＲがＬＳＮ１に存在し、ＤＵＬＲがＬＳＮ２から８に存在し、不連続スナップショットがＬＳＮ８で撮られる場合、ＬＳＮ２からＬＳＮ８のログレコードのそれぞれがＬＳＮ１でＡＵＬＲに適用されるように、新しいＡＵＬＲが作成されて、ＬＳＮ８でＤＵＬＲを置き換えてよい。ＬＳＮ８の新しいＡＵＬＲは、次いでＬＳＮ１からＬＳＮ７でのログレコードをガベージコレクション可能にし、それによりそれらのログレコードを記憶するために使用されるスペースを解放できる。連続スナップショットの場合、連続スナップショットによってカバーされる時点のそれぞれまで復元する能力を維持するために合体は起こらないことがあることに留意されたい。クライアントが、連続スナップショットが前の２日間、保持され、周期的な（例えば、日に２回、日に１回等）不連続スナップショットがその前の３０日間、保持されることを要求することがあることに留意されたい。連続スナップショットが前の２日間の範囲から外れるとき、連続スナップショットは不連続スナップショットに変換されてよく、変換された不連続スナップショットにもはや必要とされないログレコードはもはや保持されないことがある。

１日１回の不連続スナップショットが日１から３０のそれぞれに存在し、連続スナップショットが日３０から日３２まで存在する例を考える。日３３に、日３０から日３１の連続スナップショットは、それがすでに最も最近の２日間の期間内にないので、クライアントによってもはや必要とされないことがある。したがって、日３０から日３１の連続スナップショットは不連続スナップショットに変換されてよい。日３０から日３１の連続スナップショットの部分を不連続スナップショットに変換するために、メタデータは、その時点での不連続スナップショットにもはや必要とされていないログレコード（複数の場合がある）がガベージコレクション可能と示される（またはガベージコレクション不可としてもはや示されない）ように修正されてよい。同じラインに沿って、日１の不連続スナップショットも、それがもはや最も最近の２日間の前の先行する３０日のウィンドウの範囲内に入らないため、（日２の不連続スナップショットが日１の不連続スナップショットのログレコードに依存していないと仮定して）削除されてよい、及び／またはガベージコレクトされてよい。日１のスナップショットを削除することは、（以後のスナップショットによって必要とされない限り）日１のスナップショットと関連付けられたログレコードをガベージコレクトされることから保護したメタデータを、それらのログレコードが次いでガベージコレクション可能となってよいように修正及び／または削除することを含んでよい。日２の不連続スナップショットが日１の不連続スナップショットのログレコードに依存している場合、日２の不連続スナップショットと関連付けられている１つまたは複数のログレコードが、日１のログレコードを削除する、及び／またはガベージコレクトできるようにＡＵＬＲ（複数の場合がある）で変換されてよいことに留意されたい。

本明細書に説明されるように、図８の方法は単一のデータページのデータに、または複数のデータページからのデータに適用してよい。したがって、多様な実施形態では、スナップショットは複数の異なるデータページからデータを復元するために、または単一のデータページにデータを復元するために使用できてよい。したがって、スナップショットのメタデータは、単一のデータページのための１つまたは複数の特定のログレコードの１つまたは複数のログ識別子、または複数のデータページのための複数のログレコードのログ識別子を示してよい。さらに、単一のデータページのスナップショットに対応するメタデータが、いくつかの例では、複数のログレコードの複数のログ識別子を示してよいことにも留意されたい。例えば、メタデータは、例えばスナップショットがＤＵＬＲに対応する場合等、ガベージコレクトをするべきではない複数のログレコードを示してよい。係る例では、メタデータは（直接的にまたは間接的に）最も最近のＡＵＬＲまで戻る各ＤＵＬＲ、及びそのページの最も最近のＡＵＬＲはガベージコレクトされるべきではないことを示してよい。

開示されているインプレーススナップショット技法は、データブロックの読取り、コピー、及び書込みによってスナップショットを実行するためにデータをバックアップするシステムとは対照的に、より少ないＩＯリソース及びネットワーキングリソースを使用するという点で、システムの性能を改善してよい。そして、それらの性能改善のため、開示されている技法は、システムのユーザー（例えば、フォアグラウンド活動にシステムを使用しているユーザー）の目に見えるだろう、より少ないトランザクションレートの失速または制限を実現してよい。

ここで図９を参照すると、多様な実施形態で、データベースシステム４００は、ログレコードを操作する（例えば、変形する、修正する等）ように構成されてよい。図９の方法は、分散型データベース最適化ストレージシステム４１０（例えば、ストレージシステムサーバノード（複数の場合がある）４３０、４４０、４５０等）のログ構造化ストレージシステムの多様な構成要素によって実行されるとして説明されてよいが、方法はいくつかの場合にいずれの特定の構成要素によっても実行される必要はない。例えば、いくつかの場合、図９の方法は、いくつかの実施形態に従っていくつかの他の構成要素またはコンピュータシステムによって実行されてよい。または、いくつかの場合、データベースシステム４００の構成要素は、図４の例に示されるとは異なって組み合されてよい、または存在してよい。多様な実施形態では、図９の方法は、分散型データベース最適化ストレージシステムの１台または複数のコンピュータによって実行されてよく、その内の１つは図１０のコンピュータシステムとして示される。図９の方法は、ログ変形／操作のための方法の１つの例の実装として示される。他の実装では、図９の方法は追加のブロック、または図示されるよりも少ないブロックを含んでよい。例えば、図９の方法は、図９の方法が図８の方法の１つまたは複数のブロックを含むように、図８の方法と併せて使用されてよい。

９１０で、複数のログレコードが受信されてよい。例えば、ログレコードは、データベースサービスのデータベースエンジンヘッドノードから分散型データベース最適化ストレージシステムによって受信されてよい。図８で留意されるように、及び本明細書に説明されるように、各ログレコードはそれぞれのログシーケンス識別子と関連付けられてよく、データベースシステムによって記憶されるデータに対するそれぞれの変更と関連付けられてよい。また、本明細書に説明されるように、ログレコードは、ベースラインログレコード（複数の場合がある）とも呼ばれる１つまたは複数のＡＵＬＲ及び／または１つまたは複数のＤＵＬＲを含んでよい。ベースラインログレコード（複数の場合がある）は１ページのデータを含んでよく、したがってそれはデータに対する変更だけではなく、ページの完全なデータを含む。対照的に、ＤＵＬＲはデータの完全なデータではなく、データのページに対する変更を含んでよい。

以下の段落は、ログレコードの範囲を記述するために例の表記を説明する。単純な括弧（）及び角括弧［］は範囲の開いた（排他的な）境界及び閉じられた（包含的な）境界を示す。本明細書に説明されるように、ＬＳＮは０＜＝ａ＜＝ｂ＜＝ｃ＜＝ｄ＜＝ｅとなるようにログレコードの順次順序付けであってよい。ＬＳＮｔは、末尾を表す特別なＬＳＮで、０から開始し、ボリュームで書込みが発生するにつれ絶えず増加している。本明細書で使用されるように、ログセクションは、ベースラインＬＳＮでのボリュームを考えると、１つまたは複数のターゲットＬＳＮでボリュームを読み取ることができるために必要なすべての情報を有するログレコードの集合体である。一実施形態では、ログセクションは、ベースラインＬＳＮ以下の、または最高のターゲットＬＳＮより大きいＬＳＮが付いたログレコードは含まない。例えば、「ａ」のベースラインＬＳＮに完全なボリュームがあり、ログセクションがＬ（ａ；ｂ］である場合には、ボリュームを生成し、ＬＳＮ「ｂ」で読み取ることができる。

例の構文を使用すると、ログセクションは、その結果Ｌ（＜ベースラインＬＳＮ＞；＜ターゲットＬＳＮのセット＞］として表されてよい。一実施形態では、＜ベースラインＬＳＮ＞は単一のＬＳＮ（例えば、「０」または「ａ」）であってよい。＜ターゲットＬＳＮのセット＞は単一のＬＳＮ（例えば、「ｂ」）、不連続ＬＳＮのシーケンス（例えば、「ｂ，ｃ」）、ＬＳＮの包含的な範囲（例えば、「ｃ．．ｄ」）、またはその組合せ（例えば、「ｂ，ｃ，ｄ..ｅ」）であってよい。ｃ..ｄ等の包含的な範囲は、ｃとｄとの間の任意のボリュームを復元するために十分な情報が利用できることを示す。例の構文に従って、ターゲットＬＳＮはベースラインＬＳＮ以上である。さらに、例の構文に従って、ログセクションのＬＳＮは昇順で一覧表示される。

多様な実施形態では、ログセクション内のレコードはＡＵＬＲ及び／またはＤＵＬＲの組合せであることがある。ログセクションは、代わりにＤＵＬＲだけまたはＡＵＬＲだけを含んでよい。例えば、ログセクションは、ベースラインとターゲットＬＳＮとの間で修正されたユーザーページのＡＵＬＲだけを含んでよい。多様な実施形態では、ターゲットＬＳＮ以外のＬＳＮでユーザーページのバージョンを生成することができることは必要とされていない。例えば、ログセクションＬ（ａ；ｃ］は、ａ＜ｂ＜ｃの場合にＬＳＮｂでユーザーページを生成するほど十分な情報を有していないことがある。

ボリュームの初期状態がすべてゼロから構成されていると仮定すると、形式Ｌ（０；ａ］のログセクションはＬＳＮ ａでのボリュームを表してよい。

本明細書に説明されるログセクション表記は、複数のデータページ／ユーザーページを含むボリュームのＬＳＮを示す。例えば、２つのページ、ｘ及びｙだけを含むボリュームを考える。ＬＳＮ１が付いたログレコードはページｘの場合ＡＵＬＲであってよく、ＬＳＮ２が付いたログレコードはページｙの場合ＡＵＬＲであってよい。例を続行すると、ＬＳＮ３及びＬＳＮ５が付いたログレコードはページｘの場合ＤＵＬＲであってよく、ＬＳＮ４及びＬＳＮ６が付いたログレコードはページｙの場合ＤＵＬＲであってよい。読取り要求がページｙに対して入信する場合、次いでデータベースサービスは、ページｙの最も最近のＡＵＬＲであるＬＳＮ２のＡＵＬＲで開始してよく、ＬＳＮ４及びＬＳＮ６からの変更をその上に適用してよい。同様に、ページｘに対する読取り要求の場合、データベースサービスはＬＳＮ１のＡＵＬＲで開始し、次いで要求者にページｘを返す前に、ＬＳＮ３及びＬＳＮ５でのログレコードからの変更を適用してよい。

９２０で示されるように、複数のログレコードは、分散型データベース最適化ストレージシステムのストレージノードの中で記憶されてよい。一実施形態では、所与のログレコードは、分散型データベース最適化ストレージシステムの１つまたは複数のストレージノードに記憶されてよい。一実施形態では、分散型データベース最適化ストレージシステムは、どの１つまたは複数のストレージノードに所与のログレコードを記憶するのかを決定してよい、または分散型データベース最適化ストレージシステムは、所与のログレコードを記憶する１つまたは複数のストレージノードを示す指示を、データベースエンジンヘッドノードから受信してよい。いくつかの例では、各ストレージノードが所定の時間に同じ１つまたは複数のログレコードを記憶しないことがあるため、ストレージシステムの１つまたは複数のノード及び／またはミラーはカレントログレコードの完全なセットで最新ではないことがある。

９３０で示されるように、複数のログレコードが変形してよい。本明細書に説明される例の表記で示されるように、変形してよい複数のログレコードは２つ以上のログセクションを含んでよい。それらの２つ以上のログセクションは、該変形のオペランドであってよい。オペランド（例えば、Ｌ（ａ；ｃ］、Ｌ（ａ；ｂ，ｄ］、Ｌ（ａ；ｂ，ｃ..ｅ］等）としてのログセクションの多様な例は以下に提供される。変形はさまざまな方法で発生してよい。例えば、一実施形態では、複数のログレコードを変形させることにより、修正された複数のログレコードが生じてよい。修正された複数のログレコードは、異なる複数のログレコードであってよい。異なる複数のログレコードは、ログレコードの少なくとも１つでは異なるが、最初に維持された複数のログレコードよりも数が少ない、数が多い、または数が等しいことがある。ログレコードの変形は（例えば、ストレージスペース、ネットワーク使用量等に関して）より効率的なシステムを生じさせてよい。

一実施形態では、複数のノード及びミラーを有する分散型システムにおいて、ノード及び／またはミラーのいくつかが最新であってよく、いくつかは最新でないことがある。係る実施形態では、複数のログレコードを変形させることは、差異がストレージノードの内の異なるストレージノードで維持されるログレコードに存在すると決定すること、及び多様なノードで維持されるログレコードのそれらの差異を調整することを含んでよい。ログレコードの差異を調整することは、多様なノードに記憶される多様なログレコードを調整するログレコードの全体的なマスタログの形をとる修正された複数のログレコードを生成すること、及び／または再構築することを含んでよい。一実施形態では、マスタログは次いで（例えば、最新ではないログを置き換えることによって）ログのコンテンツを同期させるために多様なノード／ミラーに提供されてよい。また、一実施形態では、マスタログは特定のノードで維持されてよい。そのマスタログは、ログ調整が次に発生するまでストレージノードのマスタログと見なされてよい。

ログ調整を示すために、３つのストレージノードＳＮ１、ＳＮ２、及びＳＮ３がある単純な例を考える。ＳＮ１は、識別子ＬＳＮ１、ＬＳＮ２、及びＬＳＮ３を有するログレコードを記憶してよい。ＳＮ２は、識別子ＬＳＮ３、ＬＳＮ４、及びＬＳＮ５を有するログレコードを記憶してよく、ＳＮ３は識別子ＬＳＮ６を有するログレコードを記憶してよい。ログレコードを変形させることは、ＳＮ１とＳＮ２の両方に記憶されていた、ＬＳＮ３の２つのインスタンスではなく、ＬＳＮ１から６のかつてのインスタンスを含むマスタログレコードを生成することを含んでよい。ログ調整を実行することは、１つまたは複数のログ演算をログレコードに適用することを含んでよい。ログ演算の例は、ログレコードの合体、切取り、トリミング、削減、融合、及び／またはそれ以外の場合削除または追加を含む。係る例のログ演算はより詳細に以下に説明される。

本明細書に説明されるように、一実施形態では、ログレコードを変形させることは、複数のログレコードを合体することを含んでよい。ログレコードを合体することは、デルタログレコードを新しいベースラインログレコードに変換することを含んでよい。ＬＳＮ１、ＬＳＮ２、ＬＳＮ１５、及びＬＳＮ１６がそれぞれのＡＵＬＲの識別子であり、ＬＳＮ２からＬＳＮ１４がそれぞれのＤＵＬＲの識別子であるデータページｘ及びｙの例を考える。ログレコードを合体することは、ＬＳＮ８のＤＵＬＲをＡＵＬＲに変換することを含んでよい。ＬＳＮ８をＡＵＬＲに変換するためには、ＬＳＮ８でのログレコードを含んだＬＳＮ８と同じデータページ（例えば、データページｙ）に対応するログレコードからの変更がそのデータページの最も最近のＡＵＬＲに適用されてよい。例えば、ＬＳＮ２がデータページｙのＡＵＬＲに対応し、ＬＳＮ４、ＬＳＮ６、及びＬＳＮ８がデータページｙのＤＵＬＲに対応する場合、次いでＬＳＮ８でのＤＵＬＲをＡＵＬＲに変換することはＬＳＮ４、ＬＳＮ６、及びＬＳＮ８でのログレコードの変更をＬＳＮ２でのＡＵＬＲに適用することを含む。本明細書に説明されるように、他の状況では（例えば、連続スナップショットまたは他の依存状態の場合）、ＬＳＮ２、ＬＳＮ４、及びＬＳＮ６はもはや必要とされなくなるまで保持されてよいのに対し、特定の状況では、それらのＬＳＮのログレコードは次いでガベージコレクトされてよい、またはそれ以外の場合削除されてよい。

多様な実施形態では、複数のログレコードは、以前の状態にデータを復元するために使用できる少なくとも１つのスナップショット（例えば、図８の方法に従って作成されるスナップショット）に関連付けられてよい。係る実施形態では、複数のレコードを変形させることは、少なくとも部分的にスナップショットに基づいてログレコードの１つまたは複数をガベージコレクトすることを含んでよい。例えば、上記の合体の例を続行すると、ＬＳＮ２、ＬＳＮ４、及びＬＳＮ６が連続スナップショットの一部として必要とされる場合、次いでそれらのＬＳＮに対応するログレコードはガベージコレクション可能ではな（く、第１に合体されな）いことがある。対照的に、それらのレコードがスナップショットの一部として必要とされない場合には、それらのログレコードはガベージコレクトされてよい。例えば、不連続スナップショットが、例えばＬＳＮ１０に等、ＬＳＮ２、ＬＳＮ４、及びＬＳＮ６の後のＬＳＮに存在する場合、ＬＳＮ８でのログレコードがＡＵＬＲであるため、次いでＬＳＮ２、ＬＳＮ４、及びＬＳＮ６でのログレコードは必要とされないことがある。したがって、ＬＳＮ２、ＬＳＮ４、及びＬＳＮ６のログレコードはガベージコレクトされてよい。

本明細書に説明されるように、ログレコードを変形させることは、１つまたは複数のログレコードがガベージコレクション可能であることを示すことを含んでよい。係る例では、１つまたは複数のログレコードがガベージコレクション可能であることを示すためにログレコードを変形させることは、それらのログレコードがガベージコレクション可能であることを示すためにそれらの１つまたは複数のログレコードと関連付けられるメタデータを生成すること、及び／または修正することを含んでよい。

一実施形態では、ログレコードを変形させることは、１つまたは複数のログレコードを削除することを含んでよい。本明細書に説明されるように、ログレコードを削除することは、他の演算の中でも切取り演算またはトリミング演算の一部であってよい。ログレコードを削除することは、いくつかの実施形態では、削除がフォアグラウンドプロセスとして実行されてよいことに対して、ガベージコレクションがバックグラウンドプロセスとして受動的に且つゆったりと実行されてよい点で異なってよい。

一実施形態では、ログレコードを変形させることは、複数のログレコードをトリミングするためのトリミング演算を実行することを含んでよい。トリミング演算を実行することは、ターゲット識別子（例えば、ターゲットＬＳＮ）の値未満、または値以下のそれぞれの識別子（例えば、ＬＳＮ値）を有する１つまたは複数のログレコードを削除すること（及び／またはガベージコレクション可能として示すこと）を含んでよい。トリミング演算は、ログセクションのベースラインＬＳＮを増加するために使用されてよい。それぞれの識別子が時刻に従って順次順序付けられてよく、したがっていくつかの実施形態では、トリミングが、ターゲット識別子の関連付けられた時刻の前のそれぞれの関連付けられた時刻を有するログレコードを削除することを含んでよいことに留意されたい。

一実施形態では、演算の左の引数はベースラインＬＳＮ Ｂ１が付いたログセクションであってよく、右の引数は削除されるＬＳＮの範囲であってよい。したがって、結果は、ターゲットＬＳＮに対応する時点で開始するＬＳＮを有する１つまたは複数のログレコードであってよい。一例として、「−」がトリミングを示す以下の例のトリミング演算、Ｌ（ａ；ｃ］−（ａ，ｂ］＝、Ｌ（ｂ；ｃ］を考える。このようにして、部分（ａ，ｂ］は（ａ，ｃ］からトリミングされ、（ｂ；ｃ］の新しい範囲を生じさせる。上述されたように、単純な（）括弧は範囲の開いた境界を示し、角［］括弧は範囲の閉じられた境界を示してよい。別のトリミング例として、トリミング演算Ｌ（ａ；ｂ，ｄ］−（ａ，ｃ］を考える。結果はＬ（ｃ；ｄ］である。さらに別のトリミングの例として、Ｌ（ａ；ｂ，ｃ..ｅ］−（ａ，ｄ］＝Ｌ（ｄ；ｅ］であるトリミング演算を考える。

トリミング演算の結果として、新しいベースラインＬＳＮ以下のＬＳＮを有する１つまたは複数のログレコードは削除されてよい（またはガベージコレクトされてよい）。いくつかの例では、オリジナルのログセクションがトリミングするための係るログレコードを含まないことがあることが考えられる。それらの例では、トリミング演算はログセクションのサイズの縮小を生じさせないことがある。

一実施形態では、ログレコードを変形させることは、複数のログレコードを切り取るための切取り演算を実行することを含んでよい。切取り演算を実行することは、ターゲット識別子（例えば、ターゲットＬＳＮ）の値より大きい、または以上のそれぞれの識別子（例えば、ＬＳＮ値）を有する１つまたは複数のログレコードを削除すること（及び／またはガベージコレクション可能として示すこと）を含んでよい。切取り演算は、ログセクションの末尾の部分を削除するために使用されてよい。トリミング演算と同様に、それぞれの識別子は時刻に従って順次順序付けられているため、いくつかの実施形態では、切り取ることはターゲット識別子の関連付けられた時刻の後のそれぞれの関連付けられた時刻を有するログレコードを削除することを含んでよい。

一実施形態では、切取り演算の左の引数はターゲットＬＳＮ（複数の場合がある）Ｔ１が付いたログセクションであってよく、右の引数は新しいターゲットＬＳＮ（複数の場合がある）Ｔ２であってよく、Ｔ２はＴ１の適切なサブセットである。切取り演算は、削除されたＬＳＮが保持されているＬＳＮよりも大きくなるようにＬＳＮを削除してよい。例えば、Ｌ２がＴ２にある｛Ｔ１−Ｔ２｝のＬＳＮ Ｌ３の場合、以下の条件が当てはまってよい：Ｌ３＞Ｌ２

一例として、「＠」がトリミングを示す以下の例の切取り演算、Ｌ（ａ；ｂ，ｃ］＠［ｂ］＝Ｌ（ａ；ｂ］を考える。このようにして、それぞれの識別子がターゲット識別子ｂより大きいログレコードの部分がログセクションＬ（ａ；ｂ，ｃ］から削除される。別の例はＬ（ａ；ｂ..ｄ］＠［ｂ..ｃ］＝Ｌ（ａ；ｂ..ｃ］を含む。トリミング演算、切取り演算での場合と同様に、オリジナルのログセクションは切り取るための係るログレコードを含まないことがある。それらの例では、切取り演算はログセクションのサイズの縮小を生じさせないことがある。

一実施形態では、ログレコードを変形させることは、複数のログレコードを削減することを含んでよい。削減演算は、最高のターゲットＬＳＮを変更することなくログセクションのターゲットＬＳＮのセットを削減してよい。したがって、削減演算は切取り演算に対する補足演算であってよい。削減することはログセクションの先頭部または最後部を切り取らないことがあるが、代わりにセクションの中央部分を削除してよい。削減演算の例は、スナップショットの連続部分を削除することであるだろう。例えば、連続スナップショットが最後の２日間について要求され、不連続スナップショットが過去３０日間について要求され、いったん連続スナップショットの一部分が２日分より大きい場合、一部は削除され、それによって１つまたは複数の不連続スナップショットが生じてよい。

削減演算は「＠＠」で示されてよい。削減演算の左の引数は、ターゲットＬＳＮ Ｔ１が付いたログセクションであってよく、右の引数は次のターゲットＬＳＮ Ｔ２であり、Ｔ２はＴ１の適切なサブセットである。Ｔ１の最高のＬＳＮはＴ２の最高のＬＳＮに等しくてよい。一例として、Ｌ（ａ；ｂ..ｃ］＠＠［ｃ］は、Ｌ（ａ；ｃ］を生じさせてよい。別の例として、Ｌ（ａ；ａ..ｂ，ｃ..ｅ］＠＠［ｂ，ｄ..ｅ］は、Ｌ（ａ；ｂ，ｄ..ｅ］を生じさせてよい。ログレコードが削減演算の一部として削除されることを必要とされないことがあることに留意されたい。いくつかの例では、いくつかのログレコードは、新しいターゲットＬＳＮでユーザーページバージョンを生成するために必要とされないことがある。それらのログレコードは安全に削除されてよいが、削除されることを必要とされていない。それらのログレコードはインプレースに残すことができる、及び／またはゆったりとガベージコレクトすることができる。どのログレコードが削除可能であるのかを（例えば、削除またはガベージコレクションを介して）識別することは、複数のログレコードの中での決定された依存状態に基づいて決定されてよい。例えば、特定のＤＵＬＲは１つまたは複数の以前のＤＵＬＲ及び／または１つの以前のＡＵＬＲに依存してよい。したがって、一実施形態では、それ以外の場合削除可能であるだろうが、それに依存する他のログレコードを有するログレコードが維持されてよく、削除されない、またはガベージコレクトされないことがあるのに対し、削除可能であり、それに依存する他のログレコードを有していないログレコードは、削除されてよい、及び／またはガベージコレクション可能であってよい。

いくつかの実施形態では、柔軟に（例えば、トリミング演算を使用して）ベースラインＬＳＮを増すことが可能であるが、ターゲットＬＳＮの同様の減少は利用できない。例えば、Ｌ（ａ；ｃ］はＬ（ｂ；ｃ］に変形してよいが、いくつかの実施形態では、Ｌ（ａ；ｃ］は、ｂとｃとの間のＡＵＬＲ（複数の場合がある）によって代わられたａとｂとの間のいくつかの紛失したログレコード（複数の場合がある）であることがあるため、Ｌ（ａ；ｂ］に変形されないことがあることに留意されたい。このようにして、Ｌ（ａ；ｃ］はＬＳＮ ｂでの全体的なボリュームを生成するほど十分な情報を欠くことがある。ログセクションの新しいターゲットＬＳＮセットは、以前のターゲットＬＳＮセットのサブセットでなければならないことがある。例えば、Ｌ（ａ；ｂ..ｃ］及びＬ（ａ；ａ..ｃ］はＬＳＮ ｂでの全体的なボリュームを生成するために必要な情報を有さないことがあるが、切取り演算及び削減演算を使用してＬ（ａ；ｂ］に変形できる。

一実施形態では、ログレコードを変形させることは、該複数のログレコードを融合演算で別の複数のログレコードと結合することを含んでよい。例えば、融合演算は、両方のログセクションのターゲットＬＳＮとも保持されるように、２つの隣接するログセクションを単一のログセクションに結合することを含んでよい。融合演算は「＋」で表されてよい。左の引数は、低い方のベースラインＬＳＮ Ｂ１が付いたログセクションを含んでよく、最高のターゲットＬＳＮはＴ１である。右の引数は、高い方のベースラインＬＳＮ Ｂ２が付いたログセクションを含んでよい。いくつかの実施形態では、Ｂ２はＴ１に等しい。１つの例の融合演算はＬ（ａ；ｂ］＋Ｌ（ｂ；ｃ］＝Ｌ（ａ；ｂ，ｃ］である。別の例の融合演算はＬ（ａ；ｂ，ｃ］＋Ｌ（ｃ；ｄ，ｅ］＝Ｌ（ａ；ｂ，ｃ，ｄ，ｅ］である。多様な実施形態では、ログレコードは融合演算の一部として削除されないことがある。

一実施形態では、ガベージコレクションがスナップショットを保持しないで実行される場合、ログはＬ（０；ｔ］で表すことができる。ガベージコレクションが実行されない場合、ログはＬ（０；０..ｔ］で表すことができる。

ＬＳＮ「ａ」でのボリュームを表すための表記はＶ［ａ］であってよい。Ｖ［０］はすべてのゼロを含むと仮定できる。一実施形態では、ボリュームのログレコードを変形させることは「^*」で表される構成演算を含んでよい。新しいボリュームは低い方のＬＳＮでのボリューム及びＬＳＮギャップに対応するログセクションを考慮すると高い方のＬＳＮとして作成されてよい。左の引数はＬＳＮ Ｂでのボリュームであってよく、右の引数はベースラインＬＳＮ Ｂ及び単一のターゲットＬＳＮ Ｔのあるログセクションであってよい。複数のターゲットＬＳＮが付いたログセクションは、所望されるボリュームを構成する前に関心のある単一のＬＳＮまで切り取られてよい、及び／または削減されてよい。例は、Ｖ［ａ］^*Ｌ（ａ；ｂ］＝Ｖ［ｂ］を含む。

一実施形態では、ログレコードを変形させることは、複数のログレコードに対して演算の組合せを実行することを含んでよい。以下の演算の組合せ、｛Ｌ（ｂ；ｃ］，Ｌ（ｂ；ｄ］｝→Ｌ（ｂ；ｃ，ｄ］から引き出された変形を考える。係る変形は、以下の通りトリミング演算及び融合演算から引き出されてよい。Ｌ（ｂ；ｄ］−（ｂ，ｃ］＝Ｌ（ｃ；ｄ］及びＬ（ｂ；ｃ］＋Ｌ（ｃ；ｄ］＝Ｌ（Ｂ；ｃ，ｄ］。別の例の引き出された変形は上述の例を拡張する。つまり、上述の例からのトリミング及び融合を含み、さらに追加のトリミングＬ（ａ；ｃ］−（ａ，ｂ］＝Ｌ（ｂ；ｃ］を含む｛Ｌ（ａ；ｃ］，Ｌ（ｂ；ｄ］｝→Ｌ（ｂ；ｃ，ｄ］である。「→」の使用は演算の詳細を示すことなく全体的な変形を表すことに留意されたい。例えば、｛Ｌ１，Ｌ２｝→｛Ｌ３｝は、変形を実行するための基礎的な演算を示さないＬ１及びＬ２のＬ３への変形である。

多様な実施形態では、複数の演算の組合せを複数のログレコードに対して実行することは、他の動作の中で、スナップショット動作（例えば、図８でのようにスナップショットを撮ること、復元すること、切り詰めること、及び／または削除することの一部として）、またはログレコード調整を容易にしてよい。不連続スナップショット及び連続スナップショットを撮ること、復元すること、及び削除することの例の組合せが続く。

不連続スナップショットを撮るために演算を組み合わせることの例の場合、分散型ストレージシステムのためのライブログの初期状態はＬ（０；ｔ］であってよい。スナップショットは、最後部がＬＳＮａ、Ｌ（０；ａ，ｔ］に到達すると撮られてよい。Ｌ（０；ａ，ｔ］は次いで［ａ］，Ｌ（０；ａ，ｔ］＠［ａ］＝Ｌ（０；ａ］で切り取られてよい。Ｌ（０；ａ］は、分散型ストレージシステムとは別個の記憶場所であってよいスナップショット記憶場所にコピーされてよい。別のスナップショットは、最後部がＬＳＮ ｂ，Ｌ（０；ａ，ｂ，ｔ］に到達すると撮られてよい。Ｌ（０；ａ，ｂ，ｔ］は次いで、Ｌ（０；ａ，ｂ，ｔ］−（０；ａ］に従ってトリミングされ、Ｌ（ａ；ｂ，ｔ）を生じさせてよい。Ｌ（ａ；ｂ，ｔ）は次いで［ｂ］（Ｌ（ａ；ｂ，）＠［ｂ］）で切り取られ、Ｌ（ａ；ｂ］を生じさせてよい。Ｌ（ａ；ｂ］も次いでスナップショット記憶場所にコピーされてよい。

不連続スナップショットを復元するために演算を組み合わせる例の場合、スナップショット記憶場所で利用できるＬ（０；ａ］，Ｌ（ａ；ｂ］を考える。Ｌ（０；ａ］及びＬ（ａ；ｂ］は復元先にコピーされてよく、Ｌ（０；ａ］＋Ｌ（ａ；ｂ］＝Ｌ（０；ａ，ｂ］に従って融合されてよい。融合されたセクションは、次いでＬ（０；ａ，ｂ］＠＠［ｂ］＝Ｌ（０；ｂ］に従って削減されてよい。Ｌ（０；ｂ］は、復元する所望されるスナップショットであってよく、新しいボリュームを開始するために使用されてよい。

旧い不連続スナップショットを削除するために演算を組み合わせる例の場合、次の初期のライブログ状態、Ｌ（０；ａ，ｂ，ｔ］を考える。Ｌ（ａ；ａ，ｂ，ｔ］＠＠［b，ｔ］＝Ｌ（０；ｂ，ｔ］は、ａでスナップショットを削除するために使用されてよく、Ｌ（０；ａ，ｂ，ｔ］＠＠［ｔ］＝Ｌ（０；ｔ］は両方のスナップショットａ及びｂを削除するために使用されてよい。

連続スナップショットを撮るために演算を組み合わせることの例の場合、分散型ストレージシステムのライブログの初期状態は、不連続スナップショットを撮る例での場合のようにＬ（０；ｔ］であってよい。連続スナップショットは、Ｌ（０；ａ..ｔ］で示されるように、最後部がＬＳＮ ａに到達すると開始されてよい。尾部がＬＳＮ ｂ（ｂ＜ｔ）を交差した後、Ｌ（０；ａ..ｔ］は［ａ..ｂ］によって切り取られ（＠＠）、Ｌ（０；ａ..ｂ］を示す。Ｌ（０；ａ..ｂ］は、次いでスナップショット記憶場所にコピーされてよい。尾部がＬＳＮ ｃ（ｃ＜ｔ）を交差した後、Ｌ（０；ａ..ｔ］＠＠［ａ..ｃ］＝Ｌ（０；ａ..ｃ）となる。Ｌ（０；ａ..ｃ）＠＠［ｂ..ｃ］＝Ｌ（０；ｂ..ｃ］。Ｌ（０；ｂ..ｃ］は（０，ａ］でトリミングされ、次いでスナップショット記憶場所にコピーされてよいＬ（ｂ；ｂ..ｃ］を示す。連続スナップショットは、最後部がＬＳＮ ｄ：Ｌ（０，ａ..ｄ，ｔ］に到達すると停止されてよい。

連続スナップショットを復元するために演算を組み合わせることの例の場合、スナップショット記憶場所で利用できるＬ（０；ａ..ｂ］及びＬ（ｂ；ｂ..ｃ］を考える。Ｌ（０；ａ..ｂ］及びＬ（ｂ；ｂ..ｃ］は、２つのログセクションがＬ（０；ａ..ｂ］＋Ｌ（ｂ；ｂ..ｃ］＝Ｌ（０；ａ..ｃ］として互いに融合されてよい復元先にコピーされてよい。復元が、ｂ＜ｘ＜ｃであるＬＳＮ ｘに対して要求された場合、以下が実行されてよい。Ｌ（０；ａ..ｃ］＠［ａ..ｘ］＝Ｌ（０；ａ..ｘ］。結果は、次いで［ｘ］で削減され（＠＠）、Ｌ（０；ｘ］を生じさせてよい。所望されるスナップショットはＬ（０；ｘ］であってよく、新しいボリュームを開始するために使用されてよい。

ライブログの初期状態がＬ（０，ａ..ｄ，ｔ］である連続スナップショットを削減するために演算を組み合わせることの以下の例を考える。Ｌ（０，ａ..ｄ，ｔ］は［ｔ］で削減されて、連続スナップショット全体を削除し、Ｌ（０；ｔ］（保持されているスナップショットがないログセクション）を生じさせてよい。別の例として、Ｌ（０，ａ..ｄ，ｔ］は［ａ..ｃ，ｔ］で削減されて、ｃからｄの連続スナップショットの一部を削除し、Ｌ（０，ａ..ｃ，ｔ］を生じさせてよい。別の例として、Ｌ（０，ａ..ｄ，ｔ］は［ｃ..ｄ，ｔ］によって削減されて、ａからｃの連続スナップショットの一部を削除し、Ｌ（０，ｃ..ｄ，ｔ］を生じさせてよい。

ライブログの初期状態がＬ（０，ａ..ｔ］であり、ｃ＜ｔである現在の連続スナップショットを切り詰める以下の例を考える。現在の連続スナップショットの最近の部分だけを含んでよいＬ（０，ａ..ｔ］＠＠［ｃ..ｔ］＝Ｌ（０；ｃ..ｔ］。

多様な実施形態では、データベースサービスは、スナップショットを撮るタイムフレーム、範囲、またはウィンドウの要求をユーザーから受信してよい、及び／または要求されたスナップショットのタイプ（例えば、連続または不連続）の表示を受信してよい。例えば、ユーザーは、前の２日間の連続スナップショット、及び前の３０日間の不連続スナップショットを希望すると要求してよい。データベースサービスは、次いで、ユーザーの要求を満たすためにどのログレコード演算（複数の場合がある）（例えば、トリミング、削減、切取り等）をログセクションで実行するのかを決定してよい。例を続行すると、いったん連続スナップショットの一部が２日分よりも古いと、システムは、もはや必要とされていないログレコードのためのスペースを（例えば、ガベージコレクションを介して）再利用するためには削減演算が適切であると決定してよい。

本明細書に説明される方法は、多様な実施形態では、ハードウェア及びソフトウェアの任意の組合せによって実装されてよい。例えば、一実施形態では、方法は、プロセッサに結合されたコンピュータ可読記憶媒体に記憶されるプログラム命令を実行する１台または複数のプロセッサを含むコンピュータシステム（例えば、図１０のコンピュータシステム）によって実装されてよい。プログラム命令は、本明細書に説明される機能性（例えば、本明細書に説明されるデータベースサービス／システム及び／またはストレージサービス／システムを実装する多様なサーバ及び他の構成要素の機能性）を実装するように構成されてよい。

図１０は、多様な実施形態に従って、本明細書に説明されるデータベースシステムの少なくとも一部を実装するように構成されるコンピュータシステムを示すブロック図である。例えば、コンピュータシステム１０００は、異なる実施形態で、データベース階層のデータベースエンジンヘッドノード、またはデータベース階層のクライアントの代わりにデータベーステーブル及び関連付けられたメタデータを記憶する別個の分散型データベース最適化ストレージシステムの複数のストレージノードの内の１つを実装するように構成されてよい。コンピュータシステム１０００は、パーソナルコンピュータシステム、デスクトップコンピュータ、ラップトップコンピュータまたはノートパソコン、メインフレームコンピュータシステム、ハンドヘルドコンピュータ、ワークステーション、ネットワークコンピュータ、消費者装置、アプリケーションサーバ、ストレージデバイス、電話、携帯電話、または一般的に任意のタイプのコンピューティング装置を含むが、これに限定されることがない多様なタイプの装置のいずれかであってよい。

コンピュータシステム１０００は、入出力（Ｉ／Ｏ）インタフェース１０３０を介してシステムメモリ１０２０に結合される（いずれかが、単一スレッドまたはマルチスレッドであってよい複数のコアを含んでよい）１台または複数のプロセッサ１０１０を含む。コンピュータシステム１０００は、Ｉ／Ｏインタフェース１０３０に結合されるネットワークインタフェース１０４０をさらに含む。多様な実施形態では、コンピュータシステム１０００は、１台のプロセッサ１０１０を含んだユニプロセッサシステム、または数台のプロセッサ１０１０（例えば、２，４、８、または別の適切な数）を含んだマルチプロセッサシステムであってよい。プロセッサ１０１０は、命令を実行できる任意の適切なプロセッサであってよい。例えば、多様な実施形態では、プロセッサ１０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳ ＩＳＡ等のさまざまな命令セットアーキテクチャ（ＩＳＡ）または任意の他の適切なＩＳＡのいずれかを実装する汎用プロセッサまたは組み込みプロセッサであってよい。マルチプロセッサシステムでは、プロセッサ１０１０のそれぞれが、一般に同じＩＳＡを実装してよいが、必ずしも同じＩＳＡを実装しないこともある。コンピュータシステム１０００は、通信ネットワーク（例えば、インターネット、ＬＡＮ等）上で他のシステム及び／または構成要素と通信するための１台または複数のネットワーク通信装置（例えば、ネットワークインタフェース１０４０）も含む。例えば、システム１０００で実行中のクライアントアプリケーションは、単一のサーバ上、または本明細書で説明されるデータベースシステムの構成要素の内の１つまたは複数の実装するサーバのクラスタ上で実行中のサーバアプリケーションと通信するためにネットワークインタフェース１０４０を使用してよい。別の例では、コンピュータシステム１０００上で実行中のサーバアプリケーションのインスタンスは、他のコンピュータシステム（例えば、コンピュータシステム１０９０）の上で実装されてよいサーバアプリケーション（または別のサーバアプリケーション）の他のインスタンスと通信するために、ネットワークインタフェース１０４０を使用してよい。

示されている実施形態では、コンピュータシステム１０００は、１台または複数の永続ストレージデバイス１０６０及び／または１台または複数のＩ／Ｏデバイス１０８０も含む。多様な実施形態では、永続ストレージデバイス１０６０は、ディスクドライブ、テープドライブ、ソリッドステートメモリ、他の大容量記憶装置、または任意の他の永続ストレージデバイスに相当してよい。コンピュータシステム１０００（または、コンピュータシステム１０００上で動作する分散アプリケーションもしくはオペレーティングシステム）は、所望されるように、命令及び／またはデータを永続ストレージデバイス１０６０に記憶してよく、必要に応じて記憶されている命令及び／またはデータを取り出してよい。例えば、いくつかの実施形態では、コンピュータシステム１０００は、ストレージシステムサーバノードをホストしてよく、永続記憶装置１０６０はそのサーバノードにアタッチされるＳＳＤを含んでよい。

コンピュータシステム１０００は、プロセッサ（複数の場合がある）１０１０によってアクセス可能な命令及びデータを記憶するように構成される１つまたは複数のシステムメモリ１０２０を含む。多様な実施形態では、システムメモリ１０２０は、任意の適切なメモリ技術（例えば、キャッシュ、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ＤＲＡＭ、ＲＤＲＡＭ、ＥＤＯ ＲＡＭ、ＤＤＲ １０ＲＡＭ、同期ダイナミックＲＡＭ（ＳＤＲＡＭ）、Ｒａｍｂｕｓ ＲＡＭ、ＥＥＰＲＯＭ、不揮発性／フラッシュタイプメモリ、または任意の他のタイプのメモリの内の１つまたは複数）を使用して実装されてよい。システムメモリ１０２０は、本明細書に説明される方法及び技法を実装するためにプロセッサ（複数の場合がある）１０１０によって実行可能であるプログラム命令１０２５を含んでよい。多様な実施形態では、プログラム命令１０２５は、プラットホームネイティブバイナリ、Ｊａｖａ（商標）バイトコード等の任意のインタープリター型言語で、またはＣ／Ｃ＋＋、Ｊａｖａ（商標）等の任意の他の言語で、またはその任意の組合せで符号化されてよい。例えば、示されている実施形態では、プログラム命令１０２５は、データベース階層のデータベースエンジンヘッドノードの、または異なる実施形態で、データベース階層のクライアントの代わりにデータベーステーブル及び関連付けられたメタデータを記憶する別個の分散型データベース最適化ストレージシステムの複数のストレージノードの内の１つの機能性を実装するために実行可能なプログラム命令を含む。いくつかの実施形態では、プログラム命令１０２５は、複数の別個のクライアント、サーバノード、及び／または他の構成要素を実装してよい。

いくつかの実施形態では、プログラム命令１０２５が、ＵＮＩＸ、ＬＩＮＵＸ、Ｓｏｌａｒｉｓ（商標）、ＭａｃＯＳ（商標）、Ｗｉｎｄｏｗｓ（商標）等の多様なオペレーティングシステムの内のいずれかであってよいオペレーティングシステム（不図示）を実装するために実行可能な命令を含んでよい。プログラム命令１０２５のいずれかまたはすべては、多様な実施形態に従ってプロセスを実行するためにコンピュータシステム（または他の電子機器）をプログラミングするために使用されてよい、その上に記憶されている命令を有する非一過性のコンピュータ可読記憶媒体を含んでよいコンピュータプログラム製品、つまりソフトウェアとして提供されてよい。非一過性のコンピュータ可読記憶媒体は、マシン（例えば、コンピュータ）によって読取り可能な形（例えば、ソフトウェア、処理アプリケーション）をとる情報を記憶するための任意の機構を含んでよい。一般的に言えば、非一過性のコンピュータアクセス可能記憶媒体は、例えばＩ／Ｏインタフェース１０３０を介してコンピュータシステム１０００に結合される、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ等の磁気媒体または光学媒体等の、コンピュータ可読記憶媒体または記憶媒体を含んでよい。また、非一過性のコンピュータ可読記憶媒体は、コンピュータシステム１０００のいくつかの実施形態では、システムメモリ１０２０または別のタイプのメモリとして含まれてよい、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の任意の揮発性媒体または不揮発性媒体を含んでもよい。他の実施形態では、プログラム命令は、ネットワークインタフェース１０４０を介して実装されてよい等、ネットワークリンク及び／または無線リンク等の通信媒体を介して伝達される、光信号、音響信号、または他の形の伝搬信号（例えば、搬送波、赤外線信号、デジタル信号等）を使用して通信されてよい。

いくつかの実施形態では、システムメモリ１０２０は、本明細書に説明されるように構成されてよいデータストア１０４５を含んでよい。例えば、本明細書に説明されるデータベース階層の機能を実行する際に使用されるトランザクションログ、アンドゥログ、キャッシュに入れられたページデータ、または他の情報等の、データベース階層によって（例えば、データベースエンジンヘッドノード上に）記憶されるとして本明細書に説明される情報は、データストア１０４５にもしくは１つまたは複数のノード上のシステムメモリ１０２０の別の部分に、永続記憶装置１０６０に、及び／または１つまたは複数のリモートストレージデバイス１０７０に異なるときに及び多様な実施形態で記憶されてよい。同様に、記憶階層によって記憶されているとして本明細書に説明される情報（例えば、本明細書に説明される分散型ストレージシステムの機能を実行する上で使用されるリドゥログレコード、合体データページ、及び／または他の情報）は、データストア１０４５にもしくは１つまたは複数のノード上のシステムメモリ１０２０の別の部分に、永続記憶装置１０６０に、及び／または１つまたは複数のリモートストレージデバイス１０７０に異なるときに及び多様な実施形態で記憶されてよい。一般に、システムメモリ１０２０（例えば、システムメモリ１０２０の中のデータストア１０４５）、永続記憶装置１０６０、及び／またはリモートストレージ１０７０は、データブロック、データブロックのレプリカ、データブロックと関連付けられたメタデータ、及び／またはその状態、データベース構成情報、及び／または本明細書に説明される方法及び技法を実装する上で使用できる任意の他の情報を記憶してよい。

一実施形態では、Ｉ／Ｏインタフェース１０３０は、プロセッサ１０１０と、システムメモリ１０２０と、ネットワークインタフェース１０４０または他の周辺インタフェースを通してを含んだシステムのあらゆる周辺装置との間のＩ／Ｏトラフィックを調整するように構成されてよい。いくつかの実施形態では、Ｉ／Ｏインタフェース１０３０は、１つの構成要素（例えば、システムメモリ１０２０）から別の構成要素（例えば、プロセッサ１０１０）による使用に適したフォーマットにデータ信号を変換するために任意の必要なプロトコル、タイミング、または他のデータ変形を実行してよい。いくつかの実施形態では、Ｉ／Ｏインタフェース１０３０は、例えばペリフェラルコンポーネントインターコネクト（ＰＣＩ）バス規格、またはユニバーサルシリアルバス（ＵＳＢ）規格の変形等の多様なタイプの周辺バスを通してアタッチされるデバイスに対するサポートを含んでよい。いくつかの実施形態では、Ｉ／Ｏインタフェース１０３０の機能は、例えばノースブリッジ及びサウスブリッジ等、２つ以上の別々の構成要素に分割されてよい。また、いくつかの実施形態では、システムメモリ１０２０へのインタフェース等、Ｉ／Ｏインタフェース１０３０の機能性のいくつかまたはすべては、プロセッサ１０１０の中に直接的に組み込まれてよい。

ネットワークインタフェース１０４０は、例えば、コンピュータシステム１０００と、（本明細書に説明される１つまたは複数のストレージシステムサーバノード、データベースエンジンヘッドノード、及び／またはデータベースシステムのクライアントを実装してよい）他のコンピュータシステム１０９０等の、ネットワークにアタッチされる他のデバイスとの間でデータを交換できるように構成されてよい。さらに、ネットワークインタフェース１０４０は、コンピュータシステム１０００と多様なＩ／Ｏ装置１０５０及び／またはリモートストレージ１０７０との間の通信を可能にするように構成されてよい。入出力装置１０５０は、いくつかの実施形態では、１つまたは複数のディスプレイ端末、キーボード、キーパッド、タッチパッド、スキャン装置、音声認識装置もしくは光学認識装置、または１つまたは複数のコンピュータシステム１０００によってデータを入力するまたは取り出すために適した任意の他の装置を含んでよい。複数の入出力装置１０５０は、コンピュータシステム１０００に存在してよい、またはコンピュータシステム１０００を含む分散型システムの多様なノードで分散されてよい。いくつかの実施形態では、類似する入出力装置はコンピュータシステム１０００とは別個であってよく、ネットワークインタフェース１０４０上で等、有線接続または無線接続を通してコンピュータシステム１０００を含む分散型システムの１つまたは複数のノードと対話してよい。ネットワークインタフェース１０４０は、一般に１つまたは複数の無線ネットワークプロトコル（例えば、Ｗｉ−Ｆｉ／ＩＥＥＥ ８０２．１１、または別の無線ネットワーキング規格）をサポートしてよい。ただし、多様な実施形態では、ネットワークインタフェース１０４０は、例えば他のタイプのイーサネットネットワーク等、任意の適切な有線汎用データネットワークまたは無線汎用データネットワークを介する通信をサポートしてよい。さらに、ネットワークインタフェース１０４０は、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ ＳＡＮ等のストレージエリアネットワークを介して、または任意の他の適切なタイプのネットワーク及び／またはプロトコルを介して、アナログ音声ネットワークまたはデジタルファイバ通信ネットワーク等の電気通信ネットワーク／電話網を介する通信をサポートしてよい。多様な実施形態では、コンピュータシステム１０００は、図１０に示される構成要素より多い、少ない、または異なる構成要素（例えば、ディスプレイ、ビデオカード、オーディオカード、周辺装置、ＡＴＭインタフェース、イーサネットインタフェース、フレームリレーインタフェース等の他のネットワークインタフェース等）を含んでよい。

本明細書に説明される分散型システムの実施形態のいずれも、またはその構成要素のいずれも１つまたは複数のウェブサービスとして実装されてよいことに留意されたい。例えば、データベースシステムのデータベース階層の中のデータベースエンジンヘッドノードは、データベースサービス、及び／または本明細書に説明される分散型ストレージシステムを利用する他のタイプのデータストレージサービスをウェブサービスとしてのクライアントに提示してよい。いくつかの実施形態では、ウェブサービスは、ネットワーク上で相互運用可能なマシン対マシンの対話をサポートするように設計されたソフトウェアシステム及び／またはハードウェアシステムによって実装されてよい。ウェブサービスは、ウェブサービス記述言語（ＷＳＤＬ）等のマシン処理可能なフォーマットで記述されるインタフェースを有してよい。他のシステムは、ウェブサービスのインタフェースの記述によって規定される方法でウェブサービスと対話してよい。例えば、ウェブサービスは、他のシステムが呼び出してよい多様な動作を定義してよく、多様な動作を要求するときに他のシステムが準拠することを期待されてよい特定のアプリケーションプログラミングインタフェース（ＡＰＩ）を定義してよい。

多様な実施形態では、ウェブサービスは、ウェブサービス要求と関連付けられるパラメータ及び／またはデータを含むメッセージを使用することによって要求されてよい、または呼び出されてよい。係るメッセージは、拡張マークアップ言語（ＸＭＬ）等の特定のマークアップ言語に従ってフォーマットされてよい、及び／またはシンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）等のプロトコルを使用してカプセル化されてよい。ウェブサービス要求を実行するために、ウェブサービスクライアントは、要求を含むメッセージをアセンブルし、ハイパテキスト転送プロトコル（ＨＴＴＰ）等のインターネットベースのアプリケーション層転送プロトコルを使用して、メッセージをウェブサービスに対応するアドレス可能なエンドポイント（例えば、ユニフォームリソースロケータ（ＵＲＬ））に伝達してよい。

いくつかの実施形態では、ウェブサービスは、メッセージベースの技法よりむしろ、表象状態転送（「ＲＥＳＴｆｕｌ」）技法を使用して実装されてよい。例えば、ＲＥＳＴｆｕｌ技法に従って実装されるウェブサービスは、ＳＯＡＰメッセージの中でカプセル化されるよりむしろ、ＰＵＴ、ＧＥＴ、またはＤＥＬＥＴＥ等のＨＴＴＰ方法の中に含まれるパラメータを通して呼び出されてよい。

以下の実施形態は以下の節を鑑みてさらによく理解されてよい。
１．それぞれが少なくとも１台のプロセッサ及びメモリを含み、
複数のログレコードのそれぞれが分散型ログ構造化ストレージシステムによって記憶されるデータに対するそれぞれの変更と関連付けられ、複数のログレコードのそれぞれが複数のログシーケンス番号のそれぞれのログシーケンス番号と関連付けられる、複数のログレコードを受信する、
スナップショット識別子を示し、複数のログレコードの内の特定のログレコードと関連付けられる複数のログシーケンス番号の１つをさらに示すメタデータを生成することを含む、スナップショットに対応する状態の時点のデータを読み取るために使用可能なスナップショットを生成する
ように構成されるデータベースサービスの分散型ログ構造化ストレージシステムを集合的に実装するように構成される１つまたは複数のコンピューティングノード、
を含むシステムであって、
スナップショットを上記生成することが、スナップショットを上記生成することの一部としてデータのページを読み取る、コピーする、または書き込むことなしに実行される、
システム。
２．メタデータが、ログレコードの１つまたは複数がガベージコレクトされるのを防ぐために使用できる、節１に記載のシステム。
３．メタデータが、複数のログレコードの別の特定のログレコードと関連付けられる複数のログシーケンス番号の別のログシーケンス番号をさらに示す、節１に記載のシステム。
４．メタデータが、スナップショットが連続スナップショットであることを示し、連続スナップショットが、第１の時点と第２の時点との間の複数の時点までデータを復元するために使用できる、節１に記載のシステム。
５．データベースサービスの１台または複数のコンピュータによって、
複数のログレコードを維持することであって、複数のログレコードのそれぞれがデータベースサービスによって記憶されるデータに対するそれぞれの変更と関連付けられる、複数のログレコードを維持することと、
スナップショットに対応する状態の時点のデータを読み取るために使用できるスナップショットを生成することであって、スナップショットを上記生成することが、ログレコードの内の特定のログレコードの特定のログ識別子を示すメタデータを生成することを含む、スナップショットを上記生成することと、
を実行すること、
を含む方法であって、
スナップショットを上記生成することが、スナップショットを上記生成することの一部としてデータのページを読み取る、コピーする、または書き込むことなしに実行される、
方法。
６．メタデータが、特定のログレコードを含んだログレコードの内の１つまたは複数が削除されることを防ぐために使用できる、節５に記載の方法。
７．メタデータが、スナップショットのタイプが連続であるのか、それとも不連続であるのかを示す、節５に記載の方法。
８．スナップショットに対応する状態の時点のデータを読み取ることであって、上記読み取ることがデータの以前のバージョンのコピーを作成することなく、特定のログレコードを含んだログレコードの１つまたは複数をデータの以前のバージョンに適用することを含む、スナップショットに対応する状態の時点のデータを読み取ること
をさらに含む、節５に記載の方法。
９．上記適用することが、データベースサービスのためのバックグラウンドプロセスとして実行される、節８に記載の方法。
１０．上記適用することが、データベースサービスの多様なノード全体で並列で実行される、節８に記載の方法。
１１．ログレコードの１つまたは複数がガベージコレクションから保護されることを示さないメタデータに少なくとも部分的に基づいてログレコードの１つまたは複数を削除すること、
をさらに含む、節５に記載の方法。
１２．ログレコードの１つまたは複数が、スナップショットのタイプに少なくとも部分的に基づいて削除されるべきであると決定することと、
ログレコードの１つまたは複数を削除することと、
をさらに含む、節５に記載の方法。
１３．スナップショットに対応する状態までデータを復元することと、
スナップショットに関連付けられている１つの時刻よりも遅い複数の時刻と関連付けられる１つまたは複数のログレコードがガベージコレクション可能であることを示すことと、
をさらに含む、節５に記載の方法。
１４．少なくとも部分的にスナップショットに基づいて複数のログレコードを合体すること、
をさらに含む、節５に記載の方法。
１５．プログラム命令を記憶する非一過性のコンピュータ可読記憶媒体であって、プログラム命令が、
複数のログレコードのそれぞれがデータページに対するそれぞれの変更に関連付けられる、複数のログレコードを分散型ストレージシステムの複数のノードに記憶する、及び
スナップショットに対応する状態の時点のデータページを読み取るために使用できるスナップショットを生成することであって、スナップショットを上記生成することが複数のログレコードの内の特定のログレコードと関連付けられる時刻を示すメタデータを生成することを含む、スナップショットを生成する、
ように構成される分散型ストレージシステムを実装するためにコンピュータにより実行可能であり、
スナップショットを上記生成することが、スナップショットを上記生成することの一部としてデータのページを読み取る、コピーする、または書き込むことなしに実行される、
非一過性のコンピュータ可読記憶媒体。
１６．メタデータがログレコードの１つまたは複数がガベージコレクトされるのを防ぐために使用できる、節１５に記載の非一過性のコンピュータ可読記憶媒体。
１７．分散型ストレージシステムが、
分散型ストレージシステムの複数のノードに別の複数のログレコードを記憶することであって、別の複数のログレコードのそれぞれが別のデータページのそれぞれの変更と関連付けられる、分散型ストレージシステムの複数のノードに別の複数のログレコードを記憶する
ようにさらに構成され、
スナップショットが、スナップショットに対応する状態の時点での他のデータページを読み取るためにさらに使用可能であり、メタデータが他の複数のログレコード内の特定のログレコードをさらに示す、
節１５に記載の非一過性のコンピュータ可読記憶媒体。
１８．分散型ストレージシステムが、
スナップショットに対応する状態の時点のデータページを読み取る、及び
スナップショットに関連付けられている１つの時刻よりも遅い複数の時刻と関連付けられる１つまたは複数のログレコードがガベージコレクション可能であることを示す
ようにさらに構成される、節１５に記載の非一過性のコンピュータ可読記憶媒体。
１９．分散型ストレージシステムが、
スナップショットに対応する状態の時点のデータページを読み取ることであって、前記読み取ることがデータページの以前のバージョンをコピーすることなく、特定のログレコードを含んだログレコードの１つまたは複数をデータページの以前のバージョンに適用することを含む、スナップショットに対応する状態の時点のデータページを読み取る
ようにさらに構成される、節１５に記載の非一過性のコンピュータ可読記憶媒体。
２０．上記適用することが、分散型ストレージシステムの複数のノード全体で分散される、節１９に記載の非一過性のコンピュータ可読記憶媒体。

図に示され、本明細書に説明される多様な方法は、方法の例の実施形態を表す。方法は、ソフトウェアで、ハードウェアで、またはソフトウェア及びハードウェアの組合せで手動で実装されてよい。任意の方法の順序は変更されてよく、多様な要素が追加、再順序付け、結合、省略、修正等、されてよい。

上記実施形態はかなり詳細に説明されているが、いったん上記開示が完全に理解されると当業者に明らかになるように、多数の変形形態及び修正形態が加えられてよい。続く特許請求の範囲が、すべての係る修正形態及び変更を包含すると解釈され、したがって上記説明は制限的な意味よりむしろ例示的な意味で考えられることが意図される。

Claims (15)

1. それぞれが少なくとも１台のプロセッサ及びメモリを備え、
   複数のログレコードのそれぞれが、分散型ログ構造化ストレージシステムによって記憶されるデータに対するそれぞれの変更を示し、前記複数のログレコードのそれぞれが複数のログシーケンス番号のそれぞれのログシーケンス番号と関連付けられる、前記複数のログレコードを受信する、及び
   スナップショットを生成するための要求に応答して、前記データのコピーを作成することなしに前記スナップショットに対応する状態の時点で読み取られる前記データのために適用できる前記複数のログレコードのうちの少なくとも１つを示すメタデータを格納し、前記メタデータは、前記複数のログレコードのうちの前記少なくとも１つのログ識別子である、
   ように構成されるデータベースサービスの前記分散型ログ構造化ストレージシステムを実装するように集合的に構成される、１つまたは複数のコンピューティングノード
   を備える、システム。
2. 前記メタデータが、前記ログレコードの１つまたは複数がガベージコレクトされるのを防ぐために使用できる、請求項１に記載の前記システム。
3. 前記メタデータが、前記複数のログレコードのうちの他の１つと関連付けられる、前記複数のログシーケンス番号のうちの１つをさらに示す、請求項１に記載の前記システム。
4. 前記メタデータが、前記スナップショットが連続スナップショットであることを示し、前記連続スナップショットが、第１の時点と第２の時点との間の複数の時点まで前記データを復元するために使用できる、請求項１に記載の前記システム。
5. データベースサービスの１台または複数のコンピュータによって、
   複数のログレコードを維持することであって、前記複数のログレコードのそれぞれが、前記データベースサービスによって記憶されるデータに対するそれぞれの変更を示す、複数のログレコードを維持することと、
   スナップショットを生成するための要求に応答して、前記データのコピーを作成することなしに前記スナップショットに対応する状態の時点で読み取られる前記データのために適用できる前記複数のログレコードのうちの少なくとも１つを示すメタデータを格納することであって、前記メタデータは、前記複数のログレコードのうちの前記少なくとも１つのログ識別子である、前記格納することと、
   を実行すること、
   を含む方法であって、
   前記スナップショットを前記生成することが、前記スナップショットを前記生成することの一部として前記データのページを読み取る、コピーする、または書き込むことなしに実行される、
   方法。
6. 前記メタデータが、前記少なくとも１つのログレコードを含んだ前記ログレコードのうちの１つまたは複数が削除されることを防ぐために使用できる、請求項５に記載の前記方法。
7. 前記メタデータが、前記スナップショットのタイプが連続であるのか、それとも不連続であるのかを示す、請求項５に記載の前記方法。
8. 前記スナップショットに対応する前記状態の時点での前記データを読み取ることであって、前記読み取ることが、前記データの以前のバージョンのコピーを作成することなく、前記少なくとも１つのログレコードを含んだ前記ログレコードの１つまたは複数を前記データの前記以前のバージョンに適用することを含む、前記スナップショットに対応する前記状態の時点での前記データを読み取ること
   をさらに含む、請求項５に記載の前記方法。
9. 前記適用することが、前記データベースサービスのためのバックグラウンドプロセスとして実行される、請求項８に記載の前記方法。
10. 前記適用することが、前記データベースサービスの多様なノード全体で並列で実行される、請求項８に記載の前記方法。
11. 前記ログレコードの１つまたは複数がガベージコレクションから保護されることを示さない前記メタデータに少なくとも部分的に基づいて前記ログレコードの前記１つまたは複数を削除すること、
    をさらに含む、請求項５に記載の前記方法。
12. 前記ログレコードの１つまたは複数が、前記スナップショットのタイプに少なくとも部分的に基づいて削除されるべきであると決定することと、
    前記ログレコードの前記１つまたは複数を削除することと、
    をさらに含む、請求項５に記載の前記方法。
13. 前記スナップショットに対応する前記状態まで前記データを復元することと、
    前記スナップショットに関連付けられている１つの時刻よりも遅い複数の時刻と関連付けられる１つまたは複数のログレコードがガベージコレクション可能であることを示すことと、
    をさらに含む、請求項５に記載の前記方法。
14. 少なくとも部分的に前記スナップショットに基づいて複数の前記ログレコードを合体すること、
    をさらに含む、請求項５に記載の前記方法。
15. １台または複数のプロセッサと、
    １つまたは複数のメモリであって、前記１台または複数のプロセッサ上で実行されるときに、
    複数のログレコードを分散型ストレージシステムの複数のノードに記憶することであって、前記複数のログレコードのそれぞれが、データページに対するそれぞれの変更を示す、分散型ストレージシステムの複数のノードに複数のログレコードを記憶する、及び
    スナップショットを生成するための要求に応答して、前記データのコピーを作成することなしに前記スナップショットに対応する状態の時点で読み取られる前記データのために適用できる前記複数のログレコードのうちの少なくとも１つを示すメタデータを格納し、前記メタデータは、前記複数のログレコードのうちの前記少なくとも１つのログ識別子である
    ように構成される前記分散型ストレージシステムを実装する、プログラム命令をその上に記憶しているメモリと、
    を備える、システム。

Images