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