PHP:DOM:XMLを使用したアプリケーションについて
PHP (55 items)
2005年08月04日
ここ数ヶ月、とあるWEBサイトを開発中なんですが、
そこではXMLをログファイルとして扱ったシステムを構築してました。
その理由は、XMLをどうにかアプリケーションに組み入れたいというのが一番でしたが、
CSVやTEXTみたく、データを取り出す時に、
いちいち文字の位置やら、順番に意味付けするような仕組みより、
XMLで定義すれば、そのXMLを見ただけでもデータがわかりやすいし、
取り出すときも各ノードで取り出せるので、こりゃいいかなと思ってやったわけです。
・・しかし、数ヶ月間取り組んできましたが、
こりゃ実用的じゃないと判断し止めました。。
かなり決心が要りました(数ヶ月が無駄になる?)が、
やはりXMLはこのように使用するべきものではないなと思ったわけです。
これを経てわかった事。
まず、XMLはデータベースの様に扱うべきでない、
つまりデータサイズの大きくなるような用途では使うべきでないという事です。
そこではXMLをログファイルとして扱ったシステムを構築してました。
その理由は、XMLをどうにかアプリケーションに組み入れたいというのが一番でしたが、
CSVやTEXTみたく、データを取り出す時に、
いちいち文字の位置やら、順番に意味付けするような仕組みより、
XMLで定義すれば、そのXMLを見ただけでもデータがわかりやすいし、
取り出すときも各ノードで取り出せるので、こりゃいいかなと思ってやったわけです。
・・しかし、数ヶ月間取り組んできましたが、
こりゃ実用的じゃないと判断し止めました。。
かなり決心が要りました(数ヶ月が無駄になる?)が、
やはりXMLはこのように使用するべきものではないなと思ったわけです。
これを経てわかった事。
まず、XMLはデータベースの様に扱うべきでない、
つまりデータサイズの大きくなるような用途では使うべきでないという事です。
私の場合、PHPを使用したこのシステムで、
DOMとXSLTを使って、XMLデータを処理してました。
細かく言えば、ログデータ作成はDOMで行い、
そのログの内容を画面表示する際には、XSLTを使用していました。
通常のCSVやTEXTログを作成する場合は、
まあログファイルなんで、データは後ろに追加することしかできませんが、
DOMを使えば、追加だけでなく、XMLの更新(内容変更)ができるので、
非常に柔軟にログ作成ができます。
また、その内容を表示する場合には、
DOMでデータを舐めていかなくとも、XSLTで画面内容を定義しておけば、
ほとんどPHPによる画面編集ロジックが必要ありません。
また、XSLTにはソートや集計(SUM)等の関数が用意されているので、
データの計算も複雑なものでない限り、敏速に処理できます。
・・と、まあこの使用方法はいいと思います。
但し問題は、XMLデータが大きいものになった場合にあります。
上に書いた仕組みで作ったシステムは、結構軽快に動いてました。
データサイズが1メガ、2メガと越えていっても、
ストレスの無い速さで画面表示までされてました。
・・しかし、DOM=メモリ負荷と言われていますが、やはりその通り。
XMLのデータ構造、マシン環境にもよりますが、
私の場合は、XMLデータが5メガを越えてくると、
まさにこの仕組みは使い物にならなくなりました。。
DOMオブジェクトでXMLデータをロードした際、
XMLデータは全てメモリに読み込まれますので、
サイズが大きければその分メモリを食うのも当然です。
5メガのXMLだと、数秒〜数十秒かかりました。
つまりログ作成の処理で、XMLデータが大きくなればなるほど、
ロードするだけで時間が掛かってしまう事になります。
結果的に、もうこのDOMがメモリ食うのが一番の問題でした。
XSLTの方は5メガサイズであっても、正確には計ってませんが、
DOMよりかは早く、1秒前後で処理してました。
まあ、XSLTのライブラリはCで組まれているようなので、
この辺りは速いのかもしれません。
しかしXMLと言っても、要はTEXTファイルですし、
サイズを減らそうと思えば、ノードの名前を短くしたりする事で多少できますが、
わざわざその為だけに、一目見て無いようが解らないノード名では、
XMLの基本仕様に反するところがあるでしょう。
定義ファイルとしてXMLは色んな局面で使われている様に、
XMLデータは人間が目で見てもわかりやすいものでなくてはならないのです。
また、XMLは文字コードが絡むと非常にデリケート?でした。
XMLなんで、その中のデータはUTF-8で持っていましたが、
ここで日本語なんかが入ってくると厄介でした。
もちろん、mb_convert_encodingでエンコードしてからXMLに突っ込んでましたが、
それでも文字化けしてしまう日本語もあります。
そういうデータをXMLに書きこんでしまった場合。。
次のログ作成のXMLロード時に、XMLロードエラーとなってしまいます。
UTF-8のデータの中に、変に化けてしまった文字がUTF-8と認識されないので、
XMLデータをロードする事ができないのです、二度と。。。
つまり、そのログ(XML)は壊れてしまったと言えます。
・・・、これも使い物にならない要因の一つですね。
では、XMLを使ってどういうアプリケーションを組むのが良いか?
適しているのは、今流行のRSS、
そしてAjaxが絡んだ処理ではないでしょうか。
PHP・DOM・XSLTなどのキーワードは、RSSやらAjaxには必要となってくる技術です。
ってか、知ってると簡単にRSSリーダーなんかも作れますしね。
また、現在もよく使われている定義ファイルとして使うのも良いと思います。
定義ファイルであればサイズはそんなに膨らみませんし、
それこそ、CSVやTEXTなんかとは比べると、
遥かに柔軟な定義ファイルとして機能できます。
まあとにかく、個人的には数ヶ月自分で「できる」と信じてやってきた事が、
見事に結果として”不可”となった事で、かなり落ち込みましたが、
RSSや特にAjaxの登場で、やってきた事が無駄ではなかった事がわかりました。
そして、開発中のサイトですが、
もう少しで当サイトでも紹介したいと思ってます
DOMとXSLTを使って、XMLデータを処理してました。
細かく言えば、ログデータ作成はDOMで行い、
そのログの内容を画面表示する際には、XSLTを使用していました。
通常のCSVやTEXTログを作成する場合は、
まあログファイルなんで、データは後ろに追加することしかできませんが、
DOMを使えば、追加だけでなく、XMLの更新(内容変更)ができるので、
非常に柔軟にログ作成ができます。
また、その内容を表示する場合には、
DOMでデータを舐めていかなくとも、XSLTで画面内容を定義しておけば、
ほとんどPHPによる画面編集ロジックが必要ありません。
また、XSLTにはソートや集計(SUM)等の関数が用意されているので、
データの計算も複雑なものでない限り、敏速に処理できます。
・・と、まあこの使用方法はいいと思います。
但し問題は、XMLデータが大きいものになった場合にあります。
上に書いた仕組みで作ったシステムは、結構軽快に動いてました。
データサイズが1メガ、2メガと越えていっても、
ストレスの無い速さで画面表示までされてました。
・・しかし、DOM=メモリ負荷と言われていますが、やはりその通り。
XMLのデータ構造、マシン環境にもよりますが、
私の場合は、XMLデータが5メガを越えてくると、
まさにこの仕組みは使い物にならなくなりました。。
DOMオブジェクトでXMLデータをロードした際、
XMLデータは全てメモリに読み込まれますので、
サイズが大きければその分メモリを食うのも当然です。
5メガのXMLだと、数秒〜数十秒かかりました。
つまりログ作成の処理で、XMLデータが大きくなればなるほど、
ロードするだけで時間が掛かってしまう事になります。
結果的に、もうこのDOMがメモリ食うのが一番の問題でした。
XSLTの方は5メガサイズであっても、正確には計ってませんが、
DOMよりかは早く、1秒前後で処理してました。
まあ、XSLTのライブラリはCで組まれているようなので、
この辺りは速いのかもしれません。
しかしXMLと言っても、要はTEXTファイルですし、
サイズを減らそうと思えば、ノードの名前を短くしたりする事で多少できますが、
わざわざその為だけに、一目見て無いようが解らないノード名では、
XMLの基本仕様に反するところがあるでしょう。
定義ファイルとしてXMLは色んな局面で使われている様に、
XMLデータは人間が目で見てもわかりやすいものでなくてはならないのです。
また、XMLは文字コードが絡むと非常にデリケート?でした。
XMLなんで、その中のデータはUTF-8で持っていましたが、
ここで日本語なんかが入ってくると厄介でした。
もちろん、mb_convert_encodingでエンコードしてからXMLに突っ込んでましたが、
それでも文字化けしてしまう日本語もあります。
そういうデータをXMLに書きこんでしまった場合。。
次のログ作成のXMLロード時に、XMLロードエラーとなってしまいます。
UTF-8のデータの中に、変に化けてしまった文字がUTF-8と認識されないので、
XMLデータをロードする事ができないのです、二度と。。。
つまり、そのログ(XML)は壊れてしまったと言えます。
・・・、これも使い物にならない要因の一つですね。
では、XMLを使ってどういうアプリケーションを組むのが良いか?
適しているのは、今流行のRSS、
そしてAjaxが絡んだ処理ではないでしょうか。
PHP・DOM・XSLTなどのキーワードは、RSSやらAjaxには必要となってくる技術です。
ってか、知ってると簡単にRSSリーダーなんかも作れますしね。
また、現在もよく使われている定義ファイルとして使うのも良いと思います。
定義ファイルであればサイズはそんなに膨らみませんし、
それこそ、CSVやTEXTなんかとは比べると、
遥かに柔軟な定義ファイルとして機能できます。
まあとにかく、個人的には数ヶ月自分で「できる」と信じてやってきた事が、
見事に結果として”不可”となった事で、かなり落ち込みましたが、
RSSや特にAjaxの登場で、やってきた事が無駄ではなかった事がわかりました。
そして、開発中のサイトですが、
もう少しで当サイトでも紹介したいと思ってます
前の記事 次の記事