Om du har flera webbservrar, med flera processer, så finns det verkligen inte något du kan ta bort med att förlora unikhet.
Om du tittar på arten av ObjectId :
- ett 4-byte värde som representerar sekunderna sedan Unix-epoken,
- en 3-byte maskinidentifierare,
- ett 2-byte process-id, och
- en 3-byte räknare, som börjar med ett slumpmässigt värde.
Du kommer att se att det inte finns mycket där som du säkert kan ta bort. Eftersom de första 4 byten är tid skulle det vara utmanande att implementera en algoritm som tog bort delar av tidsstämpeln på ett rent och säkert sätt.
Maskinidentifieraren och processidentifieraren används i fall där det finns flera servrar och/eller processer som fungerar som klienter till databasservern. Om du tappade någon av dessa kan du sluta med dubbletter igen. Det slumpmässiga värdet som de sista 3 byten används för att säkerställa att två identifierare, på samma maskin, inom samma process är unika, även när de efterfrågas ofta.
Om du använde det som ett beställnings id , och du vill ha säker unikhet, skulle jag inte trimma bort något från 12-byte-numret eftersom det var noggrant utformat för att tillhandahålla en robust och effektiv distribuerad mekanism för att generera unika nummer när det finns många anslutna databasklienter.
Om du tog de sista 5 tecknen i ObjectId ... och under en given period, vad är sannolikheten för konflikt?
- process-id
- disk
Sannolikheten för konflikt är hög . Process-id:t kan förbli detsamma under hela perioden, och det andra numret är bara ett ökande antal som skulle upprepas efter 4095 beställningar. Men om processen återvinns, så har du också chansen att det blir en konflikt med äldre beställningar etc. Och om du pratar om flera databasklienter ökar chanserna också. Jag skulle bara inte försöka trimma numret. Det är inte värt att de missnöjda kunderna försöker lägga beställningar.
Även tidsstämpeln och det slumpmässiga startvärdet är inte tillräckliga när det finns flera databasklienter som genererar ObjectIds . När du börjar titta på de olika bitarna, särskilt i samband med en farm av databasklienter, bör du se varför bitarna finns där, och varför borttagning av dem kan leda till en härdsmälta i ObjectId generation.
Jag skulle föreslå att du implementerar en algoritm för att skapa ett unikt nummer och lagra det i databasen. Det är enkelt att göra. Det påverkar prestandan lite, men det är säkert.
Jag skrev det här
svara för ett tag sedan om utmaningarna med att använda ett ObjectId i en URL. Den innehåller en länk till hur man skapar ett unikt automatiskt inkrementeringsnummer med MongoDB.