Jeg er meget uenig med forfatteren af det valgte svar, at Ingen auto-increment id i MongoDB, og der er gode grunde . Vi kender ikke årsagerne til, at 10gen ikke tilskyndede til brug af auto-inkrementerede id'er. Det er spekulationer. Jeg tror, at 10gen har truffet dette valg, fordi det bare er nemmere at sikre unikke 12-byte-id'er i et klyngemiljø. Det er standardløsning, der passer til de fleste nytilkomne, og øger derfor produktadoptionen, hvilket er godt for 10gens forretning.
Lad mig nu fortælle alle om min erfaring med ObjectIds i kommercielle omgivelser.
Jeg bygger et socialt netværk. Vi har omkring 6 millioner brugere, og hver bruger har omkring 20 venner.
Forestil dig nu, at vi har en kollektion, der gemmer forholdet mellem brugere (hvem følger hvem). Det ser sådan ud
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
hvor vi har et unikt sammensat indeks {user_id, followee_id} . Vi kan estimere størrelsen af dette indeks til at være 12*2*6M*20 =2GB. Det er nu et indeks for hurtigt opslag af personer, jeg følger. For hurtigt at slå op på folk, der følger mig, har jeg brug for omvendt indeks. Det er yderligere 2 GB.
Og dette er kun begyndelsen. Jeg skal have disse ID'er med overalt. Vi har aktivitetsklynge, hvor vi gemmer dit nyhedsfeed. Det er enhver begivenhed, du eller dine venner gør. Forestil dig, hvor meget plads det tager.
Og endelig tog en af vores ingeniører en ubevidst beslutning og besluttede at gemme referencer som strenge, der repræsenterer ObjectId, som fordobler størrelsen.
Hvad sker der, hvis et indeks ikke passer ind i RAM? Ikke noget godt, siger 10gen:
Når et indeks er for stort til at passe ind i RAM, skal MongoDB læse indekset fra disk, hvilket er en meget langsommere operation end at læse fra RAM. Husk, at et indeks passer ind i RAM, når din server har RAM til rådighed for indekset kombineret med resten af arbejdssættet.
Det betyder, at læsninger er langsom. Låsestriden stiger. Skrivning bliver også langsommere. At se låsestrid på 80%-nish er ikke længere et chok for mig.
Før du ved af det, endte du med en klynge på 460 GB, som du skal opdele i skår, og som er ret svær at manipulere.
Facebook bruger 64-bit lang som bruger-id :) Det er der en grund til. Du kan generere sekventielle ID'er
- ved at bruge 10gens råd .
- brug af mysql som lagring af tællere (hvis du er bekymret for hastighed, tag et kig på handlersocket )
- ved at bruge ID-genereringstjeneste, du har bygget, eller ved at bruge noget som Snefnug af Twitter.
Så her er mit generelle råd til alle. Gør venligst dine data så små som muligt. Når du vokser, vil det spare dig for mange søvnløse nætter.