DBMSから見た Data Grid 小島　功 （産総研グリッド研究センター）

プラットフォーム側が考える、 ＤａｔａＧｒｉｄに要求される機能 ＤＢ／ストレージが分散している。 データとメタデータを分離して、メタデータはある程度一括管理し、データは分散する。 複数のアクセス法を支援する。 例：ファイルシステムでもあり、関係ＤＢとも見える。 サーバでプロトコル変換 レプリカの管理を行う。 論理的なコレクションとファイルの管理、複製の一貫性管理

続き データのバージョン管理 動的な導出データ（生成方法ないしプログラムから要求時に動的に導出する） アクセス権・利用権制御 更新の管理 生成方法の記述・系統管理など アクセス権・利用権制御 他のツールとの連携

現状 Nirvana SRB(SDSC) Oracle iFS OGSA-DAIS Chimera などなど

プラットフォームシステム側の問題意識 汎用性・相互互換性 理由： 多様なプロトコルと互換があること。 　（ファイルシステム・ＤＢ） 独自のプロトコルをあまり使ってないこと。 （問い合わせ・データ転送など） 理由： 類似の背景を持つ応用がほかにもあること。 技術的に関連するアクティビティがあること。 データベース統合が応用分野ごとにあること。（地質、文献）、アーカイブ）

例 データウェアハウス 基幹系データから重要な情報を引き出し、解析などして経営に役立てる。 例　データウェアハウス 基幹系データから重要な情報を引き出し、解析などして経営に役立てる。 基幹系データ サマリ・加工結果 コピーなど OLAPツール 多次元分析 可視化 プログラム 処理 データ・マイニング 導出データの系統管理（血統木のようなもの）などが問題 （これは、Ｖｉｒｔｕａｌ　Ｄａｔａなどでも類似の問題がある）

例2： 現時点でＷｅｂサービスとして？ Ｗｅｂサービスアクティビティ Ｓｅｍａｎｔｉｃ Ｗｅｂ セキュリティ・トランザクション WS-Security/WS-Transaction/WS-XX ワークフロー・ビジネスフロー BPELなど グリッドにおける？ 標準化の方向 Ｗ３Ｃ（Ｎｏｔ　ＧＧＦ） Ｓｅｍａｎｔｉｃ　Ｗｅｂ

方向 ＯＧＳＡにより、ＳＯＡＰ／ＨＴＴＰベースのシステムアーキテクチャが非常に有効 ＤＢはＸＭＬデータサーバとしてみる。 ８０でほとんど全部すむ。 その上でセキュリティやデータベースアクセスなどのプロトコルを合意すればよい。 ＷＷＷサービスの標準化動向ともあう。 ＤＢはＸＭＬデータサーバとしてみる。 OGSA-DAIS XQuery(XPath)/XMLSchema ファイルシステム・プロトコルを同時に提供 カタログアクセスなども、同じ方法でやる。 　（ＭＣＡＴなどの独自検索はしない）

希望 ミドルウェアなどでは、ＤＢＭＳの機能がうまく見える方が嬉しい。 単なるＳＱＬサーバではないから。 導出データと一貫性の管理 トリガ 仮想化・個人化 アクセス権限の管理など 変にラップすると、このあたりの機能がまるで使えない。（ただし、標準である必要がある） 上記の点では、ＵＤＤＩやＬＤＡＰについては？がある。

議論 （先の方向性がＤＢ屋としては幸せ） 低レベルアクセスの位置づけ Diskアクセス アクセスコントロール SAN/NAS,iSCSI スイッチ/VPN/FW ＧＲＩＤ WS-Federation WS-Trust WS-Security SOAP/HTTP FWなど

おまけ：Oracle的なソリューション 例えば、iFSのＧｒｉｄＦＴＰへの拡張を行う。 　ＪａｖａＡＰＩを使ってユーザプログラムが可能。 実際のファイルシステムは分散したＯｒａｃｌｅ上に作る。 コピー管理や導出データ管理、更新に伴うデータ一貫性の管理や系統・血統管理は、バックのＯｒａｃｌｅ側のメカニズムや分散プロトコルを使う。（更新のイベント通知など） ＷＷＷサービス基盤にのせ・ＯＧＳＡ対応とする。 ＤＢ的には自然だが、応用に対して筋のよい解か？

Oracle iFS ファイルシステム・プロトコルを話す関係データベース NFS,FTP,Samba,IMAP/SMTPなど。 応用から見ればファイルシステム（例えば、ＦＴＰサーバ）で、同時にＳＱＬ問い合わせなどの機能「も」使える。 ＳＱＬから見た側の表のイメージは、定義・プログラム可能（標準のパッケージがある） プロトコルが拡張できる（プロトコル・サーバ） iFS ＳＱＬ Oracle ＮＦＳ 仮想化 導出データ トリガなど ＦＴＰ

Oracle Materialized View ベースとなるデータと、それをもとに導出されたデータとの一貫性を自動的に維持する。 ベースデータの更新時の処理をオプションで指定。 導出データを全部再計算 差分だけ計算・更新 2. をやってみて、だめなら1.をやる しない 基幹データとサマリ・導出データやコピーの間の一貫性などの保持に利用されている。 Ｖｉｒｔｕａｌ　Ｄａｔａへの適用

対象処理（導出データを作れる処理） ＳＱＬ＋Stored Procedure ＤＢ処理に限られるともいえるし、 プログラム処理も扱えるともいえる。 インターフェイスとバインディング程度で指定できるもの プログラムはＪａｖａで記述 コールスペック（ＳＱＬとの接続関係の記述）は、Ｏｒａｃｌｅ側で記述。 例 誰かの給与が２０％以上上がったら（ここはＤＢをチェック）、そのデータを渡してＪａｖａプログラムを起動とか。 大規模アプリ・ロングトランザクションへの対応は？

その他 一貫性 （イベント発生によるトリガ、更新による自動処理起動など） 一貫性　（イベント発生によるトリガ、更新による自動処理起動など） バージョン管理　（更新によるバージョンの管理。古いバージョンの利用） 分散　　　　（リモートアクセスの提供） 個人化　　（個人ごとの視野の提供） 並列処理　（クラスタリング） 仮想化　（仮想ビューの提供） ユーザ管理・アクセス権の制御　（ＳＱＬを使ったきめ細かい管理） など。 ＤＢの文脈に限れば、ある程度は実現されていて、似た機能を０から作るか、ＤＢを単にＳＱＬサーバとして、その上でさらに上記機能を実現するミドルウェアを作ることは、屋上屋的のようにも思える。 ＤＢＭＳはＳＱＬ処理を中心とした部分に限られるが、一般化の方向（つまり、ＳＱＬだけでなく、普通のプログラム処理と組み合わせて上記の機能を実現する方向）にあることも事実。