CMSを利用してみて思うこと

CMSって・・・

　当サイトにも、いよいよというかPloneのプロダクツであるところの「CoreBlog2」というものを入れてみました。ブログなるものをこのサイトでもちょこちょこと書いていこうと思います。
　そうですねぇ、この1ヶ月ほど、ＣＭＳなるものをいじってみて、ようやくというか、思ったようなものになりつつあるのかなぁ？
　思えば、最初はDotNetNukeからでした・・・。

　インストールに苦戦したことは、so-netのブログに書いたとおりですが、機能的にはとても良いのではないかと思います。（どこが？といわれると、ちょっともう記憶が薄れているのではっきり言えないですけど・・・(^^;）
　さていよいよコンテンツを揃えて公開するぞ・・・という段階になってコケてしまいまして・・・。（悪いのは、私のＰＣ環境＋構築力の無さだと思います。決してDotNetNukeのせいではありません。）

　ということで、登場するのはPlone！
　目下勉学中の身ですけど、出会えて良かったと思います（マジで・・・）。そうですねぇ、「求めよさらば与えられん」というか、絶望の淵で一筋の光明を見出しました。
　MAGICやってる身ですし、DotNetNukeなら、使ってるSQL Serverのデータベースにアクセスできるのが分かったんですよ。で、もしかしたらちょっとした連携なんかもできるかなと思ってた矢先の出来事でした。ですけど、未練はありません。なんかPloneでの可能性を探したいと思います。

　で、某書籍を購入してきて、カスタマイズし始めるんですけど、これがまた楽しいと言うか、奥が深いというか・・・。ちょっとハマりました。
　

　まぁ書けばきりがないんですが、ようやくコツみたいなのが分かってきたところです。でもまだまだどうやればいいのかななんてことが沢山あるんですけど、先人が残したノウハウみたいのがｗｅｂで公開されていてとても助かりました。
　参考にさせて頂いたのは下記のサイトです。（まだ、そのごく一部しか身についていませんが・・・）

http://takanory.net/
http://www.liris.org/
http://www005.upp.so-net.ne.jp/nakagami/

で、表題の「ＣＭＳって・・・」の答えですけど、うーん一言では難しいなぁ・・・。(^^;今までは静的なＷｅｂページだとか、例えばＭＡＧＩＣで作るＷｅｂアプリだとか、はたまたＡＳＰのプログラムだとか、そういう角度の観点しか頭に無かったんですけど、例えば「ＲＳＳ」だとか「Ｗｅｂ２．０」とかと同レベルで「新しい技術として取り組まなければならないもの」として位置付けられるようになりました。
　そういう意味では、Ploneを世に出して下さった方々、先人の皆さんへはただただ感謝ですね。そしてこういった新しい技術によって作られる未来が素晴らしいものとなることを祈ります・・・。

Category(s): misc

Permalink

ＭＡＧＩＣリッチクライアント先取りセミナー

　今日、「ＭＡＧＩＣリッチクライアントセミナー」なるイベントに行ってきました。
　「これは凄い！」の一言でした。
　今までなかなか掴めなかったイメージも「百聞は一見にしかず」で、なるほどと思うような箇所が幾つもありました。
　そうですね、一番の疑問は、「３階層のアプリケーションを、どうやって通常のオンラインアプリケーションと同じような編集で実現できるのか？」というものだったんですが、どうやらクライアントロジック、サーバロジックの分離はＭＡＧＩＣが自動的にやってくれるという、なんとも有り難い仕組みのようです。（コーディングすると、「ロジック」タブ画面に、サーバ側の処理なのか、クライアント側の処理なのかを自動的に区別して表示してくれる模様・・・）
　ＭＡＧＩＣをやっている会社にとっては、まさに「朗報」です！

　当社としても、アプリケーションの「ＭＡＧＩＣ　リッチクライアント化」及び、「リッチクライアントを想定したアプリケーション開発」を推進していきたいと思います。

Category(s): misc; dbMAGIC

DB2のアクセスプラン

アクセスプランって何？

　某勉強会でここ数ヶ月のテーマになっているアクセスプランなのですが、いつも講義を受けっぱなしという状態だったので、そこから少し脱却すべく、最近の週末の休みを利用して、自分でいじってみました。（いわゆる復習というヤツです。）
　「アクセスプランって何だ？」という話をしだすとちょっと長くなるのでやめておきたいのですが、一言だけ・・・。
　私がこの単語（アクセスプラン）を知ったのは正直に言えばまだ１年位前のことにしかなりません。ＳＱＬ系のＲＤＢＭＳでは当たり前の話のようですが、それ以前はＤＢ２のようなインテリジェンスなＲＤＢＭＳは使っていませんでしたので・・・。
　私がそれまで持っていた概念としては、「インデックスを使ったアクセスは常に速い！」とか、「インデックスを使わせるために、そのインデックスの項目をORDER BY句に入れれば良いじゃん！」とか、そういう固定的な観念がありました。
　しかし、どうやら最近のＲＤＢＭＳは違う様です・・・。
　インデックスを使うように仕向けても、使ってくれないことがあるようですし、インデックススキャンになるか表スキャンになるかはＳＱＬオプティマイザー次第だとか、その他もろもろ・・・。
　まず、ここにショックを受けたわけですね。

とりあえず取得ツールを作る

　アクセスプランが何かという話の詳細は、「DB2 UDB アクセス・プラン速習」という有名な連載記事がありまして、詳しく書かれていますので是非ご参照下さい。　（私も目下勉強中です。(^^;）

　何をすれば良いかというと、(1)詳細なEXPLAINの取得と(2)ＳＱＬの実行時間の計測です。
　EXPLAINの取得は、ＳＱＬ文を用意し、スクリプトを実行します。
　次のような処理を記載したバッチファイルを作成し、引数にスクリプト名を付けて実行すればＯＫです。

db2 connect to sample
db2 set current explain mode explain
db2 -tf %1.sql
db2 set current explain mode no
db2exfmt -d sample -e db2admin -n %% -s %% -w -1 -# 0 -o %1exp.txt

ここで、sampleはデータベース、db2adminはスキーマ名なので、適当に修正する必要があります。
　なお、このバッチファイルは、２段階になっていて、データベースに接続するところから始まりexplain mode を切り替えてＳＱＬを実行するまでの部分と、その後のdb2exfmtを実行する部分です。

　ＳＱＬの実行時間の計測については、db2batchユーティリティを起動します。下記のようなバッチファイル作成して実行すればＯＫです。

db2batch -d sample -f %1.sql -o p 3 e 2 -r %1p.txt

　確かに両者ともスクリプトでできるのですが、日頃の開発作業の現場では、スクリプトはどこにあったのかを探したり、それをまた書き直したりするのが結構煩わしいですし、何をどうすれば良いのかすら忘れてしまいがちです。ということで、私の場合は、某ツールを使ってＧＵＩのフォームを作ってみました。
　下記の画面がソレです。

　プログラムといっても、入力テキストをファイルに書き出したり、実行するプログラムをコールする程度のものなので、週末の半日もあれば出来上がります。
　操作はコントロールセンターと同じようなインタフェースにしました。データベースをコンボボックスで選択して、スクリプトを貼り付けてから実行ボタンを押せば、結果がタブに表示されるという仕組みです。

　まぁ、スクリプトをいちいち修正しながらテストするよりは気が利いているのではないでしょうか？
（次の解析ツールのバージョンアップ版には組み込んで、使えるようにしたいと思っています。）

　工夫した点は次の箇所です。

データベースの一覧を取得するようにして、コンボボックスで切り替えできるようにしました。
起動時に、「list database directory」を実行して一覧を取得しています。
デリミタを指定できるようにしました。
　XQueryを含むＳＱＬ文では、セミコロンは使われるので、デリミタ指定は必要な機能ですね。
　それとＳＱＬ文の記載で末尾等に入力を省略してしまった場合は、内部的に自動付加するようにしてあります。これをしないと、何故かdb2batchでは結果が全く出てこないみたいで・・・。
　ちなみに、db2batchを起動する場合に、デリミタの指定は読み込ませるＳＱＬ文を記載したファイルの先頭に「--#SET DELIMITER #」等を付加しなければならないようです。
スクリプト実行時にログを書き出し、そのテキストで処理結果を判定できるようにしました。
　スクリプトの実行は「db2cmd」で行い、「-z」オプションによりログを書き出すようにしてあります。　このログでの結果取得は後の処理判定で利用されます。もしＳＱＬ文にエラーが無い場合は良いのですが、エラーがあった場合は後のdb2exfmt等を実行しないようにしています。というのは、最新の取得済みEｘｐｌａｉｎがあれば、毎回そのデータで出力を作成しまうからです。
　ちなみに、正常に処理された場合は、「情報の要求だけが実行されており・・・」というメッセージが表示されるようです。
結果をタブで切り替えられるようにしました。
処理が正常に終了すると、自動的に「アクセスプラン」のタブを表示します。

　この画面に出力結果が表示されます。
　内容の正しい把握には、かなりの修練が必要となりますが・・・。ｗ
db2batchも実行し、ベンチマーク結果も取得できるようにしました。
　せっかくなので、ベンチマーク結果も取得できるようにしました。（煩わしい場合もあるかなということで、オプション指定により実行しないようにも設定できるようにしてあります。また、出力のレベルオプション「-o p 3」も指定できるようにしてあります。）

　ちなみに、出力結果はファイルで保存し、表示はｉｅ（Internet Explorer）のコンポーネントを利用して表示するようにしました。これにより、タブを切り替えても、表示位置を残すことができ、２つの結果画面を比較しながら操作することも可能です。

動かして結果を見てみよう！

　私の関心の中心はＸＭＬなので、ＳＱＬ／ＸＭＬや、ＸＱｕｅｒｙのクエリーで検証を実行してみました。
　また、実際のサイズの異なるＸＭＬ文書での検証を行ってみました。

A. テーブル全体にアクセスするケースで検証する

　まず、Where句で曖昧検索を指定し、テーブル全体にアクセスするようなパターンを２種。

XQueryで件数を取得する

　下記のスクリプトは、アーカイブのデータから、送信先メールアドレスに"IBM"を含むメールの件数を取得するためのものです。
```
select count(*) from MAIL_ARC.MAIL_DB c 
where xmlexists(
 'declare default element namespace
    "http://schemas.eternaldesign.jp/oides/mail2xml" ; 
  $i/RFC822/Header/To[contains(fn:upper-case(.),"IBM")] '
 passing c.MAIL_DATA as "i") 
```
このスクリプトのEXPLAINを見ると、元のＳＱＬ文に対して、最適化されたＳＱＬ文が表示されているのですが、ＸＭＬ用に内部的な処理がされていることが分かります。

　次にアクセスプランの図です。下図の赤枠の部分のテーブルスキャン（TBSCAN）の箇所のI/Oコストの4295は、表の全ページの値と一致しており、総なめになっています。
　XML索引を作れば改善されるかという話もあるのですが、今回の例のように「Contain」関数を使った場合は索引は使われないと推測します。
全文検索エンジンで件数を取得する

　下記のスクリプトは、１と同じような条件のメール件数をカウントするものですが、XQueryではなく全文検索エンジン（Net Search Extender）を使用したものです。
```
select count(*) from MAIL_ARC.MAIL_DB c
where CONTAINS(
 MAIL_DATA,'section("/RFC822/Header/To") "IBM"'
 )=1 
```
取得したEXPLAINを見てみましょう。
　今回もＤＢ２がステートメントを最適化しているのが分かります。

　アクセスプランを見ても、表現上は表スキャン（TBSCAN）ですが、実際はNSEの索引を使ってアクセスするので、Ｉ/Ｏコスト（＝索引の使用ページ数？）も１１という値になっています。

ベンチマーク結果の比較

１と２の処理をベンチマーク結果で比較してみたものを下表に示します。

処理のタイプ	XQuery	NSE
経過時間	18.073455 秒	3.326436 秒
バッファー・プール・データ論理読み取り	4918	8
バッファー・プール・データ物理読み取り	9	0
バッファー・プール一時データ論理読み取り	1	0
バッファー・プール索引論理読み取り	782	187
バッファー・プール索引物理読み取り	0	22
バッファー・プール xda 論理読み取り	644	0
バッファー・プール xda 物理読み取り	0	0
バッファー・プール一時 xda 論理読み取り	170	0
バッファー・プール読み取り時間の合計 (ミリ秒)	188	219
プリフェッチ待機時間 (ミリ秒)	2267	0
直接読み取り	12	24
直接読み取り要求	3	4
直接読み取り経過時間 (ミリ秒)	14	0
読み取り行数	52169	4
書き込み行数	0	0
エージェントによって使用される合計ユーザー CPU 時間 (秒)	0.546875	0.0625
ホスト実行経過時間	5.59027	1.082779
最後に完了したステートメントの経過時間 (sec.ms)	0.177223	0.136443
ステートメント・ユーザー CPU 合計時間	2.53125	0.03125
ステートメント・システム CPU 合計時間	0	0.03125
timeron 時の SQL コンパイラー・コスト見積もり	535550	12

　今回の結果は、XQueryのケースに対しては、厳しい条件での結果となってしまいましたが、　　Where句での絞り込みを行う場合は、最悪全レコード総なめ（テーブルスキャン）を覚悟しなければならないことを示していると思います。

B. 同じスキーマの異なる文書に対するアクセスで検証する

　次に、同じスキーマの異なるＸＭＬドキュメントに対してＸＱｕｅｒｙのアクセスプランを取ってみます。
　実行するクエリーは某ツールのプログラムソースから、利用しているオブジェクトを抽出するためのもので、そのオブジェクトの番号と位置を取得するためのものです。

select xmlquery('
 <Datas>{
  for $e in 
    $i/Application//Task/TaskLogic/LogicUnit/LogicLines/LogicLine/
    CallTask[OperationType/@val="P" and fn:exists(TaskID/@obj)]
  return
  <Data>
  {attribute TNm {fn:string($e/../../../../../Header/@Description)}}
  {attribute TId {fn:string($e/../../../../../Header/@ISN_2)}}
  {attribute Cmp {fn:string($e/TaskID/@comp)}}
  {attribute Obj {fn:string($e/TaskID/@obj)}}
  </Data>
 }</Datas>'
 passing c.ITEM as "i")
from DB2MRCA.PSOURCE c 
where c.SOURCEID=nnn

最後の"nnn"のところには、異なる２つの番号が入るのですが、下記のようにそれぞれファイルサイズが大きく異なる２つのドキュメントを指定します。

ＳＯＵＲＣＥＩＤ	ファイルサイズ
284	10,706KB
304	91KB

　さて、EXPLAINの結果は変わるでしょうか？

　アクセスプランを見ると、「GENROW」という内部で生成した表を作成し、「XSCAN」という「for」文で指定したXPATHの検索との結合を行っており、ほとんどのコストはその部分で費やされているのが分かります。

　結果ですが、実行した時刻とソース内で指定した番号が異なるだけでした。つまりEXPLAIN自体は変わりません。
　それでは、ベンチマークのほうで違いを見てみることにします。
　下記の表は、経過時間とアプリケーションのスナップショットを取得した際の違いの出た主な項目です。

Where句で指定したSOURCEIDの値（データの番号）	304	284
経過時間	0.478864 秒	5.178961 秒
バッファー・プール一時データ論理読み取り	1	637
バッファー・プール索引論理読み取り	117	3324
バッファー・プール索引物理読み取り	1	4
バッファー・プール xda 論理読み取り	205	5715
バッファー・プール xda 物理読み取り	0	24
バッファー・プール一時 xda 論理読み取り	145	2797
バッファー・プール読み取り時間の合計 (ミリ秒)	0	152
プリフェッチ待機時間 (ミリ秒)	0	823
読み取り行数	2	317
書き込み行数	0	310
エージェントによって使用される合計ユーザー CPU 時間 (秒)	0.015625	0.515625
ホスト実行経過時間	0.154833	1.603549
最後に完了したステートメントの経過時間 (sec.ms)	0.00025	0.00005
ステートメント・ユーザー CPU 合計時間	0.015625	0.515625

　見て頂ければお分かりのように、値の違いは顕著に現れています。
　推測するに、内部的に処理されたＸＭＬ行（GENROW）のサイズによるものと思われます。
　結論的には、統計情報として取得される値は、目安的なものといってよく、実測しないと分からないということのようです。

　それでは、アクセスプランで表示されるコストなどの数値（I/O Cost=16、Total Cost=170.574 等）は何を根拠に算出されているのでしょう？
　これは今のところよく分かりません。（どなたか教えて下さい。）

まとめ

ＸＭＬ関連のクエリーに対しても、アクセスプランやベンチマークの取得を、通常のクエリーと同じようにＤＢ２のツールを使って検証することが可能です。
XQUeryをWhere句で使うような場合は、高コストの表スキャンになることを覚悟しなければならないので、アプリケーションに実装する上では良く考慮すべきです。全文検索エンジンを利用すべきと思われます。
データサイズの違うオブジェクトに対して、XQueryを実行する場合は、アクセスプランでは代表的な数値を用いてコストを表示しているようなので、実際の値を得るにはベンチマーク等を実行して確認する必要があります。

Category(s): misc; dbMAGIC; DB2

twitter って最近すごい・・・？

　最近、twitter ってブームですか？w
　個人的にアカウントを作成したのがいつだったかよく覚えてませんが、最近勉強しつつあるAPIでXMLを取得するとその情報が残っていました。

<created_at>Tue Sep 09 05:40:50 +0000 2008</created_at>

たしか、やりだした頃は、自分がつぶやいても一体誰が読むんだろう・・・なんて思ってたような記憶があります。
　今や世界中に急速に広まっているようで、なんでもこの調子で増えると来月末位までには10桁を突破してしまうようなことが書いてありました（ユーザのＩＤなどの数値のタイプはいわゆる BIGINT にしなければならないらしいです）。

　私のフレンドの中に外国人がいるんですが、どうやら女性なんですね（どういうきっかけで何もつぶやかない日本人をフォローし始めたのかは未だに分かりません）。最初は、どこの国の言葉かさえも分かりませんでした。翻訳サイトを開いて、順に変換していってようやくそれがポルトガル語であることに気付きました。でも正直、翻訳しても何を言っているのかは良く解らないんですねぇw（某翻訳サイトも、もう少し洗練させないといけない？）

　twitter のwikiのページのリンクにあるBOTの紹介を見たとき、いろいろできるんだと思いました。
　それから、軒並み「公式アカウント」というのも増えているようですね。企業情報のアナウンスにも多数利用されているのを見ると、もうすでに何か始動しているといっても良いでしょうね。

　ということで、当社でも遅ればせながら、公式アカウントを設置致しました。
　このサイトの更新情報や、研究開発の話題などをつぶやいて行きたいと思います。

　この投稿の後、Twitterにアクセスできなくなったのですが、どうやらハッカーによってＤＯＳ攻撃を受けていた模様です（このコメントを入れている現在もつながりにくくなっている・・・）。
　すっかりTwitterが依存してしている（生活の一部になっている）人も多いのではないかと思います。
　こういうことがあると、そういう自分の姿があらわになるものですね・・・。ｗ

twitter の公式アカウントを公開しました。

Size 1 kB - File type text/html

twitter 公式アカウント

Size 1 kB - File type text/plain

Category(s): misc; Web; twitter

Club DB2 2009/8/7

　昨日もクラブＤＢ２に参加させて頂きました。
　今回は、「ＤＢ２９．７ＤＷＨ系新機能の紹介」と表題にあるように、新ネタの話題でとても興味深かったです。

索引圧縮機能
スキャンシェアリング
ＬＯＢデータのＩＮＬＩＮＥ格納
パーティション索引

　特に盛り上がったというか、質問やら所感みたいなものが飛び交ったのが「索引圧縮機能」。
　公開されたテストでは、下記のような検証結果について報告されました。

カーディナリティの値で圧縮傾向は異なるか・・・
カーディナリティの異なるカラムの複合索引で組み合わせ順は影響するか・・・
カラムタイプで圧縮の期待できるものはどういうタイプか・・・
表圧縮と索引圧縮によって、どれくらいのパフォーマンスの効果があるか・・・

結論的に言えば、「『設計上としてはあまり推奨できない傾向にある索引？』のほうが圧縮効果が高い・・・」ということ。このあたりの「ちょっと微妙な結果」が盛り上がった原因にあったのかと推測します。
　「正しい設計をするに越したことはないけど、微妙な設計をしても、それなりにＤＢＭＳはカバーしてくれる（かもしれない・・・）」ということですネｗ

　スキャンシェアリングでは、それを無効にするための非公開のスイッチがあるとのことでした。（参加者に配布された資料には誤って記載されていた・・・）
　このスキャンシェアリングは、「多重度が高く表スキャンするような処理があっても処理が遅くならない」という機能です。単独のクエリが実行される場合は、スイッチのＯＮ／ＯＦＦに関係なく同じ程度の負荷がかかるとのこと。
　「使ってはいけないスイッチがある機能は、完成度の高い機能である」という格言？があるそうです（某Ｉ社社員談）。

　ということで簡単ですが、様子のご報告を・・・。
　こういう新機能紹介はとても有難いですね。いつもながらスタッフの皆さん有難うございました！

Category(s): misc; DB2

株式会社エターナルデザイン

Sections

Personal tools

misc