Azure DocumentDB – Teljesítmény optimalizálási tippek 2. rész

Mi is az Azure DocumentDB?

Az Azure dokumentum-adatbázis egy teljes körűen felügyelt, jól méretezhető, dokumentumok tárolására szolgáló NoSQL adatbázisszolgáltatás, melynek segítségével kis késésű, rugalmas lekérdezési lehetőségeket biztosító web-, valamint mobilalkalmazásokat hozhatunk létre.

Első részünk folytatásaként újabb hasznos tanácsot osztunk meg olvasóinkkal, miként érhetnek el optimálisabb teljesítményt a szolgáltatás finomhangolásával. Cikkünk második részében a hálózati teljesítmény növelésében, valamint az SDK használatában osztunk meg tippeket.

 

Hálózati megoldások

#1: Direkt kapcsolódás a jobb teljesítmény érdekében
A hálózati teljesítmény optimalizálását a kapcsolódás módjánál érdemes megkezdenünk! Az Azure DocumentDB alapvetően két kapcsolódási módot különböztet meg:

  • Gateway (Alapértelmezett)
  • Közvetlen

A DocumentDB egy elosztott tároló rendszer, gyűjteményeink és dokumentumaink különböző partíciókon foglalnak helyet. Az állományok fizikai címét egy segédtáblában menti el a rendszer, azok lekérdezésekor ennek segítségével irányít minket a DocumentDB az erőforrásokhoz.

Alapértelmezetten a Gateway mód alkalmazásával egy központi útválasztó lép kapcsolatba ezzel a létrehozott segédtáblával és keresi meg nekünk az átadott hivatkozás mögött eltárolt állományt.  Ez a megoldás részünkről nem igényel extra munkát, az útválasztás automatikusan történik, hátránya azonban, hogy a lekérdezés először egy útválasztón megy keresztül, mely egy kisebb késleltetést ad az adat eléréséhez. Közvetlen kapcsolódás esetén ez a plusz ugrás kiiktatható, ebben az esetben azonban magunknak kell biztosítanunk a kliensek számára az útválasztást, mi irányítjuk el őket az állományokhoz.

A Gateway móddal szemben a közvetlen kapcsolódási lehetőség csak a .NET SDK-n belül érhető el, implementálása a többi fejlesztőkészletben a későbbiekben várható.

A kliensek kapcsolódási módjairól a következő linken olvashat!

 

#2: Használjunk TCP protokollt, ha lehet
Amennyiben az előző pontban a közvetlen kapcsolódást választottuk, lehetőségünk nyílik a protokoll megválasztására is: TCP, vagy HTTPS.

Az Azure DocumentDB REST alapú kommunikáció lehetőségét biztosítja HTTPS és TCP kapcsolaton egyaránt, utóbbi azonban jobb teljesítményt biztosít – azonban ezt csak közvetlen kapcsolódás esetén használhatjuk, Gateway módban történő működés során nem.

A kapcsolódás módját a DocumentClient példányosításakor adhatjuk meg a ConnectionPolicy paraméter módosításával. Figyeljünk arra, hogy a kapcsolódás módját ConnectionMode.Direct értékre állítsuk be!

var serviceEndpoint = new Uri("https://contoso.documents.net");
var authKey = new "your authKey from Azure Mngt Portal";

DocumentClient client = new DocumentClient(serviceEndpoint, authKey,
    new ConnectionPolicy
    {

        ConnectionMode = ConnectionMode.Direct,
        ConnectionProtocol = Protocol.Tcp

    });

 

#3: Aszinkron hívással indítsunk, megelőzvén az induláskori megakadást
A legelső hívás nagyobb terhelést jelent az adatok lekérdezésekor, mivel ilyenkor kell beolvasnunk az irányító segédtábla tartalmát. Hogy az (esetlegesen) ezzel járó akadást megelőzzük, bízzuk a kérést egy aszinkron hívásra és futtassuk azt a háttérben.

await client.OpenAsync();

 

#4: Tartsuk adatainkat minél közelebb a kliensekhez
A kérésekre adott válaszok sebessége kérésről-kérésre változhat, annak függvényében, hogy a lekérdezés milyen hosszú útvonalon jut el az adatközponthoz és vissza. Igyekezzünk klienseink számára a lehető legközelebbi adatközpontban tárolni állományainkat, hogy a lehető legalacsonyabb válaszidővel érjék el az adatokat.

DeploymentConsiderations

 

SDK tippek

#1: Egyetlen DocumentDB klienst példányosítsunk alkalmazásunk futási ideje során
A hatékony kapcsolatkezelés és jobb teljesítmény elérése érdekében ajánlott egyetlen DocumentClient objektumot példányosítanunk alkalmazásunk futásra során.

 

#2: Helyezzük gyorsítótárba a dokumentumok és gyűjtemények SelfLinkjeit a válaszidő csökkentésédre
Az Azure DocumentDB minden egyes dokumentumunkhoz és gyűjteményünkhöz rendel egy SelfLink-et, melyek garantáltan egyéniek és sosem változnak az állomány élettartama során. A SelfLink használatával juthatunk el leghatékonyabban dokumentumainkhoz, a lehető legjobb olvasási teljesítményt elérve.

Példakód egy dokumentum SelfLinkkel történő olvasására:

Document document = await client.ReadDocumentAsync("/dbs/1234/colls/1234354/docs/2332435465");

 

Előfordulhat, hogy bizonyos esetekben a SelfLink nem lesz használható számunkra alkalmazásunkban, ilyenkor érdemes a dokumentumok azonosítója (Id) alapján folytatni a kereséseket.

 

#3: Finomhangoljuk a lekérdezések/olvasások által visszaadott adathalmazok méretét
Adatok lekérdezésekor használhatjuk a ReadDocumentFeedAsync parancsot, mely szegmentált formában ad vissza eredményeket, ha az eredményhalmaz túl nagy. Alapértelmezetten 100 elem, vagy 1 MB után történik a vágás és jön létre egy újabb szegmens.

Tökéletes érték erre nem létezik, alkalmazásonként más és más. Ha például csupán kevés adatot jelenítenénk meg egyszerre, akár 10-re is csökkenthetjük az értéket, más esetben azonban egészen 1000-ig is növelhetjük. A visszatérő elemek számát a lekérdezés fejlécében az x-ms-max-item-count paraméter értékeként adhatjuk át.

A lekérdezés fejléce mellett a DocumentDB SDK-n keresztül a lekérdezés megírásakor is megadhatjuk akár:

IQueryable<dynamic> authorResults =

client.CreateDocumentQuery(documentCollection.SelfLink, 
    "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'",
    new FeedOptions { MaxItemCount = 1000 });

 

 

Cikkünk első része a hatékony indexelésről, valamint a lekérdezésekkel járó költségekről gyűjt össze hasznos tanácsokat, melyet szintén érdemes elolvasni! Kétrészes cikksorozatunk végéhez értünk, reméljük hasznos tanácsokat sikerült megosztanunk olvasóinkkal!

 

Szólj hozzá!

komment