Det er ofte det første problem, du løser, når du flytter til skyen: Din virksomhed bruger snesevis, nogle gange hundreder, af forskellige heterogene databaser, og nu skal du binde dem sammen i hundreder af virtuelle visninger af dataene i skyen.
Hvad der er godt ved dette er, at du ikke behøver at migrere til nye databaser eller endda flytte dataene, hvorfra de i øjeblikket hostes i skyen. Når alt kommer til alt kan der være applikationer, der er afhængige af disse data, og den sidste ting du vil gøre er at gemme overflødige data.
Så du fødererer. Det giver dig logisk centralisering af data uden at skulle ændre, hvor dataene er fysisk gemt, cloud eller ej.
Men ikke så hurtigt. Der er vejspærringer at overveje. Her er mine to top.
Først ydeevne.Du kan helt sikkert blande data fra en objektbaseret database, en relationsdatabase og endda ustrukturerede data ved hjælp af centraliseret og virtualiseret metadatadrevet visning. Men din evne til at køre realtidsforespørgsler på disse data på en rimelig tid er en anden historie.
Den beskidte lille hemmelighed om forenede databasesystemer (cloud eller ej) er, at medmindre du er villig til at bruge den tid, det tager at optimere brugen af den virtuelle database, vil der sandsynligvis dukke op præstationsproblemer, der gør brug af en forenet database , godt, ubrugelig. Forresten hjælper det dig ikke at placere den forenede database i skyen, selvom du tilføjer mere virtuel opbevaring og beregner for at forsøge at tvinge ydeevnen.
Årsagen er, at der skal ske så meget i baggrunden bare for at få dataene på plads fra mange forskellige databasekilder. Disse problemer løses typisk med at finde ud af et godt sammensat databasedesign, indstille databasen og placere grænser for, hvor mange fysiske databaser der kan være involveret i et enkelt adgangsmønster. Jeg har fundet ud af, at grænsen typisk er fire eller fem.
For det andet sikkerhed.Jeg er ret sikker på, at de fleste skybaserede fødererede databaser, der kører i skyen, har en sårbarhed, der kan udnyttes nu, og de fleste virksomheder, der ejer dataene, ved det ikke.
Årsagen er den samme som hvorfor du typisk har ydeevneproblemer: Der er så mange bevægelige dele, at det er svært at sikre, at alle data, adgangspunkter, metadata osv. Er låst, men på samme tid let tilgængelige.
Mens dine systemer, der bruger sammensatte databaser, muligvis krypterer data i hvile, krypterer de ofte ikke data under flyvning. Eller hvis du krypterer data under flyvning, krypterer du sandsynligvis ikke data i hvile. Eller der er en direkte sti til den fysiske database, der omgår den forenede databasearkitektur og den sikkerhed, den giver.
Hidtil har jeg ikke set en forenet database med sund centraliseret sikkerhed, der fungerer både i det virtuelle og fysiske databaselag. Så få travlt med at tilslutte disse huller!
