インメモリデータベース（インメモリDB）「SAP HANA」が登場したのは2010年。それを契機に、データベースのインメモリ化を巡る開発競争が過熱した。すでにIBM、オラクル、マイクロソフトなどの主要なデータベースは、インメモリDB機能のサポートを済ませ、「各社横一線」の状況をつくり出している。だが、インメモリDBに対する各社の戦略やスタンスには差異があり、インメモリDB市場の全容を捉えるのは意外と難しい。ここでは、インメモリDBの背後で渦巻く主要ベンダーの狙いや思惑を追いながら、インメモリDBで、「何がどう変わるのか」を改めて考察する。（取材・文／福田悦朋）

●動き始めた壮大な野望

　インメモリDBを巡るデータベース・ベンダー間の攻防がさまざまに展開されているが、その火付け役を演じたのが、SAP HANAだ。

　HANAは、インメモリで動作する「カラム型」（囲み記事『カラム型とロー型』参照）のデータベースとして、2010年に登場した。当初、HANAは、データ集計・分析といった参照系の用途に特化したデータベースにすぎず、周囲も、「ビジネスインテリジェンス（BI）の市場をターゲットにした、特殊用途のデータベース・エンジン」として、HANAを捉えていた。ところが、SAPの戦略はもっと壮大だった。

　SAPは、「Run Simple（ラン・シンプル＝企業ITのシンプル化）」のコンセプトの下、エンタープライズERP市場を席巻する自社のアプリケーション製品群（ビジネス・スイート製品群）も含め、あらゆるアプリケーションのデータベースをHANAに集約する構想を練っていた。この構想にもとづき、SAPは、HANAの強化を推し進め、12年にリリースした「HANA SP5」で、（単一のカラム型データフォーマットを通じて）参照系の「OLAP：オンライン分析処理）と、更新系の「OLTP（オンライントランザクション処理）」の双方をサポート。今年2月には、HANAベースのビジネス・スイート「S/4HANA」のラウンチを発表し、S/4HANAの第一弾製品として、ファイナンシャル（財務・会計）系とロジスティック（物流）系のERP製品をHANAベースでリリースした。今後、他のSAPアプリケーションについても、HANAへの移植が順次行われ、すべてがHANAベースに切り替わる。つまり、エンタープライズERPの市場で高いシェアをもつSAPアプリケーションがHANAでしか動かなくなるというわけだ。

　さらに、SAPは現在、HANAのデータベース機能と、検索機能や各種の分析ツール/ライブラリ、そして主要データベースとの連携機能を一体化させた「HANA Platform」を構成し、このプラットフォームを中心に、企業内のデータベース・アプリケーションやデータベースをすべて集約していく方向性を鮮明に打ち出している。

●各社各様のアプローチ

　いうまでもなく、エンタープライズDBの市場で確固たる地歩を築いてきたオラクル、マイクロソフト、IBMの3社はいずれも、SAPのようにインメモリDBですべてのデータベースを集約しようとは考えていない。インメモリDBは、あくまでも従来データベースの延長線上にある拡張機能であり、図1に示したようなデータベースを巡るユーザーの課題を解決する一手段、あるいは、データ分析やOLTPの高速化ニーズに対応するための一手段に過ぎないというのが、3社の基本的な考え方だ。そのため各社の差異化の大きなポイントも、従来データベースのユーザー（あるいは、従来データベースを扱ってきたSIer）が、いかに簡単、かつスムーズに「インメモリDBによる高速化が図れるか」に置かれている。


　もっとも、SAPの対抗勢力であるオラクルとマイクロソフト、IBMの間でも、インメモリDBに対するアプローチは異なる。

　例えば、マイクロソフトのデータベース「SQL Server 2014」には、メモリ上で動作するカラム型ストア（以下、開発コード名の「xVelocity」で呼ぶ）と、インメモリのOLTP高速化エンジン（以下、開発コード名の「Hekaton」で呼ぶ）が実装されている。これにより、データを高速に取り込みながら、取り込んだデータをカラム型ストアにコンバートし、リアルタイムに分析することが可能になるという。

　また、OLTPの場合、データの永続性の確保がより厳格に求められ、インメモリDBであっても、実データやトランザクション・ログをディスクに書き込み、障害時のデータ・バックアップ/リカバリを可能にしておかなければならない。そのため、SQL Server 2014は、システム負荷が低いときに一気にデータをディスクに書き込むメカニズムを実装し、ディスクI/Oによるパフォーマンスの劣化を抑えている。

　対するオラクルとIBMは、基本的にインメモリDBを集計・分析処理の高速化エンジンとして位置づけており、為替のフロント業務や通信機器の制御に適用されるような「超高速OLTP」を実現するための技術を、インメモリDBの機能とはまた別の仕組み（オラクルは「TimesTen」、IBMは「eXtreme Scale」）として提供している。これらは、アプリケーション・レイヤ（ないしは、アプリケーション・サーバー・レイヤ）でOLTP処理をインメモリで完結させる製品だ。なお、IBMは2013年に「BLUアクセラレーション」（以下、BLU）と呼ばれるインメモリDBの技術を組み込んだ「DB2 10.5」をリリースしている。

　DB2 10.5 BLUアクセラレーション（以下、BLU）は、メモリ上で動作するカラム型ストアで、大きな特色は「ダイナミック・インメモリ」のサポートにある。この機能により、BLUでは、ディスク上のデータベースから使用頻度の高いデータをメモリ上のカラム型ストアに随時展開する。これによって、データベースを“丸ごと”インメモリ化するのに比べて、コンパクトで、かつ実効性の高いインメモリDB環境が構築できる。

　一方、オラクルは昨年7月から「Oracle Database 12c」の拡張機能として、インメモリオプションの出荷を開始した。このインメモリ機能では、単一のデータ・フォーマット（ロー型）から、ロー型とカラム型の2タイプのフォーマットを動的に生成し、メモリ上に展開。クエリ内容に応じて自動的にロー型/カラム型のテーブルに処理を振り分けるメカニズムが実装されている。メモリ上のロー型とカラム型のテーブル間ではデータ同期がとられるため、ユーザーは常に最新のデータをもとに検索や分析の処理を行うことができる。この仕組みは、ロー型のインメモリ化を実現するものともいえるが、Oracle DatabaseのOLTP性能を高めるためのものではなく、カラム型のインメモリ化で、Oracle Databaseの分析・集計の処理性能をアップさせるものであるという。

●性能よりも付加価値の争いに

　インメモリDBの使い手側にとっては、インメモリDBで何がどれほど速くなるかも気になるポイントだろう。前出の図1のデータ提供元であるITRでは、図1と同じ調査のなかで、「インメモリDBによる高速化の期待値」について、企業のデータベース・ユーザー/技術者にたずねている。結果は、図2のとおりで、性能向上の期待値として、「2倍～100倍」のレンジに回答が集中している。


　インメモリDBの適用領域にもよるだろうが、各ベンダーが公表している数値や事例をみると、ユーザーの期待値と同等の性能向上は見込めそうだ。

　例えば、米国大手小売のウォルマートでは、業務システムから1時間に2000万件規模のデータ更新（インサート）がある32TBサイズのインメモリDB（過去3年分のPOSデータ/2000億件超のファクトテーブル）をHANA Platformで構築。結果、1500人のデータ・アナリストが発行したクエリの94％の結果が2秒以内で返される環境が実現された。また、SBIグループ傘下のSBIリクイディティ・マーケットでは、為替の金融カバー取引用の集計・分析エンジンとして、SQL Server 2016のインメモリ機能を採用した。これによって、1日1回が限度だったデータ集計・分析が、ほぼリアルタイムで処理できるようになり、全体のスループットは従来の30倍に跳ね上がったという。

　さらに、こうした性能向上・高速性は、インメモリDBに共通して期待できるものでもある。少なくとも、SAP、オラクル、マイクロソフト、IBM各社は、主要なインメモリDB（あるいは、主要データベースのインメモリ機能）の性能に、大きな開きがないことを示唆している。インメモリDBの戦いは、使い手側に何を提供するかの付加価値の競争に突入しているといえるのかもしれない。

[次のページ]