Hvad er database-as-a-service (DBaaS)?
Når vi taler om, at databaser forbruges som cloudtjenester, taler vi om Database-as-a-Service (DBaaS).
Selvom dette ikke er en sølvkugle, der vil forenkle livet for enhver, der har brug for en database til et opgave- eller applikationsudviklingsprojekt, er DBaaS ikke kun enkel, den er fleksibel.
Det har mange af de fordele og ulemper, der er fælles for andre tjenester i skyen, såsom bedre omkostningskontrol på den ene side, men mere begrænsede funktioner end det lokale alternativ på den anden side.
Imidlertid fungerer det også som motor-software, der driver et stort udvalg af andre Software-as-a-Service (SaaS) apps, alt fra direkte relaterede datavisualiseringsværktøjer til organisationsomspændende ERP-platforme.
Men DBaaS er også en løsning for sig selv med fordele og ulemper, der er unikke for databasefunktioner.
Fordelene ved DBaaS inkluderer lavere adgangsbarrierer, større adgang til teknologier, der tidligere kun var inden for rækkevidde af store virksomheder, og digitalt native use cases såsom Internet of Things (IoT) datastreaming, maskinlæring (ML) -træning og hybridapps et supplement til computing på kanten.
Ulemper ved DBaaS inkluderer den generelle stivhed i databaser, kompleksiteten i datalogi, ufleksibilitet i integrationer, problemer med netværksydelse og den kompleksitet, der følger med store dataoverførsler.
Hvis du flytter følsomme data mellem din DBaaS-udbyder og et andet websted, skal du også tage sikkerhedsforanstaltninger, der kan involvere alt fra robuste identitetsstyringsprotokoller til implementering af et virtuelt privat netværk (VPN).
Derudover findes der forskellige slags DBaaS-udbydere fra dem, der ikke gør noget andet til store cloud-tjenester eller webhostingudbydere, for hvem en database kun er en ud af mange tjenester.
At vælge den bedste udbyder blandt en sådan liste betyder at sige gennem en lang liste over variabler, herunder pris, geografisk nærhed, support og endda de sidste tak, som databasen skal udføre.
Alle disse begrænsninger kan føre til det reelle behov for hjælp fra en databaseadministrator (DBA) på trods af mange DBaaS-leverandørers påstande om, at deres platforme er selvbetjening og brugervenlige.
Bundlinjen er, at datavidenskab ikke er let, selvom databasens spin-up og konfiguration er automatiseret, som det er i en eller anden grad i DBaaS-tilbud.
Men der er DBaaS-produkter og -tjenester, der er nemmere at bruge end andre, og nogle ligger bestemt inden for gennemsnittet af udviklere og forretningsanalytikere.
Jeg gennemførte anmeldelserne i denne sammenfatning fra udviklere og analytikere og i mindre grad små til mellemstore virksomheder (SMB'er) med få interne IT-ressourcer.
Målet med dette projekt var ikke at identificere overlegenhed ud fra et strengt teknisk perspektiv, men at identificere, hvor godt en typisk bruger sandsynligvis vil være i stand til at bruge tjenesten uden hjælp fra en DBA, mens den stadig bevarer teknologiens fulde fordel.
Hvis anmeldelserne blev udelukkende baseret på tekniske aspekter, kunne leverandørranglisten muligvis have været anderledes.
Hvad der 'let at bruge' virkelig betyder i en DBaaS
Som med ethvert andet SaaS-tilbud er DBaaS faktisk software på andres servere.
Det er sandt selv i de desværre navngivne "serverløse" modeller.
Overvejelsen "let at bruge" her gælder for mere end bare, om brugergrænsefladen er brugervenlig eller ej, men også for følgende:
- Uanset om der tilbydes vejledning om, hvilken databasetype eller motor der passer til dataene eller arbejdsbyrden,
- Hvor let det er at indlæse og overføre data,
- Hvor meget af serverprovisionen og servicekonfigurationen håndteres af ML og automatisering, og
- Hvor meget af sikkerhedskopierings- og gendannelsesprocessen er automatisk.
Hvis brugeren skal tage en lang liste over beslutninger, blot for at konfigurere databasen, er det ikke rigtig let at bruge til ikke-DBA'er, uanset hvor mange rullemenuer og forklaringsbokse brugergrænsefladen har.
Det kunne dog være let for DBA'er at bruge, og det er også fint, men til andre formål og en anden anmeldelse.
Med andre ord, for at en DBaaS skal være en stærk selvbetjeningsplatform, skal den eliminere behovet for, at en DBA er praktisk med hver lille brugerinteraktion.
På den anden side, hvis det skal være en alternativ eller hybrid tilføjelse til en lokal database eller endda en virksomheds primære database (som det ofte er tilfældet med cloud-native virksomheder), så er det let for DBA'er at bruge og skærm skal være de primære overvejelser.
For eksempel, hvis din virksomhed har kørt en forekomst af Microsofts SQL Server lokalt i nogle år og nu vælger at tilføje en forekomst af Microsofts Azure SQL Database som et skybaseret backup-lager, vil de fleste af dine slutbrugere f.eks.
behøver aldrig at røre ved den forekomst.
På samme måde, hvis databasens primære opgave vil være at drive en anden app eller arbejdsgang, så er det ikke ofte nødvendigt, at brugerne ofte interagerer med det direkte.
Når alt kommer til alt, når en database er i gang, kan brugerne anvende værktøjer som Business Intelligence (BI), udvikler og DevOps-apps til at udføre det arbejde, de virkelig er interesseret i.
Databasen forbliver i baggrunden for de fleste af disse scenarier.
, og endda andre avancerede brugere end DBA har sjældent brug for at røre ved det.
Når det er sagt, inkluderer brugervenlighed i denne gennemgangsopstilling hele spektret af tilbudte tjenester.
Tjenesten lader udviklere, analytikere og lejlighedsvis SMB-generel teknologiperson spinde databaser på farten med få instruktioner og lidt mere ved hånden end et kreditkort og en internetforbundet bærbar computer.
Ved disse parametre er Microsoft Azure SQL Database den nemmeste at bruge, med MongoDB Atlas kommer tæt på.
At beslutte, hvilke af disse to Editors 'Choice-vindere, du vil bruge, har mere at gøre med dine datas aktuelle format og de projekter, du arbejder på, end brugervenlighed.
IBM Db2 på Cloud er også let at bruge, selvom der er masser af udviklere, der måske beder om at adskille sig.
De fleste af de gribende handler om designbegrænsninger for udviklere.
Leverandører er ikke ens med hensyn til antallet af tilbudte regioner.
Færre muligheder kan vise sig at være en ulempe i nogle overholdelsesscenarier med Den Europæiske Unions generelle databeskyttelsesforordning (GDPR).
De varierer også med hensyn til overholdelse af andre regler, hvor nogle stadig arbejder på disse spørgsmål, og andre hurtigt kommer om bord.
Et eksempel: MongoDB Atlas er i juni 2018 i overensstemmelse med Health Insurance Portability and Accountability Act (HIPAA).
Test af versioner og vigtigheden af ??regioner
Gennemgangen af ??hvert produkt inkluderer notationer om, hvorvidt prøveversioner eller gratisversioner er tilgængelige, og eventuelle begrænsninger, der måtte gælde.
For eksempel har MongoDB Atlas en "gratis evig" version med 512 MB lagerplads og delt tilfældig adgangshukommelse (RAM).
IBM Db2 på Cloud har en gratis udviklerudgave med virksomhedsfunktioner, men Express-C, dens gratis kommercielle version, mangler avancerede virksomhedsfunktioner.
Betalte versioner varierer mindre, da de oftest er knyttet til opbevaring og computerbrug i stedet for til funktioner.
Det er dog vigtigt at bemærke, hvilke funktioner og regioner der er tilgængelige i de forskellige versioner, før du vælger en.
Selvfølgelig, hvis den ikke har avancerede virksomhedsfunktioner som IBM Db2 på Clouds Express-C-version, og du har brug for dem, så fungerer den version ikke.
Ligeledes, hvis du har problemer med GDPR at adressere, eller mange brugere over hele verden, og du virkelig har brug for at udrydde lag på din app, så vil Microsoft Azure SQL Databases forbløffende 50 regioner rundt om i verden i 140 lande få noget så meget som at have flere versioner gør.
Med hensyn til dine muligheder med hensyn til regioner har MongoDB Atlas 56.
Det gør god brug af regionerne fra Amazon Web Services (AWS), Google Cloud og Microsoft Azure, da det er hostet på alle tre.
Og kontraintuitivt kom Google BigQuery med det mindste antal regioner.
At være i stand til at vælge regionens placering til din database er vigtig af to grunde.
For det første skal du være sikker på, hvor dine data befinder sig (selv i skyen), hvor de bevæger sig, og hvordan de bruges på grund af regler som GDPR.
At være i stand til at vælge den rigtige placering til din database er bydende nødvendigt at forblive GDPR-kompatibel, selvom du ikke har nogen EU-kunde (EU) kundedata eller EU-medarbejderdata.
Flere scenarier gælder her.
For eksempel kan en medarbejder være amerikansk, og dermed påvirkes hans data ikke af GDPR.
Hans kone kan være europæisk eller amerikansk, men deres barn kan have dobbelt statsborgerskab, hvis han eller hun blev født i Europa.
Så forsikringsdata om dem er påvirket af GDPR.
Derfor, selvom virksomheden ikke har nogen EU-kunde eller EU-medarbejderdata, er det stadig nødvendigt at være GDPR-kompatibel.
Denne lov er alvorligt kompleks.
Og der er en anden, endnu mere kompleks privatlivslov fra EU, der kommer ned på gedderne.
Det er derfor klogt at vide nøjagtigt, hvor dine data er, og hvad der sker med og med dem, uanset om du tror, ??du ikke har nogen EU-individuelle data at bekymre dig om.
Jo tættere dine data og din app er på hinanden, jo bedre er ydeevnen - hvilket betyder, jo kortere forsinkelse og andre problemer.
Du vil gerne se efter muligheder for at implementere din app i det samme datacenter som din database eller samlokalisere din database ved siden af ??din app.
Versioner adskiller sig også væsentligt mellem leverandører og også inden for en enkelt leverandørs produktsortiment.
Nogle er billige i frontenden, men opkræver omkostninger ved at opkræve betaling for forskellige værktøjer og serviceopgraderinger, såsom ekstra sikkerhed eller backup- og gendannelsestjenester.
Pas på det.
Til denne gennemgangsundersøgelse brugte jeg mest testkonti til mellemliggende priser, der blev oprettet af leverandørerne snarere end de mere begrænsede versioner eller gratisversioner.
Nogle gange overførte jeg mine egne testdata, og nogle gange indlæste jeg leverandørtestdata eller arbejdede med deres forudindlæste datasæt.
I mange tilfælde leverede leverandører kreditter for at sikre, at jeg kunne teste deres systemer grundigt.
Lejlighedsvis testede jeg gratis udviklerudgaver, som jeg gjorde med SAP Cloud Platform, SAP HANA Service, fordi de normalt er fuldt udstyrede.
I alle tilfælde bemærkes den version, jeg testede, i hver anmeldelse af opskrivningen.
SQL eller NoSQL?
En anden faktor, der gør direkte sammenligning vanskeligere i denne gennemgang er i databasetyperne.
Som alle dataprofessionelle ved, håndterer SQL strukturerede data, og NoSQL er til ustrukturerede data, selvom denne forskel sandsynligvis ikke er åbenbar for almindelige brugere.
Et eksempel på strukturerede data er et regneark, mens et eksempel på ustrukturerede data er Twitter-feed-brandslangen.
SQL-databaser kaldes normalt relationelle databaser, mens NoSQL-databaser kaldes ikke-relaterede.
Men når det kommer til DBaaS, er indstillingerne mere varierede end blot at foretage en struktureret versus ustruktureret databestemmelse.
For eksempel, MongoDB Atlas, som er open source NoSQL, kører på andre brandede cloud-tjenester som AWS, Google og Microsoft skyer.
Nogle leverandører guider dig gennem labyrinten ...
