181
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 19:50:28 »Ale jako prvni pokus zkusim ten MapDB projekt.
nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.
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.
nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.
182
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 19:37:27 »Ked uz tam mas niekde postgres tak ta asi bude zaujimat toto: https://www.timescale.com/
Robi to presne to co pozadujes. Naviac ti to poskytne efektivnejsie a bezpecnejsie ulozisko ako kafka...
timescale zrovna moc efektivni ve vyuziti mista na disku neni, ma spatnou kompresi, pokud nepotrebujete delat nejake fancy dotazy, tak bych se mu vyhnul.
a nemusi stihat zapis, 1 mld za hodinu je celkem dost dat.
tady jsou nejake benchmarky
https://altinity.com/blog/clickhouse-for-time-series
https://github.com/timescale/tsbs
rozdil celkem vyrazny 26GB timescale vs 0.5GB influx vs 1.2GB clickhouse
183
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 18:13:59 »To jsou nazvy sloupcu, uz chapu.
Ten seznam nazvu counteru ale neni uplny ani finalni, muze se celkem dynamicky menit. Kazdy typ metriky mue mit jiny set counteru
muzete mit sloupce nazev_counteru, hodnota
184
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:57:57 »Ještě je možnost kouknout po nějaké off-memory hashmapě pro javu, něco jako https://github.com/jankotek/MapDB nebo podobně. Nemám s tím zkušenost, ale bylo by to něco mezi řešením v paměti a řešením pomocí externí databáze.
do toho moc dat neulozite, zadna komprese
185
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:54:09 »To je pravda, ale to neni muj boj. Na danem projektu jsem ciste v pozici precerpavace kejdy z kafky dale do sveta.
ok, ale podle me ta agregovana data v JSONu budou na disku vetsi nez by byla "splostela" data v tabulce
186
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:49:18 »kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse
ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese
Ja to nepotrebuju ukladat, jenom zpracovat agregaci a poslat dal do sveta
ok, mozna bezpecnejsi to ukladat (alespon par dnu zpet) a agregovat ta data offline
Ok, diky za hint, ulozene by to melo byt v kafce, co neni v kafce, to neexistuje. Melo by stacit si do sloupcove DB ulozit pouze tu jednu aktualne zpracovavanou hodinu.
ok, ale ta kafka zbytecne plytva mistem, v sloupcove DB neni problem ulozit nekolik dnu do cca desitek GB. Miliarda radku za hodinu nejsou pro sloupcove databaze velka data.
187
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:38:29 »treba takove sloupce, stovky miliard zaznamu by nemel byt problem na terabitovem disku, agregacni dotazy v radu par sekundTo vubec neznam, jak to funguje? Jak k sobe spojim countery co nalezi k urcite metrice?Kód: [Vybrat]datetime
metric
metadata_nodeid
metadata_cardid
metadata_portid
metadata_lvidid
counters_MP_TOTAL_TRANS_AUDIO_SESSIONS
counters_MP_PEAK_TRANS_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_DTMF_SESSION
counters_MP_ACTIVE_AUDIO_SESSIONS
counters_MP_PEAK_SRTP_SESSIONS
counters_MP_PEAK_TRANS_AUDIO_SESSIONS
counters_MP_TOTAL_SRTP_SESSIONS
counters_MP_PEAK_TRANS_DTMF_SESSION
counters_MP_TOTAL_AUDIO_SESSIONS
counters_MP_TOTAL_VIDEO_SESSIONS
counters_MP_PEAK_AUDIO_SESSIONS
counters_MP_PEAK_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_AUDIO_SESSIONS
counters_MP_ACTIVE_SRTP_SESSIONS
counters_MP_TOTAL_ROGUE_SESSIONS
counters_MP_ACTIVE_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_VIDEO_SESSIONS
counters_MP_TOTAL_TRANS_VIDEO_SESSIONS
Je to rozvoj nazvu sloupce?
nazev metriky mate v sloupci metric
188
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:37:33 »kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse
ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese
Ja to nepotrebuju ukladat, jenom zpracovat agregaci a poslat dal do sveta
ok, mozna bezpecnejsi to ukladat (alespon par dnu zpet) a agregovat ta data offline
189
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:31:35 »
treba takove sloupce, stovky miliard zaznamu by nemel byt problem na terabitovem disku, agregacni dotazy v radu par sekund
Kód: [Vybrat]
datetime
metric
metadata_nodeid
metadata_cardid
metadata_portid
metadata_lvidid
counters_MP_TOTAL_TRANS_AUDIO_SESSIONS
counters_MP_PEAK_TRANS_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_DTMF_SESSION
counters_MP_ACTIVE_AUDIO_SESSIONS
counters_MP_PEAK_SRTP_SESSIONS
counters_MP_PEAK_TRANS_AUDIO_SESSIONS
counters_MP_TOTAL_SRTP_SESSIONS
counters_MP_PEAK_TRANS_DTMF_SESSION
counters_MP_TOTAL_AUDIO_SESSIONS
counters_MP_TOTAL_VIDEO_SESSIONS
counters_MP_PEAK_AUDIO_SESSIONS
counters_MP_PEAK_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_AUDIO_SESSIONS
counters_MP_ACTIVE_SRTP_SESSIONS
counters_MP_TOTAL_ROGUE_SESSIONS
counters_MP_ACTIVE_VIDEO_SESSIONS
counters_MP_ACTIVE_TRANS_VIDEO_SESSIONS
counters_MP_TOTAL_TRANS_VIDEO_SESSIONS
190
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:18:49 »
kokud to jde nejak rozlozit do sloupcu, lil bych do sloupcove databaze, treba clickhouse
ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese
ukladat to jako JSON je nesmysl, mimo jine prijdte o moznost komprese
191
Vývoj / Re:Investor pro C++ IDE
« kdy: 19. 09. 2021, 03:23:29 »Zásadní rozdíl mezi linterem a kompilerem (staticky typovaného jazyka) je v tom, že linter lze nepoužít. (Plus je tam ta historická souvislost, že linter se používá na jazyky, které nebyly navrženy se statickými typy - Python, JS například.)Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?Linter odhali stejny typ chyb jako kompiler.Odvážné tvrzení. Ale budiž, nebudem se o tom přít.
otazka nastaveni CI.
192
Vývoj / Re:Investor pro C++ IDE
« kdy: 19. 09. 2021, 03:20:52 »Ak by linter odhalil rovnaky typ chyb ako kompiler, tak by bol tak trocha zbytocny, nie?Linter odhali stejny typ chyb jako kompiler.Odvážné tvrzení. Ale budiž, nebudem se o tom přít.
protoze obracene to neplati, linter (zalezi na linteru) casto odhali vic chyb. priklad hlint a ghc. navic linter negeneruje binarku, tak bezi mnohem rychleji, IDE ho muze spoustet na pozadi.
193
Vývoj / Re:Investor pro C++ IDE
« kdy: 19. 09. 2021, 01:55:44 »Linter odhali stejny typ chyb jako kompiler.Odvážné tvrzení. Ale budiž, nebudem se o tom přít.
Nemuzes normalne priznat, ze ma druha strana pravdu?
194
Vývoj / Re:Investor pro C++ IDE
« kdy: 19. 09. 2021, 01:18:22 »
konkretne u toho scitani, ktere je v prikladu, pokud ta operace dela neco s cisly (hadam ze scita), ruzne out of range chyby bezny kompiler neodhali, vetsinou je jednodussi napsat testy na ruzne krajni pripady
195
Vývoj / Re:Investor pro C++ IDE
« kdy: 19. 09. 2021, 01:15:22 »Tak to prr! Na nic takového jsem neptal. Já se jen opatrně ptal, co skutečnost, že to spadne dokazuje. Ty říkáš, že na to přijdu při testu. OK, tak ten test teda musím napsat. Nebo musím spustit linter, což je takovej podivnej kříženec mezi statickými typy a automatickými testy - ok.Ale ty testy musím napsat, že? A musím je napsat správně, že?
Ale vy jste se ptal, jak pomohou testy. Na tuhle chybu prijde kazdy linter, k tomu nejsou treba testy. Ale staci i uplne trivialni test, ktery pokryje ten kod.
Každopádně mi furt nedochází, v čem by to testování mělo být výhodnější, nebo co jako. (Bez ohledu na to, že už tu jedno vlákno na toto téma bylo, kde to bylo do mrti rozebráno. Ale někdo si chce tu slepou uličku asi prolézt znova. No, buduž mu přáno.)
Linter odhali stejny typ chyb jako kompiler. Testovani odhali jiny typ chyb.
