FinWX Foorumi

Yleiset keskustelualueet => EWN - European Weather Network => Aiheen aloitti: weatherc - Keskiviikko, 17.04.2019, 21:20

Otsikko: Projekti tilastot
Kirjoitti: weatherc - Keskiviikko, 17.04.2019, 21:20
Laitetaan oma ketju tilastoille.
(ja einari, ei mitään nillitystä Netatmojen oikuista tänne ;))

Alunperinhän taisin olla aika valikoiva käppyrädatan keruussa juuri tilanpuutteen takia. No, se korjaantunee kohtapuolin :)

Tuli katsottua nuo "käyrätaulukot" läpi ja siivottua ulos tyhjät, lähes tyhjät ja muuten vaan rikkinäiset taulukot. datankeruu-häkkyrät tekevät kyllä uudet taulukot niille asemille joilla se uppuu. "Käyrätaulukko" on asemakohtainen taulukko johon menee dataa 20 min välein, ja joka aikanaan siivotaan kokoon 1 vuosi. Näistä taulukoista on tarkoitus generoida päivä-taulukot joista on helppo taas generoida tilastoa kun on valmiiksi pureskeltua vrk-dataa.
Ne taulukot joihin tähän asti on mennyt dataa ok siivotaan sitten kun päivätaulukoiden generointi on toiminnassa. Näitä on joihin tähän asti mennyt dataa ovat osa pws-asemista ja palttirallaa puolet fmi-asemista.

On myös korjattu tiesää-asemien ja muiden laitosten (MET Norway, SMHI, EMHI, UK Metoffice...) keruut noihin taulukoihin.
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Keskiviikko, 17.04.2019, 21:46
Pidä tunkkis....
Taidat olla aika nihilisti.. koska loukkaat minun peruslain mukaisia oikeuksiani.. wikipedia sanoo niin...

"Nillitys – rasittava saarnaaminen elämän vähemmän merkittävistä yksityiskohdista – kuuluu vapaan yhteiskuntamme perustavanlaatuisiin oikeuksiin."
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Keskiviikko, 17.04.2019, 23:14
Wikipedia - se totuuden torvi  ;D
Kannattaisko einarin ottaa selvää/kysyä mitä tarkoitetaan jollain sanalla jollei tiedä ennen kuin vetää johtopäätöksensä? En tarkoittanut nillityksellä tuota, sillä on ihan erikin tarkoitus. Tarkoitin sitä että tuota Netatmon oikkuilua ei tarvi levitellä jokaiseen ketjuun vaan pidetään ketju otsikon mukaisena

Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Torstai, 18.04.2019, 08:02
Ehkäpä se oli testi alitajunnasta tuo projekti tilastot osion laventaminen...  johtuen tuosta>>
Olisihan se hyvä että kertoisi selvällä suomen kielellä.. mitä tarkoittaa, ehkäpä ymmärsin jo edellisellä kerralla asian toisin..
 (Ja einarille tiedoksi, tähän ketjuun ei kaivata mitään nillitystä. « Viimeksi muokattu: Torstai, 28.06.2018, 00:25 kirjoittanut weatherc »)

//tosin tähän osioon ei sitten kukaan kirjoittanutkaan, käyköhän tälle samoin//

Eli ehkä käsitin näin... "Nillittäjä on eräänlainen nilviäisen ihmismuoto, selkärangaton, mustekalaa älykkyyosamäärältään muistuttava laji, jolla on raastinkieli." (artikkeli/ me naiset, vuodelta 2016)

Toisaalta, ei ole muuta virallista merkitystä kuin se wiki- tai sivistyssanakirjan sama selitys...
Otsikko: Vs: Projekti tilastot
Kirjoitti: Naruskan Ukka Matinpoika - Torstai, 18.04.2019, 10:32
Täältä Naruskan suunnalta näyttäis siltä, että einari ja weatherc saavat keskenään paljon aikaiseksi näissä keskusteluketjuissa. Tietoa on, keskinäiset ilmaisut vain joissain kohdin vaativat selkeyttä asiaa ymmärtämättömän Ukka Matinpojan arvion mukaan.

Ei kannata kummankaan heittää pyyhettä kehään, eikä takkia käännellä...Näin sen näjen... ;)
Otsikko: Vs: Projekti tilastot
Kirjoitti: khyron - Torstai, 18.04.2019, 23:22
Tää on nyt semmosta yleisempää pohdintaa, mutta onko sulla siis taulu jokaiselle asemalle erikseen? Oletan et kyse on kuitenkin relaatiokannasta vaikka taulukoista puhutkin.
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Perjantai, 19.04.2019, 11:38
Tää on nyt semmosta yleisempää pohdintaa, mutta onko sulla siis taulu jokaiselle asemalle erikseen? Oletan et kyse on kuitenkin relaatiokannasta vaikka taulukoista puhutkin.

On, koska se oli helpoin tapa toteuttaa tuo keräys ilman että yksittäinen taulu olisi kasvanut hermottoman kokoiseksi. Tietenkin ne pystyisi tuuppaamaan kaikki samaan tauluun mutta esim PWS:en osalta se tekisi karkeesti laskettuna n 18 miljoonaa riviä silloin kun taulu "täynnä" eli vuoden datat kaikista. Ja tunnetustihan mysql rupee tökkimään kun päästään yli miljoonan rivin ellei sitten ole jokaikinen data indeksoituna myslin mielestä oikein (vrt Geoname-taulu vajaalla 2 milj rivillä joka mulla on).
Otsikko: Vs: Projekti tilastot
Kirjoitti: khyron - Perjantai, 19.04.2019, 17:05
Tää on nyt semmosta yleisempää pohdintaa, mutta onko sulla siis taulu jokaiselle asemalle erikseen? Oletan et kyse on kuitenkin relaatiokannasta vaikka taulukoista puhutkin.

On, koska se oli helpoin tapa toteuttaa tuo keräys ilman että yksittäinen taulu olisi kasvanut hermottoman kokoiseksi. Tietenkin ne pystyisi tuuppaamaan kaikki samaan tauluun mutta esim PWS:en osalta se tekisi karkeesti laskettuna n 18 miljoonaa riviä silloin kun taulu "täynnä" eli vuoden datat kaikista. Ja tunnetustihan mysql rupee tökkimään kun päästään yli miljoonan rivin ellei sitten ole jokaikinen data indeksoituna myslin mielestä oikein (vrt Geoname-taulu vajaalla 2 milj rivillä joka mulla on).

Nyt kuulostaa erikoiselta, miljoona riviä ei vielä ole hirveen paljon. Just vilasin ni yhdessä taulussa on 31 miljoonaa riviä eikä sen kanssa mitään ongelmia ole ollu. Jos taas tarkotat tökkimisellä hakujen hidastumista niin siihen oikea ratkaisu on juurikin indeksit.
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Perjantai, 19.04.2019, 18:13
Nyt kuulostaa erikoiselta, miljoona riviä ei vielä ole hirveen paljon. Just vilasin ni yhdessä taulussa on 31 miljoonaa riviä eikä sen kanssa mitään ongelmia ole ollu. Jos taas tarkotat tökkimisellä hakujen hidastumista niin siihen oikea ratkaisu on juurikin indeksit.

Se on totta, ettei miljoona tai pari rivejä pitäisi olla mitään. Nimenomaan hidastumista tarkoitin. Sainhän mä aikoinas dedinkin nurin juuri Geonamesin alunperin n 8 milj rivin taulukolla kun ei indeksit ollu ihan kohdillaan kun sen dedille dumppasin :P
Tilan puutteessa taas, niin syö nuo indeksit kivasti tilaakin, tuo Geonames-taulukko siivottuna ja karsittuna on 205 MB data ja 125 MB indeksit.  :)
Toisaalta toimii nuo keruu-taulukot ihan hyvin noin 1 per asema. Siitähän lienee yhtä monta mielipidettä kun vastaajaa että onko monta pientä taulukkoa vai yksi jättikokoinen parempi kun myslistä on kyse.

EDIT: Mikäänhän ei estä kokeilemasta yhtä suurta taulukkoa ja katsoa miten se toimii :)
EDIT 2: Laskin väärin tuon 18 milj... 3 dataa tunnissa x 7000 asemaa x 365 vrk tekee n 184 milj riviä...  :o :o :o
Otsikko: Vs: Projekti tilastot
Kirjoitti: khyron - Perjantai, 19.04.2019, 22:08
Siinä vaan jätetään kannan ominaisuuksien käyttö puolitiehen jos yritetään ite hoitaa indeksointia, ja koodista tulee turhaan monimutkaisempaa.
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Perjantai, 19.04.2019, 23:30
Siinä vaan jätetään kannan ominaisuuksien käyttö puolitiehen jos yritetään ite hoitaa indeksointia, ja koodista tulee turhaan monimutkaisempaa.

Se on totta että kun kerran nuo indeksit on siihen taulukkoon näpytelly niin nehän raksuttaa siinä taustalla (tosin syöden tilaa samalla).

Sitä en allekirjoita että koodista tulisi monimutkaisempaa monella taulukolla. Sama käyttäjä niitä kaikkia kantoja käyttää (koska helpompi niin).  Saman verran koodia datan hakuun tarvii niin omasta taulukosta kuin yhdistetystä jos yksittäisen aseman dataa ajattelee. Itse asiassa taitaa olla niin että yhdistetystä haku on monimutkaisempaa koska pitää rajoittaa haku id-numerolla ;)
"SELECT * FROM db.asema123" vs "SELECT * FROM db.taulukko WHERE asema = 123"  ;)
Ok, tuolla nyt ei oo mitään käytännön merkitystä mutta kuitenkin  ;D

Datan luonteen takia niin yhdistetty taulukko kaipaa myös uniikin numeron muutoin tulee tupla ja tripla ja 4x dataa ("kiitos" Netatmon toimimaton rajaus joka puskee samoja asemia moneen hakuun) mikä on sinänsä ihan turha data eikä sellaista "omissa taulukoissa" tarvi koska aikaleima toimii niissä uniikkina. Yhdistetyssähän tulee moni data samalla aikaleimalla joten siinä se ei toimi. Ja ei, php ei saanut niitä ylimääräisiä karsittua...
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Lauantai, 20.04.2019, 07:58
"Kannattaisko einarin ottaa selvää/kysyä mitä tarkoitetaan jollain sanalla jollei tiedä ennen kuin vetää johtopäätöksensä?"

Einari otti selvää ja tuli siihen tulokseen että taitaa jossain muussa suunnassa olla Nillitys enempi vallassa.. enhän pienistä.. vaan suurista outouksista olen valittanut  ???

Hipsteri nillittää.... kirjoittaa tuo "totuuden torvi", YLE... jutussaan kielitoimiston sanakirjasta...
https://yle.fi/uutiset/3-7711599

Kun weatherc otti netatmon tapetille.. uskallan nyt vähän nillittää.. (sopisiko että jätetään merkityksetön sana unholaan?)

Datan luonteen takia niin yhdistetty taulukko kaipaa myös uniikin numeron muutoin tulee tupla ja tripla ja 4x dataa ("kiitos" Netatmon toimimaton rajaus joka puskee samoja asemia moneen hakuun) mikä on sinänsä ihan turha data eikä sellaista "omissa taulukoissa" tarvi koska aikaleima toimii niissä uniikkina. Yhdistetyssähän tulee moni data samalla aikaleimalla joten siinä se ei toimi. Ja ei, php ei saanut niitä ylimääräisiä karsittua...

Onko se ihan varma että aikaleima on uniikki... vaikka olisikin netatmon päässä oletuksena se 6 desimaalin sekuntijaotus... eli miljoonasosa..  lotossakin on    1/18 643 560 päävoiton todennäköisyys.. eli 18,5 x pienempi, silti saattaa olla useampia kerralla..

Toiseksi, onko se aikaleima netatmon purkin ilmoittama, tai kyseisen anturin.. jos on niin tuskin niin isoa skaalaa.. luultavasti vain sekuntitasolla.. vai onko se aika jolloin kirjautuu getstationdatan kantaan.. vai aika kun siirtyy getpublicdataan.. ?

Itse kallistuisin siihen että kyseessä olevan anturin  aikaleima.. Ihan sillä perusteellakin, että jos on katkos datan toimittamisessa ranskaan, niin jokainen puuttuva 5 min. tallentuva data lähetetään omalla aikaleimallaan, tuskimpa siellä päässä arvotaan niille aikaleimoja. :D

Jos on näin.. tuskimpa anturiin on ohjelmoitu aika sen kummemmalla kuin sekuntitarkkuudella.. ja kun luultavasti on näin.. oletan edelleen että koska anturi lähettää tietoa noin 5 min. välein voi laskea että 5x60s = 300 sekuntia.. (12 min. haussa on 2-3 eri aikaleimaa periaatteessa, tosin koska data menee getstationdatasta julkiselle puolelle 10 min. välein.. ehkä 2 aikaleimaa samalta asemalta, olisiko tämä yksi syy weatherc:n mainitsemiin ongelmiin?)

Oikeastaan laskin tuon 300 sekuntia siksi että jos on esim. 6000 moduulia haussa, niin tasaisella taulukolla olisi 20 prikuulleen samaa aikaleimaa.. +/- sattumien sanelema määrä..

Jos puhutaan uniikista tiedosta, niin netatmojen osalta on niitä pääpurkin ID, moduulien ID:t sekä paikkatieto.... sanoisin.

Oliko nyt kunnon Nillitystä ::)

Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Lauantai, 20.04.2019, 11:34
Lainaus
Onko se ihan varma että aikaleima on uniikki... vaikka olisikin netatmon päässä oletuksena se 6 desimaalin sekuntijaotus... eli miljoonasosa..  lotossakin on    1/18 643 560 päävoiton todennäköisyys.. eli 18,5 x pienempi, silti saattaa olla useampia kerralla..

Omalla taulukolla aikaleima on uniikki, yhdistetyllä ei juuri koska se on sekuntitasolla eli unix timestamppi. Kysehän on juuri siitä että "uniikkin sarakkeeseen" ei tule kahta samanlaista arvoa, on ne arvot mitä tahansa. Kun sarake on määritetty uniikiksi ei mysli salli kahta samanlaista arvoa sinne.

Yhdistettyyn taulukkoon joka koekerää Netatmoilta piti virittää EWN id + aikaleima - viritys jotta toimisi (näin se sallii yhden datan per asema per päivitys), tämä taas on periaateessa 16 merkkiä turhaa dataa joka riville. Illan ja yön aikana saatu kasaan 62000 riviä dataa :P
Otsikko: Vs: Projekti tilastot
Kirjoitti: khyron - Lauantai, 20.04.2019, 12:29
Siinä vaan jätetään kannan ominaisuuksien käyttö puolitiehen jos yritetään ite hoitaa indeksointia, ja koodista tulee turhaan monimutkaisempaa.

Se on totta että kun kerran nuo indeksit on siihen taulukkoon näpytelly niin nehän raksuttaa siinä taustalla (tosin syöden tilaa samalla).

Sitä en allekirjoita että koodista tulisi monimutkaisempaa monella taulukolla. Sama käyttäjä niitä kaikkia kantoja käyttää (koska helpompi niin).  Saman verran koodia datan hakuun tarvii niin omasta taulukosta kuin yhdistetystä jos yksittäisen aseman dataa ajattelee. Itse asiassa taitaa olla niin että yhdistetystä haku on monimutkaisempaa koska pitää rajoittaa haku id-numerolla ;)
"SELECT * FROM db.asema123" vs "SELECT * FROM db.taulukko WHERE asema = 123"  ;)
Ok, tuolla nyt ei oo mitään käytännön merkitystä mutta kuitenkin  ;D

Datan luonteen takia niin yhdistetty taulukko kaipaa myös uniikin numeron muutoin tulee tupla ja tripla ja 4x dataa ("kiitos" Netatmon toimimaton rajaus joka puskee samoja asemia moneen hakuun) mikä on sinänsä ihan turha data eikä sellaista "omissa taulukoissa" tarvi koska aikaleima toimii niissä uniikkina. Yhdistetyssähän tulee moni data samalla aikaleimalla joten siinä se ei toimi. Ja ei, php ei saanut niitä ylimääräisiä karsittua...

Se asema pitää kuitenkin valita, where ehdossa se on vaan normaalia tehdä.

Erillisillä tauluilla jää datan eheys tarkistamatta.

Yhdistettyyn tauluun ei tarvitse, eikä kannata, tehdä generoitua avainta koska asema ja aika on uniikki.

Data sekoittuu kannan rakenteeseen, mm. Transaktiot menee rikki kun osa datasta onkin kannan rakenteessa ja kirjoitetaan ddl:lä.

Taulun rakenteen muutos on monimutkaisempi operaatio jos sama muutos pitää tehdä useaan paikkaan.

Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Lauantai, 20.04.2019, 12:38
Yhdistettyyn tauluun ei tarvitse, eikä kannata, tehdä generoitua avainta koska asema ja aika on uniikki.

Totta mutta erilillisinä sarakkeina (ID sekä Time) noita tulee monta samalaista eikä uniikki silloin toimi. (Kts kuva)

Taulun rakenteen muutos on monimutkaisempi operaatio jos sama muutos pitää tehdä useaan paikkaan.

Tavallaan ehkä, mutta kun on valmis häkkyrä sitä varten että plärää taulukot läpi niin suht helppoahan se on tehdä. Toisaalta, jättimäisen taulukon muuttaminen voi kestää ikuisuuden ja se on todennäköisesti lukittuna koko tuon ajan (ja hyvässä lytyssä kaataa koko myslin). Toki kovin paljoa muutoksiahan tuohon ei koskaan tule muuta kun siivousta vanhat datat ulos...

Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Lauantai, 20.04.2019, 12:45
Omalla taulukolla aikaleima on uniikki, yhdistetyllä ei juuri koska se on sekuntitasolla eli unix timestamppi. Kysehän on juuri siitä että "uniikkin sarakkeeseen" ei tule kahta samanlaista arvoa, on ne arvot mitä tahansa. Kun sarake on määritetty uniikiksi ei mysli salli kahta samanlaista arvoa sinne.

Yhdistettyyn taulukkoon joka koekerää Netatmoilta piti virittää EWN id + aikaleima - viritys jotta toimisi (näin se sallii yhden datan per asema per päivitys), tämä taas on periaateessa 16 merkkiä turhaa dataa joka riville. Illan ja yön aikana saatu kasaan 62000 riviä dataa :P

Tein äsken muutaman haun.. netatmohan antaa time_serverin lisäksi 4 muuta aikaleimaa/haku, pääosin hieman eri aikoja poislukien kerran wind ja rain pukkasi saman aikaleiman. eli 36 min. sisällä 3 time_serveraikaa ja 12 moduulikohtaista aikaleimaa...

Mitähän tuo EWN:n id + aikaleima mahtanee tarkoittaa? Liekö sama minkä saa jokaisessa netatmon haussa, eli pääpurkin id, se jossa on pressure-arvo ainoastaan  julkista dataa..  tuota en tiedä, onko time_server uniikkia?

edit// selvis se ewn id
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Lauantai, 20.04.2019, 14:29
Lainaus
Tein äsken muutaman haun.. netatmohan antaa time_serverin lisäksi 4 muuta aikaleimaa/haku, pääosin hieman eri aikoja poislukien kerran wind ja rain pukkasi saman aikaleiman. eli 36 min. sisällä 3 time_serveraikaa ja 12 moduulikohtaista aikaleimaa...

Mitähän tuo EWN:n id + aikaleima mahtanee tarkoittaa? Liekö sama minkä saa jokaisessa netatmon haussa, eli pääpurkin id, se jossa on pressure-arvo ainoastaan  julkista dataa..  tuota en tiedä, onko time_server uniikkia?

Netatmon antamat ajat eivät toimi koska kun pari tuhatta asemaa niin aina löytyy joku jolla sama aikaleima kun jollain toisella kun tuo leima on "vain" sekuntitasoa. Ja vaikka olisi mikrosekuntitasoakin niin olisi riski että osuisi samaan joskin riski olisi paljon pienempi. Tuohon samaan taulukkoon kun lykätään vielä muut pws-asemat niin alkaa sekunti-osumaa olemaan enemmänkin.
Ja se että lähtis penkomaan läpi kaikkia Netatmon antamia leimoja tekisi hommasta vaan monimutkaisen ja fail-alttiin.

Kysehän on lähinnä varmistuksesta ettei sama data mene kahteen kertaan taulukkoon. Eli kunhan PHP suostuisi karsimaan ulos duplikaatit ennen kantaan menoa niin homman *pitäisi* toimia. Datoja ei päivitetä mysliin yksitellen/yksi asema kerrallaan vaan yhtenä isona dumppina multi_queryllä. Näinollen ei voi kannasta tarkistaa onko se jo siellä ja se tekisi vaan turhaan lisää kyselyjä jos jokaista pitäisi tarkistaa erikseen. Myslin avg qps on jo nykyiselläänkin 280...

EWN id on aseman id-numero jonka mukaan se löytyy kannasta :)   
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Lauantai, 20.04.2019, 15:07
Yks hyvä kysymys on tietty myös se, että mikä typpi tuollaiselle isolle taulukolle, MyIsam vai InnoDB? InnoDB on ainakin isompi kooltaan. Tässä tietty haetaan lähinnä hyvää suorituskykyä, ei niinkään pienintä kokoa.
Kun jotain stackoverflow:ta ym tutkailee niin vastaus riippuu ihan vastaajasta.
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Lauantai, 20.04.2019, 15:53
Eikös nuo NoSQL:t ole nykyään jonkinmoisessa huudossa.. kuten tämä / Taitaa olla useimmilla purkeilla saatavana?
https://www.mongodb.com/nosql-explained
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Lauantai, 20.04.2019, 16:11
Lainaus
Totta mutta erilillisinä sarakkeina (ID sekä Time) noita tulee monta samalaista eikä uniikki silloin toimi. (Kts kuva)

Hep, saihan nuo yhdessä uniikiks kunhan ensin tyhjensi taulukon (koska duplikaatteja). No, siksihän se on vielä koekäytössä että oikut löytyisi :)

Eikös nuo NoSQL:t ole nykyään jonkinmoisessa huudossa.. kuten tämä / Taitaa olla useimmilla purkeilla saatavana?
https://www.mongodb.com/nosql-explained

Ovat, ja onhan mullakin käytössä yks RAM:ssa toimiva (Aerospike) BO:n iskuille. Huono puoli on se että data lähtee taivaan tuuliin jos reboottaa purkin mutta BO:n tarkoitukseen se on just sopiva.

EDIT: Esim MongoDB joka on Nosql on huomattavasti hitaampi SELECT-komennossa mitä Mysli, ja selectiähän tuossa tilasto-taulukossa nimenomaan tarvitaan: https://www.simform.com/mongodb-vs-mysql-databases/
Otsikko: Vs: Projekti tilastot
Kirjoitti: khyron - Lauantai, 20.04.2019, 16:58
Yhdistettyyn tauluun ei tarvitse, eikä kannata, tehdä generoitua avainta koska asema ja aika on uniikki.

Totta mutta erilillisinä sarakkeina (ID sekä Time) noita tulee monta samalaista eikä uniikki silloin toimi. (Kts kuva)

Taulun rakenteen muutos on monimutkaisempi operaatio jos sama muutos pitää tehdä useaan paikkaan.

Tavallaan ehkä, mutta kun on valmis häkkyrä sitä varten että plärää taulukot läpi niin suht helppoahan se on tehdä. Toisaalta, jättimäisen taulukon muuttaminen voi kestää ikuisuuden ja se on todennäköisesti lukittuna koko tuon ajan (ja hyvässä lytyssä kaataa koko myslin). Toki kovin paljoa muutoksiahan tuohon ei koskaan tule muuta kun siivousta vanhat datat ulos...

Jos aseman id on uniikki ja aikaleiman pitää olla aseman sisällä uniikki ni eihän noi yhdessä voi olla muuta kuin uniikki.

Ja kaikkee voi toki scriptata, mut sen järkevyys on vähän kyseenalaista jos vois käyttää valmista.

Yks hyvä kysymys on tietty myös se, että mikä typpi tuollaiselle isolle taulukolle, MyIsam vai InnoDB? InnoDB on ainakin isompi kooltaan. Tässä tietty haetaan lähinnä hyvää suorituskykyä, ei niinkään pienintä kokoa.
Kun jotain stackoverflow:ta ym tutkailee niin vastaus riippuu ihan vastaajasta.

Innodb, myisam on lähinnä historian painolastia, ei tue transaktioita tai viiteavaimia.

Ennemmin pohtisin mikä kanta olisi parempi, esim postgresql tukee brin-indeksejä jotka vie vähemmän tilaa ja sopii esim. Aikasarjoille hyvin. Tai sitten joku aikasarjajoihin erikoistunut kanta niinkuin influxdata. Tai timescaledb laajennus postgresqllään.
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Sunnuntai, 21.04.2019, 12:39
Lainaus
Jos aseman id on uniikki ja aikaleiman pitää olla aseman sisällä uniikki ni eihän noi yhdessä voi olla muuta kuin uniikki.

On, ja sehän oli koko ajan se ajatuskin että id + aikaleima = uniikki. Mysli ei vaan ensin suostunut asettaa niitä sarakkeita nippuna uniikiksi koska oli valmiiksi duplikaatteja koska parhammillaan/pahimmillaan saman Netatmon datat tulee 5:ssä eri haussa. 
Mutta, nyt näyttää toimivan ok tuo keruu Netatmojen osalta (muut pws:ät ja laitokset eivät ole ongelma tässä mielessä). Näyttää myös tulevan ihan kohtalaisen hyvin dataa per tunti kun antaa tuupata käppyrädataa joka kierroksella (5 kierrosta/tunti).
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Sunnuntai, 21.04.2019, 20:21
On, ja sehän oli koko ajan se ajatuskin että id + aikaleima = uniikki. Mysli ei vaan ensin suostunut asettaa niitä sarakkeita nippuna uniikiksi koska oli valmiiksi duplikaatteja koska parhammillaan/pahimmillaan saman Netatmon datat tulee 5:ssä eri haussa. 
Mutta, nyt näyttää toimivan ok tuo keruu Netatmojen osalta (muut pws:ät ja laitokset eivät ole ongelma tässä mielessä). Näyttää myös tulevan ihan kohtalaisen hyvin dataa per tunti kun antaa tuupata käppyrädataa joka kierroksella (5 kierrosta/tunti).

Tuossahan on kyse siitä että kun bulkkina haetaan, ei voi saada vain sitä mitä haluaa..  ;D

Mainitsin aiemmin että voisi tehdä sellaisen yksilöidyn keruun.. toki haku tapahtuisi samoin kaikista tunnuksensa antaneilta..
helpoin tapa kai olisi että tekee sellaisen apin sinne joka hakee ja hakee hyväksynnän netatmolta.. tuon sivun mukaisesti
https://dev.netatmo.com/en-US/resources/technical/reference/smarthomeapi

Liimiiteissä ei pitäisi olla ongelmaa, varsinkaan kun hakee sen 10 min. välein ja vain outdoor-datan..
https://dev.netatmo.com/en-US/resources/technical/guides/ratelimits

Vaikea arvioida miten moni liittyisi jos laittaa ewn:n sivuille ohjeet ja linkin sellaiselle kirjautumissivulle jossa tunnus annetaan.. (kuva metewaren appiin)
Sen datanhan voi ohjata erilliseen tietokantaan... kuin tuon publicin...  ja tietysti vaatimukset että asema on oikeaoppisesti asemoitu ;D

Katsoin muistin verestämiseksi tuota Hamiltonin Wd-sivua, siellä ei ole erikseen kirjautumissivua vaan jää näkyviin sinne ohjelman asetuksiin..

Tarkoitan sitä että ewn:ssä voisi olla paremmat netatmot ja sellaiset vähemmän paremmat eri osiossa ::)

Edit// pitäisiköhän niille esittää tuollaista vähän simppelimpää algoritmia, niillä taitaa ola liian vaikeaksi tehty se 8)
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Maanantai, 22.04.2019, 08:17
Ilmeisesti vain tuo enterprise.api tarvitsee sen luvan.. eli tilauksen, suunnattu yrityksille.. eihän ewn ole yritys ;D

eli pitää vain olla keino millä ne acces_tokenit saa jokaiselle asemalle joka haluaisi sitä parempaa dataa ilman katkoksia.. ja jos ja kun sellaisia sattuisi tulemaan niin sieltä saa ne  puuttuvat palaset...  niiltä osin kuin moduulit kerää ja tallentaa, sekä lähettää omaan, asemakohtaiseen tiedostoon 8)
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Maanantai, 22.04.2019, 12:33
Miksi tehdä asia monimutkaiseksi kun eräskin asema pohjanmaan suunnalta näyttää tuuppaavan dataa kiltisti 5 krt/tunnissa? ;)

Lainaus
Liimiiteissä ei pitäisi olla ongelmaa, varsinkaan kun hakee sen 10 min. välein ja vain outdoor-datan..
Mitenhän oli einarin sisälukutaidon kanssa? 2000 hakua tunnissa yksitellen haettuna ei ole mitään. 6 krt stunnissa, 5 anturia niin tuohon mahtuisi kokonaiset 66 asemaa. SMHI:n ja MET.no:n asemien datat haetaan tuolla tapaa, yks haku per asema per anturi ja hakuja taitaa olla sen reilut 10k per kierros..

Sitäpaitsi sulta unohtuu yksi seikka, aika mitä hakuun menisi. Ei mitään mahista saada dataa haettu vaikkapa 10 min välein tuolla tapaa kun alle 20 hakuakin tahtoo viedä sen 5 minuuttia, ranskisten purkit kun eivät vastaile mitään kovin nopeasti...
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Maanantai, 22.04.2019, 15:13
Kyllä einarin sisälukutaito on kohdillaan... siinähän seisoo että jos alle 100 asemaa niin 2000 pyyntöä tunnissa...  ja vaikkapa 90 asemaa tekee 540 pyyntöä tunnissa...

jos yli 100.. niin 20x asemien määrä.. eli jos vaikka 500 niin 10k pyyntöä tunnissa mahdollista

sitten, yksi asema ei vie 30 hakua tunnissa.. vaan tasan 6 jos 10 min välein...  se kun tuo getstationdata antaa kerralla kaikki arvot..
Get the last measures from all the devices of one user with the Getstationsdata method.

eli kuvat kertovat enemmän.. pyyntö-nimisessä kuvassa on vain että lue asema.. eli read_station
ja tällaisen vastauksen saa kuten kuvassa read_station luetellaan..

sitten siihen hakuaikaan.. nehän voi olla siinä yhdessä haussa kerrallaan nuo asemat.... luulisin.. niiden yksilöintitieto on vain se aseman pääyksikön id..... (tai paikkahan on jokaisella eri)

Edit//
Se  bulk-haku koskee ilmesesti vain sitä Enterprise.apia >>
With Netatmo Smart Home API, you can access your users' station measurements (indoor and outdoor).
With Netatmo Enterprise API, you can access bulk data from your users' Weather Stations.
 
kai sitä ei sittenkään sen kummemminenterpriseen  lupaa pyydellä kunhan ehtojen mukaan menee..
https://dev.netatmo.com/resources/technical/guides/developerguidelines
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Maanantai, 22.04.2019, 17:03
Lainaus
siinähän seisoo että jos alle 100 asemaa niin 2000 pyyntöä tunnissa...  ja vaikkapa 90 asemaa tekee 540 pyyntöä tunnissa...
jos yli 100.. niin 20x asemien määrä.. eli jos vaikka 500 niin 10k pyyntöä tunnissa mahdollista

Ei limiiteissä ole asemien lukumäärästä kyse vaan users = todennäköisesti ip-numero tai tuo auth token joka täytyy ensin hakea, eli ewn:n purkilta saa juuri tuon 2000 hakua tunnissa, ei enempää.
Koska nuo limiitit ovat designattu user-perusteiseksi niin se on lähinnä appi-tyyliseksi tarkoitettu. Noilla limiiteillä nimeomaan halutaan estää EWN-tyylisten systeemien data-haun yksitellen.

Lainaus
The user limit is here to prevent one user from disabling your app ability to call Netatmo APIs.
As this limit is quite high, reaching it usually means that your app makes too many API calls and you should use a few design tricks to reduce the number of calls made.
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Maanantai, 22.04.2019, 19:09
Kun mainitsin asemat.. niin oletuksena on että jos haetaan sillä aseman id:llä niin yhdellä käyttäjällä on silloin 1 asema... eli station/user..
eihän se sitä miksikään muuta.. kumpi termi on kyseessä...   se kuitenkin lienee oikein että sillä 6 haulla/ tunti/käyttäjä..tai asema, selvinnee.. mahdollisuushan olisi 20 hakuun/käyttäjä/tunti.. rajassa varaa kun on termostaatteja ja sun muita.. samaisella 20 se limiitti kasvaa kun yli sata käyttäjää.. /luvan antaneita/

Mitä se 2000 raja pitää sisällään ewn:n suhteen..  laskin että äsken oli 600-700 asemaa tuoreella datalla.. kaikki kun ruksaili niin reilu tuhat.. ?
Harmi, jos ewn:n suhteen ei ole tilaa testata...   mutta jos niin voin antaa käyttöön mitä tarvitaan...  :D


 
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Maanantai, 22.04.2019, 19:50
Kun mainitsin asemat.. niin oletuksena on että jos haetaan sillä aseman id:llä niin yhdellä käyttäjällä on silloin 1 asema... eli station/user..
eihän se sitä miksikään muuta.. kumpi termi on kyseessä...   se kuitenkin lienee oikein että sillä 6 haulla/ tunti/käyttäjä..tai asema, selvinnee.. mahdollisuushan olisi 20 hakuun/käyttäjä/tunti.. rajassa varaa kun on termostaatteja ja sun muita.. samaisella 20 se limiitti kasvaa kun yli sata käyttäjää.. /luvan antaneita/

Mitä se 2000 raja pitää sisällään ewn:n suhteen..  laskin että äsken oli 600-700 asemaa tuoreella datalla.. kaikki kun ruksaili niin reilu tuhat.. ?
Harmi, jos ewn:n suhteen ei ole tilaa testata...   mutta jos niin voin antaa käyttöön mitä tarvitaan...  :D

Jokaiseen hakuunhan tarvittan tuo auth token eli veikkaan että se kerryyttää myös limiittilaskuria. Tuo aúthihan haetaan client_id ja client_secretin kanssa. Tämän lisäksi jäänee ip-numero josta se haetaan heidään logeihin. Ei tarvi olla kummallinen insjenjööri, edes ranskalainen sellainen, että alkaisi valot vilkumaan punaista jos samasta ip-numerosta (dediltä) alkaisi tulemaan hakuja kasapäin eri auth tokeneilla...
Otsikko: Vs: Projekti tilastot
Kirjoitti: einari - Maanantai, 22.04.2019, 21:22
Hakuhan suoritetaan sitten viimekädessä sovelluksen.. eli apin tekijän auth tokenilla... kun tehdään se smart home- tai enterprise-apista.
muilta käyttäjiltähän on acces_token ja refres_token joilla valtuutus hoidetaan.. ilmeisesti antavat jonkin määräajan, milloin pitää käyttöoikeus uusia.. se on huono puoli..   Mainitsemani Hamilton tietänee asiasta enemmän.. kun WD:lle antaa netatmon tunnuksen ja salasanan.. eli sähköpostiosoitteen ja neatmon salasanan (siis sinne netatmon accountiin kirjaudutaan sähköpostios)

wd:ltä sitten näkyy netatmon setupissa third party apps- osiossa että wd käyttää tietojani smart home apilla... ;D
siellä on myös smartmixin ja netatmo support..
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Tiistai, 23.04.2019, 11:24
Taulukko jossa nuo kaikki käppyrädatat ovat samassa taulukossa näperretty kasaan. Tällä hetkellä 24 milj riviä ja 2.3 GB kokoa. tämä pelkät pws:ät ;D
Otsikko: Vs: Projekti tilastot
Kirjoitti: weatherc - Keskiviikko, 24.04.2019, 21:32
Sitten kysymys:
Mitä päivittäisiä arvoja pitäisi generoida?
Nyt saa ehdottaa :)

Max/min/keski lämpötilä
Max/min ilmanpaine
HDD
CDD

Pitää muistaa että data on ~5 krt tunnissa napsittua sen hetken arvoja, tiesäät ja laitokset 4-5 krt tunnissa (joiltakin laitoksilta 1 krt tunnissa) eli nopeasti vaihtuvan datan maksimiarvoja ei saa (kuten tuuli)...