Wakati fulani katika siku zijazo za mbali, kuondolewa kiotomatiki kwa data isiyo ya lazima itakuwa moja ya kazi muhimu za DBMS [1]. Wakati huo huo, sisi wenyewe tunahitaji kutunza kufuta au kuhamisha data isiyo ya lazima kwa mifumo ya hifadhi ya bei nafuu. Tuseme umeamua kufuta safu mlalo milioni chache. Kazi rahisi sana, haswa ikiwa hali hiyo inajulikana na kuna faharisi inayofaa. "FUTA KUTOKA kwa jedwali1 WAPI col1 = :thamani" - ni nini kinachoweza kuwa rahisi zaidi, sivyo?
Video:
-
Nimekuwa kwenye kamati ya programu ya Highload tangu mwaka wa kwanza, yaani tangu 2007.
-
Na nimekuwa na Postgres tangu 2005. Imetumika katika miradi mingi.
-
Kundi na RuPostges pia tangu 2007.
-
Tumekua na kufikia washiriki 2100+ kwenye Meetup. Ni ya pili duniani baada ya New York, kupitwa na San Francisco kwa muda mrefu.
-
Nimeishi California kwa miaka kadhaa. Ninashughulika zaidi na kampuni za Amerika, pamoja na kubwa. Ni watumiaji hai wa Postgres. Na kuna kila aina ya mambo ya kuvutia.
ni kampuni yangu. Tuko katika biashara ya kazi za kiotomatiki ambazo huondoa kushuka kwa maendeleo.
Ikiwa unafanya kitu, basi wakati mwingine kuna aina fulani ya plugs karibu na Postgres. Hebu tuseme unahitaji kusubiri hadi msimamizi akuwekee stendi ya majaribio, au unahitaji kusubiri DBA ikujibu. Na tunapata vikwazo vile katika mchakato wa maendeleo, kupima na utawala na kujaribu kuwaondoa kwa msaada wa automatisering na mbinu mpya.
Hivi majuzi nilikuwa VLDB huko Los Angeles. Huu ndio mkutano mkubwa zaidi wa hifadhidata. Na kulikuwa na ripoti kwamba katika siku zijazo DBMS haitahifadhi tu, bali pia kufuta data moja kwa moja. Hii ni mada mpya.
Kuna data zaidi na zaidi katika ulimwengu wa zettabytes - hiyo ni petabytes 1. Na sasa tayari inakadiriwa kuwa tuna zaidi ya zettabytes 000 za data zilizohifadhiwa ulimwenguni. Na kuna zaidi na zaidi yao.
Na nini cha kufanya nayo? Ni wazi kwamba inahitaji kuondolewa. Hapa kuna kiunga cha ripoti hii ya kuvutia. Lakini hadi sasa hii haijatekelezwa katika DBMS.
Wanaoweza kuhesabu pesa wanataka vitu viwili. Wanataka tufute, kwa hivyo kitaalam tunapaswa kuwa na uwezo wa kuifanya.
Nitakachosema baadaye ni hali fulani ya kufikirika ambayo inajumuisha rundo la hali halisi, yaani, aina ya mkusanyiko wa kile kilichotokea kwangu na hifadhidata zinazonizunguka mara nyingi, miaka mingi. Rakes ziko kila mahali na kila mtu huwakanyaga kila wakati.
Wacha tuseme tuna msingi au besi kadhaa ambazo zinakua. Na rekodi zingine ni takataka. Kwa mfano, mtumiaji alianza kufanya kitu huko, lakini hakumaliza. Na baada ya muda fulani tunajua kwamba hii haijakamilika haiwezi kuhifadhiwa tena. Hiyo ni, tungependa kusafisha baadhi ya vitu vya takataka ili kuokoa nafasi, kuboresha utendaji, nk.
Kwa ujumla, kazi ni kuelekeza uondoaji wa vitu maalum, mistari maalum katika meza fulani.
Na tuna ombi kama hilo, ambalo tutazungumza juu ya leo, ambayo ni, juu ya kuondolewa kwa takataka.
Tulimwomba msanidi programu aliye na uzoefu afanye hivyo. Alichukua ombi hili, akajiangalia mwenyewe - kila kitu kinafanya kazi. Ilijaribiwa kwenye jukwaa - kila kitu ni sawa. Imetolewa - kila kitu kinafanya kazi. Mara moja kwa siku tunaendesha - kila kitu ni sawa.
Hifadhidata inakua na kukua. Daily DELETE huanza kufanya kazi polepole zaidi.
Kisha tunaelewa kuwa sasa tuna kampuni ya uuzaji na trafiki itakuwa kubwa mara kadhaa, kwa hivyo tunaamua kusitisha kwa muda vitu visivyo vya lazima. Na kusahau kurudi.
Miezi michache baadaye walikumbuka. Na msanidi programu huyo aliacha au anashughulika na kitu kingine, alimwagiza mwingine kuirejesha.
Aliangalia kwenye dev, kwenye steji - kila kitu kiko sawa. Kwa kawaida, bado unahitaji kusafisha kile kilichokusanya. Aliangalia kila kitu kinafanya kazi.
Nini kitatokea baadaye? Kisha kila kitu kinaanguka kwa ajili yetu. Inashuka ili wakati fulani kila kitu kinaanguka chini. Kila mtu yuko katika mshtuko, hakuna anayeelewa kinachotokea. Na kisha ikawa kwamba jambo lilikuwa katika hii DELETE.
Hitilafu fulani imetokea? Hapa kuna orodha ya kile ambacho huenda kilienda vibaya. Ni ipi kati ya hizi iliyo muhimu zaidi?
-
Kwa mfano, hapakuwa na mapitio, yaani mtaalam wa DBA hakuiangalia. Angepata shida mara moja kwa jicho la uzoefu, na zaidi ya hayo, ana ufikiaji wa prod, ambapo laini milioni kadhaa zimekusanyika.
-
Labda walikagua kitu kibaya.
-
Labda maunzi yamepitwa na wakati na unahitaji kuboresha msingi huu.
-
Au kuna kitu kibaya na hifadhidata yenyewe, na tunahitaji kuhama kutoka Postgres hadi MySQL.
-
Au labda kuna kitu kibaya na operesheni.
-
Labda kuna makosa fulani katika shirika la kazi na unahitaji kumfukuza mtu na kuajiri watu bora?
Hakukuwa na ukaguzi wa DBA. Ikiwa kulikuwa na DBA, angeona mistari hii milioni kadhaa na hata bila majaribio yoyote angesema: "Hawafanyi hivyo." Tuseme ikiwa nambari hii ilikuwa kwenye GitLab, GitHub na kungekuwa na mchakato wa kukagua nambari na hakukuwa na kitu kama kwamba bila idhini ya DBA operesheni hii ingefanyika kwa uzalishaji, basi ni wazi DBA ingesema: "Hii haiwezi kufanywa. .β
Na angesema kuwa utakuwa na matatizo na disk IO na taratibu zote zitaenda wazimu, kunaweza kuwa na kufuli, na pia utazuia autovacuum kwa kundi la dakika, hivyo hii si nzuri.
Makosa ya pili - waliangalia mahali pabaya. Tuliona baada ya ukweli kwamba data nyingi za taka zilikusanywa kwenye prod, lakini msanidi programu hakuwa na data iliyokusanywa katika hifadhidata hii, na hakuna mtu aliyeunda taka hii wakati wa kuweka. Ipasavyo, kulikuwa na mistari 1 ambayo ilifanya kazi haraka.
Tunaelewa kwamba vipimo vyetu ni dhaifu, yaani, mchakato unaojengwa haupati matatizo. Jaribio la kutosha la DB halikufanyika.
Jaribio bora linapendekezwa kufanywa kwenye vifaa sawa. Si mara zote inawezekana kufanya hivyo kwenye vifaa sawa, lakini ni muhimu sana kuwa nakala ya ukubwa kamili wa database. Hiki ndicho nimekuwa nikihubiri kwa miaka kadhaa sasa. Na mwaka mmoja uliopita nilizungumza kuhusu hili, unaweza kuitazama yote kwenye YouTube.
Labda vifaa vyetu ni mbaya? Ikiwa unatazama, basi latency iliruka. Tumeona kwamba matumizi ni 100%. Kwa kweli, ikiwa hizi zilikuwa anatoa za kisasa za NVMe, basi labda ingekuwa rahisi zaidi kwetu. Na labda tusingejitolea kutoka kwake.
Ikiwa una mawingu, basi uboreshaji unafanywa kwa urahisi huko. Imeongeza nakala mpya kwenye maunzi mapya. ubadilishaji. Na yote ni sawa. Rahisi sana.
Je, inawezekana kwa namna fulani kugusa diski ndogo? Na hapa, kwa usaidizi wa DBA, tunaingia kwenye mada fulani inayoitwa urekebishaji wa sehemu ya ukaguzi. Ilibainika kuwa hatukuwa na urekebishaji wa vituo vya ukaguzi.
Kituo cha ukaguzi ni nini? Iko katika DBMS yoyote. Unapokuwa na data kwenye kumbukumbu inayobadilika, haijaandikwa mara moja kwa diski. Taarifa ambayo data imebadilika huandikwa kwanza kwenye logi ya kuandika mbele. Na wakati fulani, DBMS inaamua kuwa ni wakati wa kutupa kurasa halisi kwenye diski, ili ikiwa tuna kushindwa, tunaweza kufanya REDO kidogo. Ni kama toy. Ikiwa tutauawa, tutaanza mchezo kutoka kwa ukaguzi wa mwisho. Na DBMS zote huitekeleza.
Mipangilio katika Postgres iko nyuma. Zimeundwa kwa idadi ya miaka 10-15 ya data na shughuli. Na kituo cha ukaguzi sio ubaguzi.
Haya hapa ni maelezo kutoka kwa ripoti yetu ya ukaguzi wa Postgres, yaani ukaguzi wa kiafya kiotomatiki. Na hapa kuna hifadhidata ya terabytes kadhaa. Na inaweza kuonekana vizuri kwamba vituo vya ukaguzi vya kulazimishwa katika karibu 90% ya kesi.
Ina maana gani? Kuna mipangilio miwili hapo. Sehemu ya ukaguzi inaweza kuja kwa muda, kwa mfano, katika dakika 10. Au inaweza kuja wakati data nyingi zimejazwa.
Na kwa chaguo-msingi max_wal_saze imewekwa kuwa gigabyte 1. Kwa kweli, hii hufanyika katika Postgres baada ya megabytes 300-400. Umebadilisha data nyingi sana na kituo chako cha ukaguzi kinatokea.
Na ikiwa hakuna mtu aliyeiweka, na huduma ilikua, na kampuni inapata pesa nyingi, ina shughuli nyingi, basi ukaguzi unakuja mara moja kwa dakika, wakati mwingine kila sekunde 30, na wakati mwingine hata kuingiliana. Hii ni mbaya kabisa.
Na tunahitaji kuhakikisha kuwa inakuja mara chache. Hiyo ni, tunaweza kuongeza max_wal_size. Na itakuja mara kwa mara.
Lakini tumeanzisha mbinu nzima ya jinsi ya kufanya hivyo kwa usahihi zaidi, yaani, jinsi ya kufanya uamuzi kuhusu kuchagua mipangilio, kwa uwazi kulingana na data maalum.
Ipasavyo, tunafanya safu mbili za majaribio kwenye hifadhidata.
Mfululizo wa kwanza - tunabadilisha max_wal_size. Na tunafanya operesheni kubwa. Kwanza, tunaifanya kwa mpangilio wa msingi wa gigabyte 1. Na tunafanya DELETE kubwa ya mamilioni ya mistari.
Unaweza kuona jinsi ilivyo ngumu kwetu. Tunaona kwamba disk IO ni mbaya sana. Tunaangalia ni WAL ngapi tumezalisha, kwa sababu hii ni muhimu sana. Hebu tuone ni mara ngapi kituo cha ukaguzi kilifanyika. Na tunaona kuwa sio nzuri.
Ifuatayo tunaongeza max_wal_size. Tunarudia. Tunaongeza, tunarudia. Na mara nyingi sana. Kimsingi, pointi 10 ni nzuri, ambapo 1, 2, 4, 8 gigabytes. Na tunaangalia tabia ya mfumo fulani. Ni wazi kuwa hapa vifaa vinapaswa kuwa kama kwenye prod. Lazima uwe na diski sawa, kiasi sawa cha kumbukumbu, na mipangilio sawa ya Postgres.
Na kwa njia hii tutabadilishana mfumo wetu, na tunajua jinsi DBMS itafanya katika kesi ya DELETE ya molekuli mbaya, jinsi itakavyoangalia.
Vituo vya ukaguzi kwa Kirusi ni vituo vya ukaguzi.
Mfano: FUTA safu mlalo milioni kadhaa kwa faharasa, safumlalo "zimetawanyika" kwenye kurasa zote.
Hapa kuna mfano. Huu ni msingi fulani. Na kwa mpangilio chaguo-msingi wa gigabyte 1 kwa max_wal_size, ni wazi kabisa kwamba diski zetu huenda kwenye rafu kwa ajili ya kurekodi. Picha hii ni dalili ya kawaida ya mgonjwa mgonjwa sana, yaani, alijisikia vibaya sana. Na kulikuwa na operesheni moja, kulikuwa na DELETE ya mistari milioni kadhaa.
Ikiwa operesheni hiyo inaruhusiwa katika prod, basi tutalala tu, kwa sababu ni wazi kwamba DELETE moja inatuua katika kikosi.
Zaidi ya hayo, ambapo gigabytes 16, ni wazi kwamba meno tayari yamekwenda. Meno tayari ni bora, yaani, tunagonga dari, lakini sio mbaya sana. Kulikuwa na uhuru fulani huko. Upande wa kulia ni rekodi. Na idadi ya shughuli - grafu ya pili. Na ni wazi kwamba tayari tunapumua rahisi kidogo wakati gigabytes 16.
Na ambapo gigabytes 64 inaweza kuonekana kuwa imekuwa bora kabisa. Tayari meno yanatamkwa, kuna fursa zaidi za kuishi shughuli zingine na kufanya kitu na diski.
Kwa nini?
Nitaingia kwenye maelezo kidogo, lakini mada hii, jinsi ya kufanya urekebishaji wa ukaguzi, inaweza kusababisha ripoti nzima, kwa hivyo sitapakia sana, lakini nitaelezea kidogo shida gani zilizopo.
Ikiwa ukaguzi hutokea mara nyingi sana, na tunasasisha mistari yetu si kwa mfululizo, lakini kupata kwa index, ambayo ni nzuri, kwa sababu hatufuta meza nzima, basi inaweza kutokea kwamba mwanzoni tuligusa ukurasa wa kwanza, kisha wa elfu, kisha akarudi kwa wa kwanza. Na ikiwa kati ya ziara hizi kwenye ukurasa wa kwanza, kituo cha ukaguzi tayari kimeihifadhi kwenye diski, basi itaiokoa tena, kwa sababu tuliichafua mara ya pili.
Na tutalazimisha ukaguzi ili kuihifadhi mara nyingi. Je, kungekuwa na shughuli zisizohitajika kwake.
Lakini si hayo tu. Kurasa ni kilobaiti 8 katika Postgres na kilobaiti 4 katika Linux. Na kuna mpangilio kamili wa ukurasa_unaandika. Inawezeshwa na chaguo-msingi. Na hii ni sahihi, kwa sababu ikiwa tunaizima, basi kuna hatari kwamba nusu tu ya ukurasa itaokolewa ikiwa itaanguka.
Tabia ya kuandika kwa WAL ya logi ya mbele ni kwamba tunapokuwa na ukaguzi na tunabadilisha ukurasa kwa mara ya kwanza, ukurasa mzima, i.e., kilobytes zote 8, huingia kwenye logi ya mbele, ingawa tulibadilisha tu line, ambayo ina uzito wa ka 100. Na tunapaswa kuandika ukurasa mzima.
Katika mabadiliko yafuatayo kutakuwa na tuple maalum, lakini kwa mara ya kwanza tunaandika kila kitu.
Na, ipasavyo, ikiwa ukaguzi ulifanyika tena, basi lazima tuanze kila kitu kutoka mwanzo tena na kushinikiza ukurasa mzima. Kwa vituo vya ukaguzi vya mara kwa mara, tunapopitia kurasa zile zile, full_page_writes = on itakuwa zaidi ya inavyoweza kuwa, yaani, tunazalisha WAL zaidi. Zaidi hutumwa kwa nakala, kwenye kumbukumbu, kwenye diski.
Na, ipasavyo, tuna redundancies mbili.
Ikiwa tutaongeza max_wal_size, itabainika kuwa tunarahisisha kazi kwa sehemu ya ukaguzi na wal writer. Na hiyo ni nzuri.
Wacha tuweke terabyte na tuishi nayo. Kuna ubaya gani? Hii ni mbaya, kwa sababu katika kesi ya kushindwa, tutapanda kwa masaa, kwa sababu kituo cha ukaguzi kilikuwa cha muda mrefu uliopita na mengi tayari yamebadilika. Na tunahitaji kufanya haya yote TENA. Na hivyo tunafanya mfululizo wa pili wa majaribio.
Tunafanya operesheni na kuona wakati kituo cha ukaguzi kinakaribia kukamilika, tunaua -9 Postgres kwa makusudi.
Na baada ya hayo tunaanza tena, na kuona muda gani itaongezeka kwenye vifaa hivi, yaani ni kiasi gani kitakachofanya TENA katika hali hii mbaya.
Mara mbili nitagundua kuwa hali ni mbaya. Kwanza, tulianguka kabla ya kituo cha ukaguzi kukamilika, kwa hivyo tuna mengi ya kupoteza. Na pili, tulikuwa na operesheni kubwa. Na ikiwa vituo vya ukaguzi vilikuwa vimeisha, basi, uwezekano mkubwa, chini ya WAL ingetolewa tangu kituo cha ukaguzi cha mwisho. Yaani ni mshindwa maradufu.
Tunapima hali kama hiyo kwa saizi tofauti za max_wal_size na tunaelewa kuwa ikiwa max_wal_size ni gigabytes 64, basi katika hali mbaya zaidi tutapanda kwa dakika 10. Na tunafikiria ikiwa inafaa au la. Hili ni swali la biashara. Tunahitaji kuonyesha picha hii kwa wale wanaohusika na maamuzi ya biashara na kuuliza, "Je, tunaweza kulala chini kwa muda gani ikiwa kuna shida? Je, tunaweza kulala chini katika hali mbaya zaidi kwa dakika 3-5? Na ufanye uamuzi.
Na hapa kuna hatua ya kuvutia. Tuna ripoti kadhaa kuhusu Patroni kwenye mkutano huo. Na labda unaitumia. Hili ni toleo la kiotomatiki la Postgres. GitLab na Data Egret walizungumza juu ya hili.
Na ikiwa una kiotomatiki ambacho kinakuja baada ya sekunde 30, basi labda tunaweza kulala chini kwa dakika 10? Kwa sababu tutabadilisha kwa replica kwa hatua hii, na kila kitu kitakuwa sawa. Hili ni jambo lisiloeleweka. Sijui jibu wazi. Ninahisi tu kuwa mada hii haiko karibu tu na urejeshaji wa ajali.
Ikiwa tuna ahueni ya muda mrefu baada ya kushindwa, basi tutakuwa na wasiwasi katika hali nyingine nyingi. Kwa mfano, katika majaribio sawa, tunapofanya kitu na wakati mwingine tunapaswa kusubiri kwa dakika 10.
Bado singeenda mbali sana, hata kama tutakuwa na kiotomatiki. Kama sheria, maadili kama 64, gigabytes 100 ni maadili mazuri. Wakati mwingine inafaa hata kuchagua kidogo. Kwa ujumla, hii ni sayansi ya hila.
Ili kufanya marudio, kwa mfano, max_wal_size =1, 8, unahitaji kurudia operesheni ya wingi mara nyingi. Umefanikiwa. Na kwa msingi huo huo unataka kuifanya tena, lakini tayari umefuta kila kitu. Nini cha kufanya?
Nitazungumza baadaye juu ya suluhisho letu, kile tunachofanya ili kujirudia katika hali kama hizi. Na hii ndiyo njia sahihi zaidi.
Lakini katika kesi hii, tulikuwa na bahati. Ikiwa, kama inavyosema hapa "ANZA, FUTA, ROLLBACK", basi tunaweza kurudia KUFUTA. Hiyo ni, ikiwa tulighairi wenyewe, basi tunaweza kurudia. Na kimwili kwako data italala mahali pamoja. Hupati hata uvimbe wowote. Unaweza kurudia DELETE kama hizi.
Futa hii kwa kutumia ROLLBACK ni bora kwa urekebishaji wa sehemu ya ukaguzi, hata kama huna maabara ya hifadhidata iliyosambazwa ipasavyo.
Tulifanya sahani na safu moja "i". Postgres ina safu wima za matumizi. Hazionekani isipokuwa zimeombwa mahususi. Hizi ni: ctid, xmid, xmax.
Ctid ni anwani halisi. Ukurasa sifuri, nakala ya kwanza kwenye ukurasa.
Inaweza kuonekana kuwa baada ya ROOLBACK tuple ilibaki mahali pamoja. Hiyo ni, tunaweza kujaribu tena, itakuwa sawa. Hili ndilo jambo kuu.
Xmax ni wakati wa kifo cha tuple. Iliwekwa muhuri, lakini Postgres anajua kuwa shughuli hiyo ilirudishwa nyuma, kwa hivyo haijalishi ikiwa ni 0 au ni shughuli iliyorudishwa nyuma. Hii inapendekeza kwamba inawezekana kurudia juu ya DELETE na kuangalia shughuli nyingi za tabia ya mfumo. Unaweza kutengeneza maabara za hifadhidata kwa ajili ya maskini.
Hii ni kuhusu watengeneza programu. Kuhusu DBA, pia, huwakemea waandaaji wa programu kwa hili: "Kwa nini unafanya shughuli ndefu na ngumu?". Hii ni mada tofauti kabisa ya perpendicular. Kulikuwa na utawala, na sasa kutakuwa na maendeleo.
Kwa wazi, hatujagawanyika vipande vipande. Ni wazi. Haiwezekani kutovunja DELETE kama hiyo kwa lundo la mamilioni ya mistari kuwa sehemu. Itafanyika kwa dakika 20, na kila kitu kitalala. Lakini, kwa bahati mbaya, hata watengenezaji wenye ujuzi hufanya makosa, hata katika makampuni makubwa sana.
Kwa nini ni muhimu kuvunja?
-
Ikiwa tunaona kwamba diski ni ngumu, basi hebu tuipunguze. Na ikiwa tumevunjika, basi tunaweza kuongeza pause, tunaweza kupunguza kasi ya kupiga.
-
Na hatutazuia wengine kwa muda mrefu. Katika baadhi ya matukio haijalishi, ikiwa unafuta takataka halisi ambayo hakuna mtu anayefanya kazi, basi uwezekano mkubwa hutazuia mtu yeyote isipokuwa kazi ya autovacuum, kwa sababu itasubiri shughuli ikamilike. Lakini ukiondoa kitu ambacho mtu mwingine anaweza kuomba, basi atazuiwa, kutakuwa na aina fulani ya mmenyuko wa mnyororo. Shughuli za muda mrefu zinapaswa kuepukwa kwenye tovuti na programu za simu.
Hii inavutia. Mara nyingi mimi huona kwamba watengenezaji wanauliza: "Je! ninapaswa kuchagua ukubwa gani wa pakiti?".
Ni wazi kwamba ukubwa wa kifungu kikubwa, ndogo ya uendeshaji wa shughuli, yaani, ziada ya ziada kutoka kwa shughuli. Lakini wakati huo huo, wakati huongezeka kwa shughuli hii.
Nina sheria rahisi sana: chukua kadri uwezavyo, lakini usipitie utekelezwaji kwa sekunde.
Kwa nini sekunde? Maelezo ni rahisi sana na yanaeleweka kwa kila mtu, hata watu wasio wa kiufundi. Tunaona majibu. Wacha tuchukue milliseconds 50. Ikiwa kitu kimebadilika, basi jicho letu litaguswa. Ikiwa chini, basi ngumu zaidi. Ikiwa kitu kitajibu baada ya milisekunde 100, kwa mfano, ulibofya kipanya, na ikakujibu baada ya milisekunde 100, tayari unahisi kuchelewa huku kidogo. Sekunde tayari inatambulika kama breki.
Ipasavyo, ikiwa tutavunja shughuli zetu za wingi kuwa milipuko ya sekunde 10, basi tuna hatari kwamba tutamzuia mtu. Na itafanya kazi kwa sekunde chache, na watu tayari wataigundua. Kwa hivyo, napendelea kutofanya zaidi ya sekunde. Lakini wakati huo huo, usiivunje vizuri sana, kwa sababu shughuli ya juu itaonekana. Msingi utakuwa mgumu, na matatizo mengine tofauti yanaweza kutokea.
Tunachagua ukubwa wa pakiti. Katika kila kesi, tunaweza kufanya hivyo tofauti. Inaweza kuwa otomatiki. Na tuna hakika ya ufanisi wa usindikaji wa pakiti moja. Hiyo ni, tunafanya DELETE ya pakiti moja au UPDATE.
Kwa njia, kila kitu ninachozungumza sio tu kuhusu DELETE. Kama ulivyokisia, hizi ni shughuli zozote nyingi kwenye data.
Na tunaona kwamba mpango ni bora. Unaweza kuona tambazo la faharisi, tambazo la faharisi pekee ndio bora zaidi. Na tuna kiasi kidogo cha data inayohusika. Na chini ya sekunde moja hutimiza. Super.
Na bado tunahitaji kuhakikisha kuwa hakuna uharibifu. Inatokea kwamba pakiti za kwanza hufanya kazi haraka, na kisha inakuwa mbaya zaidi, mbaya zaidi na mbaya zaidi. Mchakato ni kama kwamba unahitaji kupima mengi. Hivi ndivyo maabara za hifadhidata ni za.
Na bado tunapaswa kuandaa kitu ili ituruhusu kufuata hii kwa usahihi katika uzalishaji. Kwa mfano, tunaweza kuandika wakati katika logi, tunaweza kuandika tulipo sasa na ambao tumefuta sasa. Na hii itatuwezesha kuelewa kinachotokea baadaye. Na ikiwa kitu kitaenda vibaya, pata shida haraka.
Ikiwa tunahitaji kuangalia ufanisi wa maombi na tunahitaji kurudia mara nyingi, basi kuna kitu kama roboti mwenzetu. Tayari yuko tayari. Inatumiwa na watengenezaji kadhaa kila siku. Na anajua jinsi ya kutoa hifadhidata kubwa ya terabyte kwa ombi katika sekunde 30, nakala yako mwenyewe. Na unaweza kufuta kitu hapo na kusema WEKA UPYA, na uifute tena. Unaweza kuijaribu kwa njia hii. Ninaona mustakabali wa jambo hili. Na tayari tunafanya.
Mikakati ya kugawa ni nini? Ninaona mikakati 3 tofauti ya kugawa ambayo watengenezaji kwenye pakiti wanatumia.
Ya kwanza ni rahisi sana. Tuna kitambulisho cha nambari. Na wacha tuigawanye katika vipindi tofauti na tufanye kazi nayo. Upande wa chini ni wazi. Katika sehemu ya kwanza, tunaweza kuwa na mistari 100 ya takataka halisi, katika mistari 5 ya pili au sio kabisa, au mistari yote 1 itageuka kuwa takataka. Kazi isiyo sawa sana, lakini ni rahisi kuvunja. Walichukua kitambulisho cha juu kabisa na kukivunja. Hii ni mbinu ya ujinga.
Mkakati wa pili ni njia ya usawa. Inatumika katika Gitlab. Walichukua na kukagua meza. Tulipata mipaka ya pakiti za vitambulisho ili kila pakiti iwe na rekodi 10 haswa. Na kuwaweka kwenye foleni. Na kisha sisi mchakato. Unaweza kufanya hivyo katika nyuzi nyingi.
Katika mkakati wa kwanza, pia, kwa njia, unaweza kufanya hivyo kwa nyuzi kadhaa. Sio ngumu.
Lakini kuna njia ya baridi na bora zaidi. Huu ni mkakati wa tatu. Na inapowezekana, ni bora kuichagua. Tunafanya hivyo kwa misingi ya index maalum. Katika kesi hii, itakuwa na uwezekano mkubwa kuwa index kulingana na hali yetu ya takataka na kitambulisho. Tutajumuisha kitambulisho ili kiwe index tu ili tusiende kwenye lundo.
Kwa ujumla, uchanganuzi wa faharasa pekee ni haraka kuliko uchanganuzi wa faharasa.
Na tunapata vitambulisho vyetu kwa haraka ambavyo tunataka kufuta. BATCH_SIZE tunachagua mapema. Na sisi si tu kupata yao, sisi kupata yao kwa njia maalum na mara moja hack yao. Lakini tunafunga ili ikiwa tayari imefungwa, hatuzifungi, lakini endelea na kuchukua zifuatazo. Hii ni ya kuruka kwa sasisho imefungwa. Kipengele hiki bora cha Postgres huturuhusu kufanya kazi katika nyuzi kadhaa ikiwa tunataka. Inawezekana katika mkondo mmoja. Na hapa kuna CTE - hii ni ombi moja. Na tunayo ufutaji halisi unaoendelea katika ghorofa ya pili ya CTE hii - returning *. Unaweza kurudisha kitambulisho, lakini ni bora zaidi *ikiwa huna data nyingi kwenye kila mstari.
Kwa nini tunaihitaji? Hili ndilo tunalohitaji kuripoti. Sasa tumefuta mistari mingi sana kwa kweli. Na tuna mipaka kwa kitambulisho au kwa kuundwa_kama hivi. Unaweza kufanya min, max. Kitu kingine kinaweza kufanywa. Unaweza kuweka vitu vingi hapa. Na ni rahisi sana kwa ufuatiliaji.
Kuna dokezo moja zaidi kuhusu index. Ikiwa tutaamua kuwa tunahitaji faharisi maalum kwa kazi hii, basi tunahitaji kuhakikisha kuwa haiharibu masasisho ya nakala tu. Hiyo ni, Postgres ina takwimu kama hizo. Hii inaweza kuonekana katika pg_stat_user_tables kwa jedwali lako. Unaweza kuona ikiwa sasisho motomoto zinatumiwa au la.
Kuna hali wakati faharisi yako mpya inaweza kuzikata tu. Na una masasisho mengine yote ambayo tayari yanafanya kazi, punguza kasi. Sio tu kwa sababu index ilionekana (kila index inapunguza kasi ya sasisho kidogo, lakini kidogo), lakini hapa bado inaharibu. Na haiwezekani kufanya optimization maalum kwa meza hii. Hii hutokea wakati mwingine. Huu ni ujanja ambao watu wachache wanakumbuka. Na safu hii ni rahisi kukanyaga. Wakati mwingine hutokea kwamba unahitaji kupata mbinu kutoka upande mwingine na bado kufanya bila index hii mpya, au kufanya index nyingine, au kwa njia nyingine, kwa mfano, unaweza kutumia njia ya pili.
Lakini hii ni mkakati bora zaidi, jinsi ya kugawanyika katika makundi na kupiga batches na ombi moja, kufuta kidogo, nk.
Shughuli ndefu
Otomatiki iliyozuiwa -
suala la kuzuia -
Kosa namba 5 ni kubwa. Nikolai kutoka Okmeter alizungumza kuhusu ufuatiliaji wa Postgres. Ufuatiliaji Bora wa Postgres, kwa bahati mbaya, haupo. Wengine wako karibu, wengine wako mbali zaidi. Okmeter iko karibu vya kutosha kuwa kamili, lakini mengi hayapo na yanahitaji kuongezwa. Unahitaji kuwa tayari kwa hili.
Kwa mfano, tuples zilizokufa zinafuatiliwa vyema. Ikiwa una vitu vingi vilivyokufa kwenye meza, basi kuna kitu kibaya. Ni bora kuguswa sasa, vinginevyo kunaweza kuwa na uharibifu, na tunaweza kulala chini. Inatokea.
Ikiwa kuna IO kubwa, basi ni wazi kwamba hii si nzuri.
Shughuli za muda mrefu pia. Shughuli za muda mrefu hazipaswi kuruhusiwa kwenye OLTP. Na hapa kuna kiunga cha kijisehemu kinachokuruhusu kuchukua kijisehemu hiki na tayari ufuatilie miamala mirefu.
Kwa nini shughuli za muda mrefu ni mbaya? Kwa sababu kufuli zote zitatolewa tu mwishoni. Na tunamdanganya kila mtu. Zaidi ya hayo, tunazuia otomatiki kwa jedwali zote. Sio nzuri hata kidogo. Hata kama umewasha hali ya kusubiri tu kwenye nakala, bado ni mbaya. Kwa ujumla, hakuna mahali ambapo ni bora kuepuka shughuli za muda mrefu.
Ikiwa tuna meza nyingi ambazo hazijaondolewa, basi tunahitaji kuwa na tahadhari. Hapa hali kama hiyo inawezekana. Tunaweza kuathiri moja kwa moja uendeshaji wa autovacuum. Hii ni snippet kutoka Avito, ambayo niliboresha kidogo. Na ikawa zana ya kuvutia kuona kile tulicho nacho na autovacuum. Kwa mfano, meza zingine zinangojea hapo na hazitasubiri zamu yao. Pia unahitaji kuiweka katika ufuatiliaji na kuwa na tahadhari.
Na masuala vitalu. Msitu wa miti ya block. Ninapenda kuchukua kitu kutoka kwa mtu na kukiboresha. Hapa nilichukua CTE ya kurudisha nyuma kutoka kwa Data Egret ambayo inaonyesha msitu wa miti ya kufuli. Hii ni zana nzuri ya utambuzi. Na kwa misingi yake, unaweza pia kujenga ufuatiliaji. Lakini hii lazima ifanyike kwa uangalifu. Unahitaji kujifanyia statement_timeout kidogo. Na lock_timeout inafaa.
Wakati mwingine makosa haya yote hutokea kwa jumla.
Kwa maoni yangu, kosa kuu hapa ni shirika. Ni ya shirika, kwa sababu mbinu haina kuvuta. Hii ni nambari 2 - waliangalia mahali pabaya.
Tuliangalia mahali pasipofaa, kwa sababu hatukuwa na mwambaa wa uzalishaji, ambao ni rahisi kuangalia. Msanidi programu anaweza kukosa ufikiaji wa uzalishaji kabisa.
Na sisi checked si huko. Ikiwa tungeangalia huko, tungeona wenyewe. Msanidi aliona yote hata bila DBA ikiwa aliiangalia katika mazingira mazuri, ambapo kuna kiasi sawa cha data na eneo sawa. Angeona udhalilishaji wote huu na angeaibika.
Zaidi kuhusu autovacuum. Baada ya kufanya ufagiaji mkubwa wa mistari milioni kadhaa, bado tunahitaji kufanya REPACK. Hii ni muhimu hasa kwa indexes. Watajisikia vibaya baada ya sisi kusafisha kila kitu hapo.
Na ikiwa unataka kurejesha kazi ya kusafisha kila siku, basi ningependekeza kuifanya mara nyingi zaidi, lakini ndogo. Inaweza kuwa mara moja kwa dakika au hata mara nyingi zaidi kidogo. Na unahitaji kufuatilia mambo mawili: kwamba jambo hili halina makosa na kwamba halibaki nyuma. Ujanja ambao nilionyesha utasuluhisha hii tu.
Tunachofanya ni open source. Imewekwa kwenye GitLab. Na tunaifanya ili watu waweze kuangalia hata bila DBA. Tunafanya maabara ya hifadhidata, yaani, tunaita sehemu ya msingi ambayo Joe anafanya kazi kwa sasa. Na unaweza kunyakua nakala ya uzalishaji. Sasa kuna utekelezaji wa Joe kwa slack, unaweza kusema hapo: "eleza vile na ombi kama hilo" na mara moja pata matokeo ya nakala yako ya hifadhidata. Unaweza hata KUFUTA hapo, na hakuna mtu atakayeiona.
Wacha tuseme una terabytes 10, tunatengeneza maabara ya hifadhidata pia terabytes 10. Na kwa hifadhidata 10 za terabyte kwa wakati mmoja, watengenezaji 10 wanaweza kufanya kazi kwa wakati mmoja. Kila mtu anaweza kufanya anachotaka. Inaweza kufuta, kuacha, nk. Hiyo ni ndoto. Tutazungumza juu ya hili kesho.
Hii inaitwa utoaji nyembamba. Huu ni utoaji wa hila. Hii ni aina fulani ya fantasy ambayo huondoa sana ucheleweshaji katika maendeleo, katika kupima na kufanya ulimwengu kuwa mahali pazuri zaidi katika suala hili. Hiyo ni, inakuwezesha tu kuepuka matatizo na uendeshaji wa wingi.
Mfano: hifadhidata ya terabyte 5, kupata nakala chini ya sekunde 30. Na hata haitegemei saizi, ambayo ni, haijalishi ni terabytes ngapi.
Leo unaweza kwenda na kuchimba zana zetu. Unaweza kujiandikisha ili kuona kilichopo. Unaweza kusakinisha kijibu hiki. Ni bure. Andika.
maswali
Mara nyingi sana katika hali halisi zinageuka kuwa data ambayo inapaswa kubaki kwenye jedwali ni ndogo sana kuliko ile inayohitaji kufutwa. Hiyo ni, katika hali hiyo, mara nyingi ni rahisi kutekeleza mbinu hiyo, wakati ni rahisi kuunda kitu kipya, nakala tu data muhimu huko, na shina meza ya zamani. Ni wazi kwamba mbinu ya programu inahitajika kwa wakati huu, wakati utabadilisha. Mbinu hii ikoje?
Hii ni mbinu nzuri sana na kazi nzuri sana. Ni sawa na kile pg_repack hufanya, ni sawa na kile unachopaswa kufanya unapotengeneza vitambulisho 4 byte. Mifumo mingi ilifanya hivi miaka michache iliyopita, na sahani tu zimekua, na zinahitaji kubadilishwa kuwa ka 8.
Kazi hii ni ngumu sana. Tulifanya. Na unapaswa kuwa makini sana. Kuna kufuli, nk. Lakini inafanywa. Hiyo ni, mbinu ya kawaida ni kwenda na pg_repack. Unatangaza lebo kama hiyo. Na kabla ya kuanza kupakia data ya muhtasari ndani yake, unatangaza pia sahani moja inayofuatilia mabadiliko yote. Kuna hila kwamba unaweza hata kufuatilia baadhi ya mabadiliko. Kuna hila. Na kisha unabadilisha kwa kusonga mabadiliko. Kutakuwa na pause fupi tunapofunga kila mtu, lakini kwa ujumla hii inafanywa.
Ukiangalia pg_repack kwenye GitHub, basi hapo, wakati kulikuwa na kazi ya kubadilisha kitambulisho kutoka int 4 hadi int 8, basi kulikuwa na wazo la kutumia pg_repack yenyewe. Hii pia inawezekana, lakini ni utapeli kidogo, lakini itafanya kazi kwa hili pia. Unaweza kuingilia kati kichochezi ambacho pg_repack hutumia na kusema hapo: "Hatuitaji data hii", yaani, tunahamisha tu kile tunachohitaji. Na kisha anabadilisha tu na ndivyo hivyo.
Kwa mbinu hii, bado tunapata nakala ya pili ya jedwali, ambalo data tayari imeorodheshwa na imewekwa sawasawa na faharisi nzuri.
Bloat haipo, ni njia nzuri. Lakini najua kuwa kuna majaribio ya kukuza otomatiki kwa hili, i.e. kufanya suluhisho la ulimwengu wote. Ninaweza kukuunganisha na otomatiki hii. Imeandikwa katika Python, ambayo ni jambo zuri.
Mimi niko kidogo tu kutoka kwa ulimwengu wa MySQL, kwa hivyo nilikuja kusikiliza. Na tunatumia njia hii.
Lakini ni ikiwa tu tuna 90%. Ikiwa tuna 5%, basi si nzuri sana kuitumia.
Asante kwa ripoti! Ikiwa hakuna nyenzo za kutengeneza nakala kamili ya prod, je, kuna algoriti au fomula ya kukokotoa mzigo au ukubwa?
Swali zuri. Kufikia sasa, tunaweza kupata hifadhidata za terabyte nyingi. Hata kama vifaa havifanani, kwa mfano, kumbukumbu ndogo, processor kidogo na diski hazifanani kabisa, lakini bado tunafanya hivyo. Ikiwa hakuna mahali popote, basi unahitaji kufikiria. Wacha nifikirie hadi kesho, ulikuja, tutazungumza, swali zuri.
Asante kwa ripoti! Ulianza kwanza juu ya ukweli kwamba kuna Postgres ya baridi, ambayo ina vikwazo vile na vile, lakini inaendelea. Na hii yote ni mkongojo kwa ujumla. Je, haya yote hayapingani na maendeleo ya Postgres yenyewe, ambayo baadhi ya deferent ya DELETE itaonekana au kitu kingine ambacho kinapaswa kuweka katika kiwango cha chini kile tunachojaribu kupaka na baadhi ya njia zetu za ajabu hapa?
Ikiwa tulisema katika SQL kufuta au kusasisha rekodi nyingi katika shughuli moja, basi Postgres inawezaje kuzisambaza huko? Sisi ni mdogo kimwili katika shughuli. Bado tutafanya kwa muda mrefu. Na tutafunga wakati huu, nk.
Imemaliza kwa faharasa.
Ninaweza kudhani kuwa urekebishaji sawa wa ukaguzi unaweza kuwa wa kiotomatiki. Siku moja inaweza kuwa. Lakini basi sielewi swali kabisa.
Swali ni je, kuna vekta ya maendeleo kama hii ambayo huenda hapa na pale, na hapa yako inaenda sambamba? Wale. Bado hawajafikiria juu yake?
Nilizungumza juu ya kanuni ambazo zinaweza kutumika sasa. Kuna bot nyingine , na hii unaweza kufanya marekebisho ya kiotomatiki ya ukaguzi. Je, siku moja itakuwa katika Postgres? Sijui, hata haijajadiliwa bado. Bado tuko mbali na hilo. Lakini kuna wanasayansi wanaotengeneza mifumo mipya. Na wanatusukuma kwenye faharisi za kiotomatiki. Kuna maendeleo. Kwa mfano, unaweza kuangalia tuning auto. Inachagua vigezo moja kwa moja. Lakini hatakufanyia mipangilio ya ukaguzi. Hiyo ni, itachukua kwa utendaji, buffer ya ganda, nk.
Na kwa urekebishaji wa ukaguzi, unaweza kufanya hivi: ikiwa una nguzo elfu na vifaa tofauti, mashine tofauti za wingu, unaweza kutumia bot yetu. kufanya automatisering. Na max_wal_size itachaguliwa moja kwa moja kulingana na mipangilio unayolenga. Lakini hadi sasa hii sio karibu hata katika msingi, kwa bahati mbaya.
Habari za mchana Ulizungumza juu ya hatari ya shughuli za muda mrefu. Ulisema kuwa otomatiki imezuiwa ikiwa kuna ufutaji. Je, inatudhuru vipi tena? Kwa sababu tunazungumza zaidi juu ya kufungia nafasi na kuweza kuitumia. Nini kingine tunakosa?
Autovacuum labda sio shida kubwa hapa. Na ukweli kwamba shughuli ndefu inaweza kufunga shughuli nyingine, uwezekano huu ni hatari zaidi. Anaweza kukutana au asipate. Ikiwa alikutana, basi inaweza kuwa mbaya sana. Na kwa autovacuum - hii pia ni tatizo. Kuna matatizo mawili na shughuli za muda mrefu katika OLTP: kufuli na otomatiki. Na ikiwa una maoni ya moto ya kusubiri yaliyowezeshwa kwenye replica, basi bado utapokea kufuli kiotomatiki kwa bwana, itafika kutoka kwa nakala. Lakini angalau hakutakuwa na kufuli. Na kutakuwa na loks. Tunazungumza juu ya mabadiliko ya data, kwa hivyo kufuli ni jambo muhimu hapa. Na ikiwa hii yote ni kwa muda mrefu, kwa muda mrefu, basi shughuli zaidi na zaidi zimefungwa. Wanaweza kuiba wengine. Na miti inaonekana. Nilitoa kiunga cha kijisehemu. Na tatizo hili linaonekana kwa kasi zaidi kuliko tatizo la autovacuum, ambayo inaweza tu kujilimbikiza.
Asante kwa ripoti! Ulianza ripoti yako kwa kusema kuwa ulijaribu vibaya. Tuliendelea na wazo letu kwamba tunahitaji kuchukua vifaa sawa, na msingi kwa njia ile ile. Wacha tuseme tulimpa msanidi msingi msingi. Na alikubali ombi hilo. Na anaonekana kuwa sawa. Lakini yeye hana kuangalia kwa kuishi, lakini kwa kuishi, kwa mfano, tuna mzigo wa 60-70%. Na hata tukitumia urekebishaji huu, haifanyi kazi vizuri.
Kuwa na mtaalam kwenye timu na kutumia wataalam wa DBA ambao wanaweza kutabiri kitakachotokea kwa mzigo halisi wa usuli ni muhimu. Wakati tuliendesha mabadiliko yetu safi, tunaona picha. Lakini mbinu ya juu zaidi, tulipofanya jambo lile lile tena, lakini kwa mzigo ulioigwa na uzalishaji. Ni poa kabisa. Hadi wakati huo, unapaswa kukua. Ni kama mtu mzima. Tuliangalia tu tulichonacho na pia kuangalia kama tuna rasilimali za kutosha. Hilo ni swali zuri.
Wakati tayari tunafanya takataka kuchagua na tuna, kwa mfano, bendera iliyofutwa
Hivi ndivyo otomatiki hufanya kiotomatiki kwenye Postgres.
Oh, je, yeye kufanya hivyo?
Autovacuum ni mtoza takataka.
Asante!
Asante kwa ripoti! Kuna chaguo la kuunda hifadhidata mara moja na kizigeu kwa njia ambayo takataka zote zinakuwa chafu kutoka kwa meza kuu mahali pengine hadi kando?
Bila shaka kuwa.
Je, inawezekana basi kujilinda ikiwa tumefunga meza ambayo haifai kutumika?
Bila shaka kuwa. Lakini ni kama swali la kuku na yai. Ikiwa sisi sote tunajua nini kitatokea katika siku zijazo, basi, bila shaka, tutafanya kila kitu kizuri. Lakini biashara inabadilika, kuna safu mpya, maombi mapya. Na kisha - lo, tunataka kuiondoa. Lakini hali hii bora, katika maisha hutokea, lakini si mara zote. Lakini kwa ujumla ni wazo nzuri. Punguza tu na ndivyo hivyo.
Chanzo: mapenzi.com