CAP tétel: magyarázat

Megjegyzés: Ez a bejegyzés elavult. A legfrissebb verziót itt találod.

ez a bejegyzés elavult. A frissített verziót itt találja. Szándékosan itt hagyom ezt a cikket, így nem zavarom meg a hozzám kapcsolódó más webhelyeket.

néhány évvel ezelőtt a teljesítmény szoftverrendszerré történő felépítése egyszerű volt – vagy növelte a hardver erőforrásait (méretezés), vagy módosította az alkalmazást, hogy hatékonyabban fusson (teljesítményhangolás). Ma van egy harmadik lehetőség: vízszintes méretezés (skálázás).

az elmúlt években szükségessé vált a szoftverrendszerek horizontális méretezése a számítástechnika globális jellege és az alkalmazások egyre növekvő teljesítményigénye miatt. Sok esetben már nem elfogadható egyetlen adatbázissal rendelkező kiszolgáló futtatása egyetlen adatközpontban, a vállalat székhelye mellett. Valóban elosztott környezetekre van szükségünk a mai üzleti kihívások kezeléséhez.

sajnos a vízszintes skálázás által nyújtott teljesítmény – előnyök költség-összetettségűek. Az elosztott rendszerek sokkal több tényezőt vezetnek be a teljesítményegyenletbe, mint korábban léteztek. Az adatrekordok az ügyfelek/csomópontok között eltérőek a különböző helyeken. Az egyes meghibásodási pontok elpusztítják a rendszer üzemidejét, az időszakos hálózati problémák pedig a lehető legrosszabb időben kúsznak fel.

ezek a konzisztencia (C), a rendelkezésre állás (A) és a partíció tolerancia (P) az elosztott rendszerek között alkotják azt, amit Eric Brewer ~~CAP-tételként alkotott. Egyszerűen fogalmazva, a CAP tétel azt mutatja, hogy bármely elosztott rendszer nem tudja garantálni C, A és P egyidejűleg, inkább kompromisszumokat kell tenni egy ponton-In-time elérni a teljesítmény szintjét és a rendelkezésre állás szükséges egy adott feladat.

konzisztencia-minden csomópont ugyanazokat az adatokat látja egyszerre.

egyszerűen fogalmazva, az olvasási művelet végrehajtása visszaadja a legutóbbi írási művelet értékét, ami az összes csomópont ugyanazokat az adatokat adja vissza. A rendszer akkor konzisztens, ha a tranzakció a rendszer konzisztens állapotával kezdődik, és azzal végződik, hogy a rendszer konzisztens állapotban van. Ebben a modellben a rendszer egy tranzakció során inkonzisztens állapotba léphet (és nem is változik), de az egész tranzakció visszagörgetésre kerül, ha a folyamat bármely szakaszában hiba lép fel.

a tipikus relációs adatbázisok konzisztensek: SQL Server, MySQL és PostgreSQL.

elérhetőség – minden kérés választ kap a sikerre/kudarcra.

a rendelkezésre állás elérése egy elosztott rendszerben megköveteli, hogy a rendszer az idő 100% – ában működőképes maradjon. Minden ügyfél választ kap, függetlenül a rendszer bármely egyes csomópontjának állapotától. Ezt a mutatót triviális mérni: vagy elküldhet olvasási/írási parancsokat, vagy nem.

tipikus relációs adatbázisok is rendelkezésre állnak: SQL Server, MySQL és PostgreSQL. Ez azt jelenti, hogy relációs adatbázisok léteznek a CA térben-konzisztencia és elérhetőség. A CA azonban nem csak a relációs adatbázisok számára van fenntartva – néhány dokumentumorientált eszköz, például az ElasticSearch szintén a CA égisze alá tartozik.

partíciós tolerancia – a rendszer az üzenetvesztés vagy részleges meghibásodás ellenére is működik.

a legtöbb ember úgy gondol az adattárolóra, mint a hálózat egyetlen csomópontjára. “Ez a termelési SQL Server példányunk”. Bárki, aki több mint négy percig futtatta a termelési példányt, gyorsan rájön, hogy ez egyetlen hibapontot hoz létre. A partíció-toleráns rendszer bármilyen mennyiségű hálózati hibát képes fenntartani, amely nem eredményezi a teljes hálózat meghibásodását. Az adatrekordok megfelelően replikálódnak a csomópontok és hálózatok kombinációi között, hogy a rendszer időszakos leállások esetén is fennmaradjon.

a konzisztencia (CP) Partíciótűrés alá tartozó tárolórendszerek: MongoDB, Redis, AppFabric Caching és MemcacheDB. A CP rendszerek kiváló elosztott gyorsítótárakat tesznek lehetővé, mivel minden ügyfél ugyanazokat az adatokat kapja, és a rendszer a hálózat határain túl van particionálva.

azok a tárolórendszerek, amelyek a rendelkezésre állási (Ap) Partíciótűrés alá tartoznak, a DynamoDB, a CouchDB és a Cassandra.

elavult CAP keretrendszer – ne használja

következtetés

az elosztott rendszerek lehetővé teszik számunkra, hogy olyan számítási teljesítményt és rendelkezésre állást érjünk el, amely az elmúlt években egyszerűen nem volt elérhető. Rendszereink nagyobb teljesítményt, alacsonyabb késleltetést és közel 100%-os üzemidőt biztosítanak az egész földgolyót lefedő adatközpontokban. A legjobb az egészben, hogy a mai rendszerek olyan árucikk hardvereken futnak, amelyek könnyen beszerezhetők és konfigurálhatók, a költségek megközelítik a 0 dollárt.

ennek a számítási teljesítménynek és előnynek azonban ára van. Az elosztott rendszerek összetettebbek, mint az egyhálózatú társaik. Sokkal több eszközt és készséget kell elsajátítani ahhoz, hogy valóban skálázható, nagy teljesítményű rendszert hozzunk létre. Az elosztott rendszerek összetettségének megértése, az adott feladat megfelelő kompromisszumainak megteremtése (CAP), valamint a munkához megfelelő eszköz kiválasztása mind kritikus készségek egy olyan világban, ahol a számítástechnikai rendszerek elmozdulnak, nem pedig felfelé.



+