Skaitymo ir rašymo atskyrimas
Kai įmonės verslas toliau plečiasi ir vartotojų skaičius žymiai didėja, pradinė duomenų bazė greičiausiai negalės išsilaikyti. Tada taip
- Mastelis, kuris išplečia aparatinės įrangos našumą, tačiau tikėtina, kad vartotojų skaičius ir toliau augs, o padidėjęs našumas netrukus bus suvalgytas.
- Skaitymo ir rašymo atskyrimas: duomenų bazė negali išsilaikyti, tai ne kas kita, kaip per daug skaitymo ir rašymo, ypač jei yra sudėtingų užklausų, pvz., populiariausių produktų per pastarąsias 24 valandas. Tam reikia labai sudėtingų SQL sakinių ir, žinoma, jis veikia lėtai.
Tačiau norint atskirti skaitymą ir rašymą, duomenų bazę reikia padalyti į pagrindines ir pavaldines bibliotekas.
Pagrindinės reliacinės duomenų bazės rinkoje palaiko duomenų replikavimą, todėl galite padalyti duomenų bazę į du vaidmenis: Master ir Slave, rašyti operacijas pagrindiniame ir sinchronizuoti pagrindinį serverį su kitais vergų serveriais.
Autonominės operacijos, tokios kaip skaitymo operacijos ir duomenų analizė, atliekamos Slave serveryje.
Žinome, kad daugelis programų internete yra skaitomos, todėl keli vergai gali dalytis apkrova ir užtikrinti duomenų prieinamumą bei teisingumą.
Tačiau atitinkamą pradinį programos kodą taip pat reikia modifikuoti, jį reikia pakeisti, kad duomenims rašyti būtų naudojama pagrindinė biblioteka, o skaitant duomenis būtų naudojama vergų biblioteka, o tai prilygsta perrašymui.
Sudėtingos užklausos
Tačiau net ir perrašius kodą, pastebėjau, kad našumas vis dar nebuvo žymiai pagerėjęs, nes buvo naudojama per daug sudėtingų užklausų, ir mes sakėme, kad duomenų bazės komponentas, kuris jungiasi yra labai našus.
Taigi ar galime naudoti atskirą lentelę populiariems pastarųjų 24 valandų produktams saugoti, kad tam reikėtų naudoti tik paprastą SQL.
Kitaip tariant, vienas duomenų bazės lentelių rinkinys netinka skirtingam elgesiui, pvz., ataskaitoms, paieškoms, operacijoms ir kt.
Dabartinė lentelė skirta duomenims įtraukti ir modifikuoti ir netinka sudėtingoms užklausoms.
Tačiau taip pat turime apsvarstyti, kaip atnaujinama ši užklausų bazė, ar galime toleruoti šį vėlavimą, ar ji gali būti neatnaujinta realiuoju laiku.
CQRS
Ar delsimas gali būti toleruojamas, reikia žiūrėti iš verslo perspektyvos, pavyzdžiui, populiariausi geriausi produktai per pastarąsias 24 valandas, šiek tiek pasenusi informacija neturi didelės įtakos, reikalingas tik galutinis nuoseklumas.
Galime naudoti CQRS (Command Query Responsibility Segregation), tai yra komandų atskyrimą komandoms pridėti ar modifikuoti nuo užklausos atsakomybės.
CQRS akcentuojamas skaitymo (užklausos) ir rašymo (komandos) atskyrimas, nes vartotojų skaitomi duomenys paprastai yra pasenę, todėl kodėl reikia skaityti iš duomenų bazės, galite tiesiogiai nustatyti skaitymo duomenų šaltinį. Tai gali būti talpykla, tai gali būti XML, JSON ir kt.
Kaip išspręsti anksčiau minėtą atnaujinimo problemą? Galite naudoti įvykį, t. y. įvykį, pvz., kai produktas parduodamas, galite publikuoti įvykį, kad modifikuotumėte pradinį skaitymo modelį.
Tokiu būdu sinchronizavimas tampa asinchroninis per įvykio mechanizmą.
Galiausiai, šį metodą geriausia naudoti tik sudėtingoms užklausoms, o originalios paprastos užklausos vis dar gaunamos reliacinėje duomenų bazėje. Kodėl? Kadangi naujos technologijos diegimas reikalauja kainos, pavyzdžiui, sinchroninių mutacijų žingsnių ir įvykių mechanizmų, negalime matyti tik naujų technologijų privalumų, o ne trūkumų.
|
Paskelbta 2020-05-04 09:58:50
|
|
|
|
