Læse-skrive-adskillelse
Når en virksomheds forretning fortsætter med at vokse, og antallet af brugere stiger markant, vil den oprindelige database sandsynligvis ikke kunne opretholde sig selv. Så ja
- Skalering, som udvider hardwarens ydeevne, men det er sandsynligt, at antallet af brugere vil fortsætte med at vokse, og den øgede ydeevne vil snart blive opbrugt.
- Læse-skriv adskillelse: Databasen kan ikke holde fast, det er ikke andet end for meget læse- og skrivearbejde, især hvis der er nogle komplekse forespørgsler som de mest populære produkter inden for de sidste 24 timer. Det kræver meget komplekse SQL-sætninger, og selvfølgelig er det langsomt at køre.
For at adskille læsninger og skrivninger skal databasen dog opdeles i master- og slave-biblioteker.
De vigtigste relationelle databaser på markedet understøtter datareplikering, så du kan opdele en database i to roller: Master og Slave, skriveoperationer på masteren og synkronisere masterserveren med andre slave-servere.
Offline-operationer som læseoperationer og dataanalyse udføres på slaveserveren.
Vi ved, at mange applikationer på internettet bliver læst, så flere slaver kan dele belastningen og sikre tilgængeligheden og korrektheden af dataene.
Dog skal den tilsvarende oprindelige applikationskode også ændres, og den skal ændres, så masterbiblioteket bruges til at skrive data og slavebiblioteket ved læsning af data, hvilket svarer til omskrivning.
Komplekse forespørgsler
Men selv efter at have omskrevet koden, fandt jeg ud af, at ydeevnen stadig ikke var væsentligt forbedret, fordi der blev brugt for mange komplekse forespørgsler, og vi har sagt i databasekomponenten, at joins er meget ydelseskrævende.
Så kan vi bruge en separat tabel til at gemme de populære produkter fra de sidste 24 timer, så vi kun behøver at bruge simpel SQL til det.
Med andre ord er et enkelt sæt databasetabeller uhensigtsmæssigt til forskellige adfærdsmønstre såsom rapporter, søgninger, transaktioner osv.
Den nuværende tabel er designet til at tilføje og ændre data og er ikke egnet til komplekse forespørgsler.
Men vi skal også overveje, hvordan denne forespørgselsbase opdateres, eller om vi kan tolerere denne forsinkelse, om den måske ikke opdateres i realtid.
CQRS
Om forsinkelsen kan tolereres, skal ses fra et forretningsperspektiv, som for eksempel de populære bedste produkter inden for de seneste 24 timer; lidt forældet information har ikke den store betydning, kun den endelige konsistens er nødvendig.
Vi kan bruge CQRS (Command Query Responsibility Segregation), det vil sige adskillelsen af kommandoer til at tilføje eller ændre kommandoer fra forespørgselsansvar.
I CQRS er fokus på adskillelsen af læsning (forespørgsel) og skrivning (kommando), fordi de data, brugerne læser, som regel er forældede, så hvorfor skulle man læse fra databasen? Du kan direkte etablere en læst datakilde. Det kan være Cache, det kan være XML, JSON osv.
Hvordan løser man det tidligere nævnte problem med opdatering? Du kan bruge Event, altså en begivenhed, for eksempel, når et produkt sælges, kan du offentliggøre en event for at ændre den oprindelige Read Model.
På denne måde bliver synkroniseringen asynkron gennem begivenhedsmekanismen.
Endelig er denne metode bedst kun at bruge til komplekse forespørgsler, og de oprindelige simple forespørgsler hentes stadig i den relationelle database. Hvorfor? Fordi introduktionen af en ny teknologi kræver en pris, såsom synkrone mutationstrin og begivenhedsmekanismer, kan vi ikke kun se fordelene ved nye teknologier og ikke ulemperne.
|
Opslået på 04/05/2020 09.58.50
|
|
|
|
