Uutiset:

13.10.2024
PALAUTUMISTIEDOTE

FinWX:n palvelut katkesivat hetkellisesti 13.10.2024. FinWX:n web-serveri palautettu vuorokautta aikaisempaan tilanteeseensa.
Lue häiriötilanteesta lisää täältä.

FinWX:n ylläpito pahoittelee katkoksen aiheuttamaa häiriötä.

Main Menu

consoleWD+mysql 5.1

Aloittaja JyriT, maanantai, 22.02.2010, 10:42

« edellinen - seuraava »

0 Jäsenet ja 1 Vieras katselee tätä aihetta.

JyriT

Jos joku muu painii oheisen yhdistelmän kanssa, ja on onkelmaa kaman työntämisessä kantaan.
Kokeile jos tästä olisi apuja:
mysql:n kannan taulun luontilauseet löytää täältä:
http://www.weather-watch.com/smf/index.php/topic,41140.msg340955.html#msg340955

Ja sitten itse asiaan.. Seuraavassa pläjäyksessä on varmasti löydettävissä huonoa ohjelmointitapaa, kuraa koodia, turhia rivejä, väärää syntaksia, bugeja jne.. Mutta se toimii ;)
edit, päivitin tuota crontabin komentoa jotta se tekee logia tapahtumista

<?php
//weathertodb.php
//connect to db 
include 'db_conn.php';

$paiva date('d/m/y');
$kamaa  = array();
$kamaa file("clientraw.txt");
foreach (
$kamaa as $line_num => $kamaa)
#$seperators = array('" "','" ',' "',' ');
#$kamaa = str_replace($seperators,'_',$kamaa);
$ary explode(' ',$kamaa);
for(
$i=0;$i<count($ary);$i++)
    
$ary[$i] = str_replace('"','',$ary[$i]);
$kello "$ary[29]:$ary[30]";
# $paiva = "$ary[35].$ary[36] 2010";
$saa "$ary[32] $ary[74] $kello $ary[1] $ary[3] $ary[2] $ary[4] 
$ary[5] $ary[6] $ary[7] $ary[8] $ary[9] $ary[10] $ary[11] 
$ary[12] $ary[13] $ary[14] $ary[15] $ary[16] $ary[17] 
$ary[18] $ary[19] $ary[20] $ary[21] $ary[22] $ary[23] 
$ary[24] $ary[25] $ary[26] $ary[27] $ary[28] $ary[29] 
$ary[30] $ary[31] $ary[32] $ary[33] $ary[34] $ary[35] 
$ary[36] $ary[37] $ary[38] $ary[39] $ary[40] $ary[41] 
$ary[42] $ary[43] $ary[44] $ary[45] $ary[46] $ary[47] 
$ary[48] $ary[49] $ary[50] $ary[71] $ary[72] $ary[73] 
$ary[75] $ary[76] $ary[77] $ary[78] $ary[79] $ary[110] 
$ary[111] $ary[112] $ary[113]  ";


// Lisää tieto kantaan
$sql mysql_query("INSERT INTO wx_data (station_id, date, time, average_windspeed, 
wind_direction, gust_windspeed, temperature, outdoor_humidity, barometer, 
daily_rainfall, monthly_rainfall, yearly_rainfall, rain_rate, max_rain_rate_curent_day, 
indoor_temperature, indoor_humidity, soil_temperature, forecast_icon, wmr968_extra_temperature, 
wmr968_extra_humidity, wmr968_extra_sensor_number, yesterday_rainfall, 
extra_temperature_sensor_2, extra_temperature_sensor_3, extra_temperature_sensor_4, 
extra_temperature_sensor_5, extra_temperature_sensor_6, extra_temperature_sensor_7, 
extra_humidity_2, extra_humidity_3, extra_humidity_4, hour, minute, second, station_name, 
dallas_1_wire_lightning_count, actual_solar_reading, day, month, wmr968_battery_level_1, 
wmr968_battery_level_2, wmr968_battery_level_3, wmr968_battery_level_4, wmr968_battery_level_5, 
wmr968_battery_level_6, wmr968_battery_level_7, current_windchill, current_humidex, 
max_daily_temperature, min_daily_temperature, icon_type, current_weather_desc, 
barometer_trend_last_hour, max_gust_current_day, dew_point_temperature, cloud_height, 
max_humidex, min_humidex, max_windchill, min_windchill, davis_vp_uv, max_heat_index, 
min_heat_index, heat_index, max_average_windspeed_day ) 

VALUES('
$ary[32]', '$paiva', '$kello', '$ary[1]', '$ary[3]', '$ary[2]', 
'
$ary[4]', '$ary[5]', '$ary[6]', '$ary[7]', '$ary[8]', '$ary[9]', 
'
$ary[10]',  '$ary[11]', '$ary[12]', '$ary[13]', '$ary[14]', 
'
$ary[15]', '$ary[16]', '$ary[17]', '$ary[18]', '$ary[19]', 
'
$ary[20]', '$ary[21]', '$ary[22]', '$ary[23]', '$ary[24]', 
'
$ary[25]', '$ary[26]', '$ary[27]', '$ary[28]', '$ary[29]', '$ary[30]', 
'
$ary[31]', '$ary[32]', '$ary[33]', '$ary[34]', '$ary[35]', '$ary[36]', 
'
$ary[37]', '$ary[38]', '$ary[39]', '$ary[40]', '$ary[41]', '$ary[42]', 
'
$ary[43]', '$ary[44]', '$ary[45]', '$ary[46]', '$ary[47]', '$ary[48]', 
'
$ary[49]', '$ary[50]', '$ary[71]', '$ary[72]', '$ary[73]', '$ary[75]', 
'
$ary[76]', '$ary[77]', '$ary[78]', '$ary[79]', '$ary[110]', '$ary[111]', 
'
$ary[112]', '$ary[113]'    ) ")
or die(
mysql_error());


echo 
"sää lisätty, tulostetaan lista..";

echo 
$saa;

mysql_close($mysql_id);


***********************************

<?
php
//db_conn.php
//connect to db
$mysql_id mysql_connect('db_server''username''password') or die(mysql_error());
mysql_select_db("database"$mysql_id) or die(mysql_error());
?>


************************************
crontab:
*/5 * * * * /usr/bin/php -q /tähänpolkutiedostoon/weathertodb.php >> /tähänpolkucroninluomaanlogitiedostoon/logfile.log


************************************

weatherc

Mulla ollut enemmän kun kerran mielessä siirtyä/kokeilla WD:n Console-versiota Linukalla ja aatos tulee mieleen joka kerta kun Windows WD temppuilee, jostain kumman syystä.
Suurin kulmakivi koko aseman siirtoon Linukalle on tuo ukkostutkan PCI-ajuri, Boltekin sivuilta löytyy kyllä unix-ajuri mutta viimeksi kun kokeilin en saanut toimimaan saatikka se että Nextorm on "only Windows". Tosin sen sais varmaan toimaan Winellä ihan hyvin, mutta silloinkin tarvis ensin saada se ajuri toimimaan.

Linukalla kun olis aika paljon helpompaa väsätä kaikenlaista, kuten tehdä paikallinen mysql-tietokanta koko aseman historiasta, puhumattakaan siitä että silloin vois opetella/kokeilla paljon paremmin, varsinkin jos tekee sen "yks-yhteen" tuon VPS:n kanssa että on sunnilleen samat versiot php:stä ym:sta. Muutenkin vaikuttaa tämä centos5 (jolta tätäkin kirjoitan) mukavan kevyeltä ja vakaalta, ilman turhia härpäkkeitä

Se mitä tarvis saada Console-WD:n datasta tehtyä on:
- clientraw + custom tagit (löytyy)
- mysql-kanta (löytyy joko Consolen omana palikkana tai php:llä aĺa JyriT)
- Jonkunlaiset NOAA-raportit, onko muuten tietoa löytyykö sellaista skriptiä vai pitäiskö kysyä noilta guruilta ww-foorumilla?

Mysql-kantoja tarvis varmaan tehdä ainakin 2, 1 min välein päivittyvä sekä päivittäinen jo senkin takia että päivittäinen olisi pienempi. Toinen aatos olis että 1 min päivittyviä olisi joka vuodelle oma jo senkin takia että vuoden kantaan tulis noin 525000 riviä.
Se että miten parsia aseman tähänastinen historia log-filuista on sitten oma projektinsa.


JyriT

Omassa kannassa on noin 2200 riviä (5min intervalli) jotka ottavat reippaan 500kb tilaa tietokantana. Tuosta laskemalla 100Mb menee rikki neljässä vuodessa, jos nyt laskin oikein. ;D
Samalla kaavalla minuutin intervalli aiheuttaa vuodessa 118Mb kannan, joka ei pitäisi nykyvehkeillä olla mikään ongelma.

Suorituskykymielessä ongelma saattaa tulla hakua tehdessä, siitä ei ole vielä kokemusta miten isosta kannasta hakeminen onnistuu veppiserverin voimin, pitääkö hakua jotenkin rajoittaa jne.. Aika näyttää.

Vanhan datan tuonnista:
Jos se tänhetkinen data on jossain tunnetussa muodossa ja eroteltavissa jollain merkillä esim ;  tai blanko tjsp niin sen saattaminen kantaan tuolla php tekeleellä onnistunee suht helposti.

Näihin kuviin ja näihin tunnelmiin ;)
-- Jyri

weatherc

Kokemuksesta voisin todeta että monen tuhannen rivin mysql on kökkö ja hidas, ainakin websivujen hakua ajatellen, saatikka että jos on webbiserverillä webhotellissa niin backupit lähes mahdottomia koska aina tulee joku aikaraja vastaan, niissä kun tuon php:n ajo rajoitetaan aina johonkin x määrään sekunteihin. ;) Tosin jos ajaa sitä kotikoneella niin pystyy sellaiset ohittamaan.

Juu, ei se vanhojen tietojen ajo kantaan itsessään ole ongelma, edes teknisesti. Phpllähän se sujuu helposti, vaatii vaan pientä näpertelyä että löytää kaikki "välilyönnit" koska muistaakseni välit eivät WD:n lokeissa ole samat joka kohdassa vaan löytyy 2:ta ja kolmea välilyöntiä ym. hubaa niistä....

djmake

Lainaus käyttäjältä: weatherc - keskiviikko, 03.03.2010, 22:17
Kokemuksesta voisin todeta että monen tuhannen rivin mysql on kökkö ja hidas, ainakin websivujen hakua ajatellen, saatikka että jos on webbiserverillä webhotellissa niin backupit lähes mahdottomia koska aina tulee joku aikaraja vastaan, niissä kun tuon php:n ajo rajoitetaan aina johonkin x määrään sekunteihin. ;) Tosin jos ajaa sitä kotikoneella niin pystyy sellaiset ohittamaan.

Jätinkö jonkin kohdan ymmärtämättä vai tarkoititkohan jotain muuta, mitä tuosta luin... Ehkäpä tarkennat, jos meni metsään.

Tuhansissa riveissä laskettava datamäärä on oikeastaan täysin olematon, eikä sillä ole mitään merkitystä suurimmassa osassa käyttöjä. Tämä foorumikin on kannassa jo jonkin kokoinen varsinkin rivimääränsä perusteella ja hakuja tulee sivunlatausta kohden kohtuullisen moneen paikkaan. Paljon vilkkaampiakin on silti homma toimii. Nopeasti puhutaan kymmenien ja satojenkin tuhansien rivien kannasta.
Ja BU:t voi tehdä monella tavalla. Joku toimii varmasti. Ajastaa vaikka BU:n teon palvelimelle niin, että se tekee jossain tietyssä ajankohdassa kopsun ja tuuppaa sen ftp:n yli muualle talteen.

weatherc

LainaaJätinkö jonkin kohdan ymmärtämättä vai tarkoititkohan jotain muuta, mitä tuosta luin... Ehkäpä tarkennat, jos meni metsään.

Tiedän yhdenkin NWN-aseman omistajan joka yritti kopioida 3 vuoden WD-tietokantaa joka päivitetty 1 minuutin välein (yht. n 1.5 miljoonaa riviä) kun piti siirtää se uudelle palvelimelle (ja onhan se muutenkin hyvä olla backup) ja vasta monen epäonnistuneen yrityksen jälkeen sai sen jotenkin tehtyä, en muita miten muuta kun että kaikki "normaalit" tavat päättyi aina timeouttiin.
Kooltaan megoissa WD-kanta ei ole mikään jättikokoinen, iso toki, tosin sen verran iso ettei edes mahdu noihin pienempien webhotellien kantoihin, kyse on kuitenkin useamman kymmenen megasta (tosin en edes ymmärrä miksi niiden kokoa pitäis rajoittaa niin kauan kun mahtuu webhotellin koon sisään)

Itsellä oli aikanas sellainen samanlainen WD-kanta jossa oli jotain 2 vuoden datat, silloin sivut majaili vielä webhotellissa, ja haut olivat enemmän kun hitaat. Jos ottaa esimerkkinä omat (tai teutari tai jamo) sivut jossa ukkosaikana liikennettä pikkasen enemmänkin niin mysql ei välttämättä ole paras ratkaisu myöskään.

Tiedän, että onhan noita isoja foorumejakin, jotka ovat mysql-pohjaisia, mutta kun moni niistä pyöritetään jossain webhotellissa? Juuri niin, uskallan sanoa ettei ainuttakaan, kaikki ovat joko dedikoidulla raudalla tai VPS:llä. Ja niissä on cachet ym. hakuja vähentävät tekijät, esim tätäkin sivua luet normaalina html-sivuna eli välimuistista. ;)

djmake

Lainaus käyttäjältä: weatherc - perjantai, 05.03.2010, 14:49
Tiedän yhdenkin NWN-aseman omistajan joka yritti kopioida 3 vuoden WD-tietokantaa joka päivitetty 1 minuutin välein (yht. n 1.5 miljoonaa riviä)

Niin... Tuossa aikaisemmin puhuit monen tuhannen rivin kannasta. Miellän puolitoista miljoonaa kuitenkin muutaman kertaluokan suuremmaksi.

Lainaa
kun piti siirtää se uudelle palvelimelle (ja onhan se muutenkin hyvä olla backup) ja vasta monen epäonnistuneen yrityksen jälkeen sai sen jotenkin tehtyä, en muita miten muuta kun että kaikki "normaalit" tavat päättyi aina timeouttiin.

Mitähän nämä normaalit tavat sitten mahtoivat olla ja millaisessa ympäristössä? Jos joku php-kikkare on, joka koittaa ladata koko kannan kerralla kotikoneelle tms, niin varmasti timeouttaa. Mutta ainakin paikallisella tasolla tehtynä suuremmastakin kannasta saa kopion. Isommassa hädässä kopsaa suoraan filut talteen ja miettii sitten eteenpäin.

Lainaa
Kooltaan megoissa WD-kanta ei ole mikään jättikokoinen, iso toki, tosin sen verran iso ettei edes mahdu noihin pienempien webhotellien kantoihin, kyse on kuitenkin useamman kymmenen megasta (tosin en edes ymmärrä miksi niiden kokoa pitäis rajoittaa niin kauan kun mahtuu webhotellin koon sisään)

Osa niistä rajoituksista on tosiaan aika olemattoman kokoisia ja muistuttavat lähinnä kiusantekoa. Mutta kun samaan koneeseen pitää tunkea loputtoman monta kantaa, niin sitten laitetaan noita rajoja. Samalla voidaan myydä lisämegoja eri hintaan.
Osassa paikoista levytilaa on määrä x ja kanta siihen päälle. Eli siitäkin raja. Ja kun tuo raskaus otetaan huomioon, niin jälleen syy rajoittaa. Muutenkin liian täyteen ahdetussa systeemissä kasa raskaita kantona ei ole yleensä hyvä asia.

Lainaa
Itsellä oli aikanas sellainen samanlainen WD-kanta jossa oli jotain 2 vuoden datat, silloin sivut majaili vielä webhotellissa, ja haut olivat enemmän kun hitaat. Jos ottaa esimerkkinä omat (tai teutari tai jamo) sivut jossa ukkosaikana liikennettä pikkasen enemmänkin niin mysql ei välttämättä ole paras ratkaisu myöskään.

Mysli on raskas, se on tiedostettu asia. Ei ole pitkään aikaa, kun moista keventelin yhdessä virtuaalissa. Eikä tosiaan kaikkeen se paras. Vaihtoehtoja vaan ei kaikkeen ole, ellei itse koodaa rajapintaa. Mutta tarpeen mukaanhan noita on valittava ja hitaudelle voi tehdä paljon riippuen käytössäolevasta palvelimesta. Järkevällä muistinkäytöllä lähes kaikki tarvittava saadaan suoraan cachesta ja homma toimii nopeammin.

Lainaa
Tiedän, että onhan noita isoja foorumejakin, jotka ovat mysql-pohjaisia, mutta kun moni niistä pyöritetään jossain webhotellissa? Juuri niin, uskallan sanoa ettei ainuttakaan, kaikki ovat joko dedikoidulla raudalla tai VPS:llä. Ja niissä on cachet ym. hakuja vähentävät tekijät, esim tätäkin sivua luet normaalina html-sivuna eli välimuistista. ;)

Mistäs tämä webbihotelli tähän tuli? Alkujaan mainitsit, että useamman tuhannen rivin kanta on hidas. Sitäpaitsi hotellienkin kohdalla on vähän vaarallista yleistää. Ellei kiinnostusta ole oman virtuaalin tai dediraudan pitoon, niin tarjolla on (joskin toki tottakai maksavat) hotellipaketteja, jossa on oikeasti puhtia järeämmänkin kannan tai muun pyörittelyyn. Tosin jossakinkohtaa asia on toki käytännössä lähestulkoon dedi+sopiva ylläpitosoppari.
Cachettaa tottakai voi lähes mitä ja miten vaan. Tosin siihenkään ei oikein ole mitään yleispätevää. Vaikkapa foorumi on vähän erilainen, mitä tuollainen säätietoja sisältävä kanta.

Sitä taas en tiedä, että mistä tämä sivu on tullut. Ei ole mitään tietoa, että millaisia asetuksia on käytössä ja onko esimerkiksi koska viimeksi joku tämän ladannut.

weatherc

Se mitä ajoin oli lähinnä se että säätietokanta 1 minuutin tallennusvälillä kasvaa todella isoksi ja kannataa miettiä tarkkaan miten sen tekee. Normi arkistoksi kävis hyvin vaikka 5 min väli mutta silloin jää osa datasta pois jollei sitten tee jotain max/min-tarkkailuja tuon 5 minuutin suhteen. Olet oikeassa että mysli on yleisesti tiedetty raskaana, samoin kun apachekin, silti niitä vaan käyetään suurimmassa osassa serverieristä (mitä en itse asiassa ymmärrä että miksi).
Sekin on yleisesti tiedossa ettei apache sovi sellaisenaan enemmän liikennettä puskeville sivuille, riittää pieni Googlaus ja käy ilmi että moni "isoista" sivustoista, esimerkkinä wordpress ja youtube puskevat datanasa ulos jollain muulla ohjelmalla kun apache. Tuon huomasin silloin kun ruuvailin tuota wx-vps:ä kasaan ja koitin löytää sopivaa ratkaisua sen ohjelmapuolelle, joka nyttemmin on nginx staattisille + apache php:lle.

LainaaMistäs tämä webbihotelli tähän tuli?
Suurin osa sääsivuista majailee kuitenkin jossain webhotellissa, eikä jollain kotiserverillä, siitä se tuli.
Kotikoneellahan esim. wamp:in kanssa tuollaista kantaa voi rakentaa ihan kevyesti kun ei kaiken maailman rajoitukset ovat vastassa mutta jos siitä haluaa iloa sivuilleen siellä hotellissa tulee äkkiä nuo rajoitukset vastaan, varsinkin silloin jos ja kun sitä niin elin tärkeetä backuppia haluaa ruvet väsäämään, jollei sitten hotellin pitäjä tee sitä puolestasi, esim. Plesk/Virtuozzo:ssa joka myös wx-vps:in takana on sellainen "paina nappia ja koko purkista tulee backup"-toiminto, mutta läheskään joksaisessa wehotellissa sellaista ei löydy, ei edes omille filuille. Jolloin saa olla rakentelamssa jotain purkka-ratkaisua siihen.

weatherc

En edes muistanutkaan että mulla on ollut pikkasen aikaa kerran minuutissa menossa mysql:ään dataa, en käytä sitä mihinkään, ainakaan toistaiseksi. Stringi on customoitu eli ei ole sama mitä esim. WD:n vaiko mysql-stringi puksee. Se on myös huomattavasti sitä lyhyempi, sisältäen 15 arvoa raakadataa + timestamppi.

Mutta siitä saa pikkasen osviittaa koosta ja sen sellaisesta jos suunnittelee tietokantaa tehdä:

Sisällä on nyt 150000 riviä, joka tekee noin 3.5 kuukautta (105 päivää) á 1 rivi/min ja kokoa on 11 megaa.
Vuodessa tuo tekisi 525600 riviä ja kokoa sellaiset 40 megaa.

Vertailuna kun katselin tuota oman foorumin kantoja (pieneen sellaiseen jos tähän vertaa), niin siinä ei päästä missään yli 6000 rivin tai 450 kb:n.

;D

djmake

Lainaus käyttäjältä: weatherc - lauantai, 06.03.2010, 17:58
Olet oikeassa että mysli on yleisesti tiedetty raskaana, samoin kun apachekin, silti niitä vaan käyetään suurimmassa osassa serverieristä (mitä en itse asiassa ymmärrä että miksi).
Sekin on yleisesti tiedossa ettei apache sovi sellaisenaan enemmän liikennettä puskeville sivuille, riittää pieni Googlaus ja käy ilmi että moni "isoista" sivustoista, esimerkkinä wordpress ja youtube puskevat datanasa ulos jollain muulla ohjelmalla kun apache. Tuon huomasin silloin kun ruuvailin tuota wx-vps:ä kasaan ja koitin löytää sopivaa ratkaisua sen ohjelmapuolelle, joka nyttemmin on nginx staattisille + apache php:lle.

Piti tähänkin jo aikaa sitten kommentoida...

Se on vähän sama tuossa apachessa ja myslissä, mitä vaikkapa winkkarin osalta. Kun joku ohjelma tai käyttis saa riittävän suuren markkinaosuuden, niin sen kanssa yhteensopivien sovellusten määrä kasvaa. Ja tämä taas lisää markkinaosuutta jnejne. Eli kärrynpyörä on valmis. Ja jos valitsee itselleen servua varten palikoita, niin helposti tulee siinäkin valittua niistä yleisistä, vaikkei ehdotonta pakkoa olisikaan. Ongelmiin on paremmin apua tarjolla yleisemmän osalta.

Apachea paremmin johonkin tiettyyn käyttöön sopivia on tosiaan tai riittävillä resursseilla sellaisia voidaan vaikka tehdä itse. Mutta mikä sitten on enemmän liikennettä? Sopivilla säädöillä usean sadan megan jatkuva liikenne ei vielä ole mahdoton. Ja seuraavaksi vastaan tuleekin levyjen tai itse raudan nopeus. Toisaalta Apachella (kuten monella muullakin) saa koneen tukkoon säätämällä sen päin jotain. Oletusasetuksilla harva ohjelma pystyy jokaisessa tilanteessa erityisen optimaalliseen toimivuuteen.