Oracleのインメモリはデュアル・フォーマットでローもカラムもメモリに
インメモリーデータベースはSAP HANAが先陣を切り、IBMがDB2 10.5でBLU Acceleration機能を提供してそれに追随、さらにMicrosoftがSQL Server 2014でHekatonと呼ばれていたメモリ最適化のOLTPエンジンを組み込んだ。
先行する各社の動きに対し、メジャーデータベースとしては最後に登場したのがOracle Database In-Memoryだ。このOracle Database In-Memoryの特長は3つある。まずは「デュアル・フォーマット・データベース」というアーキテクチャを採用したこと。これはロー型、カラム型の2つのフォーマットでメモリ内にデータを保持するもので、これによりメモリ上でOLTPとデータウェアハウスなどの分析系処理両方の高速化を同時に実現したのだ。ちなみに、SAP HANAもいったんロー型でデータを受け取り最終的にカラム型でインメモリにデータを持つ構造となっており、メモリー上にローもカラムもあるという意味ではOracleのデュアル・フォーマットと似ている。
もう1つの特長が、インメモリ機能を導入するのにほとんど手間がいらないこと。ある意味「スイッチをOnするだけです」と言うのは、日本オラクル データベース事業統括 製品戦略統括本部 プロダクトマーケティング本部 Cloud & Big Data推進部 部長の佐藤裕之氏だ。インメモリ機能で利用するメモリサイズとカラム型でインメモリに載せる対象を指定するだけでいい。Oracle Database In-Memoryは、すべてのデータをメモリに載せる必要はない。メモリは多いに越したことはないが、それなりの容量でも対象を絞り込むことで高速化できる。
3つ目の特長は既存のOracle Databaseのさまざまな機能が、インメモリ機能を有効にしてもそのまま活用できることだ。インメモリ化しても、アプリケーションなどからはいままでどおりのOracle Databaseと何ら変わりないものに見える。可用性、拡張性が欲しければ従来と同様Real Application Clustersの構成をとればいい。その他のセキュリティ機能なども、インメモリ化してもそのまま利用できる。バックアップなども同様であり、運用管理手順を特に変更する必要はない。
2つのフォーマットをメモリ上に持つための工夫
ロー型のインメモリの部分は、従来Oracle Databaseが利用してきたバッファキャッシュそのものだ。「それにプラスアルファで、カラム型のフォーマットをメモリ上に持つようにしました」と佐藤氏。ロー型、カラム型を同時にメモリー上に持つことで、OLTPだけでなく検索や分析の処理も高速化する。
つまりOracle Database In-Memoryでは、メモリ上にはローとカラムで重複したデータを持つ。双方でデータの不整合が起こらないよう、データは自動的に同期をとる。インメモリ上のロー型、カラム型のどちらにアクセスするかは、ユーザーやアプリケーションが意識する必要はない。「オプティマイザが判断し、自動で切り替わります」とのことだ。
オプティマイザの機能でロー型、カラム型でデータの読み込みが透過的にできることは理解しやすい。一方、データの更新はどのような処理になるのだろうか。
「基本的には既存のOracle Databaseと同じです。カラム型と同期をとるためにメモリ内にジャーナルと呼ばれる更新のログ領域を持っていて、それを利用しロー型からカラム型にデータをコピーします。検索時には、カラムとジャーナルの両方を参照し値を返します。これにより、仮にカラムのデータがまだ同期されていなくても、ジャーナルから最新の値を返すことができます」（佐藤氏）
ジャーナルに溜まるデータが閾値に達すると、最新のデータがディスクからカラムに同期される。現時点のIn-Memoryではメモリ上にあるジャーナルのデータをマージするわけではなくディスクを介して同期する。
表領域、パーティション、カラム、マテリアライズドビューなどを選択し、メモリ上に載せる対象のデータを指定できる。どのくらいのメモリ空間を確保すればいいかは、「In-Memory Advisor」を利用することで事前に調べることが可能だ。カラム領域へのデータのロードは、データベースの起動時か最初のクエリーが発生した際にデータがないときに行われる。データには優先順位が付けられ、高いものが優先される。
Oracle Database In-Memoryは、たんにカラム型のデータをメモリ上に持つから高速になるだけではない。メモリ上での処理を高速化する工夫も当然行っている。その1つが1命令で複数データを扱う処理方式であるSIMD（Single Instruction/Multiple Data）の有効活用だ。「SIMDを活用することでコア当たり1秒間に数10億行の処理が可能になります。コアを増やせばこの並列処理はさらにスケールします」と佐藤氏。さらにメモリ上でのJoin処理も内部的には最適化されており、集計やレポーティングなどの処理高速化に寄与している。
このように、カラム型のデータをメモリ上に追加することで検索や分析処理が速くなることは、Oracle Databaseのエンジニアであれば容易に理解できるだろう。では、基本的にはいままでの構造と変わらないバッファキャッシュの仕組みであるOLTP処理はなぜ速くなるのだろうか。その理由が検索や分析が十分に速くなるので、ほとんど検索や分析にしか利用しないインデックスがいらなくなる。それにより、インデックスの再構成なども当然無くなり更新処理が大幅に速くなるという。
「インデックスのメンテナンスコストは無くなります。さらに、チューニングのジレンマも無くなる。インデックスがいらなくなることが最大のチューニング効果です」（佐藤氏）
