DBA bot Joe. Anatoly Stansler (Postgres.ai)

Je, msanidi programu wa backend anaelewaje kuwa swala la SQL litafanya kazi vizuri kwenye "prod"? Katika makampuni makubwa au yanayokua kwa kasi, si kila mtu anapata "bidhaa". Na kwa ufikiaji, sio maombi yote yanaweza kukaguliwa bila maumivu, na kuunda nakala ya hifadhidata mara nyingi huchukua masaa. Ili kutatua matatizo haya, tuliunda DBA ya bandia - Joe. Tayari imetekelezwa kwa ufanisi katika makampuni kadhaa na husaidia watengenezaji zaidi ya dazeni.

Video:

Salaam wote! Jina langu ni Anatoly Stansler. Ninafanya kazi katika kampuni postgres.ai. Tumejitolea kuharakisha mchakato wa maendeleo kwa kuondoa ucheleweshaji unaohusishwa na kazi ya Postgres kutoka kwa wasanidi programu, DBA na QAs.

Tuna wateja wazuri na leo sehemu ya ripoti itatolewa kwa kesi ambazo tulikutana nazo tukifanya kazi nao. Nitazungumza juu ya jinsi tulivyowasaidia kutatua shida kubwa.

Tunapoendeleza na kufanya uhamiaji mgumu wa mzigo mkubwa, tunajiuliza swali: "Je, uhamiaji huu utaondoka?". Tunatumia ukaguzi, tunatumia ujuzi wa wenzetu wenye ujuzi zaidi, wataalam wa DBA. Na wanaweza kusema kama itaruka au la.

Lakini labda itakuwa bora ikiwa tunaweza kuijaribu wenyewe kwenye nakala za ukubwa kamili. Na leo tutazungumza tu juu ya njia gani za kupima sasa na jinsi zinaweza kufanywa vizuri na kwa zana gani. Tutazungumza pia juu ya faida na hasara za njia kama hizo, na nini tunaweza kurekebisha hapa.

Nani amewahi kufanya faharasa moja kwa moja kwenye prod au kufanya mabadiliko yoyote? Kidogo kabisa. Na kwa nani hii ilisababisha ukweli kwamba data ilipotea au kulikuwa na wakati wa kupumzika? Kisha unajua maumivu haya. Namshukuru Mungu kuna backups.

Njia ya kwanza ni kupima katika prod. Au, wakati msanidi anakaa kwenye mashine ya ndani, ana data ya majaribio, kuna aina fulani ya uteuzi mdogo. Na sisi unaendelea prod, na sisi kupata hali hii.

Inaumiza, ni ghali. Pengine ni bora si.

Na ni ipi njia bora ya kuifanya?

Wacha tuchukue hatua na tuchague sehemu fulani ya prod hapo. Au bora, hebu tuchukue prod halisi, data yote. Na baada ya kuikuza ndani ya nchi, tutaangalia kwa kuongeza uwekaji.

Hii itaturuhusu kuondoa baadhi ya makosa, yaani, kuyazuia yasiwe kwenye prod.

Je, ni matatizo gani?

• Shida ni kwamba tunashiriki maonyesho haya na wenzetu. Na mara nyingi sana hutokea kwamba unafanya aina fulani ya mabadiliko, bam - na hakuna data, kazi ni chini ya kukimbia. Staging ilikuwa multi-terabyte. Na itabidi ungojee kwa muda mrefu ili kuinuka tena. Na tunaamua kumaliza kesho. Ni hayo tu, tuna maendeleo.
• Na, kwa kweli, tuna wenzetu wengi wanaofanya kazi huko, timu nyingi. Na lazima ifanyike kwa mikono. Na hii ni usumbufu.

Na inafaa kusema kwamba tuna jaribio moja tu, risasi moja, ikiwa tunataka kufanya mabadiliko fulani kwenye hifadhidata, kugusa data, kubadilisha muundo. Na ikiwa kitu kilienda vibaya, ikiwa kulikuwa na hitilafu katika uhamiaji, basi hatutarudi nyuma haraka.

Hii ni bora zaidi kuliko mbinu ya awali, lakini bado kuna uwezekano mkubwa kwamba aina fulani ya hitilafu itaenda kwenye uzalishaji.

Ni nini hutuzuia kumpa kila msanidi benchi ya majaribio, nakala ya ukubwa kamili? Nadhani ni wazi nini kinaingia njiani.

Nani ana hifadhidata kubwa kuliko terabyte? Zaidi ya nusu ya chumba.

Na ni wazi kwamba kuweka mashine kwa kila msanidi, wakati kuna uzalishaji mkubwa kama huo, ni ghali sana, na badala yake, inachukua muda mrefu.

Tuna wateja ambao wamegundua kuwa ni muhimu sana kujaribu mabadiliko yote kwenye nakala za ukubwa kamili, lakini hifadhidata yao ni chini ya terabyte, na hakuna nyenzo za kuweka benchi ya majaribio kwa kila msanidi. Kwa hivyo, wanapaswa kupakua utupaji wa ndani kwa mashine yao na kujaribu kwa njia hii. Inachukua muda mwingi.

Hata ukiifanya ndani ya miundombinu, basi kupakua terabyte moja ya data kwa saa tayari ni nzuri sana. Lakini hutumia utupaji wa kimantiki, hupakua ndani kutoka kwa wingu. Kwao, kasi ni kuhusu gigabytes 200 kwa saa. Na bado inachukua muda kugeuka kutoka kwa dampo la kimantiki, kukunja faharisi, nk.

Lakini wanatumia njia hii kwa sababu inawaruhusu kuweka prod kuaminika.

Tunaweza kufanya nini hapa? Wacha tufanye madawati ya majaribio kuwa nafuu na tumpe kila msanidi programu benchi lake la majaribio.

Na hili linawezekana.

Na kwa njia hii, tunapofanya clones nyembamba kwa kila mtengenezaji, tunaweza kushiriki kwenye mashine moja. Kwa mfano, ikiwa una hifadhidata ya 10TB na unataka kuwapa wasanidi programu 10, huhitaji kuwa na hifadhidata XNUMX x XNUMXTB. Unahitaji mashine moja tu kutengeneza nakala nyembamba zilizotengwa kwa kila msanidi kwa kutumia mashine moja. Nitakuambia jinsi inavyofanya kazi baadaye kidogo.

Mfano halisi:

• DB - 4,5 terabytes.

• Tunaweza kupata nakala za kujitegemea katika sekunde 30.

Huna haja ya kusubiri kusimama kwa mtihani na kutegemea ni kubwa kiasi gani. Unaweza kuipata kwa sekunde. Itakuwa mazingira ya pekee kabisa, lakini ambayo yanashiriki data kati yao wenyewe.

Hii ni kubwa. Hapa tunazungumza juu ya uchawi na ulimwengu unaofanana.

Kwa upande wetu, hii inafanya kazi kwa kutumia mfumo wa OpenZFS.

OpenZFS ni mfumo wa faili wa kunakili-kwa-kuandika ambao unaauni vijipicha na clones nje ya boksi. Inaaminika na inaweza kuenea. Yeye ni rahisi sana kusimamia. Inaweza kutumwa katika timu mbili.

Kuna chaguzi zingine:

• lvm,

• Hifadhi (kwa mfano, Hifadhi safi).

Maabara ya Hifadhidata ninayozungumza ni ya kawaida. Inaweza kutekelezwa kwa kutumia chaguzi hizi. Lakini kwa sasa, tumezingatia OpenZFS, kwa sababu kulikuwa na shida na LVM haswa.

Inavyofanya kazi? Badala ya kuandika upya data kila tunapoibadilisha, tunaihifadhi kwa kuashiria tu kwamba data hii mpya imetoka kwa wakati mpya, picha mpya.

Na katika siku zijazo, tunapotaka kurudisha nyuma au tunataka kutengeneza nakala mpya kutoka kwa toleo la zamani, tunasema tu: "Sawa, tupe vizuizi hivi vya data ambavyo vimetiwa alama hivi."

Na mtumiaji huyu atafanya kazi na seti kama hiyo ya data. Atawabadilisha hatua kwa hatua, atengeneze snapshots zake mwenyewe.

Na tutatawi. Kila msanidi kwa upande wetu atapata fursa ya kuwa na kampuni yake mwenyewe ambayo atahariri, na data inayoshirikiwa itashirikiwa kati ya kila mtu.

Ili kupeleka mfumo kama huo nyumbani, unahitaji kutatua shida mbili:

• Ya kwanza ni chanzo cha data, ambapo utachukua kutoka. Unaweza kusanidi urudiaji na toleo la umma. Tayari unaweza kutumia chelezo ambazo umesanidi, natumai. WAL-E, WAL-G au Barman. Na hata ikiwa unatumia aina fulani ya suluhisho la Wingu kama RDS au Cloud SQL, basi unaweza kutumia utupaji wa kimantiki. Lakini bado tunakushauri kutumia nakala rudufu, kwa sababu kwa njia hii pia utahifadhi muundo wa faili wa faili, ambayo itakuruhusu kuwa karibu zaidi na metriki ambazo ungeona katika uzalishaji ili kupata shida hizo zilizopo.

• Ya pili ni pale unapotaka kukaribisha Maabara ya Hifadhidata. Inaweza kuwa Cloud, inaweza kuwa On-Nguzo. Ni muhimu kusema hapa kwamba ZFS inasaidia ukandamizaji wa data. Na inafanya vizuri kabisa.

Fikiria kwamba kwa kila clone kama hiyo, kulingana na shughuli ambazo tunafanya na msingi, aina fulani ya dev itakua. Kwa hili, dev pia itahitaji nafasi. Lakini kutokana na ukweli kwamba tulichukua msingi wa 4,5 terabytes, ZFS itaipunguza kwa terabytes 3,5. Hii inaweza kutofautiana kulingana na mipangilio. Na bado tuna nafasi kwa dev.

Mfumo kama huo unaweza kutumika kwa kesi tofauti.

• Hawa ni wasanidi programu, DBA za uthibitishaji wa hoja, kwa ajili ya uboreshaji.

• Hii inaweza kutumika katika majaribio ya QA ili kujaribu uhamishaji fulani kabla hatujaitoa kwenye uzalishaji. Na tunaweza pia kuinua mazingira maalum ya QA na data halisi, ambapo wanaweza kujaribu utendakazi mpya. Na itachukua sekunde badala ya masaa ya kusubiri, na labda siku katika baadhi ya matukio mengine ambapo nakala nyembamba hazitumiwi.

• Na kesi nyingine. Ikiwa kampuni haina mfumo wa uchanganuzi ulioanzishwa, basi tunaweza kutenga mwamba mwembamba wa msingi wa bidhaa na kuwapa maswali marefu au faharasa maalum ambazo zinaweza kutumika katika uchanganuzi.

Kwa mbinu hii:

1. Uwezekano mdogo wa makosa kwenye "prod", kwa sababu tulijaribu mabadiliko yote kwenye data ya ukubwa kamili.

2. Tuna utamaduni wa kupima, kwa sababu sasa si lazima kusubiri kwa saa kwa ajili ya kusimama yako mwenyewe.

3. Na hakuna kizuizi, hakuna kusubiri kati ya vipimo. Kwa kweli unaweza kwenda na kuangalia. Na itakuwa bora kwa njia hii tunapoharakisha maendeleo.

• Kutakuwa na urekebishaji mdogo. Hitilafu chache zitaishia katika uzalishaji. Tutazirekebisha kidogo baadaye.

• Tunaweza kubadilisha mabadiliko yasiyoweza kutenduliwa. Hii sio njia ya kawaida.

1. Hii ni ya manufaa kwa sababu tunashiriki rasilimali za madawati ya majaribio.

Tayari ni nzuri, lakini ni nini kingine kinachoweza kuharakishwa?

Shukrani kwa mfumo huo, tunaweza kupunguza sana kizingiti cha kuingia kwenye upimaji huo.

Sasa kuna mduara mbaya ambapo msanidi lazima awe mtaalamu ili kupata ufikiaji wa data halisi ya ukubwa kamili. Lazima aaminiwe na ufikiaji huo.

Lakini jinsi ya kukua ikiwa haipo. Lakini vipi ikiwa unayo seti ndogo tu ya data ya majaribio inayopatikana kwako? Kisha hautapata uzoefu wowote wa kweli.

Jinsi ya kutoka nje ya mduara huu? Kama kiolesura cha kwanza, kinachofaa kwa wasanidi programu wa kiwango chochote, tulichagua Slack bot. Lakini inaweza kuwa interface nyingine yoyote.

Je, inakuruhusu kufanya nini? Unaweza kuchukua hoja maalum na kuituma kwa kituo maalum cha hifadhidata. Tutatuma kiotomatiki kisanii chembamba kwa sekunde. Hebu tuendeshe ombi hili. Tunakusanya vipimo na mapendekezo. Wacha tuonyeshe taswira. Na kisha clone hii itabaki ili swala hili liweze kuboreshwa kwa namna fulani, ongeza faharisi, nk.

Na pia Slack hutupatia fursa za kushirikiana nje ya boksi. Kwa kuwa hii ni chaneli tu, unaweza kuanza kujadili ombi hili hapo hapo kwenye uzi wa ombi kama hilo, ping wenzako, DBA walio ndani ya kampuni.

Lakini kuna, bila shaka, matatizo. Kwa sababu huu ndio ulimwengu wa kweli, na tunatumia seva inayokaribisha clones nyingi kwa wakati mmoja, inatubidi kubana kiasi cha kumbukumbu na nguvu ya CPU inayopatikana kwa clones.

Lakini ili vipimo hivi viweze kukubalika, unahitaji kwa namna fulani kutatua tatizo hili.

Ni wazi kwamba hatua muhimu ni data sawa. Lakini tayari tunayo. Na tunataka kufikia usanidi sawa. Na tunaweza kutoa usanidi wa karibu sawa.

Itakuwa nzuri kuwa na vifaa sawa na katika uzalishaji, lakini inaweza kutofautiana.

Hebu tukumbuke jinsi Postgres inavyofanya kazi na kumbukumbu. Tuna cache mbili. Moja kutoka kwa mfumo wa faili na Postgres moja asili, yaani, Akiba ya Buffer Iliyoshirikiwa.

Ni muhimu kutambua kwamba Akiba ya Buffer ya Pamoja imetengwa wakati Postgres inapoanza, kulingana na ukubwa gani unaobainisha katika usanidi.

Na kashe ya pili hutumia nafasi zote zinazopatikana.

Na tunapofanya clones kadhaa kwenye mashine moja, zinageuka kuwa hatua kwa hatua tunajaza kumbukumbu. Na kwa njia nzuri, Akiba ya Buffer ya Pamoja ni 25% ya jumla ya kumbukumbu inayopatikana kwenye mashine.

Na inageuka kwamba ikiwa hatubadilisha parameter hii, basi tutaweza kuendesha matukio 4 tu kwenye mashine moja, yaani, 4 ya clones hizi nyembamba kwa jumla. Na hii, kwa kweli, ni mbaya, kwa sababu tunataka kuwa na mengi zaidi yao.

Lakini kwa upande mwingine, Cache ya Buffer inatumika kutekeleza maswali kwa faharisi, ambayo ni, mpango unategemea jinsi kache zetu ni kubwa. Na ikiwa tunachukua tu parameter hii na kuipunguza, basi mipango yetu inaweza kubadilika sana.

Kwa mfano, ikiwa tuna kache kubwa kwenye prod, basi Postgres itapendelea kutumia faharasa. Na ikiwa sivyo, basi kutakuwa na SeqScan. Na nini kingefaa ikiwa mipango yetu haikupatana?

Lakini hapa tunafikia hitimisho kwamba kwa kweli mpango katika Postgres hautegemei saizi maalum iliyoainishwa kwenye Kihifadhi Pamoja katika mpango, inategemea ufanisi_kache_size.

Effective_cache_size ni makadirio ya kiasi cha akiba ambacho kinapatikana kwetu, yaani, jumla ya Akiba ya Buffer na akiba ya mfumo wa faili. Hii imewekwa na usanidi. Na kumbukumbu hii haijatengwa.

Na kwa sababu ya kigezo hiki, tunaweza kudanganya Postgres, tukisema kwamba kwa kweli tuna data nyingi zinazopatikana, hata kama hatuna data hii. Na hivyo, mipango itaendana kabisa na uzalishaji.

Lakini hii inaweza kuathiri wakati. Na tunaboresha maswali kwa kuweka muda, lakini ni muhimu kwamba muda unategemea mambo mengi:

• Inategemea mzigo ulio kwenye prod kwa sasa.

• Inategemea sifa za mashine yenyewe.

Na hii ni parameta isiyo ya moja kwa moja, lakini kwa kweli tunaweza kuboresha haswa kwa idadi ya data ambayo swali hili litasoma ili kupata matokeo.

Na ikiwa unataka wakati kuwa karibu na kile tutachoona katika prod, basi tunahitaji kuchukua vifaa vinavyofanana zaidi na, ikiwezekana, hata zaidi ili clones zote zifanane. Lakini hii ni maelewano, i.e. utapata mipango sawa, utaona ni data ngapi swala fulani itasoma na utaweza kuhitimisha ikiwa swali hili ni nzuri (au uhamiaji) au mbaya, bado linahitaji kuboreshwa. .

Wacha tuangalie jinsi Joe ameboreshwa haswa.

Wacha tuchukue ombi kutoka kwa mfumo halisi. Katika kesi hii, hifadhidata ni 1 terabyte. Na tunataka kuhesabu idadi ya machapisho mapya ambayo yalikuwa na kupendwa zaidi ya 10.

Tunaandika ujumbe kwa kituo, nakala imetumwa kwa ajili yetu. Na tutaona kwamba ombi kama hilo litakamilika kwa dakika 2,5. Hili ndilo jambo la kwanza tunaloona.

B Joe atakuonyesha mapendekezo ya kiotomatiki kulingana na mpango na vipimo.

Tutaona kuwa hoja huchakata data nyingi sana ili kupata idadi ndogo ya safu mlalo. Na aina fulani ya faharisi maalum inahitajika, kwani tuligundua kuwa kuna safu mlalo nyingi sana zilizochujwa katika hoja.

Hebu tuchunguze kwa undani zaidi kilichotokea. Hakika, tunaona kwamba tumesoma karibu gigabytes moja na nusu ya data kutoka kwa cache ya faili au hata kutoka kwa diski. Na hii sio nzuri, kwa sababu tulipata mistari 142 tu.

Na, inaweza kuonekana, tunayo skanning ya faharasa hapa na tungefanya kazi haraka, lakini kwa kuwa tulichuja mistari mingi sana (tulilazimika kuihesabu), hoja ilifanya kazi polepole.

Na hii ilitokea katika mpango kutokana na ukweli kwamba masharti katika swala na masharti katika index sehemu hailingani.

Wacha tujaribu kufanya faharisi kuwa sahihi zaidi na tuone jinsi utekelezaji wa hoja unabadilika baada ya hapo.

Uundaji wa index ulichukua muda mrefu sana, lakini sasa tunaangalia swala na kuona kwamba wakati badala ya dakika 2,5 ni milliseconds 156 tu, ambayo ni nzuri ya kutosha. Na tunasoma megabytes 6 tu za data.

Na sasa tunatumia index tu scan.

Hadithi nyingine muhimu ni kwamba tunataka kuwasilisha mpango kwa njia inayoeleweka zaidi. Tumetekeleza taswira kwa kutumia Grafu za Moto.

Hili ni ombi tofauti, kali zaidi. Na tunaunda Grafu za Moto kulingana na vigezo viwili: hii ni kiasi cha data ambayo node fulani ilihesabu katika mpango na muda, yaani wakati wa utekelezaji wa node.

Hapa tunaweza kulinganisha nodi maalum na kila mmoja. Na itakuwa wazi ni nani kati yao anayechukua zaidi au chini, ambayo kwa kawaida ni vigumu kufanya katika njia nyingine za utoaji.

Bila shaka, kila mtu anajua explain.depesz.com. Kipengele kizuri cha taswira hii ni kwamba tunahifadhi mpango wa maandishi na pia kuweka vigezo vya msingi kwenye jedwali ili tuweze kupanga.

Na wasanidi programu ambao bado hawajaingia kwenye mada hii pia hutumia explain.depesz.com, kwa sababu ni rahisi kwao kubaini ni vipimo vipi ni muhimu na ambavyo si muhimu.

Kuna mbinu mpya ya taswira - hii ni explain.dalibo.com. Wanafanya taswira ya mti, lakini ni ngumu sana kulinganisha nodi na kila mmoja. Hapa unaweza kuelewa muundo vizuri, hata hivyo, ikiwa kuna ombi kubwa, basi utahitaji kurudi na kurudi, lakini pia chaguo.

ushirikiano

Na, kama nilivyosema, Slack inatupa fursa ya kushirikiana. Kwa mfano, ikiwa tutakumbana na hoja tata ambayo haijulikani wazi jinsi ya kuboresha, tunaweza kufafanua suala hili na wenzetu katika mazungumzo katika Slack.

Inaonekana kwetu kuwa ni muhimu kujaribu kwenye data ya ukubwa kamili. Ili kufanya hivyo, tulifanya zana ya Maabara ya Hifadhidata ya Usasishaji, ambayo inapatikana katika chanzo wazi. Unaweza kutumia Joe bot pia. Unaweza kuichukua sasa hivi na kuitekeleza ukiwa mahali pako. Miongozo yote inapatikana hapo.

Pia ni muhimu kutambua kwamba suluhisho yenyewe sio mapinduzi, kwa sababu kuna Delphix, lakini ni suluhisho la biashara. Imefungwa kabisa, ni ghali sana. Sisi hasa utaalam katika Postgres. Hizi zote ni bidhaa huria. Jiunge nasi!

Hapa ndipo ninapoishia. Asante!

maswali

Habari! Asante kwa ripoti! Inavutia sana, haswa kwangu, kwa sababu nilitatua shida kama hiyo wakati fulani uliopita. Na kwa hivyo nina maswali kadhaa. Natumai nitapata angalau sehemu yake.

Nashangaa jinsi unavyohesabu mahali pa mazingira haya? Teknolojia inamaanisha kuwa chini ya hali fulani, clones zako zinaweza kukua hadi ukubwa wa juu zaidi. Kwa kusema, ikiwa una hifadhidata ya terabyte kumi na clones 10, basi ni rahisi kuiga hali ambapo kila clone ina uzito wa data 10 ya kipekee. Je, unahesabuje mahali hapa, yaani, ile delta uliyozungumzia, ambayo clones hizi zitaishi?

Swali zuri. Ni muhimu kufuatilia clones maalum hapa. Na ikiwa clone ina mabadiliko makubwa sana, inaanza kukua, basi tunaweza kwanza kutoa onyo kwa mtumiaji kuhusu hili, au kuacha mara moja clone hii ili tusiwe na hali ya kushindwa.

Ndio, nina swali lililoulizwa. Hiyo ni, unahakikishaje mzunguko wa maisha wa moduli hizi? Tuna tatizo hili na hadithi tofauti kabisa. Je, hii hutokeaje?

Kuna ttl kwa kila clone. Kimsingi, tuna ttl fasta.

Nini, ikiwa sio siri?

Saa 1, i.e. bila kazi - saa 1. Ikiwa haijatumiwa, basi tunaipiga. Lakini hakuna mshangao hapa, kwani tunaweza kuongeza clone kwa sekunde. Na ikiwa unahitaji tena, basi tafadhali.

Pia ninavutiwa na uchaguzi wa teknolojia, kwa sababu, kwa mfano, tunatumia njia kadhaa kwa sambamba kwa sababu moja au nyingine. Kwa nini ZFS? Kwa nini hukutumia LVM? Ulisema kuwa kulikuwa na shida na LVM. Matatizo yalikuwa nini? Kwa maoni yangu, chaguo bora zaidi ni pamoja na uhifadhi, kwa suala la utendaji.

Tatizo kuu la ZFS ni nini? Ukweli kwamba lazima uendeshe kwa mwenyeji sawa, i.e. hali zote zitaishi ndani ya OS sawa. Na katika kesi ya kuhifadhi, unaweza kuunganisha vifaa tofauti. Na kizuizi ni vile tu vitalu vilivyo kwenye mfumo wa kuhifadhi. Na swali la uchaguzi wa teknolojia ni ya kuvutia. Kwa nini sio LVM?

Hasa, tunaweza kujadili LVM kwenye mkutano. Kuhusu kuhifadhi - ni ghali tu. Tunaweza kutekeleza mfumo wa ZFS popote pale. Unaweza kuiweka kwenye mashine yako. Unaweza kupakua tu hazina na kuipeleka. ZFS imewekwa karibu kila mahali ikiwa tunazungumza juu ya Linux. Hiyo ni, tunapata suluhisho rahisi sana. Na ZFS yenyewe inatoa mengi nje ya boksi. Unaweza kupakia data nyingi unavyopenda, kuunganisha idadi kubwa ya disks, kuna snapshots. Na, kama nilivyosema, ni rahisi kusimamia. Hiyo ni, inaonekana kupendeza sana kutumia. Anajaribiwa, ana miaka mingi. Ana jamii kubwa sana ambayo inakua. ZFS ni suluhisho la kuaminika sana.

Nikolai Samokhvalov: Je, naweza kutoa maoni zaidi? Jina langu ni Nikolay, tunafanya kazi pamoja na Anatoly. Ninakubali kuwa hifadhi ni nzuri. Na baadhi ya wateja wetu wana Hifadhi Safi nk.

Anatoly alibainisha kwa usahihi kuwa tunazingatia modularity. Na katika siku zijazo, unaweza kutekeleza interface moja - kuchukua snapshot, kufanya clone, kuharibu clone. Yote ni rahisi. Na uhifadhi ni baridi, ikiwa ni.

Lakini ZFS inapatikana kwa kila mtu. DelPhix tayari inatosha, wana wateja 300. Kati ya hizi, bahati 100 ina wateja 50, i.e. wanalenga NASA, nk. Ni wakati wa kila mtu kupata teknolojia hii. Na ndiyo sababu tunayo Msingi wa chanzo wazi. Tuna sehemu ya kiolesura ambayo si chanzo wazi. Hili ndilo jukwaa ambalo tutaonyesha. Lakini tunataka ipatikane na kila mtu. Tunataka kufanya mapinduzi ili watumiaji wote wanaojaribu waache kubahatisha kwenye kompyuta ndogo. Tunapaswa kuandika CHAGUA na mara moja tuone kuwa ni polepole. Acha kusubiri DBA ikuambie kuihusu. Hapa ndio lengo kuu. Na nadhani sote tutakuja kwa hili. Na tunafanya kitu hiki kwa kila mtu kuwa nacho. Kwa hiyo ZFS, kwa sababu itakuwa inapatikana kila mahali. Shukrani kwa jumuiya kwa kutatua matatizo na kwa kuwa na leseni huria, n.k.*

Salamu! Asante kwa ripoti! Jina langu ni Maxim. Tumeshughulika na masuala sawa. Waliamua wenyewe. Je, unashiriki vipi rasilimali kati ya clones hizi? Kila clone inaweza kufanya jambo lake wakati wowote: mtu anajaribu kitu kimoja, mwingine mwingine, mtu anajenga index, mtu ana kazi nzito. Na ikiwa bado unaweza kugawanya na CPU, basi kwa IO, unagawanyaje? Hili ni swali la kwanza.

Na swali la pili ni kuhusu kutofautiana kwa misimamo. Wacha tuseme nina ZFS hapa na kila kitu ni nzuri, lakini mteja kwenye prod hana ZFS, lakini ext4, kwa mfano. Jinsi gani katika kesi hii?

Maswali ni mazuri sana. Nilitaja tatizo hili kidogo na ukweli kwamba tunagawana rasilimali. Na suluhisho ni hili. Fikiria kuwa unajaribu kwenye jukwaa. Unaweza pia kuwa na hali hiyo wakati huo huo kwamba mtu anatoa mzigo mmoja, mtu mwingine. Na matokeo yake, unaona metrics isiyoeleweka. Hata shida sawa inaweza kuwa na prod. Unapotaka kuangalia ombi fulani na kuona kwamba kuna shida fulani nayo - inafanya kazi polepole, basi kwa kweli tatizo halikuwa katika ombi, lakini kwa ukweli kwamba kuna aina fulani ya mzigo sambamba.

Na kwa hiyo, ni muhimu hapa kuzingatia nini mpango utakuwa, ni hatua gani tutachukua katika mpango na ni kiasi gani cha data tutachoongeza kwa hili. Ukweli kwamba disks zetu, kwa mfano, zitapakiwa na kitu, itaathiri hasa wakati. Lakini tunaweza kukadiria jinsi ombi hili limepakiwa kwa kiasi cha data. Sio muhimu sana kwamba wakati huo huo kutakuwa na aina fulani ya utekelezaji.

Nina maswali mawili. Hii ni mambo poa sana. Je, kumekuwa na matukio ambapo data ya uzalishaji ni muhimu, kama vile nambari za kadi ya mkopo? Tayari kuna kitu tayari au ni kazi tofauti? Na swali la pili - kuna kitu kama hiki kwa MySQL?

Kuhusu data. Tutafanya obfuscation mpaka tufanye. Lakini ikiwa utapeleka Joe haswa, ikiwa hautoi ufikiaji kwa watengenezaji, basi hakuna ufikiaji wa data. Kwa nini? Kwa sababu Joe haonyeshi data. Inaonyesha tu vipimo, mipango na ndivyo hivyo. Hii ilifanyika kwa makusudi, kwa sababu hii ni moja ya mahitaji ya mteja wetu. Walitaka kuweza kuboresha bila kumpa kila mtu ufikiaji.

Kuhusu MySQL. Mfumo huu unaweza kutumika kwa kitu chochote ambacho huhifadhi hali kwenye diski. Na kwa kuwa tunafanya Postgres, sasa tunafanya otomatiki zote za Postgres kwanza. Tunataka kupata data kiotomatiki kutoka kwa nakala rudufu. Tunasanidi Postgres kwa usahihi. Tunajua jinsi ya kufanya mipango ifanane, nk.

Lakini kwa kuwa mfumo unaweza kupanuka, unaweza pia kutumika kwa MySQL. Na kuna mifano kama hiyo. Yandex ina kitu sawa, lakini haichapishi popote. Wanaitumia ndani ya Yandex.Metrica. Na kuna hadithi tu kuhusu MySQL. Lakini teknolojia ni sawa, ZFS.

Asante kwa ripoti! Pia nina maswali kadhaa. Ulisema kuwa uundaji wa cloning unaweza kutumika kwa uchanganuzi, kwa mfano kuunda faharisi za ziada hapo. Je, unaweza kueleza zaidi kuhusu jinsi inavyofanya kazi?

Na mara moja nitauliza swali la pili kuhusu kufanana kwa anasimama, kufanana kwa mipango. Mpango huo pia unategemea takwimu zilizokusanywa na Postgres. Je, unatatuaje tatizo hili?

Kwa mujibu wa uchambuzi, hakuna kesi maalum, kwa sababu hatujatumia bado, lakini kuna fursa hiyo. Ikiwa tunazungumza juu ya faharasa, basi fikiria kuwa swali linafuata jedwali lenye mamia ya mamilioni ya rekodi na safu ambayo kwa kawaida haijaorodheshwa katika prod. Na tunataka kuhesabu data fulani huko. Ikiwa ombi hili linatumwa kwa prod, basi kuna uwezekano kwamba itakuwa rahisi kwenye prod, kwa sababu ombi litashughulikiwa huko kwa dakika.

Sawa, wacha tutengeneze clone nyembamba ambayo sio mbaya kuacha kwa dakika chache. Na ili kuifanya iwe rahisi kusoma uchanganuzi, tutaongeza fahirisi za safu wima ambazo tunavutiwa na data.

Faharasa itaundwa kila wakati?

Unaweza kuifanya ili tuguse data, tufanye snapshots, kisha tutapona kutoka kwa snapshot hii na kuendesha maombi mapya. Hiyo ni, unaweza kuifanya ili uweze kuongeza clones mpya na fahirisi zilizowekwa tayari.

Kuhusu swali la takwimu, ikiwa tutarejesha kutoka kwa nakala rudufu, ikiwa tutafanya nakala, basi takwimu zetu zitakuwa sawa kabisa. Kwa sababu tuna muundo mzima wa data halisi, yaani, tutaleta data kama ilivyo na vipimo vyote vya takwimu pia.

Hapa kuna shida nyingine. Ikiwa unatumia ufumbuzi wa wingu, basi utupaji wa mantiki tu unapatikana huko, kwa sababu Google, Amazon haukuruhusu kuchukua nakala ya kimwili. Kutakuwa na shida kama hiyo.

Asante kwa ripoti. Kulikuwa na maswali mawili mazuri hapa kuhusu MySQL na kushiriki rasilimali. Lakini, kwa kweli, yote inakuja kwa ukweli kwamba hii sio mada ya DBMS maalum, lakini ya mfumo wa faili kwa ujumla. Na, ipasavyo, maswala ya kugawana rasilimali pia yanapaswa kutatuliwa kutoka hapo, sio mwisho kwamba ni Postgres, lakini katika mfumo wa faili, kwenye seva, kwa mfano.

Swali langu ni tofauti kidogo. Iko karibu na hifadhidata ya safu nyingi, ambapo kuna tabaka kadhaa. Kwa mfano, tunaweka sasisho la picha ya terabyte kumi, tunaiga. Na sisi hutumia suluhisho hili haswa kwa hifadhidata. Uigaji unaendelea, data inasasishwa. Kuna wafanyikazi 100 wanaofanya kazi sambamba hapa, ambao wanazindua picha hizi tofauti kila wakati. Nini cha kufanya? Jinsi ya kuhakikisha kuwa hakuna mgongano, kwamba walizindua moja, na kisha mfumo wa faili ulibadilika, na picha hizi zote zilikwenda?

Hawataenda kwa sababu ndivyo ZFS inavyofanya kazi. Tunaweza kuweka tofauti katika uzi mmoja mabadiliko ya mfumo wa faili ambayo huja kwa sababu ya urudufishaji. Na weka clones ambazo wasanidi hutumia kwenye matoleo ya awali ya data. Na inatufanyia kazi, kila kitu kiko katika mpangilio na hii.

Inabadilika kuwa sasisho litafanyika kama safu ya ziada, na picha zote mpya zitaenda tayari, kulingana na safu hii, sawa?

Kutoka kwa tabaka zilizopita ambazo zilitoka kwa nakala zilizopita.

Tabaka zilizopita zitaanguka, lakini zitarejelea safu ya zamani, na watachukua picha mpya kutoka safu ya mwisho iliyopokelewa kwenye sasisho?

Kwa ujumla, ndiyo.

Kisha kama matokeo tutakuwa na hadi tini ya tabaka. Na baada ya muda watahitaji kukandamizwa?

Ndiyo kila kitu ni sahihi. Kuna dirisha fulani. Tunaweka snapshots za kila wiki. Inategemea una rasilimali gani. Ikiwa una uwezo wa kuhifadhi data nyingi, unaweza kuhifadhi snapshots kwa muda mrefu. Hawataondoka peke yao. Hakutakuwa na ufisadi wa data. Ikiwa vijipicha vimepitwa na wakati, kama inavyoonekana kwetu, i.e. inategemea sera katika kampuni, basi tunaweza kuzifuta na kuweka nafasi.

Habari, asante kwa ripoti! Swali kuhusu Joe. Ulisema kuwa mteja hakutaka kumpa kila mtu ufikiaji wa data. Kwa kusema kweli, ikiwa mtu ana matokeo ya Eleza Uchambuzi, basi anaweza kutazama data.

Ni kama hivyo. Kwa mfano, tunaweza kuandika: "CHAGUA KUTOKA WAPI barua pepe = kwa hiyo". Hiyo ni, hatutaona data yenyewe, lakini tunaweza kuona ishara zisizo za moja kwa moja. Hii lazima ieleweke. Lakini kwa upande mwingine, yote yapo. Tuna ukaguzi wa kumbukumbu, tuna udhibiti wa wenzetu wengine ambao pia wanaona kile ambacho wasanidi programu wanafanya. Na ikiwa mtu anajaribu kufanya hivyo, basi huduma ya usalama itakuja kwao na kufanya kazi juu ya suala hili.

Habari za mchana Asante kwa ripoti! Nina swali fupi. Ikiwa kampuni haitumii Slack, je, kuna jambo la kuifunga kwa sasa, au inawezekana kwa wasanidi programu kupeleka matukio ili kuunganisha programu ya majaribio kwenye hifadhidata?

Sasa kuna kiunga cha Slack, i.e. hakuna mjumbe mwingine, lakini ninataka sana kutoa msaada kwa wajumbe wengine pia. Unaweza kufanya nini? Unaweza kupeleka DB Lab bila Joe, nenda kwa usaidizi wa API ya REST au kwa usaidizi wa jukwaa letu na kuunda clones na kuunganisha na PSQL. Lakini hii inaweza kufanywa ikiwa uko tayari kuwapa wasanidi programu wako ufikiaji wa data, kwa sababu hakutakuwa tena na skrini yoyote.

Sihitaji safu hii, lakini ninahitaji fursa kama hiyo.

Kisha ndiyo, inaweza kufanyika.

Chanzo: mapenzi.com