前回はOracle Database In-Memoryの仕組みを図解で解説しました。今回は実際にテーブルをインメモリ化して、検索処理の性能を測ってみます。Oracle Databaseにインメモリ＋カラム型の技術が加わると、性能はどの程度向上するのでしょうか？
テーブルをポピュレーションする
前回のおさらいになりますが、Oracle Database In-Memoryには以下の特徴があります。分かりやすく表現すると、「Oracle Databaseにカラム型のメモリ領域（インメモリ・カラムストア）を追加したもの」がOracle Database In-Memoryです。
Oracle Database In-Memoryの特徴
- メモリ上にロー型とカラム型のフォーマットを同時に保持する
- OLTPとDWH処理の両方を高速化する
- 更新処理では従来通りデータベース・バッファ・キャッシュ（ロー型）を使う
- 検索処理では新しく実装されたインメモリ・カラムストア（カラム型）を使う
- 両者の使い分けはオプティマイザが自動的に判断してくれるため、SQLの書き換えは不要
今回は、カラム型が得意とする検索処理を実行した時の性能を測っていきます。使用するハードウェアおよびOracle Databaseのパラメータは以下のとおりです。検証データはStar Schema Benchmark（※）を使って生成しており、テーブルのサイズは約70GB、レコード数は約6億です。
| CPU | Intel Xeon E5-2640 2CPU16コア |
| メモリ | 128GB |
| OS | Oracle Enterprise Linux 6.4 |
| Oracle Database | 12.1.0.2.0 シングル構成 |
| 初期化パラメータ |
sga_target = 110g inmemory_size= 100g inmemory_max_populate_servers = 8 |
※Star Schema Benchmarkの詳細についてはこちらをご参照ください。
まずは、各テーブルをインメモリ・カラムストアに読み込みます。この動作は「ポピュレーション」と呼ばれ、メモリに読み込む際にカラム型への変換や圧縮が行われます。ポピュレーションを行うには、テーブルに対してALTER文でINMEMORY属性を指定します。今回は優先度をCRITICAL、圧縮レベルをFOR QUERY LOWとします。
SQL> ALTER TABLE lineorder INMEMORY MEMCOMPRESS FOR QUERY LOW PRIORITY CRITICAL;
優先度をNONE以外に設定した場合、バックグラウンド・プロセスが2分間隔でポピュレーションのタスクを実行してくれます。OS上からは「ora_wNNN_<SID>」というワーカー・プロセスがポピュレーションを行っている様子が確認できます。
ポピュレーションはそれなりに負荷のかかる処理で、ディスクからデータを読み込むためのI/Oはもちろんのこと、圧縮のためにCPUのリソースを多く使用します。高負荷になるのが心配だという場合は、初期化パラメータのinmemory_max_populate_serversでワーカー・プロセスの数を変更することができます。
OS上からワーカー・プロセスが消えたら、ポピュレーションは完了です。今回は約70GBのテーブルをポピュレーションするのに4分かかりました。ポピュレーションの進捗やステータスは「V$IM」で始まるディクショナリ・ビューから参照できます。
この記事は参考になりましたか？
- 既存の概念を覆す！Oracle Database In-Memoryのテクノロジー連載記事一覧
- この記事の著者
-
関 俊洋（セキ トシヒロ）
株式会社アシスト データベース技術本部 データベース・エバンジェリストデータベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やソリューションの立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆や講演活動を行っている。
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
