Takenoff Labs » Notes/Domino » DB設計 » NSFDB2 が使い物にならない6つの理由

[Notes/Domino] NSFDB2 が使い物にならない6つの理由

最近管理人は、かなり無茶な案件をやっておりまして。ユーザーの要望が、「5つのテーブル(リレーションあり)から」「多種多様な条件で(MAXなどもあり)」「大量のデータを(最終的には10万件くらい?)」「高速に検索」するというものでして、それってノーツじゃねーだろ、と普通なら一蹴するところですが、昨今の大不況の影響でカネが無く、外注費がかからないノーツで「絶対やれ」ということになったのです(号泣

極力費用が発生しない方法は何か……と考えたところ、NSFDB2 であれば Domino で使う分には DB2 のライセンスが不要ですから、NSFDB2 で行こう! と提案しました。が、これが間違いの元でした(大号泣)。思ったよりはるかに使い勝手が悪かったです……。まあ、どうにかこうにか要件が満たせそうなシステムは出来てきたので、NSFDB2 でいくことはいくのですが、どういうところがイケてないかを以下に列挙してみます

(ちなみに、今回の検証はかなり会社の時間を使って行ったわけですが、上司のF田さんのご厚意により、ブログに検証結果を書くことを許可していただきました。ありがとうございますありがとうございますm(_ _)m また、検証環境は VMWare の仮想環境なので、そのせいでパフォーマンスが悪い可能性もあります(9.1 だと VMWare 環境でのバグもあるっぽい? でも本番もサーバー買うカネがなくて VMWare なんだよな……)。何か誤りがあったり、もっとパフォーマンスが上がる方法がありましたら、どしどし指摘してくださいませm(_ _)mm(_ _)m)

サポートしている DB2 のバージョンが 9.1

最初に愕然としたのが、サポートしている DB2 バージョンが 9.1 しかないということ。今の最新バージョンは 9.7 ですから、てっきりこのバージョンがサポートされるものだと思っていたのに……。DB2 ストア機能なんてバージョン間でそんなに差異はないでしょうに、テスト工数ケチってるんですかね。最新版は管理がかなり自動化されていて、管理の手間が無いかな、と思っていたのに、がっかりです。

Access View への SELECT 文が遅い

RDB 化したのだから、SELECT 文は普通に速い、と思っていましたが、それは幻想だったようです(涙)。DB2 Access View に対して、Query View で SELECT 文をなげた場合、ユーザー定義関数によっていちいち1行ごとに参照権限がチェックされ、これにより結果セットが大きい場合は、かなりの時間を食ってしまうようです……(x_x) わたしが試したところ、読者名フィールドが無い文書で試してみても、結果は変わらないようでした(ユーザー定義関数を呼ぶコストがかなり高い?)。

大量のデータを返すクエリが遅い

Query View で SELECT 文を発行した結果セットが大きい場合、結果セットの大きさによってどんどん遅くなるようです。試しに Access View 以外のテーブル(後に述べるように、これはライセンス違反なので本番では使用できませんが)を SELECT してみても、万を超えるとかなり遅くなります。

これは、SELECT 文の結果セットをすべてダウンロードして、クライアント側でビュー索引を構築するためのようです。ノーツのビューにデータを表示するにはビュー索引が必要で、Query View が動的である以上、この索引作成処理も動的に行われてしまうらしいです。なので、下手をすると、あらかじめ索引を作成してある普通のビューのほうが速いことになってしまいます(x_x)

ページング処理が超面倒

上記のことを改善するには、小さい結果セットを返して、ページング処理(Googleの検索結果みたいなやつ)をしてやれば、理論上速くなります。(管理人は、このページング処理はビューが自動でやってくれるものだと、甘い期待を抱いておりましたが、容赦なく粉砕されました(涙)。あと、参照できる行数が少ないユーザーだと、ページングをしてもあまりパフォーマンスが上がらないかもしれません(未検証ですが))

が、DB2 のバージョンが 9.1 だと、このページング処理が結構面倒なのです。管理人は MySQL が好きなので、LIMIT 句で簡単に処理できるのだろうと考えていたら、DB2 には LIMIT 句は実装されていないのでした 😥 。(まぁ、Oracle、SQLServer にも無いらしいですが。)

DB2 でページング処理をやるには、以下のサイトを参考にしてください。前者は ROW_NUMBER を使用する方法で、後者は EXCEPT を使用する方法です。(前者の場合は、OLAP関数のため、データが大量になると遅くなるので注意が必要です。後者の場合は、列が大量にあるテーブルで SELECT * を使用すると遅くなります(チューニングにもよるでしょうが)。必要な列のみに限定したほうがよいみたいです。)

DB2でMYSQLのLIMITを実現するには
DB2で行数を指定して結果を取得

どちらにしても、今何件目を処理しているかを環境変数にセットして、「前へ」「次へ」ボタンを作ってページング処理を実現しなければなりませんから、ノーツで普通にビューを作るよりはるかに面倒です。

大量データを高速に INSERT、UPDATE、DELETE できない

今回一番困ったのは、大量データを高速に INSERT、UPDATE、DELETE できないということ。今回のDBの仕様が、大量のデータを複雑な条件で検索し、その結果を追加→再度検索→また追加……ということをやりたいらしいので、検索結果を保管するテーブルに一気にデータを流し込みたいのですが、それができないっぽいのです。(なので、先週紹介した、フォルダを自動生成して、そこに入れるという手段で逃げたのです……。他に手段があるなら、マジ教えて(涙))

そもそも、ノーツで文書を保存するときにどういうことになっているかというと、

  1. 文書を保存(LotusScript のNotesDocument.Save でも同じ)
  2. NSFNOTEなどの管理テーブルに、文書の中身が丸ごと保管される(っぽい?)
  3. Access View のテーブル(おしりに「_T」が付くもの)に管理テーブルから抽出されたデータがセットされる(ちなみに、おしりに「_X」が付くテーブルもあるのですが、これがなにかよくわからない……)

image

NotesDocument.Save なんかでは、まぁ DB2 じゃないときの速度と似たようなもんです。では INSERT、UPDATE、DELETE ならどうかというと、NSFNOTE は勝手にいじれないので、Access View に対して処理するしかないみたいです。が、Access View に対して INSERT、UPDATE、DELETE すると、トリガーが動いて、結局 NSFNOTE テーブルなどにもデータをセットするわけです。なので、超重いです。(UPDATE が遅い件については、デザイナーヘルプに明記されていました……)

image

じゃあ、「_T」付きテーブルに直接処理してしまえばいいのでは、と思われるかもしれませんが、これはNG。ごにょごにょやれば、データを入れることは簡単ですし、トリガーも動かず高速ですが、Access View の定義を変更すると DROP→CREATE になるので、データが消えてしまいます。それに、そもそもこんなことはサポート外でしょう。

DB2 コマンドの IMPORT については試していませんが、NSFNOTE テーブルなどの仕様がわからないからデータの作りようがないし、Access View に対して IMPORT したのでは、結局同じことになるような気がします。

独自テーブルはライセンス違反

このような八方ふさがりの状況に業を煮やし、じゃあもう面倒だから、独自テーブルを CREATE して、そっちにデータ突っ込めばいいんじゃない? と思い、このような方法がライセンス違反になるかどうか、IBM サポート(特殊な事情により、日本ではなくシンガポール)に運用チームから問い合わせてもらったところ、あっさり「ライセンス違反だよ~」と返事が返ってきました。

てめーらの作ったシステムが使いもんにならないから、しようがなくなんとか回避しようとしているのに、その言い種はなんなんだ凸(- -メ 外部アプリから使うわけじゃなく、Domino からデータストアするんだから、結局やってることは同じはずなのに、なんでライセンス違反になるんでしょ。相変わらず IBM は顧客のことを考えていないというか、なんというか。


以上、いろいろと悪口を書いてきましたが(^^;、ノーツで Query View が作れるのはかなり便利ではあります。普通のノーツシステムでは、マスタの値を文書に持つ必要があり、マスタが更新されたら一括反映する処理を入れなくてはなりませんでしたが、それが要らなくなるのは、便利ですね。また、ノーツでは到底不可能な検索をできるのもメリットではあります。

が、せっかく DB2 化しているのに、いまひとつメリットを生かしきれていないというのが、管理人の感想です。独自テーブルがライセンス違反になりさえしなければ、まだ使えると思いますから、IBM さんにはぜひライセンスの見直しを検討してもらいたいと思います。

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

トラックバックURL :

Navigation

前の記事(カテゴリ内):

次の記事(カテゴリ内):

前の記事(日付順):

次の記事(日付順):

トラックバック

トラックバックはありません

コメント

コメントはありません

※コメントは承認制となっております。管理者が承認するまで表示されません。申し訳ありませんが、投稿が表示されるまでしばらくお待ちください。





(以下のタグが使えます)
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

For spam filtering purposes, please copy the number 6981 to the field below: