Tietokannan uudelleenrakentelu

[khyron]

Käytä joko INSERT IGNORE tai REPLACE.

Niin joo, totta. Tosin, se ei paljoa lohduta kun WD:n logfilu voi näyttää tältä (se on suora kaappaus meikäläisen logista), siinä siis 20 riviä yhdelle 10 minuutin pätkälle...
1  9 2011  0  0 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  1 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  2 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  3 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  4 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  5 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  1 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  2 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  3 8.9  96 08.3 1003.6   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  0 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  6 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  7 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  8 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  9 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0 10 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  6 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  7 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  8 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9
1  9 2011  0  5 8.9  96 08.3 1003.7   0   0 270 0.0 0.0 0.0 368.8 8.9

Onko tuo siis muotoa:
mm dd yyyy hh mi ja loppu dataa?

Mikä siinä siis on se ongelma? Pitääkö kaikki data säilyttää ja saada jollain logiikalla eri aikaleimoille?

Mysqlimport ja LOAD DATA INFILE on muuten kans kätsyjä datan importointiin. http://dev.mysql.com/doc/refman/5.0/en/mysqlimport.html

[weatherc]

mm dd yyyy hh mi ja loppu dataa?

Juu.
Itse data-rivin parsiminen ei ole se ongelma vaan tuo että WD on tuossakin esimerkissä tuupannut kymmenen minuutin ajalle 20 riviä dataa kun niitä pitäisi olla se 10. Ja minuutit ovat ihan sekaisessa järjestyksessä.
Näin sellaisia kymmenminuuttisia jossa samalla minuutilla oli eri arvojakin.

Tuon lisäksi löytyy pätkiä jossa sama aikajakso voi olla kahteen kertaan. Siivosin jo ulos syyskuun alusta 2 tuntia 1.9 klo 00 - n 02 joka löytyi kahteen kertaan.

Eli tuo WD:n aikaansaama log-filu on kaikkea muuta kun valiidia. Ainakin oman kokemuksen mukaan WD:n ongelma ei välttämättä ole livedatan tallennus vaan silloin kun se purkaa loggeria, sen se tuuppaa ihan miten sattuu..

Siinä versiossa jonka puskin mysliin (jonka saan siis helposti vaihdettua uuteen versioon) niin otos on 1 rivi joka tasa 10-minuuttinen eli 00,10,20 jne. Mutta tuo sekaisuus aihetutti sen että samaa aikaa voikin löytyä useaan otteeseen.

Toisen taulukkona tein jossa 1 rivi per päivä jossa maksimit/minimit ja sen sellaiset. Siinä ongelman on päivävaihto ja se silly fakta että WD:n logissa edellisen päivän sade voi roikkua mukana vielä seuraavan päivän ensimmäisissä datoissa, varsinkin kuun vaihtuessa, jolloin kun käytin max(dayvals) eikä sinä päivänä satanut niin mysliin meni se edellisen päivän lukema.

Löysin ww-foorumilta LogFile-utilityn mutta kas vaan se ei toimi 64 bittisessä wintoosassa koska itse appi on 16 bittinen...

[weatherc]

Löysin ww-foorumilta LogFile-utilityn mutta kas vaan se ei toimi 64 bittisessä wintoosassa koska itse appi on 16 bittinen...

Kopsasin filut usb-tikulle ja eikun emännän xp kehiin
Jo ensimmäisestä kuukaudesta (2/2006) löytyi 55 erroria... heh... hmm...

EDIT: hehhe....ei juma kekka...
Format error: On line 22347 Date/Time 3/23 @ 18:60
Ja totta sieltä löytyy rivit "ajoille" 18:60 - 18:66...

EDIT2: No niin tsekattu kaikki logfilut tuolla utilityllä ja noita ihme minuutteja löytys aivan tolkuttomasti noista alun filuista, loppuivat suunnilleen 8/2007. Mutta ennen sitä sieltä löytyi parhaimillaan/pahimmillaan 1 per päivä tuollainen rypäs. Ei oikeen tiennyt itkeä vaiko nauraa kun minuutteja oli esim. 18:60-18:100

[khyron]

Ei tuo että samoilla aikaleimoilla on useita rivejä, tai että ne on epäjärjestyksessä, pitäisi aiheuttaa mitään ongelmia myslille jois käytät noita INSERT IGNORE tai REPLACE lauseita, INSERT IGNORE jättää voimaan ekan löytyneen rivin ja REPLACE viimeisen. Jos taas ongelma on se että haluat keskiarvoja/summia/tms. kymmenen minuutin pätkistä niin mielestäni se kannattaisi tehdä kannassa.

[weatherc]

Ei tuo että samoilla aikaleimoilla on useita rivejä, tai että ne on epäjärjestyksessä, pitäisi aiheuttaa mitään ongelmia myslille jois käytät noita INSERT IGNORE tai REPLACE lauseita, INSERT IGNORE jättää voimaan ekan löytyneen rivin ja REPLACE viimeisen. Jos taas ongelma on se että haluat keskiarvoja/summia/tms. kymmenen minuutin pätkistä niin mielestäni se kannattaisi tehdä kannassa.

Totta, aatos on että muokkais tuota parsimis-skriptiä siten että se käyttää vain noita tasakymmenminuuttisia rivejä, tällöin tuo epäjärjestys ei haittane pahemmin sekä siihen komentoon lisätä tuo INSERT IGNORE. Pitää vaan laittaa checki siihen päivän vaihtoon ettei ota edellisen päivän sateita mukaan seuraavaan päivään sekä pakottaa vuosiluvun/kuukausiluvun siihen filun nimen lukuun eikä uskoa sitä mitä filussa on koska ainakin joissain on ensimmäiset lukemat edellisen vuoden/kuukauden.

Sivulla esim kk ja vv-lämpötilakeskiarvot jotka ovat etusivulla ovat suoraan kannasta avg(temp)-komennolla "FMI-tyylillä" eli käyttäen arvoja 3 tunnin välein.

[weatherc]

No niin, nyt näyttää paljon paremmalta

Tuuppasin datat sisään uudestaan tuolla INSERT IGNORE:lla laittaen ensin aikaleiman indexin UNIQUE:ksi ja meni sisään kaikki 280K riviä heittämällä 
Samoin päivätaulu meni sisään ilman ongelmia. 

Uudet datat menee sisään cronilla 10 min välein sekä päivätauluun puolilta öin clientraw:ta ja testtag:ia käyttäen.
Sivulla on Memcache käytössä noille myslin datoille joten ne eivät välttämättä päivity ihan jokaisella päivityksellä.

[weatherc]

Nyt toimii tilasto-sivun pikkukäyrätkin taas
Vaatii vielä pientä hienosäätöä koska esim. syyskuun keskilämpötila on eri riippuen miten sen ottanut (suoraan kannasta vs keskiarvo päivien keskiarvoista), eroa 0.1 astetta.

Toinen mikä sikinsokin on elo- ja syyskuun sateet. Nyt ei WD ja sivu puhu ollenkaan samaa kieltä niistä. Pitääpi tarkistaa kumpi nyt laskee väärin, eroa koko vuoden osalta on sellaiset 8 mm, jotenkin luotan enemmän myslin sum()-funktioon kun WD:seen jostain syystä...  

[weatherc]

Nyt alkaa olemaan aika aksassa tuo uusistusprojekti, tilastosivujen latautuminenkin nopeutui huomattavasti
Etusivujen käppyrätkin toimii taas ja lisäsin ne uupuvat siihen.

Vielä olisi pieni nikkarointi jäljellä hakea kannasta,
Esim: "Kuinka monta päivää vuodesta ollut Tmin < -20"

Jotain tällaista aattelin: SELECT count(Tmin) FROM db WHERE Tmiin < -20 GROUP by YEAR(DBTime).

Mutta onko keinoa millä saisi ulos useampi raja (-20, -10, 0 jne) samlla haulla?

[khyron]

SELECT YEAR(DBTime),-20,count(Tmin) FROM db WHERE Tmiin < -20 GROUP by YEAR(DBTime)
UNION
SELECT YEAR(DBTime),-10,count(Tmin) FROM db WHERE Tmiin < -10 GROUP by YEAR(DBTime);

SELECT YEAR(db1.DBTime),count(db1.Tmin),count(db2.tmin)
  FROM db db1,db db2
WHERE db1.Tmin < -20
     AND db2.tmin<-10
     and YEAR(db1.DBTime)=year(db2.dbtime)
GROUP by YEAR(db1.DBTime),year(db2.dbtime);

Noin ehkä lähtisin ite kokeileen, en o kyl ihan varma toimivuudesta, ainakaan ton toisen, ilman testausta.

[weatherc]

Tattista.
Ainakin phpmyadminissa tuo ensimmäinen toimis oikeen hyvin
Tuo uusi versio siitä on kyllä aika kätevä ajax-hakuineen