Anyone have an idea how it behaves differently from google's jump hash algorithm? The cool thing about google's one is it's so short I can include it in a HN comment:
Well I looked it up; nginx, apparently, uses ketama -- it's a ring-style hash probably works better for web backends than the jch above, as when given [0,1,2,3] and replacing the server in slot 1 you're going to have a lot of hash moves. With ketama, you'd only have the '1' hashes moving. You can't really beat google's for brevity, though.
I have used Google's jump hash. As I recall, one of the main differences is that jump hash doesn't have a mechanism to remove targets, eg, a server dies and you don't want to route requests to it. Traditional consistent hashing can do that. I guess if you had 4 servers, server #4 dies, then you can go back to 3 servers by just changing num_buckets from 4 to 3. But if server 1 dies, you can't.
Jump hash does allow adding more targets and preserves the property that most request targets stay the same when adding a new target, so if you had 3 targets and add a fourth, ~8% of the requests that would have been sent to targets 1-3 are sent to target 4, evenly chosen from servers 1-3.
If you have a real, actual, substantive critique of either the post or package itself, I'd be interested in reading that. What you posted doesn't provide that. I'm not sure who you're talking to or what you expect your comment to accomplish.
We can tell you didn't read the post because it is definitively NOT garbage. Very interesting write up by the Cloudflare team - the man literally did calculus to improve something. When's the last time any of us did Calculus to improve anything? Bang up job Kevin and everyone!!
Anyone have an idea how it behaves differently from google's jump hash algorithm? The cool thing about google's one is it's so short I can include it in a HN comment:
https://arxiv.org/pdf/1406.2294Well I looked it up; nginx, apparently, uses ketama -- it's a ring-style hash probably works better for web backends than the jch above, as when given [0,1,2,3] and replacing the server in slot 1 you're going to have a lot of hash moves. With ketama, you'd only have the '1' hashes moving. You can't really beat google's for brevity, though.
I have used Google's jump hash. As I recall, one of the main differences is that jump hash doesn't have a mechanism to remove targets, eg, a server dies and you don't want to route requests to it. Traditional consistent hashing can do that. I guess if you had 4 servers, server #4 dies, then you can go back to 3 servers by just changing num_buckets from 4 to 3. But if server 1 dies, you can't.
Jump hash does allow adding more targets and preserves the property that most request targets stay the same when adding a new target, so if you had 3 targets and add a fourth, ~8% of the requests that would have been sent to targets 1-3 are sent to target 4, evenly chosen from servers 1-3.
If you have a real, actual, substantive critique of either the post or package itself, I'd be interested in reading that. What you posted doesn't provide that. I'm not sure who you're talking to or what you expect your comment to accomplish.
You got me! I keep meaning to do this.
https://github.com/cloudflare/pingora/issues/1014
I have now solved the problem once and for all
We can tell you didn't read the post because it is definitively NOT garbage. Very interesting write up by the Cloudflare team - the man literally did calculus to improve something. When's the last time any of us did Calculus to improve anything? Bang up job Kevin and everyone!!