Cum tzi-a placut matematica in scoala?
fgbogdan:
5% write - 95% read
adica sa se replice tot - nu numai anumite tabele sau parti din ele.
Problema cu replicatul tot este urmatoarea: read-urile sint locale, dar write-urile sint globale. Adica un write trebuie replicat intre toate nodurile.
Hai sa zicem ca ai 5 noduri. Sa luam 1000 de operatii, 50 sint write si 950 sint read. Indiferent care este tehnologia folosita, in conditii ideale (nici un retry) ca sa replici cel 50 de write-uri trebuie sa adaugi 50 de read-uri (cit citesti write-urile ca sa le shipezi la celelate noduri) si 200 de write-uri (cele 50 de write-uri de la cele 4 noduri partenere). Deci deodata ai 1000 de readuri si 250 de writeuri, ceea ce inseamna 80% read si 20% write. In plus, tu suportzi 1250 de operatii din care doar 1000 sint locale. Hai sa zicem ca firma are un success nebun (cel mai periculos lucru care se poate intimpla aplicatiei tale!) si deschide 20 de filiale/depozite sau ce sint nodurile tale. Acuma cele 1000 de tranzactii locale sau transformat, dupa aceasi formula, in 2000 de tranzacti, 50% read 50% write si doar 50% si doar 50% din capacitatea locala serveste cererile locale, restul este folosit doar sa shipeze si sa primeasca replici. Si 20 de noduri nu sint deloc o cifra serioasa, daca iei pur si simplu judetele din Romania ajungi repede la cifre mai mari.
Si ia in considerare ca acestea sint cele mai optimiste calcule. In realitate nici odata nu o sa ai success 100% si vor exista retry-uri, care vor altera si mai rau aceste calcule. In plus o aplicatzie optimizata pentru 95% read evident ca va avea o schema si indexsi pentru 95% read, si va avea problem serioase cind de fapt se fac 50% read-50% write.
Facind aceste calcule simple potzi usor demonstra ca cerintele originale sint exagerate. Ma indoiesc ca este chiar nevoie sa se replice
tot la totzi.
fgbogdan:
actualizare in timp real (stocuri si alte prostii)
sa se poata folosi aplicatia in mare masura a timpului
Orice design sincron trebuie sa ia in considerare ca practic daca un nod e picat intreaga aplicatie e picata. Hai sa zicem ca organizatia ta poate sa mentina un up-time de 98% (incluzind toate opririle pentru aplicare de patch-uri, toate problemele de hardware, si mai ales toate erorile de administrare/operare). Si sa consideram ca ISP-urile folosite au un uptime de 99.9% (putem cu totzii sa ne oprim din ris acuma). 5 noduri vor avea un uptime de (.98*.999)^^5 care inseamna 90% (ne putem juca cu formula, unii pot zice ca este (.98*.999)^^(5-1), altzii ca este .98^^5*.999, dar tot pe la aceleasi cifre ajungi). Adica 10% din timp aplicatia nu merge. 10 noduri e 80% uptime, iar 20 de noduri inseamna doar 65% uptime. Acuma sint convins ca orice beneficiar caruia ii prezintzi un timp de functionare de 65%
in conditzii ideale are toate motivele sa te dea afara pe usa.
Deci din start potzi exclude orice solutzie sincrona care cere ca celelate noduri sa fie online pentru a putea face un write local.
In momentul care treci de la sincron la asincron, cam tot ce stii despre operatzii in baza de date sau despre CRUD devine obsolete. Trebuie sa gindesti intermeni de cozi, mesaje, latenta, update conflict si asa mai departe.
Astea ar fi citeva idei de start ca sa-tzi dai seama de fapt ce ai in fatza. Sa obtzii ce vrei tu este
extrem de complicat, chiar si dupa ce ai relaxat bine de tot din cerintele care le-ai pus.
http://rusanu.com