読者です 読者をやめる 読者になる 読者になる

テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

Bizur: Log-less consensusの解説

Bizurの筆者が2日前に新しい投稿をしたようだ. この記事は, Raftのようなlog-basedのものとBizurのようなlog-lessのものを比較している.

distributedthoughts.com

ざっくりやっていくぞ

  • log-basedは, 状態を1つのglobal stateの初期値+変更のリストで表現する. これはlogを管理することも必要だしlog-compactionも必要になって複雑
  • 対してlog-lessは, global stateを毎回更新する. シンプル
  • log-lessは明らかに, 状態が大きくなった時に不利である. 例えば1GBの状態を毎回ネットワークで送り続けたら死ぬほど遅い
  • しかし, 状態が小さい時を考えると, log-lessは, シンプルな分だけ良いということになる
  • つまり, log-lessとlog-basedの間にはトレードオフがある
  • ではどんなユースケースはlog-lessが良いと言えるか? a) 状態が小さい場合 b) KVS. a)は自明だからb)だけ議論する
  • KVSは状態が小さくないですが? => Keyごとに独立の状態を定義すれば状態は小さくなるし, 並行性も良くなる (multi-key transactionは無視)
  • log-less最強は分かった. KVSをlog-basedで作ることを考えよう
    • 全体を1つの状態としてlog-basedをするのはscalabilityとconcurrencyの点で明らかにダメ
    • では同様にKeyごとにlog-basedしちゃえばどうか. 小さな状態に対して巨大なログが必要になるかも知れないから恐ろしく非効率となる(言い換えると, log-basedは状態が大きくないと活用出来ない). 明らかにlog-lessでやった方が速いしシンプルだし良い
    • Keyごとというのはまずかったから, M個のKeyがあるとしてそれをN個のlog-basedにマップするのはどうか?(M>N) このハイブリッド手法は短所を中和するからうまく行きそうに見えるが, それにしてもlog-lessの方が良い

結論

Bizurに関しては筆者のEzraとだいぶメールをやりとりしておれなりに理解した. 今後, Bizurを広めていく. 新しいソフトウェアのアイデアもある. 期待してほしい