Moro!
Noita eri sivustojen tietokantoja kun vähemmän pääsee tutkimaan, niin pitää nyt kysellä, että mikä olisi se kutakuinkin paras rakenne tietokannalle tässä tapauksessa:
- Käyttäjiä 5000
- Jokainen käyttäjä lisää tietoja oman tunnuksensa alle vähintään kerran joka päivä
- Vanhojen tietojen pitää säilyä; tiedot ovat lukuarvoja ja niistä piirretään historiagraafeja
Eli vielä selvennyksenä esimerkki:
Käyttäjät pitävät kirjaa kuinka paljon juovat viinaa päivittäin. Matti käy lisäämässä lauantaiaamuna perjantain saldon: 17 pulloa kolmosta. Tuli otettua vähän väkevääkin, niin täytyy lisätä myös 1 pullo Saaremaata. Lisäämisen jälkeen Matti kuitenkin ottaa tasoittavia vielä 4 pulloa, joten hän käy lisäämässä ne illalla.
Pitäisikö moinen kanta tehdä jotenkin niin, että tehdään sarake nimeltään "Olut", johon sitten erotellaan [jotenkin] (pilkulla?) viikon kaljapullojen määrä: 1,2,1,12,13,5,3. Ja viinalle sitten oma sarake samaan tyyliin? Ei tajua...
Yksi ratkaisu on lisätä jokainen juomakerta omaksi rivikseen:
juomari juoma maara aika ------------------------------------------------ 1 3 17 4.7.2008 1 6 1 4.7.2008 2 3 8 5.7.2008 1 6 4 5.7.2008 2 2 2 5.7.2008
Tässä käyttäjillä ja juomilla on tunnusnumerot, esim. juomari 1 voi tarkoittaa Mattia ja juoma 3 voi tarkoittaa kolmosolutta.
Tästä taulusta on helppoa muodostaa kaikenlaisia tilastoja eri käyttäjien juonneista eri aikaväleillä.
Jos tilastoissa juonteja tarkastellaan aina viikoittain, taulua voi myös tiivistää keräämällä samalle riville tietyn käyttäjän tietyn juomatyypin kulutuksen kunkin viikon aikana.
Tuota mietin itsekin, mutta tuota varten laitoin tietoihin että käyttäjiä on 5000. Minkälainen soppa siitä vuodessa tietokantaan syntyy, jos joka lisäykseen tehdään uusi rivi, jos joka kävijä lisää päivittäin 2 sarakkeeseen uuden tiedon: 5000x2x365... No... aika monta riviä - saati sitten 5 vuoden aikana. Onko tuollainen ihan normaali käytäntö tietokantojen kanssa? Helppohan se olisi.
Minulla ei ole suurista tietokannoista kokemusta, mutta parin miljoonan rivin tietokanta ei silti kuulosta tavattoman valtavalta.
Ehdottamani taulurakenne edustaa joka tapauksessa mielestäni hyvää tietokantasuunnittelua.
Sivuston tilastot kannattaa kuitenkin toteuttaa niin, että tietoja ei haeta joka kerta uudestaan tietokannasta vaan tilastot luodaan esim. kerran päivässä.
No ei se tavattoman valtava olisikaan, mutta tuo 5000x2x365 jo sinällään tekee rivejä 366 miljoonaa. Tuo nyt on teoreettista laskentaa vain. Epäilen että rekisteröityneitä käyttäjiä tulee olemaan siinä 5-10 tuhannen välillä, joista sitten taas aktiivisesti (=viikottain) kirjoittaa varmaan alle tuhat.
Mutta lähden tuolla rakenteella liikenteeseen, tuota meinasin itsekin aluksi, mutta alkoi toi järkyttävä rivimäärä epäilyttämään.
Jos jollain on vielä ehdotettavaa niin vielä ehtii - alan vasta testikantaa kasaamaan :)
Rivejä ei tulisi sentään vuosittain 370 miljoonaa vaan 3,7 miljoonaa. :)
Olen samaa mieltä Antin kanssa. Tuo vaikuttaa juuri oikealta toteutusperiaatteelta. Hakunopeuden kannalta on tärkeää muistaa määrittää oikeille sarakkeille indeksit. Pari viikkoa sitten tuli töissä vastaan tapaus, jossa indeksin lisääminen yhdelle sarakkeelle nopeutti erästä kyselyä ~6 minuutista ~6 sekuntiin.
3,7 miljoonaa ei tosiaan tunnu niin kauhean paljolta. Lasketaanpa.
Oletetaan, että yksi rivi koostuu neljästä 64-bittisestä numerosta. Tällöin yksi rivi veisi tilaa 4*64/8 = 32 tavua. 3,7 milj. * 32t =~ 120 Mt. Kanta tulee siis todennäköisesti viemään pahimmillaan vain joitakin satoja megatavuja, jolloin tieto mahtuu kevyesti kokonaisuudessaan minkä tahansa nykyaikaisen tietokoneen keskusmuistiin.
Riveille kannattaa harkita myös id-sarakkeen lisäämistä. Se on tarpeellinen, jos haluat yksilöidä yksittäisiä syöttökertoja. Se ei suurentaisi tietokantaa oleellisesti.
Muutaman miljoonan rivin tietokanta on vielä pieni. Indeksoitavia sarakkeita Antin hyvästä esimerkistä vain juomari ja aika. Myös juoma JOS eri juomavaihtoehtoja alkaa olemaan 5-10 tai enemmän. Jos valittavia juomia on vain kourallinen, ei indeksointi kannata, koska joka tapauksessa tehtäisiin full_scan select kyselyssä (jos ehtolauseke kohdistuu siis juoma -sarakkeeseen). Äkkiseltään tietysti määräkin voisi olla indeksoitava, mutta se riippuu sitten siitä, että kohdistuuko siihen kuinka paljon select kyselyitä.
Indeksi on hyvä select kyselyissä ja paha insert/update/delete kyselyissä.
Eri juomavaihtoehtoja tulee olemaan vähintään 15. Ja tosiaan tuota id-saraketta on tullut tavaksi käyttää vaikka olisi miten pieni taulukko, tuntuu niin simppeliltä numeroida joka rivi omalla id:llään.
Ja taisin eilen (humalapäissäni) laskea tosiaan väärin tuon rivien määrän, 3,7 miljoonaahan siitä tuleekin :) Mutta tosiaan hyvä tietää että tämä "tavallinen" toteutustapa on asiallinen myös suurempiin tauluihin. Jos kuitenkin koon kanssa on jotain mitä kannattaa jo taulua rakentaessa ottaa huomioon, kertokaa ihmeessä. Tuo indeksointihan se oleellisin sivuseikka taitaa ollakin.
Taas kerran kiitän avusta, onhan tää nyt hienoa kun on tällanen paikka mistä saa aina asiallisen ja perustellun vastauksen! :)
MySQL 5.1 tukee partitiointia tauluissa. Jos taulun koko kasvaa, lisää se suorituskykyä.
Vertikaalinen ja horisontaalinen partitiointi on tietokantasuunnittelussa IN. Nostaa suorituskykyä kummasti mitä isompiin järjestelmiin mennään. Tällä oli jokin hieno nimityskin virallisesti, mutta ei nyt tule mieleen...
-W-
Aihe on jo aika vanha, joten et voi enää vastata siihen.