Luku-kirjoitus-erottelu
Kun yrityksen liiketoiminta jatkaa laajentumistaan ja käyttäjämäärä kasvaa merkittävästi, alkuperäinen tietokanta ei todennäköisesti pysty ylläpitämään itseään. Sitten kyllä
- Skaalautuminen, joka parantaa laitteiston suorituskykyä, mutta on todennäköistä, että käyttäjämäärä kasvaa edelleen, ja parantunut suorituskyky kuluu pian.
- Luku-kirjoitus-erotus: Tietokanta ei pysy paikallaan, kyse on vain liiallisesta lukemisesta ja kirjoittamisesta, varsinkin jos on monimutkaisia kyselyjä, kuten suosituimmat tuotteet viimeisen 24 tunnin aikana. Se vaatii hyvin monimutkaisia SQL-lauseita, ja tietenkin sen suorittaminen on hidasta.
Kuitenkin, jotta lukemiset ja kirjoitukset voidaan erottaa, tietokanta täytyy jakaa master- ja slave-kirjastoihin.
Markkinoiden päärelaatiotietokannat tukevat datan replikointia, joten tietokannan voi jakaa kahteen rooliin: master- ja slave-rooliin, kirjoittaa operaatioita masterille ja synkronoida master-palvelin muiden slave-palvelimien kanssa.
Offline-toiminnot, kuten lukutoiminnot ja datan analysointi, suoritetaan Slave-palvelimella.
Tiedämme, että monet sovellukset Internetissä luetaan, jotta useat slavet voivat jakaa kuorman ja varmistaa datan saatavuuden ja oikeellisuuden.
Kuitenkin myös vastaavaa alkuperäistä sovelluskoodia täytyy muokata, ja se on muutettava käyttämään master-kirjastoa datan kirjoittamiseen ja slave-kirjastoa datan lukemiseen, mikä vastaa uudelleenkirjoittamista.
Monimutkaiset kyselyt
Kuitenkin, vaikka kirjoitin koodin uudelleen, huomasin, että suorituskyky ei ollut merkittävästi parantunut, koska monimutkaisia kyselyitä käytettiin liikaa, ja olemme sanoneet tietokantakomponentissa, että liittymiset vaativat hyvin suorituskykyä.
Voimmeko siis käyttää erillistä taulukkoa viimeisen 24 tunnin suosituimpien tuotteiden tallentamiseen, jolloin tarvitsemme vain yksinkertaista SQL:ää?
Toisin sanoen, yksi joukko tietokantatauluja ei sovi erilaisiin toimintoihin, kuten raportteihin, hakuihin, transaktioihin jne.
Nykyinen taulukko on suunniteltu lisäämään ja muokkaamaan dataa, eikä se sovellu monimutkaisiin kyselyihin.
Mutta meidän täytyy myös miettiä, miten tämä kyselypohja päivitetään, tai voimmeko sietää tätä viivettä, tai päivitetäänkö sitä reaaliajassa.
CQRS
Sitä, voidaanko viivästystä sietää, on tarkasteltava liiketoiminnan näkökulmasta, kuten suosituista parhaista tuotteista viimeisen 24 tunnin aikana; vähän vanhentuneella tiedolla ei ole suurta vaikutusta, tarvitaan vain lopullinen johdonmukaisuus.
Voimme käyttää CQRS:ää (Command Query Responsibility Segregation), eli komentojen erottamista komentojen lisäämiseksi tai muokkaamiseksi kyselyvastuista.
CQRS:ssä painopiste on lukemisen (Query) ja kirjoittamisen (Command) erottamisessa, koska käyttäjien lukema data on yleensä vanhentunutta, joten miksi pitäisi lukea tietokannasta, voit suoraan määrittää lukutietolähteen. Se voi olla välimuisti, XML, JSON jne.
Miten ratkaista aiemmin mainittu päivitysongelma? Voit käyttää Eventiä, eli tapahtumaa, esimerkiksi kun tuote myydään, voit julkaista tapahtuman muokkaamaan alkuperäistä lukumallia.
Näin synkronointi muuttuu asynkroniseksi tapahtumamekanismin kautta.
Lopuksi tätä menetelmää on parasta käyttää vain monimutkaisiin kyselyihin, ja alkuperäiset yksinkertaiset kyselyt haetaan edelleen relaatiotietokannasta. Miksi? Koska uuden teknologian käyttöönotto vaatii hinnan, kuten synkroniset mutaatiovaiheet ja tapahtumamekanismit, emme voi nähdä vain uusien teknologioiden etuja emmekä haittoja.
|
Julkaistu 4.5.2020 9.58.50
|
|
|
|
