11．26

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
ファイルシステム・プロトコルを同時に提供
カタログアクセスなども、同じ方法でやる。
（ＭＣＡＴなどの独自検索はしない）
希望


ミドルウェアなどでは、ＤＢＭＳの機能がうまく見える
方が嬉しい。
単なるＳＱＬサーバではないから。
導出データと一貫性の管理
 トリガ
 仮想化・個人化
 アクセス権限の管理など
変にラップすると、このあたりの機能がまるで使えない。（た
だし、標準である必要がある）
 上記の点では、ＵＤＤＩやＬＤＡＰについては？がある。

議論


（先の方向性がＤＢ屋としては幸せ）
低レベルアクセスの位置づけ
WS-Federation

Diskアクセス


SAN/NAS,iSCSI
アクセスコントロール

スイッチ/VPN/FW
WS-Trust
WS-Security
SOAP/HTTP
FWなど
Ｇ
Ｒ
Ｉ
Ｄ
おまけ：Oracle的なソリューション

例えば、iFSのＧｒｉｄＦＴＰへの拡張を行う。





ＪａｖａＡＰＩを使ってユーザプログラムが可能。
実際のファイルシステムは分散したＯｒａｃｌｅ上に作る。
コピー管理や導出データ管理、更新に伴うデータ一
貫性の管理や系統・血統管理は、バックのＯｒａｃｌｅ側
のメカニズムや分散プロトコルを使う。（更新のイベン
ト通知など）
ＷＷＷサービス基盤にのせ・ＯＧＳＡ対応とする。
ＤＢ的には自然だが、応用に対して筋のよい解か？
Oracle iFS

ファイルシステム・プロトコルを話す関係データ
ベース




NFS,FTP,Samba,IMAP/SMTPなど。
応用から見ればファイルシステム（例えば、ＦＴＰサー
バ）で、同時にＳＱＬ問い合わせなどの機能「も」使える。
ＳＱＬから見た側の表のイメージは、定義・プログラム
可能（標準のパッケージがある）
プロトコルが拡張できる（プロトコル・サーバ）
ＳＱＬ
ＮＦＳ
ＦＴ
Ｐ
iFS
Oracle
仮想化
導出データ
トリガなど
Oracle Materialized View
ベースとなるデータと、それをもとに導出された
データとの一貫性を自動的に維持する。


ベースデータの更新時の処理をオプションで指定。
1.
2.
3.
4.


導出データを全部再計算
差分だけ計算・更新
2. をやってみて、だめなら1.をやる
しない
基幹データとサマリ・導出データやコピーの間
の一貫性などの保持に利用されている。
ＶｉｒｔｕａｌＤａｔａへの適用
対象処理（導出データを作れる処理）



ＳＱＬ＋Stored Procedure
ＤＢ処理に限られるともいえるし、
プログラム処理も扱えるともいえる。

インターフェイスとバインディング程度で指定できるも
の



プログラムはＪａｖａで記述
コールスペック（ＳＱＬとの接続関係の記述）は、Ｏｒａｃｌｅ側
で記述。
例


誰かの給与が２０％以上上がったら（ここはＤＢをチェック）、そ
のデータを渡してＪａｖａプログラムを起動とか。
大規模アプリ・ロングトランザクションへの対応は？
その他
一貫性（イベント発生によるトリガ、更新による自動処理起動など）
 バージョン管理（更新によるバージョンの管理。古いバージョンの利用）
 分散
（リモートアクセスの提供）
 個人化
（個人ごとの視野の提供）
 並列処理（クラスタリング）
 仮想化（仮想ビューの提供）
 ユーザ管理・アクセス権の制御（ＳＱＬを使ったきめ細かい管理）
など。


ＤＢの文脈に限れば、ある程度は実現されていて、似た機能を０から作る
か、ＤＢを単にＳＱＬサーバとして、その上でさらに上記機能を実現するミ
ドルウェアを作ることは、屋上屋的のようにも思える。

ＤＢＭＳはＳＱＬ処理を中心とした部分に限られるが、一般化の方向（つま
り、ＳＱＬだけでなく、普通のプログラム処理と組み合わせて上記の機能を
実現する方向）にあることも事実。

Download Report