カーナビに最適な空間検索を装備した「Entier」組み込みデータベースカタログ(4)(3/3 ページ)

» 2006年06月23日 00時00分 公開
[大原 雄介,@IT MONOist]
前のページへ 1|2|3       

Entierの内部アーキテクチャ

パックフェッチ

 フェッチ、つまりデータベースからSELECTした結果を取り込む作業を考えてみる。通常、プログラムが動くプロセス内部に、動的にバッファ(フェッチ・バッファ)を確保し、データベースから1行ずつ取り込んでプログラムに渡す、というのが一般的な構造である。

 ところで、行のサイズが極端に小さい(図4)場合、メモリの無駄は少ないが、1行単位でデータベースから取り込んでプログラムに渡すという作業は、非常に無駄が多い。


図4

 一方、1行のサイズが極端に大きい(図5)場合、動的に大きなサイズのフェッチ・バッファが取られることになる。組み込み環境ではそれほど大きなマージンがないのが常であり、動的に大量のバッファが確保されるとシステム全体の動作に影響を及ぼす。これが問題になりやすいのは行のサイズに合わせてフェッチ・バッファのサイズが変動することで、特に可変長データを扱う場合に顕著となる。だからといって、想定される最大サイズに合わせてフェッチ・バッファ用のヒープを確保しておくのは、無駄が大き過ぎる。

図5

 こうした問題に対する効果的な対処法がパックフェッチである。要するに、フェッチ・バッファのサイズをあらかじめ固定で決めておき、以下の処理を行う。

  • フェッチ・バッファのサイズ > 行サイズの場合

 フェッチ・バッファがいっぱいになるまで複数行をまとめて取得し、ここからプログラムに1行ずつ渡す。データベースを毎回アクセスせずに済むので、オーバーへッド削減が可能になる(図6)。

図6
  • フェッチ・バッファのサイズ < 行サイズの場合

 1行を分割してフェッチ・バッファに格納できるようにする。従って、プログラムは複数回フェッチを呼び出して行を取得する。これにより、ヒープが逼迫することが避けられる(図7)。

図7

インデックス・プリフィックス圧縮

 例として、電話帳のデータベース化を考えてみよう。電話番号をキーとしたインデックスを作成すると、市外局番など同じ数字が延々と並ぶことになる。であれば、共通のキーを抜き出して差分だけを格納すれば、インデックスのサイズを小さく保てるという仕組みがインデックス・プリフィックス圧縮だ。共通キーのくくり出しは、ページ単位で行うことになっている。デフォルトのページサイズは4kbytesだが、これはデータベースの構成時に変更可能だ。

 どのようなインデックスでも適用できるというわけではない(現時点では前方一致のみサポート)し、インデックス値のフラグメントの度合いで効果が変わってくるため万能とはいえない。とはいえ、性能のペナルティは非常に小さく、リソース節約へのインパクトは大きいといえる。

電源断対応

 これは、エラーリカバリに関する話である。電源の瞬断あるいは長期間の電源断が不意に発生した場合でも、当然データを保護する必要がある。データベースでは通常、これをトランザクションで管理するが、トランザクションといっても実態はログをファイルシステムに書き出すだけの話である。従って、ファイルシステムがダウンしてしまえばトランザクションもできないことになる。つまり、データベースのレイヤだけで電源断対応を行っても意味がないので、ファイルシステムのレイヤも同様に電源断対応を行う必要がある、というのがEntierの思想である。

 これに従い、Entierは独自のファイルシステム(FAT32互換)を提供する。このファイルシステムは管理部を二重に持つなど、障害対策を強化したものである。これに加えてDBのレイヤでもジャーナリングを施すことでトランザクションを保証している。

開発プロセス

 Entierは、前述のとおりライブラリ形式でアプリケーションに組み込まれる。SQLの与え方は、バッファにSQL命令を普通に格納し、そのまま渡すというコンサバティブなものである。つまり、Entierを呼び出すたびに構文解析ロジックが動き、パースした結果を実行する。OracleのPL/SQLのように、ソース中にSQL文を埋め込み、プリプロセッサを介してそれをプログラムとSQL命令に分離するといった使い方はしないそうだ。毎回構文解析をするのはちょっとオーバーヘッドが大きいようにも思えるが、「前処理時に利用する表の定義情報をメモリに持つことでオーバーヘッドを最小限に抑えており、性能面では良い評価を得ている」(関氏)ということで、特にここの変更は考えていないようだ。実際、空間検索などを多用するケースでは、埋め込みSQLやストアド・プロシージャなどはむしろプログラミングが面倒かもしれない。

 開発プロセスを語る際に忘れてはいけないのが、サポートやコンサルテーションである。データベース製品を長く提供してきたベンダらしく、必要なものがすべてそろっている。電話やメールでの質疑応答、オンサイトなどは標準的なサポートサービスとして用意され、個別対応でコンサルテーションや教育、あるいはデータ設計やチューニングなども行うという。このサポートサービスは、同社のHiRDBとは別に用意されたEntier専用チームが基本的に対応するという。

バージョン2も今年度中に登場

 取材中、「データベースを使うことで開発効率が向上し、品質向上やリードタイム短縮が実現できる」という言葉が頻繁に出てきた。これはEntierに限った話ではないが、「それが売り文句になるほど、組み込みの世界ではまだまだデータベースが使われていない」というのが日立製作所の見方である。実際、他社の競合製品について伺ったところ「他社製品からの乗り換えを迫るより、新しいお客さんを見つける方が早い」という答えが返ってきた。まずはパイを広げるのが先決ということで、対応するハードウェアは間口を広く取るとしている。「OSがサポートしていれば、基本的にはどのようなハードウェアでも動きます。ハードウェア依存の部分がある場合は、柔軟に対応します」(関氏)。OSについても、サポート済みのOS以外でも要望があれば対応するとしている。

 現在のEntierはVersion 1だが、今年度中(2007年3月まで)にはマルチタスク対応と全文検索機能を追加したVersion 2のリリースを予定している。カーナビや携帯などで高機能化が進んだ結果、複数プロセスから同一のデータベースにアクセスしたいという要望が多いとのことで、この辺りの対応を進めているという。


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.