Programmering

To grunner til at en samlet database ikke er en slik slam-dunk

Det er ofte det første problemet du løser når du flytter til skyen: Bedriften din bruker dusinvis, noen ganger hundrevis, av forskjellige heterogene databaser, og nå må du binde dem sammen i hundrevis av virtuelle visninger av dataene i skyen.

Det som er bra med dette er at du ikke trenger å migrere til nye databaser, eller til og med flytte dataene dit de for øyeblikket er vert i skyen. Tross alt kan det være applikasjoner som er avhengige av disse dataene, og det siste du vil gjøre er å lagre overflødige data.

Så, du fødererer. Det gir deg logisk sentralisering av data uten å måtte endre hvor dataene er fysisk lagret, sky eller ikke.

Men ikke så fort. Det er veisperringer å vurdere. Her er mine to beste.

Først ytelse.Du kan absolutt blande data fra en objektbasert database, en relasjonsdatabase og til og med ustrukturert data, ved hjelp av sentralisert og virtualisert metadatadrevet visning. Men din evne til å kjøre sanntidsforespørsler om disse dataene på en rimelig tid er en annen historie.

Den skitne lille hemmeligheten om forente databasesystemer (sky eller ikke) er at med mindre du er villig til å bruke tiden det tar å optimalisere bruken av den virtuelle databasen, vil det sannsynligvis dukke opp ytelsesproblemer som gjør bruk av en samlet database , vel, ubrukelig. For øvrig hjelper det deg ikke å plassere den forente databasen i skyen, selv om du legger til mer virtuell lagring og beregner for å prøve å tvinge ytelsen.

Årsaken er at så mye må skje i bakgrunnen bare for å få dataene på plass fra mange forskjellige databasekilder. Disse problemene løses vanligvis med å finne ut godt sammensatt databasedesign, tuning av databasen og plassering av begrensninger på hvor mange fysiske databaser som kan være involvert i et enkelt tilgangsmønster. Jeg har funnet ut at grensen vanligvis er fire eller fem.

For det andre, sikkerhet.Jeg er ganske sikker på at de fleste skybaserte databaser som kjører i skyen, har et sårbarhet som kan utnyttes nå, og de fleste bedrifter som eier dataene vet ikke det.

Årsaken er den samme som hvorfor du vanligvis har ytelsesproblemer: Det er så mange bevegelige deler at det er vanskelig å sørge for at alle data, tilgangspunkter, metadata osv. Er låst, men samtidig lett tilgjengelige.

Mens systemene dine som bruker databaser kan kryptere data i hvile, krypterer de ofte ikke data under flyging. Eller hvis du krypterer data underveis, krypterer du sannsynligvis ikke data i ro. Eller det er en direkte vei til den fysiske databasen som omgår den forenede databasearkitekturen og sikkerheten den gir.

Til dags dato har jeg ikke sett en forent database med god sentralisert sikkerhet som fungerer både i det virtuelle og fysiske databaselaget. Så bli opptatt med å plugge hullene!

$config[zx-auto] not found$config[zx-overlay] not found