Technisch

In deel 1 van deze blog – Help! MySQL groeit uit mijn jasje – schreven we over performance-uitdagingen waar je mee te maken kan krijgen als je database groeit en met welke valkuilen je rekening moet houden als je goed voorbereid wil zijn. Kortom: waar je vooraf al over na moet denken om flexibel mee te groeien met je database. In deze blog willen we je de 6 belangrijkste onderdelen meegeven waar je op kunt letten en welke parameters van invloed zijn.

Wij worden regelmatig benaderd met de vraag of we databaseomgevingen kunnen beoordelen, inventariseren of tunen. Vandaag de dag zijn de mogelijkheden om een databaseomgeving in te richten zo divers, dat vrijwel geen enkele databaseomgeving te vergelijken is met een ander. Daarover vertelde onze collega Dimitri al eerder in zijn blog ‘Zo krijg je je database weer fit en gezond’. Onze QuickScan gaat nog weer een spade dieper. De uitdaging is vaak wel dat het draaiende productieomgevingen betreft waar je liever niet allerlei scripts en analyse-tooling op loslaat om te voorkomen dat het primaire proces wordt verstoord. Wat vervolgens ook nog eens onnodig extra tijd kost. Daarbij komt het meer dan eens voor dat we tijdens onze QuickScan ook voor andere zaken worden bevraagd in het kader van ‘nu we er toch zijn’. Natuurlijk helpen we graag, maar tegelijk zorgen we wel dat we alsnog binnen de afgesproken tijd klaar kunnen zijn. In deze blog bespreekt Martijn Wallet, onze manager consultancy en training, een partitioneringsanalyse die hij maakte van een Amazon RDS Postgres-databaseomgeving tijdens een QuickScan.

In het eerste deel van deze serie van twee legden we uit hoe SQL Server op Docker gedraaid kan worden. Het eindresultaat was een Docker-container en een storage volume met daarin een SQL Server instance. In deze blog gaat Taco Zoetemelk verder werken met deze Docker-container en laat hij zien hoe je een back-up maakt en terugzet.

Geïnspireerd door mijn collega Craig en zijn blogs over het draaien van PostgreSQL in Docker, was ik benieuwd of dit ook zou kunnen met een SQL Server database. Het korte antwoord? Dat is gelukt. Het lange antwoord? Daarvoor moet je even verder lezen.

In een vorige blogpost heb ik uitgelegd hoe je een PostgreSQL-database in een container kunt implementeren vanuit een standaard-image. In deze post bekijk ik de implementatie van een PostgreSQL-cluster. Nou ja, soort van…. PostgreSQL gebruikt de term cluster om te verwijzen naar ‘een verzameling databases beheerd door een enkele PostgreSQL-serverinstantie’. Ik gebruik het in meer algemene zin om te verwijzen naar High Availability.

In mijn vorige blogpost heb ik laten zien hoe je postgreSQL in een Docker-container kunt instellen, tot het punt waar je de database met psql of pgAdmin kon beheren. Ik had echter nog niet uitgelegd hoe het werkt. Als je iets anders probeert te doen, zelfs iets kleins, of als je fouten tegenkomt zoals ik heb geschetst, dan moet je weten wat al die commando's eigenlijk doen.

In deze blog leg ik je dat uit.

Als multi-platform DBA Consultant besteed ik veel tijd aan het leren van de nieuwste features die beschikbaar komen in de verschillende open-source en proprietary databases. Meestal gebruik ik VirtualBox-images om mijn sandbox-databases te maken, maar deze kunnen behoorlijk wat schijfruimte en bronnen in beslag nemen. Vooral als ik aan het werken ben met zaken als databaseclusteroplossingen en wanneer ik meerdere databases tegelijk nodig heb.

Daarom ben ik laatst eens naar het gebruik van Docker-containers gaan kijken om dit probleem op te lossen.

Ieder jaar komt er nieuwe versie van PostgreSQL, waarin tal van nieuwe features en verbeteringen beschikbaar komen. Tijdens de laatste PostgreSQL meetup in Amsterdam heeft Devrim Gündüz, major contributor en gepassioneerd PostgreSQL consultant, de aanstaande release van PostgreSQL 12 nader uit de doeken gedaan. In deze blog zetten wij voor iedereen die niet alle commits in Github op de voet volgt, of in de gelegenheid was om de meetup te bezoeken, de belangrijkste veranderingen in PostgreSQL 12 nog eens op een rijtje.

Met de laatste update van PostgreSQL is weer een aantal fijne nieuwe functies toegevoegd aan de populaire open-source database. Naast een aantal mooie features die het werk voor de DBA gemakkelijker maken, zal het hart van databasegebruikers vooral harder gaan kloppen van één bepaalde update. Dé update waar jaren op werd gewacht. *Tromgeroffel*: PostgreSQL 11 is voorzien van een echte stored-procedure!

Van alle NewSQL databases is CockRoachDB op dit moment een van de meest indrukwekkende en imponerende. Het is van nature een distributed database systeem die zeer goed geschikt is voor cloud deployments, maar ook gebruikt kan worden on-premise of in containers. Het is mogelijk om CockRoachDB dichtbij de gebruikers te brengen, verspreid over regio’s, datacenters en verschillende cloud providers. Data kan dynamisch verplaatsen naar de locatie waar het nodig is. CockRoachDB schaalt, balanceert en repareert automatisch. Handmatige sharding is niet nodig en ACID transacties zijn mogelijk.

Een indicatie voor een "zwaar" technisch datamodel is geheugen druk. Het database systeem vreet geheugen. In het meest ideale geval is er voldoende geheugen voor de gehele database, data en indexen. In veel gevallen is dit niet mogelijk, zorg er dan voor dat tenminste de clustered indexen en vervolgens de non-clustered indexen in geheugen passen.