Teljesítménytippek az Azure Cosmos DB Python SDK-hoz

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Fontos

A cikkben szereplő teljesítménytippek csak az Azure Cosmos DB Python SDK-hoz tartoznak. További információért tekintse meg az Azure Cosmos DB Python SDK Readme kibocsátási megjegyzéseit, a Csomag (PyPI), a Csomag (Conda) és a hibaelhárítási útmutatót.

Az Azure Cosmos DB egy gyors és rugalmas elosztott adatbázis, amely zökkenőmentesen méretezhető, garantált késéssel és átviteli sebességgel. Nem kell jelentős architektúramódosításokat végeznie, vagy összetett kódot kell írnia az adatbázis Azure Cosmos DB-vel való skálázásához. A vertikális fel- és leskálázás olyan egyszerű, mint egyetlen API-hívás vagy SDK-metódushívás. Mivel azonban az Azure Cosmos DB hálózati hívásokon keresztül érhető el, az ügyféloldali optimalizálásokkal csúcsteljesítmény érhető el az Azure Cosmos DB Python SDK használatakor.

Ha tehát a "Hogyan javíthatom az adatbázis teljesítményét?" kérdésre válaszol, vegye figyelembe a következő lehetőségeket:

Hálózat

  • Ügyfelek rendezése ugyanabban az Azure-régióban a teljesítmény érdekében

Ha lehetséges, helyezze az Azure Cosmos DB-t hívó alkalmazásokat ugyanabban a régióban, mint az Azure Cosmos DB-adatbázis. Hozzávetőleges összehasonlításként az ugyanazon régión belül az Azure Cosmos DB-be irányuló hívások 1–2 ms-on belül befejeződnek, de az USA >nyugati és keleti partja közötti késés 50 ms. Ez a késés valószínűleg a kéréstől függően változhat attól függően, hogy a kérés milyen útvonalon halad át az ügyfélről az Azure-adatközpont határára. A lehető legkisebb késést úgy érheti el, hogy a hívó alkalmazás ugyanabban az Azure-régióban található, mint a kiépített Azure Cosmos DB-végpont. Az elérhető régiók listáját az Azure-régiók című témakörben találja.

Az Azure Cosmos DB kapcsolati szabályzatának illusztrációja.

A többrégiós Azure Cosmos DB-fiókkal együttműködő alkalmazásoknak előnyben részesített helyeket kell konfigurálnia, hogy a kérések egy csoportosított régióba kerülhessenek.

Gyorsított hálózatkezelés engedélyezése a késés és a PROCESSZOR-jitter csökkentése érdekében

Javasoljuk, hogy kövesse az utasításokat a gyorsított hálózatkezelés engedélyezéséhez a Windowsban (válassza az utasításokat) vagy a Linuxon (válassza ki az utasításokat) Az Azure-beli virtuális gép a teljesítmény maximalizálása érdekében (a késés és a cpu-jitter csökkentése).

Gyorsított hálózatkezelés nélkül előfordulhat, hogy az Azure-beli virtuális gép és más Azure-erőforrások között áthaladó IO szükségtelenül a virtuális gép és a hálózati kártya között található gazdagépen és virtuális kapcsolón halad át. Miután a gazdagép és a virtuális kapcsoló beágyazott a datapathban, nem csak növeli a késést és a kommunikáció csatornán belüli jittert, hanem a processzorciklusokat is ellopja a virtuális gépről. A gyorsított hálózatkezeléssel a virtuális gép közvetlenül a hálózati adapterhez kapcsolódik közvetítők nélkül; a gazdagép és a virtuális kapcsoló által kezelt hálózati házirendek adatait a hálózati adapter hardverei kezelik; a gazdagép és a virtuális kapcsoló megkerülése. A gyorsított hálózatkezelés engedélyezésekor általában alacsonyabb késésre és nagyobb átviteli sebességre, valamint konzisztensebb késésre és csökkentett processzorhasználatra számíthat.

Korlátozások: A gyorsított hálózatkezelést támogatni kell a virtuálisgép-operációs rendszeren, és csak akkor lehet engedélyezni, ha a virtuális gép leállt és felszabadítva van. A virtuális gép nem telepíthető az Azure Resource Managerrel. Az App Service-ben nincs engedélyezve gyorsított hálózat.

További részletekért tekintse meg a Windows és a Linux utasításait.

SDK-használat

  • A legújabb SDK telepítése

Az Azure Cosmos DB SDK-k folyamatosan fejlődnek a legjobb teljesítmény érdekében. Tekintse meg az Azure Cosmos DB SDK kibocsátási megjegyzéseit a legújabb SDK meghatározásához és a fejlesztések áttekintéséhez.

  • Egyetlen azure Cosmos DB-ügyfél használata az alkalmazás teljes élettartama alatt

Minden Azure Cosmos DB-ügyfélpéldány szálbiztos, és hatékony kapcsolatkezelést és -cím-gyorsítótárazást végez. Az Azure Cosmos DB-ügyfél hatékony kapcsolatkezelésének és jobb teljesítményének lehetővé tétele érdekében ajánlott az Azure Cosmos DB-ügyfél egyetlen példányát használni az alkalmazás teljes élettartama alatt.

  • Időtúllépési és újrapróbálkozások konfigurációinak finomhangolása

Az időtúllépési konfigurációk és az újrapróbálkoztatási szabályzatok az alkalmazás igényei szerint testre szabhatók. A testre szabható konfigurációk teljes listájának lekéréséhez tekintse meg az időtúllépést, és próbálkozzon újra a konfigurációs dokumentumokkal.

  • Az alkalmazáshoz szükséges legalacsonyabb konzisztenciaszint használata

CosmosClient létrehozásakor a fiókszintű konzisztenciát használja a rendszer, ha nincs megadva az ügyféllétrehozásban. A konzisztenciaszintekkel kapcsolatos további információkért tekintse meg a konzisztenciaszintek dokumentumát.

  • Az ügyfél-számítási feladatok vertikális felskálázása

Ha magas átviteli sebességen tesztel, az ügyfélalkalmazás szűk keresztmetszetté válhat a processzor- vagy hálózatkihasználtság miatt. Ha eléri ezt a pontot, folytathatja az Azure Cosmos DB-fiók további leküldését az ügyfélalkalmazások több kiszolgálón való skálázásával.

A jó hüvelykujjszabály az, hogy egy adott kiszolgálón ne lépje túl >az 50%-os processzorhasználatot, hogy a késés alacsony maradjon.

  • Operációs rendszer – Fájlok erőforráskorlátja

Egyes Linux-rendszerek (például a Red Hat) felső határt szabnak a megnyitott fájlok számának, így a kapcsolatok teljes számának. Futtassa a következőt az aktuális korlátok megtekintéséhez:

ulimit -a

A megnyitott fájlok (nofile) számának elég nagynak kell lennie ahhoz, hogy elegendő hely legyen a konfigurált kapcsolatkészlet méretéhez és az operációs rendszer által megnyitott egyéb fájlokhoz. Módosítható, hogy nagyobb kapcsolatkészletméretet biztosíthasson.

Nyissa meg a limits.conf fájlt:

vim /etc/security/limits.conf

Adja hozzá/módosítsa a következő sorokat:

* - nofile 100000

Lekérdezési műveletek

A lekérdezési műveletekhez tekintse meg a lekérdezések teljesítményére vonatkozó tippeket.

Indexelési szabályzat

  • Nem használt útvonalak kizárása az indexelésből a gyorsabb írás érdekében

Az Azure Cosmos DB indexelési szabályzata lehetővé teszi, hogy az indexelési útvonalak (setIncludedPaths és setExcludedPaths) használatával megadhatja, hogy mely dokumentumelérési utakat vegye fel vagy zárja ki az indexelésből. Az indexelési útvonalak használata jobb írási teljesítményt és alacsonyabb indextárolást kínálhat azokhoz a forgatókönyvekhez, amelyekben a lekérdezési minták előre ismertek, mivel az indexelési költségek közvetlenül korrelálnak az indexelt egyedi útvonalak számával. Az alábbi kód például azt mutatja be, hogyan lehet a dokumentumok teljes szakaszait (más néven részösszeget) belefoglalni és kizárni az indexelésből a "*" helyettesítő karakterrel.

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"))

További információ: Azure Cosmos DB indexelési szabályzatok.

Átfutás

  • Kisebb kérelemegységek/másodperces használat mérése és finomhangolása

Az Azure Cosmos DB számos adatbázisműveletet kínál, beleértve a relációs és hierarchikus lekérdezéseket az UDF-ekkel, a tárolt eljárásokat és az eseményindítókat – mind az adatbázis-gyűjtemény dokumentumain. Az egyes ilyen műveletekhez kapcsolódó költségek a művelet végrehajtásához szükséges CPU, IO és memória függvényében változnak. A hardvererőforrások átgondolása és kezelése helyett egyetlen mértékként tekinthet a kérelemegységre (RU) a különböző adatbázis-műveletek végrehajtásához és az alkalmazáskérelmek kiszolgálásához szükséges erőforrásokhoz.

Az átviteli sebesség az egyes tárolókhoz beállított kérelemegységek száma alapján van kiépítve. A kérelemegység-felhasználás másodpercenkénti sebességként lesz kiértékelve. A tárolóhoz kiosztott kérelemegység-mértéket meghaladó alkalmazások korlátozottak, amíg a sebesség nem csökken a tárolóhoz kiosztott szint alá. Ha az alkalmazás magasabb átviteli sebességet igényel, további kérelemegységek kiépítésével növelheti az átviteli sebességet.

A lekérdezések összetettsége hatással van arra, hogy egy művelet hány kérelemegységet használ fel. A predikátumok száma, a predikátumok jellege, az UDF-ek száma és a forrásadatkészlet mérete mind befolyásolják a lekérdezési műveletek költségeit.

Bármely művelet (létrehozás, frissítés vagy törlés) többletterhelésének méréséhez vizsgálja meg az x-ms-request-charge fejlécet a műveletek által felhasznált kérelemegységek számának méréséhez.

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'])

Az ebben a fejlécben visszaadott kérelemdíj a kiosztott átviteli sebesség töredékét adja. Ha például 2000 RU/s van kiépítve, és ha az előző lekérdezés 1000 1 KB-dokumentumot ad vissza, a művelet költsége 1000. Így egy másodpercen belül a kiszolgáló csak két ilyen kérést tart tiszteletben, mielőtt a sebesség korlátozza a későbbi kéréseket. További információ: Kérelemegységek és a kérelemegység-kalkulátor.

  • Túl nagy sebességkorlátozás/kérési sebesség kezelése

Amikor egy ügyfél megkísérli túllépni egy fiók fenntartott átviteli sebességét, a kiszolgálón nincs teljesítménycsökkenés, és az átviteli kapacitás használata nem lépi túl a fenntartott szintet. A kiszolgáló előzetesen a RequestRateTooLarge (HTTP-állapotkód: 429) paranccsal fejezi be a kérést, és visszaadja az x-ms-retry-after-ms fejlécet, amely azt jelzi, hogy a felhasználónak ezredmásodpercben mennyi időt kell várnia a kérés újbóli megismétlése előtt.

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

Az SDK-k implicit módon elkapják ezt a választ, tiszteletben tartják a kiszolgáló által megadott újrapróbálkozási fejlécet, és újrapróbálkoznak a kéréssel. Ha a fiókját nem éri el egyszerre több ügyfél, a következő újrapróbálkozás sikeres lesz.

Ha több ügyfél kumulatív működése következetesen meghaladja a kérések arányát, előfordulhat, hogy az ügyfél által jelenleg 9-re beállított alapértelmezett újrapróbálkozási szám nem elegendő; ebben az esetben az ügyfél egy CosmosHttpResponseError 429-ás állapotkódot ad az alkalmazásnak. Az alapértelmezett újrapróbálkozási szám módosítható úgy, hogy átadja a konfigurációt retry_total az ügyfélnek. Alapértelmezés szerint a 429-es állapotkódú CosmosHttpResponseError 30 másodperces kumulatív várakozási idő után lesz visszaadva, ha a kérés továbbra is a kérési sebesség felett működik. Ez akkor is előfordul, ha az újrapróbálkozások aktuális száma kisebb, mint a maximális újrapróbálkozások száma, legyen az alapértelmezett érték 9 vagy felhasználó által megadott érték.

Bár az automatikus újrapróbálkozási viselkedés segít javítani a rugalmasságot és a használhatóságot a legtöbb alkalmazás esetében, a teljesítménymutatók használatakor előfordulhat, különösen a késés mérése során. Az ügyfél által megfigyelt késés megnő, ha a kísérlet eléri a kiszolgálót, és az ügyfél SDK-jának csendes újrapróbálkozását okozza. A teljesítménykísérletek során fellépő késési csúcsok elkerülése érdekében mérje meg az egyes műveletek által visszaadott díjat, és győződjön meg arról, hogy a kérések a fenntartott kérések aránya alatt működnek. További információ: Kérelemegységek.

  • Kisebb dokumentumok tervezése a nagyobb átviteli sebesség érdekében

Egy adott művelet kérelemdíja (a kérelem feldolgozási költsége) közvetlenül korrelál a dokumentum méretével. A nagyméretű dokumentumokon végzett műveletek többe kerülnek, mint a kis méretű dokumentumok műveletei. Ideális esetben úgy kell létrehoznia az alkalmazást és a munkafolyamatokat, hogy az elem mérete ~1 KB legyen, vagy hasonló sorrendben vagy nagyságrendben. A késésre érzékeny alkalmazások esetében kerülni kell a nagyméretű elemeket – a több MB-os dokumentumok lelassítják az alkalmazást.

Következő lépések

Ha többet szeretne megtudni az alkalmazás méretezéshez és nagy teljesítményhez való tervezéséről, tekintse meg a particionálást és a skálázást az Azure Cosmos DB-ben.

Kapacitástervezést szeretne végezni az Azure Cosmos DB-be való migráláshoz? A kapacitástervezéshez használhatja a meglévő adatbázisfürt adatait.