図 "SAP HANA パーシスタンスレイヤ" は、パーシスタンスレイヤのアーキテクチャを簡略化して示しています。分離と一貫性の制御はインメモリストアとトランザクションマネージャによってすでに提供されていますが、パーシスタンスレイヤによって、変更が永続的であることと、再起動後にデータベースを最後にコミットされた状態に復元できることを保証します。
パーシスタンスレイヤは、ページ単位で整理された永続ディスクボリュームにデータを保存します。4K から 16M のさまざまなページサイズがサポートされています。データはディスクからロードされ、ページ単位でディスクに保存されます。読込アクセスと書込アクセスの場合は、ページはメモリ内のページバッファにロードされます。ページバッファには特定の最小サイズも最大サイズもありません。代わりに、他の用途に使用されていないすべての空きメモリをページバッファに使用することができます。メモリが別の場所で必要な場合は、LRU (最低使用頻度) ページがキャッシュから削除されます。変更されたページを削除対象として選択した場合、そのページを最初にディスクに保持する必要があります。ページとページバッファはパーシスタンスレイヤによって管理されますが、インメモリストアはロードされたページ内のデータにアクセスできます。
カラムストアパーシスタンス
カラムストアでは、通常のカラムのデータが、連続したメモリ配列に保存されます。このメモリ配列のサイズは、何ギガバイトにも及ぶことがあります。一方、パーシスタンスレイヤでは、よりサイズの小さなページ単位でメモリが管理されます。カラムがメモリにロードされると、データは最初にパーシスタンスレイヤのページバッファにロードされてから、カラム全体を含む連続したメモリ領域にコピーされます。メモリの重複消費を防ぐため、パーシスタンスレイヤでは、コンテンツがカラムストアメモリにコピーされるとすぐに各ページが解放されます。
インメモリテーブルがロードされ、データがパーシスタンスレイヤに書き込まれると、カラムストアとパーシスタンスレイヤ間でデータがコピーされます。
カラムテーブルに対する書込操作は、インメモリカラムデータ構造で実行されます。さらに、REDO ログエントリが書き込まれ、基盤となるページは "ダーティ" とマークされます。後でページをフラッシュする必要があるときに、データはインメモリカラムからデルタページに書き込まれます。
ローストアパーシスタンス
ローストアメモリは、64 MB 単位のセグメントからなる 16,000 ページに編成されます。パーシスタンスレイヤのページバッファとローストアメモリの間のコピーを回避するために、パーシスタンスレイヤには、ローストアページの登録およびアクセスのための特別なインタフェースが用意されています。ローストアページはパーシスタンスレイヤによって登録されますが、メモリの実際の割当はローストアに委任されます。ローストアページマネージャにより、メモリがローストア永続セグメントに割り当てられます。このコンセプトでは、同じメモリがローストアページとしてローストアによって管理されます。また、ページバッファ内のページとしてパーシスタンスレイヤによっても管理されます。同時実行性制御などの要素は、ローストアによって処理されます。シャドウページングや I/O などその他の側面は、パーシスタンスレイヤによって管理されます。この設計では、ローストアデータは、ローストア永続メモリセグメントに直接ロードされます。その際に、ページをコピーする必要はありません。
ディスクストレージ
電源障害の際に再起動できるようにするため、また恒久的な永続性のために、ディスクストレージが必要となります。SAP HANA パーシスタンスレイヤでは、ページ単位で整理された永続ディスクボリュームにデータが保存されます。これは、以下のようにログとデータ領域に分かれています。
挿入、削除、更新といったデータ変更は、ディスクのログ領域にただちに保存されます (同期的)。これはトランザクションに永続性を持たせるために必要です。データ全体を保持する必要はありませんが、トランザクションログは、クラッシュやデータベースの再起動の後に変更を再現するために利用できます。
カスタマイズ可能な間隔 (標準: 5 分ごと) で、新しいセーブポイントが登録されます。つまり、変更されたすべてのページがパーシスタンスのデータ領域でリフレッシュされます。
ディスクアクセスがパフォーマンスのボトルネックになり得るかどうかは、その用途によります。変更はデータボリュームに非同期的に書き込まれるので、ユーザやアプリケーションは書込を待つ必要がありません。すでにメインメモリに存在するデータを読み込む場合、永続ストレージにアクセスする必要はありません。しかし、変更をデータに適用する場合、その変更がログ領域に保持されるまでトランザクションは正常にコミットされません。
パフォーマンスを最適化するために、ログ領域には高速ストレージが使用されます。たとえば、ソリッドステートドライブ (SSD) または Fusion-io ドライブが使用されます (製品出荷マトリクスの認定ハードウェア構成を参照)。
REDO ログ
REDO ログエントリは、書込トランザクションが完了する前に保持されます。これらは、別個のログボリュームに保持され、通常のデータはデータボリュームに保持されます。対応するデータページが保持されていなくても、REDO ログエントリを使用することで、コミットされた変更を復元することができます。
SAP HANA データベースシステムによって書き込まれた REDO ログエントリは、ログ先行書込エントリです。つまり、実際のデータが書き込まれる前にエントリが書き込まれます。REDO ログの管理は、ロガーコンポーネントのタスクです。他のコンポーネントによるログエントリの登録を可能にし、バッファされた REDO ログエントリのディスクへのフラッシュを要求できるようにするためのインタフェースが提供されます。
クラッシュ後にデータベースを再起動する場合は、永続ログエントリを処理する必要があります。この処理を高速化するために、セーブポイントが定期的に書き込まれます。セーブポイント操作中に、直近のセーブポイント以降にメモリ内で行われたすべての変更がディスクに確実に保持されます。したがって、システムの起動時には、直近のセーブポイントの後に登録された REDO ログエントリのみを処理する必要があります。ログバックアップ後は、セーブポイント位置より前の古いログエントリを削除することができます。
UNDO 情報
SAP HANA は、コミットされた変更を保持するだけでなく、コミットされていない変更を保持することもできます。セーブポイントでは、変更がコミットされているかどうかに関係なく、変更されたローストアページの最新バージョンがディスクに書き込まれます。同じことが、カラムテーブルのデルタストレージの新規行にも当てはまります。変更は、対応するページがフラッシュされるときに保持されます。これは、この変更がコミットされたかどうかに関係なく行われます。
起動時に、コミットされていないこれらの変更をロールバックする必要があります。このために、UNDO 情報も保持する必要があります。REDO ログエントリとは異なり、UNDO 情報はログボリュームには書き込まれません。代わりに、システムの再起動後に変更をロールバックするために、シャドウページのコンセプトと UNDO 情報という 2 つのメカニズムが一緒に使用されます。この UNDO 情報はデータボリュームに保持されます。
データボリュームへのデータ保存: 詳細
最近の多くのデータベース管理システムと同様に、SAP HANA でもホストオペレーティングシステムのファイル抽象化レイヤを使用できます。
各データボリュームには 1 つのファイルが含まれており、そのファイルはデータが 4 KB から 16 MB のサイズ (ページサイズクラス) の複数のページにより構成されています。データは、データボリュームにページ単位で書き込まれ、データボリュームからページ単位で読み込まれます。時間の経過とともに、ページは登録、変更、上書き、および削除されます。データファイルのサイズは、より多くのスペースが必要になるのに応じて自動的に増加します。しかし、必要な領域が少なくなっても、そのサイズは自動的には減少しません。つまり、ある時点におけるデータボリュームの実際のペイロード (その時点で使用中のページの累積サイズ) は、その合計サイズよりも少ない場合があります。
これは必ずしも重要なことではありません。このことが意味するのは、単純に、ある時点におけるファイルのデータ量が、過去の別の時点 (たとえば、大きいデータのロード後) におけるデータ量より少ないということです。データボリュームにかなりの空き容量がある場合、データボリュームの縮小を検討すべきかもしれません。ただし、通常のペイロードに対してデータファイルが非常に大きい場合、データベースにより重大な問題があることを示している場合があります。SAP サポートは、この状況について分析するために役立ちます。
