- - PR -
XMLDB：製品間のメリットデメリット
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-09-25 20:58
ちょうどXMLDBをいろいろ探していたので、早速「XMLデータベース製品カタログ 2003
」を読んでみました。 結論から言うと、ちょっと期待はずれでした。 「製品カタログ」という位置付けなので仕方ないのかも知れないですけど^^;各製品の持つメリットだけでなく、「デメリット」も書いて欲しかったですね。ベンダー各社のホームページやパンフレットを見ているのとあまり変わらない情報しか載せられていないように思います。 せっかくなので、有名な山田さんがそれぞれを使ってみた感想など、添えられると面白いのですが。。。ここへの書き込みを期待して(^o^)丿 また、それぞれ製品ごとに特徴が異なるので、同じXMLDBといっても適用分野が違うんではないかと思っています。 ＃これも山田さんの書き込みを期待して。。。 掲示板をご覧の皆さんで、いろいろなXMLDBを評価された方はいらっしゃるでしょうか？現場レベルでの書き込みなんかがあると、ぜひ見てみたいです！！あるいはすでにご使用の方。なぜその製品を選択されたのか、など聞ければいいですね。 | ||||
|
投稿日時: 2003-11-28 16:20
製品化ではなく Oracle 等の Object-Relational DB との性能比較が目的でしたが、eXcelon を使ったことがあります。
結論ですが、かなり小さいのデータの扱いでは良いものの、キャッシュのヒット率が極端に低い検索や大規模データの格納/検索でははるかに Oracle 8i には及びませんでした。 更に性能もさることながら、スケーラビリティの弱さにも閉口しました。 大規模データを 10 クライアントくらいから一斉に格納しようとすると極端に性能が落ち、ひどい場合はトランザクションが機能しない（途中までデータが格納された状態で終了する）という問題がありました。 eXcelon とは eXcelon Corporation が ObjectDesign International という名前だった頃から付き合いがありましたが、スケーラビリティは ObjectStore（ObjectDesign 時代の製品名）から変わっていませんでした。 なお、現状では改善されているかもしれません 
Yggdrasil や Tamino は名前とカタログくらいしか知りませんが、もし利用経験者がいらっしゃったら私も是非聞きたいです
| ||||
|
投稿日時: 2003-11-28 16:38
実際に案件でXIS(旧eXcelonのeXtensible Information ServerというXML DB製品)をデリバリしたことがあります。また、XISに対するクライアントアプリも書きました。 結論としては、XISの内部構造を理解した上でDBをきちんと設計しないと、かなりパフォーマンスが悪くなります。あと、検索した結果は一度クライアントに全て渡される(これはClient APIという機能を使う場合で、こうならないServer APIというのもあります)ため、クライアントのJVMのヒープを圧迫します。そのため、Server APIで一度検索結果を絞るコードを実装し(まあ、いわゆるストアドプロシジャみたいなものです)、それを使ってClient APIから検索結果を取得する、という二段構えをやったりもしました。 あと、DB内はファイルシステムみたいにフォルダとファイル(XMLファイルやそれ以外のファイル)で構成されますが、1フォルダ内のファイルやフォルダの数が2000くらいを超えると極端にパフォーマンスが落ちましたね。 # あんまり細かく言ってると読む人が読んだら私が誰だかバレてしまう、、、 実は、この時は余りにパフォーマンスが出なくてリリースが伸びたり(-_-;;  して、その後日本エクセロンのコンサルタントに来てもらって設計をやり直した経緯があります。その結果上記のようなやり方に落ち着きました。
つまり、デリバリするならコンサルタントを雇いましょう、という結論だったりして 
ちなみに、私はeXcelon関係者ではありません(^-^
| ||||
|
投稿日時: 2003-11-28 16:37
しまったー
eXcelon はカタログの中に入っていませんね。マイナー? 一応、古くからある native-object DB で DOM をそのままの形で格納できるものということで許してください 
| ||||
|
投稿日時: 2003-11-28 16:42
あら、そんなことないと思いますが
ところで、Yggdrasilについては職場で評価した人がいて聞いた話なんですが、基本的にあれはインデックスを工夫して検索を速くするというアーキテクチャで、検索は速いけど更新は遅いと聞きました。まあ、実際にデリバリしたわけではないので、あまりあてにはならないんですけれど、、、 Oracle9iが出たばかりの時にXML Typeというデータ型でXMLを扱うとどうなるかの評価もやっていましたが、これはDBの1カラムにXML文書を丸ごと放り込んでいるだけだそうで、検索は速いけど更新は結局「カラムデータを取り出す、XMLデータに展開、XMLデータを更新、カラムデータを更新」というステップを踏むため、遅いそうです。こちらはプロトの開発に使いましたが、実システムにはデリバリしていないので、こちらもあまりあてにはなりませんね、、、 | ||||
|
投稿日時: 2003-11-28 16:47
あっ、私がカタログを照会している内に返事が。
ちなみに、それぞれの DBMS が、チューニングも考慮していない最悪のケースでどの程度の性能を保障するかという調査だったので、Client API しか使っていなかったと思います。 でもそうすると、クライアントサイドのヒープ圧迫→GC→パフォーマンス低下という、XIS にはかなり分の悪い評価をしていたかも
最後の結論には大変納得いたしました 
| ||||
|
投稿日時: 2003-11-28 17:02
Oracle 9i の XML Type は Release 1 と Release 2 でかなり変更されていて、確かに Release 1 の時は CLOB に放り込むだけでした。更新手順は書かれた通りです。
Release 2 の直前で評価の仕事から離れてしまい、どういう内部構造になったのかは追えていません。個人的には 1 ノード=1 テーブルとして XML 全体はテーブルの結合で表現し、操作は何らかのビューを介して行うのかなと妄想（←飽くまでも妄想  ）したことはありますが。
（でも結合された膨大なテーブルを無矛盾で更新するのって効率面でダメです  ）
| ||||
|
投稿日時: 2003-11-30 18:24
自分で投稿したことも忘れかけていたころに、返信があってちょっとびっくりしているBunBunです。
機会があってTaminoをちょっと使ってみました。 個人的な感想を。 Taminoはスキーマが扱え拡張ではありますが、データ型などをいろいろと 設定できるので、RDBになれていると、入りやすいかなという印象です。 ただ、欠点はスキーマが無いとパフォーマンスがかなり落ちるとのこと。（これはTaminoの 方も認めていました） XMLをどういう位置付けで扱うか、によりますが、常に仕様が変更され（スパイラル開発？） データのスキーマもバンバン変わる様なものでは、Taminoをどう扱うかを考えないと、いけない のかなと。 逆に設計がきちんと固められるタイプであれば、Taminoはいいのかなと思いました。 またなにか使ってみたら報告します。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。