京ぽんに採用されたインメモリDB「ENCIRQ DFF」：組み込みデータベースカタログ（3）（1/3 ページ）

ストリームベースという考え方

　エンサークが米国で設立されたのは1998年。もともとはPDAを使った情報配信サービスを行う企業だった。そのサービスは、例えば株価を常時ウオッチし、ある閾値に入るとほかの情報と併せて表示するといったものだった。しかし、2001年ごろ米国でもバブルが崩壊すると、情報配信サービス用に開発したツールを組み込み向けに提供する方向に転じた。それが、現在DFFとして販売している組み込み向けデータベースを核としたフレームワークである。

ストリームベースのインメモリDB

　DFFには、「PDAを利用した情報配信」という生い立ちに起因する特徴が2つある。1つは小フットプリントである。DFFで構築されたアプリケーションの中で、データベースとライブラリ（ENCIRQ Service Library）が占めるフットプリントは24kbytesにすぎない。PDA（当初はPalm）で動かすために追求された省スペース性は、現在も継承されている。また、すべてのデータをメモリ中に格納して動作する「インメモリ」という形態を取るため、動作に要するオーバーヘッドは最小に抑えられる。インメモリであるが故に、データベースアクセスは同一プロセス内でのAPIコールとなる。つまり、Socketなどを介して複数のプロセスからアクセスする使い方は、想定されていない。こうした構成が必要なら、データベースアクセスを行うプロセスとほかのアプリケーションのプロセス間でプロセス間通信を行うことになる。

　もう1つの特徴が、「ストリームベース」である。例えば、株価情報は常時変動するものであり、ネットワークなどを介してストリーム的に入力されてくる。従来のデータベースの場合、これをいったんアプリケーションに取り込んでデータベースに（適当な単位で）INSERTを行い、その後INSERTしたレコードに対してSELECTなどを掛けるという手順になる。これに対し、DFFは入力ストリーム（例えば株価情報）に対して直接SELECTを掛けられるという、ほかに類を見ない機能を持っている。もちろん通常のデータベース同様、レコードに対するSELECTも行える。このように、レコードとストリームを等価に扱えるのがDFFの大きな特徴である（図1）。

図1　ストリームベースのアーキテクチャ

ログなしでトランザクションを実現

　その一方、思い切った割り切りもある。例えば同社の「7つの確信的な主張」を見ると、ロールバックやエラーリカバリといったトランザクションには対応しているが、トランザクションログは持っていないのである。「そもそも組み込み向けのデータベースでトランザクションログをため込むのは現実的とはいえません」（吉原氏）という認識によるものだが、ではログなしでどうやってトランザクションを実現しているのだろうか？

　答えは、完全な同期処理である。DFFはインメモリDBであり、例えばUPDATEを行うとその結果はメモリ内に反映される。ここでCOMMITを発行すると、通常なら関連するデータを非同期でライトバックする（これが失敗したときのためにトランザクションログを生成する）わけだが、DFFは同期処理でこれをカバーする。つまりCOMMITを発行すると、全データを書き出し終わるまで返ってこないのである。確かにこの仕組みならば、トランザクションログは原則不要である。ただし複雑なトランザクションをまとめてCOMMITするとレスポンスが悪化するので、小まめなCOMMITをアプリケーション側で行うことが必須である。これは、組み込み用途であれば許容される制限と見なしている。

　ちなみに、アプリケーションの要件としてトランザクションログが必要になった場合でも、「ログを取るように改造するのは非常に簡単です。printfに似たものを仕込んだINSERTを発行するだけです」（吉原氏）とのこと。

　インメモリDBという特徴に関連するのが、環境依存性の低さである。図1のとおり、DFFのDBエンジン（ストリームエンジン）は基本的にストリームを扱うようにできており、ローカルストレージ（例えばHDDやフラッシュメモリなど）のデータはアダプタを介する形でストリームエンジンに取り込まれる。この結果、ストリームエンジンそのものはCPUやOSあるいはハードウェアに対する依存度が極めて小さい。

　例えばファイルシステムはOSやハードウェア依存の部分が多くなるが、これはアダプタを用意することで解決できる。つまり、移植に際しての作業は、アダプタの対応作業だけで済むことになる。これにより、対応する環境を大幅に増やすことが可能になっている。同社サイトのターゲットプラットフォームを見ると、「SH-Mobile-1」や「Micro-ITRON」（μITRON）など、日本でしか採用事例のないプラットフォームもある。それだけでなく、基本的にはどのようなプラットフォームにも対応できるという。「『何でもできます』と書いても信じてもらえないので一応対応プラットフォームを書いてありますが、実質は何でも行います」（吉原氏）。新規プラットフォームへのポーティング作業には2〜3週間の期間を取っているが、そのほとんどはテスト用の時間である。ポーティング作業自体はリコンパイルだけで終わる場合も珍しくないらしい。また、リファレンスボードなどを使わず、エンドユーザーが作成したカスタムボードにも簡単に移植できるという。