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。
注2）このアーキテクチャの問題は、あらかじめサイズを指定したロールバックセグメントやUNDOセグメントの範囲内でしかトランザクションを制御できないところにある。ロールバックセグメントを使い切っちゃってエラーになった！ というのはOracleを酷使されている方なら、一度は目にした光景かと思う。
一方、DB2やSQL Serverではロック方式のトランザクション制御を行っている。つまり、読み取り一貫性を保つために、自分が読んでいるデータはロックしてしまって、トランザクションが完了するまでは放さない。このロック待ちは結構やっかいで、システム全体のボトルネックになってしまう可能性がある。そのうえ、行ロックからページロックやファイルロックへエスカレーションしちゃうこともある。
そのため、回避策としてデフォルトではRead CommittedになっているIsolation Level（分離レベル）をRead Uncommittedにするという手段を取っている例も、（実運用の現場では）見掛けることがある。
とはいえ、FirebirdやPostgreSQLの履歴型アーキテクチャにももちろん弱点はある。データベースファイルそのものに、最新のバージョンから過去のバージョンまでがすべて同居していくことになってしまうので、どんどん古いバージョンが残ってしまってデータベースファイルのサイズが膨らんでしまい、パフォーマンス上の影響が出てくるという問題がある。
これを回避するために、FirebirdではSweep、PostgreSQLではVACUUMという仕組みで不要になった過去のバージョンをデータベースファイルから取り除いている。
僕がFirebirdと出会ったのは、2002年の秋だったと記憶している。ちょうどその頃、羽生彰洋氏が設立したエアロジック（現・スターロジック）に、FDELPHI注aでお世話になっていた近藤貞夫さんが参加されていて、「遊びに」といってはどうかと思うが、要するに訪ねて行った際にひょんなことから話が出たのがそのきっかけだった。
当時、『Delphiマガジン』注bがまだ健在で、編集長の武田浩一さんともFDELPHIを通じて知り合ったころだった。Delphiマガジンに何か記事を書いてみたらという話があり、Firebirdについてというのはどうかという話が近藤さんからあったので、その場で武田さんに電話をして話がまとまってしまったのだった。
そのころの僕は、Firebirdを多少は使ってみたことはあっても、それがInterBase注cのオープンソース版とどう違うのか、誰がそのプロジェクトをやっているのかなど、皆目見当もつかないような状況だった。とはいえ、まあなんとかなるかと思って引き受けてしまったのが、すべての始まりだったように思う。
近藤さんも武田さんもノリの軽い方たちなので、きっと彼らも深く考えてなかったのだろうけれど（失礼）、多分僕ならそれなりの原稿をまとめるだろうと思ってくれたのではないかと思う。
そのおかげもあって、その後、Firebird日本ユーザー会を立ち上げることができたし、微力ながらも日本でFirebirdを広める助けになっているのではないかと思う。特に、武田さんにはお世話になったが、昨年若くして急逝されてしまった。非常に残念でならない。ご冥福をお祈りします。
注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 |  |
アーキテクチャと特性、歴史
ビルドするには｜ビルドオプション｜接続ツールisql｜情報源
Page 2Eureka！ Shadowingだ!!
Firebird 2.5（SuperClassic）はプロセス・スレッドモデルを統合した実装
 |
Yet another OSS DB：Firebird |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか （2017/7/26）
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった （2017/7/24）
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと （2017/7/21）
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 （2017/7/20）
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
 |
|
|
|
|
