A relációs adatbázis hosszú ideig meglehetősen standard megoldás volt különféle (és szinte minden) szoftverhasználati esetekre, amelyeket nagy vagy kis cégeknek kellett megoldaniuk.
Manapság a változatosság sokkal nagyobb a NoSQL, a memórián belüli vagy a Data Lake adatbázisok szélesebb körű elérhetősége miatt. Ennek ellenére, amikor úgy döntenek, hogy a jelenlegi helyszíni adatbázisokat áttelepítik a felhőbe, a relációs adatbázis célként továbbra is a legegyszerűbb lehetőség az átálláshoz.
Az alábbi adatbázisokat vizsgáljuk meg közelebbről, amelyek részei lehetnek egy ilyen kezdeményezésnek:
- Jóslat
- Hajnal
- Microsoft SQL Server
- MySQL és PostgreSQL
- MariaDB
Világos leszek, miben különböznek a többitől, és miben különböznek egymástól, beleértve a hátrányaikat is. Ezután kontextusba hozom őket egy tipikus valós használati példa bemutatásával. Végül megosztom a véleményemet a különböző adatbázisok közötti döntésről az Ön esetében.
Tartalomjegyzék
AWS Oracle DB
Forrás: aws.amazon.com
Az Oracle DB kétségtelenül a legszélesebb körben használt kereskedelmi adatbázis volt az elmúlt néhány évtizedben. Amikor egy vállalatnak robusztus és nagy teljesítményű adatbázis-megoldásra volt szüksége, az Oracle DB volt az első választás. És sok jó okból.
Hogyan különbözik
Az Oracle egy robusztus és funkcionalitásban gazdag platform, amely hatalmas mennyiségű, akár teljesen eltérő beállítást és követelményt is képes kiszolgálni. Idővel ez a DB lett a tökéletes megoldás arra az esetre, ha a legkorszerűbb megbízhatóságra, méretezhetőségre és karbantarthatóságra van szüksége a helyszíni hardverinfrastruktúrán élve.
Fő előnyei
Íme néhány fő előny, amellyel egy olyan kiforrott adatbázisrendszert választ, mint az Oracle:
✅ Nagyszerű támogatás és lehetőségek a hatékony biztonsági mentési és visszaállítási tevékenységekhez.
✅ Széles lehetőség a DB megoldás teljesítményének rendszeren belüli hangolására. Még jóval később a megoldás már gyártásban van. A platformon belüli támogatási és karbantartási tevékenységek nagyon egyszerűen beállíthatók, és nagyon hatékonyak.
✅ A DB megoldás magas szintű testreszabhatósága. Mivel az Oracle DB számos funkció közül választhat, Önnek rendszerintegrátorként rengeteg lehetősége van egy robusztus rendszer felépítésére, amely pontosan azokból a funkciókból áll, amelyekre a platformnak szüksége van (gondoljunk csak triggerekre, partíciókra, alpartíciókra, automatizált elsődleges kulcssorozatokra, nézetekre , pillanatképek, adatmegszorítások, egyedi kulcsok, kombinált kulcsok, idegen kulcsok, összetett indexek stb.). Mindent támogat.
✅ Az adatbázis-tevékenységek és folyamatok egyszerű adminisztrálása. Dedikált adminisztrációs konzolok és irányítópultok, valamint számos, az Oracle által létrehozott és kizárólag a rendszergazdáknak szánt eszköz, amelyet a dobozból kivetve használhatnak.
✅ Többfelhasználós környezetek támogatása. Ha a követelmény több ezer különálló aktív felhasználó egyidejű támogatása, az Oracle a válasz.
Főbb hátrányok
Az Oracle DB nagyon rugalmas a teljesítmény függőleges skálázását illetően. De kevésbé, ha erős vízszintes skálázásra van szüksége. Ez azt jelenti, hogy könnyű frissíteni erősebb CPU-ra, több memóriára és tárhelyre a fürt DB-n.
De ha az adatok rövid időn belül jelentősen gyarapodnak – ami a felhőben tárolt adatokkal általában megtörténik, akkor a teljesítmény szűk keresztmetszete láthatóbbá és nehezebben megoldhatóvá válik. Az adatok több fürt között való szétosztása és dinamikus növekedésük elvárása a jövőben fő követelmény lesz. Ebben az esetben előfordulhat, hogy az Oracle DB kezd korlátozóbbnak lenni, mint a jövőbeni szükségletek kielégítése.
Egy másik lehetséges hátrány a költség lehet. Az Oracle DB számos szolgáltatást támogat, de ezek közül soknak is van költsége. Még inkább, ha több klaszter is működik, és a fizikai teljesítmény frissítésére van szükség. Ez azt jelenti, hogy az adatmodell szoftveres hangolása már nem elegendő. Ha további adminisztrációs eszközöket és funkciókat szeretne elérni, vállalati licencet kell vásárolnia. Ez tovább növeli az amúgy is magas költségeket.
Végül, az Oracle DB nem egy natív AWS DB szolgáltatás, ami azt jelenti, hogy nem számíthat teljes támogatásra az AWS-től. Inkább az Oracle támogatására tájékozódjon. De akkor az Oracle és az AWS fájdalompontjaival párhuzamosan és két különböző támogató csoporttal foglalkozzon.
Mikor válasszunk
Az Oracle DB felhőalapú megfelelőjének kiválasztása a legtermészetesebb döntés, amikor a jelenlegi helyszíni megoldás már használja az Oracle DB-t. A migrációt és a felhőalapú megoldásra való átállást is a lehető legegyszerűbbé teszi.
Ezért válassza az AWS Oracle DB-t a következő esetekben:
- Várhatóan a felhőalapú DB ugyanazokat a folyamatokat és funkciókat fogja támogatni, mint a helyszíni változat a belátható jövőben.
- Nem tervezi túl gyorsan integrálni a DB-t túl sok AWS natív szolgáltatással.
- Nem számít arra, hogy a jelenlegi adatmennyiség rövid időn belül jelentősen növekedni fog.
- Hatalmas mennyiségű rendelkezésre álló funkció támogatására van szüksége. Vagyis felhőre váltáskor nehéz lenne néhányat elveszíteni a jelenleg helyükön.
- A rendszernek egyszerre több száz (vagy több) aktív felhasználót kell támogatnia.
Használati példa
- Nagy telekommunikációs rendszerek számlázási, CRM- és köztes szoftver adatokhoz.
- Egyedi adatbázis-megvalósítások autóipari adatbázis-rendszerekhez, számos különböző egyéni vagy harmadik féltől származó eszközzel integrálva.
- Csomagolt rendszermegoldások a bankszektor számára, ahol az Oracle már a szállítóktól származó csomagolt megoldás rögzített része, és végül további egyedi DB-összetevőket integrál egyetlen komplex megvalósításba.
AWS Aurora DB
Forrás: aws.amazon.com
Az Aurora sok szempontból az Oracle közvetlen ellentéte, még akkor is, ha ez még mindig relációs adatbázis.
Hogyan különbözik
Az Autora DB egy natív adatbázis-szolgáltatás az AWS-ben. Az AWS teljes körű támogatást és folyamatos fejlesztést biztosít, és mélyen integrálja az AWS-szolgáltatások ökoszisztémájának többi részével.
Az Aurora DB nem éri el a funkcionalitás diverzifikációjának azt a szintjét, mint az Oracle. De a felhőben született (ellentétben az Oracle-lel). Mivel az AWS továbbfejleszti az Aurorát, a funkcionalitásbeli hiány a jövőben kisebb lehet, mint ma.
Az Aurora sok tekintetben már megelőzi az Oracle-t, különösen a többi AWS felhőszolgáltatással való integráció tekintetében. És mivel az Amazon a felhő-ökoszisztémát szem előtt tartva hozta létre az Aurorát, az Aurora készen áll a hatalmas adatbevételre és az idő múlásával történő növekedésre, így a vízszintes méretezés erős tulajdonság.
Fő előnyei
Azt mondanám, hogy az Aurora DB fő előnyei a következők:
✅ Nagyon rugalmasan bővíthető a csak olvasható DB másolatpéldányok. Amik pillanatok alatt létrehozhatók. A csak olvasható példányok ugyanazokat a DB naplókat osztják meg a fő adatbázisban, amelyből származnak. Ez azt jelenti, hogy egy új, csak olvasható adatbázis létrehozásához nincs szükség az összes adat szinkronizálására; automatikusan megteszi a meglévők megosztásával.
✅ Nagy adatbővítésre kész – a vízszintes méretezés az Aurora DB nagy jellemzője. Új fürtök hozzáadása és a skálázhatóság kiterjesztése a különböző rendelkezésre állási zónákra a lehető legegyszerűbb. Az Aurora így nagyon hatékonyan képes nagy mennyiségű adatot nagyon gyorsan kiválasztani.
✅ Kiválaszthatja, hogy az Aurora DB szerver vagy szerver nélküli módját használja. Néhány szolgáltatás hiányzik szerver nélküli módban. A kiszolgáló nélküli mód kiválasztásakor azonban sok rugalmasságot és költségoptimalizálást kaphat.
✅ Automatikus biztonsági mentések és egyszerű visszaállítás az adott időpontban. Egy másik kiemelés, hogy az Aurora DB egyszerű napi biztonsági mentéseket tud készíteni, és a teljes adatbázis bármikori visszaállítása sokkal egyszerűbb. Itt kombinálhatja a felhőkörnyezet összes előnyét, mint mindig rendelkezésre álló szabad terület, gyors belső AWS műveletek és egy dedikált Aurora DB funkció, amely gyors helyreállítási időt és rövid állásidőt céloz meg.
✅ A MySQL vagy a PostgreSQL DB motor támogatása, így kiválaszthatja a megfelelőt.
Főbb hátrányok
- Annak ellenére, hogy az Aurora vitathatatlanul a leginkább funkciókban gazdag natív relációs adatbázis, amelyet az AWS-ben választhat, e tekintetben még mindig le van maradva az Oracle mögött. Ez érthető; Az Oracle-nek a múltban sokkal több ideje volt ezen funkciók fejlesztésére. Az a tény, hogy az Aurora DB minden kiadással erősebb és közelebb kerül.
- A helyszíni térben nincs megfelelője az Aurora DB-nek. Vitatkozhat amellett, hogy a MySQL vagy PostgreSQL adatbázisokba épített régi adatbázisok szorosan illeszkednek egymáshoz – kompatibilitási szempontból pedig biztosan így van. De nem a szigorú megfelelője. Ez azt jelenti, hogy a migráció nem lesz ilyen egyszerű. Testre kell szabnia és végre kell hajtania az áttelepítési folyamatokat annak biztosítására, hogy a helyszíni adatokat továbbítsák és az Aurora DB-ben tárolják, mindezt a megfelelő adatmodell-formátumban.
- A különféle AWS-korlátok, különösen a szigorúak, olyan tényezők, amelyek bizonyos esetekben ronthatják a DB kiválasztását a továbblépéshez. Nagyon valószínű, hogy képes lesz mindegyiket megkerülni, de egyesek esetében komolyabb befektetésre lesz szükség az átalakításba, ami végső soron megnövelheti a migráció általános költségeit egy másik adatbázis-célhoz képest.
Mikor válasszunk
Dióhéjban, az Aurora DB kiválasztása goto relációs adatbázisként az AWS platformon soha nem rossz döntés, de tegye ezt, különösen, ha:
- Felhőrendszert fog felépíteni a semmiből egy relációs adatbázis köré.
- A lehető legmagasabb szintű kompatibilitást és integritást várja el a lehető legtöbb különböző natív AWS-szolgáltatással.
- Arra számít, hogy az adatmennyiség rövid időn belül jelentősen megnő.
- Azt tervezi, hogy több spin-off koncepciópróba (POC) projektet indít, ahol kihasználhatja a relációs adatbázis kiszolgáló nélküli verziójának minden előnyét.
Használati példa
- Szerver nélküli platform nagy mennyiségű infrastrukturális képadat elemzésére.
- Gépi tanulási modellek használata a Data Lake-információk feldolgozásához és üzleti előrejelzések generálásához a vállalkozás számára.
- A Netflix az Aurora DB-t használja a gyors párhuzamos lekérdezések végrehajtásához a katalógusadatokon keresztül.
AWS Microsoft SQL DB
Forrás: aws.amazon.com
Ez az adatbázis bizonyos szempontból összehasonlítható az Oracle-lel. Azt is jóval azelőtt hozták létre, hogy a felhőből dolog lett volna, és sok jelenlegi helyszíni felhasználó tervezi a felhőbe való migrálást, forrásként az MS SQL DB-t használva.
Hogyan különbözik
A hasonlóságok ellenére az MS SQL DB még mindig az, amely sokkal kevesebbet használt a múltban, mint az Oracle DB.
Legalábbis személyes tapasztalataim alapján. Az elmúlt két évtizedben több Oracle projektben is részt vettem, de csak néhány olyan esetben, amikor MS SQL DB volt érintett. És őszintén szólva, közel sem szerettem vele annyira foglalkozni, mint az Oracle DB-vel.
Mindenesetre még mindig elismerem, hogy a vállalatok nagy része az MS SQL DB-t használja fő adatbázisként, amely az összes adat egyetlen igazságpontja.
Fő előnyei
Az MS SQL DB fő előnyei:
✅ Jó integráció más Microsoft-szolgáltatásokkal és -szoftverekkel, abban az esetben, ha ezt a funkciót értékesnek ismeri el az Ön esetében.
✅ Egyszerű testreszabás egyedi kódkiterjesztésekkel, többnyire Javascript kódmodulok formájában. Ez hasznos lehet összetettebb üzleti folyamatok és az adatbázison keresztül ütemezendő feladatok kezelésekor.
✅ Adminisztrációs szempontból meglehetősen egyszerű (legalábbis az Oracle DB-hez képest).
✅ Valószínűleg sokkal értelmesebb az Azure felhő ökoszisztémában, mivel ott natív relációs adatbázisrendszernek számít, sokkal jobban kompatibilis a többi felhőszolgáltatással.
Főbb hátrányok
- Az Oracle DB esetéhez hasonlóan az AWS felhő terében nem natív adatbázisként minden támogatást és problémamegoldást külön dedikált MS SQL támogatási csapatokon keresztül kell végrehajtani.
- Kevésbé diverzifikált a funkcionalitás támogatása általában, ha összehasonlítjuk az Oracle DB-vel vagy az Aurora DB-vel.
- Nem alkalmas nagyszámú aktív felhasználó számára.
- A vízszintes méretezhetőség még nagyobb probléma, mint az Oracle DB esetében.
Mikor válasszunk
Az MS SQL DB akkor a legalkalmasabb, ha a meglévő MS SQL DB-t a lehető legkevesebb zavaró tényezővel szeretné áttelepíteni a felhőbe. Ezen túlmenően nem számíthat erre az integrációra más AWS felhőszolgáltatásokkal.
Ezután az MS SQL DB teljesen felügyelt adatbázisként fog élni az AWS felhőben, korlátlan tárhellyel és kiterjesztett lehetőségekkel a horizontális méretezhetőség és a magas rendelkezésre állás a helyszíni alternatívához képest.
Használati példa
- Köztes platformként működik különféle adatbázis-rendszerek egyedi integrációjához (akár más típusú is lehet, például Oracle DB).
- Különféle kisebb léptékű projektek, ahol az adatbázis-megoldás költsége megfontolandó, a költségvetés pedig korlátozottabb (és nem teszi lehetővé a teljes értékű Oracle DB megoldást).
AWS MySQL és PostgreSQL DB
Forrás: aws.amazon.com
Ezek az adatbázisok eredetüket tekintve egyaránt nyílt forráskódúak (bár ma már nagyobb cégek vásárolták meg), ami végső soron előnyökkel és hátrányokkal is jár.
Nem is olyan funkciókban gazdagok, mint más alternatívák, különösen eredeti formájukban. És bár továbbra is használhatja mindkettőt az AWS infrastruktúrájában ebben a formában, kétlem, hogy ennek még mindig túl sok gyakorlati értelme van.
Hogyan különbözik
Amikor a helyszíni DB-t (legyen az MySQL vagy PostgreSQL) az AWS-felhőbe migrálva, közvetlenül használhatja az Aurora-t MySQL- vagy PostgreSQL-motorral célként, és így élvezheti az Aurora DB által kínált összes további előnyt.
Természetesen ez további erőfeszítéseket fog jelenteni a migrációs szakaszban ahhoz az esethez képest, amikor natív alternatívát választanak. De ez a további erőfeszítés csak marginális lesz.
Fő előnyük a költségekben rejlik, és abban, hogy a legalkalmasabbak kisebb projektkezdeményezésekhez, ahol a robusztusság nem igazán téma.
Főbb hátrányok
- Mindkettő támogatott funkcionalitása meglehetősen korlátozott, és fel kell készülnie a karbantarthatóság és adminisztráció korlátozott lehetőségeire.
- Nem alkalmas nagyszabású projektekhez, sok aktív felhasználóval.
- Nem a legjobb a nagy teljesítményű megoldásokhoz, és ahol az állandó teljesítményhangolás erős követelmény.
Mikor válasszunk
- Ha a költség a fő téma, és a költségvetés nagyon korlátozott.
- Ha a projekt kezdeményezése meglehetősen kicsi.
- Ha az adatmennyiség meglehetősen kicsi, és nem terveznek jelentős növekedést.
Használati példa
- Személyes projekt kezdeményezések, ahol az infrastruktúra költsége a lehető legkisebb legyen.
- Kis POC-k, amelyek bizonyítanák, hogy a javasolt koncepció megvalósítható.
- Kisvállalatok projektjei kis adatmennyiséggel.
- Kis SaaS-projektekhez, amelyek nem igényelnek nagy mennyiségű adatbázis-betöltést, csak az adatok relációs adatmodellben történő tárolása szükséges.
AWS MariaDB
Forrás: aws.amazon.com
A MariaDB továbbra is egy teljesen nyílt forráskódú adatbázis, amelyet korábbi MySQL-fejlesztők hoztak létre (miután a MySQL-t felvásárolta az Oracle).
Ami a kompatibilitást illeti, minden MySQL DB jól fut a MariaDB-n belül.
Hogyan különbözik
Funkció szempontjából nem sok különbség van a MySQL-től, de a nyílt forráskódú tulajdonság a legfontosabb.
Technikailag számos hasznos funkció elérhető a MariaDB-ben, de nem a MySQL-ben.
Főbb hátrányok
Nagyon hasonló a MySQL esethez.
Mikor válasszunk
- Ha nagyon szereti a jelenlegi MariaDB helyszíni megvalósítását, és nem szeretne áttérni az Aurora DB-re, bármilyen okból sem.
- Ha valóban nyílt forráskódú szeretne maradni adatbázis-megoldásával az AWS felhő-ökoszisztémán belül.
Használati példa
Nagyon hasonló a MySQL esethez.
Végső szavak
Hasonlóképpen, mivel az Oracle DB volt a megoldás a helyszíni világban, úgy tűnik, hogy az Aurora DB ezt a helyet foglalja el az AWS felhő világában. Legalábbis a funkciókészletek szempontjából ez áll a legközelebb.
És még ha nem is igazán keresi a fő érdekelt feleket, jó tudni, hogy még mindig vannak egészen egyszerű lehetőségek arra vonatkozóan, hogyan migrálhatja meglévő adatbázisát az AWS felhőbe.
Még jobb – ezzel a kapcsolóval automatikusan olyan funkciókat kap, amelyekről addig valószínűleg hiányzott. A legfontosabb, hogy a jobb tárolási bővíthetőség, a magas rendelkezésre állás és a horizontális méretezhetőség mind a felhőkörnyezet natív jellemzői.