組込みデータベース
組込みデータベース
他のデータベースやファイルシステムと比較し、Empressの優位点や他にはない特長をご紹介します。
SQLite | PostgreSQL | |||
---|---|---|---|---|
データベース 機能 |
ライブラリ 提供 |
○ | ○ | × |
データ量 | ○ 大量データも対応可能 |
△ 中・小規模に最適 |
○ 大量データも対応可能 |
|
断電復旧機能 | ○ | × | × | |
非断片化構造 | ○ | × | × | |
SDカードの 書き込み制限対応 |
○ | × | × | |
メンテナンス フリー |
○ | × 非断片化構造でないため バキュームが必要 |
× 非断片化構造でないため バキュームが必要 |
|
マルチ アクセス |
○ | × コネクション単位なので すべてシングルアクセス |
○ | |
負荷分散 | ○ | × ローカル接続以外方法が無い ので負荷分散出来ない |
○ | |
サポート | ○ | × | × | |
ドキュメント | ○ 日本語 |
△ ほぼ英語 |
○ 日本語 |
|
データタイプ | SQL データ タイプ |
○ ANSI92 準拠 |
△ Null/Integer/Real/Text /BLOBのみ |
○ ANSI92 準拠 |
ODBC データ タイプ |
○ ODBC準拠 |
△ Null/Integer/Real/Text /BLOBのみ |
○ ODBC準拠 |
|
API機能 | SQL サポート |
○ SQL92準拠 |
△ SQL92ほぼ準拠 一部サポート外 |
○ SQL92準拠 |
上位の互換性 | ○ | △ SQLite2とSQLite3は 互換性がない |
× 互換性がない | |
セキュリティ | 暗号化 | ○ | × サードパーティによる ファイルの暗号化 |
× サードパーティによる ファイルの暗号化 |
高可用性 | レプリ ケーション |
○ | × | ○ 9系のバージョン以降から |
外部接続 | ODBC サポート |
○ | × | ○ |
JDBC サポート |
○ | × | ○ | |
PHP サポート |
○ | ○ | ○ |
EmpressとSQLite / PostgreSQLの一番の差は有償であるか否かです。Empressは商用データベースで有償です。
そのため、日本語のマニュアル、日本語での技術サポート、上位と下位バージョン互換性が保証されています。これに対して、SQLiteは上位と
下位バージョン互換性の保証はなく、サポートもなく、ドキュメントもほぼ英語です。
また、PostgreSQLは下位との互換性が良くないため、アプリケーションレベルでの改修が必要だと言われています。
機能的な違いは、SQLiteは、1コネクト単位のシングルアクセスのローカルデータベースであるのに対して、
Empressは、ライブラリで提供される組込みデータベースでありながら、ローカルデータベースでの無制限のマルチアクセス、外部デバイスからの無制限のマルチアクセス機能を有しています。
結果として、SQLiteはソフトウェアでは良く使用されますが、通信、FAでは使用された実例はあまり聞きません。
これに対し、Empressは、本来はエンタープライズデータベースが使用される金融・保険分野を含め、ほとんどの分野で採用実績がございます。
一方PostgreSQLは、エンタープライズ用データベースです。ライブラリによる提供はありません。サーバキャッシュの大きさにエンジンの速度は依存されます。スケールアウト出来る環境であればよく働きますが、組込みデバイスの様に、決められたリソース内で、高速稼働できるようには設計されておりません。現在では、組込みシステムのハードウェアのコストダウンが強く要求されています。今まではPostgreSQLでも十分稼働できると言われていた、MFP、POS、ATMなどのリッチデバイスでも、組込みデータベースが採用されるようになっております。
また、メンテナンスフリーの特長として、Empressはデータベースのストレージファイルの非断片化構造を持ち、バキュームする必要がありません。
他のデータベースとEmpressとの機能的な大きな違いは、データベースファイルに断片化が発生し、バキュームを必要とするか否かです。
PostgreSQLの最新のバージョンでは、システム運用中であってもバキューム可能な機能を提供していますが、バキュームを実行するにはドライブに多くの空き領域を必要とします。エンタープライズでは、ドライブに大きな空き領域を確保することは可能でしょうが、組込みシステムでは不可能です。
このため、バキュームが良く働かず、PostgreSQLでは、「朝は早いが夕方になると遅くなる」という話をユーザから伺います。
結論として、Empressはデータベースに対するマルチアクセス機能を有するため、IoT化のためのローカルデータベースとしての機能を充実させております。他にも、データベースのカーネル暗号化、レプリケーション、M2Mレプリケーションなど多くの機能を提供しており、更に上記のメンテナンスフリーの特長からも、Empressは、今後のIoT化において、有効なデータベースと言えるでしょう。
Empressに限らずほとんどのデータベースは、SQLという言語を有し、
またプログラムがデータベース管理システムに接続してSQLを発行し、結果を受け取るためのプログラミングインタフェースが用意されています。
このため、ファイルシステムと比較するとプログラミング効率が格段に上がり、Empressを採用した組込みシステムでは、従来80,000行あった検索プログラムを、20,000行まで減らすことに成功しました。
※通常のデータ管理でも最低30%程度、行数を減らすことが可能です。
ファイルシステムからEmpressに移行させることで、データ管理とアプリケーションを完全に分離させ、さらにレプリケーション・全文検索などがアプリケーションを補完することで、開発時間の大幅な削減が可能となります。
また、従来ファイルシステムでは面倒であったデータの整合性をEmpressが保証し、アプリケーションの機能追加が容易になります。
FileSystem | ||
---|---|---|
データファイルの作成 | 30秒 | 約1時間のプログラミング |
データをファイルに登録(追加) | 0秒 | 約1時間のプログラミング |
ファイルのデータを更新 | 0秒 | 約1時間のプログラミング |
ファイルのデータの削除 | 0秒 | 約1時間のプログラミング |
登録データの検索 | 0秒 | 約3時間のプログラミング |
インデックスの作成 | 0秒 | 約5時間のプログラミング |
複数ファイルのデータ統合 | 0秒 | 約8時間のプログラミング |
複数ファイルの並行運用 | 0秒 | 約4時間のプログラミング |
アプリのデータ検索 | 0秒 | 約16時間のプログラミング |
※上記のファイルシステムのプログラミングの時間は、Linux上でLinuxパーティションにファイルシステムを構築する際の平均的な作業時間です(Empress Software Japan調べ)