Ločitev med branjem in pisanjem
Ko se poslovanje podjetja še naprej širi in se število uporabnikov bistveno poveča, izvirna baza podatkov verjetno ne bo mogla vzdrževati. Potem da
- -in, ki poveča zmogljivost strojne opreme, vendar je verjetno, da bo število uporabnikov še naprej raslo, povečana zmogljivost pa bo kmalu izginila.
- Ločevanje med branjem in pisanjem: Baza podatkov ne zdrži, gre zgolj za preveč branja in pisanja, še posebej, če gre za zapletene poizvedbe, kot so najbolj priljubljeni izdelki v zadnjih 24 urah. Zahteva zelo zapletene SQL stavke in seveda je počasen za zagon.
Vendar pa je za ločevanje branja in pisanja potrebno podatkovno bazo razdeliti na glavno in podrejeno knjižnico.
Glavne relacijske baze podatkov na trgu podpirajo replikacijo podatkov, tako da lahko bazo podatkov razdelite na dve vlogi: glavni in podrejen, pisanje operacij na glavnem strežniku ter sinhronizacija glavnega strežnika z drugimi podrejenimi strežniki.
Operacije brez povezave, kot so branje in analiza podatkov, se izvajajo na podrejenem strežniku.
Vemo, da se na internetu bere veliko aplikacij, tako da lahko več podrejenih aplikacij deli obremenitev in zagotovi razpoložljivost ter pravilnost podatkov.
Vendar pa je treba ustrezno izvirno aplikacijsko kodo prav tako spremeniti, in jo je treba spremeniti, da se za zapisovanje podatkov uporablja glavna knjižnica ter da se pri branju podatkov uporablja podrejena knjižnica, kar je enakovredno prepisovanju.
Kompleksne poizvedbe
Vendar pa sem tudi po prepisovanju kode ugotovil, da se zmogljivost še vedno ni bistveno izboljšala, ker je bilo uporabljenih preveč zapletenih poizvedb, in v podatkovni komponenti smo že povedali, da so spajanja zelo zahtevna za zmogljivost.
Ali lahko uporabimo ločeno tabelo za shranjevanje priljubljenih izdelkov zadnjih 24 ur, tako da potrebujemo le preprost SQL.
Z drugimi besedami, en sam nabor podatkovnih tabel ni primeren za različna vedenja, kot so poročila, iskanja, transakcije itd.
Trenutna tabela je zasnovana za dodajanje in spreminjanje podatkov ter ni primerna za zahtevne poizvedbe.
Vendar moramo upoštevati tudi, kako se ta baza poizvedb posodablja, ali lahko toleriramo to zamudo in ali morda ne bo posodobljena v realnem času.
CQRS
Ali je zamuda sprejemljiva, je treba gledati tudi z vidika poslovanja, na primer priljubljeni najboljši izdelki v zadnjih 24 urah; nekoliko zastarele informacije nimajo velikega vpliva, potrebna je le končna doslednost.
Uporabimo lahko CQRS (Command Query Responsibility Segregation), torej ločevanje ukazov za dodajanje ali spreminjanje ukazov od odgovornosti poizvedb.
V CQRS je poudarek na ločevanju med branjem (Query) in pisanjem (Command), ker so podatki, ki jih berejo uporabniki, običajno zastareli, zato zakaj bi morali brati iz baze podatkov, saj lahko neposredno vzpostavite vir podatkov za branje. Lahko je Cache, XML, JSON itd.
Kako rešiti problem, kako posodobiti, omenjen prej? Lahko uporabite dogodek, torej dogodek, na primer, ko je izdelek prodan, lahko objavite dogodek za spremembo izvirnega modela branja.
Na ta način sinhronizacija postane asinhrona preko mehanizma dogodkov.
Nazadnje je ta metoda najbolje uporabljena le za kompleksne poizvedbe, izvirne preproste poizvedbe pa se še vedno pridobijo v relacijski bazi podatkov. Zakaj? Ker uvedba nove tehnologije zahteva ceno, kot so sinhroni koraki mutacije in mehanizmi dogodkov, ne moremo videti le prednosti novih tehnologij in ne slabosti.
|
Objavljeno na 4. 05. 2020 09:58:50
|
|
|
|
