De 5 grootste nadelen van data virtualisatie

Tegenwoordig wordt data virtualisatie neergezet als dé nieuwe ontwikkeling in DevOps world. Gevestigde namen zoals Delphix bieden deze oplossing aan. Het belooft ontwikkelaars en QA engineers snel nieuwe, veilige, testomgevingen te kunnen neerzetten. Enorm interessant in een wereld waarin we sneller dan ooit software naar productie willen brengen.

Deze ‘hype’ van data virtualisatie zorgt ervoor dat wij steeds vaker klanten tegenkomen die proberen hun test data management te combineren met data virtualisatie. Om een goede en weloverwogen keuze hierin te kunnen te maken, vinden wij het belangrijk om ook de andere kant van de medaille te belichten en de nadelen van data virtualisatie te benoemen.

1. Tijd

Ondanks het feit dat er gesproken wordt over significante tijdswinst in het neerzetten van ‘test’ omgevingen met behulp van ‘virtuele databases’ (VDB), gaat er nog steeds bijzonder veel tijd verloren. Want de meeste tijd waar QA engineers mee bezig zijn, is het vinden en klaarzetten van testdata. Het zoeken in een grote database van enkele miljoenen zo niet miljarden records gaat deze tijd niet verkorten. Uit recent onderzoek blijkt dat we 46% van onze tijd kwijt zijn aan het zoeken en vinden van testdata. En wat er eigenlijk onder water gebeurt is dat er een 100% kopie productie wordt neergezet en deze wordt vervolgens uitgeleverd aan de verschillende teams met VDB’s.

2. Delta’s

Een ander interessante USP van data virtualisatie zijn delta’s. De delta’s in de VDB’s zijn best interessant, maar de delta’s naar de originele source, dat wordt een stuk ingewikkelder. Want met data virtualisatie moet je één keer een kopie productie op een server zetten van de data virtualisatie leverancier. Maar met snelle doorontwikkeling naar productie, verandert uiteraard met enige regelmaat de productie data. Veel leveranciers van data virtualisatie, zoals bijvoorbeeld Delphix, geven dan aan dat door het bijhouden van delta’s op de bron, ze de ‘kopie productie’ kunnen bijwerken. Maar dat zou wel eens zeer problematisch kunnen zijn. Bij ons zijn geen organisaties bekend die zomaar zonder meer een verbinding vanuit test naar productie toestaan. Kortom: dit werkt niet. En wat is nu een hele grote tijdverliezer, deze refresh frequenties. Dit neemt soms weken in beslag. Deze tijd ga je dus verliezen bij verversing en dat doet behoorlijk pijn.

3. Kosten

Er wordt uiteindelijk een volledige kopie van productie neergezet op de ‘data virtualisatie’ server, weliswaar wordt deze gecompressed, en daardoor bespaar je op storage. Nadat dit heeft plaatsgevonden gaan 1, 2, 3 of tot wel 10 teams werken met een zogenaamde VDB. Al deze teams gaan werken op de VDB en bevragen de server. De hoeveelheid en zwaarte van deze processen (afhankelijk van de hoeveelheid QA (teams)) gaan bijzonder veel netwerkverkeer genereren, met alle mogelijke kosten van dien.

4. Single point of failure

Wat gebeurt er als de Delphix Server down is? Dan zijn alle VDB’s down en kan niemand zijn werk meer doen! Kortom: er zijn dan maar weinig omgevingen waar je dan nog op terug kunt vallen. Dit is wel een behoorlijk risico.

5. Batch processing

Wanneer je grote batch processen voor een grote database op een ‘data virtualisatie’ server wilt uitvoeren, zal dit tot grote conflicten met je collega’s leiden. De virtuele database van je teamleden zal dit niet leuk vinden…

De testdata beschikbaarheidsoplossing van DATPROF

Een andere manier van data virtualisatie, zoals DATPROF die aanbiedt, werkt als volgt: we maken gebruik van subset technologie om kleine gevulde databases te realiseren uit een bron-omgeving. Om dit te realiseren, hebben we allereerst een bron-omgeving nodig. De bron kan een productie-omgeving zijn, maar vaker is dit een kopie productie, denk daarbij aan een fall back of een acceptatie-omgeving. Wanneer deze bron gevonden is, zullen we hier testdata uit extraheren en in testdata-omgeving plaatsen. Dit klinkt heel eenvoudig, maar deze manier van testdata generatie heeft uiteraard ook zijn uitdagingen.

Tijd

Het kost tijd om een eerste subset te realiseren. Uit onze ervaringscijfers blijkt dat dit varieert van 15 minuten tot soms een aantal uren. En dan hebben we het over 15 uur of meer. Gelukkig kunnen we in veel gevallen het aantal uren nog behoorlijk terug brengen. Vervolgens levert deze subset je wel een enorm voordeel op: het terugzetten van een gesubsette testdatabase van 200 GB (in plaats van het origineel van 20+ TB) kan in enkele minuten. Dit is mogelijk door gebruik te maken van backups en recovery processen of snapshotting. Dit levert je dus een enorme tijdswinst op én je hebt de juiste testgevallen erin zitten.

Onbekend data model

Om een goede subset te maken, zijn er foreign keys nodig. Met enige regelmaat komen we applicaties tegen waar deze keys niet zijn opgeslagen in het datamodel zelf. Ze zijn dan opgeslagen in een applicatietabel of ze zijn helemaal niet opgeslagen. Voor het succesvol realiseren van een subset zijn ze echter wel nodig. Wat we dan doen is dat we de foreign keys importeren, bijvoorbeeld als ze in een applicatietabel liggen opgeslagen. Ook kunnen we gebruik maken van onze foreign key discovery module. Vervolgens zijn ze dan bekend in DATPROF Subset en kunnen we een subset realiseren.

Welke oplossing kies jij?

Samenvattend hebben beide oplossingsrichtingen hun voor- en nadelen. We hopen dat dit vergelijkende artikel behulpzaam is in de zoektocht naar de juiste oplossing! Mocht je meer willen weten, schroom niet om eens contact met ons op te nemen.