Exadata Hybrid Columnar Compression に関する検証 その２
＜Exadata Hybrid Columnar Compression に関する検証 その２＞
ペンネーム: ベロ
前回、メルマガを発行して以来、このテーマに対する反響は私が思っていた以上の
ものがあったようです。
– 通常の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と呼ばれる所以は何か?
などなど。
是非お楽しみに。
ラグビーの季節がやってきたー!!
恵比寿より