Browser)がこの機能に対応しましたので今回のDBラボはインメモリについて行っていこうと思います。In-Memory」といいます。メモリー上にカラムフォーマットで載せることにより、分析系クエリが高速化し、従来のローフォーマットも同時に使用することでトランザクション処理のパフォーマンスも向上するのが特徴です。導入の際にアプリケーション側での変更は必要なく、テーブル定義の変更でインメモリ化が可能となっています。12c(12.1.0.2)からご利用できます。)従来の通常テーブルとインメモリ設定を施したインメモリテーブルでどの程度パフォーマンスが向上するか、今回は以下のケースについて検証しようと思います。今回の検証環境は以下の通りです。従来の通常テーブルとインメモリ設定を施したインメモリテーブルでフルスキャンを行った際にどのくらいの違いが生じるのだろうか?従来のテーブルとインメモリ化したテーブルを比較し、平均実行時間を調べました。ケース1の準備まず、ベースになるテーブルを下記SQLで作成します。INDEX)/上記のテーブルを作成した後、データの作成を行います。今回は500万レコードセットした状態で行います。Browserのデータ生成ツールの機能を使用します。列の設定値:無難に1~の連番を設定しました。列の設定値:全て整数になるように丸め値を設定しました。列の設定値:日付の乱数値を設定しました。データの作成が終了しましたら、次はインメモリテーブルを作成します。Browserのオブジェクトリストより「TBL_LABO_NOMAL」を選択し、右クリックよりコピー&ペーストを行います。リネームを促されますので下記画像のように変更します。コピーが終わったら、次はインメモリの設定を行います。LOW」を指定して[作成]ボタンを押すことでインメモリ設定を行います。事前に右上の見積機能を使い、メモリがどの程度使用されるかを確認しておくことをお勧めします。インメモリ領域の空き領域を確認しておきます。3004MBの空きがあるので実験には問題ありません。準備が整いましたら、下記SQLで実行時間を計測していきます。※平均実行時間について10回計測を行い、そのうちの5つの中央値を使用。その5つの値の平均を平均実行時間とします。圧倒的にインメモリの方が早いという結果となりました。フルスキャンに関してはインメモリの方が圧倒的に早くなっています。次は通常テーブル、インデックス有りの通常テーブル、そしてインメモリテーブルの実行時間を計測します。下記のテスト1と同様の方法で新しいテーブル(TBL_LABO_NOMAL2)を作成します。作成後に下記SQLでインデックスを付加します。データをコピーします。準備が整いましたら、下記SQLで実行時間を計測していきます。平均実行時間は若干ですがインデックス有りの通常テーブルが早いという結果になりました。これはインメモリが大量レコードの中から数行のレコードを取得するのが、あまり得意でないという点も影響していると思いますが、インデックス無しの通常テーブルと比較した場合、パフォーマンスは大きく向上しており、インメモリ化してインデックスを外しても大きくパフォーマンス低下することはなさそうです。※Oracle公式ホームページでは導入前の事前調査と、メモリー管理が重要であると明言されています。実装の際は実行計画を有効に活用し、チューニングを行ったほうが良いと思います。JOINしたものを比較し、平均実行時間を調べました。ケース3の準備1つのトランザクションテーブルに3つのマスタテーブルが結合したものを計測するため、下記の8つのテーブルを用意します。レコード数はトランザクションテーブルに500万件、マスタテーブルには10万件の登録して計測します。TBL_LABO_MST3_IMトランザクションテーブルの内容は以下のようになっております。同じ構成のため割愛します。マスタテーブルの内容は以下のようになっております。同じ構成のため割愛します。作成したら次はテスト1と同様の方法でトランザクションテーブルをコピーで作成、マスタテーブルを7つコピーします。データが全て作成し終えた状態で「_IM」が末尾に付いたテーブルをインメモリ化します。準備が整いましたら、下記SQLで実行時間を計測していきます。4.163テスト3考察インメモリ化を行うことでパフォーマンスはいずれも向上しました。インメモリにしている割合に応じてパフォーマンスも向上しました。※「トランザクションのみ」が早いのは単純にマスタに対してデータ量の割合が大きくインメモリの恩恵もより大きく受けているからだと推測します。今回の検証結果では、以下のようになりました。・インメモリ化はパフォーマンス向上に役立つ・インデックスと同等の性能を持っている・データ量が多ければ多いほど恩恵が大きい今回の検証は本当に単純なテーブルの比較でしたが、インメモリはインデックスを使用してない列への検索は圧倒的に早いという結果になりました。テスト2では僅差でインデックスの検索スピードに負けましたが、インデックスは断片化によるパフォーマンス低下や更新時のオーバーヘッドを持ち合わしているためインメモリ化はこれらを解消するというチューニングとしても期待できます。何も考えずにインメモリ化を行えば、インメモリ領域がすぐに枯渇するのは明らかです。そのため、インメモリ化は実装する前に事前にパフォーマンスが上がるか否かを検証し、ボトルネックになるテーブル、もしくは更新頻度は高いが多数のインデックスが存在するテーブルにのみインメモリ設定を行なう等の方針決めなどの必要性を感じました。