PostgreSQL 20年史｜コミッター石井達夫が振り返る変遷と進化の歴史
世界中で使用されるRDBMSであるPostgreSQLの長い歴史には、どのような変遷があったのでしょうか。長く、PostgreSQLに関わり続ける石井達夫さんに、同ソフトウェアの進化歴史の中にあるキーワードをもとに振り返ってもらいました。
オープンソースのRDBMSであるPostgreSQLは、いまや世界中の人々が利用するソフトウェアとなりました。その歴史は長く、ルーツは30年以上も前にさかのぼります。
PostgreSQLの前身は、カリフォルニア大学バークレー校で1986年に始まったPOSTGRESプロジェクトです。その後、1994年にAndrew Yu氏とJolly Chen氏がPOSTGRESにSQL言語インタプリタを追加し、翌年にPostgres95をリリース。1996年にようやくPostgreSQLという名称が登場します。
こうした変遷を黎明期からその目で見てきた人物がいます。SRA OSS, Inc. 日本支社 取締役支社長の石井達夫（いしい・たつお／ 
- 変わらないPostgreSQLの本質、抽象データ型の設計思想
- かつて、PostgreSQLはビジネス利用を想定されていなかった
- PostgreSQLが迎えた、2つのパラダイムシフト
- 徹底した合議制で成り立つ、PostgreSQL開発コミュニティ
- リタイア後も、オープンソースへの貢献を続けたい
変わらないPostgreSQLの本質、抽象データ型の設計思想
——石井さんがPostgreSQLと出会われたのは、いつ頃だったのでしょうか？
石井 30年ほど前、PostgreSQLの前身であるPOSTGRESと出会ったことが始まりです。私が37歳の頃だったでしょうか。当時、私の所属するSRAはハワイ大学や富士通との共同研究を行っていました。SRAからハワイ大学の研究所にエンジニアを派遣していたのですが、前任者が帰国したため私が行くことになったのです。
石井達夫さん： PostgreSQLをはじめとする、多彩なオープンソースソフトウェア向けのサービスを展開するSRA OSS, Inc. 日本支社の取締役支社長。1991年、ハワイ大学・富士通・SRAの共同研究にてソフトウェア工学に携わったことをきっかけにデータベースへの関心を深める。2005年より現職。PostgreSQL黎明期から開発にコントリビューションするコミッターの1人。著書に『PC UNIXユーザのためのPostgreSQL完全攻略ガイド』『今すぐ導入!PHP×PostgreSQLで作る最強Webシステム』（ともに技術評論社）などがある。
——どんな研究をしていたのですか？
石井 ソフトウェア工学の研究をしており、ソースコードから自動的に情報を引き出す、という特殊なデータ解析をやっていました。あるとき、解析結果を格納しておくためのデータベースが必要になり、「リレーショナルデータベースの上に何かを乗せて、オブジェクト指向的なデータベースを作ってほしい」と頼まれたのです。
リレーショナルデータベースの上にといっても、商用のデータベースは高くて手が出せません。そこで前任者の方が「無料で使えるオープンデータベースがあるよ」と教えてくれたのが、SQLと末尾に付いてない頃のPOSTGRESでした。バージョンは4.2だったと記憶しています。それが、その後PostgreSQLに関わるようになった始まりです。
——当時から現在まで変わらない、“PostgreSQLらしさ”とは何だと思いますか？
石井 前身となるPOSTGRESは、オブジェクト指向や抽象データ型といった設計を盛り込んだデータベースでした。機能が取捨選択されて現在のPostgreSQLに取り込まれているのですが、設計の根幹は今でも変わっていません。
例えば、普通のデータベースの場合、整数型や文字型といった基本的なデータ型は、ビルトインでコードの中に埋め込まれています。ですが、PostgreSQLでは基本的なデータ型でさえもシステムカタログ（RDBMSがテーブルや列の情報などのスキーマメタデータと内部的な情報を格納する場所）に定義されています。
PostgreSQL本体のコードは、整数型や文字型とは何かという情報を一切持ちません。データ型のみならず、演算子や集約関数などの情報もすべてソースコードとは別に定義されています。
——なぜそうした設計が行われてたのでしょうか？
石井 ルーツとなっているバークレー校の研究プロジェクトでは、複素数や地理データなど従来のデータベースにはなかなか取り組めなかった型を追加することを想定して、開発が進められていました。
こうした想定がある場合、内部の実装は具体的なデータ型に依存しない設計になっている方が都合が良いわけです。また、実装がデータ型に依存していないおかげで、ソースコードが非常にすっきりとして読みやすいという利点も生まれます。
かつて、PostgreSQLはビジネス利用を想定されていなかった
——では石井さんが、PostgreSQLへのコントリビューションを開始されたのはどうして？
石井 ハワイで2年ほど過ごして帰国した後に、ある雑誌で記事を書く機会に恵まれました。記事のテーマはWebサイト制作です。当時はまだWebが出始めた頃で、CGIで動的なサイトを作るだけでも最先端の技術という時代でした。今では考えられないでしょう（笑）。
記事内では、サイトのデータを格納するためにPOSTGRESを使っていたのですが、その後、読者の方からPostgres95がリリースされたことを教えていただいたのです。こうしたきっかけでデータベースへの興味が再燃してきたのですが、当時はまだ不便な部分が多かった。使いにくい機能を自分で直しながら、利用するようになりました。
——それがコントリビューションの始まりというわけですね。どのような機能から携わり始めたのですか？
石井 当時のPostgres95は、サン・マイクロシステムズのコンピューター上でしか動かないような作りになっていました。それを他のワークステーションやBSDなどでも動くようにすることから、活動をはじめました。
——便利になった現在のPostgreSQLからは想像もつかないですね。
石井 実は、PostgreSQLをビジネス利用する動きが始まったのは日本が発端だったんです。
——どういったニーズから、PostgreSQLが利用されるようになったのですか？
石井 それまで、ビジネスで使うコンピューターはメインフレームやワークステーションが主でした。会社のなかに、非常に大きなコンピューターが1台だけ置いてあったわけです。ですが、徐々に安価なコンピューターが利用できるようになり、社内にいくつものマシンを配置するようになりました。
商用のデータベースを使うと、何台ものライセンス費用がかかって高価になります。無料で使えるデータベースがあるならば、なるべくそれを使いたいわけです。当時はMySQLがそれほど日本で普及していませんでしたから、必然的にPostgreSQLを使う流れになったわけです。しかし一方で、初期のPostgreSQLはビジネス利用するには壁が多かったのです。
——どのような障壁があったのですか？
石井 笑い話のようなエピソードですが、当時のPostgreSQLはデータベースが許容する同時接続数がせいぜい数人くらいでした。数十人が使おうとすると、たちまちデータベースが落ちてしまう（笑）。同時接続数を管理するための仕組みが存在していなかったんです。
——そんな時代があったのですね……。
石井 それだけでなく、格納するデータに英語しか使えないという課題もありました。文字コード対応をしていなかったんです。それら2つの課題は、私が主に修正コードを書いて対応していきました。
OK. First of all, let me explain the EUC coding schema. EUC can handle up to 4 charcter sets. In EUC-jp, 4 character sets are as follows: char-set 1: left half of JIS X0201(almost identical to 7-bit ASCII) char-set 2: JIS X0208(2 bytes, 8-bit KANJI) char-set 3: right half of JIS X0201(2 bytes, 8-bit KATAKANA) char-set 4: JIS X0212(3 bytes, 8-bit KANJI) Char-sets 2-4 can be distinguished by inspecting the first byte. if the first byte = SS2(0x8e) then char-set = 3; else if the first byte = SS3(0x8f) then char-set = 4; else char-set = 2;
上記はPostgresSQL開発コミュニティのメーリングリストアーカイブに残る、1997年当時の石井さんのテキスト（抜粋）だ。まさに多言語対応を進めていた時期であり、日本語特有のエンコーディングの説明がされている。
——それほど重要な機能を石井さんが実装されていたのですね。どんな手段で、世界中の開発者たちとコミュニケーションしていましたか？
石井 Postgres95の件で連絡していただいた方などと一緒に、メーリングリストを始めました。最初は数人からスタートしたメーリングリストでしたが、数年後には数千人規模にまで大きくなりました。みんなでワイワイ議論しながら、機能についてのやりとりをして。楽しかったですね。
——当時はどのようにして修正コードのやりとりしていたのでしょうか？
石井 それもメールです。新機能の提案をメールに書いて、修正パッチを添付していました。添付されているソースコードを、みんなが自分のローカルマシンでビルドしていたんです。「PostgreSQLをビジネス利用したいので、こういうパッチを当ててください」と連絡をしたら「日本ではそんなに本気でPostgreSQLを使ってるのか」なんて欧米の開発者から驚かれましたね（笑）。良い思い出です。
——なるほど（笑）。
石井 多言語対応を行った際には、世界中の方々からテストを手伝ってもらえましたし、本当に感謝してもらえました。
例えば、中国語対応のパッチは文字コードのスペックを読めば実装できるんですが、ネイティブではない私には、正しく動いているか判断できません。すると中国人の方が「私が見てあげるよ」と手伝ってくれました。
それから、「あなたがこのコードを書いてくれたので、PostgreSQLで自国の言葉が使えるようになった」とメールで感謝の気持ちを伝えていただいたり。善意のボランティアで活動が成り立つことや、利用者から開発者に直接お礼を言ってもらえることは、昔も今もOSSの良いところです。
PostgreSQLが迎えた、2つのパラダイムシフト
——同時接続数や多言語の対応以外に、PostgreSQLの発展に大きな影響を与えた機能はありますか？
石井 本格的なビジネス利用という意味合いでいえば、レプリケーションでしょうか。この機能が入ったのはPostgreSQLのバージョン9.0。2010年からです。サードパーティー製のレプリケーションツールはこれ以前にもありましたが、PostgreSQL本体に取り込まれたのはこれが最初でした。
——レプリケーションが導入されることは、なぜリレーショナルデータベースの発展において重要なのでしょうか？
石井 レプリケーションの導入によって、データベースの可用性や信頼性を支えるベースとなる仕組みが整った、という意味合いが強いです。
レプリケーションがなければ、万が一データベースのトラブルが起きた場合に、何時間も、ときには何日もかけてバックアップからデータをリカバリする必要があります。ですが、レプリケーションがあれば最小限のダウンタイムでレプリカに切り替えられる。PostgreSQLを導入可能な事業領域の幅が格段に広がりました。
——なぜ、本体にレプリケーションが取り込まれるまで時間を要したのでしょうか？
石井 その頃は、開発者の間で「レプリケーションを導入するのは、技術的な制約が多くて大変だ」という見立てがあったのです。処理速度やデータの堅牢性、アーキテクチャのシンプルさを同時に解決できる手法がありませんでした。ですが、NTTの藤井雅雄さんという方が中心となり、それらの課題を解決できる方式を考えて提案してくださったんです。
▲PostgreSQL バージョン9のレプリケーション機能は、藤井雅雄さんの講演資料で詳しく解説されている。
——レプリケーション以降で、PostgreSQLを大きく変えた機能を挙げるとすれば？
石井 その後に大きく話題になったのはパラレルクエリでしょう。この機能はエンタープライズDB社に所属するエンジニアが中心となって作ったものです。その方とは知り合いですが、本人は非常に情熱をもってこの機能を開発されていました。
私の個人的な見解ですが、OSSへのコントリビューションは、会社から業務としてアサインされればすぐにできるという性質のものではありません。個人のやる気が成果を大きく左右します。高いモチベーションを持った人でないと、いくら時間を与えられても、技術力が優れていても、実現できないです。
——それは、OSS開発のどのような特徴に起因しているのでしょうか？
石井 個人の裁量が非常に大きいことにあると思います。通常のソフト開発では、決められた仕様に基づいて機能を実装することがほとんどですが、OSSの場合はそもそも何をするか全て自分で決めなければなりません。
そして、大きな機能であればあるほど、ほかの開発者との粘り強いディスカッションが必要になります。議論をリードするための根拠を提示できる技術力やコミュニケーション能力も要求されます。正直、しんどい局面もあるわけです。だからこそ、最後までやり抜くモチベーションはとりわけ大事になってくると感じます。
——石井さん自身は何をモチベーションにOSSの活動を続けられてこられましたか？
石井 強いて言うならば、人が必要なものを作ることでしょうか。誰かが作っていないのであれば、自分でやるしかない。そこが出発点ですね。ただ、先ほども述べたように、提案した機能について他のエンジニアと議論するなかで、大変だと思った経験は数えきれないほどありますよ。
——議論を続けるなかで、やる気が削がれてしまうことはないのですか？
石井 議論の相手と実際に会ってみると、受け取る印象がずいぶん違うものですよ。私は年に何度か国際カンファレンスの場でコミッターの方々と直接お会いしますが、話してみることで理解しあえることも多いです。「こんなに良い人だったのか」と。
メールで厳しいことを言われても、その人に会ったことがあるかどうかで、受ける印象はずいぶん違います。「この人は文章ではきついことを書くけれど、本人の性格からすると、きっと悪気はない」と思えたりします（笑）。
徹底した合議制で成り立つ、PostgreSQL開発コミュニティ
——開発コミュニティのなかでは、どのような形で議論がされてリリースまでたどり着くのでしょうか？
石井 昔は全てメーリングリスト上でやり取りがされていました。ですが、さすがに現在の規模ではその形式ですと限界があります。現在はCommit Festという仕組みが導入されました。数か月ごとに区切りをつけて、集中的にパッチのレビューをするという制度です。
▲「Commitfest 2019-07」のページより。レビュー待ちのチケット一覧がズラリと並ぶ。
石井 この仕組みが導入されるまでは、パッチが多すぎて特定のチケットが誰にも気づかれず、レビューされずに放置されてしまうようなことが起こりがちでした。ですがCommit Festが導入されたことで、どのパッチがレビューされているのか。逆に対応されていないものがどれほどあるのか、定量的に視覚化されるようになったのです。
——OSS開発においてCommit Festのような仕組みを導入することは、運営を円滑に進めるうえで汎用的に有効だと思いますか？
石井 もちろん、こうした仕組みは他のオープンソースコミュニティにも適用できると思います。ですが、有効に働くかどうかは、コミュニティのスタイル次第ではないでしょうか。
PostgreSQLの開発コミュニティは、中心となる人物がいてその人が最終的な決断を下すわけではなく、徹底的な合議制になっているんです。だからこそ、Commit Festのような制度が有効に機能しているともいえます。
PostgreSQL開発コミュニティでは、特定の中心人物を置かないという姿勢を徹底しています。特定の企業が方針を決めないように、「コアメンバーのなかには、同じ会社に所属する人間が○○人以上いてはならない」という暗黙的な制約もあるくらいです。
——Linus Torvalds氏がいるLinuxや、まつもとゆきひろ氏がいるRubyとは、また異なった運営体制というわけですね。
石井 徹底的に属人化を排除するために、ドキュメントもかなり丁寧に記述します。特定のメンバーがいなくなっても、他の誰かがメンテナンスできるようによく考えられているんです。もともとソフトウェアのスタート地点が、大学の研究プロジェクトの成果を引き継いだものだから、という要素も大きいのでしょう。
——徹底した合議制だからこそ実現した機能もあるのでしょうか？
石井 先ほどのレプリケーションが良い例です。もともと「サードパーティ製のレプリケーションツールがあるのだから、これをPostgreSQL本体に取り込んではどうか」という主張も存在しました。
けれど、当時のレプリケーションはオーバーヘッドの大きさや、レプリケーション可能なデータに制約があるなど、万全なものが見当たらなかった。そのためコミュニティ内で反対意見があがり、導入が退けられてきたのです。
全員が納得できるまで待ったからこそ、一番良い状態でレプリケーションが入ったといえます。これは、合議制が奏功した点だったように思いますね。
リタイア後も、オープンソースへの貢献を続けたい
——石井さんは長きにわたり、PostgreSQLへのコントリビューションを続けてこられました。活動をふり返ってきて、良かったと思えることは？
石井 PostgreSQLへのコントリビューションを続けてきて、後悔したことは何ひとつありません。数えきれないほどの恩恵を受けてきました。
例えば、データベースやその中にあるデータが、人間の社会にとってとても重要だということを自分でも認識できましたし、他の方にも認識していただけたことはとても大きかったですね。現代は、ビッグデータの隆盛からも分かる通り、データの重要性が広く認識される時代になりました。とても良い流れだと思います。
データベースに格納される情報は、もしかすると何十年も保持され続けるものですから、そこに人間の文化の本質が入っているんじゃないかという気持ちになることすらあります。だからこそ、大事なデータをきちんと守って維持できるようなシステムを作っていかなければいけませんね。
——石井さんの経験をふまえ、最後に読者である若手エンジニアにメッセージをお願いします。
石井 OSSに携わる利点として、よく「他人のコードを見て勉強できる」ということがいわれます。もちろんそれも大きな特徴ではありますが、私はそれ以上に、他の人たちと議論しながら各人の考え方を理解しあって、最終的に全員が納得できるシステムに近づけていくプロセスそのものに意義があると思うんです。
——石井さん自身もそうした議論を行うなかで、成長が得られたとお考えですか？
石井 勉強になった経験は数えきれないほどあります。自分には考えついていなかったことを指摘してもらったり、逆にみなさんが気づいていないところを私が指摘したり。お互いに高め合う経験は、本当に意義のあるものだったと思います。
私もいい年齢になりましたが、技術的な興味は今でも全く失われていません。コードを書くという行為を通じて、世界中の人々とコミュニケーションできるのが楽しい。願わくばリタイア後も、OSSへの貢献を続けていきたいです。
取材・執筆：中薗昴
