Tietokantakysymys: yksi vai useita tauluja?

[2112]

Olisi tarkoitus raapia kokoon tietokanta, jonka tieto koostuu n. 1000 - 2000 laitteen lähettämästä datasta. Yhteensä nämä laitteet lähettävät vuoden aikana kymmeniä tuhansia lähetyksiä. Olenkin tässä pohtinut, mikä olisi järkevin tapa organisoida tuo kanta.

Tietoja ei tarvitse tämän kannan puitteissa vertailla laitteiden välillä. Kaikkein tärkeintä olisi saada haettua viimeisin data jokaisesta laitteesta mahdollisimman nopeasti ja tehokkaasti. Sen vuoksi olen pohtinut, että:
- nykyhetken tieto kaikista laitteista tallennettaisiin yhteen, yhteiseen tauluun
- jokaiselle laitteelle tulisi lisäksi oma taulunsa, jonne mennyt data tallennettaisiin satunnaista tarkastelua varten
Tämä tietenkin sotii voimakkaasti kaikenlaisia DRY-periaatteita yms. vastaan, ja ymmärrän, ettei sellainen useimmissa tapauksissa ole mitään järkevää tietokantasuunnittelua. Etuna tässä kuitenkin olisi, että se kaikkein tärkein päätaulu pysyisi aika pienikokoisena. Lisäksi, kun laite poistuu järjestelmästä, riittäisi sen siivoaminen tästä päätaulusta.

Se toinen vaihtoehto olisi tietenkin sulloa kaikista laitteista saapuva tavara yhteisiin tauluihin, joita voisi sitten varmaankin eritellä lähetetyn tiedon mukaan (eli kun laitteet lähettävät dataa A ja dataa B, niin luodaan taulut A ja B, joihin tavara tallennetaan). Lisäksi olisi tietenkin se laitetaulu, johon tallennetaan laitteen tunnus sekä joitakin muita muuttumattomia tietoja. Näin ollen olisi se yksi tieto yhdessä paikassa, niin kuin oikeassa tietokannassa kai kuuluukin. Ongelmana on, että aina, kun haetaan niitä laitteiden viimeisimpiä tietoja, joudutaan tekemään kyselyjä näihin tauluihin, joissa on sitten vuosien päästä hillitön määrä rivejä.

Vuoden tai kahden aikana tämä tuskin on ongelma kummallakaan valinnalla? Mutta muuttuuko tilanne, kun vuosia onkin takana vaikkapa 10? Tässä kun on olemassa se riski, että joudun itse kantamaan vastuun tästä pommista vielä silloinkin.

 

[SweeneyTodd]

Sanoisin, että tekee indeksin lähetysajankohdasta, jolloin sen perusteella suodattaminen on tehokasta. Tällöin tuoreet tiedot saadaan nopeasti esiin, mutta vanhatkin löytyvät kätevästi samasta kannasta. Eli esim. samalla hakulomakkeella saadaan helposti tarvittaessa molemmat näkyviin.

 

[muzzy]

tekee indeksin lähetysajankohdasta

Jep. Tämä on oikea ratkaisu.

Kannattaa toki generoida testidataa muutama miljoona riviä sinne kantaan että pääsee kokeilemaan että se toimii oikein, indeksoitu haku tämmöiseen pitäisi mennä alle millisekunnissa vaikka dataa olisikin paljon.

Jos jostain syystä tämä ei lähde toimimaan niinkuin pitäisi, voidaan harkita cachea. Aina kun tulee uusi tieto, poistetaan cachesta vanha tieto ja mahdollisesti kirjoitetaan uusi tilalle. Kyseltäessä ensin katsotaan cachesta ja sitten vasta haetaan kannasta (ja päivitetään cache kun saadaan kannasta tulokset). Memcached ja Redis ovat tähän melko tavanomaisia ratkaisuja. Yleensä tätä ei kuitenkaan kannata tehdä ennenkuin ne kyselyt ovat oikeasti raskaita, ja tämä selviää varmimmin testaamalla toimivuutta generoidulla datalla.

 

[hsalonen]

Indeksi vaan hidastaa inserttiä, mutta ei näillä datamäärillä ole ongelma.

Mutta samaan tauluun vaan.. Ei mitään järkeä tehdä jokaiselle laitteelle omaa taulua.

SQL Serverillä ainakin tuon taulun voi partitioida lähetyspvm:n mukaan ja eiköhän muillakin suurilla tietokantajärjetelmillä.

 

[©©©]

Kannattaa myös miettiä jos laitteilla on paljon tietoja niin laitteet ja laitetiedot omaan tauluun ja pelkkä data toiseen tauluun.

 

[2112]

Kiitoksia vastauksista. Eiköhän näistä se ratkaisu nyt sitten löydy. Indeksointi käyttöön, ja tietokantana varmaankin PostgreSQL, joka tukee myös tuota partitiontia. Perehdytään näihin tarkemmin.