Lugemis-kirjutamise eraldamine
Kui ettevõtte äritegevus jätkab laienemist ja kasutajate arv suureneb märkimisväärselt, ei suuda algne andmebaas tõenäoliselt end ise säilitada. Siis jah
- Skaleerumine, mis suurendab riistvara jõudlust, kuid tõenäoliselt kasvab kasutajate arv jätkuvalt ning suurenenud jõudlus kaob peagi.
- Lugemise ja kirjutamise eraldamine: Andmebaas ei suuda püsida, see on lihtsalt liiga palju lugemist ja kirjutamist, eriti kui on keerukaid päringuid, näiteks viimase 24 tunni populaarseimad tooted. See nõuab väga keerukaid SQL-lauseid ja loomulikult on see aeglane käivitamiseks.
Kuid lugemiste ja kirjutamiste eraldamiseks tuleb andmebaas jagada master- ja slave-teekideks.
Peamised relatsioonilised andmebaasid toetavad andmete replikatsiooni, seega saab andmebaasi jagada kaheks rolliks: Master ja Slave, kirjutada operatsioone masteril ning sünkroniseerida master server teiste slave-serveritega.
Võrguühenduseta toimingud, nagu lugemistoimingud ja andmeanalüüs, viiakse läbi Slave serveris.
Me teame, et paljud interneti rakendused on loetud, et mitu orja saaksid koormust jagada ja tagada andmete kättesaadavuse ja korrektsuse.
Siiski tuleb ka vastavat algset rakenduskoodi muuta, mis tuleb muuta nii, et andmete kirjutamiseks kasutataks pearaamatukogu ja andmete lugemisel slave-teeki, mis on võrdne ümberkirjutamisega.
Keerukad päringud
Kuid isegi pärast koodi ümberkirjutamist avastasin, et jõudlus ei paranenud oluliselt, sest kasutati liiga palju keerukaid päringuid ning oleme andmebaasi komponendis öelnud, et liitumised on väga jõudlusnõudlikud.
Kas saame kasutada eraldi tabelit viimase 24 tunni populaarsete toodete salvestamiseks, nii et selleks piisab lihtsast SQL-ist?
Teisisõnu, üks andmebaasitabelite komplekt ei sobi erinevate käitumiste, nagu aruanded, otsingud, tehingud jne, jaoks.
Praegune tabel on loodud andmete lisamiseks ja muutmiseks ning ei sobi keerukate päringute jaoks.
Kuid peame arvestama ka sellega, kuidas seda päringubaasi uuendatakse või kas suudame seda viivitust taluda, kas seda ei pruugi reaalajas uuendada.
CQRS
Kas viivitust saab taluda, tuleb vaadata ärilisest vaatenurgast, näiteks populaarsete parimate toodete kohta viimase 24 tunni jooksul, väike aegunud info ei avalda suurt mõju, vaja on vaid lõplikku järjepidevust.
Saame kasutada CQRS-i (Command Query Responsibility Segregation), mis tähendab käskude eraldamist käskude lisamiseks või muutmiseks päringukohustustest.
CQRS-is on rõhk lugemise (Query) ja kirjutamise (Command) eraldamisel, sest kasutajate loetud andmed on tavaliselt aegunud, seega miks on vaja andmebaasist lugeda, saad otse luua lugemisandmeallika. See võib olla vahemälu, XML, JSON jne.
Kuidas lahendada eelnevalt mainitud uuenduste probleemi? Sa võid kasutada Eventi, st sündmust, näiteks kui toode müüakse, saad avaldada sündmuse, et muuta algset lugemismudelit.
Nii muutub sünkroniseerimine sündmuste mehhanismi kaudu asünkroonseks.
Lõpuks on seda meetodit kõige parem kasutada ainult keerukate päringute puhul ning algsed lihtsad päringud hangitakse endiselt relatsioonilises andmebaasis. Miks? Kuna uue tehnoloogia kasutuselevõtt nõuab hinda, nagu sünkroonsed mutatsioonisammud ja sündmuste mehhanismid, ei saa me näha ainult uute tehnoloogiate eeliseid, mitte puudusi.
|
Postitatud 04.05.2020 09:58:50
|
|
|
|
