Olen tässä jonkin aikaa pohtinut oman statistiikkajärjestelmän rakentamista eräälle php-sovellukselleni. Jokaisen sivun statistiikat pitäisi siis tallentaa erikseen tästä päivästä hamaan tulevaisuuteen (tai ainakin viimeiset pari kuukautta). Eli tallentuisivat ainakin tiedot: uniikkeja tänään, sivulatauksia tänään JOKA päivältä. Näkisin siis Php-käyttöliittymässä, että viime torstaina oli 30 uniikkia ja 400 sivulatausta. Pystyisin myös piirtämään tyylikkään käyrän kävijöistä.
Minulle on vain ylitsepääsemättömän vaikeata pohtia millainen tietokantarakenne sopisi tälläiseen ilman, että siitä tulisi liian raskas. Oletetaan, että rivejä myslissä voi olla kymmeniä tai satoja tuhansia ja jokaiselle pitäisi tallentaa statistiikka. Osumia saa vain murto-osa riveistä päivässä.
Olen pohtinut esimerkiksi tekeväni joka kuukaudelle aina uuden taulun, jossa on 28-31 kenttää (joka päivälle oma). Näihin sitten joillain menetelmillä tallentaisin tietoja.
Onko foorumisteilla kokemusta kattavan statistiikan rakentamisesta? Hakemalla netistä ja täältä olen löytänyt vain statistiikkoja, jotka eivät tallenna joka päivältä tietoa, vaan lähinnä tallentavat "alltime"-tilastot kantaan.
Taulun rakenne voisi olla sellainen, että yhdessä kentässä on sivun id, toisessa kentässä on päivämäärä ja kolmannessa kentässä lukee, kuinka monta kertaa sivu on ladattu kyseisenä päivänä.
Kun käyttäjä saapuu sivulle, voi tapahtua kaksi asiaa: Jos sivua ja päivämäärää vastaavaa riviä ei ole vielä tietokannassa, se lisätään sinne latausmäärällä yksi. Muussa tapauksessa latausmäärää kasvatetaan yhdellä.
"Uniikit" käyttäjät mutkistavat vielä tilannetta. Yksi ratkaisu on lisätä tauluun uusi kenttä, jossa on käyttäjän IP tms.
Väistämätön totuus on, että jos sivuja ja käyttäjiä on paljon, niin myös statistiikkaa tulee paljon.
grandvia kirjoitti:
Olen pohtinut esimerkiksi tekeväni joka kuukaudelle aina uuden taulun, jossa on 28-31 kenttää (joka päivälle oma).
Tämä ei ole hyvä ratkaisu. Yleensä jos taulujen määrä kasvaa ajan myötä tai taulussa on suuri määrä samankaltaisia kenttiä, jossain on vikaa.
Uusien taulujen ja kenttien tekeminen ei ole millään tavalla optimaalista, eihän se datan määrä mihinkään vähene. Yhdelle asialle tehdään yksi taulu, ja jos datan määrä alkaa todella olla sietämätön (100000 riviä ei vielä ole ongelma!), tietoja voi jälkikäteen siirtää erilliseen arkistotauluun (tai lopulta poistaa).
Voit siis aivan hyvin tallentaa joka sivunlatauksesta perustiedot (IP-osoitteen, ladatun sivun, vaikka istunnon tunnisteenkin). Jos sitten tuntuu, ettei näistä tiedoista ole hyötyä, pyöräytät vaikka yöllä edellisen päivän kävijöistä koosteen arkistotauluun ja poistat ylimääräiset tiedot.
Laaksosen idea kuulosti mainiolta. En ollutkaan pohtinut tämän kaltaista. Ainakin PhpBB-foorumi taitaa tallentaa suuren osan tietoja vastaavalla tavalla.
Mikäköhän mahtaa nykyaikaiselle varsin tehokkaalle palvelimelle olla vielä turvallinen määrä rivejä myslitaulussa? Jos taulussa on vaikka miljoona riviä Laaksosen ehdottamalla menetelmällä tallennettua tietoa, niin kuinka raskas se onkaan ajaa läpi saadakseen yhden ID:n statistiikkahistoria?
En ole perehtynyt myslin toimintaperiaatteisiin oikeastaan yhtään.
Arkistointi-ideasta myös hatunnosto. Croneillahan varmaan arkistointi hoituu, näihin ei sitten monikaan pääsisi käsiksi, niin varmaan helpottaa kuormitusta.
Optimointia tai arkistointia pitää harkita kun sille on tarvetta. Kyselyn ajaminen vaikkapa päivittäin ajastetusti yöllä erilliseen cacheen voi olla myös ratkaisu, jos hakuaika alkaa olla liian pitkä.
grandvia kirjoitti:
Mikäköhän mahtaa nykyaikaiselle varsin tehokkaalle palvelimelle olla vielä turvallinen määrä rivejä myslitaulussa?
Paljon. Mulla ois tässä yks taulu 2,6 miljoonalla rivillä, jonne tein yhen kyselyn, joka palauttaa parisenkymmentä riviä: 0.04 sekuntia. Koneena 1.5 vuotta vanha läppäri.
grandvia kirjoitti:
Jos taulussa on vaikka miljoona riviä Laaksosen ehdottamalla menetelmällä tallennettua tietoa, niin kuinka raskas se onkaan ajaa läpi saadakseen yhden ID:n statistiikkahistoria?
Tämä riippuu siitä, kuinka pitkältä ajalta, eli pitääkö kannasta hakea 100 vai 10000 riviä.
Hakeminen on nopeaa, hitaaksi homma muuttuu vasta sitten ku tulosjoukossa on paljon rivejä ja/tai paljon dataa.
Blaze kirjoitti:
Tämä riippuu siitä, kuinka pitkältä ajalta, eli pitääkö kannasta hakea 100 vai 10000 riviä.
Hakeminen on nopeaa, hitaaksi homma muuttuu vasta sitten ku tulosjoukossa on paljon rivejä ja/tai paljon dataa.
Näinpä. Tosin silloin ei ole enää suoraan kysymys kannan tehokkuudesta vaan ennemminkin webserverin ja selaimen välisestä liikenteestä. Kannan kysely mennee nopeasti, jota voi kokeilla vaikka tmp-tauluun.
Blaze kirjoitti:
Tämä riippuu siitä, kuinka pitkältä ajalta, eli pitääkö kannasta hakea 100 vai 10000 riviä.
Hakeminen on nopeaa, hitaaksi homma muuttuu vasta sitten ku tulosjoukossa on paljon rivejä ja/tai paljon dataa.
Tämä olikin se jota mietin. Selkeyttää taas ajattelutapaani ihan uudella tavalla.
Uskoin, että lähinnä juuri se hakeminen olisi raskasta.
B_R_H kirjoitti:
Näinpä. Tosin silloin ei ole enää suoraan kysymys kannan tehokkuudesta vaan ennemminkin webserverin ja selaimen välisestä liikenteestä. Kannan kysely mennee nopeasti, jota voi kokeilla vaikka tmp-tauluun.
Niin, lukematta koko ketjua läpi (mutta haku ei löydä "inde"), niin aika olennaista haun nopeuden kannalta on, että myös indeksit on kunnossa..
Eli siis käytännössä jonkun 100 järjellisen pituisen rivin puskeminen tietokannalta asiakaskoneelle on merkityksettömän nopeaa jossain 100Mb / 1Gb verkoissa, mutta jos kannassa on vaikka 10M riviä ja haetaan ilman indeksiä niin palvelin kyllä saa rouskuttaa levyä hetken. (Tietty tuurilla voi olla muistissa)
Aihe on jo aika vanha, joten et voi enää vastata siihen.