PARTPART

3

コストメリットだけでの導入は危険

サービスレベルを意識した
オープンソース DB の正しい適用法
企業システムにおいて、オープンソースプロダクトが存混沌とした状況になってきた。そのため、システムへの在感を増してきている。古くから普及している Web

採用を検討する際に、いろいろと迷うケースも増えていサーバーやメールサーバーなどは言うに及ばず、グルーることだろう。本稿では、商用 DB とオープンソース

プウェアや CRM などの業務系アプリケーションでも勢DB を採用する際の判断基準について検討し、そこから力を拡大している。データベースの世界も例外ではな

見えてくるオープンソース DB の真のメリットを探ってい。今まで漠然とした棲み分けはあったが、ここへ来てみたい。

株式会社ビーブレイクシステムズ 上川伸彦 KAMIKAWA, Nobuhiko

鷲野秀次

WASHINO, Hidetsugu

3

サービスレベルを意識した
オープンソースDBの正しい適用法

る（もちろん他社製品にも対抗する）戦略
をとっていると言えるだろう。
こうしたベンダ各社の動きは、マーケッ
トにおけるオープンソースDB の認知度や¡ アプリケーションがDB に書き込み中でもインデックス構築が可能¡ 標準技術への準拠（SQL:2003 の機能が追加）

オープンソースを使用したシステムについての調査結果（図1）を見てみると、オー

存在感が非常に高まっていることの証拠と言えるのではないだろうか。

オープンソース DB の
高機能化

広がるオープンソース DBの適用分野

これらのほかにも200 以上の新機能や改プンソースは、今までは Web 系のような良が盛り込まれているが、特にエンタープ（多少の語弊はあるが）信頼性がそれほどライズシステムへの適用を視野に入れた機

高くなくても特に大きな問題にならないシ

能強化が目立っている。

ステムに導入されてきた。逆に言うと、基MySQL

一方のオープンソース DB においては、幹系のようなクリティカルなシステムではあまり導入されていなかったが、基幹系システムへの適用に対する期待についてはPostgreSQL（http://www.postgresql.or

MySQL は、スウェーデンのMySQL ABg/）とMySQL（http://www.mysql.com/）の創業者によって開発されたオープンソーの2 強でほとんどのシェアを分け合う構図

スのRDBMS である。オープンソースの標

一方、PostgreSQL やMySQL といったと言って良いだろう。ここで、両者につい

準的プラットフォームを意味する LAMP

オープンソース DB の最近の動向からも、て簡単に見ていこう。

（Linux、Apache、MySQL、PHP/Perl/Py

エンタープライズシステムへの適用を強くthon）という言葉に採用されるなど、世界意識した機能強化を続けていることが読みで最も有名なオープンソースDB として知取れる。これは、まさに次のような好循環

られる。

が生まれていることの証と言えるだろう。

「高まっている」と見ることができる。

以下、「ローエンド」と呼ぶことにする）、

ダ各社の意図は「有償版への呼び水」だけ

無償版商用 DB の台頭

十分運用に耐え得るスペックとなっている。

なのだろうか。そうではないと筆者は考え

当然、各ベンダの意図としては、無償版

る。躍進するオープンソースDB に対抗し、ご存知のように、現在では商用 DB のから有償版へと容易にアップグレードできユーザーや開発者の関心をオープンソース

PostgreSQL は、BSD ライセンスによりマーケットは、Oracle Database（日本オることからも分かるとおり、ユーザーがこDB から商用DB（当然、自社製品）に呼び配布されているオープンソースのRDBMS

検索処理や更新処理の速さを重要視してラクル）、SQL Server（マイクロソフト）、

れら無償版をエントリー向けに導入し、将戻すという目的もあるはずである。

である。米カリフォルニア大学バークレー

開発されており、特に更新よりも参照の頻¡ オープンソース DB の機能強化がユー

DB2（日本アイ・ビー・エム）の 3 強が分

来的にハイエンド向けの有償版へとアップ

無償版DB が狙うような、ローエンドシ

校の研究プロジェクトにて開発されたPO度の高いアプリケーションに向くとされてザーの関心を引き、「基幹系への導入」

け合う構図となっている。近年になって、グレードしていくことを期待しているのでステムを対象とするマーケットは確実に存

STGRES を起源とする。RDBMS 実装のいる。そのため、Web システム（一般的にの期待を高めている

これらのベンダ各社は、それぞれDB 製品あろう。システムを運用し続けていく中で在する。また、ローエンドだけにコスト低パイオニア的な役割を担ってきたが、ここ参照系の頻度が高い）への導入実績が多い。

¡「基幹系への導入」という期待に応えるの無償版（以下、無償版DB）を相次いでリ機能拡張や規模拡大は付きものであるか

減への圧力も強いはずだ。これは、現在にきて商用DB に比肩する機能を備えるよ

なお、MySQL は、ほかのオープンソース

方向でオープンソースDB の開発が進めリースした（表）。

ら、このような無償版提供の方向性は、

ローエンドシステムにオープンソースDB

うになってきた。Windows に対応した時プロジェクトと異なり、営利団体「MySQL

られている

各ベンダの無償版DB は、有償版の製品

ユーザーサイドから見ても商用DB を採用を採用する例が増えているという現象に如期がバージョン8 以降と最近であることもAB」が保持していて、GPL ライセンスとと比べて機能制限こそあるものの、開発専する敷居を下げるので、そのメリットは大実に現われている。このオープンソース

あり、Linux など PC-UNIX での導入実績

商用ライセンスのデュアルライセンスと用というわけでもなく、システムの特性にきいと言えそうだ。

DB の存在感が大きいマーケットにおいて、が多い。

なっている。

よっては（いろいろと議論の余地はあるが、しかし、無償版DB をリリースしたベン

ベンダ各社はオープンソースDB に対抗すPostgreSQL

2006 年 12 月 5 日にバージョン 8.2 をリ2005 年10 月にバージョン5.0 がリリースリースし、エンタープライズ向けの機能をされ、現在はMySQL EnterpriseとMySQL

さらに強化した。具体的には、主に以下のCommunity Server という2 系統が用意さOracle Database 10g Express Edition

Microsoft SQL Server 2005 Express Edition

DB2 Universal Database Express-C

性能改善、機能追加がなされている（性能れている。MySQL Enterprise は、その名最大 DB サイズ

4GB

4GB

無制限

改善には特に力が入っている）。

のとおり、性能面やセキュリティ面でエン最大メモリサイズ

1GB

1GB

4GB

最大 CPU 数

1CPU

1CPU

2CPU

稼動 OS

Windows/Linux

Windows

Windows/Linux

提供開始時期2006 年 2 月

2005 年 12 月

2006 年 1 月

その他機能制限¡以下の機能については一部提供されない
・RAC や Oracle Clusterware などのスケー
ラビリティ機能・Redo Apply/SQL Apply や Rolling Up
grades などの HA 機能
・Advanced Security Option や Encryp
tion toolkit などのセキュリティ機能・Oracle Data Mining や Oracle OLAP のBI 機能¡GUI 管理ツールには Management Studio ではなく SQL Server Express Manager という簡易版を利用¡オプション製品を購入することができない

表：主要 DB ベンダの無償版 DB¡以下の機能は提供されない・バックアップログ配布
・フルテキスト検索
・ SQL Agent job スケジューリングサービス
・インポート／エクスポート
・レポートビルダ¡以下の機能は提供されない
・Spatial Extenderクライアントおよびサンプル
・ Microsoft Cluster Server サポート・ Informix データソースサポート
・レプリケーションデータキャプチャー（SQL
レプリケーションおよび Qレプリケーション）
・ DB2 Web tools
・ GSKit

タープライズ向けの機能が備わっている。
¡ オンライントランザクション処理の性能が20 ％向上¡ メモリ上およびディスク上のソート処
理の高速化¡ マルチプロセッサ環境のスケーラビリ
ティ改善¡ ウォームスタンバイデータベース

GUI 管理画面ではネットワークやシステム負荷の現状などをグラフで確認でき、各種アラートの表示など、稼動中のシステムの問題をいち早く正確に把握できる。有料で各種のサポートも提供されている。
一方のMySQL Community Server は、

また、先日、IPA（独立行政法人 情報処
理推進機構）が行なっている「OSS 性能・信頼性評価プロジェクト」の成果が発表さ

60.9

Web系
データベース

44.8
51.6

情報系
データベース

40.7
14.1
17.4

グループ
ウェア
基幹系
データベース

6.3
23.8

数値計算／
解析用

1.6
2.9

その他

3.1
6.4

（％） 0

導入済み（N＝64）
導入意向あり（N＝172）

10 20 30 40 50 60 70

従来のGPL ライセンスで提供されるものだ。
図 1：オープンソースプロダクトを導入済み、あるいは導入意向のあるシステム（矢野経済研究所の発表記事より）

062 DB Magazine 2007 June

DB Magazine 2007 June

063

Special Feature 1

特集1

PART

3

サービスレベルを意識した
オープンソースDBの正しい適用法れたが注 1 、評価結果によると、「Postgre

オープンソース製品かで迷ってしまうよう

SQL や MySQL といったオープンソースなケースも増えていることと思う。そこで

DB はCPU 数のスケーラビリティが格段に以降では、その選択ポイントとして以下の向上し、チューニング次第で大幅な高速化

2 点に着目して考察してみたい。

グや複雑な運用などが必要となる

つまり、商用 DB かオープンソース DB

コスト

コスト
オープンソースDB

高機能化、
ノウハウ蓄積無償版の投入かの選択ポイントとしては、グラフの交点
商用DB

を分岐点と考え、対象システムのサービスや大規模対応が可能」とのことである。
詳細な情報や具体例はここでは省略する① コスト…システム開発／運用に関わるレベルが「オープンソースDB が有利」の領が、「OSS ミドルウェアの適用における課

トータルコストが適切かどうかという

域（分岐点より左側）なのか、「商用DB が題はもはや性能ではなく、信頼性や運用に判断有利」の領域（分岐点より右側）なのかを見関する要件を考慮した具体的な案件ベース② サービスレベル…システム要件（機能やの対応になってきている」とIPA はコメン

パフォーマンスなど）を実現できるかとトしている。すなわち、オープンソース

いう判断

DB が商用 DB に性能で劣る領域は、確実に狭くなってきているのである（チューニ

上記2 点に着目すると図 2 のようなグラングの難易度や運用性などもあり、一概にフを描くことができ、ここからは次のよう言い切れるわけではないが）。

なポイントが見えてこよう。

オープンソースDB

これからのマーケット

今までのマーケット
オープンソース
DBが有利

極めることが重要ということになる。

サービスレベルによる選択ポイント

商用DB

サービスレベルの高度化

オープンソースDBが有利

商用DBが有利

有利な領域を拡大させる
マーケットの創出

コスト低減により、有利な領域を拡大

サービスレベル

図 3 ：商用 DB の狙い

商用DBが有利サービスレベル

図 4 ：オープンソースの狙いことだけでなく、導入事例やノウハウ、開DB、コストをこれ以下に抑えるにはオー

すでに「使って当然」というような風潮に

このように、商用DB はライセンス料は発者を増やすことにより、あるサービスレ

プンソースDB、というような固定的な線なっている。Apache HTTP サーバーなどかかるが、サービスレベルが上がってもベルを実現する場合の開発／運用にかかる引きというよりも、常に「分岐点」を意識はその好例だろう。

チューニングなどの手間が少なく、開発／

コストをさらに低く抑えることである。そし、各プロジェクトの要件（システム要件

これに対して、DB サーバーは前述のよ運用にかかるコストの増大は少ない傾向にうすれば、より高いサービスレベルを実現のほか開発／運用メンバーのスキルなどもうな棲み分けを考えなければならないのだ¡ 一定水準のコストがかかるが、サービスある。一方のオープンソースDB はライセ

する場合でも、オープンソースDB がユー含む）を明確にした上で、コストやサービが、実際にオープンソースが使われる例はレベルにかかわらずコスト増減が少ない

ンス料は無料だが、サービスレベルが上がザーの選択肢に入ってくることだろう（図4）。

スレベルをきちんと見極める目が重要と

まだまだ少ない。やはり、Web サーバー

¡ サービスレベル（使用機能）にかかわらるにつれチューニングなどに手間暇をかけそのような視点で見ると、IPA によってなってくる。

のように「処理を行なう」ものではなく、ローエンドDB 市場への進出、そしてオー

ず、基本的にライセンス料がかかるる必要があり、開発／運用にかかるコスト

オープンソースソフトウェアの性能／信頼プンソースDB のハイエンドDB 市場への¡ サービスレベルを上げても、運用サポーが増大していく傾向にある。

性評価や、学校や教育現場へのオープン進出が顕著となっている。すなわち、商用ト機能などプロダクトの機能として含DB とオープンソース DB のカバー領域がまれる部分が多い

商用 DB

商用 DBかオープンソース DB
かの選択ポイント
ここまでで述べたように、商用 DB の確実に重なりつつあり、さらに重なる部分

オープンソース DB

が拡大し続けていることが激戦に拍車をか¡ 最小コストは低いが、サービスレベル

けていると言えそうだ。
ではユーザー側は、この状況をどのようにとらえれば良いのだろうか。商用製品か

注 1 ： http://ossipedia.ipa.go.jp/capacity/CS0702010349/

に従ってコストが増加する

ソース導入の推進など、オープンソース普発／運用にかかるコストを抑えることで、及促進の活動が行なわれているのも見逃せ

ライセンス料をどこまで挽回できるか」にない動きである。導入事例は確実に増え、一般論としては、ここまで説明してきたる。
（これも多少の語弊があるが）何かあっなる。この「開発／運用にかかるコスト」

その結果、次々に開発案件が後続し、ノウような棲み分けになっているのだが、筆者てもプログラムを修正すれば何とかなるについては、システムのサービスレベルがハウが蓄積され、ノウハウを持った開発者の経験上、実際の開発現場では必ずしもそWeb サーバーとは違い、何かあったらそ目的なので、刻々と適宜行なわれる処理ではなく、管理されるデータがすべてとな

高くなればなるほどオープンソースDB とも増えていくという好循環を後押ししていのような棲み分けが当てはまるわけではな

もそもの目的である「保存してあるデータ」の差が広がるので、ライセンス料を挽回でる。また、PostgreSQL 技術者認定試験やいようだ。

がなくなる（読めなくなる）かもしれない。

¡ サービスレベルを上げると、プロダク

きるチャンスが大きくなる。

MySQL 認定試験など、オープンソースDB

例えば、商用DB を採用しているシステの資格制度が普及してきていることも、好ム開発の現場で、現場の開発者はもとよ循環の推進力となっている（図 5）。

り、関係者の誰に聞いても「なぜ商用 DB

ト機能以外の機能の実装、チューニン

オープンソースDB

選択の分岐点商用DB

商用DBが有利サービスレベル

したがって、商用 DB の命題は「プロダト全体のシステム要件を、より高度なサー

ここまで、商用DB かオープンソースDBを使っているのか」という疑問に答えられ

ビスレベルへと導くこと」となる。そうすかについて、サービスレベルによる選択ポる人がいなかったり、見積もり時やシステ

れば、高度なサービスレベルを提供するに

イントを交えて説明してきた。しかしながム設計時のデータベース選択の際に、何のは商用 DB を用いるしかない（トータルコ

ら、商用 DB とオープンソース DB の「分疑問もなく当たり前のように商用DB の導ストが低い）という構図を作れるというこ岐点」がどこなのかについて、一概に言う入が決定されるなど、このようなことは誰とだ。さらに言うと、オープンソースDBことはできない。これは、各プロダクトのしも経験があるのではないだろうか。

が有利な領域に無償版DB を投入している、機能や商用DB のライセンス形態が刻々とこれは、データベース（というよりもと考えることもできよう（図 3）。

変わるのに加え、各プロジェクトの要件はデータ）の特性によるところが大きいと考さまざまだからである。

えられる。そもそもオープンソースプロダ

これに対してオープンソースDB の今後の課題は、プロダクトの機能品質を上げる

064 DB Magazine 2007 June

データベースは、データを保存するのが¡ ライセンス料が不要

コスト

図 2 ：商用 DB かオープンソース DB かの選択ポイント

オープンソース採用に立ちはだかる現場の壁極論を言うと、商用 DB の生命線は「開クトを高機能化することによってマーケッ

オープンソースDBが有利「データを保存する」ものだからだろうか。

したがって、この機能を使う場合は商用

DB サーバーでは、この「何かあったら」の不安の割合が非常に高いのである。
このように、「データを保存する」とい

導入事例
増加

資格制度
普及

オープン
ソースDB
普及

開発案件
後続

開発者
増加

クトは、いわゆる Web サーバーなどでは
図 5 ：オープンソース DB 普及の好循環

DB Magazine 2007 June

065

Special Feature 1

特集1

PART

3

サービスレベルを意識した
オープンソースDBの正しい適用法

う観点に立てば、商用 DB のほうが「何とは期待している。

と、基礎研究や非臨床試験が行なわれ、そ次のようなものであった。

である。

ベルに決まった。

なく安心」できるというのはうなずける。

もちろん、必ずしも「オープンソース＝の後「治験」に入る。治験が終了するとそ

今日飲むワインを選んでくれるソムリエ

サービスレベルが下がる」というわけではの結果が国によって審査され、審査に通る¡ 被験者を登録できること

よ、両 PJ ともに「データを確実に蓄積す■ 稼動時間：24 時間稼動と、数年後に飲むワインを保存しておくワ

ないが、サービスレベルを低くできるシスと市場に出回るのである（さらに、市場に¡ 被験者が治験に適合するかどうかを判る」「サービス時間を延ばす」という要件が■ データ保障：最後のトランザクション

インセラーを選ぶとしよう。あなたならど

テムに対しては、オープンソースが使いや出回った後で、再度、安全性や効き目を確

ちらを慎重に選ぶだろうか？ その感覚とすいというのは、導入事例を見ても分かる

かめる試験が行なわれる）。一般的に、成¡ 被験者に薬剤を割り付けること

タ量や同時アクセス数については、特に大■ 耐障害性：正副 2 台のホットスタンバ

似ていると思う。

イ。障害復旧時のダウンタイムゼロ

さて、細かい要件はいろいろあるにせ定すること特徴的なポイントとなっていた。またデー

終了時点まで自動復旧

とおり事実だと思う。ちなみに、当然のこ分の発見から審査の承認までに、およそ10¡ 適合しなかった被験者、薬剤を服用し規模というわけではなく、むしろ小規模と

この「何かあったら」という漠然としたとながら、サービスレベルを下げること

年程度はかかるものであり、その中でも治た被験者など、被験者を集計して表示言えるレベルであった（被験者数： 100 〜

不安は、リスク分析により不安の原因を具で、そのシステムを使う業務へのインパク験にかかる期間は3 〜7 年と一番長いと言すること数百名程度、同時アクセス：10 〜数十程度）。

このサービスレベル程度を図 6 のような体化した後に、リスクへの対策案を提示すトがあってはならない。そこはまさにSIer

われている。

すなわち、両 PJ での要件で非常に重要グラフで描けるとすれば、結果論になるることによって、ある程度は払拭できる。

の腕の見せ所になるのではないだろうか。

この治験において、薬の候補を服用する

もちろん、このほかにも細かい要件はなのがトランザクション量やボリュームでが、本 PJ においては商用 DB の選択肢がのが被験者である。治験によっては、被験あったが、基本的には非常に簡素なシステはなく、耐障害性や可用性だということが適切であったと判断ができる。

者となれるかどうかについて、年齢や性ムと言える。ただし、この PJ 固有の要件

分かっていただけたかと思う。

別、検査の結果などで厳しく制限される。

以外に、治験特有の要件として、データのまた、治験内容についての説明と同意（イ変更履歴をすべて残すというものがあっ

さて、筆者の関わったプロジェクト（以ンフォームドコンセント）がないと、そもた。つまり、治験システムでは、データが下、PJ）で、サービスレベルの検討により、そも被験者になることはできない。そのたどのように蓄積（入力／更新／削除）されデータベースを商用DB からオープンソー

め、被験者が同意した日付や検査結果の数ていったかが非常に重要なのである。

スDB に切り替えた事例があるので紹介し値などについて、きちんと管理することがでは、DB サーバーに関しては商用 DB

たい。紹介するのは、ある顧客における2求められる。

が最良の選択なのだろうか。もちろん、そつの PJ で、1 つ目の PJ が商用 DB を採用

うではないだろう。最近では、サービスレ

し、2 つ目のPJ がオープンソースDB を採ベルの考え方が浸透してきているので、用した。

り、治験システムが備えるべき基本的な機を明らかにしなければならないという意味

しかし、それでもなお、理詰めでは越えられない壁というのは存在するようで、「何となく安心」を選択するユーザーがいるこ

商用 DB とオープンソース
DB 導入のケーススタディ

とも事実である。

サービスレベルの考え方の浸透オープンソース
DB プロジェクト

商用 DB プロジェクト

一方のオープンソースDB プロジェクト
商用DB プロジェクトでは、下記のようでは、次のようなソフトウェア構成でシス

もっとも、治験終了後にデータを解析すなソフトウェア構成でシステムを構築する

テムを構築した。本 PJ においてはコストることにより薬剤の効果を明らかにし、当ことになった。この構成に決まった一番の低減の圧力が強く、オープンソースの採用

このように、被験者を登録／管理すると局の申請／承認プロセスを経て薬として認理由は、ユーザーにおけるそれまでの運用を強く要請されたこともあり、類似 PJ というのは、治験において非常に重要であ可されることを考えると、データの正当性実績であった。

して上で説明した商用DB プロジェクトがサービスレベルが上がればコストも上が2 つのPJ では基本的な部分が同じような能だと言える。2 つのPJ では、この基本的で、上記のような要件が発生するのは当然

り、サービスレベルを下げればコストも下機能であったこともあり、1 つ目のPJ で構な機能部分について、かなり似通った要件であろう。

がる、という意識が高まっている。

築したシステムを 2 つ目の PJ でもそのまを備えていた。

あるにもかかわらず、違うシステム構成を
OS ：Windows

採用する運びとなった。

DB ：Oracle9i
AP ：Tomcat

また、両PJ ともに、医師がWeb を介し

OS ：Linux

Web ：Apache

DB ：PostgreSQL

すなわち、「コストの大小によらず、あま使えないかということが検討された。こ

2 つのPJ で本システムを使った業務の流て直接システムを操作するので、使用できる程度のコストをかければ、もれなく最高の動きは、ちょうど 1 つ目の PJ が安定稼れを簡略化して説明すると、次のようになる。

る時間帯をできるだけ長くする必要があっ

この PJ では、サービスレベルの検討よ

品質のものが手に入る」というよりも、「コ動に入ったころに 2 つ目の PJ がスタートた。これは、診療時間内にシステムを操作

りもシステム構成が先に決まった感じでストに応じて品質（サービスレベル）が上したことも追い風となったのだが、細かい① 被験者が治験参加の意思を示すするのではなく、診療時間が終わった後にあった。そのため、サービスレベルについまた、オープンソースDB を採用するの下する」というのが常識となりつつある。

要件の違いにより断念するに至り、別の② 被験者が治験に適合するかを判断するシステムを操作したいという強い要望からては、次のように上記構成で可能な最高レで、サービスレベルを商用DB プロジェク

その意味では、ある程度品質を下げられるPJ としてスタートすることになった。

③ 被験者に治験の薬剤を割り付け、被験場合には、コストを抑えることができる

では、2 つのPJ に共通する要件を見ていオープンソースが最良の選択である、といこう。2 つのPJ ともに、治験の被験者を登うことも言えると思う。

録／管理するシステムである。

余談になるが、少し前だとファースト

先に、一般の人には馴染みのない用語、フード店で高級レストラン並みの味やサー治験と被験者について簡単に説明しておこ

ビスを求めるユーザーが、システム開発のう。
「治験」とは、新しい薬が誕生するた

現場では多かったように思う（もちろん原めの最終過程に、有効性と安全性の評価を

因はユーザーだけにあるのではないが）。

行なう制度を指す言葉である注 2。

この手の問題は、サービスレベルの考え方

新しい薬が誕生する全体のプロセスは次が浸透すれば、ある程度は解決すると筆者のとおりだ。まず薬の成分が発見される

Web ：Apache

者が治験薬を服用する④ 何か異常が発生した場合には、治験薬の服用を中止する

コスト

・24時間365日稼動・障害時には自動で全データを復旧
・障害復旧時のダウンタイムゼロ

コスト
オープンソースDB

・毎日一定時間メンテナンス停止
・障害時には手動でデータ復旧も行なう
・障害復旧時にはシステムを停止

オープンソースDB⑤ 上記について、適宜、進捗状況を確認
する
商用DB

商用DB
・深夜帯にはほとんど使用されない・障害発生確率と業務インパクトの再検討

つまり2 つのPJ 固有のシステム要件は、
オープンソースDBが有利

注 2：実際には、「薬の候補」を用いて国の承認を得るための成績を集める臨床試験のことを治験と呼ぶことが多い。

商用DBが有利

オープンソースDBが有利

サービスレベル

図 6 ：商用 DB プロジェクトの状況

066 DB Magazine 2007 June

AP ：Tomcat

商用DBが有利サービスレベル

図 7 ：オープンソース DB プロジェクトの状況

DB Magazine 2007 June

067

Special Feature 1

特集1

トと同レベルにすると、開発／運用コストなることで、提案バリエーションが増えるに特殊な要素があったり、長期にわたってが高くなる恐れがある。これは、図6 を見というメリットがある。今までの「食材がデータベースの使用が予想される場合など

ればお分かりいただけるだろう。そのた高いから料理も高い」世界に加えて、「安は特に注意が必要である。

め、本 PJ では、サービスレベルを、次のい食材が手に入るようになったので料理も

例えば、何かトラブルが発生した場合ように見直すことにした（図 7）。

安い」世界が生まれたことで、純粋に「料に、SIer がしっかりしている、あるいはサ

理人の腕前＝SIer の提案力／構築力」が問ポートサービスを提供している企業がある

われるようになってきている。このSIer にということであれば、対応は可能かもしれおけるメリットは、同時にユーザー企業のないが、基本的にはユーザー側の自己責任

選択の幅が広がるという意味で、ユーザーと考えておいたほうが良いだろう。

■ 稼動時間：0:00 〜6:00 をメンテナンス

時間として、システム停止■ データ保障：前日バックアップ取得時点まで（それ以降は手動復旧）■ 耐障害性：正副 2 台のホットスタンバ

企業のメリットにも直結していると筆者は考えている。

イ。障害復旧には、システムを止めて復旧作業を行なう

同様に、SIer がユーザーにオープンソー
スDB の採用を提案する場合も、こうした注意点やデメリット／リスクを総合的に検注意点およびデメリットとリスク

これならば、オープンソースDB を採用討した上で、ユーザーに提案すべきである。
＊＊＊

した場合でも、コストを抑えた現実的な運当然であるが、オープンソースDB の導以上、本パートでは、商用DB との比較用が可能だということが言えよう。これは入については、そのメリットだけでなく注を交えながらオープンソースDB のメリッ「オープンソース DB を採用する＝コスト

意点やデメリットについても知っておかな

トやデメリットを見てきたが、いかがだっ

低減」というイメージにとらわれず、サーければならない。

ただろうか。
要求されるコストとサービスレベルから

ビスレベルを落とさないとトータルコスト

まず注意したいのは、いわゆる「技に溺が膨れ上がるというサービスレベルの考えれる」ことである。技に溺れるとは、ここ

選択の「分岐点」を冷静に見極めることで、方があったからこそ、実現できたと言ってで言うと難しい技術や運用方法を採用する

オープンソースDB を商用DB 並みに適用良いだろう。

ことにより、実用に耐えないシステムとできることを簡単な事例とともに示した。

なってしまうことである。もちろん、これ

今後こうしたアプローチによる採用事例がはオープンソースDB に限った話ではない

増えることで、さらにノウハウが蓄積さが、現状では同じことをやろうとすると、

れ、低リスクでもより多くのメリットを享

商用 DB よりもオープンソースDB のほう受できるオープンソースDB システムの普が手間がかかることが多いので、技に溺れ及が進むものと筆者は考えている。

オープンソースのメリット
上で紹介した事例では、ユーザー企業で次のようなメリットが生まれた。

やすくもなるのである。
さらに言うと、オープンソースDB の一¡ 低コストでの開発（単純に、データベー

時的なコストメリット（ライセンス料が無スのライセンス料を無償とすることが償）に目を向けすぎて、現実に即した実現

できた）

可能性や運用コストに目が行かなくなる

上川伸彦（かみかわのぶひこ）（株）ビーブレイクシステムズ技術担当取締役。
大規模向けデータベース製品の開発、介護業
界、電子部品業界での EDI 標準メッセージな
どのオープンスタンダード仕様の策定や、SOA 構築基盤の設計に携わる。現在は、社内外の技術コミュニティ活動を推進する立場にある。

¡ サービスレベルや業務フローの見直しと、本番稼動後にトラブルが多発する可能（直接的なメリットではないが、オープ性が高まる。最近では、オープンソースがンソースDB の採用を検討したことで、一種の「流行り」になっているので、何が鷲野秀次（わしのひでつぐ）

サービスレベルや業務フローを再検討

何でもオープンソースというのではなく、して最新化できたのはメリットでもある）

現実に即した冷静な判断が求められる。

また、ユーザー企業以外にも、SIer にはり基本的に「自分の身は自分で守らなけ

とっては、オープンソースやサービスレベ

ればならない」という点は押さえておかな

ルを組み合わせて多種多様な提案が可能にければならない。システム要件として非常Java テクノロジスト。ASP、C++ などでの業務システム開発や独自言語での ERP パッ
ケージ開発を経て、自分の技術的な限界を知るために上京、Java 開発専業のビーブレイク
システムズに転職し、現在、Java 設計者として業務に携わっている。また、仕事面だけではなく社内サークルの中心的な存在としても活躍している。

次に、デメリットとリスクであるが、や068 DB Magazine 2007 June