Jag håller inte med författaren till det valda svaret att Inget auto-inkrement-id i MongoDB och det finns goda skäl . Vi vet inte varför 10gen inte uppmuntrade användning av auto-inkrementerade ID:n. Det är spekulationer. Jag tror att 10gen gjorde det här valet eftersom det bara är lättare att säkerställa unika 12-byte ID:n i klustrade miljöer. Det är standardlösning som passar de flesta nykomlingar och ökar därför produktanpassningen vilket är bra för 10gens verksamhet.
Låt mig nu berätta för alla om min erfarenhet av ObjectIds i kommersiell miljö.
Jag bygger ett socialt nätverk. Vi har ungefär 6 miljoner användare och varje användare har ungefär 20 vänner.
Föreställ dig nu att vi har en samling som lagrar relationen mellan användare (vem som följer vem). Det ser ut så här
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
där vi har ett unikt sammansatt index {user_id, followee_id} . Vi kan uppskatta storleken på detta index till 12*2*6M*20 =2GB. Nu är det ett index för snabb uppslagning av personer jag följer. För snabb uppslagning av personer som följer mig behöver jag omvänt index. Det är ytterligare 2 GB.
Och det här är bara början. Jag måste bära dessa ID-kort överallt. Vi har aktivitetskluster där vi lagrar ditt nyhetsflöde. Det är varje event du eller dina vänner gör. Föreställ dig hur mycket utrymme det tar.
Och till slut fattade en av våra ingenjörer ett omedvetet beslut och bestämde sig för att lagra referenser som strängar som representerar ObjectId som fördubblar sin storlek.
Vad händer om ett index inte passar in i RAM? Inget bra, säger 10gen:
När ett index är för stort för att passa in i RAM, måste MongoDB läsa indexet från disken, vilket är en mycket långsammare operation än att läsa från RAM. Tänk på att ett index passar in i RAM-minnet när din server har RAM-minne tillgängligt för indexet i kombination med resten av arbetsuppsättningen.
Det betyder att läsningen går långsamt. Låsstriden ökar. Skrivandet blir också långsammare. Att se låsstridigheter på 80%-nish är inte längre en chock för mig.
Innan du vet ordet av hamnade du med 460 GB kluster som du måste dela upp i skärvor och som är ganska svårt att manipulera.
Facebook använder 64-bitars långa som användar-id :) Det finns en anledning till det. Du kan generera sekventiella ID:n
- med 10gens råd .
- använda mysql som lagring av räknare (om du är orolig för hastigheten, ta en titt på hanteraresocket )
- använda ID-genererande tjänst som du byggde eller använda något som Snowflake av Twitter.
Så här är mitt allmänna råd till alla. Vänligen gör din data så liten som möjligt. När du växer kommer det att spara dig massor av sömnlösa nätter.