今日のつぶやき - goldenportのブログ

KVSを見たとき、KVS=ISAMでCOBOL時代に戻るのか、と思ったけど、当たらずとも遠からずというところかな。KVSは分散を指向している点がISAMと違うという理解。 #

KVSの上にB+Tree的な分散インデックスを作るといったようになると、ISAM→VSAM→RDBMS的な進化となんとなく似てくる。分散という新しい属性を追加してスパイラル。 #

エンティティEAとEBでBASEトランザクションを具体的に考えてみると、EAをアトミックに更新した後、EBの更新をかなり長時間リトライし続ける、ということになる。ここまでは、アプリケーションで何とかなる。MQのような不揮発性キューを使う。 #

エンティティEAとキューQに対するACIDは保証されないので、Qに追加した後、EAを更新となるのかな。EAを工夫してキュー的に使う方法のほうがよいかもしれない。cronで定期的にEAを検索してリトライするとか。 #

EBに対するリトライ処理は一種のジョブとして、運用管理の対象になる必要がある。ジョブの監視、キャンセル、停止など。EBへのジョブをキャンセルする場合は、EAを何らかの定常状態に戻す必要がある。このあたりのメカニズムはアプリケーションの手にあまる。 #

EAの定常状態への戻し方としては、(1)元に戻す、(2)更新されっぱなしでも構わない、(3)補償処理を行う、の3つが考えられる。現時点ではミドルウェアのサポートが期待できないので、(2)のケースや、少し頑張って(1)のケースまでが選択肢かな。 #

EAにリトライ処理中(仕掛りBASEトランザクション存在中)のフラグを用意してロック的な解、あるいはバージョンを用いた楽観的な制御で、EBの更新が完了しない間は(更新後の)EAは触らないという準ACID的な解もある。 #

準ACID的な解まではぎりぎりアプリケーションでも組めるかも。でも、手組だとバグの温床になりそうなのでフレームワークか自動生成のアシストがないと事実上は利用が難しい。 #

「EAの定常状態への戻し方(2)更新されっぱなしでも構わない」で大丈夫な応用を見つけるのが、現時点でのクラウド・アプリケーションの落とし所かな。 #

ベストエフォートで元に戻しに行くんだけど、戻らなかったらごめんなさい、ぐらいの緩い補償処理とかもあるかもしれない。でも、中途半端にベストエフォートするより，何もしない方がよいかも。 #

ACIDでない以上、色々頑張ったけど結局ダメでした、ということが必ず発生するので、不整合が起きている状況を利用者に通知して、手動、利用者判断で不整合を解消する仕組みが必要になってくる。 #

(システム管理者向けではなく)利用者向け管理コンソールのようなもの。これはアプリケーションの手に余る。クラウド・プラットフォームが提供する統合メカニズムにアプリが乗っていく形でないと、開発工数の面でも運用性の面でも現実的でない。 #

長時間のリトライ後にエラーになることがあると、補償トランザクションも大変。リトライ中の金利とか。業務フローレベルで考えているような補償トランザクションをちょっとした更新処理でも考える必要が出てくるとなると、かなり大変。 #

Automatically shipped by LoudTwitter