Oddělení čtení a zápisu
Když podnikání společnosti nadále roste a počet uživatelů výrazně roste, původní databáze pravděpodobně nebude schopna sama obstát. Pak ano
- Scale-in, což zvyšuje výkon hardwaru, ale je pravděpodobné, že počet uživatelů bude nadále růst a zvýšený výkon brzy zmizí.
- Oddělení čtení a zápisu: Databáze to nevydrží, je to jen příliš mnoho čtení a zápisu, zvláště pokud jsou v posledních 24 hodinách složité dotazy, například u nejoblíbenějších produktů. Vyžaduje velmi složité SQL příkazy a samozřejmě je pomalý na spuštění.
Aby však bylo možné oddělit čtení a zápis, je nutné databázi rozdělit na hlavní a slave knihovny.
Hlavní relační databáze na trhu podporují replikaci dat, takže databázi můžete rozdělit na dvě role: master a slave, psát operace na master serveru a synchronizovat master server s ostatními slave servery.
Offline operace, jako jsou čtení a analýza dat, se provádějí na slave serveru.
Víme, že mnoho aplikací na internetu je čteno, takže více slave může sdílet zátěž a zajistit dostupnost a správnost dat.
Odpovídající původní aplikační kód je však také nutné upravit a změnit tak, aby se pro zápis dat používala hlavní knihovna a pro čtení dat se používala slave knihovna, což je ekvivalent přepisování.
Komplexní dotazy
Nicméně i po přepsání kódu jsem zjistil, že výkon se stále výrazně nezlepšil, protože se používalo příliš mnoho složitých dotazů, a v databázové komponentě jsme uvedli, že připojení jsou velmi náročná na výkon.
Můžeme tedy použít samostatnou tabulku pro uložení populárních produktů za posledních 24 hodin, takže k tomu stačí použít jednoduché SQL?
Jinými slovy, jedna sada databázových tabulek není vhodná pro různé chování, jako jsou reporty, vyhledávání, transakce atd.
Aktuální tabulka je navržena pro přidávání a úpravu dat a není vhodná pro složité dotazy.
Ale musíme také zvážit, jak se tato dotazovací báze aktualizuje, zda toto zpoždění snášíme, zda nemusí být aktualizována v reálném čase.
CQRS
Zda lze zpoždění tolerovat, je třeba nahlížet z obchodního hlediska, například u oblíbených nejlepších produktů za posledních 24 hodin, trochu zastaralých informací nemá velký dopad, stačí konečná konzistence.
Můžeme použít CQRS (Command Query Responsibility Segregation), tedy oddělení příkazů pro přidávání nebo úpravu příkazů od dotazovacích povinností.
V CQRS je důraz kladen na oddělení čtení (Dotaz) a zápisu (příkaz), protože data čtená uživateli jsou obvykle zastaralá, takže proč je potřeba číst z databáze, můžete přímo vytvořit zdroj čtených dat. Může to být Cache, XML, JSON atd.
Jak vyřešit problém, jak aktualizovat, který jsem zmínil? Můžete použít událost, tedy událost, například když je produkt prodán, můžete publikovat událost pro úpravu původního modelu čtení.
Tímto způsobem se synchronizace stává asynchronní prostřednictvím mechanismu událostí.
Nakonec je tato metoda nejlépe použita pouze pro složité dotazy a původní jednoduché dotazy jsou stále načítany v relační databázi. Proč? Protože zavedení nové technologie vyžaduje cenu, například synchronní mutační kroky a mechanismy událostí, nemůžeme vidět jen výhody nových technologií a ne nevýhody.
|
Zveřejněno 04.05.2020 9:58:50
|
|
|
|
