Yaqin kelajakda keraksiz ma'lumotlarni avtomatik ravishda olib tashlash ma'lumotlar bazasining muhim vazifalaridan biri bo'ladi [1]. Ayni paytda, biz o'zimiz keraksiz ma'lumotlarni o'chirish yoki arzonroq saqlash tizimlariga ko'chirish haqida g'amxo'rlik qilishimiz kerak. Aytaylik, siz bir necha million qatorni o'chirishga qaror qildingiz. Juda oddiy vazifa, ayniqsa shart ma'lum bo'lsa va tegishli indeks mavjud bo'lsa. "1-jadvaldan o'chirish WHERE col1 = :value" - nima oddiyroq bo'lishi mumkin, to'g'rimi?
Video:
-
Men Highload dasturi qo'mitasida birinchi yildan beri, ya'ni 2007 yildan beri ishlayman.
-
Va men 2005 yildan beri Postgres bilan ishlayman. U ko'plab loyihalarda qo'llanilgan.
-
2007 yildan beri RuPostges bilan guruh.
-
Meetupda biz 2100+ ishtirokchiga yetdik. U Nyu-Yorkdan keyin dunyoda ikkinchi o'rinda turadi, uzoq vaqt davomida San-Frantsiskoni ortda qoldirdi.
-
Men Kaliforniyada bir necha yil yashayman. Men Amerika kompaniyalari, jumladan, yirik kompaniyalar bilan ko'proq ishlayman. Ular Postgres-ning faol foydalanuvchilari. Va har xil qiziqarli narsalar mavjud.
mening kompaniyam. Biz rivojlanishning sekinlashuvini bartaraf etadigan vazifalarni avtomatlashtirish bilan shug'ullanamiz.
Agar biror narsa qilayotgan bo'lsangiz, ba'zida Postgres atrofida qandaydir vilkalar mavjud. Aytaylik, administrator siz uchun test stendini o'rnatishini kutishingiz kerak yoki DBA sizga javob berishini kutishingiz kerak. Va biz ishlab chiqish, sinovdan o'tkazish va boshqarish jarayonida bunday to'siqlarni topamiz va ularni avtomatlashtirish va yangi yondashuvlar yordamida bartaraf etishga harakat qilamiz.
Men yaqinda Los-Anjelesdagi VLDBda edim. Bu ma'lumotlar bazalari bo'yicha eng yirik konferentsiya. Kelajakda DBMS nafaqat ma'lumotlarni saqlaydi, balki avtomatik ravishda o'chiradi, degan xabar bor edi. Bu yangi mavzu.
Zettabaytlar dunyosida ma'lumotlar tobora ko'payib bormoqda - bu 1 000 000 petabayt. Va hozirda bizda dunyoda 100 zettabaytdan ortiq ma'lumotlar saqlanganligi taxmin qilinmoqda. Va ularning soni ko'payib bormoqda.
Va u bilan nima qilish kerak? Shubhasiz, uni olib tashlash kerak. Mana ushbu qiziqarli hisobotga havola. Lekin hozirgacha bu DBMSda amalga oshirilmagan.
Pulni hisoblay oladiganlar ikkita narsani xohlashadi. Ular bizni o'chirishimizni xohlashadi, shuning uchun texnik jihatdan biz buni qila olishimiz kerak.
Men bundan keyin aytmoqchi bo'lgan narsa - bu bir qancha real vaziyatlarni o'z ichiga olgan mavhum vaziyat, ya'ni men va atrofdagi ma'lumotlar bazalari bilan ko'p marta, ko'p yillar davomida sodir bo'lgan voqealarning bir turi. Rakes hamma joyda va hamma ularga doimo qadam qo'yadi.
Aytaylik, bizda baza yoki bir nechta bazalar o'sib bormoqda. Va ba'zi yozuvlar shubhasiz axlatdir. Misol uchun, foydalanuvchi u erda biror narsa qilishni boshladi, lekin uni tugatmadi. Va bir muncha vaqt o'tgach, biz bu tugallanmagan narsalarni endi saqlab bo'lmasligini bilamiz. Ya'ni, biz joyni tejash, ish faoliyatini yaxshilash va hokazolar uchun ba'zi axlatlarni tozalashni xohlaymiz.
Umuman olganda, vazifa muayyan narsalarni, ba'zi jadvaldagi aniq qatorlarni o'chirishni avtomatlashtirishdir.
Va bizda bunday iltimos bor, biz bugun gaplashamiz, ya'ni axlatni olib tashlash haqida.
Tajribali ishlab chiquvchidan buni qilishni so'radik. U bu so'rovni oldi, o'zi tekshirdi - hamma narsa ishlaydi. Sahnalashtirishda sinovdan o'tgan - hammasi yaxshi. Chiqarilgan - hamma narsa ishlaydi. Kuniga bir marta biz uni ishga tushiramiz - hamma narsa yaxshi.
Ma'lumotlar bazasi o'sib boradi va o'sadi. Kundalik DELETE biroz sekinroq ishlay boshlaydi.
Keyin biz endi marketing kompaniyamiz borligini tushunamiz va trafik bir necha barobar ko'payadi, shuning uchun biz keraksiz narsalarni vaqtincha to'xtatishga qaror qilamiz. Va qaytishni unutmang.
Bir necha oy o'tgach, ular eslashdi. Va o'sha ishlab chiquvchi ishdan ketdi yoki boshqa narsa bilan band bo'lib, boshqasiga uni qaytarishni buyurdi.
U ishlab chiqarishni, sahnalashtirishni tekshirdi - hammasi joyida. Tabiiyki, siz hali ham to'plangan narsalarni tozalashingiz kerak. U hamma narsa ishlayotganini tekshirdi.
Keyin nima bo'ladi? Keyin biz uchun hamma narsa buziladi. U shunday tushadiki, bir nuqtada hamma narsa pastga tushadi. Hamma shokda, nima bo'layotganini hech kim tushunmaydi. Va keyin ma'lum bo'ldiki, masala shu DELETEda edi.
Nimadir noto'g'ri bajarildi? Bu erda noto'g'ri bo'lishi mumkin bo'lgan narsalar ro'yxati. Bulardan qaysi biri eng muhim?
-
Misol uchun, hech qanday ko'rib chiqish yo'q edi, ya'ni DBA mutaxassisi unga qaramadi. U tajribali ko'z bilan muammoni darhol topardi va bundan tashqari, u bir necha million qatorlar to'plangan mahsulotga kirish huquqiga ega.
-
Ehtimol, ular noto'g'ri narsani tekshirgandirlar.
-
Ehtimol, uskuna eskirgan va siz ushbu bazani yangilashingiz kerak.
-
Yoki ma'lumotlar bazasida biror narsa noto'g'ri va biz Postgres-dan MySQL-ga o'tishimiz kerak.
-
Yoki operatsiyada biror narsa noto'g'ri bo'lishi mumkin.
-
Ehtimol, ishni tashkil etishda xatolar bor va siz kimnidir ishdan bo'shatib, eng yaxshi odamlarni ishga olishingiz kerakmi?
DBA tekshiruvi yo'q edi. Agar DBA bo'lsa, u bu bir necha million satrlarni ko'rar edi va hatto hech qanday tajribalarsiz: "Ular buni qilmaydi" deb aytadi. Aytaylik, agar ushbu kod GitLab, GitHub-da bo'lsa va kodni ko'rib chiqish jarayoni bo'lsa va DBA roziligisiz ushbu operatsiya mahsulotda amalga oshirilmasa, DBA: "Buni amalga oshirib bo'lmaydi. ”
Va u sizda diskdagi IO bilan muammolarga duch kelishingizni va barcha jarayonlar aqldan ozishini, qulflar bo'lishi mumkinligini, shuningdek, siz bir necha daqiqaga avtovakuumni blokirovka qilasiz, shuning uchun bu yaxshi emas.
Ikkinchi xato - ular noto'g'ri joyda tekshirishdi. Biz mahsulotda juda ko'p keraksiz ma'lumotlar to'planganini ko'rdik, ammo ishlab chiquvchida ushbu ma'lumotlar bazasida ma'lumotlar to'planmagan va sahnalash paytida hech kim bu keraksiz narsalarni yaratmagan. Shunga ko'ra, tezda ishlab chiqilgan 1 ta chiziq bor edi.
Bizning testlarimiz zaif ekanligini tushunamiz, ya'ni qurilgan jarayon muammolarga duch kelmaydi. Adekvat JB tajribasi o'tkazilmadi.
Ideal tajriba bir xil uskunada o'tkaziladi. Buni bir xil uskunada qilish har doim ham mumkin emas, lekin bu ma'lumotlar bazasining to'liq o'lchamli nusxasi bo'lishi juda muhimdir. Mana, men bir necha yillardan beri va'z qilib kelayotgan narsam. Va bir yil oldin men bu haqda gapirgan edim, barchasini YouTube'da ko'rishingiz mumkin.
Balki jihozlarimiz yomondir? Agar qarasangiz, kechikish sakrab chiqdi. Foydalanish 100% ekanligini ko'rdik. Albatta, agar bu zamonaviy NVMe drayverlari bo'lsa, ehtimol bu biz uchun ancha oson bo'lar edi. Va, ehtimol, biz undan voz kechmasdik.
Agar sizda bulutlar bo'lsa, u erda yangilanish osongina amalga oshiriladi. Yangi uskunada yangi nusxalar ko'tarildi. o'tish. Va hammasi yaxshi. Juda oson.
Kichikroq disklarga qandaydir tarzda tegish mumkinmi? Va bu erda, faqat DBA yordamida, biz nazorat nuqtasini sozlash deb nomlangan ma'lum bir mavzuga sho'ng'iymiz. Ma'lum bo'lishicha, bizda nazorat punktini sozlash yo'q edi.
Tekshirish punkti nima? U har qanday DBMSda mavjud. Xotirada o'zgaruvchan ma'lumotlar mavjud bo'lganda, ular darhol diskka yozilmaydi. Ma'lumotlar o'zgarganligi to'g'risidagi ma'lumotlar birinchi navbatda oldindan yozish jurnaliga yoziladi. Va ma'lum bir nuqtada, DBMS haqiqiy sahifalarni diskka tashlash vaqti keldi, deb qaror qiladi, shunda bizda xatolik bo'lsa, biz kamroq REDO qilishimiz mumkin. Bu o'yinchoqqa o'xshaydi. Agar biz o'ldirilgan bo'lsak, biz o'yinni oxirgi nazorat nuqtasidan boshlaymiz. Va barcha DBMS uni amalga oshiradi.
Postgres-dagi sozlamalar orqada qolmoqda. Ular 10-15 yillik ma'lumotlar va tranzaktsiyalar hajmi uchun mo'ljallangan. Va nazorat punkti ham bundan mustasno emas.
Mana bizning Postgres tekshiruvi hisobotimizdan ma'lumot, ya'ni avtomatik sog'liqni tekshirish. Va bu erda bir necha terabaytlardan iborat ma'lumotlar bazasi. Va shuni yaxshi ko'rish mumkinki, deyarli 90% hollarda majburiy nazorat punktlari.
Bu nima degani? U erda ikkita sozlamalar mavjud. Tekshirish punkti vaqt tugashi bilan kelishi mumkin, masalan, 10 daqiqada. Yoki juda ko'p ma'lumotlar to'ldirilganda paydo bo'lishi mumkin.
Va sukut bo'yicha max_wal_saze 1 gigabaytga o'rnatiladi. Aslida, bu Postgres-da 300-400 megabaytdan keyin sodir bo'ladi. Siz juda ko'p ma'lumotlarni o'zgartirdingiz va sizning nazorat punktingiz sodir bo'ladi.
Va agar hech kim uni sozlamasa va xizmat o'sgan bo'lsa va kompaniya juda ko'p pul topsa, u juda ko'p tranzaktsiyalarga ega bo'lsa, nazorat punkti daqiqada bir marta, ba'zan har 30 soniyada keladi va ba'zan hatto bir-biriga mos keladi. Bu juda yomon.
Va biz uning kamroq kelishiga ishonch hosil qilishimiz kerak. Ya'ni, biz max_wal_size ni oshirishimiz mumkin. Va u kamroq keladi.
Ammo biz buni qanday qilib to'g'riroq qilish, ya'ni aniq ma'lumotlarga asoslanib, sozlamalarni tanlash to'g'risida qaror qabul qilish bo'yicha butun metodologiyani ishlab chiqdik.
Shunga ko'ra, biz ma'lumotlar bazalarida ikkita eksperiment o'tkazmoqdamiz.
Birinchi seriya - biz max_wal_size ni o'zgartiramiz. Va biz katta operatsiya qilamiz. Birinchidan, biz buni 1 gigabaytning standart sozlamalarida qilamiz. Va biz ko'p millionlab qatorlarni katta DELETE qilamiz.
Bu biz uchun qanchalik qiyinligini ko'rasiz. Biz disk IO juda yomon ekanligini ko'ramiz. Biz qancha WAL yaratganimizni ko'rib chiqamiz, chunki bu juda muhim. Keling, nazorat punkti necha marta sodir bo'lganini ko'rib chiqaylik. Va biz bu yaxshi emasligini ko'ramiz.
Keyin biz max_wal_size ni oshiramiz. Biz takrorlaymiz. Biz ko'paytiramiz, takrorlaymiz. Va ko'p marta. Asos sifatida, 10 ball yaxshi, bu erda 1, 2, 4, 8 gigabayt. Va biz ma'lum bir tizimning xatti-harakatlariga qaraymiz. Bu erda uskunalar mahsulotdagi kabi bo'lishi kerakligi aniq. Sizda bir xil disklar, bir xil hajmdagi xotira va bir xil Postgres sozlamalari bo'lishi kerak.
Va shu tarzda biz tizimimizni almashamiz va ommaviy DELETE yomon bo'lsa, DBMS qanday harakat qilishini, qanday nazorat nuqtasini o'tkazishini bilamiz.
Rus tilida nazorat punkti - bu nazorat punktlari.
Misol: Indeks bo'yicha bir necha million qatorlarni O'CHIRING, qatorlar sahifalar bo'ylab "tarqalgan".
Mana bir misol. Bu qandaydir asos. Va max_wal_size uchun 1 gigabayt standart sozlamalari bilan bizning disklarimiz yozib olish uchun javonga borishi juda aniq. Bu rasm juda kasal bemorning odatiy alomatidir, ya'ni u haqiqatan ham o'zini yomon his qildi. Va bitta operatsiya bor edi, faqat bir necha million satrdan DELETE bor edi.
Agar ishlab chiqarishda bunday operatsiyaga ruxsat berilsa, biz shunchaki yotib qolamiz, chunki bizni polkda bitta DELETE o'ldirishi aniq.
Bundan tashqari, 16 gigabayt bo'lsa, tishlar allaqachon ketganligi aniq. Tishlar allaqachon yaxshiroq, ya'ni biz shiftni taqillatamiz, lekin unchalik yomon emas. U yerda qandaydir erkinlik bor edi. O'ng tomonda yozuv mavjud. Va operatsiyalar soni - ikkinchi grafik. Va biz allaqachon 16 gigabayt bo'lganda biroz osonroq nafas olayotganimiz aniq.
Va bu erda 64 gigabayt butunlay yaxshilanganligini ko'rish mumkin. Tishlar allaqachon talaffuz qilingan, boshqa operatsiyalardan omon qolish va disk bilan biror narsa qilish uchun ko'proq imkoniyatlar mavjud.
Nega bunday?
Men tafsilotlarga biroz sho'ng'ib ketaman, lekin bu mavzu, nazorat punktini qanday sozlash bo'lsa, butun hisobotga olib kelishi mumkin, shuning uchun men ko'p yuklamayman, lekin qanday qiyinchiliklar borligini bir oz aytib beraman.
Agar nazorat punkti juda tez-tez sodir bo'lsa va biz satrlarimizni ketma-ket emas, balki indeks bo'yicha topamiz, bu yaxshi, chunki biz butun jadvalni o'chirmaymiz, unda dastlab birinchi sahifaga, keyin minginchi sahifaga tegib ketganimiz bo'lishi mumkin. va keyin birinchisiga qaytdi. Va agar birinchi sahifaga tashrif buyurishlar orasida nazorat punkti allaqachon diskda saqlangan bo'lsa, u yana saqlaydi, chunki biz uni ikkinchi marta iflos qildik.
Va biz nazorat punktini ko'p marta saqlashga majbur qilamiz. Qanday qilib u uchun ortiqcha operatsiyalar bo'lar edi.
Lekin bu hammasi emas. Postgresda sahifalar 8 kilobayt va Linuxda 4 kilobayt. Va full_page_writes sozlamasi mavjud. U sukut bo'yicha yoqilgan. Va bu to'g'ri, chunki agar biz uni o'chirib qo'ysak, sahifaning atigi yarmi qulab tushsa, saqlanib qolishi xavfi mavjud.
Oldinga o'tish jurnalining WAL-ga yozish harakati shundayki, bizda tekshirish punkti bo'lganida va biz sahifani birinchi marta o'zgartirganimizda, biz faqat o'zgartirgan bo'lsak ham, butun sahifa, ya'ni barcha 8 kilobayt oldinga siljish jurnaliga kiradi. 100 bayt og'irlikdagi chiziq. Va biz butun sahifani yozishimiz kerak.
Keyingi o'zgarishlarda faqat ma'lum bir tuple bo'ladi, lekin birinchi marta biz hamma narsani yozamiz.
Va shunga ko'ra, agar nazorat punkti yana sodir bo'lgan bo'lsa, biz hamma narsani noldan boshlashimiz va butun sahifani bosishimiz kerak. Tez-tez tekshiruv nuqtalari bilan, biz bir xil sahifalar bo'ylab yurganimizda, full_page_writes = on mumkin bo'lganidan ko'proq bo'ladi, ya'ni biz ko'proq WAL hosil qilamiz. Ko'proq nusxalar, arxivga, diskka yuboriladi.
Va shunga ko'ra, bizda ikkita ortiqcha ish bor.
Agar biz max_wal_size ni ko'paytirsak, biz buni nazorat nuqtasi uchun ham, wal writer uchun ham osonlashtiramiz. Va bu ajoyib.
Keling, terabaytni qo'yib, u bilan yashaylik. Buning nimasi yomon? Bu yomon, chunki agar muvaffaqiyatsiz bo'lsa, biz soatlab ko'tarilamiz, chunki nazorat punkti uzoq vaqt oldin bo'lgan va ko'p narsa allaqachon o'zgargan. Va bularning barchasini REDO qilishimiz kerak. Shunday qilib, biz tajribalarning ikkinchi seriyasini qilamiz.
Biz operatsiya qilamiz va nazorat punkti qachon tugashini ko'ramiz, biz ataylab -9 Postgresni o'ldiramiz.
Va shundan so'ng biz uni yana boshlaymiz va bu uskunada qancha vaqt ko'tarilishini, ya'ni bu yomon vaziyatda qancha REDO qilishini ko'ramiz.
Vaziyat yomon ekanligini ikki marta qayd etaman. Birinchidan, biz nazorat punkti tugashidan oldin halokatga uchradik, shuning uchun yo'qotishimiz juda ko'p. Ikkinchidan, biz katta operatsiya qildik. Va agar nazorat punktlari taym-out vaqtida bo'lsa, oxirgi nazorat punktidan beri WAL kamroq hosil bo'lar edi. Ya'ni, bu ikki marta mag'lub bo'ladi.
Biz bunday vaziyatni turli xil max_wal_size o'lchamlari uchun o'lchaymiz va agar max_wal_size 64 gigabayt bo'lsa, ikki baravar yomon holatda biz 10 daqiqaga ko'tarilishimizni tushunamiz. Va bu bizga mos keladimi yoki yo'qmi deb o'ylaymiz. Bu biznes savol. Biz ushbu rasmni biznes qarorlari uchun mas'ul bo'lganlarga ko'rsatishimiz va so'rashimiz kerak: “Muammo bo'lgan taqdirda biz qancha vaqt yotishimiz mumkin? Eng yomon holatda 3-5 daqiqa yotishimiz mumkinmi? Va siz qaror qabul qilasiz.
Va bu erda qiziq bir nuqta bor. Konferensiyada Patroniy haqida bir-ikkita ma’ruzalarimiz bor. Va ehtimol siz undan foydalanasiz. Bu Postgres uchun avtomatik uzilish. Bu haqda GitLab va Data Egret gaplashdi.
Va agar sizda 30 soniyadan so'ng keladigan avtohalokat mavjud bo'lsa, unda biz 10 daqiqa yotishimiz mumkinmi? Chunki biz shu paytgacha replikaga o'tamiz va hammasi yaxshi bo'ladi. Bu munozarali nuqta. Men aniq javobni bilmayman. Men shunchaki bu mavzu nafaqat halokatni tiklash haqida emasligini his qilaman.
Muvaffaqiyatsizlikdan keyin uzoq vaqt tiklanishimiz bo'lsa, unda biz boshqa ko'plab vaziyatlarda noqulay bo'lamiz. Misol uchun, xuddi shu tajribalarda, biz biror narsa qilsak va ba'zida 10 daqiqa kutishimiz kerak.
Men hali ham uzoqqa bormagan bo'lardim, hatto bizda avtomatik uzilish bo'lsa ham. Qoida tariqasida, 64, 100 gigabayt kabi qiymatlar yaxshi qiymatlardir. Ba'zan hatto kamroq tanlashga arziydi. Umuman olganda, bu nozik fan.
Takrorlashlarni amalga oshirish uchun, masalan, max_wal_size =1, 8, siz ommaviy operatsiyani ko'p marta takrorlashingiz kerak. Siz erishdingiz. Va xuddi shu asosda siz buni yana qilishni xohlaysiz, lekin siz allaqachon hamma narsani o'chirib tashlagansiz. Nima qilish kerak?
Men yechimimiz, bunday vaziyatlarda takrorlash uchun nima qilishimiz haqida keyinroq gaplashaman. Va bu eng to'g'ri yondashuv.
Ammo bu holatda bizga omad kulib boqdi. Agar, bu yerda yozilganidek, “BOSHLASH, OʻCHIRISH, ORTAGA OLISH” boʻlsa, biz oʻchirishni takrorlashimiz mumkin. Ya'ni, agar biz buni o'zimiz bekor qilgan bo'lsak, uni takrorlashimiz mumkin. Va jismonan sizga ma'lumotlar bir joyda yotadi. Siz hatto shishib ketmaysiz. Siz bunday DELETElarni takrorlashingiz mumkin.
Ushbu ROLLBACK bilan DELETE, agar sizda to'g'ri o'rnatilgan ma'lumotlar bazasi laboratoriyalari bo'lmasa ham, nazorat nuqtasini sozlash uchun juda mos keladi.
Biz bitta ustunli "i" bilan plastinka yasadik. Postgres-da yordamchi ustunlar mavjud. Agar maxsus so'ralmasa, ular ko'rinmaydi. Bular: ctid, xmid, xmax.
Ctid - bu jismoniy manzil. Nol sahifa, sahifadagi birinchi kortej.
Ko'rinib turibdiki, ROOLBACKdan keyin kortej o'sha joyda qolgan. Ya'ni, biz yana urinib ko'rishimiz mumkin, u xuddi shunday yo'l tutadi. Bu asosiy narsa.
Xmax - kortejning o'lim vaqti. Bu muhrlangan edi, lekin Postgres tranzaksiya orqaga qaytarilganligini biladi, shuning uchun uning 0 bo'lishi yoki qaytarilgan tranzaksiya ekanligi muhim emas. Bu shuni ko'rsatadiki, DELETE ustidan takrorlash va tizim xatti-harakatlarining ommaviy operatsiyalarini tekshirish mumkin. Kambag'allar uchun ma'lumotlar bazasi laboratoriyalarini yaratishingiz mumkin.
Bu dasturchilar haqida. DBA haqida ham ular har doim dasturchilarni buning uchun tanqid qilishadi: "Nega bunday uzoq va qiyin operatsiyalarni qilyapsiz?". Bu butunlay boshqa perpendikulyar mavzu. Ilgari ma’muriyat bo‘lgan, endi esa rivojlanish bo‘ladi.
Shubhasiz, biz bo'laklarga bo'linmadik. Bu tushunarli. Bunday DELETEni millionlab satrlarni qismlarga ajratmaslik mumkin emas. Bu 20 daqiqa davomida amalga oshiriladi va hamma narsa yotadi. Ammo, afsuski, hatto tajribali ishlab chiquvchilar ham juda katta kompaniyalarda xato qilishadi.
Nima uchun sindirish muhim?
-
Agar disk qattiq ekanligini ko'rsak, uni sekinlashtiramiz. Va agar biz buzilgan bo'lsak, biz pauza qo'shishimiz mumkin, biz drosselni sekinlashtirishimiz mumkin.
-
Va biz boshqalarni uzoq vaqt davomida bloklamaymiz. Ba'zi hollarda, bu muhim emas, agar siz hech kim ishlamayotgan haqiqiy axlatni o'chirsangiz, unda siz avtovakuum ishidan tashqari hech kimni bloklamaysiz, chunki u tranzaksiya tugashini kutadi. Ammo agar siz kimdir so'rashi mumkin bo'lgan narsani olib tashlasangiz, ular bloklanadi, qandaydir zanjir reaktsiyasi bo'ladi. Veb-saytlar va mobil ilovalarda uzoq muddatli tranzaktsiyalardan qochish kerak.
Bu qiziq. Ko'pincha ishlab chiquvchilar: "Qaysi paket hajmini tanlashim kerak?" Deb so'rashini ko'raman.
Ko'rinib turibdiki, to'plam hajmi qanchalik katta bo'lsa, tranzaksiyalarning umumiy xarajatlari, ya'ni tranzaktsiyalardan olinadigan qo'shimcha xarajatlar shunchalik kichik bo'ladi. Ammo shu bilan birga, ushbu tranzaksiya uchun vaqt ko'payadi.
Menda juda oddiy qoida bor: iloji boricha ko'proq oling, lekin soniyada bajariladigan fayllarni ko'paytirmang.
Nega bir soniya? Tushuntirish juda oddiy va hamma uchun, hatto texnik bo'lmagan odamlar uchun ham tushunarli. Biz reaktsiyani ko'ramiz. Keling, 50 millisekundni olaylik. Agar biror narsa o'zgargan bo'lsa, unda bizning ko'zimiz reaksiyaga kirishadi. Agar kamroq bo'lsa, unda qiyinroq. Agar biror narsa 100 millisekunddan keyin javob bersa, masalan, siz sichqonchani bosgan bo'lsangiz va u sizga 100 millisekunddan keyin javob bergan bo'lsa, siz allaqachon bu biroz kechikishni his qilasiz. Bir soniya allaqachon tormoz sifatida qabul qilinadi.
Shunga ko'ra, agar biz ommaviy operatsiyalarimizni 10 soniyalik portlashlarga ajratsak, unda biz kimnidir to'sib qo'yish xavfimiz bor. Va u bir necha soniya ishlaydi va odamlar buni allaqachon sezadilar. Shuning uchun, men bir soniyadan ko'proq narsani qilmaslikni afzal ko'raman. Ammo shu bilan birga, uni juda nozik tarzda buzmang, chunki tranzaksiya xarajatlari sezilarli bo'ladi. Baza qattiqroq bo'ladi va boshqa turli muammolar paydo bo'lishi mumkin.
Biz paketning o'lchamini tanlaymiz. Har bir holatda biz buni boshqacha qilishimiz mumkin. Avtomatlashtirish mumkin. Va biz bitta paketni qayta ishlash samaradorligiga aminmiz. Ya'ni, biz bitta to'plamni O'CHIRISH yoki YANGILASH qilamiz.
Aytgancha, men aytayotgan hamma narsa faqat DELETE haqida emas. Siz taxmin qilganingizdek, bu ma'lumotlar bo'yicha har qanday ommaviy operatsiyalar.
Va reja juda zo'r ekanligini ko'ramiz. Siz indeksni skanerlashni ko'rishingiz mumkin, faqat indeksni skanerlash yanada yaxshi. Va bizda oz miqdordagi ma'lumotlar mavjud. Va bir soniyadan kamroq vaqt bajariladi. Super.
Va biz hali ham degradatsiya yo'qligiga ishonch hosil qilishimiz kerak. Shunday bo'ladiki, birinchi paketlar tezda ishlaydi, keyin esa yomonlashadi, yomonlashadi va yomonlashadi. Jarayon shundayki, siz ko'p sinovdan o'tishingiz kerak. Ma'lumotlar bazasi laboratoriyalari aynan shu maqsadda.
Va biz hali ham ishlab chiqarishda buni to'g'ri bajarishimizga imkon beradigan biror narsa tayyorlashimiz kerak. Masalan, jurnalga vaqtni yozishimiz mumkin, biz hozir qayerda ekanligimizni va hozir kimni o'chirib tashlaganimizni yozishimiz mumkin. Va bu bizga keyinroq nima bo'layotganini tushunishga imkon beradi. Va agar biror narsa noto'g'ri bo'lsa, tezda muammoni toping.
Agar so'rovlarning samaradorligini tekshirishimiz kerak bo'lsa va biz ko'p marta takrorlashimiz kerak bo'lsa, unda boshqa bot kabi narsa bor. U allaqachon tayyor. U har kuni o'nlab ishlab chiquvchilar tomonidan qo'llaniladi. Va u 30 soniya ichida so'rov bo'yicha katta terabayt ma'lumotlar bazasini, o'zingizning nusxangizni qanday berishni biladi. Va u erda biror narsani o'chirishingiz va RESET deb aytishingiz va yana o'chirishingiz mumkin. Siz u bilan shu tarzda tajriba qilishingiz mumkin. Men bu narsaning kelajagini ko'raman. Va biz buni allaqachon qilyapmiz.
Bo'linish strategiyalari nima? Men paketdagi ishlab chiquvchilar foydalanadigan 3 xil bo'linish strategiyasini ko'rmoqdaman.
Birinchisi juda oddiy. Bizda raqamli identifikator mavjud. Keling, uni turli intervallarga ajratamiz va u bilan ishlaymiz. Salbiy tomoni aniq. Birinchi segmentda bizda 100 qator haqiqiy axlat bo'lishi mumkin, ikkinchi 5 qatorda yoki umuman bo'lmasligi mumkin yoki barcha 1 qator axlatga aylanadi. Juda notekis ish, lekin uni buzish oson. Ular maksimal identifikatorni olib, uni sindirishdi. Bu sodda yondashuv.
Ikkinchi strategiya - muvozanatli yondashuv. U Gitlab-da qo'llaniladi. Ular stolni olib, skanerlashdi. Biz ID paketlarining chegaralarini topdik, shunda har bir paketda 10 000 ta yozuv bor edi. Va ularni navbatga qo'ying. Va keyin biz qayta ishlaymiz. Buni bir nechta mavzularda qilishingiz mumkin.
Birinchi strategiyada ham, aytmoqchi, buni bir nechta mavzularda qilishingiz mumkin. Bu qiyin emas.
Ammo sovuqroq va yaxshiroq yondashuv mavjud. Bu uchinchi strategiya. Va iloji bo'lsa, uni tanlash yaxshidir. Biz buni maxsus indeks asosida qilamiz. Bunday holda, bu bizning axlat holatimiz va identifikatorimiz bo'yicha indeks bo'lishi mumkin. Biz identifikatorni qo'shamiz, shunda u faqat indeksni skanerlashi bo'ladi, shunda biz to'plamga bormaymiz.
Odatda, faqat indekslarni skanerlash indekslarni skanerlashdan tezroq.
Va biz tezda o'chirmoqchi bo'lgan identifikatorlarimizni topamiz. BATCH_SIZE biz oldindan tanlaymiz. Va biz ularni nafaqat olamiz, balki ularni maxsus tarzda olamiz va darhol ularni buzamiz. Ammo biz qulflaymiz, agar ular allaqachon qulflangan bo'lsa, biz ularni qulflamaymiz, balki davom etamiz va keyingilarini olamiz. Bu yangilanishni o'tkazib yuborish uchun bloklangan. Postgres-ning ushbu super xususiyati, agar xohlasak, bizga bir nechta mavzularda ishlashga imkon beradi. Bu bitta oqimda mumkin. Va bu erda CTE bor - bu bitta so'rov. Va bizda ushbu CTE ning ikkinchi qavatida haqiqiy o'chirish sodir bo'lmoqda - returning *. Siz identifikatorni qaytarishingiz mumkin, lekin bu yaxshiroq *har bir satrda ko'p ma'lumotlarga ega bo'lmasangiz.
Nega bizga kerak? Bu biz hisobot berishimiz kerak bo'lgan narsadir. Biz hozir juda ko'p qatorlarni o'chirib tashladik. Va bizda ID yoki created_at bo'yicha chegaralar mavjud. Siz min, maks. Yana bir narsa qilish mumkin. Bu yerda siz ko'p narsalarni to'plashingiz mumkin. Va bu monitoring uchun juda qulay.
Indeks haqida yana bir eslatma bor. Agar biz ushbu vazifa uchun maxsus indeks kerak deb qaror qilsak, u faqat yangilanishlar to'plamini buzmasligiga ishonch hosil qilishimiz kerak. Ya'ni, Postgresda shunday statistika mavjud. Buni jadvalingiz uchun pg_stat_user_tables da ko'rish mumkin. Issiq yangilanishlar ishlatilmoqda yoki yo'qligini ko'rishingiz mumkin.
Sizning yangi indeksingiz ularni shunchaki kesib tashlashi mumkin bo'lgan holatlar mavjud. Va sizda allaqachon ishlayotgan boshqa barcha yangilanishlar bor, sekinlashtiring. Indeks paydo bo'lgani uchun emas (har bir indeks yangilanishlarni biroz sekinlashtiradi, lekin biroz), lekin bu erda u hali ham uni buzadi. Va bu jadval uchun maxsus optimallashtirishni amalga oshirish mumkin emas. Bu ba'zida sodir bo'ladi. Bu shunday noziklikki, kam odam eslaydi. Va bu rake qadam qo'yish oson. Ba'zan shunday bo'ladiki, siz boshqa tomondan yondashuvni topishingiz va hali ham bu yangi indekssiz ish qilishingiz yoki boshqa indeks yaratishingiz yoki boshqa yo'l bilan, masalan, ikkinchi usuldan foydalanishingiz mumkin.
Ammo bu eng maqbul strategiya, qanday qilib partiyalarga bo'linish va bitta so'rov bilan partiyalarda otish, biroz o'chirish va hokazo.
Uzoq tranzaktsiyalar
Bloklangan avtovakuum -
blokirovka muammosi -
№5 xato - bu katta xato. Okmeterdan Nikolay Postgres monitoringi haqida gapirdi. Ideal Postgres monitoringi, afsuski, mavjud emas. Ba'zilar yaqinroq, ba'zilari uzoqroq. Okmeter mukammal bo'lishga etarlicha yaqin, lekin ko'p narsa etishmayapti va qo'shilishi kerak. Siz bunga tayyor bo'lishingiz kerak.
Misol uchun, o'lik kortejlar eng yaxshi nazorat qilinadi. Agar stolda juda ko'p o'lik narsalar bo'lsa, unda biror narsa noto'g'ri. Hozir reaksiyaga kirishgan ma'qul, aks holda tanazzul bo'lishi mumkin va biz yotishimiz mumkin. Bo'lib turadi.
Agar katta IO bo'lsa, bu yaxshi emasligi aniq.
Uzoq tranzaktsiyalar ham. OLTPda uzoq muddatli tranzaktsiyalarga ruxsat berilmasligi kerak. Va bu erda siz ushbu parchani olish va allaqachon uzoq tranzaktsiyalarni kuzatish imkonini beruvchi parchaga havola.
Nima uchun uzoq muddatli tranzaktsiyalar yomon? Chunki barcha qulflar faqat oxirida chiqariladi. Va biz hammani buzamiz. Bundan tashqari, biz barcha jadvallar uchun avtovakuumni bloklaymiz. Bu umuman yaxshi emas. Replikada issiq kutish rejimi yoqilgan bo'lsa ham, u hali ham yomon. Umuman olganda, hech qanday joyda uzoq operatsiyalardan qochish yaxshiroq emas.
Agar bizda vakuumsiz ko'plab jadvallar mavjud bo'lsa, unda biz ogohlantirishga ega bo'lishimiz kerak. Bu erda bunday vaziyat yuzaga kelishi mumkin. Biz bilvosita avtovakuumning ishlashiga ta'sir qilishimiz mumkin. Bu Avito-dan parcha, men uni biroz yaxshilaganman. Va bu avtovakuum bilan bizda nima borligini ko'rish uchun qiziqarli vosita bo'lib chiqdi. Misol uchun, ba'zi jadvallar u erda kutishmoqda va o'z navbatini kutishmaydi. Bundan tashqari, siz uni monitoringga qo'yishingiz va ogohlantirishga ega bo'lishingiz kerak.
Va bloklarni chiqaradi. Blok daraxtlari o'rmoni. Men kimdandir biror narsani olib, uni yaxshilashni yaxshi ko'raman. Bu erda men Data Egret-dan ajoyib rekursiv CTE-ni oldim, unda qulflangan daraxtlar o'rmoni ko'rsatilgan. Bu yaxshi diagnostika vositasi. Va uning asosida siz monitoringni ham qurishingiz mumkin. Ammo bu ehtiyotkorlik bilan bajarilishi kerak. O'zingiz uchun kichik bir bayonot_timeout qilishingiz kerak. Va lock_timeout ma'qul.
Ba'zan bu xatolarning barchasi yig'indisida sodir bo'ladi.
Menimcha, bu yerda asosiy xato tashkilotchilikda. Bu tashkiliy, chunki texnika tortmaydi. Bu 2-raqam - ular noto'g'ri joyda tekshirishgan.
Biz noto'g'ri joyda tekshirdik, chunki bizda ishlab chiqarish kloni yo'q edi, uni tekshirish oson. Ishlab chiquvchida ishlab chiqarishga umuman kirish imkoni bo'lmasligi mumkin.
Va biz u erda emas, balki tekshirdik. U yerda tekshirganimizda o‘zimiz ham ko‘rgan bo‘lardik. Ishlab chiquvchi, agar u bir xil miqdordagi ma'lumotlar va bir xil joylashuv mavjud bo'lgan yaxshi muhitda tekshirsa, DBA bo'lmasa ham, barchasini ko'rdi. U bu tanazzulni ko‘rgan bo‘lardi va uyalardi.
Avtovakuum haqida ko'proq ma'lumot. Biz bir necha million qatorlarni katta hajmda tozalashni amalga oshirganimizdan so'ng, biz hali ham REPACK qilishimiz kerak. Bu, ayniqsa, indekslar uchun juda muhimdir. U erda hamma narsani tozalaganimizdan keyin ular o'zlarini yomon his qilishadi.
Va agar siz kundalik tozalash ishlarini qaytarishni istasangiz, men buni tez-tez qilishni maslahat beraman, lekin kichikroq. Bu daqiqada bir marta yoki hatto tez-tez bir oz bo'lishi mumkin. Va siz ikkita narsani kuzatishingiz kerak: bu narsada xatolik yo'qligi va u orqada qolmasligi. Men ko'rsatgan hiyla buni hal qiladi.
Biz qiladigan narsa ochiq manba. U GitLab-da joylashtirilgan. Va biz buni odamlar DBAsiz ham tekshirishlari uchun qilamiz. Biz ma'lumotlar bazasi laboratoriyasini qilyapmiz, ya'ni Jou hozir ishlayotgan asosiy komponentni chaqiramiz. Va siz ishlab chiqarish nusxasini olishingiz mumkin. Endi Joe for slack ilovasi mavjud, siz u erda aytishingiz mumkin: "falon so'rovni tushuntiring" va darhol ma'lumotlar bazasi nusxasi uchun natijani oling. Siz hatto u erda O'CHIRISH ham mumkin va hech kim buni sezmaydi.
Aytaylik, sizda 10 terabayt bor, biz ma'lumotlar bazasi laboratoriyasini ham 10 terabayt qilamiz. Va bir vaqtning o'zida 10 terabaytlik ma'lumotlar bazalari bilan 10 ta dasturchi bir vaqtning o'zida ishlashi mumkin. Har kim o'zi xohlagan narsani qila oladi. O'chirish, tushirish va hokazo. Bu juda xayol. Bu haqda ertaga gaplashamiz.
Bu nozik ta'minot deb ataladi. Bu nozik ta'minot. Bu rivojlanish, sinovdagi kechikishlarni sezilarli darajada bartaraf etadigan va dunyoni bu borada yaxshiroq joyga aylantiradigan qandaydir fantaziyadir. Ya'ni, bu faqat ommaviy operatsiyalar bilan bog'liq muammolardan qochish imkonini beradi.
Misol: 5 terabaytlik ma'lumotlar bazasi, nusxasini 30 soniyadan kamroq vaqt ichida olish. Va bu hatto o'lchamga bog'liq emas, ya'ni qancha terabayt muhim emas.
Bugun siz borishingiz mumkin va asboblarimizni qazib oling. U erda nima borligini ko'rish uchun ro'yxatdan o'tishingiz mumkin. Siz ushbu botni o'rnatishingiz mumkin. Bu Bepul. Yozing.
Sizning savollaringiz
Ko'pincha haqiqiy vaziyatlarda jadvalda qolishi kerak bo'lgan ma'lumotlar o'chirilishi kerak bo'lgan ma'lumotlardan ancha kam ekanligi ma'lum bo'ladi. Ya'ni, bunday vaziyatda, yangi ob'ektni yaratish, u erda faqat kerakli ma'lumotlarni nusxalash va eski jadvalni trunk qilish osonroq bo'lganda, bunday yondashuvni amalga oshirish ko'pincha osonroq bo'ladi. Siz o'tayotganingizda, hozirgi vaqtda dasturiy yondashuv zarurligi aniq. Bu yondashuv qanday?
Bu juda yaxshi yondashuv va juda yaxshi vazifa. Bu pg_repack ishiga juda o'xshaydi, identifikatorlarni 4 baytga aylantirganda nima qilish kerakligiga juda o'xshaydi. Ko'pgina ramkalar buni bir necha yil oldin qilgan va faqat plitalar o'sgan va ular 8 baytga aylantirilishi kerak.
Bu vazifa ancha qiyin. Biz uddaladik. Va siz juda ehtiyot bo'lishingiz kerak. Qulflar bor va hokazo. Lekin bu amalga oshirilmoqda. Ya'ni, standart yondashuv pg_repack bilan borishdir. Siz bunday yorliqni e'lon qilasiz. Unga oniy rasm ma'lumotlarini yuklashni boshlashdan oldin, siz barcha o'zgarishlarni kuzatadigan bitta plastinani e'lon qilasiz. Siz hatto ba'zi o'zgarishlarni kuzatib bo'lmasligingiz mumkin bo'lgan hiyla bor. Nozikliklar mavjud. Va keyin siz o'zgarishlarni siljitish orqali almashtirasiz. Biz hammani yopib qo'yganimizda qisqa pauza bo'ladi, lekin umuman olganda bu amalga oshirilmoqda.
Agar siz GitHub-da pg_repack-ga qarasangiz, u erda identifikatorni int 4 dan int 8 ga o'tkazish vazifasi bo'lganida, pg_repackning o'zidan foydalanish g'oyasi paydo bo'ldi. Bu ham mumkin, lekin bu biroz xakerlik, lekin buning uchun ham ishlaydi. Siz pg_repack ishlatadigan triggerga aralashib, u erda aytishingiz mumkin: "Bizga bu ma'lumotlar kerak emas", ya'ni biz faqat kerakli narsani o'tkazamiz. Va keyin u shunchaki o'zgaradi va tamom.
Ushbu yondashuv bilan biz hali ham jadvalning ikkinchi nusxasini olamiz, unda ma'lumotlar allaqachon indekslangan va chiroyli indekslar bilan juda teng ravishda to'plangan.
Bloat mavjud emas, bu yaxshi yondashuv. Lekin men bilaman, buning uchun avtomatlashtirishni ishlab chiqish, ya'ni universal echimni yaratishga urinishlar mavjud. Men sizni ushbu avtomatlashtirish bilan bog'lashim mumkin. Bu Python tilida yozilgan, bu yaxshi narsa.
Men MySQL dunyosidan bir oz bo'lganman, shuning uchun men tinglash uchun keldim. Va biz ushbu yondashuvdan foydalanamiz.
Ammo bu faqat bizda 90% bo'lsa. Agar bizda 5% bo'lsa, unda uni ishlatish juda yaxshi emas.
Hisobot uchun rahmat! Agar mahsulotning to'liq nusxasini yaratish uchun resurslar bo'lmasa, yuk yoki o'lchamni hisoblash uchun algoritm yoki formula bormi?
Yaxshi savol. Hozircha biz ko'p terabaytli ma'lumotlar bazalarini topa oldik. U erda apparat bir xil bo'lmasa ham, masalan, kamroq xotira, kamroq protsessor va disklar mutlaqo bir xil emas, lekin baribir biz buni qilamiz. Agar mutlaqo hech qanday joy yo'q bo'lsa, unda siz o'ylashingiz kerak. Ertaga o'ylab ko'ray, keldingiz, gaplashamiz, yaxshi savol.
Hisobot uchun rahmat! Siz birinchi bo'lib shunday va shunga o'xshash cheklovlarga ega bo'lgan ajoyib Postgres borligi haqida boshladingiz, lekin u rivojlanmoqda. Va bularning barchasi katta tayoqcha. Bularning barchasi Postgresning rivojlanishiga zid emasmi, unda qandaydir DELETE deferent paydo bo'ladi yoki biz bu erda g'alati vositalarimiz bilan bulg'amoqchi bo'lgan narsalarni past darajada ushlab turishi kerak bo'lgan boshqa narsa?
Agar biz SQL-da bitta tranzaksiyada ko'plab yozuvlarni o'chirish yoki yangilashni aytgan bo'lsak, Postgres uni qanday tarqatishi mumkin? Biz operatsiyalarda jismonan cheklanganmiz. Biz buni hali uzoq vaqt davomida qilamiz. Va biz bu vaqtda qulflaymiz va hokazo.
Indekslar bilan yakunlandi.
Xuddi shu nazorat nuqtasini sozlashni avtomatlashtirish mumkin deb taxmin qilishim mumkin. Bir kun kelib shunday bo'lishi mumkin. Ammo keyin men savolni tushunmayapman.
Savol shundaki, u erda va u erda ketadigan rivojlanish vektori bormi va bu erda sizniki parallel? Bular. Ular bu haqda hali o'ylamaganmi?
Men hozir foydalanish mumkin bo'lgan tamoyillar haqida gapirdim. Yana bir bot bor , bu bilan siz avtomatlashtirilgan nazorat nuqtasini sozlashingiz mumkin. Bir kun kelib u Postgresda bo'ladimi? Bilmayman, u hali muhokama qilinmagan. Biz hali ham bundan uzoqmiz. Ammo yangi tizimlar yaratadigan olimlar bor. Va ular bizni avtomatik indekslarga o'tkazishadi. O'zgarishlar bor. Masalan, siz avtomatik sozlashni ko'rishingiz mumkin. U avtomatik ravishda parametrlarni tanlaydi. Ammo u hali siz uchun nazorat nuqtasini sozlashni amalga oshirmaydi. Ya'ni, u ishlash, qobiq buferi va boshqalar uchun tanlanadi.
Tekshirish nuqtasini sozlash uchun siz buni qilishingiz mumkin: agar sizda mingta klaster va turli xil apparat vositalari, bulutda turli xil virtual mashinalar bo'lsa, bizning botimizdan foydalanishingiz mumkin. avtomatlashtirishni amalga oshiring. Va max_wal_size avtomatik ravishda maqsad sozlamalaringizga qarab tanlanadi. Ammo hozircha bu, afsuski, yadroga ham yaqin emas.
Hayrli kun! Siz uzoq muddatli bitimlar xavfi haqida gapirdingiz. Siz o'chirishda avtovakuum bloklanganligini aytdingiz. Bu bizga yana qanday zarar keltiradi? Chunki biz ko'proq joyni bo'shatish va undan foydalanish imkoniyati haqida gapiramiz. Bizga yana nima etishmayapti?
Avtovakuum bu erda eng katta muammo emas. Va uzoq tranzaksiya boshqa tranzaktsiyalarni blokirovka qilishi mumkinligi, bu imkoniyat yanada xavflidir. U uchrashishi yoki uchrashmasligi mumkin. Agar u uchrashgan bo'lsa, bu juda yomon bo'lishi mumkin. Va avtovakuum bilan - bu ham muammo. OLTPda uzoq muddatli tranzaktsiyalarda ikkita muammo mavjud: qulflash va avtovakuum. Va agar sizda replikada issiq kutish rejimi yoqilgan bo'lsa, siz hali ham masterda avtovakuum qulfini olasiz, u replikadan keladi. Lekin hech bo'lmaganda hech qanday qulf bo'lmaydi. Va loklar bo'ladi. Biz ma'lumotlar o'zgarishi haqida gapiramiz, shuning uchun qulflar bu erda muhim nuqtadir. Va agar bularning barchasi uzoq, uzoq vaqt davomida bo'lsa, unda ko'proq va ko'proq tranzaktsiyalar qulflanadi. Ular boshqalarni o'g'irlashlari mumkin. Va lok daraxtlari paydo bo'ladi. Men parchaga havola berdim. Va bu muammo faqat to'planishi mumkin bo'lgan avtovakuum bilan bog'liq muammoga qaraganda tezroq sezilarli bo'ladi.
Hisobot uchun rahmat! Siz hisobotni noto'g'ri sinovdan o'tganingizni aytishdan boshladingiz. Biz xuddi shu uskunani, xuddi shu tarzda bazani olishimiz kerak degan fikrimizni davom ettirdik. Aytaylik, ishlab chiquvchiga bazani berdik. Va u iltimosni bajardi. Va u yaxshi bo'lganga o'xshaydi. Lekin u jonli uchun tekshirmaydi, lekin jonli uchun, masalan, bizda 60-70% yuk bor. Va agar biz ushbu sozlashdan foydalansak ham, u juda yaxshi ishlamaydi.
Jamoada mutaxassisga ega bo'lish va haqiqiy fon yuki bilan nima sodir bo'lishini bashorat qila oladigan DBA mutaxassislaridan foydalanish muhimdir. Biz shunchaki toza o'zgarishlarni olib borganimizda, biz rasmni ko'ramiz. Ammo yanada rivojlangan yondashuv, biz yana xuddi shu narsani qilganimizda, lekin ishlab chiqarish bilan simulyatsiya qilingan yuk bilan. Bu juda zo'r. Ungacha siz katta bo'lishingiz kerak. Bu kattalar kabi. Biz bor narsamizni ko'rib chiqdik, shuningdek, resurslarimiz yetarlimi yoki yo'qligini ham ko'rib chiqdik. Bu yaxshi savol.
Biz allaqachon axlatni tanlaganimizda va bizda, masalan, o'chirilgan bayroq bor
Postgresda avtovakuum avtomatik ravishda shunday qiladi.
Oh, u buni qiladimi?
Avtovakuum - bu axlat yig'uvchi.
Rahmat!
Hisobot uchun rahmat! Ma'lumotlar bazasini zudlik bilan bo'linadigan tarzda loyihalash imkoniyati bormi, shunda barcha axlatlar asosiy stoldan biron bir joyda yon tomonga ifloslanadi?
Albatta bor.
Agar biz foydalanmaslik kerak bo'lgan stolni qulflab qo'ygan bo'lsak, o'zimizni himoya qilishimiz mumkinmi?
Albatta bor. Ammo bu tovuq va tuxum savoliga o'xshaydi. Agar biz kelajakda nima bo'lishini hammamiz bilsak, unda, albatta, biz hamma narsani yaxshi qilamiz. Ammo biznes o'zgarmoqda, yangi ustunlar, yangi so'rovlar mavjud. Va keyin - ey, biz uni olib tashlamoqchimiz. Ammo bu ideal vaziyat hayotda sodir bo'ladi, lekin har doim ham emas. Ammo umuman olganda, bu yaxshi fikr. Shunchaki qisqartiring va tamom.
Manba: www.habr.com