Azure DocumentDB – Teljesítmény optimalizálási tippek 1. 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.

A következőkben néhány egyszerű, de 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 első részében hatékony indexelésről, valamint a lekérdezésekkel járó költségekről gyűjtöttünk össze érdekes tudnivalókat.

 

Indexelési szabályok

#1: Használj lazy indexelést a gyorsabb, csúcsidőben történő elérés érdekében
A DocumentDB beállításain keresztül lehetőségünk van rá, hogy – akár gyűjtemények szintjén – dokumentumaink automatikus indexelését engedélyezzük, vagy letiltsuk. Ezen felül az indexelési mód meghatározására is van módunk: választhatunk a szinkron (konzisztens) és az aszinkron (lazy) indexelés között. Alapértelmezetten az index frissítése szinkron módon történik, minden egyes új sor létrehozásakor, módosításakor, valamint törlésekor. Ezáltal a lekérdezések futtatásakor konzisztens élményt kapunk, a dokumentumok beolvasása késedelem nélkül megtörténik.

A  lazy indexelést olyan esetekben használhatjuk hatékonyan, amikor az adatok hullámokban, nagy mennyiségben kerülnek írásra és az indexeléssel járó terhelést hosszabb időtartamra kinyújtva akarjuk elosztani. Így akár csúcsidőben is problémamentesen kiszolgálhatjuk a lekéréseket. Fontos megjegyeznünk, hogy bármelyik megoldást is választjuk, végeredményben ugyanazt a sebességet fogjuk elérni, a különbség az indexelés folyamán nyilvánul meg.

 

#2: Ne indexeljük a ritkán használt könyvtárakat
Az indexelési szabályok között definiálhatjuk, hogy mely mappákat vonjuk be, vagy hagyjuk ki az indexelési folyamat során. A ritkán használt könyvtárak kihagyásával terhet veszünk le a rendszer válláról, gyorsítjuk az indexelési folyamatokat és elősegítjük a konzisztens élmény kialakítását.

 

#3: Az tartomány alapú indexelést csak ott engedélyezzük, ahol szükséges
A DocumentDB jelenleg két index útvonal típust használ: Hash és Range. A Hash indexelés az egyenlőségvizsgálatoknál ad hatékony eredményeket, míg a relációs vizsgálatoknál (pl.: >, <, >=, <=) a Range indexelés a jobb választás.

 

Lekérdezési költségek

#1: Mérd és szorítsd minimálisra a lekérdezési egységeket másodpercenként
A DocumentDB adatbázis műveletek széles skáláját kínálja, beleértve a relációs és hierarchikus lekérdezéseket felhasználó által létrehozott függvényekkel együtt (UDF), tárolt procedúrákat és triggereket – mindezek az adatbázis kollekcióiban tárolt dokumentumokon alkalmazhatók. A felsorolt műveletek költsége változó, a CPU, IO és memória igény alapján kerül meghatározásra. Azonban ahelyett, hogy a felhasználónak hardverben kellene gondolkodnia, bevezetésre került a lekérdezési egység (Request Unit, RU) fogalma, mellyel pontosan mérhető a fogyasztás.

A maximálisan felhasználható lekérdezési egység adatbázis fiókonként adható meg, lekérdezési egység/másodperc mértékegységben. Ennek a korlátnak a túllépése esetén a fiók feldolgozási sebessége korlátozásra kerül,  amíg a terhelés vissza nem csökken a megadott szint alá. Természetesen a kvóta a későbbiekben, szükség esetén növelhető.

Egy lekérdezés költségét egyszerűen kiolvashatjuk az x-ms-request-charge header-ből, .NET SDK esetében pedig  a válasz RequestCharge változóján keresztül.

 

#2: Túl nagy költségű lekérdezések kezelése
Ha egy kliens olyan lekérdezést futtatna a szerveren, mely a pillanatnyilag szabadon elérhető korlátot meghaladja, a szolgáltatás egy ReqeustRateTooLarge (HTTP státusz kód: 429) elutasítja, majd a fejlécben egy x-ms-retry-after-ms értéket visszaküldve a megadott időtartamig váratja a felhasználót az újrapróbálkozással.

A .NET Kliens SDK és LINQ lekérdezések használata esetén legtöbb esetben nem kell foglalkozunk ezzel a kivétellel, mivel az SDK jelenlegi verziója automatikusan kezeli ezt az esetet és a megadott idő után újra próbálkozik a lekérdezéssel.

A lekérdezés alapértelmezetten háromszor próbálkozik újra, végül DocumentClientException kivétellel tér vissza, 429-es státusz kóddal. (A jelenlegi .NET SDK-ban nincs lehetőség az alapértelmezett ismétlési szám módosítására)

 

#3: Dolgozz kis méretű dokumentumokkal
A lekérdezések költsége függ a dokumentumok méretétől. Nagyobb méretű dokumentumok esetén a műveletek költsége is növekszik.

 

Cikkünk második részében a hálózati teljesítmény növelésével, valamint az SDK használatával kapcsolatban osztunk meg hasznos tudnivalókat.

Szólj hozzá!

komment