[SQL] tabellen structuur voor veel data

[Verwijderd]

Hallo,

Ik kom ergens niet uit, en nu zie ik graag iemand anders zijn mening.
Mijn probleem:

Neem 100 gebruikers, die elke dag een waarde tussen de 0 en 24 opslaan.
Hoe ga ik dit logisch in een aantal tabellen prakken?

Idee 1:
1 tabel voor info van gebruikers ( PK : gebruikers_id )
1 tabel voor de dag (datum), waarde en gebruiker_id

dus dan zou elke gebruiker zo'n 365 rows per jaar produceren, 100 gebuikers produceren dan dus zo'n 365.000 rows.

dat lijkt mij best veel, zeker met het oog op meer gebruikers in de toekomst, wellicht dat de mysql db dan lichtelijk over zijn nek gaat als die data regelmatig wordt aangesproken.

Wat is jullie kijk hierop? wellicht per gebruiker een eigen tabel?

mijn dank is alvast groot.

Rob.

[RobIII]

365.000 rows is voor een beetje DB (en ja, dus ook MySQL) peanuts. En al helemaal als die tabel maar 100 keer per dag (=paar keer per uur) wordt aangesproken, zeker als die tabel enkel datum, user en waarde bevat. Trust me, dit komt nog niet eens close in de buurt van wat een DB kan hebben

[ Voor 68% gewijzigd door RobIII op 02-04-2007 13:20 ]

[djluc]

Je opzet is goed. Eventueel kan je de waarden na een x aantal maanden aggregeren. Bijvoorbeeld: In 2006 vulde user X gemiddeld een 5 in maar dat is afhankelijk van je data (wordt o.a. veel bij statistieken gebruikt).

[Joolee]

Wat een slimme oplossing is ligt naar mijn idee heel erg aan wat jij van plan bent met de gegevens die in de database staan. Als je bijv. alleen van de laatste maand de data in de database regelmatig nodig hebt kun je alles wat ouder is kopiëren naar een andere database/tabel of zelfs exporteren. Al denk ik ook niet dat mysql erg veel last heeft van al die rijen als er alleen maar de nieuwste gebruikt hoeven te worden.

Als je statistieken moet genereren kun je er ook nog aan denken dit elke dag één maal te doen en de resultaten op te slaan in een andere tabel. Dan heb je die statistieken alleen niet realtime.

[RobIII]

Joolee schreef op maandag 02 april 2007 @ 13:22:
Wat een slimme oplossing is ligt naar mijn idee heel erg aan wat jij van plan bent met de gegevens die in de database staan. Als je bijv. alleen van de laatste maand de data in de database regelmatig nodig hebt kun je alles wat ouder is kopiëren naar een andere database/tabel of zelfs exporteren.

Waarom zou je zo moeilijk doen? Met een Where-clause op je select (en een indexje) maakt het geen fluit uit of die (oude) gegevens nog in de tabel zitten.

Joolee schreef op maandag 02 april 2007 @ 13:22:
Als je statistieken moet genereren kun je er ook nog aan denken dit elke dag één maal te doen en de resultaten op te slaan in een andere tabel. Dan heb je die statistieken alleen niet realtime.

Waarom omslachtig gaan doen als je het probleem, als het een probleem begint te worden, kunt aanpakken? Een caching-mechanisme is nog altijd te bouwen. Ik zou het eerst eens even aankijken totdat het merkbaar 'trager' begint te worden (en chances are dat je product tegen die tijd alweer vervangen wordt door iets nieuwers/beters of dat de server tegen die tijd alweer stukken sneller is).

[Verwijderd]

Het gaat hier inderdaad om gegevens voor wat statistiekjes.

als 365.000 dus no problem is weet ik wel wat mijn plan is:

data opslaan zoals beschreven, dagelijks generen en per jaar de data berekenen en opslaan.

dank!

Rob.

[Icey]

Je hebt maar twee tabellen nodig, één voor je gebruikers met een gebruikersID en één met daarin een ID (autonumeriek), gebruikersID, datum & waarde.

[Voutloos]

Verwijderd schreef op maandag 02 april 2007 @ 13:29:
als 365.000 dus no problem is weet ik wel wat mijn plan is:

Absoluut geen probleem, het zijn zelfs kleine, fixed-length rijen, ideaal dus. Sterker nog, het zijn maar 36.500 rijen per jaar, want je berekening zit er een factor 10 naast.

[MSalters]

Om een idee te geven: de kleinste uitvoering van MSSQL is 4Gb; jij slaat net 100 bytes aan data per dag op. Nou zit er een beetje overhead in MSSQL (ik gok zo'n factor 16 hier) maar zelfs dan nog is de levensduur van je PC eerder bereikt dan de limiet van je DB

[RobIII]

MSalters schreef op maandag 02 april 2007 @ 20:07:
Om een idee te geven: de kleinste uitvoering van MSSQL is 4Gb; jij slaat net 100 bytes aan data per dag op. Nou zit er een beetje overhead in MSSQL (ik gok zo'n factor 16 hier) maar zelfs dan nog is de levensduur van je PC eerder bereikt dan de limiet van je DB

Dat je limiet niet (snel) bereikt wordt heeft natuurlijk 0,0 te maken met de snelheid van aggregates op je tabel(len).

[ACM]

Verwijderd schreef op maandag 02 april 2007 @ 13:17:
Neem 100 gebruikers, die elke dag een waarde tussen de 0 en 24 opslaan.
Hoe ga ik dit logisch in een aantal tabellen prakken?

Zoals al gezegd is dat helemaal niet veel, ook niet voor MySQL. Maar voor het theoretische geval dat het wel veel data zou zijn: Er zijn een aantal technieken voor mogelijk, minimaliseren van de records is natuurlijk een duidelijke zaak. Maar de meestgebruikte naam voor diverse technieken die hierbij van toepassing zijn is (data) partitioning. MySQL biedt er sinds 5.1 ondersteuning voor (naast natuurlijk een hele rij andere databases). Het basisprincipe is dat je je data in losse tabellen opsplitst op basis van een of ander algoritme (bijvoorbeeld voor elk jaar+maand een losse tabel). Op die manier kan je recente data in veel kleinere en ondiepere index-structuren benaderen en eventueel zelfs op andere disk-arrays zetten (bijv een geoptimaliseerd voor lezen vs een voor schrijven of op goedkopere disks met meer capaciteit).
En dat doe je dan natuurlijk liefst zoveel mogelijk geautomatiseerd, de grote databases bieden daar natuurlijk allerlei hippe functies voor. Het grote voordeel is dat het allemaal min of meer vanzelf gaat terwijl je bij je queries er relatief weinig rekening mee hoeft te houden, virtueel kan je het meestal als een grote tabel aanspreken.

Zo lezen wij de access logs van GoT in in een losse 'partitie' per dag (zo'n 2-3M records, 140-170MB, ex. indexen), zodat je na het inlezen de complete dag-tabel in principe nooit meer hoeft te beschrijven. Verder kan je met veel kleinere indexen werken (ze zijn namelijk minder diep) of soms zelfs weglaten. In ons geval is er bijvoorbeeld niet eens een index op het datumveld nodig, domweg omdat we altijd op hele dagen selecteren (dag, week, maand, etc), en nooit op delen van dagen.
De database (postgres in dit geval) pakt automatisch de geschikte tabellen samen en slaat de rest compleet over. En ook bij het weggooien van oude data is het makkelijk natuurlijk, gewoon de tabel van die dag droppen en klaar.

Wat is jullie kijk hierop? wellicht per gebruiker een eigen tabel?

Ook dat zou een mogelijke partitionering zijn, maar in jouw geval zou ik nu niet moeilijk doen. Tenzij je verwacht dat je partities in korte termijn miljoenen aan records gaan krijgen.

[Verwijderd]

ghehe nee dat zit niet in de planning

en idd het was 36.500 ipv van mijn 365.000, hoofdrekenen is niet mijn sterkste punt

iig bedankt voor alle mucho mucho information

[Verwijderd]

MSalters schreef op maandag 02 april 2007 @ 20:07:
Om een idee te geven: de kleinste uitvoering van MSSQL is 4Gb; jij slaat net 100 bytes aan data per dag op. Nou zit er een beetje overhead in MSSQL (ik gok zo'n factor 16 hier) maar zelfs dan nog is de levensduur van je PC eerder bereikt dan de limiet van je DB

MSSQL is wel kleiner hoor.... 4GB is gigantisch overdreven (net als die factor 16).

[kenneth]

Verwijderd schreef op maandag 02 april 2007 @ 21:18:
[...]


MSSQL is wel kleiner hoor....

Hij doelt op de maximale grootte van 'n database in de kleinste versie

4GB is gigantisch overdreven (net als die factor 16).

Houd je van mieren, of mis je het punt

[Verwijderd]

kenneth schreef op maandag 02 april 2007 @ 21:24:
[...]
Hij doelt op de maximale grootte van 'n database in de kleinste versie


[...]
Houd je van mieren, of mis je het punt

Nee, dacht dat hij de installatie grootte en/of minimale database grootte bedoelde. Maar was ff vergeten dat de gratis versies idd tot max 4gb gaan