検証で分かったOracle Database In-Memoryに関する10の真実 (前編)

性能だけではなく、注意事項も知りたい

　アシストでは、10月から11月にかけて、東京、大阪、名古屋でOracle Database In-Memoryの検証結果を発表するセミナーを開催（2014/10/29開催 アシストテクニカルフォーラム特別講演 開催報告）しました。延べ700名以上のお申し込みをいただき盛況のうちに終えることができましたが、印象的だったのは性能だけでなく注意事項や課題などに着目されている方が多かったということです。

　これまでの記事でご紹介したように、Oracle Database In-Memoryの特徴はその圧倒的な速さと、SQLの変更が不要というシンプルさにあります。Star Schema Benchmarkを用いた検証では、ディスク・アクセスに比べて数百倍、バッファ・キャッシュに比べて数十倍の速度向上が確認できています。

　しかし、表をインメモリにするという簡単な操作でこれだけの結果を得られてしまうため、「本当にそれだけで大丈夫なのか？」「他に気を付けることはないか？」と疑問を抱く方が多いように思います。そこで今回は、Oracle Database In-Memoryを実際に検証して分かった注意事項や、マニュアルに書かれていない特殊なケースでの動作などをご紹介します。

①圧縮タイプによって検索性能に差が出る

　Oracle Database In-Memoryでは、非圧縮を含む6つの圧縮タイプをサポートしています。デフォルトではFOR QUERY LOWというクエリの性能を重視した圧縮タイプが使われるようになっており、その他にも圧縮率を重視したFOR CAPACITY HIGHなどがあります。

　圧縮タイプは自由に選択できるため、メモリのサイズが有限であることを考えると、高い圧縮率のものが魅力的に映ります。ただし、どれを選択するかによって圧縮率だけでなくクエリの性能も変わってくることを考慮しなければいけません。

　以下のグラフは、圧縮タイプごとにクエリの応答性能がどの程度違うのかを並べて比較したものです。全部で14あるStar Schema Benchmarkのクエリのほぼすべてにおいて、圧縮タイプごとの性能差が確認できています。クエリによっては3倍近くの性能差が出ることもあります。

　性能差が出る理由はAWR（自動ワークロード・リポジトリ）やシステム・リソースの使用状況を見ればすぐに分かります。FOR QUERYではデータを圧縮した状態でそのまま参照できますが、FOR CAPACITYの場合は解凍が必要になります。CPUが使われた時間を比べてみると、以下のように何倍もの差が出ています。

　こうした動作の違いがあるため、性能重視の場合はデフォルトであるFOR QUERY LOWが推奨されます。FOR CAPACITYが非推奨というわけではなく、クエリの応答時間が性能要件を上回るのであれば、圧縮率を高めるための選択肢としては有効です。こうした違いを把握した上で、どの圧縮タイプを選択するかを決めましょう。