Serververhuizing, DB-versimpeling en feedbackfixes - Development-iteratie #332

De afgelopen sprints zijn we bezig geweest met meerdere verbeteringen waarin we jullie graag willen meenemen. Daarnaast doen we ook een poging om een klein stukje vooruit te kijken door met jullie te delen wat eraan zit te komen. We doen dit omdat we naar aanleiding van ons vorige .plan concludeerden dat we eerder hadden moeten communiceren over de wijzigingen die daarin stonden.

Verhuizing van de servers

In een video van ongeveer een jaar geleden hebben wij jullie laten zien hoe we Tweakers hosten. Deze video begint buiten een datacenter en neemt jullie mee naar onze servers in dat datacenter.

Helaas kregen wij in de herfst te horen dat dit datacenter op relatief korte termijn gaat sluiten. Omdat het hele gebouw leeg moet, hebben wij geen andere keuze dan ook onze servers daar weg te halen en ergens anders onder te brengen.

Hier komt nog bij dat onze hoster, die ons de afgelopen 24 jaar heeft gesponsord, in de loop der tijd zijn focus heeft verlegd en dat nu de tijd is gekomen om deze sponsorovereenkomst op te zeggen. Onze dank gaat uit naar TrueFullStaq voor de afgelopen 24 jaar, maar helaas gaan onze wegen scheiden. Wat we met onze hosting gaan doen, zullen we binnenkort in een ander artikel vertellen.

Voorbereidende werkzaamheden

Om deze verhuizing voor te bereiden, hebben wij een project naar voren gehaald om onze databaseset-up te vereenvoudigen. Op dit moment gebruiken wij nog twee verschillende databases om verschillende soorten gegevens in op te slaan: MySQL en MongoDB. Omdat één database makkelijker te onderhouden is dan twee, zijn wij begonnen met het uitfaseren van MongoDB. De redenen waarom wij MongoDB ooit zijn gaan gebruiken, zijn tegenwoordig niet meer van toepassing. Dan is het eenvoudiger om alles weer in één database onder te brengen.

De afgelopen weken hebben wij diverse zaken met betrekking tot notificaties en sessies uit MongoDB gehaald en omgezet naar MySQL. Dankzij deze werkzaamheden is de verhuizing van de servers een klein beetje eenvoudiger geworden.

Verbeteringen naar aanleiding van feedback op de slide-ins

Bij het vorige .plan openden we een feedbacktopic en naar aanleiding daarvan hebben we verbeteringen gedaan. We kregen vooral veel feedback van de actieve grootgebruikers van de Pricewatch, die het na de aanpassingen een aantal extra kliks kostte om hun doel op de pagina te bereiken.

Je kunt nu rechtstreeks vanaf boven in de productpagina de specificaties en gebruikersreviews openen door te klikken op de links vlak onder de prijs (zie screenshot hieronder). De verkorte specificaties en reviewscore daar zijn nu aanklikbaar.

Vlak onder een prijs kun je nu direct doorklikken naar de specificaties en gebruikersreviews.

Ook onthouden we je keuze voor 'Alles openen' binnen de Specificaties-slide-in, zodat bij elk product daarna altijd de specificaties direct openstaan (zie screenshot hieronder). Verder zorgt de Terug-knop van je browser er in de slide-in nu voor dat deze zich direct sluit, ook nadat je door meerdere tabs in de slide-in hebt genavigeerd. Daarnaast hebben we nog zeker een tiental andere, kleinere dingen veranderd, van de snelheid van bepaalde animaties tot het toevoegen van 'gereserveerd' in de V&A-slide-in.

De keuze voor 'Alles openen' in de Specificaties-slide-in wordt nu onthouden.

Analytics

We maken intern gebruik van tooling om bezoekersgedrag te tracken en analyseren. Mede op basis daarvan bepalen we de richting voor de website. Deze tracking signaleert onder andere waar bezoekers vastlopen, maar ook of onze verbeteringen dan ook echt geholpen hebben.

Deze trackingtooling gaat veranderen en hiervoor moeten wij met development werk verzetten. Dit is alleen een wijziging aan de achterkant, waarvan je als gebruiker niets merkt. We noemen het hier toch omdat we hierdoor minder tijd hebben om features door te ontwikkelen voor jullie. Hierdoor duurt het bijvoorbeeld langer om de wysiwygeditor, die nu nog in bèta is op het forum, verder af te maken voor release voor iedereen.

Vooruitkijkend

We hebben onlangs aangekondigd dat we Tweakers de komende jaren toegankelijker willen maken voor nieuwe gebruikers. Dit zullen we in stapjes gaan doen, te beginnen met een wijziging aan de typografie, die we in maart als bètafeature zullen introduceren. In dit forumtopic zullen we jullie op de hoogte houden over de stappen die we zetten. Door daar linksboven op 'Topic volgen' te klikken krijg je automatisch een notificatie als we een nieuw bericht plaatsen.

Reacties (22)

[ZpAz]

Wat maakt het dat de eerdere redenen om voor mongo te kiezen niet meer van toepassing zijn? Was dat gewoon uiteindelijk niet de juiste keuze of zijn er daadwerkelijke technische veranderingen gekomen in de database-systemen zelf waardoor mysql de eerdere taken over kan nemen?

[Kees]

We zijn ooit mongo gaan gebruiken om gebruikerssessies in op te slaan. Waarbij we voor mongo kozen omdat het makkelijk was extra velden toe te voegen aan het document.

Ik noem maar iets; in je sessie slaan wij op welke stad je invult bij V&A (dat slaan we per sessie op, en niet op account nivo). Toen we dat in mysql netjes wilden doen betekende dat een extra column toevoegen met daarin de 'stad', of (zoals we stiekum toch al deden) een extra veld met 'text' en daarin php-serialized data.

Maar dat serialized opslaan heeft zo z'n nadelen; het grootste is nog wel dat zodra er classes instaan, je problemen krijgt als je oude data wil lezen met nieuwe code waarin die class is aangepast.

Dus hebben we voor mongo gekozen (ook omdat nosql hip was) zodat we het gewoon in json konden gieten en eenvoudig uitlezen. Daarbij was de performance van mongo op dit soort specifieke data ook veel beter waardoor de site sneller was.

Maar tegenwoordig is het ook eenvoudig om gewoon json in mysql te gooien. Voeg daaraan toe dat de performance tegenwoordig prima is en dat 1 database makkelijker te monitoren is dan 2 verschillende types databases en de keuze was gemaakt.

Daarnaast liepen we tegen wat problemen aan in Mongo waarbij die vervelend deed met zijn replicaset (wat ook wel op te lossen was) en dat was de druppel om over te stappen

[DexterDee]

Ik hoop ergens dat Tweakers niet het pad op gaat van de commerciële cloud, maar nog zelf alles in beheer houdt. Dat gezegd hebbende, ik zou als ik het voor het zeggen had ook kritisch kijken naar MySQL.

Begrijp me niet verkeerd, ik gebruik MySQL al meer dan 20 jaar en was lange tijd een groot fan. De laatste jaren is echter het landschap dramatisch veranderd. Door het structurele mismanagement (of verwaarlozing als je niet gelooft in malicious intent) van Oracle is MySQL in een steeds slechtere positie gekomen. Met als "hoogtepunt" dat Oracle afgelopen najaar MySQL in het OCI programma heeft geduwd en ongeveer 50% van alle engineers die aan MySQL werkten heeft ontslagen. De focus van de overgebleven engineers is verschoven naar het maken van database Cloud services in plaats van de database engine.

Het gevolg van deze lijn die al jaren geleden is ingezet is dat premium features de community versie niet meer halen. Features zoals vector functies die nodig zijn in het AI tijdperk of de Hypergraph optimizer. MySQL is een soort melkkoe geworden voor Enterprise gebruikers en kan bijna niet verder af staan van de filosofie van de originele founders.

Natuurlijk hebben we spin-offs als Percona en MariaDB, maar als je vandaag de dag een project start, dan is je go-to OLTP SQL database server gewoon PostgreSQL. High availability features zoals Galera die erin geknipt en geplakt zijn, zijn lastig stabiel te maken onder hoge load.

Zou ik als het aan mij lag dan Tweakers op PostgreSQL zetten? Nee, dat niet. Ik zou vandaag de dag niet meer kiezen voor een replicated single-writer database architectuur. Ik zou ook niet kiezen voor een replicated shared nothing architectuur als Galera (of PostgreSQL cluster).

Ik zou in het geval van een zelf hosted database engine kijken naar een native gedistribueerde SQL database. Mijn persoonlijke favoriet is dan CockroachDB. Deze database is zwaar geïnspireerd op de Google Spanner en Bigtable papers, welke de backbone van onder andere Google Search en Analytics vormen. Het is een echte gedistribueerde SQL database die PostgreSQL dialect aan de buitenkant praat met een aantal heel aantrekkelijke kenmerken. Zo is de database multi-writer en schaalt de database horizontaal zowel in reads als in writes. Data sharding, rebalancing en data reparatie is volledig automatisch. Bij het toevoegen of verwijderen van nodes balanceert de data volgens de ingestelde replicatie vereisten automatisch. De nodes gedragen zich gezamenlijk als één logische database die ACID compliant is. Een upgrade van de database kan in tegenstelling tot MySQL zonder downtime worden uitgevoerd. Verder kunnen queries over grote hoeveelheden data over meerdere ranges parallel uitgevoerd worden. Zeker in combinatie met parallel uitgevoerde composite index lookups kan dit veel tijdswinst ten opzichte van MySQL opleveren. Als laatste is het "beginnen" met CockroachDB extreem simpel, wat ook bij MySQL altijd het uitgangspunt is geweest. Download de single binary en roep deze aan in een lege directory en je start een single node op die een lege database initialiseert in de huidige directory.

Het eerlijke verhaal is natuurlijk dat er niet alléén voordelen aan CockroadDB zitten ten opzichte van MySQL. Ik heb uitgebreide ervaring met het draaien van beide databases en er zijn wel een aantal nadelen en aandachtspunten. Ten eerste, CockroachDB is super robuust en bijna niet kapot te krijgen (hence the name) maar is super gevoelig voor time drift. Als de systeemtijd niet perfect gesynchroniseerd is tussen de nodes dan krijg je issues. Op te lossen met een robuste NTP infra. Ten tweede, als performance het allerbelangrijkste is en je load + dataset past op één fysieke server, dan zal MySQL in bijna alle gevallen iets sneller zijn. Je kiest CockroachDB als je rock solid (near zero maintenance) high availability en schaalbaarheid over nodes belangrijk vindt. Verder is MySQL kapot geoptimaliseerd voor kortlevende verbindingen, iets wat in PHP een veelvoorkomend patroon is. Om het beste gebruik te maken van CockroachDB in PHP, is het verstandig om application level pooling te gebruiken of een tool als pgBouncer. Als laatste is het lastiger om een consistente backup te maken van je hele dataset, omdat één node vaak niet de hele dataset heeft. Dit vereist wat meer werk dan een welgeplaatste mysqldump --single-transaction.

Vóór het AI tijdperk zou de conclusie al heel snel zijn dat het gigantische werk om te switchen van een database engine onbegonnen werk zou zijn met een mount Everest aan legacy code. Maar ik zie de laatste tijd om me heen dat grote rewrites steeds haalbaarder worden als deze gepland en uitgevoerd worden met bijvoorbeeld Claude Code.

Ik heb niet de illusie dat dit epistel de richting van Tweakers DevOps drastisch gaat veranderen, maar misschien kan ik een zelfhostende Tweaker blij maken met dit opiniestuk

[raymondw]

Tx! Zeker een leuk stukje tekst 🤙🏻

[lasharor]

Ik zie een link met de beurswaarde van MongoDB en deze aankondiging van Tweakers.net

De redenen waarom wij MongoDB ooit zijn gaan gebruiken, zijn tegenwoordig niet meer van toepassing.

Wat zijn deze redenen?

[Reactie gewijzigd door lasharor op 3 maart 2026 11:19]

[thePiett]

NoSQL was hip!

[Kees]

Ik zie een link met de beurswaarde van MongoDB en deze aankondiging van Tweakers.net

En we betaalden er niet eens voor!

Wat zijn deze redenen?

Kees in 'Serververhuizing, DB-versimpeling en feedbackfixes - Development-iteratie #332'

[thePiett]

Gaan jullie weer terug naar Vuurwerk?

[NEK]

Dat is echt heeel oud. De begin dagen van het internet :-) Mooie herinneringen aan!

[maali]

deze 'ohja' deed mij erg oud voelen, verdorie

[gpon]

Aangezien DPG zo groot is, kunnen jullie de hosting dan niet gezamenlijk onderbrengen?

[Gustaaf437]

Zoals het is opgeschreven krijg ik wel een beetje dat idee. Het zou wel zonde zijn. Het is toch één van de dingen die Tweakers uniek maakt. Hopelijk heb ik het bij het verkeerde eind, maar ik ben er bang voor.

[kuurtjes]

Hoe gaan jullie de downtime tijdens de verhuis aanpakken? Gewoon even lekker een dagje offline of eerder proberen de downtime te minimaliseren?

[RobertMe]

Tweakers draait voor zover ik weet in 2 DCs. Alle servers in één DC een dagje uit trekken zou dus geen issue mogen zijn. (Omdat er dus al load balancing / failover tussen de twee DCs is en een voorbereide "failover" vast makkelijker is dan daadwerkelijk uitval aan een van beide kanten).

[2Keys]

Succes met de migratie!

[Olaf van der Spek]

Bij het vorige .plan openden we een feedbacktopic en naar aanleiding daarvan hebben we verbeteringen gedaan.

En, hoe was de feedback?

[Hell-Slave]

Pricewatch? Wat is dat?

[stanny]

wat die slidein betreft voor de reviews: best vervelend dat als je een uitgebreide review leest en terug naar de reviews gaat, je terug bovenaan de lijst komt. vroeger was dat overzichtelijker en gebruiksvriendelijker dat de browser kon onthouden waar ergens in de lijst je zat. nu is het elke keer weer gaan zoeken waar je was. des specs-slidein snap ik, de reviews vind ik minder geslaagd in de huidige vorm.

[dmantione]

Het gaat niet gebeuren, maar het zou geniaal zijn om één locatie het kantoor van Tweakers te maken, met de huidige beschikbaarheid van glasvezelverbindingen is dat iets dat nu realistisch is. En in deze tijden van afhankelijkheden van techreuzen, zou het helemaal van deze tijd zijn en een voorbeeld voor de rest van Nederland.