Tervezés lekérdezéshez
A táblaszolgáltatás-megoldások olvasásigényesek, írásigényesek vagy a kettő kombinációja. Ez a cikk az olvasási műveletek hatékony támogatása érdekében a Table szolgáltatás tervezésekor figyelembe venni kívánt szempontokat ismerteti. Az olvasási műveleteket hatékonyan támogató kialakítás általában írási műveletekhez is hatékony. Az írási műveletek támogatásának tervezésekor azonban további szempontokat is figyelembe kell venni, amelyeket az Adatmódosítás tervezése című cikkben talál.
Az adatok hatékony olvasását lehetővé tevő Table service-megoldás megtervezésének jó kiindulópontja a "Milyen lekérdezéseket kell végrehajtania az alkalmazásnak a szükséges adatok table szolgáltatásból való lekéréséhez?"
Megjegyzés
A Table szolgáltatással fontos, hogy a terv előre legyen javítva, mert később nehéz és költséges módosítani. Például egy relációs adatbázisban gyakran megoldhatók a teljesítményproblémák egyszerűen úgy, hogy indexeket ad hozzá egy meglévő adatbázishoz: ez nem egy lehetőség a Table szolgáltatásban.
Ez a szakasz a táblák lekérdezéshez való tervezésekor felmerülő legfontosabb problémákra összpontosít. Az ebben a szakaszban tárgyalt témakörök a következők:
- A PartitionKey és a RowKey választásának hatása a lekérdezési teljesítményre
- A megfelelő PartitionKey kiválasztása
- Lekérdezések optimalizálása a Table szolgáltatáshoz
- Adatok rendezése a Table szolgáltatásban
A PartitionKey és a RowKey választásának hatása a lekérdezési teljesítményre
Az alábbi példák feltételezik, hogy a táblaszolgáltatás az alábbi struktúrájú alkalmazotti entitásokat tárolja (a legtöbb példa kihagyja a Timestamp tulajdonságot az egyértelműség érdekében):
| Oszlop neve | Adattípus |
|---|---|
| PartitionKey (részleg neve) | Sztring |
| RowKey (alkalmazott azonosítója) | Sztring |
| FirstName | Sztring |
| LastName | Sztring |
| Életkor | Egész szám |
| EmailAddress | Sztring |
Az Azure Table Storage áttekintése című cikk az Azure Table szolgáltatás néhány olyan fő funkcióját ismerteti, amelyek közvetlen hatással vannak a lekérdezések tervezésére. Ezek a table service-lekérdezések tervezésére vonatkozó alábbi általános irányelveket eredményezik. Vegye figyelembe, hogy az alábbi példákban használt szűrőszintaxis a Table service REST API-ból származik, további információt a Lekérdezési entitások című témakörben talál.
- A pont-lekérdezés a leghatékonyabban használható keresés, és ajánlott nagy mennyiségű kereséshez vagy kisebb késést igénylő keresésekhez használni. Az ilyen lekérdezések az indexekkel nagyon hatékonyan kereshetnek meg egy adott entitást a PartitionKey és a RowKey értékek megadásával. Például: $filter=(PartitionKey eq 'Sales') és (RowKey eq '2')
- A második legjobb egy olyan tartomány-lekérdezés , amely a PartitionKey paramétert használja, és a RowKey értékek tartományán szűrőket használ egynél több entitás visszaadásához. A PartitionKey érték egy adott partíciót azonosít, a RowKey értékek pedig az adott partíció entitásainak egy részét azonosítják. Például: $filter=PartitionKey eq 'Sales' és RowKey ge 'S' és RowKey lt 'T'
- A harmadik legjobb megoldás egy partícióvizsgálat , amely a PartitionKey tulajdonságot használja, és egy másik nem kulcstulajdonság szűrőit használja, és amely egynél több entitást is visszaadhat. A PartitionKey érték egy adott partíciót azonosít, a tulajdonságértékek pedig az adott partíció entitásainak egy részhalmazához lesznek kiválasztva. Például: $filter=PartitionKey eq 'Sales' és LastName eq 'Smith'
- A táblavizsgálat nem tartalmazza a PartitionKey elemet, és nagyon nem hatékony, mert a táblát alkotó összes partíciót megkeresi az egyező entitások között. Táblavizsgálatot végez, függetlenül attól, hogy a szűrő használja-e a Sorkulcsot. Például: $filter=LastName eq 'Jones'
- A több entitást visszaadó lekérdezések partitionKey és RowKey sorrendben rendezve adják vissza őket. Ha el szeretné kerülni, hogy az ügyfél entitásait használja, válasszon egy Sorkulcsot , amely a leggyakoribb rendezési sorrendet határozza meg.
Vegye figyelembe, hogy ha a RowKey értékek alapján "vagy" szűrőt ad meg, az partícióvizsgálatot eredményez, és nem lesz tartomány lekérdezésként kezelve. Ezért kerülje a szűrőket használó lekérdezéseket, például: $filter=PartitionKey eq "Sales" és (RowKey eq '121' vagy RowKey eq '322')
Példák az ügyféloldali kódra, amely a Storage-ügyfélkódtárat használja a hatékony lekérdezések végrehajtásához, lásd:
- Pont típusú lekérdezés végrehajtása a Storage-ügyfélkódtár használatával
- Több entitás lekérése a LINQ használatával
- Kiszolgálóoldali vetület
Példák az ügyféloldali kódra, amely képes kezelni az ugyanabban a táblában tárolt több entitástípust, lásd:
A megfelelő PartitionKey kiválasztása
A PartitionKey kiválasztásának ki kell egyensúlyoznia az entitáscsoport-tranzakciók használatának engedélyezésének szükségességét (a konzisztencia biztosítása érdekében) az entitások több partíció közötti elosztásának követelményével szemben (a skálázható megoldás biztosítása érdekében).
Egy szélsőséges esetben az összes entitást egyetlen partícióban tárolhatja, de ez korlátozhatja a megoldás méretezhetőségét, és megakadályozhatja, hogy a táblaszolgáltatás terheléselosztási kéréseket tudjon kiosztani. A másik szélsőséges esetben partíciónként egy entitást tárolhat, amely nagy mértékben méretezhető lenne, és amely lehetővé teszi a táblaszolgáltatás számára a kérelmek terheléselosztását, de ez megakadályozná az entitáscsoport-tranzakciók használatát.
Az ideális PartitionKey olyan, amely lehetővé teszi hatékony lekérdezések használatát, és amelyek elegendő partícióval rendelkeznek a megoldás skálázhatóságának biztosításához. Általában azt fogja tapasztalni, hogy az entitások megfelelő tulajdonságot kapnak, amely elosztja az entitásokat a megfelelő partíciók között.
Megjegyzés
Például egy olyan rendszerben, amely a felhasználókkal vagy az alkalmazottakkal kapcsolatos információkat tárolja, a UserID jó PartitionKey lehet. Előfordulhat, hogy több entitás is rendelkezik, amelyek egy adott UserID azonosítót használnak partíciókulcsként. A felhasználó adatait tároló entitások egyetlen partícióba vannak csoportosítva, így ezek az entitások entitáscsoport-tranzakciókon keresztül érhetők el, miközben továbbra is nagy mértékben méretezhetők.
A PartitionKey kiválasztásakor további szempontokat is figyelembe kell venni, amelyek az entitások beszúrásával, frissítésével és törlésével kapcsolatosak. További információ: Táblák tervezése adatmódosításhoz.
Lekérdezések optimalizálása a Table szolgáltatáshoz
A Table szolgáltatás automatikusan indexeli az entitásokat a PartitionKey és a RowKey értékek használatával egyetlen fürtözött indexben, ezért a pont típusú lekérdezések a leghatékonyabbak. A PartitionKey és a RowKey fürtözött indexén kívül azonban nincs más index.
Számos tervnek meg kell felelnie az entitások több feltételen alapuló keresésének engedélyezéséhez szükséges követelményeknek. Például az alkalmazotti entitások keresése e-mail, alkalmazottazonosító vagy vezetéknév alapján. A Table Design Patterns (Táblatervezési minták ) című cikkben ismertetett minták az ilyen típusú követelményekre mutatnak be, és ismertetik annak megkerülésének módját, hogy a Table szolgáltatás nem biztosít másodlagos indexeket:
- Partíción belüli másodlagos indexminta – Az entitások több példányát tárolja különböző RowKey-értékekkel (ugyanabban a partícióban), hogy gyors és hatékony kereséseket és alternatív rendezési sorrendeket biztosíthasson különböző RowKey-értékek használatával.
- Particionálások közötti másodlagos indexminta – Az egyes entitások több példányát tárolja különböző RowKey-értékekkel külön partíciókban vagy külön táblákban, hogy gyors és hatékony kereséseket és alternatív rendezési sorrendeket biztosíthasson különböző RowKey-értékek használatával.
- Indexentitások mintája – Indexentitások karbantartása az entitáslistákat visszakereső hatékony keresések engedélyezéséhez.
Adatok rendezése a Table szolgáltatásban
A Table service növekvő sorrendbe rendezett entitásokat ad vissza a PartitionKey , majd a RowKey alapján. Ezek a kulcsok sztringértékek, és annak biztosítása érdekében, hogy a numerikus értékek megfelelően legyenek rendezve, alakítsa át őket rögzített hosszúságúra, és nullákkal jelölje meg őket. Ha például a Sorkulcsként használt alkalmazottazonosító érték egész szám, akkor a 123-as alkalmazotti azonosítót 00000123 kell konvertálnia.
Számos alkalmazásnak különböző megrendelések szerint kell adatokat használnia: például az alkalmazottak név szerinti rendezését vagy a dátumhoz való csatlakozást. Az alábbi minták az entitások rendezési sorrendjeinek alternatív megoldását ismertetik:
- Partíción belüli másodlagos indexminta – Az entitások több példányát tárolja különböző RowKey-értékekkel (ugyanabban a partícióban), hogy gyors és hatékony kereséseket és alternatív rendezési sorrendeket biztosíthasson különböző RowKey-értékek használatával.
- Particionálások közötti másodlagos indexminta – Az egyes entitások több példányát tárolja különböző RowKey-értékekkel külön partíciókban, külön táblákban, hogy a különböző RowKey-értékek használatával gyors és hatékony kereséseket és alternatív rendezési sorrendeket lehessen létrehozni.
- Naplószél minta – A partícióhoz legutóbb hozzáadott n entitások lekérése egy fordított dátum és idő sorrendben rendezett RowKey érték használatával.