Kumusta tanan! Ang akong ngalan mao si Golov Nikolay. Kaniadto, nagtrabaho ko sa Avito ug nagdumala sa Data Platform sulod sa unom ka tuig, nga mao, nagtrabaho ko sa tanang database: analytical (Vertica, ClickHouse), streaming ug OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Niini nga panahon, nakiglabot ako sa daghang mga database - lahi kaayo ug dili kasagaran, ug uban ang dili standard nga mga kaso sa ilang paggamit.
Nagtrabaho ko karon sa ManyChat. Sa esensya, kini usa ka pagsugod - bag-o, ambisyoso ug paspas nga pagtubo. Ug sa una kong pag-apil sa kompanya, usa ka klasiko nga pangutana ang mitungha: "Unsa ang kinahanglan nga makuha sa usa ka batan-on nga pagsugod gikan sa merkado sa DBMS ug database?"
Niini nga artikulo, base sa akong report sa , tubagon nako ni nga pangutana. Ang usa ka video nga bersyon sa report anaa sa .
Kasagaran nga nailhan nga mga database 2020
2020 na, mitan-aw ko sa palibot ug nakita nako ang tulo ka klase sa mga database.
Unang tipo - klasiko nga mga database sa OLTP: PostgreSQL, SQL Server, Oracle, MySQL. Gisulat kini dugay na ang milabay, apan may kalabutan gihapon tungod kay pamilyar kaayo sila sa komunidad sa developer.
Ang ikaduha nga tipo mao ang base gikan sa "zero". Gisulayan nila nga magpalayo gikan sa mga klasiko nga sumbanan pinaagi sa pagbiya sa SQL, tradisyonal nga mga istruktura ug ACID, pinaagi sa pagdugang sa built-in nga sharding ug uban pang madanihon nga mga bahin. Pananglitan, kini mao ang Cassandra, MongoDB, Redis o Tarantool. Ang tanan nga kini nga mga solusyon gusto nga itanyag ang merkado sa usa ka butang nga bag-o nga sukaranan ug giokupar ang ilang niche tungod kay nahimo kini nga labi ka kombenyente alang sa pipila nga mga buluhaton. Akong ipasabut kini nga mga database nga adunay payong nga termino nga NOSQL.
Ang "zero" nahuman na, naanad na kami sa mga database sa NOSQL, ug ang kalibutan, gikan sa akong panglantaw, mihimo sa sunod nga lakang - sa gidumala nga mga database. Kini nga mga database adunay parehas nga kinauyokan sa klasiko nga mga database sa OLTP o bag-ong mga NoSQL. Apan wala nila kinahanglana ang DBA ug DevOps ug nagdagan sa pagdumala nga hardware sa mga panganod. Alang sa usa ka developer, kini "usa lang ka base" nga nagtrabaho sa usa ka dapit, apan walay usa nga nagpakabana kung giunsa kini gi-install sa server, kinsa ang nag-configure sa server ug kinsa ang nag-update niini.
Mga pananglitan sa ingon nga mga database:
- Ang AWS RDS usa ka gidumala nga wrapper para sa PostgreSQL/MySQL.
- Ang DynamoDB usa ka AWS analogue sa database base sa dokumento, susama sa Redis ug MongoDB.
- Ang Amazon Redshift usa ka gidumala nga analytical database.
Kini sa batakan nga mga karaan nga database, apan gipadako sa usa ka gidumala nga palibot, nga wala kinahanglana nga magtrabaho sa hardware.
Nota. Ang mga pananglitan gikuha alang sa AWS environment, apan ang ilang mga analogue anaa usab sa Microsoft Azure, Google Cloud, o Yandex.Cloud.
Unsay bag-o niini? Sa 2020, wala niini.
Konsepto nga walay server
Ang tinuod nga bag-o sa merkado sa 2020 mao ang serverless o serverless nga mga solusyon.
Akong sulayan nga ipasabut kung unsa ang gipasabut niini gamit ang pananglitan sa usa ka regular nga serbisyo o aplikasyon sa backend.
Aron ma-deploy ang usa ka regular nga aplikasyon sa backend, kami mopalit o mag-abang sa usa ka server, kopyahon ang code niini, imantala ang katapusan nga punto sa gawas ug kanunay nga magbayad alang sa abang, kuryente ug mga serbisyo sa sentro sa datos. Kini ang sumbanan nga laraw.
Aduna bay laing paagi? Sa mga serbisyo nga walay server mahimo nimo.
Unsa ang pokus sa kini nga pamaagi: wala’y server, wala’y nag-abang bisan usa ka virtual nga pananglitan sa panganod. Aron ma-deploy ang serbisyo, kopyaha ang code (functions) sa repository ug i-publish kini sa endpoint. Dayon nagbayad lang kami sa matag tawag niini nga function, hingpit nga wala magtagad sa hardware diin kini gipatuman.
Ako mosulay sa pag-ilustrar niini nga paagi sa mga hulagway.
Classic nga pag-deploy. Kami adunay usa ka serbisyo nga adunay usa ka piho nga karga. Nagpataas kami og duha ka mga higayon: pisikal nga mga server o mga higayon sa AWS. Ang mga hangyo sa gawas gipadala sa kini nga mga higayon ug giproseso didto.
Sama sa imong makita sa litrato, ang mga server dili parehas nga gilabay. Ang usa 100% gigamit, adunay duha ka hangyo, ug ang usa 50% ra - partially idle. Kung dili tulo ka mga hangyo ang moabut, apan 30, nan ang tibuuk nga sistema dili makasagubang sa pagkarga ug magsugod sa paghinay.
Pag-deploy nga walay server. Sa usa ka palibot nga wala’y server, ang ingon nga serbisyo wala’y mga higayon o mga server. Adunay usa ka piho nga pundok sa gipainit nga mga kapanguhaan - gagmay nga giandam nga mga sudlanan sa Docker nga adunay gi-deploy nga function code. Ang sistema nakadawat sa gawas nga mga hangyo ug alang sa matag usa kanila ang walay server nga balangkas nagpataas sa usa ka gamay nga sudlanan nga adunay code: kini nagproseso niining partikular nga hangyo ug nagpatay sa sudlanan.
Usa ka hangyo - usa ka sudlanan nga gipataas, 1000 ka hangyo - 1000 ka sudlanan. Ug ang pag-deploy sa mga server sa hardware mao na ang buhat sa cloud provider. Kini hingpit nga gitago sa walay server nga balangkas. Niini nga konsepto nagbayad kami sa matag tawag. Pananglitan, usa ka tawag ang moabut sa usa ka adlaw - mibayad kami sa usa ka tawag, usa ka milyon ang moabut kada minuto - mibayad kami og usa ka milyon. O sa usa ka segundo, mahitabo usab kini.
Ang konsepto sa pagmantala sa usa ka serverless function angay alang sa usa ka stateless nga serbisyo. Ug kung kinahanglan nimo ang usa ka (estado) nga statefull nga serbisyo, nan kami nagdugang usa ka database sa serbisyo. Sa kini nga kaso, kung bahin sa pagtrabaho kauban ang estado, ang matag statefull function yano nga nagsulat ug nagbasa gikan sa database. Dugang pa, gikan sa usa ka database sa bisan unsa sa tulo ka mga matang nga gihulagway sa sinugdanan sa artikulo.
Unsa ang kasagarang limitasyon sa tanan niini nga mga database? Kini ang mga gasto sa usa ka kanunay nga gigamit nga cloud o hardware server (o daghang mga server). Dili igsapayan kung mogamit kami usa ka klasiko o gidumala nga database, kung kami adunay Devops ug usa ka admin o wala, nagbayad gihapon kami alang sa pag-abang sa hardware, kuryente ug data center 24/7. Kung kami adunay usa ka klasiko nga base, nagbayad kami alang sa agalon ug ulipon. Kung kini usa ka puno kaayo nga sharded database, nagbayad kami sa 10, 20 o 30 nga mga server, ug kanunay kaming nagbayad.
Ang presensya sa permanente nga gireserba nga mga server sa istruktura sa gasto kaniadto giisip nga usa ka kinahanglan nga daotan. Ang naandan nga mga database usab adunay uban nga mga kalisud, sama sa mga limitasyon sa gidaghanon sa mga koneksyon, mga pagdili sa pag-scale, geo-apod-apod nga consensus - kini mahimo nga masulbad sa pipila ka mga database, apan dili tanan sa usa ka higayon ug dili sa labing maayo.
Wala'y server nga database - teorya
Pangutana sa 2020: posible ba nga maghimo usab usa ka database nga wala’y server? Ang tanan nakadungog bahin sa serverless backend... atong sulayan nga himoon ang database nga walay server?
Katingad-an kini nga paminawon, tungod kay ang database usa ka statefull nga serbisyo, dili kaayo angay alang sa walay server nga imprastraktura. Sa samang higayon, ang estado sa database dako kaayo: gigabytes, terabytes, ug sa analytical databases bisan mga petabytes. Dili kaayo sayon ang pagpataas niini sa gaan nga mga sudlanan sa Docker.
Sa laing bahin, hapit tanan nga modernong mga database adunay daghang lohika ug mga sangkap: mga transaksyon, koordinasyon sa integridad, mga pamaagi, mga dependency sa relasyon ug daghang lohika. Alang sa daghang lohika sa database, igo na ang gamay nga estado. Gigabytes ug Terabytes direkta nga gigamit sa gamay nga bahin sa lohika sa database nga nalambigit sa direkta nga pagpatuman sa mga pangutana.
Busa, ang ideya mao: kung ang bahin sa lohika nagtugot sa walay estado nga pagpatay, nganong dili bahinon ang base ngadto sa Stateful ug Stateless nga mga bahin.
Wala’y server alang sa mga solusyon sa OLAP
Atong tan-awon kung unsa ang hitsura sa pagputol sa usa ka database ngadto sa Stateful ug Stateless nga mga bahin gamit ang praktikal nga mga pananglitan.
Pananglitan, kita adunay usa ka analytical database: eksternal nga datos (pula nga silindro sa wala), usa ka proseso sa ETL nga nagkarga sa datos ngadto sa database, ug usa ka analista nga nagpadala sa mga pangutana sa SQL ngadto sa database. Kini usa ka klasiko nga pamaagi sa operasyon sa bodega sa datos.
Sa kini nga laraw, ang ETL adunay kondisyon nga gihimo kausa. Unya kinahanglan nimo nga kanunay nga magbayad alang sa mga server diin ang database nagdagan nga adunay datos nga puno sa ETL, aron adunay usa ka butang nga ipadala sa mga pangutana.
Atong tan-awon ang usa ka alternatibong pamaagi nga gipatuman sa AWS Athena Serverless. Walay permanente nga gipahinungod nga hardware diin gitipigan ang na-download nga datos. Imbes niini:
- Nagsumite ang user og SQL query ngadto kang Athena. Ang Athena optimizer nag-analisar sa SQL query ug nangita sa metadata store (Metadata) alang sa piho nga datos nga gikinahanglan aron mapatuman ang pangutana.
- Ang optimizer, base sa nakolekta nga datos, nag-download sa gikinahanglan nga datos gikan sa gawas nga mga tinubdan ngadto sa temporaryo nga pagtipig (temporary database).
- Ang usa ka pangutana sa SQL gikan sa tiggamit gipatuman sa temporaryo nga pagtipig ug ang resulta ibalik sa tiggamit.
- Ang temporaryo nga pagtipig gilimpyohan ug ang mga kapanguhaan gipagawas.
Niini nga arkitektura, nagbayad lamang kami alang sa proseso sa pagpatuman sa hangyo. Walay hangyo - walay gasto.
Kini usa ka pamaagi sa pagtrabaho ug gipatuman dili lamang sa Athena Serverless, apan usab sa Redshift Spectrum (sa AWS).
Ang pananglitan sa Athena nagpakita nga ang Serverless database nagtrabaho sa tinuod nga mga pangutana nga adunay napulo ug gatusan ka Terabytes nga datos. Gatusan nga Terabytes ang nanginahanglan gatusan nga mga server, apan dili kami kinahanglan nga magbayad alang kanila - kami ang nagbayad sa mga hangyo. Ang katulin sa matag hangyo mao ang (kaayo) ubos kon itandi sa espesyal nga analytical database sama sa Vertica, apan wala kami mobayad alang sa downtime nga mga panahon.
Ang ingon nga database magamit alang sa talagsaon nga analytical ad-hoc nga mga pangutana. Pananglitan, sa diha nga kita sa kalit nga modesisyon sa pagsulay sa usa ka pangagpas sa pipila ka dako nga kantidad sa data. Si Athena perpekto alang niini nga mga kaso. Alang sa regular nga mga hangyo, ang ingon nga sistema mahal. Sa kini nga kaso, i-cache ang datos sa pipila ka espesyal nga solusyon.
Walay server alang sa mga solusyon sa OLTP
Ang miaging pananglitan nagtan-aw sa OLAP (analytical) nga mga buluhaton. Karon atong tan-awon ang mga buluhaton sa OLTP.
Atong hunahunaon ang scalable nga PostgreSQL o MySQL. Atong ipataas ang usa ka regular nga gidumala nga pananglitan nga PostgreSQL o MySQL nga adunay gamay nga kapanguhaan. Kung ang instance makadawat og dugang nga load, magkonektar kami og dugang nga mga replika diin among ipang-apod-apod ang bahin sa reading load. Kung walay mga hangyo o load, atong i-off ang mga replika. Ang unang higayon mao ang agalon, ug ang uban mga replika.
Kini nga ideya gipatuman sa usa ka database nga gitawag Aurora Serverless AWS. Ang prinsipyo yano ra: ang mga hangyo gikan sa gawas nga mga aplikasyon gidawat sa proxy fleet. Sa pagtan-aw sa pagtaas sa load, kini naggahin sa mga kapanguhaan sa pag-compute gikan sa pre-warmed minimal nga mga higayon - ang koneksyon gihimo sa labing madali nga panahon. Ang pag-disable sa mga higayon mahitabo sa samang paagi.
Sulod sa Aurora adunay konsepto sa Aurora Capacity Unit, ACU. Kini (kondisyon) usa ka pananglitan (server). Ang matag piho nga ACU mahimong usa ka agalon o usa ka ulipon. Ang matag Capacity Unit adunay kaugalingon nga RAM, processor ug gamay nga disk. Tungod niini, ang usa mao ang agalon, ang uban gibasa lamang nga mga replika.
Ang gidaghanon sa mga Aurora Capacity Units nga nagdagan usa ka ma-configure nga parameter. Ang minimum nga gidaghanon mahimong usa o zero (sa kini nga kaso, ang database dili molihok kung walay mga hangyo).
Kung ang base nakadawat mga hangyo, ang proxy fleet nagpataas sa Aurora CapacityUnits, nga nagdugang sa mga kapanguhaan sa pasundayag sa sistema. Ang abilidad sa pagdugang ug pagkunhod sa mga kahinguhaan nagtugot sa sistema sa "pag-juggle" nga mga kapanguhaan: awtomatikong ipakita ang indibidwal nga mga ACU (ilisan kini sa mga bag-o) ug i-roll out ang tanan nga karon nga mga update sa gi-withdraw nga mga kapanguhaan.
Ang Aurora Serverless nga base mahimong masukod ang pagkarga sa pagbasa. Apan ang dokumentasyon wala direktang nagsulti niini. Mahimong gibati nga sila makabayaw sa usa ka multi-master. Walay magic.
Ang kini nga database haum kaayo aron malikayan ang paggasto og daghang kantidad sa salapi sa mga sistema nga adunay dili matag-an nga pag-access. Pananglitan, sa paghimo sa MVP o pagpamaligya sa mga site sa business card, kasagaran wala kami magdahom nga usa ka lig-on nga karga. Busa, kung walay access, dili kami mobayad sa mga higayon. Kung mahitabo ang wala damha nga pagkarga, pananglitan pagkahuman sa usa ka komperensya o kampanya sa advertising, daghang mga tawo ang mobisita sa site ug ang load mahinuklugong motaas, Aurora Serverless awtomatik nga gikuha kini nga load ug dali nga nagkonektar sa nawala nga mga kapanguhaan (ACU). Pagkahuman ang komperensya, nakalimtan sa tanan ang bahin sa prototype, ang mga server (ACU) nangitngit, ug ang mga gasto nahulog sa zero - kombenyente.
Kini nga solusyon dili angay alang sa stable nga highload tungod kay dili kini makasukod sa load sa pagsulat. Ang tanan niini nga mga koneksyon ug pagdiskonekta sa mga kahinguhaan mahitabo sa gitawag nga "scale point" - usa ka punto sa panahon nga ang database wala gisuportahan sa usa ka transaksyon o temporaryo nga mga lamesa. Pananglitan, sa sulod sa usa ka semana ang sukdanan nga punto mahimong dili mahitabo, ug ang base nagtrabaho sa parehas nga mga kahinguhaan ug dili gyud mapalapad o makontrata.
Walay magic - kini regular nga PostgreSQL. Apan ang proseso sa pagdugang sa mga makina ug pagdiskonekta niini partially automated.
Walay server pinaagi sa disenyo
Ang Aurora Serverless usa ka daan nga database nga gisulat pag-usab alang sa panganod aron mapahimuslan ang pipila ka mga benepisyo sa Serverless. Ug karon sultihan ko ikaw mahitungod sa base, nga orihinal nga gisulat alang sa panganod, alang sa walay server nga pamaagi - Serverless-by-design. Gipalambo dayon kini nga wala’y pag-isip nga kini modagan sa pisikal nga mga server.
Kini nga base gitawag nga Snowflake. Kini adunay tulo ka yawe nga mga bloke.
Ang una usa ka bloke sa metadata. Kini usa ka paspas nga serbisyo sa memorya nga nagsulbad sa mga isyu sa seguridad, metadata, mga transaksyon, ug pag-optimize sa pangutana (gipakita sa ilustrasyon sa wala).
Ang ikaduha nga bloke usa ka set sa virtual computing clusters alang sa mga kalkulasyon (sa ilustrasyon adunay usa ka set sa asul nga mga lingin).
Ang ikatulo nga bloke usa ka sistema sa pagtipig sa datos base sa S3. Ang S3 mao ang walay sukod nga pagtipig sa butang sa AWS, sama sa walay dimensiyon nga Dropbox alang sa negosyo.
Atong tan-awon kon sa unsang paagi naglihok ang Snowflake, nga nagtuo nga usa ka bugnaw nga pagsugod. Sa ato pa, adunay usa ka database, ang datos gikarga niini, wala’y nagdagan nga mga pangutana. Tungod niini, kung walay mga hangyo sa database, nan among gipataas ang paspas nga in-memorya nga serbisyo sa Metadata (unang block). Ug kami adunay S3 storage, diin ang mga datos sa lamesa gitipigan, gibahin sa gitawag nga micropartitions. Alang sa kayano: kung ang lamesa adunay mga transaksyon, nan ang mga micropartition mao ang mga adlaw sa mga transaksyon. Ang matag adlaw usa ka bulag nga micropartition, usa ka bulag nga file. Ug kung ang database naglihok sa kini nga mode, nagbayad ka lang alang sa wanang nga giokupar sa datos. Dugang pa, ang rate sa matag lingkoranan ubos kaayo (ilabi na ang pagkonsiderar sa mahinungdanong compression). Ang serbisyo sa metadata nagtrabaho usab kanunay, apan dili nimo kinahanglan ang daghang mga kapanguhaan aron ma-optimize ang mga pangutana, ug ang serbisyo mahimong makonsiderar nga shareware.
Karon atong hunahunaon nga ang usa ka user miadto sa atong database ug nagpadala sa usa ka SQL pangutana. Ang pangutana sa SQL gipadala dayon sa serbisyo sa Metadata alang sa pagproseso. Tungod niini, sa pagdawat sa usa ka hangyo, kini nga serbisyo nag-analisar sa hangyo, magamit nga datos, pagtugot sa user ug, kung maayo ang tanan, naghimo og usa ka plano alang sa pagproseso sa hangyo.
Sunod, gisugdan sa serbisyo ang paglansad sa cluster sa kompyuter. Ang computing cluster usa ka cluster sa mga server nga naghimo og mga kalkulasyon. Kana mao, kini usa ka cluster nga mahimong adunay 1 server, 2 server, 4, 8, 16, 32 - kutob sa imong gusto. Gilabay nimo ang usa ka hangyo ug ang paglansad niini nga cluster magsugod dayon. Nagkinahanglan gyud kini og mga segundo.
Sunod, human magsugod ang cluster, ang mga micropartition nga gikinahanglan sa pagproseso sa imong hangyo magsugod nga makopya ngadto sa cluster gikan sa S3. Sa ato pa, hunahunaon naton nga aron mapatuman ang usa ka pangutana sa SQL kinahanglan nimo ang duha nga partisyon gikan sa usa ka lamesa ug usa gikan sa ikaduha. Sa kini nga kaso, ang tulo ra nga kinahanglan nga partisyon ang makopya sa cluster, ug dili tanan nga mga lamesa sa tibuuk. Mao nga, ug tukma tungod kay ang tanan nahimutang sa sulod sa usa ka sentro sa datos ug konektado sa kusog kaayo nga mga kanal, ang tibuuk nga proseso sa pagbalhin mahitabo kaayo nga dali: sa mga segundo, panagsa ra sa mga minuto, gawas kung maghisgot kami bahin sa pipila ka makalilisang nga mga hangyo. Tungod niini, ang mga micropartition gikopya ngadto sa computing cluster, ug, sa pagkompleto, ang SQL query gipatuman niini nga computing cluster. Ang resulta niini nga hangyo mahimong usa ka linya, daghang linya o usa ka lamesa - kini gipadala sa gawas ngadto sa user aron iyang ma-download kini, ipakita kini sa iyang BI nga himan, o gamiton kini sa laing paagi.
Ang matag pangutana sa SQL dili lamang makabasa sa mga aggregate gikan sa na-load nga datos kaniadto, apan maka-load/makahimo usab ug bag-ong datos sa database. Kana mao, kini mahimo nga usa ka pangutana nga, pananglitan, nagsal-ot sa bag-ong mga rekord ngadto sa laing lamesa, nga mosangpot sa dagway sa usa ka bag-ong partition sa computing cluster, nga, sa baylo, awtomatikong maluwas sa usa ka storage sa S3.
Ang senaryo nga gihulagway sa ibabaw, gikan sa pag-abot sa user ngadto sa pagpataas sa cluster, pagkarga sa datos, pagpatuman sa mga pangutana, pagkuha sa mga resulta, gibayran sa rate sa mga minuto sa paggamit sa gipataas nga virtual computing cluster, virtual bodega. Nagkalainlain ang rate depende sa AWS zone ug gidak-on sa cluster, apan sa kasagaran kini pipila ka dolyar matag oras. Ang usa ka pungpong sa upat ka mga makina doble kamahal kay sa usa ka pungpong sa duha ka makina, ug ang usa ka pungpong sa walo ka mga makina doble pa sa kamahal. Ang mga kapilian sa 16, 32 nga mga makina magamit, depende sa pagkakomplikado sa mga hangyo. Apan nagbayad ka lamang sa mga minuto kung ang cluster nagdagan, tungod kay kung wala’y mga hangyo, imong kuhaon ang imong mga kamot, ug pagkahuman sa 5-10 minuto nga paghulat (usa ka ma-configure nga parameter) kini mogawas sa kaugalingon, gawasnon ang mga kapanguhaan ug mahimong gawasnon.
Ang usa ka hingpit nga realistiko nga senaryo mao ang kung magpadala ka usa ka hangyo, ang cluster mo-pop up, medyo nagsulti, sa usa ka minuto, nag-ihap kini usa ka minuto, dayon lima ka minuto aron masira, ug matapos nimo ang pagbayad sa pito ka minuto nga operasyon niini nga cluster, ug dili sa mga bulan ug tuig.
Ang unang senaryo nga gihulagway gamit ang Snowflake sa usa ka user setting. Karon atong hunahunaon nga adunay daghang mga tiggamit, nga mas duol sa tinuod nga senaryo.
Ingnon ta nga kami adunay daghang mga analista ug mga taho sa Tableau nga kanunay nga nagbomba sa among database sa daghang gidaghanon sa yano nga analytical nga mga pangutana sa SQL.
Dugang pa, ingnon ta nga kami adunay mga imbentibo nga Data Scientist nga naningkamot sa pagbuhat sa mga makalilisang nga butang gamit ang datos, naglihok nga adunay napulo ka Terabytes, nag-analisar sa bilyon-bilyon ug trilyon nga mga linya sa datos.
Alang sa duha ka matang sa workload nga gihulagway sa ibabaw, ang Snowflake nagtugot kanimo sa pagpataas sa ubay-ubay nga mga independent computing clusters sa lain-laing mga kapasidad. Dugang pa, kini nga mga cluster sa kompyuter nagtrabaho nga independente, apan adunay sagad nga makanunayon nga datos.
Alang sa daghang ihap sa gaan nga mga pangutana, mahimo nimong ipataas ang 2-3 ka gagmay nga mga pungpong, halos 2 ka makina matag usa. Kini nga pamatasan mahimong ipatuman, taliwala sa ubang mga butang, gamit ang mga awtomatikong setting. Busa moingon ka, “Snowflake, pagpataas ug gamayng pungpong. Kung ang pagkarga niini motaas sa usa ka piho nga parameter, ipataas ang parehas nga ikaduha, ikatulo. Sa diha nga ang luwan magsugod sa pagkunhod, palonga ang sobra. Aron nga bisan pila pa ka mga analista ang moabut ug magsugod sa pagtan-aw sa mga taho, ang tanan adunay igo nga mga kapanguhaan.
Sa samang higayon, kung ang mga analista natulog ug walay usa nga nagtan-aw sa mga taho, ang mga pungpong mahimong hingpit nga mangitngit, ug mohunong ka sa pagbayad alang kanila.
Sa samang higayon, alang sa bug-at nga mga pangutana (gikan sa Data Scientists), mahimo nimong ipataas ang usa ka dako kaayo nga cluster para sa 32 ka makina. Ang kini nga cluster mabayran usab alang sa mga minuto ug oras kung ang imong higante nga hangyo nagdagan didto.
Ang oportunidad nga gihulagway sa ibabaw nagtugot kanimo sa pagbahin dili lamang sa 2, apan usab sa daghang mga matang sa workload ngadto sa mga clusters (ETL, monitoring, report materialization,...).
Atong i-summarize ang Snowflake. Ang base naghiusa sa usa ka matahum nga ideya ug usa ka magamit nga pagpatuman. Sa ManyChat, gigamit namo ang Snowflake aron analisahon ang tanang datos nga naa namo. Wala kami tulo nga mga pungpong, sama sa pananglitan, apan gikan sa 5 hangtod 9, nga lainlain ang gidak-on. Kami adunay naandan nga 16-machine, 2-machine, ug usab super-gamay nga 1-machine alang sa pipila ka mga buluhaton. Malampuson nilang gipang-apod-apod ang load ug gitugotan mi nga makadaginot ug daghan.
Ang database malampuson nga nagtimbang sa pagbasa ug pagsulat nga load. Kini usa ka dako nga kalainan ug usa ka dako nga kauswagan kung itandi sa parehas nga "Aurora", nga nagdala lamang sa load sa pagbasa. Gitugotan ka sa snowflake nga ma-scale ang imong workload sa pagsulat gamit kini nga mga cluster sa kompyuter. Kana mao, sama sa akong nahisgutan, naggamit kami daghang mga kumpol sa ManyChat, ang gagmay ug labi ka gamay nga mga kumpol labi nga gigamit alang sa ETL, alang sa pagkarga sa datos. Ug ang mga analista nagpuyo na sa mga medium nga kumpol, nga hingpit nga wala maapektuhan sa pagkarga sa ETL, mao nga dali sila nga nagtrabaho.
Tungod niini, ang database haum kaayo alang sa mga buluhaton sa OLAP. Bisan pa, sa kasubo, dili pa kini magamit alang sa mga OLTP workloads. Una, kini nga database kolumnar, uban ang tanan nga mga sangputanan. Ikaduha, ang pamaagi mismo, kung alang sa matag hangyo, kung gikinahanglan, imong gipataas ang usa ka cluster sa kompyuter ug gibahaan kini sa datos, sa walay palad, dili pa igo nga kusog alang sa mga OLTP load. Ang paghulat sa mga segundo alang sa mga buluhaton sa OLAP normal, apan alang sa mga buluhaton sa OLTP kini dili madawat; 100 ms mas maayo, o 10 ms mas maayo pa.
Ang resulta
Ang usa ka serverless database posible pinaagi sa pagbahin sa database ngadto sa Stateless ug Stateful nga mga bahin. Mahimo nimong namatikdan nga sa tanan nga mga pananglitan sa ibabaw, ang Stateful nga bahin, medyo nagsulti, nagtipig sa mga micro-partition sa S3, ug ang Stateless mao ang optimizer, nagtrabaho kauban ang metadata, nagdumala sa mga isyu sa seguridad nga mahimo’g mapataas ingon independente nga gaan nga mga serbisyo sa Stateless.
Ang pagpatuman sa mga pangutana sa SQL mahimo usab nga isipon nga mga serbisyo sa light-state nga mahimong mo-pop up sa serverless mode, sama sa Snowflake computing clusters, i-download lamang ang gikinahanglan nga datos, ipatuman ang pangutana ug "go out."
Ang mga database sa lebel sa produksiyon nga wala’y server magamit na, nagtrabaho sila. Kining walay server nga mga database andam na sa pagdumala sa mga buluhaton sa OLAP. Ikasubo, alang sa mga buluhaton sa OLTP sila gigamit ... nga adunay mga nuances, tungod kay adunay mga limitasyon. Sa usa ka bahin, kini usa ka minus. Apan, sa laing bahin, kini usa ka oportunidad. Tingali ang usa sa mga magbabasa mangita usa ka paagi aron mahimo ang usa ka database sa OLTP nga hingpit nga wala’y server, nga wala’y mga limitasyon sa Aurora.
Nanghinaut ko nga nakit-an nimo kini nga makapaikag. Ang walay server mao ang umaabot :)
Source: www.habr.com