Is it another question? Yeah it is because my issue was with the fact that the generator is listed as efficient and the documentation does not list that it has the same draw backs of GUID based generators.
Any reasonable person should be able to see... Right, but my point again is that I did not find a website/blog/documentation mention this issue. That's why I asked this question in the first place. John On Fri, Apr 3, 2009 at 12:14 PM, Greg Young <[email protected]> wrote: > > Is it another question? > > " but I think there might be > > other people concerned when a table only contains a few 100k worth of > > records yet the id's are in the billions." > > These people have made the decision to use a hilo partitioning > strategy ... I would hope they chose the partitioning strategy for a > reason. Any reasonable person should be able to see that they made a > tradeoff in the size/distribution of their key for concurrency and > scalability. > > > > Greg > > On Fri, Apr 3, 2009 at 11:33 AM, John Morales <[email protected]> wrote: > > Whether it's irrelevant is another question, but I think there might be > > other people concerned when a table only contains a few 100k worth of > > records yet the id's are in the billions. > > > > I agree that for the most part the surrogate key value is a minor > > implementation issue, and you're right that int64, or better yet a > decimal > > type backed by oracle number(28) which allows in the precision to > octillion > > values, running out of space is while not impossible, is incredibly > hard... > >\ > > As for user visible, no it's not a issue for the user, while they might > see > > the id in the query string there is no real need for them to know this > > surrogate key value. I guess I'm to set in if a human readable and > somewhat > > logical 1-to-1 on amount of records and id values.... > > > > Oskar does bring up a good point of being able to pull up the record in a > > query tool becomes tedious. The problem with GUIDS from IIRC is the size > of > > the index, the fragmentation, and the human reability. All I'm stating is > > that in ASP.NET applications the HILO generator suffers the same > flaws... > >\\\ > > John > > > > On Fri, Apr 3, 2009 at 10:53 AM, Greg Young <[email protected]> > wrote: > >> > >> Who cares what the ids are? what is the % of space remaining in the > >> int64?! > >> > >> I mean seriously wtf are you taking hilo ids and showing them to users? > >> > >> Greg > >> > >> On Fri, Apr 3, 2009 at 8:37 AM, John Morales <[email protected]> > wrote: > >> > While you're right, it's quite possible to avoid reaching the upper > >> > limit on > >> > of the data size limit, if this is what you consider good design, then > >> > good > >> > luck to you. > >> > > >> > John > >> > > >> > On Fri, Apr 3, 2009 at 8:34 AM, John Morales <[email protected]> > wrote: > >> >> > >> >> A more realistic example. > >> >> > >> >> 3 web servers 200 tables, app reseting 5 times a day > >> >> > >> >> 3 * 5 * 200 = 3000 high values a day > >> >> > >> >> the high value is multiplied by the max_lo so in just 1 year your > id's > >> >> will be in the 190 billion range.. > >> >> > >> >> > >> >> While your' > >> >> > >> >> > >> >> On Thu, Apr 2, 2009 at 9:04 PM, Erik Lundby <[email protected]> wrote: > >> >>> > >> >>> <snip> > >> >>> > >> >>> . those reserved ranges are lost forever, which is wasteful > >> >>> > >> >>> </snip> > >> >>> > >> >>> > >> >>> > >> >>> But what are you wasting? With an int64 id and that default int16 > max > >> >>> low you are talking about, wouldn’t you have something like 140 > >> >>> trillion > >> >>> high values? > >> >>> > >> >>> So if you have 100 web servers resetting 3 times an hour, you will > get > >> >>> 7200 high values used a day. > >> >>> > >> >>> > >> >>> > >> >>> In 19 billion years you can probably just switch to int128. J > >> >>> > >> >>> > >> >>> > >> >>> Erik > >> >>> > >> >>> > >> >>> > >> >>> From: [email protected] [mailto:[email protected]] On > >> >>> Behalf Of John Morales > >> >>> Sent: Thursday, April 02, 2009 4:39 PM > >> >>> To: [email protected] > >> >>> Subject: [nhusers] Re: table hilo and application restarts/asp.net > >> >>> > >> >>> > >> >>> > >> >>> Yeah, the increment generator does not support more than 1 > concurrent > >> >>> session factory per database, which right now is all I need... And I > >> >>> guess I > >> >>> should re-evaluate this decision, this is one of those times where > >> >>> YAGNI > >> >>> isn't the best strategy as I might very well need to support scaling > >> >>> out. > >> >>> > >> >>> IMO, the concurrent sessionfactory support hilo has using reserved > >> >>> blocks > >> >>> of id's is inefficient, contrary to what the documentation says. > Once > >> >>> the > >> >>> session factory is terminated. those reserved ranges are lost > forever, > >> >>> which > >> >>> is wasteful. With the only option is to reduce the max_lo range cap, > >> >>> which > >> >>> just reduces the amount of potential waste. A more efficient > generator > >> >>> that > >> >>> reuses those unused ranges while allowing a clustered environment is > >> >>> what I > >> >>> truly need. > >> >>> > >> >>> If I have some time I might help out with this. > >> >>> > >> >>> John > >> >>> > >> >>> On Thu, Apr 2, 2009 at 7:03 PM, Fabio Maulo <[email protected]> > >> >>> wrote: > >> >>> > >> >>> 2009/4/2 John Morales <[email protected]> > >> >>> > >> >>> > >> >>> > >> >>> While looking into the source I saw that the increment generator > does > >> >>> exactly what I need, it uses a cached copy of the max id for each > >> >>> table on > >> >>> appdomain start and assigns id's as necessary. Without having to hit > >> >>> the > >> >>> database for each insert. > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> mmmm... take care with it... what happen when you have 2 webserver ? > >> >>> or > >> >>> two application instance ? > >> >>> -- > >> >>> Fabio Maulo > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> > >> >>> This signature is intentionally left blank > >> >>> > >> >>> > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> >> This signature is intentionally left blank > >> > > >> > > >> > > >> > -- > >> > This signature is intentionally left blank > >> > > >> > > > >> > > >> > >> > >> > >> -- > >> It is the mark of an educated mind to be able to entertain a thought > >> without accepting it. > >> > >> > > > > > > > > -- > > This signature is intentionally left blank > > > > > > > > > > > -- > It is the mark of an educated mind to be able to entertain a thought > without accepting it. > > > > -- This signature is intentionally left blank --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
