MySQL trigger notifikacije

Zdravo,


Kako je najbolje rešiti pitanje notifikacija u radu sa bazom? Recimo, korisnik koristi neku aplikaciju ili sajt i treba da mu stigne notifikacija.

Najprostija varijanta bi bila da se baza proverava na određeni vremenski period ali to rešenje nije baš idealno. Ako staviš mali period, onda se opterećuje baza čestim proverama a ako se stavi duži period, onda notifikacije stižu sa zakašnjenjem (što u određenim situacijama može da bude problem, ne u svim naravno).

Sledeća, malo naprednija varijanta bi bila, pravljenje neke websocket konekcije sa klijentom. Ali tu se postavlja pitanje baze, kako će server-side aplikacija znati da se pojavila notifkacija? Mora nekako MySQL da je obavesti. Recimo neki trigger pa kad se aktivira, da pošalje poruku na određeni API. Sad je samo pitanje da li MySQL to može? Koliko sam gledao na internetu, tako nešto može da se postigne uključivanjem nekog UDF-a pa onda recimo curl. Međutim, kažu ljudi da tu performanse nisu baš sjajne (pošto se sve odvija sinhrono) a nije ni bezbedno uključivati taj UDF.

Ima li neka bolja varijanta, recimo da MySQL pošalje native API request, ne vidim da je to neki nebeski problem u 21 veku ;)

van baze, ta notifikacija je trebalo da se generise u layer-u iznad baze pre nego je uopste upisano u bazu to sto treba da generise notifikaciju.
monitoring baze da bi se odatle generisala notifikacije je pogresna arhitektura sistema.

ako "bas mora" (budzi se na postojeci sistem koji iz nekog razloga ne moze da se promeni) onda se "subscribe to changes on database" i onda se te promene parsiraju i odatle generisu eventi koji te zanimaju. U slucaju MySQL-a to bi radio tako sto bi se okacio na mysql server preko replication protokola kao slave i parsirao sve promene nad bazom dok ne vidis to sto te zanima i onda generisao notifikaciju.. drugi RDBMS-i imaju druge nacine da se "pretplatis" na dogadjaje na bazi (ndbcluster ima mogucnost da se pretplatis samo ne dogadjaje u jednoj tabeli ili cak samo jednom slogu na primer) ali u osnovi to se tako radi kad mora taj event da se vadi iz baze, ali ako dizajniras sistem kako treba, kao sto rekoh, nikada se to ne vadi iz baze nego iz layera pre.

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ako je MVC arhitektura, u modelu ubacis neki trait ili nesto tako (ne znam koji programski jezik je u pitanju), helper funkciju, bilo sta, i preko toga publishujes websocket. Najprostije resenje, nije nesto resursno zahtevno. Ako koristis repository pattern, bolje da ide u repository da ne prljas model.

Bazi preko API-ja NIKAKO ne proveravas vremenski odredjeno da vidis da li ima promena iz tih razloga!!! Gledao sam kako ljudi prave chat aplikacije i svakih 200-500ms salju upit ka Postgresu ili MySQLu od strane klijentske aplikacije "da li ima novih poruka za mene", pa ako ih ima, "daj mi sve poruke koje su nove". I tako se zakaci 50 chattera i sruse 16-core xeon.

Ovo drugo Bogdanovo resenje je mozda najsigurnije ali je definitivno najskuplje u resursima svakog vida jer ti treba replika SQL servera koji koristis, i ako ne gresim, tu imas opterecenje od synca, a ako je bas toliko realtime, samo ces sebi veci problem da napravis.

Websocketi, lockovi i budi miran :)

Jeste da je 21. vek ali (My)SQL nije napravljen za to. Jednostavno, on ima pun q podataka razbacanih na sve strane, povezane nekim relacijama, lupljenim indexima, ovo, ono, i njegov zadatak je da izvrsi query koji mu das sto je brze moguce, a onako kako si mu dozvolio. Ostalo nije njegova briga :)

Ne znam sta je tacno u pitanju, mozda mozes i Redis da uposlis malo ako imas resursa. Generalno ja gotivim da kombinujem sve to pa onda jurim na kom layeru cu uhvatiti najbolje performanse za koji deo. Ima onoga sto Redis ne moze (ako stalno imas apdejte nema bas neke svrhe kesirati podatke), ali za te potrebe su tu socketi. Kad imas mnoooogo podataka i treba da ih dobavis brzo koliko je moguce, tu dolazi SQL.

Ako nije neki enterprise-level app, imas Pushera sa 1 mil poruka dnevno besplatno ako ne gresim. Ne moras da se zezas sa podizanjem ws servera. Ako nisu 100% drugaciji podaci vec hvatas i nesto starih podataka, tu mozes da optimizujes queryje i uposlis i redis lepo. Najbolje da podesis sve i igras se lepo 2-3 dana dok ne vidis gde je najbolje sta da ide :) Manje vise svaka "jaca" aplikacija bi trebalo da ima i jedno i drugo, s obzirom da spominjes sockete kapiram da je neki web app u pitanju.

Imaj u vidu da mozes da ubacis i GraphQL izmedju klijenta i servera dodatno ako ces u ekstreme.

Potpis

THE ONLY EASY DAY WAS YESTERDAY

Da, ovo se jasno vidi da ne treba raditi, previše je mali interval. Meni vrši posao i provera na 30 sekundi pa ne znam da li da pravim "seljački" setInterval i da se zezam sa soketima po principu "bolje odma nego kasnije". Jezik je PHP, ništa fensi. Nisam radio sa njegovim soketima pa bih morao da provaljujem kako rade... ili možda sokete uraditi na nekoj drugoj platformi?

jok, to resenje samo ako bas bas mora (znaci ako ne moze da se implementira notifikacija unutar layera iznad baze) ali ti ne treba ni replika niti imas opterecenje... kazes mysql-u da pise binary log (sto ako si iole normalan ti je vec upaljeno) ti se kao klijent kacis direkt na mysql kao slave i imas strim sa mysql-a koji parsujes i gledas dal je tu to sto te zanima (ne postoji slave server, tvoj app je slave server)... taj app onda ostatku tvog app-a kada se desi situacija koju cekas, dojavi.. pa onda dalje opet saljes klijentu kako god (push notifikacija ili sta vec) ... nije to neko m00do da se napravi ni neko opterecenje samo to je svakako samo i iskljucivo ako mora, znaci npr nemas sors od aplikacije koja pise po bazi..



nije nijedan RDBMS a nisu ni ovi NoSQL-ovi ..

elem, ima tu jos jedna fora kod mysql-a, posto mysql daje mogucnost da napises UDF kao externi app ti mozes iz mysql-a da kroz trigger cimnes neki svoj UDF koji ce onda van MySQL-a da uradi sta oces (posalje push notifikaciju) ali to je resenje koje ako nisi vec sam znao da moze, ne treba da ga koristis :D .. jer to znaci da treba da rebildujes taj udf so svaki put kada radis update mysql-a (testiras etc etc..) ... ima i toga u produkciji ali .. to je glavobolja na kub

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Ima vec XY tehnologija koje ce ovo out-of-the-box zavrsiti :) Najgora nocna mora je podesiti sve to, i posle 2 godine odraditi migraciju na neko drugo mesto i nemas pojma sta si uopste i radio :D A na stranu kompleksnost i razne "rupice u zakonu" da izvedes sve to. Ako pravis nesto stabilno za produkciju, nije ovo neki problem koji se ne da resiti sa postojecim stvarima bez maltene ikakvog podesavanja :) Taman se covek izigra sa silnim tehnologijama da razbije monotoniju, a u isto vreme zadrzavas neki regularan build proces kompatibilan sa maltene svim sistemima da ti ni kontejnerizacija ne treba, i ne moras da razmisljas o upgrade pathu jer je sve pravljeno da se koristi onako kako ga koristis :)

Kompleksni upiti i cuvanje podataka - SQL
Realtime manipulacija podacima - Websocks
Smanjivanje upita ka bazi date koja je vecinom staticna a cesto se "trazi" - Redis (eventualno memcached)
Smanjivanje overfetchinga i fazon "get only what you need" - GraphQL

Bavis se developmentom na miru, primera mali zilion na netu, nema glavobolja :)

Sto se socketa tice, ja bih odmah krenuo na Pushera - nemas zezancije da podizes svoj websocks server, a u startu ce da ti pruzi SVE sto ti je potrebno. Ako krenes da prebijas limite, onda dizi svoj server. Do tad mozes na nekom stagingu da isprobas kako bi tvoj websocks server funkcionisao, mada iskreno, Pusher je prilicno velikodusan sa free tier limitima da neces tako lako i brzo dostici granicu. PHP to lepo hendluje, ne znam da li koristis neki FW, na primer Laravel u startu ima podrsku bas za pusher.

Nema tu njegovih socketa, to su univerzalni websockets, samo nadjes osnovi tutorial kako ih broadcastujes i to je to, browseri ih nativno resavaju. Da se ne pravim pametan, izguglaj "Pusher with PHP", ima primera koliko hoces.

Ja bih u startu krenuo na sockete radije nego posle menjao core aplikacije kad vec postane cupavo, mada imaj u vidu da 30 sekundi nije strasan interval - doduse ne znam kakav query je u pitanju. Ja trenutno radim neki masivni ecommerce gde koristimo Postgres i imamo upite koji traju po 45 minuta sa sve ispravnim indexima, Boga oca ekstenzija, cega sve ne... jednostavno kad naraste data, upiti ce se duze izvrsavati i nema spasa. Jedno je kad lokalno testiras pa sve ide k'o podmazano, drugo je kad se natrpa podacima. Ako mozes ikako, daj nam otprilike primer sta se tacno desava pa da vidimo koja je najbolja solucija, ne moras da kazes tacno sta je u pitanju, metaforizuj :) Ja muku mucim trenutno sa Postgresovim ilike-om na 30 left-joinovanih tabela (suludo ali takav je projektni zahtev, jedno dugme na novoj app menja 40 dugmadi sa stare) sa par desetina miliona upita a rezultat mi treba za manje od 2-3 sekunde jer ide autocomplete... da sam se od starta oslanjao samo na Postgres, sad bih bio u ogromnom problemu. Tu su i neke druge stvari gde Postgres ama bas nista ne moze da uradi da nam resi problem i tu ide Elastic. I performanse nikako ne testiraj na 100-200 rekorda, ni na 1000, racunaj koliko bi otprilike imao za godinu dana, dve godine, seeduj neku dummy datu, stavi na staging i vidi sta se desava. Ja sam u ovom ecomm-u prvo mislio da ce "par minuta" update queryja biti solidno, i bilo je, dok nismo seedovali ono sto ocekujemo u nekoj malo daljoj buducnosti i sa 2-3 minuta dosli na 45. Nije strasno jer ide po noci 2x i jednom dnevno, ali svejedno...

Pa iz ove price vidi da ti je bolje od samog starta da uzmes najbezbolniju mogucnost jer posle mozes da ubijes sql server :D

Potpis

THE ONLY EASY DAY WAS YESTERDAY

?!?!??



zavisi koji jezik koristi i koji app server koristi... ako zanemarimo php gotovo sve ostale tehnologije koje se koriste za bekend nativno podrzavaju WS i WSS (java, nodejs, piton, go..)



ne vidim kako mu WS/WSS resava problem toga sto treba da napravi notifikaciju kada se nesto promeni u bazi :D


ako pricamo o web-u 30 sekundi je vecnost ako je vezano za bazu ... 30 sekundi za upit je ok za neki OLAP query u nekom ERP-u inace za RDB i WEB 30sec je vecnost
ako pricamo o 30sec intervalu da klijent pinga server, opet, ne treba da pinga bazu, ako nema 2way komunikacije izmedju klijenta i servera klijent moze da pinga neki servis koji ce da ima informaciju da li je ili nije ali nikako na 30sec ne treba da pinga bazu sa glupim pitanjima


ima spasa, samo mora da umes :D



to nije nacin ni da je interval od 5 minuta, prosto, to se tako ne radi..
pitanje koliko imas tih notifikacija, ako je vise od jedne iskoristis neki queue (na primer zmq je jedan od najboljih) i generises te notifikacije tamo gde treba (pre upisa u bazu) slazes ih i povlacis kako treba


osnovna stvar kod WS/WSS je da imas app server koji "traje" i zato kod php programera nisu toliko popularni jer php skript ima kratko trajanje a vecina interpretera limitira trajenje php skripta tako da mora koristis trikove da bi to radilo... zavisno od framework-a koji koristis imas razlicita resenja, komercijalno imas pusher (ima dosta nezgodne licence cudi me da ga zlatni preporucuje, jeste lagan za koriscenje ali..), open source imas rachet... imas primera koliko volis po netu

btw ovakvu pricu sam pricao vec jedno 300 puta, i svaki put se na kraju svodi na "jbg, ovako sam umeo" i neko pinga bazu na x sekundi jer "radi jbg sa 3 korisnika extra" i onda .... jbg ...
ima sve svoje, kazu imas dva pravca, jedan je da dizajniras kako treba a drugi je da pravis da radi i resavas problem onda kada nastane.. prvi princip je bolji ali cesto nikad ne dodje do mvp-a dok drugi princip mada kosta vise na kraju mnogo brze dovodi do mvp-a pa posle ako mora prepises sve iz nule, nema veze, probao si, pokazao, uzeo pare... sve ima svoje tako da.. bitno ti je da znas sta i kako a pravi kako mozes :D

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/