Kirjoittaja Aihe: Projekti tilastot  (Luettu 1644 kertaa)

0 jäsentä ja 1 Vieras katselee tätä aihetta.

Poissa weatherc

  • Ylläpito
  • *****
  • Viestejä: 8369
Vs: Projekti tilastot
« Vastaus #10 : 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...
« Viimeksi muokattu: Perjantai, 19.04.2019, 23:46 kirjoittanut weatherc »

Poissa einari

  • Kiinteä osa Foorumia
  • *****
  • Viestejä: 354
Vs: Projekti tilastot
« Vastaus #11 : 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ä ::)

« Viimeksi muokattu: Lauantai, 20.04.2019, 08:05 kirjoittanut einari »

Poissa weatherc

  • Ylläpito
  • *****
  • Viestejä: 8369
Vs: Projekti tilastot
« Vastaus #12 : 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

Poissa khyron

  • Kiinteä osa Foorumia
  • *****
  • Viestejä: 335
    • Säätila Rauma
Vs: Projekti tilastot
« Vastaus #13 : 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.


Poissa weatherc

  • Ylläpito
  • *****
  • Viestejä: 8369
Vs: Projekti tilastot
« Vastaus #14 : 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...

« Viimeksi muokattu: Lauantai, 20.04.2019, 12:43 kirjoittanut weatherc »

Poissa einari

  • Kiinteä osa Foorumia
  • *****
  • Viestejä: 354
Vs: Projekti tilastot
« Vastaus #15 : 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

Poissa weatherc

  • Ylläpito
  • *****
  • Viestejä: 8369
Vs: Projekti tilastot
« Vastaus #16 : 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 :)   

Poissa weatherc

  • Ylläpito
  • *****
  • Viestejä: 8369
Vs: Projekti tilastot
« Vastaus #17 : 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.

Poissa einari

  • Kiinteä osa Foorumia
  • *****
  • Viestejä: 354
Vs: Projekti tilastot
« Vastaus #18 : 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

Poissa weatherc

  • Ylläpito
  • *****
  • Viestejä: 8369
Vs: Projekti tilastot
« Vastaus #19 : 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/
« Viimeksi muokattu: Lauantai, 20.04.2019, 16:38 kirjoittanut weatherc »