Conpressionの検証を実施していきます。前回、Columnarたる所以をダンプから発見することは出来ませんでした。Blockをまたがった単位であることは分かりました。CUの中身がどのような構造になっているのか、検証することができません。ここにこだわっていても埒があかないので、物的証拠を探すよりも状況証拠を集める方針に切り替えることにします。カラム単位で圧縮することで、パフォーマンス(Query)がどう変わるのか?カラム単位で圧縮と言うと、カラム単位で別領域(別Block)にデータを格納して、Queryアクセスもカラム単位でアクセスするのではないか?そうすると、SELECT句の書き方で、パフォーマンスが大きく異なるのでは?と想像できます。単一カラムを選択で、パフォーマンスがどう変化するのか検証してみます。ここで、有意な変化があるのなら、CUの中の”カラム単位”のブロックへのアクセスをしているのではないかと推察できます。00:03:56.84なるほど、経過時間は、全カラム選択時と比較して、約半分に減少しました。いうことは、CUの内部ではカラム単位でデータアクセスしていると言える。いやいや、それだけでは何とも言えません。経過時間と共に統計情報を見てみます。readsに大きな変化は見られません。toclientが、約半分になっています。これは、経過時間が半分になったことと相関してます。Columnarと言えども、内部的にカラム単位でアクセスするような動作ではないのではないと思われます。それは、低レベルのブロックアクセスがカラム単位の有無で変化がないことから想像できます。clientに関係します。クライアントに返したデータ量が半分になったのです。それは、圧縮してあるデータの展開量が半分になったと推定できます。Compressionでは、データをクライアントに返す直前に必要なデータの展開を行っているということです。圧縮データの展開処理は、データをクライアントに返す直前に行う。なるとWHERE句の処理はどうなるのか?と疑問が湧いてきます。WHERE句の有無でパフォーマンス(Query)に変化があるのか?WHERE句の有無で、パフォーマンスが大きく異なる場合、データの展開処理の場所と頻度が異なる可能性が高い。以下、WHERE句の無いSQLと有るSQLでパフォーマンスを計測してみます。like'%@%';以下、経過時間と統計情報です。processedWHERE句の有無でパフォーマンスに有意な差は見られません。WHERE句の処理は、通常(非圧縮データ)のように、データブロックを検索して結果を得るのではなく、どこか別のメタデータ(一種のインデックス)を使用しているのではないかと推察されます。このメタデータを経由して、実データへアクセスすることで展開処理がなくても(オーバーヘッドを最小化して)検索が実行できるものと思われます。メタデータにはどんなものがあるのでしょうか?これは、現在のところ想像の域を出ませんが、きっと、圧縮前のデータとそれを使用しているROW、(もしくはカラム)へのポインタ情報ではないか?ではでは、実データにアクセスしない(と思われる)方法、つまりメタデータのみアクセス出来そうなものは何か?きっとCOUNT(*)系のアクセスだと、メタデータ+そのポインタのみのアクセスで完了して、実データへはアクセスしなくて良い可能性が高い。メタデータにはどんなデータを管理しているのか?また、メタデータだけのアクセスが可能なのか?以下のSQLを実行してみます。ARCHIVE_HIGH_COMPRESS_TABLE;メタデータが先程、筆者が想像したような構造になっている場合、実データへのアクセスは行わず、メタデータから必要なポインタ計算のみ実行することでアクセスは相当高速化されるはずです。processed思った通りです。1416094となっていましたが、今回のCOUNT(*)では31825と大幅に減少しています。経過時間も1秒未満となっています。block(未満)程度の大きさではないかと大まかに推測できます。ちなみに、COUNT(*)ではなく、カラム名を入れてCOUNTを取得すると以下のようになりました。readsに大きな変化はありませんが、経過時間が大きく異なります。これは、メタデータから、COUNT(*)のようなカラム情報がないものを検索するより、カラム情報を特定するオーバーヘッドがかなり高いと想像できます。いうことで、今回の検証はこの辺にしておきます。今回の検証は想像を含めた状況証拠を見てみることに集中しました。その中で、以下のようなことが言えると思われます。reserved.トップページ企業概要プライバシーポリシ。