A Table Storage teljesítmény- és méretezhetőségi ellenőrzőlistája
A Microsoft számos bevált eljárást dolgozott ki a nagy teljesítményű alkalmazások Table Storage-beli fejlesztéséhez. Ez az ellenőrzőlista a fejlesztők által a teljesítmény optimalizálásához követhető főbb eljárásokat azonosítja. Tartsa szem előtt ezeket a gyakorlatokat az alkalmazás tervezésekor és a folyamat során.
Az Azure Storage méretezhetőségi és teljesítménycélokkal rendelkezik a kapacitás, a tranzakciós sebesség és a sávszélesség tekintetében. Az Azure Storage skálázhatósági céljairól további információt a standard tárfiókok méretezhetőségi és teljesítménycéljai, valamint a Table Storage méretezhetőségi és teljesítménycéljai című témakörben talál.
Checklist
Ez a cikk a table storage-alkalmazás fejlesztése során követhető ellenőrzőlistába rendezi a teljesítmény bevált eljárásait.
Méretezhetőségi célok
Ha az alkalmazás megközelíti vagy túllépi a méretezhetőségi célok bármelyikét, előfordulhat, hogy a tranzakció késése vagy szabályozása megnő. Amikor az Azure Storage szabályozza az alkalmazást, a szolgáltatás 503 (kiszolgáló foglalt) vagy 500 (művelet időtúllépése) hibakódokat ad vissza. Ezeknek a hibáknak a skálázhatósági célok korlátain belüli elkerülése fontos része az alkalmazás teljesítményének növelésének.
A Table service méretezhetőségi céljairól további információt a Table Storage méretezhetőségi és teljesítménycéljai című témakörben talál.
Tárfiókok maximális száma
Ha egy adott előfizetés/régió kombinációhoz engedélyezett tárfiókok maximális számát közelíti meg, akkor több tárfiókot használ szegmensekre a bejövő, kimenő, I/O-műveletek másodpercenkénti (IOPS) vagy kapacitás növeléséhez? Ebben a forgatókönyvben a Microsoft azt javasolja, hogy használja ki a tárfiókok megnövekedett korlátait, hogy lehetőség szerint csökkentse a számítási feladathoz szükséges tárfiókok számát. Lépjen kapcsolatba az Azure ügyfélszolgálatával , és kérje a tárfiókra vonatkozó megnövekedett korlátokat.
Kapacitás- és tranzakciós célok
Ha az alkalmazás egy tárfiók méretezhetőségi céljaihoz közelít, fontolja meg az alábbi módszerek egyikének alkalmazását:
- Gondolja át azt a számítási feladatot, amely miatt az alkalmazás megközelíti vagy túllépi a méretezhetőségi célt. Meg tudja másképp tervezni, hogy kevesebb sávszélességet vagy kapacitást használjon, vagy kevesebb tranzakciót használjon?
- Ha az alkalmazásnak meg kell haladnia az egyik méretezhetőségi célt, hozzon létre több tárfiókot, és particionálja az alkalmazás adatait a több tárfiók között. Ha ezt a mintát használja, ügyeljen arra, hogy az alkalmazást úgy tervezzen meg, hogy a jövőben további tárfiókokat lehessen hozzáadni a terheléselosztáshoz. Maguk a tárfiókok a tárolt adatok, a tranzakciók vagy az átvitt adatok használatán kívül más költségekkel sem járnak.
- Ha az alkalmazás megközelíti a sávszélesség-célokat, fontolja meg az adatok ügyféloldali tömörítését az adatok Azure Storage-ba való küldéséhez szükséges sávszélesség csökkentése érdekében. Bár az adatok tömörítése sávszélességet takaríthat meg, és javíthatja a hálózati teljesítményt, negatív hatással lehet a teljesítményre is. Értékelje ki az ügyféloldali adattömörítésre és dekompresszióra vonatkozó további feldolgozási követelmények teljesítményre gyakorolt hatását. Ne feledje, hogy a tömörített adatok tárolása megnehezítheti a hibaelhárítást, mert a standard eszközökkel nehezebb lehet megtekinteni az adatokat.
- Ha az alkalmazás megközelíti a méretezhetőségi célokat, győződjön meg arról, hogy exponenciális visszalépést használ az újrapróbálkozáshoz. A legjobb, ha megpróbálja elkerülni a méretezhetőségi célok elérését a cikkben ismertetett javaslatok végrehajtásával. Ha azonban exponenciális visszalépést használ az újrapróbálkozáshoz, az megakadályozza az alkalmazás gyors újrapróbálkozását, ami tovább ronthatja a szabályozást. További információ: Időtúllépési és kiszolgálói foglaltsági hibák.
Adatműveletek céljai
Az Azure Storage terhelése a tárfiók felé történő forgalom növekedésével egyensúlyban van, de ha a forgalom hirtelen kipukkan, előfordulhat, hogy nem tudja azonnal lekérni ezt az átviteli sebességet. A kipukkadás során szabályozási és/vagy időtúllépések várhatók, mivel az Azure Storage automatikusan kiegyensúlyozza a táblát. A lassú felfutás általában jobb eredményeket biztosít, mivel a rendszernek van ideje a megfelelő terheléselosztásra.
Entitások másodpercenként (tárfiók)
A táblák elérésének méretezhetőségi korlátja legfeljebb 20 000 entitás (egyenként 1 KB) másodpercenként egy fiók esetében. A beszúrt, frissített, törölt vagy beolvasott entitások általában a cél felé számlálnak. Így egy 100 entitást tartalmazó kötegbeszúrás 100 entitásnak számít. Az 1000 entitást beolvasó és 5 visszaadott lekérdezés 1000 entitásnak számít.
Entitások másodpercenként (partíció)
Egyetlen partíción belül a táblák elérésére szolgáló méretezhetőségi cél másodpercenként 2000 entitás (egyenként 1 KB) az előző szakaszban leírt számlálással.
Networking
Az alkalmazás fizikai hálózati korlátai jelentős hatással lehetnek a teljesítményre. Az alábbi szakaszok néhány olyan korlátozást ismertetnek, amelyekkel a felhasználók találkozhatnak.
Ügyfélhálózati képesség
A sávszélesség és a hálózati kapcsolat minősége fontos szerepet játszik az alkalmazások teljesítményében, az alábbi szakaszokban leírtak szerint.
Átviteli sebesség
A sávszélesség esetében a probléma gyakran az ügyfél képességei. A nagyobb Azure-példányok nagyobb kapacitású hálózati adapterekkel rendelkeznek, ezért érdemes megfontolni egy nagyobb példány vagy több virtuális gép használatát, ha nagyobb hálózati korlátokra van szüksége egyetlen gépről. Ha helyszíni alkalmazásból éri el az Azure Storage-t, ugyanez a szabály érvényes: ismerje meg az ügyféleszköz hálózati képességeit és az Azure Storage helyéhez való hálózati kapcsolatot, és szükség szerint javítsa őket, vagy tervezze meg az alkalmazást, hogy a képességeiknek megfelelően működjön.
Kapcsolat minősége
A hálózati használathoz hasonlóan ne feledje, hogy a hibákat és csomagvesztést eredményező hálózati feltételek lassítják a hatékony átviteli sebességet. A WireShark vagy a NetMon használata segíthet a probléma diagnosztizálásában.
Location
Bármely elosztott környezetben az ügyfél kiszolgálóhoz közeli elhelyezése a legjobb teljesítményt nyújtja. A legalacsonyabb késéssel rendelkező Azure Storage eléréséhez az ügyfél számára a legjobb hely ugyanabban az Azure-régióban található. Ha például van egy Azure-webalkalmazása, amely az Azure Storage-t használja, akkor mindkettőt egyetlen régióban, például az USA nyugati régiójában vagy Délkelet-Ázsiában találja. Az erőforrások közös keresése csökkenti a késést és a költségeket, mivel az egyetlen régión belüli sávszélesség-használat ingyenes.
Ha az ügyfélalkalmazások hozzáférnek az Azure Storage-hoz, de nem az Azure-ban vannak üzemeltetve, például mobileszköz-alkalmazásokban vagy helyszíni vállalati szolgáltatásokban, akkor a tárfióknak az ügyfelekhez közeli régióban való keresése csökkentheti a késést. Ha az ügyfelek széles körben vannak elosztva (például néhány Észak-Amerika és néhány Európában), akkor érdemes lehet régiónként egy tárfiókot használni. Ez a megközelítés könnyebben implementálható, ha az alkalmazás által tárolt adatok egyedi felhasználókra vonatkoznak, és nem igényelnek adatok replikálását a tárfiókok között.
SAS és CORS
Tegyük fel, hogy engedélyeznie kell a felhasználó webböngészőjében vagy egy mobiltelefonos alkalmazásban futó kódokat, például a JavaScriptet az Azure Storage-adatok eléréséhez. Az egyik módszer egy proxyként működő szolgáltatásalkalmazás létrehozása. A felhasználó eszköze a szolgáltatással hitelesít, ami viszont engedélyezi az Azure Storage-erőforrásokhoz való hozzáférést. Ily módon elkerülheti a tárfiókkulcsok nem biztonságos eszközökön való felfedését. Ez a megközelítés azonban jelentős többletterhelést jelent a szolgáltatásalkalmazáson, mivel a felhasználó eszköze és az Azure Storage között átvitt összes adatnak át kell haladnia a szolgáltatásalkalmazáson.
Elkerülheti, hogy egy szolgáltatásalkalmazást proxyként használjon az Azure Storage-hoz közös hozzáférésű jogosultságkódok (SAS) használatával. Az SAS használatával engedélyezheti, hogy a felhasználó eszköze egy korlátozott hozzáférési jogkivonat használatával közvetlenül az Azure Storage-ba küldjön kéréseket. Ha például egy felhasználó fel szeretne tölteni egy fényképet az alkalmazásba, akkor a szolgáltatásalkalmazás létrehozhat egy SAS-t, és elküldheti azt a felhasználó eszközére. Az SAS-jogkivonat engedélyt adhat egy Azure Storage-erőforrásba való írásra egy megadott ideig, amely után az SAS-jogkivonat lejár. További információ az SAS-ről: Korlátozott hozzáférés biztosítása az Azure Storage-erőforrásokhoz közös hozzáférésű jogosultságkódok (SAS) használatával.
A webböngészők általában nem engedélyezik a JavaScript használatát az egyik tartomány webhelye által üzemeltetett lapon bizonyos műveletek, például írási műveletek egy másik tartományba történő végrehajtásához. Az azonos eredetű szabályzatként ismert házirend megakadályozza, hogy egy rosszindulatú szkript egy oldalon hozzáférjen egy másik weblap adataihoz. Az azonos eredetű szabályzat azonban korlátozhatja a felhőben történő megoldáskészítést. A forrásközi erőforrás-megosztás (CORS) egy böngészőfunkció, amely lehetővé teszi a céltartomány számára, hogy a forrástartományból származó kéréseket megbízhatónak minősítő böngészővel kommunikáljon.
Tegyük fel például, hogy egy Azure-ban futó webalkalmazás egy Azure Storage-fiókba küld egy erőforrást. A webalkalmazás a forrástartomány, a tárfiók pedig a céltartomány. Bármelyik Azure Storage-szolgáltatáshoz konfigurálhatja a CORS-t, hogy a forrástartományból érkező kéréseket az Azure Storage megbízhatónak minősítő webböngészővel kommunikáljon. A CORS-ról további információt az Azure Storage forrásközi erőforrás-megosztási (CORS) támogatásában talál.
Az SAS és a CORS segítségével elkerülheti a webalkalmazás felesleges terhelését.
Batch-tranzakciók
A Table service támogatja az ugyanazon táblában lévő és ugyanahhoz a partíciócsoporthoz tartozó entitásokon végrehajtott kötegtranzakciókat. További információ: Entitáscsoport-tranzakciók végrehajtása.
.NET-konfiguráció
A .NET-keretrendszer használó projektek esetében ez a szakasz felsorol néhány gyors konfigurációs beállítást, amelyekkel jelentős teljesítménybeli javulást érhet el. Ha nem .NET-nyelvet használ, ellenőrizze, hogy a választott nyelven vannak-e hasonló fogalmak.
Az alapértelmezett kapcsolatkorlát növelése
Megjegyzés:
Ez a szakasz a .NET-keretrendszer használó projektekre vonatkozik, mivel a kapcsolatkészletezést a ServicePointManager osztály vezérli. A .NET Core jelentős változást vezetett be a kapcsolatkészlet kezelése körül, ahol a kapcsolatkészletezés a HttpClient szintjén történik, és a készlet mérete alapértelmezés szerint nem korlátozott. Ez azt jelenti, hogy a HTTP-kapcsolatok automatikusan skálázódnak a számítási feladatok kielégítése érdekében. A .NET legújabb verziójának használata ajánlott, ha lehetséges, a teljesítménybeli fejlesztések előnyeinek kihasználásához.
Az .NET-keretrendszer használó projektek esetében az alábbi kóddal növelheti az alapértelmezett kapcsolati korlátot (amely ügyfélkörnyezetben általában 2, kiszolgálói környezetben 10) 100-ra. Az értéket általában körülbelül az alkalmazás által használt szálak számának megfelelő értékre kell állítania. A kapcsolatok megnyitása előtt állítsa be a kapcsolatkorlátot.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
A .NET-keretrendszer kapcsolatkészletkorlátairól további információt a .NET-keretrendszer Csatlakozás ion Pool Limits és az új Azure SDK for .NET című témakörben talál.
Más programozási nyelvek esetén a dokumentációból megtudhatja, hogyan állíthatja be a kapcsolati korlátot.
Szálak minimális számának növelése
Ha szinkron hívásokat és aszinkron feladatokat használ, érdemes lehet növelni a szálak számát a szálkészletben:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
További információ: ThreadPool.SetMinThreads metódus.
Kötetlen párhuzamosság
Bár a párhuzamosság kiválóan alkalmas a teljesítményre, ügyeljen a kötetlen párhuzamosság használatára, ami azt jelenti, hogy nincs korlátozva a szálak vagy párhuzamos kérések száma. Ügyeljen arra, hogy korlátozza az adatok feltöltésére vagy letöltésére irányuló párhuzamos kérelmeket, hogy ugyanabban a tárfiókban több partícióhoz férhessen hozzá, vagy hogy ugyanabban a partícióban több elemhez is hozzáférhessen. Ha a párhuzamosság nem kötött, az alkalmazás túllépheti az ügyféleszköz képességeit vagy a tárfiók méretezhetőségi céljait, ami hosszabb késéseket és szabályozást eredményez.
Ügyfélkódtárak és -eszközök
A legjobb teljesítmény érdekében mindig a Microsoft által biztosított legújabb ügyfélkódtárakat és eszközöket használja. Az Azure Storage-ügyfélkódtárak különböző nyelvekhez érhetők el. Az Azure Storage a PowerShellt és az Azure CLI-t is támogatja. A Microsoft aktívan fejleszti ezeket az ügyfélkódtárakat és eszközöket a teljesítmény szem előtt tartásával, naprakészen tartja őket a legújabb szolgáltatásverziókkal, és biztosítja, hogy belsőleg kezelje a bevált teljesítménybeli eljárások nagy részét.
Szolgáltatáshibák kezelése
Az Azure Storage hibát ad vissza, ha a szolgáltatás nem tud feldolgozni egy kérést. Az Azure Storage által adott forgatókönyvben visszaadott hibák megértése hasznos a teljesítmény optimalizálásához.
Időtúllépési és kiszolgálói foglaltsági hibák
Az Azure Storage korlátozhatja az alkalmazást, ha megközelíti a méretezhetőség korlátait. Bizonyos esetekben előfordulhat, hogy az Azure Storage valamilyen átmeneti feltétel miatt nem tudja kezelni a kéréseket. Mindkét esetben előfordulhat, hogy a szolgáltatás 503(Kiszolgáló foglalt) vagy 500 (időtúllépés) hibát ad vissza. Ezek a hibák akkor is előfordulhatnak, ha a szolgáltatás újraegyensúlyozza az adatpartíciókat a nagyobb átviteli sebesség érdekében. Az ügyfélalkalmazásnak általában újra kell próbálkoznia az ilyen hibákat okozó művelettel. Ha azonban az Azure Storage azért szabályozza az alkalmazást, mert túllépi a méretezhetőségi célokat, vagy ha a szolgáltatás valamilyen más okból nem tudta kiszolgálni a kérést, az agresszív újrapróbálkozások tovább ronthatják a problémát. Az exponenciális visszatartási újrapróbálkozási szabályzat használata ajánlott, és az ügyfélkódtárak alapértelmezés szerint ezt a viselkedést használják. Előfordulhat például, hogy az alkalmazás 2 másodperc, majd 4 másodperc, 10 másodperc, majd 30 másodperc után újra próbálkozik, majd teljesen feladja. Ily módon az alkalmazás jelentősen csökkenti a szolgáltatás terhelését ahelyett, hogy fokozná a szabályozáshoz vezető viselkedést.
Csatlakozás tivitási hibák azonnal újrapróbálhatók, mert nem a szabályozás eredménye, és várhatóan átmenetiek lesznek.
Nem újrapróbálkozható hibák
Az ügyfélkódtárak kezelik az újrapróbálkozásokat, és tisztában vannak azzal, hogy mely hibák próbálkozhatók újra, és melyek nem. Ha azonban közvetlenül az Azure Storage REST API-t hívja meg, vannak olyan hibák, amelyeket nem szabad újrapróbálkoznia. Egy 400-ás (hibás kérelem) hiba például azt jelzi, hogy az ügyfélalkalmazás olyan kérelmet küldött, amely nem feldolgozható, mert nem volt a várt formában. A kérés újraküldése minden alkalommal ugyanazt a választ eredményezi, így nincs értelme újrapróbálkozni. Ha közvetlenül az Azure Storage REST API-t hívja meg, vegye figyelembe a lehetséges hibákat, és hogy újra kell-e próbálkoznia.
Az Azure Storage hibakódjaival kapcsolatos további információkért tekintse meg az Állapot és a hibakódok című témakört.
Konfiguráció
Ez a szakasz számos gyorskonfigurációs beállítást sorol fel, amelyekkel jelentős teljesítménybeli javulást érhet el a Table szolgáltatásban:
JSON használata
A Table szolgáltatás a 2013-08-15-ös tárolási szolgáltatástól kezdve támogatja a JSON használatát az XML-alapú AtomPub formátum helyett a táblaadatok átviteléhez. A JSON használatával akár 75%-kal is csökkentheti a hasznos adatok méretét, és jelentősen javíthatja az alkalmazás teljesítményét.
További információkért tekintse meg a Microsoft Azure Tables: A Table Service-műveletek JSON- és hasznos adatformátumának bemutatása című bejegyzést.
A Nagle letiltása
A Nagle algoritmusa széles körben implementálva van a TCP/IP-hálózatokon a hálózati teljesítmény javítása érdekében. Ez azonban nem optimális minden körülmények között (például rendkívül interaktív környezetekben). A Nagle algoritmusa negatív hatással van az Azure Table szolgáltatáshoz érkező kérések teljesítményére, és ha lehetséges, le kell tiltania.
Schema
Az adatok ábrázolása és lekérdezése a táblaszolgáltatás teljesítményét befolyásoló legnagyobb tényező. Bár minden alkalmazás más, ez a szakasz néhány általános bevált gyakorlatot mutat be, amelyek a következőkhöz kapcsolódnak:
- Táblaterv
- Hatékony lekérdezések
- Hatékony adatfrissítések
Táblák és partíciók
A táblák partíciókra vannak osztva. A partíciókban tárolt összes entitás ugyanazt a partíciókulcsot használja, és egy egyedi sorkulcsot tartalmaz, amely azonosítja azt a partíción belül. A partíciók előnyöket biztosítanak, de méretezhetőségi korlátokat is bevezetnek.
- Előnyök: Az ugyanabban a partícióban lévő entitásokat egyetlen, atomi, kötegelt tranzakcióban frissítheti, amely legfeljebb 100 különálló tárolási műveletet tartalmaz (legfeljebb 4 MB teljes méret). Feltételezve, hogy ugyanannyi entitást kell lekérni, az egyetlen partíción belüli adatokat is hatékonyabban kérdezheti le, mint a partíciókra kiterjedő adatokat (bár a táblaadatok lekérdezésével kapcsolatos további javaslatokért olvassa el).
- Méretezhetőségi korlát: Az egyetlen partícióban tárolt entitásokhoz való hozzáférés nem kiegyensúlyozott, mert a partíciók támogatják az atomi kötegtranzakciókat. Ezért az egyes táblapartíciók méretezhetőségi célértéke alacsonyabb, mint a Table szolgáltatás egésze esetében.
A táblák és partíciók ezen jellemzői miatt a következő tervezési alapelveket kell alkalmaznia:
- Keresse meg azokat az adatokat, amelyeket az ügyfélalkalmazás gyakran frissít vagy lekérdez ugyanabban a logikai egységben ugyanabban a partícióban. Keresse meg például az adatokat ugyanabban a partícióban, ha az alkalmazás írásokat összesítenek, vagy atomi kötegműveleteket hajt végre. Emellett az egyetlen partícióban lévő adatok hatékonyabban kérdezhetők le egyetlen lekérdezésben, mint a partíciók közötti adatok.
- Keresse meg azokat az adatokat, amelyeket az ügyfélalkalmazás nem szúr be, frissít vagy kérdez be ugyanabban a logikai egységben (azaz egyetlen lekérdezésben vagy kötegfrissítésben) külön partíciókban. Ne feledje, hogy egyetlen táblában nincs korlátozva a partíciókulcsok száma, így a partíciókulcsok millióinak használata nem jelent problémát, és nem befolyásolja a teljesítményt. Ha például az alkalmazás egy népszerű webhely, amelyen a felhasználó bejelentkezik, akkor a felhasználói azonosító használata partíciókulcsként jó választás lehet.
Gyakori elérésű partíciók
A gyakori elérésű partíciók olyan partíciók, amelyek a fiók felé történő forgalom aránytalan százalékát kapják, és nem kiegyensúlyozottak, mert egyetlen partícióról van szó. A gyakori elérésű partíciók általában kétféleképpen hozhatók létre:
Csak hozzáfűzési és csak előre felfűzési minták
A "Csak hozzáfűzés" minta olyan, ahol az adott partíciókulcs felé tartó forgalom (vagy majdnem az összes) az aktuális időnek megfelelően növekszik és csökken. Tegyük fel például, hogy az alkalmazás az aktuális dátumot használja partíciókulcsként a naplóadatokhoz. Ez a kialakítás azt eredményezi, hogy az összes beszúrás a tábla utolsó partíciójára kerül, és a rendszer nem tudja megfelelően betölteni az egyensúlyt. Ha a partícióra irányuló forgalom mennyisége meghaladja a partíciószintű méretezhetőségi célt, akkor szabályozást eredményez. Jobb, ha több partícióra küldi a forgalmat, hogy lehetővé tegye a terheléselosztást a kérések között a táblában.
Nagy forgalmú adatok
Ha a particionálási séma egyetlen partíciót eredményez, amely csak olyan adatokkal rendelkezik, amelyek sokkal több adatot használnak, mint a többi partíció, akkor szabályozás is előfordulhat, mivel ez a partíció megközelíti az egyetlen partíció méretezhetőségi célját. Jobb, ha meggyőződik arról, hogy a partíciós séma nem eredményez egyetlen partíciót sem, amely megközelíti a méretezhetőségi célokat.
Lekérdezés
Ez a szakasz a Table szolgáltatás lekérdezésének bevált eljárásait ismerteti.
Lekérdezési hatókör
A lekérdezéshez többféleképpen is megadhatja az entitások tartományát. Az alábbi lista a lekérdezési hatókör minden beállítását ismerteti.
- Pont-lekérdezések:- A pont lekérdezés pontosan egy entitást kér le a lekérni kívánt entitás partíciókulcsának és sorkulcsának megadásával. Ezek a lekérdezések hatékonyak, és ahol csak lehetséges, érdemes használni őket.
- Particionálási lekérdezések: A partíciós lekérdezések olyan lekérdezések, amelyek egy közös partíciókulcsot használó adatkészletet kérnek le. A lekérdezés általában egy partíciókulcs mellett egy sorkulcsértéktartományt vagy értéktartományt határoz meg bizonyos entitástulajdonságokhoz. Ezek a lekérdezések kevésbé hatékonyak, mint a pont-lekérdezések, és takarékosan kell használni őket.
- Tábla-lekérdezések: A tábla-lekérdezések olyan lekérdezések, amelyek olyan entitásokat kérnek le, amelyek nem osztanak meg közös partíciókulcsot. Ezek a lekérdezések nem hatékonyak, és ha lehetséges, kerülje őket.
Általában kerülje a vizsgálatokat (az egyetlen entitásnál nagyobb lekérdezéseket), de ha be kell vizsgálnia, próbálja rendszerezni az adatokat úgy, hogy a vizsgálatok a szükséges adatokat beolvashassák anélkül, hogy jelentős mennyiségű entitást adnak vissza, amelyekre nincs szüksége.
Lekérdezés sűrűsége
A lekérdezés hatékonyságának egy másik fő tényezője a visszaadott entitások száma a visszaadott készlet megkereséséhez beolvasott entitások számához képest. Ha az alkalmazás olyan tulajdonságérték szűrőjével végez tábla lekérdezést, amely csak az adatmegosztások 1%-a, a lekérdezés minden visszaadott entitás esetében 100 entitást vizsgál. A korábban tárgyalt táblázatméretezhetőségi célok a beolvasott entitások számához kapcsolódnak, és nem a visszaadott entitások számához: az alacsony lekérdezési sűrűség miatt a Table szolgáltatás könnyen szabályozhatja az alkalmazást, mert annyi entitást kell beolvasnia, hogy lekérje a keresett entitást. A szabályozás elkerüléséről további információt a denormalizálás című szakaszban talál.
A visszaadott adatok mennyiségének korlátozása
Ha tudja, hogy egy lekérdezés olyan entitásokat ad vissza, amelyekre nincs szüksége az ügyfélalkalmazásban, érdemes lehet szűrővel csökkenteni a visszaadott készlet méretét. Bár az ügyfélnek vissza nem adott entitások továbbra is beleszámítanak a méretezhetőségi korlátokba, az alkalmazás teljesítménye javul a csökkentett hálózati hasznos adatméret és az ügyfélalkalmazás által feldolgozandó entitások számának csökkentése miatt. Ne feledje, hogy a méretezhetőségi célok a vizsgált entitások számához kapcsolódnak, így a sok entitást kiszűrő lekérdezések szabályozást eredményezhetnek még akkor is, ha kevés entitást adnak vissza. A lekérdezések hatékonyabbá tételéről további információt a Lekérdezés sűrűsége című szakaszban talál.
Ha az ügyfélalkalmazásnak csak korlátozott tulajdonságkészletre van szüksége a tábla entitásaiból, a visszaadott adathalmaz méretének korlátozásához vetítéssel korlátozhatja a visszaadott adatkészlet méretét. A szűréshez hasonlóan a kivetítés is segít csökkenteni a hálózati terhelést és az ügyfélfeldolgozást.
Denormalizálás
Ellentétben a relációs adatbázisokkal, a táblaadatok hatékony lekérdezésének bevált eljárásai az adatok denormalizálásához vezetnek. Vagyis duplikálja ugyanazokat az adatokat több entitásban (az adatok megkereséséhez használható kulcsok egyikével), hogy a lekérdezések által beolvasandó entitások száma minimalizálható legyen az ügyfél számára szükséges adatok megkereséséhez, ahelyett, hogy nagy számú entitást kellene beolvasnia az alkalmazás által igényelt adatok megkereséséhez. Egy e-kereskedelmi webhelyen például érdemes lehet megkeresni egy megrendelést az ügyfélazonosító (adja meg az ügyfél rendeléseit) és a dátum (dátum szerinti rendelések) alapján is. A Table Storage-ban a legjobb, ha kétszer tárolja az entitást (vagy egy rá mutató hivatkozást) – egyszer táblanévvel, PK-val és RK-val, hogy megkönnyítse az ügyfélazonosító alapján történő keresést, egyszer, hogy megkönnyítse a dátum szerinti megtalálását.
Beszúrás, frissítés és törlés
Ez a szakasz a Table szolgáltatásban tárolt entitások módosításának bevált eljárásait ismerteti.
Kötegelés
A Batch-tranzakciókat entitáscsoport-tranzakcióknak nevezzük az Azure Storage-ban. Az entitáscsoport-tranzakción belüli összes műveletnek egyetlen partíción kell lennie egy táblában. Ha lehetséges, entitáscsoport-tranzakciók használatával szúrásokat, frissítéseket és törléseket hajthat végre kötegekben. Az entitáscsoport tranzakcióinak használata csökkenti az ügyfélalkalmazásból a kiszolgálóra irányuló oda-vissza utazások számát, csökkenti a számlázható tranzakciók számát (az entitáscsoport tranzakciói egyetlen tranzakcióként számítanak számlázási célokra, és legfeljebb 100 tárolási műveletet tartalmazhatnak), és lehetővé teszik az atomi frissítéseket (az entitáscsoport tranzakcióiban minden művelet sikeres vagy sikertelen). A nagy késéssel rendelkező környezetek, például a mobileszközök nagy mértékben profitálnak az entitáscsoportok tranzakcióinak használatából.
Beszúrás és frissítés
Használja a Table Upsert-műveleteket , ahol csak lehetséges. Az Upsertnek két típusa van, amelyek mindkettő hatékonyabbak lehetnek, mint a hagyományos beszúrási és frissítési műveletek:
- InsertOrMerge: Akkor használja ezt a műveletet, ha fel szeretné tölteni az entitás tulajdonságainak egy részét, de nem biztos benne, hogy az entitás már létezik-e. Ha az entitás létezik, ez a hívás frissíti az Upsert műveletben szereplő tulajdonságokat, és az összes meglévő tulajdonságot a jelenlegi állapotában hagyja, ha az entitás nem létezik, beszúrja az új entitást. Ez hasonló a lekérdezésben használt előrejelzéshez, mert csak a változó tulajdonságokat kell feltöltenie.
- InsertOrReplace: Akkor használja ezt a műveletet, ha teljesen új entitást szeretne feltölteni, de nem tudja biztosan, hogy már létezik-e. Ezt a műveletet akkor használja, ha tudja, hogy az újonnan feltöltött entitás teljesen helyes, mert teljesen felülírja a régi entitást. Frissíteni szeretné például a felhasználó aktuális helyét tároló entitást, függetlenül attól, hogy az alkalmazás korábban tárolt-e helyadatokat a felhasználó számára; az új hely entitás befejeződött, és nincs szüksége semmilyen információra egyetlen korábbi entitásból sem.
Adatsorok tárolása egyetlen entitásban
Előfordulhat, hogy egy alkalmazás olyan adatsort tárol, amelyet gyakran egyszerre kell lekérnie: az alkalmazások például nyomon követhetik a processzorhasználatot az elmúlt 24 óra adatainak mozgó diagramjának ábrázolása érdekében. Az egyik módszer az, hogy óránként egy táblaentitással rendelkezik, és minden entitás egy adott órát jelöl, és az adott órára vonatkozóan tárolja a processzorhasználatot. Az adatok ábrázolásához az alkalmazásnak le kell kérnie az adatokat tartalmazó entitásokat a legutóbbi 24 órából.
Másik lehetőségként az alkalmazás az óránkénti processzorhasználatot egyetlen entitás külön tulajdonságaként is tárolhatja: óránkénti frissítéshez az alkalmazás egyetlen InsertOrMerge Upsert-hívással frissítheti a legutóbbi óra értékét. Az adatok ábrázolásához az alkalmazásnak csak egyetlen entitást kell lekérnie a 24 helyett, ami hatékony lekérdezést tesz lehetővé. A lekérdezések hatékonyságáról további információt a Lekérdezés hatóköre című szakaszban talál.
Strukturált adatok tárolása blobokban
Ha kötegelt beszúrásokat végez, majd entitástartományokat keres össze, fontolja meg a blobok használatát táblák helyett. Jó példa erre egy naplófájl. Kötegelhet több percnyi naplót, és beszúrhatja őket, majd egyszerre több percnyi naplót is lekérhet. Ebben az esetben a teljesítmény jobb, ha blobokat használ táblák helyett, mivel jelentősen csökkentheti a beírt vagy beolvasott objektumok számát, valamint a szükséges kérések számát is.