実装のひと工夫で高速化する技術：Database Watch（2014年5月版）（1/3 ページ）

　近年よく聞く「列指向」データベース。集計処理など必要な列のデータだけがほしいときには有利とされています。さらにひと工夫を加えたデータ構造を持つ製品も出てきています。

IRS V3.1では時系列の範囲検索にデータ構造を最適化

　NECの「InfoFrame Relational Store」（以下IRS）は着々と進化を遂げてきています。IRSはRDBが持つSQLインターフェースやトランザクション性能を持ちつつ、KVSが持つスケールアウト性能も持ち合わせた「いいところどり」の製品です。NECによると「SQLでアクセスできるNoSQL」という位置付けです。

　NEC システムソフトウェア事業部 シニアマネージャ 白石雅己氏（写真）は「昨年（2013年）の前半あたりは、まだ物珍しさからの関心が多かったのですが、その秋ごろには徐々に実案件が増えてきています。具体的な導入フェイズに移行しているお客さまが増えてきています」と手応えを感じているようです。

　前回（2013年10月号）で取り上げたころがちょうど転換期だったのかもしれません。当時はまだV2.1でAWSに対応開始したところでした。ちょうど先月（2014年4月）にはV3.1をリリースしています。

　余談ですがベンチャービジネスに詳しい人がかつて「ソフトウェアはバージョン3になると、ようやくビジネスとして花開くようになる」と話していたのを聞いたことがあります。Windowsや一太郎もこの法則に当てはまるそうです。そう考えると、IRSはこれから勢いがついてくるのかもしれません。

世の中の多くの事象は時系列で分析できる

　V3.1の強化点は検索性能です。実際の顧客の利用事例では、時系列データを扱うことが多く、検索するときは製品などの「ID」や「期間」でデータを抽出することがほとんどだそうです。

　例えば製品型番と製造日をキーに品質データを参照する、あるいはカード番号とバーゲン期間の売上データを参照するなどといった時に参照するのは時系列データです。この例はいずれも「時系列データから条件と範囲を指定して検索」という操作です。

　一方、IRSはスケールアウトのためにデータを“分散配置”できるKVSです。範囲検索を実行するとなると、複数サーバーにアクセスすることになるため、オーバーヘッドが発生します。しかし、このオーバーヘッドをなくすためにデータを時系列でまとめると、データサイズを大きくしてしまい、パフォーマンスに影響を与えます。

「レンジクラスタ」

　そこでNECは時系列データの範囲検索に有利となるようなデータ構造を考案しました。それが「レンジクラスタ」です。時系列やIDなど、検索に使いそうな値でまとめてデータを格納する構造を採りました。巨大化するデータを一定のサイズでまとめてツリー構造のような形で保有するイメージです（ツリー構造といっても1件ずつツリー構造を持つようなXMLとは違います）。これにより、I/Oの効率化が進みます。

レンジクラスタの構造概念図（資料提供：NEC）

　実際に前のバージョンが採用しているデータ構造とV3.1以降で利用できる「レンジクラスタ」のデータ構造で比較すると、検索が時系列データからの範囲検索なら顕著にアクセスが早くなるそうです。なお、新たに実装されたものなので、既存ユーザーが以前のデータ構造で利用している場合は、データをテーブルに入れ直す必要がありますが、データ移行自体はそう難しい処理ではないとのことです。

　他にもV3.1では、アプリケーションインターフェースの拡充やセキュリティ機能の強化が見られます。これまでインターフェースとしては基本的にJavaのODBCドライバでしたが、C言語用ODBCドライバ、COBOL専用ドライバが追加されています。

　また、V3.1ではセキュリティ機能も強化しています。顧客からは監査証跡や不正アクセス検知への要望が高かったことから、IBM InfoSphere Guardiumとの連携を実現させています、Guardiumユーザーであれば透過的に管理できます。