SQLite3

研究で、大量のデータをテーブルに保存する必要があり、しばらくは STL の multiset みたいなやつを、自分で memory conservative な実装に書き直してメモリ上に展開していたのだけれど、いよいよメモリの容量がしんどくなってきた。 具体的にどれくらいしんどいかというと、32bit な環境では到底ダメで、64bit な環境で 16GB メモリを積んでも、ぎりぎり足りるか足りないかな感じ。

研究で、大量のデータをテーブルに保存する必要があり、しばらくは STL の multiset みたいなやつを、自分で memory conservative な実装に書き直してメモリ上に展開していたのだけれど、いよいよメモリの容量がしんどくなってきた。具体的にどれくらいしんどいかというと、32bit な環境では到底ダメで、64bit な環境で 16GB メモリを積んでも、ぎりぎり足りるか足りないかな感じ。これからもっとデータセットを大きくしたいので、もうメモリじゃ無理だ。
まあ、そんなわけで、最初は小さいデータセットをディスク上に展開することを考えてみた。で、Key:Value な表がひとつあればそれだけで幸せなので、こういうので一番簡単そう、というかよく知っているのはBerkeley DB なのだが、こいつは全然ダメだった。後から考えると、もしかしたら index を付ける方法があるのかもしれないのだが、それがよくわからず、結局のところ検索がうんざりするほど遅くて、実用には耐えないという判断。Berkeley DB を採用した理由は、API が簡単、というのはもちろんなのだが、PostgreSQL だとか MySQL のような RDBMS のように、データの実体は DBMS が管理していてユーザが直接ファイルを消したり移動したりできない、という状況がイヤだったので。こういう場合、DBMS への充分なアクセス権がないユーザは table を作ることさえできないしね。
で、いろいろ調べていたら、SQLite というのがあることを思い出した。こいつは、Berkeley DB と同じく、任意のところにファイルを作ってそいつをデータベースの実体にすることができるし、ライブラリをリンクしてやれば自分のプログラムが DBMS になる、という形式の SQL engine だ。しかも、性能はそれなりに良いらしく、少なくともテーブルの規模がそこそこならば MySQL とあんまりかわんない、というベンチマークも Web に落ちていた。こりゃいけそうだ。しかも、最近の MacOS X の /usr/{include,lib} にはこいつが最初から入ってるんですよ!
というわけで、いまテスト中。ほぼ完全に SQL92 Compliant で、index も定義できるし、けっこういい感じだ。

コメントを残す