i mit tilfælde vil de fleste id'er blive genereret inden for et stort antal mobile klienter, ikke inden for et begrænset sæt servere. Jeg spekulerer på, om der i dette tilfælde er en berettiget bekymring.
Det lyder som meget dårlig arkitektur for mig. Bruger du en to-lags arkitektur? Hvorfor skulle de mobile klienter have direkte adgang til db? Vil du virkelig stole på netværksbaseret sikkerhed?
I hvert fald nogle overvejelser om kollisionssandsynligheden:
Hverken UUID eller ObjectId er afhængige af deres blotte størrelse, dvs. begge er ikke tilfældige tal, men de følger et skema, der forsøger systematisk at reducere sandsynligheden for kollisioner. I tilfælde af ObjectId'er er deres struktur:
- 4 byte sekunder siden unix-epoken
- 3 byte maskin-id
- 2 byte proces-id
- 3 byte tæller
Det betyder, at i modsætning til UUID'er er ObjectId'er monotone (undtagen inden for et enkelt sekund), hvilket nok er deres vigtigste egenskab. Monotoniske indekser vil få B-træet til at blive udfyldt mere effektivt, det tillader sidesøgning efter id og tillader en 'standard sortering' efter id for at gøre dine markører stabile, og de har selvfølgelig et tidsstempel, der er let at udtrække. Det er de optimeringer, du skal være opmærksom på, og de kan være enorme.
Som du kan se af strukturen af de andre 3 komponenter, bliver kollisioner meget sandsynlige, hvis du laver> 1k indsættelser/s på en enkelt proces (ikke rigtig muligt, ikke engang fra en server), eller hvis antallet af maskiner vokser forbi omkring 10 (se fødselsdagsproblem), eller hvis antallet af processer på en enkelt maskine bliver for stort (så igen, det er ikke tilfældige tal, men de er virkelig unikke på en maskine, men de skal forkortes til to bytes ).
For at en kollision skal ske, skal de naturligvis matche alle disse aspekter, så selvom to maskiner har den samme maskinhash, ville det stadig kræve, at en klient indsætter med den samme tællerværdi i nøjagtig samme sekund og samme proces-id, men ja, disse værdier kan kollidere.