Návrh pro úpravu dat

Tento článek se zaměřuje na aspekty návrhu pro optimalizaci vkládání, aktualizací a odstraňování. V některých případech budete muset vyhodnotit kompromis mezi návrhy, které optimalizují dotazování proti návrhům, které optimalizují úpravy dat stejně jako v návrzích pro relační databáze (i když techniky pro správu kompromisů při návrhu se v relační databázi liší). Oddíl Vzory návrhu tabulky popisuje některé podrobné vzory návrhu pro službu Table Service a zdůrazňuje některé z těchto kompromisů. V praxi zjistíte, že mnoho návrhů optimalizovaných pro dotazování entit funguje dobře i pro úpravy entit.

Optimalizace výkonu operací vložení, aktualizace a odstranění

Pokud chcete aktualizovat nebo odstranit entitu, musíte ji umět identifikovat pomocí hodnot PartitionKey a RowKey . V tomto ohledu by vaše volba PartitionKey a RowKey pro úpravu entit měla splňovat kritéria podobná vaší volbě pro podporu dotazů na body, protože chcete identifikovat entity co nejefektivněji. K vyhledání entity ke zjištění hodnot PartitionKey a RowKey, které potřebujete aktualizovat nebo odstranit, nechcete používat neefektivní prohledávání oddílů nebo tabulek .

Následující vzory v části Vzory návrhu tabulky řeší optimalizaci výkonu nebo operace vložení, aktualizace a odstranění:

• Model odstranění velkého objemu – Umožňuje odstranění velkého objemu entit uložením všech entit pro souběžné odstranění do jejich vlastní samostatné tabulky. Entity odstraníte odstraněním tabulky.
• Model datových řad – pokud chcete minimalizovat počet požadavků, které jste udělali, ukládejte celou datovou řadu do jedné entity.
• Vzor širokých entit – k ukládání logických entit s více než 252 vlastnostmi použijte více fyzických entit.
• Vzor velkých entit – k ukládání velkých hodnot vlastností použijte úložiště objektů blob.

Zajištění konzistence uložených entit

Dalším klíčovým faktorem, který ovlivňuje výběr klíčů pro optimalizaci úprav dat, je způsob zajištění konzistence pomocí atomických transakcí. Egt můžete použít pouze k provozu s entitami uloženými ve stejném oddílu.

Následující vzory v článku Vzory návrhu tabulek se týkají správy konzistence:

• Vzor sekundárního indexu uvnitř oddílů – Uložte 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í řazení pomocí různých hodnot RowKey .
• Vzor sekundárního indexu mezi oddíly – Uložte 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í řazení pomocí různých hodnot RowKey .
• Model nakonec konzistentních transakcí – Povolte nakonec konzistentní chování napříč hranicemi oddílů nebo hranice systému úložiště pomocí front Azure.
• Vzor entit indexu – Udržujte entity indexu, abyste umožnili efektivní vyhledávání, které vrací seznamy entit.
• Model denormalizace – kombinování souvisejících dat do jedné entity vám umožní načíst všechna potřebná data pomocí dotazu na jeden bod.
• Model datových řad – pokud chcete minimalizovat počet požadavků, které jste udělali, ukládejte celou datovou řadu do jedné entity.

Informace o transakcích skupin entit najdete v části Transakce skupin entit.

Zajistěte, aby návrh pro efektivní úpravy usnadnil efektivní dotazy.

V mnoha případech vede návrh pro efektivní dotazování k efektivním úpravám, ale vždy byste měli vyhodnotit, jestli je to případ vašeho konkrétního scénáře. Některé vzory v článku Vzory návrhu tabulek explicitně vyhodnocují kompromisy mezi dotazováním a úpravou entit a měli byste vždy vzít v úvahu počet jednotlivých typů operací.

Následující vzory v článku Vzory návrhu tabulek řeší kompromisy mezi návrhem pro efektivní dotazy a návrhem pro efektivní úpravu dat:

• Vzor složeného klíče – Pomocí složených hodnot RowKey umožníte klientovi vyhledat související data pomocí dotazu na jeden bod.
• Vzor chvostu protokolu – načte n entit, které byly do oddílu naposledy přidány, pomocí hodnoty RowKey , která se seřadí v opačném pořadí podle data a času.