先ほども触れましたが、組み込みシステムではサービスや機器ごとに特化した個別の要件が多くあります。そのため、組み込みデータベースへの要件も多岐に渡ります(表1)。
表1 組み込みデータベースへの要件
分類 | 要件 | 優先度 | コメント |
---|---|---|---|
運用性 | ゼロアドミニストレーション |
◎
|
・組み込みデータベースとして必須の機能 |
性能 | 高レスポンス |
◎
|
・製品の特徴を考慮する必要がある(環境、要件によって得意不得意がある) |
高スループット |
○
|
大型システムへの組み込み(サーバへの組み込み)には重要 | |
省リソース | 小フットプリント |
◎
|
・環境、要件によって異なるが、だいたい数M~数100Kバイト ・機能を選択可能なアークテクチャにすることにより、フットプリントを調節できるのが望ましい |
小ランタイムメモリ |
◎
|
・一般にDLLで提供されるものが多い(概ね1M以下で動作) ・機能によっては、メモリ消費量を調節できることが望ましい |
|
リソース再利用 |
◎
|
・削除されたレコードのファイル、メモリ領域の再利用 | |
信頼性 | 電源瞬断対応 |
◎
|
・ファイル・システムとの組み合わせで実現されることが多い |
レプリケーション |
△
|
・高信頼性システムへの組み込み(サーバ組み込み)には重要 | |
標準データベース機能 | ACID(トランザクション) |
○
|
・組み込みシステムでは、アプリケーションに任せる場合もある ・ファイルシステムとの差別化 |
マルチプロセス/マルチスレッド対応 |
△
|
・組み込みシステムでは、アプリケーションに任せる場合が多い ・性能、リソース消費量とのトレードオフを考慮する必要あり |
|
標準(ANSI)SQL |
○
|
・複雑な検索機能の開発等を考慮すると望ましい ・性能、リソース消費量とのトレードオフを考慮する必要あり |
|
標準API(ODBC/JDBC) |
○
|
・DBアプリケーション開発者を考慮すると望ましい ・性能、リソース消費量とのトレードオフを考慮する必要あり |
|
セキュリティ | データの暗号化 |
△
|
・ほかのソリューションで補完する場合が多い ・性能とのトレードオフを考慮する必要あり |
アクセス認証 |
○
|
・ファイルシステムとの差別化 | |
通信の暗号化 |
△
|
・ほかのソリューションで補完する場合が多い | |
ユーザ権限 |
△
|
・そもそもマルチユーザ環境が少ない ・大型システムへの組み込み(サーバへの組み込み)には重要 |
|
ポータビリティ | マルチプラットフォーム |
◎
|
・組み込みデータベースの重要な特徴 |
ポーティングキット |
○
|
・組み込みシステムは、個別要件が多いため、ビジネス・モデルとして考慮する必要あり (バイナリ提供のみでは対応困難) |
これらの中でも組み込みデータベースにとって特に重要な要件として、次の5つが挙げられます。
運用環境を考慮
組み込みシステムの運用環境を考慮すると、長期無人運転を前提とした自動起動、終了、復旧、最適化や容易なインストール、アップグレードが可能なゼロアドミニストレーション機能は必須です。
高い性能
厳しいリソースの制約の中で、高性能(特に高レスポンス)を実現する必要があります。環境依存の要素が大きいため目標値を明確に数値化することはできませんが、一般に数百万オーダの検索で数10msレベルのレスポンスタイムが必要となると考えられます。
リソースに制約がある
機能とのトレードオフになりますが、厳しいリソース制約に対応するため、できるだけフットプリントやランタイムのメモリ消費量を小さくすることが重要になります。また、単にリソース消費量を削減するだけでなく、設定などにより消費量をできるだけ正確に制御できることが望ましいと考えられます。
高い信頼性
コンシューマ向け機器の場合、電源の瞬断への対応が重要になります。具体的には、電源の瞬断が発生してもデータやデータベースが破壊されることなく、電源が復旧した時には整合性を保ちながら速やかに自動復旧する仕組みが必要があります。
高いポータビリティ
組み込みシステムの多種多様なプラットフォームに対応するためには、ポータビリティの高いアーキテクチャが必要となります。具体的には、環境に依存しないコアのアクセスロジック、ストレージエンジン、インタフェースなどのレイヤと、環境に依存するCPU、OSなどのレイヤが分離したアークテクチャであることが望ましいでしょう。
上記以外に考慮すべき要件としては、標準データベース機能、とくに標準(ANSI)SQLのサポートがあります。標準SQLをサポートしていれば、複雑なデータ処理を比較的簡単に実現することができます。しかし、SQLの処理自体が多くのリソースや処理時間を必要とするため、レスポンスタイムやリソースの制約がクリティカルな環境では、大きなオーバヘッドになる可能性があります。従って、すべての環境においてSQLを使用できるようにするのは難しいかもしれません。