SQLite その後

SQLite を使って若干コードを書いてみた。けっこう速いぞ。
API もわかりやすくて、いい感じだ。SQL をちょっと知っているならば、API の説明についているサンプルコードと、web で見つけた何かを読めばすぐ書ける (せっかくなので、そのうちサンプルコードを載せよう…)。
ただ、INT 型とかでデータベースに保存されているデータを、Query で引っかけたときに、いちいち atoi() とか使って文字列から変換して変数に放り込むのは面倒だし遅そうなので、なんとかならないのだろうか? (どうやら、これはなんともならない、という話だが…)
INSERT INTO の前後には暗黙の BEGIN/COMMIT が付くらしいので、ひたすらデータを放り込み続ける場合は、大量の INSERT INTO の前後に 明示的に BEGIN/COMMIT を付けてやるのがよさそうで、かつ、最初は書き込みしかしない、というのであれば、それが終わってから CREATE INDEX すると検索が速くなる。
いま書いているプログラムは、最初に数十分あるいは数時間にわたって、ひたすらテーブルを作りまくるので、最初に CREATE INDEX してしまうと、インデックスを保持しながらテーブルを拡大していかねばならず、これが凶悪なまでに性能を劣化させる。しかし、最後の 1/3 か 1/4 では結局、読んだり書いたりの繰り返しになるので、ここが性能上の問題なのだが…
結局のところ、SQLite はかなり速い、という感じなのだが、PostgreSQL とか MySQL にしたら、もうすこし速くなるだろうか? DBMS と自分のアプリケーションが別のプロセスになるから、dual processor なマシンであれば良いかもしれない。
普段開発で使っているマシンは Power Macintosh G5 (2.0GHz x 2) で、多少激しくディスクをアクセスしても、アプリケーションとは別のプロセッサで OS がファイルシステムをメンテしてくれるようで、アプリケーションの CPU 使用率は 90% 以上を維持することができ(ただし、最初にインデックスを作ったりするとえらいことになり、昨日は 13 時間走らせてユーザプロセスに割り当てられた CPU time はたったの1時間だった)、けっこういい感じなのだが、シングルプロセッサな FreeBSD のシステムで走らせたら、CPU 使用率が 5% とかになってしまってびっくり。理想的には、4プロセッサくらいのシステムで OS の kernel + DBMS + アプリケーションを並列実行できる環境かな、と思う。しかし、DBMS が別のマシンで走っていたりすると、きっとネットワークがボトルネックになってダメだな。