Posts binnen een (forum)draadje wel/niet gelezen

plus duizend miljoen miljard!

In ieder ander forum kan ik topics subscriben en weet de software tot waar ik een topic gelezen heb, gesubscribed of niet. Zeker bij hoog-volume fora is dat wel erg handig, want ik kan niet de hele dag alles lezen wat ik wil lezen.

Hier op tweakers zijn een aantal "het grote <...>-topic"s die het volgen waard zijn. Ik heb echter niet altijd de tijd om die allemaal te lezen, dus de methode om "nieuw sinds vorige bezoek" te bekijken voldoet eigenlijk voor geen meter. Even een keer m'n MyReact-bookmark aanklikken in m'n browser betekent al dat ik vele posts ga missen omdat mijn laatste-bezoek-timestamp dan alsweer is bijgewerkt.

Tot nu toe kon je bookmarks gebruiken als work-around voor deze tekortkoming. Ook die mogelijkheid is nu gesloopt. Dit maakt het onmogelijk om dit forum nog enigszins serieus te volgen. Af en toe een blik om te kijken of er nog interessante hot topics zijn is het enige dat overblijft.

Jammer. Of mis ik iets?

Klik eens op het icoontje voor een topic in welke listing dan ook?

Dat is overigens gebaseerd op het moment dat je voor het laatst aanwezig was, niet wat je daadwerkelijk gelezen hebt. Een tabel bijhouden waarin 400.000 users en 13 (?) miljoen topics aan elkaar gelinkt worden lijkt me niet echt lekker fris werken.

NMe schreef op maandag 22 oktober 2012 @ 22:00:
Klik eens op het icoontje voor een topic in welke listing dan ook?

Dat is overigens gebaseerd op het moment dat je voor het laatst aanwezig was, niet wat je daadwerkelijk gelezen hebt.

Die ken ik, maar zoals ik al schreef in het bericht waar je op reageert: "Ik heb echter niet altijd de tijd om die allemaal te lezen, dus de methode om "nieuw sinds vorige bezoek" te bekijken voldoet eigenlijk voor geen meter. Even een keer m'n MyReact-bookmark aanklikken in m'n browser betekent al dat ik vele posts ga missen omdat mijn laatste-bezoek-timestamp dan alsweer is bijgewerkt."

Misschien moet ik dat nog nader toelichten?

Ik volg o.a. "Het grote ligfiets topic" en "Het grote luchtvaart topic". Daarnaast lees ik ook wel eens andere topics. In beide grote topics loop ik op het moment enkele pagina's achter, maar ik wil die wel nog eens doorlezen. Nu staan er bookmarks te wijzen naar de post die ik het laatst gelezen heb. Op dit moment heb ik geen mogelijkheid meer om nog wat in die topics te lezen zonder compleet het spoor daar kwijt te raken. Klik ik op het door jou aangeraden icoontje, dan spring ik naar de laatste posts sinds gisteren. Moet ik dan van daaruit achteruit lezen tot het punt waar het me weer wat bekend voorkomt?

Een tabel bijhouden waarin 400.000 users en 13 (?) miljoen topics aan elkaar gelinkt worden lijkt me niet echt lekker fris werken.

Hoe doet phpBB dat dan? Is open source, dus je zou dat af kunnen kijken als je zelf zonder inspiratie zit.

Je hoeft ook niet alle 13 miljoen topics voor me bij te houden, maar alleen die topics die ik wel eens bezocht heb. Of desnoods alleen topics waarop ik besluit me te abonneren. Uiteindelijk gaat het om maar 1 integer per user per bezocht topic. Lang niet zoveel als de bulken tekst die per bericht per user per topic opgeslagen moeten worden. Kan me toch niet voorstellen dat de resources zo krap zijn dat dat niet gaat lukken...

In jaren 90 hadden BBS'en er geen moeite mee. Usenetreaders hebben ook altijd prima onthouden waar ik bleef. Vele diverse fora hebben ook geen problemen, alleen bij Tweakers beginnen ze te zuchten over grote tabellen en grote aantallen users. Kom op zeg! Dit is BASISFUNCTIONALITEIT op een forum.

Of laat ik het iets vriendelijker vragen: hoe doen anderen dit dan? Hebben die er genoeg aan om alleen de hot topics een beetje te skimmen? Is er misschien een GoT -> NNTP interface zodat ik zelf een reader kan draaien die deze functionaliteit wel biedt?

Hieperdepiep...

rob_erwt in "[Bug] [GoT] Bookmark knop verdwenen"

Hoera!!!


(Maar het blijft een work-around t.o.v. een last-read-pointer...)

[ Voor 27% gewijzigd door TwOkkie op 23-10-2012 11:24 ]

MatHack schreef op maandag 22 oktober 2012 @ 23:00:
Ik weet dat je inderdaad op het icoontje kan klikken, vroeger werd aan de hand van dezelfde timestamp echter binnen een thread ook getoond welke posts je wel/niet gelezen had. Ik wil nog wel eens wat scrollen in een thread, dus dan is die extra indicatie fijn.

Ik kan me niet herinneren die feature ooit gezien te hebben op GoT, domweg omdat die feature niet lekker performt op de gebruikers- en topicaantallen die wij hebben.

TwOkkie schreef op dinsdag 23 oktober 2012 @ 09:01:
[...]


Die ken ik, maar zoals ik al schreef in het bericht waar je op reageert: "Ik heb echter niet altijd de tijd om die allemaal te lezen, dus de methode om "nieuw sinds vorige bezoek" te bekijken voldoet eigenlijk voor geen meter. Even een keer m'n MyReact-bookmark aanklikken in m'n browser betekent al dat ik vele posts ga missen omdat mijn laatste-bezoek-timestamp dan alsweer is bijgewerkt."

Misschien moet ik dat nog nader toelichten?

Ik volg o.a. "Het grote ligfiets topic" en "Het grote luchtvaart topic". Daarnaast lees ik ook wel eens andere topics. In beide grote topics loop ik op het moment enkele pagina's achter, maar ik wil die wel nog eens doorlezen. Nu staan er bookmarks te wijzen naar de post die ik het laatst gelezen heb. Op dit moment heb ik geen mogelijkheid meer om nog wat in die topics te lezen zonder compleet het spoor daar kwijt te raken. Klik ik op het door jou aangeraden icoontje, dan spring ik naar de laatste posts sinds gisteren. Moet ik dan van daaruit achteruit lezen tot het punt waar het me weer wat bekend voorkomt?

Dat is de keus die je zelf hebt gemaakt door die topics niet bij te lezen. Ik begrijp best dat het behelpen is, maar het is niet anders.

Hoe doet phpBB dat dan? Is open source, dus je zou dat af kunnen kijken als je zelf zonder inspiratie zit.

Een phpBB-forum met vergelijkbare topic- en gebruikersaantallen als hier ga je niet vinden.

Je hoeft ook niet alle 13 miljoen topics voor me bij te houden, maar alleen die topics die ik wel eens bezocht heb. Of desnoods alleen topics waarop ik besluit me te abonneren. Uiteindelijk gaat het om maar 1 integer per user per bezocht topic. Lang niet zoveel als de bulken tekst die per bericht per user per topic opgeslagen moeten worden. Kan me toch niet voorstellen dat de resources zo krap zijn dat dat niet gaat lukken...

Als je voor elk topic apart moet gaan bijhouden of je wel of niet actief bij wil houden waar je precies gebleven bent gaat dat ook vervelen. Het per view bijhouden resulteert in honderden topics per user per week, wat op den duur dus steeds slechter gaat performen.

In jaren 90 hadden BBS'en er geen moeite mee.

In de jaren 90 zaten er nog geen half miljoen mensen op één BBS.

Usenetreaders hebben ook altijd prima onthouden waar ik bleef.

Usenetreaders hoeven maar voor één gebruiker bij te houden waar die gebleven is. Uitgaande van 1000 onderwerpen op usenet maakt dat een verschil van 1000 vs. 400.000.000 records. Dat verschil zie je toch wel? En dan hebben we op GoT nog wel wat meer onderwerpen dan 1000.

Vele diverse fora hebben ook geen problemen, alleen bij Tweakers beginnen ze te zuchten over grote tabellen en grote aantallen users. Kom op zeg! Dit is BASISFUNCTIONALITEIT op een forum.

Dit is basisfunctionaliteit op kleine fora die naar grote fora helemaal niet lekker opschaalt.

Of laat ik het iets vriendelijker vragen: hoe doen anderen dit dan?

Kleinere aantallen.

[ Voor 74% gewijzigd door NMe op 23-10-2012 13:14 ]

NMe schreef op dinsdag 23 oktober 2012 @ 13:07:
Ik kan me niet herinneren die feature ooit gezien te hebben op GoT,

Ik ook niet, maar TS begon daar over. Heb wel eerder reacties van deze strekking gelezen:

domweg omdat die feature niet lekker performt op de gebruikers- en topicaantallen die wij hebben.
[...]
Een phpBB-forum met vergelijkbare topic- en gebruikersaantallen als hier ga je niet vinden.
[...]
Als je voor elk topic apart moet gaan bijhouden of je wel of niet actief bij wil houden waar je precies gebleven bent gaat dat ook vervelen. Het per view bijhouden resulteert in honderden topics per user per week, wat op den duur dus steeds slechter gaat performen.
[...]
In de jaren 90 zaten er nog geen half miljoen mensen op één BBS.
[...]
Dit is basisfunctionaliteit op kleine fora die naar grote fora helemaal niet lekker opschaalt.
[...]
Kleinere aantallen.

Zijn jullie echt het grootste forum ter wereld?

Usenetreaders hoeven maar voor één gebruiker bij te houden waar die gebleven is. Uitgaande van 1000 onderwerpen op usenet maakt dat een verschil van 1000 vs. 400.000.000 records. Dat verschil zie je toch wel? En dan hebben we op GoT nog wel wat meer onderwerpen dan 1000.

Dat weet ik, maar die reader draai ik dan ook lokaal. Hier is de "reader" een of andere niet-optionele webapp die bij jullie draait. Ik zou het helemaal niet erg vinden als jullie in mijn gebruikersdata een soort .newsrc bijhouden. Desnoods bijvoorbeeld alleen de laatste 1024 topics die ik geopend heb + die ik gebookmarked heb. Of zoiets. Kost je misschien 8k per gebruiker aan rauwe data. (32bit TopicId -> 32bit MessageId).

Misschien dat ik hier een beetje de beste stuurman aan de wal aan het uithangen ben, maar het lijkt mij dat je met wat handige tweakers daar wel een mouw aan kan passen.

Ik noemde maar phpBB omdat dat een veelgebruikt pakket is, ook op andere best-wel-drukke-fora die ik bezoek. Ik heb geen idee hoe ze het doen, maar daar weet het forum echt per topic automatisch en zonder ernaar om te kijken, tot welk bericht ik gekomen ben.

Dat is de keus die je zelf hebt gemaakt door die topics niet bij te lezen. Ik begrijp best dat het behelpen is, maar het is niet anders.

Toch is het f'ing irritant. Even tijdens het compilen kijken of je al een reactie hebt op een brandende vraag, betekent dat je in alle andere topics berichten gaat missen. Ik vind dat nog steeds een zeer irritante feature van dit forum. Niks persoonlijks verder hoor..

Bookmarks is op zich dan wel een handige work-around, alleen vergeet ik wel eens om voor het sluiten van een topic even dat +je te klikken. Zijn toch iedere keer weer twee clicks (en page loads) extra die ik bij de concurrentie niet tegenkom.

Sorry voor de schop van dit wat oudere topic...

Ik vraag me af hoe een forum als xda-developers dit dan wel voor elkaar krijgt?

Dat lijkt me toch ook niet echt een klein forum?

Bij elke post die je daar opent staat netjes een knop "View first unread". Deze werkt over verschillende PC's heen en zelfs in combinatie met de Android app (gebaseerd op Tapatalk).

Mr Magic schreef op vrijdag 25 januari 2013 @ 01:38:
Sorry voor de schop van dit wat oudere topic...

Ik vraag me af hoe een forum als xda-developers dit dan wel voor elkaar krijgt?

Dat lijkt me toch ook niet echt een klein forum?

Bij elke post die je daar opent staat netjes een knop "View first unread". Deze werkt over verschillende PC's heen en zelfs in combinatie met de Android app (gebaseerd op Tapatalk).

Met een 20 tal cookies denk ik. Deze wordt constant bijgewerkt als je naar beneden scrollt.

MuddyMagical schreef op vrijdag 25 januari 2013 @ 06:09:
[...]

Met een 20 tal cookies denk ik. Deze wordt constant bijgewerkt als je naar beneden scrollt.

Cookies werken toch niet over meerdere PC's heen?

Maar goed, zou leuk zijn als GoT ook zoiets had. Als het niet kan voor alle topics dan misschien alleen voor topics die de gebruiker bookmarkt?

XDA draait op vbulletin, die houden dat bij in een tabel in de database. Dat soort tabellen wordt wel ranzig groot. Ik heb het even nagekeken op een relatief klein forum: 10k users en 28k topics. Dat zorgt voor een threadread tabel van 1MB. Bedenk even dat er in Lieve Adjes alleen al bijna zoveel topics zijn, met bijna 50 keer zo veel users. Ik heb geen statistieken van het aantal topics over het complete forum, maar je kan je vast voorstellen dat zo'n tabelletje op dit forum nogal uit de klauwen kan lopen qua grootte. Nu is diskspace niet het probleem, dat zijn de lookup tijden, plus de writes daarop. Daarbij ben je voor elk topic in de lijst een extra join aan het doen.. uiteindelijk kost het gewoon veel performance.

Voor mijn userdata is al flink wat ruimte gereserveerd. O.a. de bookmarks die ik nu misbruik als pointer naar het laatst gelezen bericht. Iedere keer dat ik dit gebruikt, kost dat me twee klicks en twee pageloads extra: bookmark -> bookmark toevoegen. Zou je iets implementeren, dan hoef ik die twee kliks niet meer te doen. Scheelt performance. Nou zal lang niet iedereen dit zo doen, maar ook ik doe het liever niet.

Wel zou ergens moeten worden bijgehouden welke topics ik allemaal geopend heb. Op een of andere manier is hier een concensus dat dit een tabel moet zijn met de afmeting Usercount x topiccount. Dit hoeft natuurlijk echt niet. Je kan per user bijhouden welke topics ie opent en bij dat topic noteren wat op dat moment het laatst gedisplayde bericht was. Dit is nog steeds aardig wat data, maar alleen als alle users alle topics gaan lezen heb je zo'n gigantische tabel nodig. Mocht dit toch nog te groot worden, dan kun je nog altijd een expire toepassen. Sla dan het tijdstip van de expire op en beschouw in een topic dat je niet kan vinden, deze expiredatum als "eerste nieuwe bericht". Op deze manier hoef je maar een paar honderd of misschien wel duizend setjes getallen per user te onthouden. Hoeveel topics opent een gemiddelde user per jaar?

Verder hoef je die join pas te doen op het moment dat een topic geopend wordt. Ook dat lijkt me te verwaarlozen vergeleken met de hoeveelheid werk die er verzet moet worden om alle avatars, postingdata en taglines te verzamelen.

sudo bouw deze feature in ;-)

Er moet een record zijn met <userid> <topicid> <timestamp> om bij te houden wanneer iemand voor het laatst een topic gelezen heeft. Nu kan je zeggen dat alle topics met een lastpostdate van <registratie datum user> - 2 uur niet gecontroleerd hoeven worden, plus bij implementatie zo'n zelfde conditie (datum implementatie - 1 dag oid). Daar maak je je query al complexer (lees: trager) mee, want dan moeten er twee extra variabelen gecontroleerd worden. Het alternatief is voor alle users en alle topics alvast iets inserten: 1.5 miljoen topics x een half miljoen gebruikers: 750 miljard records.

Vervolgens is het geimplementeerd, en dan krijg je permanente "nieuwe berichten" statussen op alle topics die jij niet leest. Dus vanaf het punt van implementatie ga jij records in die tabel produceren bij elk topic wat je leest. Dan zijn het er niet vanaf dag een een belachelijk aantal, maar dat gaat rap omhoog.

Ik ga even wat getallen uit m'n duim zuigen als voorbeeld:
- Een record in zo'n tabel is "<userid> <topicid> <timestamp". 7 bytes voor het userid, 7 bytes voor het topicid, 10 bytes voor een timestamp. Laat het 30 bytes per record zijn.
- De wat actievere gebruikers zullen gemiddeld zo'n 10 nieuwe topics per dag openen, = 10 inserts.
- Daarnaast lezen ze per dag hun "favoriete"/"vaste" topics bij, laten dat er ook nog eens 25 topic keer 4 keer bijlezen zijn = 100 updates.
- Laten er 1000 actieve gebruikers zijn die dagelijks terugkomen: 10000 inserts plus 100000 updates op die tabel.

In een dagje zijn dat dus al 10k nieuwe records, met een grootte in bytes van 300000 bytes, dus ~293kB aan data. En dat voor maar 1000 gebruikers. Laten er eens zo'n 10000 gebruikers per dag online komen, ook wat minder actieve users, dan zit je wel gauw aan een megabyte per dag aan data, met zo'n 25k aan records. Zoals je ziet, dat loopt aardig rap op. Oh ja, die 750 miljard records in filesize? Veel. Heel, heel, heel veel. Slechts 20.5 terabyte. Saillant detail: de maximale table size van MySQL is (op Solaris) 16TB, op een standaard linux bak 4TB.

En dan heb ik het echt nog alleen gehad over de pure data. Met inserts en updates ga je al heel gauw overhead op die tabel krijgen. Die 1MB die ik noemde was een beetje gejokt. Feitelijk is de data in de tabel maar 113 kb. Door de overhead van vele write acties op die tabel was hij aangegroeid naar net boven de 1MB. Een optimize lost dat wel op hoor, maar stel je even voor dat dit hier gedaan wordt. Die tabel groeit zo snel uit z'n voegen dat zelfs de optimize dat niet bij kan houden.

Een oplossing voor de enorme hoeveelheid data kan een sliding window zijn: je gaat alleen de topics in de laatste X dagen controleren. Hoewel dat leuk werkt voor de actieve users, werkt dat niet voor de casual gebruiker die eens of twee keer per maand langskomt. Die optie valt dus vrij snel af.

Wat bedoel je toch met "je gaat topics controleren"? Er hoeft helemaal niet in alle topics voor alle users gekeken te worden. Ook is het nergens voor nodig om "nieuwe berichten" te vinden in topics die ik niet lees. Dat zijn dingen die jij/jullie er telkens bij halen om uit te leggen dat dit niet mogelijk is. Maar laat die gedachte nou eens los... Je hele berekening zal best wel kloppen, maar daarbij ga je uit van een design dat hier inderdaad niet geschikt voor is. Het kan namelijk volgens mij veel simpeler.

We hoeven niet een overzicht van alle topics waar nieuwe posts in zijn. We willen alleen maar alle bestaande overzichten uitbreiden met een "jump to first new post" button. Pas als daarop geklikt wordt, moet je in een tabel kijken vanaf welk bericht ik het topic wil zien. Dat kost 1 query extra, bovenop al die queries die gedaan moeten worden om alle berichten en avatars te verzamelen. Daarna moet er een insert of update gedaan worden. Was er geen pointer: insert er eentje. Was die er wel, update hem dan.

Er worden dus op twee momenten queries uitgevoerd: op het moment dat ik een topic open (is er een pointer, gebruik die dan) en op het moment dat een pagina klaar is met laden (insert een nieuwe pointer of update de pointer). Als alle users iedere minuut een topic openen en dat 24 uur volhouden, is dat 1440 records per user per dag. Maar hoeveel users zijn er per dag gemiddeld on-line en hoeveel (unieke) topics openen die? Dat zijn getallen die ik niet ken, maar als 10000 gebruikers gemiddeld 20 topics unieke topics per dag lezen dan heb je het over 200000 records per dag. Zou zo'n record 16 bytes groot zijn (3 x 32 bit + wat overhead) dan hebben we het over 3 MB per dag. Zou je die pointers na een jaar expiren, dan heb je ongeveer een gigabyte aan data nodig. Misschien zit ik er een grootte-orde naast en heb je 10GB nodig, maar zelfs dat moet toch wel ergens in te passen zijn? Het zal in ieder geval in het niet vallen bij de hoeveelheid data die de diverse topics aan plain text bevatten.

Je zou ook op aantal pointers kunnen expiren. Iedere keer dat je een nieuwe pointer toevoegt, gooi je de oudste weg als het er meer dan 1000 zijn. Dan heb je 16K data per user nodig voor deze feature. Hell, je zou dit in een binairy blob naast mijn avatar in de sessie kunnen proppen, dan heb je mijn hele ".newsrc" bij de hand, zonder dat je ingewikkelde tabellen hoeft te gaan ontwerpen.

Maar misschien praten we heel erg langs elkaar heen...

[ Voor 8% gewijzigd door TwOkkie op 25-01-2013 15:33 ]

TwOkkie schreef op vrijdag 25 januari 2013 @ 15:28:
Wat bedoel je toch met "je gaat topics controleren"? Er hoeft helemaal niet in alle topics voor alle users gekeken te worden. Ook is het nergens voor nodig om "nieuwe berichten" te vinden in topics die ik niet lees.

Leg eens uit hoe dit moet dan: de feature is ingebakken, en alle topics staan op ongelezen omdat je volgens die feature nog geen topic gelezen hebt. Je kan dan een "mark all topics as read" inbouwen, maar als je daarop klikt moet je ineens voor elk topic in de database een record inserten dat het forum vertelt dat je het topic gelezen hebt. Dat is even vrolijk anderhalf miljoen records in één keer. Dat kun je omdraaien door juist elk topic op te slaan dat je niet gelezen hebt, maar dat betekent weer dat je voor elk nieuw topic een record moet gaan opslaan voor elke bestaande user.

Je zit dus in de praktijk echt met een boel mutaties te kijken op zo'n tabel, en die tabel wordt zeker met zo'n "markeer als gelezen"-knop nog véél sneller dan MueR omschrijft absurd groot. De performance die je daarop verliest is gewoon de feature niet waard.

Ik vraag me af hoeveel gebruikers alle topics lezen, dat zullen er maar bijzonder weinig zijn. Daarnaast zou je prima voor een hybride oplossing kunnen gaan om het beheersbaar te houden.

Het exacte moment wordt enkel bij gehouden van topics die in de laatste 4 weken zijn bekeken. Indien deze periode is verstreken wordt de "topicid:userid:timestamp" regel gepruned.

De hoeveelheid updates op een dergelijke tabel is iets wat MySQL allicht niet heel tof zal gaan vinden, ik denk dat noSQL dan ook een beetje optie is voor dergelijke data.

Om te kijken of het uberhaupt haalbaar is zou je eerst eens moeten kijken hoeveel topics gebruiker daadwerkelijk bekijken in een periode van 4 weken om zo een voorzichtige schatting te kunnen maken van de grote van je dataset,

sPENKMAN schreef op vrijdag 25 januari 2013 @ 17:35:
Ik vraag me af hoeveel gebruikers alle topics lezen, dat zullen er maar bijzonder weinig zijn.

Dat zou voor zo'n "alles als gelezen markeren"-feature niet uitmaken. En die is zelfs met enkele duizenden topics (afgelopen vier weken zoals jij voorstelt) best nog spannend wat betreft de mutaties op die tabel terwijl er ook veel in gelezen moet kunnen worden.

NMe schreef op vrijdag 25 januari 2013 @ 17:48:
[...]

Dat zou voor zo'n "alles als gelezen markeren"-feature niet uitmaken. En die is zelfs met enkele duizenden topics (afgelopen vier weken zoals jij voorstelt) best nog spannend wat betreft de mutaties op die tabel terwijl er ook veel in gelezen moet kunnen worden.

Zou dat potentieel nog te heftig kunnen zijn voor bijvoorbeeld MongoDB? Wat ik toch begrijp is dat noSQL in een dergelijk geval verbazende resultaten weet neer te zetten.
Dat zullen jullie zelf allicht beter weten trouwens daar jullie er volgens mij al gebruik van maken


Ik moet eerlijk bekennen dat ik wel heel nieuwsgierig wordt naar daadwerkelijke getallen waar het om zou gaan. Kan je dit allicht ergens uit een database kunnen trekken (allicht tracking van gebruikers binnen het forum als dat actief is) of is dat niet heel makkelijk te bewerkstellingen? Ik zou bijvoorbeeld denken aan;
- Uniek aantal bekeken topics in 4 weken (of een andere periode) - aantal actief bekeken topics
- Unieke records bekeken topic/user in <timeframe> met aantal revisits van de gebruiker aan dat topic - de totale recordset met update aantallen
- Unieke topic/user records van de alle users de dag voor de 4 weken - het aantal records wat periodiek gepruned zal moeten worden

sPENKMAN schreef op vrijdag 25 januari 2013 @ 20:20:
[...]

Zou dat potentieel nog te heftig kunnen zijn voor bijvoorbeeld MongoDB? Wat ik toch begrijp is dat noSQL in een dergelijk geval verbazende resultaten weet neer te zetten.
Dat zullen jullie zelf allicht beter weten trouwens daar jullie er volgens mij al gebruik van maken

Ik heb geen idee, ik dev niet voor Tweakers. Maar zelfs als het performancetechnisch nog te doen is, is de explosieve groei van die tabel niet te overzien. 20TB aan data voor zoiets kleins klinkt niet echt als zinnige besteding van je schijfruimte.

sPENKMAN schreef op vrijdag 25 januari 2013 @ 20:20:
[...]


Zou dat potentieel nog te heftig kunnen zijn voor bijvoorbeeld MongoDB? Wat ik toch begrijp is dat noSQL in een dergelijk geval verbazende resultaten weet neer te zetten.
Dat zullen jullie zelf allicht beter weten trouwens daar jullie er volgens mij al gebruik van maken

Wij zijn de laatste tijd juist steeds minder tevreden over de performance en schaalbaarheid van MongoDB

NMe schreef op vrijdag 25 januari 2013 @ 20:40:
[...]

Ik heb geen idee, ik dev niet voor Tweakers. Maar zelfs als het performancetechnisch nog te doen is, is de explosieve groei van die tabel niet te overzien. 20TB aan data voor zoiets kleins klinkt niet echt als zinnige besteding van je schijfruimte.

Ik denk dat je qua grootte een beetje overdrijft. Het somethingawful forum is een hevig gemodde versie van vBulletin, heeft een factor meer leden dan GoT, er wordt een factor meer gepost wordt dan hier en heeft deze functionaliteit ook en draait ook behoorlijk soepel.

bakakaizoku schreef op vrijdag 25 januari 2013 @ 20:50:
[...]


Ik denk dat je qua grootte een beetje overdrijft. Het somethingawful forum is een hevig gemodde versie van vBulletin, heeft een factor meer leden dan GoT, er wordt een factor meer gepost wordt dan hier en heeft deze functionaliteit ook en draait ook behoorlijk soepel.

Somethingawful:172,823 users total.
Tweakers: 400.000+ (kan exacte aantal niet vinden)

En wat als je nou kunt aangeven als gebruiker dat je dit voor max 5 topics zou willen ofzo?

Wat is daar precies het nut van en hoe zie je dat interfacetechnisch voor je?

Ik denk dat er best wel een performante oplossing voor dit probleem te verzinnen is waarbij je uiteindelijk niet meer hoeft op te slaan dan de topics die een gebruiker daadwerkelijk geopend heeft. Uiteindelijk zal dat qua opslag toch ook wel behoorlijk aantikken, zelfs met bepaalde limitaties, maar ook dat is niet iets waar ik me direct druk over maak.

Er zal ook nog wel een lastigheid in zitten om een dergelijke markering ook correct op forum-niveau te krijgen, en zo zullen er vast nog wel meer randzaken zijn die eerst goed uitgedacht moeten worden om iets dergelijks goed te implementeren, maar ik zeg niet op voorhand dat zoiets onmogelijk is of onverkomelijke performance-consequenties met zich meedraagt.

De vraag is echter: wat kost het om zoiets te bouwen, en wat is uiteindelijk de toegevoegde waarde boven het snelle simpele ruwe systeem wat we nu hanteren. Uiteindelijk kunnen we de tijd die we aan zoiets besteden niet besteden aan andere dingen, dus die afweging zullen we altijd moeten maken.

De grootste lastigheid bij het maken van die afweging op dit moment is het feit dat een ballpark inschatting van de tijd die het zou kosten erg lastig te geven is zonder eerst tijd te besteden om eea te onderzoeken en uit te denken.

Daarbij zie ik hier ook overlap met ideeën die we al hebben waarbij je je op specifieke topics kan 'abonneren' en er voor kan kiezen een notificatie te krijgen voor die topics als er nieuwe reacties zijn.

@Nme: De topics die je bijvoorbeeld gebookmarked hebt en dat je daar een popup van krijgt.
@crisp: Laatste gedeelte zou het voor mij al genoeg afdekken.

Ik zou het al voldoende vinden om een "spring naar laatste ongelezen bericht" optie te hebben voor de topics die ik gebookmarkt heb. Als je het alleen voor gebookmarkte topics doet hoef je lang niet zoveel data op te slaan lijkt me.

Het gaat mij eigenlijk alleen om de grote/actieve topics die ik dagelijks volg.

Het is gewoon zeer irritant om bij zulke topics zelf te moeten onthouden op welke pagina je gebleven was of naar het eind springen en dan terugscrollen op zoek naar je laatst gelezen bericht.

Als je overigens naar http://forum.xda-developers.com/ gaat en je kijkt rechts bovenin zie je dat ze zo'n 4,8 miljoen members hebben waarvan er rond de 50.000 online zijn. Dat lijken me toch ook flinke aantallen en zij hebben deze feature voor elk topic standaard aanstaan.

Falcon schreef op vrijdag 25 januari 2013 @ 22:13:
@Nme: De topics die je bijvoorbeeld gebookmarked hebt en dat je daar een popup van krijgt.

Dan praat je eerder over een postnotificatie voor specifieke topics en daar staat wel al iets voor op de (langetermijn-) agenda zoals crisp al zegt.

Mr Magic schreef op zaterdag 26 januari 2013 @ 11:26:
Ik zou het al voldoende vinden om een "spring naar laatste ongelezen bericht" optie te hebben voor de topics die ik gebookmarkt heb.

Als je bij elk bezoek alles leest dat je wil lezen kan dat. Als je op het icon vóór het topic klikt ga je naar het eerste nieuwe bericht sinds je laatste bezoek.

[ Voor 36% gewijzigd door NMe op 26-01-2013 13:02 ]

NMe schreef op vrijdag 25 januari 2013 @ 16:58:
[...]

Leg eens uit hoe dit moet dan: de feature is ingebakken, en alle topics staan op ongelezen omdat je volgens die feature nog geen topic gelezen hebt. Je kan dan een "mark all topics as read" inbouwen, maar als je daarop klikt moet je ineens voor elk topic in de database een record inserten dat het forum vertelt dat je het topic gelezen hebt. Dat is even vrolijk anderhalf miljoen records in één keer.

Dat is ook helemaal niet nodig. Daar kun je nog de huidige functionaliteit van de timestamp van het laatste bezoek voor gebruiken. Alleen laat je dit niet meer gelijk zijn aan het laatste bezoek maar aan het oudste record in je tabel met pointers of gebruik daarvoor een speciaal wildcard-pointer. Alles ouder dan dat is gelezen. Hoef je alleen nog maar te kiezen of- en hoe je die tabel expired.

Je zit dus in de praktijk echt met een boel mutaties te kijken op zo'n tabel, en die tabel wordt zeker met zo'n "markeer als gelezen"-knop nog véél sneller dan MueR omschrijft absurd groot. De performance die je daarop verliest is gewoon de feature niet waard.

Of je laat die tunnelvisie los en kijkt waar we echt behoefte aan hebben. Dat jullie allang besloten hebben dat het niet zou kunnen, is me duidelijk. Toch is het een feature die ieder ander systeem wel biedt, en daar zijn ook echt wel hele grote jongens bij. Eigenelijk had ik wel wat meer creativiteit verwacht van devvers van notabene tweakers.net!

NMe schreef op vrijdag 25 januari 2013 @ 17:48:
Dat zou voor zo'n "alles als gelezen markeren"-feature niet uitmaken. En die is zelfs met enkele duizenden topics (afgelopen vier weken zoals jij voorstelt) best nog spannend wat betreft de mutaties op die tabel terwijl er ook veel in gelezen moet kunnen worden.

Je blijft uitgaan van het idee dat je een matrix van X topics bij Y gebruikers nodig hebt, waar ik juist tot twee keer toe een alternatief voorstel.

NMe schreef op vrijdag 25 januari 2013 @ 20:40:
Ik heb geen idee, ik dev niet voor Tweakers. Maar zelfs als het performancetechnisch nog te doen is, is de explosieve groei van die tabel niet te overzien. 20TB aan data voor zoiets kleins klinkt niet echt als zinnige besteding van je schijfruimte.

Nog steeds blijf je uitgaan van dit - inderdaad onbruikbare - ontwerp.

NMe schreef op zaterdag 26 januari 2013 @ 13:00:
Als je bij elk bezoek alles leest dat je wil lezen kan dat. Als je op het icon vóór het topic klikt ga je naar het eerste nieuwe bericht sinds je laatste bezoek.

En als ik niet bij elk bezoek alles wil lezen, maar het wil laten afhangen van hoeveel tijd ik heb en waar ik op dat moment in geinteresseerd ben? Ik gebruik daar nu bookmarks voor, maar blijf dat een irritante work-around vinden.

TwOkkie schreef op zaterdag 26 januari 2013 @ 17:41:
[...]


En als ik niet bij elk bezoek alles wil lezen, maar het wil laten afhangen van hoeveel tijd ik heb en waar ik op dat moment in geinteresseerd ben? Ik gebruik daar nu bookmarks voor, maar blijf dat een irritante work-around vinden.

Daarbij komt nog dat het forum voor mij bepaalt hoe lang een sessie duurt. Als ik mijn browser open laat staan op de GoT-pagina en ik ben een paar uur "idle" wordt dat als nieuwe sessie gezien en zijn alsnog alle pointers gereset.

Het zou handig zijn als ik zelf kon bepalen hoe lang het duurt voordat een sessie eindigt.

TwOkkie schreef op zaterdag 26 januari 2013 @ 17:41:
Eigenelijk had ik wel wat meer creativiteit verwacht van devvers van notabene tweakers.net!
[...]
Nog steeds blijf je uitgaan van dit - inderdaad onbruikbare - ontwerp.

De eerste regel zeg je nog dat NMe en ik devvers bij Tweakers zijn, hier reageer je notabene op een post waarin NMe keihard en ondubbelzinnig zegt dat hij niet bij Tweakers devt. NMe en ik zijn devvers, maar niet bij Tweakers. Dus als wij het stomweg niet eens zijn met een idee (dat kan voorkomen, wij hebben ook een mening, go figure), is dat niet meteen de eindconclusie van de devvers van Tweakers. Je kan ofwel met ons persoonlijk in discussie gaan waarom wij het wel met deze feature eens zouden moeten zijn, of dat niet doen en je alleen richten op de mensen met de titel "Devver" zoals crisp, maar ga ons niet beschuldigen van meningen de grond in boren en weigeren ze te ontwikkelen. You can't have your cake and eat it too.

Sorry als ik tegen de verkeerden aan schop, maar het verhaal wat NMe hier neerlegt en wat jij nog eens met cijfers onderbouwd is wel het verhaal dat ik keer op keer voorbij zie komen als deze ontbrekende maar zeer wenselijke feature weer eens ter sprake komt. Ik schop ook niet tegen NMe of jou aan, maar wel tegen het verhaal en de conclusie (vanuit tweakers gecommuniceerd?) dat het onmogelijk is om dit redelijkerwijs te implementeren.

Kort gezegd biedt ik een alternatief design aan, maar dat wordt met een simpel argument van tafel geveegd, waarna er nog een paar keer wordt gehamerd op de onwerkbaarheid van het verkeerde design.

Goed, jij en NMe zijn geen devvers van tweakers, maar jullie vertalen wel de mening van de devvers van tweakers. Of vergis ik me zelfs daarin?

Zoals ik al eerder zei:

TwOkkie schreef op vrijdag 25 januari 2013 @ 15:28:
Maar misschien praten we heel erg langs elkaar heen...

TwOkkie schreef op zondag 27 januari 2013 @ 13:48:
Goed, jij en NMe zijn geen devvers van tweakers, maar jullie vertalen wel de mening van de devvers van tweakers. Of vergis ik me zelfs daarin?

Ja, zelfs daar vergis jij je in.

Hoor ik daar een feature ...

Is er wel iets te zeggen over op welke plek deze feature eventueel staat in de Tweakers planning (eerst impact analyse natuurlijk)?

MueR schreef op zondag 27 januari 2013 @ 14:05:
Ja, zelfs daar vergis jij je in.

Goed, dan sta ik gecorrigeerd. Maar al zolang als ik hier op het forum kom en geklaag zie over het ontbreken van deze feature, zie ik de uitleg dat het onmogelijk is om voor X users en Y topics een tabel van X*Y bij te houden. Hier ook weer ondebouwd met berekeningen over hoe groot dat wel niet zou worden. Ik begon daardoor de indruk te krijgen dat dit is de consensus is onder tweakers.net en z'n devvers.

Nou hoop ik maar dat de echte devvers meelezen.. ;-)

NMe schreef op zondag 27 januari 2013 @ 14:41:

offtopic:
En dit is nou waarom ik dolgraag af en toe mijn kleurtje uit zou kunnen zetten.

De verwarring ontstond niet door je subtitel maar door de manier waarop je uit ging leggen waarom het nooit zou kunnen werken. Ik kreeg daardoor de indruk dat je er iets mee te maken had.

[ Voor 24% gewijzigd door TwOkkie op 28-01-2013 10:56 ]

Mr Magic schreef op zaterdag 26 januari 2013 @ 11:26:
Ik zou het al voldoende vinden om een "spring naar laatste ongelezen bericht" optie te hebben voor de topics die ik gebookmarkt heb. Als je het alleen voor gebookmarkte topics doet hoef je lang niet zoveel data op te slaan lijkt me.

Je kunt toch ook een post bookmarken? Dat heeft precies dit effect. (Ok, werkt niet in alle browsers zoals Internet Explorer op Windows Phone devices, maar dat is een browserprobleem)

TwOkkie schreef op maandag 28 januari 2013 @ 10:53:
Nou hoop ik maar dat de echte devvers meelezen.. ;-)

DrivinUCrazy schreef op maandag 28 januari 2013 @ 10:59:
[...]

Je kunt toch ook een post bookmarken? Dat heeft precies dit effect. (Ok, werkt niet in alle browsers zoals Internet Explorer op Windows Phone devices, maar dat is een browserprobleem)

Nee, want er wordt niet onthouden welke post binnen een thread je als laatste gelezen hebt.

Als je niet al je gebookmarkte topics leest binnen één sessie en je komt de volgende keer terug worden alle tussenliggende posts niet meer als nieuw gezien (correct me if I'm wrong).

Mr Magic schreef op maandag 28 januari 2013 @ 19:36:
[...]

Nee, want er wordt niet onthouden welke post binnen een thread je als laatste gelezen hebt.

Wat DrivingUCrazy bedoelt is dat je ook een post (dus niet een topic maar een individueel bericht) kunt bookmarken en vervolgens vanaf daar verder lezen. Alleen of dat nou zo praktisch is...want dan moet je van elk topic dat je op die manier bijhoudt steeds als je klaar bent een nieuwe bookmark maken en de oude weggooien.

NMe schreef op maandag 28 januari 2013 @ 19:46:
[...]

Wat DrivingUCrazy bedoelt is dat je ook een post (dus niet een topic maar een individueel bericht) kunt bookmarken en vervolgens vanaf daar verder lezen. Alleen of dat nou zo praktisch is...want dan moet je van elk topic dat je op die manier bijhoudt steeds als je klaar bent een nieuwe bookmark maken en de oude weggooien.

Wat je dus eigenlijk zegt is dat je met een 'Automatically bookmark last post on visit and delete old bookmark for this topic' functie dezelfde functionaliteit kunt bereiken. Dit lijkt me niet een ingreep waar veel onderzoek aan vooraf hoeft te gaan. Sowieso is de functie alleen handig voor bepaalde topics die je volgt en dus logischerwijs in je bookmarks horen.

Kun je dit niet eenvoudig buiten Tweakers om ontwikkelen?

Een js-bookmarklet in combinatie met kort scriptje serverside op een externe server programmeren, kost niet zoveel tijd. Als het aanslaat implementeert Tweakers het later wel.

Je hebt hele topic gelezen:
Je klikt op de js-bookmarklet, server ziet de refer, checkt de laatste post.

Je bent halverwege gestopt met lezen:
Klik op het (datum link) bericht dat je als laatst hebt gelezen, je klikt op de js-bookmarklet, server ziet de refer.

Daarna kom je weer in het topic, je klikt op diezelfde js-bookmarklet, en hij brengt je naar de post waar je gebleven was. Kost je wel een extra klik en kost Tweakers een nutteloze pageview.
(voorlopige beperking is wel alleen publieke fora)

[ Voor 18% gewijzigd door Startups op 28-01-2013 21:01 ]

NMe schreef op maandag 28 januari 2013 @ 19:46:
[...]

Wat DrivingUCrazy bedoelt is dat je ook een post (dus niet een topic maar een individueel bericht) kunt bookmarken en vervolgens vanaf daar verder lezen. Alleen of dat nou zo praktisch is...want dan moet je van elk topic dat je op die manier bijhoudt steeds als je klaar bent een nieuwe bookmark maken en de oude weggooien.

Dat bedoelde ik inderdaad, maar wel met de kanttekening dat je de oude bookmark niet hoeft weg te gooien: die wordt automatisch overschreven.
Je klikt dus rechtsboven bij de post waar je bent gebleven (hoeft niet de laatste post te zijn) op "bookmark", en in het volgende scherm klik je weer op bookmark. Klaar.
2e voordeel: in de omschrijving van de bookmark staat ook automatisch de poster van de post waar je bent gebleven. Mocht je sessie dus gereset zijn, zonder dat je dat topic hebt bijgelezen, kun je over je bookmark hoveren. Dan zie je of de naam van de laatste poster overeenkomt met je bookmark.

Ik doe al jaren niets anders, werkt prima. Wat mij betreft mag dat tussenscherm er wel uit; ik heb persoonlijk nooit de behoefte om de omschrijving van de bookmark aan te passen. Maar dat is dan ook het enige dat ik er op aan te merken heb.

AlainS schreef op maandag 28 januari 2013 @ 20:29:
[...]


Wat je dus eigenlijk zegt is dat je met een 'Automatically bookmark last post on visit and delete old bookmark for this topic' functie dezelfde functionaliteit kunt bereiken. Dit lijkt me niet een ingreep waar veel onderzoek aan vooraf hoeft te gaan. Sowieso is de functie alleen handig voor bepaalde topics die je volgt en dus logischerwijs in je bookmarks horen.

Sommige topics gaan harder dan ik kan bijlezen, zeker bij een paar dagen afwezigheid. (Eigen ervaring met het motortopic in de zomer) Andere topics wil ik maar één keer bookmarken, bijvoorbeeld om te kijken of er nog reacties op mijn post komen.
En het "delete old bookmark for this topic" is er al, dus daar hoeft niets voor toegevoegd te worden.

Imho zijn we er al als we het tussenscherm "Topic toevoegen aan bookmarks" overslaan. Zo heb je een supersnelle manier om een bookmark aan te maken. Er zijn ook vast mensen die hun bookmarks compleet in mappen indelen. Om deze mensen tegemoet te komen misschien nog een optie in de voorkeuren maken zodat dit mogelijk blijft, maar dat was het dan ook wel. Maar dit is puur een voorstel om een bestaande functionaliteit nog wat meer te stroomlijnen, meer niet.

[ Voor 33% gewijzigd door DrivinUCrazy op 28-01-2013 21:25 ]

DrivinUCrazy schreef op maandag 28 januari 2013 @ 21:19:
[...]
Sommige topics gaan harder dan ik kan bijlezen, zeker bij een paar dagen afwezigheid. (Eigen ervaring met het motortopic in de zomer) Andere topics wil ik maar één keer bookmarken, bijvoorbeeld om te kijken of er nog reacties op mijn post komen.

Dat kan toch ook? Als je een vinkje bij een enkele bookmark zet wordt de bookmark automatisch geupdatet naar de nieuwste post. Zonder vinkje niet, dus je kunt ook losse bookmarks aanmaken ...

Sorry, ik volg je even niet. Over welk vinkje heb je het nou precies?

Ik denk dat je mijn "één keer bookmarken" niet goed begrijpt. Ik bedoel niet dat ik maar één bookmark uit dat topic in mijn bookmarklijst wil hebben. Ik bedoel dat ik een reactie plaats, en mijn eigen post dan bookmark. Zo kan ik later nog eens direct naar mijn post terug springen om te kijken of daar mensen op hebben gereageerd. Zo niet; bookmark verwijderen en het topic weg laten zakken.

Denk bijvoorbeeld aan het kleine mededelingen topic, dat erg hard gaat. Maar, als ik daar iets zou posten, dan kan het zijn dat mensen daar op reageren met suggesties of vragen. Dát wil ik dan zien, in plaats van alleen maar even een reactie te dumpen en vervolgens volstrekt negeren.

Het vinkje "verwijder deze bookmark nadat ik erin gereageerd heb" is imho overbodig. Zodoende mag van mij dat tussenscherm ook overgeslagen worden, wat ik hierboven al zei.

Eens dat het "tussenscherm" bij de bookmarks verwijderen of het automatisch updaten van de bookmarks al een hoop zou schelen. Een korte dialog, eventueel met vinkje "niet meer tonen" zou wat mij betreft al heel prettig zijn. Soms is het handmatig bookmarken ook wel prettig. Bij topics met erg lange postings vind ik het juist ook wel eens erg handig dat ik halverwege de bookmark kan zetten als ik een TL;DR momentje heb. Dan kan ik het op dat punt later weer oppakken.

Maar ik denk dat de bookmarks zijn zoals ze nu zijn, bedoeld zijn om belangrijke berichten weer terug te vinden. Bijvoorbeeld, je leest iets wat je wil uitzoeken om later op terug te komen. Een dag later heb je het uitgezocht, je plaatst je bevindingen en de bookmark mag vanaf dat moment weer weg. In dat kader kan ik me ook voorstellen dat je een andere naam wil opgeven en hem wil opslaan in het foldertje "Uitzoeken". Op zich een hele nuttige feature, maar ik vraag me af hoe vaak het op die manier gebruikt wordt en hoe vaak ter compensatie van het ontbreken van een fatsoenlijke (sorry! ) last-read-pointer.

[ Voor 3% gewijzigd door TwOkkie op 29-01-2013 10:36 ]

AlainS schreef op maandag 28 januari 2013 @ 20:29:
[...]

Wat je dus eigenlijk zegt is dat je met een 'Automatically bookmark last post on visit and delete old bookmark for this topic' functie dezelfde functionaliteit kunt bereiken. Dit lijkt me niet een ingreep waar veel onderzoek aan vooraf hoeft te gaan. Sowieso is de functie alleen handig voor bepaalde topics die je volgt en dus logischerwijs in je bookmarks horen.

Als er dan toch aan een oplossing voor dit probleem gedevd moet worden, dan zou ik die tijd stoppen in een echte oplossing en niet in een workaround.

NMe schreef op dinsdag 29 januari 2013 @ 10:38:
[...]

Als er dan toch aan een oplossing voor dit probleem gedevd moet worden, dan zou ik die tijd stoppen in een echte oplossing en niet in een workaround.

Toch is "de oplossing" niet veel meer dan "bookmarks on steroids".

LastReadPointers extends Bookmarks. Of netter: beide een subclass van MessagePointers.