Návrh pro dotazování

  • Článek

Řešení table service mohou být náročná na čtení, zápis nebo kombinaci těchto dvou řešení. Tento článek se zaměřuje na to, co je potřeba mít na paměti při návrhu služby Table service, která bude efektivně podporovat operace čtení. Návrh, který efektivně podporuje operace čtení, je obvykle také efektivní pro operace zápisu. Při návrhu pro podporu operací zápisu je však potřeba vzít v úvahu další aspekty, které jsou popsány v článku Návrh pro úpravu dat.

Dobrým výchozím bodem pro návrh řešení služby Table Service, které vám umožní efektivně číst data, je zeptat se: "Jaké dotazy bude moje aplikace muset spustit, aby načetla potřebná data ze služby Table Service?".

Poznámka

U služby Table service je důležité, aby byl návrh správný, protože je obtížné a nákladné ho později změnit. Například v relační databázi je často možné vyřešit problémy s výkonem jednoduše přidáním indexů do existující databáze: to není možnost u služby Table Service.

Tato část se zaměřuje na klíčové problémy, které je potřeba řešit při návrhu tabulek pro dotazování. Mezi témata probíraná v této části patří:

Jak vaše volba PartitionKey a RowKey ovlivňuje výkon dotazů

Následující příklady předpokládají, že služba Table Service ukládá entity zaměstnanců s následující strukturou (většina příkladů pro přehlednost vynechá vlastnost časového razítka):

Název sloupce Datový typ
PartitionKey (název oddělení) Řetězec
RowKey (ID zaměstnance) Řetězec
FirstName Řetězec
LastName Řetězec
Age (Věk) Integer
EmailAddress Řetězec

Článek Přehled služby Azure Table Storage popisuje některé z klíčových funkcí služby Azure Table Service, které mají přímý vliv na návrh dotazů. Výsledkem jsou následující obecné pokyny pro návrh dotazů služby Table Service. Všimněte si, že syntaxe filtru použitá v následujících příkladech pochází z rozhraní REST API služby Table Service. Další informace najdete v tématu Dotazování entit.

  • Bodový dotaz je nejúčinnější vyhledávání, které se má použít, a doporučuje se použít pro vyhledávání ve velkých objemech nebo vyhledávání vyžadujících nejnižší latenci. Takový dotaz může použít indexy k velmi efektivnímu vyhledání jednotlivé entity zadáním hodnot PartitionKey a RowKey . Například: $filter=(PartitionKey eq 'Sales') and (RowKey eq '2')
  • Druhý nejlepší je dotaz rozsahu, který používá PartitionKey a filtruje oblast hodnot RowKey k vrácení více než jedné entity. Hodnota PartitionKey identifikuje konkrétní oddíl a hodnoty RowKey identifikují podmnožinu entit v daném oddílu. Příklad: $filter=PartitionKey eq 'Sales' a RowKey ge 'S' a RowKey lt 'T'
  • Třetí nejlepší je kontrola oddílu , která používá PartitionKey a filtruje jinou vlastnost než klíč a která může vrátit více než jednu entitu. Hodnota PartitionKey identifikuje konkrétní oddíl a hodnoty vlastností se vyberou pro podmnožinu entit v daném oddílu. Příklad: $filter=PartitionKey eq 'Sales' a LastName eq 'Smith'
  • Prohledávání tabulky neobsahuje klíč oddílu a je velmi neefektivní, protože vyhledává všechny oddíly, které tvoří vaši tabulku, a hledá odpovídající entity. Provede kontrolu tabulky bez ohledu na to, jestli filtr používá klíč řádku. Příklad: $filter=Příjmení eq 'Jones'
  • Dotazy, které vracejí více entit, je vrátí seřazené v pořadí PartitionKey a RowKey . Abyste se vyhnuli uchýlování entit v klientovi, zvolte Klíč řádku , který definuje nejběžnější pořadí řazení.

Všimněte si, že použití "nebo" k zadání filtru založeného na hodnotách RowKey má za následek prohledávání oddílu a není považováno za dotaz na rozsah. Proto byste se měli vyhnout dotazům, které používají filtry, například: $filter=PartitionKey eq 'Sales' and (RowKey eq '121' nebo RowKey eq '322').

Příklady kódu na straně klienta, který používá klientskou knihovnu úložiště ke spouštění efektivních dotazů, najdete tady:

Příklady kódu na straně klienta, který dokáže zpracovat více typů entit uložených ve stejné tabulce, najdete tady:

Volba vhodného klíče oddílu

Volba PartitionKey by měla vyvážit potřebu povolit použití transakcí skupin entit (k zajištění konzistence) a požadavek na distribuci entit mezi více oddílů (aby se zajistilo škálovatelné řešení).

V jednom krajním případě byste mohli všechny své entity uložit do jednoho oddílu, ale to může omezit škálovatelnost vašeho řešení a zabránit službě Table Service v vyrovnávání zatížení požadavků. Na druhou stranu můžete na každý oddíl uložit jednu entitu, která by byla vysoce škálovatelná a která umožňuje službě Table Service vyrovnávat zatížení požadavků, ale která by vám zabránila v používání transakcí skupin entit.

Ideální partitionkey je ten, který umožňuje používat efektivní dotazy a který má dostatek oddílů, aby bylo vaše řešení škálovatelné. Obvykle zjistíte, že vaše entity budou mít vhodnou vlastnost, která vaše entity distribuuje mezi dostatečné oddíly.

Poznámka

Například v systému, který ukládá informace o uživatelích nebo zaměstnanech, může být Id uživatele vhodným klíčem oddílu. Můžete mít několik entit, které jako klíč oddílu používají dané ID uživatele. Každá entita, ve které jsou uložená data o uživateli, je seskupené do jednoho oddílu, a proto jsou tyto entity přístupné prostřednictvím transakcí skupin entit a jsou stále vysoce škálovatelné.

Při výběru klíče oddílu existují další aspekty, které souvisejí s tím, jak budete vkládat, aktualizovat a odstraňovat entity. Další informace najdete v tématu Návrh tabulek pro úpravy dat.

Optimalizace dotazů pro službu Table

Služba Table service automaticky indexuje vaše entity pomocí hodnot PartitionKey a RowKey v jednom clusterovém indexu, a proto je použití dotazů na body nejúčinnější. V clusterovaných indexech PartitionKey a RowKey však nejsou žádné jiné indexy než indexy.

Mnoho návrhů musí splňovat požadavky, aby bylo možné vyhledávat entity na základě více kritérií. Například vyhledání entit zaměstnanců na základě e-mailu, ID zaměstnance nebo příjmení. Vzory popsané v tématu Vzory návrhu tabulky řeší tyto typy požadavků a popisují způsoby, jak obejít skutečnost, že služba Table Service neposkytuje sekundární indexy:

  • Vzor sekundárního indexu uvnitř oddílu – Ukládejte více kopií každé entity pomocí různých hodnot RowKey (ve stejném oddílu), abyste umožnili rychlé a efektivní vyhledávání a alternativní pořadí řazení pomocí různých hodnot RowKey .
  • Vzor sekundárního indexu mezi oddíly – Ukládejte více kopií každé entity pomocí různých hodnot RowKey v samostatných oddílech nebo samostatných tabulkách, abyste umožnili rychlé a efektivní vyhledávání a alternativní pořadí řazení pomocí různých hodnot RowKey .
  • Vzor entit indexu – udržovat entity indexu, aby bylo možné efektivně vyhledávat, které vrací seznamy entit.

Řazení dat ve službě Table

Služba Table vrací entity seřazené vzestupně na základě PartitionKey a potom podle RowKey. Tyto klíče jsou řetězcové hodnoty, a pokud chcete zajistit správné řazení číselných hodnot, měli byste je převést na pevnou délku a vložit je do nul. Pokud například hodnota ID zaměstnance, kterou používáte jako Klíč řádku , je celočíselná hodnota, měli byste převést ID zaměstnance 123 na 00000123.

Mnoho aplikací má požadavky na používání dat seřazených v různých pořadích: například řazení zaměstnanců podle jména nebo podle data připojení. Následující vzory řeší alternativní pořadí řazení pro vaše entity:

  • Vzor sekundárního indexu uvnitř oddílu – Ukládejte více kopií každé entity pomocí různých hodnot RowKey (ve stejném oddílu), abyste umožnili rychlé a efektivní vyhledávání a alternativní pořadí řazení pomocí různých hodnot RowKey.
  • Vzor sekundárního indexu mezi oddíly – Ukládejte více kopií každé entity s použitím různých hodnot RowKey v samostatných oddílech v samostatných tabulkách, abyste umožnili rychlé a efektivní vyhledávání a alternativní pořadí řazení pomocí různých hodnot RowKey.
  • Vzor chvostu protokolu – pomocí hodnoty RowKey, která se seřadí podle data a času, načte n entit, které byly do oddílu naposledy přidány.

Další kroky