[pgsql-jp: 30592] Re: 画像データベースの作成。
Hirokazu Aoyama
aoyama @ cds.ne.jp
2003年 7月 25日 (金) 11:25:29 JST
こんにちは、青山です。
> 北村(逃避モード)です。
>
> A.実行型プログラムで処理する場合
> トランザクション(T1)開始
> /tmp/xxx.jpg を /img/xxxx.jpg にコピー
> →NG の場合は T1 ロールバック
> RDBMS のトランザクション(T2)開始
> ・DB に /img/xxxx.jpg をインサート
> →NG の場合は T2 ロールバック
> ・その他の DB 処理
> →NG の場合は T2 ロールバック
> T2 COMMIT
> /tmp/xxxx.jpg を削除
> T1 COMMIT
> T1 ロールバックは、/img/xxxx.jpg を削除します(プログラム内
> にそういうルーチンを作成してあることを意味します)。
>
> B.PostgreSQL でファイルをコピーする関数を作成した場合
> PostgreSQL のトランザクション開始
> ・その他の DB 処理
> →NG の場合は ロールバック
> ・DB に /img/xxxx.jpg をインサート
> トリガにより関数(F1)呼び出し
> (F1)
> インサートされた名称により /img からファイルをコピー
> →NG の場合は FALSE 返却
> /tmp 内の該当ファイルを削除
> →NG の場合は FALSE 返却
> (F1)が FALSE の場合は RAISE ERROR
> →NG の場合は ロールバック
> PostgreSQL のトランザクション COMMIT
> (トリガにしない場合は、「その他のDB処理」を後に持ってきても
> 問題ないかも)
>
> 漏れがあるかもしれませんが、上記 A. または B. で 1つのトラン
> ザクションです。
これは一見するとトランザクションのように見えますが、実際には、
以下のような問題があります。
(1) ファイル処理を失敗した場合の「ロールバック」処理が本当にうまくいくのか?
(2) ファイルを削除してからCOMMITを行うまでの間にDBMSとクライアント
との通信が切れたりシグナルを受信したりして強制的にロールバックして
しまうケースも考えられる。
この場合は、DB内にレコードは残っているが、ファイルは存在しないという
形になる。
これらが保証されないため、トランザクションは成立していないと思います。
また、ファイルシステムのキャッシュの問題があるため、DBのCOMMITが
完了する前に、ファイルがディスクに書き込まれていることを
100%に近いレベルで保証しておく必要があると思います。
> > まずは、そのリスクを仕様上許容できるのかできないのか、という観点から
> > チェックすべきではないかと思います。
>
> 「ファイルの実体」と「データベース内のファイル格納場所情報」
> の整合が取れないような状態にするのは(私の観点からは)許されざ
> るべきことであり、それを「仕様」としてしまうのは変です。
ここでの「仕様」というのはソフトウェア単品の仕様のことではなく、
運用や障害時対応、リスク管理まで含めたシステム全体の仕様のことを
言っています。
「許されざるべき」と言っても、障害は必ず発生するわけなので、完璧に
保証できることはあり得ません。
どこまで許容するか(0.1%か0.001%か、等)、もし発生した場合はどのような
対応が可能かという観点から、許容可能な「リスクの大きさ」を仕様とするのが
正しい(というか一般的な)システム設計ではないでしょうか?
# 「100%許容できない」と記述してある要求定義書なんて読んだこと
# ありませんが・・。
# 特にオープンソースの場合はそんなこと書けないですよね。そこを保証するとは
# 契約書に書けないですから。
責任分界点として、作りこんだアプリケーションのレベルでは整合性を保証するが、
DBMS製品レベルの問題は保証できない、とか、DBMS製品レベルでは保証するが
OSやハードのレベルでは保証できない、など、どこで保証するかによって、
顧客側のリスクの取り方が変わってきますので、その「保証レベル」を明確に
して、誰がどう責任を持つのかを最初に客に言って了承をとっておかないと、
後でトラブルになる可能性もあります。
--
Hirokazu Aoyama <aoyama @ cds.ne.jp>
pgsql-jp メーリングリストの案内