Tips voor betere prestaties voor De Python SDK van Azure Cosmos DB

VAN TOEPASSING OP: NoSQL

Azure Cosmos DB is een snelle en flexibele gedistribueerde database die naadloos wordt geschaald met gegarandeerde latentie en doorvoer. U hoeft geen belangrijke architectuurwijzigingen aan te brengen of complexe code te schrijven om uw database te schalen met Azure Cosmos DB. Omhoog en omlaag schalen is net zo eenvoudig als het maken van één API-aanroep of SDK-methode-aanroep. Omdat Azure Cosmos DB echter toegankelijk is via netwerkaanroepen, zijn er optimalisaties aan de clientzijde die u kunt maken om piekprestaties te bereiken bij het gebruik van de Python SDK van Azure Cosmos DB.

Dus als u 'Hoe kan ik de prestaties van mijn database verbeteren?' vraagt, moet u rekening houden met de volgende opties:

Netwerken

• Clients in dezelfde Azure-regio plaatsen voor prestaties

Plaats indien mogelijk toepassingen die Azure Cosmos DB aanroepen in dezelfde regio als de Azure Cosmos DB-database. Voor een geschatte vergelijking zijn aanroepen naar Azure Cosmos DB binnen dezelfde regio voltooid binnen 1-2 ms, maar de latentie tussen de west- en oostkust van de VS is >50 ms. Deze latentie kan waarschijnlijk variëren van aanvraag tot aanvraag, afhankelijk van de route die door de aanvraag wordt genomen, omdat deze wordt doorgegeven van de client naar de grens van het Azure-datacenter. De laagst mogelijke latentie wordt bereikt door ervoor te zorgen dat de aanroepende toepassing zich in dezelfde Azure-regio bevindt als het ingerichte Azure Cosmos DB-eindpunt. Zie Azure-regio's voor een lijst met beschikbare regio's.

Een app die communiceert met een Azure Cosmos DB-account met meerdere regio's, moet voorkeurslocaties configureren om ervoor te zorgen dat aanvragen naar een regio met meerdere regio's gaan.

Versneld netwerken inschakelen om latentie en CPU-jitter te verminderen

Het is raadzaam om de instructies te volgen om versneld netwerken in te schakelen in uw Windows (selecteer voor instructies) of Linux (selecteer voor instructies) Azure VM om de prestaties te maximaliseren (latentie en CPU-jitter verminderen).

Zonder versneld netwerk kan IO die tussen uw Azure-VM en andere Azure-resources wordt verzonden, onnodig via een host en virtuele switch gerouteerd worden, tussen de virtuele machine en de netwerkaansluiting. Wanneer de host en virtuele switch in lijn worden geplaatst met het gegevenspad, neemt niet alleen de latentie en jitter toe in het communicatiekanaal, maar worden er ook CPU-cycli van de virtuele machine gestolen. Bij versneld netwerken communiceren de VM-interfaces rechtstreeks met de NIC zonder tussenpersonen. Alle netwerkbeleidsgegevens die door de host en de virtuele switch werden verwerkt, worden nu verwerkt door de hardware van de NIC. De host en de virtuele switch worden daarbij omzeild. Over het algemeen kunt u lagere latentie en hogere doorvoer verwachten, evenals consistentere latentie en een lager CPU-gebruik wanneer u versneld netwerken inschakelt.

Beperkingen: versneld netwerk moet worden ondersteund op het VM OS en kan alleen worden ingeschakeld wanneer de VM wordt gestopt en gedealloceerd. De VM kan niet worden geïmplementeerd met Azure Resource Manager. App Service heeft geen versneld netwerk ingeschakeld.

Raadpleeg de windows- en Linux-instructies voor meer informatie.

Hoge beschikbaarheid

Zie Hoge beschikbaarheid in Azure Cosmos DB voor algemene richtlijnen voor het configureren van hoge beschikbaarheid in Azure Cosmos DB.

Naast een goede basisinstallatie in het databaseplatform kan circuitonderbreker op partitieniveau worden geïmplementeerd in de Python SDK, wat kan helpen bij storingsscenario's. Deze functie biedt geavanceerde mechanismen voor beschikbaarheidsuitdagingen, bovenop en verder gaand dan de herstartmogelijkheden over meerdere regio's die standaard in de SDK zijn ingebouwd. Dit kan de tolerantie en prestaties van uw toepassing aanzienlijk verbeteren, met name onder hoge belasting of gedegradeerde omstandigheden.

Circuitonderbreker op partitieniveau

De circuitonderbreker op partitieniveau (PPCB) in de Python SDK verbetert de beschikbaarheid en veerkracht door de gezondheid van afzonderlijke fysieke partities bij te houden en verzoeken weg te leiden van problematische partities. Deze functie is met name handig voor het afhandelen van tijdelijke en terminalproblemen, zoals netwerkproblemen, partitie-upgrades of migraties.

PPCB is van toepassing in de volgende scenario's:

• Elk consistentieniveau
• Bewerkingen met partitiesleutel (puntlees-/schrijfbewerkingen)
• Accounts met één schrijfregio en meerdere leesregio's
• Meerdere accounts voor schrijfregio's

Hoe het werkt

Partities gaan over in vier statussen: Gezond, Ongezond Voorlopig, Ongezond en Gezond Voorlopig op basis van het slagen of falen van verzoeken.

1. Fouten bijhouden: De SDK bewaakt foutpercentages (bijvoorbeeld 5xx, 408) per partitie gedurende een venster van één minuut. Opeenvolgende fouten per partitie worden voor onbepaalde tijd bijgehouden door de SDK.
2. Markeren als niet beschikbaar: Als een partitie de geconfigureerde drempelwaarden overschrijdt, wordt deze gedurende 1 minuut gemarkeerd als Tijdelijk Ongezond en uitgesloten van verkeer.
3. Overgang naar ongezond of herstel: Als herstelpogingen mislukken, gaat de partitie over naar Ongezond. Na een uitstelinterval wordt een gezonde voorlopig test uitgevoerd met een aanvraag voor beperkte tijd om het herstel te bepalen.
4. Herstel: Als de verkennende test slaagt, keert de partitie terug naar Gezond. Anders blijft deze ongezond tot de volgende sonde.

Deze failover wordt intern beheerd door de SDK en zorgt ervoor dat verzoeken bekende problematische partities vermijden totdat wordt bevestigd dat ze weer gezond zijn.

Configuratie via omgevingsvariabelen

U kunt het PPCB-gedrag beheren met behulp van deze omgevingsvariabelen:

Uitgesloten regio's

Met de functie uitgesloten regio's kunt u nauwkeurig controle krijgen over aanvraagroutering door specifieke regio's uit te sluiten van uw voorkeurslocaties per aanvraag. Deze functie is beschikbaar in Azure Cosmos DB Python SDK versie 4.14.0 en hoger.

Belangrijkste voordelen:

• Snelheidsbeperking verwerken: wanneer er 429 (Te veel aanvragen) antwoorden optreden, worden aanvragen automatisch doorgestuurd naar alternatieve regio's met beschikbare doorvoer
• Gerichte routering: Zorg ervoor dat aanvragen worden verwerkt vanuit specifieke regio's door alle andere regio's uit te sluiten
• Voorkeursvolgorde overslaan: de standaardlijst met voorkeursregio's voor afzonderlijke aanvragen overschrijven zonder afzonderlijke clients te maken

Configuration:

Uitgesloten regio's kunnen worden geconfigureerd op zowel clientniveau als aanvraagniveau:

from azure.cosmos import CosmosClient
from azure.cosmos.partition_key import PartitionKey

# Configure preferred locations and excluded locations at client level
preferred_locations = ['West US 3', 'West US', 'East US 2']
excluded_locations_on_client = ['West US 3', 'West US']

client = CosmosClient(
    url=HOST,
    credential=MASTER_KEY,
    preferred_locations=preferred_locations,
    excluded_locations=excluded_locations_on_client
)

database = client.create_database('TestDB')
container = database.create_container(
    id='TestContainer',
    partition_key=PartitionKey(path="/pk")
)

# Create an item (writes ignore excluded_locations in single-region write accounts)
test_item = {
    'id': 'Item_1',
    'pk': 'PartitionKey_1',
    'test_object': True,
    'lastName': 'Smith'
}
created_item = container.create_item(test_item)

# Read operations will use preferred_locations minus excluded_locations
# In this example: ['West US 3', 'West US', 'East US 2'] - ['West US 3', 'West US'] = ['East US 2']
item = container.read_item(
    item=created_item['id'],
    partition_key=created_item['pk']
)

Uitgesloten regio's op aanvraagniveau:

Uitgesloten regio's op aanvraagniveau hebben de hoogste prioriteit en overschrijven instellingen op clientniveau:

# Excluded locations can be specified per request, overriding client settings
excluded_locations_on_request = ['West US 3']

# Create item with request-level excluded regions
created_item = container.create_item(
    test_item,
    excluded_locations=excluded_locations_on_request
)

# Read with request-level excluded regions
# This will use: ['West US 3', 'West US', 'East US 2'] - ['West US 3'] = ['West US', 'East US 2']
item = container.read_item(
    item=created_item['id'],
    partition_key=created_item['pk'],
    excluded_locations=excluded_locations_on_request
)

Consistentie afstemmen versus beschikbaarheid

De functie uitgesloten regio's biedt een extra mechanisme voor het verdelen van consistentie en beschikbaarheid in uw toepassing. Deze mogelijkheid is met name waardevol in dynamische scenario's waarbij de vereisten kunnen veranderen op basis van operationele omstandigheden:

Dynamische verwerking van storingen: Wanneer een primaire regio te maken krijgt met een storing en de drempelwaarden voor circuitonderbrekers op partitieniveau ontoereikend zijn, maken uitgesloten regio's onmiddellijke failover mogelijk zonder codewijzigingen of het herstarten van toepassingen. Dit biedt een snellere reactie op regionale problemen vergeleken met wachten op automatische activering van circuitonderbrekers.

Voorkeuren voor voorwaardelijke consistentie: toepassingen kunnen verschillende consistentiestrategieën implementeren op basis van de operationele status:

• Stabiele status: prioriteit geven aan consistente leesbewerkingen door alle regio's behalve de primaire regio's uit te sluiten, waardoor gegevensconsistentie wordt gegarandeerd tegen de mogelijke beschikbaarheidskosten
• Storingsscenario's: voorkeur geven aan beschikbaarheid boven strikte consistentie door routering tussen regio's mogelijk te maken, mogelijke gegevensvertraging te accepteren in ruil voor continue beschikbaarheid van services

Met deze aanpak kunnen externe mechanismen (zoals traffic managers of load balancers) failoverbeslissingen organiseren terwijl de toepassing controle houdt over consistentievereisten via uitsluitingspatronen voor regio's.

Wanneer alle regio's worden uitgesloten, worden aanvragen doorgestuurd naar de primaire/hubregio. Deze functie werkt met alle aanvraagtypen, waaronder query's, en is met name handig voor het onderhouden van singleton-clientexemplaren en het bereiken van flexibel routeringsgedrag.

SDK-gebruik

• De meest recente SDK installeren

De Azure Cosmos DB SDK's worden voortdurend verbeterd om de beste prestaties te bieden. Zie de releaseopmerkingen van de Azure Cosmos DB SDK om de meest recente SDK te bepalen en verbeteringen te bekijken.

• Een Singleton Azure Cosmos DB-client gebruiken voor de levensduur van uw toepassing

Elk Azure Cosmos DB-clientexemplaren is thread-veilig en voert efficiënt verbindingsbeheer en adrescaching uit. Om efficiënt verbindingsbeheer en betere prestaties van de Azure Cosmos DB-client mogelijk te maken, is het raadzaam om één exemplaar van de Azure Cosmos DB-client te gebruiken voor de levensduur van de toepassing.

• Time-outs afstemmen en configuraties opnieuw proberen

Time-outconfiguraties en beleid voor opnieuw proberen kunnen worden aangepast op basis van de behoeften van de toepassing. Raadpleeg het document voor de configuratie van time-outs en retries om een volledige lijst met aanpasbare configuraties te verkrijgen.

• Het laagste consistentieniveau gebruiken dat is vereist voor uw toepassing

Wanneer u een CosmosClient maakt, wordt consistentie op accountniveau gebruikt als er geen is opgegeven bij het maken van de client. Zie het document over consistentieniveaus voor meer informatie over consistentieniveaus .

• De werklast van uw clients uitbreiden

Als u test op hoge doorvoerniveaus, kan de clienttoepassing het knelpunt worden omdat de computer het CPU- of netwerkgebruik beperkt. Als u dit punt bereikt, kunt u het Azure Cosmos DB-account verder pushen door uw clienttoepassingen uit te schalen op meerdere servers.

Een goede vuistregel is niet groter dan >50% CPU-gebruik op een bepaalde server, om latentie laag te houden.

• Resourcelimiet voor openen van besturingssysteembestanden

Sommige Linux-systemen (zoals Red Hat) hebben een bovengrens voor het aantal geopende bestanden en dus het totale aantal verbindingen. Voer het volgende uit om de huidige limieten weer te geven:

ulimit -a

Het aantal geopende bestanden (nofile) moet groot genoeg zijn om voldoende ruimte te hebben voor de geconfigureerde grootte van de verbindingsgroep en andere geopende bestanden door het besturingssysteem. Het kan worden gewijzigd om een grotere verbindingsgroepgrootte toe te staan.

Open het bestand limits.conf:

vim /etc/security/limits.conf

Voeg/wijzig de volgende regels toe:

* - nofile 100000

Querybewerkingen

Zie de prestatietips voor het uitvoeren van query's.

Indexeringsbeleid

• Niet-gebruikte paden uitsluiten van indexering voor snellere schrijfbewerkingen

Met het indexeringsbeleid van Azure Cosmos DB kunt u opgeven welke documentpaden moeten worden opgenomen of uitgesloten van indexering door gebruik te maken van indexeringspaden (setIncludedPaths en setExcludedPaths). Het gebruik van indexeringspaden kan betere schrijfprestaties en lagere indexopslag bieden voor scenario's waarin de querypatronen vooraf bekend zijn, omdat indexeringskosten rechtstreeks worden gecorreleerd aan het aantal unieke paden dat is geïndexeerd. In de volgende code ziet u bijvoorbeeld hoe u volledige secties van de documenten (ook wel substructuur genoemd) kunt opnemen en uitsluiten van indexering met behulp van het jokerteken *.

container_id = "excluded_path_container"
indexing_policy = {
        "includedPaths" : [ {'path' : "/*"} ],
        "excludedPaths" : [ {'path' : "/non_indexed_content/*"} ]
        }
db.create_container(
    id=container_id,
    indexing_policy=indexing_policy,
    partition_key=PartitionKey(path="/pk"))

Zie Het indexeringsbeleid van Azure Cosmos DB voor meer informatie.

Doorvoer

• Meten en afstemmen op lagere aanvraageenheden/tweede gebruik

Azure Cosmos DB biedt een uitgebreide set databasebewerkingen, waaronder relationele en hiërarchische query's met UDF's, opgeslagen procedures en triggers, die allemaal werken op de documenten in een databaseverzameling. De kosten die gepaard gaan met elke bewerking hangen af van de CPU, de IO en het geheugen, vereist om de bewerking uit te voeren. In plaats van aan hardwareresources te denken en te beheren, kunt u een aanvraageenheid (RU) beschouwen als één meting voor de resources die nodig zijn voor het uitvoeren van verschillende databasebewerkingen en het uitvoeren van een toepassingsaanvraag.

Doorvoer wordt ingericht op basis van het aantal aanvraageenheden dat is ingesteld voor elke container. Verbruik van aanvraageenheden wordt geëvalueerd als een tarief per seconde. Toepassingen die de ingerichte aanvraageenheidsnelheid voor hun container overschrijden, zijn beperkt totdat de snelheid lager is dan het ingerichte niveau voor de container. Als uw toepassing een hoger doorvoerniveau vereist, kunt u de doorvoer verhogen door extra aanvraageenheden in te richten.

De complexiteit van een query heeft invloed op het aantal aanvraageenheden dat wordt verbruikt voor een bewerking. Het aantal predicaten, de aard van de predicaten, het aantal UDF's en de grootte van de brongegevensset zijn allemaal van invloed op de kosten van querybewerkingen.

Als u de overhead van een bewerking wilt meten (maken, bijwerken of verwijderen), inspecteert u de header x-ms-request-charge om het aantal aanvraageenheden te meten dat door deze bewerkingen wordt verbruikt.

document_definition = {
    'id': 'document',
    'key': 'value',
    'pk': 'pk'
}
document = container.create_item(
    body=document_definition,
)
print("Request charge is : ", container.client_connection.last_response_headers['x-ms-request-charge'])

De verzoekkosten die in deze header worden geretourneerd, zijn een fractie van uw geconfigureerde doorvoer. Als u bijvoorbeeld 2000 RU/s hebt ingericht en als de voorgaande query 1000 1KB-documenten retourneert, zijn de kosten van de bewerking 1000. Daarom eert de server binnen één seconde slechts twee dergelijke aanvragen voordat de frequentie van volgende aanvragen wordt beperkt. Zie Aanvraageenheden en de rekenmachine voor aanvraageenheden voor meer informatie.

• Omgaan met snelheidsbeperking/aanvraagsnelheid te hoog

Wanneer een client de gereserveerde doorvoer voor een account probeert te overschrijden, is er geen prestatievermindering op de server en is er geen gebruik van doorvoercapaciteit buiten het gereserveerde niveau. De server zal de aanvraag op voorhand beëindigen met RequestRateTooLarge (HTTP-statuscode 429) en retourneert de x-ms-retry-after-ms header die aangeeft hoeveel milliseconden de gebruiker moet wachten voordat de aanvraag opnieuw kan worden geprobeerd.

HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100

De SDKs vangen dit antwoord impliciet op, respecteren de door de server opgegeven retry-after header en proberen de aanvraag opnieuw. Tenzij uw account gelijktijdig wordt geopend door meerdere clients, slaagt de volgende nieuwe poging.

Als u meer dan één client hebt die gezamenlijk consistent boven de aanvraagsnelheid opereert, is het huidige standaard aantal nieuwe pogingen, intern door de client ingesteld op 9, mogelijk niet voldoende; in dat geval genereert de client een CosmosHttpResponseError met statuscode 429 naar de applicatie. Het standaardaantal nieuwe pogingen kan worden gewijzigd door de configuratie door te geven retry_total aan de client. De CosmosHttpResponseError met statuscode 429 wordt standaard geretourneerd na een cumulatieve wachttijd van 30 seconden als de aanvraag blijft werken boven de aanvraagsnelheid. Dit gebeurt zelfs wanneer het huidige aantal nieuwe pogingen kleiner is dan het maximumaantal nieuwe pogingen, of het nu de standaardwaarde is van 9 of een door de gebruiker gedefinieerde waarde.

Hoewel het automatische herhaalgedrag helpt om de veerkracht en bruikbaarheid voor de meeste toepassingen te verbeteren, kan het conflicteren bij het uitvoeren van prestatiebenchmarks, vooral bij het meten van latentie. De door de client waargenomen latentie zal pieken als het experiment de server beperkt en ervoor zorgt dat de client-SDK stilletjes opnieuw probeert. Als u latentiepieken tijdens prestatie-experimenten wilt voorkomen, meet u de lading die door elke bewerking wordt geretourneerd en zorgt u ervoor dat verzoeken binnen de gereserveerde aanvraagsnelheid blijven. Zie Aanvraageenheden voor meer informatie.

• Ontwerpen voor kleinere documenten voor hogere doorvoer

De aanvraagkosten (de aanvraagverwerkingskosten) van een bepaalde bewerking worden rechtstreeks gecorreleerd aan de grootte van het document. Bewerkingen op grote documenten kosten meer dan bewerkingen voor kleine documenten. Ontwerp uw toepassing en werkstromen bij voorkeur zo dat de grootte van uw item ongeveer 1 kB is, of van een vergelijkbare orde van grootte. Voor latentiegevoelige toepassingen moeten grote items worden vermeden: documenten met meerdere MB vertragen uw toepassing.

Volgende stappen

Zie Partitioneren en schalen in Azure Cosmos DB voor meer informatie over het ontwerpen van uw toepassing voor schaalaanpassing en hoge prestaties.

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