Nə vaxtsa uzaq gələcəkdə lazımsız məlumatların avtomatik silinməsi DBMS-nin mühüm vəzifələrindən biri olacaqdır [1]. Bu vaxt biz özümüz lazımsız məlumatların silinməsi və ya daha ucuz saxlama sistemlərinə köçürülməsi ilə məşğul olmalıyıq. Tutaq ki, siz bir neçə milyon sıra silmək qərarına gəldiniz. Xüsusilə vəziyyət məlumdursa və uyğun bir indeks varsa, kifayət qədər sadə bir vəzifə. "Cədvəl1-DƏN SİL HARADA col1 = :value" - daha sadə nə ola bilər, elə deyilmi?
Video:
-
Mən birinci ildən, yəni 2007-ci ildən Highload proqram komitəsindəyəm.
-
Mən 2005-ci ildən Postgres-dəyəm. Bir çox layihələrdə istifadə etdi.
-
2007-ci ildən RuPostges ilə qrup.
-
Meetup-da 2100+ iştirakçıya çatdıq. Uzun müddət San Fransiskonu geridə qoyaraq Nyu Yorkdan sonra dünyada ikincidir.
-
Mən bir neçə ildir Kaliforniyada yaşayıram. Mən daha çox Amerika şirkətləri ilə, o cümlədən iri şirkətlərlə işləyirəm. Onlar Postgres-in aktiv istifadəçiləridir. Və hər cür maraqlı şeylər var.
mənim şirkətimdir. Biz inkişafın ləngiməsini aradan qaldıran tapşırıqların avtomatlaşdırılması işindəyik.
Əgər bir şey edirsinizsə, Postgres ətrafında bəzən bir növ fişlər var. Tutaq ki, adminin sizin üçün test stendi qurmasını gözləmək və ya DBA-nın sizə cavab verməsini gözləmək lazımdır. Biz isə inkişaf, sınaq və idarəetmə prosesində belə darboğazları tapır və avtomatlaşdırma və yeni yanaşmaların köməyi ilə onları aradan qaldırmağa çalışırıq.
Mən bu yaxınlarda Los-Ancelesdəki VLDB-də idim. Bu, verilənlər bazası üzrə ən böyük konfransdır. Gələcəkdə DBMS-nin yalnız məlumatları saxlamayacaq, həm də avtomatik olaraq siləcəyinə dair bir hesabat var idi. Bu yeni mövzudur.
Zettabayt dünyasında getdikcə daha çox məlumat var - bu, 1 petabaytdır. İndi isə artıq təxmin edilir ki, dünyada 000 zettabaytdan çox məlumatımız var. Və onların sayı getdikcə daha çox olur.
Və bununla nə etmək lazımdır? Aydındır ki, onu çıxarmaq lazımdır. Bu maraqlı reportajın linkini təqdim edirik. Amma indiyədək bu, DBMS-də həyata keçirilməyib.
Pul saymağı bacaranlar iki şey istəyir. Onlar bizim silməyimizi istəyirlər, ona görə də texniki olaraq bunu edə bilməliyik.
Bundan sonra deyəcəyim şey, bir sıra real vəziyyətləri, yəni mənim və ətrafdakı verilənlər bazaları ilə dəfələrlə, illər boyu baş verənlərin bir növ kompozisiyasını ehtiva edən bəzi mücərrəd vəziyyətdir. Tırmıqlar hər yerdə var və hamı onların üzərinə addımlayır.
Tutaq ki, böyüyən bir baza və ya bir neçə bazamız var. Və bəzi qeydlər açıq-aşkar zibildir. Məsələn, istifadəçi orada nəsə etməyə başladı, amma onu bitirmədi. Və bir müddət sonra biz bilirik ki, bu yarımçıq artıq saxlanıla bilməz. Yəni, yerə qənaət etmək, performansı yaxşılaşdırmaq və s. üçün bəzi zibil əşyalarını təmizləmək istərdik.
Ümumiyyətlə, vəzifə hansısa cədvəldə konkret şeylərin, konkret xətlərin çıxarılmasını avtomatlaşdırmaqdır.
Və belə bir xahişimiz var ki, bu gün haqqında danışacağıq, yəni zibillərin çıxarılması ilə bağlı.
Təcrübəli tərtibatçıdan bunu etməyi xahiş etdik. Bu tələbi götürdü, özü üçün yoxladı - hər şey işləyir. Səhnədə sınaqdan keçirildi - hər şey yaxşıdır. Çıxarıldı - hər şey işləyir. Gündə bir dəfə onu işə salırıq - hər şey yaxşıdır.
Verilənlər bazası böyüyür və böyüyür. Gündəlik DELETE bir az daha yavaş işləməyə başlayır.
Sonra başa düşürük ki, indi marketinq şirkətimiz var və trafik bir neçə dəfə artacaq, ona görə də lazımsız şeyləri müvəqqəti dayandırmaq qərarına gəlirik. Və qayıtmağı unut.
Bir neçə ay sonra xatırladılar. Və həmin tərtibatçı işdən çıxıb və ya başqa bir şeylə məşğuldur, başqasına onu qaytarmağı tapşırıb.
O, tərtibatı, səhnələşdirməni yoxladı - hər şey qaydasındadır. Təbii ki, hələ də yığılanları təmizləmək lazımdır. Hər şeyin işlədiyini yoxladı.
Sonra nə olacaq? Sonra hər şey bizim üçün dağılır. Elə düşür ki, nə vaxtsa hər şey yıxılır. Hamı şokdadır, heç kim nə baş verdiyini anlamır. Və sonra məlum olur ki, məsələ bu SİLİNDƏ imiş.
Nəsə xəta baş verdi? Budur, nəyin səhv ola biləcəyinin siyahısı. Bunlardan hansı ən vacibdir?
-
Məsələn, heç bir rəy yox idi, yəni DBA eksperti ona baxmadı. Təcrübəli bir gözü ilə problemi dərhal tapardı və bundan əlavə, bir neçə milyon xəttin yığıldığı məhsula çıxışı var.
-
Ola bilsin ki, nəyisə səhvən yoxlayıblar.
-
Ola bilsin ki, avadanlıq köhnəlib və siz bu bazanı təkmilləşdirməlisiniz.
-
Yaxud verilənlər bazasının özündə nəsə səhvdir və biz Postgres-dən MySQL-ə keçməliyik.
-
Yaxud əməliyyatda nəsə səhv olub.
-
Bəlkə işin təşkilində bəzi səhvlər var və kimisə işdən çıxarıb ən yaxşı adamları işə götürmək lazımdır?
DBA yoxlanışı yox idi. Əgər DBA olsaydı, o, bu bir neçə milyon sətri görərdi və heç bir təcrübə etmədən belə deyərdi: "Onlar bunu etmirlər". Tutaq ki, bu kod GitLab, GitHub-da olsaydı və kodun nəzərdən keçirilməsi prosesi olsaydı və DBA-nın təsdiqi olmadan bu əməliyyat məhsulda baş verməyəcəkdi, onda DBA açıq şəkildə deyəcək: “Bunu etmək olmaz. ”
Və o, disk IO ilə problemləriniz olacağını və bütün proseslərin çılğınlaşacağını, kilidlərin ola biləcəyini və həmçinin bir neçə dəqiqə ərzində avtovakuumu bloklayacağınızı söyləyəcəkdi, buna görə də bu yaxşı deyil.
İkinci səhv - səhv yerdə yoxladılar. Məhsulda çoxlu lazımsız məlumatların yığıldığını, lakin tərtibatçının bu verilənlər bazasında məlumat toplamadığını və səhnələşdirmə zamanı heç kim bu zibil yaratmadığını gördük. Müvafiq olaraq, tez işlənmiş 1 xətt var idi.
Testlərimizin zəif olduğunu başa düşürük, yəni qurulan proses heç bir problem yaratmır. Adekvat DB təcrübəsi aparılmadı.
İdeal eksperiment tercihen eyni avadanlıqda aparılır. Eyni avadanlıqda bunu etmək həmişə mümkün deyil, lakin onun verilənlər bazasının tam ölçülü surəti olması çox vacibdir. Artıq bir neçə ildir ki, bunu təbliğ edirəm. Və bir il əvvəl bu barədə danışmışdım, hamısına YouTube-da baxa bilərsiniz.
Bəlkə avadanlıqlarımız pisdir? Baxırsınızsa, gecikmə sıçrayıb. Biz istifadənin 100% olduğunu gördük. Əlbəttə, əgər bunlar müasir NVMe diskləri olsaydı, yəqin ki, bizim üçün çox asan olardı. Və bəlkə də ondan əl çəkməzdik.
Buludlarınız varsa, yeniləmə orada asanlıqla həyata keçirilir. Yeni aparatda yeni replikalar qaldırıldı. keçid. Və hər şey yaxşıdır. Olduqca asan.
Birtəhər kiçik disklərə toxunmaq mümkündürmü? Və burada, yalnız DBA-nın köməyi ilə, biz yoxlama nöqtəsinin tənzimlənməsi adlı müəyyən bir mövzuya dalırıq. Belə çıxır ki, bizdə keçid məntəqəsinin tüninqi olmayıb.
Nəzarət məntəqəsi nədir? İstənilən DBMS-də var. Yaddaşda dəyişən məlumat olduqda, onlar dərhal diskə yazılmır. Verilənlərin dəyişdirilməsi haqqında məlumat əvvəlcə qabaqcadan yazma jurnalına yazılır. Və müəyyən bir nöqtədə, DBMS qərar verir ki, real səhifələri diskə atmağın vaxtıdır, belə ki, uğursuzluqla üzləşsək, daha az REDO edə bilək. Oyuncaq kimidir. Əgər öldürülsək, oyuna sonuncu keçid məntəqəsindən başlayacağıq. Və bütün DBMS onu həyata keçirir.
Postgres-də parametrlər geridə qalır. Onlar 10-15 illik məlumat və əməliyyatların həcmi üçün nəzərdə tutulub. Və keçid məntəqəsi də istisna deyil.
Budur Postgres yoxlama hesabatımızdan, yəni avtomatik sağlamlıq yoxlanışı. Və burada bir neçə terabaytlıq bir verilənlər bazası var. Və demək olar ki, 90% hallarda məcburi keçid məntəqələrinin olduğunu yaxşı görmək olar.
Bunun mənası nədi? Orada iki parametr var. Yoxlama məntəqəsi fasilə ilə, məsələn, 10 dəqiqədən sonra gələ bilər. Və ya kifayət qədər çox məlumat doldurulduqda gələ bilər.
Varsayılan olaraq max_wal_saze 1 gigabayta təyin edilmişdir. Əslində, bu, həqiqətən Postgres-də 300-400 meqabaytdan sonra baş verir. Çox məlumat dəyişdiniz və yoxlama nöqtəniz baş verdi.
Və heç kim onu kökləməyibsə və xidmət böyüyübsə və şirkət çoxlu pul qazanırsa, çoxlu əməliyyatları var, o zaman keçid məntəqəsi dəqiqədə bir dəfə, bəzən 30 saniyədən bir gəlir və bəzən hətta üst-üstə düşür. Bu olduqca pisdir.
Və bunun daha az tez-tez gəlməsinə əmin olmalıyıq. Yəni, biz max_wal_size artıra bilərik. Və daha az tez-tez gələcək.
Ancaq biz bunu necə daha düzgün etmək, yəni konkret məlumatlara əsaslanaraq, parametrləri seçmək barədə qərar vermək üçün bütöv bir metodologiya hazırlamışıq.
Müvafiq olaraq, verilənlər bazası üzərində iki sıra təcrübələr edirik.
Birinci seriya - biz max_wal_size dəyişirik. Və biz böyük bir əməliyyat edirik. Birincisi, biz bunu 1 gigabaytlıq standart parametrdə edirik. Və biz milyonlarla sətirdən ibarət kütləvi SİLİN.
Bizim üçün nə qədər çətin olduğunu görə bilərsiniz. Disk IO-nun çox pis olduğunu görürük. Nə qədər WAL yaratdığımıza baxırıq, çünki bu çox vacibdir. Baxaq, neçə dəfə keçid məntəqəsi olub. Və bunun yaxşı olmadığını görürük.
Sonra max_wal_size artırırıq. Təkrar edirik. Artırırıq, təkrar edirik. Və dəfələrlə. Prinsipcə, 10 bal yaxşıdır, burada 1, 2, 4, 8 gigabaytdır. Və biz müəyyən bir sistemin davranışına baxırıq. Aydındır ki, burada avadanlıq məhsuldakı kimi olmalıdır. Eyni disklərə, eyni miqdarda yaddaşa və eyni Postgres parametrlərinə sahib olmalısınız.
Və bu şəkildə sistemimizi mübadilə edəcəyik və DBMS-nin pis kütləvi DELETE vəziyyətində necə davranacağını, yoxlama nöqtəsinin necə olacağını bilirik.
Rus dilində keçid məntəqəsi keçid məntəqələridir.
Misal: Bir neçə milyon sətiri indekslə SİLİN, sətirlər səhifələr arasında "səpələnmişdir".
Budur bir nümunə. Bu hansısa əsasdır. Və max_wal_size üçün standart olaraq 1 gigabayt qəbulu ilə disklərimizin qeyd üçün rəfə getdiyi çox aydındır. Bu şəkil çox xəstə bir xəstənin tipik simptomudur, yəni özünü həqiqətən pis hiss edir. Və tək bir əməliyyat var idi, sadəcə bir neçə milyon sətirdən ibarət bir SİLME var idi.
Əgər istehsalda belə əməliyyata icazə verilirsə, onda biz sadəcə uzanacağıq, çünki bir SİLİN bizi rəfdə öldürdüyü aydındır.
Bundan əlavə, 16 gigabayt olan yerdə dişlərin artıq getdiyi aydındır. Dişlər artıq yaxşıdır, yəni tavanı döyürük, amma o qədər də pis deyil. Orada bir qədər azadlıq var idi. Sağda qeyd var. Və əməliyyatların sayı - ikinci qrafik. Və aydındır ki, 16 gigabayt olanda artıq bir az daha asan nəfəs alırıq.
Və 64 gigabaytın tamamilə yaxşılaşdığını görmək olar. Artıq dişlər tələffüz olunur, digər əməliyyatlardan sağ çıxmaq və disklə bir şey etmək üçün daha çox imkanlar var.
Niyə belədir?
Təfərrüatlara bir az dalaşacağam, amma bu mövzu, yoxlama nöqtəsinin tənzimlənməsi bütöv bir hesabatla nəticələnə bilər, buna görə də çox yükləməyəcəyəm, amma hansı çətinliklərin olduğunu bir az qeyd edəcəyəm.
Yoxlama məntəqəsi çox tez-tez baş verirsə və sətirlərimizi ardıcıl olaraq deyil, indekslə tapırıqsa, bu yaxşıdır, çünki bütün cədvəli silmirik, o zaman əvvəlcə birinci səhifəyə, sonra mininci səhifəyə toxunmuşuq. və sonra birinciyə döndü. Əgər birinci səhifəyə bu səfərlər arasında yoxlama məntəqəsi onu artıq diskdə saxlayıbsa, o, onu yenidən saxlayacaq, çünki biz onu ikinci dəfə çirkləndirmişik.
Və biz yoxlama məntəqəsini dəfələrlə saxlamağa məcbur edəcəyik. Onun üçün lazımsız əməliyyatlar necə olardı.
Ancaq bu hamısı deyil. Postgres-də səhifələr 8 kilobayt və Linux-da 4 kilobaytdır. Və full_page_writes parametri var. Defolt olaraq aktivdir. Və bu düzgündür, çünki onu söndürsək, o zaman səhifənin yalnız yarısının qəzaya uğrayaraq xilas olacağı təhlükəsi var.
İrəli jurnalın WAL-a yazmağın davranışı elədir ki, yoxlama nöqtəmiz olduqda və səhifəni ilk dəfə dəyişdikdə bütün səhifə, yəni bütün 8 kilobayt irəli jurnala daxil olur, baxmayaraq ki, biz yalnız 100 bayt ağırlığında olan xətt. Və bütün səhifəni yazmalıyıq.
Sonrakı dəyişikliklərdə yalnız müəyyən bir tuple olacaq, lakin ilk dəfə hər şeyi yazırıq.
Və müvafiq olaraq, yoxlama məntəqəsi yenidən baş veribsə, onda biz hər şeyi yenidən sıfırdan başlamaq və bütün səhifəni itələməliyik. Tez-tez yoxlama nöqtələri ilə eyni səhifələri gəzdiyimiz zaman full_page_writes = on ola biləcəyindən daha çox olacaq, yəni biz daha çox WAL yaradırıq. Daha çoxu replikalara, arxivə, diskə göndərilir.
Və buna uyğun olaraq iki ixtisarımız var.
Əgər biz max_wal_size artırsaq, belə çıxır ki, biz həm nəzarət nöqtəsi, həm də wal yazıçısı üçün işi asanlaşdırırıq. Və bu əladır.
Gəlin bir terabayt qoyaq və onunla yaşayaq. Bunun nəyi pisdir? Bu pisdir, çünki nasazlıq olarsa, saatlarla qalxacağıq, çünki keçid məntəqəsi çoxdan olub və artıq çox şey dəyişib. Və bütün bunları REDO etməliyik. Beləliklə, ikinci sınaq seriyasını edirik.
Biz bir əməliyyat edirik və nəzarət məntəqəsinin nə vaxt tamamlanacağını görürük, bilərəkdən -9 Postgres öldürürük.
Bundan sonra biz onu yenidən işə salırıq və onun bu avadanlıqda nə qədər yüksələcəyini, yəni bu pis vəziyyətdə nə qədər REDO edəcəyini görürük.
İki dəfə qeyd edim ki, vəziyyət pisdir. Birincisi, keçid məntəqəsi bitməmiş qəzaya uğradıq, ona görə də itirəcəyimiz çox şey var. İkincisi, biz böyük əməliyyat keçirdik. Yoxlama məntəqələri fasilədə olsaydı, çox güman ki, son keçid məntəqəsindən bəri daha az WAL yaranardı. Yəni ikiqat uduzur.
Biz belə bir vəziyyəti müxtəlif max_wal_size ölçüləri üçün ölçürük və başa düşürük ki, əgər max_wal_size 64 gigabaytdırsa, onda ikiqat ən pis halda 10 dəqiqəyə qalxacağıq. Biz isə düşünürük ki, bu, bizə yaraşır, ya yox. Bu biznes sualıdır. Bu şəkli biznes qərarlarına cavabdeh olan şəxslərə göstərib soruşmalıyıq: “Problem zamanı ən çox nə qədər uzana bilərik? Ən pis vəziyyətdə 3-5 dəqiqə uzana bilərikmi? Və bir qərar verirsən.
Və burada maraqlı bir məqam var. Konfransda Patroni ilə bağlı bir neçə məruzəmiz var. Və bəlkə də ondan istifadə edirsiniz. Bu Postgres üçün avtomatik keçiddir. GitLab və Data Egret bu barədə danışdılar.
Və əgər 30 saniyəyə gələn avtomatik yüklənmə varsa, onda bəlkə 10 dəqiqə uzana bilərik? Çünki bu vaxta qədər replikaya keçəcəyik və hər şey yaxşı olacaq. Bu mübahisəli məqamdır. Mən dəqiq cavab bilmirəm. Sadəcə hiss edirəm ki, bu mövzu təkcə qəzaların bərpası ilə bağlı deyil.
Uğursuzluqdan sonra uzun müddət bərpa olsaq, o zaman bir çox başqa vəziyyətlərdə narahat olacağıq. Məsələn, eyni təcrübələrdə bir şey etdikdə və bəzən 10 dəqiqə gözləmək məcburiyyətindəyik.
Mən hələ də çox uzağa getməzdim, hətta bizdə avtomatik yüklənmə olsa belə. Bir qayda olaraq, 64, 100 gigabayt kimi dəyərlər yaxşı dəyərlərdir. Bəzən hətta daha azını seçməyə dəyər. Ümumiyyətlə, bu incə bir elmdir.
İterasiyaları etmək üçün, məsələn, max_wal_size =1, 8, kütləvi əməliyyatı dəfələrlə təkrarlamaq lazımdır. Sən bunu bacardın. Və eyni bazada bunu yenidən etmək istəyirsən, amma artıq hər şeyi silmisən. Nə etməli?
Çözüm yollarımızdan, belə vəziyyətlərdə təkrarlamaq üçün nə etdiyimizdən sonra danışacağam. Və bu ən düzgün yanaşmadır.
Amma bu işdə bəxtimiz gətirdi. Əgər burada deyildiyi kimi "BAŞLAYIN, SİLİN, GERİ DÖNDÜR" deyirsinizsə, SİLİNİ təkrarlaya bilərik. Yəni özümüz ləğv etmişiksə, deməli, təkrarlaya bilərik. Və fiziki olaraq sizə məlumat eyni yerdə yatacaq. Heç bir şişkinlik də almırsınız. Siz bu cür SİLİNDƏLƏRİ təkrarlaya bilərsiniz.
ROLLBACK ilə bu SİL, düzgün yerləşdirilmiş verilənlər bazası laboratoriyalarınız olmasa belə, yoxlama nöqtəsinin tənzimlənməsi üçün idealdır.
Bir sütun "i" ilə bir boşqab hazırladıq. Postgres-də faydalı sütunlar var. Xüsusi olaraq tələb edilmədikcə onlar görünməzdir. Bunlar: ctid, xmid, xmax.
Ctid fiziki ünvandır. Sıfır səhifə, səhifədəki ilk tuple.
ROOLBACK-dan sonra dəftərin eyni yerdə qaldığını görmək olar. Yəni yenidən cəhd edə bilərik, o da eyni şəkildə davranacaq. Əsas olan budur.
Xmax, dəftərin ölüm vaxtıdır. O, möhürlənmişdi, lakin Postgres əməliyyatın geri çəkildiyini bilir, ona görə də onun 0 və ya geri çəkilmiş əməliyyat olmasının fərqi yoxdur. Bu onu göstərir ki, DELETE üzərində təkrarlamaq və sistem davranışının toplu əməliyyatlarını yoxlamaq mümkündür. Kasıblar üçün verilənlər bazası laboratoriyaları yarada bilərsiniz.
Bu proqramçılar haqqındadır. DBA haqqında da proqramçıları buna görə danlayırlar: “Niyə belə uzun və çətin əməliyyatlar edirsiniz?”. Bu tamamilə fərqli perpendikulyar mövzudur. Əvvəllər idarəçilik var idi, indi də inkişaf olacaq.
Aydındır ki, biz parçalanmamışıq. Aydındır. Milyonlarla sətir yığını üçün belə SİLİNİ hissələrə bölməmək mümkün deyil. 20 dəqiqə ediləcək və hər şey yatacaq. Ancaq təəssüf ki, hətta çox böyük şirkətlərdə belə təcrübəli tərtibatçılar səhv edirlər.
Qırmaq niyə vacibdir?
-
Diskin sərt olduğunu görsək, onda yavaşlayaq. Əgər biz sınmışıqsa, onda fasilələr əlavə edə bilərik, tənzimləməni yavaşlata bilərik.
-
Və uzun müddət başqalarını blok etməyəcəyik. Bəzi hallarda fərq etməz, əgər heç kimin üzərində işləmədiyi real zibilləri silirsinizsə, o zaman çox güman ki, avtovakuum işindən başqa heç kimi blok etməyəcəksiniz, çünki o, əməliyyatın tamamlanmasını gözləyəcək. Ancaq başqasının tələb edə biləcəyi bir şeyi silsəniz, o zaman bloklanacaq, bir növ zəncirvari reaksiya olacaq. Veb saytlarda və mobil tətbiqlərdə uzun əməliyyatlardan çəkinmək lazımdır.
Bu maraqlıdır. Mən tez-tez görürəm ki, tərtibatçılar soruşurlar: "Hansı paket ölçüsünü seçməliyəm?".
Aydındır ki, paketin ölçüsü nə qədər böyük olarsa, əməliyyatın qaimə məsrəfi bir o qədər kiçik olar, yəni əməliyyatlardan əlavə məsrəflər. Ancaq eyni zamanda, bu əməliyyat üçün vaxt artır.
Mənim çox sadə bir qaydam var: bacardığınız qədər götürün, lakin saniyədə icra olunanları keçməyin.
Niyə bir saniyə? İzahat çox sadə və hər kəs, hətta texniki olmayan insanlar üçün başa düşüləndir. Bir reaksiya görürük. 50 millisaniyə götürək. Bir şey dəyişdisə, gözümüz reaksiya verəcəkdir. Daha azdırsa, daha çətindir. Əgər bir şey 100 millisaniyədən sonra cavab verirsə, məsələn, siz siçanı kliklədiniz və o sizə 100 millisaniyədən sonra cavab verdisə, siz artıq bu kiçik gecikməni hiss edirsiniz. Bir saniyə artıq əyləc kimi qəbul edilir.
Buna uyğun olaraq, kütləvi əməliyyatlarımızı 10 saniyəlik partlamalara bölsək, o zaman kimisə bloklamaq riskimiz var. Və bir neçə saniyə işləyəcək və insanlar bunu artıq görəcəklər. Ona görə də bir saniyədən artıq etməməyi üstün tuturam. Ancaq eyni zamanda, onu çox incə bir şəkildə parçalamayın, çünki əməliyyat yükü nəzərə çarpacaq. Baza daha sərt olacaq və başqa müxtəlif problemlər yarana bilər.
Paketin ölçüsünü seçirik. Hər bir halda biz bunu fərqli şəkildə edə bilərik. Avtomatlaşdırıla bilər. Və biz bir paketin emalının səmərəliliyinə əminik. Yəni bir paketin SİLİNİ və ya YENİLƏNİB.
Yeri gəlmişkən, danışdığım hər şey təkcə SİLMƏ ilə bağlı deyil. Təxmin etdiyiniz kimi, bunlar verilənlər üzərində hər hansı toplu əməliyyatlardır.
Və görürük ki, plan əladır. İndeks skanını görə bilərsiniz, yalnız indeks taraması daha yaxşıdır. Və bizdə az miqdarda məlumat var. Və bir saniyədən az yerinə yetirir. Super.
Və hələ də heç bir deqradasiya olmadığına əmin olmalıyıq. Elə olur ki, ilk paketlər tez işləyir, sonra isə daha da pisləşir, pisləşir və pisləşir. Proses elədir ki, çox sınamaq lazımdır. Verilənlər bazası laboratoriyaları məhz bunun üçündür.
Və biz hələ bir şey hazırlamalıyıq ki, istehsalda buna düzgün əməl etməyə imkan versin. Məsələn, jurnala vaxtı yaza bilərik, indi harada olduğumuzu və indi kimləri sildiyimizi yaza bilərik. Və bu, sonradan nə baş verdiyini anlamağa imkan verəcək. Və bir şey səhv olarsa, problemi tez tapın.
Əgər sorğuların səmərəliliyini yoxlamaq lazımdırsa və biz dəfələrlə təkrarlamalıyıqsa, o zaman yoldaş bot kimi bir şey var. O, artıq hazırdır. Gündəlik onlarla tərtibatçı tərəfindən istifadə olunur. Və o, 30 saniyə ərzində istək əsasında nəhəng bir terabayt verilənlər bazasını, öz surətinizi necə verməyi bilir. Və orada nəyisə silib RESET deyərək yenidən silə bilərsiniz. Bu şəkildə təcrübə edə bilərsiniz. Mən bu işin gələcəyini görürəm. Və biz artıq bunu edirik.
Bölmə strategiyaları hansılardır? Paketdəki tərtibatçıların istifadə etdiyi 3 fərqli bölmə strategiyasını görürəm.
Birincisi çox sadədir. Rəqəmsal ID-miz var. Gəlin onu müxtəlif intervallara ayıraq və bununla işləyək. Mənfi tərəfi aydındır. Birinci seqmentdə 100 sətir real zibilimiz ola bilər, ikinci 5 sətirdə və ya heç olmaya bilər və ya 1 sətir hamısı zibil olacaq. Çox qeyri-bərabər iş, lakin onu qırmaq asandır. Maksimum şəxsiyyət vəsiqəsini götürüb sındırdılar. Bu sadəlövh yanaşmadır.
İkinci strategiya balanslaşdırılmış yanaşmadır. Gitlab-da istifadə olunur. Masanı götürüb skan etdilər. Biz ID paketlərinin sərhədlərini tapdıq ki, hər paketdə tam olaraq 10 qeyd var. Və onları növbəyə qoyun. Və sonra emal edirik. Bunu bir neçə mövzuda edə bilərsiniz.
Birinci strategiyada da, yeri gəlmişkən, bunu bir neçə mövzuda edə bilərsiniz. Bu çətin deyil.
Ancaq daha soyuq və daha yaxşı bir yanaşma var. Bu üçüncü strategiyadır. Və mümkün olduqda, onu seçmək daha yaxşıdır. Biz bunu xüsusi indeks əsasında edirik. Bu halda, çox güman ki, zibil vəziyyətimizə və ID-yə uyğun bir indeks olacaq. Biz identifikatoru daxil edəcəyik ki, o, yalnız skan edilmiş indeks olsun ki, yığına getməyək.
Ümumiyyətlə, yalnız indeks taraması indeks taramasından daha sürətlidir.
Və silmək istədiyimiz şəxsiyyət vəsiqələrimizi tez tapırıq. BATCH_SIZE biz əvvəlcədən seçirik. Və biz onları təkcə əldə etmirik, biz onları xüsusi bir şəkildə əldə edirik və dərhal hack edirik. Amma biz kilidləyirik ki, əgər onlar artıq kilidlənibsə, biz onları kilidləməyək, davam edək və sonrakıları götürək. Bu, yeniləmə ötürməsinin kilidlənməsi üçündür. Postgres-in bu super xüsusiyyəti istəsək bir neçə mövzuda işləməyə imkan verir. Bir axınla mümkündür. Və burada bir CTE var - bu bir xahişdir. Və bu CTE-nin ikinci mərtəbəsində əsl silinmə gedir - returning *. Siz id-i qaytara bilərsiniz, lakin bu daha yaxşıdır *hər sətirdə çox məlumatınız yoxdursa.
Niyə bizə lazımdır? Geri hesabat verməli olduğumuz budur. İndi faktiki olaraq bir çox sətirləri silmişik. Və bizim ID və ya yaradılmış_at ilə sərhədlərimiz var. Siz min, maks. Başqa bir şey etmək olar. Burada çox şey doldura bilərsiniz. Və monitorinq üçün çox əlverişlidir.
İndekslə bağlı daha bir qeyd var. Bu tapşırıq üçün xüsusi bir indeksə ehtiyacımız olduğuna qərar etsək, o zaman yığının yalnız tuples yeniləmələrini korlamadığından əmin olmalıyıq. Yəni Postgresin belə statistikası var. Bunu cədvəliniz üçün pg_stat_user_tables-də görmək olar. İsti yeniləmələrin istifadə edilib-edilmədiyini görə bilərsiniz.
Yeni indeksinizin sadəcə onları kəsə biləcəyi vəziyyətlər var. Və artıq işləyən bütün digər yeniləmələrə sahibsiniz, yavaşlayın. Yalnız indeks göründüyü üçün deyil (hər bir indeks yeniləmələri bir az ləngidir, amma bir az), amma burada yenə də onu məhv edir. Və bu cədvəl üçün xüsusi optimallaşdırma etmək mümkün deyil. Bu bəzən olur. Bu elə bir incəlikdir ki, az adam xatırlayır. Və bu dırmıq üzərində addımlamaq asandır. Bəzən elə olur ki, qarşı tərəfdən bir yanaşma tapmaq lazımdır və hələ də bu yeni indeks olmadan etmək və ya başqa bir indeks yaratmaq və ya başqa bir şəkildə, məsələn, ikinci üsuldan istifadə edə bilərsiniz.
Amma bu, ən optimal strategiyadır, bir istəklə partiyalara bölünüb partiyalara necə çəkilmək, bir az silmək və s.
Uzun əməliyyatlar
Bloklanmış avtovakuum -
bloklama məsələsi -
5 nömrəli səhv böyükdür. Okmeterdən olan Nikolay Postgres monitorinqi haqqında danışdı. Təəssüf ki, ideal Postgres monitorinqi mövcud deyil. Bəziləri daha yaxın, bəziləri daha uzaqdır. Okmeter mükəmməl olmağa kifayət qədər yaxındır, lakin çox şey yoxdur və əlavə etmək lazımdır. Bunun üçün hazır olmaq lazımdır.
Məsələn, ölü tuples ən yaxşı şəkildə izlənilir. Cədvəldə çoxlu ölü şey varsa, deməli bir şey səhvdir. İndi reaksiya vermək daha yaxşıdır, əks halda deqradasiya ola bilər və biz uzana bilərik. Baş verir.
Böyük bir IO varsa, bunun yaxşı olmadığı aydındır.
Uzun əməliyyatlar da. OLTP-də uzun əməliyyatlara icazə verilməməlidir. Və burada bu fraqmenti götürməyə və artıq uzun əməliyyatları izləməyə imkan verən fraqmentə keçid var.
Niyə uzun əməliyyatlar pisdir? Çünki bütün qıfıllar yalnız sonunda buraxılacaq. Və hamını yıxırıq. Üstəlik, biz bütün masalar üçün avtovakuumu bloklayırıq. Heç yaxşı deyil. Replikada isti gözləmə rejimini aktiv etsəniz belə, bu hələ də pisdir. Ümumiyyətlə, heç bir yerdə uzun əməliyyatlardan qaçmaq daha yaxşı deyil.
Əgər tozsoranla təmizlənməmiş çoxlu masalarımız varsa, o zaman xəbərdarlıq almalıyıq. Burada belə bir vəziyyət mümkündür. Avtovakuumun işinə dolayı təsir göstərə bilərik. Bu Avito-dan bir parçadır, onu bir az təkmilləşdirdim. Və avtovakuumla nəyə sahib olduğumuzu görmək üçün maraqlı bir vasitə olduğu ortaya çıxdı. Məsələn, bəzi masalar orada gözləyir və öz növbəsini gözləməyəcək. Siz həmçinin monitorinqə qoyub xəbərdarlıq etməlisiniz.
Və bloklar verir. Blok ağacları meşəsi. Kimdənsə nəyisə götürüb onu təkmilləşdirməyi xoşlayıram. Burada mən Data Egret-dən sərin rekursiv CTE götürdüm ki, bu da ağacların meşəsini göstərir. Bu yaxşı diaqnostik vasitədir. Və onun əsasında siz də monitorinq qura bilərsiniz. Ancaq bu diqqətlə edilməlidir. Özünüz üçün kiçik bir bəyanat_timeout etməlisiniz. Və lock_timeout arzuolunandır.
Bəzən bütün bu səhvlər cəmi baş verir.
Məncə, burada əsas səhv təşkilatçılıqdır. Təşkilati xarakter daşıyır, çünki texnika çəkmir. Bu 2 nömrədir - səhv yerdə yoxladılar.
Yanlış yerdə yoxladıq, çünki bizdə istehsal klonu yox idi, onu yoxlamaq asandır. Tərtibatçının istehsala ümumiyyətlə girişi olmaya bilər.
Orada yoxladıq. Orada yoxlasaydıq, özümüz də görərdik. Tərtibatçı, eyni miqdarda məlumatın və eyni yerin olduğu yaxşı bir mühitdə yoxlasa, DBA olmadan da hamısını gördü. Bütün bu alçaqlığı görəcək və utanacaqdı.
Avtovakuum haqqında daha çox məlumat. Bir neçə milyon sətirdən ibarət böyük bir tarama etdikdən sonra hələ də REPACK etməliyik. Bu, indekslər üçün xüsusilə vacibdir. Biz orada hər şeyi təmizlədikdən sonra özlərini pis hiss edəcəklər.
Gündəlik təmizlik işlərini geri qaytarmaq istəyirsinizsə, mən bunu daha tez-tez, lakin daha kiçik etməyi təklif edərdim. Bu dəqiqədə bir dəfə və ya daha tez-tez bir az ola bilər. Və iki şeyi izləmək lazımdır: bu şeyin heç bir səhvi olmaması və geridə qalmaması. Göstərdiyim hiylə bunu həll edəcək.
Bizim etdiyimiz açıq mənbədir. GitLab-da yerləşdirilib. Biz bunu elə edirik ki, insanlar DBA olmadan da yoxlaya bilsinlər. Biz verilənlər bazası laboratoriyası edirik, yəni Joe-nun hazırda işlədiyi əsas komponenti çağırırıq. Və istehsalın bir nüsxəsini götürə bilərsiniz. İndi boşluq üçün Joe tətbiqi var, orada deyə bilərsiniz: "filan sorğunu izah edin" və dərhal verilənlər bazası surətiniz üçün nəticə əldə edin. Siz hətta orada SİLƏ bilərsiniz və heç kim bunu fərq etməyəcək.
Tutaq ki, sizin 10 terabaytınız var, verilənlər bazası laboratoriyasını da 10 terabayt edirik. Və eyni vaxtda 10 terabaytlıq verilənlər bazası ilə 10 tərtibatçı eyni vaxtda işləyə bilər. Hər kəs istədiyini edə bilər. Silmək, buraxmaq və s. Bu, belə bir fantaziyadır. Bu barədə sabah danışacağıq.
Buna nazik təminat deyilir. Bu incə təminatdır. Bu, inkişafda, sınaqda gecikmələri xeyli aradan qaldıran və dünyanı bu baxımdan daha yaxşı bir yerə çevirən bir növ fantaziyadır. Yəni, yalnız toplu əməliyyatlarla bağlı problemlərdən qaçmağa imkan verir.
Nümunə: 5 terabaytlıq verilənlər bazası, 30 saniyədən az müddətdə surət əldə etmək. Və hətta ölçüsündən də asılı deyil, yəni neçə terabaytın əhəmiyyəti yoxdur.
Bu gün gedə bilərsiniz və alətlərimizi qazın. Orada nə olduğunu görmək üçün qeydiyyatdan keçə bilərsiniz. Bu botu quraşdıra bilərsiniz. Pulsuzdur. yaz.
Suallar
Çox tez-tez real vəziyyətlərdə cədvəldə qalmalı olan məlumatların silinməsi lazım olandan daha az olduğu ortaya çıxır. Yəni, belə bir vəziyyətdə, yeni bir obyekt yaratmaq, orada yalnız lazımi məlumatları kopyalamaq və köhnə cədvəli yükləmək daha asan olduqda, belə bir yanaşmanı həyata keçirmək çox vaxt daha asandır. Aydındır ki, siz keçid zamanı bu an üçün proqramlı bir yanaşma lazımdır. Bu yanaşma necədir?
Bu, çox yaxşı yanaşmadır və çox yaxşı vəzifədir. Bu, pg_repack-in etdiyinə çox bənzəyir, identifikatorları 4 bayt etdikdə etməli olduğunuz şeyə çox oxşardır. Bir çox çərçivə bunu bir neçə il əvvəl etdi və sadəcə plitələr böyüdü və onları 8 bayta çevirmək lazımdır.
Bu vəzifə olduqca çətindir. Biz bunu etdik. Və çox diqqətli olmalısınız. Kilidlər var və s. Amma edilir. Yəni standart yanaşma pg_repack ilə getməkdir. Siz belə bir etiket elan edirsiniz. Snapshot məlumatlarını ona yükləməyə başlamazdan əvvəl, bütün dəyişiklikləri izləyən bir lövhə elan edirsiniz. Bəzi dəyişiklikləri izləyə bilməyəcəyiniz bir hiylə var. İncəliklər var. Və sonra dəyişiklikləri yuvarlamaqla keçid edirsiniz. Hamını bağlayanda qısa bir fasilə olacaq, amma ümumilikdə bu edilir.
GitHub-da pg_repack-a baxsanız, o zaman orada bir ID-ni int 4-dən int 8-ə çevirmək tapşırığı olanda, pg_repack-in özündən istifadə etmək fikri var idi. Bu da mümkündür, lakin bu, bir az hackdir, lakin bunun üçün də işləyəcək. Siz pg_repack-in istifadə etdiyi triggerə müdaxilə edib orada deyə bilərsiniz: "Bizə bu məlumat lazım deyil", yəni biz yalnız bizə lazım olanı köçürürük. Və sonra o, sadəcə dəyişir və bu qədərdir.
Bu yanaşma ilə biz hələ də cədvəlin ikinci nüsxəsini alırıq, burada məlumatlar artıq indeksləşdirilir və gözəl indekslərlə çox bərabər şəkildə yığılır.
Bloat mövcud deyil, bu yaxşı bir yanaşmadır. Ancaq bilirəm ki, bunun üçün bir avtomatlaşdırma yaratmaq, yəni universal bir həll etmək cəhdləri var. Mən sizinlə bu avtomatlaşdırma ilə əlaqə saxlaya bilərəm. Python-da yazılmışdır, bu yaxşı bir şeydir.
Mən MySQL dünyasından bir qədər azam, ona görə də dinləməyə gəldim. Və biz bu yanaşmadan istifadə edirik.
Ancaq bu, yalnız 90% olduqda olur. Əgər bizdə 5 faiz varsa, onda ondan istifadə etmək çox yaxşı deyil.
Hesabat üçün təşəkkür edirik! Məhsulun tam surətini çıxarmaq üçün heç bir resurs yoxdursa, yükü və ya ölçüsünü hesablamaq üçün hər hansı bir alqoritm və ya düstur varmı?
Yaxşı sual. İndiyə qədər biz çox terabaytlıq verilənlər bazalarını tapa bilirik. Oradakı avadanlıq eyni olmasa belə, məsələn, daha az yaddaş, daha az prosessor və disklər tam olaraq eyni deyil, amma yenə də bunu edirik. Əgər tamamilə heç bir yer yoxdursa, onda düşünmək lazımdır. Sabaha qədər fikirləşim, gəlmisən, danışarıq, yaxşı sualdır.
Hesabat üçün təşəkkür edirik! Siz əvvəlcə belə və belə məhdudiyyətləri olan, lakin inkişaf edən sərin Postgres olduğundan başladınız. Və bütün bunlar böyük ölçüdə bir qoltuqaltıdır. Bütün bunlar Postgresin inkişafı ilə ziddiyyət təşkil etmirmi, hansısa DELETE deferentinin meydana çıxacağı və ya burada bəzi qəribə vasitələrimizlə ləkələməyə çalışdığımız şeyi aşağı səviyyədə saxlamalı olan başqa bir şey?
SQL-də bir əməliyyatda çoxlu qeydləri silmək və ya yeniləmək lazım olduğunu söyləmişiksə, Postgres onu orada necə paylaya bilər? Əməliyyatlarımızda fiziki olaraq məhdudyıq. Hələ uzun müddət bunu edəcəyik. Və biz bu zaman kilidləyəcəyik və s.
İndekslərlə tamamlandı.
Güman edə bilərəm ki, eyni yoxlama məntəqəsinin tənzimlənməsi avtomatlaşdırıla bilər. Bir gün ola bilər. Amma sonra sualı həqiqətən başa düşə bilmirəm.
Sual olunur ki, ora-bura gedən, sizinki isə paralel gedən elə bir inkişaf vektoru varmı? Bunlar. Bu barədə hələ də düşünməyiblər?
İndi istifadə oluna biləcək prinsiplərdən danışdım. Başqa bir bot var , bununla siz avtomatlaşdırılmış yoxlama nöqtəsinin tənzimləməsini edə bilərsiniz. Bir gün Postgresdə olacaqmı? Bilmirəm, hələ müzakirə olunmayıb. Biz hələ bundan uzağıq. Ancaq yeni sistemlər yaradan alimlər var. Və bizi avtomatik indekslərə itələyirlər. İnkişaflar var. Məsələn, avtomatik tuningə baxa bilərsiniz. Parametrləri avtomatik seçir. Amma o, hələ sizin üçün yoxlama nöqtəsi tənzimləməsi etməyəcək. Yəni, performans, qabıq buferi və s.
Yoxlama məntəqəsinin tənzimləməsi üçün isə bunu edə bilərsiniz: əgər buludda minlərlə klasteriniz və müxtəlif avadanlıqlarınız, müxtəlif virtual maşınlarınız varsa, bizim botdan istifadə edə bilərsiniz. avtomatlaşdırma aparın. Və max_wal_size avtomatik olaraq hədəf parametrlərinizə uyğun seçiləcək. Ancaq bu günə qədər, təəssüf ki, nüvəyə belə yaxın deyil.
Günortanız Xeyir Uzun əməliyyatların təhlükələrindən danışdınız. Dediniz ki, silinmə zamanı avtovakuum bloklanır. Bunun bizə başqa necə zərəri var? Çünki biz daha çox yer boşaltmaq və ondan istifadə edə bilməkdən danışırıq. Başqa nəyi əskik edirik?
Avtovakuum bəlkə də burada ən böyük problem deyil. Və uzun bir əməliyyatın digər əməliyyatları bağlaya bilməsi, bu ehtimal daha təhlükəlidir. O, görüşə bilər, görüşməyə də bilər. Əgər görüşsəydi, bu, çox pis ola bilər. Və autovakuum ilə - bu da bir problemdir. OLTP-də uzun əməliyyatlarla bağlı iki problem var: kilidləmə və avtovakuum. Əgər replikada aktiv gözləmə rejimində rəyiniz varsa, onda siz yenə də masterda avtovakuum kilidi alacaqsınız, o, replikadan gələcək. Amma heç olmasa qıfıllar olmayacaq. Və oxlar olacaq. Söhbət məlumat dəyişikliklərindən gedir, ona görə də kilidlər burada mühüm məqamdır. Bütün bunlar uzun, uzun müddətdirsə, getdikcə daha çox əməliyyat bağlanır. Başqalarını oğurlaya bilərlər. Və lok ağacları görünür. Snippetə keçid verdim. Və bu problem yalnız yığıla bilən avtovakuum problemindən daha tez nəzərə çarpır.
Hesabat üçün təşəkkür edirik! Hesabatınıza səhv test etdiyinizi söyləməklə başladınız. Fikrimizi davam etdirdik ki, eyni avadanlığı, baza ilə eyni şəkildə götürməliyik. Deyək ki, biz tərtibatçıya baza verdik. Və tələbi yerinə yetirdi. Və deyəsən yaxşıdır. Amma canlı yox, canlı üçün yoxlayır, məsələn, bizdə 60-70% yük var. Və bu tənzimləmədən istifadə etsək də, çox yaxşı işləmir.
Komandada bir mütəxəssisin olması və real fon yükü ilə nə baş verəcəyini təxmin edə bilən DBA ekspertlərindən istifadə etmək vacibdir. Sadəcə təmiz dəyişikliklərimizi sürdükdə şəkli görürük. Ancaq daha inkişaf etmiş bir yanaşma, eyni şeyi yenidən etdikdə, lakin istehsalla simulyasiya edilmiş bir yüklə. Bu olduqca sərin. O vaxta qədər böyüməlisən. Bu, böyüklər kimidir. Biz sadəcə əlimizdə olanlara baxdıq və kifayət qədər resurslarımız olub-olmamasına da baxdıq. Bu yaxşı sualdır.
Biz artıq bir zibil seçin və biz, məsələn, silinmiş bir bayraq edirik
Avtovakuumun Postgres-də avtomatik etdiyi budur.
Oh, bunu edir?
Avtovakuum zibil yığandır.
Təşəkkür edirik!
Hesabat üçün təşəkkür edirik! Bölmə ilə verilənlər bazasını dərhal elə bir şəkildə tərtib etmək variantı varmı ki, bütün zibil əsas masadan hardasa yan tərəfə çirklənsin?
Əlbəttə var.
İstifadə edilməməsi lazım olan bir masanı kilidləmişiksə, özümüzü qorumaq mümkündürmü?
Əlbəttə var. Amma bu, toyuq-yumurta sualına bənzəyir. Gələcəkdə nə olacağını hamımız bilsək, təbii ki, hər şeyi sərin edəcəyik. Amma iş dəyişir, yeni sütunlar, yeni sorğular var. Və sonra - oops, biz onu silmək istəyirik. Ancaq bu ideal vəziyyət, həyatda baş verir, lakin həmişə deyil. Amma ümumilikdə yaxşı fikirdir. Sadəcə kəsin və bu qədər.
Mənbə: www.habr.com