Lees-schrijf scheiding
Wanneer de activiteiten van een bedrijf blijven groeien en het aantal gebruikers aanzienlijk toeneemt, is de oorspronkelijke database waarschijnlijk niet in staat zichzelf te onderhouden. Dan ja
- Scale-in, wat de prestaties van de hardware uitbreidt, maar het is waarschijnlijk dat het aantal gebruikers zal blijven groeien en de verbeterde prestaties snel zullen worden opgeslokt.
- Lees-schrijf scheiding: De database kan niet standhouden, het is niet meer dan te veel lezen en schrijven, vooral als er complexe zoekopdrachten zijn zoals de populairste producten van de afgelopen 24 uur. Het vereist zeer complexe SQL-instructies, en natuurlijk is het traag om te draaien.
Om echter lezen en schrijven te scheiden, moet de database worden opgesplitst in master- en slave-bibliotheken.
De belangrijkste relationele databases op de markt ondersteunen datareplicatie, dus je kunt een database opsplitsen in twee rollen: Master en Slave, schrijfoperaties op de master, en synchroniseren van de masterserver met andere slave-servers.
Offline bewerkingen zoals leesoperaties en data-analyse worden uitgevoerd op de Slave-server.
We weten dat veel applicaties op het internet worden gelezen, zodat meerdere slaves de belasting kunnen delen en de beschikbaarheid en correctheid van de data kunnen waarborgen.
De bijbehorende originele applicatiecode moet echter ook worden gewijzigd, en deze moet worden aangepast zodat de masterbibliotheek wordt gebruikt om data te schrijven en de slave-bibliotheek te gebruiken bij het lezen van data, wat gelijkstaat aan herschrijven.
Complexe queries
Toch merkte ik, zelfs na het herschrijven van de code, dat de prestaties nog steeds niet significant verbeterden omdat er te veel complexe queries werden gebruikt, en we hebben in de databasecomponent gezegd dat joins erg prestatie-intensief zijn.
Kunnen we dus een aparte tabel gebruiken om de populaire producten van de afgelopen 24 uur op te slaan, zodat we alleen eenvoudige SQL hoeven te gebruiken?
Met andere woorden, één set databasetabellen is ongeschikt voor verschillende gedragingen zoals rapporten, zoekopdrachten, transacties, enzovoort.
De huidige tabel is ontworpen om gegevens toe te voegen en te wijzigen, en is niet geschikt voor complexe zoekopdrachten.
Maar we moeten ook overwegen hoe deze querybasis wordt bijgewerkt, of of we deze vertraging kunnen verdragen, of het mogelijk niet in realtime wordt bijgewerkt.
CQRS
Of de vertraging te tolereren is, moet vanuit zakelijk perspectief worden bekeken, zoals de populairste beste producten van de afgelopen 24 uur; een beetje verouderde informatie heeft weinig impact, alleen de uiteindelijke consistentie is vereist.
We kunnen CQRS (Command Query Responsibility Segregation) gebruiken, dat wil zeggen, het scheiden van commando's om commando's toe te voegen of te wijzigen van queryverantwoordelijkheden.
In CQRS ligt de nadruk op de scheiding van lezen (Query) en schrijven (Commando), omdat de door gebruikers gelezen data meestal verouderd is, dus waarom zou je uit de database moeten lezen, je kunt direct een gelezen databron opstellen. Het kan cache zijn, het kan XML, JSON, enzovoort zijn.
Hoe los je het eerder genoemde probleem van updaten op? Je kunt Event gebruiken, dat wil zeggen, een gebeurtenis, bijvoorbeeld, wanneer een product wordt verkocht, kun je een event publiceren om het oorspronkelijke Read Model aan te passen.
Op deze manier wordt synchronisatie asynchroon via het gebeurtenismechanisme.
Ten slotte wordt deze methode het beste alleen gebruikt voor complexe zoekopdrachten, en de oorspronkelijke eenvoudige zoekopdrachten worden nog steeds opgehaald in de relationele database. Waarom? Omdat de introductie van een nieuwe technologie een prijs vereist, zoals synchrone mutatiestappen en gebeurtenismechanismen, kunnen we niet alleen de voordelen van nieuwe technologieën zien en niet de nadelen.
|
Geplaatst op 04-05-2020 09:58:50
|
|
|
|
