4 ms·

Check my post from 10 years ago https://nhibernate.info/blog/2009/03/19/nhibernate-poid-generators-revealed.html https://nhibernate.info/blog/2009/03/19/nhiber

Check my post from 10 years ago https://nhibernate.info/blog/2009/03/19/nhibernate-poid-generators-revealed.html https://nhibernate.info/blog/2009/03/19/nhibernate-poid-gene... I put data about fragmentation when using uuid there.

hardwaresofton 6y ago
Hey thanks for linking that post -- I have to say that I didn't find much value in it and here's why (most of which has nothing to do with you so please don't take it personally, just thought it was worth mentioning): - I don't use ORMs for the most part (query builders for basic CRUD, my personal favorite ORM is typeorm[0] precisely because you don't have to use it as an ORM) - I don't use .NET (I'm bad at it, and the last time I used it was when EF was in the middle of the transition to core/standard and it was hell) - HiLo is the thing that you all recommended, but there's almost no information about it - The post basically says HiLo > Comb > UUIDv4, but with very little actual testing After looking around for what HiLo was, I found an article about the generation for an ORM in PG[1]. But I'm somewhat confused -- it's actually perfectly possible to pre-generate UUIDv1s, I do it in my applications before the query. I'm not sure what HiLo actually improves upon other than that. So basically that leaves COMB, and as I've said -- I don't feel the need to use COMB if UUIDv1 is good enough. [0]: https://github.com/typeorm/typeorm https://github.com/typeorm/typeorm [1]: https://www.npgsql.org/efcore/modeling/generated-properties.html https://www.npgsql.org/efcore/modeling/generated-properties....
- tehlike 6y ago
  The blog mentions ORM, but it actually has nothing to do with orms, if you read it closer. 1. ID generation is generic problem. You can go two ways about it, one is letting your DB handle/generate it, and one handling it at application level. Your ORM can do it, or they may not. TypeORM/Sequelize are primitive ORMs compared to hibernate/nhibernate, but ORM could be a place where you can handle ID generation, or you can handle it in your business code. 2. .NET has nothing to do with it, if you want to extract information out of it, it applies to any language, concepts are programming concepts. 3. At the time i suggested HiLo > Comb > UUIDv4 and i actually gave my rationale. These days i choose sequential uuid/comb instead, mostly because i don't care about readable ids. On HiLo: If you want mostly sequential human readable numbers, instead of using DB generated identity, it's smarter to use a simple algorithm like HiLo algorithm. Hi/Lo is High + Lo referring to bucketization of the numbers. Hi goes from 0...infinity, Lo goes from 0 to bucketsize-1. The basic idea is, if you have an application (or a distributed system for that matter), you preallocate id ranges to each node instance in your application. Bucket size: 128 Instance 1: Hi=0, Lo=0 Instance 2: Hi=1, Lo=0 Instances assign ids based on the following formula: Hi * bucketSize + (Lo++); This means instances can assign ids from 0...127 and and 128 ...255 on their own, without hitting database. When they run out of their range, they make a new query and increment Hi parameter stored in database. Applications assigning ids without hitting database is important. Think of the following scenario: If you have Order + Order Details, you can send all the inserts in one go if the order id is preassigned. Otherwise, you have to insert the order, get the id, then insert the order details with order id you just obtained. On Comb creates less fragmentation in the database. I actually put a small bit of image there that simply shows what happens if you insert thousands of records with id=uuid4 vs comb. One of the tables will be more fragmented. the other will be significantly less.. UUIDv1 is structured as [low bits of timestamp, mid bits of timestamp, high bits of timestamp....] which means first bits of uuid moves faster than middle/higher bits, which is very problematic for the fragmentation. Feel free to ping me on email if you want to talk more: tehlike@gmail.com I was a contributor on NHibernate around 2008.

hardwaresofton 6y ago

Hey thanks for linking that post -- I have to say that I didn't find much value in it and here's why (most of which has nothing to do with you so please don't take it personally, just thought it was worth mentioning): - I don't use ORMs for the most part (query builders for basic CRUD, my personal favorite ORM is typeorm[0] precisely because you don't have to use it as an ORM) - I don't use .NET (I'm bad at it, and the last time I used it was when EF was in the middle of the transition to core/standard and it was hell) - HiLo is the thing that you all recommended, but there's almost no information about it - The post basically says HiLo > Comb > UUIDv4, but with very little actual testing After looking around for what HiLo was, I found an article about the generation for an ORM in PG[1]. But I'm somewhat confused -- it's actually perfectly possible to pre-generate UUIDv1s, I do it in my applications before the query. I'm not sure what HiLo actually improves upon other than that. So basically that leaves COMB, and as I've said -- I don't feel the need to use COMB if UUIDv1 is good enough. [0]: https://github.com/typeorm/typeorm https://github.com/typeorm/typeorm [1]: https://www.npgsql.org/efcore/modeling/generated-properties.html https://www.npgsql.org/efcore/modeling/generated-properties....

tehlike 6y ago
The blog mentions ORM, but it actually has nothing to do with orms, if you read it closer. 1. ID generation is generic problem. You can go two ways about it, one is letting your DB handle/generate it, and one handling it at application level. Your ORM can do it, or they may not. TypeORM/Sequelize are primitive ORMs compared to hibernate/nhibernate, but ORM could be a place where you can handle ID generation, or you can handle it in your business code. 2. .NET has nothing to do with it, if you want to extract information out of it, it applies to any language, concepts are programming concepts. 3. At the time i suggested HiLo > Comb > UUIDv4 and i actually gave my rationale. These days i choose sequential uuid/comb instead, mostly because i don't care about readable ids. On HiLo: If you want mostly sequential human readable numbers, instead of using DB generated identity, it's smarter to use a simple algorithm like HiLo algorithm. Hi/Lo is High + Lo referring to bucketization of the numbers. Hi goes from 0...infinity, Lo goes from 0 to bucketsize-1. The basic idea is, if you have an application (or a distributed system for that matter), you preallocate id ranges to each node instance in your application. Bucket size: 128 Instance 1: Hi=0, Lo=0 Instance 2: Hi=1, Lo=0 Instances assign ids based on the following formula: Hi * bucketSize + (Lo++); This means instances can assign ids from 0...127 and and 128 ...255 on their own, without hitting database. When they run out of their range, they make a new query and increment Hi parameter stored in database. Applications assigning ids without hitting database is important. Think of the following scenario: If you have Order + Order Details, you can send all the inserts in one go if the order id is preassigned. Otherwise, you have to insert the order, get the id, then insert the order details with order id you just obtained. On Comb creates less fragmentation in the database. I actually put a small bit of image there that simply shows what happens if you insert thousands of records with id=uuid4 vs comb. One of the tables will be more fragmented. the other will be significantly less.. UUIDv1 is structured as [low bits of timestamp, mid bits of timestamp, high bits of timestamp....] which means first bits of uuid moves faster than middle/higher bits, which is very problematic for the fragmentation. Feel free to ping me on email if you want to talk more: tehlike@gmail.com I was a contributor on NHibernate around 2008.