第三の DB、Firebird -- 3

管理しやすい DB

また、Firebird は管理しやすい。 DB 管理システムを設計し、記述するのは楽しい。 まあ、少なくともその種のたちの人間にとっては。 しかし、使いやすくするのはやっかいだし、大体、あれやこれや考えた末でなければできない。

InterBase は商用の製品として設計され、3カ月間無料サポート付きで売られたので、 インストールと管理を簡単にすることはとても重要だった。 Firebird も InterBase の伝統を引き継ぎ、 シンプルなインストール プロシージャ、オンラインバックアップで、 オフラインメンテナンスが必要ない。 さらに、これは議論の多いところだが、チューニングパラメータがほとんどない。

チューニング

DB にはチューニングが必要なことは誰でもだと知っている。 出荷時の DB に対しインストールされた時点での DB は、 どのベンチマークも大体2、あるいは3倍の改良を示している。 チューニングはコンサルティング サービスの目玉だが、 顧客がアプリケーション開発会社社からのみでなく、 DB 開発会社からもサポート契約を購入しなければならない場合、 DB に基づいたアプリケーションの配布するのにかなり障壁となる。 理想的には、会計パッケージを購入する顧客は、DB の存在を知る必要はないのだ。

DB のほとんどは、 チューニングしてメモリが様々な機能にちょうどよく割り当てられるようにしなければならない。 Firebird では、使用メモリを最大にして、 大量の DB ページがキャッシュされるよう設定できる。 ソフトウェアはメモリに関するほかのことを管理する。 メモリを最大量にするのは、 10 MB RAM のマシンが普通だった時代の遺物だ。

チューニングのもうひとつの役目はデータ配置で、 DB 内でのテーブル配置とレコード配置の両方を行う。 配置をコントロールできると、データベース管理者は、 参照場所が悪かったりあるいはヘッド競合がある時はどうしていいか分からなくなる。 Firebird では配置の操作は異なったやり方で行われる。 データは全て単一のファイルか一連のファイルに格納され、 マルチファイル DB でさえ、テーブル配置コントロールを持たない。 単にディスク上に DB を広げるメカニズムでしかない。

データは3つのレベルのルックアップ ツリーを介して配置され、 ポインタページ、データページ、ページ上のレコードで構成される。 レコード識別子はポインタページの続き番号、 データページ番号のポインタページにあるオフセット、 レコードに対するポインタのデータページにあるオフセットである。 データベースがバックアップから復旧される時、 テーブルに対する全ページは一塊にされる。 そうでなければ、DB ファイル中に、 最初に割り当てられリリースされたページを使って割り当てられ、 それから、ファイルの最後に新しいページを割り当てる。

Firebird はテーブル内にいかなるレコードも持たない。 他の DB だとレコードをインデックス値に基づいてまとめるので、 その結果、一緒に読み込まれそうなレコードは一緒に格納される。 従って、他のインデックスでのアクセスは著しく遅い。 Firebird のインデックスアクセスは異なった構造をとっている。 WHERE CLAUSE がインデックスで決定できる時、 Firebird はまずレコードにマッチする識別子を全て探し、 スパース ビットマップに格納する。 ビットマップはレコード識別子順に並び、 レコード識別子はレコードのストレージロケーションを表しているので、 どのページの全レコードもすぐに読むことができる。 この結果、全インデックスのルックアップタイムは同じになる。

Firebird のインデックスは非常に高密度だ。 なぜなら、 各キーのプリフィックスもサフィックスも圧縮されているからだ。 サフィックスの圧縮は、 データ型によるが、空白あるいはゼロを単純に消すだけで、 圧縮はセグメントキーの各セグメント上でなされる。 プレフィックスを圧縮すると以前のキーに合致する先頭のバイトは消去される。 それで、複製された値はキーを持たず、まったく格納されない。 インデックス中の密度の濃いストレージは BTREE の深度を最小にし、 ほとんどのデータで、その他のインデックス型の優位はなくなる。 地理データはまた別の問題だが、 しかしこれは Firebird がフォーカスしている領域ではない。 膨大な地理的データを扱うには、 他のオープンソース DB にもっとよいものがあるだろう。

メタデータ

Firebird はまたメタデータの取扱いで、 DB の管理の難しさを減らしている。 ほとんどのメタデータの操作は稼働中の DB 上で実行できる。 カラムの追加、修正、削減、再整列ができるが、 データを除去したり、詰め替えたりする必要はない。 テーブルにカラムを追加する場合、レコードの中央に表示できる。 カラムを追加する時にその位置をレコード内に指定できるし、 必要なら、他のカラムの位置を変更し、新しいカラムのための空間を作ることができる。

カラム名、データタイプ、長さ、デフォルト値、状態は全て変更できる。

次は 第三の DB、Firebird -- 4  »