Een vriend en ik zijn bezig met een forum en we zijn opzoek naar een manier hoe we het beste ongelezen/gelezen kunnen doen.
De manier waarop we het nu doen is dat we elke keer als iemand een topic bezoekt dan slaan we dat op, maar als je een grote userbase hebt dan komt die tabel na een tijdje behoorlijk vol te zitten.
Is er een betere of meer efficiëntere manier om dit te doen?
Hier werkt het hetzelfde. Om te voorkomen dat tabellen huge worden gebruik ik enkel de data van de afgelopen 14 dagen ofzo; topics ouder dan dat worden sowieso als gelezen gemarkeerd. Je voorkomt dan dat je ook topics uit 2008 enzo zit te checken.
De tabel bevat nu ook meer dan 1 miljoen rijen, maar als je de boel goed optimaliseert dan merk je daar niks van; hij vindt in 0,0004 seconde of ik dit topic al eens eerder heb gelezen.
Hier werkt het hetzelfde. Om te voorkomen dat tabellen huge worden gebruik ik enkel de data van de afgelopen 14 dagen ofzo; topics ouder dan dat worden sowieso als gelezen gemarkeerd. Je voorkomt dan dat je ook topics uit 2008 enzo zit te checken.
De tabel bevat nu ook meer dan 1 miljoen rijen, maar als je de boel goed optimaliseert dan merk je daar niks van; hij vindt in 0,0004 seconde of ik dit topic al eens eerder heb gelezen.
Heb jij er ook hardware tegenaan gegooid of dat niet? (Jij weet ongetwijfeld dat ik een optimalisatie OCD heb)
Is het geen mogelijkheid om elke keer als er weer gereageerd wordt om dan de rijen te verwijderen van "forum_threads_read" te verwijderen zodat je er voor zorgt dat het een stuk minder vol wordt?
Of is dat een slecht idee, heb ee nog niks over gelezen namelijk.
Is het geen mogelijkheid om elke keer als er weer gereageerd wordt om dan de rijen te verwijderen van "forum_threads_read" te verwijderen zodat je er voor zorgt dat het een stuk minder vol wordt?
Of is dat een slecht idee, heb ee nog niks over gelezen namelijk. Dat moet je gewoon even logisch beredeneren.
Je houdt in die tabel bij of een topic al gelezen is. Zodra er wordt gereageerd dan is een topic per definitie ongelezen, dus kun je inderdaad die hits weggooien. Maar als die post dan weer verwijderd wordt dan is het topic nog steeds als ongelezen gemarkeerd, terwijl er dus in feite niets nieuws is. Je moet dan zelf kiezen hoe je dat tegen elkaar afweegt.
Sevvlor schreef:
Eerdere citaten tonen
Lennard schreef:
Hier werkt het hetzelfde. Om te voorkomen dat tabellen huge worden gebruik ik enkel de data van de afgelopen 14 dagen ofzo; topics ouder dan dat worden sowieso als gelezen gemarkeerd. Je voorkomt dan dat je ook topics uit 2008 enzo zit te checken.
De tabel bevat nu ook meer dan 1 miljoen rijen, maar als je de boel goed optimaliseert dan merk je daar niks van; hij vindt in 0,0004 seconde of ik dit topic al eens eerder heb gelezen.
Heb jij er ook hardware tegenaan gegooid of dat niet? (Jij weet ongetwijfeld dat ik een optimalisatie OCD heb)
Er is af en toe een upgrade geweest om te zorgen dat de hele database in het RAM past, en in het optimaliseren van de queries heb ik vele uren werk gestoken. Er zijn tijden geweest dat het baggertraag was, maar inmiddels draait het weer als een zonnetje. *afklopt* Maar verder draait het gewoon op 2GB RAM, en dan is er nog een dikke honderd MB vrij ook, en is dat uiteraard ook voor Apache, email enzovoorts.
Is het geen mogelijkheid om elke keer als er weer gereageerd wordt om dan de rijen te verwijderen van "forum_threads_read" te verwijderen zodat je er voor zorgt dat het een stuk minder vol wordt?
Of is dat een slecht idee, heb ee nog niks over gelezen namelijk.
Persoonlijk ben ik tegen het verwijderen van data, althans in dit opzicht. Ik dacht dat in sommige gevallen de "index" van MySQL dan vernieuwd moest worden door MySQL zelf. Dat gebeurt bij een UPDATE niet, mits je de PK niet aanpast.
//Dit is het enige wat ik kan vinden, ik weet het niet helemaal zeker meer. //edit 2: alles heeft effect, Ik ga verder zoeken wat de effecten zijn. Ik wil het zelf ook weten
Is het geen mogelijkheid om elke keer als er weer gereageerd wordt om dan de rijen te verwijderen van "forum_threads_read" te verwijderen zodat je er voor zorgt dat het een stuk minder vol wordt?
Of is dat een slecht idee, heb ee nog niks over gelezen namelijk.
Persoonlijk ben ik tegen het verwijderen van data, althans in dit opzicht. Ik dacht dat in sommige gevallen de "index" van MySQL dan vernieuwd moest worden door MySQL zelf. Dat gebeurt bij een UPDATE niet, mits je de PK niet aanpast.
Ik ben ook tegen het verwijderen van data, maar in sommige gevallen is er niks op tegen, toch? Ik bewaar ook de Apache statuslijsten van de hele dag van alle webservers, maar dat is iets van 1GB per dag aan data. Als ik dat wil gaan bewaren dan heb ik huge storage nodig, en ik heb er geen klap aan. Die tabel wordt regelmatig opgeschoond, maar de overhead daarvan wordt ook steeds groter, dus die moet om de paar maanden wel geoptimized worden om het snel te houden.
Die topic-gelezen-tabel schoon ik eens in de zoveel jaar op, en dat lijkt me dan ook prima. Sterker nog; niemand merkt dat omdat topics > 14 dagen sowieso als gelezen worden beschouwd.
Sevvlor schreef:
Eerdere citaten tonen
Joeryy schreef:
Is het geen mogelijkheid om elke keer als er weer gereageerd wordt om dan de rijen te verwijderen van "forum_threads_read" te verwijderen zodat je er voor zorgt dat het een stuk minder vol wordt?
Of is dat een slecht idee, heb ee nog niks over gelezen namelijk.
Persoonlijk ben ik tegen het verwijderen van data, althans in dit opzicht. Ik dacht dat in sommige gevallen de "index" van MySQL dan vernieuwd moest worden door MySQL zelf. Dat gebeurt bij een UPDATE niet, mits je de PK niet aanpast.
//Dit is het enige wat ik kan vinden, ik weet het niet helemaal zeker meer.
Oh dat klinkt logisch inderdaad. Maar dan nog zou ik denk ik liever eens in de zoveel tijd die tabel fragmenteren dan met gigabytes aan data zitten die je niet gebruikt en eigenlijk ook helemaal niets aan hebt.
Ik ben al blij dat ik deze query heb kunnen maken , ben totaal geen held als het om SQL gaat.
SELECT p.datetime AS last_post_thread, r.datetime AS last_visit FROM forum_threads t, forum_posts p, forum_threads_read r WHERE t.id = :thread_id AND (r.datetime > t.datetime OR r.datetime > p.datetime) AND r.user_id = :user_id ORDER BY r.datetime DESC LIMIT 1
Het is mij wel een keer gelukt om het te maken, maar geloof mij het is toch wel aardig pittig met al die queries en shizzle. Daar ben je nog wel even mee bezig.
Het is mij wel een keer gelukt om het te maken, maar geloof mij het is toch wel aardig pittig met al die queries en shizzle. Daar ben je nog wel even mee bezig.
Ik vond het persoonlijk meevallen . Het was alleen een gigantische query.??
toevoeging op 9 december 2014, 0007:
Joeryy schreef:
Ik ben al blij dat ik deze query heb kunnen maken , ben totaal geen held als het om SQL gaat.
SELECT p.datetime AS last_post_thread, r.datetime AS last_visit FROM forum_threads t, forum_posts p, forum_threads_read r WHERE t.id = :thread_id AND (r.datetime > t.datetime OR r.datetime > p.datetime) AND r.user_id = :user_id ORDER BY r.datetime DESC LIMIT 1
Persoonlijk ben ik geen voorstander van tabelnamen in het meervoud. Ver verneukt ORM en bij complexere queries is de naamgeving schijt irritant
Lennard spreekt hier over meerdere queries die je eigenlijk in een (redelijk ingewikkelde) join waarschijnlijk ook op kan halen en kan optimaliseren. Hier en daar eigen invulling geven, en dan kom je al een heel eind.
Lennard spreekt hier over meerdere queries die je eigenlijk in een (redelijk ingewikkelde) join waarschijnlijk ook op kan halen en kan optimaliseren. Hier en daar eigen invulling geven, en dan kom je al een heel eind. Ja precies, ik heb het nu ook wat anders dan ik daar vertel (puur om het snel te houden), maar het gaat erom dat je de gedachte erachter goed begrijpt. Je moet het niet 1:1 overnemen, maar zelf ook even kritisch meedenken.
Lennard spreekt hier over meerdere queries die je eigenlijk in een (redelijk ingewikkelde) join waarschijnlijk ook op kan halen en kan optimaliseren. Hier en daar eigen invulling geven, en dan kom je al een heel eind. Ja precies, ik heb het nu ook wat anders dan ik daar vertel (puur om het snel te houden), maar het gaat erom dat je de gedachte erachter goed begrijpt. Je moet het niet 1:1 overnemen, maar zelf ook even kritisch meedenken.
Het scheelt ook nogal dat die uitleg al 5 jaar oud is. In die 5 jaar kun je heel wat bijleren over MySQL
Jouw reactie
Deel je idee, stel een vraag of help een ander verder.
, ben totaal geen held als het om SQL gaat.
07:
