Salaam wote! Jina langu ni Golov Nikolay. Hapo awali, nilifanya kazi huko Avito na kusimamia Jukwaa la Data kwa miaka sita, yaani, nilifanya kazi kwenye hifadhidata zote: uchambuzi (Vertica, ClickHouse), utiririshaji na OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Wakati huu, nilishughulika na idadi kubwa ya hifadhidata - tofauti sana na isiyo ya kawaida, na kwa kesi zisizo za kawaida za matumizi yao.
Kwa sasa ninafanya kazi ManyChat. Kwa asili, hii ni mwanzo - mpya, yenye tamaa na inayokua kwa kasi. Na nilipojiunga na kampuni hiyo mara ya kwanza, swali la kawaida liliibuka: "Ni nini kinachopaswa kuanza kwa vijana kutoka kwa DBMS na soko la hifadhidata?"
Katika makala hii, kulingana na ripoti yangu katika , nitajibu swali hili. Toleo la video la ripoti linapatikana .
Hifadhidata zinazojulikana 2020
Ni 2020, nilitazama pande zote na nikaona aina tatu za hifadhidata.
Aina ya kwanza - hifadhidata za kawaida za OLTPUjuzi: PostgreSQL, Seva ya SQL, Oracle, MySQL. Yaliandikwa muda mrefu uliopita, lakini bado yanafaa kwa sababu yanafahamika sana na jumuiya ya wasanidi programu.
Aina ya pili ni misingi kutoka "sifuri". Walijaribu kuondokana na mifumo ya kawaida kwa kuacha SQL, miundo ya jadi na ACID, kwa kuongeza sharding iliyojumuishwa na vipengele vingine vya kuvutia. Kwa mfano, hii ni Cassandra, MongoDB, Redis au Tarantool. Suluhisho hizi zote zilitaka kutoa soko kitu kipya na kuchukua niche yao kwa sababu zilionekana kuwa rahisi sana kwa kazi fulani. Nitaashiria hifadhidata hizi na neno mwavuli NOSQL.
"Zero" zimekwisha, tulizoea hifadhidata za NOSQL, na ulimwengu, kwa maoni yangu, ulichukua hatua inayofuata - hifadhidata zinazosimamiwa. Hifadhidata hizi zina msingi sawa na hifadhidata za kawaida za OLTP au mpya za NoSQL. Lakini hawana haja ya DBA na DevOps na huendesha vifaa vinavyosimamiwa kwenye mawingu. Kwa msanidi programu, hii ni "msingi tu" unaofanya kazi mahali fulani, lakini hakuna mtu anayejali jinsi imewekwa kwenye seva, ambaye alisanidi seva na ambaye anaisasisha.
Mifano ya hifadhidata kama hizi:
- AWS RDS ni karatasi inayosimamiwa ya PostgreSQL/MySQL.
- DynamoDB ni analogi ya AWS ya hifadhidata inayotegemea hati, sawa na Redis na MongoDB.
- Amazon Redshift ni hifadhidata ya uchanganuzi inayosimamiwa.
Hizi ni hifadhidata za zamani, lakini zilizokuzwa katika mazingira yaliyosimamiwa, bila hitaji la kufanya kazi na vifaa.
Kumbuka. Mifano inachukuliwa kwa ajili ya mazingira ya AWS, lakini analogi zake pia zipo katika Microsoft Azure, Google Cloud, au Yandex.Cloud.
Nini kipya kuhusu hili? Mnamo 2020, hakuna hii.
Dhana isiyo na seva
Nini kipya kwenye soko mnamo 2020 ni suluhisho zisizo na seva au zisizo na seva.
Nitajaribu kuelezea hii inamaanisha nini kwa kutumia mfano wa huduma ya kawaida au programu ya nyuma.
Ili kupeleka maombi ya kawaida ya nyuma, tunanunua au kukodisha seva, tunakili msimbo humo, kuchapisha mwisho wa nje na kulipia kodi, umeme na huduma za kituo cha data mara kwa mara. Huu ndio mpango wa kawaida.
Je, kuna njia nyingine? Kwa huduma zisizo na seva unaweza.
Ni nini lengo la mbinu hii: hakuna seva, hakuna hata kukodisha mfano wa kawaida kwenye wingu. Ili kupeleka huduma, nakili msimbo (kazi) kwenye hazina na uchapishe hadi mwisho. Kisha sisi hulipa tu kila simu kwa kazi hii, tukipuuza kabisa vifaa ambako vinatekelezwa.
Nitajaribu kuelezea mbinu hii na picha.
Usambazaji wa kawaida. Tuna huduma yenye mzigo fulani. Tunatoa mifano miwili: seva halisi au matukio katika AWS. Maombi ya nje yanatumwa kwa matukio haya na kushughulikiwa huko.
Kama unavyoona kwenye picha, seva hazitupwa kwa usawa. Moja inatumika 100%, kuna maombi mawili, na moja ni 50% tu - bila kazi kwa sehemu. Ikiwa sio maombi matatu yanayofika, lakini 30, basi mfumo mzima hautaweza kukabiliana na mzigo na utaanza kupungua.
Usambazaji usio na seva. Katika mazingira yasiyo na seva, huduma kama hiyo haina matukio au seva. Kuna dimbwi fulani la rasilimali moto - vyombo vidogo vilivyotayarishwa vya Docker vilivyo na nambari ya kazi iliyotumwa. Mfumo hupokea maombi ya nje na kwa kila mmoja wao mfumo usio na seva huinua kontena ndogo na nambari: inashughulikia ombi hili na kuua kontena.
Ombi moja - kontena moja lililoinuliwa, ombi 1000 - kontena 1000. Na kupelekwa kwenye seva za vifaa tayari ni kazi ya mtoa huduma wa wingu. Imefichwa kabisa na mfumo usio na seva. Katika dhana hii tunalipa kwa kila simu. Kwa mfano, simu moja ilikuja kwa siku - tulilipia simu moja, milioni ilikuja kwa dakika - tulilipa milioni. Au kwa sekunde, hii pia hufanyika.
Dhana ya kuchapisha kazi isiyo na seva inafaa kwa huduma isiyo na uraia. Na ikiwa unahitaji (jimbo) huduma kamili, basi tunaongeza hifadhidata kwenye huduma. Katika kesi hii, linapokuja suala la kufanya kazi na serikali, kila kazi kamili huandika tu na kusoma kutoka kwa hifadhidata. Kwa kuongezea, kutoka kwa hifadhidata ya aina yoyote ya aina tatu zilizoelezewa mwanzoni mwa kifungu.
Je, ni kizuizi gani cha kawaida cha hifadhidata hizi zote? Hizi ni gharama za seva ya wingu inayotumiwa mara kwa mara au vifaa (au seva kadhaa). Haijalishi ikiwa tunatumia hifadhidata ya kawaida au inayodhibitiwa, iwe tuna Devops na msimamizi au la, bado tunalipia maunzi, umeme na ukodishaji wa kituo cha data 24/7. Ikiwa tuna msingi wa kawaida, tunalipa bwana na mtumwa. Ikiwa ni hifadhidata iliyopakiwa sana, tunalipia seva 10, 20 au 30, na tunalipa kila mara.
Uwepo wa seva zilizohifadhiwa kabisa katika muundo wa gharama hapo awali ulitambuliwa kama uovu muhimu. Hifadhidata za kawaida pia zina shida zingine, kama vile mipaka ya idadi ya miunganisho, vizuizi vya kuongeza, makubaliano ya kusambazwa kwa geo - zinaweza kutatuliwa kwa njia fulani katika hifadhidata fulani, lakini sio zote mara moja na sio sawa.
Database isiyo na seva - nadharia
Swali la 2020: inawezekana kufanya hifadhidata isiwe na seva pia? Kila mtu amesikia kuhusu hali ya nyuma isiyo na seva... hebu tujaribu kufanya hifadhidata isiwe na seva?
Hii inasikika ya kushangaza, kwa sababu hifadhidata ni huduma kamili, haifai sana kwa miundombinu isiyo na seva. Wakati huo huo, hali ya hifadhidata ni kubwa sana: gigabytes, terabytes, na katika hifadhidata za uchambuzi hata petabytes. Sio rahisi sana kuiinua kwenye vyombo vyepesi vya Docker.
Kwa upande mwingine, karibu hifadhidata zote za kisasa zina idadi kubwa ya mantiki na vifaa: shughuli, uratibu wa uadilifu, taratibu, utegemezi wa uhusiano na mantiki nyingi. Kwa mantiki nyingi za hifadhidata, hali ndogo inatosha. Gigabytes na Terabytes hutumiwa moja kwa moja na sehemu ndogo tu ya mantiki ya hifadhidata inayohusika katika kutekeleza maswali moja kwa moja.
Kwa hivyo, wazo ni: ikiwa sehemu ya mantiki inaruhusu utekelezaji usio na uraia, kwa nini usigawanye msingi katika sehemu zisizo na serikali na zisizo na utaifa.
Bila seva kwa suluhisho za OLAP
Wacha tuone jinsi kukata hifadhidata katika sehemu Zisizo na Uraia kunaweza kuonekana kwa kutumia mifano ya vitendo.
Kwa mfano, tuna hifadhidata ya uchanganuzi: data ya nje (silinda nyekundu upande wa kushoto), mchakato wa ETL ambao hupakia data kwenye hifadhidata, na mchambuzi anayetuma hoja za SQL kwenye hifadhidata. Huu ni mpango wa kawaida wa uendeshaji wa ghala la data.
Katika mpango huu, ETL inafanywa kwa masharti mara moja. Kisha unahitaji kulipa mara kwa mara kwa seva ambazo hifadhidata inaendesha na data iliyojazwa na ETL, ili kuna kitu cha kutuma maswali.
Wacha tuangalie mbinu mbadala iliyotekelezwa katika AWS Athena Serverless. Hakuna maunzi maalum ambayo data iliyopakuliwa huhifadhiwa. Badala ya hii:
- Mtumiaji anawasilisha swali la SQL kwa Athena. Kiboreshaji cha Athena huchanganua hoja ya SQL na kutafuta hifadhi ya metadata (Metadata) ili kupata data mahususi inayohitajika kutekeleza hoja.
- Kiboreshaji, kulingana na data iliyokusanywa, hupakua data muhimu kutoka vyanzo vya nje hadi hifadhi ya muda (database ya muda).
- Hoja ya SQL kutoka kwa mtumiaji inatekelezwa katika hifadhi ya muda na matokeo yanarejeshwa kwa mtumiaji.
- Hifadhi ya muda inafutwa na rasilimali hutolewa.
Katika usanifu huu, tunalipa tu mchakato wa kutekeleza ombi. Hakuna maombi - hakuna gharama.
Hii ni mbinu ya kufanya kazi na inatekelezwa si tu katika Athena Serverless, lakini pia katika Redshift Spectrum (katika AWS).
Mfano wa Athena unaonyesha kuwa hifadhidata isiyo na seva hufanya kazi kwenye maswali halisi na makumi na mamia ya Terabytes ya data. Mamia ya Terabytes itahitaji mamia ya seva, lakini sio lazima kuzilipia - tunalipia maombi. Kasi ya kila ombi ni (chache) sana ikilinganishwa na hifadhidata maalum za uchanganuzi kama vile Vertica, lakini hatulipii muda wa kupumzika.
Hifadhidata kama hiyo inatumika kwa maswali adimu ya uchanganuzi ya matangazo. Kwa mfano, tunapoamua kwa hiari kujaribu nadharia juu ya kiasi kikubwa cha data. Athena ni kamili kwa kesi hizi. Kwa maombi ya kawaida, mfumo kama huo ni ghali. Katika kesi hii, kache data katika suluhisho maalum.
Haina seva kwa suluhisho za OLTP
Mfano uliopita uliangalia kazi za OLAP (uchambuzi). Sasa hebu tuangalie kazi za OLTP.
Wacha tufikirie PostgreSQL au MySQL inayoweza kusambazwa. Wacha tuinue mfano unaodhibitiwa wa kawaida wa PostgreSQL au MySQL na rasilimali ndogo. Wakati mfano unapokea mzigo zaidi, tutaunganisha nakala za ziada ambazo tutasambaza sehemu ya mzigo wa kusoma. Ikiwa hakuna maombi au mzigo, tunazima nakala. Mfano wa kwanza ni bwana, na wengine ni nakala.
Wazo hili linatekelezwa katika hifadhidata inayoitwa Aurora Serverless AWS. Kanuni ni rahisi: maombi kutoka kwa programu za nje yanakubaliwa na meli ya wakala. Kuona ongezeko la mzigo, inagawa rasilimali za kompyuta kutoka kwa hali ndogo za joto - unganisho hufanywa haraka iwezekanavyo. Matukio ya kulemaza hufanyika kwa njia ile ile.
Ndani ya Aurora kuna dhana ya Aurora Capacity Unit, ACU. Huu ni (masharti) mfano (seva). Kila ACU maalum inaweza kuwa bwana au mtumwa. Kila Kitengo cha Uwezo kina RAM yake, processor na diski ndogo. Ipasavyo, mmoja ni bwana, wengine wanasomwa nakala tu.
Idadi ya Vitengo hivi vya Uwezo wa Aurora vinavyoendesha ni kigezo kinachoweza kusanidiwa. Kiasi cha chini kinaweza kuwa moja au sifuri (katika kesi hii, hifadhidata haifanyi kazi ikiwa hakuna maombi).
Msingi unapopokea maombi, kundi la wakala huongeza Aurora CapacityUnits, na kuongeza rasilimali za utendaji wa mfumo. Uwezo wa kuongeza na kupunguza rasilimali huruhusu mfumo "kuchanganya" rasilimali: kuonyesha kiotomatiki ACU za kibinafsi (kuzibadilisha na mpya) na kusambaza sasisho zote za sasa kwa rasilimali zilizoondolewa.
Msingi wa Aurora Serverless unaweza kuongeza mzigo wa kusoma. Lakini nyaraka hazisemi hili moja kwa moja. Inaweza kuhisi kama wanaweza kuinua bwana wengi. Hakuna uchawi.
Database hii inafaa ili kuepuka kutumia kiasi kikubwa cha fedha kwenye mifumo yenye ufikiaji usiotabirika. Kwa mfano, wakati wa kuunda MVP au tovuti za kadi ya biashara ya uuzaji, kwa kawaida hatutarajii mzigo thabiti. Ipasavyo, ikiwa hakuna ufikiaji, hatulipii matukio. Wakati mzigo usiyotarajiwa hutokea, kwa mfano baada ya mkutano au kampeni ya matangazo, umati wa watu hutembelea tovuti na mzigo huongezeka kwa kasi, Aurora Serverless inachukua mzigo huu moja kwa moja na kuunganisha haraka rasilimali zinazokosekana (ACU). Kisha mkutano unapita, kila mtu anasahau kuhusu mfano, seva (ACU) huwa giza, na gharama hupungua hadi sifuri - rahisi.
Suluhisho hili halifai kwa upakiaji thabiti kwa sababu hauongezei mzigo wa uandishi. Viunganisho hivi vyote na kukatwa kwa rasilimali hufanyika katika kile kinachojulikana kama "kiwango cha kiwango" - wakati ambapo hifadhidata haihimiliwi na shughuli au meza za muda. Kwa mfano, ndani ya wiki hatua ya kiwango inaweza kutokea, na msingi hufanya kazi kwenye rasilimali sawa na hauwezi kupanua au mkataba.
Hakuna uchawi - ni PostgreSQL ya kawaida. Lakini mchakato wa kuongeza mashine na kuziondoa ni otomatiki kwa sehemu.
Bila seva kwa muundo
Aurora Serverless ni hifadhidata ya zamani iliyoandikwa upya kwa ajili ya wingu ili kunufaika na baadhi ya manufaa ya Serverless. Na sasa nitakuambia juu ya msingi, ambayo hapo awali iliandikwa kwa wingu, kwa mbinu isiyo na seva - isiyo na seva-kubuni. Iliendelezwa mara moja bila kudhani kuwa itaendesha kwenye seva za kimwili.
Msingi huu unaitwa Snowflake. Ina vitalu vitatu muhimu.
Ya kwanza ni kizuizi cha metadata. Hii ni huduma ya kumbukumbu ya haraka ambayo hutatua masuala na usalama, metadata, miamala na uboreshaji wa hoja (unaoonyeshwa kwenye kielelezo kilicho upande wa kushoto).
Kizuizi cha pili ni seti ya vikundi vya kompyuta vya kawaida kwa mahesabu (katika kielelezo kuna seti ya miduara ya bluu).
Kizuizi cha tatu ni mfumo wa kuhifadhi data kulingana na S3. S3 ni hifadhi ya kitu isiyo na kipimo katika AWS, aina kama Dropbox isiyo na kipimo kwa biashara.
Wacha tuone jinsi Snowflake inavyofanya kazi, tukichukulia mwanzo baridi. Hiyo ni, kuna hifadhidata, data imejaa ndani yake, hakuna maswali yanayoendesha. Ipasavyo, ikiwa hakuna maombi kwenye hifadhidata, basi tumeinua huduma ya haraka ya Metadata ya kumbukumbu (kizuizi cha kwanza). Na tuna hifadhi ya S3, ambapo data ya meza huhifadhiwa, imegawanywa katika kinachojulikana kama micropartitions. Kwa unyenyekevu: ikiwa meza ina shughuli, basi micropartitions ni siku za shughuli. Kila siku ni micropartition tofauti, faili tofauti. Na wakati hifadhidata inafanya kazi katika hali hii, unalipa tu nafasi iliyochukuliwa na data. Aidha, kiwango cha kiti ni cha chini sana (hasa kwa kuzingatia ukandamizaji mkubwa). Huduma ya metadata pia inafanya kazi kila mara, lakini huhitaji rasilimali nyingi ili kuboresha maswali, na huduma inaweza kuchukuliwa kuwa shareware.
Sasa hebu tufikirie kwamba mtumiaji alikuja kwenye hifadhidata yetu na kutuma swali la SQL. Hoja ya SQL hutumwa mara moja kwa huduma ya Metadata ili kuchakatwa. Ipasavyo, baada ya kupokea ombi, huduma hii inachambua ombi, data inayopatikana, ruhusa za watumiaji na, ikiwa kila kitu kiko sawa, huchora mpango wa kushughulikia ombi.
Ifuatayo, huduma huanzisha uzinduzi wa nguzo ya kompyuta. Kundi la kompyuta ni kundi la seva zinazofanya hesabu. Hiyo ni, hii ni nguzo ambayo inaweza kuwa na seva 1, seva 2, 4, 8, 16, 32 - nyingi unavyotaka. Unatuma ombi na uzinduzi wa nguzo hii huanza mara moja. Inachukua sekunde.
Ifuatayo, baada ya nguzo kuanza, sehemu ndogo zinazohitajika kuchakata ombi lako huanza kunakiliwa kwenye kikundi kutoka S3. Hiyo ni, hebu fikiria kwamba kutekeleza swala la SQL unahitaji sehemu mbili kutoka kwa meza moja na moja kutoka kwa pili. Katika kesi hii, sehemu tatu tu muhimu zitanakiliwa kwa nguzo, na sio meza zote kabisa. Ndio sababu, na haswa kwa sababu kila kitu kiko ndani ya kituo kimoja cha data na kuunganishwa na chaneli za haraka sana, mchakato mzima wa uhamishaji hufanyika haraka sana: kwa sekunde, mara chache sana kwa dakika, isipokuwa tunazungumza juu ya maombi ya kutisha. Ipasavyo, sehemu ndogo ndogo zinanakiliwa kwa nguzo ya kompyuta, na, baada ya kukamilika, hoja ya SQL inatekelezwa kwenye nguzo hii ya kompyuta. Matokeo ya ombi hili inaweza kuwa mstari mmoja, mistari kadhaa au meza - hutumwa nje kwa mtumiaji ili aweze kuipakua, kuionyesha kwenye chombo chake cha BI, au kuitumia kwa njia nyingine.
Kila hoja ya SQL haiwezi tu kusoma mijumuisho kutoka kwa data iliyopakiwa awali, lakini pia kupakia/kutoa data mpya katika hifadhidata. Hiyo ni, inaweza kuwa swala ambalo, kwa mfano, huingiza rekodi mpya kwenye meza nyingine, ambayo inaongoza kwa kuonekana kwa sehemu mpya kwenye nguzo ya kompyuta, ambayo, kwa upande wake, inahifadhiwa moja kwa moja katika hifadhi moja ya S3.
Hali iliyoelezwa hapo juu, kuanzia kuwasili kwa mtumiaji hadi upandishaji wa nguzo, kupakia data, kutekeleza hoja, kupata matokeo, hulipwa kwa kiwango cha dakika za kutumia nguzo ya kompyuta iliyoinuliwa, ghala pepe. Kiwango kinatofautiana kulingana na eneo la AWS na ukubwa wa nguzo, lakini kwa wastani ni dola chache kwa saa. Kundi la mashine nne ni ghali mara mbili ya kundi la mashine mbili, na nguzo ya mashine nane bado ni ghali mara mbili. Chaguzi za 16, mashine 32 zinapatikana, kulingana na ugumu wa maombi. Lakini unalipa tu kwa dakika hizo wakati nguzo inaendesha, kwa sababu wakati hakuna maombi, unaondoa mikono yako, na baada ya dakika 5-10 ya kusubiri (parameter inayoweza kusanidi) itatoka yenyewe, weka huru rasilimali na uwe huru.
Hali ya kweli kabisa ni wakati unatuma ombi, nguzo hujitokeza, kwa kusema, kwa dakika, inahesabu dakika nyingine, kisha dakika tano kuzima, na unaishia kulipa kwa dakika saba za uendeshaji wa nguzo hii, na sio kwa miezi na miaka.
Hali ya kwanza iliyoelezewa kwa kutumia Snowflake katika mpangilio wa mtumiaji mmoja. Sasa hebu fikiria kwamba kuna watumiaji wengi, ambayo ni karibu na hali halisi.
Wacha tuseme tuna wachambuzi wengi na ripoti za Jedwali ambazo hushambulia hifadhidata yetu mara kwa mara na idadi kubwa ya maswali rahisi ya uchanganuzi ya SQL.
Kwa kuongeza, tuseme kwamba tuna Wanasayansi wa Data wavumbuzi ambao wanajaribu kufanya mambo ya kutisha na data, kufanya kazi na makumi ya Terabytes, kuchambua mabilioni na matrilioni ya safu za data.
Kwa aina mbili za mzigo wa kazi ulioelezwa hapo juu, Snowflake inakuwezesha kuongeza makundi kadhaa ya kujitegemea ya kompyuta ya uwezo tofauti. Zaidi ya hayo, makundi haya ya kompyuta hufanya kazi kwa kujitegemea, lakini kwa data thabiti ya kawaida.
Kwa idadi kubwa ya maswali nyepesi, unaweza kuongeza vikundi vidogo 2-3, takriban mashine 2 kila moja. Tabia hii inaweza kutekelezwa, kati ya mambo mengine, kwa kutumia mipangilio ya moja kwa moja. Kwa hivyo unasema, βKitambaa cha theluji, inua kikundi kidogo. Ikiwa mzigo juu yake unaongezeka juu ya parameter fulani, ongeza pili sawa, ya tatu. Wakati mzigo unapoanza kupungua, zima ziada. Ili hata waje wachambuzi wangapi waanze kuangalia ripoti, kila mtu ana rasilimali za kutosha.
Wakati huo huo, ikiwa wachambuzi wamelala na hakuna mtu anayeangalia ripoti, makundi yanaweza kuwa giza kabisa, na unaacha kuwalipa.
Wakati huo huo, kwa maswali mazito (kutoka kwa Wanasayansi wa Takwimu), unaweza kuongeza nguzo moja kubwa sana kwa mashine 32. Kundi hili pia litalipwa kwa dakika na saa hizo pekee wakati ombi lako kuu linatekelezwa hapo.
Fursa iliyoelezwa hapo juu inakuwezesha kugawanya sio 2 tu, lakini pia aina zaidi za mzigo wa kazi katika makundi (ETL, ufuatiliaji, uboreshaji wa ripoti, ...).
Hebu tufanye muhtasari wa Snowflake. Msingi unachanganya wazo zuri na utekelezaji unaowezekana. Katika ManyChat, tunatumia Snowflake kuchanganua data yote tuliyo nayo. Hatuna makundi matatu, kama katika mfano, lakini kutoka 5 hadi 9, ya ukubwa tofauti. Tuna mashine 16 za kawaida, 2-mashine, na pia mashine ndogo sana 1 kwa kazi zingine. Wanafanikiwa kusambaza mzigo na kuruhusu sisi kuokoa mengi.
Hifadhidata inafanikiwa kupima mzigo wa kusoma na kuandika. Hii ni tofauti kubwa na mafanikio makubwa ikilinganishwa na "Aurora" sawa, ambayo ilibeba mzigo wa kusoma tu. Snowflake hukuruhusu kuongeza mzigo wako wa kazi ya uandishi na vikundi hivi vya kompyuta. Hiyo ni, kama nilivyosema, tunatumia nguzo kadhaa katika ManyChat, nguzo ndogo na ndogo sana hutumiwa sana kwa ETL, kwa kupakia data. Na wachambuzi tayari wanaishi kwenye nguzo za kati, ambazo haziathiriwa kabisa na mzigo wa ETL, hivyo hufanya kazi haraka sana.
Ipasavyo, hifadhidata inafaa kwa kazi za OLAP. Hata hivyo, kwa bahati mbaya, bado haijatumika kwa mzigo wa kazi wa OLTP. Kwanza, hifadhidata hii ni safu, na matokeo yote yanayofuata. Pili, mbinu yenyewe, wakati kwa kila ombi, ikiwa ni lazima, unainua nguzo ya kompyuta na kuijaza na data, kwa bahati mbaya, bado haiko haraka vya kutosha kwa mizigo ya OLTP. Sekunde za kungoja kwa kazi za OLAP ni kawaida, lakini kwa kazi za OLTP haikubaliki; ms 100 itakuwa bora zaidi, au ms 10 itakuwa bora zaidi.
Jumla ya
Hifadhidata isiyo na seva inawezekana kwa kugawa hifadhidata katika sehemu zisizo na Uraia na za Kitaifa. Huenda umegundua kuwa katika mifano yote iliyo hapo juu, sehemu ya Stateful, kwa kiasi, ni kuhifadhi sehemu ndogo ndogo katika S3, na Stateless ni kiboreshaji, kinachofanya kazi na metadata, kushughulikia masuala ya usalama ambayo yanaweza kutolewa kama huduma huru nyepesi zisizo na uraia.
Utekelezaji wa hoja za SQL pia unaweza kutambuliwa kama huduma za hali nyepesi ambazo zinaweza kujitokeza katika hali isiyo na seva, kama vile vikundi vya kompyuta vya Snowflake, kupakua data muhimu pekee, kutekeleza hoja na "kwenda nje."
Hifadhidata za kiwango cha uzalishaji kisicho na seva tayari zinapatikana kwa matumizi, zinafanya kazi. Hifadhidata hizi zisizo na seva tayari ziko tayari kushughulikia kazi za OLAP. Kwa bahati mbaya, kwa kazi za OLTP hutumiwa ... na nuances, kwa kuwa kuna mapungufu. Kwa upande mmoja, hii ni minus. Lakini, kwa upande mwingine, hii ni fursa. Labda mmoja wa wasomaji atapata njia ya kufanya hifadhidata ya OLTP bila seva kabisa, bila mapungufu ya Aurora.
Natumaini umepata kuvutia. Serverless ni siku zijazo :)
Chanzo: mapenzi.com