[php/mysql] Postcount efficient bijhouden

[MAZZA]

Voor een pagina waar mensen kunnen reageren op nieuws wil ik per user de postcount bijhouden. Nu zit ik een beetje met een dilemma. Hoe ga ik deze postcount bijhouden?
De bedoeling is dat de postcount in het profiel van de user ga bijhouden. Dus echt vaak wordt deze niet opgevraagd. Nu had ik een discussie met een vriend van me om die postcount dus bij te houden. Ik dacht zelf aan dit:

Pseudocode:

code:

if (post=true) {
    update dabase postcount+=1;
}

Maar die vriend zei dat je net zo goed een count() kan doen op de post tabel. Maar in mijn ogen is dat een stuk zwaarder dan mijn manier. Hoewel het op mijn manier wel een extra update query is bij elke post.

Zijn er meer mensen tegen dit probleem aangelopen? Wat is efficient?

Ik ben benieuwd

[gorgi_19]

Je krijgt een stuk redunantie in je tabel als je de postcount apart opslaat. Echter, ik denk niet dat het opweegt tegen het voordeel van efficiency. Ik neem aan dat ze hier ook niet iedere keer een count-functie gaan gebruiken voor het bepalen van het aantal posts.

[justmental]

Een count is een stuk trager.
Gewoon die update doen zoals je van plan was.

[MAZZA]

Hmm mijn idee.. Maar nu hoor ik weer van iemand anders dat een count() op de posts tabel met daarop een index op de id van de gebruiker veel sneller/efficienter zou zijn. Ook omdat er met een update bij elke post sneller 'out-of-synch' zou raken.

Tegenstrijdige reacties dus

[Lurge]

is dr geen parse devver die het je ff kan mededelen wat zij gebruiken hier?

[gorgi_19]

MAZZA schreef op 21 February 2003 @ 12:21:
Hmm mijn idee.. Maar nu hoor ik weer van iemand anders dat een count() op de posts tabel met daarop een index op de id van de gebruiker veel sneller/efficienter zou zijn. Ook omdat er met een update bij elke post sneller 'out-of-synch' zou raken.

Tegenstrijdige reacties dus

Je kan mij echt niet wijsmaken dat

SQL:

Select aantal FROM tabel where user=1 

langzamer is dan

SQL:

Select count(*) as aantal FROM tabel where user=1 

Verder:
Out of synch raken? Gewoon consequent bij insert en delete alles bijhouden?

[justmental]

MAZZA schreef op 21 February 2003 @ 12:21:
Hmm mijn idee.. Maar nu hoor ik weer van iemand anders dat een count() op de posts tabel met daarop een index op de id van de gebruiker veel sneller/efficienter zou zijn. Ook omdat er met een update bij elke post sneller 'out-of-synch' zou raken.

Tegenstrijdige reacties dus

-Je posts tabel is veel groter dan je gebruikers tabel.

Dat out of sync raken hoeft niet te gebeuren als je deze gegevens netjes bijwerkt, dus ook bij deleten van posts en topics.

edit:
niet helemaal goed gelezen

[ Voor 11% gewijzigd door justmental op 21-02-2003 12:30 ]

[Verwijderd]

Lurge schreef op 21 February 2003 @ 12:24:
is dr geen parse devver die het je ff kan mededelen wat zij gebruiken hier?

T lijkt mij dat ze de methode van de topicstarter gebruiken Elke keer een count() op een tabel van meer dan 17 miljoen records is geen pretje voor je dbase-server

[Vuurvlieg]

het ligt voornamelijk aan de hoeveelheid posts die er gedaan worden, de count() gaat bij lage hoeveelheden prima, maar bij grote hoeveelheden posts wordt deze traag, door elke keer de postcount te updaten spreid je de load als het ware. Het ligt er een beetje aan dus hoeveel posts je verwacht per user.

[MAZZA]

Vuurvlieg schreef op 21 February 2003 @ 12:30:
het ligt voornamelijk aan de hoeveelheid posts die er gedaan worden, de count() gaat bij lage hoeveelheden prima, maar bij grote hoeveelheden posts wordt deze traag, door elke keer de postcount te updaten spreid je de load als het ware. Het ligt er een beetje aan dus hoeveel posts je verwacht per user.

De postcount wordt niet echt vaak opgevraagd. Aan de andere kant wordt er natuurlijk wel meer gepost (althans dat hoop ik toch ). En elke post betekent dan ook een update query. Vandaar dus de discussie die ik eerder al had met iemand. De afweging is dus puur van wat is zwaarder. Bij elke post een update of bij het opvragen van een userprofile (als het goed is minder vaak dan het posten) een count.

[Orphix]

Gewoon de postcount updaten. Ik kan me voorstellen dat een count(*) op een gehele tabel met een index op de primary key wel snel is (wordt het aantal elementen van een key bijgehouden in de index tabel van een database?)

Maar stel dat je straks achter elke naam de postcount van die gebruiker wil laten zien, dan is dat extra veld meenemen veel efficienter dan voor elke gebruiker de database zijn/haar aantal posts laten tellen (dmv een subselect of join).

[drm]

Volgens mij kun je het beste, als je het echt wilt weten, gewoon zelf een tijdje proefdraaien met beide oplossingen. Ik denk zelf dat een update elke post zo weinig overhead geeft op het updaten/inserten van een post zelf, dat dat de beste oplossing zou zijn.

Maar om daar goed inzicht in te krijgen zou je beide gevallen uit moeten proberen waarbij je in het ene geval de totale overhead van updates bijhoudt, en in het andere geval de totale overhead van de count(user_id) op de post tabel. (sowieso is count(*) langzamer dan op user_id...). Als je die na een maand ofzo tegen elkaar af kan wegen, dan weet je wat de beste keus is.

Eerlijk gezegd zou ik me er niet zo druk om kunnen maken, omdat de meeste overhead doorgaans toch niet in dergelijke queries zit

[ Voor 4% gewijzigd door drm op 21-02-2003 12:49 ]

[MAZZA]

Ik zal het inderdaad allebei eens proberen Thx allen!

[.oisyn]

overigens is het out-of-sync raken tegen te gaan met transacties

[Lurge]

SELECT count(code) FROM item doet er:
Count 10000 times in 2.34805095196 seconds over

en

SELECT facility_id FROM item WHERE code='2-2056-319/BRK1' doet er:
SELECT 10000 times in 3.93859004974 seconds over.

deze code gebruik ik voor de loop:

PHP:

for($i=0;$i<10000;$i++){
        $result = mysql_query($sql);
        $rij = mysql_fetch_assoc($result);
}

en bij 50000 keer duurt de count(code) query: 12.718791008 seconds
en de andere: 23.7208149433 seconds

Vraag ik me alleen nog af wat het scheelt als je de 1e query met een WHERE erin doet.
Resultaat zou zijn: dat de count(code) sneller zou zijn.

edit:

Ook ff getest met 50000 keer en dan SELECT count(code) FROM item WHERE 1 en daar komt ie uit op: 8.11223006248 seconds

Als ik deze query gebruik:
[code]SELECT count(code) AS bla FROM item WHERE range_id < 15[/code]
dan lijkt ie wel in een loop te komen zo lang duurt het...

PS. in de database zitten 10.000 records

[ Voor 20% gewijzigd door Lurge op 21-02-2003 16:49 ]

[MAZZA]

Zeer verhelderend lurge! Thanks