En relationel database var i lang tid en ganske standardløsning på forskellige (og næsten alle) softwarebrugssager, som store eller små virksomheder skulle løse.
I dag er variabiliteten meget højere med den bredere tilgængelighed af NoSQL-, in-memory- eller data lake-databaser. Men på trods af det, når som helst beslutningen om at migrere nuværende on-premise databaser til skyen, er relationsdatabasen som mål stadig den mest ligetil mulighed for denne overgang.
Vi vil se nærmere på følgende databaser, der kan være en del af et sådant initiativ:
- Oracle
- Aurora
- Microsoft SQL Server
- MySQL og PostgreSQL
- MariaDB
Jeg vil være klar over, hvordan de adskiller sig fra resten, og hvad der adskiller dem, herunder deres ulemper. Så bringer jeg dem ind i kontekst ved at demonstrere et typisk brugseksempel fra den virkelige verden. Til sidst vil jeg dele mit syn på at vælge mellem de forskellige databaser til din sag.
Indholdsfortegnelse
AWS Oracle DB
Kilde: aws.amazon.com
Oracle DB var uden tvivl den mest udbredte kommercielle database i de sidste par årtier. Når en virksomhed havde brug for en robust og højtydende databaseløsning, var Oracle DB det første valg. Og af mange gode grunde.
Hvordan det adskiller sig
Oracle er en robust og funktionalitetsrig platform, der kan betjene en enorm mængde af endda helt forskellige opsætninger og krav. Med tiden blev denne DB den ultimative go-to-løsning, hvis du har brug for avanceret pålidelighed, skalerbarhed og vedligeholdelsesdygtighed på den lokale hardwareinfrastruktur.
Vigtigste fordele
Her er nogle af de vigtigste fordele, du får, når du vælger et så modent databasesystem som Oracle:
✅ Fantastisk support og muligheder for effektive backup- og gendannelsesaktiviteter.
✅ Bredt område af muligheder for, hvordan man tuner ydelsen af DB-løsningen inde i systemet. Selv længe efter er løsningen allerede i produktion. Support- og vedligeholdelsesaktiviteter på denne platform er virkelig nemme at konfigurere, og de er meget effektive.
✅ Høj tilpasning af DB-løsningen. Da Oracle DB understøtter en omfattende mængde funktionaliteter at vælge imellem, har du som systemintegrator masser af muligheder for at bygge et robust system bestående af præcis de funktionaliteter, som din platform har brug for (tænk triggere, partitioner, underpartitioner, automatiserede primærnøglesekvenser, visninger , snapshots, databegrænsninger, unikke nøgler, kombinerede nøgler, fremmednøgler, sammensatte indekser osv.). Den understøtter alt.
✅ Nem administration af databaseaktiviteter og processer. Dedikerede administrationskonsoller og dashboards og mange værktøjer skabt af Oracle og udelukkende dedikeret til administratorer til brug ud af boksen.
✅ Understøttelse af flerbrugermiljøer. Hvis kravet er at understøtte tusindvis af distinkte aktive brugere på samme tid, er Oracle svaret.
Vigtigste ulemper
Oracle DB er meget fleksibel med hensyn til vertikal skalering af ydeevnen. Men mindre, når du har brug for stærk vandret skalering. Det betyder, at det er nemt at opgradere til en stærkere CPU, mere hukommelse og lagerplads på en klynge-DB.
Men hvis dine data vokser markant på kort tid – hvilket er det sædvanlige tilfælde, der sker med data i skyen, bliver flaskehalsene i ydeevnen mere synlige og sværere at løse. At sprede dataene på tværs af flere klynger og forvente, at de vokser dynamisk, bliver et hovedkrav fremover. I dette tilfælde kan du opleve, at Oracle DB begynder at være mere begrænsende end at opfylde dine fremtidige behov.
En anden mulig ulempe kan være omkostningerne. Oracle DB understøtter mange funktioner, men mange af dem koster også. Endnu mere, hvis flere klynger er på plads, og fysiske præstationsopgraderinger er nødvendige. Det betyder, at softwaretuning af datamodellen ikke længere er tilstrækkelig. For at flere administrative værktøjer og funktioner er tilgængelige, skal du købe en virksomhedslicens. Dette vil øge de i forvejen høje omkostninger yderligere.
Endelig er Oracle DB ikke en indbygget AWS DB-tjeneste, hvilket betyder, at du ikke skal forvente fuld support fra AWS. Orienter dig hellere til Oracle-support. Men behandl så Oracle og AWS smertepunkter parallelt og med to forskellige sæt supportteams.
Hvornår skal man vælge
At vælge cloud-modstykket til Oracle DB er den mest naturlige beslutning at tage, når din nuværende on-premise-løsning allerede bruger Oracle DB. Det vil også gøre migreringen og skiftet til den cloud-baserede løsning så let, som det bliver.
Vælg derfor AWS Oracle DB i tilfældet:
- Du forventer, at cloud DB vil understøtte de samme processer og funktionaliteter som den lokale variant i en overskuelig fremtid.
- Du planlægger ikke at integrere DB’en med for mange native AWS-tjenester meget hurtigt.
- Du forventer ikke, at den nuværende datamængde vil vokse væsentligt i løbet af kort tid.
- Du har brug for støtte fra en enorm mængde funktionaliteter på plads. Det vil sige, at det ville være svært at miste nogle af dem på plads i øjeblikket, når du skifter til skyen.
- Dit system skal understøtte hundredvis af aktive brugere på samme tid (eller flere).
Eksempel på brug
- Store telekommunikationssystemer til fakturering, CRM og middleware-data.
- Brugerdefinerede DB-implementeringer til databasesystemer til biler, integreret med flere forskellige brugerdefinerede eller tredjepartsleverandørværktøjer.
- Pakkede systemløsninger til bankindustrien, hvor Oracle allerede er en fast del af den pakkede løsning fra leverandørerne og til sidst integrerer yderligere brugerdefinerede DB-komponenter i én kompleks implementering.
AWS Aurora DB
Kilde: aws.amazon.com
På mange måder er Aurora det direkte modsatte af Oracle, selvom det stadig er en relationel database.
Hvordan det adskiller sig
Autora DB er en indbygget databasetjeneste i AWS. AWS giver det fuld support og løbende udvikling og integrerer det dybt med resten af AWS-tjenesternes økosystem.
Aurora DB når ikke det niveau af funktionalitetsdiversificering, som Oracle allerede har. Men det blev født i skyen (i modsætning til Oracle). Da AWS videreudvikler Aurora, kan funktionalitetsgabet i sidste ende blive mindre i fremtiden, end det er i dag.
På mange måder er Aurora allerede foran Oracle, især hvad angår integration med andre AWS-skytjenester. Og da Amazon skabte Aurora med et sky-økosystem i tankerne, er Aurora klar til massiv dataindkomst og stigning over tid, så horisontal skalering er en stærk egenskab.
Vigtigste fordele
Jeg vil sige, at de vigtigste fordele ved Aurora DB er:
✅ Meget fleksibel udvidelse af skrivebeskyttede DB-kopiinstanser. Dem kan du oprette på få sekunder. Skrivebeskyttede forekomster deler de samme DB-logfiler fra hoveddatabasen, som de stammer fra. Det betyder, at oprettelse af en ny skrivebeskyttet database ikke kræver synkronisering af alle data; det gør det automatisk ved at dele de eksisterende.
✅ Klar til stor datavækst – horisontal skalering er en stor funktion i Aurora DB. Tilføjelse af nye klynger og udvidelse af skalerbarheden på tværs af forskellige tilgængelighedszoner er så enkelt, som det bliver. Aurora er så meget effektiv til at udvælge store mængder data meget hurtigt.
✅ Du kan vælge, om du vil bruge server- eller serverløs tilstand i Aurora DB. Nogle af funktionerne vil mangle i serverløs tilstand. Men du får en masse fleksibilitet og omkostningsoptimeringer, når du vælger serverløs tilstand.
✅ Automatiserede sikkerhedskopier og nem returnering på tidspunkter. Et andet højdepunkt er, at Aurora DB kan lave nemme daglige sikkerhedskopier, og at gendanne hele databasen til ethvert tidspunkt er meget enklere. Du kan kombinere alle fordelene ved cloudmiljøet her, som altid ledig plads, hurtige interne AWS-operationer og en dedikeret Aurora DB-funktion, der er rettet mod hurtige gendannelsestider og kort nedetid.
✅ Understøttelse af enten MySQL eller PostgreSQL DB-motor, så du kan vælge, hvad der passer dig.
Vigtigste ulemper
- Selvom Aurora uden tvivl er den mest funktionsrige indbyggede relationsdatabase, du kan vælge i AWS, halter den stadig bagud Oracle i denne henseende. Det er forståeligt; Oracle havde tidligere meget mere tid til at udvikle disse funktioner. Faktum er, at Aurora DB er, for hver udgivelse, stærkere og tættere.
- Der er ingen ækvivalent til Aurora DB i det lokale område. Du kan argumentere for, at gamle databaser bygget inde i MySQL- eller PostgreSQL-databaser er et tæt match – og fra et kompatibilitetsperspektiv er de det bestemt. Men de er ikke den strenge ækvivalent. Det betyder, at migreringen ikke bliver så ligetil. Du bliver nødt til at tilpasse og implementere migreringsprocesser for at sikre, at de overfører data fra stedet og gemmer dem i Aurora DB, alt sammen i det korrekte datamodelformat.
- Forskellige AWS-grænser, især de svære, er en faktor, der i nogle tilfælde kan forringe valget af denne DB som et mål for at gå fremad. Det er meget sandsynligt, at du vil være i stand til at omgå dem alle, men for nogle vil du have brug for nogle mere seriøse investeringer i refactoring, som i sidste ende kan øge de samlede omkostninger ved migrering i forhold til et andet databasemål.
Hvornår skal man vælge
I en nøddeskal er det aldrig en dårlig beslutning at vælge Aurora DB som goto relationsdatabase i AWS-platformen, men gør det, især hvis:
- Du vil bygge et cloud-system fra bunden omkring en relationsdatabase.
- Du forventer det højeste niveau af kompatibilitet og integritet med så meget som muligt forskellige native AWS-tjenester.
- Du forventer, at din datamængde vil vokse betydeligt over kort tid.
- Du planlægger at starte adskillige spin-off proofs of concept (POC) projekter, hvor du kan udnytte alle fordelene ved den serverløse version af en relationel database.
Eksempel på brug
- En serverløs platform til at analysere store mængder infrastrukturbilleddata.
- Brug af maskinlæringsmodeller til at behandle dine datasøoplysninger og generere forretningsforudsigelser for din virksomhed.
- Netflix bruger Aurora DB til hurtige parallelle forespørgselsudførelser over deres katalogdata.
AWS Microsoft SQL DB
Kilde: aws.amazon.com
Denne database er på nogle måder sammenlignelig med Oracle. Det blev også oprettet lang tid før skyen blev en ting, og der er mange nuværende on-premise-brugere, der planlægger at migrere til skyen ved at bruge MS SQL DB som kilde.
Hvordan det adskiller sig
På trods af disse ligheder er MS SQL DB stadig den, der havde meget mindre brug i fortiden sammenlignet med Oracle DB.
I det mindste at dømme ud fra mit personlige erfaringsperspektiv. Jeg var involveret i flere Oracle-projekter i løbet af de sidste to årtier, men kun i en håndfuld tilfælde, hvor MS SQL DB var involveret. Og ærligt talt kunne jeg ikke lide at beskæftige mig med det nær så meget, som jeg gjorde med Oracle DB.
I hvert fald genkender jeg stadig et stort segment af virksomheder, der bruger MS SQL DB som hoveddatabasen, der er det eneste sandhedspunkt for alle data.
Vigtigste fordele
De vigtigste fordele ved MS SQL DB har:
✅ God integration med andre Microsoft-tjenester og -software, hvis dette er en funktion, du genkender som værdifuld for din sag.
✅ Nem tilpasning med tilpassede kodeudvidelser, for det meste i form af Javascript-kodemoduler. Dette kan være nyttigt, når man har at gøre med mere komplekse forretningsprocesser og opgaver, der skal planlægges over databasen.
✅ Ret simpelt fra et administrationsperspektiv (i hvert fald i forhold til Oracle DB).
✅ Det giver sandsynligvis meget mere mening i Azures cloud-økosystem, da det der betragtes som et naturligt relationelt databasesystem, meget mere kompatibelt med andre cloud-tjenester der.
Vigtigste ulemper
- På samme måde som i Oracle DB-sagen skal al support og problemløsning, som en ikke-native database i AWS-skyen, køres via separate dedikerede MS SQL-supportteams.
- Mindre diversificering af funktionalitetsunderstøttelse generelt, når man sammenligner det med Oracle DB eller Aurora DB.
- Ikke egnet til et stort antal aktive brugere.
- Horisontal skalerbarhed er et endnu større problem end med Oracle DB-kabinettet.
Hvornår skal man vælge
MS SQL DB er bedst egnet, hvis du ønsker at migrere den eksisterende MS SQL DB on-premise til skyen med så få distraktioner rundt omkring som muligt. Du forventer heller ikke den integration med andre AWS cloud-tjenester i særlig grad.
Så vil MS SQL DB leve inde i AWS-skyen som en fuldt administreret database med ubegrænset lagerplads og udvidede muligheder for horisontal skalerbarhed og høj tilgængelighed sammenlignet med det lokale alternativ.
Eksempel på brug
- Fungerer som en mellemgrundsplatform for tilpasset integration af forskellige databasesystemer (kan endda være af en anden type, f.eks. Oracle DB).
- Forskellige mindre projekter, hvor omkostningerne ved databaseløsningen er en ting at overveje, og budgettet er mere begrænset (og ikke tillader at gå efter en fuldgyldig Oracle DB-løsning).
AWS MySQL og PostgreSQL DB
Kilde: aws.amazon.com
Disse databaser er begge open source af oprindelse (selv om de nu allerede er købt af større virksomheder), hvilket i sidste ende giver dem både fordele og ulemper.
De er heller ikke så funktionelle som andre alternativer, især i deres oprindelige form. Og selvom du stadig kan bruge dem begge i AWS-infrastruktur i denne form, tvivler jeg på, at dette stadig giver for meget praktisk mening.
Hvordan det adskiller sig
Når du migrerer den lokale DB (det være sig MySQL eller PostgreSQL) til AWS-skyen, kan du bare bruge Aurora direkte med MySQL- eller PostgreSQL-motoren som mål og dermed få alle de ekstra fordele, Aurora DB har at tilbyde.
Selvfølgelig vil det betyde en ekstra indsats for migrationsfasen i forhold til tilfældet, hvor et naturligt alternativ ville blive valgt. Men den ekstra indsats vil kun være marginal.
Deres største fordel ligger i omkostningerne, og at de egner sig bedst til små projektinitiativer, hvor robusthed egentlig ikke er et emne.
Vigtigste ulemper
- Begge er ret begrænset i understøttet funktionalitet, og du skal være forberedt på begrænsede muligheder for vedligeholdelse og administration.
- Ikke egnet til store projekter med mange aktive brugere.
- Ikke bedst til højtydende løsninger, og hvor konstant justering af ydeevne er et stærkt krav.
Hvornår skal man vælge
- Hvis omkostninger er hovedemnet, og budgettet er meget begrænset.
- Hvis projektinitiativet er ret lille.
- Hvis datamængden er ret lille, og der ikke er planer om væsentlig vækst.
Eksempel på brug
- Personlige projektinitiativer, hvor omkostningerne til infrastrukturen skal være så minimale som muligt.
- Små POC’er, der ville bevise, at det foreslåede koncept kan realiseres.
- Små virksomheders projekter med små mængder data.
- For små SaaS-projekter, der ikke kræver en omfattende mængde af databasebelastninger, er blot datalagring på en relationel datamodelmåde alt, der virkelig kræves.
AWS MariaDB
Kilde: aws.amazon.com
MariaDB er stadig en fuldstændig open source-database skabt af tidligere MySQL-udviklere (efter MySQL’s erhvervelse af Oracle).
Med hensyn til kompatibilitet vil enhver MySQL DB køre fint inde i MariaDB.
Hvordan det adskiller sig
Funktionsmæssigt er der ikke mange forskelle fra MySQL at forvente, men open source-egenskaben er højdepunktet.
Teknisk set er der en del nyttige funktioner, der er tilgængelige i MariaDB, men ikke i MySQL.
Vigtigste ulemper
Ganske lig MySQL-sagen.
Hvornår skal man vælge
- Hvis du absolut elsker din nuværende MariaDB on-premise implementering og ikke ønsker at migrere til Aurora DB, uanset årsagen.
- Hvis du vil forblive ægte open source med din databaseløsning inde i AWS cloud-økosystemet.
Eksempel på brug
Ganske lig MySQL-sagen.
Afsluttende ord
På samme måde, da Oracle DB var løsningen i on-premise-verdenen, ser det ud til, at Aurora DB indtager denne plads i AWS-skyverdenen. I det mindste set fra funktionssættenes perspektiv er dette det tætteste, du kan komme.
Og selvom du ikke rigtig er ude efter de vigtigste interessenter, er det godt at vide, at der stadig er ret enkle muligheder for, hvordan du migrerer din eksisterende database til AWS-skyen.
Endnu bedre – med denne switch får du automatisk funktioner, som du højst sandsynligt manglede indtil da. Vigtigst af alt er bedre lagerudvidelsesmuligheder, høj tilgængelighed og horisontal skalerbarhed alle native funktioner i cloudmiljøet.