Použití nejvhodnějšího úložiště pro úlohu

Vyberte technologii úložiště, která je pro vaše data nejvhodnější, a také způsob jejího použití.

Pryč jsou časy, kdy byste všechna vaše data uložili do velké relační databáze SQL. Relační databáze jsou velmi vhodné v případě, kdy je potřeba poskytovat záruky modelu ACID pro transakce s relačními daty. Ale součástí jsou některé náklady:

• Dotazy můžou vyžadovat nákladná spojení.
• Data musí být normalizovaná a vyhovovat předdefinovanému schématu (schéma při zápisu).
• Spory o zámky mohou ovlivnit výkon.

V rozsáhlém řešení je pravděpodobné, že technologie jednoho datového úložiště nevyhoví všem vašim potřebám. Alternativy k relačním databázím zahrnují úložiště dvojic klíč/hodnota, dokumentové databáze, databáze vyhledávacího modulu, databáze časových řad, sloupcové databáze a databáze grafů. Každá z nich má výhody a nevýhody a různé typy dat se přirozeně hodí do některé z nich.

Katalog produktů může být například uložený v dokumentové databázi, jako je například Cosmos DB, která umožňuje flexibilní schéma. V takovém případě je popis každého produktu samostatným dokumentem. Pro dotazy na celý katalog můžete katalog indexovat a index uložit ve službě Azure Search. Inventář produktů je možné dát do databáze SQL, protože tato data vyžadují záruky modelu ACID.

Mějte na paměti, že data zahrnují více než jen trvalá data aplikací. Zahrnují také protokoly aplikací, události, zprávy a mezipaměti.

Doporučení

Nepoužívejte relační databáze pro všechno. Vezměte v úvahu jiná vhodná úložiště dat. Přečtěte si o volbě správného úložiště dat.

Přijměte polyglotickou trvalost. V rozsáhlém řešení je pravděpodobné, že technologie jednoho datového úložiště nevyhoví všem vašim potřebám.

Vezměte v úvahu typ dat. Například transakční data uložte do databáze SQL, dokumenty JSON uložte do databáze dokumentů, data telemetrie uložte do databáze časových řad, protokoly aplikací uložte do Elasticsearch a objekty blob do Azure Blob Storage.

Dávejte přednost dostupnosti před (silnou) konzistencí. Věta CAP říká, že distribuovaný systém musí dělat kompromisy mezi dostupností a konzistencí. (Síťové oddíly, ostatní fáze CAP věta se nikdy nedají zcela vyhnout.) Často můžete dosáhnout vyšší dostupnosti tím, že přijmete model konečné konzistence .

Vezměte v úvahu dovednosti vývojového týmu. Existují výhody použití polyglotické trvalosti, ale je možné to přehnat. Přijetí nové technologie úložiště dat vyžaduje novou sadu znalostí. Vývojový tým musí pochopit, jak využívat technologii naplno. Musí pochopit příslušné vzorce použití, způsob optimalizace dotazů, vyladění výkonu a další. Při zvažování technologií úložiště je to potřeba vzít v úvahu.

Používejte kompenzační transakce. Vedlejším účinkem polyglotické trvalosti je to, že jedna transakce může zapisovat data do několika různých úložišť. Pokud se něco nezdaří, použijte k vrácení zpět všech dokončených kroků kompenzační transakce.

Podívejte se na ohraničené kontexty. Termín ohraničené kontexty pochází z návrhu na základě domény. Ohraničený kontext je explicitní hranicí kolem modelu domény a definuje, na které části domény se model vztahuje. V ideálním případě se ohraničený kontext mapuje na subdoménu obchodní domény. Ohraničené kontexty ve vašem systému tvoří přirozené místo pro zvážení použití polyglotické trvalosti. Například produkty se mohou objevit v subdoméně katalogu produktů i v subdoméně inventáře produktů, ale je velmi pravděpodobné, že tyto dvě subdomény mají různé požadavky na ukládání, aktualizaci a dotazování na produkty.