[Mew-dist 07565] Re: merging Network News (Re: user meeting?)

[Shigeya Suzuki]

>>>>> "kazu" == 山本和彦  <Kazu> writes:

kazu> 基本的に "o" とか mailagent とかで、ディレクトリに振り分ける作業自体が
kazu> 古いと感じています。

kazu> 「この条件にマッチするメールをこのフォルダにあると思え」とか「このフォ
kazu> ルダはこの条件にマッチするもの全部」とかルールを書く枠組を提供すれば、
kazu> 勝手にフォルダは増えます。でも実際にはディレクトリに移動させなくてもい
kazu> いはず。

kazu> 今までの環境を維持したいなら、このルールに従ってコピーを本当に移動させ
kazu> るコマンドを作るのでしょうね。

ああ、なるほど。virtual フォルダがうんぬんというのは、そういう意味か。
ルールが十分柔軟なら良いんでしょう。

# 実は、ウチで作ってるISP向けメールサーバで、それに近い構造を持ってます。
# たとえば、受け取ったボディは複数の recipient でも、1個しか持たないと
# いうことを実現するのにも使ってます。


kazu> そんなことは分かっていますよ。その前のメールで、Messge-ID: の DB と本
kazu> 文の DB というふうに説明しているはずです。

決して、あげ足とるつもりではないですが、
↑のように「別」とは、読めなかったです。

そういう気持なのは分からないでもないけれど。

kazu> 全文検索もできるようにしたいという目標です。

むろん、そんなことを分かっているのは分かっているのつもりではあります。

仮に、
	o Message-ID のDB

	  →きもちとして、当然getdateパース済みの日付情報とか、そうい
	  うのも効率化のために、入っていると仮定。

	o 本文のDB

	  全文検索の情報が入っている

と、します。

「いろいろなDBを使いたい」と言ったときに、全文検索のエンジンにどうイン
ターフェースもたせるのか、と、本体をどう保持するのか、とか、そこいらの
問題が出てくると思うのです。

全部重複してもっちゃうならそれで終わりですけどねぇ。

僕は、たとえば、Sybase とか Oracle をバックエンドに使いたいとか思って、
かりにお金が潤沢にあって全文検索モジュールを買えたとして(笑) そういっ
たものが使える枠組みがあれば、便利かなと思ってるのです。

その場合、ボディ部分はDBに突込まなければいけなくなるだろうとか、そうい
う制約が出てきます。そういう意味で、どこで切り分けるかは結構重要。なん
でも重複して持てばもちろんできるが…

たぶん、結構実装するモデルを仮定していると思うので、もうちょっと抽象的
に考えるべきかなとも思います。


kazu> バックアップがそんなに大変ですか？ 所詮ファイルなのでファイルシステム
kazu> のバックアップとなんら変わらないと思いますが。(差分バックアップも含め
kazu> て。)

これも「DB」によるのでは？
やはり、フォルダをどう保持するかで、気持に差があるきがしますねぇ。

単純にファイルならそれだけ保存すればいいけれど、これもエンジン次第だけ
れど、インデックスの部分は再構築するのを前提に考えていますか？ 全文検
索やろうとしたら、インデックスの構築は、結構コスト高ではないかと思うの
で、できれば差分とれるほうがウレシイきはします。

もちろん、お掃除もうまくできないといけない。

# 差分バックアップをとれたり、インデックスを戻せるエンジンが
# 手近にあるかどうかは、別の話です。
# 一般的な SQL的 DB だと、戻すときに index は作り直しでしょうけれど、
# 全文検索系はどうしてるのかな。。調べてみるべきだな…

たとえば、CD-R に焼くために移すとき、理想的には、インデックス毎うつっ
て欲しいキモチはある。ディスクに戻すときには戻って欲しいし、焼いたCDの
ものをそのまま検索もかけたいと思うし…


「所詮ファイル」であると言った時点で、制約つきますよね。つまり、データ
の保持の仕方は基本的にファイルであって、それに付加して、インデックスを
作ると想定していると。ファイルに対して外部的にインデックス作ってくれる
全文検索エンジンを使うというのを想定しているのかな。

僕は、↓で言うところの DB/File systme の選択の幅をもう少し広げてかんが
えられるのではないかと思っています。必要に応じて「ファイルで保持する」
インターフェースもあって欲しいかな、とも。

つまり、クライアント側の（あるいは↓の DB/Folder I/F のレベルの）イン
ターフェースをかえずに、最後のバックエンドをどうするのかに自由度持たせ
られるとうれしい。この「自由度」の想定に少しずれがあるだけかな。


> この「低いレベル」というのは、何をさしていっていますか？
> （どこから見て低いのかが分からない）

kazu> Mew <-[IMAP]-> C++ Daemon <--[DB/folder IF]--> DB/file system

kazu> の左側です。

うーん。

shigeya


PS. 山本さんは、１メッセージ１ファイル方式を使うともなんとも書いてない
のに気づいたから、捨てようかと思ったのだけれど、途中まで書いたのオマケ
としてつけます。

# こんなことやってる時間は、なーい！

------------------------------

かりにファイルで、たとえば、ファイルの数が増えるのがイヤだということで、
とりまとめたとして、フォルダを仮想的に用意するとして、メールボディの実
体はどう保持されるのを仮定していますか？

たとえば、 A B C ってメールが届いたとして、

今の MH フォルダだと
	inbox/1  	中味は A 
	inbox/2 	中味は B
	inbox/3 	中味は C

mbox だと、
	inbox		中味に A, B, C

当然、毎回全部 mbox をなめるなんて構造にしたらパフォーマンス的にメリッ
トは小さいから、付加情報を（VM みたいに）作って置く、たとえば、
inbox.db とか用意するのでしょう。

さて、僕が想像しているように、リファイルや削除が仮想的に行われるとした
ら、たぶん、

	mbox
	mbox.db

とかいう、外には見えない「箱」があって、手前に

	inbox.db	(inbox フォルダ)
	mew-dist.db	(mew-dist フォルダ)

とかあって、そいつの参照を mbox に向ければ仮想的にできるでしょうけれど、
削除したときはどうするのでしょう。もしくはこういう仕掛けの多段の組み合
わせでしょうけれど、そうなると どうしても mbox が巨大になりますよね。
（1G  もあったらイヤ。）

そうなるとイヤだから、表に見えない箱を複数にしたりするのは可だと思うけ
れど、それはそれでまた問題かもしれない。結構メンテナンスが面倒だし、バ
グの入り込む余地が大きそう…（そんなこと考えてねーよと言われるのがオチ
か。）

お掃除も問題だけれど、かかれていたようにDBが壊れたらイヤですな。DBが壊
れたら（容易にあり得ますね……たとえば、ディスクがいっぱいになったら壊
滅的かも）仮想フォルダ自体の情報が失われるので大変なことになるかも…

それを避けるためにはトランザクションを保持するとか、だんだん大げさなこ
とになってゆくのか？