RavenDB HiLo ID Generation: What, How, Why
Following my comments about RavenDB sharding, I had a very interesting email exchange with Matt Warren about RavenDB HiLo id generation. Matt pointed me to Rob Ashton’s post which covers in more details what is behind RavenDB HiLo:
- Waiting until SaveChanges to get ids for saved entities makes writing logic against those entities troublesome
- Calling SaveChanges every time a new entity is created makes transactions troublesome
- Calling SaveChanges to get the entity id means a call across the wire just to get an entity id, which is expensive
- Simply assigning a Guid to the Id makes accessing documents via REST an unpleasant experience
- You can’t just assign a random integer, because you’d just get collisions as other clients did the same and tried to save their entities
- HiLo provides a method of creating incremental integer based ids for entities in a fashion that is safe in concurrent environments
I do agree with points 2 to 5 above, but I see those as consequences or alternatives to the first one. Assuming that the first point represents indeed a real issue, the trade-off of RavenDB HiLo is offering is the following:
- one network round trip to get the Hi value
- some locking server side to ensure the next Hi value generation is truly atomic
- some more locking client side for generating the Lo values
Hopefully I’m missing something as this doesn’t look to me either less complicated or a good trade-off. Or maybe the hypothesis is wrong.
Original title and link: RavenDB HiLo ID Generation: What, How, Why (©myNoSQL)
via: http://codeofrob.com/entries/ravendb---the-hilo-what-how-and-why.html
