Méretezhető és nagy teljesítményű táblák tervezése
Tipp.
A cikk információi az eredeti Azure Table Storage-ra vonatkoznak. Ugyanezek a fogalmak vonatkoznak az újabb Azure Cosmos DB for Tablere is, amely nagyobb teljesítményt és rendelkezésre állást, globális elosztást és automatikus másodlagos indexeket kínál. Fogyasztásalapú kiszolgáló nélküli módban is elérhető. Az Azure Cosmos DB-ben és az Azure Table Storage-ban található Table API között van néhány funkcióbeli különbség . További információ: Azure Cosmos DB for Table. A könnyebb fejlesztés érdekében mostantól egységes Azure Tables SDK-t biztosítunk, amely az Azure Table Storage és az Azure Cosmos DB for Table célként való megcélzására is használható.
Skálázható és teljesítményalapú táblák tervezéséhez figyelembe kell vennie olyan tényezőket, mint a teljesítmény, a méretezhetőség és a költség. Ha korábban relációs adatbázisok sémáit tervezte, ezek a szempontok ismerősek, de bár vannak hasonlóságok az Azure Table Service Storage-modell és a relációs modellek között, fontos különbségek is vannak. Ezek a különbségek általában különböző kialakításokhoz vezetnek, amelyek a relációs adatbázisokban jártas személyek számára ellentétesen vagy helytelenül néznek ki, mégis érdemes lehet noSQL-kulcsokat/értéktárakat, például az Azure Table szolgáltatást tervezni. A tervezési különbségek nagy része azt tükrözi, hogy a Table szolgáltatás olyan felhőalapú alkalmazásokat támogat, amelyek több milliárd entitást (vagy sorokat tartalmazhatnak a relációs adatbázis terminológiájában) vagy olyan adathalmazokat, amelyeknek nagy tranzakciómennyiségeket kell támogatniuk. Ezért másképp kell gondolnia az adatok tárolására, és meg kell értenie a Table szolgáltatás működését. A jól megtervezett NoSQL-adattár lehetővé teszi, hogy a megoldás sokkal tovább és alacsonyabb költséggel méretezhető legyen, mint egy relációs adatbázist használó megoldás. Ez az útmutató segít az alábbi témakörökben.
Az Azure Table szolgáltatás ismertetése
Ez a szakasz kiemeli a Table szolgáltatás néhány kulcsfontosságú funkcióját, amelyek különösen fontosak a teljesítmény és a méretezhetőség tervezése szempontjából. Ha még nem használta az Azure Storage-t és a Table szolgáltatást, először olvassa el az Azure Table Storage használatának első lépéseit a .NET használatával, mielőtt elolvassa a cikk hátralévő részét. Bár az útmutató középpontjában a Table szolgáltatás áll, az Azure Queue- és Blob-szolgáltatások ismertetését, valamint azt, hogy hogyan használhatja őket a Table szolgáltatással.
Mi a Table szolgáltatás? Ahogy a névtől várható, a Table szolgáltatás táblázatos formátumot használ az adatok tárolásához. A standard terminológiában a tábla minden sora egy entitást jelöl, az oszlopok pedig az entitás különböző tulajdonságait tárolják. Minden entitáshoz tartozik egy kulcspár, amely egyedileg azonosítja azt, és egy időbélyeg-oszlop, amelyet a Table szolgáltatás az entitás legutóbbi frissítésének nyomon követésére használ. A program automatikusan alkalmazza az időbélyeget, és nem írhatja felül manuálisan az időbélyeget tetszőleges értékkel. A Table szolgáltatás ezt az utolsó módosítású időbélyeget (LMT) használja az optimista egyidejűség kezelésére.
Feljegyzés
A Table service REST API-műveletei az LMT-ből származó ETag-értéket is visszaadják. Ez a dokumentum az ETag és az LMT kifejezéseket használja felcserélhetően, mivel ugyanazokra az alapul szolgáló adatokra hivatkoznak.
Az alábbi példa egy egyszerű táblatervet mutat be az alkalmazottak és részlegek entitásainak tárolására. Az útmutató későbbi részében bemutatott példák közül sok erre az egyszerű kialakításra épül.
| PartitionKey | RowKey | Időbélyegző | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | Részleg | 2014-08-22T00:50:30Z |
|
||||||||
| Sales | 00010 | 2014-08-22T00:50:44Z |
|
Eddig ezek az adatok a relációs adatbázisban lévő táblákhoz hasonlóan jelennek meg, és a fő különbségek a kötelező oszlopok, valamint a több entitástípus ugyanabban a táblában való tárolásának lehetősége. Emellett a felhasználó által definiált tulajdonságok, például a FirstName vagy az Age is rendelkezik adattípussal, például egész számokkal vagy sztringekkel, akárcsak egy relációs adatbázis oszlopa. Bár a relációs adatbázisoktól eltérően a Table szolgáltatás séma nélküli jellege azt jelenti, hogy egy tulajdonságnak nem kell azonos adattípussal rendelkeznie az egyes entitásokon. Ha összetett adattípusokat szeretne egyetlen tulajdonságban tárolni, szerializált formátumot kell használnia, például JSON-t vagy XML-t. A táblaszolgáltatásról, például a támogatott adattípusokról, a támogatott dátumtartományokról, az elnevezési szabályokról és a méretkorlátozásokról további információt a Table Service adatmodelljének ismertetése című témakörben talál.
A PartitionKey és a RowKey kiválasztása alapvető fontosságú a jó táblatervezéshez. A táblában tárolt entitásoknak a PartitionKey és a RowKey egyedi kombinációjával kell rendelkezniük. A relációs adatbázistáblák kulcsaihoz hasonlóan a PartitionKey és a RowKey értékek indexelve létrehoznak egy fürtözött indexet a gyors keresések engedélyezéséhez. A Table szolgáltatás azonban nem hoz létre másodlagos indexeket, ezért a PartitionKey és a RowKey az egyetlen indexelt tulajdonság. A táblázattervezési mintákban ismertetett minták némelyike bemutatja, hogyan lehet megkerülni ezt a látszólagos korlátozást.
A táblák egy vagy több partícióból állnak, és számos tervezési döntés a megoldás optimalizálásához megfelelő PartitionKey és RowKey kiválasztásával kapcsolatos. A megoldások egyetlen táblából állhatnak, amely az összes entitást partíciókba rendezve tartalmazza, de általában egy megoldás több táblával rendelkezik. A táblák segítségével logikusan rendszerezheti az entitásokat, hozzáférés-vezérlési listákkal kezelheti az adatokhoz való hozzáférést, és egyetlen tárolási művelettel elvethet egy teljes táblát.
Táblapartíciók
A fióknév, a táblanév és a PartitionKey együttesen azonosítja azt a partíciót a tárolási szolgáltatásban, amelyben a táblaszolgáltatás tárolja az entitást. Az entitások címzési sémájának részeként a partíciók definiálják a tranzakciók hatókörét (lásd alább az entitáscsoport tranzakcióit ), és a táblaszolgáltatás skálázásának alapját képezik. A partíciókról további információt a Table Storage teljesítmény- és méretezhetőségi ellenőrzőlistájában talál.
A Table szolgáltatásban az egyes csomópontok egy vagy több teljes partíciót használnak, a szolgáltatás pedig dinamikusan terheléselosztási partíciókkal skálázható a csomópontok között. Ha egy csomópont terhelés alatt áll, a táblaszolgáltatás feloszthatja az adott csomópont által kiszolgált partíciók tartományát különböző csomópontokra; ha a forgalom csökken, a szolgáltatás a csendes csomópontok partíciótartományait egyetlen csomópontra egyesítheti.
A Table szolgáltatás belső részleteiről és különösen a partíciók kezelésének módjáról a Microsoft Azure Storage: Magas rendelkezésre állású felhőalapú tárolási szolgáltatás erős konzisztenciával című tanulmányában olvashat.
Entitáscsoport tranzakciói
A Table service-ben az entitáscsoport-tranzakciók (EGT-k) az egyetlen beépített mechanizmus, amely atomi frissítéseket hajt végre több entitáson. Az EGT-eket néha kötegtranzakcióknak is nevezik. Az EGT-ek csak ugyanazon a partíción tárolt entitásokon működhetnek (vagyis ugyanazzal a partíciókulcszal egy adott táblában). Ezért bármikor, amikor atomi tranzakciós viselkedésre van szükség több entitás között, gondoskodnia kell arról, hogy ezek az entitások ugyanabban a partícióban legyenek. Ez gyakran oka annak, hogy több entitástípust is ugyanabban a táblában (és partícióban) tart, és nem használ több táblát a különböző entitástípusokhoz. Egyetlen EGT legfeljebb 100 entitáson működhet. Ha több egyidejű EGT-t küld feldolgozásra, fontos gondoskodni arról, hogy ezek az EGT-k ne működjenek olyan entitásokon, amelyek gyakoriak a teljes EGA-kban; ellenkező esetben a feldolgozás késleltethető.
Az EGT-k emellett potenciális kompromisszumot is bevezetnek a tervezés során történő értékeléshez. Ez azt jelzi, hogy a több partíció használata növeli az alkalmazás méretezhetőségét, mivel az Azure több lehetőséget kínál a csomópontok közötti terheléselosztási kérelmekre. A további partíciók használata azonban korlátozhatja az alkalmazás atomi tranzakciók végrehajtását és az adatok erős konzisztenciájának fenntartását. Emellett vannak olyan konkrét méretezhetőségi célok egy partíció szintjén, amelyek korlátozhatják az egy csomópontra várható tranzakciók átviteli sebességét. Az Azure Standard Storage-fiókok méretezhetőségi céljairól a standard tárfiókok méretezhetőségi céljait ismertető cikkben talál további információt. 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.
Kapacitással kapcsolatos szempontok
Az alábbi táblázat a kapacitás-, méretezhetőség- és teljesítménycélokat ismerteti a Table Storage esetében.
| Erőforrás | Cél |
|---|---|
| Az Azure-tárfiókban található táblázatok száma | Csak a tárfiók kapacitása korlátozza |
| A partíciók száma a táblázatban | Csak a tárfiók kapacitása korlátozza |
| Entitások száma egy partíción belül | Csak a tárfiók kapacitása korlátozza |
| Egyetlen táblázat maximális mérete | 500 TiB |
| Egyetlen entitás maximális mérete, az összes tulajdonságértéket beleértve | 1 MiB |
| Tulajdonságok maximális száma egy táblázatentitásban | 255 (a három rendszertulajdonságot – PartitionKey, RowKey és Timestamp – is beleértve) |
| Egyedi tulajdonság maximális teljes mérete egy entitásban | Tulajdonságtípustól függően változik. További információt a Table Service adatmodelljét ismertető témakör tulajdonságtípusokkal foglalkozó részében talál. |
| A PartitionKey mérete | Legfeljebb 1024 karakter hosszúságú sztring |
| A RowKey mérete | Legfeljebb 1024 karakter hosszúságú sztring |
| Az entitáscsoport-tranzakció mérete | Egy tranzakció legfeljebb 100 entitást tartalmazhat, és a hasznos adat méretének 4 MiB értéknél kisebbnek kell lennie. Egy entitáscsoport-tranzakció egy entitást legfeljebb egyszer frissíthet. |
| Tárolt hozzáférési szabályzatok táblázatonkénti maximális száma | 5 |
| Maximális kérelemmennyiség tárfiókonként | 20 000 tranzakció másodpercenként, 1 KiB entitásméretet feltételezve |
| Az átviteli sebesség célértéke egyetlen táblázatpartíció esetében (1 KiB méretű entitások) | Legfeljebb 2000 entitás másodpercenként |
Költségekkel kapcsolatos szempontok
A table storage viszonylag olcsó, de a Table service-megoldások kiértékelésének részeként a kapacitáshasználatra és a tranzakciók mennyiségére vonatkozó költségbecsléseket is tartalmaznia kell. Számos esetben azonban a denormalizált vagy duplikált adatok tárolása a megoldás teljesítményének vagy méretezhetőségének javítása érdekében érvényes módszer. A díjszabással kapcsolatos további információkért tekintse meg az Azure Storage díjszabását.