Ik ben het sterk oneens met de auteur van het geselecteerde antwoord dat Geen auto-increment id in MongoDB en er zijn goede redenen . We weten niet waarom 10gen het gebruik van automatisch oplopende ID's niet aanmoedigde. Het is speculatie. Ik denk dat 10gen deze keuze heeft gemaakt omdat het gewoon eenvoudiger is om de uniciteit van 12-byte ID's in een geclusterde omgeving te garanderen. Het is een standaardoplossing die geschikt is voor de meeste nieuwkomers en verhoogt daarom de acceptatie van producten, wat goed is voor de activiteiten van 10gen.
Laat me nu iedereen vertellen over mijn ervaring met ObjectIds in een commerciële omgeving.
Ik bouw een sociaal netwerk op. We hebben ongeveer 6 miljoen gebruikers en elke gebruiker heeft ongeveer 20 vrienden.
Stel je nu voor dat we een verzameling hebben waarin de relatie tussen gebruikers wordt opgeslagen (wie volgt wie). Het ziet er zo uit
_id : ObjectId
user_id : ObjectId
followee_id : ObjectId
waarop we een unieke samengestelde index hebben {user_id, followee_id} . We kunnen de grootte van deze index schatten op 12*2*6M*20 =2GB. Dat is een index voor het snel opzoeken van mensen die ik volg. Voor het snel opzoeken van mensen die mij volgen heb ik reverse index nodig. Dat is nog eens 2 GB.
En dit is nog maar het begin. Ik moet deze ID's overal mee naartoe nemen. We hebben een activiteitencluster waar we uw nieuwsfeed opslaan. Dat is elk evenement dat jij of je vrienden doen. Stel je voor hoeveel ruimte het kost.
En ten slotte nam een van onze technici een onbewuste beslissing en besloot om referenties op te slaan als tekenreeksen die ObjectId vertegenwoordigen die twee keer zo groot is.
Wat gebeurt er als een index niet in het RAM past? Niets goeds, zegt 10gen:
Als een index te groot is om in RAM te passen, moet MongoDB de index van schijf lezen, wat een veel langzamere operatie is dan lezen uit RAM. Houd er rekening mee dat een index in RAM past wanneer uw server RAM beschikbaar heeft voor de index in combinatie met de rest van de werkset.
Dat betekent dat het lezen traag is. Slotstrijd gaat omhoog. Schrijven wordt ook langzamer. Het zien van slotconflicten in 80%-nish is niet langer een schok voor mij.
Voor je het weet heb je een cluster van 460 GB dat je in scherven moet splitsen en dat vrij moeilijk te manipuleren is.
Facebook gebruikt 64-bits lang als gebruikers-ID :) Dat heeft een reden. U kunt opeenvolgende ID's genereren
- met behulp van Advies van 10gen .
- mysql gebruiken als opslag van tellers (als je je zorgen maakt over snelheid, kijk dan eens naar handlersocket )
- met behulp van een ID-genererende service die u hebt gebouwd of met iets als Sneeuwvlok door Twitter.
Dus hier is mijn algemene advies aan iedereen. Gelieve uw gegevens zo klein mogelijk te maken. Als je groeit, zal het je veel slapeloze nachten besparen.