Lasīšanas un rakstīšanas atdalīšana
Ja uzņēmuma bizness turpina paplašināties un lietotāju skaits ievērojami palielinās, sākotnējā datu bāze, visticamāk, nespēs sevi uzturēt. Tad jā
- Mērogošana, kas paplašina aparatūras veiktspēju, taču ir iespējams, ka lietotāju skaits turpinās pieaugt, un palielinātā veiktspēja drīz tiks apēsta.
- Lasīšanas un rakstīšanas atdalīšana: Datu bāze nevar noturēties, tas nav nekas cits kā pārāk daudz lasīšanas un rakstīšanas, it īpaši, ja ir daži sarežģīti vaicājumi, piemēram, populārākie produkti pēdējo 24 stundu laikā. Tas prasa ļoti sarežģītus SQL paziņojumus, un, protams, tas ir lēns.
Tomēr, lai atdalītu lasīšanu un rakstīšanu, datu bāze ir jāsadala galvenajās un vergu bibliotēkās.
Galvenās relāciju datu bāzes tirgū atbalsta datu replicēšanu, tāpēc jūs varat sadalīt datu bāzi divās lomās: Master un Slave, rakstīt operācijas šablonā un sinhronizēt galveno serveri ar citiem vergu serveriem.
Bezsaistes operācijas, piemēram, lasīšanas operācijas un datu analīze, tiek veiktas vergu serverī.
Mēs zinām, ka daudzas lietojumprogrammas internetā tiek lasītas, lai vairāki vergi varētu dalīties ar slodzi un nodrošināt datu pieejamību un pareizību.
Tomēr ir jāmaina arī atbilstošais oriģinālais lietojumprogrammas kods, un tas ir jāmaina, lai datu rakstīšanai izmantotu galveno bibliotēku un datu lasīšanai izmantotu vergu bibliotēku, kas ir līdzvērtīga pārrakstīšanai.
Sarežģīti vaicājumi
Tomēr, pat pēc koda pārrakstīšanas, es atklāju, ka veiktspēja joprojām nav būtiski uzlabojusies, jo tika izmantots pārāk daudz sarežģītu vaicājumu, un mēs esam teikuši, ka datu bāzes komponents, kas pievienojas, ir ļoti veiktspējas intensīvs.
Tātad mēs varam izmantot atsevišķu tabulu, lai saglabātu pēdējo 24 stundu populāros produktus, lai to izdarītu tikai vienkāršs SQL.
Citiem vārdiem sakot, viens datu bāzes tabulu kopums nav piemērots dažādām darbībām, piemēram, pārskatiem, meklējumiem, darījumiem utt.
Pašreizējā tabula ir paredzēta datu pievienošanai un modificēšanai, un tā nav piemērota sarežģītiem vaicājumiem.
Bet mums ir arī jāapsver, kā šī vaicājumu bāze tiek atjaunināta, vai mēs varam pieļaut šo kavēšanos, vai tā var netikt atjaunināta reāllaikā.
CQRS
Tas, vai kavēšanos var pieļaut, ir jāaplūko no biznesa viedokļa, piemēram, populārākie labākie produkti pēdējo 24 stundu laikā, nedaudz novecojušai informācijai nav lielas ietekmes, nepieciešama tikai galīgā konsekvence.
Mēs varam izmantot CQRS (Command Query Responsibility Segregation), tas ir, komandu atdalīšanu komandu pievienošanai vai modificēšanai no vaicājuma pienākumiem.
CQRS uzsvars tiek likts uz lasīšanas (vaicājums) un rakstīšanas (komanda) atdalīšanu, jo lietotāju lasītie dati parasti ir novecojuši, tāpēc kāpēc ir nepieciešams lasīt no datu bāzes, jūs varat tieši izveidot lasīšanas datu avotu. Tas var būt kešatmiņa, tas var būt XML, JSON utt.
Kā atrisināt iepriekš minēto atjaunināšanas problēmu? Varat izmantot notikumu, tas ir, notikumu, piemēram, pārdodot preci, varat publicēt notikumu, lai modificētu sākotnējo lasīšanas modeli.
Tādā veidā sinhronizācija kļūst asinhrona, izmantojot notikumu mehānismu.
Visbeidzot, šo metodi vislabāk izmantot tikai sarežģītiem vaicājumiem, un sākotnējie vienkāršie vaicājumi joprojām tiek iegūti relāciju datu bāzē. Kāpēc? Tā kā jaunas tehnoloģijas ieviešanai ir nepieciešama cena, piemēram, sinhronās mutācijas soļi un notikumu mehānismi, mēs nevaram redzēt tikai jauno tehnoloģiju priekšrocības, nevis trūkumus.
|
Publicēts 04.05.2020 09:58:50
|
|
|
|
