InsightTechnology 旧ブログ

＜Exadata Hybrid Columnar Compression に関する検証 その６＞
ペンネーム： ベロ

今回で、Hybrid Columnar Compressionシリーズは最後となります。
11g R2より、Exadataに限らず、様々な機能拡張がされていますが
Hybrid Columnar Compressionは、データ量爆発の今日において、
データ量を削減しつつ、パフォーマンスを確保するというデータ
を管理する者への大命題を解決する一つとなり得ます。

本シリーズでは、Exadataではない環境にてHybrid Columnar
Compressionの機能を検証すべく、いくつかオラクル社ではサポート
されていない方法を使用しました。その中で分かった事実を
まとめると以下のようでした。

1. Hybrid Columnar Compression方式であるQUERYやARCHIVEという
   圧縮方式は、カラム単位の複数ブロック(CU:Compression Unit)
   単位でアクセスされる

2. CU単位での圧縮であることから、圧縮率の向上が見込むことが
   可能となるが、DMLもCU単位で処理されることから同時実行性は
   低下する

3. Hybridと名称がついているのは、新方式(Query/Archive)と
   旧方式(BASIC/OLTP)が共存しているから

4. CUの特性上、SELECT文のカラム名の指定方式によっては
   パフォーマンスが大きく変化する可能性がある

上記より、実運用でHybrid Columnar Compressionを使用する場合
いくつか、パフォーマンスの観点で考慮は必要なものの、大幅な
データ圧縮とI/Oデペンドによるボトルネックの解消は可能だろう
と思われます。

また、最後にHybrid Columnar Compressionを使用する上での注意
事項を記載しておきます。

a) DML使用時
    Hybrid Columnar Compressionとして圧縮されるものは以下の
    場合です。
      - Direct Load
      - Parallel DML
      - /*+ APPEND */
      - Direct Path SQLLDR

	Hybrid Columnar Compressionを使用して圧縮されたテーブルに
	対して、以下の方式でDMLが発行された場合、自動的に旧来
	(OLTPモード)に変換されます
	- Conventional Insert
	- Updated rows

b) SELECT使用時
	- クライアントにデータを返す時点でデータの展開がされます
	- Buffer Cacheには、圧縮された状態で配置されます

ということから、主に威力を発揮する場合は以下と言える
– Direct Loadを多用するシステム
– データの検索がメインのシステム
– データの更新が非常に少ないシステム

ただし、本検証は、実際のExadataでの検証結果ではなく、単なる
シュミレーション環境ですので、その点にはご注意ください。

それでは、またお会いできる日を楽しみに。

春が待ち遠しい恵比寿より