- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Argos: Adjátok vissza a netet! - szeretnék elaludni!
- Autódiagnosztika: a gyakorlatban
- laskr99: Processzor és videokártya szilícium mag fotók újratöltve!
- droidic: Időutazás floppyval: A 486-os visszavág PCem-men
- LordAthis: Ismét egy "Idióta" A.I. Projekt, hogy meglovagolja az aktuális trendeket...
Hirdetés
-
LOGOUT
Új hozzászólás Aktív témák
-
inf3rno
nagyúr
válasz
#39560925 #8895 üzenetére
Nem csak noSQL létezik, van newSQL is, ami ugyanúgy SQL, csak nulláról írt adatbázis motorokkal, és azt mondják sebességben felveszi a versenyt a noSQL adatbázisokkal. Rengeteg van egyébként, olvastam egy könyvet polyglot persistence témában régebben, amiben felsoroltak legalább 10 divatosat, mint mongodb, neo4j, riak, stb... Mindegyiknél megvan az a feladat, amiben nagyon jó, meg persze az is, amiben nagyon rossz. Szóval lekérdezés alapján érdemes adatbázist választani. Kis alkalmazásoknál persze választasz egyet azt kalap. Nagy alkalmazásoknál meg jobb helyeken váltanak monolitról microservice-re egy méret felett, és minden microservice-nek egy vagy több adatbázist adnak, amelyek eltérő típusúak (is lehetnek). A típus attól függ, hogy az adott lekérdezés csomagra melyik adatbázis alkalmasabb a legjobban. Ezeket úgy frissítik, hogy csinálnak egy központi event storage-et, ami a teljes rendszer állapotát tárolja, aztán az abba bekerülő domain event-eket figyelik, és ha új event érkezik, akkor annak megfelelően frissítik a microservice-hez tartozó adatbázist. Nem kell multiphase commit, hogy szinkronban legyenek az adatbázisok, mert elég ha az event storage letárolja az event-et, a kis adatbázisok ha valami rosszul megy, akkor maximum eldobják a jelenlegi táblát, és nulláról újra lekérik az összes event-et, és végrehajtják magukon. Ez nagyon rugalmas rendszer így, mert egyedül az event storage lecserélése, ami problémás. A microservice-ekhez tartozó query database-eket bármikor tetszés szerint lehet cserélni, vagy akár még több különbözőt is lehet párhuzamosan futtatni, és A/B teszteket csinálni, és loggolni, hogy a kliens mennyi idő alatt kapott választ a lekérdezésre. A hátrány annyi, hogy legalább 2 helyen meglesz ugyanaz az adat, illetve, hogy visszamenőleg nehéz módosítani domain event-eket, mert akkor vagy belenyúlsz az event storage-be és módosítod a már letárolt event-ek adatait, hogy pl új tulajdonságok is kapjanak értéket, vagy mondjuk bevezetsz egy MyDomainEventV2 osztályt, ami már tartalmazza az új tulajdonságokat. Egyik sem tűnik valami jónak. Na asszem már túl sokat bloggoltam, mi is volt a kérdés?
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- 11 GB-os RTX 2080 TI - HP OEM - garanciával
- Wacom Cintiq DTK-2260 digitális rajztábla
- BESZÁMÍTÁS! Gigabyte Z790 i7 14700KF 32GB DDR5 1TB SSD RTX 4070S 12GB Be Quiet! Pure Base 501 750W
- Samsung Galaxy A23 128GB Kártyafüggetlen 1 év Garanciával
- HIBÁTLAN iPhone 12 Pro 256GB Pacific Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3107, 100% Akkumulátor
Állásajánlatok
Cég: FOTC
Város: Budapest