Globaal unieke IDs voor meerdere servers

[Verwijderd]

Hoi,

Voor een relatief eenvoudige (Java) applicatie die gebruik maakt van Postgres heb ik momenteel meerdere nodes draaien, die echter gebruik maken van 1 centrale PG instantie.

Deze PG instantie wil ik binnenkort gaan opsplitsen naar een instantie per applicatie node. De applicatie gebruikt momenteel een sequence in een PG tabel die opgehoogd wordt om oplopend telkens unieke IDs te genereren.

Met een DB instantie per node heb ik niet langer de beschikking over eenvoudige unieke IDs. Ik zat nu echter te twijfelen tussen 2 mogelijke oplossingen:

1)
Nog steeds gebruik maken van 1 centrale DB instantie, maar alleen voor het genereren van de IDs. De sequence kan atomic verhoogd worden met een waarde hoger dan 1, zodat ik een node in 1 keer een hele ID range kan geven. De machine kan dan weer opnieuw een range ophalen als de huidige (bijna) op is. Deze oplossing mapped ook direct naar de JPA/Hibernate SEQUENCE generator strategy, waarbij je met initialValue() en allocationSize() de range kan instellen die telkens (automatisch) opgehaald wordt.

2)
Elke machine van een uniek nummer voorzien (b.v. een hash van de hostname) en deze als soort prefix gebruiken voor mijn huidige ID. Een variatie hierop is in plaats van 1 ID, 2 IDs te gebruiken waarbij het paar dan uniek is. De ene ID is dan het unieke machine nummer en het andere ID een uniek nummer per node. De 2de variant vereist wel flink wat herschrijven van code. Het unieke machine nummer direct als een prefix gebruiken kan niet, omdat het ID een nummer moet zijn. Dit veranderen in een string is eigenlijk niet makkelijk te doen.

Ik vraag me af of iemand wat kan zeggen over welke 2 van de mogelijke oplossingen nu beter is en/of wat er eigenlijk het meest in de praktijk gebruikt wordt. Het lijkt me nogal een algemeen probleem, immers heel veel websites hebben te maken met unieke nummers (order, invoice, custumer, etc) en maken gebruik van meerdere nodes.

[P_de_B]

[google=guid]

Ik denk dat je daar wel verder mee komt

[RobIII]

Verwijderd schreef op dinsdag 29 juli 2008 @ 18:22:

Beide IMHO nogal omslachtige oplossingen, zeker als je bedenkt dat je topictitel notabene gewoon de oplossing bevat GUID it is (Wat hierboven dus ook al gezegd wordt...)

[ Voor 8% gewijzigd door RobIII op 29-07-2008 18:32 ]

[flowerp]

RobIII schreef op dinsdag 29 juli 2008 @ 18:32:
[...]
Beide IMHO nogal omslachtige oplossingen,

De eerste is in een normale situatie zeker niet omslachtig als je JPA gebruikt. Het is welgeteld 1 eenvoudige annotation op je entity bean Je EJB layer alsmede je DB kunnen dan gewoon geclusterd zijn.

Wat de TS wil is echter net even wat anders, omdat er waarschijnlijk sprake is van echt volledig aparte databases per applicatie server. Ook dan is het met JPA niet zo heel moeilijk. Je maakt gewoon een persistence unit (PU) met 1 bean erin die naar 1 globale DB wijst. Deze noem je GlobalSequence ofzo. Op het ID field/setter zet je een annotation als @ID @GeneratedValue(strategy=GenerationType.SEQUENCE, generator="Some_Sequence").

Per default cached JPA 50 IDs, maar dit kun je makkelijk verhogen als je wilt.

Elke keer als je een nieuwe GlobalSequence aanmaakt en deze persist heb je een nieuwe sequentiële unieke ID.

GUID's kunnen een oplossing zijn, maar voldoen zeker niet altijd. Eigenlijk is het gewoon een fancy random number generator algorithm. Bij veel web toepassingen zie ik echter dat veel dingen juist een oplopend nummer krijgen en dat wijst dus zeker niet op het gebruik van GUIDs.

Bij wikipedia staat b.v. dit erover:

While each generated GUID is not guaranteed to be unique, the total number of unique keys (2^128 or 3.4×10^38) is so large that the probability of the same number being generated twice is very small.

Als je dus b.v. de applicatie schrijft die de paspoort document nummers genereert, of sofi nummers (om maar wat extreems te noemen), denk ik dat je beter toch iets anders kunt gebruiken ondanks de kleine kans op een collision. Ook als het simpelweg nodig is dat de unieke nummers oplopend zijn voldoet een GUID niet echt.

Het grootste argument tegen een GUID is echter deze opmerking van de TS:

omdat het ID een nummer moet zijn. Dit veranderen in een string is eigenlijk niet makkelijk te doen.

Ik neem aan dat dat nummer nu opgeslagen is in een integer of een long. Een GUID gaat dan simpelweg niet werken omdat 2^128 nou eenmaal niet in 2^32 of 2^64 past, zelfs als deze unsigned zouden zijn in Java.

[P_de_B]

Nou, met een kans van 1: 2^128 durf ik het risico op collisions wel te nemen. Heb je enig idee hoe veel 2^128 is?

For example, consider the observable universe, which contains about 5×10^22 stars; every star could then have 6.8×10^15 universally unique GUIDs.

De kans dat een sequence dubbel is vanwege een softwarebug is volgens mij groter.

Als het echter een oplopend nummer moet zijn voldoet een guid idd niet.

[RobIII]

offtopic:
Een GUID is gewoon een 128 bits integer, dus die kun je prima als een _{weliswaar huge ass} getal schrijven

P_de_B schreef op dinsdag 29 juli 2008 @ 21:55:
Nou, met een kans van 1: 2^128 durf ik het risico op collisions wel te nemen. Heb je enig idee hoe veel 2^128 is?

Psies, de kans op een collision is dusdanig klein dat het verwaarloosbaar is en de kans op 'overlap' door bugs is vele malen groter. Daarbij; die enkele collision die je dan heeeeeeeeel misschien zou krijgen los ik liever op dan die bug Kwestie van nieuw GUID assignen (FK's nalopen) et voila.

[ Voor 66% gewijzigd door RobIII op 29-07-2008 22:44 ]

[Gomez12]

P_de_B schreef op dinsdag 29 juli 2008 @ 21:55:
Nou, met een kans van 1: 2^128 durf ik het risico op collisions wel te nemen. Heb je enig idee hoe veel 2^128 is?

Het gaat er niet om hoe groot de kans is imho.

Het gaat erom dat je juist een bugvrije omgeving probeert te genereren. Hiermee weet je van te voren dat er een kans is op collisions.

Als een systeem 5 jaar gebruikt wordt en dan opeens krijgt een order van 3 ton hetzelfde guid als een order van 1 euro dan zal ik toch echt wel de ontwerper van het systeem vervloeken als ik hier na vele uren bugtracken achter ben gekomen. Als er 1 guid dubbel gebruikt is dan zijn het er imho bijna altijd meerdere en dan wordt het dus zoeken naar de andere.

Oftewel een guid is leuk voor een imageshack oid, voor een real-live business application wens ik op voorhand geen mogelijke bugs te zien. Hoe klein de kans ook is, als murphy's law opduikt dan heb ik opeens een hel om te debuggen.
Oftewel ik schrijf liever 10 uur extra aan ontwikkeling dan dat ik met de klant in discussie moet over 40 uur debugging en daarna alsnog die 10 uur ontwikkeling omdat murphy's law om de hoek kwam...
Nog even daargelaten wat dit voor je reputatie doet...

[RobIII]

Gomez12 schreef op dinsdag 29 juli 2008 @ 22:53:
[...]

Het gaat er niet om hoe groot de kans is imho.

Het gaat erom dat je juist een bugvrije omgeving probeert te genereren. Hiermee weet je van te voren dat er een kans is op collisions.

Als een systeem 5 jaar gebruikt wordt en dan opeens krijgt een order van 3 ton hetzelfde guid als een order van 1 euro dan zal ik toch echt wel de ontwerper van het systeem vervloeken als ik hier na vele uren bugtracken achter ben gekomen. Als er 1 guid dubbel gebruikt is dan zijn het er imho bijna altijd meerdere en dan wordt het dus zoeken naar de andere.

Je hebt echt géééén idee hoe 'groot' die kans op een collision is.... Schrijf 2^128 eens uit?
Die kans is (Ietwat kort door de bocht, want er zijn een paar piepkleine haakjes die verwaarloosbaar zijn) dan 1:340.282.366.920.938.463.463.374.607.431.768.211.456

Gomez12 schreef op dinsdag 29 juli 2008 @ 22:53:
Oftewel ik schrijf liever 10 uur extra aan ontwikkeling dan dat ik met de klant in discussie moet over 40 uur debugging en daarna alsnog die 10 uur ontwikkeling omdat murphy's law om de hoek kwam...
Nog even daargelaten wat dit voor je reputatie doet...

Ik neem de kans op een collision any time over de kans op een bug in code waar ik 10 uur aan moet spenderen.

[ Voor 12% gewijzigd door RobIII op 29-07-2008 23:02 ]

[Gomez12]

RobIII schreef op dinsdag 29 juli 2008 @ 22:43:
[...]

Psies, de kans op een collision is dusdanig klein dat het verwaarloosbaar is en de kans op 'overlap' door bugs is vele malen groter. Daarbij; die enkele collision die je dan heeeeeeeeel misschien zou krijgen los ik liever op dan die bug Kwestie van nieuw GUID assignen (FK's nalopen) et voila.

Ok, kwestie risico inventarisatie dus.
Alleen als ik een fullblown app heb draaien waarbij pas na een maand deze fout eruitkomt ( facturaties zijn altijd leuke punten om hierachter te komen of archiveringen ) en aan de FK hangen nog 30 tabellen, dan voorkom ik liever de bug dan hem te fixen.

Fixen is waarschijnlijk iets uitgebreider dan 1 nieuw GUID assignen als het over een grotere app gaat....

RobIII schreef op dinsdag 29 juli 2008 @ 22:55:
[...]

Je hebt echt géééén idee hoe 'groot' die kans op een collision is.... Schrijf 2^128 eens uit?

Jammer, maar ik heb wel een idee hoe groot die kans op een collision is. En ik heb daarbij ook een idee hoeveel foute implementaties er van GUID´s zijn waardoor de kans op duplicate GUID´s opeens exponentieel toeneemt ( vb. ooit eens 1x een bedrijf gezien wat per ongeluk in zijn ghost-image een mac-address override had zitten ( veroorzaakte 101 andere problemen die iets urgenter waren dan dit ) als de switches niet waren gaan bokken was hun GUID al een heel stuk minder UNIQUE geweest ).

Windows heeft een redelijke standaard GUID procedure die gewoon goed werkt, maar als iemand software in Java gaat schrijven dan ga ik er bij voorbaat al van uit dat het in meer OS'en moet gaan werken en dan schat ik ook de kans op "echte" GUID's kleiner in.
Eigen implementaties zijn helemaal leuk...

In theorie klinkt het goed, in de praktijk denk ik dat je langer bezig bent met het zoeken naar een goede GUID implementatie dan met het maken van een eigen oplossing. Een foute GUID implementatie zie je namelijk niet na 2 dagen debuggen opeens terug. Maar na 5 jaar kan het je wel opeens in the ass bijten omdat je opeens niet 2^128 gebruikt maar per ongeluk 2^32 of zelfs nog kleiner...

[...]
Ik neem de kans op een collision any time over de kans op een bug in code waar ik 10 uur aan moet spenderen.

Ok, ik probeer gewoon zoveel mogelijk defensief te coden. Kwestie van ervaring, kan jij vanaf scratch zelf sneller een werkend unique-systeem bouwen dan dat je een bestaande GUID-library gedebugged hebt.
Probably is mijn eigen werkend unique-systeem langzamer dan een lib, maar ik en mijn collega's kunnen het wel ongeveer 100x zo snel debuggen als een lib van het internet...

[ Voor 54% gewijzigd door Gomez12 op 29-07-2008 23:19 ]

[Cousin Boneless]

Je zou ook een SOAP service kunnen inzetten die fungeert als centrale unieke nummer generator. Dit is ook min of meer wat je onder 1) beschrijft, maar dan wat geabstraheerd van de database gedachte. Je kan dan over de hele wereld unieke nummers genereren zonder dat de generator in het lokale netwerk hangt.

Ik vertrouw toch nog altijd op de GUID als een uniek nummer. Daar wordt ook nog iets unieks van de netwerkkaart in verwerkt, waardoor de kans op een overeenkomst in dat geval nog kleiner is als deze kans van het trekken van 2 gelijke nummers uit 2^128 combinaties?

[RobIII]

Gomez12 schreef op dinsdag 29 juli 2008 @ 23:00:

Fixen is waarschijnlijk iets uitgebreider dan 1 nieuw GUID assignen als het over een grotere app gaat....

a) die collisions binnen dezelfde DB kom je op het moment van aanmaken al tegen (trustme: Never gonna happen)
b) stél dat er een collision is dan kom je die tegen bij het mergen van databases en kun je op dat moment (again, spaar je de moeite om het uberhaupt te maken) dat record opzij leggen of hernummeren voordat je 't doorvoert. En dat hoeft echt niet moeilijk te zijn want je hoeft alleen de FK's na te lopen (tikkie versimpeld, maar altijd nog minder werk (en again never ever gonna happen) en safer).

Cousin Boneless schreef op dinsdag 29 juli 2008 @ 23:04:
Ik vertrouw toch nog altijd op de GUID als een uniek nummer. Daar wordt ook nog iets unieks van de netwerkkaart in verwerkt, waardoor de kans op een overeenkomst in dat geval nog kleiner is als deze kans van het trekken van 2 gelijke nummers uit 2^128 combinaties?

Dat was in v1 UUIDs zo en is al lang achterhaald. Overigens maakt dat de kans op collisions groter wegens mac-address spoofing en beperkingen in het algoritme. Overigens zie je daar ook meteen de 'beperkingen' staan; er worden een paar bits gereserveerd in sommige gevallen, waardoor de space in feite slinkt tot 1^122 ofzo, maar again is dat getal dan nog steeds huge-ass en niet te bevatten.

[ Voor 37% gewijzigd door RobIII op 29-07-2008 23:18 ]

[momania]

RobIII schreef op dinsdag 29 juli 2008 @ 22:55:
[...]

Je hebt echt géééén idee hoe 'groot' die kans op een collision is.... Schrijf 2^128 eens uit?
Die kans is (Ietwat kort door de bocht, want er zijn een paar piepkleine haakjes die verwaarloosbaar zijn) dan 1:340.282.366.920.938.463.463.374.607.431.768.211.456

offtopic:
Toch he... de aanname is makkelijk dat het nooit voor zal komen, maar toch...

Regel 1:
'Assumption is the mother of all fuckups'

Ofwel, als er een 100% veilige oplossing is, altijd voor die oplossing gaan.

[RobIII]

momania schreef op dinsdag 29 juli 2008 @ 23:13:
[...]

offtopic:
Toch he... de aanname is makkelijk dat het nooit voor zal komen, maar toch...

Regel 1:
'Assumption is the mother of all fuckups'

I live by that rule

momania schreef op dinsdag 29 juli 2008 @ 23:13:

offtopic:
Ofwel, als er een 100% veilige oplossing is, altijd voor die oplossing gaan.

De pest is dat je eigen oplossing waarschijnlijk (ik zeg niet zéker) foutgevoeliger is dan de kans op een collision in 1:3.4³⁸

Als we die 'aanname' niet meer mogen/kunnen doen gaan er wereldwijd een he-le-boel applicaties een probleem krijgen. Wat ik je brom _{Ik ben niet aansprakelijk voor eventuele gevolgen}

[ Voor 13% gewijzigd door RobIII op 29-07-2008 23:16 ]

[momania]

RobIII schreef op dinsdag 29 juli 2008 @ 23:14:
[...]

I live by that rule

Goezo jei!

De pest is dat je eigen oplossing waarschijnlijk (ik zeg niet zéker) foutgevoeliger is dan de kans op een collision in 1:3.4³⁸

Als we die 'aanname' niet meer mogen/kunnen doen gaan er wereldwijd een he-le-boel applicaties een probleem krijgen. Wat ik je brom

True, maar in deze situatie is het mogelijk om een 100% proof implementatie te doen voor unieke ID's... Ook al is die misschien wat omslachtiger, zou ik toch voor die optie gaan

Ik ben niet aansprakelijk voor eventuele gevolgen

Ik weet je te vinden

[ Voor 8% gewijzigd door momania op 29-07-2008 23:18 ]

[Verwijderd]

Genereer een GUID, schrap de eerste paar tekens, en vervang die door per-machine unieke tekens. Simpel zat.

[RobIII]

momania schreef op dinsdag 29 juli 2008 @ 23:17:
True, maar in deze situatie is het mogelijk om een 100% proof implementatie te doen voor unieke ID's... Ook al is die misschien wat omslachtiger, zou ik toch voor die optie gaan

...waarmee je in optie 1) afhankelijkheid inbouwt van het toegankelijk zijn van de centrale server en in optie 2) je "wel flink wat herschrijven van code" moet doen ... True, een int vervangen door een GUID zal ook wat werk zijn, maar altijd minder dan allerlei pseudo-unieke-combined keys IMHO.

Verwijderd schreef op dinsdag 29 juli 2008 @ 23:19:
Genereer een GUID, schrap de eerste paar tekens, en vervang die door per-machine unieke tekens. Simpel zat.

Middle of the road oplossing. Ook een aardig idee.

edit:
@hieronder: het zal idd je GUID 'verzwakken', dat wel. Maar again; enig idee over welke magnitude's we het hier hebben?

[ Voor 37% gewijzigd door RobIII op 29-07-2008 23:32 ]

[Gomez12]

Verwijderd schreef op dinsdag 29 juli 2008 @ 23:19:
Genereer een GUID, schrap de eerste paar tekens, en vervang die door per-machine unieke tekens. Simpel zat.

Op zich perfecte oplossing, maar waarom tekens schrappen? Lijkt mij gewoon nog even wat tekens toevoegen, dan blijft het al uitgedachte systeem van GUID's 100% in stand en voeg ik er alleen zelf nog een extra zekerheid aan toe.
Door iets te schrappen krijg ik het idee dat ik het systeem van GUID's verzwak ( ik gebruik minder getallen ) en daarna nog eens verzwak door een paar vaste getallen te hanteren.

De machine-ids zijn niet uniek per machine en de GUID is verzwakt door getallen weg te halen. Lijkt mij zo ongeveer het slechtste van 2 werelden. En of je nou 128 of 160 bits opslaat maakt imho op dat niveau ook niets meer uit.

[momania]

RobIII schreef op dinsdag 29 juli 2008 @ 23:20:
[...]

...waarmee je in optie 1) afhankelijkheid inbouwt van het toegankelijk zijn van de centrale server en in optie 2) je "wel flink wat herschrijven van code" moet doen ... True, een int vervangen door een GUID zal ook wat werk zijn, maar altijd minder dan allerlei pseudo-unieke-combined keys IMHO.

ok ok ok

Ligt er ook allemaal maar net aan in wat voor omgeving/situatie je zit. In dit geval gaat het om een 'simpele' applicatie, dus zal het geen kwaad kunnen om GUID's te gebruiken.

In de financiele systemen waar ik aan werk zullen mijn leidinggevende (en mijn team-genoten) er niet echt blij mee zijn

[Gomez12]

Cousin Boneless schreef op dinsdag 29 juli 2008 @ 23:04:
Je zou ook een SOAP service kunnen inzetten die fungeert als centrale unieke nummer generator. Dit is ook min of meer wat je onder 1) beschrijft, maar dan wat geabstraheerd van de database gedachte. Je kan dan over de hele wereld unieke nummers genereren zonder dat de generator in het lokale netwerk hangt.

En je hebt altijd te maken met network lags etc. Vaak genoeg zijn dit soort network lags net genoeg om de user-experience van prettig naar onprettig te laten gaan...

[GlowMouse]

P_de_B schreef op dinsdag 29 juli 2008 @ 21:55:
For example, consider the observable universe, which contains about 5×10^22 stars; every star could then have 6.8×10^15 universally unique GUIDs.

Daar quote je een mooie drogreden, ook wel bekend onder de naam verjaardagsparadox. Zou je die sterren een 128-bits (geheel vrij) GUID geven, zou de kans vrijwel 1 zijn dat er een dubbele bij zit. Zie hier onder Approximations voor de afleiding.
Neemt niet weg dat ik me tot 10^15 GUID's weinig zorgen zou maken.

[RobIII]

Als je 10 miljard PC's (we zijn met 6.7 miljard (give or take) mensen op de wereld) 1 miljoen GUID's per seconde laat genereren dan doe je er nog steeds ~10.7x10¹⁵ jaar over om ze allemaal te genereren. Het universum is (geschat) op 13.73x10⁹ jaar oud. Even lomp gerekend zou het universum dus nog een miljard keer langer moeten bestaan... En gelukkig gebruiken de meesten onder ons onze PC voor leukere dingen

True, met de birthdayparadox in acht genomen is er een kans op een collision (as stated before) maar die kans is (omdat we nu niet zitten met een kans op 1 van de 365 dagen ) nog steeds verwaarloosbaar.

quote: http://en.wikipedia.org/w...y_paradox#Generalizations

The birthday problem in this more generic sense applies to hash functions: the expected number of N-bit hashes that can be generated before getting a collision is not 2^N, but rather only 2^N/2.

Ik ben geen statisticus (en misschien maar goed ook ) maar ik zie het hele probleem niet.

[ Voor 37% gewijzigd door RobIII op 29-07-2008 23:55 ]

[Marcj]

Je moet ongeveer 7 triljoen GUID's hebben gegenereerd (vanuit gegaan van 122-bits random) voordat je meer dan 1% kans hebt op een dubbele. Tegen de tijd dat je zoveel rijen in een database wilt opslaan heb je wel andere problemen om over na te denken

[GlowMouse]

RobIII schreef op dinsdag 29 juli 2008 @ 23:42:
Ik ben geen statisticus (en misschien maar goed ook )

_{In dit geval is dat inderdaad maar goed ook. Een statisticus bepaalt kansen namelijk op basis van gegevens, en je geeft zelf al aan dat het genereren van die gegevens een tijdrovende klus is. Omscholen tot kansrekenaar en daarna de kans berekenen is een stuk sneller.}

[flowerp]

RobIII schreef op dinsdag 29 juli 2008 @ 22:43:

offtopic:
Een GUID is gewoon een 128 bits integer, dus die kun je prima als een _{weliswaar huge ass} getal schrijven

Klopt, maar als alle Java code al een int of long gebruikt dan kan het mogelijk veel werk zijn om dit te gaan omcoden naar b.v. BigInteger. Zoals ik al zei, je kan een GUID misschien makkelijk als een getal schrijven, maar hoe ga jij 128 bits dan in 32 bits proppen?

Als je weet hoe dan kan, zou ik er maar heel snel pattent om aanvragen

[Ruudjah]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 89% gewijzigd door Ruudjah op 02-12-2009 00:19 ]

[RobIII]

GlowMouse schreef op woensdag 30 juli 2008 @ 00:04:
[...]

_{In dit geval is dat inderdaad maar goed ook. Een statisticus bepaalt kansen namelijk op basis van gegevens}

offtopic:
Waar baseer ik mijn berekening dan op Maar hoe dan ook: boeie De kans is letterlijk te klein om je zorgen om te maken (IMHO).

Zie overigens ook Wikipedia: Universally Unique Identifier: Random UUID probability of duplicates

flowerp schreef op woensdag 30 juli 2008 @ 00:06:
Klopt, maar als alle Java code al een int of long gebruikt dan kan het mogelijk veel werk zijn om dit te gaan omcoden naar b.v. BigInteger. Zoals ik al zei, je kan een GUID misschien makkelijk als een getal schrijven, maar hoe ga jij 128 bits dan in 32 bits proppen?

a) ik heb geen idee of Java een GUID class kent (en als dat niet zo is: why not?) en b) met een degelijke refactor tool moet het geen vre-se-lijk onaangename klus zijn en zeer waarschijnlijk veel minder werk dan optie 1) of 2).
Maar goed, ik ben aardig moe gepredikt. TS ziet maar

flowerp schreef op woensdag 30 juli 2008 @ 00:06:
Als je weet hoe dan kan, zou ik er maar heel snel pattent om aanvragen

Ik zal Jan Sloot eens bellen

[ Voor 59% gewijzigd door RobIII op 30-07-2008 11:20 ]

[GlowMouse]

RobIII schreef op woensdag 30 juli 2008 @ 00:12:
[...]

offtopic:
Waar baseer ik mijn berekening dan op .

offtopic:
Op de theoretische afleiding die eerder genoemd was. Een statisticus werkt op basis van gegevens, een kansrekenaar niet. Subtiel verschil, maar iedereen doet het fout

Ik zal Jan Sloot eens bellen

Hij had toch een trucje bedacht dat iedereen een driecijferig telefoonnummer kreeg? Wel eng dat jij met hem kunt bellen trouwens
@onder: met dezelfde techniek krijgt iedereen een kort telefoonnummer

[ Voor 6% gewijzigd door GlowMouse op 30-07-2008 00:20 ]

[RobIII]

GlowMouse schreef op woensdag 30 juli 2008 @ 00:17:
Hij had toch een trucje bedacht dat iedereen een driecijferig telefoonnummer kreeg?

Nope >> Wikipedia: Jan Sloot
(Hoewel dat ook een leuke toepassing zou zijn. Snel! Patent aanvragen! )

GlowMouse schreef op woensdag 30 juli 2008 @ 00:17:
Wel eng dat jij met hem kunt bellen trouwens

Mod-powah

[Marcj]

RobIII schreef op woensdag 30 juli 2008 @ 00:12:
[...]

a) ik heb geen idee of Java een GUID class kent (en als dat niet zo is: why not?) en b) met een degelijke refactor tool moet het geen vre-se-lijk onaangename klus zijn en zeer waarschijnlijk veel minder werk dan optie 1) of 2).
Maar goed, ik ben aardig moe gepredikt. TS ziet maar

java.util.UUID

[Niemand_Anders]

Het probleem is dat je de slave nodes van de database cluster gebruikt voor zowel lezen als schrijven. Dat betekend ook dat alle nodes met elkaar moeten repliceren om up-to-date te blijven.

Daarom worden de meeste database clusters volgens het master-slave (loadbalacing) principe opgezet. Er is slechts 1 node (de master) waarop data modificaties plaats vinden. De veranderingen worden (direct) doorgevoerd op de slaves. De slaves worden daarbij als readonly worden behandeld. Je hoeft dan ook niet zelf unieke id's te genereren omdat de database gewoon zijn eigen sequence aanhouden.

Wat lastiger zijn de replicating clusters (failover + loadbalacing). Voordat database waar redelijk veel updates op plaats vinden kunnen trager worden als de replicaties direct op alle nodes moet worden afgedwongen.

Je kunt een en ander wel iets versnellen als je gewoon 1 vaste node gebruikt voor je sequences. Dus voordat je een insert query uitvoert, zul je eerst de "select nextval('customerid_sequence')" query moeten uitvoeren. De daadwerkelijk insert query kun je dan op elk van de andere nodes uitvoeren.

Het is echter niet verstandig het genereren van id's naar de client te trekken.

[RobIII]

Nog een laatste opmerking over GUID/UUID's:

quote: http://en.wikipedia.org/w...probability_of_duplicates

To put these numbers into perspective, one's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.00000000006 (6 x 10-11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.

The odds of a properly generated duplicate UUID being used in error in any practical circumstance is so low that any other work to improve software reliability would clearly be a much higher priority.

Grappig dat ik daar gisteren overheen gekeken heb. Anyhow, het is denk ik breed genoeg besproken; de keuze is aan de TS. In mijn bescheiden mening ben je gek als je dan moeilijk gaat zitten doen en afhankelijkheden van allerlei andere servers e.d. gaat inbouwen.

[ Voor 44% gewijzigd door RobIII op 30-07-2008 11:24 ]

[Verwijderd]

Bedankt voor alle antwoorden! Ik had GUIDs inderdaad over het hoofd gezien.

De applicatie is trouwens weliswaar simpel qua code, maar heftig in het gebruik. Het registreert transacties. Per node grofweg 15 per seconde. Per maand wordt het ongeveer 2 a 3 transacties per seconde meer.

De ID wordt nu inderdaad bijgehouden in een Java long. Dat zijn dus 64 bits, signed. De applicatie zelf refactoren is zeker te doen. Velen malen moeilijker is het om alle applicaties achter deze ene applicatie te gaan refactoren. Dat zijn dingen als user interfaces, report generators, statistieken, etc etc. Dat is zeer veel en zeer complexe code. Een stuk van deze dependend code is ook legacy, b.v. Java scriptlets midden in JSP pagina's. Zoals bekend refactoren deze zeer lastig (MyEclipse neemt deze b.v. niet mee in een refactoring).

De 2de oplossing die ik zelf bedacht zit natuurlijk met het zelfde probleem, vandaar mijn aanvankelijke voorkeur naar de eerste oplossing. Dan kan alle andere code hetzelfde blijven. Toch klinkt de GUID -zeer- aantrekkelijk, ten zeerste omdat daar support in zit in Java.

De kans op een dubbele ID beschouw ik ook als verwaarloosbaar. Mocht het toch ooit gebeuren dan kan ik dit ontdekken op het moment dat ik de individuele databases merge via een eenvoudige PK constraint.

[Kalentum]

Verwijderd schreef op dinsdag 29 juli 2008 @ 18:22:
Hoi,

Voor een relatief eenvoudige (Java) applicatie die gebruik maakt van Postgres heb ik momenteel meerdere nodes draaien, die echter gebruik maken van 1 centrale PG instantie.

Deze PG instantie wil ik binnenkort gaan opsplitsen naar een instantie per applicatie node. De applicatie gebruikt momenteel een sequence in een PG tabel die opgehoogd wordt om oplopend telkens unieke IDs te genereren.

Met een DB instantie per node heb ik niet langer de beschikking over eenvoudige unieke IDs. Ik zat nu echter te twijfelen tussen 2 mogelijke oplossingen:

Andere optie: replicatie, mits je lees/schrijfverhouding dit toelaat. Je hebt dan 1 master database en een aantal slaves. Is ook niet zo ingegrijpend voor je applicatie. De master geeft wijzigingen door aan de slave (=node).

[Verwijderd]

rutgerw schreef op woensdag 30 juli 2008 @ 14:27:
[...]
Andere optie: replicatie, mits je lees/schrijfverhouding dit toelaat. Je hebt dan 1 master database en een aantal slaves. Is ook niet zo ingegrijpend voor je applicatie. De master geeft wijzigingen door aan de slave (=node).

Inderdaad, replicatie is een mogelijkheid om de robuustheid van de applicatie te laten toenemen. Echter, PostgreSQL staat nu niet echt bekend om z'n uitstekende replicatie opties. Er zijn wat vage third party extenties die het toevoegen aan PG, maar niets wat nou echt heel betrouwbaar lijkt (maar misschien moet ik beter kijken).

Er wordt nagenoeg voornamelijk geschreven, wat voor een replicatie oplossing natuurlijk niet ideaal is. Zoals gezegd, ongeveer 15 writes per seconde per node. Elke write is een simpele transactie, maar de tabel per node zal dan wel enkele gigabytes groot zijn. Lezen is slechts sporadisch en bestaat bijvoorbeeld uit het opvragen van de laatste X transacties voor een bepaalde user en 1 keer per zoveel uur uit 1 grote bulk read waarna een report gegenereerd wordt.

[Soultaker]

Verwijderd schreef op dinsdag 29 juli 2008 @ 18:22:
Ik vraag me af of iemand wat kan zeggen over welke 2 van de mogelijke oplossingen nu beter is en/of wat er eigenlijk het meest in de praktijk gebruikt wordt.

Dit laatste is eenvoudig te beantwoorden: meestal worden GUIDs gebruikt. Als je OS (zoals bijvoorbeeld Windows) die genereert, dan zit er sowieso een (gehasht) MAC adres van een netwerkkaart in (die globaal uniek zijn) en waarschijnlijk een sequence number of iets dergelijks, waardoor het ook theoretisch onmogelijk is dat twee computers per ongeluk dezelfde GUID genereren. Zelfs voor hosts die niet op het netwerk aangesloten zijn, is die kans zeer klein.

Het enige nadeel van GUIDs is dat ze relatief lang zijn. Niet zo groot dat je ze niet als key in een database kunt gebruiken, maar soms is een kleinere key efficienter. In dat geval zou ik iets doen als 256*id + x waarbij x een uniek nummer is per host (b.v. het laatste getal in het IP-adres als je je servers toevallig in een klasse C netwerk hebt staan).

[flowerp]

Soultaker schreef op woensdag 30 juli 2008 @ 19:14:
[...]
In dat geval zou ik iets doen als 256*id + x waarbij x een uniek nummer is per host (b.v. het laatste getal in het IP-adres als je je servers toevallig in een klasse C netwerk hebt staan).

Ik heb daar ook wel eens aan gedacht voor een soortgelijk probleem, maar dit gaat natuurlijk fout als je je services op 1 machine draait onder verschillende poort nummers. Dat doe ik zelf geregeld met Tomcat instanties. Je kunt dan ook wel weer het poort nummer meenemen van je applicatie, maar ik ben altijd bang dat er dan toch weer iets mogelijk is waar ik niet aan gedacht heb.

[Verwijderd]

Soultaker schreef op woensdag 30 juli 2008 @ 19:14:
dan zit er sowieso een (gehasht) MAC adres van een netwerkkaart in (die globaal uniek zijn) en waarschijnlijk een sequence number of iets dergelijks, waardoor het ook theoretisch onmogelijk is dat twee computers per ongeluk dezelfde GUID genereren.

Dat was ooit het idee, maar tegenwoordig kun je bij vrijwel ieder netwerkkaart het MAC adres wijzigen/spoofen, en bij virtual machines / virtual netwerkkaarten wordt 't wel helemaal simpel.

Maar met RobIII, de kans dat jij en ik in ons leven een duplicate GUID tegenkomen is kleiner dan dat je huisje op de Cauberg door een oceaanstomer wordt geramd.