Exadata Hybrid Columnar Compression に関する検証 その2

<Exadata Hybrid Columnar Compression に関する検証 その2>
ペンネーム: ベロ

前回、メルマガを発行して以来、このテーマに対する反響は私が思っていた以上の
ものがあったようです。

– 通常のOracle 11gR2でHybrid Columnar Compressionを本当に体感できるのか?
– どうやってHybrid Columnar Compressionを体感できるのか?
– 体感できるなら、それはサポートされているのか?

などなど。

では、軽く回答していきます。

Q1.
通常のOracle 11gR2でHybrid Columnar Compressionを本当に体感できるのか?
A1.
通常のOracle 11gR2のみでHybrid Columnar Compressionを体感することは可能
です。

ただし、これは、私が個人的に検証目的で実施していることであり、本来では
実施してはいけない類のものです。。。が、どうしても検証してみたいという
エンジニア魂が抑えられず実施していることをお忘れなく。

Q2.
どうやってHybrid Columnar Compressionを体感できるのか?
A2.
本来は、本メルマガでご紹介したいところですが、もろもろの事情で今回は
非公開とさせてもらいます(いわゆる自主規制です)
ただし、キーワードだけご紹介
– HCC
– ビットマスク
これを頼りに皆さまリサーチに励んでみてください。

Q3.
体感できるなら、それはサポートされているのか?
A3.
全くもってサポートされていません。今回、ご紹介する予定のHybrid Columnar
Compressionの機能も本来の動作をしていない可能性があります。

では、気を取り直して早速検証していきましょう。
今回、環境に使用した環境は以下の通りです。

== 検証環境と検証データのおさらい =============================================
[検証環境に関して]
OS : Redhat Linux AS 5.3 (x86)
Oracle : Oracle 11.2.0.1 32bit

[検証データに関して]
最初にnocompress_tableとし購買履歴のデータを準備します。このテーブルのサイズ
は以下の通りです。

SQL> col table_name for a30
SQL> select table_name,blocks,compression,compress_for from user_tables
 2 > where  table_name = 'NOCOMPRESS_TABLE';

TABLE_NAME                         BLOCKS COMPRESS COMPRESS_FOR
------------------------------ ---------- -------- ------------
NOCOMPRESS_TABLE                   170300 DISABLED

今回の環境はブロックサイズが8KBですので、テーブルのサイズとしては、約1.3GB
程度となります。
===============================================================================

今回の検証は、Hybrid Columnar Compressionを使用した場合、従来のAdvanced
Compression(非圧縮のテーブルを含みます)と比較して、どの程度の圧縮率になるのか?
また、圧縮にかかる時間はどのように変化するのか?を見てみます。

今回比較対象としたオペレーションは以下の通りです。

NOCOMP      : 非圧縮テーブル
OLTP_COMP   : OLTP圧縮テーブル
BASIC_COMP  : BASIC圧縮テーブル
Q_LOW_COMP  : QUERY LOW圧縮テーブル
Q_HIGH_COMP : QUERY HIGH圧縮テーブル
A_LOW_COMP  : ARCHIVE LOW圧縮テーブル
A_HIGH_COMP : ARCHIVE HIGH圧縮テーブル

圧縮サイズに関して)

NOCOMP      |################################## 170300
OLTP_COMP   |############################# 145380
BASIC_COMP  |########################## 129688
Q_LOW_COMP  |############ 60311
Q_HIGH_COMP |####### 32587
A_LOW_COMP  |###### 27929
A_HIGH_COMP |### 16105
------------------------------------------------------------> block(s)

圧縮時間に関して)

NOCOMP      |####################### 3:47
OLTP_COMP   |####################### 3:52
BASIC_COMP  |######################## 4:00
Q_LOW_COMP  |############## 2:17
Q_HIGH_COMP |###################### 3:35
A_LOW_COMP  |####################### 3:47
A_HIGH_COMP |###################################### 6:24
------------------------------------------------------------> time

まず、従来のOLTP/BASICの圧縮に比べ、Hibrid Columnar Compression(Query/Archive)
の圧縮率がかなり高いことが分かります。また、圧縮にかかる時間は、従来の圧縮に
比べ高速化されている場合もあります。
この事実から、Queryタイプの圧縮は、DWHであっても比較的参照が多いテーブルが適
しており、Archiveタイプの圧縮は、参照頻度が低い、まさしくアーカイブ的に使用
するテーブルが適していると言えるでしょう。

この、圧縮率の高さと高速性はどこからきているのか?
次回からは、徐々に機能の概要から中身の検証を行っていこうと思います。
ブロックレベルで、従来の圧縮とHybrid Columnar Compressionとでどう違うのか?
Hybridと呼ばれる所以は何か?
などなど。

是非お楽しみに。

ラグビーの季節がやってきたー!!
恵比寿より