Wikipedia:De kroeg/Beheersing diskruimte

Eventuele andere voor- en nadelen hier toevoegen. Verdere discussie a.u.b. op de overlegpagina.

De Kroeg is qua benodigde diskruimte veruit de "duurste" pagina van nl.wikipedia. Omdat alles (aantal artikelen, aantal gebruikers, etc.) exponentieel groeit (vuistregel voor nl: verdubbeling elke 9 maanden), wordt het tijd daar iets aan te doen.

Het huidige systeem

Voor- en nadelen

Voordelen

• Bekend systeem
• In principe een centrale discussie voor alles
• Gemakkelijk terug te vinden via de volglijst

Nadelen

• Neemt gigantisch veel plaats in op de harde schijf.
• Grote lap tekst. Afhankelijk van de drukte op de pagina, ontsnapt een onderwerp al vrij snel aan de aandacht.
• Oneigenlijk gebruik: onderwerpen die niks met de wiki te maken hebben, of slechts zijdelings.
• Door de nadelen zijn er al afsplitsingen, zodat veel discussies aan de gemiddelde gebruiker voorbij gaan.
• Het terugvinden van discussies uit het verleden, is moeilijk.
• Door archivering van oude onderwerpen, wordt de inhoud (gaat naar het archief) van de geschiedenis (blijft onderdeel van de De Kroeg) gescheiden.

Enkele getallen

Sinds 25 april 2006 tot heden (18 augustus 2006) hebben er 10.000 bewerkingen op de Kroeg pagina plaatsgevonden. Dat omvat dus een periode van 3,75 maanden, waarin ook nog eens een relatief rustige vakantieperiode in viel. Daarom wordt verder gerekend met 3 maanden.

De ervaring leert dat ergens bij een bestandgrootte van 300-350 kB wel iemand gaat archiveren. Diezelfde ervaring leert dat na archivering er ca. 150 kB overblijft. De gemiddelde grootte van het bestand kan dus (wederom afgerond) op tenminste 200 kB gesteld worden.

In die 3 maanden dus een verhoging van de opslagcapaciteit met tenminste 2 GB.

N.B. Deze berekening komt qua ordegrootte overeen met de uitgebreide statistieken, zie: [1], volgens welke De Kroeg, incl het 2003-2005 archief, per eind juli 2006 een kleine 8 GB in beslag neemt, per eind april 2007 neemt het 11.4 GB in beslag.

Volgens de gegevens van de database dumps bedraagt de totale (ongecomprimeerde, current zowel als old) opslagruimte, die nl:wikipedia in beslag neemt, ergens tussen de 40 en 45 GB. De Kroeg neemt daarvan dus iets van 20% voor zijn rekening.

Bij voortzetting van de huidige werkwijze zal de behoefte aan opslagcapaciteit eveneens exponentieel toenemen. Immers het aantal gebruikers dat aan de Kroeg discussies deelneeemt zal exponentieel toenemen, maar ook de gemiddelde bestandgroote zal dat doen. Tenminste als het archiveringsritme, bepaald door de "ouderdom" van de discussie per onderwerp, ongewijzigd blijft. Het eindresultaat is dat over 9 maanden de 3 maandelijkse groei van de opslagcapaciteit niet verdubbeld, maar verviervoudigd zal zijn.

Gerelateerde zaken

Bewerkingsconflicten

Een andere structuur van De Kroeg zal weinig tot niets verbeteren aan het optreden van bewerkingsconflicten. Deze ontstaan meestal in verhitte discussies over een bepaald onderwerp. Dan zijn meerdere gebruikers tegelijk met hetzelfde stukje tekst (onder hetzelfde (sub)kopje) bezig en bwc's zijn dan onvermijdelijk.

Een structuur waarbij de hele Kroeg in subpagina's wordt opgedeeld, zal alleen het aantal bwc's verminderen, indien een gebruiker de gehele tekst van de Kroeg aan het bewerken is. Dat gebeurt waarschijnlijk alleen bij een archivering, die om die reden dan ook vaak in de "stille uurtjes" wordt uitgevoerd.

Archivering

Archivering technisch

Technisch gesproken zijn er, in het geval van geen subpagina's, drie methoden van archivering:

• M.b.v. een permalink (en simpele verwijdering van een stuk van de inhoud).
• Door het overhevelen van een stuk tekst naar een nieuw archiefbestand.
• Door hernoeming van de pagina en door daarna de ontstane redir te gebruiken als schone lei.

Kenmerken permalink archivering

• Is technisch de meest elegante (geen extra pagina met bijbehorende opslagcapaciteit nodig).
• Geschiedenis en inhoud blijven gekoppeld, hoewel er eerst wel in de geschiedenis gescrolled zal moeten worden.
• Gearchiveerde/verwijderde tekst blijft opzoekbaar met b.v. Google, althans als die tekst er enige tijd heeft gestaan. Bekijken van de live url heeft echter geen zin (immers de tekst is verwijderd). De cached link geeft wel de juiste (oude) versie.
• Bij een permalinkarchivering is niet te zien of de discussie over een bepaald onderwerp klaar was itt de klassieke archivering per onderwerp.

NB. Gezien de frequentie van wijzigen, mag men aannemen dat een of meerdere Googlebots e.a. permanent met wikipedia bezig zijn. Er is echter geen garantie hoe snel ze op een zojuist gewijzigde pagina terugkomen.

Kenmerken archivering via nieuw bestand (huidge Kroeg methode)

• Geschiedenis en inhoud worden losgekoppeld.
• De archiefpagina wordt op enig moment altijd wel geindexeerd door Google. De tekst op Kroegpagina zelf was dat al, dus in principe geeft dat twee resultaten op een verder unieke zoekterm.

Kenmerken hernoemingsmethode

• Geschiedenis en inhoud blijven gekoppeld.
• Is alleen toepasbaar bij de "schone lei" methode.

Bij het werken met subpagina's (zoals bij de verwijderlijst) is technisch gesproken geen archiveringsactie noodzakelijk. Geschiedenis en inhoud blijven gekoppeld en met een zoekactie via Google kom je gelijk op de juiste subpagina.

Archivering functioneel

Functioneel gesproken vindt een archiveringsactie van de Kroeg plaats volgens een van de volgende varianten:

• Alle onderwerpen die voor datum x gestart zijn worden gearchiveerd. Kleine nuances zijn mogelijk in die zin dat datum x afhankelijk gemaakt wordt van het al dan "getroffen" worden van een hot item door deze archiveringsactie. Deze methode wordt waarschijnlijk het meeste toegepast, mede omdat dit het minste werk is. Er zijn voorzover bekend (bijna) nooit bezwaren hiertegen gerezen.
• Alle onderwerpen waaraan sinds datum x niets meer aan toegevoegd is, worden gearchiveerd. Dit is beduidend meer werk, wordt soms gedaan en leidt toch meestal tot een nog relatief grote omvang van het overgebleven bestand.

In het geval van subpagina's omvat de archivering niet veel meer dan het "verhuizen" van subpagina's, in analogie met de verwijderlijst na een verwijdersessie. Langere tijd niet archiveren heeft in dit geval geen consequentie voor het disk gebruik. De pagina op het scherm wordt alleen langer.

Zoeken (op oude onderwerpen)

Dit is een vrij moeizaam proces. Begint met herinneren wanneer het ongeveer geweest is en achtereenvolgens de TOC's van de archiefbestanden van ongeveer die datum bekijken. Een Google search zou misschien praktischer zijn, maar die moet dan wel "aangekleed" worden, anders blijft het bomen en bos probleem bestaan.

Alleen de hierna genoemde methode "Opknippen naar onderwerp" zal hier iets aan kunnen verbeteren (met een prefindex zoeken), maar omdat er dan geen datuminformatie meer beschikbaar is en het aantal onderwerpen op den duur steeds groter zal worden, is de vraag of dit op termijn wel een echte verbetering is (misschien krijg je dan wel onderwerpen als !Vraagje of _Vraagje).

De oplossing

De oplossing moet gezocht worden in het "opknippen", in ieder geval technisch, van De Kroeg. Bij de verwijderlijst is in februari 2006 hetzelfde gedaan. Daarbij is toen, vanwege het duidelijke tijdaspect van de verwijderlijst, gekozen voor een opknippen per dag. Voor De Kroeg zijn er echter alternatieven denkbaar, die hieronder uiteengezet worden.

N.B. In het navolgende is de uiteindelijke bestandgrootte, die van de servers naar de client overgepompt moet worden, niet als primaire factor in de beschouwing meegenomen. Hoewel dit natuurlijk ook een kostenpost (bandbreedte) betekent, is deze verwaarloosbaar klein t.o.v. de totale bandbreedte die voor (nl.)wikip(m)edia benodigd is. Ook aan de client-side is de uiteindelijk paginagroote voor het merendeel van de Kroegbezoekers w.s. geen punt (gezien de penetratie van breedband in de meeste westerse landen).

Opknippen naar onderwerp

Voordelen

• Levert de grootste besparing op.
• Mogelijkheid om een onderwerp op je volglijst te zetten.
• Geen andere archivering nodig dan de hoofdpagina af en toe op te schonen. De subpagina's vormen vanzelf het archief.
• Discussies die al meerdere keren gevoerd zijn, kunnen mits de naamgeving goed was, snel weer teruggevonden worden.

Nadelen

• Er is een solide (werkend met alle browsers, skins, enz.) script nodig om een nieuw onderwerp toe te voegen.
• Mogelijke doublures in naamgeving met onvoorspelbare gevolgen, m.n. bij eenvoudige onderwerptitels als "Vraagje".
• Een nieuw onderwerp dat op een van de klassieke wijzen geopend wordt, door aan het einde van het laatste onderwerp met een nieuw kopje te beginnen, raakt quasi voor eeuwig zoek. Reparatie is een ingewikkelde zaak.

Opknippen naar aard van het onderwerp

E.e.a. in analogie met het en: model.

Voordelen

• Overzichtelijker voor diegenen die slechts in bepaalde soorten onderwerpen geinteresseerd zijn.
• Een totaal Kroeg is simpel te maken, maar de volgorde is dan per soort en daarbinnen op tijd van aanmaken van het onderwerp.
• Zinvolle volglijsten mogelijk.
• Kan een aantal van de alternatieve cafe's die inmiddels als paddestoelen uit de grond schieten in zich verenigen.

Nadelen

• Vraagt van de starter van een nieuw onderwerp dat deze van tevoren moet nadenken over de plaats waar het past. Met risico dat er veel in Diversen o.i.d. terecht komt.
• Archivering is per soort nodig.
• Een verkeerd geplaatst onderwerp ontsnapt misschien aan de aandacht van een andere geinteresseerde.

Opknippen naar tijd

Voordelen

• Bekend proces van de (artikel)verwijderlijst.
• Tijdseenheid kan flexibel zijn. Kan een week zijn, maar ook een dag, of zelfs een deel van een dag. Dus toekomstvast.
• Het "aangezicht" (daarmee niet bedoeld het plaatje, enz) van De Kroeg verandert niet.
• Semi-automatische archivering. Mogelijkheid om link naar oudere subpagina een tijdje vast te houden (net als bij verwijderlijst). Dus ook voor iemand die terug komt van vakantie eenvoudig te raadplegen.
• Bestand tegen oude (ingeroeste) werkwijzen. In het ergste geval komt een onderwerp gestart op dag 0 terecht op dag -1.

Nadelen

• Vraagt het aanmaken van een nieuwe periode, in analogie met de "nieuwe dag" bewerking op de verwijderlijst. Dit is overigens, ook zonder javascript, verder te automatiseren.
• Na opslaan van een toevoeging op een onderwerp, verschijnt de subpagina waarin gewerkt is. Net als bij de verwijderpagina kan bovenaan op eenvoudige wijze een linkje naar de totale pagina gezet worden. Als de subpagina groot is kan dat wat scrollen vragen. Dit is te verhelpen door de naviagatie ook onderaan de pagina te zetten (met een absolute positioned div, anders raakt die kwijt).

Conclusies

...