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.


Příspěvky - Standa Blábol

Stran: 1 ... 3 4 [5] 6 7 ... 17
61
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.

62
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.

63
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.

64
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.

65
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 18:35:41 »
Citace
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

66
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

67
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

68
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.

69
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.

70
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.

71
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:43:54 »
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
To vubec neznam, jak to funguje? Jak k sobe spojim countery co nalezi k urcite metrice?
Je to rozvoj nazvu sloupce?

nazev metriky mate v sloupci metric

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

72
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:35:21 »
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
To vubec neznam, jak to funguje? Jak k sobe spojim countery co nalezi k urcite metrice?
Je to rozvoj nazvu sloupce?

73
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 17:32:09 »
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

74
Tak jsem to konečně "opravil". Na Lenovo podpoře jsem po zadání sériového čísla notebooku stáhl jakési udělátko co mě vytvořilo rescue disk. Windows se mě úspěšně nainstaloval do továrního nastavení. Myslím si že nachvilku si budu užívat bezstarostnosti továrního nastavení a na nějakou dobu si odpustím hrátky se systémem :) . Uvidím jak dlouho mě to vydrží a začne se mě stýskat zpátky po linuxu :)

Pokud mas Wokna 10 v verzi professional, mas tak taky Hyper-V hypervizor. Navod viz google
Fedoru si proste nainstaluj jako Hyper-V image, virtualizacni overhead je velice maly.

75
Vývoj / Agregace velkého množství streamovaných dat
« kdy: 22. 09. 2021, 16:59:19 »
Dotaz do think tanku na moznosti zpracovani velkeho mnozstvi stream dat.

Kafka mi posila stream metric dat v JSON formatu.
Dat je hodne, 90 mil ruznych typu metrik, kazda prijde s periodou 5 minut, tedy za hodinu 90*12=1.08 miliardy zprav.
Format (zjednoduseny) je takovyto, realna jedna zprava ma cca 1.5kB dat.

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,
"MP_ACTIVE_AUDIO_SESSIONS": 3,
"MP_PEAK_SRTP_SESSIONS": 0,
"MP_PEAK_TRANS_AUDIO_SESSIONS": 0,
"MP_TOTAL_SRTP_SESSIONS": 0,
"MP_PEAK_TRANS_DTMF_SESSION": 0,
"MP_TOTAL_AUDIO_SESSIONS": 18215,
"MP_TOTAL_VIDEO_SESSIONS": 6,
"MP_PEAK_AUDIO_SESSIONS": 14,
"MP_PEAK_VIDEO_SESSIONS": 2,
"MP_ACTIVE_TRANS_AUDIO_SESSIONS": 0,
"MP_ACTIVE_SRTP_SESSIONS": 0,
"MP_TOTAL_ROGUE_SESSIONS": 0,
"MP_ACTIVE_VIDEO_SESSIONS": 0,
"MP_ACTIVE_TRANS_VIDEO_SESSIONS": 0,
"MP_TOTAL_TRANS_VIDEO_SESSIONS": 0
}
}


Mam existujici (muj) Java programek, ktery se napoji na kafku, nacita zpravy, mirne transformuje a posila na soket k dalsimu zpracovani. Load to zvlada bez problemu.

Nyni potrebuju nad temito daty provadet hodinove agregace, pricemz dale potrebuju agregovat podle subsetu metadat.
Pro priklad dat vyse, potrebuju agregovat countery (min/max/avg) pro kombinaci metadat nodeid,cardid,portid - hodnota lvidid se muze menit, potrebuju zachovat hodnotu lviid z posledni prijate zpravy pro kombinaci nodeid,cardid,portid.
Vysledkem ma byt obdobny JSON, kde blok metadat bude obsahovat metadata z posledni zpracovane zpravy a blok agregovanych counteru bude pro kazdy counter obsahovat sadu agregovanych dat sum/count/min/max - (avg=sum/count). Nejak takhle:

Kód: [Vybrat]
{
"metric": "metric1"
"metadata": {
"nodeid": "node1",
"cardid": "card1",
"portid": "port1",
"lvidid": "lvid23"  # hodnota metadat z posledni zpravy
},
"counters": {
"MP_TOTAL_TRANS_AUDIO_SESSIONS": [120, 20, 0, 30], # sum/count/min/max
"MP_PEAK_TRANS_VIDEO_SESSIONS": [130, 25, 0, 32],
.
.
.
}
}

Muj prvni naivni navrh je:
- pustim kafka replay od hodiny X do X+1
- v mym Java programku na cteni kafka streamu si udelam HashMapu, kde key bude kombinace nodeid,cardid,portid a value bude bean se string metadata (raw JSON) a HashMapa <countername, aggvalues array>
- pro kazdou prichozi zpravu si sestavim key (nodeid,cardid,portid) a v HashMape pro dany key vytvorim/updatuju bean (metadata string se preplacne, agregovane hodnoty prepocitaji)
- az probehnu cely kafla replay - vysmahnu ven HashMapu v JSONu

Problem je s velikosti dat. Vyse popsanou agregaci se dostanu na cca 70 milionu keys v HashMape. Pokud pocitam, ze jeden value v HashMape zabere cca 2kB RAM, celkem ta HashMapa zabere 130GB RAM - nesmysl.

Muj druhy naivni navrh, jako HashMapu pouziju Postgresa, ve kterym bude jedna tabulka reprezentujici vyse popsanou HashMapu ve formatu
Kód: [Vybrat]
(
  key varchar(255),
  aggdata jsonb
)
A na postgresu bude pro insertovani PLSQL procedura, ktera provede potrebne vytvoreni/update pole "aggdata jsonb"

Velikost dat by postgres zvladnout mel, jak to bude s rychlosti, netusim.


Prosim, budu vdecen za jakekoliv hinty, jak toto resit, dik.

Stran: 1 ... 3 4 [5] 6 7 ... 17