HSQLDBのデバイス搭載可能なDBとしての妥当性

最近、HSQLDBをデバイス搭載可能なデータベースとして使えるかどうかという調査を行う機会がありましたので、ご紹介しようと思います。

HSQLDBの最新版1.8.0.4を利用
プロファイリングを実行して、
ポイントになるソースコードの調査

＊よくHSQLDBがディスクフラッシュを十分に行っていないため、耐障害性が無いのではと言われていましたが、
SET WRITE_DELAY FALSE;
でcommit時にflushを強制的に実行させることが可能です

======================================================

「耐障害性について」
・クラッシュリカバリのアルゴリズムにそもそも欠陥があります
http://www.hsqldb.org/doc/guide/apc.html
・CHECKPOINTメソッド自体も耐障害性が十分考慮されていない
（データベースファイルが消えたという現象がここから来ます）

これら２つの調査の過程で明らかになったのが以下のものです。
１．".data"ファイルは、基本的に各行をバイト配列に変換して書き込んでいるだけ
（ばらばらのデータが並んでいるのでメモリに読み込まないと操作できない）
２．".data"ファイルは、インデックスを含んでいない
３．".log"ファイルには、実行されたSQLが並んでいるだけ
４．フリースペースマネジメントが存在しない

「省メモリ消費について」
・HSQLDBは各行をメモリに読み込まなければ作業できない
・HSQLDBはハイパフォーマンスを実現するため、処理をメモリ内で行う
・インデックスはAVLTreeというアルゴリズムで全てメモリ内にある

======================================================

つまり、HSQLDBは通常のディスクベースデータベースと大きく異なり、あくまでもインメモリデータベースであることが分かります。これは、JBossなどのJ2EEサーバー内で、メッセージングなどの一時データを格納したり、高速な処理が要求される処理をすることが目的だからです。サーバー上ではメモリは十分安価なリソースとなっているので、メモリやUPSを買ったほうが早いといえます。もしACIDデータベースが必要な操作はEJBを使うまでです。

CACHED TABLEが導入されてファイルを使用するようになりましたが、あくまでもそれは数ギガバイトというデータをメモリに全て格納するのは厳しい、という拡張性の問題を解決するものです。

またもう一点気になったのが、フォーラムやメーリングリストで、数週間又は数ヶ月問題なく動いていたのに、急にデータベースファイルが無くなった、またはOutOfMemoryが出るようになったというクレームをよく目にすることです。不確かなので検証はできませんでしたが、回答もされることが無いのを見るとコードの品質が低いと考えるのが妥当です。

HSQLDBに耐障害性や省メモリ消費が欠如しているのは、パフォーマンスを重視したインメモリデータベースだからであり、それを補強・改良することは、ディスクベースの新しいデータベースを設計して作りあげることに等しく、恐らく最初に魅力に感じたであろう、パフォーマンスを失うことにもつながるでしょう。

もちろんアプリケーションサーバー内で高速データベースが必要な場合は、圧倒的に優れていることもよく分かりました。もしご意見ご感想等ございましたら、japan@db4o.comまでご連絡ください。