JP6538780B2 - 分散型データベースシステムのシステム全体のチェックポイント回避 - Google Patents

Description

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

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

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

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

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

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

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

一実施形態に係るデータベースソフトウェアスタックの多様な構成要素を示すブロック図である。 いくつかの実施形態に従って、ウェブサービスベースのデータベースサービスを実装するように構成されてよいサービスシステムアーキテクチャを示すブロック図である。 一実施形態に係る、データベースエンジン、及び別個の分散型データベースストレージサービスを含むデータベースシステムの多様な構成要素を示すブロック図である。 一実施形態に係る、分散型データベース最適化ストレージシステムを示すブロック図である。 一実施形態に係る、データベースシステムでの別個の分散型データベース最適化ストレージシステムの使用を示すブロック図である。 一実施形態に係る、分散型データベース最適化ストレージシステムの所与のノードにデータ及びメタデータがどのように記憶されてよいのかを示すブロック図である。 一実施形態に係る、データベースボリュームの例の構成を示すブロック図である。 いくつかの実施形態に係る、分散型データベースシステムでのシステム全体のチェックポイント回避のための方法を示す流れ図である。 いくつかの実施形態に係る、分散型データベースシステムのための高速クラッシュ回復を実行する方法を明示する一連の図である。 いくつかの実施形態に係る、分散型データベースシステムのための高速クラッシュ回復を実行する方法を示す流れ図である。 いくつかの実施形態に係る、回復されたデータベースでアクセス要求を処理するための方法を示す流れ図である。 多様な実施形態に従って、データベースエンジン、及び別個の分散型データベースストレージサービスを含むデータベースシステムの少なくとも一部を実装するように構成されるコンピュータシステムを示すブロック図である。

分散型データベースシステムのためのシステム全体のチェックポイント回避の多様な実
施形態が開示される。分散型ストレージシステムのストレージノードは、いくつかの実施
形態では、ストレージノードに記憶される特定のデータページにリンクされる１つまたは
複数のリドゥログレコードをデータベースシステムから受信してよい。データページは、
データベースのためのデータを記憶する複数のデータページの内の１つであってよい。合
体イベントは、特定のデータページにリンクされる１つまたは複数のリドゥログレコード
に少なくとも部分的に基づいて特定のデータページについて検出されてよい。合体動作は
、特定のデータページの以前に記憶されていたバージョンに１つまたは複数のログレコー
ドを適用して、特定のデータページをその現在の状態で生成するために実行されてよい。

分散型データベースシステムのための高速クラッシュ回復の多様な実施形態が開示され
る。データベースシステムヘッドノードは、いくつかの実施形態では、故障回復動作を実
行してよい。システム故障から回復すると、データベースのためのデータを記憶する分散
型ストレージシステムのストレージノードとの接続が確立されてよい。いくつかの実施形
態では、ストレージノードとの接続の確立時、データベースヘッドノードは、データベー
スをアクセスのために利用できるようにしてよい。少なくともいくつかの実施形態では、
１つまたは複数のアクセス要求が受信されてよく、１つまたは複数のデータページの現在
の状態が要求され、ストレージノードから受信されてよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここで図８を参照すると、多様な実施形態では、上述されたように、データベースシス
テムは、ストレージノードのデータページの中に記憶されているデータに対する多様なア
クセス要求（例えば、書込み要求）に応えてリドゥログレコードを生成し、リドゥログレ
コードが生成されたそれぞれのデータページを記憶するストレージノードにリドゥログレ
コードを送信するように構成されてよい。ストレージノードは、特定のデータページのた
めの合体イベントを検出し、それに応じて特定のデータページのために合体動作を実行し
てよい。典型的なデータベースシステムは、一方、周期的な間隔で記憶されるデータに適
用される生成されたリドゥログのすべてをフラッシュし、このようにしてデータベースに
よって実行されるアクセス要求及び他のタスクの処理を中断させるシステム全体のチェッ
クポイントを適用してよい。

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

８１０に示されるように、データベースのために記憶される特定のデータページにリン
クされるリドゥログレコードが維持されてよい。これらのリドゥログレコード（上述され
たように、ＵＬＲと呼ばれることがある）は、ユーザーデータに対する変更を記述してよ
い。リドゥログレコードは、データページ等のユーザーデータの特定の部分にリンクされ
てよい。例えば、いくつかの実施形態では、リドゥログレコードは、特定のデータページ
に最終的にリンクされるリドゥログレコードの連鎖を形成し、各リドゥログレコードはデ
ータページのための以前に受信されたリドゥログレコードを指す。この例を使用すると、
３つのリドゥログレコードが特定のデータページにリンクされる場合には、最も最近に受
信されたリドゥログレコードは次に最も最近に受信されたリドゥログレコードを指し、次
に最も最近に受信されたリドゥログレコードは同様に３番目に最も最近に受信されたリド
ゥログレコードを指し、３番目に最も最近に受信されたリドゥログレコードはデータペー
ジの最も最近に保存された状態を指す。前のリドゥログレコードに対する各ポインタによ
って示されるリドゥログレコードの論理的な順序付けが、係るリドゥログレコードが係る
順序で物理的に記憶されることを暗示しないことに留意されたい。図６に関して上述され
たように、これらのリドゥログレコードは、いくつかの実施形態では、ユーザーデータの
他の部分にリンクされた他のリドゥログレコードとインタリーブされてよい。したがって
、前の例は制限的となることを目的としていない。

多様な実施形態では、リドゥログレコードは、ストレージノード４３０、４４０、４５
０等のストレージノードにデータが記憶されてよい、１つまたは複数のデータベースを管
理してよいデータベースエンジンヘッドノード４２０等のデータベースシステムから受信
されてよい。しかしながら、少なくともいくつかの実施形態では、ストレージノードは、
ストレージノードがデータを記憶するための１つまたは複数の追加のデータベースシステ
ムまたはノードからリドゥログレコードを受信してよい。これらの他のデータベースシス
テムまたはノードは、ストレージノードにそのそれぞれのデータベースのために記憶され
ているデータの特定の部分にリンクされたリドゥログレコードを送信してもよい。

いくつかの実施形態では、受信されたリドゥログレコードが次いで記憶されてよい。図
６は、係るリドゥログレコードがどのようにして受信され、処理され、ストレージノード
に記憶されてよいのかの多様な実施形態を説明する。多様な形式のメタデータが、データ
ページ等の特定の部分データにリンクされるリドゥログレコードの数つまりカウント等の
記憶されているリドゥログレコードのために維持されてよい。例えば、上記に示された例
でのように、３つのリドゥログレコードが特定のデータページにリンクされる場合、次い
で特定のデータページのリドゥログレコードカウントは３で維持されてよい。多様な他の
ログレコードに対するポインタまたはデータページの最も最近に保存された状態に対する
ポインタ等、サイズまたは物理的な場所、及びリドゥログレコードがリンクされるデータ
の部分等のリドゥログレコードに関する他のメタデータが維持されてよい。

記憶されているリドゥログレコードのために維持されるメタデータに対する更新は、リ
ドゥログレコード自体に対する変更、それらがリンクされる特定のデータページに対する
変更、またはリドゥログレコードを活用することによって、またはリドゥログレコードに
関して実行される動作もしくは他の方法もしくは技法に応えて行われてよい。例えば、８
３０で示されるように、合体動作が実行され、データページの現在の状態を生成するため
に特定のデータページにリンクされる１つまたは複数のリドゥログレコードを適用する場
合、次いでリドゥログレコードカウントは特定のデータページに対するリドゥログレコー
ドカウントからそれらの適用されたリドゥログレコードを削除するために更新されてよい
。

多様な実施形態では、特定のデータページのための合体イベントは、特定のデータペー
ジにリンクされる１つまたは複数のリドゥログレコードに少なくとも部分的に基づいて、
８２０で示されるように検出されてよい。検出された合体イベントは、合体動作が特定の
データページに対して実行されてよいことを示してよい。少なくともいくつかの実施形態
では、特定のデータページのための合体イベントを検出することは、他のデータページに
ついて検出された合体イベントとは関係なく、または他のデータページについて検出され
た合体イベントを考慮せずに発生してよい。特定のデータページが、多くのリドゥログレ
コードが受信される「ホット」データページであってよいシナリオを考える。リドゥログ
レコードはめったに他のデータページのために受信されることはない。合体イベントを検
出することは、合体閾値を超えるそれぞれのデータページにリンクされるリドゥログレコ
ードの数に基づいてよく、したがって、このシナリオでは、合体イベントは他のデータペ
ージについてより、特定の「ホット」データページについてより頻繁に検出されてよい。

合体イベントを検出することは、バックグラウンドプロセスとして実行してよいストレ
ージノード監視構成要素またはプロセスの一部として実行されてよく、読取り要求、書込
み要求、及び他のアクセス要求を処理するフォアグラウンドプロセスは、合体イベントの
検出の前に（または合体イベントの検出を遅延させて）実行されてよい。合体イベントの
検出は、ストレージノードの作業負荷が作業負荷閾値未満であるとき等、周期的な間隔ま
たは非周期的な間隔で発生してよい。

特定のデータページにリンクされたリドゥログレコードに少なくとも部分的に基づいて
合体イベントを検出するための多様な方法及び技法が実装されてよい。例えば、少なくと
もいくつかの実施形態では、合体閾値は合体イベントを検出するために活用されてよい。
合体閾値は、合体イベントが検出される前に特定のデータページにリンクされてよいリド
ゥログレコードの数を定義してよい。例えば、特定のデータページが、１０リドゥログレ
コードの合体閾値を超える１１リドゥログレコードを有する場合、次いで合体イベントが
検出されてよい。異なる合体閾値は異なるデータページに活用されてよい。例えば、デー
タページにリンクされた頻繁なリドゥログレコードを受信する「ホット」データページの
シナリオを再度考える。リドゥログレコードをあまり頻繁に受信しないデータページより
も高い合体閾値は、「ホット」データページに活用され、このようにして「ホット」デー
タページに対して実行される合体動作の数を削減してよい。代わりに、いくつかの実施形
態では、同じ合体閾値または類似する合体閾値が活用されてよい。合体閾値は、多様な他
の技法または構成部品と結合されてもよい。例えば、他の構成部品を使用していつ合体閾
値が超えられる可能性があるのかを計算し、タイマまたは他の構成要素を設定して、合体
イベント検出を実行するバックグラウンドモニタまたは他のプロセスに対し、特定のデー
タページのリドゥログレコードカウントが調べられるべきであることを示すこと。

少なくともいくつかの実施形態では、特定のデータページに対する（またはデータペー
ジの特定のセットに対する）合体閾値が決定されてよい。例えば、いくつかの実施形態で
は、合体閾値はユーザー定義の合体閾値に従って決定されてよい。ユーザー定義の合体閾
値は、要求され、決定され、もしくはデータベースエンジンヘッドノード４２０等のデー
タベースシステムからストレージノードに対して示される合体閾値であってよい、または
データベースシステムのクライアントは合体イベントを検出するために使用される合体閾
値を与えてよい。いくつかの実施形態では、合体閾値はストレージノードの作業負荷また
は性能に基づいて決定されてよい。例えば、いくつかの実施形態では、作業負荷測度また
は性能測度が、合体動作を実行するための能力が低いことを示す場合、次いで合体閾値は
、検出される合体イベントの数がストレージノードによってその現在の作業負荷で処理さ
れ得るように増加されてよい。いくつかの実施形態では、リドゥログレコードが特定のデ
ータページについて受信されるレートつまり頻度が計算され、合体閾値を決定するために
使用されてよい。少なくともいくつかの実施形態では、リドゥログレコードのサイズ、物
理記憶でのリドゥログレコードの場所、リドゥログレコードを記憶するために利用可能な
スペース、及び／または合体動作がデータページの以前に記憶されたバージョンにリドゥ
ログレコードを適用するために実行されてよい時刻等の多様な他の特徴が合体閾値を決定
するために使用されてよい。

特定のデータページに対する合体イベントを検出することに応えて、特定のデータペー
ジにリンクされる１つまたは複数のリドゥログレコードが、８３０で示されるように特定
のデータページをその現在の状態で生成するために特定のデータの以前に記憶されたバー
ジョンに適用されてよい。少なくともいくつかの実施形態では、特定のデータページにリ
ンクされるリドゥログレコードを適用することは合体動作の一部として実行される。上述
されたような合体動作つまり合体は、ユーザーページのより最近のバージョンを作成する
ためにＤＵＬＲ等のリドゥログレコードをユーザーページの初期のバージョンに適用して
よい。いくつかの実施形態では、合体動作は、最も最近のＡＵＬＲ（例えば、データペー
ジの以前に記憶されたバージョン）の位置を突き止め、ＤＵＬＲのいずれも省略すること
なくあらゆる以後のＤＵＬＲを順に適用することを含んでよい。例えば、３つのＤＵＬＲ
が受信され、ＡＵＬＲにリンクされている場合、最初に受信されたＤＵＬＲがＡＵＬＲに
適用される（このようにして、以前に記憶されたデータページを基準にして最初に受信さ
れた変更を適用する）。次いで、次に受信されたＤＵＬＲが適用され、最後に最も最近の
ＤＵＬＲが適用され、ストレージノードでのＤＵＬＲの受信に基づいて決定される順にＤ
ＵＬＲを適用する。いくつかの実施形態では、新しいＡＵＬＲは特定のデータページの現
在の状態として生成される。リドゥログレコードカウント等の上述されたメタデータは、
リドゥログレコードの適用を反映し、リドゥログレコードカウントに関して、その数をカ
ウントから削除するために更新されてよい。

少なくともいくつかの実施形態では、遅延は、８２０で示される合体イベントの検出と
８３０で示されるリドゥログレコードの適用との間で発生してよい、または実行されてよ
い。例えば、該検出及び該適用を実行するストレージノードの作業負荷が、リドゥログレ
コードを適用することの実行と、合体イベントの検出との間の遅延を決定してよい。同様
に、合体イベントの検出に応えるリドゥログレコードの適用はバックグラウンドプロセス
の一部として実行されてよい、すなわち削減される、つまり多様なアクセス要求（例えば
、読取り要求または書込み要求）の処理等、フォアグラウンドプロセスを実行しないとき
にだけ実行される。遅延した合体動作またはデータページのためのリドゥログの適用は、
データページがいつリドゥログレコードを適用させるべきであるのかの順序、シーケンス
、またはタイミングを決定する、先入先出し（ＦＩＦＯ）待ち行列または優先順位待ち行
列等のデータ構造に入れられてよい。例えば、上述されたシナリオでのように、「ホット
」データページが検出された合体イベントを有する場合、別のデータページの代わりに「
ホット」データページに対するリドゥログの適用を実行する方がより効率的であることが
ある。バックグラウンドプロセスとしてリドゥログレコードの適用を遅延するまたは実行
する結果として、合体イベントが検出されたデータページにリンクされる１つまたは複数
の追加のリドゥログレコードが受信されてよい。少なくともいくつかの実施形態では、こ
れらの追加のリドゥログレコードは、他のリドゥログレコードがデータページの以前に記
憶されたバージョンに適用されるときに適用されてよい。

図４に示されるように、複数のストレージノード４３０、４４０、４５０他は、分散型
ストレージサービスの一部として実装されてよい。上記図８に関して上述された多様な方
法及び技法は、これらの複数のストレージノードによって互いと無関係に実行されてよい
。各ストレージノードは、合体イベントを検出すること、及びそれに応じて同時にまたは
互いと異なるときに１つまたは複数のリドゥログレコードを適用することを実行するだけ
ではなく、異なる合体閾値または同じ合体閾値を決定してもよい。

ここで、いくつかの実施形態に従って、分散型データベースシステムのための高速クラ
ッシュ回復を実行するための方法を明示する一連の図を示す図９Ａを参照する。典型的な
データベースシステムにおけるクラッシュ回復は達成が困難なプロセスである。これらの
典型的なシステムでは、データベースシステム故障からの回復時、データベースのクリー
ンなバージョンが得られ、次いでディスクに記憶されていないトランザクションからのリ
ドゥログレコードのすべてが、データベースをデータベースシステム故障の前のその現在
の状態に復元するためにリプレイされなければならず、データベースにアクセスできるよ
うになる前に多大な復元時間を生じさせる。図９Ａは、一方、クラッシュ回復を実行する
ためのより高速且つより効率的な技法を提供してよい分散型データベースシステム用の高
速クラッシュ回復の説明を提供する。

シーン９９２で、図２に関して上述されたデータベースクライアント２５０等のデータ
ベースクライアント９０６は、図２に上述されたネットワーク２６０上で、データベース
を実装する、図４に関して上述されたデータベースヘッドノード４３０等のデータベース
ヘッドノード９０２と通信する。ストレージノード９０８は、データベースヘッドノード
９０２によって実装されるデータベースのためのログ構造化データストレージを実装する
１つまたは複数のストレージノードであってよい。多様なアクセス要求が受信され、その
後ストレージノード９０８からアクセスされたデータを取り出すと、データベースヘッド
ノード９０２によってサービスを提供されてよい。図８に関して上述されたもの等のリド
ゥログレコードが生成され、ユーザーデータを送信する代わりにストレージノード９０８
に送信されてよい。リドゥログレコードはストレージノード９０８で維持されてよい。少
なくともいくつかの実施形態では、合体動作は、図８に関して上述されたように等、合体
イベントの検出に応えて実行されてよい。

シーン９９４は、データベースヘッドノード９０２の故障を示す。データベースヘッド
ノード故障は、電源喪失、利用可能なメモリなし、システム障害等の、データベースヘッ
ドノードが機能を続行できないようにさせる任意のタイプのシステム故障であることがあ
る。データベースクライアント９０６とデータベースヘッドノード９０２との間の通信は
、図に示されるように送信または受信されないことがある。したがって、データベースに
対するアクセスは提供され得ない。同様に、ストレージノード９０８とデータベースヘッ
ドノード９０２との間の通信が送信または受信されないことがあり、したがってデータベ
ースのために記憶されているデータに対する要求が処理されないことがある。

シーン９９６では、回復動作が示されてよい。同じシステムハードウェアで再起動され
たヘッドノードアプリケーションプログラムのバージョン、または異なるハードウェアで
起動されたヘッドノードの別のインスタンスであってよい新しいデータベースヘッドノー
ド９０４がオンラインにされてよい。ストレージノード９０８との接続は、示されるよう
に、データベースヘッドノード９０４によって確立されてよい。シーン９９８は、ストレ
ージノード９０８との接続の確立時、データベースヘッドノード９０２で実装されたのと
同じデータベースが、新しいデータベースヘッドノード９０４でのアクセスのために利用
可能にされてよいことを示す。読取り要求または書込み要求等のアクセス要求は、ネット
ワーク２６０を介してデータベースクライアント９０６から新しいデータベースヘッドノ
ード９０４に送信されてよい。リドゥログレコードはすでに、アクセス要求にサービスを
提供するために新しいデータベースヘッドノード９０８にデータベースのために記憶され
ているデータのカレントバージョンを提供してよいストレージノード９０８に送信されて
いたので、新しいデータベースヘッドノード９０４は、データベースヘッドノード故障の
前にデータの現在の状態を入手するためにこれらのリドゥログレコードをリプレイする必
要がないことがある。ストレージノード９０８は、特定のデータに対する要求が受信され
るとき特定のデータの以前に記憶されていたバージョンにリドゥログレコードを適用して
よい。代わりに、特定のデータの現在の状態は、図８に関して上述されたように合体イベ
ントが検出されるとき等、あらゆるリドゥログレコードがすでに適用されている特定に向
けられた状態でストレージノードにすでに記憶されていてよい。

図９Ｂは、いくつかの実施形態に係る、分散型データベースシステムのための高速クラ
ッシュ回復を実行する方法を示す流れ図である。多様な実施形態では、データベースヘッ
ドノード故障が発生することがある。このヘッドノード故障はあらゆる通信、修正、また
は故障したデータベースヘッドノードによって実装され、管理されるデータベースへの他
の形のアクセスを妨げることがある。例えば、図２に説明されるデータベースクライアン
ト２５０等のデータベースシステムクライアントは、故障したデータベースヘッドノード
に読取り要求または書込み要求を送信できないことがある。データベースヘッドノードの
故障は、例えば図２に上述されたウェブサービスプラットホーム２００、または何らかの
他のシステムもしくは構成要素によって検出されてよい。ヘッドノードの故障に応えて、
再起動されたデータベースヘッドノードまたは新しいデータベースヘッドノード（例えば
、以前に故障したヘッドノードと同じまたは異なるハードウェア上でホストされる新しい
データベースヘッドノード仮想インスタンス）が、回復動作を実行するように命令されて
よい。いくつかの実施形態では、この回復動作はこれらの要素に制限されていないが、回
復動作は図９Ｂに示される多様な要素を含んでよい。

データベースヘッドノード故障からの回復は、９１０に示されるように発生してよい。
回復は実行され、さまざまな方法で完了していると決定されてよい。例えば、データベー
スヘッドノードアプリケーションは、多様なテストを実行すること、多様な装置を有効に
すること等、実行するために準備するときに多様な状態を有することがある。このプロセ
スの一部として、ノード故障からの回復の完了を示してよいデータベースヘッドノードに
ついて準備完了した状態が決定されてよい。９１０に示されるように、データベースノー
ド故障からの回復時、１台または複数のストレージノードとの接続が確立され、９２０に
示されるように、データベースのためにデータを記憶することが確立されてよい。

図９Ａ及び上記の多様な他の図に関して上述されたように、データベースは、図３及び
図４に説明されるデータベースヘッドノード３２０または４４０等のデータベースヘッド
ノードによって実装され、管理されてよい。上述された読取り要求または書込み要求等の
データベースアクセス要求を実装することの一部として、データベースヘッドノードで処
理されてよい。少なくともいくつかの実施形態では、データベースに対する変更を反映す
るリドゥログレコードは、ストレージノードに記憶されるデータに対する変更を反映する
、図４で上述されたストレージノード４５０等の１つまたは複数のストレージノードに送
信される。特定のデータページまたはデータの他の部分等の、変更されるデータを記憶す
るストレージノードは、変更される、データページ等のデータの部分にリンクされるリド
ゥログレコードを受信してよい。これらのリドゥログレコードは、データページのカレン
トバージョンに対する要求に応えて、または合体イベントの検出に応えて等、なんらかの
他の時に、データページ等のデータの部分の以前に記憶されていたバージョンに適用され
てよい（例えば、合体動作）。データベースのためのリドゥログレコードは、上述された
多様な方法で、データベースヘッドノードで実装されるデータベースのために維持される
ので、いくつかの実施形態では、ストレージノードはデータベースヘッドノードに、デー
タベースヘッドノード故障の時刻まで最新であると保証されるデータの現在の状態を送信
してよい。

接続の確立先のストレージノードが識別されてよい。例えば、図４で上述されたクライ
アント側ストレージサービスドライバ４２５は、どのストレージノードがデータベースの
ためにデータを記憶するのか、及びデータベースのどの部分がストレージノードに記憶さ
れるのかを示す情報を維持してよい。接続要求、または何らかの他の通信メッセージは、
図４に関して上述された多様な通信方法の１つを使用して送信されてよい。同様に、肯定
応答、及びストレージノード及び／またはデータベースヘッドノードのステータスについ
ての他の情報が交換されてよい。

９２０に示されるように、１つまたは複数のストレージノードとの接続の確立時、デー
タベースは、９３０に示されるように、アクセスのために利用可能にされてよい。いくつ
かの実施形態では、アクセスは１つまたは複数のアクセス要求（例えば、読取り要求、書
込み要求）に提供されてよい。データベースの可用性の表示が生成され、クライアントに
送信されてよい。例えば、データベースがアクセスに利用可能である旨のメッセージがデ
ータベースクライアントに送信されてよい。係るメッセージは、図２に説明されるウェブ
サービスプラットホーム２００、またはなんらかの他の通信プラットホームもしくは装置
を介して送信されてよい。上述されたように、典型的なデータベースシステムでは、リド
ゥログレコードのリプレイは、データベースを利用可能にする前に実行されなければなら
ない。しかし、少なくともいくつかの実施形態では、データベースはリドゥログレコード
をリプレイせずに利用可能にされてよい。リドゥログレコードとともに使用されるときの
用語「リプレイ」が概してデータの以前に記憶されていたバージョンに対して１つまたは
複数のリドゥログレコードを適用することを意味することに留意されたい。

少なくともいくつかの実施形態では、ストレージノードは、データベースヘッドノード
故障を検出できてよい、またはそれ以外の場合データベースヘッドノード故障を認識させ
られてよい。データベースヘッドノード故障の検出に応えて、ストレージノードは、スト
レージノードで受信されたリドゥログレコードに対する切り詰め演算を実行してよい。切
り詰め演算は、データベースヘッドノードの故障の前に完了しなかったシステムトランザ
クションの一部であるリドゥログレコードを決定してよい、または識別してよい。これら
の識別されたリドゥログレコードは、それらがリンクされているデータページにそれらが
適用され得ないように、削除されてよい、またはそれ以外の場合、マークされてよい、移
動されてよい、もしくは識別されてよい。例えば、記憶ページが特定のデータページのた
めに５リドゥログレコードを維持し、最も最近の３リドゥログレコードが、データベース
ヘッドノード故障の前に完了しなかったシステムトランザクションの一部である場合、次
いでストレージノードは、２つの最も旧いリドゥログレコードだけを適用することによっ
てデータページの現在の状態を生成するときに最も最近の３リドゥログレコードを無視し
てよい。少なくともいくつかの実施形態では、切り詰め演算は、回復されたデータベース
ヘッドノードと接続を確立できるようになる前に、影響を受けたリドゥログレコードがあ
るストレージノードに対して実行されてよい。データベースエンジンヘッドノードは、い
くつかの実施形態では、データベースヘッドノードの故障前に完了しなかったシステムト
ランザクションの一部であるリドゥログレコードを同様に決定し、または識別し、これら
の識別されたリドゥログレコードが、それらがリンクされているデータページにそれらが
適用され得ないように削除されてよい、またはそれ以外の場合マークされてよい、移動さ
れてよい、または識別されてよい旨の通知をストレージノードに送信するように構成され
てよい。例えば、図３に関して上述されたクライアント側ストレージサービスドライバ３
２５等のクライアント側ストレージサービスドライバは、上述された技法を実行してよい
。切り詰め演算を説明するこれらの技法は、いくつかの実施形態では、バックグラウンド
プロセスの一部として実行されてよい。

少なくともいくつかの実施形態では、システムトランザクションは、ユーザートランザ
クションを実行する、または実装するための動作または他の形の１つもしくは複数のタス
クであってよい。ユーザートランザクションは、受信されたアクセス要求から多様なタス
クまたは動作を実行するために複数のシステムトランザクションを含んでよい。例えば、
データベースに対する挿入命令が受信されてよい。ユーザートランザクションとして、こ
の挿入命令は、挿入を実行するために、例えばｂ−ツリー等のデータベースデータ構造に
作用する等、挿入を実行するための複数のシステムトランザクションを含んでよい。少な
くともいくつかの実施形態では、不完全なユーザートランザクションは、ユーザートラン
ザクションであり、該ユーザートランザクションに含まれるシステムトランザクションの
すべてが完了していない（または耐久的にされていない）可能性がある。同様に、システ
ムトランザクションは不完全なことがある。ユーザートランザクション及びシステムトラ
ンザクションの一部としてデータベースのために記憶されたデータに対して行われた変更
を反映するリドゥログレコードは、いくつかの実施形態では、特定のユーザートランザク
ション及び／またはシステムトランザクションで識別されてよい。

図９Ｃは、いくつかの実施形態に係る、回復されたデータベースでアクセス要求を処理
するための方法を示す流れ図である。上述されたように、少なくともいくつかの実施形態
では、アクセス要求が受信されてよく、アクセスのためにデータベースを利用できるよう
にしたデータベースヘッドノード。アクセス要求は、読取り要求、書込み要求、またはデ
ータベースのために記憶されているデータを入手するもしくは修正するための任意の他の
要求であってよい。図９Ｃが示すように、アクセス要求は、９４０で示されるようにデー
タベースに対して受信されてよい。それに応じて、９５０示されるように１つまたは複数
のストレージノードからの１つまたは複数のデータページに対する要求が行われてよい（
クライアントからのアクセス要求及びデータベースヘッドノードからのデータ要求の両方
とも、上記図５に関してより詳細に扱われている）。要求された１つまたは複数のデータ
ページの現在の状態は、９６０に示されるように、ストレージノードから受信されてよい
。上述されたように、この現在の状態は、データページの以前に記憶されたバージョンま
で以前に受信されたリドゥログレコードをリプレイする、もしくはデータページの以前に
記憶されたバージョンに以前に受信されたリドゥログレコードを適用することによって、
または現在の状態であるデータページの以前に記憶されたバージョンを返すことによって
生成されてよい。多様な実施形態では、各データページまたは要求されたデータの一部は
、（例えばゆったりと）データに対する要求を受信することに応えて、その現在の状態を
決定させる、生成させる、及び／または送り返させてよい。

少なくともいくつかの実施形態では、アンドゥログレコードは、データベースヘッドノ
ードで維持されてよい。上述されたようなアンドゥログレコードは、不完全なユーザート
ランザクションが発生した場合に等、データに対して行われた変更をアンドゥするために
データベースのために記憶されるデータに適用される変更を記録してよい。ユーザートラ
ンザクションは、（複数のシステムトランザクション等の）データベースのために記憶さ
れるデータに対する複数の変更を含み、１つまたは複数のリドゥログレコード及び１つま
たは複数のアンドゥログレコードを生成してよい。ユーザートランザクションは、ユーザ
ートランザクションの変更のすべてがコミットされなかった（例えば、耐久的にされなか
った）ときに不完全であることがある。図３に関して上述されたトランザクションログ３
４０等のトランザクションテーブルは、どのユーザートランザクション、及びストレージ
ノードに記憶されているデータのその関連付けられた部分が、データベースヘッドノード
故障前にコミットされず、したがって不完全であるのかを示すために実装されてよい。９
７０で示されるように、受信されたデータページがトランザクションテーブルによって示
される等、不完全なユーザートランザクションによって影響を及ぼされるかどうかに関し
て決定が下されてよい。はいである場合、肯定の出口が示すように、次いでアンドゥログ
レコードの１つまたは複数が、不完全なトランザクションによって行われた変更をアンド
ゥして、９７２に示すように、データページの新しい現在の状態を生成するためにデータ
ページに適用されてよい。アンドゥログレコードが適用された、つまり不完全なユーザー
トランザクションによってデータページが影響を及ぼされなかった後、次いでデータペー
ジの現在の状態が、９８０で示されるようにアクセス要求にサービスを提供するために提
供されてよい。

少なくともいくつかの実施形態で、トランザクションテーブルに基づいて、不完全なユ
ーザートランザクションによって影響を受けたデータの部分を決定する、または識別する
バックグラウンドプロセスが実行されてよい。不完全なユーザートランザクションによっ
て影響を受けた、データページ等のデータの部分の現在の状態に対する要求が送受されて
よい。アンドゥログレコードは、次いで、不完全なユーザートランザクションによってこ
れらのデータページに向けられた変更をアンドゥするために適用されてよい。多様な実施
形態では、データベースキャッシュが、アンドゥログレコードが適用された後にこれらの
データページで更新されてよい。

少なくともいくつかの実施形態では、以前に記録されたスナップショットが、データベ
ースの状態を初期の状態に復元するために使用されてよい。例えば、アクセスのためにデ
ータベースを利用可能にする前に、要求は、データベースのためのデータを以前に記録さ
れたスナップショットに対応する状態に復元するためにストレージノードに送信されてよ
い。スナップショットは、以前に受信されたリドゥログレコードを、記録されたスナップ
ショット点（例えば、タイムスタンプまたはマーカ）までリプレイできるようにする、ス
トレージノードに記憶されるリドゥログのためのタイムスタンプまたは他のマーカまたは
インジケータを識別することによって記録されてよく、該復元は複数のリドゥログの１つ
または複数をデータの以前のバージョンに適用することを含む。ストレージノードにスナ
ップショットを実装する追加説明が上記に示される。

図９Ｂから図９Ｃの方法及び技法は、データベースエンジンヘッドノード４２０等のデ
ータベースシステムの多様な構成要素によって実行されるとして説明されてよいが、方法
は、いくつかの場合、いずれの特定の構成要素によっても実行される必要はない。例えば
、いくつかの場合、図９Ｂから図９Ｃは、いくつかの実施形態に従って、なんらかの他の
構成要素またはコンピュータシステムによって実行されてよい。また、いくつかの場合、
データベースシステム４００の構成部品は、データベースシステム４００の構成要素は、
図４の例に示されるのとは異なって組み合されてよい、または存在してよい。多様な実施
形態では、図９Ｂから図９Ｃの方法は分散型データベースシステムの１台または複数のコ
ンピュータによって実行されてよく、その内の１つは図１０のコンピュータシステムとし
て示される。図９Ｂから図９Ｃの方法は、分散型データベースシステムの高速クラッシュ
回復のための方法の例の実装として示される。他の実装では、図９Ｂから図９Ｃの方法は
追加のブロック、または図示されるよりも少ないブロックを含んでよい。

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

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

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

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

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

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

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

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

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

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

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

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

上述は以下の節を鑑みてさらによく理解されてよい。
１．データベースサービスの少なくとも１つのデータベースエンジンヘッドノードであっ
て、
ストレージノードが特定のデータページを含んだ複数のデータページにデータベースの
ためのデータを記憶し、１つまたは複数のリドゥログレコードのそれぞれが特定のデータ
ページの中に記憶されるデータに対する１つまたは複数のアクセス要求に応えて生成され
る、分散型ストレージサービスを実装する複数のストレージノードの内の１つのストレー
ジノードに記憶される複数のデータページの内の特定のデータページにリンクされる１つ
または複数のリドゥログレコードを生成する、
ストレージノードに１つまたは複数のリドゥログレコードを送信する
ように構成される、少なくとも１つのデータベースエンジンヘッドノードと、
分散型ストレージサービスの前記ストレージノードであって、
特定のデータページにリンクされる受信された１つまたは複数のリドゥログレコードを
記憶する、
特定のデータページにリンクされる１つまたは複数のリドゥログレコードが合体閾値を
超えると判断する、及び
合体動作が特定のデータページにリンクされる１つまたは複数のリドゥログレコードを
特定のデータページの以前に記憶されたバージョンに適用して、特定のデータページをそ
の現在の状態で生成することを含む、該合体動作を実行する
ように構成されるストレージノードと、
を含んだシステム。
２．ストレージノードが複数のデータページのそれぞれのためにリドゥログレコードカウ
ントを維持するようにさらに構成され、
特定のデータページにリンクされる１つまたは複数のリドゥログレコードが合体閾値を
超えると判断するために、少なくとも１つの計算ノードが、特定のデータページのために
維持されるリドゥログレコードカウントが合体閾値を超えると判断するようにさらに構成
される、
節１に記載のシステム。
３．ストレージノードが、合体動作を実行することに応えて、特定のデータページにリン
クされる１つまたは複数のリドゥログレコードをリドゥログレコードカウントから削除す
るためにリドゥログレコードカウントを更新するようにさらに構成される、節２に記載の
システム。
４．データベースエンジンヘッドノードが、ストレージノードに記憶される複数のデータ
ページの別のデータページにリンクされる、１つまたは複数の他のリドゥログページを以
前に生成し、送信しており、
データベースエンジンヘッドノードが、
データベースエンジンヘッドノード故障からの回復時に、特定のデータページの現在の
状態、及び他のデータページの現在の状態に対する要求をストレージノードに送信する
ようにさらに構成され、
ストレージノードが、
特定のデータページの現在の状態、及び他のデータページの現在の状態に対する要求を
データベースエンジンヘッドノードから受信する、及び
特定のデータページに対する要求を受信することに応えて、データベースエンジンヘッ
ドノードに特定のデータページの以前に生成された現在の状態を送信し、
他のデータページに対する要求を受信することに応えて、
他のデータページにリンクされる１つまたは複数の他のリドゥログレコードを他のデー
タページの以前に記憶されたバージョンに適用して、他のデータページをその現在の状態
で生成するために合体動作を実行する、及び
データベースエンジンヘッドノードに他のデータページの現在の状態を送信する
ようにさらに構成される、
節１に記載のシステム。
５．１台または複数のコンピューティング装置によって、
データベースのために記憶される特定のデータページにリンクされる１つまたは複数の
リドゥログレコードを維持すること、
特定のデータページにリンクされる１つまたは複数のリドゥログレコードに少なくとも
部分的に基づいて特定のデータページのための合体イベントを検出すること、及び
特定のデータページのための合体イベントを検出することに応えて、特定のデータペー
ジにリンクされる１つまたは複数のリドゥログレコードを特定のデータページの以前に記
憶されたバージョンに適用して、特定のデータページをその現在の状態で生成すること
を実行すること
を含む、方法。
６．特定のデータページのための合体イベントを該検出することが非周期的に発生する、
節５に記載の方法。
７．特定のデータページのための合体イベントを該検出することが、特定のデータページ
にリンクされる１つまたは複数のリドゥログレコードが合体閾値を超えると判断すること
をさらに含む、節５に記載の方法。
８．特定のデータページのための合体イベントを該検出することが、ユーザー定義の合体
閾値に従って合体閾値を決定することをさらに含む、節７に記載の方法。
９．データベースのために記憶される異なるデータページにリンクされる１つまたは複数
の追加のリドゥログレコードを維持することと、
異なるデータページにリンクされる１つまたは複数の追加のリドゥログレコードが別の
合体閾値を超えると判断することであって、該他の合体閾値が該合体閾値とは異なる、判
断することと、
をさらに含む、節７に記載の方法。
１０．１台または複数のコンピューティング装置がともに分散型ストレージサービスを実
装する複数のストレージノードの内の１つのストレージノードを実装し、１つまたは複数
のリドゥログレコードが、それぞれが複数のストレージノード全体でデータベースのため
に記憶される特定のデータページを含んだ複数のデータページの内の１つにリンクされる
複数のリドゥログレコードに含まれ、複数のリドゥログレコードがデータベースシステム
から受信される、節５に記載の方法。
１１．複数のストレージノードの内の１つまたは複数の他のストレージノードが、１つま
たは複数の他のストレージノードに記憶される複数のデータページの内の異なるデータペ
ージを該維持する、該検出する、及び該適用することを実行する、節１０に記載の方法。
１２．該検出すること及び該適用することが、１つまたは複数の他のストレージノードに
記憶されるデータページの内の異なるデータページのために異なる時間に実行される、節
１２に記載の方法。
１３．１台または複数のコンピューティング装置がともに、分散型ストレージサービスを
実装する複数のストレージノードの内の１つのストレージノードを実装し、
特定のデータページのための合体イベントを検出することに応えて、
特定のデータページにリンクされる１つまたは複数のリドゥログレコードを特定のデー
タページの以前に記憶されたバージョンに適用して、特定のデータページをその現在の状
態で生成する前に、ストレージノードによって実行される他のプロセスの作業負荷に少な
くとも部分的に基づいて１つまたは複数のリドゥログレコードを該適用することの開始を
遅延させること、
をさらに含む、節５に記載の方法。
１４．１台または複数のコンピューティング装置によって実行されるときに、
データベースのために記憶される特定のデータページにリンクされる１つまたは複数の
リドゥログレコードを維持すること、
特定のデータページにリンクされる１つまたは複数のリドゥログレコードが合体閾値を超
えると判断すること、及び、
特定のデータページにリンクされる１つまたは複数のリドゥログレコードを特定のデー
タページの以前に記憶されたバージョンに適用して、特定のデータページをその現在の状
態で生成すること、
を実装するプログラム命令を記憶する非一過性のコンピュータ可読記憶媒体。
１５．１台または複数のコンピューティング装置がともに、分散型ストレージサービスの
ストレージノードを実装し、プログラム命令が、１台または複数のコンピューティング装
置によって実行されるときに、ストレージノードの性能に少なくとも部分的に基づいて合
体閾値を決定することをさらに実装する、節１４に記載の非一過性のコンピュータ可読記
憶媒体。
１６．プログラム命令が、１台または複数のコンピューティング装置によって実行される
ときに、特定のデータページにリンクされる受信されたリドゥログレコードの頻度に少な
くとも部分的に基づいて合体閾値を決定することをさらに実装する、節１４に記載の非一
過性のコンピュータ可読記憶媒体。
１７．プログラム命令が、１台または複数のコンピューティング装置によって実行される
ときに、記憶空間可用性に少なくとも部分的に基づいて合体閾値を決定することをさらに
実装する、節１４に記載の非一過性のコンピュータ可読記憶媒体。
１８．プログラム命令が、１台または複数のコンピューティング装置によって実行される
ときに、１つまたは複数のリドゥログレコードを該適用することが実行されてよいときの
時刻に少なくとも部分的に基づいて合体閾値を決定することをさらに実装する、節１４に
記載の非一過性のコンピュータ可読記憶媒体。
１９．プログラム命令が、１台または複数のコンピューティング装置によって実行される
ときに、特定のデータページにリンクされる１つまたは複数のリドゥログレコードの１つ
または複数のサイズに少なくとも部分的に基づいて合体閾値を決定することをさらに実装
する、節１４に記載の非一過性のコンピュータ可読記憶媒体。
２０．プログラム命令が、１台または複数のコンピューティング装置によって実行される
ときに、特定のデータページにリンクされる１つまたは複数のリドゥログレコードのため
の１つまたは複数の記憶場所に少なくとも部分的に基づいて合体閾値を決定することをさ
らに実装する、節１４に記載の非一過性のコンピュータ可読記憶媒体。
２１．特定のデータページにリンクされる１つまたは複数のリドゥログレコードを特定の
データページの以前に記憶されたバージョンに該適用して、特定のデータページをその現
在の状態で生成することがバックグラウンドプロセスとして実行される、節１４に記載の
非一過性のコンピュータ可読記憶媒体。
２２．プログラム命令が、１台または複数のコンピューティング装置によって実行される
ときに、特定のデータページにリンクされる１つまたは複数のリドゥログレコードを特定
のデータページの以前に記憶されたバージョンに適用して、特定のデータページをその現
在の状態で生成することに応えて、特定のデータページのリドゥログレコードカウントを
更新して、リドゥログレコードカウントから特定のデータページにリンクされる１つまた
は複数のリドゥログレコードを削除するようにさらに構成される、節１４に記載の非一過
性のコンピュータ可読記憶媒体。
２３．プログラム命令が、１台または複数のコンピューティング装置によって実行される
ときに、
特定のデータページにリンクされる別のリドゥログレコードを受信すること、及び
特定のデータページにリンクされる他のリドゥログレコードを含むために特定のデータ
ページのためのリドゥログレコードカウントを更新すること
を実装する、節２２に記載の非一過性のコンピュータ可読記憶媒体。

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

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

Claims (15)

1. 少なくとも１つのプロセッサと、
   ストレージボリュームの異なる各々の部分にアクセスするために、
   少なくとも部分的にデータストアで受信されたアクセス要求に基づいて、前記データストアに記憶された前記ストレージボリュームの前記異なる各々の部分を記憶する複数のデータページの個々のデータページのための合体イベントを独立して検出させ、
   前記検出された合体イベントに応答して前記個々のデータページのための各々の合体動作を前記少なくとも１つのプロセッサに、少なくとも実行させるプログラム命令を記憶するメモリを備え、前記プログラム命令は、前記少なくとも１つのプロセッサに、
   前記データストアに記憶された前記複数のデータページに対する記述変更ログにアクセスして、前記個々のデータページに対する変更を取得させ、
   前記個々のデータページに対して前記取得された変更を適用して、前記個々のデータページの異なるバージョンを生成させ、
   受信されるアクセス要求にサービスを提供するために、前記個々のデータページの前記異なるバージョンで前記個々のデータページを置き換えさせるシステム。
2. 合体イベントを独立して検出するために、前記方法は、前記少なくとも１つのプロセッサに、
   前記個々のデータページに対する前記検出された合体イベントを始動する各々の閾値基準を評価させ、前記個々のデータページの１つに対する前記検出された合体イベントの１つのために前記それぞれの閾値基準は、前記個々のデータページの他の１つに対する前記検出された合体イベントの他の１つのための前記各々の閾値基準とは異なる請求項１に記載のシステム。
3. 前記方法は、さらに、前記少なくとも１つのプロセッサに前記複数のデータページに対する前記記述変更ログに記載された変更の各々のカウントを追跡させ、
   前記各々の閾値基準の前記評価は、前記変更の各々のカウントが前記各々の閾値基準を超えることを判断するために、前記記述変更ログに記述の前記変更のカウントを前記個々のデータページに対する前記各々の閾値基準に対して比較する請求項２に記載のシステム。
4. 前記方法は、さらに、前記少なくとも１つのプロセッサに、
   前記各々の閾値基準の評価に先立って、少なくとも部分的に、前記１つの個々のデータページがアクセスされる頻度に基づいて、前記１つの個々のデータページに対する前記各々の閾値基準を変更することを実施させる請求項２に記載のシステム。
5. 合体イベントを独立して検出するために、前記方法は、前記少なくとも１つのプロセッサに、合体動作を実行する能力に従って、前記個々のデータページに対しする前記検出された合体イベントを始動する閾値基準を決定させる請求項１に記載のシステム。
6. 合体イベントを独立して検出するために、前記方法は、前記少なくとも１つのプロセッサに、前記記述変更ログに追加の変化を記憶するための利用可能な空間に従って、前記個々のデータページに対する前記検出された合体イベントを始動する閾値基準を決定させる請求項１に記載のシステム。
7. 前記少なくとも１つのプロセッサは、分離されたデータベースの代わりに、前記複数のデータページを記憶する分散型データストアのための第１のストレージノードの一部として実装され、前記分散型データストアは、前記データベースの代わりに、他のデータページを記憶する第２のストレージノードをさらに実装し、前記第２のストレージノードは、前記第１のストレージノードとは独立して合体イベントを検出し且つ合体動作を実行する請求項１に記載のシステム。
8. 少なくとも１つのプロセッサによって実行される方法であって、
   ストレージボリュームの異なる各々の部分にアクセスするために、
   少なくとも部分的にデータストアで受信されたアクセス要求に基づいて、前記データストアに記憶された前記ストレージボリュームの前記異なる各々の部分を記憶する複数のデータページの個々のデータページのための合体イベントを独立して検出すること、
   前記検出された合体イベントに応答して前記個々のデータページに対するそれぞれの合体動作を実行すること、且つ 前記データストアに記憶された前記複数のデータページに対する記述変更ログにアクセスして前記個々のデータページに対する変更を取得すること、
   前記個々のデータページに対して前記取得された変更を適用して、前記個々のデータページの異なるバージョンを生成すること、
   受信されるアクセス要求にサービスを提供するために、前記個々のデータページの前記異なるバージョンで前記個々のデータページを置き換えること
   を含む方法。
9. 合体イベントを独立して検出することは、
   前記検出された合体イベントを始動する各々の閾値基準を評価し、前記個々のデータページの１つに対する前記検出された合体イベントの１つのために前記それぞれの閾値基準は、前記個々のデータページの他の１つに対する前記検出された合体イベントの他の１つのための前記各々の閾値基準とは異なる請求項８に記載の方法。
10. 前記方法は、前記複数のデータページに対する前記記述変更ログに記載された変更の各々のカウントを追跡することをさらに備え、
    前記各々の閾値基準の前記評価は、前記変更の各々のカウントが前記各々の閾値基準を超えることを判断するために、前記記述変更ログに記述の前記変更のカウントを前記個々のデータページに対する前記各々の閾値基準に対して比較する請求項９に記載の方法。
11. 前記方法は、前記各々の閾値基準の評価に先立って、少なくとも部分的に、前記１つの個々のデータページがアクセスされる頻度に基づいて、前記１つの個々のデータページに対する前記各々の閾値基準を変更することをさらに備える請求項９に記載の方法。
12. 合体イベントを独立して検出することは、合体動作の能力に従って、個々のデータページに対する前記検出された合体イベントを始動する閾値基準を決定することを備える請求項８に記載の方法。
13. 合体イベントを独立して検出することは、前記記述変更ログに追加の変更を記憶するための利用可能な空間に従って、前記個々のデータページに対する前記検出された合体イベントを始動する閾値基準を決定することを備える請求項８に記載の方法。
14. 前記合体イベントを独立して検出することおよび前記各々の合体動作を実行することは、分離されたデータベースに代わって、前記複数のデータページを記憶する分散型データストアのための第１のストレージノードによって実行され、前記分散型データストアは、前記データベースに代わって、他のデータページを記憶する第２のストレージノードをさらに実装し、且つ前記第２のストレージノードは、前記第１のストレージノードとは独立して合体イベントを検出し且つ合体動作を実行する請求項８に記載の方法。
15. 少なくとも１つのプロセッサに、
    ストレージボリュームの異なる各々の部分にアクセスするために、
    少なくとも部分的にデータストアで受信されたアクセス要求に基づいて、前記データストアに記憶された前記ストレージボリュームの前記異なる各々の部分を記憶する複数のデータページの個々のデータページのための合体イベントを独立して検出させること、
    前記検出された合体イベントに応答して前記個々のデータページに対するそれぞれの合体動作を実行させること、且つ 前記データストアに記憶された前記複数のデータページに対する記述変更ログにアクセスして前記個々のデータページに対する変更を取得すること、
    前記個々のデータページに対して前記取得された変更を適用して、前記個々のデータページの異なるバージョンを生成すること、
    受信されるアクセス要求にサービスを提供するために、前記個々のデータページの前記異なるバージョンで前記個々のデータページを置き換えること
    を実行させるプログラム命令が記憶された非一時的なコンピュータ可読記憶媒体。

Images