Als je meerdere webservers hebt, met meerdere processen, dan is er echt niets dat je kunt verwijderen met verlies van uniciteit.
Als je kijkt naar de aard van de ObjectId :
- een waarde van 4 bytes die de seconden vertegenwoordigt sinds het Unix-tijdperk,
- een machine-ID van 3 bytes,
- een 2-byte proces-ID, en
- een 3-byte teller, beginnend met een willekeurige waarde.
Je zult zien dat er niet veel is dat je veilig zou kunnen verwijderen. Aangezien de eerste 4 bytes tijd zijn, zou het een uitdaging zijn om een algoritme te implementeren dat delen van de tijdstempel op een schone en veilige manier verwijdert.
De machine-ID en proces-ID worden gebruikt in gevallen waarin er meerdere servers en/of processen zijn die als client voor de databaseserver optreden. Als u een van beide laat vallen, kunt u opnieuw dubbele bestanden krijgen. De willekeurige waarde als de laatste 3 bytes wordt gebruikt om ervoor te zorgen dat twee identifiers, op dezelfde machine, binnen hetzelfde proces uniek zijn, zelfs als er vaak om wordt gevraagd.
Als je het als een bestelling gebruikte id , en u wilt verzekerd zijn van uniciteit, zou ik niets weghalen van het 12-byte-nummer, omdat het zorgvuldig is ontworpen om een robuust en efficiënt gedistribueerd mechanisme te bieden voor het genereren van unieke nummers wanneer er veel aangesloten databaseclients zijn.
Als u de laatste 5 tekens van de ObjectId ... heeft genomen, en in een bepaalde periode, wat is dan de kans op een conflict?
- proces-ID
- teller
De kans op een conflict is hoog . De proces-ID kan gedurende de hele periode hetzelfde blijven en het andere nummer is slechts een oplopend nummer dat na 4095 bestellingen wordt herhaald. Maar als het proces recyclet, heb je ook de kans dat er een conflict ontstaat met oudere bestellingen, enz. En als je het hebt over meerdere database-clients, nemen de kansen ook toe. Ik zou gewoon niet proberen om het aantal te knippen. Het is de ontevreden klanten niet waard om bestellingen te plaatsen.
Zelfs de tijdstempel en de willekeurige seed-waarde zijn niet voldoende als er meerdere databaseclients zijn die ObjectIds genereren . Als je naar de verschillende stukjes begint te kijken, vooral in de context van een verzameling databaseclients, zou je moeten begrijpen waarom de stukjes er zijn en waarom het verwijderen ervan zou kunnen leiden tot een ineenstorting van ObjectId generatie.
Ik stel voor dat je een algoritme implementeert om een uniek nummer te maken en op te slaan in de database. Het is eenvoudig genoeg om te doen. Het heeft wel wat invloed op de prestaties, maar het is veilig.
Ik schreef dit
antwoord een tijdje geleden over de uitdagingen van het gebruik van een ObjectId in een url. Het bevat een link naar hoe u een uniek automatisch oplopend nummer kunt maken met MongoDB.