[pgsql-jp: 30594] Re: 画像データベースの作成。

Jun Kitamura kitamura @ zoozee.jp
2003年 7月 25日 (金) 13:10:08 JST


北村(あて逃げ失敗)です。
こんなにツッコミがあるとは思わなかったので、まとめてここに書
かせてください。ご勘弁をぉ。

> こんにちは、青山です。
(snip)
> > 「ファイルの実体」と「データベース内のファイル格納場所情報」
> > の整合が取れないような状態にするのは(私の観点からは)許されざ
> > るべきことであり、それを「仕様」としてしまうのは変です。
> 
> ここでの「仕様」というのはソフトウェア単品の仕様のことではなく、
> 運用や障害時対応、リスク管理まで含めたシステム全体の仕様のことを
> 言っています。
> 「許されざるべき」と言っても、障害は必ず発生するわけなので、完璧に
> 保証できることはあり得ません。
> どこまで許容するか(0.1%か0.001%か、等)、もし発生した場合はどのような
> 対応が可能かという観点から、許容可能な「リスクの大きさ」を仕様とするのが
> 正しい(というか一般的な)システム設計ではないでしょうか?

はい。了解です。もちろん、私も 100% 保証します! とう仕様の
話をしていたわけではありません。また、概略設計にもなってない
状態ですので、その辺は理解してもらえるだろうとw。

前回のメールでは、

> という方式でしたが、まれに、HDDの容量不足やディスク不良による
> 書き込みエラー等が発生したときに、DB内のパス情報は格納されているが
> 画像ファイルが存在しない状態が発生したり、あるいは、
> ファイルをFTP等で追加したけれど、DB処理がバグ等の問題により
> ロールバックしてしまい、DB内に情報がないのにファイルだけが
> 浮いた状態で存在する、という不整合状態が発生していました。

ということで、文面から(勝手に)大量にそういう状態が発生したと
思いましたので、「こうすれば避けられるのでは?」と思ったまで
です。ですので、

[pgsql-jp: 30590] moto kawasaki <kawasaki @ kawasaki3.org>
> そういう意味で、(回避策はあるものの)「本質的にデータの紛失や矛盾等を許容」せ
> ざるを得ないのでしょう。

完璧な・・・というつもりでなかったのですが、私の文面が悪かっ
たようです。(読み返したら、確かに完璧な・・って感じの文章で
した)w

[pgsql-jp: 30592] Hirokazu Aoyama <aoyama @ cds.ne.jp>
> (1) ファイル処理を失敗した場合の「ロールバック」処理が本当にうまくいくのか?

もちろん、上手くいかない時もあるでしょう。定期的に、データベー
ス内のデータとファイルの実体をチェックし、不必要なレコードの
削除、またはファイルの削除を行なう必要も出てくるでしょう。

ALIHALA Hiroshi <arihara.hiroshi @ jp.fujitsu.com> wrote:
>  これ、OS(特にWin系)でアプリがこけた場合とかに発生する現象に似てま
> すね。DB 云々じゃなくファイル全般での話です。
>  実体とポインタを別々にするならば、起こりうる問題として CHKDSK ユー
> ティリティ相当のチェックツールを作っておいた方がいいかもしれません。

と、その通りだと思いますよ。

[pgsql-jp: 30592] Hirokazu Aoyama <aoyama @ cds.ne.jp>
> (2) ファイルを削除してからCOMMITを行うまでの間にDBMSとクライアント
>     との通信が切れたりシグナルを受信したりして強制的にロールバックして
>     しまうケースも考えられる。
>     この場合は、DB内にレコードは残っているが、ファイルは存在しないという
>     形になる。

[pgsql-jp: 30593] Hirokazu Aoyama <aoyama @ cds.ne.jp>
> 追加がある以上、登録ミスなどが必ず発生しますので、DELETE処理は
> 必須だろう、という半ば思い込み、半ば常識的判断のもとに書きましたが、
> 現実的には恐らくこのDELETE処理が鬼門になるかと思います。

たしかに・・・。DELETE ありますね。鬼門になりそうですね。
この場合、データベース内にファイル名が無くファイル実体はある、
という方が救いがあるので、そういう設計にするかと思います。

[pgsql-jp: 30592] Hirokazu Aoyama <aoyama @ cds.ne.jp>
> 責任分界点として、作りこんだアプリケーションのレベルでは整合性を保証するが、
> DBMS製品レベルの問題は保証できない、とか、DBMS製品レベルでは保証するが
> OSやハードのレベルでは保証できない、など、どこで保証するかによって、
> 顧客側のリスクの取り方が変わってきますので、その「保証レベル」を明確に
> して、誰がどう責任を持つのかを最初に客に言って了承をとっておかないと、
> 後でトラブルになる可能性もあります。

責任範囲の明確化はその通りです。可能性というか、確実にトラブ
ルになりますw。

[pgsql-jp: 30592] Hirokazu Aoyama <aoyama @ cds.ne.jp>
> また、ファイルシステムのキャッシュの問題があるため、DBのCOMMITが
> 完了する前に、ファイルがディスクに書き込まれていることを
> 100%に近いレベルで保証しておく必要があると思います。

[pgsql-jp: 30591] Tetsuya Kakura <kakura @ saki.netwk.ntt-at.co.jp>
> ファイルシステム上に画像ファイルを置くと、T1 のロールバックが
> 失敗する場合のリカバリをどのようにするかとか、T1 のロールバッ
> クにファイルの置き換えや移動を行わなければならない場合に元のフ
> ァイルに戻す手法や元の場所に戻すことを考えなくてはならず、解決
> 不能ではないにしても、エラー時の対処は煩雑になると考えられるの
> ではないですか?そう考えるとファイルシステム上に画像ファイルを
> おく場合は、矛盾を起こさないための完璧なロジックを組むのは結構
> 大変そうに思うのですが?

ごめんなさい、そこまで細かい話をするつもりは無かったんで・・
・。細かい話しになっていけば、flush しなくてはならない、とか、
T1のロールバックは /tmp からも /img からも削除し何も無い状態
に戻すことにする、とかあると思いますよ。
DB の実体もファイルシステム上にあるわけでキャッシュ云々なら
そこまで言及しなくてはならい、とか、HDD から書き込まれていと
返事は来たが実は(HDDの)キャッシュからディスクへの写し込みに
失敗していた・・とか、散々出てくるでしょう。

リアルタイムに整合性を100%とれ、というつもりでは無かったこと、
詳細な設計までするつもりでもなかったこと、ご了承くださいませ。





pgsql-jp メーリングリストの案内