Finns det några fördelar med att använda ett anpassat

Fördelar med att generera ditt eget _id s:

Du kan göra dem mer människovänliga genom att tilldela ökande nummer:1 , 2 , 3 , ...
Eller så kan du göra dem mer människovänliga genom att använda slumpmässiga strängar:t3oSKd9q

(Detta tar inte upp för mycket utrymme på skärmen, kan plockas ut från en lista och kan eventuellt kopieras manuellt om det behövs. Du måste dock göra det tillräckligt långt för att förhindra maskopi.)
Om du använder slumpmässigt genererade strängar kommer de att ha en ungefär jämn splittringsfördelning, till skillnad från standardmongo ObjectIds, som tenderar att gruppera poster som skapats ungefär samtidigt på samma skärva. (Om det är till hjälp eller inte beror verkligen på din skärningsstrategi.)
Eller så kanske du vill skapa ditt eget anpassade _id s som kommer att gruppera relaterade objekt på en skärva, t.ex. efter ägare eller geografisk region eller en kombination. (Återigen, om det är önskvärt eller inte beror på hur du avser att fråga efter data och/eller hur snabbt du producerar och lagrar den. Du kan också göra detta genom att ange en skärvnyckel istället för _id sig. Se diskussionen nedan.)


 
 Fördelar med att använda ObjectId s:
   
 ObjectIds är mycket bra för att undvika kollisioner. Om du genererar ditt eget _id s slumpmässigt eller samtidigt måste du hantera kollisionsrisken själv.
 
  
 ObjectIds innehåller deras skapelsetid inom dem. Det kan vara ett billigt och enkelt sätt att behålla skapandet av ett dokument och att sortera dokument kronologiskt. (Å andra sidan, om du inte vill exponera/läcka skapandet av ett dokument, då får du inte exponera dess ObjectId!)
 
 
 
 nanoid
 modulen kan hjälpa dig att generera korta slumpmässiga ID. De tillhandahåller också en kalkylator
 som kan hjälpa dig att välja en bra id-längd, beroende på hur många dokument/id du genererar varje timme.
 
 Alternativt skrev jag mongoose-generate-unique-key
 för att generera mycket korta slumpmässiga id (förutsatt att du använder mongoose-biblioteket).
 Shardingstrategier
 
 Jag kommer inte att påstå att jag är en expert på hur man bäst delar data, men här är några situationer som vi kan överväga:
   
 Ett astronomiskt observatorium eller partikelaccelerator hanterar gigabyte data per sekund. När en intressant händelse upptäcks kanske de vill lagra en enorm mängd data på bara några sekunder. I det här fallet vill de förmodligen ha en jämn fördelning av dokument över skärvorna, så att varje skärva kommer att arbeta lika hårt för att lagra data, och ingen skärva kommer att överväldigas.
 
  
 Du har en enorm mängd data och ibland behöver du bearbeta allt genast. I det här fallet (men beroende på algoritmen) kan en jämn fördelning återigen vara önskvärd, så att alla skärvor kan arbeta lika hårt med att bearbeta sin bit av data, innan de kombinerar resultaten i slutet. (Även om vi i det här scenariot kan förlita oss på MongoDB:s balancer, snarare än vår shard-nyckel, för den jämna fördelningen. Balanseraren körs i bakgrunden efter att data har lagrats. Efter att ha samlat in mycket data kan du behöva låt det omfördela bitarna över natten.)
 
  
 Du har en app för sociala medier med en stor mängd data, men den här gången gör många olika användare många lätta frågor relaterat främst till deras egna data, eller deras specifika vänner eller ämnen. I det här fallet är det inte meningsfullt att involvera varje fragment när en användare gör en liten fråga. Det kan vara meningsfullt att klippa efter användar-ID (eller efter ämne eller geografiskt område) så att alla dokument som tillhör en användare kommer att lagras på ett fragment, och när den användaren gör en fråga behöver bara ett fragment utföra arbete. Detta bör lämna de andra skärvorna fria att bearbeta frågor för andra användare, så många användare kan betjänas samtidigt.
 
  
 Dela dokument efter skapelsetid (som standard ObjectIds ger dig) kan vara önskvärt om du har många lätta frågor som tittar på data för liknande tidsperioder. Till exempel många olika användare som frågar efter olika historiska diagram.
 
 Men det kanske inte är så önskvärt om de flesta av dina användare bara frågar efter de senaste dokumenten (en vanlig situation på sociala medieplattformar) eftersom det skulle innebära att en eller två skärvor skulle få det mesta av arbetet. Att distribuera efter ämne eller kanske efter region kan ge en plattare övergripande fördelning, samtidigt som relaterade dokument kan klumpas ihop på en enda skärva.
 
 
 
 Du kanske vill läsa de officiella dokumenten om detta ämne:
   
 https://docs.mongodb.com/manual/sharding/#shard -nyckelstrategi
 
 
  
 https://docs.mongodb.com/manual/ core/sharding-choose-a-shard-key/

Finns det några fördelar med att använda ett anpassat _id för dokument i MongoDB?

Shardingstrategier