(Brian Moran)

 私は以前に「StingerはYukonの夢を見るか?」(既報)という記事で,IBMの最新データベース・ソフト「DB2 UDB 8.2」(開発コード名Stinger)が,Microsoftの次期データベース・ソフト「SQL Server 2005」(開発コード名Yukon)に打撃を与えると書いた。データベース・エンジンにCLR(共通言語ランタイム)を実装する方式を,DB2が2004年秋に製品化で先手を打ったからだ。

 それ以来,私はDB2のCLRとSQL Server 2005のCLRについて調べてきた。そして,Microsoftの担当者と話をする機会を持った。私が話したのは,SQL Serverの製品マネージメント担当のディレクタTom Rizzo氏,CLR担当のグループ・プログラム・マネージャMahesh Prakriya氏,リレーショナル・データベース・エンジン担当のグループ・プログラム・マネージャBalaji Rathakrishnan氏―である。彼らは私に2つのデータベース・ソフトにおけるCLRの実装の違いに関する重要な情報を提供してくれた。

CLRのバージョンが異なる
プロセスの外か内かの違いがある

 まず,知っておかなければならないのは,DB2がサポートするのは「CLR 1.0」か「CLR 1.1」であり,SQL Server 2005がサポートするのは「CLR 2.0」であるということだ。

 CLR 2.0は豊富でより強力なホスティングのAPIセットを提供してくれる。公平にいうならCLR 2.0の開発環境である「Visual Studio 2005(VS 2005)」(開発コード名Whidbey)は,まだ出荷されていないので,IBMはCLR 2.0をサポートしようがない。しかし,Visual Studio 2005で利用可能になる豊富なAPIは,SQL Server 2005がCLRを「プロセス内」にホストするために,極めて重要なものだ。

 一方,DB2はCLRを「プロセス外」でホストする。これをIBMでは「フェンスド・モード」と呼んでいる。CLRをホストするのがプロセス内かプロセス外かという違いが,IBMのDB2とMicrosoftのSQL Server 2005におけるCLR実装の本質的な違いである。

SQL Server 2005の性能はDB2の7倍も
CLRの内部でダイナミックに最適化

 この違いは,安定した性能に差を引き起こす。Microsoftが私に語ってくれたラボのテストによると,CLRを実装したSQL Server 2005の性能は,プロセス外に実装したDB2の性能の7倍もあったという。

 さらに,Visual Studio 2005におけるホスティングの豊富なAPI群を使うと,SQL Serverに対して,プロセス内で何が起こったかを判断して,コア・エンジンがCLRをダイナミックに最適化できるようになる。

 DB2はCLRの古いバージョンに基づいているため,このようなことはできない。DB2は単純で,CLRのプロセスの内側で何が起こっているか知らないのだ。

 こう考えてみてほしい。SQL Serverにとって,CLRはOSと同じように稼働している。DB2とそのCLRは,その場その場のプロセスの処理以上のことはやらない。それは,2つのプロセスがお互いに勝手に話しているようなものだ。どちらのプロセスも他のプロセスに関する情報を持ち合わせていない。またどちらのプロセスも他のプロセスにおける活動状況についてインテリジェントな決定を下せない。

SQL Server 2005のCLRは
セキュリティに柔軟性がある

 セキュリティに関する違いも重要である。SQL Server 2005では,CLRが外部のリソースによってアクセスされるときに,オリジナルの呼び出し元を詐称されていても効果的に防げるようになっている。

 一方,DB2のCLRは,プロセス上もユーザー・レベル上も独立している。SQL Server 2000の「xp_cmdshell」と同じで,セキュリティ・モデルに柔軟性を備えていない。

 DB2は,CLRの実装においてUDT(ユーザー定義タイプ)とUDA(ユーザー定義属性)をサポートしていないが,SQL Server 2005はサポートしている。SQL Server 2005におけるCLRのアセンブリ(アプリケーションに相当)は,データベースの本質的な部分であり,データベースに保存されている。一方,DB2の実装においては,ファイル・システムに保存されていて,管理者は,バックアップをデータベースと別に実施しなければならない。作業も難しい。SQL Server 2005は,ホストの防御に関してより洗練されており,確実にユーザーを保護する。

 データベース・エンジン内において,危険なこと実行するような.NET APIの要求に対しては,ユーザーを保護してくれる。例えば,DB2のCLRプロシージャからGUI(グラフィカル・ユーザー・インターフェース)のダイアログ画面を開こうとすると,基本的に接続はハングする。DB2のCLRプロシージャは,「Environment.Exitメソッド」と呼ばれるものを実行する。これは基本的にDB2のCLRのインスタンスをシャットダウンする処理だ。一方,SQL Server 2005のCLRは操作が危険と考え,これを防いでくれる。

 Microsoftは,豊富なレベルでツールを提供し,Visual Studio 2005とよりぴったりな統合を実現している。例えば,SQL Server 2005は,Visual Studioのデバッガを使えば,CLRプロシージャに透過的にアクセスできる。しかし,DB2ではデバッグのため,CLRプロシージャに手動でアクセスしなければならない。DB2では,コア開発ツールの中にデバッグ機能を搭載していないからだ。

 MicrosoftとIBMのCLRの実装の違いに関する全体的なリストは長い。ここではいくつかのリンク集を紹介するに留めよう。

「Comparing SQL Server 2005 and IBM DB2 v8.2 as a Database Platform for Visual Studio and .NET Developers」
…Michael OteyとDenielle Oteyによる比較概要。

「SQL Server Chat: SQL Server 2005 Beta 2 CLR Q&A」
…SQL Server Worldwide Users Group(SSWUG)が協力した公開Webチャット。

MicrosoftのChris Brummeが運営するWebログ
…CLRに関するすごい情報が読める。