Skálázható particionálási stratégia tervezése az Azure Table Storage-hoz
Ez a cikk a táblák Azure Table Storage-ban való particionálását és a hatékony skálázhatóság biztosításához használható stratégiákat ismerteti.
Az Azure magas rendelkezésre állású és nagy mértékben skálázható felhőtárhelyet biztosít. Az Azure mögöttes tárolórendszerét számos szolgáltatás biztosítja, többek között az Azure Blob Storage, az Azure Table Storage, az Azure Queue Storage és a Azure Files.
Az Azure Table Storage strukturált adatok tárolására lett tervezve. Az Azure Storage szolgáltatás korlátlan számú táblát támogat. Minden tábla nagy méretűre méretezhető, és terabájtnyi fizikai tárterületet biztosít. Ahhoz, hogy a legjobban kihasználhassa a táblák előnyeit, optimálisan particionálja az adatokat. Ez a cikk az Azure Table Storage-adatok hatékony particionálására használható stratégiákat ismerteti.
Táblaentitások
A táblaentitások a táblában tárolt adategységeket jelölik. A táblaentitások hasonlóak egy tipikus relációsadatbázis-tábla soraihoz. Minden entitás tulajdonságok gyűjteményét határozza meg. Minden tulajdonság kulcs/érték párként van definiálva a neve, az értéke és az érték adattípusa alapján. Az entitásoknak a következő három rendszertulajdonságot kell meghatározniuk a tulajdonsággyűjtemény részeként:
PartitionKey: A PartitionKey tulajdonság olyan sztringértékeket tárol, amelyek azonosítják azt a partíciót, amelyhez egy entitás tartozik. A partíciók, amint azt később tárgyaljuk, szerves részét képezik a tábla méretezhetőségének. Az azonos PartitionKey értékkel rendelkező entitások ugyanabban a partícióban vannak tárolva.
RowKey: A RowKey tulajdonság olyan sztringértékeket tárol, amelyek egyedileg azonosítják az egyes partíciókon belüli entitásokat. Az entitás elsődleges kulcsát a PartitionKey és a RowKey alkotja.
Időbélyeg: Az Időbélyeg tulajdonság egy entitás nyomon követhetőségét biztosítja. Az időbélyeg egy dátum/idő érték, amely az entitás legutóbbi módosításának időpontját jelzi. Az időbélyeget néha az entitás verziójának is nevezik. Az időbélyegek módosításait a rendszer figyelmen kívül hagyja, mert a táblaszolgáltatás az összes beszúrási és frissítési művelet során megőrzi a tulajdonság értékét.
Tábla elsődleges kulcsa
Az Azure-entitások elsődleges kulcsa a PartitionKey és a RowKey kombinált tulajdonságaiból áll. A két tulajdonság egyetlen fürtözött indexet alkot a táblában. A PartitionKey és a RowKey érték legfeljebb 1024 karakter hosszúságú lehet. Üres sztringek is engedélyezettek; a null értékek azonban nem engedélyezettek.
A fürtözött index növekvő sorrendben rendezi a PartitionKey , majd a RowKey sorrendet növekvő sorrendben. A rendezési sorrend minden lekérdezési válaszban megfigyelhető. A rendszer lexikális összehasonlításokat használ a rendezési művelet során. A "111" sztringérték a "2" sztringérték előtt jelenik meg. Bizonyos esetekben a rendezési sorrend numerikus lehet. Numerikus és növekvő sorrendben történő rendezéshez rögzített hosszúságú, nulla kitöltésű sztringeket kell használnia. Az előző példában a "002" a "111" előtt jelenik meg.
Táblapartíciók
A partíciók azonos PartitionKey értékekkel rendelkező entitások gyűjteményét jelölik. A partíciókat mindig egy partíciókiszolgáló szolgálja ki. Minden partíciókiszolgáló egy vagy több partíciót is kiszolgálhat. A partíciókiszolgálók az egy partícióról egy időben kiszolgálható entitások számának korlátját szabják meg. A partíciók méretezhetőségi célja 2000 entitás másodpercenként. Ez az átviteli sebesség magasabb lehet a tárolócsomópont minimális terhelése során, de le van szabályozva, amikor a csomópont forróvá vagy aktívvá válik.
A particionálás fogalmának jobb szemléltetése érdekében az alábbi ábrán egy táblázat látható, amely a lábversenyes események regisztrációinak egy kis részhalmazát tartalmazza. Az ábra a particionálás fogalmi nézetét mutatja be, ahol a PartitionKey három különböző értéket tartalmaz: az esemény neve három távolsággal (teljes maraton, félmaraton és 10 km). Ez a példa két partíciókiszolgálót használ. Az A kiszolgáló félmaratonra és 10 km-re vonatkozó regisztrációkat tartalmaz. A B kiszolgáló csak a teljes maratontávokat tartalmazza. A RowKey értékek kontextust biztosítanak, de az értékek ebben a példában nem értelmezhetők.
Egy tábla három partícióval
Méretezhetőség
Mivel a partíciókat mindig egyetlen partíciókiszolgáló szolgálja ki, és minden partíciókiszolgáló egy vagy több partíciót is kiszolgálhat, az entitások kiszolgálásának hatékonysága összefügg a kiszolgáló állapotával. Előfordulhat, hogy azok a kiszolgálók, amelyek nagy forgalmat tapasztalnak a partícióikon, nem tudják fenntartani a magas átviteli sebességet. Ha például az előző ábrán a "2011 New York City Marathon__Half" számos kérése érkezik, előfordulhat, hogy az A kiszolgáló túl forróvá válik. A kiszolgáló átviteli sebességének növelése érdekében a tárolórendszer terheléselosztja a partíciókat más kiszolgálókon. Ennek az az eredménye, hogy a forgalom sok más kiszolgálón is el van osztva. A forgalom optimális terheléselosztásához több partíciót kell használnia, hogy az Azure Table Storage el tudja osztani a partíciókat több partíciókiszolgálón.
Entitáscsoport tranzakciói
Az entitáscsoport-tranzakciók olyan tárolási műveletek készletei, amelyek atomi módon vannak implementálva az ugyanazon PartitionKey értékkel rendelkező entitásokon. Ha az entitáscsoport bármely tárolási művelete meghiúsul, az entitás összes tárolási művelete vissza lesz állítva. Egy entitáscsoport tranzakciója legfeljebb 100 tárolási műveletből áll, és legfeljebb 4 MiB méretű lehet. Az entitáscsoport-tranzakciók az Azure Table Storage számára a relációs adatbázisok által biztosított atomitás, konzisztencia, elkülönítés és tartósság (ACID) szemantika korlátozott formáját biztosítják.
Az entitáscsoport tranzakciói javítják az átviteli sebességet, mivel csökkentik az Azure Table Storage-ba küldendő egyes tárolási műveletek számát. Az entitáscsoport-tranzakciók gazdasági előnyt is biztosítanak. Az entitáscsoport tranzakcióinak számlázása egyetlen tárolási műveletként történik, függetlenül attól, hogy hány tárolási műveletet tartalmaz. Mivel egy entitáscsoport-tranzakció összes tárolási művelete hatással van az azonos PartitionKey értékkel rendelkező entitásokra, az entitáscsoport-tranzakciók használatának szükségessége vezethet a PartitionKey érték kiválasztásához.
Tartománypartíciók
Ha egyedi PartitionKey értékeket használ az entitásokhoz, mindegyik entitás a saját partíciójához tartozik. Ha a használt egyedi értékek növelik vagy csökkentik az értéket, lehetséges, hogy az Azure tartománypartíciókat hoz létre. A tartománypartíciók szekvenciális, egyedi PartitionKey értékekkel rendelkező entitásokat csoportosítanak a tartomány lekérdezéseinek teljesítményének javítása érdekében. Tartománypartíciók nélkül a tartomány-lekérdezéseknek partíciók vagy kiszolgálóhatárok közöttinek kell lenniük, ami csökkentheti a lekérdezési teljesítményt. Vegyünk egy olyan alkalmazást, amely a következő táblát használja, amely a PartitionKey esetében növekvő szekvencia-értékkel rendelkezik:
| PartitionKey | RowKey |
|---|---|
| "0001" | - |
| "0002" | - |
| "0003" | - |
| "0004" | - |
| "0005" | - |
| "0006" | - |
Az Azure az első három entitást egy tartománypartícióba csoportosíthatja. Ha tartománylekérdezést alkalmaz arra a táblára, amely a PartitionKey-t használja feltételként, és entitásokat kér le a "0001"-ről a "0003"-ra, a lekérdezés hatékonyan végrehajtható, mert az entitások egyetlen partíciókiszolgálóról vannak kiszolgálva. Nem garantálható, hogy mikor és hogyan jön létre egy tartománypartíció.
A tábla tartománypartícióinak megléte befolyásolhatja a beszúrási műveletek teljesítményét, ha növekvő vagy csökkenő PartitionKey értékekkel rendelkező entitásokat szúr be. A PartitionKey értékeket növelő entitások beszúrását csak hozzáfűzési mintának nevezzük. A csökkenő értékekkel rendelkező entitások beszúrását csak előtagos mintának nevezzük. Érdemes lehet nem használni ezeket a mintákat, mert a beszúrási kérelmek teljes átviteli sebességét egyetlen partíciókiszolgáló korlátozza. Ennek az az oka, hogy ha a tartománypartíciók léteznek, az első és az utolsó (tartomány)partíció a legkisebb és a legnagyobb PartitionKey értéket tartalmazza. Ezért egy olyan új entitás beszúrása, amely szekvenciálisan alacsonyabb vagy magasabb PartitionKey értékkel rendelkezik, az egyik végpartíciót célozza meg. Az alábbi ábra az előző példán alapuló lehetséges tartománypartíciókat mutatja be. Ha "0007", "0008" és "0009" entitásokat szúr be, azokat a rendszer az utolsó (narancssárga) partícióhoz rendeli.
Tartománypartíciók halmaza
Fontos megjegyezni, hogy nincs negatív hatással a teljesítményre, ha a beszúrási műveletek pontozottabb PartitionKey értékeket használnak.
Adatok elemzése
Az indexek kezelésére használható relációs adatbázisok tábláitól eltérően az Azure Table Storage-táblák csak egy indexet tartalmazhatnak. Az Azure Table Storage-ban az indexek mindig a PartitionKey és a RowKey tulajdonságokból áll.
Az Azure-táblákban nincs meg a tábla teljesítményhangolásának luxusa, ha további indexeket ad hozzá, vagy módosít egy meglévő táblát a bevezetés után. A táblázat megtervezése során elemeznie kell az adatokat. Az optimális méretezhetőség, valamint a lekérdezési és beszúrási hatékonyság szempontjából a PartitionKey és a RowKey értékek a legfontosabb szempontok. Ez a cikk a PartitionKey kiválasztását hangsúlyozza, mivel közvetlenül kapcsolódik a táblák particionálásához.
Partícióméretezés
A partícióméretezés a partíció által tartalmazott entitások számát jelenti. Ahogy a méretezhetőségről is szó van, a több partícióval jobb terheléselosztás érhető el. A PartitionKey érték részletessége befolyásolja a partíciók méretét. A legalsó szinten, ha egyetlen értéket használ a PartitionKey értékként, az összes entitás egyetlen, nagyon nagy partícióban található. A legrészletesebb szinten a PartitionKey minden entitáshoz egyedi értékeket tartalmazhat. Az eredmény az, hogy minden entitáshoz van egy partíció. Az alábbi táblázat a részletesség tartományának előnyeit és hátrányait mutatja be:
| PartitionKey részletessége | Partíció mérete | Előnyök | Hátrányok |
|---|---|---|---|
| Egyetlen érték | Kis számú entitás | Kötegtranzakciók bármely entitással lehetségesek. Minden entitás helyi, és ugyanabból a tárolócsomópontból szolgál ki. |
|
| Egyetlen érték | Nagy számú entitás | Az entitáscsoport tranzakciói bármely entitással lehetségesek. Az entitáscsoport-tranzakciók korlátaival kapcsolatos további információkért lásd: Entitáscsoport-tranzakciók végrehajtása. | A skálázás korlátozott. Az átviteli sebesség egyetlen kiszolgáló teljesítményére korlátozódik. |
| Több érték | Több partíció A partícióméretek az entitások eloszlásától függenek. |
Egyes entitásokon kötegtranzakciók lehetségesek. Dinamikus particionálás lehetséges. Az egykéréses lekérdezések lehetségesek (nincsenek folytatási jogkivonatok). A terheléselosztás több partíciókiszolgálón is lehetséges. |
Az entitások partíciók közötti rendkívül egyenetlen eloszlása korlátozhatja a nagyobb és aktívabb partíciók teljesítményét. |
| Egyedi értékek | Sok kis partíció | A tábla nagy mértékben méretezhető. A tartománypartíciók javíthatják a partíciók közötti tartománylekérdezések teljesítményét. |
A tartományokat tartalmazó lekérdezésekhez több kiszolgálóra is szükség lehet. Kötegelt tranzakciók nem lehetségesek. A csak hozzáfűzési vagy a csak előerős minták hatással lehetnek a beszúrási átviteli sebességre. |
A táblázat bemutatja, hogyan érinti a skálázást a PartitionKey értékek. Ajánlott a kisebb partíciókat előnyben részesíteni, mert jobb terheléselosztást biztosítanak. A nagyobb partíciók bizonyos esetekben megfelelőek lehetnek, és nem feltétlenül hátrányosak. Ha például az alkalmazás nem igényel méretezhetőséget, egyetlen nagy partíció lehet megfelelő.
Lekérdezések meghatározása
A lekérdezések adatokat kérnek le a táblákból. Az Azure Table Storage-ban lévő táblák adatainak elemzésekor fontos figyelembe venni, hogy az alkalmazás mely lekérdezéseket fogja használni. Ha egy alkalmazás több lekérdezéssel rendelkezik, előfordulhat, hogy rangsorolnia kell őket, bár a döntések szubjektívek lehetnek. A domináns lekérdezések sok esetben megkülönböztethetők más lekérdezésektől. A teljesítmény szempontjából a lekérdezések különböző kategóriákba sorolhatók. Mivel egy tábla csak egy indexet tartalmaz, a lekérdezési teljesítmény általában a PartitionKey és a RowKey tulajdonságokhoz kapcsolódik. Az alábbi táblázat a lekérdezések különböző típusait és azok teljesítményértékelését mutatja be:
| Lekérdezés típusa | PartitionKey egyezés | Sorkulcs egyeztetése | Teljesítményértékelés |
|---|---|---|---|
| Sortartomány vizsgálata | Exact | Részleges | Jobb a kisebb méretű partíciókkal. Rossz a nagyon nagy partíciókkal. |
| Partíciótartomány vizsgálata | Részleges | Részleges | Jó, ha kevés partíciókiszolgálót érintenek. Rosszabb, ha több kiszolgálót érintenek. |
| Teljes táblázatvizsgálat | Részleges, nincs | Részleges, nincs | Rosszabb, ha a partíciók egy részhalmazát ellenőrzik. Legrosszabb, ha az összes partíciót beolvasták. |
Megjegyzés
A táblázat egymáshoz képest határozza meg a teljesítményértékeléseket. A partíciók száma és mérete végső soron meghatározhatja a lekérdezés végrehajtását. Például egy sok nagy partícióval rendelkező tábla partíciótartomány-vizsgálata rosszul teljesíthet, mint egy néhány kis partíciót tartalmazó tábla teljes táblavizsgálata.
Az előző táblázatban felsorolt lekérdezéstípusok a legjobb lekérdezéstípusoktól a legrosszabb típusig mutatnak előrehaladást a teljesítményértékelésük alapján. A pont típusú lekérdezések a legjobban használható lekérdezések, mivel teljes mértékben használják a tábla fürtözött indexét. A következő pont lekérdezés a lábversenyek regisztrációs táblájának adatait használja:
http://<account>.windows.core.net/registrations(PartitionKey=”2011 New York City Marathon__Full”,RowKey=”1234__John__M__55”)
Ha az alkalmazás több lekérdezést használ, nem mindegyik lehet pont típusú lekérdezés. A teljesítmény szempontjából a tartomány lekérdezései pont típusú lekérdezéseket követnek. A tartomány lekérdezéseinek két típusa van: a sortartomány vizsgálata és a partíciótartomány vizsgálata. A sortartomány-vizsgálat egyetlen partíciót határoz meg. Mivel a művelet egyetlen partíciókiszolgálón történik, a sortartomány-vizsgálatok általában hatékonyabbak, mint a partíciótartomány-vizsgálatok. A sortartomány-vizsgálatok teljesítményének egyik fő tényezője azonban az, hogy mennyire szelektív a lekérdezés. A lekérdezésválasztó meghatározza, hogy hány sort kell iteratedálni az egyező sorok megkereséséhez. A szelektívebb lekérdezések hatékonyabbak a sortartomány-vizsgálatok során.
A lekérdezések prioritásainak felméréséhez vegye figyelembe az egyes lekérdezések gyakoriságára és válaszidejére vonatkozó követelményeket. A gyakran végrehajtott lekérdezések magasabb prioritást kaphatnak. A fontos, de ritkán használt lekérdezések azonban alacsony késési követelményekkel rendelkezhetnek, amelyek rangsorolhatják azt a prioritási listán.
Válassza ki a PartitionKey értéket
A táblák kialakításának középpontjában a méretezhetőség, a hozzá való hozzáféréshez használt lekérdezések és a tárolási üzemeltetési követelmények szolgálnak. A választott PartitionKey értékek határozzák meg a táblák particionálásának módját és a használható lekérdezések típusát. A tárolási műveletek, különösen a beszúrások is befolyásolhatják a PartitionKey értékek választását. A PartitionKey értékek egyetlen értéktől az egyedi értékekig terjedhetnek. Ezek több érték használatával is létrehozhatók. Az entitástulajdonságok használatával létrehozhatja a PartitionKey értéket. Vagy az alkalmazás kiszámíthatja az értéket. Az alábbi szakaszok fontos szempontokat tárgyalnak.
Entitáscsoport tranzakciói
A fejlesztőknek először meg kell fontolniuk, hogy az alkalmazás entitáscsoport-tranzakciókat (kötegelt frissítéseket) fog-e használni. Az entitáscsoport-tranzakciókhoz az entitásoknak ugyanazt a PartitionKey értéket kell megadniuk. Mivel a kötegelt frissítések egy teljes csoporthoz tartoznak, a PartitionKey értékek lehetőségei korlátozottak lehetnek. A készpénztranzakciókat karbantartó banki alkalmazásoknak például atomilag be kell szúrniuk a táblába a készpénztranzakciókat. A készpénztranzakciók mind a terhelési, mind a hiteloldalt képviselik, és nullára kell nullát tenni. Ez a követelmény azt jelenti, hogy a fiókszám nem használható a PartitionKey érték részeként, mert a tranzakció minden oldala eltérő fiókszámokat használ. Ehelyett a tranzakcióazonosító jobb választás lehet.
Partíciók
A partíciószámok és -méretek befolyásolják a terhelés alatt álló táblák méretezhetőségét. Emellett a PartitionKey értékek részletességétől is függnek. Nehéz lehet meghatározni a PartitionKey paramétert a partíció mérete alapján, különösen akkor, ha az értékek eloszlását nehéz előrejelezni. A hüvelykujj egy jó szabálya, hogy több, kisebb partíciót használjon. Számos táblapartíció megkönnyíti az Azure Table Storage számára a partíciók által kiszolgált tárolócsomópontok kezelését.
A PartitionKey egyedi vagy finomabb értékeinek kiválasztása kisebb, de több partíciót eredményez. Ez általában azért előnyös, mert a rendszer terheléselosztást végezhet a sok partíció között a terhelés elosztásához. Figyelembe kell azonban vennie, hogy sok partíció van a többpartíciós tartományok lekérdezéseire. Az ilyen típusú lekérdezéseknek több partíciót kell felkeresniük a lekérdezések teljesítéséhez. Lehetséges, hogy a partíciók több partíciókiszolgáló között vannak elosztva. Ha egy lekérdezés átlép egy kiszolgálóhatárt, a folytatási jogkivonatokat vissza kell adni. A folytatási jogkivonatok a következő PartitionKey vagy RowKey értékeket adják meg a lekérdezés következő adatkészletének lekéréséhez. Más szóval a folytatási jogkivonatok legalább egy további kérést jelentenek a szolgáltatásnak, ami csökkentheti a lekérdezés általános teljesítményét.
A lekérdezés-kiválasztás egy másik tényező, amely befolyásolhatja a lekérdezés teljesítményét. A lekérdezés-választóképesség azt méri, hogy hány sort kell iterálni az egyes partíciókhoz. Minél szelektívebb egy lekérdezés, annál hatékonyabb a kívánt sorok visszaadása. A tartománylekérdezések általános teljesítménye függhet az érintett partíciókiszolgálók számától vagy a lekérdezés szelektívségétől. Ne használjon csak hozzáfűző vagy csak előtagos mintákat, amikor adatokat szúr be a táblába. Ha ezeket a mintákat használja, annak ellenére, hogy kis és sok partíciót hoz létre, korlátozhatja a beszúrási műveletek átviteli sebességét. A csak hozzáfűző és a csak előtagú mintákat a Tartománypartíciókban tárgyaljuk.
Lekérdezések
A használni kívánt lekérdezések ismerete segíthet meghatározni, hogy mely tulajdonságokat érdemes figyelembe venni a PartitionKey értékhez. A lekérdezésekben használt tulajdonságok a PartitionKey érték jelöltjei. Az alábbi táblázat általános útmutatást nyújt a PartitionKey érték meghatározásához:
| Ha az entitás... | Művelet |
|---|---|
| Egy kulcstulajdonság van | Használja PartitionKeyként. |
| Két fő tulajdonsággal rendelkezik | Használja az egyiket PartitionKeyként , a másikat Pedig Sorkulcsként. |
| Két kulcstulajdonságnál több van | Összefűzött értékek összetett kulcsának használata. |
Ha egynél több egyformán domináns lekérdezés van, az adatokat többször is beszúrhatja különböző RowKey értékek használatával, amelyekre szüksége van. Az alkalmazás kezeli a másodlagos (vagy harmadlagos stb.) sorokat. Ez a mintatípus a lekérdezések teljesítménykövetelményeinek kielégítésére használható. Az alábbi példa a lábverseny-regisztrációs példa adatait használja. Két domináns lekérdezése van:
- Lekérdezés BIB-szám alapján
- Lekérdezés kor szerint
Mindkét domináns lekérdezés kiszolgálásához szúrjon be két sort entitáscsoport-tranzakcióként. Az alábbi táblázat a forgatókönyv PartitionKey és RowKey tulajdonságait mutatja be. A RowKey értékek előtagot biztosítanak a bib és az életkor számára, hogy az alkalmazás különbséget tud tenni a két érték között.
| PartitionKey | RowKey |
|---|---|
| 2011 New York City Marathon__Full | BIB:01234__John__M__55 |
| 2011 New York City Marathon__Full | KOR:055__1234__John__M |
Ebben a példában egy entitáscsoport tranzakciója lehetséges, mert a PartitionKey értékei megegyeznek. A csoporttranzakció biztosítja a beszúrási művelet atomitását. Bár ezt a mintát különböző PartitionKey értékekkel is használhatja, javasoljuk, hogy ugyanazokat az értékeket használja az előny eléréséhez. Ellenkező esetben előfordulhat, hogy extra logikát kell írnia, hogy biztosítsa a különböző PartitionKey értékeket használó atomi tranzakciókat.
Tárolási műveletek
Az Azure Table Storage táblái nem csak a lekérdezésekből tapasztalhatnak terhelést. A tárolóműveletek, például a beszúrások, frissítések és törlések terhelését is tapasztalhatják. Gondolja át, milyen típusú tárolási műveleteket fog végrehajtani a táblán, és milyen sebességgel. Ha ritkán hajtja végre ezeket a műveleteket, előfordulhat, hogy nem kell aggódnia miattuk. A gyakori műveletek, például a sok beszúrás rövid idő alatt történő végrehajtása esetén azonban figyelembe kell vennie, hogy ezek a műveletek hogyan lesznek kiszolgálva a választott PartitionKey értékek eredményeként. A fontos példák a csak hozzáfűző és a csak előtagú minták. A csak hozzáfűző és a csak előtagú mintákat a Tartománypartíciókban tárgyaljuk.
Ha csak hozzáfűző vagy előtagos mintát használ, a partitionKey egyedi növekvő vagy csökkenő értékeit fogja használni a későbbi beszúrások során. Ha ezt a mintát gyakori beszúrási műveletekkel kombinálja, a táblázat nem fogja tudni nagy méretezhetőséggel kiszolgálni a beszúrási műveleteket. A tábla méretezhetősége azért van hatással, mert az Azure nem tudja terheléselosztásra használni a műveletkéréseket más partíciókiszolgálókra. Ebben az esetben érdemes lehet véletlenszerű értékeket használni, például GUID értékeket. Ezután a partícióméretek kicsik maradhatnak, és továbbra is fenntarthatják a terheléselosztást a tárolási műveletek során.
Táblapartíció stressztesztelése
Ha a PartitionKey érték összetett, vagy más PartitionKey-leképezésekkel való összehasonlítást igényel, előfordulhat, hogy tesztelnie kell a tábla teljesítményét. A tesztnek meg kell vizsgálnia, hogy egy partíció milyen jól teljesít a csúcsterhelések alatt.
Stresszteszt végrehajtása
- Létrehozás egy teszttáblát.
- Töltse be a teszttáblát adatokkal, hogy olyan entitásokat tartalmazzon, amelyek a megcélzott PartitionKey értékkel rendelkeznek.
- Az alkalmazás használatával szimulálhatja a tábla terhelésének csúcsát. Egyetlen partíciót célozzon meg a 2. lépés PartitionKey értékével. Ez a lépés minden alkalmazás esetében más, de a szimulációnak tartalmaznia kell az összes szükséges lekérdezést és tárolási műveletet. Előfordulhat, hogy módosítania kell az alkalmazást, hogy egyetlen partíciót célozzon meg.
- Vizsgálja meg a tábla GET vagy PUT műveleteinek átviteli sebességét.
Az átviteli sebesség vizsgálatához hasonlítsa össze a tényleges értékeket az egyetlen kiszolgálón található egyetlen partíció megadott korlátjának értékével. A partíciók másodpercenként legfeljebb 2000 entitást használhatnak. Ha egy partíció átviteli sebessége meghaladja a másodpercenkénti 2000 entitást, előfordulhat, hogy a kiszolgáló túl gyakran fut éles környezetben. Ebben az esetben a PartitionKey értékek túl durvaak lehetnek, így nincs elég partíció, vagy a partíciók túl nagyok. Előfordulhat, hogy módosítania kell a PartitionKey értéket, hogy a partíciók több kiszolgáló között legyenek elosztva.
Terheléselosztás
A partícióréteg terheléselosztása akkor következik be, ha egy partíció túl gyakori. Ha egy partíció túl gyakori, a partíció, különösen a partíciókiszolgáló a cél méretezhetőségén túl működik. Az Azure Storage esetében minden partíció skálázhatósági célértéke másodpercenként 2000 entitás. A terheléselosztás az Elosztott fájlrendszer (DFS) rétegben is megtörténik.
Az elosztott fájlrendszerbeli réteg terheléselosztása az I/O-terheléssel foglalkozik, és kívül esik a jelen cikk hatókörén. A partícióréteg terheléselosztása nem történik meg azonnal a méretezhetőségi cél túllépése után. Ehelyett a rendszer néhány percet vár a terheléselosztási folyamat megkezdése előtt. Ez biztosítja, hogy egy partíció valóban forróvá váljon. Nem szükséges olyan partíciókat létrehozni, amelyek terheléselosztást váltanak ki, mert a rendszer automatikusan végrehajtja a feladatot.
Ha egy táblát egy bizonyos terheléssel hoztak létre, a rendszer a tényleges terhelés alapján kiegyensúlyozhatja a partíciókat, ami a partíciók jelentősen eltérő eloszlását eredményezi. A partíciók beírása helyett érdemes lehet olyan kódot írni, amely kezeli az időtúllépést és a kiszolgáló foglaltsági hibáit. A rendszer terheléselosztáskor adja vissza a hibákat. A hibák újrapróbálkozással történő kezelésével az alkalmazás jobban képes kezelni a csúcsterheléseket. Az újrapróbálkozásra vonatkozó stratégiákat a következő szakaszban ismertetjük részletesebben.
Terheléselosztás esetén a partíció néhány másodpercig offline állapotba kerül. Az offline időszakban a rendszer egy másik partíciókiszolgálóhoz rendeli hozzá a partíciót. Fontos megjegyezni, hogy az adatokat nem a partíciókiszolgálók tárolják. Ehelyett a partíciókiszolgálók az elosztott fájlrendszer rétegéből származó entitásokat szolgálnak ki. Mivel az adatokat nem a partícióréteg tárolja, a partíciók különböző kiszolgálókra való áthelyezése gyors folyamat. Ez a rugalmasság nagy mértékben korlátozza az alkalmazás által esetlegesen tapasztalt állásidőt.
Újrapróbálkozási stratégia
Fontos, hogy az alkalmazás kezelje a tárolási művelet hibáit, hogy ne veszítsen el adatfrissítéseket. Egyes hibákhoz nincs szükség újrapróbálkozési stratégiára. A 401-es nem engedélyezett hibát eredményező frissítések esetében például nem előnyös a művelet újrapróbálkozása, mert valószínű, hogy az alkalmazás állapota nem változik a 401-es hibát feloldó újrapróbálkozések között. Az olyan hibák azonban, mint a Kiszolgáló elfoglaltsága vagy az Időtúllépés, az Azure terheléselosztási funkcióihoz kapcsolódnak, amelyek táblaméretezhetőséget biztosítanak. Amikor az entitásokat kiszolgáló tárolócsomópontok gyakorivá válnak, az Azure úgy egyensúlyba helyezi a terhelést, hogy partíciókat helyez át más csomópontokra. Ez idő alatt előfordulhat, hogy a partíció nem érhető el, ami kiszolgáló foglalt vagy időtúllépési hibákat eredményez. Végül a partíció újra szerkeszthető, és a frissítések folytatódnak.
Az újrapróbálkozás stratégiája megfelelő a kiszolgáló foglaltsági vagy időtúllépési hibáihoz. A legtöbb esetben kizárhatja a 400 szintű hibákat és néhány 500 szintű hibát az újrapróbálkozás logikájából. A kizárható hibák közé tartozik az 501 Nem implementált és az 505-ös HTTP-verzió nem támogatott. Ezután újrapróbálkozési stratégiát implementálhat akár 500 szintű hibákhoz, például a Kiszolgáló elfoglaltsága (503) és az Időtúllépés (504) esetében.
Az alkalmazás három gyakori újrapróbálkozési stratégiája közül választhat:
- Nincs újrapróbálkozás: Nem történik újrapróbálkozási kísérlet.
- Kijavított visszalépés: A művelet újrapróbálkozása N alkalommal, állandó visszalépési értékkel.
- Exponenciális visszalépés: A művelet n-szer ismétlődik exponenciális visszalépési értékkel.
A No Retry stratégia egy egyszerű (és kitérő) módszer a műveleti hibák kezelésére. A Nincs újrapróbálkozás stratégia azonban nem túl hasznos. Ha nem hajt végre újrapróbálkozási kísérleteket, az nyilvánvaló kockázatot jelent, mivel az adatok nem megfelelően vannak tárolva a sikertelen műveletek után. Jobb stratégia a Rögzített Visszalépés stratégia használata. ez lehetővé teszi a műveletek újrapróbálkozásának lehetőségét ugyanazzal a visszalépési időtartammal.
A stratégia azonban nem a nagy mértékben méretezhető táblák kezelésére van optimalizálva. Ha sok szál vagy folyamat várakozik ugyanarra az időtartamra, ütközések fordulhatnak elő. Az ajánlott újrapróbálkozási stratégia egy exponenciális visszalépést használ, ahol minden újrapróbálkozási kísérlet hosszabb, mint az utolsó kísérlet. Hasonló a számítógépes hálózatokban, például az Ethernetben használt ütközéselkerülési algoritmushoz. Az exponenciális visszalépés véletlenszerű tényezővel ad további varianciát az eredményként kapott intervallumnak. A visszalépési érték ezután a minimális és maximális korlátokra van korlátozva. A következő képlet használható a következő visszalépési érték kiszámításához egy exponenciális algoritmus használatával:
y = Rand(0,8z, 1,2z)(2x-1
y = Min(zmin + y, zmax)
Ahol:
z = alapértelmezett visszalépés ezredmásodpercben
zmin = alapértelmezett minimális visszalépés ezredmásodpercben
zmax = alapértelmezett maximális visszalépés ezredmásodpercben
x = az újrapróbálkozések száma
y = a visszalépés értéke ezredmásodpercben
A Rand (véletlenszerű) függvényben használt 0,8 és 1,2 szorzó az eredeti érték ±20%-ában véletlenszerű eltérést eredményez. A ±20%-os tartomány a legtöbb újrapróbálkozáshoz elfogadható, és megakadályozza a további ütközéseket. A képlet a következő kóddal valósítható meg:
int retries = 1;
// Initialize variables with default values
var defaultBackoff = TimeSpan.FromSeconds(30);
var backoffMin = TimeSpan.FromSeconds(3);
var backoffMax = TimeSpan.FromSeconds(90);
var random = new Random();
double backoff = random.Next(
(int)(0.8D * defaultBackoff.TotalMilliseconds),
(int)(1.2D * defaultBackoff.TotalMilliseconds));
backoff *= (Math.Pow(2, retries) - 1);
backoff = Math.Min(
backoffMin.TotalMilliseconds + backoff,
backoffMax.TotalMilliseconds);
Összefoglalás
Az Azure Table Storage-ban lévő alkalmazások nagy mennyiségű adatot tárolhatnak, mivel a Table Storage számos tárolási csomópont partícióit kezeli és rendeli újra. Az adatparticionálással szabályozhatja a tábla méretezhetőségét. Tervezze meg előre a táblázatséma definiálásakor, hogy hatékony particionálási stratégiákat implementáljon. A PartitionKey értékek kiválasztása előtt elemezze az alkalmazás követelményeit, adatait és lekérdezéseit. Előfordulhat, hogy az egyes partíciók más tárolócsomópontokhoz lesznek hozzárendelve, amikor a rendszer válaszol a forgalomra. Partíciós stresszteszt használatával győződjön meg arról, hogy a tábla a megfelelő PartitionKey értékekkel rendelkezik. Ez a teszt segít meghatározni, hogy a partíciók túl gyakoriak-e, és segít a szükséges partíciómódosítások végrehajtásában.
Annak érdekében, hogy az alkalmazás kezelje az időszakos hibákat, és hogy az adatok megmaradjanak, használjon újrapróbálkozási stratégiát visszalépéssel. Az Azure Storage ügyfélkódtár által használt alapértelmezett újrapróbálkozási szabályzat exponenciális visszalépéssel rendelkezik, amely megakadályozza az ütközéseket, és maximalizálja az alkalmazás átviteli sebességét.