Hvordan sammenligner AWS relasjonsdatabaser

En relasjonsdatabase var lenge en ganske standardløsning på ulike (og nesten alle) programvarebrukssaker som store eller små bedrifter måtte løse.

I dag er variabiliteten mye høyere med den bredere tilgjengeligheten av NoSQL-, in-memory- eller data Lake-databaser. Men til tross for det, når beslutningen tas om å migrere gjeldende lokale databaser til skyen, er relasjonsdatabasen som et mål fortsatt det enkleste alternativet for denne overgangen.

Vi skal se nærmere på følgende databaser som kan være en del av et slikt initiativ:

• Oracle
• Aurora
• Microsoft SQL Server
• MySQL og PostgreSQL
• MariaDB

Jeg vil være tydelig på hvordan de skiller seg fra resten og hva som skiller dem, inkludert deres ulemper. Deretter vil jeg bringe dem inn i kontekst ved å demonstrere et typisk brukseksempel fra den virkelige verden. Til slutt vil jeg dele mitt syn på å velge mellom de forskjellige databasene for ditt tilfelle.

AWS Oracle DB

Kilde: aws.amazon.com

Oracle DB var utvilsomt den mest brukte kommersielle databasen de siste tiårene. Når et selskap trengte en robust og høyytende databaseløsning, var Oracle DB førstevalget. Og av mange gode grunner.

Hvordan det skiller seg

Oracle er en robust og funksjonsrik plattform som kan betjene en enorm mengde til og med helt forskjellige oppsett og krav. Over tid ble denne DB den ultimate go-to-løsningen i tilfelle du trenger state-of-the-art pålitelighet, skalerbarhet og vedlikeholdsvennlighet som bor på den lokale maskinvareinfrastrukturen.

Hovedfordeler

Her er noen av hovedfordelene du får når du velger et så modent databasesystem som Oracle:

✅ God støtte og alternativer for effektive sikkerhetskopierings- og gjenopprettingsaktiviteter.

✅ Stort område med muligheter for hvordan du kan justere ytelsen til DB-løsningen inne i systemet. Selv lenge etter er løsningen allerede i produksjon. Støtte- og vedlikeholdsaktiviteter på denne plattformen er veldig enkle å sette opp, og de er veldig effektive.

✅ Høy tilpasning av DB-løsningen. Siden Oracle DB støtter en omfattende mengde funksjonaliteter å velge mellom, har du som systemintegrator mange muligheter til å bygge et robust system som består av akkurat de funksjonalitetene som plattformen din trenger (tenk triggere, partisjoner, underpartisjoner, automatiserte primærnøkkelsekvenser, visninger , øyeblikksbilder, databegrensninger, unike nøkler, kombinerte nøkler, fremmednøkler, sammensatte indekser, etc.). Den støtter alt.

✅ Enkel administrasjon av databaseaktiviteter og prosesser. Dedikerte administrasjonskonsoller og dashboards, og mange verktøy laget av Oracle og dedikert utelukkende til administratorer for bruk rett ut av esken.

✅ Støtte for flerbrukermiljøer. Hvis kravet er å støtte tusenvis av distinkte aktive brukere samtidig, er Oracle svaret.

De viktigste ulempene

Oracle DB er svært fleksibel når det gjelder vertikal skalering av ytelsen. Men mindre når du trenger sterk horisontal skalering. Det betyr at det er enkelt å oppgradere til en sterkere CPU, mer minne og lagringsplass på en klynge-DB.

Men hvis dataene dine vokser betydelig på kort tid – som er det vanlige tilfellet som skjer med data i skyen, vil ytelsesflaskehalsene bli mer synlige og vanskeligere å løse. Å spre dataene på tvers av flere klynger og forvente at de skal vokse dynamisk vil bli et hovedkrav fremover. I dette tilfellet kan du oppleve at Oracle DB begynner å være mer begrensende enn å oppfylle dine fremtidige behov.

En annen mulig ulempe kan være kostnaden. Oracle DB støtter mange funksjoner, men mange av dem har også en kostnad. Enda mer hvis flere klynger er på plass og fysiske ytelsesoppgraderinger er nødvendig. Det betyr at programvarejustering av datamodellen ikke lenger er tilstrekkelig. For at flere administrative verktøy og funksjoner skal være tilgjengelige, må du kjøpe en bedriftslisens. Dette vil øke de allerede høye kostnadene ytterligere.

Til slutt, Oracle DB er ikke en innebygd AWS DB-tjeneste, noe som betyr at du ikke kan forvente full støtte fra AWS. Orienter deg heller mot Oracle-støtte. Men håndter Oracle og AWS smertepunkter parallelt og med to forskjellige sett med støtteteam.

Når du skal velge

Å velge skymotparten til Oracle DB er den mest naturlige beslutningen å ta når den nåværende lokale løsningen allerede bruker Oracle DB. Det vil også gjøre migreringen og bytte til den skybaserte løsningen så enkel som mulig.

Velg derfor AWS Oracle DB i tilfellet:

• Du forventer at sky-DB vil støtte de samme prosessene og funksjonalitetene som den lokale varianten i overskuelig fremtid.
• Du planlegger ikke å integrere DB med for mange AWS native tjenester veldig raskt.
• Du forventer ikke at det nåværende datavolumet vil vokse betydelig i løpet av kort tid.
• Du trenger støtte fra en enorm mengde funksjoner på plass. Det vil si at det ville være vanskelig å miste noen av dem på plass når du bytter til skyen.
• Systemet ditt må støtte hundrevis av aktive brukere på samme tid (eller flere).

Eksempel på bruk

• Store telekommunikasjonssystemer for fakturering, CRM og mellomvaredata.
• Egendefinerte DB-implementeringer for bildatabasesystemer, integrert med flere forskjellige tilpassede eller tredjepartsleverandørverktøy.
• Pakkede systemløsninger for bankindustrien, hvor Oracle allerede er en fast del av den pakkede løsningen fra leverandørene og til slutt integrerer ytterligere tilpassede DB-komponenter i én kompleks implementering.

AWS Aurora DB

Kilde: aws.amazon.com

På mange måter er Aurora det direkte motsatte av Oracle, selv om det fortsatt er en relasjonsdatabase.

Hvordan det skiller seg

Autora DB er en innebygd databasetjeneste i AWS. AWS gir den full støtte og pågående utvikling og integrerer den dypt med resten av AWS-tjenesteøkosystemet.

Aurora DB når ikke det nivået av funksjonalitetsdiversifisering som Oracle allerede har. Men det ble født i skyen (i motsetning til Oracle). Siden AWS videreutvikler Aurora, kan funksjonalitetsgapet til slutt bli mindre i fremtiden enn det er i dag.

På mange måter er Aurora allerede foran Oracle, spesielt når det gjelder integrasjon med andre AWS-skytjenester. Og siden Amazon skapte Aurora med et skyøkosystem i tankene, er Aurora klar for massiv datainntekt og økning over tid, så horisontal skalering er en sterk egenskap.

Hovedfordeler

Jeg vil si at hovedfordelene med Aurora DB er:

✅ Veldig fleksibel utvidelse av skrivebeskyttede DB-kopiforekomster. De du kan lage bare på sekunder. Skrivebeskyttede forekomster deler de samme DB-loggene til hoveddatabasen de kommer fra. Det betyr at å opprette en ny skrivebeskyttet database ikke krever synkronisering av alle dataene; det gjør det automatisk ved å dele de eksisterende.

✅ Klar for stor datavekst – horisontal skalering er en stor funksjon i Aurora DB. Å legge til nye klynger og utvide skalerbarheten på tvers av forskjellige tilgjengelighetssoner er så enkelt som det blir. Aurora er da veldig effektiv til å velge store datamengder veldig raskt.

✅ Du kan velge om du vil bruke server eller serverløs modus til Aurora DB. Noen av funksjonene vil mangle i serverløs modus. Men du får mye fleksibilitet og kostnadsoptimaliseringer når du velger serverløs modus.

✅ Automatiserte sikkerhetskopier og enkel tilbakestilling på tidspunktet. Et annet høydepunkt er at Aurora DB kan gjøre enkle daglige sikkerhetskopier, og å gjenopprette hele databasen til et hvilket som helst tidspunkt er mye enklere. Du kan kombinere alle fordelene med skymiljøet her, som alltid tilgjengelig ledig plass, raske interne AWS-operasjoner og en dedikert Aurora DB-funksjon som er rettet mot raske gjenopprettingstider og kort nedetid.

✅ Støtte for enten MySQL eller PostgreSQL DB-motor, slik at du kan velge den som passer deg.

De viktigste ulempene

• Selv om Aurora uten tvil er den mest funksjonsrike native relasjonsdatabasen du kan velge i AWS, henger den fortsatt etter Oracle i denne forbindelse. Det er forståelig; Oracle hadde mye mer tid til å utvikle disse funksjonene tidligere. Faktum er at Aurora DB er, for hver utgivelse, sterkere og nærmere.
• Det er ingen ekvivalent til Aurora DB i det lokale rommet. Du kan argumentere for at gamle databaser bygget inne i MySQL- eller PostgreSQL-databaser er en tett match – og fra et kompatibilitetsperspektiv er de det sikkert. Men de er ikke den strenge ekvivalenten. Det betyr at migreringen ikke vil være så enkel. Du må tilpasse og implementere migreringsprosesser for å sikre at de overfører data fra lokale og lagrer dem i Aurora DB, alt i riktig datamodellformat.
• Ulike AWS-grenser, spesielt de vanskelige, er en faktor som i noen tilfeller kan forringe å velge denne DB som et mål for å gå videre. Det er svært sannsynlig at du vil være i stand til å omgå dem alle, men for noen vil du trenge noen mer seriøse investeringer i refaktorisering, som til slutt kan øke de totale kostnadene ved migrering sammenlignet med et annet databasemål.

Når du skal velge

I et nøtteskall er det aldri en dårlig beslutning å velge Aurora DB som goto-relasjonsdatabasen i AWS-plattformen, men gjør det, spesielt hvis:

• Du vil bygge et skysystem fra bunnen av rundt en relasjonsdatabase.
• Du forventer det høyeste nivået av kompatibilitet og integritet med så mye som mulig forskjellige native AWS-tjenester.
• Du forventer at datavolumet ditt vil vokse betydelig over kort tid.
• Du planlegger å starte flere spin-off proofs of concept (POC)-prosjekter der du kan utnytte alle fordelene med den serverløse versjonen av en relasjonsdatabase.

Eksempel på bruk

• En serverløs plattform for å analysere store mengder infrastrukturbildedata.
• Bruk av maskinlæringsmodeller for å behandle datainnsjøinformasjonen din og generere forretningsspådommer for virksomheten din.
• Netflix bruker Aurora DB for raske parallelle spørringskjøringer over katalogdataene deres.

AWS Microsoft SQL DB

Kilde: aws.amazon.com

Denne databasen er på noen måter sammenlignbar med Oracle. Den ble også opprettet lenge før skyen ble en ting, og det er mange nåværende lokale brukere som planlegger å migrere til skyen ved å bruke MS SQL DB som kilde.

Hvordan det skiller seg

Til tross for disse likhetene, er MS SQL DB fortsatt den som hadde mye mindre bruk i fortiden sammenlignet med Oracle DB.

I det minste å dømme ut fra mitt personlige erfaringsperspektiv. Jeg var involvert i flere Oracle-prosjekter de siste to tiårene, men bare i en håndfull tilfeller der MS SQL DB var involvert. Og ærlig talt, jeg likte ikke å håndtere det i nærheten av så mye som jeg gjorde med Oracle DB.

Uansett, jeg gjenkjenner fortsatt et stort segment av selskaper som bruker MS SQL DB som hoveddatabasen som er det eneste sannhetspunktet for alle dataene.

Hovedfordeler

Hovedfordelene som MS SQL DB har:

✅ God integrasjon med andre Microsoft-tjenester og programvare, i tilfelle dette er en funksjon du kjenner igjen som verdifull for din sak.

✅ Enkel tilpasning med tilpassede kodeutvidelser, for det meste i form av Javascript-kodemoduler. Dette kan være nyttig når du arbeider med mer komplekse forretningsprosesser og jobber som skal planlegges over databasen.

✅ Ganske enkelt fra et administrasjonsperspektiv (i hvert fall i forhold til Oracle DB).

✅ Det gir sannsynligvis mye mer mening i Azure-skyøkosystemet, siden det regnes som et naturlig relasjonsdatabasesystem, mye mer kompatibelt med andre skytjenester der.

De viktigste ulempene

• I likhet med Oracle DB-tilfellet, som en ikke-innfødt database i AWS-skyen, må all støtte og problemløsning drives via separate dedikerte MS SQL-støtteteam.
• Mindre diversifisering av funksjonalitetsstøtte generelt når man sammenligner den med Oracle DB eller Aurora DB.
• Ikke egnet for et stort antall aktive brukere.
• Horisontal skalerbarhet er et enda større problem enn med Oracle DB-dekselet.

Når du skal velge

MS SQL DB er best egnet hvis du ønsker å migrere eksisterende MS SQL DB on-premise inn i skyen med så få distraksjoner rundt som mulig. Dessuten forventer du ikke den integrasjonen med andre AWS-skytjenester i særlig grad.

Da vil MS SQL DB leve inne i AWS-skyen som en fullstendig administrert database med ubegrenset lagring og utvidede muligheter for horisontal skalerbarhet og høy tilgjengelighet sammenlignet med det lokale alternativet.

Eksempel på bruk

• Fungerer som en mellomplattform for tilpasset integrasjon av ulike databasesystemer (kan til og med være av en annen type, for eksempel Oracle DB).
• Ulike prosjekter i mindre skala hvor kostnaden for databaseløsningen er en ting å vurdere, og budsjettet er mer begrenset (og ikke tillater å gå for en fullverdig Oracle DB-løsning).

AWS MySQL og PostgreSQL DB

Kilde: aws.amazon.com

Disse databasene er begge åpen kildekode etter opprinnelse (selv om de nå allerede er kjøpt av større selskaper), og gir dem til slutt både fordeler og ulemper.

De er heller ikke så funksjonsrike som andre alternativer, spesielt i sin opprinnelige form. Og selv om du fortsatt kan bruke dem begge i AWS-infrastruktur i denne formen, tviler jeg på at dette fortsatt gir for mye praktisk mening.

Hvordan det skiller seg

Når du migrerer den lokale DB-en (det være seg MySQL eller PostgreSQL) til AWS-skyen, kan du bare bruke Aurora direkte med MySQL- eller PostgreSQL-motoren som mål og dermed få alle tilleggsfordelene Aurora DB har å tilby.

Selvfølgelig vil det bety noe ekstra innsats for migrasjonsfasen i forhold til tilfellet når et naturlig alternativ ville bli valgt. Men den ekstra innsatsen vil bare være marginal.

Hovedgevinsten deres ligger i kostnadene og at de egner seg best for små prosjekttiltak, der robusthet egentlig ikke er et tema.

De viktigste ulempene

• Begge er ganske begrenset i støttet funksjonalitet, og du må være forberedt på begrensede muligheter for vedlikehold og administrasjon.
• Ikke egnet for store prosjekter med mange aktive brukere.
• Ikke best for løsninger med høy ytelse og hvor konstant ytelsesjustering er et sterkt krav.

Når du skal velge

• Hvis kostnad er hovedtemaet og budsjettet er svært begrenset.
• Hvis prosjektinitiativet er ganske lite.
• Hvis datavolumet er ganske lite og det ikke er planer om betydelig vekst.

Eksempel på bruk

• Personlige prosjekttiltak der kostnadene for infrastrukturen skal være så lave som mulig.
• Små POC-er som vil bevise at det foreslåtte konseptet kan realiseres.
• Små bedrifters prosjekter med små mengder data.
• For små SaaS-prosjekter, som ikke krever en omfattende mengde databasebelastninger, er bare datalagring på en relasjonsdatamodellmåte alt som virkelig kreves.

AWS MariaDB

Kilde: aws.amazon.com

MariaDB er fortsatt en fullstendig åpen kildekode-database laget av tidligere MySQL-utviklere (etter MySQLs oppkjøp av Oracle).

Når det gjelder kompatibilitet, vil enhver MySQL DB kjøre helt fint inne i MariaDB.

Hvordan det skiller seg

Funksjonsmessig er det ikke mange forskjeller fra MySQL å forvente, men åpen kildekode-egenskapen er høydepunktet.

Teknisk sett er det ganske mange nyttige funksjoner som er tilgjengelige i MariaDB, men ikke i MySQL.

De viktigste ulempene

Ganske lik MySQL-saken.

Når du skal velge

• Hvis du absolutt elsker din nåværende MariaDB-implementering på stedet og ikke vil migrere til Aurora DB, uansett grunn.
• Hvis du ønsker å forbli virkelig åpen kildekode med databaseløsningen din i AWS-skyøkosystemet.

Eksempel på bruk

Ganske lik MySQL-saken.

Siste ord

På samme måte, ettersom Oracle DB var løsningen i den lokale verden, ser det ut til at Aurora DB tar denne plassen i AWS-skyverdenen. I det minste sett fra funksjonssettets perspektiv er dette det nærmeste du kan komme.

Og selv om du egentlig ikke er ute etter de viktigste interessentene, er det godt å vite at det fortsatt er ganske enkle alternativer for hvordan du kan migrere din eksisterende database til AWS-skyen.

Enda bedre – med denne bryteren vil du automatisk få funksjoner du mest sannsynlig manglet til da. Viktigst av alt, bedre lagringsmuligheter, høy tilgjengelighet og horisontal skalerbarhet er alle native funksjoner i skymiljøet.