JP6346937B2 - データベースエンジンを備えたデータベースシステム及び別個の分散型ストレージサービス - Google Patents

Description

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

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

従来のデータベースシステムでは、データベースシステムによって管理されるデータは、直接的にアタッチされたディスクに記憶される。ディスクが故障すると、ディスクは交換され、次いで適切なデータをリロードされる必要がある。例えば、多くのシステムでは、クラッシュ回復は、バックアップシステムからの最も最近のスナップショットを復元し、次いで前回のスナップショット以降、その点から先に行われるあらゆる変更をリプレイすることを含む。ただし、この手法は大型データベースまで十分にスケーリングしない。

実施形態は、いくつかの実施形態及び例示的な図面について一例として本明細書に説明されているが、当業者は実施形態が説明されている実施形態または図面に制限されないことを認識する。図面及び図面に対する詳細な説明は、開示されている特定の形式に実施形態を制限することを目的とするのではなく、逆に、添付の特許請求の範囲によって定められる精神及び範囲に入るすべての修正形態、同等物、及び変更形態を対象とすることを目的とすることが理解されるべきである。本明細書に使用される見出しは編成のためだけであり、明細書または特許請求項の範囲を制限するために使用されることを意図していない。本願を通して使用されるように、単語「してよい」は、強制の意味（つまり、しなければならないを意味する）よりむしろ、許可の意味（つまり、する可能性を有することを意味する）で使用される。同様に、単語「含む」、「含んだ」、及び「含む」は、含むが、これに限定されるものではないことを意味する。

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

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

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

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

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

上述されたように、典型的な大型データベースシステムでは、データベースシステムがシステムの故障に続いて再起動できる前に、データセット全体が復元される必要がある。これらのデータベースシステムでは、クラッシュに続いて、システムは、データページのすべてがディスク（例えば、チェックポイント）にフラッシュされたことがわかった最後の点を決定しなければならず、その点から先へのあらゆる変更ログをリプレイしなければならない。例えば、クライアントプロセスからの入信クエリーを処理するためにデータベースを使用できるようになる前に、システムプロセスは、決定されたチェックポイントの後に変更されたデータページのすべてを読み込み、それらのデータページにすでに適用されていない適用可能な変更ログレコードのそれぞれを適用しなければならない。

いくつかの実施形態では、本明細書に説明されるデータベースシステムは、回復されるデータセット全体を待機する必要なく、データベースクラッシュ後にほぼ即時に（例えば、クエリーを受け入れ、サービスを提供するためにデータベースを利用できるようにするために）故障に続いてデータベースエンジンを再起動できてよい。代わりに、クエリーは、クラッシュ回復が１つまたは複数のバックグラウンドスレッドによってゆったりと実行される間に、受信され、サービスを受けることができる。例えば、クラッシュに続いて、複数のバックグラウンドスレッドが異なるストレージノード上で並列で動作して、対応するリドゥログからデータページを再構築してよい。その一方で、入信クエリーがまだ再構築されていないデータページをターゲットとしている場合、ストレージ層は適切なリドゥログからオンザフライでそのデータページを作成し直すように構成されてよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本明細書に説明されるデータベースエンジン及び分散型データベースストレージサービス等の、データベースエンジン及び別個の分散型データベースストレージサービスを含むデータベースシステムでデータにアクセスするための方法の一実施形態が、図５の流れ図によって示される。５１０で示されるように、この例では、方法は、データベースエンジンヘッドノードが、データベーステーブルのデータレコードに向けられた書込み要求を（例えば、データベースクライアントから）受信することを含んでよい。例えば、書込み要求は、新しいデータレコードがデータベーステーブルに（またはデータベーステーブルの特定のデータページに）追加される必要があることを指定してよい、またはデータベーステーブルの特定のデータページの既存のデータレコードに対する修正を指定してよい。方法は、データベースエンジンヘッドノードが、５２０でのように、要求された書込みを指定するリドゥログレコードを生成し、５３０でのように、特定のデータページを記憶する分散型データベース最適化ストレージシステムのノードにリドゥログレコードを送信する（が、要求が向けられる特定のデータページを送信しない）ことを含んでよい。

この例に示されるように、方法は、リドゥログレコードを受け取ることに応えて、５４０でのように、ストレージシステムノードがディスクに（または別のタイプの永続記憶媒体に）リドゥログレコードを書き込み、データベースエンジンヘッドノードに書込み肯定応答を返すことを含んでよい。いくつかの実施形態では、書込み肯定応答を受信することに応えて、データベースエンジンヘッドノードは、そこから書込み要求が受信されたクライアント（不図示）に対応する書込み肯定応答を返してよい。この例で示されるように、時間のある点で（例えば、リドゥログレコードを受信し、書込み肯定応答を返すことの後の時点で）、方法は、ストレージシステムノードが、ステップ５５０でのように、（例えば、ステップ５４０でディスクに書き込まれたリドゥログレコードを含んだ）特定のデータページのための複数のリドゥログレコードを合体させて、その現在の状態で特定のデータページのインスタンス化を生成することを含んでよい。例えば、リドゥログを合体させることは、特定のデータページのためにストレージシステムによって受信されたが、特定のデータページの最新のバージョンを提供するために特定のデータページのインスタンスにまだ適用されていないリドゥログのすべてを、特定のデータページの以前にインスタンス化されたバージョンに適用することを含んでよい。いくつかの実施形態では、特定のデータページの最新のバージョンが、１つまたは複数のリドゥログから、例えば該リドゥログを特定のデータページの以前に記憶されたバージョンに適用することなく、直接的に生成されてよいことに留意されたい。

図５に示されるように、方法は、（例えば、特定のデータページの最新のバージョンを作成するためにリドゥログを合体させることの後のなんらかの点で）データベースエンジンヘッドノードが、５６０でのように、特定のデータページに向けられた読取り要求を受信することも含んでよい。それに応じて、データベースエンジンヘッドノードは、５７０でのように、特定のデータページを記憶するストレージノードに対応する読取り要求を送信してよい。この例では、データベースエンジンヘッドノードがそのキャッシュに特定のデータページのカレントバージョンを記憶しないことが仮定されることに留意されたい。それ以外の場合、方法は、データベースエンジンヘッドノードが、対応する読取り要求をストレージシステムノードに送信することよりむしろ（例えば、そのキャッシュから要求されたデータを返すことによって）読取り要求自体に応答することを含んでよい。この例で示されるように、方法は、ストレージシステムノードが、５８０でのように、データベースエンジンヘッドノードに特定のデータページをその現在の状態で返すことを含んでよく、ステップ５８０の後、データベースエンジンヘッドノードは、５９０でのように、そこから読取り要求が受信されたクライアントに要求されたデータを返してよい。

多様な実施形態では、（例えば、ステップ５８０でのように）データベースエンジンヘッドノードに返される特定のデータページのバージョンは、ステップ５５０で合体動作によって生成されたのと同じバージョンであってよい、または後の合体動作（例えば、ステップ５５０での合体動作の後であった追加のリドゥログレコードを適用した動作）によって作成されたより最近のバージョンであってよい。例えば、異なる実施形態では、追加の合体動作は、データベースクラッシュ回復動作の一部として、または別のタイプのトリガに応えて、データベースエンジンヘッドノードからの読取り要求の受信に応えて、ストレージシステムノードで実行された可能性がある。いくつかの実施形態では、データベースエンジン及び別個の分散型データベースストレージサービスを含むデータベースシステムでデータにアクセスするための図５に示される動作は、データにアクセスする要求を受信することに応えて自動的に（例えば、ユーザー介入なしに）データベースシステムで実行されてよいことに留意されたい。

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

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

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

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

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

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

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

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

データベースエンジンの視点から、データベースシステムで書込み動作を実行するための方法の一実施形態が、図７の流れ図に示されている。７１０に示されるように、この例では、方法は、データベースエンジンヘッドノードがデータベーステーブルのデータレコードに向けられた書込み要求を（例えば、データベースクライアントから）受信することを含んでよい。例えば、書込み要求は、新しいデータレコードがデータベーステーブルに（またはデータベーステーブルの特定のデータページに）追加される必要があることを指定してよい、またはデータベーステーブルの特定のデータページの既存のデータレコードに対する修正を指定してよい。また、方法は、データベースエンジンヘッドノード（またはデータベースエンジンヘッドノードの特定の構成要素）が、７２０でのように、書込み要求をパースする及び／または最適化することを含んでもよい。例えば、いくつかの実施形態では、データベースエンジンヘッドノードは、クエリー実行計画を生成することに責任を負ってよい。図７に示されるように、方法は、データベースエンジンヘッドノードが、７３０でのように、要求された書込みを指定するリドゥログレコードを生成すること、及びデータベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、７４０でのように、書込み要求が向けられる特定のデータページを記憶する分散型データベース最適化ストレージシステムのノードを決定することを含んでよい。

この例に示されるように、方法は、データエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、７５０でのように、ストレージシステムの決定されたノードに、リドゥログレコードを送信するが、特定のデータページの任意のバージョンを送信しないことを含んでよい。図７に示されるように、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、ストレージシステムからの書込みの肯定応答を受信するまで（及び受信しない限り）書込み要求に関してデータベースエンジンヘッドノードによって取られる他のアクションがないことがある。いったんこの肯定応答が受信されると（７６０からの肯定の終了として示される）、方法は、データベースエンジンヘッドノードが、７７０でのように、要求者に（例えば、そこから書込み要求が受信されたクライアントに）対応する書込み肯定応答を返すことを含んでよい。いくつかの実施形態では、書込み肯定応答が所定の期間内にストレージシステムから受信されない場合、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）は、決定されたストレージノードが故障した（もしくは劣化している）、またはなんらかの他のエラー状態がストレージシステムに存在すると決定するように構成されてよいことに留意されたい。また、書込み動作を実行するための図７に示される動作が、書込み要求を受信することに応えて自動的に（例えば、ユーザー介入なしに）データベースシステムで実行されてよいことにも留意されたい。

分散型データベース最適化ストレージシステムの視点から、データベースシステムで書込み動作を実行するための方法の一実施形態が、図８の流れ図によって示される。８１０に示されるように、この例では、方法は、分散型データベース最適化ストレージシステムのノードが、ノードが記憶する特定のデータページ（であるが、特定のデータページ自体の任意のバージョンではない）に向けられるリドゥログレコードを、データベースエンジンから（例えば、データベースヘッドノードのクライアント側ストレージサービスドライバから）またはストレージシステムの別のクライアントから受信することを含んでよい。リドゥログレコードを受信することに応えて、方法は、ストレージシステムノードが、８２０でのように、ページのリドゥログレコードを１つまたは複数のディスクに（または別のタイプの永続記憶媒体に）書き込むことを含んでよい。例えば、異なる実施形態では、ストレージシステムノードは、特定のディスクに記憶される特定のデータページのリドゥログに、または同じ可用性ゾーンのもしくは２つ以上の異なる可用性ゾーンのそれぞれの１つまたは複数のディスクに記憶される係るリドゥログのいくつかのレプリカの内のいずれかにリドゥログレコードをアペンドしてよい。いったんリドゥログレコードの１つまたは複数のコピーが（システム全体の耐久性方針、アプリケーションに固有の耐久性方針、またはクライアントにより指定された耐久性方針に従って）無事に書き込まれると、方法は、ストレージシステムノードが、８３０でのように、データベースエンジンに（またはストレージシステムの他のクライアントに）書込み肯定応答を返すことを含んでもよい。リドゥログレコードが、それがストレージシステムノード上で向けられる特定のデータページの以前にインスタンス化されたバージョンに適用されているのか、それともまだ適用されていないのかに関係なく、リドゥログレコードを無事に書き込んだ後の任意の時点で、ストレージシステムノードがデータベースエンジンに書込み肯定応答を返してよいことに留意されたい。

この例に示されるように、ストレージシステムノードが、特定のデータページの最新のバージョンを作成するために特定のデータページの１つまたは複数のリドゥログレコードを合体させるべきときである場合（８４０からの肯定の終了として示される）、方法は、ストレージシステムノードが、（８５０でのように）特定のデータページの新しいバージョンをその現在の状態で生成するために特定のデータページの最も最近に記憶されたバージョンに１つまたは複数のリドゥログレコードを適用し、特定のデータページのその新しいバージョンを１つまたは複数のディスクに書き込むことを含んでよい。例えば、合体動作は、特定のデータページの最も最近にインスタンス化されたバージョンに対する、前回の合体動作以降に受信された（及び／または特定のデータページのいずれのバージョンにもまだ適用されていない）すべてのリドゥログレコードの適用を含んでよい。他の実施形態では、特定のデータページのカレントバージョンは、例えば特定のデータページの以前に記憶されたバージョンにそれらを適用することなく、１つまたは複数のリドゥログから直接的に生成されてよい。本明細書に説明されるように、異なる実施形態では、所与のデータページの未決のリドゥログレコードをいつ合体させるべきかを決定するさまざまな方法があってよい。例えば、合体動作は、データページをターゲットとする単一のリドゥログを受信することに応えて、データページをターゲットとする所定数のリドゥログレコードまたは所与の期間内にデータページをターゲットとする所定数のリドゥログレコードを受信したことに応えて、データページをターゲットとする読取り要求を受信することに応えて、クラッシュ回復動作の開始に応えて、または任意の他の適切な方針に従って定期的な（例えば周期的な）時間間隔でデータページに対してトリガされてよい。

図８に示されるように、ストレージシステムノードが特定のデータページのリドゥログレコードを合体させるべきではないが（８４０からの否定の終了として示される）、特定のデータページをターゲットとする別のリドゥログレコードが受信される場合（８６０からの肯定の終了として示される）、方法は、追加のリドゥログレコードのために８２０から８６０に示される動作を繰り返すことを含んでよい。この例では、特定のデータページをターゲットとするより多くのリドゥログレコードがストレージシステムによって受信されるにつれ、ストレージシステムノードは追加のリドゥログレコードごとに８２０から８６０に示される動作を繰り返してよく、ストレージシステムノードは１つまたは複数の適用可能なトリガ及び／または方針に従ってときどき特定のデータページのためにリドゥログレコードを合体させてよい。これは、８６０から８２０への肯定の終了のフィードバック、及び８６０から８４０への否定の終了からのフィードバックによって図８に示される。書込み動作を実行するための図８に示される動作が、リドゥログレコードを受信することに応えて自動的に（例えば、ユーザー介入なしに）ストレージシステムで実行されてよいことに留意されたい。

いくつかの実施形態では、いくつかのデータページ（例えば、仮にあるとしても、めったにアクセスされないデータページ）は（例えば、合体動作によって）絶対に生成されることがない場合がある、及び／またはメモリで持続されることがない場合があることに留意されたい。例えば、いくつかの実施形態では、係るデータページに向けられるあらゆるリドゥログレコードは、１つまたは複数のストレージシステムノードによって記憶されてよい（例えば、メモリで持続されてよい）が、これらのリドゥログレコードは、それらを読み取る要求が受信されるまで、または受信されない限り、それらのデータページの完全なバージョンを生成するために使用されないことがある。係る実施形態では、たとえ（例えば、読取り要求に応えて）係るデータページのバージョンが生成されても、（例えばそれがすぐに再びアクセスされる、頻繁にアクセスされる、または絶対にアクセスされる可能性が低い場合）それはメモリで持続されないが、代わりにそれが要求者に返された後の任意の時点で廃棄されてよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

データベースシステムで読取り動作を実行するための方法の一実施形態は、データベースエンジンの視点から、図１１の流れ図によって示される。１１１０で示されるように、この例では、方法は、データベースエンジンヘッドノードが（例えば、データベースクライアントから）特定のデータページに向けられる読取り要求を受信することを含んでよい。また、方法は、データベースエンジンヘッドノード（またはデータベースエンジンヘッドノードの特定の構成要素）が、１１２０でのように、読取り要求をパースする、及び／または最適化することを含んでもよい。例えば、いくつかの実施形態では、データベースエンジンヘッドノードは、クエリー実行計画を生成することに責任を負ってよい。図１１に示されるように、特定のデータページが、１１３０からの肯定の終了として示される、データベースエンジンヘッドノードのキャッシュに常駐する場合、方法は、データベースエンジンヘッドノードが、１１３５でのように、そのキャッシュで検出される特定のデータページのバージョンから要求されたデータを返すことを含んでよい。例えば、いくつかの実施形態では、データベースエンジンヘッドノードはそのキャッシュの中に最も最近アクセスされたデータページのコピーを一時的に保持してよく、（例えば、それらの書込み要求のためのリドゥログレコードを生成し、分散型データベース最適化ストレージシステムに渡すことに加えて）それらに向けられる書込み要求を受信することに応えてそれらのコピーを更新してよい。いくつかの係る実施形態では、読取り動作がターゲットとする特定のデータページがキャッシュに常駐する場合、特定のデータページは特定のデータページの最新のバージョンであると見なされてよい（例えば、データページをターゲットとするすべてのリドゥログレコードが、キャッシュに記憶される特定のデータページのバージョンにすでに適用されていると仮定されてよい）。

図１１に示されるように、特定のデータページが、１１３０からの否定の終了として示される、データベースエンジンヘッドノードのキャッシュに常駐しない場合、方法は、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、１１４０でのように、特定のデータページを記憶する分散型データベース最適化ストレージシステムのノードを決定し、決定されたストレージシステムノードに対応する読取り要求を送信することを含んでよい。図１１に示されるように、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、ストレージシステムから特定のデータページを（その現在の状態で）受信するまで（及び受信しない限り）、読取り要求に関してデータベースエンジンヘッドノードによって講じられる他のアクションはないことがある。いったんデータベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、決定されたストレージシステムノードから特定のデータページをその現在の状態で受信すると（１１５０からの肯定の終了で示される）、方法は、データベースエンジンヘッドノードが、１１６０でのように、要求されたデータを要求者（例えば、そこから読取り要求が受信されたクライアント）に返すことを含んでよい。例えば、決定されたストレージシステムノードから受信された特定のデータページのバージョンが、今まで特定のデータページをターゲットとしたすべてのリドゥログレコードが適用される（またはデータベースシステムのトランザクション性及び一貫性を維持しつつ適用できたリドゥログレコードの内の少なくともすべて）の特定のデータページのバージョンである場合、データベースエンジンヘッドノードは、決定されたストレージシステムノードから受信される特定のデータページのバージョンから要求されたデータを返してよい。いくつかの実施形態では、特定のデータページのカレントコピーが所定の期間内にストレージシステムから受信されない場合、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）は、決定されたストレージノードが故障した（もしくは劣化している）、またはなんらかの他のエラー状態がストレージシステムに存在すると決定するように構成されてよいことに留意されたい。また、読取り動作を実行するための図１１に示される動作が、読取り要求を受信することに応えて自動的に（例えば、ユーザー介入なしに）データベースシステムで実行されてよいことも留意されたい。

分散型データベース最適化ストレージシステムの視点から、データベースシステムで読取り動作を実行するための方法の一実施形態が、図１２の流れ図によって示される。１２１０で示されるように、この例では、方法は、分散型データベース最適化ストレージシステム内のノードが、ストレージシステムノードによって記憶される特定のデータページに向けられる読取り要求を受信することを含んでよい。異なる実施形態では、ストレージシステムは、データベースエンジンから（例えば、データベースヘッドノードのクライアント側ストレージサービスドライバから）、または別のストレージサービスクライアントから読取り要求を受信してよい。この例に示されるように、ストレージシステムノードがデータページの最新のコピーを記憶する場合（１２２０からの肯定の終了として示される）、方法は、ストレージシステムノードが、１２５０でのように、それがすでに記憶しているデータページの最新のコピーを返すことを含んでよい。例えば、今までストレージシステムノードによって受信された特定のブロックをターゲットとするリドゥログレコードのすべて（またはデータベースシステムのトランザクション性及び一貫性のプロパティを維持しつつ適用できたリドゥログレコードの少なくともすべて）が特定のデータページに適用された場合（例えば、それらが特定のデータページのカレントバージョンを作成するために合体した場合）、ストレージシステムノードは、応答を返す前に特定のデータページのリドゥログレコードに対して追加の合体動作を実行する必要がないことがある。

他方、ストレージシステムノードがデータページの最新のコピーを記憶しない場合（１２２０からの否定の終了として示される）、方法は、ストレージシステムノードが、１２３０でのように、ディスクからまたは別の永続ストレージデバイスから最も最近に記憶されたコピーを取り出し、次いで１２４０でのように、特定のデータページの取り出されたコピーに特定のデータページの１つまたは複数のリドゥログレコードで指定された変更を適用して、特定のデータページの最新のコピーを生成することを含んでよい。例えば、ストレージシステムノードは、特定のデータページの取り出されたコピーに、今までストレージシステムノードによって受信されたが、特定のデータページにまだ適用されていない特定のデータページをターゲットとするありとあらゆるリドゥログレコードを適用してよい。いったんストレージシステムノードが特定のデータページの最新のコピーを作成すると、ストレージシステムノードは、（１２５０でのように）データページの最新のコピーとして、データベースエンジン（または他のストレージシステムクライアント）に特定のデータページの新規に作成されたコピーを返してよい。読取り動作を実行するための図１２に示される動作が、読取り要求を受信することに応えて自動的に（例えば、ユーザー介入なしに）ストレージシステムで実行されてよいことに留意されたい。

上述されたように、保護グループ（ＰＧ）は、セグメントの集合体によって形成される耐久性の単位を表す抽象分散エンティティである。いくつかの実施形態では、保護グループは、ボリュームの中の１つまたは複数のエクステントを表してよい。保護グループは、１つまたは複数のエクステントのためのインタフェースを曝露してよく、１つまたは複数のセグメント及び関連付けられたメタデータをカプセル化し（隠して）よい。保護グループは、保護グループ向けに構成される耐久性方針に従って、保護グループが暴露するエクステントの耐久性を維持することに責任を負ってよい。いくつかの実施形態では、保護グループは永続エクステントデータに冗長なセグメントを使用することによって、及び係る冗長性を積極的に維持することによって、その構成するエクステントすべての耐久性を達成してよい。保護グループが基礎的なセグメントの上にエクステント読取り動作／書込み動作をマッピングする方法は、エクステントのユーザーにとって不透明であってよい。異なる冗長性戦略が、エクステントミラーリング、エクステントイレージャコーディング、及び／またはレイジーレプリケーション（ｌａｚｙ ｒｅｐｌｉｃａｔｉｏｎ）を含むが、これに限定されるものではない異なる実施形態で利用されてよい。

「ミラーリングされた保護グループ」とは、構成するセグメントのそれぞれが単一のエクステントの同期ミラーリングコピーである保護グループである。このモデルでは、変更が保護グループの中の影響を受けるすべての同期ミラーリングセグメントで耐久的にされると、変更は耐久的と見なされる。保護グループは、単一の可用性ゾーンの中で、または複数の可用性ゾーンに渡って形成されてよい。例えば、ある特定の可用性ゾーンの中のセグメントだけをカプセル化する保護グループの場合、保護グループの可用性は関連付けられた可用性ゾーンの可用性に直接的に結び付けられてよい。いくつかの実施形態では、領域保護グループは複数の可用性ゾーンに渡ってセグメントをカプセル化してよい。いくつかの係る実施形態では、領域保護グループは、各ＡＺから１つ、対応するＡＺ保護グループの集合体として実装されてよい。

保護グループを含む分散型データベース最適化ストレージシステムで読取り動作及び書込み動作を実行するための方法の一実施形態が、図１３の流れ図によって示される。１３１０で示されるように、この例では、方法は、データベース階層のデータベースエンジンヘッドノードが（例えば、データベースクライアントから）データベーステーブルのデータレコードに向けられた書込み要求を受信することを含んでよい。例えば、書込み要求は、新しいデータレコードがデータベーステーブルに（またはデータベーステーブルの特定のデータページに）追加されるべきであることを指定してよい、またはデータベーステーブルの特定のデータページの既存のデータレコードに対する修正を指定してよい。書込み要求を受信することに応えて、方法は、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、１３２０でのように、要求が向けられる特定のデータページを記憶する分散型データベース最適化ストレージシステムの保護グループの２つ以上のストレージノードに、リドゥログレコードを送信する（が、書込み要求が向けられる特定のデータページのコピーを送信しない）ことを含んでよい。

この例に示されるように、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、保護グループのストレージノードの選抜グループから書き込みが無事に完了した旨の肯定応答を受信するまで、データベースエンジンヘッドノードは、保護グループのストレージノードの選抜グループから書込み肯定応答を受信するのを待機してよい。これは、１３３０からの否定の終了から１３３０への入力へのフィードバックによって図１３に示される。いったんデータベースエンジンヘッドノードが保護グループのストレージノードの選抜グループから書込み肯定応答を受信すると（１３３０からの肯定の終了として示される）、方法は、１３４０でのように、データベースエンジンヘッドノードが要求者に（例えば、データベースクライアントに）対応する書込み肯定応答を返すことを含んでよい。いくつかの実施形態では、書込み肯定応答が所定の期間内に保護グループのストレージノードの選抜グループから受信されない場合、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）は、保護グループのストレージノードの内の１つまたは複数が故障した（もしくは、劣化している）またはなんらかの他のエラー状態がストレージシステムに存在すると決定するように構成されてよいことに留意されたい。

図１３に示されるように、方法は、（例えば、書込み要求を受信し、書込み要求に応答することの後のなんらかの時点で）、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が（１３５０でのように）特定のデータページに向けられる読取り要求を受信することを含んでよい。読取り要求を受信することに応えて、方法は、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、（１３６０でのように）特定のデータページを記憶する保護グループの２つ以上のストレージノードに読取り要求を送信することを含んでよい。

この例に示されるように、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）が、保護グループのストレージノードの選抜グループから特定のデータページのカレントコピーを受信するまで、データベースエンジンヘッドノードは保護グループのストレージノードの選抜グループから特定のデータページのカレントコピーを受信するのを待機してよい。例えば、いくつかの実施形態では、保護グループのストレージノードの内の１つまたは複数は特定のデータページのカレントコピーを記憶しないことがあり、応答の前に（例えば、合体動作で）特定のデータページの初期バージョンに１つまたは複数の未決のリドゥログレコードを適用することによって特定のデータページのカレントコピーを作成しなければならないことがある。これは、１３７０からの否定の終了から１３７０への入力へのフィードバックによって図１３に示される。いったんデータベースエンジンヘッドノードが、保護グループのストレージノードの選抜グループから特定のデータページのカレントコピーを受信すると（１３７０からの肯定の終了として示される）、方法は、データベースエンジンヘッドノードが、１３８０でのように、要求者に（例えば、データベースクライアントに）データページのカレントコピーを返すことを含んでよい。いくつかの実施形態では、特定のデータページのカレントコピーが所定の期間内に保護グループのストレージノードの選抜グループから受信されない場合、データベースエンジンヘッドノード（またはより詳細にはデータベースエンジンヘッドノード上のクライアント側ストレージサービスドライバ）は、保護グループのストレージノードの１つまたは複数が故障した（もしくは劣化している）こと、またはなんらかの他のエラー状態がストレージシステムに存在することを決定するように構成されてよいことに留意する。また、書込み動作を実行するための、または読取り動作を実行するための図１３に示される動作は、そのようにする要求を受信することに応えて自動的に（例えば、ユーザー介入なしに）データベースシステムで実行されてよいことにも留意されたい。

いくつかの既存のデータベースシステムは、すべてのデータページをディスクに周期的にフラッシュする（例えば、５分ごとに１回ページのすべてをチェックポイントする）。係るシステムでは、クラッシュがある場合、システムは、前回データページがフラッシュされた以降多くの変更が向けられたデータページのカレントバージョンを作成し直すために多数のリドゥログレコードをリプレイしなければならない可能性がある。例えば、これは、入信命令が電子商取引アプリケーションで受信されるたびにシーケンス番号が増分されるページ等、多数の変更が継続的に向けられるキャッシュ内のホットデータページに当てはまることがある。システムに記憶されているすべてのデータページを一度にチェックポイントとする代わりに、本明細書に説明されるシステムでは、チェックポイントは、データベースまたはセグメント単位でよりむしろ、データブロック（例えば、データページ）単位で実行されてよい。例えば、いくつかの実施形態では、チェックポイントは各ストレージノードで実行されてよく、特定のストレージノードに記憶されるデータページのそれぞれが、それが保証されるとき（例えば、リドゥログレコードの数それ自体のリドゥログが所定数に達するとき）だけに、ストレージノードでデータページの新しいバージョン（例えば、そのデータページのチェックポイント）を作成するために合体してよい。係る実施形態では、データベース階層はチェックポイントにまったく関与していなくてもよい。代わりに、チェックポイントは、ストレージノード自体の責任である分散プロセス（例えば、バックグラウンドプロセス）であってよい。チェックポイントは（各ストレージノードに影響を及ぼす他のフォアグラウンド活動及び／またはバックグラウンド活動に対する可視性を有してよい）記憶階層上のバックグラウンドプロセスによって実行されてよいため、いくつかの実施形態では、記憶階層（または記憶階層のストレージシステムサーバノードの１つ）は、それが別のフォアグラウンドプロセスまたはバックグラウンドプロセスによって非常にロードされている場合、特定のストレージノードのためのチェックポイント動作を延期するように構成されてよい。いくつかの実施形態では、チェックポイント動作を延期することは、チェックポイントがフォアグラウンドレーテンシに悪影響を及ぼすのを妨げてよい。

いくつかの実施形態では、（例えば、本明細書に説明されるデータ構造等の）多様なメモリ内データ構造が、セグメントが機能するために必要とされてよい。いくつかの実施形態では、これらのメモリ内構造は、すべてのログページのフルスキャンを行うことによって（例えば、クラッシュに続く）起動中に構築されてよい。いくつかの実施形態では、これらのメモリ内データ構造のいくつかの周期的なチェックポイントは、クラッシュに続く起動時間を短縮するために実行されてよい。

いくつかの既存のデータベースシステムでは、データベース階層は、変更が受信されているのと同じ頻度で、ストレージ層にデータページを書き出す必要があってよく、それ以外の場合、キャッシュが、ストレージ層にまだ書き出されていない汚れたページを十分に得る場合、より多くの変更を受け入れるためにページはフラッシュされなければならないことがあり、このことがシステムにレーテンシをもたらす。対照的に、本明細書に説明されるシステムでは、データベースエンジンヘッドノードのキャッシュ内のデータページのリドゥログが分散型ストレージシステムに渡され（書込み肯定応答が受信され）る限り、データベース階層はそのキャッシュから、（ストレージ層によっていつでも再構築できる）データページを立ち退かせてよい。

本明細書に説明されるシステムのいくつかの実施形態では、クラッシュ回復動作、フラッシュバック動作、及びポイントインタイムリストア動作は、リドゥログまたはアンドゥログのどちらかのリプレイを必要としないことがある。代わりに、該動作は、インスタンスの構築、カレントボリュームＬＳＮの適切なコミットポイントへのリセット、及びデータベースサービスの再起動を含んでよい。

本明細書に説明されるデータベースシステムは、いくつかの実施形態では、以前のデータベーススケーリング手法に関連付けられる不利な点（例えば、複雑度及び／またはコストに関して不利な点）のいくつかを被ることなく、いくつかの既存のデータベースよりも大きなデータベーステーブル及び／またはより高いスループットに対処するためにスケーリングされてよい。例えば、いくつかの実施形態では、ボリュームサイズに対して実際の制限はないことがあり、ボリュームは（例えば、セグメントの追加の保護グループを加えることによって）可用性の損失または性能の変化なしに動的に成長できてよい。さらに、書込みトラフィックがセグメント全体で拡散されることを仮定すると、ＩＯＰＳは実質的に際限なしにされてよい。例えば、いくつかの実施形態では、ＩＯＰＳは、新しい書き込みが記憶階層に転送される間に、必要な再ストライピングがバックグラウンドで実行されている状態で、現在実行中のデータベースの性能に影響を与えることなく増加または減少してよい。係る実施形態では、クエリー性能は、バックアップ動作または再ミラーリングの間にＩＯトラフィックをフリーズする必要なく、予測可能且つ一貫性があるようにされてよい。代わりに、記憶階層は、ストライピング、ミラーリング、及び熱管理を管理し、これらの責任をデータベース階層または管理者から取り除いてよい。

本明細書に説明されるように、記憶階層でのすべての書込みは、データベース階層へ肯定応答される前に永続媒体で耐久的にされてよい。これは大規模な電力事象での論理的な破損を妨げてよく、係る場合にバックアップから復旧する必要性を取り除いてよい。いくつかの実施形態では、バックアップからの復旧が必要とされる唯一のときは、カスタマエラー（例えば、テーブルの偶然の削除、または同等）に応えてであってよい。

いくつかの実施形態では、複製動作は、データブロックではなくログレコードの移動を伴うので、複製の性能の影響は他のデータベースシステムにおいてよりはるかに低くてよい。さらに、可用性ゾーン全体での書込みの調整は記憶階層で実行されてよく、同期複製のための確保されたデータベーススタンバイノードの使用を必要としなくてよく、このことが既存のデータベースシステムと比較してコストを削減してよい。

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

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

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

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

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

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

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

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

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

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

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

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

以下の実施形態は以下の節を鑑みてさらによう理解されてよい。
１．それぞれが少なくとも１台のプロセッサ及びメモリを備える複数のコンピューティングノード
を含み、
複数のコンピューティングノードの１つまたは複数がデータベースサービスを実装するように構成され、データベースサービスがデータベースエンジンヘッドノードを含み、
複数のコンピューティングノードの２つ以上の他のコンピューティングノードが、１台または複数のストレージデバイスにそれぞれのデータページとしてデータベーステーブルの部分を記憶する分散型ストレージサービスのサーバノードを実装するように構成され、
データベースエンジンヘッドノードが、
データベースサービスのクライアントから、データベーステーブルの所与のデータレコードに向けられる書込み要求であって、所与のデータレコードに加えられる修正を指定する書込み要求を受信する、
所与のデータレコードに加えられる修正を表すリドゥログレコードを生成する、
所与のデータレコードを含むデータページのバージョンを記憶する分散型ストレージサービスの特定のサーバノードに、所与のデータレコードを含むデータページを送信しないが、リドゥログレコードを送信する
ように構成され、
分散型ストレージサービスの特定のサーバノードが、
データベースエンジンヘッドノードからリドゥログレコードを受信する、
１台または複数のストレージデバイスにリドゥログレコードを書き込む、
データベースエンジンヘッドノードに、リドゥログレコードが書き込まれた旨の肯定応答を返す、及び
肯定応答を返すことの後に、
データページのカレントバージョンを生成するために、分散型ストレージサービスの特定のサーバノードが、データページの以前に記憶されたバージョンに、受信されたリドゥログレコード及びデータページへの修正を表す１つまたは複数の他のリドゥログレコードを適用するように構成される、所与のデータレコードを含むデータページのカレントバージョンを生成する、及び
１台または複数のストレージデバイスにデータページのカレントバージョンを書き込む
ように構成される、
コンピューティングシステム。
２．データベースエンジンヘッドノードが、
データベースクライアントから、所与のデータレコードを含んだデータページを読み取る要求を受信する、
データページを読み取る要求を受信することに応えて、分散型ストレージサービスの特定のサーバノードにデータページのカレントバージョンに対する要求を送信する
ようにさらに構成される、節１に記載のコンピューティングシステム。
３．分散型ストレージサービスの特定のサーバノードが、
データベースエンジンヘッドノードから、所与のデータレコードを含んだデータページのカレントバージョンに対する要求を受信する、及び
データページのカレントバージョンに対する要求を受信することに応えて、データベースエンジンヘッドノードにデータページのカレントバージョンを返す
ようにさらに構成される、節２に記載のコンピューティングシステム。
４．データページのカレントバージョンを生成することが、データページのカレントバージョンに対する要求を受信することに応えて実行される、節３に記載のコンピューティングシステム。
５．データベースエンジンヘッドノードが、分散型ストレージシステムのためのクライアント側ドライバを含み、
分散型ストレージシステムの特定のサーバノードにリドゥログレコードを送信するために、クライアント側ドライバが、
所与のデータレコードを含んだデータページのバージョンを記憶する分散型ストレージサービスの特定のサーバノードを決定する、及び
データベースサービスの代わりに分散型ストレージシステムの特定のサーバノードにリドゥログレコードを送信する
ように構成される、節１に記載のコンピューティングシステム。
６．それぞれが少なくとも１台のプロセッサ及びメモリを備える１つまたは複数のコンピューティングノードであって、１つまたは複数のコンピューティングノードがデータベースサービスを集合的に実装するように構成され、データベースサービスがデータベースエンジンヘッドノード及び分散型ストレージシステムへのインタフェースを含む、１つまたは複数のコンピューティングノード
を含み、
データベースエンジンヘッドノードが、
データベースサービスのクライアントから、データベーステーブルの所与のデータレコードに向けられる書込み要求であって、所与のデータレコードに加えられる修正を指定する書込み要求を受信する、
所与のデータレコードに加えられる修正を表すリドゥログレコードを生成する、
インタフェースを介して、所与のデータレコードを含んだデータページのバージョンを記憶する分散型ストレージサービスの特定のサーバノードに、所与のデータレコードを含んだデータページを送信しないが、リドゥログレコードを送信する、
インタフェースを介して、リドゥログレコードが分散型ストレージサービスに書き込まれた旨の肯定応答を受信する、及び
データベースクライアントに、要求された書込みが実行されたことを示す応答を返す
ように構成される、システム。
７．データベースエンジンヘッドノードが、
データベースサービスのクライアントから、所与のデータレコードを含んだデータページを読み取る要求を受信する、及び
データページを読み取る要求を受信することに応えて、
インタフェースを介して、分散型ストレージサービスの特定のサーバノードにデータページのカレントバージョンに対する要求を送信する、
インタフェースを介して、データページのカレントバージョンを受信する、及び
そこからデータページを読み取る要求が受信されたクライアントに、データページのカレントバージョンを返す
ようにさらに構成される、節６に記載のシステム。
８．データベースエンジンヘッドノードが、最近アクセスされたデータページを記憶するキャッシュを含み、
データベースエンジンヘッドノードが、データページのカレントバージョンがキャッシュに存在しないと決定することに応えて、特定のサーバノードにデータページのカレントバージョンに対する要求を送信するように構成される、
節７に記載のシステム。
９．データベースエンジンヘッドノードが、最近アクセスされたデータページを記憶するキャッシュを含み、
キャッシュが所与のデータレコードを含んだデータページのコピーを記憶し、
データベースエンジンヘッドノードが、データページのキャッシュに入れられたコピーの所与のデータレコードに、書込み要求で指定される修正を適用するようにさらに構成される、
節６に記載のシステム。
１０．データベースエンジンヘッドノードが、
リドゥログレコードを送信する前に、特定のサーバノードを決定することが分散型ストレージシステムへのインタフェースによって実行される、所与のデータレコードを含んだデータページのバージョンを記憶する分散型ストレージサービスの特定のサーバノードを決定する
ようにさらに構成される、節６に記載のシステム。
１１．データベースエンジンヘッドノードが、
データベースサービスの１つまたは複数のクライアントから、データベーステーブルに向けられる２つ以上の追加の書込み要求を受信する、及び
２つ以上の追加の書込み要求を提供することが、データベーステーブルをターゲットとするトランザクションの原子性、独立性、及び一貫性のプロパティを強化することを含む、２つ以上の追加の書込み要求を提供する
ようにさらに構成される、節６に記載のシステム。
１２．それぞれが少なくとも１台のプロセッサ及びメモリを含む１つまたは複数のコンピューティングノードであって、１つまたは複数のコンピューティングノードが、分散型ストレージサービスのクライアントの代わりに、１台または複数のストレージデバイスにデータブロックを記憶する分散型ストレージサービスを集合的に実装するように構成される、１つまたは複数のコンピューティングノード
を含み、
１つまたは複数のコンピューティングノードの所与のコンピューティングノードが、
クライアントから、所与のコンピューティングノードに記憶される特定のデータブロックの更新レコードであって、特定のデータブロックに加えられる修正を指定する更新レコードを受信する、
１台または複数のストレージデバイスの１つまたは複数に更新レコードを書き込む、
クライアントに、生成される特定のデータブロックのカレントバージョンを、または特定のデータブロックに適用される更新レコードに指定される修正を待機することなく、更新レコードが書き込まれた旨の肯定応答を返す
ように構成される、システム。
１３．肯定応答を返すことの後に、１つまたは複数のコンピューティングノードの所与のコンピューティングノードが、
更新レコードに応じて、特定のデータブロックのカレントバージョンを生成する、及び
１台または複数のストレージデバイスの１つまたは複数に特定のデータブロックのカレントバージョンを書き込む
ようにさらに構成される、節１２に記載のシステム。
１４．特定のデータブロックのカレントバージョンを生成するために、所与のコンピューティングノードが、特定のデータブロックの以前に記憶されたバージョンに更新レコードを適用するように構成される、節１３に記載のシステム。
１５．特定のデータブロックのカレントバージョンを生成するために、所与のコンピューティングノードが特定のデータブロックの以前に記憶されたバージョンに、特定のデータブロックの以前に記憶されたバージョンが書き込まれた以降に受信された特定のデータブロックに対する修正を表す１つまたは複数の他の更新レコードを適用するようにさらに構成される、節１４に記載のシステム。
１６．特定のデータブロックのカレントバージョンを生成するために、所与のコンピューティングノードが特定のデータブロックの以前に記憶されたバージョンに、更新レコード及び１つまたは複数の他の更新レコードを適用するためにバックグラウンドプロセスを実行するように構成され、一方フォアグラウンドプロセスが分散型ストレージサービスによって記憶されるデータブロックをターゲットとする読取り要求及び書込み要求を受信する、節１３に記載のシステム。
１７．１つまたは複数のコンピューティングノードの所与のコンピューティングノードが、
クライアントから、データブロックをターゲットとする読取り要求を受信するようにさらに構成され、
特定のデータブロックのカレントバージョンを生成することが、読取り要求を受信することに応えて実行される、
節１３に記載のシステム。
１８．１つまたは複数のコンピューティングノードの別のコンピューティングノードが、特定のデータブロックを記憶し、
１つまたは複数のコンピューティングノードの他のコンピューティングノードが、
クライアントから、特定のデータブロックの更新レコードを受信する、
１台または複数のストレージデバイスの別のストレージデバイスに更新レコードを書き込む、
クライアントに、更新レコードが書き込まれた旨の別の肯定応答を返す、及び
他の肯定応答を返すことの後に、
特定のデータブロックのカレントバージョンを生成するために、所与のコンピューティングノードが特定のデータブロックの以前に記憶されたバージョンに、受信された更新レコードを適用するように構成される、特定のデータブロックのカレントバージョンを生成する、及び
１台または複数のストレージデバイスの別のストレージデバイスに特定のデータブロックのカレントバージョンを書き込む
ように構成される、節１２に記載のシステム。
１９．１台または複数のコンピュータで実行されるときに、１台または複数のコンピュータに、
分散型ストレージシステムに記憶されるデータブロックをターゲットとする書込み要求であって、データブロックに加えられる修正を指定する書込み要求を含んだクエリーを受信することと、
データブロックに加えられる修正を表すリドゥログレコードを生成することと、
データブロックを記憶する分散型ストレージシステムのノードを決定することと、
分散型ストレージシステムの決定されたノードにリドゥログレコードを送信するが、データブロックのコピーを送信しないことと、
分散型ストレージシステムの決定されたノードから、リドゥログレコードが決定されたノードのストレージデバイスに書き込まれた旨の肯定応答を受信することと、
を実行させる、プログラム命令を記憶する非一過性のコンピュータ可読記憶媒体。
２０．１台または複数のコンピュータで実行されるときに、プログラム命令が、１台または複数のコンピュータに、リドゥログを上記生成する前に、
クエリーをパースすることと、
クエリー実行計画を生成することと、
をさらに実行させる、節１９に記載の非一過性のコンピュータ可読記憶媒体。
２１．１台または複数のコンピュータで実行されるときに、プログラム命令が、１台または複数のコンピュータに、
データブロックを記憶する分散型ストレージシステムの１つまたは複数の他のノードを決定することであって、１つまたは複数の他のノードが決定されたノードと同じ保護グループの一部である、決定することと、
分散型ストレージシステムの１つまたは複数の他のノードに、リドゥログレコードを送信するが、データブロックのコピーを送信しないことと、
をさらに実行させる、節１９に記載の非一過性のコンピュータ可読記憶媒体。
２２．１台または複数のコンピュータで実行されるときに、プログラム命令が、１台または複数のコンピュータに、
保護グループのノードの選抜グループから、ノードの選抜グループのノードのそれぞれのストレージデバイスにリドゥログレコードが書き込まれた旨の肯定応答を受信することと、
ノードの選抜グループから肯定応答を受信することに応えて、そこからクエリーが受信されたクライアントに、書込み要求がコミットされたことを示すクエリー応答を返すことと、
をさらに実行させる、節２１に記載の非一過性のコンピュータ可読記憶媒体。
２３．クエリーがデータベースサービスから受信される、節１９に記載の非一過性のコンピュータ可読記憶媒体。
２４．１台または複数のコンピュータで実行されるときに、１台または複数のコンピュータに、
それぞれが１台または複数のストレージデバイスを含んだ１つまたは複数のストレージシステムサーバノードに、データベーステーブルのデータレコードを含んだ複数のデータページを記憶することと、
特定のデータページに向けられるリドゥログレコードを受信することと、
ストレージデバイスの１台または複数にリドゥログレコードを記憶することと、
特定のデータページのために合体動作が保証されることを決定することと、
上記決定することに応えて、
特定のデータページのために合体動作を実行することであって、合体動作を実行することが、特定のデータページのカレントバージョンを生成するために、特定のデータページの以前に生成されたバージョンに、リドゥログレコード及び１つまたは複数の他のリドゥログレコードを適用することを含む、実行することと、
特定のデータページのカレントバージョンを、ストレージデバイスの１つまたは複数記憶することと、
を実行させる、プログラム命令を記憶する非一過性のコンピュータ可読記憶媒体。
２５．１つまたは複数のコンピュータで実行されるときに、プログラム命令が、１台または複数のコンピュータに、
特定のデータページに向けられる読取り要求を受信することと、
読取り要求を受信することに応えて、特定のデータページのカレントバージョンを返すことと、
をさらに実行させる、節２４に記載の非一過性のコンピュータ可読記憶媒体。
２６．合体動作が保証されることを上記決定することが、受信されているが、まだ特定のデータページに適用されていない特定のデータページに向けられるリドゥログレコードの数が合体動作のための所定の閾値を超えると決定することを含む、節２４に記載の非一過性のコンピュータ可読記憶媒体。
２７．合体動作が保証されることを上記決定することが、ノードまたはストレージデバイスが故障したと決定することを含む、節２４に記載の非一過性のコンピュータ可読記憶媒体。
２８．１台または複数のコンピュータで実行されるときに、プログラム命令が１台または複数のコンピュータに、
別のデータページに向けられる別のリドゥログレコードを受信することと、
ストレージデバイスの１台または複数に他のリドゥログレコードを記憶することと、
合体動作が他のデータページのために保証されていないと決定することと、
上記決定することに応えて、他のデータページのために合体動作を実行することを控えることと、
を実行させる、節２４に記載の非一過性のコンピュータ可読記憶媒体。

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

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

Claims (15)

1. それぞれが少なくとも１台のプロセッサ及びメモリを備える複数のコンピューティングノード
   を備え、
   前記複数のコンピューティングノードの１つまたは複数がデータベースサービスを実装するように構成され、前記データベースサービスがデータベースエンジンヘッドノードを備え、
   前記複数のコンピューティングノードの２つ以上の他のコンピューティングノードが、１台または複数のストレージデバイスにそれぞれのデータページとしてデータベーステーブルの部分を記憶する分散型ストレージサービスのサーバノードを実装するように構成され、
   前記データベースエンジンヘッドノードが、
   前記データベースサービスのクライアントから、データベーステーブルの所与のデータレコードに向けられる書込み要求であって、前記所与のデータレコードに加えられる修正を指定する前記書込み要求を受信する、
   前記所与のデータレコードに加えられる前記修正を表すリドゥログレコードを生成する、
   前記所与のデータレコードを備える前記データページのバージョンを記憶する前記分散型ストレージサービスの特定のサーバノードに、前記所与のデータレコードを備えるデータページを送信しないが、前記リドゥログレコードを送信する
   ように構成され、
   前記分散型ストレージサービスの前記特定のサーバノードが、
   前記データベースエンジンヘッドノードから前記リドゥログレコードを受信する、
   １台または複数のストレージデバイスに前記リドゥログレコードを書き込む、
   前記データベースエンジンヘッドノードに、前記リドゥログレコードが書き込まれた旨の肯定応答を返す、及び
   前記肯定応答を返すことの後に
   前記所与のデータレコードを備える前記データページのカレントバージョンを生成し、前記データページの前記カレントバージョンを生成するために、前記分散型ストレージサービスの前記特定のサーバノードが、前記データページの以前に記憶されたバージョンに、前記受信されたリドゥログレコード及び前記データページへの修正を表す１つまたは複数の他のリドゥログレコードを適用するように構成される、及び
   １台または複数のストレージデバイスに前記データページの前記カレントバージョンを書き込む
   ように構成され、
   前記データベースエンジンヘッドノードは、さらに、
   前記分散型ストレージサービスの前記特定のサーバノードからの前記肯定応答の受信に基づいて、前記クライアントへ、前記要求された書込みが実行されたことを示す応答を返すように構成される、
   コンピューティングシステム。
2. 前記データベースエンジンヘッドノードが、
   データベースクライアントから、前記所与のデータレコードを備える前記データページを読み取る要求を受信する、
   前記データページを読み取る前記要求を受信することに応えて、前記分散型ストレージサービスの前記特定のサーバノードに前記データページのカレントバージョンに対する要求を送信する
   ようにさらに構成される、請求項１に記載の前記コンピューティングシステム。
3. 前記データベースエンジンヘッドノードが、前記分散型ストレージサービスのためのクライアント側ドライバを備え、
   前記分散型ストレージサービスの前記特定のサーバノードに前記リドゥログレコードを送信するために、前記クライアント側ドライバが、
   前記所与のデータレコードを備える前記データページのバージョンを記憶する前記分散型ストレージサービスの前記特定のサーバノードを決定する、及び
   前記データベースサービスの代わりに前記分散型ストレージサービスの前記特定のサーバノードに前記リドゥログレコードを送信する
   ように構成される、請求項１に記載の前記コンピューティングシステム。
4. それぞれが少なくとも１台のプロセッサ及びメモリを備える１つまたは複数のコンピューティングノードであって、前記１つまたは複数のコンピューティングノードがデータベースサービスを集合的に実装するように構成され、前記データベースサービスがデータベースエンジンヘッドノード及び分散型ストレージサービスへのインタフェースを備える、１つまたは複数のコンピューティングノード
   を備え、
   前記データベースエンジンヘッドノードが、
   前記データベースサービスのクライアントから、データベーステーブルの所与のデータレコードに向けられる書込み要求であって、前記所与のデータレコードに加えられる修正を指定する前記書込み要求を受信する、
   前記所与のデータレコードに加えられる前記修正を表すリドゥログレコードを生成する、
   前記インタフェースを介して、前記所与のデータレコードを備えるデータページのバージョンを記憶する前記分散型ストレージサービスの特定のサーバノードに、前記所与のデータレコードを備える前記データページを送信しないが、前記リドゥログレコードを送信する、
   前記インタフェースを介して、前記リドゥログレコードが前記分散型ストレージサービスに書き込まれた旨の肯定応答を受信する、及び
   前記肯定応答の受信に基づいて、前記データベースサービスのクライアントに、前記要求された書込みが実行されたことを示す応答を返す
   ように構成される、システム。
5. 前記データベースエンジンヘッドノードが、
   前記データベースサービスのクライアントから、前記所与のデータレコードを備える前記データページを読み取る要求を受信する、
   前記データページを読み取る前記要求を受信することに応えて、
   前記インタフェースを介して、前記分散型ストレージサービスの前記特定のサーバノードに、前記データページのカレントバージョンに対する要求を送信する、
   前記インタフェースを介して、前記データページの前記カレントバージョンを受信する、及び
   そこから前記データページを読み取る前記要求が受信された前記クライアントに、前記データページの前記カレントバージョンを返す、
   ようにさらに構成される、請求項４に記載の前記システム。
6. 前記データベースエンジンヘッドノードが、最近アクセスされたデータページを記憶するキャッシュを備え、
   前記データベースエンジンヘッドノードが、前記データページのカレントバージョンが前記キャッシュに存在しないと決定することに応えて、前記特定のサーバノードに前記データページの前記カレントバージョンに対する前記要求を送信するように構成される、
   請求項５に記載の前記システム。
7. 前記データベースエンジンヘッドノードが、最近アクセスされたデータページを記憶するキャッシュを備え、
   前記キャッシュが、前記所与のデータレコードを備える前記データページのコピーを記憶し、
   前記データベースエンジンヘッドノードが、前記データページの前記キャッシュに入れられたコピーの前記所与のデータレコードに、前記書込み要求で指定される前記修正を適用するようにさらに構成される、請求項４に記載の前記システム。
8. 前記データベースエンジンヘッドノードが、
   前記リドゥログレコードを送信する前に、前記特定のサーバノードを決定することが前記分散型ストレージサービスへの前記インタフェースによって実行される、前記所与のデータレコードを備える前記データページのバージョンを記憶する前記分散型ストレージサービスの前記特定のサーバノードを決定する
   ようにさらに構成される、請求項４に記載の前記システム。
9. 前記データベースエンジンヘッドノードが、
   前記データベースサービスの１つまたは複数のクライアントから、前記データベーステーブルに向けられる２つ以上の追加の書込み要求を受信する、
   前記２つ以上の追加の書込み要求を提供することが、前記データベーステーブルをターゲットとするトランザクションの原子性、独立性、及び一貫性のプロパティを強化することを含む、前記２つ以上の追加の書込み要求を提供する
   ようにさらに構成される、請求項４に記載の前記システム。
10. それぞれが少なくとも１台のプロセッサ及びメモリを備える１つまたは複数のコンピューティングノードであって、前記１つまたは複数のコンピューティングノードが、分散型ストレージサービスのクライアントの代わりに１台または複数のストレージデバイスにデータブロックを記憶する前記分散型ストレージサービスを集合的に実装するように構成される、前記１つまたは複数のコンピューティングノード
    を備え、
    前記１つまたは複数のコンピューティングノードの所与のコンピューティングノードが、
    前記クライアントから、前記所与のコンピューティングノードに記憶される特定のデータブロックの更新レコードであって、前記特定のデータブロックに加えられる修正を指定する前記更新レコードを受信するが、前記修正が加えられた前記特定のデータブロックを受信しない、
    前記１台または複数のストレージデバイスの１つまたは複数に前記更新レコードを書き込む、及び
    前記クライアントに、生成される前記特定のデータブロックのカレントバージョンを、または前記特定のデータブロックに適用される前記更新レコードに指定される前記修正を待機することなく、前記更新レコードが書き込まれた旨の肯定応答を返す
    ように構成される、システム。
11. 前記肯定応答を返すことの後に、前記１つまたは複数のコンピューティングノードの前記所与のコンピューティングノードが、
    前記更新レコードに応じて、前記特定のデータブロックのカレントバージョンを生成する、及び
    前記１台または複数のストレージデバイスの１つまたは複数に前記特定のデータブロックの前記カレントバージョンを書き込む
    ようにさらに構成される、請求項１０に記載の前記システム。
12. 前記特定のデータブロックの前記カレントバージョンを生成するために、前記所与のコンピューティングノードが、前記特定のデータブロックの以前に記憶されたバージョンに前記更新レコードを適用するように構成される、請求項１１に記載の前記システム。
13. 前記特定のデータブロックの前記カレントバージョンを生成するために、前記所与のコンピューティングノードが、前記特定のデータブロックの以前に記憶されたバージョンに、前記更新レコード及び１つまたは複数の他の更新レコードを適用するためにバックグラウンドプロセスを実行するように構成され、一方フォアグラウンドプロセスが前記分散型ストレージサービスによって記憶されるデータブロックをターゲットとする読取り要求または書き込み要求を受信する、請求項１１に記載の前記システム。
14. 前記１つまたは複数のコンピューティングノードの前記所与のコンピューティングノードが、
    前記クライアントから、前記データブロックをターゲットとする読取り要求を受信するようにさらに構成され、
    前記特定のデータブロックの前記カレントバージョンを生成することが、前記読取り要求を受信することに応えて実行される、
    請求項１１に記載の前記システム。
15. 前記１つまたは複数のコンピューティングノードの別のコンピューティングノードが前記特定のデータブロックを記憶し、
    前記１つまたは複数のコンピューティングノードの前記別のコンピューティングノードが、
    前記クライアントから、前記特定のデータブロックの前記更新レコードを受信する、
    前記１台または複数のストレージデバイスの別のストレージデバイスに前記更新レコードを書き込む、
    前記クライアントに、前記更新レコードが書き込まれた旨の別の肯定応答を返す、及び、
    前記別の肯定応答を返すことの後に、
    前記特定のデータブロックのカレントバージョンを生成するために、前記所与のコンピューティングノードが、前記特定のデータブロックの以前に記憶されたバージョンに、前記受信された更新レコードを適用するように構成される、前記特定のデータブロックの前記カレントバージョンを生成する、及び
    前記１台または複数のストレージデバイスの別のストレージデバイスに前記特定のデータブロックの前記カレントバージョンを書き込む
    ように構成される、請求項１０に記載の前記システム。

Images