[PHP] Database limiet

[Verwijderd]

Hallo,

Ik heb een script wat bijhoudt hoeveel, en welke bezoekers naar een specifieke pagina gaan. Dit wordt allemaal opgeslagen in de database (bezoek_id, bezoek_ip, bezoek_pagina). Hierdoor komen er aardig wat records in de database te staan waardoor deze vol begint te raken. Wat zou een oplossing kunnen zijn om dit probleem te verhelpen? Zelf zat ik te denken dat deze informatie misschien in een bestand weggeschreven zou kunnen worden, maar heb geen idee of dit helpt?

Iemand een idee?

[AtleX]

Heb je niet gewoon genoeg aan de serverlogs, zoals access.log en error.log van Apache? Die zijn gewoon in het CLF formaat, dus met Webalizer, AWStats of een custom tool moet je daar vrij eenvoudig statistieken van kunnen bakken.

[CodeCaster]

Dat zijn erg ruwe gegevens, waar je onverwerkt niks mee kunt. Waarom maak je geen scriptje dat zeg, per dag, de gegevens naar een overzicht wegschrijft?

Dan moet je wel gaan uitzoeken wat je nou eigenlijk wil opslaan, het aantal unieke IP's per dag bijvoorbeeld.

Ook zou je een koppeltabel kunnen bijhouden, waarbij het IP een ID krijgt en je pagina ook, waarna je deze twee dus apart in een tabel opslaat.

[Verwijderd]

2 woorden: "Google Analytics"

[Pete]

Ehm, wanneer is een database vol?

Wat je uiteraard kunt doen is je archief te "summarizen" en dit apart op te slaan. Ook kun je een history tabel maken per jaar als de tabellen te groot worden om zinnig queries op uit te kunnen voeren.

[SH4D3H]

Wat is 'aardig wat'?
Je weet dat een goede database makkelijk miljoenen van die records kan bijhouden?

[Janoz]

Ik mis een datum/tijd in je tabel.

Het exporteren naar een bestand heeft imho weinig nut aangezien daardoor de hoeveelheid data niet kleiner wordt. Het helpt natuurlijk wel wanneer je dit ergens anders gaat bewaren. Ikzelf zou het niet in een bestand gaan zetten maar gewoon in een database laten (eventueel een externe database). In een database is er veel makkelijker wat statistiek op los te laten.

Mocht de data eventueel toch te groot gaan worden dan kun je gaan kijken welke gegevens je nu eigenlijk belangrijk vindt. Wil je nog steeds weten dat IP X op tijdstip Y ergens vorige week pagina Z bezocht heeft? En hetzelfde voor een jaar terug?

Wat vaak gedaan wordt is oude data aggregeren. Na 3 maanden tel je de bezoeken bij elkaar op en bewaar je alleen de hits per pagina per uur oid, en na een half jaar alleen nog maar per dag ipv per uur. Maar dat is iets dat je in moet regelen afhankelijk van welke gegevens je nodig hebt en hoeveel ruimte je beschikbaar wilt stellen.

[Niemand_Anders]

Dat ligt er natuurlijk helemaal aan wat met met de 'statistieken' gedaan wordt. Wij laten bijvoorbeeld complete analyzes op op deze data om trends te ontdekken. Als je dan data gaat plat slaan (bijvoorbeeld gegevens per dag bijhouden) wordt het lastiger om voorspellingen voor de toekomst te doen. Worden de gegevens alleen gebruikt om statistieken te tonen (ala google analystics of NedStat) dan is het 'plat' slaan van de gegevens een goede oplossing om 'ruimte' te creeren.

Het opslaan van statistieken per 'jaar' tabel is niet handig als er queries om meerdere jaren nodig zijn.

[Bosmonster]

Ik snap je opmerking 'database raakt vol' niet helemaal. In een beetje tabel kunnen 4,2 miljard records en dat is zonder gekke trucjes. Wat raakt er precies vol?

Daarnaast is aggregeren inderdaad de beste oplossing als je beperkte database ruimte hebt of je de performance onder de grote hoeveelheid data begint te lijden.

Daar nog eens naast snap ik overigens ook de statistische waarde niet van die 2 gegevens die je opslaat. Alleen met IP en bezochte pagina kom je niet heel ver volgens mij.

[ Voor 21% gewijzigd door Bosmonster op 17-04-2008 12:02 ]

[André]

Move naar Programming

[Verwijderd]

De tijd en datum wordt inderdaad ook opgeslagen. Was ik inderdaad vergeten te melden. Met aardig wat records bedoel ik 16.000. Een database zou echter veel meer aan moeten kunnen. Maar de grootte van de tabel is bijna 800 mb. En de opslagruimte op de server laat niet meer toe.

Het aggregeren is misschien een optie, maar aangezien de gegevens maar van een paar maanden zijn zal dit lastig worden denk ik

[_Apache_]

800MB? Dat maakt ~ 50KB per record?!

Heb je overhead op je tabel?
Wel is relationering gedacht? 1000x een dezelfde gegevens opslaan is kansloos, gewoon 1 keer goed opslaan en koppelen

[Voutloos]

50 KB per row? Sla je soms meteen de complete pagina erbij op?

Je tabel zou zo maar een factor 100 kleiner kunnen zijn met de kolommen welke je tot nu toe genoemd hebt, en dan doe je het nog slecht.

Zou je de create table statement hier kunnen zetten?

[Verwijderd]

Heb de tabel gexporteerd. Dit is dan het create teable statement wat ik hiervan kreeg:

CREATE TABLE `tabel_statistiek` (
`bezoek_id` int(11) NOT NULL auto_increment,
`bezoek_ip` varchar(15) collate latin1_general_ci default NULL,
`bezoek_pagina` varchar(100) collate latin1_general_ci default NULL,
`bezoek_tijd` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
PRIMARY KEY (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;

Heb trouwens geen overhead op de tabel

[ Voor 3% gewijzigd door Verwijderd op 17-04-2008 13:46 ]

[Voutloos]

Dan heb je gewoon het aantal rows of het aantal bytes verkeerd genoemd net.

[Verwijderd]

Dat kan ik hier nu niet zien.

Heb deze tabel gisteren namelijk leeg gemaakt (wel een back-up van, maar die staat thuis op de pc). Dit heb ik gedaan om toch nog ruimte te krijgen om afbeeldingen te kunnen uploaden, welke niet in de db staan. Zal het vanavond nog wel eens proberen te bekijken.. Maar de grootte moet sowieso kloppen, want kon eerst geen afbeeldingen meer uploaden en na het leegmaken van deze tabel wel weer. Dus dit was een ruimtegebrek probleem..

[TeeDee]

Verwijderd schreef op donderdag 17 april 2008 @ 14:04:
Maar de grootte moet sowieso kloppen, want kon eerst geen afbeeldingen meer uploaden en na het leegmaken van deze tabel wel weer. Dus dit was een ruimtegebrek probleem..

Zou je, alvorens je je DB leeg mikt, niet eerst even wat grondiger onderzoek doen ipv dit paardenmiddel toe te passen?

[Bosmonster]

Gezien het kleine aantal records en het gebrek aan indices verwacht ik ook dat die tabel 800KB was ipv 800MB. Of dat je een flink aantal nullen op het aantal records gemist hebt. (in welk geval de tabel statistisch gezien enigszins nutteloos was geworden door het gebrek aan indices).

Dat je iets weggooit en je kan weer uploaden zegt bar weinig over hoeveel je net weggegooid hebt natuurlijk Ook als je 800K weggooit kun je vast weer wat afbeeldingen uploaden.

[Verwijderd]

TeeDee schreef op donderdag 17 april 2008 @ 14:19:
[...]

Zou je, alvorens je je DB leeg mikt, niet eerst even wat grondiger onderzoek doen ipv dit paardenmiddel toe te passen?

Heb dit idd niet zelf onderzocht. Maar hield me hier ook niet mee bezig. Iemand anders heeft dit ook gemaakt, maar doordat hij zelf niet op internet kon en de afbeeldingen + info perse geupload moesten worden had ie mij gevraagd de tabel even leeg te maken. Natuurlijk is dit niet de beste oplossing, maar wel de snelste en het werkte wel.. Maar nu ik deze opmerkingen hier lees begin ik toch inderdaad de indruk te krijgen dat ik een keer te weinig door 1024 heb gedeeld.. Maar of dat klopt zie ik vanavond wel

[Cartman!]

Als je zo graag je bezoekers wil tracken, geef dan een paar tientjes uit voor Clicky Kun je zelf realtime bezoekers mee tracken. Mag het niks kosten? Pak dan Google Analytics. Dergelijke diensten zijn zoveel verder dan je alleen kunt komen from scratch.

[Verwijderd]

sorry had idd fout gerekend..

Maar het is niet dat ik perse mn bezoekers wil tracken, maar leek me wel leuk om zelf een scriptje daarvoor te schrijven

[Arnout]

Verwijderd schreef op vrijdag 18 april 2008 @ 09:48:
sorry had idd fout gerekend..

Maar het is niet dat ik perse mn bezoekers wil tracken, maar leek me wel leuk om zelf een scriptje daarvoor te schrijven

Kan ook prima op die manier, maar dan moet je database niet moeilijk gaan doen bij 16000 records / 800 Kb. Dat is in databasetermen werkelijk niks.

[Hydra]

Arnout schreef op vrijdag 18 april 2008 @ 09:56:
[...]

Kan ook prima op die manier, maar dan moet je database niet moeilijk gaan doen bij 16000 records / 800 Kb. Dat is in databasetermen werkelijk niks.

Dat zou access nog prima trekken, dus ik vraag me af waar de conclusie vandaan komt dat de DB het niet trekt.

[Verwijderd]

Er draaien nog meer scripts. Een van die scripts wordt gebruikt voor het toevoegen van een afbeelding + beschrijving. Iemand kreeg dit op een gegeven moment niet meer voor elkaar. Wel met alleen een beschrijving. Dus het probleem zat in de afbeelding dus.. Iemand dacht dat het wel in de grootte van de db kon zitten. Deze had ik dus toen even weggehaald en toen had ik het getest. Het werkte toen wel. Dus de conclusie getrokken dat het daar aan zou liggen... (Had ik niet moeten doen..)

De fout zat echter niet in de db maar degene die de afbeelding wilde gebruiken, maakte gebruik van het oude systeem waarin de koppelingen niet meer goed zaten. Vandaar dat het bij hem niet werkte en bij mij wel..