Zijn er voordelen aan het gebruik van een aangepaste

Voordelen met het genereren van uw eigen _id s:

U kunt ze mensvriendelijker maken door oplopende getallen toe te kennen:1 , 2 , 3 , ...
Of je kunt ze mensvriendelijker maken door willekeurige strings te gebruiken:t3oSKd9q

(Dat neemt niet te veel ruimte in beslag op het scherm, kan uit een lijst worden gehaald en kan indien nodig handmatig worden gekopieerd. U moet het echter wel lang genoeg maken om samenspanningen te voorkomen.)
Als u willekeurig gegenereerde tekenreeksen gebruikt, hebben ze een ongeveer gelijkmatige verdeling van de shards, in tegenstelling tot de standaard mongo ObjectIds, die de neiging heeft om records die rond dezelfde tijd zijn gemaakt, op dezelfde shard te groeperen. (Of dat nuttig is of niet, hangt echt af van uw sharding-strategie.)
Of misschien wilt u uw eigen aangepaste _id s waarmee gerelateerde objecten op één shard worden gegroepeerd, b.v. per eigenaar, of geografische regio, of een combinatie. (Nogmaals, of dat wenselijk is of niet, hangt af van hoe u de gegevens wilt opvragen en/of hoe snel u deze produceert en opslaat. U kunt dit ook doen door een shardsleutel op te geven in plaats van de _id zelf. Zie de discussie hieronder.)

Voordelen van het gebruik van ObjectId s:

ObjectIds zijn erg goed in het vermijden van botsingen. Als u uw eigen _id . genereert willekeurig of gelijktijdig is, moet u het aanvaringsrisico zelf beheren.
ObjectIds bevatten hun aanmaaktijd erin. Dat kan een goedkope en gemakkelijke manier zijn om de aanmaakdatum van een document te behouden en om documenten chronologisch te sorteren. (Aan de andere kant, als je de aanmaakdatum van een document niet wilt onthullen/lekken, dan mag je de ObjectId niet blootleggen!)

De nanoid module kan u helpen om korte willekeurige id's te genereren. Ze bieden ook een calculator die u kan helpen bij het kiezen van een goede id-lengte, afhankelijk van hoeveel documenten/id's u elk uur genereert.

Als alternatief schreef ik mongoose-generate-unique-key voor het genereren van zeer korte willekeurige id's (op voorwaarde dat u de mangoestbibliotheek gebruikt).

Shardingstrategieën

Ik zal niet beweren een expert te zijn in de beste manier om gegevens te sharden, maar hier zijn enkele situaties die we kunnen overwegen:

Een astronomisch observatorium of deeltjesversneller verwerkt gigabytes aan gegevens per seconde. Wanneer een interessante gebeurtenis wordt gedetecteerd, willen ze misschien een enorme hoeveelheid gegevens opslaan in slechts enkele seconden. In dit geval willen ze waarschijnlijk een gelijkmatige verdeling van documenten over de shards, zodat elke shard even hard zal werken om de gegevens op te slaan en geen enkele shard overweldigd zal worden.
Je hebt een enorme hoeveelheid gegevens en soms moet je alles verwerken onmiddelijk. In dit geval (maar afhankelijk van het algoritme) kan een gelijkmatige verdeling opnieuw wenselijk zijn, zodat alle shards even hard kunnen werken aan het verwerken van hun deel van de gegevens, voordat ze de resultaten aan het einde combineren. (Hoewel we in dit scenario mogelijk kunnen vertrouwen op de balancer van MongoDB, in plaats van op onze shard-sleutel, voor de gelijkmatige verdeling. De balancer wordt op de achtergrond uitgevoerd nadat de gegevens zijn opgeslagen. Nadat u veel gegevens hebt verzameld, moet u mogelijk laat het om de brokken een nacht te herverdelen.)
Je hebt een app voor sociale media met een grote hoeveelheid gegevens, maar deze keer stellen veel verschillende gebruikers veel lichte vragen voornamelijk gerelateerd aan hun eigen gegevens, of hun specifieke vrienden of onderwerpen. In dit geval heeft het geen zin om elke shard te betrekken wanneer een gebruiker een kleine vraag stelt. Het kan zinvol zijn om te sharden op gebruikers-ID (of op onderwerp of op geografische regio), zodat alle documenten van één gebruiker op één shard worden opgeslagen, en wanneer die gebruiker een query doet, hoeft slechts één shard te werken. Hierdoor zouden de andere shards vrij moeten blijven om zoekopdrachten voor andere gebruikers te verwerken, zodat veel gebruikers tegelijk kunnen worden bediend.
Documenten sharden op aanmaaktijd (wat de standaard ObjectIds u zullen geven) kan wenselijk zijn als u veel lichte zoekopdrachten hebt die gegevens voor vergelijkbare tijdsperioden bekijken. Bijvoorbeeld veel verschillende gebruikers die verschillende historische grafieken doorzoeken.

Maar het is misschien niet zo wenselijk als de meeste van uw gebruikers alleen de meest recente documenten opvragen (een veelvoorkomende situatie op sociale-mediaplatforms), omdat dat zou betekenen dat een of twee shards het meeste werk zouden krijgen. Distributie per onderwerp of misschien per regio kan zorgen voor een vlakkere algemene distributie, terwijl gerelateerde documenten ook samen kunnen klonteren op een enkele scherf.

Misschien vind je het leuk om de officiële documenten over dit onderwerp te lezen:

Zijn er voordelen aan het gebruik van een aangepaste _id voor documenten in MongoDB?

Shardingstrategieën