Takenoff Labs » ビューの速度低下の原因について

[Notes/Domino] ビューの速度低下の原因について

ビューは、Notes の（数少ない？）非常に便利な機能のうちの1つですが、設計に注意しないと、思わぬパフォーマンス低下を招いてしまいます。この記事では、IBM が配布している Red Book に載っている事項＆載っていない事項をまとめて紹介したいと思います。

まず、ビューで処理が遅くなるのはどういう時かとういうと、大きく分けて索引作成時とビューを表示する時があると思います。

索引（Index）とは、ものすごく乱暴な言い方をすれば、ビューの実データのことです。Notes は、文書のデータをリアルタイムに読んでビューに表示しているわけではなく、いったん文書のデータをビューに必要な分だけ抜き出してソート処理などを施しておいたもの（=索引）を作成し、そのデータを読み込んでビューに表示しています。これにより、ビューを開くたびに負荷のかかる処理をしなくてよいため、2回目以降のアクセスが高速になるというわけです。まぁこの機構がメリットにもデメリットにもなってしまうのですが……。

索引は、DBが設置されている場所で作成されます。したがって、サーバーにあるDBの場合、サーバー側の負荷となってしまいます。複製した場合は、索引は引き継がれません。処理対象は、作成または更新された文書のみとなります（つまり差分更新です）。索引の更新間隔はビューの設計プロパティで変更できますが、初期状態では「自動（最初の使用後）（=ビューを開いた時）」になります。重いビューで、即時に更新される必要のないものは、更新間隔を「自動」などに変更すると良いでしょう。

ビューを表示する時は、もちろん Notes Client でビューを開いた時のことです。索引を使用しているんだから、開いた時は関係ないじゃないか、という人もいるかもしれませんが、残念ながらそうではありません。詳しくは後述します。

それでは、以下、ビューが遅くなる個々のケースを挙げていきます。

大量の文書が作成・更新される場合

Notes の致命的な欠点の1つが、大量のデータを保管するのに向いていないという点です。索引作成速度がそれほど速くないため、大量の文書が作成・更新されるDBでは、ビューの索引作成が完了するまで、非常に長い時間がかかってしまいます。これはビューをどんなに単純化しても同じことです（すでに文書からデータを抜き出すところが遅い？）。一般的に、10万件を超える文書が発生するDBは、Notes 向きではないでしょう。RDB にしておいたほうが無難です。

もっとも、ほとんど文書が更新されない参照がメインのDB（あるいは日に100件程度で文書が増えていくDB）では、大量の文書を扱ってもいいじゃないか、という意見もあると思います（実際、わたしは100万文書以上を保管するDBを見たこともあります）。が、索引は初期状態では未使用後45日で削除されてしまいますし、マイグレーション時に索引を削除せざるをえない場合もあると思います。いったん索引が削除されてしまうと、1からの作成となってしまうため、恐ろしく長い時間待たされることになってしまいます。また、数十万文書レベルになると、DBのコピー・複製するだけでもエラい時間がかかってしまう場合があります。仕様変更で新規ビューを作らなくてはいけない場合も、新規ビューを開くのに時間がかかってしまいます。よって、Notes で大量の文書を扱うことは、わたしはあまりお勧めはいたしません。

選択式で日付/時刻関数を使用している場合

これはよく知られていることですが、@Now や @Today など、リアルタイムに計算する必要がある関数を選択式に使用していると、あらかじめ索引が作られず、ビューを開いたときに毎回全文書を対象として索引作成処理が行われてしまうため、遅くなってしまいます。文書数が少ない場合は問題ありませんが、多い場合は、スケジュールエージェントでフラグを立てて、そのフラグをビューで評価する、などの代替策をとったほうがよいかもしれません（まぁ、一概にこれがベストとは言えませんが。環境変数を使うワザもあるみたいですね）。

列に長い文字列を表示している場合

R6 から、列に長い文字列を表示していると、ビューを開くときに異常に長い時間待たされる場合があります（索引作成速度は関係なし）。IBM の人に確認したところ、この問題は R6 からで、R5では発生しないとのこと。ダメじゃん(- -メ

列に長い文字を表示するくらいなら、@Leftで先頭の何文字かを表示するほうが速いです。全部の文字列を表示する必要がない場合は、この方法を試してみてください。

ちなみに、行の高さを2行以上＆「内容に合わせる」にしている場合も、多少速度に影響するようです。

（2012/02/14追記）

以下、長島さん＆中島さんのブログで紹介されているように、この問題はクライアントの notes.ini に「DisableUniscribe=1」を設定すると解消されるようです。

ビュー表示の遅延 - Notes サポートのつぶやき

最新バージョンでは設定しなくても最初っから速いみたいですね。私は R8.5.3 で直っていることを確認しました。

文書に読者権限を設定している場合

これは見落とされがちですが、文書に読者名フィールドを設定している場合も、ビューを開くときの速度に影響が出ます。読者名フィールドが設定されていると、その文書を表示してよいかどうかはユーザーごとの権限によるので、開くときに参照できるかどうかの計算が行われてしまいます。Notes Client は、ビューの画面を満たすのに充分な量の文書を読み込むまで、その計算を延々行うことになります。

たとえば、あるユーザーが10000文書のうち1文書しか見る権限が無いとすると、画面を満たす量の文書は最後まで得られないことになりますので、10000文書分の計算が行われます。結果、ビューが開かれるまで、かなりの時間待たされることになってしまいます。が、管理者のユーザーはたいてい全文書を見る権限がありますから、画面を満たす量（数十文書程度？）を計算したところで処理が止まるため、高速に表示されます。よって、一般ユーザーがストレスを感じているのに、管理者が気付かない、ということが起こってしまいます。

これを回避するには、ビューをカテゴライズするという方法があります。ビューをカテゴライズし、ビューを開くときにすべてカテゴリを閉じる設定にしていれば、参照権限を計算する処理が行われないため、速く表示されます（カテゴリは必ず表示されるので）。カテゴリを展開するときに、カテゴリ内の文書に対してだけ計算が行われることになります（ので、なるべくカテゴリが多くなるような設定が望ましいです）。

空カテゴリを表示しないオプションを設定している場合

前の節で、カテゴライズによる回避方法を記載しましたが、ビューのプロパティの「空カテゴリを使用しない」オプションを使用すると、台無しになってしまいます。なぜかというと、このプロパティを設定していると、自分が表示できないカテゴリかどうかをチェックするために、カテゴリ内の文書をすべてチェックする処理が行われてしまうためです。結果的に、カテゴライズする前とほとんど変わりのないパフォーマンスになってしまいます。このプロパティを使用する場合は、文書数が少ない場合だけにしたほうが無難です。

どうしても空カテゴリを表示したくない場合は、個人ビューを使用するか、埋め込みビューで単一カテゴリを使う方法があります。前者は、いろいろと問題があるため、わたし的にはあまりお勧めではありません。後者で逃げることが多いですが、この方法も検索が出来なくなったり、列のソート変更ができなくなったり、とあまり良いことはありません……。何か良い方法があったら教えてください（＞＜）

読者名フィールドと「ヘッダをクリック時にソート」を併用している場合

読者名フィールドを使用した場合はビューを開くときに遅くなる、と前節で述べましたが、読者名フィールドを使用していて、かつ列のプロパティの「ヘッダをクリック時にソート」を有効にしている場合は、索引作成速度が異様に遅くなるようです。「ヘッダをクリック時にソート」を有効にしている列の数が増えれば増えるほど、どんどん遅くなっていくようです。読者名フィールド、「ヘッダをクリック時にソート」のどちらかだけの場合は、索引作成速度には影響はなく、この2つが組み合わさったときだけ、異様に遅くなるみたいです。残念ながら、理由は全く解りません（＞＜）

ふーん、じゃあ「ヘッダをクリック時にソート」プロパティのチェックを外せばいいのね、と思ったアナタ。事はそう単純ではありません。「ヘッダをクリック時にソート」は、設計的には $CollationN （N は連番）というアイテムに対応しているのですが（「昇順」「降順」の場合は1つだけですが、「両方」の場合は2つ分できます）、「ヘッダをクリック時にソート」のチェックを外しても、$CollationN が消えない場合があります（R6.5.2では消えず、R7.0.2では消えることを確認しました）。$CollationN アイテムが残っていると、ビューの動作自体に不具合はないものの、索引作成速度は何ら変わらないことになってしまいます。

これを回避するには、ビューを文書として取得して $CollationN アイテムを消す荒技がありますが、万人にはお勧めできないので、コードは掲載しません（＾＾；　おとなしく新規ビューを作って、列などを全部コピーするのが無難だと思います。（ただし、ビューのUNIDは変わってしまいますので、その点は注意。）

余談ですが、「ヘッダをクリック時にソート」は、単に索引を切り替えているだけみたいな機能のようです。なので、このプロパティを使用すればするだけ、索引サイズはどんどん増えていくようです。乱用は避けたほうが無難です。

とりあえず、今わたしが把握しているのは上記の点です。また気付いた点があったら、追記するか別のエントリに記載します。何か間違い・情報がありましたら、コメントにてツッコミお願いいたしますm(_ _)m