reklama

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Témata - szdcf1sd561cas5c

Stran: [1]
1
Vývoj / Tip na novy projekt...
« kdy: 09. 02. 2020, 16:58:51 »
Mam momentalne volno a rad by som sa pustil do nejakeho noveho komercneho projektu. Mate nejaku inspiraciu ze co by stalo za to skusit poriesit?

Nechcem sa vsak pustat do SaaS ani nic centralizovane(komplexna infrastruktura) co stoji na vysokom pocte uzivatelov. Skor ma laka nieco co zakaznik moze hostovat u seba, pripadne nejaky centralizovany projekt s mensim poctom platiacich zakaznikov ktoreho existencia nestoji na tom ze vyzaduje obrovsky balik na reklamu a na ziskani velkeho poctu uzivatelov.
Taktiez sa nechcem pustat to nejakeho obrovseko projektu ktory je na viac nez rok prace, skor nieco specializovanejsie co sa da zbuchat do pol roka.

2
Vývoj / Návrh služby s AOL zápisem
« kdy: 01. 12. 2019, 10:24:08 »
Mam sluzbu "writer" ktora loguje spravy z roznych producentov. Kazdy producent ma sekvencne uint64 id pre svoje spravy. Ked sprava dorazi do tejto logovacej sluzby tak sa musi skontrolovat ze dana sekvencia pre daneho producenta uz nebola zapisana a je konsekutivna voci uz zapsianymi spravam, nasledne sa sprava zapise a prideli sa jej globalne sekvencne id.

Cize v praxi by to vyzeralo ako:
1:foo:1
2:foo:2
3:baz:1
4:bar:1
5:foo:3
6:bar:2
7:baz:2
8:bar:3

Aktualne to zapisujem do kdvdb, avsak do budnca sa obavam toho ze ta db, ako jeden subor, bude prilis velka. Je to b+tree a vyuziva mmap ale i tak nechcem skoncit s TB/PB suborom.

Preto by som chcel prejst na "manualne" logovanie do AOL suborov ktore by rotovali ked dosiahnu urcitu velkost. Tym znizim riziko poskodenia jedneho velkeho suboru a zalohovanie sa tak taktiez znacne ulahci.

Teraz ide o to ze tato sluzba je len na zapis sprav, avsak spravy sa budu aj citat(vo vysokom objeme) a na to su ine sluzby ktore sluzia prave na tento ucel(princip CQRS). Takze z tejto zapisovacej sluzby musim aj vediet citat spravy a synchronizovat ich do "readerov" aby ich mohli servirovat klientom.

"Reader" si len uchovava id globalnej sekvencie ktoru naposledy prijal takze z "masteru" si stiahne iba nove spravy. Cize ked budem pouzivat novy system zapisu do tychto mensich suborov tak musim aj vediet otvorit subor ktory obsahuje spravy ktore reader este nezosynchronizoval.

Cize "master" si musi sledovat lokalne sekvencie pre kazdeho producenta aby zapisoval iba nove spravy a ignoroval opakovane spravy a taktiez aby nepreskocil nejaku spravu(tzn. 1,2,3,6) a taktiez musi uchovavat globalnu sekvenciu.

Realne ide o malo dat, prakticky iba:
8 bytov pre uint64 globalnej sekvencie a mapa [string]uint64 pre sledovanie "lokalnych" sekvencii pre jednotlivych producentov.

Teraz ide o to, kde a ako uchovavat tieto indexy a ako sa dostat ku spravam ktore "reader" este nesynchronizoval.
Napada ze by som mohol pouzivat kvdb kde by som si uchovaval vyssie spomenute + byte index a nazov suboru pre kazdu spravu, podla coho viem potom pre readera otvorit konkretny subor a naseekovat na konkretny bajt so spravami ktore este nema a poslat mu ich. Problem tohto riesenia je ze mi takto vznikaju dve oddelene transakcie. Jedna je zapis samotnych sprav do suborov, druha je ukladanie tychto indexov. Ak by sa stalo ze jedna operacia neprejde, tak mi vznikne inkonzistentny stav.

Dalsia varianta je len zapisovat na koniec aktivneho suboru metadata(globalny index + lokalne sekvencie) a drzat ich v pameti pre rychle vyhodnotenie. Problem je ze nemozem uchovavat pointery pre jednotlive spravy nakolko by slo o privela dat pre taketo uchovanie v aktivnom subore a musel by som vediet ktory subor otvorit pre synchronizovanie readerov podla globalnej sekvencie, cize nazvy suborov by museli byt presne rozsahy sprav(napr 0-5000.dat, 5001-10000.dat, ..) a uz nie podla velkosti dat samotnych co by sposobilo inkonzistentne velkosti tychto suborov. Avsak ak viem podla sekvencie identifikovat subor tak potom ho len preskenovat a najst prvu spravu na sycnhrzonizovanie nie je az tak narocne.

Takze by ma zaujimalo ako by ste navrhli riesenie pre takuto situaciu?

3
Vývoj / Protokoly pro živý video stream
« kdy: 13. 11. 2019, 21:24:42 »
Hladam informacie o tom, aky protokol sa dnes najbeznejsie pouziva na zivy webovy prenos(youtube, dlive, twitch, fb, twitter...). Konkretne ma zaujima protokol na upload(tzn od producenta na sluzbu, napr z OBS, Xsplit, ...) a download(tzn. zo sluzby do klientskych web prehliadacov). Nasiel som dost protokolov a "technik" ale nic co by jasne hovorilo ze prootkol XY je dnes najpouzivanejsi a pouzivaju ho sluzby x, y, z.

4
/dev/null / Linux na upadku?
« kdy: 09. 11. 2019, 11:42:00 »
Kto ma cas sledovat tak vie co sa "deje" vo svete...no nevedel som ze samotny Linux bol uz infiltrovany do takej hlbky a ze je na tom tak zle...

https://www.youtube.com/watch?v=wIa1ItmVz40

Minuta 3:30 ma tiez znacne prekvapila - vsetky financne prispevky pre Linux Foundation idu uplne inam nez maju ist.

5
Vývoj / UX - aktualizacia json dokumentu
« kdy: 05. 11. 2019, 14:09:28 »
Mam api server kam klienti posielaju json dokument. Aktualne sa tento dokument moze aktualizovat iba ked sa posle ako celok. Ja chcem implementovat jednoduche patchovanie aby klient nemusel tahat najprv cely dokument ku sebe, spravit zmeny a znova ho cely poslat na server.

Otazka je ake api je dobre pre takyto ucel. Mozem mat moznost poslat json dokument ktory obsahuje iba zmeny a na servery sa spravi merge. Pripadne mozem pouzit json patch ktory je standardizovany. Pripadne pouzivam kniznicu ktora pouziva zapis "foo.bar.0.baz" ak ide o pole, pripadne "foo.bar.:25.baz" ak ide o objekty resp "foo.bar-1.baz" ak ide o pridanie polozky do pola. je to velmi jednoduche avsak nie je to ziaden znamy standard. Takze neviem ze co je pre uzivatelov dobra metoda - nadiktovat syntax ktora vyhovuje mne, alebo pouzit json patch ktory som moc vo svete nevidel, cely dokment...alebo co skratka? Neviem popravde ze co sa dnes na toto pouziva kedze som sa s tym nikdy nestretol(nerobim s nosql) a nemam prehlad + neviem co preferuju uzivatelia skratka.

6
Hardware / Rada: bare metal s dobrou cenou a spolahlivostou?
« kdy: 13. 10. 2019, 14:51:25 »
Pozeram po nejakych bare metal serveroch na prenajom. Cena je priorita ale aj celkova hodnota(priepustnost a limit siete, disky, ...) a spolahlivost zeleza ale aj datacentra. Okrem Hetzneru a OVH sa oplati pozriet aj nieco ine? Viem ze Hetzner nemal uplne dobru povest v minulosti ale myslim ze to je uz je pasé. OVH je skor zname v nizkonakladovych VPS ale ceny serverov nema uplne zle, i ked znacne drahsie nez porovnatelne u Hetznera.

7
Vývoj / JWT - řešení přístupu v mikroslužbách
« kdy: 04. 05. 2019, 13:48:36 »
Ahojte,
s JWT mam uz skusenosti ale aktualne riesim to ze mam velku aplikaciu ktora sa sklada z mnozstva mikrosluzieb a rozmyslam ako sa riesi pristup ku jednotlivym objektom. Cize autorizacia, nie autentifikacia.

Konkretne ak ide o jwt tak bude obsahovat id usera ale napriklad uz nebude obsahovat informacie ohladom pristupu - cize ak mam nejaku mikroslubu kde tento user vytvoril 200 clankov tak mu nemozem do jwt nahadzat idcka vsetkych clankov aby som vedel ze k nim ma pristup, pripadne ze moze editovat clanky nejakeho ineho usera(na to su sice role). A ked sa sluzby vetvia a napriklad prva sluzba vie sparovat nejaky objekt s userom ale nejaka tretia sluzba uz ma len id nejakej entity a nie usera ktory ju vytvoril tak stracam informaciu pouzitelnu na autorizaciu nejakej akcie pre takehoto usera.

Tak by ma zuajimalo ako sa to normalne riesi?

Stran: [1]

reklama