Modelování dat pro úlohy na úrovni operátora

Podnikové aplikace nasazené v jedné oblasti můžou tento model návrhu aplikací obvykle ignorovat a bezpečně delegovat odpovědnost na vrstvu databáze, aby byla data spolehlivě dostupná. Toto chování neplatí pro aplikace na úrovni operátora, které musí být nasazené ve více oblastech. Nasazení ve více oblastech nutí architekta aplikace zvážit ohrožení zabezpečení, která je ochotný přijmout pro svá data.

CAP teorém

Databáze můžou poskytovat tři klíčové vlastnosti pro data, která spravují pro aplikaci, označované jako CAP:

• Konzistence: Čtení dat vrátí poslední zápis.
• Dostupnost: Každý požadavek obdrží platnou odpověď.
• Odolnost proti oddílům: Systém dál funguje i přes zpoždění nebo celkovou ztrátu komunikace mezi prvky.

Cap teorém uvádí, že vrstva databáze nemůže poskytnout všechny tyto tři vlastnosti pro stejná data současně v případě síťových oddílů. Architekt musí explicitně rozhodnout o návrhu, které z vlastností CAP upřednostní za jakých podmínek a jak řešit hraniční případy.

Podle CAP teorému může každá databáze zaručit pouze dvě ze tří možných vlastností pro stejná data současně v případě přítomnosti síťového oddílu.

Nasazení ve více oblastech znamená, že odolnost oddílů se stává významnou. Ve většině případů architekti na úrovni operátora upřednostňují odolnost a dostupnost oddílů před konzistencí. U každého typu dat musí architekt zvážit, jaké kompromisy jsou ochotni provést, vzhledem k hraničním případům.

Představte si například databázi systémových uživatelů. Je přijatelné, aby se uživatelská databáze přeřadila na jen pro čtení, pokud existuje síťový oddíl? Toto chování upřednostňuje konzistenci a dostupnost čtení před dostupností zápisu. Toto stanovení priority nemusí být vhodné, pokud je pro uživatele nepřijatelné, aby měl přístup k izolovanému webu po odvolání jeho oprávnění jinde. Popsaný scénář by vyžadoval blokování veškerého přístupu k databázi, pokud existuje oddíl, který upřednostňuje dostupnost zápisu před dostupností čtení.

Poznámka

Vytvořená ohrožení zabezpečení se můžou u různých databází v rámci stejné aplikace lišit, protože databáze budou pravděpodobně mít různé profily použití.

Tam, kde je konzistence ohrožením, musí se aplikace vypořádat s artefakty nekonzistence dat pomocí bezkonfliktních replikovaných datových typů (CRDT). Použití CRDT vyžaduje disciplínu při návrhu a implementaci aplikace. Jejich použití znamená, že slučování dat po událostech oddílů může datová vrstva automaticky zpracovat bez zásahu člověka nebo složité logiky na úrovni aplikace.

Důležité

Další podrobnosti o možnostech datových platforem pro klíčové úlohy najdete tady.

Architekt musí také pochopit kompromisy v datovém modelu, které byly provedeny v rámci závislých služeb. Tyto kompromisy mají vliv na službu poskytovanou do jejich aplikace, protože tyto kompromisy nemusí být v souladu s požadavky na úroveň aplikace.

Další krok

Projděte si oblast návrhu modelování stavu pro úlohy na úrovni operátora.

Oblast návrhu: Modelování stavu