4 ms·

Cool, makes more sense now. At a high level it would be interesting to make it as durable as possible in situations where say F=2 but you have 30 nodes. As I

by spotman 11y ago

Cool, makes more sense now. At a high level it would be interesting to make it as durable as possible in situations where say F=2 but you have 30 nodes. As I understand it, in this hypothetical case, the majority of the system would work fine if 3 nodes fail, but there could also be some percentage of transactions which are unfulfillable due to this scenario while there should be many that can still be answered with confidence. ( if I'm understanding correctly that data does not go into every node with a configuration like this and is consistently hashed across ) So was just curious how a prolonged period of this may turn into an unbounded problem when trying to digest your page on it. Ultimately it sounds like it's headed in a good path and embracing this partial-fail-but-that-doesn't-mean-show-is-over with specifics is a good thing to get ironed out and would certainly be a key thing to get right early, even if it's largely semantics and client behavior. Good luck, will try to play with it soon

msackman 11y ago
> As I understand it, in this hypothetical case, the majority of the system would work fine if 3 nodes fail, but there could also be some percentage of transactions which are unfulfillable due to this scenario while there should be many that can still be answered with confidence. ( if I'm understanding correctly that data does not go into every node with a configuration like this and is consistently hashed across ) Yes, you understand it perfectly. :) > Ultimately it sounds like it's headed in a good path and embracing this partial-fail-but-that-doesn't-mean-show-is-over with specifics is a good thing to get ironed out and would certainly be a key thing to get right early, even if it's largely semantics and client behavior. Indeed. Semantics are very important and I want to make sure GoshawkDB is easy to understand and reason about at all times.

by spotman 11y ago

msackman 11y ago

> As I understand it, in this hypothetical case, the majority of the system would work fine if 3 nodes fail, but there could also be some percentage of transactions which are unfulfillable due to this scenario while there should be many that can still be answered with confidence. ( if I'm understanding correctly that data does not go into every node with a configuration like this and is consistently hashed across ) Yes, you understand it perfectly. :) > Ultimately it sounds like it's headed in a good path and embracing this partial-fail-but-that-doesn't-mean-show-is-over with specifics is a good thing to get ironed out and would certainly be a key thing to get right early, even if it's largely semantics and client behavior. Indeed. Semantics are very important and I want to make sure GoshawkDB is easy to understand and reason about at all times.