Kamusta kayong lahat! Ang pangalan ko ay Golov Nikolay. Dati, nagtrabaho ako sa Avito at pinamamahalaan ang Data Platform sa loob ng anim na taon, ibig sabihin, nagtrabaho ako sa lahat ng database: analytical (Vertica, ClickHouse), streaming at OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Sa panahong ito, nakipag-usap ako sa isang malaking bilang ng mga database - ibang-iba at hindi pangkaraniwan, at sa mga hindi karaniwang kaso ng kanilang paggamit.
Kasalukuyan akong nagtatrabaho sa ManyChat. Sa esensya, ito ay isang startup - bago, ambisyoso at mabilis na lumalago. At noong una akong sumali sa kumpanya, isang klasikong tanong ang lumitaw: "Ano ngayon ang dapat kunin ng isang batang startup mula sa DBMS at database market?"
Sa artikulong ito, batay sa aking ulat sa , sasagutin ko ang tanong na ito. Available ang isang video na bersyon ng ulat sa .
Mga karaniwang kilalang database 2020
2020 na, tumingin ako sa paligid at nakakita ako ng tatlong uri ng database.
Unang uri - mga klasikong database ng OLTP: PostgreSQL, SQL Server, Oracle, MySQL. Matagal nang naisulat ang mga ito, ngunit may kaugnayan pa rin dahil pamilyar ang mga ito sa komunidad ng developer.
Ang pangalawang uri ay base mula sa "zero". Sinubukan nilang lumayo sa mga klasikong pattern sa pamamagitan ng pag-abandona sa SQL, mga tradisyonal na istruktura at ACID, sa pamamagitan ng pagdaragdag ng built-in na sharding at iba pang mga kaakit-akit na feature. Halimbawa, ito ay Cassandra, MongoDB, Redis o Tarantool. Ang lahat ng mga solusyong ito ay nais na mag-alok sa merkado ng isang bagay na panimula na bago at sinakop ang kanilang angkop na lugar dahil sila ay naging lubhang maginhawa para sa ilang mga gawain. Ipapahiwatig ko ang mga database na ito na may payong terminong NOSQL.
Tapos na ang "zero", nasanay na kami sa mga database ng NOSQL, at ang mundo, mula sa aking pananaw, ay gumawa ng susunod na hakbang - upang pinamamahalaang mga database. Ang mga database na ito ay may parehong core ng mga klasikong OLTP database o mga bagong NoSQL. Ngunit hindi nila kailangan ang DBA at DevOps at tumatakbo sa pinamamahalaang hardware sa cloud. Para sa isang developer, ito ay "base lang" na gumagana sa isang lugar, ngunit walang nagmamalasakit kung paano ito naka-install sa server, kung sino ang nag-configure sa server at kung sino ang nag-update nito.
Mga halimbawa ng naturang mga database:
- Ang AWS RDS ay isang pinamamahalaang wrapper para sa PostgreSQL/MySQL.
- Ang DynamoDB ay isang AWS analogue ng isang database na nakabatay sa dokumento, katulad ng Redis at MongoDB.
- Ang Amazon Redshift ay isang pinamamahalaang analytical database.
Ang mga ito ay karaniwang mga lumang database, ngunit pinalaki sa isang pinamamahalaang kapaligiran, nang hindi nangangailangan na magtrabaho sa hardware.
Tandaan. Ang mga halimbawa ay kinuha para sa AWS environment, ngunit ang kanilang mga analogue ay umiiral din sa Microsoft Azure, Google Cloud, o Yandex.Cloud.
Ano ang bago dito? Sa 2020, wala nito.
Konsepto na walang server
Ang talagang bago sa merkado sa 2020 ay walang server o walang server na mga solusyon.
Susubukan kong ipaliwanag kung ano ang ibig sabihin nito gamit ang halimbawa ng isang regular na serbisyo o backend na application.
Para mag-deploy ng regular na backend na application, bumibili o umarkila kami ng server, kopyahin ang code dito, i-publish ang endpoint sa labas at regular na nagbabayad para sa renta, kuryente at mga serbisyo ng data center. Ito ang karaniwang scheme.
Mayroon bang ibang paraan? Sa mga serbisyong walang server magagawa mo.
Ano ang pokus ng diskarteng ito: walang server, hindi man lang nagrenta ng virtual na instance sa cloud. Upang i-deploy ang serbisyo, kopyahin ang code (mga function) sa repositoryo at i-publish ito sa endpoint. Pagkatapos ay binabayaran lang namin ang bawat tawag sa function na ito, ganap na binabalewala ang hardware kung saan ito isinasagawa.
Susubukan kong ilarawan ang diskarte na ito gamit ang mga larawan.
Klasikong deployment. Mayroon kaming isang serbisyo na may tiyak na pagkarga. Nagtaas kami ng dalawang pagkakataon: mga pisikal na server o mga pagkakataon sa AWS. Ang mga panlabas na kahilingan ay ipinapadala sa mga pagkakataong ito at pinoproseso doon.
Tulad ng makikita mo sa larawan, ang mga server ay hindi itinatapon nang pantay. Ang isa ay 100% nagamit, mayroong dalawang kahilingan, at ang isa ay 50% lamang - bahagyang idle. Kung hindi dumating ang tatlong kahilingan, ngunit 30, kung gayon ang buong sistema ay hindi makakayanan ang pagkarga at magsisimulang bumagal.
Walang server na pag-deploy. Sa isang walang server na kapaligiran, ang naturang serbisyo ay walang mga pagkakataon o server. Mayroong isang tiyak na pool ng pinainit na mapagkukunan - maliit na inihandang mga lalagyan ng Docker na may naka-deploy na function code. Ang system ay tumatanggap ng mga panlabas na kahilingan at para sa bawat isa sa kanila ang serverless framework ay nagtataas ng isang maliit na lalagyan na may code: pinoproseso nito ang partikular na kahilingang ito at pinapatay ang lalagyan.
Isang kahilingan - isang lalagyan ang nakataas, 1000 kahilingan - 1000 lalagyan. At ang pag-deploy sa mga server ng hardware ay gawain na ng cloud provider. Ito ay ganap na nakatago ng walang server na framework. Sa konseptong ito binabayaran namin ang bawat tawag. Halimbawa, isang tawag ang dumating sa isang araw - nagbayad kami ng isang tawag, isang milyon ang dumating kada minuto - nagbayad kami ng isang milyon. O sa isang segundo, nangyayari rin ito.
Ang konsepto ng pag-publish ng isang serverless function ay angkop para sa isang stateless na serbisyo. At kung kailangan mo ng isang (estado) statefull na serbisyo, pagkatapos ay nagdaragdag kami ng database sa serbisyo. Sa kasong ito, pagdating sa pagtatrabaho sa estado, ang bawat statefull function ay nagsusulat at nagbabasa lamang mula sa database. Bukod dito, mula sa isang database ng alinman sa tatlong uri na inilarawan sa simula ng artikulo.
Ano ang karaniwang limitasyon ng lahat ng mga database na ito? Ito ang mga gastos ng isang palaging ginagamit na cloud o hardware server (o ilang mga server). Hindi mahalaga kung gumagamit kami ng classic o pinamamahalaang database, mayroon man kaming Devops at isang admin o wala, nagbabayad pa rin kami para sa pagrenta ng hardware, kuryente at data center 24/7. Kung mayroon kaming isang klasikong base, binabayaran namin ang panginoon at alipin. Kung ito ay isang napaka-load na sharded database, nagbabayad kami para sa 10, 20 o 30 server, at patuloy kaming nagbabayad.
Ang pagkakaroon ng mga permanenteng nakalaan na server sa istraktura ng gastos ay dating napagtanto bilang isang kinakailangang kasamaan. Ang mga maginoo na database ay mayroon ding iba pang mga kahirapan, tulad ng mga limitasyon sa bilang ng mga koneksyon, mga paghihigpit sa pag-scale, pinagkasunduan sa geo-distributed - maaari silang malutas sa ilang mga database, ngunit hindi lahat nang sabay-sabay at hindi perpektong.
Walang server na database - teorya
Tanong ng 2020: posible bang gawing walang server din ang database? Narinig na ng lahat ang tungkol sa serverless backend... subukan nating gawing serverless ang database?
Ito ay kakaiba, dahil ang database ay isang statefull na serbisyo, hindi masyadong angkop para sa walang server na imprastraktura. Kasabay nito, ang estado ng database ay napakalaki: gigabytes, terabytes, at sa analytical database kahit petabytes. Hindi napakadali na itaas ito sa magaan na mga lalagyan ng Docker.
Sa kabilang banda, halos lahat ng mga modernong database ay naglalaman ng isang malaking halaga ng lohika at mga bahagi: mga transaksyon, koordinasyon ng integridad, mga pamamaraan, mga dependency sa relasyon at maraming lohika. Para sa napakaraming lohika ng database, sapat na ang isang maliit na estado. Ang Gigabytes at Terabytes ay direktang ginagamit ng isang maliit na bahagi lamang ng lohika ng database na kasangkot sa direktang pagsasagawa ng mga query.
Alinsunod dito, ang ideya ay: kung ang bahagi ng lohika ay nagpapahintulot sa stateless execution, bakit hindi hatiin ang base sa Stateful at Stateless na mga bahagi.
Walang server para sa mga solusyon sa OLAP
Tingnan natin kung ano ang maaaring hitsura ng pagputol ng isang database sa Stateful at Stateless na mga bahagi gamit ang mga praktikal na halimbawa.
Halimbawa, mayroon kaming isang analytical database: panlabas na data (pulang silindro sa kaliwa), isang proseso ng ETL na naglo-load ng data sa database, at isang analyst na nagpapadala ng mga query sa SQL sa database. Ito ay isang klasikong pamamaraan ng pagpapatakbo ng data warehouse.
Sa pamamaraang ito, ang ETL ay may kondisyong isinasagawa nang isang beses. Pagkatapos ay kailangan mong patuloy na magbayad para sa mga server kung saan tumatakbo ang database ng data na puno ng ETL, upang mayroong isang bagay na magpadala ng mga query.
Tingnan natin ang isang alternatibong diskarte na ipinatupad sa AWS Athena Serverless. Walang permanenteng nakatalagang hardware kung saan iniimbak ang na-download na data. Sa halip na ito:
- Nagsusumite ang user ng SQL query kay Athena. Sinusuri ng Athena optimizer ang SQL query at hinahanap ang metadata store (Metadata) para sa partikular na data na kailangan upang maisagawa ang query.
- Ang optimizer, batay sa nakolektang data, ay nagda-download ng kinakailangang data mula sa mga panlabas na mapagkukunan patungo sa pansamantalang imbakan (pansamantalang database).
- Ang isang SQL query mula sa gumagamit ay isinasagawa sa pansamantalang imbakan at ang resulta ay ibinalik sa gumagamit.
- Ang pansamantalang imbakan ay na-clear at ang mga mapagkukunan ay inilabas.
Sa arkitektura na ito, nagbabayad lang kami para sa proseso ng pagpapatupad ng kahilingan. Walang mga kahilingan - walang gastos.
Ito ay isang gumaganang diskarte at ipinatupad hindi lamang sa Athena Serverless, kundi pati na rin sa Redshift Spectrum (sa AWS).
Ang halimbawa ng Athena ay nagpapakita na ang Serverless database ay gumagana sa mga totoong query na may sampu at daan-daang Terabytes ng data. Daan-daang Terabytes ang mangangailangan ng daan-daang mga server, ngunit hindi namin kailangang magbayad para sa mga ito - binabayaran namin ang mga kahilingan. Ang bilis ng bawat kahilingan ay (napakababa) kumpara sa mga dalubhasang analytical database tulad ng Vertica, ngunit hindi kami nagbabayad para sa mga downtime period.
Ang nasabing database ay naaangkop para sa mga bihirang analytical ad-hoc na query. Halimbawa, kapag kami ay kusang nagpasya na subukan ang isang hypothesis sa ilang napakalaking dami ng data. Si Athena ay perpekto para sa mga kasong ito. Para sa mga regular na kahilingan, ang ganitong sistema ay mahal. Sa kasong ito, i-cache ang data sa ilang espesyal na solusyon.
Walang server para sa mga solusyon sa OLTP
Ang nakaraang halimbawa ay tumingin sa OLAP (analytical) na mga gawain. Ngayon tingnan natin ang mga gawain sa OLTP.
Isipin natin ang scalable na PostgreSQL o MySQL. Magtaas tayo ng regular na pinamamahalaang instance na PostgreSQL o MySQL na may kaunting mapagkukunan. Kapag nakatanggap ng mas maraming load ang instance, magkokonekta kami ng mga karagdagang replika kung saan ibabahagi namin ang bahagi ng reading load. Kung walang mga kahilingan o pag-load, pinapatay namin ang mga replika. Ang unang pagkakataon ay ang master, at ang natitira ay mga replika.
Ang ideyang ito ay ipinatupad sa isang database na tinatawag na Aurora Serverless AWS. Ang prinsipyo ay simple: ang mga kahilingan mula sa mga panlabas na aplikasyon ay tinatanggap ng proxy fleet. Nakikita ang pagtaas ng load, naglalaan ito ng mga mapagkukunan sa pag-compute mula sa mga pre-warmed minimal na pagkakataon - ang koneksyon ay ginagawa nang mabilis hangga't maaari. Ang hindi pagpapagana ng mga pagkakataon ay nangyayari sa parehong paraan.
Sa loob ng Aurora mayroong konsepto ng Aurora Capacity Unit, ACU. Ito ay (may kondisyon) isang halimbawa (server). Ang bawat partikular na ACU ay maaaring isang master o isang alipin. Ang bawat Capacity Unit ay may sariling RAM, processor at minimal na disk. Alinsunod dito, ang isa ay master, ang natitira ay read only replicas.
Ang bilang ng mga Aurora Capacity Unit na ito na tumatakbo ay isang na-configure na parameter. Ang pinakamababang dami ay maaaring isa o zero (sa kasong ito, ang database ay hindi gagana kung walang mga kahilingan).
Kapag ang base ay nakatanggap ng mga kahilingan, ang proxy fleet ay nagtataas ng Aurora CapacityUnits, na nagpapataas ng mga mapagkukunan ng pagganap ng system. Ang kakayahang dagdagan at bawasan ang mga mapagkukunan ay nagbibigay-daan sa system na "mag-juggle" ng mga mapagkukunan: awtomatikong magpakita ng mga indibidwal na ACU (papalitan ang mga ito ng mga bago) at ilunsad ang lahat ng kasalukuyang mga update sa mga na-withdraw na mapagkukunan.
Maaaring sukatin ng Aurora Serverless base ang reading load. Ngunit hindi ito direktang sinasabi ng dokumentasyon. Maaaring pakiramdam na maaari nilang iangat ang isang multi-master. Walang magic.
Ang database na ito ay angkop na angkop upang maiwasan ang paggastos ng malaking halaga ng pera sa mga system na may hindi inaasahang pag-access. Halimbawa, kapag gumagawa ng MVP o marketing business card na mga site, kadalasan ay hindi namin inaasahan ang isang matatag na pagkarga. Alinsunod dito, kung walang access, hindi kami nagbabayad para sa mga pagkakataon. Kapag may nangyaring hindi inaasahang pag-load, halimbawa pagkatapos ng kumperensya o kampanya sa pag-advertise, maraming tao ang bumibisita sa site at tumataas nang husto ang load, awtomatikong kinukuha ng Aurora Serverless ang load na ito at mabilis na ikinokonekta ang mga nawawalang mapagkukunan (ACU). Pagkatapos ay lumipas ang kumperensya, nakalimutan ng lahat ang tungkol sa prototype, ang mga server (ACU) ay madilim, at ang mga gastos ay bumaba sa zero - maginhawa.
Ang solusyon na ito ay hindi angkop para sa stable na highload dahil hindi nito nasusukat ang writing load. Ang lahat ng mga koneksyon at pagdiskonekta ng mga mapagkukunan ay nangyayari sa tinatawag na "scale point" - isang punto sa oras kung kailan ang database ay hindi suportado ng isang transaksyon o pansamantalang mga talahanayan. Halimbawa, sa loob ng isang linggo ang scale point ay maaaring hindi mangyari, at ang base ay gumagana sa parehong mga mapagkukunan at hindi maaaring lumawak o makontrata.
Walang magic - ito ay regular na PostgreSQL. Ngunit ang proseso ng pagdaragdag ng mga makina at pagdiskonekta sa mga ito ay bahagyang awtomatiko.
Walang server ayon sa disenyo
Ang Aurora Serverless ay isang lumang database na muling isinulat para sa cloud upang samantalahin ang ilan sa mga benepisyo ng Serverless. At ngayon sasabihin ko sa iyo ang tungkol sa base, na orihinal na isinulat para sa cloud, para sa walang server na diskarte - Serverless-by-design. Agad itong binuo nang walang pag-aakalang tatakbo ito sa mga pisikal na server.
Ang base na ito ay tinatawag na Snowflake. Mayroon itong tatlong pangunahing bloke.
Ang una ay isang metadata block. Ito ay isang mabilis na serbisyo sa memorya na lumulutas ng mga isyu sa seguridad, metadata, mga transaksyon, at pag-optimize ng query (ipinapakita sa larawan sa kaliwa).
Ang pangalawang bloke ay isang hanay ng mga virtual computing cluster para sa mga kalkulasyon (sa ilustrasyon ay mayroong isang hanay ng mga asul na bilog).
Ang ikatlong bloke ay isang sistema ng pag-iimbak ng data batay sa S3. Ang S3 ay walang sukat na imbakan ng bagay sa AWS, na parang walang sukat na Dropbox para sa negosyo.
Tingnan natin kung paano gumagana ang Snowflake, kung ipagpalagay na isang malamig na simula. Iyon ay, mayroong isang database, ang data ay na-load dito, walang tumatakbong mga query. Alinsunod dito, kung walang mga kahilingan sa database, itinaas namin ang mabilis na in-memory na serbisyo ng Metadata (unang block). At mayroon kaming imbakan ng S3, kung saan naka-imbak ang data ng talahanayan, na nahahati sa tinatawag na micropartition. Para sa pagiging simple: kung ang talahanayan ay naglalaman ng mga transaksyon, ang mga micropartition ay ang mga araw ng mga transaksyon. Araw-araw ay isang hiwalay na micropartition, isang hiwalay na file. At kapag ang database ay nagpapatakbo sa mode na ito, magbabayad ka lamang para sa espasyo na inookupahan ng data. Bukod dito, ang rate sa bawat upuan ay napakababa (lalo na kung isasaalang-alang ang makabuluhang compression). Patuloy ding gumagana ang serbisyo ng metadata, ngunit hindi mo kailangan ng maraming mapagkukunan para ma-optimize ang mga query, at maituturing na shareware ang serbisyo.
Ngayon isipin natin na may isang user ang pumunta sa aming database at nagpadala ng SQL query. Ang SQL query ay agad na ipinadala sa serbisyo ng Metadata para sa pagproseso. Alinsunod dito, sa pagtanggap ng kahilingan, sinusuri ng serbisyong ito ang kahilingan, available na data, mga pahintulot ng user at, kung maayos ang lahat, gagawa ng plano para sa pagproseso ng kahilingan.
Susunod, sinisimulan ng serbisyo ang paglulunsad ng kumpol ng computing. Ang computing cluster ay isang cluster ng mga server na nagsasagawa ng mga kalkulasyon. Iyon ay, ito ay isang kumpol na maaaring maglaman ng 1 server, 2 server, 4, 8, 16, 32 - hangga't gusto mo. Maghagis ka ng kahilingan at magsisimula kaagad ang paglulunsad ng cluster na ito. Ito ay talagang tumatagal ng mga segundo.
Susunod, pagkatapos magsimula ang cluster, ang mga micropartition na kailangan para maproseso ang iyong kahilingan ay magsisimulang makopya sa cluster mula sa S3. Iyon ay, isipin natin na upang magsagawa ng isang SQL query kailangan mo ng dalawang partisyon mula sa isang talahanayan at isa mula sa pangalawa. Sa kasong ito, ang tatlong kinakailangang partisyon lamang ang makokopya sa kumpol, at hindi lahat ng mga talahanayan nang buo. Iyon ang dahilan kung bakit, at tiyak dahil ang lahat ay matatagpuan sa loob ng isang data center at konektado sa pamamagitan ng napakabilis na mga channel, ang buong proseso ng paglilipat ay nangyayari nang napakabilis: sa mga segundo, napakabihirang sa ilang minuto, maliban kung pinag-uusapan natin ang tungkol sa ilang napakalaking kahilingan . Alinsunod dito, ang mga micropartition ay kinopya sa computing cluster, at, kapag nakumpleto, ang SQL query ay isasagawa sa computing cluster na ito. Ang resulta ng kahilingang ito ay maaaring isang linya, ilang linya o isang talahanayan - ipinapadala ang mga ito sa labas sa user upang ma-download niya ito, ipakita ito sa kanyang BI tool, o gamitin ito sa ibang paraan.
Ang bawat query sa SQL ay hindi lamang makakapagbasa ng mga pinagsama-samang mula sa dating na-load na data, ngunit naglo-load/bumuo din ng bagong data sa database. Iyon ay, maaari itong maging isang query na, halimbawa, naglalagay ng mga bagong tala sa isa pang talahanayan, na humahantong sa paglitaw ng isang bagong partisyon sa cluster ng computing, na, sa turn, ay awtomatikong nai-save sa isang solong imbakan ng S3.
Ang senaryo na inilarawan sa itaas, mula sa pagdating ng user hanggang sa pagtaas ng cluster, paglo-load ng data, pagsasagawa ng mga query, pagkuha ng mga resulta, ay binabayaran sa rate para sa mga minuto ng paggamit ng nakataas na virtual computing cluster, virtual warehouse. Nag-iiba ang rate depende sa AWS zone at laki ng kumpol, ngunit sa karaniwan ay ilang dolyar bawat oras. Ang kumpol ng apat na makina ay dalawang beses na mas mahal kaysa sa isang kumpol ng dalawang makina, at ang kumpol ng walong makina ay doble pa rin ang mahal. Available ang mga opsyon ng 16, 32 machine, depende sa pagiging kumplikado ng mga kahilingan. Ngunit magbabayad ka lamang para sa mga minutong iyon kapag ang kumpol ay aktwal na tumatakbo, dahil kapag walang mga kahilingan, uri mong alisin ang iyong mga kamay, at pagkatapos ng 5-10 minutong paghihintay (isang na-configure na parameter) ito ay lalabas nang kusa, magbakante ng mga mapagkukunan at maging libre.
Ang isang ganap na makatotohanang senaryo ay kapag nagpadala ka ng kahilingan, lalabas ang cluster, medyo nagsasalita, sa isang minuto, bibilang ito ng isa pang minuto, pagkatapos ay limang minuto upang isara, at magbabayad ka para sa pitong minutong operasyon ng cluster na ito, at hindi para sa mga buwan at taon.
Ang unang senaryo na inilarawan gamit ang Snowflake sa isang setting ng solong user. Ngayon isipin natin na maraming gumagamit, na mas malapit sa totoong senaryo.
Sabihin nating marami kaming analyst at ulat ng Tableau na patuloy na binobomba ang aming database ng maraming simpleng analytical SQL query.
Bilang karagdagan, sabihin nating mayroon kaming mga mapag-imbento na Data Scientist na sumusubok na gumawa ng mga napakapangit na bagay gamit ang data, nagpapatakbo gamit ang sampu-sampung Terabytes, nagsusuri ng bilyun-bilyon at trilyong row ng data.
Para sa dalawang uri ng workload na inilarawan sa itaas, pinapayagan ka ng Snowflake na itaas ang ilang independiyenteng mga cluster ng computing na may iba't ibang kapasidad. Bukod dito, ang mga computing cluster na ito ay gumagana nang nakapag-iisa, ngunit may karaniwang pare-parehong data.
Para sa isang malaking bilang ng mga magaan na query, maaari kang magtaas ng 2-3 maliliit na cluster, halos 2 machine bawat isa. Maaaring ipatupad ang pag-uugaling ito, bukod sa iba pang mga bagay, gamit ang mga awtomatikong setting. Kaya sasabihin mo, "Snowflake, itaas ang isang maliit na kumpol. Kung ang pagkarga dito ay tumaas sa itaas ng isang tiyak na parameter, itaas ang isang katulad na pangalawa, pangatlo. Kapag ang kargada ay nagsimulang humupa, patayin ang labis." Upang kahit gaano karaming mga analyst ang dumating at magsimulang tumingin sa mga ulat, lahat ay may sapat na mapagkukunan.
Kasabay nito, kung tulog ang mga analyst at walang tumitingin sa mga ulat, maaaring tuluyang magdilim ang mga kumpol, at huminto ka sa pagbabayad para sa kanila.
Kasabay nito, para sa mabibigat na query (mula sa Data Scientists), maaari kang magtaas ng isang napakalaking cluster para sa 32 machine. Babayaran din ang cluster na ito para lamang sa mga minuto at oras na iyon kapag ang iyong higanteng kahilingan ay tumatakbo doon.
Ang pagkakataong inilarawan sa itaas ay nagbibigay-daan sa iyong hatiin hindi lamang 2, kundi pati na rin ang higit pang mga uri ng workload sa mga kumpol (ETL, pagsubaybay, pag-uulat ng materyalisasyon,...).
Ibuod natin ang Snowflake. Pinagsasama ng base ang isang magandang ideya at isang maisasagawang pagpapatupad. Sa ManyChat, ginagamit namin ang Snowflake para suriin ang lahat ng data na mayroon kami. Wala kaming tatlong kumpol, tulad ng sa halimbawa, ngunit mula 5 hanggang 9, na may iba't ibang laki. Mayroon kaming karaniwang 16-machine, 2-machine, at napakaliit din na 1-machine para sa ilang gawain. Matagumpay nilang naipamahagi ang load at hinahayaan kaming makatipid ng malaki.
Matagumpay na nasusukat ng database ang pag-load ng pagbabasa at pagsusulat. Ito ay isang malaking pagkakaiba at isang malaking tagumpay kumpara sa parehong "Aurora", na nagdala lamang ng pag-load ng pagbabasa. Binibigyang-daan ka ng Snowflake na sukatin ang iyong workload sa pagsusulat gamit ang mga computing cluster na ito. Iyon ay, tulad ng nabanggit ko, gumagamit kami ng ilang mga kumpol sa ManyChat, ang maliliit at napakaliit na mga kumpol ay pangunahing ginagamit para sa ETL, para sa paglo-load ng data. At ang mga analyst ay nakatira na sa mga medium cluster, na talagang hindi apektado ng ETL load, kaya mabilis silang gumana.
Alinsunod dito, ang database ay angkop na angkop para sa mga gawain ng OLAP. Gayunpaman, sa kasamaang-palad, hindi pa ito naaangkop para sa mga OLTP workload. Una, ang database na ito ay columnar, kasama ang lahat ng mga kasunod na kahihinatnan. Pangalawa, ang diskarte mismo, kapag para sa bawat kahilingan, kung kinakailangan, itataas mo ang isang kumpol ng computing at binaha ito ng data, sa kasamaang-palad, ay hindi pa sapat na mabilis para sa mga OLTP load. Ang paghihintay ng mga segundo para sa mga gawain sa OLAP ay normal, ngunit para sa mga gawaing OLTP ay hindi ito katanggap-tanggap; 100 ms ay magiging mas mahusay, o 10 ms ay magiging mas mahusay.
Kabuuan
Ang isang serverless database ay posible sa pamamagitan ng paghahati ng database sa Stateless at Stateful na mga bahagi. Maaaring napansin mo na sa lahat ng mga halimbawa sa itaas, ang Stateful na bahagi ay, medyo nagsasalita, nag-iimbak ng mga micro-partition sa S3, at ang Stateless ay ang optimizer, nagtatrabaho sa metadata, humahawak sa mga isyu sa seguridad na maaaring itaas bilang independiyenteng magaan na mga serbisyong Stateless.
Ang pagpapatupad ng mga query sa SQL ay maaari ding ituring bilang mga light-state na serbisyo na maaaring mag-pop up sa serverless mode, tulad ng Snowflake computing clusters, i-download lamang ang kinakailangang data, isagawa ang query at "lumabas."
Ang mga database ng antas ng produksyon na walang server ay magagamit na, gumagana ang mga ito. Ang mga walang server na database na ito ay handa nang pangasiwaan ang mga gawain sa OLAP. Sa kasamaang palad, para sa mga gawain ng OLTP ginagamit ang mga ito... na may mga nuances, dahil may mga limitasyon. Sa isang banda, ito ay isang minus. Ngunit, sa kabilang banda, ito ay isang pagkakataon. Marahil ang isa sa mga mambabasa ay makakahanap ng isang paraan upang gawing ganap na walang server ang isang database ng OLTP, nang walang mga limitasyon ng Aurora.
Sana ay nakita mo itong kawili-wili. Serverless ang kinabukasan :)
Pinagmulan: www.habr.com