- Jordan kengät myytävänä
- 16373
|
Lukemisen/kirjoittamisen erottelu
Kun yrityksen liiketoiminta laajenee jatkuvasti ja käyttäjien määrä kasvaa voimakkaasti, alkuperäinen tietokanta ei todennäköisesti kestä. Silloin voit
- skaalautua, jolloin laitteiston suorituskykyä laajennetaan, mutta on todennäköistä, että käyttäjämäärän kasvaessa edelleen, lisääntynyt suorituskyky syö pian loppuun.
- Luku- ja kirjoituserottelu: tietokanta ei kestä, lukemista ja kirjoittamista on vain liikaa, varsinkin jos on joitakin monimutkaisia kyselyjä, kuten kuumimmat tuotteet viimeisen 24 tunnin aikana. Tarve hyvin monimutkaisiin SQL-lausekkeisiin, ylöspäin ajaminen on tietysti hidasta.
Mutta jotta luku- ja kirjoituserottelu voidaan tehdä, tietokanta on jaettava master-kirjastoon ja slave-kirjastoon.
Tärkeimmät markkinoilla olevat relaatiotietokannat tukevat tietojen replikointia, joten tietokanta voidaan jakaa Master- ja Slave-rooleihin, jolloin Master-palvelimella suoritettavat kirjoitusoperaatiot synkronoidaan Master-palvelimelta muille Slave-palvelimille.
Lukutoiminnot sekä tietojen analysointi ja muut offline-toiminnot suoritetaan Slave-palvelimella.
Tiedämme, että monet sovellukset Internetissä luetaan, joten useat Slave-palvelimet voivat jakaa kuormitusta hieman, mutta myös varmistaa tietojen saatavuuden ja oikeellisuuden.
Mutta vastaavasti alkuperäistä sovelluskoodia on myös muutettava, on muutettava kirjoittamaan tietoja pääkirjastolla, lukemaan tietoja, kun orjakirjaston käyttö, se vastaa uudelleenkirjoittamista.
Monimutkaiset kyselyt
Mutta vaikka koodin uudelleenkirjoittamisen jälkeen havaittiin, että suorituskykyä ei voida vieläkään merkittävästi parantaa, syy on edelleen liian monien monimutkaisten kyselyjen käyttäminen, tietokantakomponentit sisällä olemme sanoneet, että liitokset ovat hyvin kuluttavia suorituskykyä.
Joten emmekö voi käyttää erillistä taulukkoa tallentaa viimeisen 24 tunnin suosituimpien tuotteiden ah, niin että vain täytyy käyttää yksinkertaista SQL voidaan tehdä.
Se sanoi, että yksi joukko tietokantatauluja on sopimaton eri käyttäytymismalleja, kuten raportteja, hakuja, tapahtumia ja niin edelleen.
Nykyiset taulukot on suunniteltu tietojen lisäämiseen ja muuttamiseen, eivätkä ne sovellu monimutkaisiin kyselyihin.
Meidän on kuitenkin pohdittava myös sitä, miten tämä kyselypohja päivitetään, ja myös sitä, voimmeko elää viiveen kanssa, koska se ei välttämättä ole reaaliaikaista.
CQRS
Voidaan sietää viiveongelmaa on tarkasteltava liiketoimintaa, kuten viimeisen 24 tunnin suosittua äärimmäistä, hieman vanhentuneilla tiedoilla ei ole suurta vaikutusta, vain vaaditaan, että lopullinen johdonmukaisuus voi olla.
Voimme käyttää CQRS (Command Query Responsibility Segregation), eli lisätä, poistaa ja muuttaa komento- ja kyselyvastuun erottelua.
CQRS:ssä korostetaan lukemisen (Query) kirjoittamisen (Command) erottamista, koska käyttäjä lukee tiedot ovat yleensä vanhentuneita, joten miksi silti tarvitsee lukea tietokannasta uudelleen, voit luoda suoraan luetun tietolähteen. Voi olla välimuisti, voi olla XML, JSON jne..
Sitten miten päivittää edellä mainittu ongelma miten ratkaista? Voit käyttää tapahtumaa, eli tapahtumia, kuten myyty tuote, voit julkaista tapahtuman alkuperäisen lukumallin muuttamiseksi.
Tämä muuttaa synkronisen asynkroniseksi tapahtumamekanismin kautta.
Lopuksi tätä menetelmää on parasta käyttää vain monimutkaisissa kyselyissä, alkuperäinen yksinkertainen kysely otetaan edelleen relaatiotietokannan sisällä. Miksi? Koska uuden tekniikan käyttöönotto on maksettava hinta, kuten synkroninen asynkroniseksi, mutta tarvitaan myös tapahtumamekanismia, emme voi vain nähdä uuden tekniikan etuja, emmekä voi nähdä puutteita.
|
Edellinen artikkeliJining New Coronavirus Real-Time Big Data Report Lähdekoodi LataaSeuraava：Dll.refresh-tiedoston vaikutus, kun viitataan projektin luokkakirjastoihin
|
发表于 2020-5-4 09:58:50
s 