Témata

1

Vývoj / Event Sourcing - diffovacie eventy

« kdy: 05. 03. 2019, 12:22:32 »

Rastie mi kod pre jeden ES projekt a ES vzdy pridava velky "overhead". Ide o mikrosluzby takze pre kazdu treba riesit agregat(y), eventy, prikazy a td. Eventy maju schemu definovanu cez PB a kazdy event samozrejme musi mat "apply" handler.

S tym ako rastie codebase zacinam zvazovat prechod na unifikovany system. Co tym myslim je nasledovne:

Event sa vzdy vztahuje na nejaky "resource" alias agregat. Kazdy agregat je vo svojej podstate programova entita(nehovorim o ddd) co je vo svojej podstate dokument ktory mozno brat ako normalny json objekt.

Cela podstata eventu je zachytenie zmien ktore boli vykonane na specifickom agregate. Niekto moze debatovat o tom ze eventy nemusia byt vzdy spojene s agregatom(napriklad notifikacia o odoslani emailu) ale ja osobne to beriem tak ze event je VZDY napojeny na agregat, aj ked ten agregat moze reprezentovat len uplnu blbost ako je zaznam v logu, stale ide o zmenu stavu ktoru treba zachytit.

Vzhladom na hore uvedene zvazujem prerobit eventy na objekty, ktore ostanu tak ako su, avsak ich payload by nebol definovany schemou ale obsahoval by sadu zmien ktore boli na (json) dokumente vykonane formou k-v zoznamu kde kluc by bol cesta ku zmene(foo.bar.0.baz) a hodnota by bola hodnota priradena tejto ceste po aplikovani zmien(eventu). Null by znamenal zmazanie. Samozrejme by slo pouzit aj nejaky standard ako je napriklad rfc 6902 pre json patch.

Eventy by uz neniesil identitu(field_foo_changed, user_created, item_added_to_cart...) ale niesli by tagy oddelene ciarkou napriklad, ktore by niesli nazvy poli ktore boli zmenene. Cize kontext zmeny by zanikol.

Eventy stale budu podporovat verzovanie takze handler bude vediet po aplikovani eventu nacitat data z agregatu spravne. Replay eventov bude vzdy fungovat bez nutnosti riesit schemu nakolko ide o jendoduche "patchovanie" takze ku tomu netreba ziadnu specialnu logiku.

Listenery/projektory mozu stale pocuvat na eventy tak ako predtym, ale namiesto pocuvania na specificky event budud pocuvat na specificke zmeny - podla tagov, nie podla povodnych nazvov eventov zalozenych na kontexte.

Kvoli absencii schemy budu reaktory moct vytvorit aktualny stav agregatu bezs nutnosti poznat schemu. Pokial ide o nacitanie dat z agregatu, nic sa nemeni nakolko reaktory musi vzdy vediet aku formu dany agregat ma takze aj predtym musel reaktor rozumit datam ktore spracuva, cize nic sa nemeni, schema nie je nutna.

Takyto pristup ma dva nasledky - tym ze zanikne kontext eventov vzniknu eventy ktore mozu byt vecsie a obsahovat viacej udajov nez predtym, co zapricini vzysenie trafficu ale zaroven znizenie celkoveho poctu eventov.

Druhy nasledok je absencia kontextvych dat ktore neboli sucastou zmien ale boli uzitocne pre reaktory - napriklad aktualny menovy kurz. To sa vsak da vyriesit novym polom na objekte eventu specialne pre taketo data, takze prakticky sa nic nezmeni.

Co si o niecom takom myslite? Zatial som nedostal ziaden konstruktivny feedback, takze teoreticky nevidim nejake nevyhody takehoto systemu. Pozitiva o ktore mi ide su zrychlenie vyvoja a zjednodusenie logiky zakomponovania ES do biznis logiky.

2

Vývoj / Dynamicka cenotvorba / pricing engine

« kdy: 22. 02. 2019, 19:10:08 »

Viem ze toto nie je nic nove na svete a plno spolocnosti to uz riesilo a prislo s nejakymi navrhmi. Osobne vsak zatial neviem o ziadnom rieseni ktore je mozne aplikovat na konkretneho uzivatela a nie na vecsiu skupinu a s pouzitim pred-vypocitanych cien.

Prakticky ma zaujima, ci je vobec realne vytvorenie dynamickeho enginu ktory by vypocital cenu produktov na zaklade definovanych podmienok pre kazdeho uzivatela samostatne?

Problemom su query ktore pouzivaju cenovy rozsah alebo radenie podla ceny. Pokial je pocet produktov vo vysokych cislach tak by to znamenalo nutnost nacitania vsetkych produktov, vypocitania cien pre kazdy samostatne a nasledne aplikovanie filtra/podmienok query. Co je samozrejme mozne, ale odpoved by asi nebola vygenerovana v dostatocne rychlom casovom useku na to aby to bolo realne pouzitelne v produkcii.

Je vobec nieco take mozne? Realne ma napada akurat nejaka forma paralelizmu a shardovania ale komplexnost takehoto riesenia mi pride znacne vysoka do realnej prevadzky, respektive by to vyzadovalo asi tim odbornikov nieco take dat dokopy, jednotlivec by to asi sam nenakodil.

3

Hledám práci / Golang, externe

« kdy: 18. 02. 2019, 18:11:25 »

Robim s Go a mam volne kapacity, keby niekto zhanal externistu na kratkodobu alebo dlhodobu spolupracu. Kodim skoro 20 rokov, nie som lacny, nehladam Javu, C/C++/C#, Python a ine.

PM.

4

Server / Jak databáze řeší indexy?

« kdy: 17. 02. 2019, 18:19:01 »

Ked si vezmem ze vsetky db pod kapotou pouzivaju na indexy btree(pripadne rtree na priestorove objekty) a hashmapy pre uchovanie riadkov v tabulkach, tak by ma vcelku zaujimalo, ako riesia porovnavanie vysledkov a radenie. Napriklad ak nejaka query vrati 100 000 zaznamov pre index A a rovnako pre index B, tak ratam ze db musi do pamete nacitat 200 000 zaznamov a potom to nejak porovnat a odfiltrovat tie ktore sa nezhoduju. Nehovoriac o tom ze ak mam par mega zaznamov tak cely index asi tiez nezaberie len par kB. Pripadne potom este aplikovat aj radenie. Cize ma zaujima to, ako to robia tak aby si nezaplnili pamet pokial ide o nejaku vytazenu db napriklad a stale vedia zabezpecit rychlost odozvy?

Davkovanie moze byt riesenie ale v konencom dosledku sa aj tak musia porovnat vsekty najdene vysledky cize tam uz davkovanie asi nepomoze, plus keby sa vysledky davok zapisovali na disk, kym sa spracuju zvysne ulohy na neskorsie porovnanie, tak by to najskor znacne spomalilo takuto db, takze davkovanie tam asi nebude.

5

Server / Docker a Google Cloud Datastore / Amazon S3 volume

« kdy: 17. 11. 2016, 21:49:26 »

Ahojte,
zacal som sa hrat, prvy krat, s dockerom a postupne sa prepracoval k tomu ze mam tri kontajnery: nginx, php-fpm a data.

Na nginxe bezi oficialny nginx s vlastnym konfigom, php-fpm je z oficialneho image bez zasahu a v data si stahujem z gitu php zdrojaky.

Zatial sa hram len s docker compose ale chystam sa na kubernetes, respektive Google Container Engine.

Anyway, data image spristupnuje volume v dockerfile a tu mountujem v docker-compose.jsom cez volumes_from parameter a aj php aj nginx tuto volume z data vidia.

Co vsak rieism teraz je to ze chcem namountovat Google Cloud Datastore respektive Amazon S3 do nejakej zlozky v data kontajnery/image, napriklad /app/data a moct tak citat a pisat do tohto backendu z nginx(prakticky len citanie) a php kontajneru.

Neviem ako to riesi Amazon S3 ale GCD ma na to gcsfuse utilitku zalozenu na libfuse. Cez nu sa mi podarilo v pohode namountovat backend do /app/data v mojej data image a spustit kontajner.

Ked si otvorim data kontajner cez shell tak ten backend realne funguje, vidim subory, vytvaram subory, citam subory a tak dalej...a ked si otvorim webovu amdinistraciu(google/amazon) tak je vsetko ako ma byt.

Ked sa vsak pozriem do nginx alebo php kontajneru tak zlozka je prazdna a akekolvek zmeny v tejto zlozke vidia iba tieto dva kontajnery a nie samotny data kontajner ktory volume poskytuje.

Prisiel som k zaveru ze nginx a php kontajnery vidia "originalnu" cielovu zlozku(/app/data) do ktorej nie je namountovany backend a ze tento backend funguje iba priamo v data kontajnery.

Avsak nechcem robit monoliticku aplikaciu ani mountovat backend v kazdej image, tak by ma zaujimalo ci neviete niekto ako toto rozbehat? V principe je to iba otazka dockeru a ako riesi prepojenia volume a kontajnerov do coho ja moc nevidim zatial.

Googlil som, ale neviem sa nicoho dopatrat.