Příspěvky

31

Software / Re:Altus Vario napojení – WSDL skrze AVIS

« kdy: 06. 10. 2021, 18:28:54 »

SoapUI bolo vo free verzii posledne nejako 3.5...

Kym ta url pre ziskanie WSDL nebude fungovat tak nic ine nema zmysel riesit.

https://www.soapui.org/downloads/latest-release/

No a? Viem kde to stiahnut a aj to ze to potrebuje platnu licenciu.

To nic nemeni na tom ze SoapUI je k nicomu ak timeoutuje poziadavka na ziskanie WSDL...

Osobne pouzivam (resp mam nainstalovany, uz dlouho jsem nepouzil) SoapUI verzi 5.3.
Posledni verzi 5.6 pro windows ZIP (bez instalace) jsem si zkusmo stahl a pustil, jede bez nejakych licencnich pozadavku.

32

Software / Re:Altus Vario napojení – WSDL skrze AVIS

« kdy: 06. 10. 2021, 15:01:14 »

SoapUI bolo vo free verzii posledne nejako 3.5...

Kym ta url pre ziskanie WSDL nebude fungovat tak nic ine nema zmysel riesit.

https://www.soapui.org/downloads/latest-release/

33

Software / Re:Altus Vario napojení – WSDL skrze AVIS

« kdy: 06. 10. 2021, 02:45:27 »

Jako prvni si stahni SoapUi, v nem zaloz wsdl projet, predej mu URL wsdl a cum co to udela.

Az bude fungovat SoapUI, zacni resit, v cem to chces naprogramovat

34

Vývoj / Re:Agregace velkého množství streamovaných dat

« kdy: 24. 09. 2021, 16:37:56 »

C++ pristup pres Hashmapy vybehne z RAM.

Tyjo. Indexy vyběhnou z RAM, přestože nedržíte v indexu jednotlivé zprávy, ale jenom třídící kombinace + poslední zprávu v každé agregované kategorii?

Ano, anzto tech agregovanych kategorii je cca 70 mega

35

Vývoj / Re:Agregace velkého množství streamovaných dat

« kdy: 24. 09. 2021, 11:59:26 »

Vysvetleno v SQL, potrebuju select sum,count,min,max from table where timestamp between x,x+1 group by some_metadata. A pak jeste kompletni metadata (ne jenom ty v group by klauzuli) casove posledniho radku pro kazdou group by grupu.

C++ pristup pres Hashmapy vybehne z RAM.

Ale z RAM vyběhnou jen ty metadata, ne? Takže jde imho jen o to si ty metadata někam odložit?

Mapdb jsem navrhoval, protože to je drop-in replacement za java kolekce, takže pokud už existuje ta naivní implementace, lze vyzkoušet s minimem úsilí.

Jeste neexistuje nic, ale urcite od odzkousim jako prvni pokus. Diky.

36

Vývoj / Re:Agregace velkého množství streamovaných dat

« kdy: 24. 09. 2021, 10:28:19 »

Kód: [Vybrat]

{
"metric": "metric1"
"metadata": {
"nodeid": "node1",
"cardid": "card1",
"portid": "port1",
"lvidid": "lvid1"
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": 0,
"MP_PEAK_TRANS_VIDEO_SESSIONS": 0,
"MP_ACTIVE_TRANS_DTMF_SESSION": 0,
...
...Tam muze opravdu byt libovolny bordel a v libovolnem poradi...

Tenhle konkrétní datový formát jsem nepotkal, přece jenom už mnoho let "dělám do včel". Řekl bych, že jde o nějakou telemetrii ze skupiny nějakých "aktivních prvků" (A/V komunikačních zařízení). Jiní zde asi vidí na první pohled, o co přesně jde a znají hotová řešení.

Spíš pro svou zábavu a pro zajímavost bych se rád zeptal na upřesnění "metamodelu" těch dat (a taky protože jsem možná natvrdlej):

Vypadá to na nějaký polymorfní objekt zvaný "metric", kde "metadata" je stálá/společná množina čtyř atributů, ale polymorfní je množina atributů "counters". Mám pravdu? A množina objektů "counters" je stabilní alespoň pro konkrétní "detailní třídu metriky", tzn. pro konkrétní hodnotu klíčového atributu "metric" ? Tzn. pokud byste si vedl mapu klíčovanou polem "metric", tak jednotlivé uzly (záznamy v mapě) už budou mít každý svou stálou množinu atributů "counters"? Nebo i pak jsou přípustné prázdné hodnoty? (pořadí counterů neřeším.)
Různých typů objektu "metric" je cca kolik? Chápu že 90 milionů je jich *kusů* (úhrnem instancí).

Protože držím v ruce kladivo, problém mi připomíná hřebík: v C++ bych na to použil dvě patra indexu s použitím třídy "std::map", možná se substitucí klíčových stringů integerem, pokud bych usoudil, že to přináší nějakou výkonovou výhodu.

Vicemene ano, jenom tech metadat je v realu mnohem vic. Pro agregaci je nepotrebuju, ale potrebuju znat vsecha metadata z posledni zpravy, co odpovida agregacni kombinaci.

Vysvetleno v SQL, potrebuju select sum,count,min,max from table where timestamp between x,x+1 group by some_metadata. A pak jeste kompletni metadata (ne jenom ty v group by klauzuli) casove posledniho radku pro kazdou group by grupu.

C++ pristup pres Hashmapy vybehne z RAM.

37

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 19:54:44 »

Ale jako prvni pokus zkusim ten MapDB projekt.

nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.

Ok, na ten se taky podivam.
Popravde me efektivita ukladani moc nezajima, chci do toho nacpat hodinu metric dat, pak to poslu do sveta, pak to cely smazu a dalsi hodinu dat.

38

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 19:39:29 »

Pokud bys šel tímdle směrem, tak to holt je úloha spíš na C/C++, byť i v Javě se asi dá psát úsporně (např. si předalokovat bytový vektor a z něho pak "alokovat" stringy sám, ale pak je trochu otázka, proč to psát v JAVĚ.... - ale jinak ohledně toho mě neber moc vážně, Javu znam z rychlíku).
Na C++ existuje Kafka klient:https://docs.confluent.io/clients-librdkafka/current/overview.html
A ohledně 7GB paměti - to je hodně? 8GB modul stojí litr, pokud ten stroj, kde to má běžet, by to fakt nezvlád.... Oproti ceně, za "kterou to napíšeš", to jsou drobný.

Javu preferuju, protoze se v ni dela mnohem snaz, nez v C++, snazsi DevOps, navic ma jit o rozvoj existujiciho programu.
Navic konfigurace memory heapu pro JVM v takovych velikostech uz neni zadek, aby ta RAM byla vyuzivana aspon trochu efektivne.
Nez C++, to bych to pro tento ucel radsi delal v GO. Ale jako prvni pokus zkusim ten MapDB projekt.
To by mohlo fungovat bez excesivniho usili at uz programatorskeho, nebo DevOps.

39

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 19:32:37 »

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 bezne pouzivam, ale ja resim jiny problem.

40

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 18:35:41 »

Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.

A co Ti brání si držet tabulku: "id metriky":"metrika"? S 90 milionama metrik to dělá řádově 4GB.....
To, co je tady problém je opačná otázka, jak dostatečně rychle zjistit ID z metriky, tak aby bylo rozumně spojitý (neděravý) a tedy to zabralo rozumně paměti. A tady mi to zní jako perfektní úloha na nějakou formu "perfektního hashování".

Anebo, ono umístění řetězce v paměti je ideální "perfektní hash", navíc zadarmo a reversibilní :-). Takže se opravdu úloha redukuje na perfektní zahašování stringu. Stačí si uvědomit, že klíč k redukci paměťové náročnosti je v tom, držet řetězec s názvem metriky v paměti pouze jednou a vždy na něj pouze odkazovat.
Pravda, v takto jednoduchém modelu má hashovací klíč 8 bytů, ale to furt není nic, co by se do rozumnýho stroje do paměti nevešlo. A popř. jde pak ještě perfektně hashovat ten 64bit pointer do nějakého 32bit čísla, kdybys na tom chtěl pálit programátorskej čas (jakože kdyžtak dokoupit paměť by vyšlo levnějc :-)).

EDIT: A nebo zůstat u indexace 4bit integerem, a název metriky držet v datové struktuře spolu s agregovanými hodnotami, to je vlastně ještě přirozenější, než mít "extra slovník".

To je pekny hint.
Jenom bych to zevseobecnil na obousmernou mapu (dve mapy) id_retezce/retezec,to by mohlo pomoct. A pouzit to pro vsecky nazvy metrik, metadat, counteru.
Ale to bude imho porad moc, i kdybych to zdrcnul na 100B per agregovany zaznam (coz je v pripade Java Collections IMHO nemozne), porad je to 7GB RAM

41

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 18:18:16 »

Převeď si to do nějakýho rozumnýho binárního formátu. 90 milionů metrik popíšeš místo stringem o velikosti desítek bajtů jedním integerem, čímž se Ti velikost zprávy smrskne skoro desetkrát a vejde se Ti to do paměti.....

Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.

Tak holt prijde ke kazdemu sloupcovemu streamu i bitmapa jestli je field used. Bitmapa bude obsahovat indikaci zda je to null/nenull, coz je 1 Gbit/hodinu * pocet sloupcu. A pro expandovani random N-teho zaznamu se holt musi spocitat kolik jich bylo prazdnych predtim, ale pokud delas exapanzi jako replay dat od pocatku, tak to je v podstate takova "dekomprese" on the fly

Pokud by ale celkovy pocet sloupcu byl hodne velky a kazdy record mel velice nahodny subset poli, bych spis uvazoval o klasickem binarnim DB formatu s indexem pro indikaci jaky je to sloupec - jako:  byte cc (column count), byte field_lookup[cc], unsigned data[cc] ... a pripadne to zarovnaval na nejake 1MB boundary nebo ukladal index kde ktery record zacina.

Btw podle jakych podklicu to chcete agregovat? Na beznou celkovou agregaci nepotrebujete lookup prece. A pokud by podklice nasledovali za sebou (napr. casova osa), tak staci flushnout agregaci a zacit s nulou pro dalsi cast.

Pocet sloupcu (counteru), je velice variabilni. Agregovat chci pouze podle kombinace metadat.

Tady mam jiny priklad pro jiny typ zpravy

Kód: [Vybrat]

"counters": {
"MP_PINHOLE_MEDIA_BUNDLE_CH_PEAK": 0,
"MP_PINHOLE_WORST_MOS_ACTIVE": 10,
"MP_PINHOLE_TOTAL_RTP_RX": 35562640,
"MP_PINHOLE_CH_MULTIPLEXED_PEAK": 0,
"MP_PINHOLE_EVS_MODE_CHANGE_UE_INIT": 0,
"MP_PINHOLE_RTCP_APP_AMR_IO_SWITCH_SENT": 0,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_AMR": 0,
"MP_PINHOLE_WITH_CODEC_G722": 0,
"MP_PINHOLE_DSP_ABORMAL_REL_EVS": 0,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_OTHERS": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_AMRWB": 0,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_AMRWB": 1987,
"MP_PINHOLE_VIDEO_TRANSCODING_CH_PEAK": 0,
"MP_PINHOLE_DSP_NORMAL_REL_EVS": 1009,
"MP_PINHOLE_WITH_CODEC_G729": 0,
"MP_PINHOLE_CRYPTO_CHANNEL_PEAK": 0,
"MP_PINHOLE_WORST_R_FACTOR_ACTIVE": 7,
"MP_PINHOLE_VIDEO_TRANSCODING": 0,
"MP_PINHOLE_CH_MULTIPLEXED": 0,
"MP_PINHOLE_DSP_ABORMAL_REL_OTHERS": 0,
"MP_PINHOLE_AUDIO_TRANSCODING_CH_PEAK": 6700274,
"MP_PINHOLE_EVS_SWITCH_TO_AMR_WB_IO": 0,
"MP_PINHOLE_EVS_MODE_CHANGE_UAG_INIT": 0,
"MP_PINHOLE_RTCP_APP_AMR_IO_SWITCH_RCVD": 0,
"MP_PINHOLE_WITH_CODEC_EVS_AMR_WB_IO": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_AMRWB": 1986,
"MP_PINHOLE_MEAN_MOS_ACTIVE": 44,
"MP_PINHOLE_DSP_ALLOC_ATTEMPTS_EVS": 1018,
"MP_PINHOLE_WITH_CODEC_EVS_PRIMARY": 0,
"MP_PINHOLE_TOTAL_OUT_OF_SEQ": 0,
"MP_PINHOLE_WITH_CODEC_G711": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_OTHERS": 0,
"MP_PINHOLE_FAX_TRANSCODING_CH_PEAK": 0,
"MP_PINHOLE_RTCP_APP_BANDWIDTH_SENT": 0,
"MP_PINHOLE_RTCP_APP_CHNL_AWARE_SENT": 0,
"MP_PINHOLE_DSP_ABORMAL_REL_AMR": 0,
"MP_PINHOLE_FAX_TRANSCODING_CH": 0,
"MP_PINHOLE_CODEC_MODE_CHANGE_UAG_INIT": 0,
"MP_PINHOLE_DSP_NORMAL_REL_AMR": 0,
"MP_PINHOLE_RTCP_APP_CHNL_AWARE_RCVD": 0,
"MP_PINHOLE_TOTAL_PACKET_LOSS": 978004,
"MP_PINHOLE_TOTAL_UDPTL_RX": 0,
"MP_PINHOLE_TIMESTAMP": 1632318300,
"MP_PINHOLE_AVG_PKT_LATENCY": 13,
"MP_PINHOLE_AVG_PKT_SIZE": 84,
"MP_PINHOLE_RTCP_APP_REDUNDNACY_SENT": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_AMR": 0,
"MP_PINHOLE_RTCP_APP_CMR_SENT": 0,
"MP_PINHOLE_RTCP_APP_PRI_SWITCH_SENT": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_AMR": 0,
"MP_PINHOLE_RTCP_APP_BANDWIDTH_RCVD": 0,
"MP_PINHOLE_RTCP_APP_FRAME_AGG_RCVD": 0,
"MP_PINHOLE_CODEC_WITH_T38_UDPTL": 0,
"MP_PINHOLE_RTCP_APP_CMR_RCVD": 0,
"MP_PINHOLE_RTCP_APP_PRI_SWITCH_RCVD": 0,
"MP_PINHOLE_BEST_R_FACTOR_ACTIVE": 98,
"MP_PINHOLE_RTCP_APP_FRAME_AGG_SENT": 0,
"MP_PINHOLE_WITH_CODEC_AMR_WB": 6427,
"MP_PINHOLE_CRYPTO_CHANNEL": 0,
"MP_PINHOLE_CODEC_WITH_T38_RTP": 0,
"MP_PINHOLE_MAX_PKT_LATENCY": 65535,
"MP_PINHOLE_RTCP_APP_PRIMARY_RATE_SENT": 0,
"MP_PINHOLE_BEST_MOS_ACTIVE": 45,
"MP_PINHOLE_DSP_ABORMAL_REL_AMRWB": 0,
"MP_PINHOLE_EVS_SWITCH_TO_PRIMARY": 0,
"MP_PINHOLE_RTCP_APP_PRIMARY_RATE_RCVD": 0,
"MP_PINHOLE_RTCP_APP_REDUNDNACY_RCVD": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_EVS": 1018,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_AMRWB": 0,
"MP_PINHOLE_MEAN_R_FACTOR_ACTIVE": 95,
"MP_PINHOLE_DSP_ALLOC_FAIL_ERROR_EVS": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_AMR": 0,
"MP_PINHOLE_WITH_CODEC_AUDIO_OTHERS": 8,
"MP_PINHOLE_WITH_DTMF_TRANSCODING": 0,
"MP_PINHOLE_AUDIO_TRANSCODING_CH": 1125,
"MP_PINHOLE_CODEC_MODE_CHANGE_UE_INIT": 0,
"MP_PINHOLE_MEDIA_BUNDLE_CH": 0,
"MP_PINHOLE_AVG_JITTER": 3867,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_OTHERS": 0,
"MP_PINHOLE_DSP_ALLOC_FAIL_CONGESTION_EVS": 0,
"MP_PINHOLE_DSP_NORMAL_REL_AMRWB": 1979,
"MP_PINHOLE_WITH_CODEC_AMR_NB": 446,
"MP_PINHOLE_DSP_NORMAL_REL_OTHERS": 0,
"MP_PINHOLE_CODEC_WITH_G_711_FAX": 0,
"MP_PINHOLE_DSP_ALLOC_SUCCESS_OTHERS": 0,
"MP_PINHOLE_MAX_JITTER": 475028227
},
Tam muze opravdu byt libovolny bordel a v libovolnem poradi

42

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 18:10:36 »

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.

To vypada opravdu zajimave, diky

43

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 17:52:07 »

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.

To je pravda, ale to neni muj boj. Na danem projektu jsem ciste v pozici precerpavace kejdy z kafky dale do sveta.

44

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 17:49:48 »

Převeď si to do nějakýho rozumnýho binárního formátu. 90 milionů metrik popíšeš místo stringem o velikosti desítek bajtů jedním integerem, čímž se Ti velikost zprávy smrskne skoro desetkrát a vejde se Ti to do paměti.....

Dik za hint, tohle mi asi ale nepomuze. Prevod na integer otisk postaci pro agregaci, ja to ale pak zase potrebuju expandovat na puvodni stringy a poslat dale do sveta.

45

Vývoj / Re:Agregace velkeho mnzstvi stream dat

« kdy: 22. 09. 2021, 17:46:05 »

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.