Poznámka: Tento příspěvek je zastaralý. Nejaktuálnější verzi najdete zde.
tento příspěvek je zastaralý. Aktualizovanou verzi najdete zde. Záměrně zde nechávám tento článek, abych nerušil další weby, které se ke mně vracejí.
před Několika lety, budování výkonnosti v software, systém byl jednoduchý – buď zvýšení své hardwarové prostředky (scale up) nebo upravené vaše aplikace běžet efektivněji (ladění výkonu). Dnes existuje třetí možnost: horizontální škálování(měřítko).
horizontální škálování softwarových systémů se v posledních letech stalo nezbytným kvůli globální povaze výpočetní techniky a stále rostoucím nárokům na výkon aplikací. V mnoha případech již není přijatelné provozovat jeden server s jednou databází v jediném datovém centru sousedícím s ústředím vaší společnosti. K řešení dnešních obchodních výzev potřebujeme skutečně distribuovaná prostředí.
bohužel výkonnostní výhody, které horizontální škálování poskytuje, přicházejí s nákladovou složitostí. Distribuované systémy zavádějí do rovnice výkonu mnohem více faktorů, než existovalo dříve. Datové záznamy se liší mezi klienty/uzly na různých místech. Jednotlivé body selhání zničit systém up-time, a přerušované problémy sítě plížit se v nejhorším možném čase.
Tyto obavy o soudržnost (C), dostupnost (A), a partition tolerance (P) mezi distribuované systémy tvoří, co ~~Eric Brewer~~ razil jako CAP Teorém. Jednoduše řečeno, CAP teorém ukazuje, že jakýkoliv distribuovaný systém, nemůže záruka, C, a a P současně, spíše kompromisy musí být provedeny na bod-v-čas k dosažení úrovně výkonu a dostupnosti potřebné pro konkrétní úkol.
konzistence-všechny uzly vidí stejná data současně.
jednoduše řečeno, provedení operace čtení vrátí hodnotu poslední operace zápisu, která způsobí, že všechny uzly vrátí stejná data. Systém má konzistenci, pokud transakce začíná systémem v konzistentním stavu a končí systémem v konzistentním stavu. V tomto modelu, systém může (a má) posun do nekonzistentním stavu během transakce, ale celá transakce dostane vrácena zpět, pokud je chyba v kterékoli fázi procesu.
typické relační databáze jsou konzistentní: SQL Server, MySQL a PostgreSQL.
dostupnost-každý požadavek dostane odpověď na úspěch / neúspěch.
dosažení dostupnosti v distribuovaném systému vyžaduje, aby systém zůstal funkční 100% času. Každý klient dostane odpověď, bez ohledu na stav každého jednotlivého uzlu v systému. Tato metrika je triviální k měření: buď můžete odeslat příkazy pro čtení/zápis, nebo nemůžete.
k dispozici jsou také typické relační databáze: SQL Server, MySQL a PostgreSQL. To znamená, že relační databáze existují v prostoru CA-konzistence a dostupnost. Ca však není vyhrazena pouze pro relační databáze-některé nástroje zaměřené na dokumenty, jako je ElasticSearch, také spadají pod deštník CA.
tolerance oddílů-systém pokračuje v práci i přes ztrátu zprávy nebo částečné selhání.
většina lidí si myslí, že jejich úložiště dat jako jediný uzel v síti. „Toto je naše produkční instance SQL Serveru“. Každý, kdo spustil výrobní instanci déle než čtyři minuty, si rychle uvědomí, že to vytváří jediný bod selhání. Systém, který je tolerantní k oddílům, může vydržet jakékoli selhání sítě, které nevede k selhání celé sítě. Datové záznamy jsou dostatečně replikovány napříč kombinacemi uzlů a sítí, aby se systém udržel v průběhu přerušovaných výpadků.
úložné systémy, které spadají pod toleranci oddílů s konzistencí (CP): MongoDB, Redis, AppFabric Caching a MemcacheDB. CP systémy vytvářejí vynikající distribuované mezipaměti, protože každý klient získá stejná data a systém je rozdělen přes hranice sítě.
úložné systémy, které spadají pod toleranci oddílů s dostupností (AP), zahrnují DynamoDB, CouchDB a Cassandra.
Závěr
Distribuované systémy nám umožní dosáhnout úrovně výpočetní výkon a dostupnost, které byly prostě není k dispozici v yesteryears. Naše systémy mají vyšší výkon, nižší latenci a téměř 100% up-time v datových centrech, které pokrývají celý svět. Nejlepší ze všeho je, že dnešní systémy jsou provozovány na komoditním hardwaru, který je snadno dosažitelný a konfigurovatelný s náklady blížícími se 0$.
všechny tyto výpočetní výkon a přínos přichází za cenu, nicméně. Distribuované systémy jsou složitější než jejich protějšky s jednou sítí. Existuje mnoho dalších nástrojů a dovedností, které je třeba získat, aby se vytvořil skutečně škálovatelný a vysoce výkonný systém. Pochopení složitosti vzniklé v distribuovaných systémech, takže vhodné kompromisy pro úkol po ruce (SZP), a výběr správné nástroje pro práci jsou všechny důležité dovednosti ve světě, kde počítačové systémy jsou pohybující se ven, ne nahoru.
