 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||||||||||
|
||||||||||||||||||||
| コスト削減、スピードアップ……商用DBの異種データ接続は厳しい課題の連続 | ||||||||||||||||||||
|
さらに、もしデータベース管理者が上のような処理を行おうと思っても、自分でできなければ専門のデータ処理業者に発注するしかない。それだけで数百万円くらいのコストがかかってしまうのを、SQL Serverでは全部GUIでユーザ自身が処理できるようになっている。 こうしたビジネスの効率やコスト性といったレベルのユーザメリットまでを提供できて、商用データベースはようやく及第点になる。冒頭で「つながるかどうかは、もはや問題ではない」と書いたのは、そういうことなのである。 そうしたビジネス面でのアドバンテージを提供する最新のETLツールという視点から、SQL Server 2005のIntegration Servicesの性能をもう少し見てみよう。 エンタープライズ系ソリューションとして不可欠の条件の一つがスピードである。企業のデータベースシステムの場合、膨大なデータ量に加え、やはりバッチ型のシステムになりがちだ。限られた時間帯の中で最大限のパフォーマンスを要求されるシステムでは、処理性能も重要になってくる。 このためIntegration Servicesでは、スレッディングの技術を使って並列処理が行えるように、Windowsに最適化された変換サービスとしてアーキテクチャを刷新。この結果、SQL Server 2000に比べて600%という驚異的なバッチ性能の向上を遂げている。 これがさらに64bit化されるとなると、さらにIntegration Servicesの活躍するシーンは拡がっていくだろう。極端な話、UNIX＋OracleとUNIX＋Oracleのデータ変換にIntegration Servicesを使いたいというユーザがきっと出てくると、斎藤氏自身が予想しているほどだ。 商用データベースにおいては、異種データを扱えることは"前提"にすぎない。その前提であるデータ活用の能力と、その取り出し口であるアプリケーションまでをトータルに考えていなくては充分といえないのである。ユーザのビジネスの効率化やコスト抑制といった"成果"に結びついて、はじめて存在意義が認められるといっても過言ではないだろう。 |
||||||||||||||||||||
| OSS DBのデータ変換は、商用DBからOSS DBへの移行がらみが多いという事実 | ||||||||||||||||||||
|
さて、一方のOSSデータベースはどうだろうか。今回もこれまでに引き続き、PostgreSQLのエバンジェリストである株式会社SRAの石井達夫氏に伺ってみよう。 「異種データベース接続は、エンタープライズソリューションでは必須です。しかしOSSデータベースの場合は生まれてきた背景が商用データベースと異なりますので、PostgreSQLにしてもそうした機能を必ずしも完備しているわけではありません」 CSVなどの形式でデータを交換するのは現在でも可能だし、PostgreSQL ODBC Driverのようなものもある。また最近はデータをいったんXMLに落としてから交換する方法もあるが、これはXMLのエンジンがあるかどうかの問題で、データベースとは直接関係ない。 また、Oracleのスキーマを取り込むといった本当に簡単なツールならば存在するものの、SQL ServerのDTS（Integration Services）のようなパッケージの一部として実装している例はまだないのが実状だという。データベースエンジン自体が発展途上にあるOSSとしては、商用データベースのようにデータ交換機能だけを独立してアセンブルする段階ではまだないのだろう。 石井氏の経験では、異機種データベース同士をつなぐというよりも、「どうやったら商用データベースをPostgreSQLにコンバージョンできるか？」といった問い合わせの方が多いのだという。なるほど、こちらの方がユーザの問題としては切実である。 というのも、OracleからPostgreSQLならばともかく、これまでのシステムをInfomixで構築しているケースなどでは、今後どうしていいかわからないでいるユーザが本当に少なくないのだという。 念のため書き添えておくと、もちろんInfomix製品自体は現在も存在している。だが、IBM傘下に収まってからのバージョンアップのペースや製品ラインナップの動向を見る限り、将来的に大きな展開は期待できそうにないのが実状だ。少なくともDB2 UDBへの移行を考えるのでなければ、「では他にどういう未来図が？」と思うのは、至極当然のなりゆきだろう。 |
||||||||||||||||||||
| アメリカの"気象庁"における、商用DBからOSS DBへの移行事例が語るもの | ||||||||||||||||||||
|
さてInfomixからの移行だが、InfomixにはC言語のプログラムにSQLを埋め込めるツールがあり、これと同じようなツールがPostgreSQLにもあるのだそうだ。事実、このPostgreSQLのツールには「Infomix互換モード」といったものも設けられており、充分にInfomixからのデータ移行を意識していることが伺える。 石井氏が、InfomixからPostgreSQLへの移行で興味深い事例を紹介してくれた。アメリカのNWS（National Weather Service）が、2004年にInfomixからPostgreSQLへのマイグレーションを行ったというのだ。NWSは気象の観測や予報を担当するアメリカ合衆国の政府機関で、いわゆる日本の気象庁のような官庁だ。 この移行にあたってはSRAの子会社であるSRA AMERICAがコンサルティングとトレーニングを請け負った（注1）。日本の企業がアメリカの政府機関からITに関する技術業務を受託するのは極めて異例だが、それ以上にOSSデータベースがアメリカの公機関に採用されたこと自体、PostgreSQLのパフォーマンスが認められた画期的な事例と考えてよいだろう。
※注1：
詳しい情報は、2004年11月のニュースリリースを参照
http://www.sra.co.jp/public/sra/topics/topics2004/041119.shtml またOSSを採用するということは、少なくともソリューションの先を見越しているユーザならば、価格的に安いからといった単純な動機だけではない。自社内（自組織内）にそのOSSの技術者を自前で育成していこうという決意まで含んだ将来計画を持っていなければ不可能である。NWSの採用にも、そうした技術者育成というビジョンがあったのではと石井氏は見る。 |
||||||||||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
