Hur jämförs AWS relationsdatabaser

av

En relationsdatabas var länge en ganska standardlösning för olika (och nästan alla) programvaruanvändningsfall som stora eller små företag var tvungna att lösa.

Idag är variationen mycket högre med den bredare tillgängligheten av NoSQL-, in-memory- eller data lake-databaser. Men trots det, närhelst beslutet tas att migrera aktuella lokala databaser till molnet, är relationsdatabasen som mål fortfarande det enklaste alternativet för denna övergång.

Vi kommer att titta närmare på följande databaser som kan vara en del av ett sådant initiativ:

  • Orakel
  • Aurora
  • Microsoft SQL Server
  • MySQL & PostgreSQL
  • MariaDB

Jag kommer att vara tydlig med hur de skiljer sig från resten och vad som skiljer dem åt, inklusive deras nackdelar. Sedan ska jag föra in dem i sitt sammanhang genom att demonstrera ett typiskt verkligt användningsexempel. Slutligen ska jag dela med mig av min syn på att välja mellan de olika databaserna för ditt fall.

AWS Oracle DB

Källa: aws.amazon.com

Oracle DB var utan tvekan den mest använda kommersiella databasen under de senaste decennierna. Närhelst ett företag behövde en robust och högpresterande databaslösning var Oracle DB förstahandsvalet. Och av många goda skäl.

Hur det skiljer sig

Oracle är en robust och funktionsrik plattform som kan tjäna en enorm mängd till och med helt olika inställningar och krav. Med tiden blev denna DB den ultimata go-to-lösningen om du behöver den senaste tillförlitligheten, skalbarheten och underhållsbarheten på den lokala hårdvaruinfrastrukturen.

Huvudsakliga fördelar

Här är några av de främsta fördelarna du får när du väljer ett så moget databassystem som Oracle:

✅ Bra stöd och alternativ för effektiv säkerhetskopiering och återställning.

✅ Brett område av möjligheter för hur man ställer in prestandan för DB-lösningen inuti systemet. Även långt efter är lösningen redan i produktion. Support- och underhållsaktiviteter på den här plattformen är väldigt enkla att ställa in och de är mycket effektiva.

✅ Hög anpassning av DB-lösningen. Eftersom Oracle DB stöder en omfattande mängd funktioner att välja mellan, har du som systemintegratör massor av alternativ att bygga ett robust system bestående av exakt de funktioner som din plattform behöver (tänk triggers, partitioner, underpartitioner, automatiserade primärnycklarsekvenser, vyer , ögonblicksbilder, databegränsningar, unika nycklar, kombinerade nycklar, främmande nycklar, sammansatta index, etc.). Den stöder allt.

✅ Enkel administration av databasaktiviteter och processer. Dedikerade administrationskonsoler och instrumentpaneler, och många verktyg skapade av Oracle och dedikerade enbart till administratörer att använda direkt.

✅ Stöd för fleranvändarmiljöer. Om kravet är att stödja tusentals distinkta aktiva användare samtidigt är Oracle svaret.

Huvudsakliga nackdelar

Oracle DB är mycket flexibel när det gäller vertikal skalning av prestanda. Men mindre när du behöver stark horisontell skalning. Det betyder att det är enkelt att uppgradera till en starkare CPU, mer minne och lagringsutrymme på en kluster-DB.

Men om din data växer avsevärt på kort tid – vilket är det vanliga fallet som händer med data i molnet, kommer prestandaflaskhalsarna att bli mer synliga och svårare att lösa. Att sprida data över flera kluster och förvänta sig att de ska växa dynamiskt kommer att bli ett huvudkrav framöver. I det här fallet kanske du upptäcker att Oracle DB börjar vara mer begränsande än att uppfylla dina framtida behov.

En annan möjlig nackdel kan vara kostnaden. Oracle DB stöder många funktioner, men många av dem kostar också. Ännu mer så om flera kluster finns på plats och fysiska prestandauppgraderingar är nödvändiga. Det betyder att mjukvarujustering av datamodellen inte räcker längre. För att fler administrativa verktyg och funktioner ska vara tillgängliga måste du köpa en företagslicens. Detta kommer att öka de redan höga kostnaderna ytterligare.

Slutligen är Oracle DB inte en inbyggd AWS DB-tjänst, vilket betyder att du inte ska förvänta dig fullt stöd från AWS. Inrikta dig hellre på Oracle-support. Men hantera Oracle och AWS smärtpunkter parallellt och med två olika uppsättningar av supportteam.

När ska man välja

Att välja molnets motsvarighet till Oracle DB är det mest naturliga beslutet att ta närhelst din nuvarande lokala lösning redan använder Oracle DB. Det kommer också att göra migreringen och bytet till den molnbaserade lösningen så enkel som den blir.

Välj därför AWS Oracle DB i fallet:

  • Du förväntar dig att molnet DB kommer att stödja samma processer och funktioner som den lokala varianten under överskådlig framtid.
  • Du planerar inte att integrera DB med för många inbyggda AWS-tjänster mycket snabbt.
  • Du förväntar dig inte att den nuvarande datamängden kommer att växa märkbart på kort tid.
  • Du behöver stöd av en stor mängd funktioner på plats. Det vill säga, det skulle vara svårt att tappa några av dem på plats när man byter till molnet.
  • Ditt system måste stödja hundratals aktiva användare samtidigt (eller fler).

Exempel på användning

  • Stora telekommunikationssystem för fakturering, CRM och mellanprogram.
  • Anpassade DB-implementationer för databassystem för fordon, integrerade med flera olika anpassade eller tredjepartsleverantörsverktyg.
  • Paketerade systemlösningar för bankbranschen, där Oracle redan är en fast del av den paketerade lösningen från leverantörerna och så småningom integrerar ytterligare anpassade DB-komponenter i en komplex implementering.

AWS Aurora DB

Källa: aws.amazon.com

På många sätt är Aurora den raka motsatsen till Oracle, även om det fortfarande är en relationsdatabas.

Hur det skiljer sig

Autora DB är en inbyggd databastjänst i AWS. AWS ger det fullt stöd och pågående utveckling och integrerar det på djupet med resten av AWS-tjänsternas ekosystem.

Aurora DB når inte den nivån av funktionalitetsdiversifiering som Oracle redan har. Men det föddes i molnet (till skillnad från Oracle). Eftersom AWS vidareutvecklar Aurora kan funktionsgapet så småningom bli mindre i framtiden än vad det är idag.

På många sätt ligger Aurora redan före Oracle, särskilt när det gäller integration med andra AWS molntjänster. Och eftersom Amazon skapade Aurora med ett moln-ekosystem i åtanke, är Aurora redo för massiva datainkomster och ökningar över tid, så horisontell skalning är en stark egenskap.

Huvudsakliga fördelar

Jag skulle säga att de främsta fördelarna med Aurora DB är:

✅ Mycket flexibel utbyggnad av skrivskyddade DB-kopieringsinstanser. De kan du skapa på bara några sekunder. Skrivskyddade instanser delar samma DB-loggar för huvuddatabasen som de kommer från. Det betyder att skapa en ny skrivskyddad databas inte kräver synkronisering av all data; det gör det automatiskt genom att dela de befintliga.

✅ Klart för stor datatillväxt – horisontell skalning är en stor egenskap hos Aurora DB. Att lägga till nya kluster och utöka skalbarheten över olika tillgänglighetszoner är hur enkelt som helst. Aurora är då mycket effektiv i att välja ut stora mängder data mycket snabbt.

✅ Du kan välja om du vill använda server- eller serverlöst läge för Aurora DB. Några av funktionerna kommer att saknas i serverlöst läge. Men du får mycket flexibilitet och kostnadsoptimeringar när du väljer serverlöst läge.

✅ Automatiserade säkerhetskopieringar och enkel återställning vid tidpunkten. En annan höjdpunkt är att Aurora DB kan göra enkla dagliga säkerhetskopieringar, och att återställa hela databasen till vilken tidpunkt som helst är mycket enklare. Du kan kombinera alla fördelar med molnmiljön här, som alltid tillgängligt ledigt utrymme, snabba inre AWS-operationer och en dedikerad Aurora DB-funktion som riktar sig till snabba återställningstider och korta stillestånd.

✅ Stöd för antingen MySQL eller PostgreSQL DB-motor, så att du kan välja vad som passar dig.

Huvudsakliga nackdelar

  • Även om Aurora utan tvekan är den mest funktionsrika inbyggda relationsdatabasen du kan välja i AWS, släpar den fortfarande efter Oracle i detta avseende. Det är förståeligt; Oracle hade mycket mer tid att utveckla dessa funktioner tidigare. Faktum kvarstår att Aurora DB är, för varje release, starkare och närmare.
  • Det finns ingen motsvarighet till Aurora DB i det lokala utrymmet. Du kan hävda att gamla databaser byggda inuti MySQL- eller PostgreSQL-databaser är en nära match – och ur ett kompatibilitetsperspektiv är de det säkert. Men de är inte den strikta motsvarigheten. Det betyder att migreringen inte kommer att vara så okomplicerad. Du kommer att behöva anpassa och implementera migreringsprocesser för att säkerställa att de överför data från lokalt och lagrar det i Aurora DB, allt i rätt datamodellformat.
  • Olika AWS-gränser, särskilt de svåra, är en faktor som i vissa fall kan förringa valet av denna DB som mål att gå vidare. Det är mycket troligt att du kommer att kunna kringgå dem alla, men för vissa kommer du att behöva några mer seriösa investeringar i refaktorering, vilket i slutändan kan öka de totala kostnaderna för migrering jämfört med ett annat databasmål.

När ska man välja

I ett nötskal, att välja Aurora DB som goto relationsdatabasen i AWS-plattformen är aldrig ett dåligt beslut, men gör det, särskilt om:

  • Du kommer att bygga ett molnsystem från grunden kring en relationsdatabas.
  • Du förväntar dig högsta nivå av kompatibilitet och integritet med så mycket som möjligt olika inbyggda AWS-tjänster.
  • Du förväntar dig att din datavolym kommer att växa betydligt under en kort tid.
  • Du planerar att starta flera spin-off proofs of concept-projekt (POC) där du kan utnyttja alla fördelarna med den serverlösa versionen av en relationsdatabas.

Exempel på användning

  • En serverlös plattform för att analysera stora mängder infrastrukturbilddata.
  • Användning av maskininlärningsmodeller för att bearbeta din datasjöinformation och generera affärsförutsägelser för ditt företag.
  • Netflix använder Aurora DB för snabba parallella frågekörningar över deras katalogdata.

AWS Microsoft SQL DB

Källa: aws.amazon.com

Denna databas är på vissa sätt jämförbar med Oracle. Det skapades också en lång tid innan molnet blev en grej, och det finns många nuvarande lokala användare som planerar att migrera till molnet med MS SQL DB som källa.

Hur det skiljer sig

Trots dessa likheter är MS SQL DB fortfarande den som hade mycket mindre användning tidigare jämfört med Oracle DB.

Åtminstone att döma utifrån mitt personliga erfarenhetsperspektiv. Jag var involverad i flera Oracle-projekt under de senaste två decennierna, men bara i en handfull fall där MS SQL DB var inblandad. Och ärligt talat gillade jag inte att ta itu med det i närheten av så mycket som jag gjorde med Oracle DB.

Hur som helst, jag känner fortfarande igen ett stort segment av företag som använder MS SQL DB som huvuddatabas som är den enda sanningspunkten för all data.

Huvudsakliga fördelar

Huvudfördelarna med MS SQL DB har:

✅ Bra integration med andra Microsoft-tjänster och programvara, om detta är en funktion som du känner igen som värdefull för ditt fall.

✅ Enkel anpassning med anpassade kodtillägg, mestadels i form av Javascript-kodmoduler. Detta kan vara användbart när man hanterar mer komplexa affärsprocesser och jobb som ska schemaläggas över databasen.

✅ Ganska enkelt ur ett administrationsperspektiv (åtminstone i jämförelse med Oracle DB).

✅ Det är förmodligen mycket mer meningsfullt i Azures moln-ekosystem, eftersom det där anses vara ett inbyggt relationsdatabassystem, mycket mer kompatibelt med andra molntjänster där.

Huvudsakliga nackdelar

  • På samma sätt som i Oracle DB-fallet, som en icke-inbyggd databas i AWS-molnet, måste all support och problemlösning drivas via separata dedikerade MS SQL-supportteam.
  • Mindre diversifiering av funktionalitetsstöd i allmänhet när man jämför det med Oracle DB eller Aurora DB.
  • Inte lämplig för ett stort antal aktiva användare.
  • Horisontell skalbarhet är ett ännu större problem än med Oracle DB-fodralet.

När ska man välja

MS SQL DB är bäst lämpad om du vill migrera den befintliga MS SQL DB på plats till molnet med så få distraktioner som möjligt. Du förväntar dig inte heller den integrationen med andra AWS molntjänster i någon större utsträckning.

Då kommer MS SQL DB att leva inuti AWS-molnet som en helt hanterad databas med obegränsad lagring och utökade alternativ för horisontell skalbarhet och hög tillgänglighet jämfört med det lokala alternativet.

Exempel på användning

  • Fungerar som en mellanplattform för anpassad integration av olika databassystem (kan till och med vara av en annan typ, till exempel Oracle DB).
  • Olika mindre skala projekt där kostnaden för databaslösningen är en sak att överväga, och budgeten är mer begränsad (och inte tillåter att gå för en fullfjädrad Oracle DB-lösning).

AWS MySQL och PostgreSQL DB

Källa: aws.amazon.com

Dessa databaser är båda öppen källkod till ursprung (även om de nu redan köpts av större företag), vilket i slutändan ger dem både fördelar och nackdelar.

De är inte heller lika funktionsrika som andra alternativ, särskilt i sin ursprungliga form. Och även om du fortfarande kan använda dem båda i AWS-infrastruktur i denna form, tvivlar jag på att detta fortfarande är för mycket praktiskt vettigt.

Hur det skiljer sig

När du migrerar den lokala DB (oavsett om det är MySQL eller PostgreSQL) till AWS-molnet, kan du bara direkt använda Aurora med MySQL- eller PostgreSQL-motorn som mål och på så sätt få alla ytterligare fördelar som Aurora DB har att erbjuda.

Visst, det kommer att innebära ytterligare ansträngningar för migrationsfasen i jämförelse med fallet när ett inhemskt alternativ skulle väljas. Men den ytterligare ansträngningen kommer bara att vara marginell.

Deras främsta vinst ligger i kostnaderna och att de lämpar sig bäst för små projektinitiativ, där robusthet egentligen inte är ett ämne.

Huvudsakliga nackdelar

  • Båda har ganska begränsade funktioner som stöds, och du måste vara beredd på begränsade alternativ för underhåll och administration.
  • Inte lämplig för storskaliga projekt med många aktiva användare.
  • Inte bäst för högpresterande lösningar och där konstant prestandajustering är ett starkt krav.

När ska man välja

  • Om kostnaden är huvudämnet och budgeten är mycket begränsad.
  • Om projektinitiativet är ganska litet.
  • Om datamängden är ganska liten och det inte finns några planer på betydande tillväxt.

Exempel på användning

  • Personliga projektinitiativ där kostnaden för infrastrukturen ska vara så minimal som möjligt.
  • Små POCs som skulle bevisa att det föreslagna konceptet kan förverkligas.
  • Små företags projekt med små mängder data.
  • För små SaaS-projekt, som inte kräver en omfattande mängd databasbelastningar, är bara datalagring i ett relationsdatamodellsätt allt som verkligen krävs.

AWS MariaDB

Källa: aws.amazon.com

MariaDB är fortfarande en helt öppen källkodsdatabas skapad av tidigare MySQL-utvecklare (efter MySQL:s förvärv av Oracle).

När det gäller kompatibilitet kommer alla MySQL DB att fungera bra i MariaDB.

Hur det skiljer sig

Funktionsmässigt finns det inte många skillnader från MySQL att förvänta sig, men open source-egenskapen är höjdpunkten.

Tekniskt sett finns det en hel del användbara funktioner som är tillgängliga i MariaDB men inte i MySQL.

Huvudsakliga nackdelar

Ganska likt MySQL-fallet.

När ska man välja

  • Om du absolut älskar din nuvarande MariaDB-implementering på plats och inte vill migrera till Aurora DB, oavsett anledning.
  • Om du vill vara verkligt öppen källkod med din databaslösning i AWS moln ekosystem.

Exempel på användning

Ganska likt MySQL-fallet.

Slutord

På samma sätt, eftersom Oracle DB var lösningen i den lokala världen, verkar det som att Aurora DB tar denna plats i AWS molnvärld. Åtminstone ur funktionsuppsättningarnas perspektiv är detta det närmaste du kan komma.

Och även om du inte riktigt är ute efter de viktigaste intressenterna är det bra att veta att det fortfarande finns ganska enkla alternativ för hur du migrerar din befintliga databas till AWS-molnet.

Ännu bättre – med den här switchen får du automatiskt funktioner som du troligen saknade fram till dess. Det viktigaste är att bättre lagringsmöjligheter, hög tillgänglighet och horisontell skalbarhet är alla inbyggda funktioner i molnmiljön.