データベース統合エンジン

アプリ
ケーション
データベース統合エンジン
DB 統合
エンジン
ローカル
クライアント
クエリ最適化
DB 統合エンジン
サーバ
スマートコミュニティでは，個別に構築された複数の
システムが管理するデータを横断的に活用する必要があ
ります。しかし，個々のシステムでは互いに異なるデータ
SQL 関数
DB 統合エンジン
複数の DB の
問合せ結果
を結合
異なるデータベースの
横断的な検索を容易に実現
アプリケーション
アプリケーション
DB
ドライバ
各 DB への検索要求を最適化し，
DB 統合エンジン内の検索結果
マージ処理を高速化
仮想 DB
ドライバを開発することで，
統合できる DB を追加可能
NoSQL 型 DB
用
ドライバ
用
ドライバ
RDBMS
SELECT
WHERE
②個々の DB への依頼に分割
DB 統合エンジン
SELECT
， FROM
WHERE
> 123
断検索が，DB 問合せ言語（SQL）の1文で簡単に実現
できるようになります。各 DB に対応するドライバが DB
間の差異を吸収することで，SQLの仕様の違いを感じさ
せない検索を実現しています。
なり，検索結果のデータ量が大きい場
DB
に
（
， ） 閉じる SQL 関数
NoSQL 型 DB
RDBMS
RDBMS
テーブル
5,360
時間を比較しました（図 3）。
家庭（HEMS）
ビル（BEMS）
交通インフラ
5,354
137.7
図1．DB 統合エンジンのモジュール構成 ̶ アプリケーションから受け付け
た SQLを解析して，各 DB への検索要求に分割します。そして，ドライバを
使って DB から結果を取得し，最終的に一つの検索結果を返します。
約 1.5 倍の高速化
120
⑶ 類似製品を使用
なるDB 上にあるテーブルを結合するも
80
60
のです。一方のテーブルには約7,000
40
20
0
⑵ 検索要求を最適化した DB 統合
実験に使用したSQL 文は，二つの異
94.29
100
RDBMS：Relational Database Management System
HEMS ：Home Energy Management System
BEMS ：Building Energy Management System
DB 統合エンジンを使用
エンジンを使用
160
時間（ms）
水道
⑴ 検 索要求を最 適化していない
DB
140
社会インフラクラウドシステム
性能評価
次の三つの実装方法に対して，実行
テーブル
図 2．DB への検索要求の例 ̶ DB 上で計 算できるSQL 関数や検索条件式がある場合，それを
含んだ SQL文をDB で実行します。
RDBMS
新エネルギー
， ）
④DB から結果を
取得
DB
アプリケーション
に組み込んで，
データ通信時間
を抑制
します。
に
閉じる条件式
用
ドライバ
各種
データベース
合にボトルネックとなる転送時間を削減
DB
RDBMS
ライブラリ版
DB を仮想的に一つの DBとみなして透過的にアクセス
この DB 統合エンジンにより，異なるDB に対する横
用ドライバ
SELECT
，（
FROM
DB 統合エンジン間の通信時間がなく
， ）
⑤DB をまたがる
条件式による
結合演算
用ドライバ
③条件式を DB への
問合せに含める
（
，
条件式
条件式
③SQL 関数を DB への
問合せに含める
ベース（DB）が使われています。そこで東芝は，異なる
できるようにする，DB 統合エンジンを開発しました。
，（ ， ）FROM
=
AND
>
①一つの SQL文を受け
付けて，SQL を解釈
行のレコードが格納されていて，その中
検索要求を最適化していない
DB 統合エンジンを使用
検索要求を最適化した
DB 統合エンジンを使用
類似製品
を使用
図 3．検索性能の比較 ̶ 約 7,000 行のテーブルと約 2,000 行のテーブルとを結合するSQL の実行に
要する時間を比較しました。その結果，検索要求の最適化により約 57倍の高速化を達成し，類似
製品と比べ約1.5 倍の高速で検索することができました。
から約70 行を選択します。もう一方の
テーブルには約 2,000 行のレコードが
格 納されていて，約 30 行を選 択しま
す。そして，それらを結合演算して最終
⑸ 全 DBから得た結果に対してDB
を介して DB にアクセスすることで，
を対象とする場合，対象データを取得
数の DBを横断したデータの検索演算
統合エンジン上で検索演算を実施
オーバヘッドによる性能劣化が予想さ
したうえで DB 統合エンジンが検索演
を，標準的な SQLの1文で簡単に実現
この中で，個々の DBに依 存した処
れます。性能のボトルネックは，データ
算を実行します。
スマートコミュニティでは，電気，ガ
できるようにすることを目的としていま
理である⑶と⑷をドライバとして独立さ
通信量及び DB 統合エンジン上での検
この最適化処理の結果として，可能
た。今回のように，条件式をDB 上で計
ス，交通など異なる分野の制御システ
す（図1）。DB 統合エンジンの課題とし
せることで，統合可能な DBを追加でき
索演算です。今回，これらの問題を解
なかぎり個々の DB 上でデータを絞り
算させることで DBからの検索結果を
ムが保有するデータを横断的に活用し
て，統合対象の DBを容易に増やせる
るようにしました。
決するために，DB への検索要求を最
込むことにより，DBとDB 統合エンジ
絞れたことが，性能を発揮できた要因
て，インフラの統合的な管理と最適制
拡張性と高速化がありました。
適化する処理技術を開発しました。
ン間のデータ転送量や DB 統合エンジ
と考えています。
DB 統合エンジンとは，このような複
異なるDB の横断的な
アクセスへの要求と課題
御を目指しています。しかし，個々のシ
ステムは異なるDBを使 用しているた
め，それらへの横断的なアクセスが必
要になります。
異なるDBを併用する場合，それぞれ
のSQLで個別に検索結果を取得し，そ
した技術について以下に述べます。
SQLの仕様の差を吸収するドライバ
DB 統合エンジンは，次の手順でSQL
文を実行します。
れらのデータに対して，結合，並べ替え，
⑴ SQL 文を解釈
及び集計などの検索演算をアプリケー
⑵ 個々の DB への検索内容を決定
ション側で行う必要があります。つまり
開発者は，個々のDBの仕組みや実装
56
これらの課題を解決するために開発
⑶ 検索内容からDB 独自の SQL 文
を生成
方法を学習したうえで，アプリケーショ
⑷ DB 独 自 のAPI（Application
ン上でDBの内部演算と同等の演算プ
Programming Interface）で DB
ログラムを実装しなければなりません。
へ問い合わせて結果を取得
SQLは表形式のデータに対する問
合せ言 語ですが，表計算ソフトウェア
SQL 文には，検索条件式や SQL 関
や，テキストデータ，非構造データなど
数という問合せ要素が含まれます。こ
でもデータを表とみなすことができれ
の問合せ要素をできるだけ DB 上で計
ば，ドライバを通じてそれらへアクセス
算させることで，高速化を図りました
できるようになります。現在，3 種類の
リレーショナル DBと1種類の NoSQL
型 DB（注1）をサポートしています。
（図 2）。
アプリケーションプロセスへの
組込みによる高速化
DB 統合エンジンとしては，構成形態
の高速で検索できることを確認しまし
今後の展望
DB 統合エンジン上での検索演算の
性能改善や，SQL 文の最適化により，
いっそうの高 速化を検 討しています。
そのために，問 合 せ要 素 が複 数の
の異なるクライアント／サーバ型とライ
更に，分散トランザクション機能（注 2）の
DB 上のデータを対 象とするか，ただ
ブラリ型を用意しています。アプリケー
導入やドライバの拡充を行い，適用範囲
の拡大を目指します。
一つの DB 上のデータだけを対象とす
ションに組み込めるライブラリ型は，更
るかを判定します。ただ一つの DB 上の
なる高速化が期待できます。
データが対象である場合，その問合せ
ライブラリ 型 で は，クライアント／
アプリケーションは，DB 統合エンジン
要素をデータが格納されているDB へ
サーバ型で発生するアプリケーションと
東芝レビュー Vol.68 No.9（2013）
その結果，類似製品と比べて約1.5 倍
ン上での演算が減ります。
DB への検索要求最適化による
高速化
（注1） 関係モデルに基づかずに構築された
DB の総称。
的に 6 行の結果を生成します。
の問合せとして，検索演算を対象 DBで
実行します。また，複数 DB 上のデータ
データベース統合エンジン
（注 2） DB をまたがるトランザクション管 理
機能。
片山 大河
ソフトウェア技術センター
先端ソフトウェア開発担当
57