Schrijfprestaties optimaliseren in Azure Cosmos DB voor MongoDB
VAN TOEPASSING OP: MongoDB
Door schrijfprestaties te optimaliseren kunt u optimaal profiteren van de onbeperkte schaal van Azure Cosmos DB voor MongoDB. In tegenstelling tot andere beheerde MongoDB-services, wordt de API voor MongoDB automatisch en transparant shards voor u (wanneer u shard-verzamelingen gebruikt) om oneindig te schalen.
De manier waarop u gegevens schrijft, moet hiervoor rekening houden door gegevens parallelliseren en verspreiden over shards om de meeste schrijfbewerkingen uit uw databases en verzamelingen te krijgen. In dit artikel worden aanbevolen procedures beschreven voor het optimaliseren van schrijfprestaties.
De belasting over uw shards verdelen
Bij het schrijven van gegevens naar een shard-API voor MongoDB-verzameling worden uw gegevens gesplitst (sharded) in kleine segmenten en naar elke shard geschreven op basis van de waarde van uw shardsleutelveld. U kunt elk segment beschouwen als een klein deel van een virtuele machine waarin alleen de documenten met één unieke shardsleutelwaarde worden opgeslagen.
Als uw toepassing een enorme hoeveelheid gegevens naar één shard schrijft, is dit niet efficiënt omdat de app de doorvoer van slechts één shard overschrijdt in plaats van de belasting over al uw shards te spreiden. De schrijfbelasting wordt gelijkmatig verdeeld over uw verzameling door parallel te schrijven naar veel documenten met unieke shardsleutelwaarden.
Een voorbeeld hiervan is een productcatalogustoepassing die is geshard op het categorieveld. In plaats van naar één categorie (shard) tegelijk te schrijven, is het beter om tegelijkertijd naar alle categorieën te schrijven om de maximale schrijfdoorvoer te bereiken.
Het aantal indexen verminderen
Indexeren is een uitstekende functie om de tijd die nodig is om query's uit te voeren op uw gegevens drastisch te verminderen. Voor de meest flexibele query-ervaring maakt de API voor MongoDB standaard een jokertekenindex voor uw gegevens mogelijk om query's uit te voeren op alle velden die razendsnel verlopen. Alle indexen, waaronder jokertekenindexen, veroorzaken echter extra belasting bij het schrijven van gegevens omdat schrijfbewerkingen de verzameling en indexen wijzigen.
Door het aantal indexen te verminderen tot alleen de indexen die u nodig hebt om uw query's te ondersteunen, worden uw schrijfbewerkingen sneller en goedkoper. In de algemene regel raden we het volgende aan:
- Elk veld waarop u filtert, moet een bijbehorende index met één veld hebben. Met deze optie kunt u ook filteren in meerdere velden.
- Elke groep velden waarop u sorteert, moet een samengestelde index voor die groep hebben.
Ingesteld op onwaar in de MongoDB-stuurprogramma's
Standaard stellen de MongoDB-stuurprogramma's de geordende optie in op 'true' bij het schrijven van gegevens, waarmee elk document één voor één wordt geschreven. Deze optie vermindert de schrijfprestaties omdat elke schrijfaanvraag moet wachten tot de vorige is voltooid. Bij het schrijven van gegevens stelt u deze optie in op false om de prestaties te verbeteren.
db.collection.insertMany(
[ <doc1> , <doc2>, ... ],
{
ordered: false
}
)
Afstemmen op de optimale batchgrootte en het aantal threads
Parallellisatie van schrijfbewerkingen in veel threads/processen is essentieel voor het schalen van schrijfbewerkingen. De API voor MongoDB accepteert schrijfbewerkingen in batches van maximaal 1000 documenten voor elk proces/thread.
Als u per proces/thread meer dan 1000 documenten tegelijk schrijft, kunnen clientfuncties, zoals insertMany()
ongeveer 1000 documenten, worden beperkt. Anders wacht de client tot elke batch is doorgevoerd voordat deze naar de volgende batch gaat. In sommige gevallen is het splitsen van de batches met minder of iets meer dan 1000 documenten sneller.
Volgende stappen
- Meer informatie over indexeren in de API voor MongoDB.
- Meer informatie over sharding/partitionering van Azure Cosmos DB.
- Meer informatie over het oplossen van veelvoorkomende problemen.
- Wilt u capaciteitsplanning uitvoeren voor een migratie naar Azure Cosmos DB? U kunt informatie over uw bestaande databasecluster gebruiken voor capaciteitsplanning.
- Als alles wat u weet het aantal vcores en servers in uw bestaande databasecluster is, leest u meer over het schatten van aanvraageenheden met behulp van vCores of vCPU's
- Als u typische aanvraagtarieven voor uw huidige databaseworkload kent, leest u meer over het schatten van aanvraageenheden met behulp van azure Cosmos DB-capaciteitsplanner