Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: wjub 28. 05. 2019, 19:04:25
-
Zdravím,
potřebuju trošku nakopnout. Mám aplikaci, která zobrazuje data z nějakého přístroje. Každou vteřinu cca 20 hodnot.
Teď bych potřeboval, tu aplikaci spustit na více počítačích, abych se na to mohl podívat odkudkoliv.
Napadlo mě udělat program, který bude ty data sbírat a ukládat do SQL databáze - to umím,
následně udělám aplikaci, co se připojí k té SQL databázi a bude je zobrazovat - to taky umím.
Jen se mi moc nezdá, že je to správná cesta, protože ve vteřinových intervalech je to 2 a půl milionu záznamů za měsíc.
Jak to efektivně řešit?
díky.
-
Ukladat takove kvanta muzes, na pocitaci udelas velky buffer v RAM a pak z bufferu zapisovat do db s pripadnou filtraci dat. A zobrazovat budes defaultne jen par poslednich minut.
-
Dva a půl milionu záznamů za měsíc zvládne s prstem v nose jakákoli SQL databáze hodná toho názvu. Nicméně nepíšete tam nic o tom, že byste použil nějakých vlastností relačních databází, takže použít na to relační databázi bude nejspíš plýtvání zdroji – vhodná NoSQL databáze by asi to samé zvládla s nižšími náklady.
-
Možná je to Use Case pro RRDTool.
-
Pokud umíte SQL, klidně bych to na tom odprototypoval.
Pokud jde o záznamy v určitém čase a byl by problém s výkonem, můžete kouknout na „time series databases“. Tuším, že třeba Postgres už pro to má nějakou podporu, takže byste nemusel měnit úplně databázový software.
-
Dík za odpovědi,
MS SQL právě mám k dispozici a umím s tím (základní věci).
Je pravda, že zatím je na to relační databáze zbytečná, jen potřebuju sypat někam hodnoty a alespoň z pěti různých počítačů je v reálném čase číst.
Do budoucna bych rád přidal možnost koukat do historie a dělat nějaké statistiky.
Asi to tak zatím udělám, ale zajímalo mě, jaký je ideální postup jak toto řešit.
-
ja by som na to nesiel cez databazu. zbytocne citat z databazy kazdych par sekund z klientov je IT porno.
nedavno tu bol pekny serial o message brokeroch a neviem si predstavit lepsi priklad pouzitia ako toto.
zdroj dat to sype do topicu, 5 subscriberov to cita realtime a jeden subscriber to pise do DB.
-
ja by som na to nesiel cez databazu. zbytocne citat z databazy kazdych par sekund z klientov je IT porno.
nedavno tu bol pekny serial o message brokeroch a neviem si predstavit lepsi priklad pouzitia ako toto.
zdroj dat to sype do topicu, 5 subscriberov to cita realtime a jeden subscriber to pise do DB.
To by ale mělo smysl jedině v případě, kdy klienti ta data mají zobrazovat neustále a více než jeden. Pokud je způsob použití jeden uživatel a „teď se chci na data podívat“ a pak „teď se na data chci zase podívat, ale sedím u jiného počítače“, budou se data v poměru k zápisům číst jen velice málo kdy.
-
"potřebuju sypat někam hodnoty a alespoň z pěti různých počítačů je v reálném čase číst."
Z tohoto som pochopil ze ich chce citat naraz.
Aj kvoli 1 klientovi by som nasadil jednoducheho mesaage brokera
-
"potřebuju sypat někam hodnoty a alespoň z pěti různých počítačů je v reálném čase číst."
Z tohoto som pochopil ze ich chce citat naraz.
Aj kvoli 1 klientovi by som nasadil jednoducheho mesaage brokera
Je zbytečné tvořit message brokera, když můžeš použít obyčejnou cache, kterou má webserver.
-
Klasická SQL databáze bude mít prot takový usecase zbytečně vysoké hw nároky, imho je lepší použít specializovanou časovou databázi, jak už tady zaznělo. Brokera bych taky použil, je to daleko jednodušší a přímočařejší, než řešit nějaké kejkle kolem http, websocketů a kýhočerta.
Podle mě dobrý řešení by byl klasický stack: data posílat pomocí MQTT, broker Mosquitto, na MQTT navěsit jednoduchý databázový zapisovač, databáze InfluxDB. Případně TimescaleDB (to je ta kolegou výš zmíněná podpora pro timeseries pro Postgres). Na zobrazování Grafana (s InfluxDB funguje skvěle).
Instalace toho všeho je asi tak na hodinu, bude to celý fungovat out of the box, jenom je potřeba napsat ten odesílač dat a zapisovač do databáze. Obojí v Pythonu cca padesát řádek, v Go o maličko víc, ale řádově stejně.
-
Snad jediné koncepční řešení zde napsal Gofi - naslouchající klienty jsou oddělené od zařízení i databáze, data získávají přes jednotné, abstraktní, nezávislé rozhraní (broker či vlastní protokol, je to jedno). Volba DB (včetně výměny, více DB, další redistribuce ap.) je pak už jen okrajovým a lokálním problémem.
Je zbytečné tvořit message brokera, když můžeš použít obyčejnou cache, kterou má webserver.
Naprosto netuším, co by mohl mít požadovaný systém společného s webserverem.
-
Snad jediné koncepční řešení zde napsal Gofi - naslouchající klienty jsou oddělené od zařízení i databáze, data získávají přes jednotné, abstraktní, nezávislé rozhraní (broker či vlastní protokol, je to jedno). Volba DB (včetně výměny, více DB, další redistribuce ap.) je pak už jen okrajovým a lokálním problémem.
Broker či vlastní protokol vůbec není jedno. Pokud použiju brokera, najdu spoustu sw, který už je připravený na spolupráci s ním a množství kódu, který budu muset napsat, se radikálně sníží. Pokud si vymyslím vlastní protokol, skončím u toho, že si budu brokera psát sám, strávím nad tím spoustu času a udělám to hůř.
Stejně tak volba DB: mít hezké rozhraní je víceméně nutnost, ale co je za ním taky není tak úplně jedno. Pokud bude DB polovinu strojového času pálit třeba na řešení transakcí, které v tomhle usecasu vůbec nepotřebuju, a místo Raspberry to budu muset provozovat na x86 server-grade hw, je to setsakramentský rozdíl.
-
Podíval bych se na https://docs.influxdata.com/influxdb/v1.7/, to je databáze určená speciálně pro tebou nastíněné použítí, má jednoduchý SQL like query language, takže je jednoduchá na naučení. Pokud bych se nechtěl moc štvát s frontendem, zvážil byh ještě nasazení grafany (https://grafana.com/) pro vizualizaci dat.
-
Klasická SQL databáze bude mít prot takový usecase zbytečně vysoké hw nároky, imho je lepší použít specializovanou časovou databázi, jak už tady zaznělo. Brokera bych taky použil, je to daleko jednodušší a přímočařejší, než řešit nějaké kejkle kolem http, websocketů a kýhočerta.
Podle mě dobrý řešení by byl klasický stack: data posílat pomocí MQTT, broker Mosquitto, na MQTT navěsit jednoduchý databázový zapisovač, databáze InfluxDB. Případně TimescaleDB (to je ta kolegou výš zmíněná podpora pro timeseries pro Postgres). Na zobrazování Grafana (s InfluxDB funguje skvěle).
Instalace toho všeho je asi tak na hodinu, bude to celý fungovat out of the box, jenom je potřeba napsat ten odesílač dat a zapisovač do databáze. Obojí v Pythonu cca padesát řádek, v Go o maličko víc, ale řádově stejně.
Time series databáze se hodí jen na určitý typ dat a ani tam nepřináší oproti obecným sloupcovým DB téměř žádné zrychlení. Nebo jsou dokonce pomalejší.
https://www.altinity.com/blog/clickhouse-for-time-series
-
na 2 miliony záznamů měsíčně v pohodě stačí jakákoliv sql.
-
..
influxdb
..
grafana
..
ano. to je, myslím, řešení. Hlavně to funguje prakticky out-of-the box a grafana je v současnosti nejlepší OSS visu tool.
Influx jede po http, takže se dá schovat za komoditní http(s) proxy..
-
Broker či vlastní protokol vůbec není jedno. Pokud použiju brokera, najdu spoustu sw, který už je připravený na spolupráci s ním a množství kódu, který budu muset napsat, se radikálně sníží. Pokud si vymyslím vlastní protokol, skončím u toho, že si budu brokera psát sám, strávím nad tím spoustu času a udělám to hůř.
Stejně tak volba DB: mít hezké rozhraní je víceméně nutnost, ale co je za ním taky není tak úplně jedno. Pokud bude DB polovinu strojového času pálit třeba na řešení transakcí, které v tomhle usecasu vůbec nepotřebuju, a místo Raspberry to budu muset provozovat na x86 server-grade hw, je to setsakramentský rozdíl.
Jasně, ale o tom má odpověď nebyla, byla o tom, že připojovat jednotlivé klienty přímo k DB je prasečina.
-
Jasně, ale o tom má odpověď nebyla, byla o tom, že připojovat jednotlivé klienty přímo k DB je prasečina.
Tak to kazdopadne :)
-
Jasně, ale o tom má odpověď nebyla, byla o tom, že připojovat jednotlivé klienty přímo k DB je prasečina.
Tak to kazdopadne :)
I v případě použití CouchDB?
-
I v případě použití CouchDB?
Jiste. Treba proto, ze kdyz budes chtit vymenit CouchDB za OtherCoolDB, budes muset prepsat klienty.
-
Díky za nápady,
upřesním trošku situaci.
Klienta s vizualizací už mám, data získávám přes TCP/IP, mám knihovny a v C# načítám každou vteřinu pole dat.
Potřebuju ale těch klientů připojit alespoň 5 současně, proto ta potřeba, aby to někdo četl a ukládal a klienti to tahaly z DB.
Asi ideální by bylo aby to někdo četl, on-line data zároveň nějak zpřístupnil klientům a zároveň ukládal do DB. Z DB by se pak četlo pouze, pokud by byla potřeba historie.
Preferuju C#, a taky abych na serveru nemusel instalovat moc věcí, nemám ho pod kontrolou, ale je na něm SQL.
-
Klienta s vizualizací už mám, data získávám přes TCP/IP, mám knihovny a v C# načítám každou vteřinu pole dat. Potřebuju ale těch klientů připojit alespoň 5 současně, proto ta potřeba, aby to někdo četl a ukládal a klienti to tahali z DB.
Pokud tam chcete mít tu SQL databázi jen kvůli tomu, aby z ní mohlo číst více klientů, tak to není úplně optimální postup. Pro tento případ jsou skutečně přiléhavější postupy, třeba právě ty message brokery.
Pokud chcete mít ale data uložená a provádět nad nimi statistiky, exporty apod. tak bych tu SQL klidně použil.
-
Jasně, ale o tom má odpověď nebyla, byla o tom, že připojovat jednotlivé klienty přímo k DB je prasečina.
Tak to kazdopadne :)
Proč? V řadě situací v tom problém nevidím.
-
I v případě použití CouchDB?
Jiste. Treba proto, ze kdyz budes chtit vymenit CouchDB za OtherCoolDB, budes muset prepsat klienty.
Klienty ne, budeš muset nainstalovat jiného HTTP démona, nějaký skriptovací jazyk a databázi, ale klient zůstane stejný - ať už Firefox nebo třeba Chromium.
-
Proč? V řadě situací v tom problém nevidím.
Mam rovnaky nazor a pripajam sa k tejto otazke.