TokyoCabinetの冗長性のポリシーについて作者が語る

@mikio1978

TCはDBを閉じずにkill -9 するとデータベースが壊れることがあるが、運がよければ壊れないように腐心していたし、壊れても直せるようにしていたが、KCではそれを一切しないことにした。すなわちDBを閉じずにkill -9すると絶対確実に壊れる。しかも壊滅的に壊れる。

@mikio1978

でもそれがstraightforwardってやつだと思う。openした時には前にcloseした時の情報が復元できるというのがストレージインターフェイスの要件であって、closeしていないものを保証すべきではない。

@mikio1978

一方で、現実の要請として、setに成功した時点で永続性を確保したいというのはあるから、やっぱりトランザクションが欲しくなる。でもBerkeley DBやTCのようにローカルなログでdurabilityを確保するのは俺のユースケースでは意味がない。

@mikio1978

flareとかkumofsとか、上層の機能でACID的な要請を確保してもらえると仮定するなら、DBMは逆にそれらの機能を完全に捨て去って性能のみを追求すべきだ。しかし、それは正論である一方、よりカジュアルなユースケースの要請にはまったく答えられていない。

@mikio1978

直でDBMを叩きたい場合が結構あるのだ。というか元来DBMはそのためのものなのだ。例えば日記キーワードランキングでは100万文書における各単語の出現数を数えているが、そのためにいわゆる分散KVSはオーバースペックすぎる。できるだけ短時間に更新したいので、ローカルで簡潔したい。

@mikio1978

ローカルで完結したとして、その処理中に電源が突然落ちてデータベースが壊れたらどうするのかと人は言うだろう。でも、再計算すればいいじゃないか。その時間が惜しければ、2台で同じことをやればいいじゃないか。

@mikio1978

分散KVSを使ったらどうせ2台どころじゃなく台数を突っ込むのだから、やはりDBMを直で叩いた方が安い。すなわち冗長化のためだけだったらアプリレベルで対処した方が安い。

@mikio1978

さて、アプリレベルで冗長化するのは非常に厄介だけれど、ローカルでデータ処理を完結したいという場合にのみ、DBM自体にdurabilityの要件が発生するということは覚えておきたい。

@mikio1978

アプリレベルで冗長化できない原因は、モデルが複雑であることと、それに比してプログラマが無能であることの2つの複合なんだろうけど、そういう課題は実際に多くありそうだ。日記キーワードランキングぐらいだと楽勝だが、リアルタイム検索のインデックスを整合性を保って更新するとかだとむずい。

@mikio1978

で、「DB＋計算プログラム」というセットを2系統まるまる用意すればアプリレベルの冗長化は成立するんだけど、それが難しいモデルの具体例はどんなのか。

@mikio1978

タスクキューのワーカとかで入力を消費してしまう場合は、2系統ともが取得するまでバッファしておくか、どこかに履歴を退避しといて一定期間再取得できるようにすればいい。入力がでかすぎる場合も同じ。

@mikio1978

とかいうもろもろのチェックサム的なメタデータを加えていくとどんどん肥大化するなぁ。でも変えるなら今が一番コストが小さい。

@mikio1978

で、結局のところ、2系統分の機材を用意できないか、それらの整合性をとるための仕組みを開発する工数がない場合に、1系統で運用したくなるわけだ。そして、性能要件がタイトであるためにネットワーク越しにDBを使いたくないならば、ローカルのDBMを採用することになる。

@mikio1978

そして、1系統しかないシステムがさらに不安定な場合、ディスクが壊れる頻度よりもkill -9しなきゃならない頻度の方が高いから、DBM単体のdurabilityがkill -9に耐えるとうれしいということになる。

@mikio1978

そこで俺が叫びたいのは、不安定なシステムを作ってる奴に安定性云々を語られるとなんだかむかつくということだ。まあ、だからこそDBだけは堅牢にしたいってのは分かるんだけど、偉そうに言われるとどうしてもむかついてしまう。