PostgreSQL強化のため、ユーザ企業が資金をプール
その結果生まれたのが、GiSTインデックスシステムにおける行レベルのロック機能である。これによって、PostgreSQLは企業での使用に堪えられるものになった。開発者と企業スポンサーによると、この新機能にはまだぎくしゃくした点がいくつかあり、その解決を待って、リリース間近のPostgreSQL 8.1に組み込まれる予定である。現在は、PostgreSQL CVSリポジトリに置かれている。本稿では、オープンソースソフトウェアプロジェクトに対するユーザサポートの1つのあり方として、この新機能の開発プロセスに注目してみた。
必要な機能、期限は間近
GiSTベースのPostgreSQL拡張機能（tsearch2、ltree、intarray、PostGIS）で同時実行制御と回復制御の改善が必要であることは、以前からかなり広く認識されていた。だが、さほど急を要する問題とは思われておらず、少なくとも、PostgreSQLを使用している企業が自分のポケットマネーを出してまで改善を急がせるというのは、まったく想定外のことだった、とRefractions社のPaul Ramsey社長は言う。同社はコンサルティングと製品開発を手がける企業で、PostGISオープンソース空間データベース開発の主要プレーヤでもある。
「私は、PostGIS誕生後のかなり早い段階からそうした機能の必要性に気づいていて、ほぼ2年前から（PostgreSQL GiST開発者のOleg BartunovやTeodor Sigaevと）意見交換をしていました」とRamseyは言う。「GiSTには表ロックの限界があって、将来を見通すと、これがパフォーマンス上のボトルネックになることは明らかでしたから、私自身はさほどこの製品をプッシュする気持ちはありませんでした。PostGISユーザのメーリングリストに要望をちょっと書いてみたりもしましたが、あまり反応もなかったですしね。ところが、数か月前から『やる時間はある。だが、8.1に間に合わせるつもりなら、いまから始めないとだめだ』と向こうから言ってきまして、私もまたメーリングリストにせっせと投稿を……。思うに、（a）8.1の最終期限が近づいたことと、（b）地理空間データベースのユースケースが変化した（リアルタイムアプリケーションやWebアプリケーションで、書き込み負荷が増加した）ことから、みなが重い腰を上げ、CFOにせっつく気になったのでしょう。それに、コミュニティにも2年分の成長がありましたからね。この製品に依存している企業が2年前より増え、それだけ財布も大きくなっていたということです」
Refractions、Cadcorp、WebBased、GlobeXplorer、Intevation GmbH、Mobile Meridianの各社が資金を出し合い、合計1万ドル弱が集まった。とくにRefractions社は、2000ドルを奮発したほか、品質確認、テスト、経理に人を出すという形で、さらに1000ドル分を寄付している。
「サポートが活発化した理由は、なんと言っても、最終期限が間近に迫っていたことでしょう。時期Xまでに資金が必要だ。集まらなければ、8.1リリースには組み込めない。いま金を出して、すぐに手に入れるか、金を出さずにいて、リリースサイクル1つ分待つか。その判断を迫られて、いま金を出すほうを選んだ企業が多かったわけです」
開発とデータセット強化
Webbased社の主任開発者、Mark Cave-Aylandは、pgsql-hackersとpostgis-usersという2つのメーリングリストでのやり取りを通じてGiSTサポートの必要に目覚めた、と言う。
「うちの地図システムでは、PostGISインデックス付きデータを大量にデータベースにロードします。で、そのロードが完全に終わるまで既存のデータをまったく変更できないわけですから、同時実行に難があるのは明らかでした」
Webbased社はインターネット、データ、画像技術関連の製品を設計し、製造している。同時実行での改善があれば、開発者には開発時間の短縮、ユーザにはパフォーマンスの向上がもたらされる、とCave-Aylandは言う。
「共有されている表のなかには、1個所の更新に何十分という時間がかかるものもあります。そんなとき、その更新が終わるまで、他の開発者はシステムでの仕事がまったくできない。これでは困ります。ユーザにとってのメリットと言うと、同じ時間枠の中で複数のデータセットをロードできることですね。それだけ、データへのアクセスが速くなります」
アップグレード以前のGiSTインデックスは、表レベルのロックしかサポートしていなかった。そのため、大量の読み書きが行われる状況では、パフォーマンスに「とてもむらがあった」とRamseyは言う。
「最大の恩恵を受けるのは、たぶんPostGISコミュニティでしょう。他ユーザに比べて複雑なデータを扱いますからね。わが社の地理空間データベースの1つを例にとると、レコード数はほんの15,000個ですが、それが40GBのスペースを占めています。このデータベースで複数の更新を同時に実行できれば、わが社のプロジェクトのデータ処理時間が目覚しく減少します。多数のユーザを同時にサポートするオンラインサービスでも、大きなパフォーマンス向上が期待できるでしょう」
企業レベルへ、需要に先行
新機能の導入で、企業におけるPostgreSQLの使用に拍車がかかるだろう、とRamseyは考えている。ユーザにとって、使用できる機能が豊富になる。
「今回のアップグレードで、PostgreSQLのオブジェクトリレーショナル部分が企業レベルに達し、他のデータタイプと足並みをそろえました。従来バージョンでも、読み取りパフォーマンスと複雑なデータのクエリプランニングは優秀でしたが、書き込み負荷の大きなアプリケーションに難点がありました。わが社が専門とする地理空間の分野では、ますます多くのデータベースアプリケーションで大量の読み書きが同時処理されるようになっています。たとえば、リアルタイムの位置追跡があります。当然、大量の地理空間データが読み書きされます。われわれとしては需要に先行し、クライアントから要求があったときには、もうそのための機能が存在する――そういう状態にしておきたいわけです」
今回のプロジェクトでは、GiST回復サポートも実装されている。新機能の開発者の1人、モスクワ大学シュテルンベルク天文研究所のOleg Bartunovは、「自分にとって理想的」なプロジェクトだったと語る。
「オープンソース開発者として、私には、何か提案すればサポートしてもらえるような組織が必要でした。だから、ぼくらの興味がOpenGISの要求と一致したというのは、とても幸運でした。結果として、長く待たれていたプロジェクトを完成できたわけですし」
新機能の開発に見られた開発者とスポンサーの協調関係は、さらなるPostgreSQL改良に期待をもたせる、ともBartunovは語る。すでにいくつかの改良点が開発者の課題リストにあがっている。
「HP Russiaとの間で、ロシアにおけるPostgreSQLサポートについてすでに話し合っていて、いま提案の作成に取りかかっています。われわれの目標は、全文検索の［強化された］組み込み機能を開発することです。GiSTでできたのですから、これもできないわけはないでしょう」
模範的方式？
今回のプロジェクトは、PostgreSQLにとっても、参加した企業やユーザにとってもよい結果となったが、一方で、協調的な資金集めと開発管理のためのインフラストラクチャの必要性が浮き彫りになった、とPostgreSQLのJosh Berkusは言う。
「PostgreSQLでは、いつでもこの種の開発へのニーズが存在します。オープンソースの世界では、この種の金銭的協力をサポートする公式機関が以前から望まれていました。責任の所在を明確にし、テストもちゃんとし、支払いもちゃんとさせる――そういう組織ですね。Fundable.orgがそれを目指していましたが、あそこのアプリケーションは、資金を出して開発させようという気を企業に起こさせるほど役立つものではなかったですから……。だから、依然として『お金のSourceForge』が必要です」
しかし、参加した当事者にとって、今回はうまくいったケースだ、とWebbased社のCave-Aylandは言う。
「グループとして資金を集め、望みの機能を実現してもらうというアイデアは、個人的にはとてもいいと思います。うちは小さな会社ですから、単独ではなかなかできません。大勢が少しずつ出し合って、全員が利益を分け合う。とてもいいんじゃないですか」
Cave-Aylandの見るところ、最大の鍵はRamseyがプロジェクトを組織し、顧客と開発者の間に立って仲介者として働いたことだ、と言う。
「プロジェクトをサポートしてくれる企業を探すのが大変だったと思いますよ。私自身、最初はかなり抵抗がありました。フリープロジェクトに資金協力？ そういう思いがあって……。まあ、いま思えば、こういう形のほうが筋が通りますね。たとえば、新しいASPサーバにMicrosoft SQL Serverをインストールすれば、そのたびにお金を払うわけです。それに対し、うちでは過去3年間、無料でPostgreSQLを使ってきました。そして、ある機能が欲しくて、それのためにSQL Serverライセンス1つ分程度の資金を提供しましたが、この機能はすべてのデータベースサーバで使用できて、最終製品に劇的な違いとなって反映されるわけですから」
Ramsey自身は、PostgreSQLの改善を目指した今回の機能開発を「概念的にはいいモデルだが、実際的なモデルではない」と考えている。
「今回なんとかかんとかうまくいったのは、当該アップグレードが特定コミュニティ（PostGISコミュニティ）内部で十分な将来価値を持つことを大勢のユーザが認めたという点と、信頼に足る中心的人物（Refractions社）がいて、コミュニティを奮い立たせたという点――この2点があったことに尽きます。わが社はPostGISコミュニティに信用がありましたから、自分から手を上げて、『これは重要で、役に立つ。だから応援する』と発言することで、協力者を得ることができました。スポンサーとなる組織の信用と潜在的賛同者の多さが鍵ですが、どの機能、どのオープンソースコミュニティにも期待できることではないでしょう。それに、信用できるプロジェクトであることを示すために、わが社は最初から資金を投じ、人も出しました。これも、あらゆる組織に期待できることではありません」
原文
