Mongodb Primary Key: Exempel för att ställa in _id-fält med ObjectId()
Stephen Twain
⚡ Smart sammanfattning
MongoDB Primärnyckeln är _id-fältet som unikt identifierar varje dokument i en samling. Som standard innehåller den ett automatiskt genererat ObjectId, men du kan också tilldela ett eget värde till _id-fältet när du infogar ett dokument.
Vad är Primary Key in MongoDB?
In MongoDB, _id-fältet som primärnyckel för samlingen så att varje dokument kan identifieras unikt i samlingen. Fältet _id innehåller ett unikt ObjectID-värde.
Som standard när du infogar dokument i samlingen, om du inte lägger till ett fältnamn med _id i fältnamnet, MongoDB kommer automatiskt att lägga till ett objekt-id-fält som visas nedan
När du frågar efter dokumenten i en samling kan du se ObjectId för varje dokument i samlingen.
Om du vill säkerställa det MongoDB skapar inte _id-fältet när samlingen skapas och om du vill ange ditt eget id som _id för samlingen, måste du uttryckligen definiera detta när du skapar samlingen.
När du uttryckligen skapar ett id-fält måste det skapas med _id i dess namn.
Låt oss titta på ett exempel på hur vi kan uppnå detta.
db.Employee.insert({_id:10, "EmployeeName" : "Smith"})
Code Förklaring:
- Vi antar att vi skapar det första dokumentet i samlingen och därför definierar vi i ovanstående uttalande när vi skapar samlingen uttryckligen fältet _id och definierar ett värde för det.
Om kommandot utförs framgångsrikt och nu använder kommandot find för att visa dokumenten i samlingen, kommer följande utdata att visas
Produktion:
Utdata visar tydligt att _id-fältet vi definierade när vi skapade samlingen nu används som primärnyckel för samlingen.
Vad är ObjectId i MongoDB?
Ett ObjectId är standardvärdestypen som MongoDB tilldelar primärnyckeln _id. Det är en 12-byte identifierare som är utformad för att vara globalt unik över servrar och samlingar, så två dokument får nästan aldrig samma värde. Eftersom klientdrivrutinen kan generera ett ObjectId utan att fråga servern, MongoDB kan snabbt infoga dokument och skala över många maskiner utan en central räknare.
Varje ObjectId lagras i kompakt binär form men visas som en hexadecimal sträng med 24 tecken, till exempel ObjectId("507f1f77bcf86cd799439011"). De första bytena baseras på aktuell tid, vilket innebär att värdena ökar stadigt allt eftersom dokument skapas. Detta gör ObjectId inte bara unikt utan också grovt sorterbart efter insättningsordning, en användbar egenskap när du vill ha de nyaste eller äldsta posterna först.
Struktur av en MongoDB ObjectId
A MongoDB ObjectId är exakt 12 byte långt, och varje del har en specifik betydelse. Att förstå strukturen hjälper till att förklara varför ObjectId är unika och tidsordnade:
- 4-byte tidsstämpel: Antalet sekunder sedan Unix-epoken, som registrerar när objekt-ID:t skapades. Detta gör att ID:n kan sorteras efter tid.
- 5-byte slumpmässigt värde: Ett värde som genereras en gång per process, vilket kombinerar maskin- och processidentiteten, så att olika klienter producerar olika ID:n.
- 3-byte stegräknare: En räknare som börjar från ett slumpmässigt värde och ökar med varje nytt ObjectId i samma sekund, vilket förhindrar kollisioner under snabba insättningar.
Tillsammans garanterar dessa tre delar att varje ObjectId är unikt, även när många dokument infogas samtidigt på olika servrar. Du kan läsa den inbäddade skapandetiden när som helst genom att anropa metoden getTimestamp() på ett ObjectId.
Fördelar med att använda ObjectId som primärnyckel
Att använda standardobjektet ObjectId som primärnyckel _id erbjuder flera praktiska fördelar, vilket är anledningen till att de flesta MongoDB samlingar är beroende av det:
- Automatisk generering: Du behöver inte skapa eller hantera nyckelvärden själv, vilket minskar risken för dubbletter av nycklar.
- Global unikhet: Objekt-ID:n förblir unika över servrar, så de fungerar bra i distribuerade och shardade distributioner.
- Inbyggd tidsstämpel: Den inbäddade skapandetiden låter dig sortera eller filtrera dokument efter ålder utan ett extra datumfält.
- Hög prestanda: Klientgenerering undviker en tur och retur till servern, keeping sätter in snabbt.
Även om ObjectId passar de flesta applikationer kan du fortfarande välja ett anpassat _id, till exempel en e-postadress eller produktkod, när en naturlig affärsnyckel förenklar frågor. Rätt val beror på hur du planerar att söka upp och relatera dina data.
