Hvis du har flere webservere med flere processer, så er der virkelig ikke noget, du kan fjerne med at miste unikhed.
Hvis du ser på arten af ObjectId :
- en 4-byte værdi, der repræsenterer sekunderne siden Unix-epoken,
- en 3-byte maskin-id,
- et 2-byte proces-id, og
- en 3-byte tæller, der starter med en tilfældig værdi.
Du vil se, at der ikke er meget der, som du sikkert kan fjerne. Da de første 4 bytes er tid, ville det være udfordrende at implementere en algoritme, der fjernede dele af tidsstemplet på en ren og sikker måde.
Maskin-id'en og proces-id'en bruges i tilfælde, hvor der er flere servere og/eller processer, der fungerer som klienter til databaseserveren. Hvis du droppede en af dem, kan du ende med dubletter igen. Den tilfældige værdi som de sidste 3 bytes bruges til at sikre, at to identifikatorer, på den samme maskine, inden for samme proces, er unikke, selv når der ofte anmodes om det.
Hvis du brugte det som en ordre id , og du vil have sikret unikhed, ville jeg ikke trimme noget væk fra 12 byte-tallet, da det var omhyggeligt designet til at give en robust og effektiv distribueret mekanisme til at generere unikke numre, når der er mange forbundne databaseklienter.
Hvis du tog de sidste 5 tegn i ObjectId ..., og i en given periode, hvad er sandsynligheden for konflikt?
- proces-id
- tæller
Sandsynligheden for konflikt er høj . Proces-id'et kan forblive det samme gennem hele perioden, og det andet nummer er blot et stigende antal, der ville gentages efter 4095 ordrer. Men hvis processen genbruges, så har du også chancen for, at der vil være en konflikt med ældre ordrer osv. Og hvis du taler om flere databaseklienter, øges chancerne også. Jeg ville bare ikke prøve at trimme nummeret. Det er ikke værd at de ulykkelige kunder forsøger at afgive ordrer.
Selv tidsstemplet og den tilfældige startværdi er ikke tilstrækkelig, når der er flere databaseklienter, der genererer ObjectIds . Når du begynder at se på de forskellige stykker, især i forbindelse med en farm af databaseklienter, bør du se, hvorfor stykkerne er der, og hvorfor fjernelse af dem kan føre til en nedsmeltning i ObjectId generation.
Jeg vil foreslå, at du implementerer en algoritme til at oprette et unikt nummer og gemme det i databasen. Det er nemt nok at gøre. Det påvirker ydeevnen lidt, men det er sikkert.
Jeg skrev dette
svare for et stykke tid siden om udfordringerne ved at bruge et ObjectId i en URL. Den indeholder et link til, hvordan man opretter et unikt automatisk stigningsnummer ved hjælp af MongoDB.