Exadata Hybrid Columnar Compression に関する検証 その５
＜Exadata Hybrid Columnar Compression に関する検証 その５＞
ペンネーム： ベロ
前回まで、Hybrid Columnar Compressionの動作を見てきました。第１回では
圧縮にかかる時間を各圧縮タイプで比較してみました。今回はSELECTにかかる
時間を各圧縮タイプで比較してみたいと思います。
以下のSQLを各圧縮タイプごとに実行し、イベント10046のSQLトレースからSQL
の実行に関する統計情報を見てみます。
select cust_last_name,count(*) from group by cust_last_name;
call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 13 8.70 48.09 169355 169618 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 15 8.71 48.10 169355 169618 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 13 9.00 21.97 61468 61828 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 15 9.00 21.97 61468 61828 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 13 7.93 13.16 32335 34350 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 15 7.93 13.16 32335 34350 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.02 0.33 29 58 0 Execute 1 0.00 0.00 0 0 0 Fetch 13 7.57 11.78 27693 21274 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 15 7.60 12.12 27722 21332 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.04 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 13 10.17 14.20 16369 14727 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 15 10.18 14.24 16369 14727 0
これでは、分かりづらいので、disk + queryの大きい順にソートしてみます。
|################################## 338973 |############ 123296 |####### 66685 |##### 49054 |### 31096 ----------------------------------------------------------- disk + query
では同様にelapsedでもソートしてみます。
|################################################ 48.10 |###################### 21.97 |############## 14.24 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |############# 13.16 |############ 12.12 ----------------------------------------------------------- elapsed
disk + queryを見るとReadすべきデータ量に依存して物理 + 論理I/Oの増加
傾向が見て取れます。圧縮によるデータサイズがそのまま、I/O量に比例して
ますね。
しかし、実際にSQLのレスポンス時間はどうでしょう?
ARCHIVE HIGHで圧縮されたデータは、I/O量が最も少ないにも関わらず、最も
高速とは行きませんでした。
これは、データの検索という物理I/Oに依存する処理とは別にデータを展開
するというCPUに依存した処理が必要だからです。
ARCHIVE HIGHで圧縮されたデータは高圧縮であるメリットと同時にデータを
展開する処理でオーバーヘッドが高いことを示していると思われます。
また、前回お話したように、Hybrid Columnar Compressionはデータを実行
環境に返す際にデータの展開処理を行うことが、既存のデータ処理に影響する
場合があるかも知れません。
以下、簡単なPL/SQLで検証してみます。
begin for rec in (select from SOE.QUERY_HIGH_COMPRESS_TABLE) loop null; end loop; end; /
上記のカラムの数でパフォーマンスが大きく異なります。
call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.02 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 13.91 13.84 32314 206444 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 13.91 13.86 32314 206444 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.04 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 16.24 17.60 32314 206198 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 16.24 17.64 32314 206198 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 20.93 22.04 32335 211692 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 20.93 22.04 32335 211692 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 24.11 25.34 32338 212923 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 24.11 25.34 32338 212923 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.03 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 24.44 27.33 32339 213462 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 24.44 27.37 32339 213462 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.02 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 29.25 33.04 32375 219367 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 29.25 33.06 32375 219367 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 31.51 39.23 32451 229278 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 31.51 39.23 32451 229278 0 call count cpu elapsed disk query current ------- ------ -------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 Execute 1 0.00 0.00 0 0 0 Fetch 177419 38.24 42.20 32456 229766 0 ------- ------ -------- ---------- ---------- ---------- ---------- total 177421 38.24 42.20 32456 229766 0
これも、disk + queryでソートしてみます。
|######################## 238758 |######################## 238512 |######################## 244027 |######################### 245261 |######################### 245801 |######################### 251742 |########################## 261729 |########################## 262222 ----------------------------------------------------------- disk + query
さらに elapsedでソートしてみます。
|############## 13.86 |################## 17.64 |###################### 22.04 |######################### 25.34 |########################### 27.37 |################################# 33.06 |####################################### 39.23 |########################################## 42.20 ----------------------------------------------------------- elapsed
I/O関連の統計情報にほとんど変化が見られないのに比べ、実行速度は
カラム数と比例して長くなっています。
これは、データの展開処理にて多くのCPUリソースが必要とされるためだと
思われます。
Hybrid Columnar CompressionがDWH系で威力を発揮することを考えるとテーブル
構造は非正規化されていることも多いと思われますが、安直に
select * from ～と処理してしまうと、相当量の無駄が発生してしまうことが
予想されます。
適切なカラムを選択して処理することが大事になると思います。
(*文中の測定結果はExadataを使用しての測定結果ではありません)