Lese-skrive-separasjon
Når en bedrifts virksomhet fortsetter å vokse og antallet brukere øker betydelig, vil den opprinnelige databasen sannsynligvis ikke kunne opprettholde seg selv. Da ja
- Skalering, som øker maskinvarens ytelse, men det er sannsynlig at antallet brukere vil fortsette å vokse, og den økte ytelsen vil snart bli spist opp.
- Lese-skrive-separasjon: Databasen kan ikke holde på seg, det er ikke annet enn for mye lese- og skriving, spesielt hvis det er noen komplekse spørringer som de mest populære produktene de siste 24 timene. Det krever svært komplekse SQL-setninger, og selvfølgelig er det tregt å kjøre.
For å skille lesing og skriving må databasen imidlertid deles opp i master- og slavebiblioteker.
De viktigste relasjonsdatabasene på markedet støtter datareplikering, så du kan dele en database i to roller: Master og Slave, skriveoperasjoner på masteren, og synkronisere masterserveren med andre slave-servere.
Offline-operasjoner som leseoperasjoner og dataanalyse utføres på Slave-serveren.
Vi vet at mange applikasjoner på Internett leses, slik at flere slaver kan dele belastningen og sikre tilgjengelighet og korrekthet av dataene.
Den tilsvarende opprinnelige applikasjonskoden må imidlertid også endres, og den må endres til å bruke hovedbiblioteket til å skrive data, og bruke slavebiblioteket når man leser data, noe som tilsvarer omskriving.
Komplekse spørringer
Men selv etter å ha skrevet om koden, fant jeg at ytelsen fortsatt ikke var betydelig forbedret fordi for mange komplekse spørringer ble brukt, og vi har sagt i databasekomponenten at joins er svært ytelseskrevende.
Så kan vi bruke en separat tabell for å lagre de populære produktene fra de siste 24 timene, slik at vi bare trenger å bruke enkel SQL for å gjøre det.
Med andre ord er et enkelt sett med databasetabeller uegnet for ulike atferder som rapporter, søk, transaksjoner osv.
Den nåværende tabellen er designet for å legge til og endre data, og er ikke egnet for komplekse spørringer.
Men vi må også vurdere hvordan denne spørringsbasen oppdateres, eller om vi kan tolerere denne forsinkelsen, om den kanskje ikke oppdateres i sanntid.
CQRS
Om forsinkelsen kan tolereres må sees fra et forretningsperspektiv, som de populære beste produktene de siste 24 timene, litt utdatert informasjon har ikke stor betydning, det kreves bare endelig konsistens.
Vi kan bruke CQRS (Command Query Responsibility Segregation), det vil si separasjon av kommandoer for å legge til eller endre kommandoer fra spørringsansvar.
I CQRS legges vekt på separasjonen mellom lesing (Spørring) og skriving (Kommando), fordi dataene som leses av brukere vanligvis er utdaterte, så hvorfor må du lese fra databasen, du kan direkte etablere en lesedatakilde. Det kan være Cache, det kan være XML, JSON, osv.
Hvordan løse problemet med hvordan man oppdaterer nevnt tidligere? Du kan bruke Event, altså en hendelse, for eksempel, når et produkt selges, kan du publisere en hendelse for å endre den opprinnelige Read-modellen.
På denne måten blir synkronisering asynkron gjennom hendelsesmekanismen.
Til slutt er denne metoden best å bruke kun for komplekse spørringer, og de opprinnelige enkle spørringene hentes fortsatt i relasjonsdatabasen. Hvorfor? Fordi introduksjonen av en ny teknologi krever en pris, som synkrone mutasjonstrinn og hendelsesmekanismer, kan vi ikke bare se fordelene med ny teknologi og ikke ulempene.
|
Publisert på 04.05.2020 09:58:50
|
|
|
|
