当ブログに掲載しているサンプルは、すべて利用者の自己責任という形でお願いします。
ただし、明らかな不具合がある場合、ご連絡いただければ、訂正記事を出します。
また、こちらのサンプルは、別のサイト等への公開、転載は一切禁止しています。
どうしてもと言う場合は、筆者にあらかじめご連絡ください。
記事そのもののリンクについてはご自由に行っていただいてよいです。

テクてく Lotus 技術者 Slack に参加しよう!

2017年4月7日金曜日

文書サマリーデータの上限を 16 MB に増やしてみた

皆さん、こんにちは。

昨日、桜の花が見ごろ~と書いたのに、あいにくの雨です。
これで桜の花が散ってしまわなければいいのですが・・・





さて、今日は、IBM Domino 9.0.1 Feature Pack 8から実現可能になった「文書サマリーデータの上限を 16 MB に増やす」に焦点を当ててみましょう。

元の記事は、こちらです。
IBM Domino 9.0.1 Social Edition フィーチャーパック 8 の新機能
文書サマリーデータの上限を 16 MB に増やす


9.0.1 FP7までは、1文書あたりのサマリデータサイズが64KBまでとされていました。
サマリデータとは、テキストフィールド、数値フィールド、日時フィールドで設定された文書アイテムのことを指します。
リッチテキストはサマリデータに含まれないため、除外して考えます。
また、表示用の計算結果フィールドは、サマリデータとして認識されるものの、文書のアイテムとして保存されることはないため、この上限値の計算式からは除外してもよさそうです。

文書アイテムがサマリデータかそうでないかを簡単に確かめる方法として、文書のプロパティを見ることが挙げられます。
文書を開かずにビュー上で、文書のプロパティを開きます。
左から2番目のタブを見ると、文書の各アイテムの情報が表示されます。
そのうち、どれか1つのアイテムを選択します。
すると、右側にそのアイテムの情報が表示されます。
この中に、「フィールドフラグ」という項目があります。そこに、"SUMMARY"と書いてあれば、そのアイテムはサマリデータということになります。

Field1アイテムはサマリデータです

余談ですが、ここのフィールドフラグを見ると、そのアイテムがユーザ名の場合、どんな種類なのかが分かるようになっています。
読者フィールドの場合、"READ-ACCESS NAMES "
作成者フィールドの場合、"READ/WRITE-ACCESS NAMES "
名前フィールドの場合、"NAMES"
です。
読者権限を設定したはずなのに誰でも見えるな、なんでだ?
といった時に、このフィールドフラグで確認できます。


本題に戻りましょう。
このサマリデータが文書全体で64KBまでとなっていました。
さらにいうと、1アイテムあたりの上限サイズは32KBです。
ここで気を付けないといけないのは、「$Revisions」「$UpdatedBy」の存在です。
それぞれサマリデータとして定義されるので、上限サイズからこれらのデータサイズを差し引いた分が1文書あたりにセットできるサマリデータということになります。

また、IBM Notes/Dominoの場合、LMBCSで格納されているので、文字数のカウントには注意が必要です。


ここで、本当にサマリの限界は64KBなのかどうかを確認するためにサンプルDBを作成してみました。
サマリデータ確認用サンプルDB

図では「フィールド1」~「フィールド6」までしか見えていませんが、実際には「フィールド10」まで作ってあります。
フィールド1-10の各テキストフィールドに値を入力して、[計算]ボタンをクリックすると、ラジオボタンの値が"ON"の場合に限り、一番右の列の「バイト」と書かれている箇所に、そのアイテムのサイズを計算してセットするようにしています。

実際に文書を保存する場合、フラグのON/OFFを見て、各アイテムをサマリデータとするかどうかを計算しています(OFFの場合はサマリデータにしない)。
ここで注意すべき点があります。
UI上で文書を保存すると、テキスト/数値/日時フィールドはすべてサマリデータとして保存されてしまいます。
そのため、このサンプルDBでは、UI上では保存できないようにして(QuerySaveイベントで止めています)、LotusScriptを使ってバックエンドで保存するようにしています。


※作成者、作成日、最終更新者、最終更新日、タイトル、カテゴリ、フラグ、サイズフィールドもサマリデータとして計算されるので、フィールド1-10には全部で64KBも入力できません。

このDBでデータを入力してみました。
まず、1アイテムに格納できる上限サイズは32KBかどうかを確かめてみました。
入力バイト数が分かるように半角英数字だけを入力していくと、確かに32KBを超えようとするとエラーメッセージが表示されました。
32KBでエラーになった
※画面ではアイテムサイズが32,761バイトになっていますが、制御用のデータとして6バイト使われるので、実際に格納できるのが32,761バイトまでということになります。

ここで、32761バイトまで入力して、他のフィールドにも同様にデータを入力します。
エラーが出るまで入力し続けて、保存します。
文書を保存してみた
保存した文書のサイズは約62KBで、サマリが約61KBでした。
このサマリの数値はフィールド1-10のアイテムサイズを合算したものなので、 実際にはもっと多いでしょう。
それでも、64KBを超えていないことは分かっていただけたと思います。


ここまでがIBM Domino 9.0.1 FP7までの話です(長いなぁ・・・)。
今度は、このサンプルDBをコピーして、サマリサイズを16MBまで拡張できるようにしましょう。
※コピーするのは、比較のためです。


まず、ODSを52にできるようにするために、Dominoサーバのnotes.iniに
CREATE_R9_DATABASES=1
の行を追記します。
その後、Dominoサーバを再起動します。

次に、先ほどのサンプルDBをDominoサーバ上にコピーします(IBM Notesクライアントで行います)。
これで作成されたNotes DBのODSは52になります。

そして、Dominoサーバコンソール上で
load compact -LargeSummary on "データベースファイルパス名"
と入力して、サマリデータを拡張します。
compactコマンドを発行

今回は、文書はコピーしないで設計だけをコピーしたので、あっという間に終わりました。
メッセージを読むとサマリデータの拡張を有効化しました。というようなことが書いてあります。

肝心のNotes DBはどうなったかな?と思い、プロパティを見てみましたが、これといって変わった個所はありませんでした。
load catalog
を実行してカタログDBの更新を行って、コピー前のDB文書と比較もしてみましたが、何も変わってません。
Domino Administratorを使って、DB分析を行いましたが、それらしいものは出力されていません。

えーっと・・・どうしろと!?

と、とりあえず、新規に文書を作ってみましょう。
まず、1つのフィールドに入力できるサイズの上限は32KBでした。
ここは変わってないんですね。
続いて、同じサイズのデータを別のフィールドに入力します。ここは面倒なので、コピー&ペーストで行いました。
サマリデータが拡張されているなら、エラーにならないはず!

ということで、どんどんデータを入力していき、保存してみました。
64KBを超えて保存できた!

文書サイズ、サマリデータサイズともに64KBを大幅に超えた160KBになっています。
限界値の16MBまでは程遠いですが(計算したら、全部のフィールドが32KBとしても500個のフィールドが設定できます!)、それでも従来の64KBを超えて保存することができるのが分かっていただけたと思います。


いかがでしょうか?
フィールドを増やしすぎたのはいいけど(ホントは良くないと思う・・・)、文書の保存ができなくなった!というのも、この設定を適用すれば、そんな心配もなくなります。


気がかりなのは、compactを実行しても、DBのプロパティも何も変わらないこと。
これ、絶対に度のDBに対して適用したかを忘れますよね・・・
どうにかしてほしいですね。




なお、最初に紹介したIBM Knowledge Centerの記事(IBM Domino 9.0.1 Social Edition フィーチャーパック 8 の新機能)中に
「単一フィールドのサイズの上限は、引き続き 64 K です。」
という箇所がありますが、正しくは
「単一フィールドのサイズの上限は、引き続き 32 K です。」
です。
IBMさん、修正してくださいね。



それでは今日はこの辺で・・・



Notes/Dominoで困ったことがあれば、弊社にお問い合わせください。
IBM Championの私が承ります!
お問い合わせはこちらから→Lotus Notes/Domino カスタマイズとセキュリティ強化 - 株式会社エフ

0 件のコメント: