Ovaj članak predstavlja sažetak rada "Žetva, prinos i skalabilni sustavi tolerancije" koji su objavili Eric Brewer & Amando Fox 1999. Svi citati koji nisu dodijeljeni su iz ovog rada.
Članak se bavi kompromisima između konzistentnosti i dostupnosti (CAP) za velike sustave. Vrlo je lako ukazati na CAP i ustvrditi da niti jedan sustav ne može imati dosljednost i dostupnost.
Ali, postoji kvaka. ZPP je pogrešno shvaćen na razne načine. Kao što Coda Hale objašnjava u svom izvrsnom postu na blogu "Ne možete žrtvovati toleranciju particija":
Od dosljednosti, dostupnosti i tolerancije particija CAP teorema, tolerancija particije je obavezna u distribuiranim sustavima. Ne možete ga ne odabrati. Umjesto ZPP-a, trebali biste razmisliti o svojoj dostupnosti u smislu prinosa (postotaka uspješno odgovorenih zahtjeva) i žetve (postotak potrebnih podataka koji su stvarno uključeni u odgovore) i koje će od ove dvije vaše žrtvovati kada se dogode kvarovi.Rad se fokusira na povećanje dostupnosti velikih sustava tolerancijom, zadržavanjem i izolacijom kvara:
Pretpostavljamo da klijenti postavljaju upite poslužiteljima, u kojem slučaju postoje najmanje dvije metrike za ispravno ponašanje: prinos, što je vjerojatnost ispunjavanja zahtjeva, i žetva, koja mjeri udio podataka koji se odražava u odgovoru, tj. cjelovitost odgovora na upit.Dvije metrike, žetva i prinos mogu se sažeti kako slijedi:
- Berba : podaci u odgovoru / ukupni podaci
Na primjer: Ako je jedan od čvorova u klasteru od 100 čvorova, žetva je 99% za vrijeme trajanja kvara.
- Prinos : zahtjevi završeni s uspjehom / ukupan broj zahtjeva
Napomena: Prinos se razlikuje od vremena rada. Prinos se bavi brojem zahtjeva, ne samo vremenom kada sustav nije mogao odgovoriti na zahtjeve.
Rad tvrdi da postoje određeni sustavi koji zahtijevaju savršeni odgovor na upite svaki put. Također, postoje sustavi koji s vremena na vrijeme mogu tolerirati nesavršene odgovore.
Da bismo povećali ukupnu dostupnost naših sustava, moramo pažljivo razmotriti potrebnu dosljednost i garancije dostupnosti koje mora pružiti.
Trgovanje berbom za prinos - vjerojatnosna dostupnost
Gotovo svi sustavi su vjerojatni, bez obzira shvaćaju li to ili ne. Konkretno, bilo koji sustav koji je 100% dostupan pod pojedinačnim greškama vjerovatno je cjelovito dostupan (budući da postoji vjerojatnost višestrukih kvarova koji nisu nula)U radu se govori o razumijevanju vjerojatnosne prirode dostupnosti. To pomaže u razumijevanju i ograničavanju utjecaja kvarova donošenjem odluka o tome što treba biti dostupno i s kakvim se greškama sustav može nositi.
Oni ocrtavaju linearnu degradaciju žetve u slučaju višestrukih kvarova na čvorovima. Berba je izravno proporcionalna broju čvorova koji ispravno funkcioniraju. Stoga se linearno smanjuje / povećava.
Dvije su strategije za povećanje prinosa:
- Slučajna raspodjela podataka na čvorovima
Ako jedan od čvorova padne, ponašanje kvara u prosjeku i u najgorem slučaju ne mijenja se. Ipak, ako raspodjela nije slučajna, ovisno o vrsti podataka, utjecaj kvara može varirati.
Na primjer, ako padne samo jedan od čvorova pohranjenih podataka koji se odnose na stanje korisničkog računa, cijeli bankovni sustav neće moći raditi.
- Kopiranje najvažnijih podataka
To smanjuje utjecaj u slučaju da jedan od čvorova koji sadrži podskup podataka visokog prioriteta padne.
Također poboljšava žetvu.
Još jedno zapaženo zapažanje izneseno u radu je da je moguće kopirati sve vaše podatke. To ne čini puno na poboljšanju vaše žetve / uroda, ali znatno povećava troškove rada. To je zato što Internet radi na temelju protokola s najboljim naporima koji nikada ne mogu garantirati 100% žetve / uroda.
Razgradnja primjene i ortogonalni mehanizmi
Druga se strategija fokusira na blagodati ortogonalnog dizajna sustava.
Započinje izjavom da su veliki sustavi sastavljeni od podsustava koji ne podnose kvarove. Ali ne uspijevaju na način koji omogućuje da cijeli sustav nastavi funkcionirati s određenim utjecajem na korisnost.
Stvarna korist je sposobnost pružanja upravljanja svakim podsustavom odvojeno, pružajući snažnu dosljednost ili postojano stanje samo za podsustave kojima je to potrebno, a ne za cijelu aplikaciju. Uštede mogu biti značajne ako samo nekoliko malih podsustava zahtijeva dodatnu složenost.U radu se navodi da su ortogonalne komponente potpuno neovisne jedna o drugoj. Oni nemaju sučelje vremena izvođenja s ostalim komponentama, osim ako ne postoji konfiguracijsko sučelje. To omogućuje da svaka pojedinačna komponenta samostalno otkaže i minimalizira njezin utjecaj na cjelokupni sustav.
Sastav ortogonalnih podsustava prebacuje teret provjere mogućih štetnih interakcija s vremena izvođenja na vrijeme sastavljanja, a postavljanje ortogonalnih zaštitnih mehanizama poboljšava robusnost za vrijeme izvođenja interakcija koje se događa, pružajući poboljšano zadržavanje grešaka.Cilj ovog rada bio je motivirati istraživanja na polju dizajniranja otpornih i visoko dostupnih sustava velikih razmjera.
Također, dobro razmislite o dosljednosti i dostupnosti jamstava koja aplikacija mora pružiti. Kao i kompromise koje je sposoban napraviti u smislu žetve u odnosu na prinos.
Ako vam se svidio ovaj rad, pritisnite tipku za pljeskanje kako bi ga vidjelo više ljudi. Hvala vam.
PS - Ako ste stigli toliko daleko i željeli biste primati e-poštu kad god objavim jedan od ovih postova, prijavite se ovdje.