JP5660693B2 - ハイブリッドｏｌｔｐ及びｏｌａｐ高性能データベースシステム - Google Patents

Description

オンライントランザクション処理（ＯＬＴＰ）及びオンライン分析処理（ＯＬＡＰ）の２つのエリアは、データベースアーキテクチャに関して異なる課題を提示する。従来型システムでは、高レートの基幹業務トランザクションを有する顧客は、そのデータを、ＯＬＴＰ用の１つのデータベースと、ＯＬＡＰ用の１つのいわゆるデータウェアハウスという２つの別々のシステムに分割した。妥当なトランザクションレートを可能にするものの、この分離は、抽出変換負荷データステージングを周期的にしか開始しないことによって引き起こされる遅延によるデータ鮮度の問題と、２つの別々の情報システムを維持することによる過剰なリソース消費とを含む、多くの欠点を有する。

歴史的には、データベースシステムは主に、オンライントランザクション処理のために使用された。そのようなトランザクション処理システムの典型的な例は、販売注文入力又はバンキングトランザクション処理である。こうしたトランザクションは、データ全体の小部分のみにアクセスして処理し、したがってかなり高速に実行することができる。標準化ＴＰＣ−Ｃベンチマーク結果によれば、現在最高のスケールのシステムは、毎秒１００，０００件を超えるそのような販売トランザクションを処理することができる。

約２０年前、ビジネスインテリジェンス（ＢＩ）という、データベースシステムの新しい使用法が発展した。ＢＩアプリケーションは、ビジネス分析に関するレポートを生成するためにデータのかなりの部分を処理する、長時間のいわゆるオンライン分析処理（ＯＬＡＰ）照会に依拠する。典型的なレポートは、地理的領域又は製品カテゴリ、或いは顧客分離などによってグループ化された集約販売統計を含む。オペレーショナルＯＬＴＰデータベースに対するこうした照会を実行する、ＳＡＰのＥＩＳプロジェクトなどの初期の試行は、ＯＬＡＰ照会処理によってリソース競合が生じ、基幹業務トランザクション処理が極度に損なわれたために却下された。したがって、図１に例示するデータステージングアーキテクチャが考案された。この場合、トランザクション処理が専用ＯＬＴＰデータベースシステム上で実施される。さらに、ビジネスインテリジェンス照会処理のために、別々のデータウェアハウスシステムがインストールされる。周期的に、例えば夜間に、ＯＬＴＰデータベース変更が抽出され、データウェアハウススキーマのレイアウトに変換され、データウェアハウスにロードされる。このデータステージング及びそれに関連するＥＴＬプロセスは、いくつかの固有の欠点を示す。

古いデータ：ＥＴＬプロセスは周期的に実行することができるだけなので、データウェアハウス状態は、最新のビジネストランザクションを反映しない。したがって、ビジネス分析は、その決定の基礎を、古い（期限切れの）データに置かなければならない。

冗長性：２つのシステムの使用は、データの２つの冗長なコピーを維持するコストを招く。積極的な面では、冗長性により、アプリケーション特有の方式で、ＯＬＴＰ処理用の正規化テーブルで、及びＯＬＡＰ照会用のスタースキームとしてデータをモデルすることが可能となる。

高経費：２つのシステム（ハードウェア、ソフトウェアなど）のための経費、及び２つのシステムのための保守コスト、及び複雑なＥＴＬプロセスを考慮に入れなければならないので、２つの別々のシステムを維持することは、技術的及び経済的な犠牲を招く。

本発明の目的は、こうした欠点に対処することである。

本発明によれば、請求項１に記載の方法が提供される。有利な実施形態が、残りの請求項に列挙される。

本発明は、ハードウェア支援複製機構を使用してトランザクションデータの整合スナップショットを維持することにより、ＯＬＴＰとＯＬＡＰの両方を同時に処理することのできるハイブリッドシステムを提供する。一実施形態では、本発明は、ＯＬＴＰトランザクションのＡＣＩＤプロパティを保証し、同一の任意に最新かつ整合したスナップショットに対してＯＬＡＰ照会セッション（複数の照会）を実行するメインメモリデータベースシステムを提供する。仮想メモリ管理（アドレス変換、キャッシング、更新時コピー）に関するプロセッサ固有のサポートの利用により、高トランザクションレートと低ＯＬＡＰ照会応答時間の両方を同時に得ることができる。

本発明の一実施形態によれば、ＯＬＴＰデータベースとＯＬＡＰデータウェアハウスシステムの分離が放棄される。同一のシステムに対する、こうした２つの非常に異なる作業負荷の統合に必要な処理性能は、メインメモリデータベースアーキテクチャによって達成することができる。

本発明は、トランザクションＯＬＴＰデータの最新状態に対するＯＬＡＰ照会の実行を可能にする。これは、ＯＬＴＰデータベースに対するトランザクション処理と、周期的にリフレッシュされるだけであり、古い（期限切れの）データに基づく照会となる、データウェアハウスに対する照会処理との分離を実施する従来型システムとは対照的である。

本発明の一実施形態では、トランザクションデータベースは照会処理機能を備え、それによって、照会処理（の一部）をデータウェアハウスからＯＬＴＰシステムにシフトする。この目的で、同一のデータベース上のＯＬＴＰトランザクション処理とＯＬＡＰ照会処理の混合作業負荷がサポートされる。これは、相異なるアプリケーションシナリオのために専用システムを構築する最近の傾向とはある程度逆行する。同一のシステム上のこうした２つの非常に異なる作業負荷の統合は、例えばメインメモリデータベースアーキテクチャを通じて、処理性能が改善した場合に、最良に実装することができる。

一見すると、（インターネットアクセス可能）データボリュームの劇的な急増は、すべてのトランザクションデータをメインメモリに常駐したままにするというこの前提に矛盾する可能性がある。しかし、より詳しい検討により、ビジネスクリティカルトランザクションデータベースボリュームが有するサイズは限定されることが示され、このことにより、メインメモリデータ管理が支持される。この仮定を確証するために、アマゾンの推定トランザクションボリュームを分析することができる。注文処理データボリュームは、年間で推定約１５０億ユーロの収益を有する。ＴＰＣ−Ｃベンチマークについて指定されるように、個々の注文明細が約１５ユーロの値を有し、各注文明細が約５４バイトの格納データを負うと仮定すると、合計データボリュームは、そのような販売アプリケーションで支配的なリポジトリである注文明細について１年当たり５４ＧＢとなる。

この推定は、ボリュームを増大させる他のデータ（顧客及び製品データ）も、データを圧縮してボリュームを低減させる可能性も含まない。それでも、年間販売データが大規模サーバのメインメモリに収まることができると仮定することは安全である。さらに、過去の開発から推定すると、コモディティ並びにハイエンドサーバのメインメモリ容量は、最大のビジネス顧客の要件よりも速く増大すると予想することは安全である。

ＯＬＴＢデータベースとＯＬＡＰデータウェアハウスの従来技術の分離を示す図である。 本発明の一実施形態によるメインメモリＯＬＴＰデータベースアーキテクチャを示す図である。 本発明の一実施形態によるハイブリッドＯＬＴＰ及びＯＬＡＰデータベースアーキテクチャを示す図である。 本発明の一実施形態による新しい仮想メモリスナップショットのフォーキングを示す図である。 本発明の一実施形態で使用される「更新時コピー」を示す図である。 本発明の一実施形態による、ＯＬＡＰ照会のための仮想メモリスナップショットの使用を示す図である。 本発明の一実施形態による、異なる時点での複数のＯＬＡＰセッションを示す図である。 本発明の一実施形態による、区分データに対するマルチスレッドＯＬＴＰ処理を示す図である。 本発明の一実施形態による、整合スナップショットバックアップアーカイブを示す図である。 本発明の一実施形態によるリドゥーロギング（ｒｅｄｏ ｌｏｇｇｉｎｇ）を示す図である。 本発明の一実施形態による、ＯＬＴＰ処理のためのスタンドバイとして、及びアクティブＯＬＡＰプロセッサとして働く２次サーバの使用を示す図である。 本発明の一実施形態によるアクティブトランザクションに関するアンドゥーロギングを示す図である。 本発明の一実施形態による、（１）保存バックアップをロードすること、及び（２）リドゥーログインを適用することを含む回復プロセスを示す図である。

本発明の一実施形態によるトランザクション処理のためのメインメモリアーキテクチャを図２に示す。この実施形態では、単一スレッディング手法が採用され、すべてのＯＬＴＰトランザクションが順次実行される。このアーキテクチャは、アクティブな更新トランザクションのみがデータベース全体を「所有」するので、コストのかかるデータオブジェクト又は索引構造のロッキング及びラッチングの必要をなくす。有利なことに、この順次実行手法は、メインメモリデータベースを通じて実装することができ、他のトランザクションのためにインターリービングにＣＰＵを使用することによって１つのトランザクションの代わりにＩ／Ｏ操作をマスクする必要はない。メインメモリアーキテクチャでは、典型的なビジネストランザクション（例えば、注文入力又は支払処理）が有する持続時間は、わずか数〜１０マイクロ秒である。しかし、複雑なＯＬＡＰ型照会を作業負荷キューに注入することが許可された場合、すべての後続のＯＬＴＰトランザクションは、そのような長時間の照会の計算を待機しなければならなくなるので、複雑なＯＬＡＰ型照会はシステムを詰まらせることになる。そのようなＯＬＡＰ照会が例えば３０ｍｓ以内に終了した場合であっても、約１０００以上のＯＬＴＰトランザクションを完了することのできる持続時間にわたってシステムをロックすることになる。

しかし、毎秒数万のレートでＯＬＴＰトランザクションを処理すると同時に、トランザクションデータの最新のスナップショットに対してＯＬＡＰ照会を処理するメインメモリデータベースシステムを提供することが望ましい。この課題を図３に示す。本発明の一実施形態によれば、ハードウェア支援複製機構を使用してトランザクションデータの整合スナップショットを維持することにより、ＯＬＴＰとＯＬＡＰを同時に処理することのできるハイブリッドシステムが提供される。

本発明は、ＯＬＴＰトランザクションのＡＣＩＤプロパティを保証するメインメモリデータベースシステムによって実装することができる。特に、耐久性及び高速回復のために、ロギング及びバックアップアーカイビング方式を利用することができる。ＯＬＴＰ処理と並列に、同一の任意に最新かつ整合したスナップショットに対してＯＬＡＰ照会セッション（複数の照会）を実行することができる。仮想メモリ管理（アドレス変換、キャッシング、更新時コピー）のためのプロセッサ固有のサポートの利用により、同一のシステムで、かつ同時に、前例のない高トランザクションレート及び超低ＯＬＡＰ照会応答時間が達成される。

システムアーキテクチャ
本発明の一実施形態によれば、ＯＬＴＰトランザクション及びＯＬＡＰ照会は、同一のメインメモリ常駐データベース上で実施することができる。旧式のディスクベースのストレージサーバとは対照的に、任意のデータベース特有のバッファ管理及びページ構造化を省略することができる。データは、仮想メモリ内の単純なメインメモリ最適化データ構造内に常駐する。したがって、どんな追加の間接的方法も用いずにＯＳＪＣＰＵ実装アドレス変換を「フルスピード」で活用することができる。２つの主流のリレーショナルデータベース記憶方式を利用することができる。行格納手法では、関係がレコード全体の配列として維持され、列格納手法では、関係が、属性値のベクトルとして垂直に区分される。仮想メモリは物理メインメモリよりも（著しく）大きくなることができるとしても、仮想メモリページのＯＳ制御スワッピングを回避するために、データベースは、物理メインメモリのサイズに限定されることが好ましい。或いは、フラッシュメモリや固体ドライブなどの２次ストレージによってメインメモリを補足することもできる。

ＯＬＴＰ処理
すべてのデータがメインメモリに常駐するので、ＩＯを待つために停止することは決してないことになる。したがって、単一スレッディング手法に依拠することができ、すべてのＯＬＴＰトランザクションが順次実行される。このアーキテクチャは、１つの更新トランザクションのみがデータベース全体を「所有」するので、コストのかかるデータオブジェクトのロッキング及びラッチングの必要をなくす。このシリアル実行手法は、メインメモリデータベース上で実装することができ、他のトランザクションのためにインターリービングにＣＰＵを使用することによって１つのトランザクションの代わりにＩ／Ｏ操作をマスクする必要はない。メインメモリアーキテクチャでは、典型的なビジネストランザクション（例えば、注文入力又は支払処理）が有する持続時間は、わずか約１０マイクロ秒である。これは毎秒数万程度のスループットとなり、大規模なビジネスアプリケーションが必要とするものよりもさえ、ずっと高い。

トランザクションが実行を待つためにシリアル化される左側のキューにより、ＯＬＴＰトランザクションのシリアル実行を図４で例示する。トランザクションは、高水準スクリプト記述言語でストアドプロシージャとして実装される。この言語は、探索キーによってデータベースエントリをルックアップし、オブジェクトのセットを通じて反復し、データレコードを挿入、更新、及び削除する機能などを提供する。次いで、この高水準スクリプト記述コードが、メモリ内データ構造を直接操作する低レベルコードにコンパイルされる。

ＯＬＴＰトランザクションは、キュー内の後続のトランザクションに関する長い待ち時間を回避するために、短い応答時間を有するべきである。このことにより、任意の種類の対話トランザクション、例えばユーザ入力を要求すること、又は外部機関のクレジットカードチェックを同期式に起動することが禁止される。

ＯＬＡＰスナップショット管理
複雑なＯＬＡＰ型の照会をＯＬＴＰ作業負荷キューに注入することが許可された場合、すべての後続のＯＬＴＰトランザクションは、そのような長時間の照会の計算の完了を待機しなければならなくなるので、複雑なＯＬＡＰ型照会はシステムを詰まらせることになる。そのようなＯＬＡＰ照会が例えば３０ｍｓ以内に終了した場合であっても、恐らくは数千のＯＬＴＰトランザクションを完了することのできる持続時間にわたってシステムをロックする。毎秒数万のレートでＯＬＴＰトランザクションを処理すると同時に、トランザクションデータの最新のスナップショットに対してＯＬＡＰ照会を処理するメインメモリデータベースシステムを提供する目標を達成するために、新しいプロセスに関する仮想メモリスナップショットを作成するオペレーティングシステム機能が活用される。このことは、ＯＬＴＰプロセスを複製すること、すなわちＯＬＴＰプロセスの子プロセスを作成することによって行われる。例えば、ＯＬＴＰプロセス複製は、フォーキング（ＵＮＩＸ（登録商標）でのｆｏｒｋ（）システムコール）によって実施することができる。以下では、「フォーキング」に対する参照は、ＯＬＴＰプロセス複製の任意の実装を指すものとする。

トランザクション整合性を保証するために、トランザクションの中央でフォーキングを実施するのではなく、２つの（シリアル）トランザクション間のみでフォーキングを実施すべきである。図４でオーバレイされたページフレームパネルによって例示するように、子プロセスは、親プロセスアドレス空間の厳密なコピーを得る。図６に示すように、フォーク操作によって作成される仮想メモリスナップショットが、ＯＬＡＰ照会のセッションを実行するために使用される。

スナップショットは、厳密にフォーク操作が行われたときに存在した状態にとどまる。幸いにも、最新式のオペレーティングシステムは、メモリセグメントをすぐに物理的にコピーしない。むしろ、図５に示すように、オペレーティングシステムは、怠惰な「更新時コピー戦略」を利用する。当初、親プロセス（ＯＬＴＰ）と子プロセス（ＯＬＡＰ）は、（オブジェクトａに対する）両方の仮想アドレスを同一の物理メインメモリ位置に変換することにより、同一の物理メモリセグメントを共有する。図では、点線のフレームにより、メモリセグメントの共有を強調する。点線のフレームは、（まだ）複製されなかった仮想メモリページを表す。オブジェクト、例えばデータ項目ａが更新されるときにのみ、ＯＳ及びハードウェアサポートされる更新時コピー機構が、ａが常駐する仮想メモリページの複製を開始する。その後で、トランザクションを実行するＯＬＴＰプロセスによってアクセス可能な、ａ’と表す新しい状態と、ＯＬＡＰ照会セッションによってアクセス可能な、ａと表す古い状態とがある。図が示唆するのとは異なり、追加のページが、ページ変更を開始したＯＬＴＰプロセスについて実際に作成され、ＯＬＡＰスナップショットは古いページを指す。この詳細は、いくつかのそのようなスナップショットが作成される場合（図７参照）にスペース消費を推定するために重要である。

機能を見る別の直感的方法は以下の通りである。ＯＬＴＰプロセスはデータベース全体の上で動作し、データベースの一部がＯＬＡＰモジュールと共有される。すべてのＯＬＴＰ変更が、コピーされる（シャドーイング（ｓｈａｄｏｗ）される）データベースページからなる、別々のコピー（エリア）Ｄｅｌｔａに適用される。したがって、ＯＬＴＰプロセスは、要求時更新後ページのそのワーキングセットを作成する。このことは、ページをバッファプールにスワップすることにいくぶん類似しているが、バッファプール内のページ障害を処理するのに１０ｍｓかかる代わりに、メインメモリページをコピーするのに２μｓしかかからないので、更新後ページの要求時コピーが３〜４倍高速である。「時々」、最新のＯＬＡＰセッションに関する新しいプロセスをフォークすることにより、ＤｅｌｔａがＯＬＡＰデータベースとマージされる。それによって、Ｄｅｌｔａが概念的に（メインスナップショット）データベースに再統合される。Ｄｅｌｔａをメインデータベースにマージするどんなソフトウェア解決策とも異なり、ハードウェアサポートされる仮想メモリマージ（フォーク）を非常に効率的に１秒未満単位で達成することができる。

（Ｄｅｌｔａへの）複製が、通常はデフォルトサイズ４ＫＢを有する、ページ全体の細分性で実施される。この例では、ａ’の状態変化により、ａの複製だけでなく、ｂなどのこのページ上のすべての他のデータ項目の複製も、それが変化していないとしても誘発される。この欠点は、ＴＬＢキャッシング及び書込み時コピー実施を介する超効率的ＶＭアドレス変換などの、ＯＳ及びプロセッサによる非常に効果的で高速な仮想メモリ管理によって補償される。データベースシステムでの従来のシャドーイング概念は、ページレベルでシャドーコピーを維持し、又は個々のオブジェクトをシャドーイングする純粋なソフトウェア機構に基づく。

スナップショットは、親（すなわち、ＯＬＴＰ要求実行）プロセスによる更新後ページ数に比例したストレージオーバヘッドを招く。スナップショットは、フォーク操作がスナップショットを作成するときのＯＬＴＰプロセスのメモリ状態と、ＯＬＴＰプロセスの現メモリ状態との間のデルタ（変更後ページに対応する）を複製する（ＯＬＡＰプロセスは、共有ページを（ほぼ）決して変更しない。このことはもちろん、更新時コピー機構のために問題とはならない。しかし、性能を向上させるために、ＯＬＡＰプロセスは、その一時データ構造を非共有メインメモリエリアに割り振るべきである）。メインメモリ容量が不十分である場合、ＯＬＡＰ照会エンジンは２次記憶装置（例えばディスク）を利用することができ、それによってメインメモリ容量をより長い実行時間と交換する。ディスクベースの規則を作成することによって関係をソートすることは、１つの顕著な例である。ＯＬＡＰ照会キュー内の、卵形線によって示されるすべてのＯＬＡＰ照会は、データベースの同一の整合スナップショット状態にアクセスする。そのような照会のグループは照会セッションと呼ばれることがあり、ビジネスアナリストが同一の状態を反復的に照会して、例えばさらなる詳細にまで掘り下げ、又はより良好な概要を求めてロールアップすることによってデータの詳細な分析のためにそのようなセッションを使用できることが示される。

複数のＯＬＡＰセッション
これまでのところ、ＯＬＴＰに関する１つのプロセスと、ＯＬＡＰに関する別のプロセスという２つのプロセスを使用するデータベースアーキテクチャを説明した。ＯＬＡＰ照会が読取り専用であるので、同一のアドレス空間を共有する複数のスレッドでＯＬＡＰ照会を容易に並列に実行することができる。それでもなお、ＯＬＡＰ照会がどんな可変データ構造も共有しないので、任意の同期（ロッキング及びラッチング）オーバヘッドを回避することができる。通常は１０個を超えるコアを有する現代のマルチコアコンピュータは、この照会間並列化を介してかなりの高速化をもたらすことができる。

マルチコアサーバを有効に活用する別の可能性は、複数のスナップショットを生成することである。特に、任意の現スナップショットを得ることができる。このことは単に、新しいスナップショットを周期的に（又は要求時に）フォークし、したがって新しいＯＬＡＰ照会セッションプロセスを開始することによって達成することができる。このことを、ただ１つのＯＬＴＰプロセスの現データベース状態（フロントパネル）と、３つのアクティブ照会セッションプロセスのスナップショットとを示す図７に例示し、最も古いものは背景にあるものである。連続する状態変化が、データ項目ａ（最も古い状態）、ａ’、ａ’’、及びａ’’’（最も若いトランザクション整合状態）という４つの異なる状態によって強調される。ＥＴＬデータステージングを用いる現在の分離データウェアハウス解決策の場合と同様に、数分又は数時間ではなく、数秒の間隔で最新の照会に関するスナップショットを作成することが予想されるので、明らかに、大部分のデータ項目は、異なるスナップショット間で変化しない。アクティブなスナップショットの数は、原理上は、それぞれがそれ自体のプロセスで限定されない。優先順位を調節することにより、ＯＬＴＰプロセスが多数であり、及び／又はマルチスレッディングを使用し、したがってコア数を超過する場合であっても、基幹業務のＯＬＴＰプロセスに常にコアが割り振られることを確認することができる。

セッションの最後の照会が終了した後、スナップショットが削除される。このことは単に、照会セッションを実行中であったプロセスを終了することによって行われる。スナップショットが作成されたのと同じ順序でスナップショットを削除する必要はない。そのようなスナップショットは、例えば詳細なストック取得目的で、より長い持続時間にわたって持続することができる。しかし、スナップショットのメモリオーバヘッドは、このスナップショットの作成から次に若いスナップショットの時間まで（それが存在する場合、又は実際の時間まで）の実行中のトランザクション数に比例する。図７に、「中間年齢」スナップショットについて物理的に複製され、したがって最も古いスナップショットによって共有され、アクセス可能であるデータ項目ｃを通じて、このことを示す。直観にはいくぶん反するが、ｃが常駐するページが、ＯＳ／プロセッサにより、物理ページに関連する参照カウンタを介して最も古いスナップショットと共有されるものとして自動的に検出されるので、最も古いスナップショットの前に中間年齢スナップショットを終了することは依然として可能である。したがって、中間年齢スナップショットプロセスの終了時に解放される、ａ’が常駐するページとは異なり、中間年齢スナップショットの終了を生き残る。最も若いスナップショットは、現ＯＬＴＰプロセスアドレス空間内に含まれる状態ｃ’にアクセスする。

マルチスレッド化ＯＬＴＰ処理
既に略述したように、複数のスレッドとしてＯＬＡＰプロセスを構成することができ、現代のコンピュータの複数のコアがより良く利用される。このことは、ＯＬＴＰプロセスについても可能である。１つの単純な拡張は、複数の読取り専用ＯＬＴＰトランザクションを並列に管理することである。読取り／書込みトランザクションがＯＬＴＰ作業負荷キューの先頭にあるとすぐに、それ以上の更新トランザクションがキューの先頭でなくなるまで、システムが静止し、順次モードに転送し戻される。現実的アプリケーションでは、通常は、更新トランザクションよりも多くの読取り専用トランザクションがあり、したがって、あるレベルの並列度を得ることを予想することができ、並列度は、ＯＬＴＰ作業負荷キューを（注意深く）再構成することによって向上させることさえできる。

データを区分することが自然である、多くのアプリケーションシナリオがある。これに関する１つの非常に重要なアプリケーションクラスはマルチテナンシーである。異なるデータベースユーザ（テナントと呼ばれる）が、同一又は類似のデータベーススキーマに対して作業するが、そのトランザクションデータを共有しない。むしろ、テナントは、データのそのプライベートパーティションを維持する。いくつかのリードモーストリー（ｒｅａｄ−ｍｏｓｔｌｙ）データ（例えば、製品カタログ、地理的情報、Ｄｕｎ ＆ Ｂｒａｄｓｔｒｅｅｔのようなビジネス情報カタログ）が異なるテナント間で共有される。

興味深いことに、トランザクション処理用の広く知られている業界標準であるＴＰＣ−Ｃベンチマーク（ｗｗｗ．ｔｐｃ．ｏｒｇ）は、類似の区分化を示す。データの大部分をそれが属するウェアハウスによって水平に区分することができるからである。唯一の例外は、この共有データパーティションに対応する項目テーブルである。

そのような区分アプリケーションシナリオでは、ＯＬＴＰプロセスを複数のスレッドとして構成し、並列度を介して性能をさらに向上させることができる。このことを図８に示す。トランザクションがそのプライベートパーティションのみにアクセス及び更新し、共有データにアクセスする（更新しない）限り、そのようなトランザクションを並列に、パーティション当たり１つ実行することができる。図はこのことを示す。パネル内の各卵形（トランザクションを表す）が、別々のスレッドによって実行される１つのそのようなパーティション制約トランザクションに対応するからである。

しかし、パーティションにわたって読み取り、又は共有データパーティションを更新するトランザクションは、同期を必要とする。一実施形態では、クロスパーティショントランザクションが、純粋な順次手法と同様に、システムに対する排他的アクセスを要求する。このことは、すべてのパーティションが１つのノード上に常駐する中央システムで十分に効率的である。しかし、マルチパーティショントランザクションのための２相コミットプロトコルを必然的に伴う計算クラスタにわたってノードが分散する場合、より高度な同期手法が有益である。

ＯＬＡＰスナップショットを前と同様にフォークすることができる（トランザクション整合式にこのことを行うことができる前にすべてのスレッドが静止することを除いて）。ＯＬＡＰ照会をすべてのパーティション及び共有データにわたって構築することができ、このことは例えば、管理目的のマルチテナンシーアプリケーションで有益である。

計算クラスタ内の異なるノードにプライベートパーティションを割り振る分散システムについて、データベースの区分化をさらに活用することができる。リードモーストリー共有パーティションをすべてのノードにわたって複製することができる。次いで、対応するノードにパーティション制約トランザクションを転送し、どんな同期オーバヘッドも伴わずに並列に実行することができる。同期は、パーティションクロストランザクション（ｐａｒｔｉｔｉｏｎ−ｃｒｏｓｓｉｎｇ ｔｒａｎｓａｃｔｉｏｎｓ）及びすべてのノードにわたる同期スナップショット作成のために必要である。

ＯＬＡＰ照会セッションのスナップショット分離
スナップショット分離では、トランザクションは、トランザクション整合データベース状態を継続的に確認する。トランザクション整合データベース状態が、トランザクションが開始するより前（直前）の時点で存在したからである。データベース修正が並列で実行中に、そのようなスナップショットを実装するための異なる可能性がある。

ロールバック：この方法は、データベースオブジェクトを定位置で更新する。より古い照会がより古いバージョンのデータ項目を必要とする場合、より古いバージョンのデータ項目が、このオブジェクトに対するすべての更新をアンドゥーすることによって現バージョンから作成される。したがって、オブジェクトのより古いコピーが、いわゆるロールバックセグメントで、すべてのアンドゥーログレコードを必要な時点まで逆に適用することによって作成される。

バージョニング（ｖｅｒｓｉｏｎｉｎｇ）：すべてのオブジェクト更新が、オブジェクトの新しいタイムスタンプバージョンを生成する。したがって、照会の代わりの読取りが、そのタイムスタンプが照会の開始時間よりも小さい最も若いバージョン（最大のタイムスタンプ）を取り出す。バージョニングされたオブジェクトは、永続的に維持され（タイムトラベリング照会を可能にする）、又はアクティブ照会がそれにアクセスする必要がもうなくなるまで一時的に維持される。

シャドーイング：元々は、シャドーイングは、すべての変更が最初にシャドーに書き込まれ、次いでトランザクションコミット時間にデータベースにインストールされたときに、アンドゥーロギングの必要をなくすために作成された。しかし、シャドーイング概念は、スナップショットの維持にも適用することができる。

仮想メモリスナップショット：本発明の実施形態によるスナップショット機構は、照会セッションと呼ばれる一連の照会に関するスナップショットを明示的に作成する。この点で、照会セッションのすべての照会が、フォークプロセスを介して保持される同一の整合状態に依拠することのできる１つのトランザクションに束ねられる。

さらに、不揮発性２次サーバ又はストレージ上のデータベース全体のバックアップアーカイブを作成するためにＶＭスナップショットを活用することができる。このプロセスを図９に示す。通常、アーカイブは、１〜１０Ｇｂ／ｓの高帯域幅ネットワークを介して、同一の計算センタ内の専用ストレージサーバに書き込まれる。この転送速度を維持するために、ストレージサーバは、対応する集約帯域幅のためのいくつかの（約１０枚）のディスクを利用しなければならない。

ＯＬＴＰトランザクション同期
単一スレッドモードでは、ＯＬＴＰトランザクションは、データベース全体を所有するので、どんな同期機構も必要としない。

マルチスレッドモードでは、２つのタイプのトランザクションが区別される。
・パーティション制約トランザクションは、それ自体のパーティション内のデータを読み取り、更新することができ、共有パーティション内のデータを読み取ることができる。しかし、更新はそれ自体のパーティションに限定される。
・パーティションクロストランザクションは、さらに、共有データを更新し、又は別のパーティション内のデータにアクセス（読取り又は更新）するものである。

共有データに対する更新はめったに生じず、トランザクションが通常はそれ自体のデータのみに対して作用するように区分化が導出されるので、後者のクラスのトランザクションのパーティションクロストランザクションは、非常にまれであるはずである。ＯＬＴＰ作業負荷内のストアドプロシージャトランザクションの分類は、その実装コードを分析することに基づいて自動的に行われる。実行中に、トランザクションが「パーティション制約」と誤って分類されたことが判明した場合、トランザクションがロールバックされ、ＯＬＴＰ作業負荷キューに「パーティションクロス」として再挿入される。

好ましくは、並列に、パーティション当たり最大１つのパーティション制約トランザクションが許可される。この制約下で、パーティションは非重複データ構造を有し、共有データはアクセス読取り専用であるので、どんな種類のロッキング又はラッチングも必要がない。

しかし、パーティションクロストランザクションは、排他的モードで許可されなければならない。本質的には、パーティションクロストランザクションは、許可される前に、データベース全体に対する排他的ロック（又はＰＯＳＩＸ用語では、許可される前に、障壁を通過しなければならない）を事前主張しなければならない。したがって、パーティションクロストランザクションの実行は、すべての他のトランザクションが終了するまで待機しなければならないので比較的高コストであり、その持続時間中に、他のトランザクションは許可されない。システムに許可されると、パーティションクロストランザクションの排他的許可が、やはり共有データパーティション又はプライベートデータパーティションの任意の種類のロッキング又はラッチング同期を防止するので、トランザクションはフルスピードで実行される。

耐久性
トランザクションの耐久性は、コミットされるトランザクションのすべての効果を障害後に復元しなければならないことを必要とする。これを達成するために、古典的リドゥーロギングを使用する。図１０では、シリアルトランザクションストリームから生じ、不揮発性リドゥーログ記憶装置に至る灰色の卵形によってこのことを強調する。トランザクションを表すストアドプロシージャのパラメータをロギングすることによって論理リドゥーロギングを利用する。従来のデータベースシステムでは、システムクラッシュ後にデータベースがアクション不整合状態となることがあるので、論理ロギングは問題がある。トランザクション整合アーカイブから再始動が実施されるので（図９参照）、本発明の図示する実施形態では、このことが生じることができない。データベースを正しく回復することができるために、実行される順序でこうした論理ログレコードを書き込むことだけが重要である。単一スレッドＯＬＴＰ構成では、このことが容易に達成される。マルチスレッドシステムでは、すべてのトランザクションに関して完全に順序付けなければならないのは、パーティションクロストランザクションのログレコードだけであり、パーティション制約トランザクションのログレコードを並列に書き込むことができ、したがってパーティション当たり順次化されるだけである。

２次サーバを介する高可用性及びＯＬＡＰロードバランシング：リドゥーログストリームを使用して２次サーバを維持することもできる。この２次サーバは単に、１次サーバと同じトランザクションを実行するだけである。１次サーバ障害の場合、トランザクション処理が２次サーバに切り替わる。しかし、安定したストレージへのリドゥーログレコードの書込みを中止せず、耐障害性のためだけに２次サーバに依拠することが好ましい。ソフトウェアエラーは、ワーストケースでは、１次及び２次サーバの「同期」クラッシュとなることがある。２次サーバは、どんな読取り専用ＯＬＴＰトランザクションも実行する必要がないので、通常は１次サーバよりも低い負荷であり、したがって１次サーバよりも低いＯＬＴＰ負荷を有する。このことは、ＯＬＡＰ照会セッションの一部（又はすべて）を２次サーバに委ねることによって利用することができる。１次サーバ上のＯＬＡＰセッションのプロセスをフォークする代わりに、又はそれに加えて、２次サーバも使用することができる。ＯＬＴＰ処理のためのスタンドバイとして、及びアクティブＯＬＡＰプロセッサとして働く２次サーバの使用を図１１に示す。図には、ストレージサーバのアーカイブに整合スナップショットを書き込むために１次サーバの代わりに２次サーバを使用する可能性を図示していない。それによって、バックアッププロセスが１次サーバからより負荷の少ない２次サーバに委ねられる。

ロギングの最適化
ライトアヘッドロギング（ｗｒｉｔｅ ａｈｅａｄ ｌｏｇｇｉｎｇ：ＷＡＬ）原理は、トランザクションをコミットする前にログレコードをフラッシュ（ｆｌｕｓｈ）することを必要とするので、性能ボトルネックとなることが判明することがある。このことは、トランザクションが待機しなければならないので、単一スレッド実行では特にコストがかかる。

以下２つの一般に利用される戦略が可能である。
・グループコミット、又は、
・非同期コミット

グループコミットは、例えばＩＢＭのＤＢ２で構成可能である。トランザクションの最終的コミットは、トランザクションの終了直後には実行されない。むしろ、いくつかのトランザクションのログレコードが蓄積され、バッチモードでフラッシュされる。したがって、コミットの確認が遅延する。トランザクションのバッチが完了し、そのログレコードがフラッシュされるのを待機する間、すべてのトランザクションのロックは既に解放されている。このことは早期ログ解放と呼ばれる。現在の非ロッキングシステムでは、このことは、対応するパーティションに関する次のトランザクション（複数可）を許可することになる。ログバッファがトランザクションのグループについてフラッシュされると、そのコミットがクライアントに対して確認される。

別の、安全性のより低い方法は、ログレコードのフラッシュを待機するのを回避することによってＷＡＬ原理を緩和する。ログレコードが揮発性ログバッファに書き込まれるとすぐに、トランザクションがコミットされる。このことは「非同期」コミットと呼ばれる。障害の場合、こうしたログレコードの一部が失われることがあり、したがって回復プロセスが、再始動中に、こうしたコミットされたトランザクションを見落とすことになる。

原子性
トランザクションの原子性は、失敗したトランザクションの効果をデータベースからなくすことができることを必要とする。明示的に中止したトランザクションだけを考慮する必要があり、Ｒ１回復と呼ばれる。データベースが揮発性メモリ内だけにあり、トランザクションのコミットの成功が保証されるときにのみ論理リドゥーログが書き込まれるので、ルーザトランザクション（ｌｏｓｅｒ−ｔｒａｎｓａｃｔｉｏｎ）（クラッシュ時にアクティブであったもの）の更新が復元後データベースでアンドゥーされることを要求するいわゆるＲ３回復は、この実施形態では必要ではない。さらに、回復のための開始点として働くデータベースのアーカイブコピーはトランザクション整合であり、したがって回復中にアンドゥーする必要のあるどんな操作も含まない（図９参照）。結果として、アンドゥーロギングは、（すべてのアクティブトランザクションに関するマルチスレッドモードでの）アクティブトランザクションに対して必要なだけであり、揮発性メモリ内だけで維持することができる。このことを図１２で、ページフレームパネルの左上のリングバッファによって強調する。トランザクション処理の間、更新後データオブジェクトがあれば、その以前のイメージがこのバッファに記録される。リングバッファがトランザクション当たりの更新数（にマルチスレッド操作でのアクティブトランザクション数を掛けたもの）によって束ねられるので、リングバッファのサイズはかなり小さい。

クリーニングアクション整合スナップショット（Ｃｌｅａｎｉｎｇ Ａｃｔｉｏｎ−Ｃｏｎｓｉｓｔｅｎｔ Ｓｎａｐｓｈｏｔ）
アンドゥーロギングを使用して、１つ又は複数のトランザクションがアクティブであった間に作成されたアクション整合ＶＭスナップショットからトランザクション整合スナップショットを作成することもできる。このことは特に、マルチスレッドＯＬＴＰシステムがトランザクション処理を完全に静止させる必要を回避するので、マルチスレッドＯＬＴＰシステムで有益である。その関連するＶＭスナップショットを含むＯＬＡＰプロセスをフォークした後、アンドゥーログレコードが、逆の発生順にスナップショット状態に適用される。アンドゥーログバッファが（フォーク時に）アクティブトランザクションのすべての効果を反映するので、そうした、得られるスナップショットのみがトランザクション整合であり、この時点までに完了したすべてのトランザクションを含む、フォーク時に依然としてアクティブであるトランザクションの開始前のデータベースの状態を反映する。

システム障害後の回復
回復中、メインメモリで復元される、最も若い完全に書かれたアーカイブで始めることが可能である。次いで、リドゥーログが発生順に適用され、アーカイブのスナップショットに関するフォーク後の最初のリドゥーログエントリで開始する。例えば、最大１０Ｇｂ／ｓまでの帯域幅（ストレージサーバからのネットワークの帯域幅によって限定される）でアーカイブを復元することができ、リドゥーログを毎秒１００，０００のトランザクションレートで適用することができる場合、典型的な大企業に関するファイルオーバ時間（例えば、１００ＧＢのデータベース及び毎秒数千の更新トランザクション）は、バックアップアーカイブが毎時書き込まれる場合、わずか１〜数分程度である。このフェイルオーバ時間を許容することができない場合、複製したサーバに依拠することも可能であり、図１１に示すように、一方はアクティブモードであり、他方は例えばリドゥーログ「スニッフィング（ｓｎｉｆｆｉｎｇ）」を介して、同一のトランザクションを実施する。障害の場合、単純なスイッチオーバがシステムを復元する。

回復プロセスを図１３に示す。

上述の実施形態は例として説明したに過ぎず、こうした実施形態に対する修正が添付の特許請求の範囲内に含まれることを理解されよう。

Claims (17)

1. メモリを備えるハイブリッドＯＬＴＰ及びＯＬＡＰデータベースシステムを維持する方法であって、
   １つ又は複数のＯＬＴＰトランザクションを実行するステップと、
   １つ又は複数の仮想メモリスナップショットを作成するステップと、
   前記仮想メモリスナップショットのうちの１つ又は複数を使用して１つ又は複数のＯＬＡＰ照会を実行するステップと、
   既存のハードウェアサポートメモリ整合性制御機構を使用して、前記データベース内のデータオブジェクトが更新されるときを識別し、対応するページの新しい物理コピーの作成をトリガするステップと、
   を含む方法。
2. 前記方法は、
   データオブジェクトに対する更新に応答して、前記データオブジェクトが格納される仮想メモリページを複製するステップ、
   をさらに含み、
   その後で更新後データオブジェクトがＯＬＴＰトランザクションにとってアクセス可能となると共に、非更新データオブジェクトが、ＯＬＡＰ照会のために依然としてアクセス可能である、請求項１に記載の方法。
3. 前記ＯＬＴＰトランザクションが第１アドレス空間内で実行され、
   前記仮想メモリスナップショットを作成するステップが、前記第１アドレス空間のコピーを表す第２アドレス空間を用意するサブステップを含み、
   前記ＯＬＡＰ照会が第２アドレス空間内で実行され、
   前記仮想メモリスナップショットを作成するステップが、ＯＬＴＰプロセスを複製して、ＯＬＡＰ照会の実行のための子プロセスを作成するサブステップを含む、請求項１に記載の方法。
4. 前記データベースが、パーティション内にプライベートデータを格納し、共有データを格納し、前記パーティションが、異なるデータ処理システム上に常駐することができ、
   前記方法が、
   前記プライベートデータに対する読取り及び／又は更新アクセス、又は前記共有データに対する読取りアクセスを含むＯＬＴＰトランザクションを並列に実行するステップ、
   前記パーティションにわたる読取りアクセス、又は前記共有データへの更新アクセスを含むＯＬＴＰトランザクションを順次実行するステップ、及び、
   前記パーティションのうちの１つ又は複数及び前記共有データにわたる１つ又は複数のＯＬＡＰ照会を実行するステップ、
   のうち１つ以上を含む、請求項１〜３のいずれか一項に記載の方法。
5. 前記仮想メモリスナップショットがトランザクション整合である、請求項１〜４のいずれか一項に記載の方法。
6. ＯＬＴＰトランザクションがアクティブではないとき、前記仮想メモリスナップショットを作成するステップ、
   をさらに含む請求項５に記載の方法。
7. １つ又は複数のＯＬＴＰトランザクションがアクティブであるとき、前記仮想メモリスナップショットを作成するステップと、
   アンドゥーログ機構を使用して、前記１つ又は複数のアクティブなＯＬＴＰトランザクションが開始される前に、前記データベースの状態を表すように前記仮想メモリスナップショットを適応させるステップと、
   をさらに含む請求項５に記載の方法。
8. 前記仮想メモリスナップショットのうちの１つを使用して複数のＯＬＡＰ照会を並列に実行するステップ、
   をさらに含む、請求項１〜７のいずれか一項に記載の方法。
9. それぞれの並列ＯＬＡＰ照会について複数の仮想メモリスナップショットを作成するステップ、
   をさらに含む請求項１〜５のいずれか一項に記載の方法。
10. 周期的に又は要求時に新しい仮想メモリスナップショットを作成するステップ、
    をさらに含む請求項１〜９のいずれか一項に記載の方法。
11. 対応するＯＬＡＰ照会の完了後に前記仮想メモリスナップショットを削除するステップ、
    をさらに含む請求項１〜１０のいずれか一項に記載の方法。
12. 前記仮想メモリスナップショットを使用して、前記データベースのトランザクション整合バックアップを用意するステップ、
    をさらに含む請求項１〜１１のいずれか一項に記載の方法。
13. 前記トランザクション整合バックアップ及びリドゥーログ機構を使用して、前記データベースを復元するステップ、
    をさらに含む請求項１２に記載の方法。
14. １次サーバを維持して、前記ＯＬＴＰトランザクションを実行するステップと、
    ２次サーバを維持して、前記１次サーバによって実行される前記ＯＬＴＰトランザクションのうちの少なくとも一部も、データに対する更新アクセスを含むすべてのＯＬＴＰトランザクションを実行し、前記ＯＬＡＰ照会のうちの少なくとも一部を実行するステップと、
    をさらに含む請求項１〜１３のいずれか一項に記載の方法。
15. メモリに格納されたデータベースと、
    プロセッサと、
    前記プロセッサに結合され、実行されたときに、請求項１〜１４のいずれか一項に記載の方法を前記プロセッサに実行させる命令を格納するストレージと、
    を備える、ハイブリッドＯＬＴＰ及びＯＬＡＰデータベースシステム。
16. 前記データベースがメインメモリデータベースである、請求項１５に記載のハイブリッドＯＬＴＰ及びＯＬＡＰデータベースシステム。
17. プロセッサベースのシステムのプロセッサに、請求項１〜１４のいずれか一項に記載の方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images