ソフトウェア > Lotus > Lotus Developer Domain >

Iris Today Archives

Rnext データベースに向けて何が変わるのか

by Laura Rutherford
レベル：すべて
対象：Domino Rnext
原文の掲載：2001年11月1日

Iris Today Archivesの原文（US）

インデックス

	ノーツ/ドミノ環境におけるデータベースの役割を説明してください。
	これまでリリースとリリースの間に、データベースに大きな変更はありましたか？
	Rnext 用のデータベースの計画段階において、あなたの掲げた最終目標は何でしたか？その目標を設定したのはなぜですか？
	Rnext 向けのデータベースの改良において主要な部分はどこですか？その改良の原動力は何ですか？
	拡張された機能について説明してください
	いくつかの機能について詳しく取り上げていきましょう。ODSから始めたいと思います。ODS とは何ですか？なぜこれを変更したのですか？
	新しい ODS は、R5 アプリケーションや R5 管理クライアントにとってどのような影響があるのでしょうか。
	View Logging について何か述べることはありますか？トランザクション・ロギングは基本的にビューのためのものなのですか？
	他にトランザクション・ロギングについて新しいことは何ですか？
	もう一つの新機能は Single Copy Template（SCT）ですが、これを開発したきっかけは何ですか？ディスク容量の節約だけが利点なのですか？
	SCT を有効にするために管理者がすべきことは何ですか？
	単一コピー・オブジェクト・ストア（SCOS）は R4の頃からあります。それがどういったものかを簡単に説明し Rnext において何が新しくなったのかを教えてください。
	SCT も SCOS もデータベース容量の低減に有効ですが、データベース容量を減らすために他に何を行ないましたか？
	LZ1 圧縮は、ネットワーク・パフォーマンスにどのように影響しますか？
	streaming attachments（ストリーミング添付ファイル）および streaming replication（ストリーミング複製）もネットワーク・パフォーマンスを改善すると思います。この機能について何かありますか？
	新しいデータベース機能や拡張について、何か他におっしゃりたいことはありますか？
	新しい機能や拡張の中で、何が一番気に入っていますか？
	Rnext 後のノーツとドミノのデータベースの方向性については、どう考えますか？

ご注意：

この記事は、ノーツ Rnext ベータ・プログラムで計画・開発されている機能を紹介します。したがって、最終的な機能や UI と、記事中に紹介されるものは異なる可能性があります。

データベースは、ノーツとドミノにおいて、メールの保存からシステム設定に必要な情報の保存まで重要な役割を担っています。この記事では、データベース・チームの副プロジェクト・リーダーのキミリー・ガイルが、Rnext の拡張された新しいデータベース機能について説明し、さらにこの機能がユーザーとユーザーのドミノ環境に対してどのような意味をもつかについて説明します。

ノーツ/ドミノ環境におけるデータベースの役割を説明してください。

データベースは、ドミノとノーツの文書保管場所です。これを聞くと、あなたはこのように思うかも知れません。「メッセージは全てメール・ボックスに入っているのではなかったのか。データを整理するためのビューやフォルダーもある。」ところが実は、ほとんどのユーザーが知っている以上に、データベースはドミノにおいて大きな役割を果たしているのです。例えば、ユーザー・アドレスの全てに加え、サーバーの設定情報を保存しているドミノ・ディレクトリーもデータベースとして保存されているのです。

実際、ドミノの実行に必要な情報のほとんど全ては、データベースに保存されています。ログ・データベース、管理要求データベース、テンプレート・データベースがあり、新しいデータベースを作る際に順番に利用されます。データベースなしではドミノは何もできません。

上に戻る

これまでリリースとリリースの間に、データベースに大きな変更はありましたか？

もちろんありました。私は、この仕事を初めてから4年しかたっていませんので、R5 のリリース以前についてお話しすることはできませんが、R5 では、トランザクション・ログ情報を含めることにより、データベースとその働きに大きな変更を行ないました。情報は、再起動やメディア・リカバリーで変更を復元するために利用されます。これにより、さらに効率的なバックアップの機会を提供できます。そして、クラッシュしたサーバーを再起動するときにデータを失うことはありません。ディスクに書き込んでいないあらゆる情報は、サーバーを再起動するときに自動的にこのデータベースに適用されます。したがって、これはデータベースの働きと、復旧するために保存する構造化された情報の種類に対して大きな変更を伴いました。

上に戻る

Rnext 用のデータベースの計画段階において、あなたの掲げた最終目標は何でしたか？その目標を設定したのはなぜですか？

データベースの新しいリリースに向けた計画を立てたとき、目標はいろいろな分野からでてきました。もちろん、お客様からのフィードバックが次に行なうことを決定する上で最も大きいものです。初めに述べた通り、ドミノが行なう全てのことに関して、データはデータベースのどこかに保存されるので、ディスク容量の低減が私達の注目しているとても大きな領域です。保存に要するディスク容量が少なくて済めば、それはお客様にとって有益なことです。お客様は保存容量、つまりハードディスクを買い続けたくはないはずです。

もう一つの大きな領域は、ネットワーク伝送性能です。ドミノの設定の多くは速いことが必要です。ユーザーはとにかく早く情報を手に入れたいのです。スピードが落ちるのは、ネットワーク越しにデータを送るときです。そこで、ネットワークの遅延（latency）を低減する方法を検討したいのです。

お客様から、ある機能が気に入っているが、もうすこし使いやすければいいのにと言われることがよくあります。計画段階から、使いやすさすなわちユーザビリティーの問題にも注目し、もっと使いやすくするように努めています。

また、Rnext ではすでにある機能のいくつかを、次の水準へ持ち上げたいと考えていました。例えば、R5 で導入し、View logging（ビュー・ロギング）の機能をカバーするように拡張したトランザクション・ログ機能です。

上に戻る

Rnext 向けのデータベースの改良において主要な部分はどこですか？その改良の原動力は何ですか？

ディスク容量の観点において、私達は冗長な情報を減らす方法について考えました。その方法として思いついたのは、Single Copy Template（単一コピー・テンプレート）を利用することです。Single Copy Template を利用することにより、データベース毎に情報を保存するのではなく、テンプレート内の設計情報を参照することができます。例えば、以前はメール・フォーム・マクロの見た目を記述する情報は、1つ1つのメール・データベースに保存されていました。現在は、何百人ものユーザーごとに何百回も保存しなくても、この種のテンプレート内の情報はそのままにしておいて、それを参照することができるようになっています。

ネットワーク伝送性能を強化するために、私達はデータをサーバーからサーバー、クライアントからサーバーへ送信する際に、それほど多くの確認通知を必要としないストリーミング技術について検討しています。

添付ファイルは、現状でも無駄を減らすために圧縮して保存するようになっていますが、Rnext では新しい圧縮アルゴリズムを選択できるように追加しました。Rnext 形式のデータベースでは、LZ1 圧縮アルゴリズムを利用できます。この機能の目的は、ディスク使用および添付ファイルを送信する際のネットワークの遅延を減らすことです。

View Logging は、もちろん改良の重要領域でした。現在 R5では、処理中のサーバーがクラッシュしたら、サーバーが再起動したときにはドミノ・ディレクトリーのビューは破壊され、再構築しなくてはならなくなると考えられます。再構築には、サーバーが完全に再起動するまである程度の時間がかかります。そのため、トランザクション・ロギングをビューに実装することは、サーバーの復帰にかかる時間を減らすことになります。再起動後にビューは変化せず、再構築する必要がないからです。

つまり、大きな新しい機能は、Single Copy Template（SCT）、添付ファイルの LZ1 圧縮、ストリーミング技術、View Logging です。これが、4大新機能ということになります。

上に戻る

拡張された機能について説明してください

主要なものとしては、単一コピー・オブジェクト・ストア（SCOS, Single Copy Object Store）いわゆる共有メールです。いくつかの大きな拡張を行ない、ディスク・アクセスの集中を軽減し、使いやすく管理しやすくしました。ツール（compact、updall、fixup）に対しても小さな変更をいくつか行なって、ユーザーにとって使いやすくしました。

上に戻る

いくつかの機能について詳しく取り上げていきましょう。ODSから始めたいと思います。ODS とは何ですか？なぜこれを変更したのですか？

ODSは「on disk structure」の略です。これは、データをディスク上に保存する際のフォーマットであり、データベースの情報を管理するのに必要なメタ・データの全てです。新しいバージョンへ変更するために、データベースを圧縮する時間がかかるので、私たちはどうしても必要な場合のみ ODS バージョンを変更します。ODSの変更は、普通、新しい機能を取り入れるために、あるいは何らかの機能を使えないようにするために行ないます。例えば、コードは LZ1 形式で保存された添付ファイルを、再圧縮して R5 フォーマットにすることなく、R5 フォーマットになおして複製することができないことを知っている必要があります。私達は、新しい ODS が必要となる Rnext に向けて何点か変更を行ないました。

View Logging（ビュー・ロギング )も変更点の1つです。ビューのデータを管理するために新しい構造体やメソッドが追加されたため、View Logging は新しい ODS データベース上でのみ行えます。Single Copy Template も新しい ODS を必要とします。設計情報を新しい参照ポインタ（reference pointer）から取得する方法を扱う新しい方法があります。すでに述べた通り、もう一つは LZ1 です。新しい圧縮方式 LZ1 を扱う構造体が存在しないため、古い形式の ODS データベースで LZ1 を使うことはできません。

上に戻る

新しい ODS は、R5 アプリケーションや R5 管理クライアントにとってどのような影響があるのでしょうか。

特に影響はありません。全ての ODS データベースが下位互換性を保証するように、大変な労力を費やしてきました。

上に戻る

View Logging について何か述べることはありますか？トランザクション・ロギングは基本的にビューのためのものなのですか？

まさに、その通りです。R5 に導入したトランザクション・ロギングの仕組みは、現在、ビューに適用されています。R5 ではビューのログを取ることはしていませんでした。この機能を追加した理由は2つあります。再起動時間についてはすでに述べました。大きなディレクトリーがあると、サーバーは 20 分から 30 分間停止してしまうことがあります。View Logging があれば、その時間は顕著に減少します。サーバーの再起動リカバリは、気に入っていただいている R5 からのものと同じトランザクション・ログを通して実行され、ビューは最新の状態になります。

View Logging はメディア・リカバリーにおいても利用できます。R5 においては、メディア・リカバリーをトランザクション・ログを用いて行なったとしたら、ビューは最新の状態にならず再構築が必要になります。Rnext では、データベースのバックアップを行ないそれを復旧し、そしてそれが Rnext ODS データベースであるならば、復旧後にビューは全て最新の状態になります。再構築の時間を待つ必要はないのです。

上に戻る

他にトランザクション・ロギングについて新しいことは何ですか？

R5 以後、トランザクション・ロギングについて追加、あるいは改善された点はいくつかあります。新しいスタイルを追加しました。以前は、[循環] と [アーカイブ] の2種類のスタイルがありました。[循環] は最大 4GB のログのセットです。ログの終端に達したら、先頭に戻って上書きします。これを繰り返して文字通り循環します。[アーカイブ] ではログを上書きすることはなく、必要に応じて新しいログ範囲（log extents）を作成します。これを時々、保管用のメディアにコピーします。[アーカイブ] は、データベースを復元するのに必要な情報を全て確実に保存しておくために、バックアップをとるという場合に利用するスタイルです。

linear あるいは looping linearと呼ばれる新しいスタイルを追加しました。これは [循環] スタイルに似ていますが、任意の容量を設定でき、4GB の制限がないことが相違点です。これにより、バックアップとメディア・リカバリーを循環の方法で行えることになり、そのため保管用のメディアが不要になります。十分なディスク容量があり、バックアップの間に記録される全ての情報を保存するログをとれるならば、この新しいスタイルが役に立つことでしょう。

バックアップ・ベンダー向けに NSF_RECOVER_DATABASES_WITH_CALLBACK という新しい API を追加しました。例えば、制限された国と通信する場合などいくつかの事例があります。政府は時々特定の国へ送信したメールを調べ、リストアップすることを必要とするかも知れません。この関数を利用すれば、このコール・バックを備えたログを使って復旧し、全ての更新されたノート（note）を確認することができます。

修復したログ範囲（log extents）の代替取り出しパス（alternative retrieve paths）を取得できるようにするフラグもあります。アーカイブされたログ範囲（log extents）は、メディアリカバリーの間に復元されるログ・ディレクトリーに保存されます。このフラグを利用して、アクセスの集中をさけ、ログ用のドライブのシーク・タイムを減らすために領域を別のドライブ上に修復できます。

さらに、IS_NEW_BACKUP_NEEDEDという API も新しく追加されました。循環ログにおいてこの API を呼んで、ログの先頭を上書きしたかどうかを知ることができます。上書きした場合、古いバックアップはすでに有効でなくなっているので、新しくデータベースのバックアップを行なう必要があります。

上に戻る

もう一つの新機能は Single Copy Template（SCT）ですが、これを開発したきっかけは何ですか？ディスク容量の節約だけが利点なのですか？

ディスク容量の節約が主な利点です。SCT の効果は、個別のデータベース全てに設計要素を保存する必要がないということです。設計要素はテンプレート内にだけ存在し、それを参照するという形をとるのです。例えば、Rnext のメール・データベースを開くと、基づいているテンプレートは Single Copy Template ですが、ユーザーには違いは全く分かりません。そのコードは見えないところで自動的に「ノート（note）を開くのだけど、どんな外見かを知らないのでテンプレートに問い合わせよう。」といっているのです。するとテンプレートは、「ノート・メモ（note memo）はこのような外見です。」という内容の情報を送り返します。それから、メール・データベースは実際の情報を書き込むのです。

R5 のデータベースにおいて、ノート（note）がこのように見えるという情報は、それぞれのメール・データベースに保存されています。SCT を利用すれば、メール SCT テンプレートに対して 6MB 程度という相当な節約になります。そのため、Rnext で新しいメール SCT データベースを作ると、サイズは 680KB 程度になります。SCT なしでそれを作ると、6MB を少し越える位になります。何千というメール・データベースを作成した場合、とても多くのディスク容量を節約することになると分ります。

上に戻る

SCT を有効にするために管理者がすべきことは何ですか？

これは自動的に行われるといったものではなく、テンプレートのプロパティーの1つなのです。テンプレート用のデータベース・プロパティー・ボックスの [デザイン] タブには、「これはテンプレートです。名前はこれです。」という情報を表示している領域があります。Rnext ODS データベース用に、「これは Single Copy Template です。」ということを示すチェックボックスもあります。このチェックボックスにチェックすると、[デザイナー] は、そのテンプレートから派生したデータベースすべてから設計要素を取り除きます。この動作が起こるのは、次にデータベースを開いたとき、または [デザイナー] がすべてのデータベース上で一晩中稼働するようにスケジュールされている場合です。[圧縮]を次に実行したときに、その領域が整理されます。管理者は、どのテンプレートを SCT と見なすのかが分かっている必要があります。

上に戻る

単一コピー・オブジェクト・ストア（SCOS）は R4の頃からあります。それがどういったものかを簡単に説明し Rnext において何が新しくなったのかを教えてください。

単一コピー・オブジェクト・ストア、あるいは共有メールは、ディスク容量節約の機能です。SCOS が行なうことは、複数のユーザー宛に送信されるメッセージを、ユーザーごとのメール・データベースに保存する代わりに、一つだけ保存しておくことです。それをある一カ所つまり共有メール・データベースに保存します。ユーザーがこの動作に気づくことは全くありません。ユーザーは自分のデータベースを開き、そのメッセージが自分のデータベース内にあるように思います。

R5 では、通常、すべてのメール・データベースが利用する共有メール・データベースは1つでした。ご想像の通り、このことが問題を引き起こしていたのです。Rnext において、私たちは問題を減らすために複数の SCOS データベースの自動設定を可能にしました。同様に、必要に応じて、複数のディレクトリーを作り、複数のディスクに渡って自分の共有メール・データベースを分散させることができます。

管理の負担を減らすために行なったことが他に2つあります。以前は、ユーザーのメール・データベースから参照されなくなったメッセージを削除するために、タスクを定期的に実行する必要がありました。今では、最後のユーザーが削除した時点でそのようなメッセージは自動的に削除されるようになりました。他の大きな改良点は、この機能の設定をドミノ・ディレクトリーのサーバー設定文書においたことです。その文書に [Shared Mail（共有メール）] という新しいタブがあり、ここでどのディレクトリーを使うか、各ディレクトリーにいくつデータベースを設けるか、新しい共有メールを受け付けなくなるディレクトリーの最大容量を設定できます。すべてのディレクトリーが一杯になったら、共有メールを使うのをやめ、メールは、各ユーザーのメール・データベースに完全な形で保存されます。ユーザー・インターフェースの拡張の背景には、管理において高い集中力を不要にしようという狙いがあります。

上に戻る

SCT も SCOS もデータベース容量の低減に有効ですが、データベース容量を減らすために他に何を行ないましたか？

大きなものとしては、LZ1 圧縮があります。添付ファイル向けの新しく性能のよい圧縮アルゴリズムです。これは Rnext の構成においてのみ利用するように、強く推奨します。R5 クライアントがサーバーから受け取った LZ1 形式の添付ファイルを読もうとすると、クライアントは LZ1 アルゴリズムを解釈できないので、サーバーは添付ファイルを再度ハフマン符号へ圧縮します。この作業にはかなりの時間を要しますので、十分に Rnext に対応した構成において　LZ1 を使うことを推奨します。

LZ1 によってハフマン符号よりも節約できる容量は、添付ファイルの種類によって変わります。添付ファイルのなかには密に詰まっているものもあります。たとえば、実行ファイルはテキスト・ファイルよりも密になります。そのため、容量をこれだけ節約できると言ったときには、実際には添付ファイルの種類によって変わるのです。実行ファイルでは、LZ1 のほうがハフマン符号の添付ファイルより平均で 15% から 20% 程度小さくなります。添付ファイルが多いときには、十分にディスク容量を節約できることが分かると思います。

上に戻る

LZ1 圧縮は、ネットワーク・パフォーマンスにどのように影響しますか？

Rnext だけを利用している場合には、添付ファイルの容量が減り、ネットワークを流れるデータ量が減るので、ネットワーク・パフォーマンスに影響します。

上に戻る

streaming attachments（ストリーミング添付ファイル）および streaming replication（ストリーミング複製）もネットワーク・パフォーマンスを改善すると思います。この機能について何かありますか？

ストリーミングはすばらしい機能です。ストリーミングの機能がない場合、ネットワーク越しにデータを送るときには、クライアント、あるいはサーバーが別のサーバーからデータを要求し、そのサーバーはひとかたまりのデータを送り返します。それから、要求した側が、「受信完了しました。さらに送ってください。」というメッセージを送ります。送信側のサーバーはそのメッセージを待ってから、次のひとかたまりを送信し、このやりとりを繰り返します。ストリーミングの機能があれば、クライアント、あるいはサーバーは情報を要求し、サーバーその全体を一度に送信します。データはネットワーク・バッファー・パケットに分解されますが、受信側のクライアント、あるいはサーバーが個々のパケットに対して受信確認を返送することはありません。したがって、受信確認を待つ時間がなくなります。

ストリーミングは、複製やネットワーク越しの添付ファイル送信、あるいはメール・ファイルの移動のような、管理タスクのためのデータベースのコピーにおいて利用されます。ストリーミングは pull のみ複製において利用されます。つまり、ユーザーは、サーバー間複製において、push-pull から pull-pull へ変更したくなるかも知れません。

上に戻る

新しいデータベース機能や拡張について、何か他におっしゃりたいことはありますか？

compact（圧縮）や fixup（修復）、updall（索引）に関して行なったことがいくつかあります。以前は、1つのデータベース、あるいは全てのデータベースで、このタスクを実行できました。そのうち1つか2つでは、ディレクトリーの指定もできました。3つのツール全てに対して Rnext 向けに行なったことは、データベースを指定（これは以前と同じです。）でき、その全てにおいてディレクトリーを指定できるようにしたことです。また、拡張子が IND の間接ファイル（indirect file）を作りました。このファイルには、データベースやディレクトリーのリストを保存しておくことができ、さらにデータの一部についてツールを実行する際には、容易にカスタマイズできます。私たちは、この機能は高く評価されるものと考えています。自分でも使ったことがありますが、この機能なしでやってきたということは今となっては驚くべきことです。IND ファイルは、テキスト・ファイルですので、必要なデータベース、あるいはディレクトリーのみを書き込むことができます。

また、fixup タスクをサーバー稼働中に実行できるように機能を追加しました。サーバー稼働中に起こりうる状況ですが、fixup は開いているファイルに対して実行することはできません。そのため、私たちは、fixup が、オフラインのデータベースを選択的に取り扱えるような方法を追加しました。

また、コピー形式圧縮（copy style compaction）中に temp ファイルの名前を変更するためのリトライの回数、およびリトライ間の待ち時間を指定する仕組みについても検討してきました。

上に戻る

新しい機能や拡張の中で、何が一番気に入っていますか？

気に入っているのは、View Logging です。私が担当した仕事ですから。再起動を速くできますので、管理者も View Logging を気に入ると思います。膨大なメール設定を管理する管理者は、SCOS の拡張には感動さえするかも知れません。View Logging 、単一コピーテンプレート、単一コピー・オブジェクト・ストアは、3つの主要な拡張といえると思います。

上に戻る

Rnext 後のノーツとドミノのデータベースの方向性については、どう考えますか？

ディスクの使用容量は常にの改善できる可能性がありますので、私たちはこれについてさらに進めていきます。ツールの使いやすさにも、絶えず注目していきます。より速く、より小さくするためにできることは、何でも行なっていきます。

キミリー・ガイルについて
キミリーは、1997 年からアイリスでデータベース・チームの品質管理技術者として働いています。それ以前は、Digital Equipment Corporation や Mango という小規模な新興企業に勤めていたことがあります。現在は、プロジェクトの指揮や、開発、QE の仕事をこなしています。キミリーは、フィギュアスケートのトレーニングをしています。そして、2002 年オリンピックでアメリカ・チームの一員となるという、かすかな希望をもっています。

ローラ・ラザフォードについて
ローラは、1999 年1月に娘のケイトが生まれるまで、ロータスでユーザー・アシスタント・グループのライターとして働いていました。その後、 2000 年9月には二人目 (！) の娘のマギーが生まれました。現在彼女は、二人の娘、二匹の犬、夫1人（こういった優先順位です）の世話にほとんどの時間を割いています。あいた時間の楽しみは、読書や走ること、そして、信じていただけないかも知れませんが、Iris Today の記事を書くことを愛しています。

上に戻る