Codekraker 20: Martijn Dashorst - Werkenbijtopicus
Codekraker 20: Martijn Dashorst

Codekraker 20: Martijn Dashorst

Leer van je eigen fouten en voer een database migratie en architectuuraanpassing niet gelijktijdig door!

Een ezel stoot zich in het algemeen niet twee keer aan dezelfde steen, toch? In mijn vorige Codekraker was ik stellig over het feit dat je bij een database migratie áltijd een tool moet gebruiken die een weg terug biedt. Daar sta ik nog steeds 100% achter. Helaas ben ik met mijn team recentelijk in de val getrapt en heb ik ondervonden wat de gevolgen zijn als je dit níet doet. Ik neem je mee in deze fout, zodat jullie dit niet (meer) hoeft te overkomen. Mijn advies is dan ook: voer een database migratie én architectuuraanpassing niet gelijktijdig door.

Waar we de fout in gingen? De overstap van Oracle naar PostgreSQL. Deze móést gedaan worden om heel veel redenen, dus gebeuren ging het sowieso. En als je dan tóch gaat migreren, dan kun je net zo goed alles meteen anders inrichten. Dat is wat we dachten. In de Oracle-situatie hadden we onze 200 klanten verdeeld over 8 schema’s en daardoor 8 gescheiden kopieën van onze draaiende applicaties. In plaats van deze 8 schema’s een-op-een over te zetten met onze ervaringen van de vorige migratie, wilden we onze architectuur omvormen naar één PostgreSQL schema met één geünificeerd applicatieplatform waarbij we elk onderdeel los kunnen opschalen. En dat hadden we beter niet tegelijkertijd kunnen doen.

Waar het allemaal mee begon was de wens om het onderhoud van de database te verlichten. In Oracle hadden we onze 200 klanten verdeeld over 8 schema’s die elk met de hand moesten worden geüpdatet. We wilden terug naar één schema, maar de tabellen werden te groot. PostgreSQL kon daar niet mee overweg: het ophalen van rapporten duurde simpelweg veel te lang. Dus hebben we iedere klant een eigen schema gegeven. Van 8 naar 1 naar 200 schema’s dus. De rapporten waren nu eindelijk snel. Toch liepen we door deze keuze tegen allemaal beperkingen aan, die ervoor zorgden dat PostgreSQL de drukte van de applicatie niet meer aankon. Concreet betekende dat in ons geval dat onze 200 klanten en de bijna 200.000 leerlingen niet meer konden werken met de applicatie.

En dan hadden we nog de gewenste architectuuraanpassing. Door onze 8 schema’s in Oracle hadden we dus ook 8 kopieën van onze applicaties draaien. Die wilden we ook terugbrengen naar één. Daardoor passen effectief veel minder gegevens in de cache. Want waar caches eerst bijvoorbeeld ‘maar’ 25 klanten hoefden te bedienen, moest die ene cache nu 200 klanten bedienen. De database werd drukker, waardoor het een uitdaging was om de applicatie snel te houden.

Wat we uiteindelijk gedaan hebben is het splitsen van de database in twee, waarbij de helft van de schema’s op de ene database kwam en de andere helft op de ander. Dit, in combinatie met nog wat extra optimalisaties, zorgde ervoor dat we de applicatie weer werkend kregen. Gelukkig, na 5 maanden optimaliseren, werkt de applicatie nu beter dan ooit tevoren.

Kortom, we hebben twee ‘problemen’ tegelijkertijd opgepakt. Op dat punt liep het mis. Het is niet duidelijk of, als we de migratie en de architectuurmigratie gescheiden hadden aangepakt, we niet tegen problemen aangelopen waren. Maar die problemen waren wel anders geweest én we hadden een weg terug gehad. Dus: pak altijd één complexiteit per keer op. Leer van mijn fout, luister altijd goed naar jezelf en heb de ballen om terug te kijken naar ervaringen uit het verleden!

 Benieuwd naar andere codekrakers? Je checkt ze hier.