[MYSQL/PHP] Hitcounts opslaan in DB*

[djluc]

Ik ben bezig met een speciale hitcounter zoals ook in het topic gasten volgen door site te lezen is. Voor iedere hit wordt een nieuwe rij aangemaakt in de tabel hits, ik denk echter dat mr MYSQL dit niet zo grappig gaat vinden.

Het script moet over een tijdje namelijk voor meerdere sites gaan werken, en dan zit je zo aan de miljoen hits per jaar. Het opslaan daarvan is niet zo'n punt maar het uitlezen zal toch een vrij pittige klus worden.

Kan ik hiermee problemen krijgen of houdt de mysql server zich wel, de server staat bij een hosting provider en dus niet op één of andere afgedankte pc.

offtopic:
hoe kan ik de topictitel veranderen? per ongeluk op enter geduwd.

[ Voor 8% gewijzigd door djluc op 29-12-2002 11:43 ]

[Verwijderd]

Als je de juiste index's op de betreffende tabel hebt gelelgd dan is de methode die je hierboven beschrijft volgens mij de beste.

[djluc]

Ik zou een index leggen op de site-id omdat dat steeds een voorwaarde is, en op de normale id. Zou je er nog meer maken?

[whoami]

[nohtml]

djluc schreef op 29 december 2002 @ 11:40:
Ik ben bezig met een speciale hitcounter zoals ook in het topic gasten volgen door site te lezen is. Voor iedere hit wordt een nieuwe rij aangemaakt in de tabel hits, ik denk echter dat mr MYSQL dit niet zo grappig gaat vinden.

Het script moet over een tijdje namelijk voor meerdere sites gaan werken, en dan zit je zo aan de miljoen hits per jaar. Het opslaan daarvan is niet zo'n punt maar het uitlezen zal toch een vrij pittige klus worden.

Als je goeie indexen op die tabellen legt, dan moet het uitlezen wel vrij vlot gaan. Alleen, ik weet niet hoe MySQL zich gedraagt bij 'miljoenen' records in één tabel.

djluc schreef op 29 December 2002 @ 11:40:

offtopic:
hoe kan ik de topictitel veranderen? per ongeluk op enter geduwd.

Wachten tot een modje het opmerkt, of een topic posten in SeM.
Hoe wil je de titel hebben?

[ Voor 56% gewijzigd door whoami op 29-12-2002 11:46 ]

[eXtReMeBiE]

Ik kwam laatst ook met een 'probleem' voor een counter...
Nu heb ik deze tabel-constructie:
Hits | IP.
Als een bezoeker die nog niet eerder op de site is gekomen (dwz: waarvan zijn ip niet in de DB staat) de site bezoekt, wordt er een extra rij aangemaakt, met daarin de waardes 1 voor hits, en $REMOTE_ADDR voor ip.
Als een bezoeker zijn ip wel in de DB staat, gewoon het aantal hits horende bij dat IP opzoeken, +1 doen, en dan terugschrijven in de DB...

Edit:
Dan is dus het aantal unieke bezoekers mysql_num_rows, en het aantal totale bezoekers zou je met bijv. een loop kunnen optellen, of zoals mij verteld was met mySQL zelf...

offtopic:
Ik heb echter de loop gebruikt aangezien ik het script al klaarhad, maar dat terzijde...

Als het goed is met 'count' in je mysql query, weet niet zeker

[ Voor 30% gewijzigd door eXtReMeBiE op 29-12-2002 13:15 ]

[djluc]

Dat klopt idd, maar er wordt bij mij per hit meer informatie opgeslagen dan bij jouw counter, het doet er verder even niet toe wat, ik moet echt voor iedere hit een rij hebben.

Of de db het leuk gaat vinden vraag ik mij dus ook af, zeker omdat je na meerdere jaren gewoon echt een giga tabel hebt. In de tabel staan overigens geen hele waarden maar alleen id's, zoals bezoeker=1, pagina=3. Wat bereft de grootte van de data valt het dus allemaal wel mee.

offtopic:
trouwens doet, met een ip een bezoeker identificeren is iets wat absoluut niet mag, je dient hiervoor sessions te gebruiken.

[ACM]

djluc schreef op 29 December 2002 @ 14:46:

offtopic:
ouwens doet, met een ip een bezoeker identificeren is iets wat absoluut niet mage, je dient hiervoor sessions te gebruiken.

Nou zeg je dat alweer

Wie zegt dat jij een bezoeker aan het identificeren bent als je domweg een hitcounter maakt
Je kan prima de ip's gebruiken voor een indicatie van het aantal bezoekers, het precieze aantal kan je toch niet of nauwelijks te weten komen.

[djluc]

Heb je misschien ook een idee over mijn vraag, dat zou ik wel fijn vinden ;-)

offtopic:
Als je 10 mensen naar jouw site laat surfen achter een proxy, ze bezoeken allemaal 3 pagina's. Eiegnlijk zou je dan dus 10 unieke bezoekers gehad hebben en 30 hits. Nu heb je maar 1 bezoeker met 30 hits, het lijkt dus of een bezoeker heel je site doopluist, trwijl hij dat eigenelijk niet doet. Hoe precies deze methode is weet ik niet, maar er zullen weinig fouten inzitten.

[ACM]

Euh, ik heb nog niet echt een degelijke uitleg gezien
Elke "kolom" waar je op/in zoekt moet je voor afwegen of het met een index erop sneller wordt. Elke index is echter weer wel een (beetje) trager bij het update/inserten/deleten. (niet helemaal waar, want het vinden van de te deleten/updaten entry kan weer sneller gaan).

Als je (siteid, paginaid, bezoekerid, tijd) opslaat en je wilt een overzicht bouwen per site, pagina en bezoeker 'moet' je dus ook op die drie een index leggen (eventueel een samengestelde, als je bijna alleen maar samenstellingen pakt (bijvoorbeeld overzichten van bezoekers op pagina X van site Z)

offtopic:
Je hebt het over miljoenen hits per jaar, denk je niet dat die foutmarge van een paar procent (zoveel mensen gebruiken geen proxy, of wel?) echt zoveel uitmaakt? Op andere plaatsen tel je tenslotte vast wel weer mensen dubbel (mensen met meerde browsers, meerdere computers, etc)

[ Voor 20% gewijzigd door ACM op 29-12-2002 15:21 ]

[djluc]

Maar mijn basisopzet, dus van iedere hit een record amken is dus wel te behappen door mysql, mooi.

offtopic:
Dat klopt idd, maar je probeert toch je ebst te doen om de resultaten zoveel mogelijk te laten kloppen. Krijg je als je op ctrl-N drukt trouwens een nieuwe sessionid?d8 van wel.

[bigtree]

djluc schreef op 29 December 2002 @ 17:04:
Maar mijn basisopzet, dus van iedere hit een record amken is dus wel te behappen door mysql, mooi.

Een miljoen pageviews per jaar vinnik niet eens zo veel. Moet MySQL makkelijk trekken. Check wel even of er een fair-use policy op je account zit. Meestal wordt de grootte van je DB niet echt gecontroleerd.

offtopic:
Dat klopt idd, maar je probeert toch je ebst te doen om de resultaten zoveel mogelijk te laten kloppen. Krijg je als je op ctrl-N drukt trouwens een nieuwe sessionid?d8 van wel.

Dat ligt er aan. Als het session-cookie al naar je pc is geschreven, dan niet. Als je cookies uit hebt staan (en je zit nog op de eerste pagina), dan krijg je een nieuwe sessie bij Ctrl-N.

[djluc]

Ik heb toch een controle op cookies dus die kan ik nog wel wat aanpassen om zo toch de gebruiker te blijven herkennen.

Die miljoen hits is slechts een fictief getal he, ik weet natuurlijk nooit precies hoeveel bezoekers de sites die mijn systeem gaan implementeren volgend jaar gaan krijgen. Als de service goed begint te lopen kunnen het er weleens veel meer worden. Wat betreft die fair-use-policy he, als er geen max aan de db zit kan ik er vrijwel ongelimiteerd gegevens in opslaan neem ik aan. Het moet natuurlijk niet te gek worden dat hun servers plat komen te liggen ;-) Verder valt de grootte eigenlijk wel mee, per hit sla ik een datum, en 4 id's (auto_increment) op, zo veel info is dat toch niet.

[marty]

ik zou er alleen niet van uit gaan dat iedereen cookies aan heb staan. bezoekers die het dan uit hebben staan tel je dan namelijk bij iedere klik als nieuwe bezoeker
tenzij je graag snel een miljoen bezoekers wil hebben, dan is dat wel een slimme oplossing ...

[Verwijderd]

Het ligt natuurlijk volledig aan welke informatie je wilt bewaren. Als je (zoals in je andere topic staat) iedere afzonderlijke user wil tracken over je site, zal je al die gegevens moeten bewaren. Als het bijvoorbeeld voldoende is om te weten hoeveel users van pagina 1 naar pagina 2 surfen, en hoeveel van pagina 2 naar 3, dan zou je, ipv de user tracken, gewoon voor iedere navigatie tussen 2 pagina's een totaal kunnen ophogen. Als tussenoplossing zou je evt. wel de tracking data voor iedere maand kunnen onthouden, en die daarna weggooien (waarbij je natuurlijk wel iedere keer de totalen up to date moet houden).

Verder staat er in de (oude?) FAQ nog een stukje advies over indexen dat nuttig zou kunnen zijn.

HTH

[djluc]

Dat ophogen d8 ik eerst ook aan, alleen dan weet je nog steeds niet welk pad ze nu volgen als je verder redeneerd. Je weet namelijk niet hoe ze op die beginpagina zijn gekomen, en waar ze na de 2de pagina weer naartoe gaan.

Ik gebruik ook de informatie om te kijken wat de exacte route was van 1 bezoeker.

Als coekies trouwens uit staan wil ik nog een andere manier bedenken, maaar dat is nu even niet het belangrijkste.

[Verwijderd]

Dat zeg ik dus al in de tweede zin:

Als je (zoals in je andere topic staat) iedere afzonderlijke user wil tracken over je site, zal je al die gegevens moeten bewaren.

Kortom, je ontkomt er niet aan alle records van iedere overgang te bewaren. Het enige dat je dan nog kan doen is een goede DB kiezen (evt. iets anders dan MySQL), je DB goed tunen en je hardware opschroeven.

[djluc]

Thanx, ik ga het gewoon een tijdje proberen, en na een tijdje zal ik weleens kijken of ik het op deze manier haal, anders stap ik over op een andere db. Ik hoop dat het antwoord op mijn andere topic ook snel gevonden zal worden.

[ddofborg]

Het beste wat je kunt doen is het volgende:

Je maakt een tabel waar bij elke bezoek b.v. datum/tijd, ip, url opgeslagen worden. Als je na zoveel tijd 'te veel' records hebt dan maakt je nog een tabel aan die dezelfde data opslaat, maar dan gegroupeerd.
Dus bijvoorbeeld bezoeken per dag. Als datum/tijd heb je dan b.v. alleen de datum, en aantal bezoeken.
Als je bijvoorbeeld infomatie moet hebben die met URL's te maken heeft, dan maak je een tabel met URL en aantal bezoeken, enz...

Dit kun je automatiseren door elke week om 04:00 uur een cron job uit te voeren die alle informatie uit grote tabel in de kleinere tabellen stopt.
Als nadeel heeft het natuurlijk dat je informatie dubbel opslaat, maar als voorbeeld dat je VEEEEEL minder tijd nodig hebt op alle informatie uit de grote tabel te halen.

IMDB doet het bijvoorbeeld ook. 1 keer per dag om 06:00 uur wordt de data van de stemmen enzo bijgewerkt, want realtime is het niet te trekken.

Maar zoals gezegd is, met goed indexen is het ERG goed te doen. Ik heb thuis een DB met 3.000.000 record met text erin, en FULLTEXT zoeken op een Pentium 1 @ 200 MHz duurt 0.08 seconden. Dus met andere data moet het niet langer duren.


PS: let niet op taalfouten, ik heb nu geen tijd om het door te lezen...
Suc6,
DD

[djluc]

Alvast bedankt voor je info!
Het ophalen mag alleen door de webmaster gebeuren, en zal dus niet zoals bij nedstat basic erg vaak gedaan worden. Als een fulltext search op 3000000 records 'maar' 0.08s duurt op een PI dan moet dit geen enkel probleem vormen op de prof. servers van een hosting provider.