in mijn geval worden de meeste ID's gegenereerd binnen een groot aantal mobiele clients, niet binnen een beperkte set servers. Ik vraag me af of er in dit geval een terechte zorg is.
Dat lijkt me erg slechte architectuur. Gebruik je een two-tier architectuur? Waarom zouden de mobiele cliënten directe toegang tot db hebben? Wilt u echt vertrouwen op netwerkgebaseerde beveiliging?
Hoe dan ook, enkele overwegingen over de aanvaringskans:
Noch UUID noch ObjectId vertrouwen op hun enorme omvang, d.w.z. beide zijn geen willekeurige getallen, maar ze volgen een schema dat de kans op botsingen systematisch probeert te verminderen. In het geval van ObjectIds is hun structuur:
- 4 byte seconden sinds unix-tijdperk
- 3-byte machine-ID
- 2-byte proces-ID
- teller van 3 bytes
Dit betekent dat, in tegenstelling tot UUID's, ObjectIds monotoon zijn (behalve binnen een enkele seconde), wat waarschijnlijk hun belangrijkste eigenschap is. Monotone indexen zorgen ervoor dat de B-Tree efficiënter wordt gevuld, het maakt paginering op id mogelijk en maakt een 'standaard sortering' op id mogelijk om uw cursors stabiel te maken, en natuurlijk hebben ze een gemakkelijk te extraheren tijdstempel. Dit zijn de optimalisaties waarvan u op de hoogte moet zijn, en ze kunnen enorm zijn.
Zoals je kunt zien aan de structuur van de andere 3 componenten, worden botsingen zeer waarschijnlijk als je> 1k inserts/s doet op een enkel proces (niet echt mogelijk, zelfs niet vanaf een server), of als het aantal machines groeit na ongeveer 10 (zie verjaardagsprobleem), of als het aantal processen op een enkele machine te groot wordt (dat zijn dan weer geen willekeurige getallen, maar ze zijn echt uniek op een machine, maar ze moeten worden ingekort tot twee bytes ).
Om een botsing te laten plaatsvinden, moeten ze natuurlijk overeenkomen in alle deze aspecten, dus zelfs als twee machines dezelfde machine-hash hebben, moet een client nog steeds dezelfde tellerwaarde invoegen in exact dezelfde seconde en hetzelfde proces-ID, maar ja, deze waarden kunnen botsen.