パーティショニングとデータ圧縮を併用するメリット：Oracleパーティショニング実践講座（5）（2/3 ページ）

本連載では、大規模データベースでのパフォーマンス・チューニングの手法として、Oracleパーティショニングを解説する。単なる機能説明にとどまらず、実機による検証結果を加えて、より実践的な内容をお届けする。（編集部）

[岸和田隆，アシスト]

データ圧縮とパーティショニング併用のメリット

　データウェアハウスのように、データの投入処理がバッチ処理として実施される場合であればデータ圧縮は利用しやすいと思います。しかし、オンライン・トランザクション処理で頻繁にアクセスされる表のデータに対してデータ圧縮を実施するのは、データのロード時に圧縮する方法であれ、既存の表データを圧縮する方法であれ、非常に困難であることが想像できます。

　そこでデータ圧縮とオンライン・トランザクション処理を両立させるために、パーティショニングの併用を検討してみましょう。

　例えば、売上データを月ごとにパーティションで分割したとします。売上データの場合、登録、更新が行われるのは当月のパーティションであり、過去の売上データに対する処理は検索が中心となります。圧縮処理はパーティション単位で実施でき、圧縮時のロックも該当パーティションのみ保持されるため、過去の売上データを含むパーティションを圧縮すれば、表全体の使用領域が大幅に減少し、過去の売上データの集計処理でデータ圧縮効果が望めるだけでなく、アクセスが頻繁な当月パーティションへのオンライン・トランザクションの影響を回避することができます。

図2　パーティショニングとデータ圧縮の併用

既存の表データを圧縮する場合の領域について

　ただし、既存の表データを圧縮する場合には、空き領域に注意が必要です。図3のように、圧縮の過程で圧縮前のデータと圧縮後のデータを格納できる領域が必要となります。大規模なデータを含む表を圧縮するよりは、パーティショニングされた表のパーティションごとに圧縮を実施した方が、圧縮時の領域という側面でも実用的だと考えられます。

図3　既存の表データの圧縮イメージ

売上実績表を例にデータ圧縮を検証する

　それでは、データ圧縮がどの程度の効果を得られるか確認してみましょう。いままでの検証と同様に、売上実績表に対してデータ圧縮前とデータ圧縮後の検索時間やCPUリソースの違いについて紹介します。

　検証環境は第2回「パーティション・プルーニングの有効性を検証する」と同様に検証用のSQLとして、筆者の勤務するアシストが提供する「Rapid Warehouse Pack」のERモデルと、Webレポーティング・ツール「WebFOCUS」のテンプレートから、単純なSQLを抽出しています。詳細は第2回の「図4　検証で使用する表構成（Rapid Warehouse Pack ERモデル）」「表2　売上実績表の組み合わせとパーティション数」を参照してください。

　売上実績表を圧縮した場合、表1のような結果となりました。重複データのサイズと重複の度合いによって圧縮率は異なるため圧縮率としての参考にはなりませんが、データ圧縮により表を構成するブロック数に変化が生じることが分かります。

　そのため、一意検索のような特定ブロックの検索ではデータ圧縮によるブロック数の減少効果は得られませんが、全表走査や範囲走査など多くのブロックを走査する必要のある検索では、アクセスする総ブロック数が減少するため応答時間に良い効果があると予想できます。

　ただ、圧縮の構造がポインタによる重複値の削減だとしても、圧縮前のブロックとは異なるアクセスが行われるため、CPUリソースの消費量に影響を及ぼす可能性も予想できます。

	サイズ	ブロック数	エクステント数	圧縮率
NP圧縮前	102.3Gbytes	3,352,352	1,821	65.4％
NP圧縮後	66.9Gbytes	2,191,104	1,251
表1　売上実績表の圧縮効果 NP：非パーティション