Sziasztok! A nevem Golov Nikolay. Korábban az Avitóban dolgoztam, és hat évig menedzseltem a Data Platformot, vagyis az összes adatbázison dolgoztam: analitikus (Vertica, ClickHouse), streaming és OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Ezalatt az idő alatt nagyszámú – nagyon eltérő és szokatlan – adatbázissal, illetve ezek használatának nem szabványos eseteivel foglalkoztam.
Jelenleg a ManyChat-nál dolgozom. Lényegében ez egy startup – új, ambiciózus és gyorsan növekvő. És amikor először csatlakoztam a céghez, felmerült egy klasszikus kérdés: „Mit vegyen most egy fiatal startup a DBMS- és adatbázispiacról?”
Ebben a cikkben a címen megjelent jelentésem alapján , erre a kérdésre válaszolok. A jelentés videós változata a következő címen érhető el .
Általánosan ismert adatbázisok 2020
2020 van, körülnéztem és háromféle adatbázist láttam.
Első típus - klasszikus OLTP adatbázisok: PostgreSQL, SQL Server, Oracle, MySQL. Nagyon régen írták őket, de még mindig aktuálisak, mert annyira ismerősek a fejlesztői közösség számára.
A második típus az alapok "nulláról". Megpróbáltak eltávolodni a klasszikus mintáktól az SQL, a hagyományos struktúrák és az ACID elhagyásával, beépített sharding és egyéb vonzó funkciók hozzáadásával. Ez például a Cassandra, a MongoDB, a Redis vagy a Tarantool. Mindezek a megoldások valami alapvetően újat akartak kínálni a piacnak, és elfoglalták a rést, mert bizonyos feladatok elvégzésére rendkívül kényelmesnek bizonyultak. Ezeket az adatbázisokat a NOSQL gyűjtőfogalommal fogom jelölni.
Véget értek a „nullák”, megszoktuk a NOSQL adatbázisokat, és a világ az én szemszögemből megtette a következő lépést – kezelt adatbázisok. Ezek az adatbázisok ugyanazt a magot tartalmazzák, mint a klasszikus OLTP adatbázisok vagy az új NoSQL adatbázisok. De nincs szükségük DBA-ra és DevOps-ra, és felügyelt hardveren futnak a felhőkben. Egy fejlesztő számára ez „csak egy alap”, ami működik valahol, de senkit nem érdekel, hogy hogyan van telepítve a szerverre, ki konfigurálta a szervert és ki frissíti.
Példák ilyen adatbázisokra:
- Az AWS RDS a PostgreSQL/MySQL felügyelt burkolója.
- A DynamoDB egy dokumentum alapú adatbázis AWS analógja, hasonlóan a Redishez és a MongoDB-hez.
- Az Amazon Redshift egy menedzselt analitikai adatbázis.
Ezek alapvetően régi adatbázisok, de felügyelt környezetben készültek, anélkül, hogy hardverrel kellene dolgozni.
Jegyzet. A példák az AWS környezetre vonatkoznak, de analógjaik a Microsoft Azure-ban, a Google Cloudban vagy a Yandex.Cloudban is megtalálhatók.
Mi az újdonság ebben? 2020-ban ebből semmi.
Szerver nélküli koncepció
Ami igazán új a piacon 2020-ban, az a szerver nélküli vagy szerver nélküli megoldások.
Megpróbálom elmagyarázni, mit jelent ez egy normál szolgáltatás vagy háttéralkalmazás példáján.
Egy normál háttéralkalmazás üzembe helyezéséhez vásárolunk vagy bérelünk egy szervert, rámásoljuk a kódot, kívülről közzétesszük a végpontot, és rendszeresen fizetünk a bérleti díjért, az áramszolgáltatásért és az adatközponti szolgáltatásokért. Ez a standard séma.
Van más mód? Szerver nélküli szolgáltatásokkal megteheti.
Mire fókuszál ez a megközelítés: nincs szerver, még virtuális példány bérlése sincs a felhőben. A szolgáltatás üzembe helyezéséhez másolja a kódot (függvényeket) a lerakatba, és tegye közzé a végponton. Ezután egyszerűen fizetünk minden egyes hívásért ennek a függvénynek, teljesen figyelmen kívül hagyva a hardvert, ahol a függvény végrehajtódik.
Ezt a megközelítést megpróbálom képekkel illusztrálni.
Klasszikus telepítés. Van egy szolgáltatásunk bizonyos terheléssel. Két példányt emelünk ki: fizikai szervereket vagy példányokat az AWS-ben. Külső kéréseket küldenek ezekre a példányokra, és ott dolgozzák fel.
Ahogy a képen is látszik, a szerverek nem egyformán vannak elhelyezve. Az egyik 100%-ban kihasznált, két kérés van, az egyik pedig csak 50%-ban – részben tétlen. Ha nem három kérés érkezik, hanem 30, akkor az egész rendszer nem lesz képes megbirkózni a terheléssel, és lassulni kezd.
Szerver nélküli telepítés. Szerver nélküli környezetben egy ilyen szolgáltatásnak nincsenek példányai vagy kiszolgálói. Van egy bizonyos fűtött erőforráskészlet – kis előkészített Docker-konténerek telepített funkciókóddal. A rendszer fogadja a külső kéréseket, és mindegyikhez a szerver nélküli keretrendszer felállít egy kis konténert kóddal: feldolgozza ezt a kérést és megöli a konténert.
Egy kérés - egy konténer emelt, 1000 kérés - 1000 konténer. A hardveres szervereken történő telepítés pedig már a felhőszolgáltató feladata. Teljesen elrejti a szerver nélküli keretrendszer. Ebben a koncepcióban minden hívásért fizetünk. Például naponta egy hívás jött – egy hívásért fizettünk, percenként millió jött – millióért fizettünk. Vagy egy másodperc alatt ez is megtörténik.
A szerver nélküli funkció közzétételének koncepciója alkalmas állapot nélküli szolgáltatásra. Ha pedig (állapot)teljes szolgáltatásra van szüksége, akkor adatbázist adunk a szolgáltatáshoz. Ebben az esetben, amikor az állapottal kell dolgozni, minden statefull függvény egyszerűen ír és olvas az adatbázisból. Sőt, a cikk elején leírt három típus bármelyikének adatbázisából.
Mi az összes ilyen adatbázis közös korlátja? Ezek egy folyamatosan használt felhő- vagy hardverszerver (vagy több szerver) költségei. Teljesen mindegy, hogy klasszikus vagy menedzselt adatbázist használunk, van-e Devops és adminisztrátor vagy nincs, a hardver-, villany- és adatközpontbérlést továbbra is a nap 24 órájában fizetjük. Ha van klasszikus alapunk, fizetünk a mesterért és a rabszolgáért. Ha nagyon terhelt szilánkos adatbázisról van szó, akkor 7, 10 vagy 20 szerverért fizetünk, és folyamatosan fizetünk.
Az állandóan lefoglalt szerverek költségstruktúrában való jelenlétét korábban szükséges rossznak tekintették. A hagyományos adatbázisoknak más nehézségei is vannak, mint például a kapcsolatok számának korlátozása, a méretezési korlátozások, a földrajzilag elosztott konszenzus – ezek bizonyos adatbázisokban valahogy megoldhatók, de nem egyszerre és nem ideálisan.
Szerver nélküli adatbázis - elmélet
2020 kérdése: lehetséges-e szerver nélkülivé tenni egy adatbázist is? Mindenki hallott már a szerver nélküli háttérrendszerről... próbáljuk meg szerver nélkülivé tenni az adatbázist?
Ez furcsán hangzik, mert az adatbázis állapotteljes szolgáltatás, nem nagyon alkalmas szerver nélküli infrastruktúrára. Ugyanakkor az adatbázis állapota igen nagy: gigabájt, terabájt, az analitikai adatbázisokban pedig még petabájtok is. Nem olyan egyszerű könnyű Docker konténerekben felemelni.
Másrészt szinte minden modern adatbázis hatalmas mennyiségű logikát és összetevőt tartalmaz: tranzakciók, integritás koordináció, eljárások, relációs függőségek és sok logika. Elég sok adatbázis-logikához elég egy kis állapot is. A gigabájtokat és a terabájtokat a lekérdezések közvetlen végrehajtásában részt vevő adatbázis-logika csak kis része használja közvetlenül.
Ennek megfelelően az ötlet a következő: ha a logika egy része lehetővé teszi az állapot nélküli végrehajtást, miért nem osztja fel az alapot Stateful és Stateless részekre.
Szerver nélküli OLAP megoldásokhoz
Nézzük meg, hogyan nézhet ki egy adatbázis állapottartó és állapot nélküli részekre vágása gyakorlati példákon keresztül.
Például van egy analitikus adatbázisunk: külső adatok (piros henger a bal oldalon), egy ETL folyamat, amely adatokat tölt be az adatbázisba, és egy elemző, amely SQL lekérdezéseket küld az adatbázisba. Ez egy klasszikus adattárház üzemeltetési séma.
Ebben a sémában az ETL feltételesen egyszer kerül végrehajtásra. Ezután folyamatosan fizetni kell a szerverekért, amelyeken az adatbázis fut ETL-lel feltöltött adatokkal, hogy legyen mire lekérdezéseket küldeni.
Nézzünk meg egy alternatív megközelítést az AWS Athena Serverlessben. Nincs állandóan dedikált hardver, amelyen a letöltött adatokat tárolnák. Ehelyett:
- A felhasználó SQL-lekérdezést küld az Athena-nak. Az Athena optimalizáló elemzi az SQL-lekérdezést, és megkeresi a metaadattárban (Metadata) a lekérdezés végrehajtásához szükséges konkrét adatokat.
- Az optimalizáló az összegyűjtött adatok alapján külső forrásból tölti le a szükséges adatokat átmeneti tárolóba (ideiglenes adatbázisba).
- A felhasználótól érkező SQL-lekérdezés az ideiglenes tárolóban fut le, és az eredmény visszakerül a felhasználóhoz.
- Az ideiglenes tárhely törlődik, és az erőforrások felszabadulnak.
Ebben az architektúrában csak a kérés végrehajtásának folyamatáért fizetünk. Nincsenek kérések – nincsenek költségek.
Ez egy működő megközelítés, és nemcsak az Athena Serverless-ben, hanem a Redshift Spectrumban is (AWS-ben) valósul meg.
Az Athena példája azt mutatja, hogy a Serverless adatbázis valós lekérdezéseken működik, több tíz és száz terabájtnyi adattal. Több száz terabájthoz több száz szerverre lesz szükség, de nem kell fizetnünk értük – mi fizetjük a kéréseket. Az egyes kérések sebessége (nagyon) alacsony az olyan speciális analitikai adatbázisokhoz képest, mint a Vertica, de nem fizetünk az állásidőért.
Egy ilyen adatbázis alkalmazható ritka analitikai ad-hoc lekérdezésekre. Például, amikor spontán úgy döntünk, hogy tesztelünk egy hipotézist valamilyen gigantikus mennyiségű adaton. Az Athena tökéletes ezekre az esetekre. Rendszeres kérések esetén egy ilyen rendszer drága. Ebben az esetben tárolja az adatokat valamilyen speciális megoldásban.
Szerver nélküli OLTP megoldásokhoz
Az előző példa az OLAP (analitikai) feladatokat vizsgálta. Most nézzük az OLTP feladatokat.
Képzeljük el a méretezhető PostgreSQL-t vagy MySQL-t. Állítsunk fel egy normál felügyelt PostgreSQL-t vagy MySQL-t minimális erőforrással. Amikor a példány több terhelést kap, további replikákat fogunk csatlakoztatni, amelyekhez az olvasási terhelés egy részét elosztjuk. Ha nincs kérés vagy betöltés, kikapcsoljuk a replikákat. Az első példány a mester, a többi pedig replika.
Ezt az ötletet az Aurora Serverless AWS nevű adatbázisban valósítják meg. Az elv egyszerű: a külső alkalmazásoktól érkező kéréseket a proxy flotta elfogadja. A terhelés növekedését látva lefoglalja a számítási erőforrásokat az előmelegített minimális példányokból - a kapcsolat a lehető leggyorsabban létrejön. A példányok letiltása ugyanúgy történik.
Az Aurorán belül létezik az Aurora Capacity Unit, az ACU koncepciója. Ez (feltételesen) egy példány (szerver). Minden egyes ACU lehet master vagy slave. Minden kapacitásegységnek saját RAM-ja, processzora és minimális lemeze van. Ennek megfelelően az egyik mester, a többi csak olvasható replika.
A futó Aurora kapacitásegységek száma konfigurálható paraméter. A minimális mennyiség egy vagy nulla lehet (ebben az esetben az adatbázis nem működik, ha nincsenek kérések).
Amikor a bázis kéréseket kap, a proxy flotta megemeli az Aurora CapacityUnits egységeket, növelve a rendszer teljesítményerőforrásait. Az erőforrások növelésének és csökkentésének képessége lehetővé teszi a rendszer számára, hogy „zsonglőrködjön” az erőforrásokkal: automatikusan megjeleníti az egyes ACU-kat (újra cseréli őket), és kiadja a visszavont erőforrások összes aktuális frissítését.
Az Aurora Serverless bázis képes skálázni az olvasási terhelést. De a dokumentáció ezt nem mondja közvetlenül. Úgy érezheti, fel tudnak emelni egy multi-mestert. Nincs varázslat.
Ez az adatbázis kiválóan alkalmas arra, hogy ne költsön hatalmas összegeket kiszámíthatatlan hozzáférésű rendszerekre. Például MVP vagy marketing névjegykártya oldalak létrehozásakor általában nem számítunk stabil terhelésre. Ennek megfelelően, ha nincs hozzáférés, akkor nem fizetünk az példányokért. Ha váratlan terhelés történik, például egy konferencia vagy reklámkampány után, emberek tömegei keresik fel az oldalt, és a terhelés drámaian megnő, az Aurora Serverless automatikusan átveszi ezt a terhelést, és gyorsan összekapcsolja a hiányzó erőforrásokat (ACU). Aztán elmúlik a konferencia, mindenki megfeledkezik a prototípusról, a szerverek (ACU) elsötétülnek, a költségek pedig nullára csökkennek – kényelmes.
Ez a megoldás nem alkalmas stabil nagy terhelésre, mert nem skálázza az írási terhelést. Mindezek az erőforrások kapcsolódásai és megszakításai az úgynevezett „skálázási ponton” fordulnak elő – egy olyan időpontban, amikor az adatbázist nem támogatja tranzakció vagy ideiglenes táblák. Például előfordulhat, hogy egy héten belül nem jön létre a skálapont, és a bázis ugyanazokon az erőforrásokon dolgozik, és egyszerűen nem tud bővülni vagy összehúzódni.
Nincs varázslat – ez a szokásos PostgreSQL. A gépek hozzáadásának és leválasztásának folyamata azonban részben automatizált.
Szerver nélküli kialakítás
Az Aurora Serverless egy régi adatbázis, amelyet a felhőre írtak át, hogy kihasználják a Serverless előnyeit. És most elmondom az alapról, amelyet eredetileg a felhőre írtak, a szerver nélküli megközelítéshez - Serverless-by-design. Azonnal kifejlesztették anélkül, hogy feltételezték volna, hogy fizikai szervereken fog futni.
Ezt az alapot Snowflake-nek hívják. Három kulcsblokkja van.
Az első egy metaadatblokk. Ez egy gyors, memórián belüli szolgáltatás, amely megoldja a biztonsággal, a metaadatokkal, a tranzakciókkal és a lekérdezésoptimalizálással kapcsolatos problémákat (a bal oldali ábrán látható).
A második blokk virtuális számítási klaszterek készlete a számításokhoz (az ábrán kék körök láthatók).
A harmadik blokk egy S3 alapú adattároló rendszer. Az S3 egy dimenzió nélküli objektumtárolás az AWS-ben, olyan, mint a dimenzió nélküli Dropbox üzleti célra.
Nézzük meg, hogyan működik a Snowflake, hidegindítást feltételezve. Vagyis van adatbázis, abba töltődnek be az adatok, nem futnak lekérdezések. Ennek megfelelően, ha nem érkezik kérés az adatbázishoz, akkor felvettük a gyors memórián belüli metaadat szolgáltatást (első blokk). És van S3 tárolónk, ahol a táblaadatokat úgynevezett mikropartíciókra osztva tárolják. Az egyszerűség kedvéért: ha a tábla tranzakciókat tartalmaz, akkor a mikropartíciók a tranzakciók napjai. Minden nap külön mikropartíció, külön fájl. És amikor az adatbázis ebben a módban működik, csak az adatok által elfoglalt területért kell fizetni. Ráadásul az egy ülésre jutó arány nagyon alacsony (különös tekintettel a jelentős tömörítésre). A metaadat szolgáltatás is folyamatosan működik, de nem kell sok erőforrás a lekérdezések optimalizálásához, és a szolgáltatás shareware-nek tekinthető.
Most képzeljük el, hogy egy felhasználó érkezett az adatbázisunkhoz, és SQL-lekérdezést küldött. Az SQL lekérdezést azonnal elküldi a Metaadat szolgáltatásnak feldolgozásra. Ennek megfelelően ez a szolgáltatás a kérelem beérkezésekor elemzi a kérést, a rendelkezésre álló adatokat, a felhasználói jogosultságokat, és ha minden rendben van, tervet készít a kérelem feldolgozására.
Ezután a szolgáltatás elindítja a számítási fürt elindítását. A számítási fürt olyan kiszolgálók fürtje, amelyek számításokat végeznek. Vagyis ez egy fürt, amely tartalmazhat 1 szervert, 2 szervert, 4, 8, 16, 32 - amennyit csak akar. Bedob egy kérést, és azonnal megkezdődik a fürt elindítása. Tényleg másodpercekbe telik.
Ezután a fürt elindítása után megkezdődik a kérés feldolgozásához szükséges mikropartíciók másolása a fürtbe az S3-ból. Vagyis képzeljük el, hogy egy SQL-lekérdezés végrehajtásához két partícióra van szükség az egyik táblából és egy a másodikból. Ebben az esetben csak a három szükséges partíció lesz átmásolva a fürtbe, nem pedig az összes tábla. Éppen ezért, és éppen azért, mert minden egy adatközponton belül van, és nagyon gyors csatornákon van összekötve, a teljes átviteli folyamat nagyon gyorsan lezajlik: másodpercek alatt, nagyon ritkán percek alatt, hacsak nem valami szörnyű kérésekről beszélünk. Ennek megfelelően a mikropartíciók a számítási fürtbe másolódnak, és a befejezés után az SQL-lekérdezés ezen a számítási fürtön fut le. Ennek a kérésnek az eredménye lehet egy sor, több sor vagy egy táblázat – ezeket külsőleg küldik el a felhasználónak, hogy letölthesse, megjeleníthesse a BI eszközében, vagy más módon felhasználhassa.
Minden SQL lekérdezés nem csak aggregátumokat tud olvasni a korábban betöltött adatokból, hanem új adatokat is betölthet/generálhat az adatbázisban. Azaz lehet olyan lekérdezés, amely például új rekordokat szúr be egy másik táblába, ami egy új partíció megjelenéséhez vezet a számítási klaszteren, amely viszont automatikusan egyetlen S3 tárolóba kerül.
A fent leírt forgatókönyv, a felhasználó érkezésétől a fürt felállításáig, az adatok betöltéséig, a lekérdezések végrehajtásáig, az eredmények megszerzéséig, a felemelt virtuális számítástechnikai klaszter, virtuális raktár perc használati díjával kerül kifizetésre. Az árfolyam az AWS zónától és a klaszter méretétől függően változik, de átlagosan néhány dollár óránként. Egy négy gépből álló klaszter kétszer drágább, mint egy két gépből álló klaszter, és egy nyolc gépből álló klaszter még mindig kétszer olyan drágább. A kérések összetettségétől függően 16, 32 gép közül választhat. De csak azokért a percekért fizet, amikor a fürt ténylegesen fut, mert ha nincs kérés, akkor valahogy leveszi a kezét, és 5-10 perc várakozás után (konfigurálható paraméter) magától elalszik, szabadítson fel erőforrásokat és váljon szabaddá.
Egy teljesen reális forgatókönyv az, hogy amikor elküld egy kérést, a fürt viszonylagosan egy perc alatt felugrik, számol még egy percet, majd öt percet a leállításhoz, és végül fizet a fürt hét percnyi működéséért, és nem hónapokig és évekig.
Az első forgatókönyv, amelyet a Snowflake egyfelhasználós beállításban használnak. Most képzeljük el, hogy sok felhasználó van, ami közelebb áll a valós forgatókönyvhöz.
Tegyük fel, hogy sok elemzőnk és Tableau-jelentésünk van, amelyek folyamatosan bombázzák adatbázisunkat nagyszámú egyszerű elemző SQL-lekérdezéssel.
Ezen túlmenően, tegyük fel, hogy vannak ötletes adattudósaink, akik szörnyű dolgokat próbálnak csinálni az adatokkal, több tíz terabyte-tal operálnak, milliárd és billió adatsort elemeznek.
A fent leírt két típusú munkaterhelés esetén a Snowflake lehetővé teszi több, különböző kapacitású független számítási klaszter létrehozását. Ezen túlmenően ezek a számítási klaszterek függetlenül működnek, de közös konzisztens adatokkal.
Nagyszámú könnyű lekérdezéshez 2-3 kis klasztert hozhat létre, egyenként nagyjából 2 gépet. Ez a viselkedés többek között automatikus beállításokkal valósítható meg. Tehát azt mondod: „Hópehely, emelj egy kis klasztert. Ha a terhelés egy bizonyos paraméter fölé emelkedik, emeljünk hasonló másodikat, harmadikat. Amikor a terhelés csökkenni kezd, oltsa el a felesleget. Hogy akárhány elemző jön és kezdi el nézegetni a jelentéseket, mindenkinek legyen elegendő erőforrása.
Ugyanakkor, ha az elemzők alszanak, és senki sem nézi meg a jelentéseket, a klaszterek teljesen elsötétülhetnek, és Ön nem fizet értük.
Ugyanakkor nehéz lekérdezések esetén (a Data Scientiststől) egy nagyon nagy fürt hozható létre 32 gép számára. Ez a fürt is csak azokra a percekre és órákra kerül kifizetésre, amikor az óriási kérelme fut ott.
A fent leírt lehetőség lehetővé teszi, hogy ne csak 2, hanem több típusú munkaterhelést is klaszterekre (ETL, monitoring, report materialization,...) osszanak fel.
Foglaljuk össze a Hópehelyet. Az alap ötvözi a szép ötletet és a működőképes megvalósítást. A ManyChatnál a Snowflake segítségével elemezzük az összes rendelkezésünkre álló adatot. Nem három klaszterünk van, mint a példában, hanem 5-től 9-ig, különböző méretű. Vannak hagyományos 16-os, 2-gépesek és néhány feladathoz szuper-kicsi 1-gépesek is. Sikeresen osztják el a terhelést, és sokat spórolhatunk.
Az adatbázis sikeresen skálázza az olvasási és írási terhelést. Ez óriási különbség és óriási áttörés ugyanazon „Aurorához” képest, amely csak az olvasási terhelést viselte. A Snowflake lehetővé teszi az írási terhelés skálázását ezekkel a számítási fürtökkel. Vagyis, mint említettem, a ManyChat-ben több klasztert használunk, a kicsi és szuperkicsi klasztereket elsősorban ETL-re, adatok betöltésére használják. Az elemzők pedig már közepes klasztereken élnek, amelyeket abszolút nem érint az ETL terhelés, így nagyon gyorsan dolgoznak.
Ennek megfelelően az adatbázis kiválóan alkalmas OLAP feladatokra. Sajnos azonban még nem alkalmazható OLTP-munkaterhelésekre. Először is, ez az adatbázis oszlopos, minden ebből következő következménnyel együtt. Másodszor, maga a megközelítés, amikor minden kéréshez szükség esetén felállítunk egy számítási klasztert és elárasztjuk azt adatokkal, sajnos még nem elég gyors az OLTP-betöltésekhez. A másodpercek várakozása az OLAP-feladatokra normális, de az OLTP-feladatoknál elfogadhatatlan; 100 ms jobb lenne, vagy 10 ms még jobb.
Teljes
Szerver nélküli adatbázis úgy lehetséges, hogy az adatbázist állapot nélküli és állapotmentes részekre osztja. Valószínűleg észrevetted, hogy a fenti példák mindegyikében a Stateful rész relatíve az S3 mikropartícióinak tárolása, az Állapot nélküli pedig az optimalizáló, amely metaadatokkal dolgozik, és olyan biztonsági problémákat kezel, amelyek független, könnyű állapot nélküli állapot nélküli szolgáltatásokként vethetők fel.
Az SQL-lekérdezések végrehajtása könnyű állapotú szolgáltatásoknak is felfogható, amelyek szerver nélküli módban felbukkanhatnak, például a Snowflake számítási fürtök, csak a szükséges adatokat töltik le, végrehajtják a lekérdezést és „kimúlnak”.
A szerver nélküli éles szintű adatbázisok már használhatóak, működnek. Ezek a kiszolgáló nélküli adatbázisok már készen állnak az OLAP feladatok kezelésére. Sajnos az OLTP feladatokhoz használják... árnyalatokkal, mivel vannak korlátok. Ez egyrészt mínusz. De másrészt ez egy lehetőség. Talán az egyik olvasó megtalálja a módját, hogy egy OLTP adatbázist teljesen szervermentessé tegyen, az Aurora korlátai nélkül.
Remélem érdekesnek találtad. A szerver nélküli a jövő 🙂
Forrás: will.com