Yet another OSS DB:Firebird(1)

Firebirdのアーキテクチャと特性、歴史

Firebird日本ユーザー会
はやしつとむ
2008/10/16

Firebirdと履歴型アーキテクチャ

 さて、使ってみたところで今度はFirebirdのアーキテクチャを見ていこう。

Eureka! Shadowingだ!!
  ――Falconも採用した履歴型アーキテクチャ

 Jim StarkeyがFirebirdの原型となるjrdを作り始めたとき(このあたりのいきさつは次ページ「Firebirdがやってきたところ・向かう先」で紹介する)、Jimはマサチューセッツ州グロトンに住んでいた。

 あるとき彼は自宅のシャワールームで森を見ていて「ユリイカ!」とヒラめいちゃったそうなんだ。何をヒラめいたかというと、「シャドーイング」というアイデア。それはJimによって的確なカタチを与えられて、「マルチジェネレーションアーキテクチャ」(MGA:履歴型アーキテクチャ)として世に出ることになった。

 履歴型アーキテクチャというと、PostgreSQLに実装されているMVCC(マルチバージョンコンカレンシーコントロール)注1も有名だけど、まあ表現が違うだけでやっていることは似たようなもの。MySQLの場合はこの辺のアーキテクチャはストレージエンジンによって違うのだけど、Jimが手掛けたFalconストレージエンジンはやっぱり履歴型アーキテクチャを採用している(まだ完成していないけれど)。

 履歴型アーキテクチャの特徴としては、ロック競合をしない読み取り一貫性の確保が容易であるという点が挙げられる。更新をブロックすることなく反復した読み取りが可能であり、またロールバックも確実に行える。もちろん、更新と更新が競合してしまうとデッドロックが発生したりするんだけどね。

 このあたりの処理について、商用のRDBMSではどうなのかというと、OracleはUNDOセグメント(以前はロールバックセグメントと呼んだ)という表領域=ファイルを用意し、トランザクションごとの一貫性を保つために必要な過去のバージョンのデータを退避させている注2

注1)PostgreSQLのマニュアルにはMVCCについて詳しい解説があり参考になる。

注2)このアーキテクチャの問題は、あらかじめサイズを指定したロールバックセグメントやUNDOセグメントの範囲内でしかトランザクションを制御できないところにある。ロールバックセグメントを使い切っちゃってエラーになった! というのはOracleを酷使されている方なら、一度は目にした光景かと思う。

 一方、DB2やSQL Serverではロック方式のトランザクション制御を行っている。つまり、読み取り一貫性を保つために、自分が読んでいるデータはロックしてしまって、トランザクションが完了するまでは放さない。このロック待ちは結構やっかいで、システム全体のボトルネックになってしまう可能性がある。そのうえ、行ロックからページロックやファイルロックへエスカレーションしちゃうこともある。

 そのため、回避策としてデフォルトではRead CommittedになっているIsolation Level(分離レベル)をRead Uncommittedにするという手段を取っている例も、(実運用の現場では)見掛けることがある。

 とはいえ、FirebirdやPostgreSQLの履歴型アーキテクチャにももちろん弱点はある。データベースファイルそのものに、最新のバージョンから過去のバージョンまでがすべて同居していくことになってしまうので、どんどん古いバージョンが残ってしまってデータベースファイルのサイズが膨らんでしまい、パフォーマンス上の影響が出てくるという問題がある。

 これを回避するために、FirebirdではSweep、PostgreSQLではVACUUMという仕組みで不要になった過去のバージョンをデータベースファイルから取り除いている。

コラム2:僕と火の鳥との出会いと、そのころの出来事

 僕がFirebirdと出会ったのは、2002年の秋だったと記憶している。ちょうどその頃、羽生彰洋氏が設立したエアロジック(現・スターロジック)に、FDELPHI注aでお世話になっていた近藤貞夫さんが参加されていて、「遊びに」といってはどうかと思うが、要するに訪ねて行った際にひょんなことから話が出たのがそのきっかけだった。

 当時、『Delphiマガジン』注bがまだ健在で、編集長の武田浩一さんともFDELPHIを通じて知り合ったころだった。Delphiマガジンに何か記事を書いてみたらという話があり、Firebirdについてというのはどうかという話が近藤さんからあったので、その場で武田さんに電話をして話がまとまってしまったのだった。

 そのころの僕は、Firebirdを多少は使ってみたことはあっても、それがInterBase注cのオープンソース版とどう違うのか、誰がそのプロジェクトをやっているのかなど、皆目見当もつかないような状況だった。とはいえ、まあなんとかなるかと思って引き受けてしまったのが、すべての始まりだったように思う。

 近藤さんも武田さんもノリの軽い方たちなので、きっと彼らも深く考えてなかったのだろうけれど(失礼)、多分僕ならそれなりの原稿をまとめるだろうと思ってくれたのではないかと思う。

 そのおかげもあって、その後、Firebird日本ユーザー会を立ち上げることができたし、微力ながらも日本でFirebirdを広める助けになっているのではないかと思う。特に、武田さんにはお世話になったが、昨年若くして急逝されてしまった。非常に残念でならない。ご冥福をお祈りします。

注a)まだパソコン通信だったころのNiftyServe(現@nifty)のフォーラム(mixiのコミュニティみたいなもの)で、Borland(現在はエンバカデロ・テクノロジーズのブランドになってしまったCODE GEAR)のDelphiを対象としていた。Borlandの社員も参加し、名人・達人・迷人(?)が集っていた「魔窟」のようなところだった。

注b)同じくDelphiを対象とした雑誌。2007年11月に編集長であり発行人であった武田さんが亡くなったため、廃刊となった。僕の手元にはvol.41(2005年7月1日発行)があるが、vol.1は持っていないので、いつごろ発刊したのか不明(編集注記:1998年10月、PSネットワーク発行という記録がWeb上に残っています)。

注c)InterBaseは、エンバカデロ・テクノロジーズの製品。最新バージョンはInterBase2007。以前はBorlandの開発製品に、無償で利用できるローカル版などが付属していたので、Delphi使いなら一度は使ったことがある製品だろう(http://www.codegear.com/jp/products/interbase)。

【編集注】本稿を掲載するにあたり、筆者・林氏と武田氏の関係や本稿のベースとなった原稿が書かれた経緯を知った。この場を借り、武田氏のご冥福を祈るとともに、武田氏のご尽力に感謝したい。
次のページへ 2/3 次のページへ

Index
Yet another OSS DB:Firebird(1)
アーキテクチャと特性、歴史
・Firebirdのインストールから起動まで
ビルドするには|ビルドオプション|接続ツールisql|情報源
→ Page 2
・Firebirdと履歴型アーキテクチャ
Eureka! Shadowingだ!!
  Page 3
・Firebirdがやってきたところ・向かう先
Firebird 2.5(SuperClassic)はプロセス・スレッドモデルを統合した実装

 

Yet another OSS DB:Firebird


Database Expert フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Database Expert 記事ランキング

本日月間