SE関のノーツ/ドミノ徒然草

第3回 良い諦めが功を奏した複製機能

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

もう既に多くの方がご存じかとは思いますが、簡単に言えば複製(リプリケーション)機能は、離れた場所で2つ以上の同じデータベースを、時間差がありながらも常に同じ状態に保つようにする機能と言えるでしょう。現実の世界で例を考えてみましょう。社内の内線電話帳などは今でも多くの企業が紙の状態で各オフィスに配られていたりするでしょう。この紙の内線電話帳はいわば離れた場所にある2つ以上のデータベースです。誰かがオフィスを引っ越すたびにその変更は総務の方などが集めて定期的に配っているのが実状でしょう。この変更をコンピューターで、システム的に、もうすこし短い間隔で自動的に行うのが複製機能です。

ではどのくらい短い間隔で変更をやりとりすればよいのでしょうか? もちろん『まったく時間差なく』全ての電話帳が変更されるのが理想かもしれません。実際これを実現できるのが、前回からお話している完全なデータベースを目指しているリレーショナルデータベース(RDB)の一つの究極な形である分散RDBです。分散RDBは二相コミットという技術を使って、分散しているRDBをあたかも一つのRDBと見立てて操作することができます。ただそんな完全な電話帳を誰が望んでいるでしょうか?

実際にはどの時点から新しい電話番号を使うかというのは人によって千差万別、場合によっては新しいオフィスに行ってからもしばらく古いオフィスに寄って残務整理をするというのはよくあることです。このようにあいまいに動いている人間の営みを完全にデータベースに反映させようというのはあまり意味があるとは思えません。少しくらいの間、各々のデータベースの中身がわずかに違っても、あまり影響がない場合も多々あるのは明らかです。もしその完全性を追うがために、通信回線は高速なものを用意して、各サーバーも信頼性を高くしなければならなかったら、それだけの投資が本当に必要かどうか分からなくなってきます。

さらに電話帳をシステム化する場合、せっかくだから個人の簡単な自己紹介やプロフィールを載せようとか、顔写真を載せようとか、と言った付加価値を狙う場合でてきます。そうなると1人分のデータはかなり大きくなってきて、ますます完全に同期した、即ち変更が反映される時間をなくしたシステムを作ろうとするのはお金ばかりかかってしまいます。システムにいろいろな付加価値をつけるのを目的とするか、または遅れのない完全なデータベースを目的とするか。電話帳のような場合はおのずと答えは明らかになってくるでしょう。

複製機能は、このような要件の場合に、リアルタイムではなくある一定の間隔で、離れた場所のデータベースを同じ内容に保つということを効率良く、具体的には変更された差分データだけを交換するという方法で、極めて安いコストで行う機能と言えるでしょう。ここにタイトルであげた『良い諦め』が一つあります。リアルタイムを諦め安いコストをとったのです。

RDB

RDB
最近RDBの世界でも同様の理由で複製が実現され、使われだしました。オンラインのデータをある時間間隔でかまわないので複製して、いろいろな場所に配布し分析に使ったりするのが主な目的です。しかしこと複製機能に関して言えばノーツは一日の長たるものがあります。最も驚くべき点はその効率の良さです。

ノートパソコンを愛用している私ですが、そのノートパソコン上には10以上のノーツデータベースがサーバーから複製されています。しかも毎日その差分を複製するのですが、全部で万に近い文書数のデータベースから差分を見つけ出し1分もたたないうちにその日の変更分がサーバーと交換されます。これでノートパソコンは私のオフィスそのものです。あとはお客様からお客様へ、途中の喫茶店でもたいていの仕事をこなすことができます。

その秘密はやはり『良い諦め』にあります。もし丁寧なプログラマーが2つのデータベースの差分を交換するプログラムを開発したらどうするでしょうか? それぞれの2つのデータベースの一文書一文書を丹念に比較するか、または日付などをベースにその差分を探すこととなるでしょう。特にキーなどが特別にない文書ではこれらの作業は困難を極めます。このような方法では万単位の文書がある場合は、ノーツのような短時間では複製できないのは明らかです。

そこでノーツのとった方法は一つ一つの文書の名前ともなるユニークなキーを時間をベースに作成し、さらに作成日時や変更日時、そして変更回数などの履歴情報をすべての文書に持たせました。さらにフィールド単位で複製ができるように各フィールドにも変更された履歴を持たせてあります。どうでしょうテーブルを基本として管理されているRDBに比べていかにも重そうです。実際ノーツのデータベースはRDBなどにくらべてアクセスが遅いのは、多分にこれらが影響しているでしょう。しかしこうすることで2つのデータベース間の対応する文書は簡単に特定でき、さらにどの文書が新しいかという情報は、文書の中身を見なくとも、これらの付加的な情報だけで簡単に判別できるのです。アクセスのパフォーマンスを諦めて複製のやり易さをとったとでも言えるでしょう。まさに『良い諦め』の一つです。

さて全ての文書にキーがついてこれで複製は短時間にできそうにも思えます。しかし考えてみると削除された文書についてはどうでしょう。どれが削除されたかという情報は、そのままではいくら文書にキーがついていても、全ての文書のキーとつきあわせて、どれが削除されたかということを見つけ出さなければなりません。これでは文書が増えていくと複製の時間は膨大にかかってしまいます。そこでノーツは削除スタブという文書の抜け殻のようなものを考え出しました。つまり文書が削除されてもその中身は消されるものの、文書の情報と消されたという情報を残しておくという方法です。これも一種の文書のようなものですからこれを複製することで削除の情報をつぎつぎに伝えることができます。

しかしここでもう一つ問題が発生します。長い間データベースを使っているとデータベースが削除スタブだらけになってしまうのです。ここでノーツはもう一つの『良い諦め』をしています。ある日数がたったらもう削除スタブは自動的に消してしまうのです。通常では90日がこの日数で、もし90日以上複製をとらないと、正しく削除の情報は複製されません。しかしコンピューターの世界で90日も通信しないシステムはないと考えれば、やはり無難な選択と言えるでしょう。過去は諦める、これもやはり『良い諦め』の一つと言えるでしょう。

リアルタイムを諦め、アクセスパフォーマンスを諦め、過去を諦め、あとは複製をより速くするために履歴を残したりするテクニックを使い、最終的にノーツはコストが安く、高速で、実用上十分なデータの完全性で、複製という機能を実現できているのです。90年代の初めから100台を超えるパソコンサーバーと電話回線の低速回線を使って、膨大な数のデータベースを複製しているノーツユーザーがいたことは、まさにこの選択が正しかったことを証明していると言えるでしょう。

技術の議論ではよくトレードオフという言葉が使われます。つまり2つのことが相反する場合、どちらかを程よく諦めてもう一方のメリットをとり、製品などを実現するかということです。ノーツもこと複製に関しては、今までのデータベースでは考えてもいなかった『良い諦め』というトレードオフをして、今までにない製品に仕上がったと言っても過言ではないでしょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339113
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第3回 良い諦めが功を奏した複製機能
publish-date=12292007