Läs-skriv-separation
När ett företags verksamhet fortsätter att växa och antalet användare ökar avsevärt, är det troligt att den ursprungliga databasen inte kan upprätthålla sig själv. Då ja
- Skala-in, vilket ökar hårdvarans prestanda, men det är troligt att antalet användare kommer att fortsätta växa och den ökade prestandan snart kommer att tas upp.
- Läs-skriv-separation: Databasen kan inte hålla kvar, det är bara för mycket läs- och skrivande, särskilt om det finns några komplexa frågor som de mest populära produkterna under de senaste 24 timmarna. Det kräver mycket komplexa SQL-satser, och naturligtvis är det långsamt att köra.
För att kunna separera läsningar och skrivningar måste dock databasen delas upp i master- och slavebibliotek.
De viktigaste relationsdatabaserna på marknaden stödjer datareplikering, så du kan dela upp en databas i två roller: Master och Slave, skriva operationer på mastern och synkronisera masterservern med andra slavservrar.
Offline-operationer såsom läsoperationer och dataanalys utförs på Slave-servern.
Vi vet att många applikationer på Internet läses, så att flera slavar kan dela belastningen och säkerställa datans tillgänglighet och korrekthet.
Dock måste även motsvarande originalapplikationskod ändras, och den måste ändras för att använda masterbiblioteket för att skriva data och använda slavbiblioteket vid dataläsning, vilket motsvarar omskrivning.
Komplexa frågor
Men även efter att ha skrivit om koden upptäckte jag att prestandan fortfarande inte förbättrades nämnvärt eftersom för många komplexa frågor användes, och vi har sagt i databaskomponenten att joins är mycket prestandakrävande.
Så kan vi använda en separat tabell för att lagra de populära produkterna från de senaste 24 timmarna, så att vi bara behöver använda enkel SQL för att göra det.
Med andra ord är en enda uppsättning databastabeller olämplig för olika beteenden såsom rapporter, sökningar, transaktioner osv.
Den nuvarande tabellen är utformad för att lägga till och ändra data, och är inte lämplig för komplexa frågor.
Men vi måste också överväga hur denna frågebas uppdateras, eller om vi kan tolerera denna fördröjning, om den kanske inte uppdateras i realtid.
CQRS
Om förseningen kan tolereras måste ses ur ett affärsperspektiv, som de populära bästa produkterna under de senaste 24 timmarna, lite föråldrad information har inte så stor påverkan, endast den slutliga konsekvensen krävs.
Vi kan använda CQRS (Command Query Responsibility Segregation), det vill säga separationen av kommandon för att lägga till eller ändra kommandon från frågeansvar.
I CQRS ligger fokus på separationen mellan läs (Fråga) och skrivning (Kommando), eftersom data som läses av användare vanligtvis är föråldrad, så varför behöva läsa från databasen, du kan direkt etablera en läst datakälla. Det kan vara cache, XML, JSON, etc.
Hur löser man problemet med hur man uppdaterar som nämnts tidigare? Du kan använda Event, det vill säga en händelse, till exempel, när en produkt säljs kan du publicera en händelse för att ändra den ursprungliga Read Model.
På detta sätt blir synkroniseringen asynkron genom händelsemekanismen.
Slutligen används denna metod bäst endast för komplexa frågor, och de ursprungliga enkla frågorna hämtas fortfarande i den relationella databasen. Varför? Eftersom introduktionen av en ny teknik kräver en kostnad, såsom synkrona mutationssteg och händelsemekanismer, kan vi inte bara se fördelarna med ny teknik och inte nackdelarna.
|
Publicerad på 2020-05-04 09:58:50
|
|
|
|
