Marina Novikova: 　学歴をお聞きしてもよろしいですか?　また、これまで働いた中でどこが一番気に入っていましたか?

Jim Starkey: 私がコンピュータに関わり合うようになったのはちょうど高校生になった頃のことでした。地方の大学は政府から補助金をもらって、高校の生徒達にFORTRANを教えていたのです。一番最初にパンチカード（ググッてみてね）を打ったときは、曲がってしまったことを覚えています。最初に触れたコンピュータはIBMの7040だったのですが、とても大きな部屋を専有するくらいばかでかくて、そのくせメモリは全部で32Kバイトしかなかったのです。翌年私は15歳になったのですが、その時に最初のコンピュータ言語をデザインしました。その言語は機械語とアセンブラをまねしたものでした。それ以来ずっとコンピュータと関わり続けています。　私の学位は、実は純粋数学に関するものなんです。私の公式のコンピュータ・サイエンスに関するバックグラウンドは、たった一つの特別プロジェクトコース に関するものだけです。　私の最初の「本当」のコンピュータに関する仕事は、 インターネットの先駆けであるARPAnet のためのデータベースマシンを作り上げるためのプロジェクトに関する調査でした。それは、アメリカ・コンピュータ社( 7人の有名人による会社 ) で行われました。そこにいた間、Codd博士のリレーショナル・データベースに関する初期の論文に出会ったのです。リレーショナル・データベース理論は、ばかげたほどアカデミックな言葉によって論じられていましたが、いったんその姿を現すと、じつに純粋で、単純で、エレガントだということがよくわかりました。そんなわけで、コンピュータが最初に私にとりついて、2番目はリレーショナルデータベースだったというわけなんです。 　私の第 二 の「本当」の仕事はDECでのものでした。DECはとても働きやすいところでした。それは、もうほとんど無政府状態といったほうがいいでしょうね。私は、 Datatrieve と呼ばれる非常に成功した製品を作り上げました。実はこれ、マネージャがばかげた政治的な策略のためにキャンセルしたんですが、それは何の意味も無かったんです。そこで私は次のような月次報告書を書き始めました「Problems：プロジェクトはキャンセルされた。これが元に戻せないのであれば、開発スケジュールに影響を及ぼすであろう」。やはり、それも何の役にも立ちませんでした。第 2 のバージョンは、予定どおりに出荷されました ( まだキャンセルされたままでしたが ) 。こんなにマネジメントが最善の努力をしているにもかかわらず成功する会社は賞賛に値しますよね。しかし、ゴードン・ベルが DEC を離れたので、私も辞める時がきたのを悟りました。

Marina Novikova: あなたは、非常に興味深いプロジェクト Netfrastructure にかかわってますね。こういえば当たっているのかわからないのですが、Netfrastructureは、 SMP に最適化された SQL ‐サーバで、Java サポートをビルド・インしたものなのでしょうか?

Jim Starkey: Netfrastructure の背景にある本質的アイデアは、コンテンツ、プレゼンテーション、それからロジックを分離することです。コンテンツは「コンテンツ・ストア」に存在しているのですが、それはJDBC に準拠したマルチユーザでSQL‐ベース、トランザクション‐ベースの「コンテンツ・ストア」なのです。我々はそれをデータベースとは呼んではいません、というのも私はデータベース・マーケットが大嫌いだからなのです。そういうわけで、それは「コンテンツ・ストア」なのです。コンテンツ・ストア、OK？プレゼンテーションは本当に気の利いたページ生成エンジンとJava仮想マシンに統合されたロジックによってハンドリングされています。全てのコンポーネントは共通のロール・ベースのセキュリティ・スキーマを共有しています。　データベース（えーと、コンテンツ・ストアね）のアーキテクチャーはInterbase/Firebirdとは根本的に異なるものです、それはコンピューティング・プラットフォームの根本的な変化を反映しているからです。私が最初のバージョンのInterbaseを設計してアポロ DN320に実装したとき、それは十分に速かったし、随分お金もかかったし、2メガバイトを使い切ったものでした。今では、地方の商店街で売っているような最も安価なマシンでさえ128MBのメモリを積んで、何百ドルかでギガバイトまで拡張することもできます。賢明な人でしたら、ギガバイトのメモリを2MBで利用するのと同じ使い方はしないでしょう。エンジンはシングルプロセスで、マルチ・スレッドに対応して、SMPに連動します。　Netfrastructureの別の側面で興味深いのは、アプリケーションのトポロジーが逆転するということです。アプリケーションはデータベース・エンジンの内部で実行されます。そう、あたかも巨大なストアド・プロシージャのようにね。JDBCメソッドの実行は半ダースの機械語なんだけど、実際にはスレッドスイッチ、コンテクスト・スイッチ、プロトコル・スタックを下っていって、プロトコル・スタックを上っていって、データベース・エンジンに対してサーバ・レイヤーから呼ばれ、検証されて、それから恐らく各ステップで引数が変換されて、そしてまた元に戻されているわけです。そんなわけで、我々は、 2、 3 ダースのナノセコンドと大体 10 ミリセカンドの間の差異について論じているんです。それは10の何乗にもになってしまう。どんなデータの移動に対してもこれは起きてしまう。それから、もちろんだけど、この仕事は徹底したセキュリティ環境の元で行われています。つまり、アプリケーション言語はサンドボックス の中で見事に動いて見せなくてはならないわけです、Javaである以上ね。そういうことで、自分でJava仮想マシンを書き上げてしまったのです。

Marina Novikova: みんなが言っていることですが、Netfrastructureを一から作り上げることで、あなたが元々 Interbase/Firebird で使われていて、もっとも理解しているマルチ・ジェネレーション・アーキテクチャのアイデアを実装するのを助けたのでしょうか。言い換えれば、あなたは、次世代の Firebird 開発者に対して、どうやって小さくて速いサーバーを作り上げればいいのかについて、わかりやすくデモンストレーションを行ったのでしょうか。私の言っていることは当たっているかしら?

Jim Starkey: 私は、マルチ・ジェネレーション・アーキテクチャのアイデアを実装するのを助けたわけではありません、確かに私はそれを発明しました。しかし、それは私が DECにいた時のことです。そうまだ私がInterbase を始める前のことです。DEC は、私と一緒にやろうとはしなかったので、結局自分自身でそれを作り上げました。　NetfrastructureとInterbase/Firebird の間の大きな違いは、 Netfrastructure がディスク上ではなくメモリ上でのマルチ・ジェネレーション であることなのですが、Interbase/Firebird はディスク上でジェネレーションを保持しています。この変更には 2 つの主な理由があります。一番目は、メモリが安くなって豊富に使えるようになったということ。二番目は、 Interbase は共有メモリを使わないクラスタ向けに設計されていたので、ディスクを使うしかなかったのです。そんなわけで、素晴らしいことに Netfrastructure は Firebird より最低でも 10 倍速くなったのですが、実は本当に重要なものは私がスイープについて説明する必要がなくなったことなのです。

Marina Novikova: そうすると、あなたの意見によれば、Interbase/Firebird のマルチ・ジェネレーション・アーキテクチャはサーバの開発上の妨げとなるのでしょうか？非常に多くの更新があった場合、ガーベッジ・コレクションは更に遅く予測できない状態になるということでしょうか。

Jim Starkey: とんでもない。あなたが InterBase/Firebird のディスク書込みの簡潔さをを伝統的なトランザクションログと比較するなら、マルチ・ジェネレーション は、簡単に勝つでしょう、それはディスクのオーバーヘッドがより少ないという統計で現れるでしょう。ブロックヘッドだけがボトル・ネックを作り出すでしょうが、 Interbase/Firebird は競合しているシステムと比べてより少ないブロックヘッドしか発生させません。

Marina Novikova: あなたは、 Java がデータベース・ウェブ・アプリケーション開発者にとって最も良い選択であると思いますか?

Jim Starkey: 絶対的で正統的なアーキテクチャがあるので、Java はすばらしい言語です、小さくてシンプル、そして堅固です。しかし、それが何にでも向いているかと言えばそうではありません。Javaは、アプリケーションの意味を表すためには非常に良いプログラミング言語です - 小さくて、シンプルで、優雅で、堅固。サンドボックス実行モデルは、アプリケーションコードが通常ふさわしくないとされる場所での実行を許します、データベース ( えーと、コンテンツ・ストアね ) システムの内部でのようなところでね。一方、 Java における文字列の扱いに関するパフォーマンスは悲惨なほどです、それからスレッド同期化のプリミティブな部分、2つ の状態を持つMUTEX も、哀れなほど遅いのです。Netfrastructure では、アプリケーション・ロジックのために Java を使用していますが、コンテンツ・マネジメントとページ生成に関してはＣ++を残しています、そのことは実装が物語っているんですが。

Marina Novikova: どうして、Interbase/Firebird のインデックスはユニ・ディレクショナルなのでしょう？またどうして、Interbase/Firebird のインデックスはバランスド・ツリーではなくて、シンプル・ツリーなのでしょうか ( 我々が利用可能なソースがある、現在のバージョンでも確認することができるのですが )? それは、 Interbase/Firebird アーキテクチャの制限によるものなのですか ?

Jim Starkey: それは全て1 つの個人的な見解に還元されます ：　私は、チューニングが嫌いなんです。コンピュータやソフトウェアは、スマートであるべきだと思っています ( 最適化なんてことについて考えなくてもすむようにね ) 。　この問題は、クラスタ化インデックスと非クラスタ化インデックスの対立なのです。伝統的なデータベース・インプリメントは、インデックスページとデータベースページの間でインデックスが飛び跳ねて歩き回らなくてはなりません。開発者はそのことを非常に迅速に学んだのですが、このことはディスク・アクセスにとって大変悲観的な結果をもたらします。そのため、彼らはレコードの物理的オーダがインデックスオーダと一致するように、クラスタリングを発明したのです。しかしこのことはスペース管理の問題と、ページ・オーバーフロー、 書き戻しのストラテジー、最適化の問題、それから全般的な混乱状態へ陥らせました。データベースのユーザは、物理構造、論理構造、アクセスパス・ストラテジー、それからインデックス設計を計画しなければならなくなってしまいました。そして、それらが必然的に引き起こす悪い結果に対して、データベース開発者はユーザの設計が悪いと非難したわけです。　そんなわけで私は、代替インデックス技術を開発したんですが、 それはbtree を Datacomputerの 反転と結合したものです。全般的なアイデアは、非常にシンプルなものです。インデックスとデータページの間を渡り歩くよりむしろ、インデックスは最初にスキャンされて、スパース・ビット・ベクターにおいて選択されたレコードを示すビットをセットし、ビット・オーダーに従ってレコードを処理し、それはまたディスク上の物理的配置にしたがっているわけです。このことは、いくつかの大きな勝利の鍵を持っています。一番目は、全てのインデックスは、うまく取りまわされたクラスタ化インデックスのように動作します。二番目には、インデックスバケットは、 二相ロッキングに支配されません。三番目に、ブーリアン、つまり「ＡＮＤ」と「OR」に関する操作について、ビットマップを媒介として実質的にコストなしに実行可能となります、つまりオプティマイザーが代替インデックス間で選択をする必要性そのものを消去してしまうのです。　そんなわけで、それは全く問題とならないのです、つまり最低でもインデックスが昇順か降順かということについてはね。インデックスが最初にスキャンされ、それからレコードがその次にフェッチされます。あなたがレコードを並び替えたいと思うなら、物理的順番でレコードをフェッチしてそれを並び替えるこの方法は、ランダムアクセスと共にディスクアームを鳴らしてフェッチするよりも「いつでも」速いのです。そして更に多くのレコードが関連し、さらに多くのソートがあれば尚更です。　インデックスの中を渡り歩くことが意味をなす唯一の時間というのは、あなたが 何百万ものレコードの中で、最初のいくつかを問い合わせた時だけです。実際のところ、これはdBase エミュレーションをしていた間は、デフォルトで起こりうるケースでした。そんなわけで、我々は賢明にも、バイナリ・アクセス言語を付加し、こうしたケースを理解するオプティマイザを準備し、インデックスを渡り歩いているのです。　Interbase/Firebird は普通の btree ( 元々バランスがとれている ) です。私は、バケットを空にして再結合するためのコードを書きませんでした。なぜなら、データの統計が通常安定していて、従って、スペースは再使用されるであろうし、もっと他に私が行うべき多くの重要なことがあると思ったからなのです。いつかは、重要なことをやり尽くして、バケットの再結合に手をつけることになるだろうと、信じていますが。

Marina Novikova: Interbase/Firebird は、完全なリレーショナルDBMS ですよね? 結局のところ、Forced Writesオプションが有効でない時、各トランザクションはそれぞれのコミット後に必ずしもセーブされるとは限らないわけですが。ACID におけるD は、 Durability を意味しているので、トランザクションがコミットされるなら、それは小さなハードウェア・エラーの場合には失われないことが確実でなくてはなりません。Interbase/Firebird においてはForced Writes をしなければならないわけですが、しかし、これは、オペレーションのスピードを減少してしまいます。このことについて何かお話し頂けますか?

Jim Starkey: そうですね。Interbaseは、信頼性の高いディスクを持つ堅牢なオペレーティングシステム上で動くように設計されましたが、Unix では、これは、パフォーマンスと絶対的信頼性の間でのトレード・オフを意味しました。私は、トレード・オフが好きではないのですが、そこにはそれがあったわけです。シリアル・ライト・ログ は、トレード・オフをほとんど消去するでしょうが、クラシック・モデルにおいてはそれを実行することは不可能です。Netfrastructure は、シリアル・ライト・ログのためのアーキテクチャーになっています。しかし、バッテリバックアップを持つ Linux はこれまで決してクラッシュしたことがありませんので、私は自分のトロくさいインプリメントのおかげで、睡眠時間を削られずにすんでいます。

Marina Novikova: Interbase 6 のソースコードが公開された後で、多くの興味深いものがあることが分かりました、不幸にも実現することがなかったものですが、例えば、式に対するインデックス、 双方向のカーソル、 XNETや、その他のものです。どうして、それらの開発者がそのアイデアを完成しなかった、と思いますか?　これは、アーキテクチャの制限によるものですか、あるいは時間が足りなかったとか、または他の何かの不足のためだったのでしょうか?　それから、あなたは、 オープンソースのDBMS についてどうお考えですか?　Linux は今上昇傾向にありますが、オープンなデータベースは今後、DBMS マーケットのかなりの部分を占めると思いますか ?

Jim Starkey: オープンソースプロジェクトのアキレス腱は、意思決定の方法にあると思います。コンセンサスに最も依存しているのですが、革新に関するコンセンサスは、とてもとても難しい。そんなわけで、オープンソースプロジェクトは、標準化へ向かう傾向があると思っています。Linux は、良くも悪くも、Posix と Unix に基礎を置いている。OK 、それらは20 年間の間に陳腐化してきたものだが、ふーむ、たしかにうまく動いています。一方、 SQL はテーマではあっても標準化されていません。現実の標準は、あらゆる目的に対してほとんど役に立たないもので、インタオペラビリティに沿って作成されたものにすぎないのです。確かなことは、プロジェクトを組織化するために必要なものは何もないということなのです。　データベース ( とコンテンツ・ストアね ) システムが扱うべき重要で、興味深い問題は山積みです。例えば、ウェブの基礎は検索です。どのようなデータベースシステムが、オープン・コンテクスト検索をサポートしているでしょうか?　私が知る限り、一つだけです。どのようなデータベースが、ユーザープロファイルに基づくデータを自動的にフィルタリングするでしょうか?　私が知る限り、一つだけです、それはコンテンツ・ストアと呼ばれています。　Firebirdの連中は、セキュリティ・ホールをふさぎ、システムを安定させ、バグを修正し、問題点を取り除く良い仕事をしてきました。そのシステムは、うまくマイナーチェンジすることを必要としていて、いまではそれは一つの答えを持っています。しかし、私はそういったことによって、データベース・テクノロジーにおける世界的リーダーとしての Interbase の伝統的な役割が取り戻せるとは思いません。Interbase/Firebirdは異種接続性、 二相コミット、カスケーディング・トリガ、ユーザー定義関数、イベント・アラータ、BLOBフィルタ、配列サポート、 双方向のマルチベンダーゲートウェイ等を持つ最初のデータベースでした。しかしその後、私はオープンソースプロジェクトが革新を促しているのを全く見ていないのです。　私はこれが少し難しいことだということを知っていますが、私はオープンソースプロジェクトとしての Interbase を決して開発することはないでしょう 。私は政治家ではなく技術者です。私は、自分が急進的な新しいデータベースアーキテクチャに関してコンセンサスを作らなかったということを強く確信しています。私は革新を信じ、そして革新は、一貫したビジョンを必要としています。私はオープンソースの中でそうしたビジョンを見たことがありません。しかし、私はこれだけは知っています。Firebird がクラシックとスーパー‐サーバのコードベースを分離しない限り、どちらも、どこへ行くことも出来ないでしょう。それぞれが、他方の開発を抑制してしまっているからです。

Marina Novikova: あなたは、そうした多くの発明に満足していますか?　Netfrastructure ではあなたの夢やアイデアを実現したわけですが、Interbaseと Firebird の開発をどのように評価していますか?　あなたがFirebirdの発展を見ることは興味深いことで、喜ばしいと思っていらっしゃるのでしょうか？例えば、アーキテクチャの変更のような重要な改善、メインバグの修正、 DSQL の拡張、パフォーマンスの改善等々ですが。

Jim Starkey: 私は、一群の発明をしてきましたが、それら全てを愛しています。VAX Datatrieve は、 VAX を離れて存続し、オラクルの爪から逃れ、 DECを離れて存続し、コンパックを離れて存続し、そしてHPの製品としてまだ生き続けています。私はVAX Datatrieveを気に入っています。それから、私にはとんとわかりませんが、どういうわけか PDP-11　のDatatrieve は、同じくまだ利用可能です。私はそのこと自体にとても驚いています。開発者が Firebird の様々な部分の周辺に腕を伸ばすのを見ることは、興味深いことですが、私は、誰かがFirebirdと共に走り出すのを待ち続けています。おそらく、誰かがそうするでしょうね。私が Firebird に活発にかかわっていたなら、自分がしただろうと考えているのは以下のような事です :1. シャム双生児となっているクラシックとスーパーサーバを分割すること、それによってそれぞれが生きながらえることが出来る。2. SQL をふさわしいエンジンに移動する間、レガシー・インタフェースとして BLR を維持すること。DSQL を捨てること。3. 2 レベルのネーム・スペースを導入すること4. スーパーサーバに対する知的に防御できる、有効なセキュリティを実装すること5. トリガ、ストアド・プロシージャ及びUDF のために Java バーチャル Machine を埋め込むこと6. スーパー‐サーバのためにシリアル・ライト・ログを実装すること ;書込みに注意を払わなくてもいいように

Marina Novikova: あなたは、オリジナルの Interbase アーキテクチャにおけるいくつかのあなたのアイデアが次の開発者によって不正確に理解され、もしくは誤って実現されていると思いますか?

Jim Starkey: どちらもないですね。アイデアもアーキテクチャも、最初から十年間にわたって利用可能なプラットフォームに完璧に適合していました。私が別のデータベースシステムを作らなければならなかったのでしたら、アポロ DN320 のために、マルチ・レベルなネーム・スペースを持つネイティブなSQLを作ったでしょうね、でも、他のものほとんど同じになったでしょう。　私が現代のマシン上ですべてをやり直さなければならないのであれば、再びすべての点で Netfrastructure を書くことになるでしょうね。しかしその時は、システムテーブルをケース・インセンシティブにするでしょう。それから、インデックスキーに関するアンの言うことを聞かないといけないですね。

Marina Novikova: Interbase/Firebird/Yaffilのコミュニティ全体に対して、望んでいることがあればお聞かせ下さい。

Jim Starkey: 過去から学びなさい。将来のために設計しなさい。もはや1984 年ではないのです。それにふさわしい扱いをしましょう。