it seem that the performance gain of not having all update go to a single log could be also achieved by having one log per bucket. My understanding is that with Bizur all update for the same bucket also need to proceed sequentially.
Also with most system like Raft a failed machine trying to rejoin the cluster does not need to download the complete transaction log but can instead download a snapshot of the state machines then load log entry created after this snapshot.
Another aspect is that if the bucket contain a large number of key. From the Bizure paper it seem that the complete set of "key->value" need to be sent to replica each time the bucket is updated instead of only the entry that changed.
This would produce much larger network traffic compared to Raft or Zab when all replica are mostly in sync
1) Keeping a log mechanism per bucket would be expensive, since it is a heavy mechanism. It will cost memory & network traffic. The additional information needed by Bizur for a bucket is minimal, basically, just a version.
2) In Bizur, rejoining the cluster includes the equivalent of copying the snapshot. However, that node can start participating in the Bizur even before it finished reading the entire snapshot, because of the key-value data model. Once a bucket has been copied, it can start serving it, which is much faster than log-based algorithms.
3) You are correct about the size of a bucket. In our implementation we aim to have up to 8-10 keys in a bucket, to avoid the overhead you mentioned. That's why it's especially important to be very efficient pet-bucket (see point #1).
Also with most system like Raft a failed machine trying to rejoin the cluster does not need to download the complete transaction log but can instead download a snapshot of the state machines then load log entry created after this snapshot.
Another aspect is that if the bucket contain a large number of key. From the Bizure paper it seem that the complete set of "key->value" need to be sent to replica each time the bucket is updated instead of only the entry that changed. This would produce much larger network traffic compared to Raft or Zab when all replica are mostly in sync