前回

kumofsをベース にRDBMS用ストレージエンジンって作れないものか

にて仕様上「不定」と書いているところに意地悪な突っ込みをしたら作者からtweetが飛んできた。

frsyuki 後で書きたい。いつか書く。Set/Get操作の意味論はオリジナルではなく レプリカの整合性の問題だという話。MySQLとの比較で整理が必要かも。RT @L_star: kumofsをベースにRDBMS用ストレージエンジンって作れないものか

とまあこんな感じ。一応軽く調べてみたので補足するとストレージレベル、Tokyo Cabinetは一応トランザクションまでサポートしているし、WALとShadow pagingを備える、とあるためこのレベルでRDBMSクラスの持続性はほぼ維持できていると言ってよい。kumofsはデータ書くと言ってもディスクより下位層ぐらいまでいくともうTCお任せなので、ここが問題になるわけではなさそうだ。これはまず一安心である。setに失敗したからと言ってデータが壊れるわけではない。

なので以上２つを真に受けると、setが失敗して値が不定になるというのは「オリジナルにデータが書き込まれたが、レプリカには完全に書き込まれていない状態」になりうるのを示唆しているようだ。

ソースを見たところも、ここに何かおもしろい小細工があるわけではなく、単にレプリカにデータを書き込ませつつ自身にもデータを書いているだけのようだ。一応書き込みは非同期か同期かできるようなので、同期にしておけば信頼性はある程度高かろう。

逆のGetも同様にたいしたことはしていない。単にキャッシュ見て、あればそっちを返し、無ければ読み込んで返す。なのでどのレプリカに問い合わせているかどうかだけが問題のようだ。

と言うわけでレプリカの整合性の問題ということだそうだ。この種のクラウドシステム使う時点でその辺まで厳密に要求するな、と言われるとその通りである:)