Forum - Vetercek.com

To sem nekako računal. Ti kr neopren raztegn. 😂😂😂😂

No za Ivana se  jaz javim, da grem po njega brž, ko bomo smeli čez mejo!

Hvala obema za fedback!

@slashrsm indexe imam pomoje kar dobro nastavljene, ogromno sem prihranil, ker sem vse char-e dal v int kjer je bilo možno (npr. ime postaje, smer vetra...) naslednji korak pa je tako kot predlagaš razdelitev na particije po letih. Če zagusti z prostorom lahko potem stare podatke odstranim ali prestavim na kak backup server...

@thejan nekaj sem tudi gledal druge baze ampak pomoje bo mysql/mariadb čist ok. V resnici v 90% uporabiki gledajo le podatke za današnji dan, zapisujem pa tudi po večini na 5 min, tako da pomojem ni sile.

Kar se tiče postaje, zadnje čase res ne pišem kaj dosti, kar še ne pomeni da se nič ne dogaja. Nasprotno, v času lockdowna sem spisal nov software za postajo, ki sedaj ne predvideva, da so GSM modul deluje tako kot je treba ampak vsako stvar (čist vsak drek) preveri, preden se program nadaljuje. Nato v primeru napake postopek ponovi, nato sledi soft reset če pa kakih 3-4min ni uspeha pa nato še hard reset. To bo (upam) odpravilo še manjše potežkoče ki se občasno pojavljajo. Napisal sem tudi novo funkcijo, ki beleži smer vetra, tako da smer pretvori na X in Y komponento, s katerima potem računam povprečje nato pa ju združim ponovno nazaj v stopinje. Tako dobim na stopinjo točno povprečno smer (prej sem beležil v kateri 1/16 kroga je veternica največkrat). Naredil sem tudi nekaj popravkov na knjižnici, ki služi za pošiljanje podatkov, ki jih bom še poslal in jih bo (upam) avtor upošteval.

Delamo tudi povsem nov hardver z novim 4g/nb-iot čipom, poizkušam narediti 3d printan anemometer, ki bi bil kompaktibilen z obstoječo postajo, ter tudi anemometer brez vrtljivih delov. Tako da se kar dogaja :) 

Vsekakor je v planu postavit še kako postajo, vendar ne želim hiteti, če bi se odkril še kakšen bug.  Treba je tudi preverit, kaj se je zgodilo z sončno celico v sv. Ivanu, zakaj ne fila več, če je problem v pre-tankem kablu, ali je dejansko hin celica ali kaj drugega. 

Pridružujem se mnenju, da je PHP primeren za to kar dela in da vetercek.com deluje odlično hitro in se s stem sploh ne bi ubadal.

Raje še kako postajo postavit :)

Kot je slashrsm napisal je v tem primeru verjetno večina na bazi, to si tudi sam že pogruntal in optimiraš querye.

Javascript je res bolj za 'web appe', za pedenat GUI ipd.

Jaz se z bazami poklicno ukvarjam nekih 10 let, videl sem že vse živo, vsak SQL ima neke specifike in v grobem delujejo po podobnem principu.

Kar me je v zadnjih letih še najbolj pritegnilo je bil Influx kot namenska baza za časovne meritve, kar vetercek v bistvu je. Zelo dobro zadeva deluje, recimo v kombinaciji, ko imaš recimo podatke o 'entitetah', npr imena postaj, njihove koordinate, državo ipd. v MySQL, medtem ko vse meritve pišeš v Influx, kolonami ID postaje, tip meritve, npr. hitrost vetra, čas in vrednost.

Ker je Influx prav za to narejen impresivno hitro beležin in vrača take časovne podatke, npr. v JSON-u, naprej pa join narediš na MySQL in daš dataset PHPju v predstavitev... Mogoče, če hočeš na hitrosti delat je tudi v to smer za razmislit, kot rečeno pa hitro deluje in nekaj časa še zagotovo bo. Potem pa lahk tud brišeš podatke po nekaj letih verjetno...

Pri poizvedbah v bazo ti lahko veliko pomagajo tudi indexi. Če jih pravilno postaviš ti lahko neverjetno pohitrijo zadeve, sploh če se gre za tabele z veliko vrsticami. Še en trik, ki sem ga jaz velikokrat uporabil je to, da poizkušaš s pogoji čim bolj zmanjšati dataset, tako da baza potem kakšne dodatne pogoje in sorte dela na čim manj vrsticah.

Primer: imaš nek seznam člankov ki so najbolj branih člankov. Če upališ query na celi bazi in nato sortiraš po ogledih zna to trajat kar dolgo časa. Če imaš v bazi članke za nekaj let nazaj lahko skleneš da boš iskal samo za zadnjih M tednov. Daš datum kot prvi pogoj, po možnosti podprtega z indexom in tako boš sortiral vnose zadnjih M tednov namesto za celotno zgodovino.

Tudi joini ti lahko upočasnijo določene poizvedbe (spet odvisno za kakšne podatke gre, kakšne indekse imaš, ...). Včasih zna bit hitreje narest več poizvedb v posamezne tabele. Pomembno je da takšne reči izmeriš (s cache-om izklopljenim: "SELECT SQL_NO_CACHE a,b,c FROM...").

Hvala za odgovor. To sem iskal. 

Najprej sem res gledal bolj popularne knjižnice kot React in Vue, sploh Vue me je takoj pritegnila, potem sem gledal en zanimiv video na youtubu, kako folk za vsak drek uporablja frameworke in kako je lahko javascript tudi hitro preveč kompliciran. Potem sem naletel na Mithril, ki se mi je zdela zelo zanimiva opcija, ki bi jo najbrž tudi uporabil. Potem sem že začel razmišljat da v bistvu ne rabim kaj dosti in sem naredil zgornji primer v plain javascriptu. 

Sem pa potem razmišljal, da je treba naredit še avtentikacijo, lokalizacijo, in še en kup enih stvari tako da zaenkrat opuščam idejo, še posebej ker pri mojih primerih ni kakšne strašne razlike v preformansu.

Vsekakor pa bom obstoječ pejđ še mal spimpal. predvsem pri MySQL sem (bil) zelo švoh in sem naredil kak request več kot bi bilo treba, tako da seadj malo bolj pazim in jih joinam ko se da.

Frontend appi (React, Vue) so zanimivi ko želiš narediti stran bolj interaktivno, bolj kot v smislu aplikacije (primer bi bil Gmail). Če tega ne potrebuješ je po mojem mnjenu težko upravičiti pristop s frontend appom. Seveda je lahko tudi želja po učenju nečesa novega čisto dober razlog. Osebno ti nebi priporočal pisat frontend app-a z vanilla JS. Če se boš odločil za to uporabi enega od frameworkov. Meni osebno je bil Vue všeč, pa tudi Elm se mi zdi kar zanimiv (ima sicer malo bolj alternativen pristop).

JavaScript app sam po sebi ti ne zagotavlja da bo stran delovala hitreje. a) še vedno boš delal klice na strežnik, tako da se bo njegovo počasnejše delovanje še vedno poznalo. Res da nekoliko manj opazno, pa vseeno. b) JavaScript app se da zelo hitro zakomplicirati do te mere da je počasen za umret. Uporaba JavaScripta ti sama po sebi ne zagotavlja odzivnosti. Pomembno je kako boš app spisal!

Moje mnenje je, da Veterček nima težav s performance-om. Pa tudi če bi jih imel se ponavadi vedno da lažje optimizirat obstoječ app kot pisati novega. 

Še ena zanimiva opcija bi lahko bil Phoenix z LiveView, ki temelji na Elixirju (ki zna bit sam po sebi precej hiter). Je pa res da gre za precej nišno zadevo.

https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript

https://www.phoenixframework.org/blog/build-a-real-time-twitter-clone-in-15-minutes-with-live-view-and-phoenix-1-5