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.
SoapUI bolo vo free verzii posledne nejako 3.5...
Kym ta url pre ziskanie WSDL nebude fungovat tak nic ine nema zmysel riesit.
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?
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í.
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.
Ale jako prvni pokus zkusim ten MapDB projekt.
nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.
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ý.
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...
CitaceDik 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".
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.
"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
},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.
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.
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.....
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
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
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.