0. はじめに

0.1. この文書は何？ 読み方と対象者

0.1.1. 書いてあること

オープンソースの DBMS FireBird を使って、簡単なシステムを作りました。

その紹介と、それをサンプルにしながら、システム開発、DBMS、C/S システム、WEB などの話を少し書きます。 ( この文書は随時加筆修正しています )

0.1.2. 読み方

プログラムを読み書きすることのない方には、3章、4章、6章は興味のない内容かもしれません。お読みにならなくても大丈夫です。大事なポイントには他章からリンクがあります。

文書中には、プログラムのコードがたくさん入っていますが、コードの解説が主題ではありません。
システム開発・運用との「向き合い方」を軸に書いたつもりです。

想定した読者は、プログラマ、IT部門のマネージャ、そして、
『システム屋のいうことが分からなくて悩む管理者』などです。

0.1.3. ウソを見抜くために

システムエンジニアも時々「ウソ」をつきます。

意図的なウソもあれば、エンジニア自身の勘違いや不注意から来るウソもあります。
ネットワーク・バブルとともに世の中に広まった都市伝説もあります。

2章と 5章では、システム内部の事情に詳しくない管理者が騙されやすいウソの例を少しだけ書きました。

これらは、システムの品質と性能について考えるアプローチのほんの一例に過ぎませんが、このような視点で疑問を持つことの必要性を感じていただきたいのが、この文書の意図の一つです。

0.1.4. ほんの一例。例えばこういう勘違い

人間の日常的な感覚と、コンピュータシステムの動作とは少し異なる部分があります。

10万件のデータの検索システムがありました。
このデータ量が 100倍に増えて、1,000万件になったら検索に時間がかかって使い物にならなくなりました。

この事例は、多くの人を直感的に納得させます。
『そらそうだ。100倍になったのだもの、時間もそれだけかかるわなぁ』

でも、ウソです。

データベースのインデックスで使われる 2分探索のロジックの処理コストは、log₂N の関数に比例します。

すなわち、二分探索の繰り返し回数は、10万件なら平均 16.6 回、1,000万件では平均 23.3 回、応答処理時間は最大でも 40% しか延びません。
画面表示ならほとんど違いは感じないはずなのです。

もし、データ量に比例して検索時間が延びてしまったなら、それは 2分探索ではなく線形探索(いわゆる全件サーチ)が行われていることを意味します。

インデックスが使われていないという潜在的バグか。
なにか、性能最適化を誤った設計か。
それとも、別の部分の性能限界か。
別の原因が、必ずあります。

第 2章の2.4. ビューでは、こういう何気なく見過ごされる影響の大きな性能問題について、触れています。

『1,000 万件』という、やや日常的感覚からかけ離れた数字を前にして、思考停止しないことが大事です。

0.2. 世界の鳥類名検索辞典

題材は、このような CGI プログラムです。

世界の鳥類名検索辞典 (http://birds.oosato.org/cgi-bin/jpn2spccgi)
インターネットから見れます。もしよろしければ、使ってみてください。

野鳥の名前や分類を「学名」「和名」「英名」で変換したり検索する仕掛けです。

0.3. どんな環境で動いてるの？

0.3.1. ソフトウェア

OS は Linux です。Red Hat 9 をベースに自前でパッチしながらセキュリティ更新を続けています。
したがって、文字コードはまだ euc-jp です。
WEB サーバは Apache です。
DBMS は FireBird-SuperServer-1.5.5 です。
プログラミング言語は Perl です。IBPerl で FireBird と連携しています。

0.3.2. ハードウェア

とてもプアです。古い GraniteBay [E7205] チップセットに Pentium4/2.8GHz で HDD は parallel-ATA です。遅いです。
いまの serial-ATA や SCSI なら、DB のアクセスが数倍速くなるはずですが、プログラムの問題を見つけるには好都合(^^;)、ということにしておきましょう。

0.4. FireBird DBMS とは

FireBird って何？という方への簡単な説明

0.4.1. 歴史

FireBird の元になった Interbase は DEC 社の RDBMS Rdb/VMS から分岐し、1984 年に最初のバージョンがリリースされました。

1980年初頭に開発が始まった、Informix、Oracle、Ingres などと同等の歴史を持ちます。

その後、開発は Borland社に移り、Borland 社が 2000年に InterBase のソースコードを公開し、それを元に OSS として FireBird が開発されています。

0.4.2. 互換性、プラットフォームなど

標準 SQL への忠実度は高く、方言が少ないです。

Linux, HP-UX, Solaris, SUN-OS, Windows, MacOS など幅広いプラットフォームで動いています。

OS や FileSystem への依存度が低いです。例えば、Linux の ext3 ファイルシステムから、Windows の NTFS ファイルシステムにデータベースファイルを単純コピーして、そのまま Windows 版 FireBird で動きます。

0.4.3. 特徴など

オープンソースのDBMSの中でも、参照系のパフォーマンスを重視した MySQL などと異なり、トランザクション処理に特徴があります。PostgresSQL や 商用の Oracle 等に比較しても、トランザクション処理の軽さ・速さが目立ちます。

他の多くの DBMS が「ログ」で履歴を管理するのに対して、InterBase/FireBird は DEC Rdb 譲りの「マルチバージョニング」という方式で履歴を管理します。
これにより、シンプルで制約の少ないロック機能や、超高速ロールバックが実現できます。
その代償として、COUNT() 関数が全件サーチを行ってしまうなどの弱点が少しあります。

以前は、Cooked デバイス上でしか使えませんでしたが、現在のバージョンでは RAW デバイスサポートもあります。
RAW デバイスの効果のほどは……、まだ試していません。

0.4.4. 運用上の利点

とてもシンプルで管理が楽です。日常的なデータベース管理者を必要とせず、「手離れの良い」システムが組めます。

実際に大手チェーンストアのいくつかの物流センターセンターシステムを作り、稼働させた実績があります。
システム管理者のいない物流センターの作業現場に納入後 5年間以上、一度も現地訪問せずトラブルフリーで動き続けています。

他の DBMS に比較して独自拡張が少なく方言に悩まされることがあまりないのが特徴です。
反面、あれもこれもといった「便利機能」は少ないです。

例えば、PostgreSQL の COPY や Oracle の SQL*Loader に相当するものがありません。
バッチの大量データのローディングも全て標準 SQL で行います。

「そんな、遅くてかなわんでしょ?」と心配するあなた、きっと Oracle に毒されています。
同じプラットフォームで比較したことがないので、あくまで感覚ですが、FireBird でオンライン状態で SQL で更新しても、Oracle でオフラインで SQL*Loader のダイレクトパスを使うのと、速度は劣る印象がありません。
(参考) 3.3.1. データ流し込みプログラム

これは、実運用では、オンライン運用を続けたまま特別なバッチ処理やシャットダウンのジョブスケジュール管理を必要としないことを意味します。管理者なしで運用できる理由の一つでもあります。

0.5. 新しい環境への対応状況

上記 0.3. の環境はあまりに古いので、最新の環境での状況について触れておきます。

別のテスト環境に移植してみましたが、下記の環境でも支障なく動きます。
OS : CentOS-5.3 ( RHELクローンの最新版です )
DBMS : FireBird-SuperServer-2.1.2.ntp1(2009年4月版)
encoding : UTF-8

以下の章で掲載するプログラム、スクリプト等は、UTF8 環境への移行を配慮して書いています。
EUCJP、UTF8 のどちらでも動作確認はできています。