オープンソースDBの成熟度を計る［後編］

各製品の長所と短所を知り、採用・導入のシナリオを検討する

（2007年09月20日）

前のページへ < ｜1｜2｜3｜

オープンソースDBの進化の方向性

　本稿で取り上げた主要なオープンソースDBは、進化の方向性という観点から次の2つのグループに分類することができる（図6）。

●エンタープライズ向け指向のグループ
　MySQL、PostgreSQL、Ingres
●組み込み／ワークグループ向け指向のグループ
　Firebird、Apache Derby

　エンタープライズ指向のMySQL、PostgreSQL、Ingresについては、いずれも商用DBに匹敵する機能、性能を備えつつある。また、組み込み／ワークグループ向け指向のFirebird、Apache Derbyも、共に求められる要件を満たす能力が高い製品である。これらのDBに備わる技術や機能は、現在どのぐらいの成熟度に達しているのかを見ていこう。

図6：オープンソースDB／商用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にまとめた。

表2：さまざまなオープンソースDB

　さて、各オープンソースDBの特徴を踏まえて、実際にいくつかのシナリオを元に、ユーザー・ニーズと選択肢のマッチングを示してみたい。もちろん、前提条件として、初めからオープンソースDBを選ばないほうがよい場合もある（コラム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ならではと言えるだろう。

●ビジネス・インテリジェンス（BI）関連の機能。また、BIを容易に扱うための機能
●高度なXML機能や、XMLと既存データベースのハイブリッド統合
●大規模クラスタ・システムや高可用システムの構築

　また、自社がすでに特定の商用DBでビジネスを展開しており、そのモデルが適切である場合は、オープンソースDBへの移行というよりは、その商用DBのエントリー版などを検討するのが現実的な解である。

（月刊Computerworld 2007年8月号に掲載）

前のページへ < ｜1｜2｜3｜