[php] stats per dag, week maand bijhouden

[Verwijderd]

Ik wil het aantal views van foto's bijhouden, maar wil dan niet alleen het totaal aantal views van die foto bijhouden, maar ook de views van vandaag, van de afgelopen week en de afgelopen maand (per foto dus) zodat ik dus kan displayen welke foto's vandaag het beste zijn bekeken, en welke afgelopen week het beste zijn bekeken en welke afgelopen maand het beste zijn bekeken.

ik kan natuurlijk elke dag de views per dag per foto bijhouden, maar ik denk dat het mss wel iets makkelijker/kleiner kan? bijv. alleen de views van de afgelopen 7 dagen bijhouden, die elke dag bijelkaar optellen (dan heb je dus voor de afgelopen week) en elke dag de afgelopen 4 weken bijelkaar optellen en updaten als maand.

is hier een handig iets voor te verzinnen, mensen die hier ervaring mee hebben?

het is van groot belang dat de database zo simpel/snel mogelijk is.. aangezien het hier gaat om +/- 500.000 foto's


ohja, en dit wil ik dan niet alleen met views per foto, maar bijv. ook met downloads van een foto, comments per foto, rating van een foto enz enz.

[ Voor 8% gewijzigd door Verwijderd op 17-05-2007 12:49 ]

[P.O. Box]

het aantal foto's is niet echt van belang... het aantal views meer... maar dan nog moet je het wel heel bond maken om de database over de zeik te krijgen...
je kunt het op meerdere manieren doen... ik zelf zou denk ik kiezen uit een van de volgende twee mogelijkheden:
1. maak een tabel aan met foto_id en datumtijd en zet voor iedere view van een foto een record in de tabel. Als je heel veel views hebt loopt de grootte van de tabel snel op, maar het is een hele simpele tabel, dus je moet het wel heel gek doen om er problemen mee te krijgen.

2. maak ee ntabel aan met foto_id, datum en counter en hoog voor iedere view op een bepaalde datum de counter met 1 op.... je tabel wordt dan iets kleiner... je hebt nog steeds per dag je gewenste gegevens en kan er makkelijk de week / maand uit destilleren... nadeel is, dat als je ooit op uren (bijv. om te weten op welke tijden de meeste bezoekers komen) wilt rapporteren zul je je tabel moeten ombouwen, en heb je niets meer aan je oude data.

In beide gevallen kun je uiteraard ook na een x periode (in jouw voorbeeld een maand) de oude data verwijderen uit de tabel....

[Evilbee]

Edwardvb schreef op donderdag 17 mei 2007 @ 12:53:
1. maak een tabel aan met foto_id en datumtijd en zet voor iedere view van een foto een record in de tabel. Als je heel veel views hebt loopt de grootte van de tabel snel op, maar het is een hele simpele tabel, dus je moet het wel heel gek doen om er problemen mee te krijgen.

En hoe wil je hiermee dan gaan tellen? Met een group by statement? Dat is de perfecte manier om de query langzaam te maken. Dit kan je eventueel doen voor een tijdelijke data. Maar voor de uiteindelijke data moet je toch echt oplossing 2 gebruiken.

[RobIII]

Evilbee schreef op donderdag 17 mei 2007 @ 13:20:

En hoe wil je hiermee dan gaan tellen? Met een group by statement? Dat is de perfecte manier om de query langzaam te maken.

Heb je daar ook een onderbouwing bij? Tenzij je DB huge-ass groot wordt (en trust me, een paar miljoen records is écht niet huge-ass) is het namelijk geen probleem. Tegen de tijd dat het wél een probleem gaat worden heb je waarschijnlijk al zoveel verdiend met je site dat je er gewoon een dikkere server onder duwt of je server clustert met andere servers en in een farm gooit.

Evilbee schreef op donderdag 17 mei 2007 @ 13:20:
Dit kan je eventueel doen voor een tijdelijke data. Maar voor de uiteindelijke data moet je toch echt oplossing 2 gebruiken.

Lekker scaleable Not.

Verwijderd schreef op donderdag 17 mei 2007 @ 12:47:
ohja, en dit wil ik dan niet alleen met views per foto, maar bijv. ook met downloads van een foto, comments per foto, rating van een foto enz enz.

Je kunt per 'soort' een aparte views tabel bijhouden, zeker leuk(er) als je referentiële integriteit wil laten afdwingen door je DB. Anderzijds kun je het met een extra veld ("type" ofzo) in je "views" tabel gooien op dezelfde hoop als de rest en met een indexje erbij (en een fatsoenlijk RDBMS ) zul je ook hier geen fluit van merken.

Overigens vind ik 500.000+ foto's best flink (qua foto's dan); om wat voor site gaat het als ik mag vragen? Zelfs Corbis heeft er "maar" 2.1 miljoen online staan...

[ Voor 32% gewijzigd door RobIII op 17-05-2007 13:41 ]

[Verwijderd]

RobIII schreef op donderdag 17 mei 2007 @ 13:36:
[...]

Heb je daar ook een onderbouwing bij? Tenzij je DB huge-ass groot wordt (en trust me, een paar miljoen records is écht niet huge-ass) is het namelijk geen probleem. Tegen de tijd dat het wél een probleem gaat worden heb je waarschijnlijk al zoveel verdiend met je site dat je er gewoon een dikkere server onder duwt of je server clustert met andere servers en in een farm gooit.

tja om nou al je winst in een legertje servers te steken terwijl dat niet had gehoeven als je beter had geprogrammeerd is ook weer een beetje zonde he..

Overigens vind ik 500.000+ foto's best flink (qua foto's dan); om wat voor site gaat het als ik mag vragen? Zelfs Corbis heeft er "maar" 2.1 miljoen online staan...

het zijn eigenlijk 2 aparte sites, de 1 heeft er iets meer dan 200.000, de anders heeft er 250.000, maar ik wil op beide hetzelde.

maargoed,

ik denk dat ik het nu zo ga doen:

Idd een table views_stats oid aanmaken, met daarin de velden: pic_id,datum,hits

ik denk dat ik in de table fotos 4 extra velden toevoeg, namelijk:
views_today, views_thisweek, views_thismonth, views_total
die moeten dus wel aan het einde van elke dag dmv cronjob gereset/geupdate worden (behalve de views_total uiteraard).
en bij elke view worden alle 4 de velden +=1 geupdate.

en dan elke dag om 00:00 dmv cronjob:
* gaat de views_today teller op 0
* wordt het veld views_thisweek geupdate door de uit de views_stats berekende aantal van de afgelopen 6 dagen.
* wordt het veld views_thismonth geupdate door de uit de views_stats berekende aantal van de afgelopen 30 dagen.

is dit een goede oplossing volgens jullie?

het klopt dan niet helemaal:
omdat je bijv. bij views_thisweek op 17-1-2007 14:00 eigenlijk nog de views vanaf 10-1-2007 14:00 erbij moet hebben, maar je hebt die views van 10-1-2007 er dan helemaal niet bij, pas vanaf 11-1 2007 00:00
toch?

[Spockz]

Zou het niet handig zijn om 1 tabel te maken waarin elke view geregged wordt. En waar dagelijks, wekelijks, maandelijks de statistieken uit gehaald worden. Zo heb je niet zoveel load als wanneer je elke keer opnieuw de statistieken gaat bepalen.

[SH4D3H]

Verwijderd schreef op donderdag 17 mei 2007 @ 15:56:
het klopt dan niet helemaal:
omdat je bijv. bij views_thisweek op 17-1-2007 14:00 eigenlijk nog de views vanaf 10-1-2007 14:00 erbij moet hebben, maar je hebt die views van 10-1-2007 er dan helemaal niet bij, pas vanaf 11-1 2007 00:00
toch?

En dat 'week' en 'month' nogal misleidende termen zijn.
Als ik op 1 juni langskom en zie dat je X (wat is heel veel? ) hits hebt gehad deze maand lijkt dat niet echt te kloppen

[Verwijderd]

Verwijderd schreef op donderdag 17 mei 2007 @ 15:56:
ik denk dat ik in de table fotos 4 extra velden toevoeg, namelijk:
views_today, views_thisweek, views_thismonth, views_total

Dat lijkt me volstrekt overbodig, dat kun je beter aan de database overlaten en er een goede sum() query met de juiste data in je where-clause op los laten.

[ERIKvanPAASSEN]

Mij lijkt het handigst om een tabel te hebben met records per foto per dag, zoiets:

code:

id   datum         foto     views
1    2007-05-18    1        1354
2    2007-05-18    5        13
3    2007-05-18    8        13351
4    2007-05-19    1        0
5    2007-05-19    5        4682
6    2007-05-19    8        763

Je zou kan dan vrij makkelijk een week of maand optellen en je databasegrootte blijft relatief klein.
Ik heb verder weinig verstand van grote databases, of dit idee handig is moet je zelf maar uitzoeken.

[Equator]

IMO lijkt mij een 2tal tabellen het makkelijkste.

1 tabel zoals hierboven al besproken:

code:

[id] [unix_timestamp] [photo_id]
001   170243433454       3005

Met een goede indexering en een count kan je heel snel zien hoeveel views er zijn geweest in de afgelopen 24 uur, de afgelopen 2 dagen/week en maand.

1 x per maand kijk je hoeveel views er zijn geweest per foto, en die sla je op in een 2e tabel:

code:

[id] [foto_id] [month] [views]
001   3005        02    120345

En na die verwerking verwijder je alle entries in tabel 1 welke ouder zijn dan 1 maand.
Zo hou je de tabellen overzichtelijk en relatief klein.