Teljesítménytippek az Azure Cosmos DB Sync Java SDK v2-hez

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Fontos

Nem ez a legújabb Java SDK az Azure Cosmos DB-hez! Frissítse a projektet az Azure Cosmos DB Java SDK v4-re , majd olvassa el az Azure Cosmos DB Java SDK v4 teljesítménytippek útmutatóját. A frissítéshez kövesse a Migrate to Azure Cosmos DB Java SDK v4 útmutatójában és a Reactor vs RxJava útmutatóban található utasításokat.

Ezek a teljesítménytippek csak az Azure Cosmos DB Sync Java SDK v2-hez használhatók. További információért tekintse meg a Maven-adattárat .

Fontos

2024. február 29-én megszűnik az Azure Cosmos DB Sync Java SDK v2.x; az SDK és az SDK-t használó összes alkalmazás továbbra is működni fog; Az Azure Cosmos DB egyszerűen nem nyújt további karbantartást és támogatást ehhez az SDK-hoz. Javasoljuk, hogy kövesse a fenti utasításokat az Azure Cosmos DB Java SDK v4-be való migráláshoz.

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 ugyanolyan egyszerű, mint egyetlen API-hívás. További információkért tekintse meg a tároló átviteli sebességének kiépítését vagy az adatbázis átviteli sebességének kiépítését. 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 Sync Java SDK v2 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

  1. Csatlakozás ion mód: A DirectHttps használata

    Az ügyfél Azure Cosmos DB-hez való csatlakozásának módja jelentősen befolyásolja a teljesítményt, főként a megfigyelt ügyféloldali késés szempontjából. Az ügyfél Csatlakozás ionPolicy – a Csatlakozás ionMode – konfigurálásához egy kulcskonfigurációs beállítás érhető el. A két elérhető Csatlakozás ionModes a következő:

    1. Átjáró (alapértelmezett)

    2. DirectHttps

      Az átjáró mód minden SDK-platformon támogatott, és ez a konfigurált alapértelmezett mód. Ha az alkalmazás szigorú tűzfalkorlátozásokkal rendelkező vállalati hálózaton fut, az Átjáró a legjobb választás, mivel a szabványos HTTPS-portot és egyetlen végpontot használja. A teljesítménybeli kompromisszum azonban az, hogy az átjáró mód további hálózati ugrást foglal magában minden alkalommal, amikor az adatok beolvasása vagy írása az Azure Cosmos DB-be történik. Emiatt a DirectHttps mód jobb teljesítményt nyújt a kevesebb hálózati ugrás miatt.

      Az Azure Cosmos DB Sync Java SDK v2 https protokollt használ átviteli protokollként. A HTTPS TLS-t használ a kezdeti hitelesítéshez és a forgalom titkosításához. Az Azure Cosmos DB Sync Java SDK v2 használatakor csak a 443-at használó HTTPS-portot kell megnyitni.

      A Csatlakozás ionMode a DocumentClient-példány felépítése során van konfigurálva a Csatlakozás ionPolicy paraméterrel.

    Java SDK V2 szinkronizálása (Maven com.microsoft.azure::azure-documentdb)

    public ConnectionPolicy getConnectionPolicy() {
  ConnectionPolicy policy = new ConnectionPolicy();
  policy.setConnectionMode(ConnectionMode.DirectHttps);
  policy.setMaxPoolSize(1000);
  return policy;
}

ConnectionPolicy connectionPolicy = new ConnectionPolicy();
DocumentClient client = new DocumentClient(HOST, MASTER_KEY, connectionPolicy, null);

    A diagram az Azure Cosmos DB kapcsolati szabályzatát mutatja be.

  2. Ü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 ábra két régió kéréseit és válaszait mutatja be, ahol a számítógépek középszintű szolgáltatásokon keresztül csatlakoznak egy Azure Cosmos DB-fiókhoz.

SDK-használat

  1. A legújabb SDK telepítése

    Az Azure Cosmos DB SDK-k folyamatosan fejlődnek a legjobb teljesítmény érdekében. A legújabb SDK-fejlesztések meghatározásához látogasson el az Azure Cosmos DB SDK-ba.

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

    Minden DocumentClient-példány szálbiztos, és hatékony kapcsolatkezelést és cím gyorsítótárazást végez a Közvetlen módban való működés során. Annak érdekében, hogy a DocumentClient hatékony kapcsolatkezelést és jobb teljesítményt biztosíthasson, javasoljuk, hogy appDomain-enként egyetlen DocumentClient-példányt használjon az alkalmazás teljes élettartama alatt.

  3. A MaxPoolSize növelése gazdagépenként átjáró mód használatakor

    Az Azure Cosmos DB-kérések HTTPS/REST protokollon keresztül jönnek létre az Átjáró mód használatakor, és az alapértelmezett kapcsolati korlát vonatkozik gazdanévre vagy IP-címre. Előfordulhat, hogy a MaxPoolSize értékét magasabb értékre (200–1000) kell beállítania, hogy az ügyfélkódtár több egyidejű kapcsolatot használjon az Azure Cosmos DB-hez. Az Azure Cosmos DB Sync Java SDK v2-ben a Csatlakozás ionPolicy.getMaxPoolSize alapértelmezett értéke 100. Az érték módosításához használja a setMaxPoolSize függvényt.

  4. Párhuzamos lekérdezések hangolása particionált gyűjteményekhez

    Az Azure Cosmos DB Sync Java SDK 1.9.0-s és újabb verziója támogatja a párhuzamos lekérdezéseket, amelyek lehetővé teszik a particionált gyűjtemény párhuzamos lekérdezését. További információt az SDK-k használatához kapcsolódó kódmintákban talál. A párhuzamos lekérdezések célja, hogy javítsák a lekérdezések késését és átviteli sebességét a soros megfelelőjükkel szemben.

    (a) Tuning setMaxDegreeOfParallelism: A párhuzamos lekérdezések több partíció párhuzamos lekérdezésével működnek. Az egyes particionált gyűjteményekből származó adatokat azonban a rendszer a lekérdezés szempontjából sorosan olvassa be. Ezért a setMaxDegreeOfParallelism használatával állítsa be azoknak a partícióknak a számát, amelyek a legnagyobb eséllyel érik el a legkiteljesítőbb lekérdezést, feltéve, hogy az összes többi rendszerfeltétel változatlan marad. Ha nem tudja a partíciók számát, a setMaxDegreeOfParallelism használatával beállíthatja a magas számot, és a rendszer a minimális (partíciók száma, felhasználó által megadott bemenet) értéket választja a párhuzamosság maximális fokaként.

    Fontos megjegyezni, hogy a párhuzamos lekérdezések akkor biztosítják a legjobb előnyöket, ha az adatok egyenletesen oszlanak el az összes partíció között a lekérdezés szempontjából. Ha a particionált gyűjteményt úgy particionálják, hogy a lekérdezés által visszaadott adatok teljes vagy nagy része néhány partícióban (legrosszabb esetben egy partícióban) koncentrálódik, akkor a lekérdezés teljesítményét szűk keresztmetszetet képeznének ezek a partíciók.

    (b) Tuning setMaxBufferedItemCount: A párhuzamos lekérdezés úgy van kialakítva, hogy előre leküldje az eredményeket, miközben az ügyfél feldolgozza az aktuális eredményköteget. Az előkezelés segít a lekérdezések késésének általános javításában. a setMaxBufferedItemCount korlátozza az előre megadott eredmények számát. Ha beállítja aMaxBufferedItemCount értéket a visszaadott eredmények várt számára (vagy magasabb számra), ez lehetővé teszi a lekérdezés számára, hogy maximális előnyt kapjon az előkezelésből.

    Az előtelepítés ugyanúgy működik, függetlenül a MaxDegreeOfParallelizmustól, és az összes partíció adatainak egyetlen puffere van.

  5. Backoff implementálása getRetryAfterInMilliseconds időközönként

    A teljesítménytesztelés során növelnie kell a terhelést, amíg a kérések kis száma nem lesz szabályozva. Ha szabályozva van, az ügyfélalkalmazásnak vissza kell kapcsolnia a szabályozást a kiszolgáló által megadott újrapróbálkozási időközhöz. A visszalépés tiszteletben tartása biztosítja, hogy minimális időt töltsön várakozással az újrapróbálkozások között. Az újrapróbálkozások szabályzattámogatása az Azure Cosmos DB Sync Java SDK 1.8.0-s és újabb verziójában érhető el. További információ: getRetryAfterInMilliseconds.

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

    Ha magas átviteli sebességen (>50 000 RU/s) tesztel, az ügyfélalkalmazás szűk keresztmetszetté válhat, mivel a gép túllépi a processzor- vagy hálózati kihasználtságot. 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.

  7. Névalapú címzés használata

    Használjon névalapú címzést, ahol a hivatkozások formátuma dbs/MyDatabaseId/colls/MyCollectionId/docs/MyDocumentIda SelfLinks (_self) helyett, amelyek formátuma dbs/<database_rid>/colls/<collection_rid>/docs/<document_rid> lehetővé teszi a hivatkozás létrehozásához használt összes erőforrás ResourceId-azonosítóinak lekérését. Emellett, mivel ezek az erőforrások újra létrejönnek (valószínűleg ugyanazzal a névvel), ezek gyorsítótárazása nem feltétlenül segít.

  8. A lekérdezések/olvasási hírcsatornák oldalméretének finomhangolása a jobb teljesítmény érdekében

    Ha a dokumentumok tömeges olvasását olvasási csatornával (például readDocuments) vagy SQL-lekérdezés kiadásakor hajtja végre, a rendszer szegmentált módon adja vissza az eredményeket, ha az eredményhalmaz túl nagy. Alapértelmezés szerint a rendszer 100 elemből vagy 1 MB-ból álló adattömbökben adja vissza az eredményeket, attól függően, hogy melyik korlátot éri el először a rendszer.

    Az összes vonatkozó eredmény lekéréséhez szükséges hálózati kerek utak számának csökkentése érdekében az x-ms-max-item-count kérelem fejlécével akár 1000-ra is növelheti az oldalméretet. Azokban az esetekben, amikor csak néhány eredményt kell megjelenítenie, például ha a felhasználói felület vagy az application API csak 10 találatot ad vissza egyszerre, az oldalméretet 10-re is csökkentheti az olvasások és lekérdezések által felhasznált átviteli sebesség csökkentése érdekében.

    Az oldalméretet a setPageSize metódussal is beállíthatja.

Indexelési szabályzat

  1. 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 megszűrje, 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 bemutatja, hogyan zárhatja ki a dokumentumok teljes szakaszát (alszakaszát) az indexelésből a "*" helyettesítő karakterrel.

    Java SDK V2 szinkronizálása (Maven com.microsoft.azure::azure-documentdb)

    Index numberIndex = Index.Range(DataType.Number);
numberIndex.set("precision", -1);
indexes.add(numberIndex);
includedPath.setIndexes(indexes);
includedPaths.add(includedPath);
indexingPolicy.setIncludedPaths(includedPaths);
collectionDefinition.setIndexingPolicy(indexingPolicy);

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

Átfutás

  1. 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 (vagy a ResourceResponse<T> vagy a FeedResponse T> megfelelő RequestCharge tulajdonságát <a műveletek által felhasznált kérelemegységek számának méréséhez.

    Java SDK V2 szinkronizálása (Maven com.microsoft.azure::azure-documentdb)

    ResourceResponse<Document> response = client.createDocument(collectionLink, documentDefinition, null, false);

response.getRequestCharge();

    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.

  2. 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 belsőleg jelenleg 9-re beállított alapértelmezett újrapróbálkozási szám nem elegendő; ebben az esetben az ügyfél egy DocumentClientException 429-as állapotkódot ad az alkalmazásnak. Az alapértelmezett újrapróbálkozási szám a setRetryOptions használatával módosítható a Csatlakozás ionPolicy-példányon. Alapértelmezés szerint a 429-es állapotkódú DocumentClientException 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.

  3. 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.

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.