Olvasás-írás szétválasztás
Amikor egy vállalat üzletága tovább bővül és a felhasználók száma jelentősen nő, az eredeti adatbázis valószínűleg nem képes fenntartani önmagát. Akkor igen
- A skálázás, amely növeli a hardver teljesítményét, de valószínű, hogy a felhasználók száma tovább nőni fog, és a megnövekedett teljesítmény hamarosan elfogy.
- Olvasás-írás szétválasztása: Az adatbázis nem tartja fenn, ez nem több, mint túl sok olvasás és írás, különösen, ha bonyolult lekérdezések vannak, például az elmúlt 24 órában a legnépszerűbb termékek. Nagyon összetett SQL utasításokat igényel, és természetesen lassú a futtatása.
Azonban az olvasás és írás szétválasztásához az adatbázist master és slave könyvtárakra kell osztani.
A piac fő relációs adatbázisai támogatják az adatreplikációt, így egy adatbázist két szerepre lehet osztani: mester és szolga, műveleteket írni a mesterre, és szinkronizálni a master szervert más slave szerverekkel.
Az offline műveletek, mint az olvasási műveletek és az adatelemzés, a Slave szerveren zajlanak.
Tudjuk, hogy sok internetes alkalmazás olvasható, így több rabszolga is megoszthatja a terhelést, és biztosítja az adatok elérhetőségét és helyességét.
Azonban az eredeti alkalmazáskódot is módosítani kell, és módosítani kell, hogy a master könyvtárat használja az adatok írására, és a slave könyvtárat használja adatolvasásnál, ami egyenértékű az újraírással.
Komplex lekérdezések
Azonban a kód újraírása után is azt tapasztaltam, hogy a teljesítmény nem javult jelentősen, mert túl sok összetett lekérdezést használtak, és az adatbázis komponensében is említettük, hogy a csatlakozások nagyon teljesítményigényesek.
Használhatunk tehát külön táblát az elmúlt 24 óra népszerű termékeinek tárolására, így csak egyszerű SQL-t kell használnunk?
Más szóval, egyetlen adatbázis-táblakészlet nem megfelelő különböző viselkedésekhez, például jelentésekhez, keresésekhez, tranzakciókhoz stb.
A jelenlegi táblázat adatok hozzáadására és módosítására készült, és nem alkalmas összetett lekérdezésekre.
De figyelembe kell vennünk azt is, hogyan frissítik ezt a lekérdezési alapot, vagy hogy el tudjuk-e viselni ezt a késést, esetleg nem frissül-e valós időben.
CQRS
Hogy a késés tolerálható-e, üzleti szempontból kell megvizsgálni, például az elmúlt 24 órában megjelent népszerű legjobb termékeket, a kissé elavult információnak nincs nagy hatása, csak a végső következetesség szükséges.
Használhatjuk a CQRS-t (Command Query Responsibility Segregation), vagyis a parancsok elválasztását a parancsok hozzáadására vagy módosítására a lekérdezési felelősségektől.
A CQRS-ben a hangsúly az olvasás (Query) és az írás (Parancs) szétválasztásán van, mivel a felhasználók által olvasott adatok általában elavultak, így miért kellene az adatbázisból olvasni, közvetlenül be lehet állítani olvasóadat-forrást. Lehet gyorsítótár, XML, JSON stb.
Hogyan lehet megoldani a korábban említett frissítési problémát? Használhatod az Eventet, vagyis egy eseményt, például amikor egy terméket eladnak, közzétehetsz egy eseményt, hogy módosítsd az eredeti Olvasási Modellt.
Így a szinkronizáció az eseménymechanizmuson keresztül aszinkronná válik.
Végül ezt a módszert leginkább csak összetett lekérdezésekre használják, és az eredeti egyszerű lekérdezések továbbra is a relációs adatbázisban vannak letöltve. Miért? Mivel egy új technológia bevezetéséhez árat kell megszerezni, például szinkron mutációs lépéseket és eseménymechanizmusokat, nem csak az új technológiák előnyeit látjuk, nem pedig a hátrányait.
|
Közzétéve 2020. 05. 04. 9:58:50
|
|
|
|
