From ab4755dfa12f4f5d2e60a945fdcfdbf2b26634f2 Mon Sep 17 00:00:00 2001 From: fukachan Date: Sat, 31 May 2003 08:51:07 +0000 Subject: reconstruct/update considerations around DB. --- fml/doc/ja/tutorial/book.sgml | 5 +- fml/doc/ja/tutorial/include/chapters.ent | 4 +- fml/doc/ja/tutorial/internals/db.sgml | 196 --------------------- fml/doc/ja/tutorial/internals/db.thread.sgml | 60 ------- fml/doc/ja/tutorial/internals/db_modules.sgml | 243 ++++++++++++++++++++++++++ fml/doc/ja/tutorial/internals/dbms.sgml | 27 ++- fml/doc/ja/tutorial/threadtrack/db.sgml | 6 +- 7 files changed, 277 insertions(+), 264 deletions(-) delete mode 100644 fml/doc/ja/tutorial/internals/db.sgml delete mode 100644 fml/doc/ja/tutorial/internals/db.thread.sgml create mode 100644 fml/doc/ja/tutorial/internals/db_modules.sgml (limited to 'fml/doc/ja/tutorial') diff --git a/fml/doc/ja/tutorial/book.sgml b/fml/doc/ja/tutorial/book.sgml index 72b29245..55ef7b0a 100644 --- a/fml/doc/ja/tutorial/book.sgml +++ b/fml/doc/ja/tutorial/book.sgml @@ -2,7 +2,7 @@ This is an sgml using DocBook dtd. Use sgmltools version 2.0.x or above to generate various output formats. -$FML: book.sgml,v 1.56 2003/05/12 10:16:38 fukachan Exp $ +$FML: book.sgml,v 1.57 2003/05/26 08:56:51 fukachan Exp $ --> &chapter.io.abstraction; &chapter.lock; - &chapter.db; - &chapter.db.thread; + &chapter.db.modules; &chapter.dbms; diff --git a/fml/doc/ja/tutorial/include/chapters.ent b/fml/doc/ja/tutorial/include/chapters.ent index 4bfb331d..633c2df7 100644 --- a/fml/doc/ja/tutorial/include/chapters.ent +++ b/fml/doc/ja/tutorial/include/chapters.ent @@ -1,5 +1,5 @@ @@ -107,8 +107,8 @@ + - diff --git a/fml/doc/ja/tutorial/internals/db.sgml b/fml/doc/ja/tutorial/internals/db.sgml deleted file mode 100644 index 0eeaa829..00000000 --- a/fml/doc/ja/tutorial/internals/db.sgml +++ /dev/null @@ -1,196 +0,0 @@ - - - - - データをどう保持するべきか？(データベースの扱い) - - - -永続的にデータを保持する方法はいくつかあります。いい加減なものから大真 -面目なものまでいろいろです。大真面目に考えると、LRU などの機能を持った -モジュールを利用して作るのかもしれませんが、やや大げさで、いまひとつしっ -くりこない気がします。つまり、そこまで真面目に virtual memory のような -実装をしなくてもよいのでは？という気がします。それに、もし切実に必要な -ら、なんらかの - -DBMS - - - - DBMS = DataBase Management System - - -を使うべきでしょう。 - - - - -そういったわけで FML では、expire の仕方に応じて２つのデータ保持クラス -を用意しています。それは「サイズを気にせず、時間を区切って expire する -のか？」もしくは「使用する領域のサイズをある程度気にするか？」の２種類 -です。 - - - - -現在では -Tie::JournaledFile クラス -を利用した -Tie::JournaledDir クラス -もあるので、 -将来 -Tie::JournaledDir もしくは File::CacheDir かのいづれかは -不必要になるかも知れません。 -また、インターフェイスの違いから適宜使い分けるのかもしれません。 - - - -2002/08: -File::CacheDir は改名し、なくす方向で考えています。 -そもそも File::CacheDir は -FML/Process/Kernel.pm -と -FML/Filter/TrafficMonitor.pm -でしか使ってません。 -しかも、 -TrafficMonitor.pm は事実上未完成なので、まだ変更が可能です。 -実際 FML::Process::Kernel の var/mail/ でしか使っていないので、 -File::CacheDir を使わないようにすることが可能でしょう。 - - - - - - - Tie::JournaledFile クラス - - - -これは、一つのファイルに append していくタイプです。 -この機能は - - Tie::JournaledFile - -クラスが提供します。 - - - - -このクラスは、データを追加もするし参照もしたい場合に用いられますが、 -追加のオペレーションしか行なえません。 -つまり LFS (Log Structured File System) のような振舞いです。 - - - - -参照する際は最後に追加したデータが取り出されます。 -つまり、値は追加された値を last match で取り出しています。 - - - - -逆に、必要な場合には、過去のログを追跡していくことができます。 - - - - -このクラスは、サイズを度外視して一定期間のあいだ記録しておきたいデータ -に対して使います。例えば、登録時の confirmation のキャッシュや -message-id キャッシュです。これらは expire を時間で制御したいからです。 -このクラスは引数でファイル名を与えることになっているので、ファイル名に -日付付のファイルを選ぶと良いでしょう。 - - - - -なお、普通の tie() とは違う - -key => [ - ろぐ1 (どっかのふぁいるのどっかの行), - ろぐ2 (どっかのふぁいるのどっかの行), - ろぐ3 (どっかのふぁいるのどっかの行), -] - -型のデータとりだしをしたい場合があります。 -この形のデータ取り出しは -get_all_values_as_hash_ref() -メソッドを使えば可能です。 - - - - - -なお検索時の挙動の -first match と last match は切替えることができます。 -どちらの戦略で探すのか、 -クラスオブジェクトを生成する際に明示的に指定することが推奨されます。 -デフォルトは first match です。 - - - - - - - - - File::CacheDir - - - -この - - File::CacheDir - -クラスは、主にサイズに上限を設けたいタイプのデータを蓄える場合に用 -います。expire の時間については気にしません。 -サイズで有無を言わさず切ってしまいます。 - - - - -デバッグ等に用いるデータはこれで十分と考えています。 -普段は使わないデバッグのために、サイズを食われるのも嫌ですから。 - - - - -このクラスは、あるディレクトリ(例: db/)の有限の複数のファイル郡の中に -データを蓄えます。 -例えば db/ に 1 〜 100 の名前のファイルがつくられ、 -順番に使われてきます。 -これらのファイルはぐるぐる回って使われ、上書きされます。 - - - - - -旧 RingBuffer は File::CacheDir に統合されました。 - - - - - - - - - - モジュールの使い分け - - - -う〜ん、困りましたね… - - - -元々はサイズの上限を重視する場合が -リングバッファ、つまり File::CacheDir でした。 -逆に、 -時間方向の expire を重視する場合は Tie::Journaled* を使うつもりでした。 -でも時間方向の File::CacheDir はそれと一緒じゃん;) - - - - - diff --git a/fml/doc/ja/tutorial/internals/db.thread.sgml b/fml/doc/ja/tutorial/internals/db.thread.sgml deleted file mode 100644 index 059a9824..00000000 --- a/fml/doc/ja/tutorial/internals/db.thread.sgml +++ /dev/null @@ -1,60 +0,0 @@ - - - - - スレッド・データベース - - - - -スレッドのデータベースは -「主に article_id か thread_id が primary key」 -です。 - -$status open / close -$ml_name elena -article_id 100 -thread_id elena/100 -$from ヘッダの From: (めーる＠アドレスの形式) -$sender ヘッダの Sender: (めーる＠アドレスの形式) -$x_sender ヘッダの X-Sender: (めーる＠アドレスの形式) - -[thread] - - aritcle_id => thread_id - -[article] - - thread_id => article_ids - - Example: elena/100 => 100 101 103 105 - -[date] - - aritcle_id => unix_time - -[sender] - - article_id => from - -[message_id] - - mesasge_id => thread_id - -[status] - - thread_id => $status - -[index] - - thread_id => "$ml_name " * - - Example: support/100 => support sales - - - - - - diff --git a/fml/doc/ja/tutorial/internals/db_modules.sgml b/fml/doc/ja/tutorial/internals/db_modules.sgml new file mode 100644 index 00000000..7aa5d74d --- /dev/null +++ b/fml/doc/ja/tutorial/internals/db_modules.sgml @@ -0,0 +1,243 @@ + + + + + データベース関連モジュール + + + + + + 概要もしくは理想像 + + + +ＭＬドライバはメールのさまざまな要素をデータとして保存する必要がありま +す。しかしながら、同じ要素でも、永続的に持つべき場合と、一定時間経過後 +に捨てて良い扱いの場合とがあります。 + + + +前者の例はスレッドのデータです。一方、後者の例はフィルタシステムの持っ +ている message-id cache などです。スレッドデータベースも同じく +message-id のデータを持っていますし、記事の分については重複しています。 +ですが、２つの有効期間は異なるため別々に取り扱う必要があります。 + + + +とはいえ実際問題スレッド関係とそれ以外に集約できそうなので、 +各モジュールの理想的な関係は次のようになるのでしょう。 + +モジュールＡ ---|ア|----- スレッド DB +モジュールＢ ---|ダ| +モジュールＣ ---|プ| +モジュールＤ ---|タ|----- キャッシュ (有効期限つき) + +このスレッド DB は + +Mail::Message::DB + +のようなものとし、各種アダプタ層ががんばってほしい。 +また、キャッシュの方だが、現在では Tie::JournaledDir もしくは +File::CacheDir かのいづれかが使われることとなる。 + + + + + + + + 永続的なデータの保持 + + + +永続的にデータを保持する方法はいくつかあります。いい加減なものから大真 +面目なものまでいろいろです。大真面目に考えると、LRU などの機能を持った +モジュールを利用して作るのかもしれませんが、やや大げさで、いまひとつしっ +くりこない気がします。つまり、そこまで真面目に virtual memory のような +実装をしなくてもよいのでは？という気がします。それに、もし切実に必要な +ら、なんらかの + +DBMS + + + + DBMS = DataBase Management System + + +を使うべきでしょう。 + + + + +そういったわけで FML では、expire の仕方に応じて２つのデータ保持クラス +を用意しています。それは「サイズを気にせず、時間を区切って expire する +のか？」もしくは「使用する領域のサイズをある程度気にするか？」の２種類 +です。 + + + + +現在では +Tie::JournaledFile クラス +を利用した +Tie::JournaledDir クラス +もあるので、 +将来 +Tie::JournaledDir もしくは File::CacheDir かのいづれかは +不必要になるかも知れません。 +また、インターフェイスの違いから適宜使い分けるのかもしれません。 + + + +2002/08: +File::CacheDir は改名し、なくす方向で考えています。 +そもそも File::CacheDir は +FML/Process/Kernel.pm +と +FML/Filter/TrafficMonitor.pm +でしか使ってません。 +しかも、 +TrafficMonitor.pm は事実上未完成なので、まだ変更が可能です。 +実際 FML::Process::Kernel の var/mail/ でしか使っていないので、 +File::CacheDir を使わないようにすることが可能でしょう。 + + + + + + + + + Tie::JournaledFile クラス + + + +これは、一つのファイルに append していくタイプです。 +この機能は + + Tie::JournaledFile + +クラスが提供します。 + + + + +このクラスは、データを追加もするし参照もしたい場合に用いられますが、 +追加のオペレーションしか行なえません。 +つまり LFS (Log Structured File System) のような振舞いです。 + + + + +参照する際は最後に追加したデータが取り出されます。 +つまり、値は追加された値を last match で取り出しています。 + + + + +逆に、必要な場合には、過去のログを追跡していくことができます。 + + + + +このクラスは、サイズを度外視して一定期間のあいだ記録しておきたいデータ +に対して使います。例えば、登録時の confirmation のキャッシュや +message-id キャッシュです。これらは expire を時間で制御したいからです。 +このクラスは引数でファイル名を与えることになっているので、ファイル名に +日付付のファイルを選ぶと良いでしょう。 + + + + +なお、普通の tie() とは違う + +key => [ + ろぐ1 (どっかのふぁいるのどっかの行), + ろぐ2 (どっかのふぁいるのどっかの行), + ろぐ3 (どっかのふぁいるのどっかの行), +] + +型のデータとりだしをしたい場合があります。 +この形のデータ取り出しは +get_all_values_as_hash_ref() +メソッドを使えば可能です。 + + + + + +なお検索時の挙動の +first match と last match は切替えることができます。 +どちらの戦略で探すのか、 +クラスオブジェクトを生成する際に明示的に指定することが推奨されます。 +デフォルトは first match です。 + + + + + + + + + File::CacheDir クラス + + + +この + + File::CacheDir + +クラスは、主にサイズに上限を設けたいタイプのデータを蓄える場合に用 +います。expire の時間については気にしません。 +サイズで有無を言わさず切ってしまいます。 + + + + +デバッグ等に用いるデータはこれで十分と考えています。 +普段は使わないデバッグのために、サイズを食われるのも嫌ですから。 + + + + +このクラスは、あるディレクトリ(例: db/)の有限の複数のファイル郡の中に +データを蓄えます。 +例えば db/ に 1 〜 100 の名前のファイルがつくられ、 +順番に使われてきます。 +これらのファイルはぐるぐる回って使われ、上書きされます。 + + + + + +旧 RingBuffer は File::CacheDir に統合されました。 + + + + + + + + + + モジュールの使い分け + + + +う〜ん、困りましたね… + + + +元々はサイズの上限を重視する場合が +リングバッファ、つまり File::CacheDir でした。 +逆に、 +時間方向の expire を重視する場合は Tie::Journaled* を使うつもりでした。 +でも時間方向の File::CacheDir はそれと一緒じゃん;) + + + + + diff --git a/fml/doc/ja/tutorial/internals/dbms.sgml b/fml/doc/ja/tutorial/internals/dbms.sgml index 881fcfea..b069ee07 100644 --- a/fml/doc/ja/tutorial/internals/dbms.sgml +++ b/fml/doc/ja/tutorial/internals/dbms.sgml @@ -1,5 +1,5 @@ @@ -7,6 +7,12 @@ データベース管理システム + + + + 概要 + + DBMS との通信は @@ -21,5 +27,24 @@ IO::Adapter IO::Adapter の前段階のプログラムが頑張る必要があります。 + + + + + + TODO + + + +メソッドが必要最少限になっているかは考えた方がいい。 +けれど、 + +IO::Adapter + +のメソッド準拠ではあるので、とりあえずいいのかな。 + + + + diff --git a/fml/doc/ja/tutorial/threadtrack/db.sgml b/fml/doc/ja/tutorial/threadtrack/db.sgml index e97e2241..48e7dfcf 100644 --- a/fml/doc/ja/tutorial/threadtrack/db.sgml +++ b/fml/doc/ja/tutorial/threadtrack/db.sgml @@ -1,5 +1,5 @@ @@ -45,7 +45,9 @@ x_sender -いずれの .db も article_id か thread_id が primary key です。 +スレッドのデータベースは +「主に article_id か thread_id が primary key」 +です。 具体的に書くと以下のようになります。 [thread .db] -- cgit v1.2.1