オープンソースDBの成熟度を計る［後編］
木村明治
キムラデービー 代表
Firebird http://www.firebirdsql.org/
商用DBから分岐した軽量かつ堅牢なDB
安定版：1.5.4、1.0.3／最新版：2.0.1／次期版：2.1
成り立ち
Firebirdは、コードギア（旧ボーランド、インプライズ）が開発した商用RDBMS「InterBase」を起源としている。InterBase自体は1983年に最初のバージョンが発表された、歴史ある製品である。2000年に「InterBase 6.0 Open Edition」を発表した時点で一度、ソースコードが公開されたが、その後撤回されて現在も商用RDBMSとして販売されている。このとき公開されたソースを元に、2002年、InterBase 6.0との完全互換性を目指したオープンソースDBとしてFirebird 1.0が誕生した。
技術・機能の特徴
■一昔前のマシンでも軽快に動作
Firebirdは、ベースとなったInterBaseの思想を受け継ぎ、メモリやディスク容量が潤沢ではない環境でも軽快に動作するのが売りである。
例えば、Firebirdの最新Windows版においても、メモリはOSの標準容量、ハードディスクは20MB以上もあれば動作する。なお、他のオープンソースDBと同様、Windows、Linux、FreeBSD、Solaris、HP-UX、Mac OS X（PPCおよびインテル版）に対応しているが、特にWindowsは10年以上前から対応しており、Windows 9x系までサポートする。
■柔軟な構成を可能にするインプロセス・ライブラリ
一般的なRDBMSでは、クライアント／サーバ（C/S）構成をとるのが一般的だが、Firebirdでは、C/Sのほかに、インプロセス・ライブラリにより組み込みDBとしての利用も可能だ。その際には、クライアント・プログラムをほとんど変更することなく、両モードを切り替えることができる（図5）。まずは組み込み構成で構築し、マルチユーザーやリモートで使いたくなった際に、C/S構成に変更することが容易に行えるのだ。
また、RDBMSでは、物理的なDBファイルは、指定ディレクトリ以下に複数のファイルで構成するのが一般的だが、Firebirdでは1つのDBに対して、1つの物理ファイルで構成する方式をとる。なお、指定により複数ファイルで構成することも可能だ。こうして、アプリケーションのデータ・ストアとしてハンドリングしやすい構成をとれるようになっている。
■過不足のないトリガ、プロシージャ、ビュー機能
軽量を身の上とし、Windows 9xにも対応しているからといっても、Firebirdは決して非力な環境に向けた目的限定型のRDBMSではない。むしろ、くせのない形でさまざまな用途に対応可能だ。SQL文は標準仕様と大きく異なることはなく、他のDBからの移行や一からの構築もスムーズに行える。ビューは更新可能なものを作成でき、「WITH CHECK OPTION」も設定可能だ。
トリガやストアド・プロシージャはPSQL（手続き型SQL）で、ユーザー定義関数はC/C++やDelphi言語で作成可能だ。これらは10年以上の実績がある。
■MPLから派生したIPL/IDPLをライセンスに採用
Firebirdのライセンスには、OSI承認のMPL（Mozilla Public License）のバリエーションであるIPL（Interbase Public License）とIDPL（Initial Developer’s Public License）が採用されており、いずれも商用・非商用にかかわらず無料で使える。IPLはInterBase由来のソースコードに、IDPLはFirebirdで新規に起こされたソースコードに適用される。
最新版／次期版の強化ポイント
2006年11月に2.0が発表され、最新版は2007年3月にリリースされた2.0.1となる。インデックス構造の改善とインデックス長上限の緩和、副問い合わせ（導出テーブル）、CANCEL構文、EXECUTE BLOCK構文、シーケンスや新しいカーソル構文のサポート、オプティマイザとバッファ・キャッシュの改善、従来からあるホット・バックアップに加えて、差分バックアップ・ツールの追加などが行われている。
次期版である2.1では、DBコアにあまり手を入れない形で便利な機能を追加する。DBトリガ、グローバル一時表、共通表式（CTE）や再帰問い合わせ、LIST関数やMERGE文などである。現在アルファ版が公開中で、今年中にはリリースされる見込みである。
選ぶ理由と選ばない理由
Firebirdの最大の長所は、「小さく始めて、大きく育てる」ことが可能な点だ。わずかなフットプリントながら、C/Sへの移行が可能であり、運用コストも低い点が支持を集めている。また、適用形態によらない、完全なフリーを実現している点も大きい。
一方、大規模環境での運用には機能が十分ではない点が欠点として挙げられる。それゆえ、大規模ユーザー事例の数も不足している。また、日本語情報や技術者の数も現状では十分とは言えない。
| Column 1：58カ国／1万以上のユーザー・ベースと成熟したエンタープライズ機能を持つIngres |
|---|
|
前編の図2に示したように、Ingresの先祖であるUCB版Ingresは、PostgreSQLの遠い先祖にあたるが、それ以外にも、「Sybase」「Microsoft SQL Server」「Tandem Non-Stop SQL」「CA-Universe」「Britton-Lee」「Wang PACE」といったDBの由来となっている。一方、商用のIngresは、旧イングレス、アスク、コンピュータ・アソシエイツ（現CA）を経て、2006年にはCAから分離独立した新生イングレスからGNU GPLと商用のデュアル・ライセンスで提供されている。 このように紆余曲折を経てはいるが、Ingresは58カ国／1万以上のユーザーを擁し、他のオープンソースDBが最近のバージョンでサポートないしはサポート予定のエンタープライズ向け機能を古くから備え、成熟度を高めている。例えば、レプリケーションは1994年に、クラスタリングやテーブル・パーティショニングは2004年にサポート済みである。 2007年2月、イングレスは新たな試みとして、ソフトウェア・スタックのOSとDBを統合した「Icebreaker」を発表した。同ソフトも含めて顧客基盤の拡大とブランドの再構築を目標に活動中である。 |
Apache Derby/JavaDB http://db.apache.org/derby/
Javaで構築されたオープンソースDB
最新版：10.2／旧版：10.1
成り立ち
Apache Derbyの起源は、クラウドスケープが1997年にリリースした「JBMS」というDBである。その後、同社はインフォミックス・ソフトウェアに買収され、そのインフォミックスは2001年にIBM傘下となり、JBMSは「IBM Cloudscape」という製品名で販売された。
IBMは2004年、Apache Software FoundationにCloudscapeのソースコードを寄贈する。しばらくはApacheのインキュベーター・プロジェクトであったが、2005年8月に「Apache Derby」プロジェクトに格上げされ、バージョン10.1.10がリリースされた。その後、バグ・フィックスやマイナーな改善を続け、最新版は10.2 となる。
技術・機能の特徴
■XML対応に強いPure Java DB
Apache DerbyはJavaで構築されたRDBMSであり、XML機能（XMLタイプ、XMLPARSE、XMLSERIALIZE、XMLEXISTS、 XQUERY）がサポートされている。JDBCはバージョン4で仕様上はXMLが扱えるようになった。Derbyの現行バージョンは、java.sql.SQLXMLをサポートしていないが、今後のサポートが期待できる。
■組み込みとC/Sに両対応
元来、組み込み向けDBであったため、Apache Derbyのサイズは数MBでフットプリントが小さい。バージョン10.1でオープンソースのJDBCネットワーク・ドライバが追加されたことにより、マルチユーザー、マルチコネクション、スレッド・セーフなC/Sモードで動作させることが可能になった。また、10.1ではオンライン・バックアップに対応したが、ライタをブロックするものだった。そこで10.2ではブロックせずにオンライン・バックアップができるように改良された。
■SQL認証モードとDB暗号化を装備
10.2 からレガシー認証モードに加え、SQL認証モードが追加された（derby.database.sqlAuthorization=true）。GRANT/REVOKEステートメントが可能になり、DBのモード変更は不可で、ユーザーは自スキーマ上のみでSQLオブジェクトを作成できる。
DBの暗号化機能は10.1から標準で備えている。同バージョンでの暗号化機能はDB作成時のみ利用できたが、10.2からは暗号化がなされていない既存のDBを暗号化することや、すでに暗号化されているDBのキー変更が可能になった。
選ぶ理由と選ばない理由
Apache Derbyを積極的に選ぶ理由としては、Pure Java DBとして、Javaアプリケーションとのスムーズな統合が可能である点がまず挙げられる。なお、Java SE 6より「JavaDB」としてApache Derbyが標準で添付されるようになった。また、インプロセス・ライブラリを利用してのアプリケーションとの連携が可能である点や、今後、XML機能のさらなる拡張が期待できる点もアドバンテージと言える。一方、欠点としては、大規模DBの構築には向かない点と、日本語情報や技術者の数が少ない点が挙げられる。
オープンソースDBの進化の方向性
本稿で取り上げた主要なオープンソースDBは、進化の方向性という観点から次の2つのグループに分類することができる（図6）。
●エンタープライズ向け指向のグループ
MySQL、PostgreSQL、Ingres
●組み込み／ワークグループ向け指向のグループ
Firebird、Apache Derby
エンタープライズ指向のMySQL、 PostgreSQL、Ingresについては、いずれも商用DBに匹敵する機能、性能を備えつつある。また、組み込み／ワークグループ向け指向のFirebird、Apache Derbyも、共に求められる要件を満たす能力が高い製品である。これらのDBに備わる技術や機能は、現在どのぐらいの成熟度に達しているのかを見ていこう。
エンタープライズ向け機能の成熟度
ここでは、代表的なエンタープライズ向け機能の1つであるテーブル・パーティショニング機能を例にとって見ていくことにする。これは、データの特性や利用目的に合わせて、1つの表を複数に分割して管理することを可能にするものだ。
Ingresでは2004年リリースのr3で、PostgreSQLでは2005年リリースの8.0で、テーブル・パーティショニング機能が実用的なものに改善された。MySQLについては次期版の5.1で実装される予定だ。
一方、商用DBでは、2000年以前より同機能を実装している製品が存在し、現在では、レンジ、リスト、ハッシュや、それらを併用する形でのテーブル・パーティショニングも可能になるなど成熟度を高めている。
このように、テーブル・パーティショニング機能に関しては商用DBのほうが充実していることがわかる。現行バージョンで同機能が未実装のMySQLについては次期版の登場が待たれるところだが、同機能を必要とするMySQLユーザーは、マスタ分割や参照分割を用いるなど、運用上の工夫を行うことで同等の効果を得ることができる。
組み込み／ワークグループ向け機能の成熟度
FirebirdやApache Derbyは、インプロセスのライブラリとしても組み込み可能な点や、フットプリントの小ささと軽快な動作、専任のDB管理者が不要な点が共通の特徴として挙げられる。こうした組み込み／ワークグループ向け指向のオープンソースDBについては、もともと商用DBが主戦場としなかった領域での機能強化にフォーカスしており、それを最新バージョンでも保っていると言える。
それに加えて、両DBとも、それぞれ独自の持ち味がより強調される方向にある。Javaで構築されたApache Derbyは当然、Javaとの親和性が高く、またXML、JDBCとの適合性も向上させてきている。Firebirdは、インデックスの制限値やテーブルの上限値といった旧来の制限を撤廃し、求められる範囲でのセキュリティおよびSQL機能の強化が施されている。
商用であれ、オープンソースであれ、DBを導入し利用する側からすると、備わる機能が明確で、それらの機能が導入目的の要件を満たせるものならばよいことになる。ITマネジャーにとっては、要件を満たす部分が標準で用意されているのか、用意されていない場合は、リーズナブルな工数で作り込むことができるのか、その作り込みは自社で可能なのか、SIerに委ねるのか、といった見極めが重要になってくる。
オープンソースDB導入のシナリオ
前節までに取り上げた製品以外のオープンソースDBについては、主要なものを表2にまとめた。
さて、各オープンソースDBの特徴を踏まえて、実際にいくつかのシナリオを元に、ユーザー・ニーズと選択肢のマッチングを示してみたい。もちろん、前提条件として、初めからオープンソースDBを選ばないほうがよい場合もある（Column 2を参照）。
シナリオ1｜社内ツールのデータ・ストア
業務用に自社内で利用する小規模なツールのデータ・ストアとして採用する。本格的なDBでは環境設定や運用の面で大げさにすぎるケースでは、インプロセスで扱えるFirebird、MySQL、Apache Derbyなどを使うことで手軽に構築でき、その後のデータの取り回しもSQLベースで行えるようになる。また、いったん構築した後の、リモートやマルチユーザー対応といった拡張も問題なく行える。
シナリオ2｜アプリケーションへの組み込み
DB組み込み型のアプリケーションを開発する際に採用する。それまで商用DBや、機能制限のある商用DBの無料版、提供形態により商用ライセンスが必要なオープンソースDBなどを使っているケースで、そのDB部分を置き換えるという用途だ。
オープンソースDBに変更することにより、ライセンス料がかからず、かつ、機能制限のないアプリケーションの開発が可能になる。特に、ベンダーやSIerが販売数の少ない特定業務アプリケーションを開発するケースで効果が大きい。開発コストを抑えることで、価格を下げることができるので、アプリケーションのエントリー版の提供といったことが可能になる。この用途には、FirebirdやApache Derbyが適している。
シナリオ3｜旧バージョンの商用DBからの移行
ビジネスの成長と共に規模（データ量、ユーザー数、トランザクション数）が拡大するようなシステムでは、商用DBを使い続け、最新版にバージョンアップする動機がある。だが、長年運用してきてトラフィックの伸びも先が見えているようなシステムにおいては、バージョンアップする必要性に乏しいことが多々ある。つまり、“そこそこの機能・性能”で要件が満たせる場合だ。
商用DBの場合、旧版のサポートが永続提供されることはなく、対応OSは更新されないままだ。そこで、オープンソースDBに移行することで、同じバージョンを最新のOS上で使い続けたり、メンテナンス工数を下げたりすることが可能になる。この用途では、Firebird、MySQL、PostgreSQLが適している。
なお、商用DBの移行を主目的としたオープンソースDBベースの製品も存在する。PostgreSQLをベースとした「EnterpriseDB」や、Firebirdをベースとした「Fyracle」がそれで、共にOracle互換DBである。
EnterpriseDBは、ルック＆フィールをOracle DBに合わせて教育・運用コストを下げることを目指した製品だ。PostgreSQLベースということで、特にエンタープライズ・システムでの移行ニーズにこたえる製品と言える。また、Fyracleは、Oracle 7/8辺りのバージョンを用いたワークグループ／ミッドレンジのOracleシステムを、Firebirdの特徴を生かす形で移行することを促す製品である。
シナリオ4｜運用中の商用DBからの移行
商用DBは豊富な機能を備え、バージョンアップとともにそれらを成熟させているため、そのフル機能を生かしたシステムの場合、オープンソースDBへの移行は不可能に近いかもしれない。
しかし、商用DBのフル機能を使いこなしているというケースは実際のところまれであり、システム構築時と、その後の運用時の要件を明確にして適用範囲を限れば、既存の商用DBを用いたシステムの移行や新規開発は十分可能だ。ただし、要件を満たすために作り込みなどが必要になる場合、それを自社のIT/IS部門で行うのか、SIerに委ねるのかによって、トータルで要するコストは変わってくる。工数をかけて無理やり作り込むようなことがあれば本末転倒で、妥当な工数で実現できるよう、要件を落とし込んでいく必要がある。注意すべきは、移行後のオープンソースDBの機能・性能の限界とその対処方法などを自社IT部門やシステムのSIerが事前に把握しておくことである。そして、それらをオープンソースDBの開発元にフィードバックすることにより、より適用範囲を広げていけるような関係作りが望ましい。
この用途にはMySQL、PostgreSQL、Ingresが適している。これらはすべてエンタープライズ・システムへの適用を視野に入れた機能・性能強化が継続的に行われているからだ。
以上、本稿では代表的なオープンソースDBを取り上げて、その特徴や機能の成熟度について言及し、そのあと、シナリオを提示しながら企業での導入メリットや課題について説明してきた。読者の皆さんがオープンソースDBを選択する際の一助となれば幸いである。
| Column 2：初めからオープンソースDBを選ばないほうがよいケース |
|---|
|
シナリオ4でも述べたように、オープンソースDBは、商用RDBMSの豊富な機能をそのまま移行したり、代替したりできるものではない。よって、商用RDBMSに備わる最新の機能が必要になることが明らかである場合には、初めからオープンソースDBを選択肢から外すことになる。特に、以下のような機能は、現時点では商用DBならではと言えるだろう。
また、自社がすでに特定の商用DBでビジネスを展開しており、そのモデルが適切である場合は、オープンソースDBへの移行というよりは、その商用DBのエントリー版などを検討するのが現実的な解である。 |
（月刊Computerworld 2007年8月号に掲載）
提供：Computerworld.jp
