2016年06月16日

[Oracle]統計情報はリアルタイム化の夢を見るか?

 <最初に>

9iの頃まではANALYZEとも呼ばれていた統計情報、当時は「ANALYZEすると遅くなる」「RULEヒントを付けた方が良い」 という都市伝説もありました。
10g以降、ルールベースオプティマイザが廃止された為、仕方なく統計情報と向き合う様になったという方も居るかも知れません。私がそうです。

Oracle Databaseを運用する上で、統計情報の収集は重要なテーマです。
統計情報を収集せずに固定化する運用としているシステムもあれば、標準設定の平日22時の自動収集でも問題無いシステムもあります。

統計情報を固定化する主な理由は「統計情報の変動」に起因する「実行計画の変動」を回避する為です。
そもそも「統計情報の変動」は「格納データの変動」に起因します。
日付データで例えると、新規登録・更新される日付や検索される日付範囲は、システム日付と共に変わります。
古い日付の統計情報で固定化してしまうと、格納データと固定化した統計情報は日々乖離していきます。
統計情報には行数以外にも、最大値、最小値、ヒストグラム等が含まれます。
格納データを全件アクセスする広範囲の検索条件でも、統計情報上では最大値から外れた検索条件として見え、 INDEX検索が有利とコストベースオプティマイザが判断する危険性があります。
統計情報固定化だけでは実行計画を固定化出来ず、格納データや検索条件も固定化しなければなりません。
そこまですると固定コンテンツ化してしまい、更新処理が得意なOracle Databaseを使うメリットが無くなってしまいます。
昔は統計情報固定化という運用を取る事もありましたが、次第に「格納データと統計情報の乖離」による弊害に気を遣う事が多くなってきました。

コストベースオプティマイザが正しい判断をする為には、正しい統計情報が必要です。
しかし統計情報収集にはいくつか問題点があります。
11g以降改善されてきてはいますが、大量データが含まれるテーブルでは統計情報収集に長時間掛かります。
更に統計情報収集はバッチ処理なので、実行タイミングに悩む事があります。
短期間で削除と登録を行う揮発性の高いテーブルや、統計情報収集後に発生したデータでは、前述した「格納データと統計情報の乖離」 による弊害が発生する可能性があります。
適応計画や適応統計で、ハズレの実行計画の検知や改善は行えますが、初回ペナルティを受ける可能性は残ります。

そこで「統計情報のリアルタイム化」という夢を見たのです。
統計情報がリアルタイム化されると、下記の様なメリットがあります。
・長時間掛かるバッチ処理での統計情報収集処理自体が不要若しくは高速化されます。
・「格納データと統計情報の乖離」が無くなる事で、ハズレの実行計画を引く可能性が低下します。

そもそも統計情報には次のものがあります。
・表統計
 行数
 ブロック数
 行の平均長さ
列統計
 列内の個別値(NDV)数
 列内のNULL数
 データ配分(ヒストグラム)
 拡張統計
・索引統計
 リーフ・ブロック数
 レベル数
 索引クラスタ化係数
・システム統計
 I/Oパフォーマンスと使用率
 CPUパフォーマンスと使用率

この内、格納データに依存するのは、表統計、列統計、索引統計です。
セグメントやブロックの情報は元々ディクショナリでリアルタイム管理されています。
行数のリアルタイム管理も難しくは無さそうです。
リアルタイム化が難しそうな箇所は、列統計全般と索引クラスタ化係数だと思います。

 <案1.ラムダアーキテクチャ

少し前にクラウドインテグレーターの情報収集をした際に「ラムダアーキテクチャ」というキーワードを聞きました。
バッチ処理とリアルタイム処理を融合したアーキテクチャで、AWSのRedShiftとKinesisを利用して実装したとの事でした。

DBMS_STATSでの統計情報収集はバッチ処理なので、リアルタイム処理で統計情報を収集する仕組みが別にあれば良さそうです。

 <案2.インメモリカラムストア

12cにて採用されたIn-Memory Optionで、インメモリカラムストアが使用可能となりました。
インメモリカラムストアは列情報なので、列統計全般と索引クラスタ化係数の算出にも使えそうです。
テーブルからインメモリカラムストアに読み込むポピュレーションの後続ジョブとして、インメモリカラムストアから統計情報を逐次収集する事で、 高精度な統計情報を低負荷で収集出来そうです。

ポピュレーションは厳密に言えばリアルタイム処理ではありませんが、DBMS_STATSでの統計情報収集と比べればリアルタイムに近付きます。
インメモリカラムストア若しくはそのサブセットの利用は、統計情報のリアルタイム化に有効だと思います。

インメモリカラムストアには問題もあります。
再起動後は再ポピュレーションしてメモリに乗せなければならない点です。
暖機運転が終わらないと、インメモリ処理が実行出来ません。

 <案3.ローカル管理統計情報

現在の統計情報はSYSTEM表領域内のディクショナリに、履歴はSYSAUX表領域に格納されています。
統計情報をリアルタイムで更新すると、競合が発生するかも知れません。
ディクショナリ管理表領域でも聞いた事のあるような話です。
8iにて採用されたローカル管理表領域で、エクステント情報をヘッダ部のビットマップで管理するようになりました。
統計情報がリアルタイム化される際には、統計情報もローカル管理される様になるかも知れません。
「ローカル管理統計情報」とでも名付けます。

 <案4.適応インメモリ・リアルタイム統計情報

ブロック数やエクステント数の上限が決まっているローカル管理表領域のビットマップは、ヘッダ部の固定領域に確保されています。
統計情報のデータ量は、列数、索引数、ヒストグラム、拡張統計に応じて変動します。
データ量が変動する統計情報は、固定領域ではなく、エクステント単位に拡張出来た方が良いかも知れません。
データ用エクステントとは別に、統計情報用エクステントを用意する事になりそうです。

更に、インメモリカラムストア用エクステントも用意して、シャットダウン前や定期的にメモリ内容をディスクへ保存する事が出来れば、 再起動後の再ポピュレーションの負荷を削減出来ます。
インメモリカラムストアは1MBプールと64KBプールで管理されており、あらかじめ圧縮されている為、 同じサイズかそれより大きなサイズのエクステントに保存する事になりそうです。

データ用表領域は UNIFORM SIZE nM で均一に設定される事もあるので、 統計情報・インメモリカラムストア用エクステントとはサイズが異なる場合があります。
統計情報・インメモリカラムストア用エクステントは、データ用表領域ではなく、 SYSAUX表領域やフラッシュの様な高速ストレージへ保存した方が良いかも知れません。
DB_CACHE_SIZEと「Database Smart Flash Cache」の関係の様に、 INMEMORY_SIZEを高速ストレージで拡張する様な使い方も考えられます。
最近の新機能に合わせて「適応インメモリ」とでも名付けます。

統計情報の保存先は前述したローカル管理では無くなってしまい、「適応統計」は12cで既に実在する機能名なので、 「リアルタイム統計情報」とでも名付けます。

realtime_statistics

 <最後に>

「統計情報のリアルタイム化」について、こうなれば良いのに、あれが使えそう、と思う事を書き出し、 Oracle Databaseの将来について語ってみました。

posted by charade at 05:00| Comment(0) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする