Halo sadayana! Ngaran abdi Golov Nikolay. Saméméhna, kuring digawé di Avito sarta junun Platform Data salila genep taun, nyaeta, kuring digawé di sakabéh database: analitik (Vertica, ClickHouse), streaming sarta OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Antukna, kuring diurus sajumlah ageung pangkalan data - béda pisan sareng teu biasa, sareng kasus anu henteu standar pamakeanna.
Abdi ayeuna damel di ManyChat. Intina, ieu mangrupikeun ngamimitian - énggal, ambisius sareng ngembang pesat. Sareng nalika kuring mimiti ngagabung sareng perusahaan, timbul patarosan klasik: "Naon anu kedah dilakukeun ku ngamimitian ngora ti DBMS sareng pasar database?"
Dina artikel ieu, dumasar kana laporan kuring di , Kuring bakal ngajawab patarosan ieu. A versi video laporan sadia di .
Pangkalan data umum 2020
Taun 2020, kuring ningali sabudeureun sareng ningali tilu jinis pangkalan data.
Jenis munggaran - database OLTP Palasik: PostgreSQL, SQL Server, Oracle, MySQL. Tembok ditulis lila pisan, tapi masih relevan sabab geus akrab jeung komunitas pamekar.
Jenis kadua nyaéta dasar tina "nol". Aranjeunna nyobian ngajauhan pola klasik ku ngantunkeun SQL, struktur tradisional sareng ACID, ku nambihan sharding anu diwangun sareng fitur anu pikaresepeun. Contona, ieu Cassandra, MongoDB, Redis atanapi Tarantool. Sadaya solusi ieu hoyong nawiskeun pasar anu dasarna anyar sareng nempatan Ecological maranéhanana sabab tétéla pisan merenah pikeun tugas nu tangtu. Kuring bakal nunjukkeun pangkalan data ieu nganggo istilah payung NOSQL.
"Enol" parantos réngsé, urang biasa kana pangkalan data NOSQL, sareng dunya, tina sudut pandang kuring, nyandak léngkah salajengna - pikeun database junun. Basis data ieu ngagaduhan inti anu sami sareng pangkalan data OLTP klasik atanapi NoSQL énggal. Tapi aranjeunna henteu peryogi DBA sareng DevOps sareng ngajalankeun hardware anu diurus dina méga. Pikeun pamekar, ieu "ngan dasar" anu dianggo dimana waé, tapi teu aya anu paduli kumaha éta dipasang dina server, anu ngonpigurasikeun server sareng anu ngamutahirkeunana.
Conto database sapertos kieu:
- AWS RDS mangrupikeun bungkus anu diurus pikeun PostgreSQL / MySQL.
- DynamoDB mangrupikeun analog AWS tina pangkalan data dumasar dokumén, sami sareng Redis sareng MongoDB.
- Amazon Redshift mangrupikeun database analitik anu diurus.
Ieu dasarna basis data heubeul, tapi digedékeun dina lingkungan junun, tanpa kudu digawekeun ku hardware.
Catetan. Conto dicandak pikeun lingkungan AWS, tapi analogna ogé aya dina Microsoft Azure, Google Cloud, atanapi Yandex.Cloud.
Naon nu anyar ngeunaan ieu? Dina 2020, teu aya ieu.
Konsep tanpa server
Anu énggal di pasar taun 2020 nyaéta solusi tanpa server atanapi tanpa server.
Kuring bakal nyobian ngajelaskeun naon hartina ngagunakeun conto layanan biasa atawa aplikasi backend.
Pikeun nyebarkeun aplikasi backend biasa, urang mésér atanapi nyéwa server, nyalin kodeu kana éta, nyebarkeun titik tungtung di luar sareng rutin mayar nyéwa, listrik sareng jasa pusat data. Ieu skéma standar.
Aya jalan séjén? Kalayan jasa tanpa server anjeun tiasa.
Naon fokus pendekatan ieu: teu aya server, malah teu nyéwa instansi virtual dina awan. Pikeun nyebarkeun jasa éta, salin kodeu (fungsi) kana gudang sareng nyebarkeun ka tungtung. Teras we saukur mayar unggal panggero pikeun fungsi ieu, lengkep ignoring hardware dimana eta dieksekusi.
Kuring bakal nyobian ngagambarkeun pendekatan ieu sareng gambar.
deployment Palasik. Kami ngagaduhan jasa kalayan beban anu tangtu. Urang ngangkat dua instansi: server fisik atawa instansi di AWS. Paménta éksternal dikirim ka instansi ieu sareng diolah di dinya.
Sakumaha anjeun tiasa tingali dina gambar, server teu disposed of sarua. Hiji anu 100% garapan, aya dua requests, sarta hiji ngan 50% - sawaréh dianggurkeun. Mun teu tilu requests anjog, tapi 30, sakabéh sistem moal bisa Cope jeung beban sarta bakal ngawitan ngalambatkeun turun.
Panyebaran tanpa server. Dina lingkungan tanpa server, jasa sapertos kitu teu gaduh instansi atanapi server. Aya kolam renang tangtu sumberdaya dipanaskeun - wadahna Docker leutik disusun kalawan kode fungsi deployed. Sistim nu narima requests éksternal sarta unggal sahijina kerangka serverless raises wadahna leutik kalawan kode: eta ngolah pamundut husus ieu sarta maéhan wadahna.
Hiji pamundut - hiji wadah diangkat, 1000 requests - 1000 wadahna. Sareng panyebaran dina server hardware parantos janten padamelan panyadia awan. Ieu sagemblengna disumputkeun ku kerangka serverless. Dina konsép ieu kami mayar unggal panggero. Contona, hiji panggero datang sapoé - urang mayar hiji telepon, sajuta datang per menit - urang mayar hiji juta. Atawa dina sadetik, ieu ogé kajadian.
Konsep medarkeun fungsi serverless cocog pikeun layanan stateless. Sareng upami anjeun peryogi jasa statefull (kaayaan), maka kami nambihan database kana jasa éta. Dina hal ieu, lamun datang ka gawé bareng kaayaan, unggal fungsi statefull saukur nulis jeung maca tina database. Leuwih ti éta, ti database salah sahiji tilu jenis dijelaskeun dina awal artikel.
Naon watesan umum sadaya basis data ieu? Ieu mangrupikeun biaya pikeun server awan atanapi hardware anu terus dianggo (atanapi sababaraha server). Henteu janten masalah naha urang nganggo database klasik atanapi anu diurus, naha urang gaduh Devops sareng admin atanapi henteu, kami masih mayar kanggo nyéwa hardware, listrik sareng pusat data 24/7. Upami urang gaduh dasar klasik, urang mayar master sareng budak. Lamun éta database sharded kacida dimuat, urang mayar 10, 20 atawa 30 server, sarta kami mayar terus.
Ayana server ditangtayungan permanén dina struktur ongkos ieu saméméhna katarima salaku jahat perlu. Basis data konvensional ogé ngagaduhan kasusah sanés, sapertos wates jumlah sambungan, larangan skala, konsensus anu disebarkeun geo - kumaha waé tiasa direngsekeun dina pangkalan data anu tangtu, tapi henteu sakaligus sareng henteu idéal.
Database tanpa server - téori
Patarosan taun 2020: naha mungkin ngadamel pangkalan data tanpa server ogé? Sarerea geus uninga ngeunaan serverless backend ... hayu urang coba sangkan database serverless?
Ieu hurung aneh, sabab database mangrupa layanan statefull, teu cocog pisan pikeun infrastruktur serverless. Dina waktos anu sami, kaayaan pangkalan data ageung pisan: gigabytes, terabytes, sareng dina database analitik bahkan petabytes. Henteu gampang pikeun ngangkat éta dina wadah Docker anu hampang.
Di sisi anu sanés, ampir sadaya pangkalan data modéren ngandung seueur logika sareng komponén: transaksi, koordinasi integritas, prosedur, kagumantungan hubungan sareng seueur logika. Pikeun rada loba logika database, kaayaan leutik cukup. Gigabytes sareng Terabytes langsung dianggo ku ngan ukur bagian leutik tina logika database anu aub dina ngalaksanakeun patarosan langsung.
Sasuai, idena nyaéta: upami bagian tina logika ngamungkinkeun palaksanaan stateless, naha henteu ngabagi dasar kana bagian Stateful sareng Stateless.
Serverless pikeun solusi OLAP
Hayu urang tingali kumaha motong database kana bagian Stateful na Stateless bisa kasampak kawas ngagunakeun conto praktis.
Contona, urang boga database analitik: data éksternal (silinder beureum dina kénca), hiji prosés ETL nu beban data kana database, sarta analis nu ngirim queries SQL ka database. Ieu mangrupikeun skéma operasi gudang data klasik.
Dina skéma ieu, ETL sacara kondisional dilaksanakeun sakali. Teras anjeun kedah mayar terus-terusan pikeun server dimana pangkalan data dijalankeun ku data anu ngeusi ETL, ku kituna aya anu ngirimkeun patarosan.
Hayu urang tingali pendekatan alternatif anu dilaksanakeun dina AWS Athena Serverless. Henteu aya hardware khusus anu permanén dimana data anu diunduh disimpen. Gantina ieu:
- Pamaké ngirimkeun pamundut SQL ka Athena. Optimasi Athena nganalisa pamundut SQL sareng milarian toko metadata (Metadata) pikeun data khusus anu diperyogikeun pikeun ngalaksanakeun pamundut.
- Optimasi, dumasar kana data anu dikumpulkeun, ngaunduh data anu diperyogikeun tina sumber éksternal kana panyimpenan samentawis (database samentawis).
- Paménta SQL ti pangguna dieksekusi dina panyimpenan samentawis sareng hasilna dipulangkeun ka pangguna.
- Panyimpenan samentawis diberesihan sareng sumber daya dileupaskeun.
Dina arsitektur ieu, urang ngan mayar prosés executing pamundut teh. Taya requests - euweuh waragad.
Ieu mangrupikeun pendekatan anu tiasa dianggo sareng dilaksanakeun henteu ngan ukur di Athena Serverless, tapi ogé dina Redshift Spectrum (dina AWS).
Conto Athena nunjukeun yen database Serverless jalan dina queries nyata kalawan puluhan sarta ratusan Terabytes data. Ratusan Terabytes ngabutuhkeun ratusan server, tapi urang henteu kedah mayar aranjeunna - urang mayar kanggo pamundut. Laju unggal pamundut téh (pisan) low dibandingkeun database analitik husus kawas Vertica, tapi urang teu mayar perioda downtime.
Database sapertos kitu tiasa dianggo pikeun patarosan ad-hoc analitik anu jarang. Contona, nalika urang spontaneously mutuskeun pikeun nguji hipotésis dina sababaraha jumlah gigantic data. Athena sampurna pikeun kasus ieu. Pikeun pamundut biasa, sistem sapertos kitu mahal. Dina hal ieu, cache data dina sababaraha solusi husus.
Serverless pikeun solusi OLTP
Conto saméméhna ningali tugas OLAP (analitik). Ayeuna hayu urang tingali tugas OLTP.
Hayu urang ngabayangkeun scalable PostgreSQL atanapi MySQL. Hayu urang angkat conto anu teratur PostgreSQL atanapi MySQL kalayan sumber daya minimal. Nalika instance nampi langkung seueur beban, kami bakal nyambungkeun réplika tambahan anu kami bakal ngadistribusikaeun bagian tina beban bacaan. Upami teu aya pamundut atanapi beban, urang mareuman réplika. Conto kahiji nyaéta master, sareng sésana mangrupikeun réplika.
Gagasan ieu dilaksanakeun dina pangkalan data anu disebut Aurora Serverless AWS. Prinsipna basajan: pamundut ti aplikasi éksternal ditampi ku armada proxy. Ningali kanaékan beban, éta nyayogikeun sumber komputasi tina instansi minimal anu tos dipanaskeun - sambunganna dilakukeun gancang-gancang. Nganonaktipkeun instansi lumangsung dina cara nu sarua.
Dina Aurora aya konsep Aurora Kapasitas Unit, ACU. Ieu (saratna) hiji conto (server). Unggal ACU khusus tiasa janten master atanapi budak. Unggal Unit Kapasitas gaduh RAM sorangan, prosesor sareng disk minimal. Sasuai, hiji master, sésana dibaca ukur réplika.
Jumlah Unit Aurora Kapasitas ieu ngajalankeun mangrupakeun parameter configurable. Kuantitas minimum tiasa hiji atanapi nol (dina hal ieu, pangkalan data henteu tiasa dianggo upami henteu aya pamundut).
Nalika dasarna nampi pamundut, armada proxy naékkeun Aurora CapacityUnits, ningkatkeun sumber daya kinerja sistem. Kamampuhan pikeun ningkatkeun sareng ngirangan sumber daya ngamungkinkeun sistem "juggle" sumberdaya: sacara otomatis nunjukkeun ACU individu (ngagantikeunana ku anu énggal) sareng gulung sadaya pembaruan ayeuna kana sumber anu ditarik.
Dasar Aurora Serverless tiasa skala beban bacaan. Tapi dokuméntasi henteu nyarios ieu langsung. Éta sigana sigana aranjeunna tiasa angkat multi-master. Henteu aya sihir.
Pangkalan data ieu cocog pisan pikeun ngahindarkeun ngaluarkeun artos anu ageung pikeun sistem anu aksés anu teu kaduga. Contona, nalika nyieun MVP atawa pamasaran situs kartu bisnis, urang biasana teu nyangka beban stabil. Sasuai, lamun euweuh aksés, urang teu mayar instansi. Nalika aya beban anu teu kaduga, contona saatos konperénsi atanapi kampanye iklan, seueur jalma nganjang ka situs sareng beban naék sacara dramatis, Aurora Serverless otomatis nyandak beban ieu sareng gancang nyambungkeun sumber daya anu leungit (ACU). Teras konperénsi pas, sadayana hilap ngeunaan prototipe, server (ACU) poék, sareng biaya turun ka nol - merenah.
Solusi ieu henteu cocog pikeun beban luhur anu stabil sabab henteu skala beban tulisan. Sadaya sambungan ieu sareng pegatna sumberdaya lumangsung dina anu disebut "titik skala" - titik waktos nalika pangkalan data henteu dirojong ku transaksi atanapi tabel samentawis. Contona, dina saminggu titik skala bisa jadi teu lumangsung, sarta dasarna jalan dina sumberdaya sarua jeung saukur teu bisa dilegakeun atawa kontrak.
Henteu aya sihir - éta PostgreSQL biasa. Tapi prosés nambahkeun mesin sarta disconnecting aranjeunna sawaréh otomatis.
Serverless ku desain
Aurora Serverless mangrupikeun database lami anu ditulis ulang pikeun awan pikeun ngamangpaatkeun sababaraha kauntungan tina Serverless. Sareng ayeuna kuring bakal nyarioskeun ka anjeun ngeunaan dasarna, anu tadina ditulis pikeun awan, pikeun pendekatan tanpa server - Serverless-by-design. Éta langsung dikembangkeun tanpa anggapan yén éta bakal dijalankeun dina server fisik.
Dasar ieu disebut Snowflake. Cai mibanda tilu blok konci.
Anu kahiji nyaéta blok metadata. Ieu mangrupikeun layanan mémori gancang anu ngabéréskeun masalah kaamanan, metadata, transaksi, sareng optimasi pamundut (ditémbongkeun dina ilustrasi di kénca).
Blok kadua nyaéta sakumpulan klaster komputasi virtual pikeun itungan (dina ilustrasi aya sakumpulan bunderan biru).
Blok katilu nyaéta sistem panyimpen data dumasar kana S3. S3 mangrupikeun panyimpen obyék tanpa dimensi dina AWS, sapertos Dropbox tanpa dimensi pikeun bisnis.
Hayu urang tingali kumaha Snowflake jalan, asumsina mimiti tiis. Hartina, aya database, data dimuat kana eta, teu aya queries ngajalankeun. Sasuai, upami teu aya pamundut ka pangkalan data, maka kami parantos ngangkat jasa Metadata dina mémori gancang (blok munggaran). Sarta kami boga gudang S3, dimana data tabel disimpen, dibagi kana disebut micropartitions. Pikeun kesederhanaan: upami tabel ngandung transaksi, maka micropartitions mangrupikeun dinten transaksi. Saban poé nyaéta micropartition misah, file misah. Sareng nalika pangkalan data beroperasi dina modeu ieu, anjeun ngan ukur mayar rohangan anu dijajah ku data. Leuwih ti éta, laju per korsi pisan low (utamana nyokot kana akun komprési signifikan). Ladenan metadata ogé tiasa dianggo terus-terusan, tapi anjeun henteu peryogi seueur sumber pikeun ngaoptimalkeun patarosan, sareng jasa éta tiasa dianggap shareware.
Ayeuna hayu urang ngabayangkeun yén hiji pamaké datang ka database urang jeung dikirim query SQL. Paménta SQL langsung dikirim ka layanan Metadata pikeun diolah. Sasuai, nalika nampi pamundut, jasa ieu nganalisa pamundut, data anu sayogi, idin pangguna sareng, upami sadayana leres, nyusun rencana pikeun ngolah pamundut éta.
Salajengna, jasa ngamimitian peluncuran klaster komputasi. Kluster komputasi mangrupikeun gugusan server anu ngalakukeun itungan. Hartina, ieu klaster nu bisa ngandung 1 server, 2 server, 4, 8, 16, 32 - saloba rék. Anjeun ngalungkeun pamundut sareng peluncuran klaster ieu langsung dimimitian. Bener butuh detik.
Salajengna, saatos kluster dimimitian, mikropartisi anu diperyogikeun pikeun ngolah pamundut anjeun mimiti disalin kana kluster tina S3. Nyaéta, hayu urang ngabayangkeun yén pikeun ngaéksekusi query SQL anjeun peryogi dua partisi tina hiji méja sareng hiji tina anu kadua. Dina hal ieu, ngan tilu partitions diperlukeun bakal disalin kana klaster, sarta teu sakabeh tabel. Éta pisan sababna naha, sarta persis sabab sagalana aya dina hiji puseur data sarta disambungkeun ku saluran pisan gancang, sakabéh prosés mindahkeun lumangsung gancang pisan: dina sababaraha detik, jarang pisan dina menit, iwal mun urang ngobrol ngeunaan sababaraha requests monstrous . Sasuai, micropartitions disalin kana klaster komputasi, sarta, sanggeus réngsé, query SQL dieksekusi dina klaster komputasi ieu. Hasil tina pamundut ieu tiasa janten hiji garis, sababaraha garis atanapi tabel - aranjeunna dikirim sacara éksternal ka pangguna supados anjeunna tiasa ngaunduhana, nampilkeunana dina alat BI na, atanapi dianggo ku sababaraha cara anu sanés.
Unggal query SQL teu ngan bisa maca aggregates tina data saméméhna dimuat, tapi ogé beban / ngahasilkeun data anyar dina database. Hartina, bisa jadi query nu, contona, inserts rékaman anyar kana tabel sejen, nu ngabalukarkeun penampilan partisi anyar dina klaster komputasi, nu, kahareupna otomatis disimpen dina gudang S3 tunggal.
Skenario ditétélakeun di luhur, ti datangna pamaké ka raising tina klaster, loading data, executing queries, meunangkeun hasil, dibayar dina laju pikeun menit ngagunakeun klaster komputasi virtual diangkat, gudang maya. Laju beda-beda gumantung kana zona AWS sareng ukuran klaster, tapi rata-rata sababaraha dolar per jam. Kluster opat mesin dua kali langkung mahal tibatan klaster dua mesin, sareng klaster dalapan mesin masih dua kali langkung mahal. Pilihan 16, 32 mesin sadia, gumantung kana pajeulitna requests. Tapi anjeun ngan ukur mayar kanggo menit-menit éta nalika klusterna leres-leres dijalankeun, sabab nalika henteu aya pamundut, anjeun kedah nyandak panangan anjeun, sareng saatos 5-10 menit ngantosan (parameter anu tiasa dikonfigurasi) éta bakal pareum nyalira. ngosongkeun sumber daya sareng janten gratis.
A skenario lengkep realistis nyaeta mun anjeun ngirim pamundut a, klaster Pops up, rélatif diomongkeun, dina hiji menit, éta diitung menit sejen, lajeng lima menit mareuman, jeung anjeun mungkas nepi Mayar pikeun tujuh menit operasi klaster ieu, jeung teu keur bulan jeung taun.
Skenario munggaran dijelaskeun nganggo Snowflake dina setélan pangguna tunggal. Ayeuna hayu urang bayangkeun yén aya seueur pangguna, anu langkung caket kana skenario anu nyata.
Anggap urang gaduh seueur analis sareng laporan Tableau anu terus-terusan ngabom database kami kalayan sajumlah ageung query SQL analitik anu sederhana.
Sajaba ti éta, hayu urang nyebutkeun yén urang boga inventive Data Élmuwan anu nyoba ngalakukeun hal monstrous kalawan data, beroperasi kalawan puluhan Terabytes, nganalisis milyaran sarta triliun baris data.
Pikeun dua jinis beban kerja anu dijelaskeun di luhur, Snowflake ngamungkinkeun anjeun pikeun ngangkat sababaraha klaster komputasi mandiri tina kapasitas anu béda. Sumawona, klaster komputasi ieu tiasa dianggo sacara mandiri, tapi kalayan data konsisten umum.
Pikeun angka nu gede ngarupakeun queries lampu, Anjeun bisa ngumpulkeun 2-3 klaster leutik, kira-kira 2 mesin unggal. Paripolah ieu tiasa dilaksanakeun, diantarana, nganggo setélan otomatis. Janten anjeun nyarios, "Snowflake, angkat gugusan leutik. Lamun beban dina eta naek luhureun parameter nu tangtu, ngangkat kadua sarupa, katilu. Nalika beban mimiti suda, pareumkeun kaleuwihanana." Ku kituna euweuh urusan sabaraha analis datang tur mimitian nempo laporan, dulur boga cukup sumberdaya.
Dina waktos anu sami, upami analis bobo sareng teu aya anu ningali laporan, klaster tiasa janten poék, sareng anjeun ngeureunkeun mayarana.
Dina waktu nu sarua, pikeun queries beurat (tina Data Scientists), anjeun tiasa ngangkat hiji klaster kacida gedéna pikeun 32 mesin. Kluster ieu ogé bakal dibayar ngan pikeun menit sareng jam nalika pamundut raksasa anjeun dijalankeun di dinya.
Kasempetan ditétélakeun di luhur ngidinan Anjeun pikeun ngabagi teu ukur 2, tapi ogé leuwih jenis workload kana klaster (ETL, monitoring, materialization laporan, ...).
Hayu urang nyimpulkeun Snowflake. Dasarna ngagabungkeun ide anu saé sareng palaksanaan anu tiasa dianggo. Di ManyChat, kami nganggo Snowflake pikeun nganalisis sadaya data anu kami gaduh. Kami henteu ngagaduhan tilu klaster, sapertos conto, tapi tina 5 dugi ka 9, tina ukuran anu béda. Simkuring gaduh 16-mesin konvensional, 2-mesin, sarta ogé super-leutik 1-mesin pikeun sababaraha tugas. Aranjeunna suksés ngadistribusikaeun beban sareng ngamungkinkeun urang ngahemat pisan.
Pangkalan data hasil skala beban maca sareng nyerat. Ieu mangrupikeun bédana anu ageung sareng terobosan anu ageung dibandingkeun sareng "Aurora" anu sami, anu ngan ukur nyandak beban bacaan. Snowflake ngidinan Anjeun pikeun skala workload tulisan anjeun kalawan klaster komputasi ieu. Maksudna, sakumaha kuring disebutkeun, kami nganggo sababaraha klaster di ManyChat, klaster leutik jeung super-leutik utamana dipaké pikeun ETL, pikeun loading data. Sareng analis parantos hirup dina klaster sedeng, anu leres-leres henteu kapangaruhan ku beban ETL, janten aranjeunna gancang pisan.
Sasuai, pangkalan data cocog pikeun tugas OLAP. Tapi, hanjakalna, éta henteu acan tiasa dianggo pikeun beban kerja OLTP. Firstly, database ieu columnar, kalayan sagala konsékuansi ensuing. Bréh, pendekatan sorangan, lamun keur unggal pamundut, upami diperlukeun, anjeun ngangkat klaster komputasi jeung banjir data, hanjakalna, teu acan cukup gancang pikeun beban OLTP. Ngadagoan detik pikeun tugas OLAP normal, tapi pikeun tugas OLTP teu bisa ditarima; 100 md bakal leuwih alus, atawa 10 md bakal leuwih alus.
hasil
Database tanpa server tiasa dilakukeun ku ngabagi pangkalan data kana bagian Stateless sareng Stateful. Anjeun meureun geus noticed nu dina sakabéh conto di luhur, bagian Stateful nyaeta, rélatif diomongkeun, nyimpen mikro-partitions di S3, sarta Stateless nyaeta optimizer nu, gawé bareng metadata, nanganan masalah kaamanan nu bisa diangkat jadi lightweight jasa Stateless bebas.
Ngaéksekusi queries SQL ogé bisa dianggap salaku ladenan light-state nu bisa pop up dina modeu serverless, kawas Snowflake komputasi klaster, undeur ngan data diperlukeun, ngajalankeun query jeung "kaluar".
Database tingkat produksi tanpa server parantos sayogi dianggo, aranjeunna tiasa dianggo. Database tanpa server ieu parantos siap pikeun nanganan tugas OLAP. Hanjakal, pikeun tugas OLTP aranjeunna dipaké ... kalawan nuansa, saprak aya watesan. Di hiji sisi, ieu mangrupikeun minus. Tapi, di sisi anu sanés, ieu mangrupikeun kasempetan. Panginten salah sahiji pamiarsa bakal mendakan cara pikeun ngadamel database OLTP lengkep tanpa server, tanpa watesan Aurora.
Kuring miharep anjeun kapanggih eta metot. Serverless mangrupikeun masa depan :)
sumber: www.habr.com