⑥圧縮率は設定によって数倍の差が出る
Oracle Database In-Memoryには6種類の圧縮タイプが用意されています。どれを選択するかはユーザが自由に決めることができ、クエリの性能を重視する場合は「FOR QUERY」、圧縮率を重視する場合は「FOR CAPACITY」というように、適切な圧縮タイプは目的によって変わってきます。
圧縮タイプごとの性能差については前回ご紹介しましたので、今回は圧縮率がどの程度異なるのかを比較していきます。使用するデータはこれまでと同じStar Schema Benchmarkのスキーマです。ファクト表には6億行のレコードがあり、列内に同じ値（数字）が多く含まれているのが特徴です。
結果を見ると、圧縮タイプによって最大で3倍ほど圧縮率が異なっています。最も圧縮率の高いFOR CAPACITYではデータのサイズが1/4以下になっており、FOR QUERYなど他の圧縮タイプと比べてより多くのデータをメモリ上に格納できます。
圧縮タイプごとの違いが分かったところで、今度は従来の圧縮やExadataのHybrid Columnar Compression（HCC）と比べてみましょう。その結果が以下のグラフです。
従来の圧縮と比べると、FOR QUERY LOW以降であればOracle Database In-Memoryの方が高い圧縮率になっています。従来の圧縮はデータブロック内にある重複値をシンボル表にコピーするという形で行われていますが、データを行単位で格納しているため、圧縮率はそれほど高くなりません。重複データは同じ行内ではなく列内に存在する可能性が高いので、列指向であるOracle Database In-Memoryのほうが仕組み上有利です。Exadata HCCには及ばないものの、圧縮率としてはかなり優れていることが分かります。
なお、従来の圧縮やExadata HCCで圧縮済みの表でも、ポピュレーションをするとOracle Database In-Memoryの圧縮が適用されます。圧縮されたものをそのままメモリ上に持っていけるわけではないので、メモリのサイジングはOracle Database In-Memoryの圧縮率をもとに行う必要があります。DBMS_COMPRESSIONパッケージやOracle Database In-Memory Advisorを使えば必要な領域を試算できるので、サイジングの際に活用すると良いでしょう。
⑦OLTPの性能はそのまま維持できる
Oracle Database In-Memoryは分析処理だけに特化した機能であり、更新処理を高速化するような仕組みは持っていません。時折「OLTPの高速化」という表現を見かけますが、それは表をインメモリにして分析用の索引を削除すれば、索引の更新が不要になる分OLTPの高速化に繋がるという意味です。更新は従来どおりバッファ・キャッシュを使って行われるため、索引を削除しない限り非インメモリと同等の性能になるはずです。
実際にSwingbenchを用いたテストを行ってみたのが以下のグラフです。あらかじめポピュレーションしておいた表に対して、100から500までセッション数を変化させて検証しています。
一番左にある非DBIM（Oracle Database In-Memoryを使用しない構成）を基準に比べてみると、100～300セッションの間ではほとんど性能に変化がないことが分かります。500セッションの超高負荷状態になると多少差が見られますが、更新処理向けの圧縮タイプであるFOR DMLを選択しておけばその影響も軽微です。
Oracle Database In-Memoryは、OLTPと分析処理をリアルタイムに融合するというコンセプトを掲げています。非インメモリと同等の更新性能が維持できれば、更新されたデータをその場で分析するというリアルタイムな情報活用が可能になるはずです。
