Oddelenie čítania a zápisu
Keď podnikanie spoločnosti naďalej rastie a počet používateľov výrazne rastie, pôvodná databáza pravdepodobne nebude schopná udržať sa. Tak áno
- Scale-in, ktorý rozširuje výkon hardvéru, ale je pravdepodobné, že počet používateľov bude naďalej rásť a zvýšený výkon čoskoro zmizne.
- Oddelenie čítania a zápisu: Databáza to nevydrží, je to len príliš veľa čítania a zápisu, najmä ak sú v posledných 24 hodinách zložité dotazy, napríklad najpopulárnejšie produkty. Vyžaduje veľmi zložité SQL príkazy a samozrejme je pomalý na spustenie.
Avšak na oddelenie čítania a zápisu je potrebné databázu rozdeliť na hlavné a podriadené knižnice.
Hlavné relačné databázy na trhu podporujú replikáciu dát, takže databázu môžete rozdeliť na dve úlohy: master a slave, písať operácie na master serveri a synchronizovať master server s inými slave servermi.
Offline operácie, ako sú čítacie operácie a analýza dát, sa vykonávajú na slave serveri.
Vieme, že mnoho aplikácií na internete sa číta, aby viaceré slave mohli zdieľať záťaž a zabezpečiť dostupnosť a správnosť dát.
Avšak zodpovedajúci pôvodný aplikačný kód je tiež potrebné upraviť a musí byť zmenený tak, aby sa na zápis dát používala hlavná knižnica a na čítanie dát sa používala podriadená knižnica, čo je ekvivalentné prepisovaniu.
Komplexné dotazy
Avšak aj po prepísaní kódu som zistil, že výkon sa stále výrazne nezlepšil, pretože sa použilo príliš veľa zložitých dotazov, a v databázovej komponente sme uviedli, že spojenia sú veľmi náročné na výkon.
Môžeme teda použiť samostatnú tabuľku na uloženie populárnych produktov za posledných 24 hodín, aby sme na to potrebovali len jednoduché SQL.
Inými slovami, jedna sada databázových tabuliek nie je vhodná pre rôzne správania, ako sú reporty, vyhľadávania, transakcie a podobne.
Aktuálna tabuľka je navrhnutá na pridávanie a úpravu dát a nie je vhodná pre zložité dotazy.
Musíme však tiež zvážiť, ako sa táto databáza dotazov aktualizuje, alebo či dokážeme toto oneskorenie tolerovať, či nemusí byť aktualizovaná v reálnom čase.
CQRS
Či sa oneskorenie dá tolerovať, treba posudzovať z obchodného hľadiska, napríklad populárne najlepšie produkty za posledných 24 hodín, trochu zastarané informácie nemajú veľký vplyv, stačí konečná konzistencia.
Môžeme použiť CQRS (Command Query Responsibility Segregation), teda oddelenie príkazov na pridávanie alebo úpravu príkazov od dotazovacích zodpovedností.
V CQRS je dôraz kladený na oddelenie čítania (Query) a zápisu (Príkaz), pretože údaje čítané používateľmi sú zvyčajne zastarané, takže prečo by bolo potrebné čítať z databázy, môžete priamo vytvoriť zdroj čítaných dát. Môže to byť Cache, XML, JSON a podobne.
Ako vyriešiť problém, ako aktualizovať, spomenutý vyššie? Môžete použiť udalosť, teda udalosť, napríklad keď sa produkt predá, môžete publikovať udalosť na úpravu pôvodného modelu čítania.
Týmto spôsobom sa synchronizácia stáva asynchrónnou prostredníctvom mechanizmu udalostí.
Nakoniec je táto metóda najlepšie použitá len pre zložité dotazy a pôvodné jednoduché dotazy sa stále načítavajú v relačnej databáze. Prečo? Keďže zavedenie novej technológie si vyžaduje cenu, ako sú synchronné mutačné kroky a mechanizmy udalostí, nemôžeme vidieť len výhody nových technológií a nie len nevýhody.
|
Zverejnené 4. 5. 2020 9:58:50
|
|
|
|
