今こそオープンソースのデータベースを検討すべき理由がある

データベースもオープンソース・ソフトウェアを選ぶ敷居が大きく下がっている

　データベースシステムに関しては、実績を重視し商用製品を使い続けてきた長い歴史がある。しかしここ最近になり、PostgreSQLやMySQLなどオープンソースのデータベースへの関心が一気に高まっている。これは、商用データベースの高いコストに不満を持つことなどがきっかけだろう。さらに、これらオープンソースのデータベースがどんどん進化し、基本機能や性能などが商用データベースと遜色なくなってきたこともある。

　またビッグデータ活用が話題となり、注目を集めたNoSQLのデータベースのほとんどがオープンソースのソフトウェアであり、こんなところからもデータを蓄積し活用する領域でオープンソースのソフトウェアを使う敷居を大幅に下げているかもしれない。

　よほど高度な可用性でも求めない限り、新規で構築するシステムのデータベースにオープンソース・ソフトウェアを選択してもそれほど苦労することはないだろう。一方で利用実績が増えているとは言え、既存の商用データベースをオープンソースに乗り換えるのはそう簡単ではない。

　これはデータベースが変われば、多くの場合その上で動くアプリケーションも変更することになるからだ。どんなに互換性の高いデータベースを選んでも、既存の商用データベースと全く同じとはいかない。適宜SQLを書き換えたり、アプリケーションのプログラムコードを変更したり、場合によってはデータベースのロックの動きが異なることからプログラムロジックを変更する必要もあるかもしれない。これらはできることなら避けたいのが情報システム部門の意向だろう。

　仮にデータを移行するだけで済むようなシステムの場合でも、移行後のテストはしっかり行う必要がある。高い信頼性を求められるシステムの場合なら、かなりレアなケースについてもテストが必要となり、これには相当な手間と時間がかかる。移行の手間やコストを憂慮し、商用データベースからの移行を躊躇する話はよく耳にする。

　もう一つ注意するべきなのが、移行後の保守運用の体制だ。商用データベース製品なら、費用はかかるもののベンダーが提供するサポートサービスが十分に用意されており、なんらか問題が発生する前に対応するプロアクティブなサポートも期待できる。障害が発生した際の問題の切り分けなども、ベンダーのサポート担当者に任せることもできるだろう。

　一方でオープンソースのデータベースを選択した場合には、ライセンスコストやサポートコストは安くはなるが、問題が発生した際にはある程度自分たちの手で解決できなければならないだろう。バグやパッチなどの情報も自分で集めなければならず、パッチをいつ適用すべきかも自ら判断する必要がある。選んだオープンソースのデータベースが今後どんな進化をするかを把握するために、積極的に開発コミュニティに参加する必要もあるかもしれない。

　またベンダー製品であれば、専用の管理ツールやバックアップの仕組みなども用意されており、基本的にはそれらを採用することで運用管理はかなり楽になるはずだ。一方でオープンソースのデータベースの場合は、管理ツールやバックアップの仕組みなどはまだあまり充実していないことが多い。別のコミュニティが開発するオープンソースのソフトウェアや3rdパーティー製のツールなどもあるが、将来性なども考慮しながら自分たちで適宜選択し、組み合わせた際の動作検証なども自ら行う必要がある。