Domino ビューのインライン更新機能

2020/7/27 - 読み終える時間: 3 分

原題は Going Inline with Domino Views という記事です。「Domino ビューにはインラインだよ」というニュアンスだと思います。別のニュアンスも感じ取れますが、自分はネイティブではないので確信はありません。内容的にはビューのインライン更新機能についてです。

Domino ビューのインライン更新機能

2020年7月23日

著者: John Curtis / Domino Core Application Team Lead

私は長年にわたって Notes Indexing Facility (NIF) の奥深くで作業をしてきました。初期の Domino 開発者が最初の日からしっかりとバンドルされた豊富な機能からは、まだまだやるべきことがあり、収穫するべきことがあるからです。非常に多くの多様なデータがコードを通ってガラスの上に流れてくるので、これは挑戦的な領域である可能性があります。注意を怠ると、あるユーザーのストーリーを喜ばせる一方で、別のユーザーのストーリーはそれほどでもないものになってしまいます。

NIF で最も問題となる操作の1つは、更新の処理です。誰かが「じゃあ、何が問題なの？他のデータベース製品はインデックスの更新に問題はありませんが、Dominoはなぜ違うのでしょうか？Dominoはなぜ違うのでしょうか？その答えは、Designer でのビューやフォルダの作成の容易さにあります。ビューは常に数と複雑さを増していくというのはよくある話です。

そこで、私はよくこのように違いの質問に答えます。「あなたがMySQLやOracle、DB2やMongoDBの管理者のところに行って、データベースに 200～1000 個のインデックスを要求したら、彼らは何と言うでしょうか？」もちろん、彼らはあなたを笑い者にするでしょう。しかし、Domino データベースではインデックスの数はごく普通のもので、それが怠惰に更新されたり、スケジュール通りに更新されたり、トリガーや強制的に更新されたりする理由です。更新/更新のルールには様々なものがありますので、ここでは触れません。

NIF で最もコストのかかる問題のいくつかは、更新のための過度のキューイングに起因しています。APIや文書のほとんどは、ユーザーがビューを開いて最新の更新を見たいときに「リフレッシュ」と呼んでいますが、これは完全に理にかなっています。問題は、多数のユーザー（まあ、スレッド）が一度にそれを行うとき、彼らはそれぞれが 「公正な読み書き (fair read/write)」キューでビューを更新する権利を競います。つまり、読みたいだけの人は書き手よりも優先されません（私たちは更新を飢えさせることはありません）。その結果、サービスレベルアグリーメント（SLA）のタイミングに違反し、ビューを開くのに時間がかかりすぎてしまうことがあります。

以下は、SPR JCUS8MXLA2 用にまとめた図です。この中には、スケジュールされた専用のビュー更新を表す「更新タスク」が含まれています。

ご存知ないかもしれませんが、v9.0.1 Feature Pack で、Domino の開発者はこの問題を攻撃するための機能をひっそりと開発していました。これは「インラインビュー更新」あるいはシンプルに「インライン」と呼ばれています。この機能は以下のコマンドで有効/無効にできます。

load updall <データベース名> [-T <ビュー名>] -inline on/off

これが何をするかというと、文書更新時にビューの更新を適用することです。そのため、ビューオープン時のすべてのリフレッシュ要求は、そのまま「nops」として扱うことができます。文書の更新はより重い作業単位になりますが、ビューのオープンと読み込みのパフォーマンスのトレードオフはそれだけの価値があります。

Domino V10では、使用率の高いビューを検出して自動的に専用の更新スレッドを作成するという2つ目の取り組みが開始されました。これは notes.ini の NIF_VIEW_USAGE_ENABLED=1 で有効になっています。

私は最初の取り組みである-inlineの効果を測定したかったので、この夏、HCL Chelmsford で（まあ、COVID-19のために自宅で）、Dominoコアのインターンである Joseph Calles と一緒に仕事をするという特権を得ました。私は Joseph に、-inline のオンとオフを使って実際のタイミングを提供することの探求をお願いしました。彼は、3つのビューを持つ 200K の文書のデータベースに対して、読み込みと更新の負荷を変化させるスクリプトを書き、Domino コンソールで "show trans" を使って統計を収集しました。Joseph 氏は、文書の更新とビュー操作の上限を10/秒に設定しましたが、もちろん、あなたの数値は、ボリューム、データ量、使用するハードウェアに応じて変化します。

誰もこれらの数字が現実のものであると主張していません、データと処理は自動化されています。しかし、彼らは収集されたセットとの相対的な一貫性があります。また、インラインの使用を検討する際に知っておくべき傾向を示しています。テスト負荷の分散は単純なものでした。

OPEN_COLLECTION トランザクションは、インラインがオフのときにビューを更新しようとするときの負荷を下げるものです。その利点は最初のグラフを見れば一目瞭然で、インラインがないとビューを開く時間が直線的に増加するよりもはるかに速くなることに注目すべきです。これが、私が言及したログジャムです。

2つ目のグラフでは、ビューを開いている時間とビューを読んでいる時間を組み合わせて、1つの時間を提供しています。これは、ユーザーがビューを開いて最初のウィンドウのエントリがレンダリングされるまでの時間に近いものです。ここでも、-inline を使用しないトランザクションの数が多くなるとスパイクが発生することは明らかです。

今では、800 ミリ秒のレスポンスで SLA に違反することはほとんどありません。繰り返しになりますが、ポイントは曲線です。ビューを開くための最大時間を表示すると、実際にはほとんどのSLAに違反するであろう、不規則で最悪のケースのユーザー体験を示しています（このグラフでは、時間は秒単位で表示されていますのでご注意ください）。

ウソのない宣伝 (Truth in advertising): 文書の更新時間は -inline をオンにすると増加しますが、それを期待するでしょう。そして、指数関数的に増加するのではなく、直線的に増加します。しかし、これをスループットの低下と混同しないでください。

この最後のグラフは、更新、検索、ビューのオープン、ビューエントリの読み込みなど、すべての操作を等しく扱い、それらの合計時間を平均化しています。つまり、インライン処理の全体的な持続時間の影響を表しています。

しかし、元々のユースケースを覚えておくことは重要です。複数のユーザーがビューを開いて読もうとしていますが、最初に「リフレッシュ」（更新）を行います。複数のユーザがビューを開いて読もうとしますが、最初に「リフレッシュ」（つまり更新）を行います。 -inline をオンにすると、読まれているビューは NSFNoteUpdate 操作中に更新されるので、リフレッシュ操作は不要です。そのため、これらのビューのオープン操作ははるかに軽量化されます。

繰り返しになりますが、この動作はトランザクション中心のデータベースシステム、特にデータがきちんとした四角形の中に存在するリレーショナルシステムでは「普通」です（少し進歩しています）。しかし、Domino では、文書の格納と処理を行う NoSQL エンジンである Domino では、非常に多くの異なるインデックスをサポートしており、インデックスデータを非常に多くの異なる方法で構築しているため、多くの場合、遅延更新モデルが適切なものとなります。そして -inline 機能は、それが適切でない場合に対処します。

ですから、もしあなたが競合するビューを持っているのであれば (すべてのビューが熱く競合しているわけではありませんが)、以下のコマンドを使用して、インラインビュー更新を有効にする検討を強くお勧めします。

load updall <DB名> -inline on -T <競合するビュー名>

すると、良い結果を得ることができることでしょう。

文書の更新コストが急増する可能性があるため、データベース内のすべてのビューに対してオンにすることには注意が必要です。みなさんは、ご自身の環境で、最も競合の多いビューを知っているでしょうからうまくやってみてください。