Хэзээ нэгэн цагт шаардлагагүй өгөгдлийг автоматаар устгах нь DBMS-ийн чухал ажлуудын нэг байх болно [1]. Энэ хооронд бид өөрсдөө шаардлагагүй өгөгдлийг устгах эсвэл хямд хадгалах систем рүү шилжүүлэхэд анхаарах хэрэгтэй. Та хэдэн сая мөрийг устгахаар шийдсэн гэж бодъё. Нэлээд энгийн ажил, ялангуяа нөхцөл байдал мэдэгдэж байгаа бөгөөд тохиромжтой индекс байгаа бол. "DELETE FROM table1 WHERE col1 = :value" - илүү хялбар юу байж болох вэ?
Видео:
-
Би эхний жилээс, өөрөөр хэлбэл 2007 оноос хойш Highload хөтөлбөрийн хороонд ажиллаж байна.
-
Би 2005 оноос хойш Postgres-тэй хамт ажиллаж байна. Үүнийг олон төсөлд ашигласан.
-
2007 оноос хойш RuPostges-тэй групп.
-
Бид Meetup-д 2100+ оролцогч болж өссөн. Сан Франциског удаан хугацаанд гүйцэж түрүүлсэн Нью-Йоркийн дараа дэлхийд хоёрдугаарт бичигдэж байна.
-
Би Калифорнид хэдэн жил амьдарсан. Би Америкийн компаниуд, тэр дундаа томоохон компаниудтай илүү харьцдаг. Тэд Postgres-ийн идэвхтэй хэрэглэгчид юм. Мөн янз бүрийн сонирхолтой зүйлүүд байдаг.
миний компани. Бид хөгжлийн удаашралыг арилгах ажлыг автоматжуулах бизнес эрхэлдэг.
Хэрэв та ямар нэгэн зүйл хийж байгаа бол Postgres-ийн эргэн тойронд заримдаа ямар нэгэн залгуур байдаг. Та админ танд зориулж тестийн тавцан тавихыг хүлээх хэрэгтэй эсвэл DBA танд хариу өгөхийг хүлээх хэрэгтэй гэж бодъё. Бид боловсруулах, турших, удирдах үйл явцад ийм саад бэрхшээлийг олж илрүүлж, автоматжуулалт, шинэ арга барилын тусламжтайгаар тэдгээрийг арилгахыг хичээдэг.
Би саяхан Лос Анжелес дахь VLDB-д байсан. Энэ бол мэдээллийн сангийн хамгийн том хурал юм. Ирээдүйд DBMS нь өгөгдлийг хадгалахаас гадна автоматаар устгах болно гэсэн мэдээлэл гарсан. Энэ бол шинэ сэдэв юм.
Дэлхий дээр зеттабайтын тоо улам ихсэж байна - энэ нь 1 петабайт юм. Одоо бид дэлхий дээр 000 гаруй зеттабайт өгөгдөл хадгалсан гэж аль хэдийн тооцоолсон. Мөн тэд улам олон болж байна.
Тэгээд юу хийх вэ? Үүнийг арилгах шаардлагатай байгаа нь ойлгомжтой. Энэхүү сонирхолтой тайлангийн холбоосыг энд оруулав. Гэвч өнөөг хүртэл үүнийг DBMS-д хэрэгжүүлээгүй байна.
Мөнгө тоолж чаддаг хүмүүс хоёр зүйлийг хүсдэг. Тэд биднийг устгахыг хүсч байгаа тул техникийн хувьд бид үүнийг хийх боломжтой байх ёстой.
Дараа нь миний хэлэх зүйл бол олон тооны бодит нөхцөл байдлыг багтаасан хийсвэр нөхцөл байдал, өөрөөр хэлбэл надад болон эргэн тойрны мэдээллийн санд олон удаа, олон жил тохиолдсон зүйлийн эмхэтгэл юм. Тармуурууд хаа сайгүй байдаг бөгөөд хүн бүр байнга гишгэдэг.
Бид өсөн нэмэгдэж буй суурь эсвэл хэд хэдэн суурьтай гэж бодъё. Мөн зарим бичлэгүүд нь мэдээжийн хэрэг хог юм. Жишээлбэл, хэрэглэгч тэнд ямар нэг зүйл хийж эхэлсэн боловч дуусгаагүй. Хэсэг хугацааны дараа энэ дуусаагүй зүйлийг хадгалах боломжгүй гэдгийг бид мэднэ. Өөрөөр хэлбэл, бид орон зай хэмнэх, гүйцэтгэлийг сайжруулах гэх мэт зарим хог хаягдлыг цэвэрлэхийг хүсч байна.
Ерөнхийдөө даалгавар бол зарим хүснэгтэд тодорхой зүйл, тодорхой мөрүүдийг арилгах ажлыг автоматжуулах явдал юм.
Мөн бид өнөөдөр ярих болно, хог зайлуулах тухай ийм хүсэлт байна.
Бид туршлагатай хөгжүүлэгчээс үүнийг хийхийг хүссэн. Тэр энэ хүсэлтийг авч, өөрөө шалгаж үзсэн - бүх зүйл ажилладаг. Тайзан дээр туршиж үзсэн - бүх зүйл сайхан байна. Гарсан - бүх зүйл ажилладаг. Өдөрт нэг удаа бид үүнийг ажиллуулдаг - бүх зүйл сайхан байна.
Мэдээллийн сан өсөн нэмэгдэж, хөгжиж байна. Өдөр тутмын DELETE нь арай удаан ажиллаж эхэлдэг.
Дараа нь бид маркетингийн компанитай болж, ачаалал хэд дахин их байх болно гэдгийг ойлгож байгаа тул шаардлагагүй зүйлсийг түр зогсоохоор шийдсэн. Тэгээд буцаж ирэхээ март.
Хэдэн сарын дараа тэд санав. Тэр хөгжүүлэгч ажлаасаа гарсан эсвэл өөр зүйлд завгүй байгаа тул өөр хүнд буцааж өгөхийг тушаажээ.
Тэр хөгжүүлэлт, найруулга зэргийг шалгасан - бүх зүйл хэвийн байна. Мэдээжийн хэрэг, та хуримтлагдсан зүйлийг цэвэрлэх хэрэгтэй хэвээр байна. Тэр бүх зүйл ажиллаж байгааг шалгасан.
Дараа нь юу болох вэ? Дараа нь бидний хувьд бүх зүйл нуран унах болно. Энэ нь унадаг тул хэзээ нэгэн цагт бүх зүйл унадаг. Бүгд шоконд орсон, юу болоод байгааг хэн ч ойлгохгүй байна. Тэгээд л энэ УСТГАХ-д асуудал байсан юм байна лээ.
Ямар нэгэн зүйл буруугаар эргэсэн? Энд алдаа гарсан зүйлсийн жагсаалтыг энд оруулав. Эдгээрийн аль нь хамгийн чухал вэ?
-
Жишээлбэл, ямар ч тойм гараагүй, өөрөөр хэлбэл DBA-ийн мэргэжилтэн үүнийг хараагүй. Тэрээр туршлагатай нүдээр асуудлыг даруй олж мэдэх бөгөөд үүнээс гадна тэрээр хэдэн сая шугам хуримтлагдсан бүтээгдэхүүнд нэвтрэх боломжтой болно.
-
Магадгүй тэд ямар нэг зүйл буруу шалгасан байх.
-
Магадгүй техник хангамж хуучирсан тул та энэ суурийг шинэчлэх хэрэгтэй.
-
Эсвэл мэдээллийн санд ямар нэг зүйл буруу байгаа бөгөөд бид Postgres-ээс MySQL рүү шилжих хэрэгтэй.
-
Эсвэл мэс засалд ямар нэг алдаа гарсан байж магадгүй юм.
-
Магадгүй ажлын зохион байгуулалтад алдаа гарч, хэн нэгнийг халж, хамгийн сайн хүмүүсийг ажилд авах шаардлагатай байна уу?
DBA шалгалт байгаагүй. Хэрэв DBA байсан бол тэр хэдэн сая мөрийг харж, ямар ч туршилтгүйгээр "Тэд үүнийг хийдэггүй" гэж хэлэх болно. Хэрэв энэ код GitLab, GitHub дээр байсан бөгөөд кодыг шалгах процесс явагдах бөгөөд DBA-ийн зөвшөөрөлгүйгээр энэ үйл ажиллагаа бүтээгдэхүүн дээр явагдахгүй байсан бол DBA: "Үүнийг хийх боломжгүй" гэж хэлэх нь ойлгомжтой гэж бодъё. ”
Тэр танд дискний IO-тэй холбоотой асуудал гарах бөгөөд бүх процессууд галзуурах болно, түгжигдэх болно, мөн та хэдэн минутын турш автовакуумыг хааж болно, тиймээс энэ нь сайн зүйл биш гэж хэлэх болно.
Хоёр дахь алдаа - тэд буруу газар шалгасан. Бүтээгдэхүүн дээр маш их хог хаягдал хуримтлагдсан боловч хөгжүүлэгч энэ мэдээллийн санд өгөгдөл хуримтлуулаагүй бөгөөд тайз хийх явцад хэн ч энэ хог хаягдлыг үүсгээгүйг бид олж харлаа. Үүний дагуу 1 мөр хурдан хийгдсэн байв.
Бидний туршилтууд сул байна, өөрөөр хэлбэл бүтээгдсэн процесс нь асуудал үүсгэдэггүй гэдгийг бид ойлгож байна. Хангалттай DB туршилт хийгдээгүй.
Хамгийн тохиромжтой туршилтыг ижил төхөөрөмж дээр хийх нь дээр. Үүнийг нэг төхөөрөмж дээр хийх нь үргэлж боломжгүй байдаг ч энэ нь мэдээллийн сангийн бүрэн хэмжээний хуулбар байх нь маш чухал юм. Энэ бол би хэдэн жилийн турш номлож байгаа зүйл юм. Жилийн өмнө би энэ тухай ярьж байсан, та бүгдийг YouTube-ээс үзэх боломжтой.
Магадгүй манай тоног төхөөрөмж муу байна уу? Хэрэв та харвал хоцролт нь үсрэв. Ашиглалт 100 хувь байгааг бид харлаа. Мэдээжийн хэрэг, хэрэв эдгээр нь орчин үеийн NVMe хөтчүүд байсан бол энэ нь бидний хувьд илүү хялбар байх болно. Тэгээд ч бид үүнээс хойш хэвтэхгүй байх.
Хэрэв танд үүл байгаа бол шинэчлэлтийг тэнд хялбархан хийх боломжтой. Шинэ техник хангамж дээр шинэ хуулбаруудыг босгосон. шилжих. Тэгээд бүх зүйл сайхан байна. Маш амархан.
Жижиг дискэнд ямар нэгэн байдлаар хүрэх боломжтой юу? Энд зөвхөн DBA-ийн тусламжтайгаар бид хяналтын цэгийн тааруулалт гэж нэрлэгддэг тодорхой сэдэв рүү шумбаж байна. Манайд шалган нэвтрүүлэх цэгийн тохируулга байхгүй байсан нь харагдаж байна.
Шалгах цэг гэж юу вэ? Энэ нь ямар ч DBMS-д байдаг. Таны санах ойд өгөгдөл өөрчлөгдөхөд тэр даруй диск рүү бичигддэггүй. Өгөгдөл өөрчлөгдсөн тухай мэдээллийг эхлээд урьдчилан бичих бүртгэлд бичнэ. Хэзээ нэгэн цагт DBMS нь бодит хуудсуудыг диск рүү буулгах цаг нь болсон гэж шийддэг бөгөөд ингэснээр алдаа гарвал бид бага REDO хийх боломжтой болно. Яг л тоглоом шиг. Хэрэв бид алагдсан бол сүүлчийн хяналтын цэгээс тоглоомоо эхлүүлнэ. Мөн бүх DBMS үүнийг хэрэгжүүлдэг.
Postgres-ийн тохиргоонууд хоцорч байна. Эдгээр нь 10-15 жилийн хугацаатай өгөгдөл, гүйлгээнд зориулагдсан. Мөн хяналтын цэг нь үл хамаарах зүйл биш юм.
Манай Postgres шалгалтын тайлан, тухайлбал эрүүл мэндийн автомат шалгалтын мэдээлэл энд байна. Энд хэд хэдэн терабайтын зарим мэдээллийн сан байна. Бараг 90 хувьд нь албадан шалган нэвтрүүлэх цэгүүд байгааг сайн харж болно.
Энэ нь юу гэсэн үг вэ? Тэнд хоёр тохиргоо байна. Шалгах цэг нь жишээлбэл, 10 минутын дараа ирж болно. Эсвэл маш их мэдээлэл бөглөсөн үед гарч ирж магадгүй юм.
Мөн анхдагчаар max_wal_saze нь 1 гигабайтаар тохируулагдсан. Үнэн хэрэгтээ энэ нь Postgres-д 300-400 мегабайтын дараа үнэхээр тохиолддог. Та маш их өгөгдлийг өөрчилсөн бөгөөд таны хяналтын цэг болсон.
Тэгээд хэн ч тааруулаагүй, үйлчилгээ нь томорч, компани нь маш их мөнгө олдог, маш их гүйлгээтэй байдаг бол хяналтын цэг минутанд нэг удаа, заримдаа 30 секунд тутамд ирдэг, заримдаа бүр давхцдаг. Энэ бол нэлээд муу.
Мөн бид энэ нь бага ирдэг эсэхийг шалгах хэрэгтэй. Энэ нь бид max_wal_size-ийг өсгөж чадна. Мөн энэ нь бага зэрэг ирэх болно.
Гэхдээ бид үүнийг хэрхэн илүү зөв хийх вэ, өөрөөр хэлбэл тодорхой өгөгдөл дээр үндэслэн тохиргоог хэрхэн сонгох шийдвэр гаргах талаар бүхэл бүтэн арга зүйг боловсруулсан.
Үүний дагуу бид мэдээллийн сан дээр хоёр цуврал туршилт хийж байна.
Эхний цуврал - бид max_wal_size-ийг өөрчилдөг. Мөн бид томоохон хагалгаа хийж байна. Эхлээд бид үүнийг 1 гигабайтын анхдагч тохиргоогоор хийдэг. Мөн бид олон сая мөрийг их хэмжээгээр устгадаг.
Энэ нь бидэнд ямар хэцүү байгааг харж болно. Дискний IO маш муу байгааг бид харж байна. Бид хичнээн WAL үүсгэсэн бэ гэдгийг хардаг, учир нь энэ нь маш чухал юм. Шалгах цэг хэдэн удаа болсныг харцгаая. Мөн энэ нь сайн биш гэдгийг бид харж байна.
Дараа нь бид max_wal_size-г нэмэгдүүлнэ. Бид давтана. Бид нэмэгддэг, бид давтдаг. Тэгээд маш олон удаа. Зарчмын хувьд 10 оноо нь сайн, 1, 2, 4, 8 гигабайт байна. Мөн бид тодорхой системийн зан төлөвийг хардаг. Энд тоног төхөөрөмж үйлдвэрлэсэн шиг байх ёстой нь тодорхой байна. Та ижил диск, ижил хэмжээний санах ой, ижил Postgres тохиргоотой байх ёстой.
Ийм байдлаар бид системээ солилцож, DELETE муу тохиолдолд DBMS хэрхэн ажиллахыг, энэ нь шалгах цэгийг хэрхэн яаж хийхийг мэддэг.
Орос хэлээр шалган нэвтрүүлэх цэг нь хяналтын цэг юм.
Жишээ нь: Хэдэн сая мөрийг индексээр нь УСТГАХ, мөрүүд хуудаснуудаар "тарагдсан".
Энд нэг жишээ байна. Энэ бол ямар нэгэн суурь юм. Мөн max_wal_size-ийн хувьд 1 гигабайтын анхдагч тохиргоотойгоор бидний дискүүд бичлэг хийх тавиур руу явдаг нь маш тодорхой юм. Энэ зураг нь маш их өвчтэй өвчтөний ердийн шинж тэмдэг юм, өөрөөр хэлбэл тэр үнэхээр муу санагдсан. Тэгээд ганц хагалгаа байсан, хэдэн сая мөрийг УСТГАХ л байсан.
Хэрэв ийм ажиллагаа явуулахыг зөвшөөрвөл бид зүгээр л хэвтэх болно, учир нь нэг УСТГАХ хүн биднийг хороонд алах нь тодорхой.
Цаашилбал, хаана 16 гигабайт, энэ нь шүд аль хэдийн явсан нь тодорхой байна. Шүд нь аль хэдийн илүү сайн болсон, өөрөөр хэлбэл бид таазыг тогшиж байна, гэхдээ тийм ч муу биш. Тэнд жаахан эрх чөлөө байсан. Баруун талд нь бичлэг байна. Мөн үйлдлүүдийн тоо - хоёр дахь график. Мөн 16 гигабайт байхад бид аль хэдийн бага зэрэг хялбар амьсгалж байгаа нь тодорхой байна.
Мөн 64 гигабайт нь бүрэн сайжирсан нь харагдаж байна. Шүд нь аль хэдийн тодроод байгаа тул бусад үйлдлүүдийг даван туулах, дискээр ямар нэгэн зүйл хийх боломж илүү их байдаг.
Яагаад ийм байна
Би нарийн ширийн зүйлийг бага зэрэг судлах болно, гэхдээ хяналтын цэгийн тохируулгыг хэрхэн хийх талаар энэ сэдэв нь бүхэл бүтэн тайланг гаргах боломжтой тул би нэг их ачаалахгүй, гэхдээ ямар бэрхшээл байгааг бага зэрэг тоймлох болно.
Хэрэв хяналтын цэг хэтэрхий олон удаа тохиолдвол бид мөрүүдээ дарааллаар нь биш харин индексээр нь олдог бөгөөд энэ нь сайн, учир нь бид хүснэгтийг бүхэлд нь устгадаггүй тул эхлээд эхний хуудсанд, дараа нь мянга дахь хуудсанд хүрсэн байж магадгүй юм. тэгээд эхнийх рүүгээ буцсан. Хэрэв эхний хуудас руу орох хооронд шалгах цэг үүнийг аль хэдийн дискэнд хадгалсан бол бид үүнийг хоёр дахь удаагаа бохирдуулсан тул дахин хадгалах болно.
Мөн бид шалган нэвтрүүлэх цэгийг олон удаа хадгалах болно. Хэрхэн түүний хувьд илүүц ажиллагаа явуулах бол.
Гэхдээ энэ нь бүгд биш юм. Хуудас нь Postgres дээр 8 килобайт, Линукс дээр 4 килобайт байна. Мөн бүтэн_хуудас_бичих тохиргоо байдаг. Энэ нь анхдагчаар идэвхжсэн байна. Энэ нь зөв, учир нь хэрэв бид үүнийг унтраавал хуудасны зөвхөн тал нь эвдэрсэн тохиолдолд л хадгалагдах аюултай.
Дамжуулах бүртгэлийн WAL-д бичих үйл явц нь бид шалгах цэгтэй болж, хуудсыг анх удаа өөрчлөх үед бүх хуудас, өөрөөр хэлбэл бүх 8 килобайт нь урагшлах бүртгэлд ордог. 100 байт жинтэй шугам. Мөн бид хуудсыг бүхэлд нь бичих ёстой.
Дараагийн өөрчлөлтүүдэд зөвхөн тодорхой tuple байх болно, гэхдээ бид анх удаа бүх зүйлийг бичиж байна.
Үүний дагуу, хэрэв хяналтын цэг дахин тохиолдвол бид бүх зүйлийг эхнээс нь эхлүүлж, хуудсыг бүхэлд нь түлхэх хэрэгтэй. Тогтмол шалган нэвтрүүлэх цэгүүдээр бид ижил хуудсуудаар дамжин өнгөрөхөд full_page_writes = on нь байж болох хэмжээнээс их байх болно, өөрөөр хэлбэл бид илүү их WAL үүсгэдэг. Илүү ихийг хуулбар, архив, диск рүү илгээдэг.
Үүний дагуу бидэнд хоёр орон тооны цомхотгол бий.
Хэрэв бид max_wal_size-ийг нэмэгдүүлбэл бид шалган нэвтрүүлэх цэг болон вал зохиолчийн аль алинд нь илүү хялбар болгох болно. Энэ бол гайхалтай.
Терабайтыг оруулаад түүнтэйгээ амьдарцгаая. Үүний юу нь муу вэ? Энэ нь муу, учир нь бүтэлгүйтсэн тохиолдолд бид олон цагаар авирах болно, учир нь шалган нэвтрүүлэх цэг нэлээд эрт байсан бөгөөд маш их зүйл өөрчлөгдсөн. Мөн бид энэ бүх REDO хийх хэрэгтэй. Тиймээс бид хоёр дахь цуврал туршилтыг хийж байна.
Бид хагалгаа хийж, шалган нэвтрүүлэх цэг хэзээ дуусахыг хараад -9 Postgres-г санаатайгаар устгадаг.
Үүний дараа бид үүнийг дахин эхлүүлж, энэ төхөөрөмж дээр хэр удаан өсөхийг, өөрөөр хэлбэл энэ муу нөхцөл байдалд хэр зэрэг ДАХИНДАХ болно гэдгийг харах болно.
Нөхцөл байдал муу байгааг би хоёр удаа тэмдэглэх болно. Нэгдүгээрт, шалган нэвтрүүлэх цэг дуусаагүй байхад бид осолдсон тул алдах зүйл их байна. Хоёрдугаарт, бид маш том хагалгаа хийсэн. Хэрэв хяналтын цэгүүд завсарлагатай байсан бол сүүлийн хяналтын цэгээс хойш бага WAL үүсэх магадлалтай. Энэ нь давхар ялагдсан гэсэн үг.
Бид ийм нөхцөл байдлыг янз бүрийн max_wal_size хэмжээтэй хэмжиж, хэрвээ max_wal_size нь 64 гигабайт бол хамгийн муу тохиолдолд бид 10 минутын турш авирах болно гэдгийг ойлгодог. Тэгээд энэ нь бидэнд тохирох уу, үгүй юу гэж боддог. Энэ бол бизнесийн асуулт юм. Бид энэ зургийг бизнесийн шийдвэр гаргах үүрэгтэй хүмүүст үзүүлж, “Асуудал гарсан тохиолдолд бид хамгийн ихдээ хэр удаан хэвтэж чадах вэ? Бид хамгийн хүнд нөхцөлд 3-5 минутын турш хэвтэж чадах уу? Тэгээд та шийдвэрээ гарга.
Мөн энд нэг сонирхолтой зүйл байна. Бид чуулган дээр Патронигийн талаар хэд хэдэн илтгэл тавьсан. Магадгүй та үүнийг ашиглаж байгаа байх. Энэ бол Postgres-д зориулсан автомат шилжүүлэлт юм. GitLab болон Data Egret нар энэ тухай ярьсан.
Хэрэв танд 30 секундын дотор автоматаар дамждаг бол бид 10 минут хэвтэх боломжтой юу? Учир нь бид энэ үед хуулбар руу шилжих бөгөөд бүх зүйл сайхан болно. Энэ бол маргаантай асуудал юм. Би тодорхой хариулт мэдэхгүй байна. Энэ сэдэв нь зөвхөн ослын нөхөн сэргээх тухай биш гэдгийг би зүгээр л мэдэрч байна.
Хэрэв бид бүтэлгүйтсэний дараа удаан эдгэрч байвал бусад олон нөхцөл байдалд бид эвгүй байдалд орно. Жишээлбэл, ижил туршилтуудад бид ямар нэгэн зүйл хийж, заримдаа 10 минут хүлээх хэрэгтэй болдог.
Хэдийгээр бид автомат ажиллагаатай байсан ч би хэт хол явахгүй. Дүрмээр бол 64, 100 гигабайт гэх мэт утгууд нь сайн утга юм. Заримдаа бүр бага зүйлийг сонгох нь зүйтэй. Ерөнхийдөө энэ бол нарийн шинжлэх ухаан юм.
Давталтыг хийхийн тулд, жишээ нь, max_wal_size =1, 8, та масс үйлдлийг олон удаа давтах хэрэгтэй. Чи чадсан. Мөн ижил суурь дээр та үүнийг дахин хийхийг хүсч байгаа боловч та бүгдийг аль хэдийн устгасан байна. Юу хийх вэ?
Ийм нөхцөл байдалд давтагдахын тулд бид юу хийх талаар бид дараа нь ярих болно. Мөн энэ бол хамгийн зөв хандлага юм.
Гэхдээ энэ тохиолдолд бид азтай байсан. Хэрэв энд бичсэнчлэн "ЭХЛҮҮЛЭХ, УСТГАХ, БУЦАХ" гэж үзвэл бид УСТГАХ үйлдлийг давтаж болно. Өөрөөр хэлбэл, хэрэв бид өөрсдөө цуцалсан бол дахин давтаж болно. Мөн таны бие махбодийн хувьд өгөгдөл нь нэг газар байх болно. Танд ямар ч хавдсан ч байхгүй. Та ийм DELETE-г давтаж болно.
Танд өгөгдлийн сангийн лаборатори зохих ёсоор тавигдаагүй байсан ч ROLLBACK-тай энэхүү DELETE нь хяналтын цэгийг тааруулахад тохиромжтой.
Бид "i" баганатай хавтанг хийсэн. Postgres нь хэрэглээний баганатай. Тэд тусгайлан асуугаагүй бол үл үзэгдэх болно. Үүнд: ctid, xmid, xmax.
Ctid бол физик хаяг юм. Тэг хуудас, хуудасны эхний tuple.
ROOLBACK-ийн дараа уг залгуур нэг байрандаа үлдсэнийг харж болно. Өөрөөр хэлбэл, бид дахин оролдож болно, энэ нь адилхан байх болно. Энэ бол гол зүйл.
Xmax бол залгуурын үхэх цаг юм. Энэ нь тамга дарагдсан байсан ч Postgres гүйлгээг буцасныг мэдэж байгаа тул 0 эсвэл буцаагдсан гүйлгээ нь хамаагүй. Энэ нь DELETE дээр давталт хийх, системийн үйл ажиллагааны бөөн үйлдлийг шалгах боломжтойг харуулж байна. Та ядуу хүмүүст зориулсан мэдээллийн сангийн лаборатори хийж болно.
Энэ бол програмистуудын тухай юм. DBA-ийн талаар ч тэд програмистуудыг "Яагаад ийм урт, хэцүү ажиллагаанууд хийж байгаа юм бэ?" гэж загнадаг. Энэ бол огт өөр перпендикуляр сэдэв юм. Удирдлага байсан, одоо хөгжил дэвшил болно.
Бид хэсэг хэсгээрээ хуваагдаагүй нь ойлгомжтой. Энэ нь тодорхой байна. Ийм УСТГАХ-ыг хэдэн сая мөрийг хэсэг болгон задлахгүй байх боломжгүй. Энэ нь 20 минутын турш хийгдэх бөгөөд бүх зүйл хэвтэх болно. Гэвч харамсалтай нь туршлагатай хөгжүүлэгчид ч гэсэн маш том компаниудад алдаа гаргадаг.
Яагаад эвдэх нь чухал вэ?
-
Хэрэв бид диск хатуу байгаа бол үүнийг удаашруулъя. Хэрэв бид эвдэрсэн бол түр зогсолт нэмж, хурдыг удаашруулж болно.
-
Мөн бид бусдыг удаан хугацаанд хаахгүй. Зарим тохиолдолд энэ нь хамаагүй, хэрэв та хэн ч ажиллаагүй жинхэнэ хог хаягдлыг устгаж байгаа бол автомат вакуумаас өөр хэнийг ч хаахгүй байх магадлалтай, учир нь энэ нь гүйлгээ дуусахыг хүлээх болно. Гэхдээ хэрэв та хэн нэгний хүсэлт гаргаж болох зүйлийг устгавал тэд хаагдах болно, ямар нэгэн гинжин урвал үүсэх болно. Вэбсайт болон гар утасны програмууд дээр урт хугацааны гүйлгээ хийхээс зайлсхийх хэрэгтэй.
Энэ сонирхолтой байна. Хөгжүүлэгчид "Би ямар багцын хэмжээг сонгох ёстой вэ?" Гэж асуудаг.
Багцын хэмжээ их байх тусам гүйлгээний нэмэлт зардал, өөрөөр хэлбэл гүйлгээний нэмэлт зардал бага байх нь ойлгомжтой. Гэхдээ үүнтэй зэрэгцэн энэ гүйлгээний хугацаа нэмэгддэг.
Надад маш энгийн дүрэм бий: аль болох ихийг аваарай, гэхдээ секундэд гүйцэтгэх файлуудыг бүү дав.
Яагаад секунд гэж? Тайлбар нь маш энгийн бөгөөд техникийн бус хүмүүст ч ойлгомжтой. Бид хариу үйлдэл үзүүлж байгааг харж байна. 50 миллисекунд авч үзье. Хэрэв ямар нэг зүйл өөрчлөгдсөн бол бидний нүд хариу үйлдэл үзүүлэх болно. Хэрэв бага бол илүү хэцүү. Хэрэв ямар нэг зүйл 100 миллисекундын дараа хариу өгвөл, жишээлбэл, та хулганаа дарахад 100 миллисекундын дараа хариу өгсөн бол та энэ бага зэрэг сааталыг аль хэдийн мэдэрнэ. Секундыг аль хэдийн тоормос гэж ойлгодог.
Үүний дагуу бид нийтийг хамарсан үйл ажиллагаагаа 10 секундын тэсрэлт болгон задлах юм бол хэн нэгнийг хаах эрсдэлтэй. Энэ нь хэдхэн секундын турш ажиллах бөгөөд хүмүүс үүнийг аль хэдийн анзаарах болно. Тиймээс би нэг секундээс илүүг хийхгүй байхыг илүүд үздэг. Гэхдээ үүнтэй зэрэгцэн үүнийг маш нарийн задалж болохгүй, учир нь гүйлгээний нэмэлт зардал мэдэгдэхүйц байх болно. Суурь нь илүү хэцүү байх болно, өөр өөр асуудал үүсч болно.
Бид багцын хэмжээг сонгодог. Аль ч тохиолдолд бид үүнийг өөрөөр хийх боломжтой. Автоматжуулах боломжтой. Мөн бид нэг багцыг боловсруулах үр дүнтэй гэдэгт итгэлтэй байна. Өөрөөр хэлбэл, бид нэг багцыг УСТГАХ эсвэл ШИНЭЧЛЭГДЭГ.
Дашрамд хэлэхэд миний яриад байгаа бүх зүйл зөвхөн DELETE-ийн тухай биш юм. Таны таамаглаж байгаагаар эдгээр нь өгөгдөл дээрх аливаа бөөн үйл ажиллагаа юм.
Төлөвлөгөө маш сайн байгааг бид харж байна. Та индекс сканыг харж болно, зөвхөн индекс скан хийх нь илүү дээр юм. Мөн бид бага хэмжээний өгөгдөлтэй холбоотой. Мөн секунд хүрэхгүй хугацаанд биелдэг. Мундаг.
Мөн бид доройтол байхгүй эсэхийг шалгах хэрэгтэй хэвээр байна. Эхний багцууд хурдан үр дүнд хүрч, дараа нь улам дордож, улам дорддог. Процесс нь маш их туршилт хийх шаардлагатай болдог. Мэдээллийн сангийн лаборатори яг ийм зорилготой юм.
Үүнийг үйлдвэрлэлд зөв дагаж мөрдөх боломжийг олгохын тулд бид ямар нэгэн зүйлийг бэлтгэх шаардлагатай хэвээр байна. Жишээлбэл, бид бүртгэлд цагаа бичиж болно, бид одоо хаана байгаа, хэнийг устгасан зэргийг бичиж болно. Энэ нь дараа нь юу болж байгааг ойлгох боломжийг бидэнд олгоно. Хэрэв ямар нэг зүйл буруу болвол асуудлыг хурдан олоорой.
Хэрэв бид хүсэлтийн үр ашгийг шалгах шаардлагатай бөгөөд бид олон удаа давтах шаардлагатай бол нөхөр бот гэх мэт зүйл байдаг. Тэр аль хэдийн бэлэн болсон. Үүнийг өдөр бүр олон арван хөгжүүлэгчид ашигладаг. Мөн тэрээр асар том терабайт мэдээллийн санг хүсэлтээр 30 секундын дотор өөрийн хуулбараар хэрхэн өгөхийг мэддэг. Та тэнд ямар нэг зүйлийг устгаад RESET гэж хэлээд дахин устгаж болно. Та үүнийг ингэж туршиж үзэж болно. Би энэ зүйлийн ирээдүйг харж байна. Мөн бид үүнийг аль хэдийн хийж байна.
Хуваах стратеги гэж юу вэ? Багц дээрх хөгжүүлэгчид ашиглаж буй 3 өөр хуваалтын стратегийг би харж байна.
Эхнийх нь маш энгийн. Бидэнд тоон ID байна. Үүнийг янз бүрийн интервалд хувааж, үүнтэй хамт ажиллацгаая. Сул тал нь ойлгомжтой. Эхний хэсэгт бид 100 эгнээ жинхэнэ хогтой байж магадгүй, хоёр дахь 5 мөрөнд эсвэл огт байхгүй, эсвэл 1 мөр бүгд хог болж хувирна. Маш жигд бус ажил, гэхдээ эвдэхэд хялбар байдаг. Тэд хамгийн дээд үнэмлэхийг нь аваад эвдэрсэн. Энэ бол гэнэн хандлага юм.
Хоёр дахь стратеги бол тэнцвэртэй хандлага юм. Үүнийг Gitlab-д ашигладаг. Тэд ширээг аваад сканнердсан. Бид ID багцуудын хил хязгаарыг олсон бөгөөд ингэснээр багц бүр яг 10 бичлэгтэй байв. Тэгээд тэднийг дараалалд оруулаарай. Тэгээд бид боловсруулдаг. Та үүнийг олон хэлхээнд хийж болно.
Эхний стратеги дээр та үүнийг хэд хэдэн хэлхээнд хийж болно. Энэ нь хэцүү биш юм.
Гэхдээ илүү сэрүүн, илүү сайн арга байдаг. Энэ бол гурав дахь стратеги юм. Боломжтой бол үүнийг сонгох нь дээр. Бид үүнийг тусгай индексийн үндсэн дээр хийдэг. Энэ тохиолдолд энэ нь бидний хог хаягдлын байдал, ID-ийн дагуу индекс байх магадлалтай. Бид ID-г оруулах бөгөөд энэ нь зөвхөн индексийг сканнердах бөгөөд ингэснээр бид бөөгнөрөл рүү орохгүй.
Ерөнхийдөө зөвхөн индексийг сканнердах нь индекс скан хийхээс хурдан байдаг.
Мөн бид устгахыг хүссэн ID-аа хурдан олдог. BATCH_SIZE-г бид урьдчилан сонгоно. Мөн бид зөвхөн тэднийг аваад зогсохгүй тусгай аргаар олж аваад шууд хакердана. Гэхдээ бид түгжиж байгаа бөгөөд хэрэв тэд аль хэдийн түгжигдсэн бол бид тэднийг түгжихгүй, харин цааш хөдөлж, дараагийнхыг нь авна. Энэ нь шинэчлэлтийг алгасах түгжээнд зориулагдсан. Postgres-ийн энэхүү супер онцлог нь хэрэв хүсвэл бид хэд хэдэн хэлхээнд ажиллах боломжийг олгодог. Энэ нь нэг урсгалаар боломжтой. Энд CTE байна - энэ бол нэг хүсэлт юм. Бид энэ CTE-ийн хоёрдугаар давхарт жинхэнэ устгал хийж байна - returning *. Та ID-г буцааж болно, гэхдээ энэ нь илүү дээр юм *хэрэв танд мөр бүрт тийм их мэдээлэл байхгүй бол.
Бидэнд яагаад хэрэгтэй байна вэ? Үүнийг бид эргэн мэдээлэх шаардлагатай байна. Одоо бид маш олон мөрийг устгасан. Мөн бид ID эсвэл create_at гэсэн хил хязгаартай байдаг. Та хамгийн бага, хамгийн ихдээ хийж болно. Өөр зүйл хийж болно. Та энд маш их зүйлийг хийж болно. Мөн хяналт тавихад маш тохиромжтой.
Индекстэй холбоотой бас нэг тэмдэглэл байна. Хэрэв бид энэ даалгаварт тусгай индекс хэрэгтэй гэж шийдсэн бол энэ нь зөвхөн багцын шинэчлэлтийг сүйтгэхгүй байх ёстой. Энэ нь Postgres ийм статистиктай байдаг. Үүнийг таны хүснэгтийн pg_stat_user_tables дээрээс харж болно. Халуун шинэчлэлтүүд ашиглагдаж байгаа эсэхийг харж болно.
Таны шинэ индекс тэдгээрийг зүгээр л таслах тохиолдол байдаг. Танд аль хэдийн ажиллаж байгаа бусад бүх шинэчлэлтүүд байгаа тул удаашруулна уу. Зөвхөн индекс гарч ирснээс биш (индекс бүр шинэчлэлтийг бага зэрэг удаашруулдаг, гэхдээ бага зэрэг), гэхдээ энд үүнийг сүйтгэсээр байна. Мөн энэ хүснэгтэд тусгай оновчлол хийх боломжгүй юм. Энэ нь заримдаа тохиолддог. Энэ бол цөөхөн хүн санаж байгаа маш нарийн зүйл юм. Мөн энэ тармуурыг гишгэхэд хялбар байдаг. Заримдаа та нөгөө талаас хандлагыг хайж олох хэрэгтэй бөгөөд энэ шинэ индексгүйгээр хийх, эсвэл өөр индекс хийх, эсвэл өөр аргаар, жишээлбэл, та хоёр дахь аргыг ашиглаж болно.
Гэхдээ энэ бол хамгийн оновчтой стратеги, хэрхэн багц болгон хувааж, нэг хүсэлтээр багцаар буудах, бага зэрэг устгах гэх мэт.
Урт хугацааны гүйлгээ
Блоклогдсон автовакуум -
блоклох асуудал -
Алдаа №5 бол маш том алдаа юм. Окметрээс Николай Постгресийн мониторингийн талаар ярьсан. Харамсалтай нь Postgres-ийн хамгийн тохиромжтой хяналт байхгүй байна. Зарим нь илүү ойр, зарим нь хол байдаг. Окметр төгс болоход хангалттай ойрхон байгаа ч маш их зүйл дутагдаж, нэмэх шаардлагатай. Та үүнд бэлэн байх хэрэгтэй.
Жишээлбэл, үхсэн залгууруудыг хамгийн сайн хянаж байдаг. Хэрэв та ширээн дээр маш олон үхсэн зүйл байгаа бол ямар нэг зүйл буруу байна гэсэн үг. Одоо хариу үйлдэл үзүүлэх нь дээр, эс тэгвээс доройтол үүсч магадгүй бөгөөд бид хэвтэж болно. Энэ нь тохиолддог.
Хэрэв том IO байгаа бол энэ нь сайн биш гэдэг нь тодорхой байна.
Мөн урт хугацааны гүйлгээ. OLTP дээр урт гүйлгээ хийхийг зөвшөөрөх ёсгүй. Мөн энд танд энэ хэсгийг авч, урт хугацааны гүйлгээг хянах боломжийг олгодог хэсэгчилсэн холбоос байна.
Урт хугацааны гүйлгээ яагаад муу байдаг вэ? Учир нь бүх түгжээ нь зөвхөн төгсгөлд нь гарах болно. Тэгээд бид хүн бүрийг хуурдаг. Дээрээс нь бид бүх хүснэгтэд автомат вакуумыг хаадаг. Энэ нь огт сайн биш юм. Хэдийгээр та хуулбар дээр халуун зогсолтыг идэвхжүүлсэн байсан ч энэ нь муу хэвээр байна. Ерөнхийдөө урт хугацааны гүйлгээнээс зайлсхийх нь хаана ч байхгүй.
Хэрэв бид тоос сорогдоогүй олон ширээтэй бол сэрэмжлүүлэг өгөх хэрэгтэй. Энд ийм нөхцөл байдал үүсэх боломжтой. Бид автовакуумын үйл ажиллагаанд шууд бусаар нөлөөлж болно. Энэ бол Avito-ийн хэсэг бөгөөд үүнийг би бага зэрэг сайжруулсан. Мөн энэ нь автовакуумаар бидэнд юу байгааг харах сонирхолтой хэрэгсэл болж хувирав. Жишээлбэл, зарим ширээ тэнд хүлээж байгаа бөгөөд ээлжээ хүлээхгүй. Та мөн үүнийг хяналтанд оруулж, сэрэмжлүүлэгтэй байх хэрэгтэй.
Мөн блокуудыг гаргадаг. Блок модны ой. Би хэн нэгнээс юм аваад сайжруулах дуртай. Энд би Data Egret-ээс цоож мод бүхий ойг харуулсан гайхалтай рекурсив CTE авсан. Энэ бол оношлогооны сайн хэрэгсэл юм. Үүний үндсэн дээр та мониторинг хийж болно. Гэхдээ үүнийг болгоомжтой хийх хэрэгтэй. Та өөртөө зориулж жижиг мэдэгдэл_цаг хугацаа хийх хэрэгтэй. Мөн lock_timeout нь зүйтэй юм.
Заримдаа эдгээр бүх алдаа нийлбэрээр тохиолддог.
Миний бодлоор энд байгаа гол алдаа бол зохион байгуулалттай холбоотой. Энэ нь зохион байгуулалттай, учир нь техник нь татдаггүй. Энэ бол 2 дугаар - тэд буруу газар шалгасан.
Бид шалгахад хялбар үйлдвэрлэлийн клон байхгүй тул буруу газар шалгасан. Хөгжүүлэгч нь үйлдвэрлэлд нэвтрэх эрхгүй байж болно.
Тэгээд бид тэнд шалгаагүй. Тэнд шалгасан бол бид өөрсдөө үзэх байсан. Хөгжүүлэгч нь DBA-гүй ч гэсэн ижил хэмжээний өгөгдөлтэй, ижил байршилтай сайн орчинд шалгаж үзсэн бол бүгдийг нь харсан. Тэр энэ бүх доройтлыг харж, ичиж зовох байсан.
Автовакуумын талаар дэлгэрэнгүй. Хэдэн сая мөрийг их хэмжээгээр шүүрсний дараа бид REPACK хийх шаардлагатай хэвээр байна. Энэ нь ялангуяа индексийн хувьд чухал юм. Бид тэнд байгаа бүх зүйлийг цэвэрлэсний дараа тэд эвгүй байдалд орох болно.
Хэрэв та өдөр тутмын цэвэрлэгээний ажлыг буцааж өгөхийг хүсч байвал би үүнийг илүү олон удаа хийхийг зөвлөж байна, гэхдээ бага байна. Энэ нь минутанд нэг удаа эсвэл бүр илүү олон удаа байж болно. Мөн та хоёр зүйлийг хянах хэрэгтэй: энэ зүйлд алдаа байхгүй, хоцрохгүй байх. Миний үзүүлсэн заль үүнийг л шийдэх болно.
Бидний хийдэг зүйл бол нээлттэй эх сурвалж юм. Энэ нь GitLab дээр тавигдсан. Мөн бид үүнийг DBA-гүй байсан ч хүмүүс шалгах боломжтой болгодог. Бид мэдээллийн сангийн лаборатори хийж байна, өөрөөр хэлбэл Жоегийн ажиллаж байгаа үндсэн бүрэлдэхүүн хэсэг гэж нэрлэдэг. Мөн та үйлдвэрлэлийн хуулбарыг авч болно. Одоо Joe for slack-ийн хэрэгжилт байна, та тэнд "ийм, ийм хүсэлтийг тайлбарла" гэж хэлээд мэдээллийн сангийн хуулбарынхаа үр дүнг шууд авах боломжтой. Та тэнд УСТГАХ ч болно, хэн ч үүнийг анзаарахгүй.
Танд 10 терабайт байна гэж бодъё, бид мэдээллийн сангийн лабораторийг мөн 10 терабайт болгодог. Мөн нэгэн зэрэг 10 терабайт мэдээллийн баазтай бол 10 хөгжүүлэгчид нэгэн зэрэг ажиллах боломжтой. Хүн бүр хүссэнээ хийж чадна. Устгах, унагах гэх мэт. Энэ бол уран зөгнөл юм. Бид маргааш энэ талаар ярих болно.
Үүнийг нимгэн хангамж гэж нэрлэдэг. Энэ бол нарийн зохицуулалт юм. Энэ бол хөгжүүлэлт, туршилтын хоцролтыг ихээхэн арилгаж, дэлхийг энэ талаар илүү сайн газар болгодог нэг төрлийн уран зөгнөл юм. Өөрөөр хэлбэл, энэ нь бөөнөөр үйл ажиллагаа явуулахтай холбоотой асуудлаас зайлсхийх боломжийг танд олгоно.
Жишээ нь: 5 терабайт мэдээллийн сан, 30 секундээс бага хугацаанд хуулбарыг авах. Мөн энэ нь хэмжээнээс ч хамаардаггүй, өөрөөр хэлбэл хэдэн терабайт байх нь хамаагүй.
Өнөөдөр та очиж болно мөн бидний багаж хэрэгслийг ухаж . Та тэнд юу байгааг харахын тулд бүртгүүлж болно. Та энэ роботыг суулгаж болно. Энэ Үнэгүй. бичих.
Асуултууд
Бодит нөхцөл байдалд ихэвчлэн хүснэгтэд үлдэх ёстой өгөгдөл нь устгах шаардлагатай хэмжээнээс хамаагүй бага байдаг. Өөрөөр хэлбэл, ийм нөхцөлд шинэ объект үүсгэх, зөвхөн шаардлагатай өгөгдлийг хуулж, хуучин хүснэгтийг хадгалахад хялбар байх үед ийм аргыг хэрэгжүүлэх нь ихэвчлэн хялбар байдаг. Таныг солих гэж байгаа энэ мөчид программчлагдсан хандлага хэрэгтэй байгаа нь тодорхой байна. Энэ хандлага ямар байна вэ?
Энэ бол маш сайн арга барил, маш сайн ажил юм. Энэ нь pg_repack-ийн хийдэг зүйлтэй маш төстэй бөгөөд ID-г 4 байт болгоход хийх ёстой зүйлтэй маш төстэй юм. Олон фреймворкууд хэдэн жилийн өмнө үүнийг хийсэн бөгөөд зүгээр л ялтсууд өссөн бөгөөд тэдгээрийг 8 байт болгон хөрвүүлэх шаардлагатай болсон.
Энэ даалгавар нэлээд хэцүү. Бид үүнийг хийсэн. Мөн та маш болгоомжтой байх хэрэгтэй. Түгжээ гэх мэт.Гэхдээ хийгдэж байна. Өөрөөр хэлбэл, стандарт арга бол pg_repack-тай ажиллах явдал юм. Та ийм шошго зарлаж байна. Мөн та агшин зуурын өгөгдлийг байршуулж эхлэхээсээ өмнө бүх өөрчлөлтийг дагаж мөрддөг нэг хавтанг зарлана. Зарим өөрчлөлтийг ч хянахгүй байж магадгүй гэсэн заль мэх бий. Нарийн мэдрэмжүүд байдаг. Дараа нь та өнхрөх өөрчлөлтөөр солигдоно. Бүгдийг хаах үед богино завсарлага байх болно, гэхдээ ерөнхийдөө үүнийг хийж байна.
Хэрэв та GitHub дээрх pg_repack-г харвал ID-г int 4-ээс int 8 руу хөрвүүлэх даалгавар гарч ирэхэд pg_repack-г өөрөө ашиглах санаа гарч ирсэн. Энэ нь бас боломжтой, гэхдээ энэ нь хакердах арга юм, гэхдээ энэ нь бас үүнийг хийх болно. Та pg_repack-ийн ашигладаг триггерт оролцож, "Бидэнд энэ өгөгдөл хэрэггүй" гэж хэлж болно, өөрөөр хэлбэл бид зөвхөн хэрэгтэй зүйлээ шилжүүлдэг. Тэгээд тэр зүгээр л солигддог, тэгээд л болоо.
Энэ аргын тусламжтайгаар бид өгөгдлийг аль хэдийн индексжүүлсэн, үзэсгэлэнтэй индексүүдээр маш жигд овоолсон хүснэгтийн хоёр дахь хуулбарыг авсаар байна.
Bloat байхгүй, энэ нь сайн арга юм. Гэхдээ үүний тулд автоматжуулалтыг хөгжүүлэх, өөрөөр хэлбэл бүх нийтийн шийдэл гаргах оролдлого байгааг би мэднэ. Би тантай энэ автоматжуулалттай холбогдож болно. Энэ нь Python дээр бичигдсэн байдаг нь сайн хэрэг.
Би MySQL-ийн ертөнцөөс жаахан хүн болохоор сонсох гэж ирсэн юм. Мөн бид энэ аргыг ашигладаг.
Гэхдээ 90 хувьтай байхад л болно. Хэрэв бид 5% байгаа бол үүнийг ашиглах нь тийм ч сайн биш юм.
Мэдээлэл өгсөнд баярлалаа! Хэрэв бүтээгдэхүүний бүрэн хуулбарыг хийх нөөц байхгүй бол ачаалал, хэмжээг тооцоолох алгоритм эсвэл томъёо байдаг уу?
Сайн асуулт. Одоогоор бид олон терабайт мэдээллийн санг олох боломжтой. Тэнд байгаа техник хангамж нь ижил биш байсан ч, жишээ нь санах ой, процессор, диск бага зэрэг нь яг адилхан биш, гэхдээ бид үүнийг хийдэг. Хэрэв үнэхээр хаана ч байхгүй бол та бодох хэрэгтэй. Маргааш хүртэл бодъё, чи ирлээ, ярилцъя, энэ сайхан асуулт байна.
Мэдээлэл өгсөнд баярлалаа! Та эхлээд ийм ийм хязгаарлалттай, тийм ч сайнгүй Postgres байдаг, гэхдээ энэ нь хөгжиж байна гэж эхэлсэн. Мөн энэ нь бүхэлдээ таяг юм. Энэ бүхэн Postgres-ийн хөгжилтэй зөрчилдөж байгаа бөгөөд үүнд зарим DELETE deferent гарч ирэх эсвэл бидний зарим хачирхалтай хэрэгслээр түрхэхийг оролдож буй зүйлийг бага түвшинд байлгах ёстой өөр зүйл биш гэж үү?
Хэрэв бид SQL дээр нэг гүйлгээнд олон бүртгэлийг устгах эсвэл шинэчлэхийг хэлсэн бол Postgres үүнийг яаж тэнд түгээх вэ? Бид үйл ажиллагааны хувьд бие махбодийн хувьд хязгаарлагдмал байдаг. Бид үүнийг удаан хугацаанд хийх болно. Мөн бид энэ үед түгжих болно гэх мэт.
Индексүүд дууссан.
Үүнтэй ижил хяналтын цэгийн тохируулгыг автоматжуулж болно гэж би бодож байна. Хэзээ нэгэн цагт ийм байж магадгүй. Гэхдээ би асуултыг үнэхээр ойлгохгүй байна.
Асуулт бол энд тэнд явж байгаа хөгжлийн вектор, энд таных зэрэгцэн явдаг хөгжлийн вектор байна уу? Тэдгээр. Тэд энэ талаар хараахан бодож амжаагүй байна уу?
Одоо хэрэглэгдэж болох зарчмуудын тухай ярилаа. Өөр робот байна , үүгээр та хяналтын цэгийн автомат тохируулга хийх боломжтой. Хэзээ нэгэн цагт Постгрес хотод байх болов уу? Мэдэхгүй ээ, одоо болтол хэлэлцээгүй л байна. Бид үүнээс хол хэвээр байна. Гэхдээ шинэ систем хийдэг эрдэмтэд байдаг. Мөн тэд биднийг автомат индекст оруулдаг. Хөгжил бий. Жишээлбэл, та автомат тохируулгыг харж болно. Энэ нь параметрүүдийг автоматаар сонгоно. Гэхдээ тэр танд хараахан шалган нэвтрүүлэх цэгийн тохируулга хийхгүй. Энэ нь гүйцэтгэл, бүрхүүлийн буфер гэх мэтийг сонгох болно.
Шалгах цэгийг тааруулахын тулд та үүнийг хийж болно: хэрэв танд мянга мянган кластер, өөр өөр техник хангамж, үүлэн дотор өөр өөр виртуал машин байгаа бол та манай роботыг ашиглаж болно. автоматжуулалт хийх. Мөн max_wal_size нь таны зорилтот тохиргооны дагуу автоматаар сонгогдох болно. Гэвч харамсалтай нь энэ нь үндсэндээ ойр ч биш байна.
Өдрийн мэнд Та урт хугацааны гүйлгээний аюулын талаар ярьсан. Та устгасан тохиолдолд автовакуумыг хаадаг гэж хэлсэн. Энэ нь бидэнд өөр ямар хор хөнөөл учруулах вэ? Яагаад гэвэл бид орон зайг чөлөөлөх, ашиглах боломжтой байх талаар илүү их ярьж байна. Бидэнд өөр юу дутагдаж байна вэ?
Автовакуум нь энд хамгийн том асуудал биш байж магадгүй юм. Мөн урт гүйлгээ нь бусад гүйлгээг түгжих боломжтой тул энэ боломж нь илүү аюултай юм. Тэр уулзаж ч болно, уулзахгүй ч байж болно. Хэрэв тэр уулзсан бол энэ нь маш муу байж магадгүй юм. Мөн автовакуумтай бол энэ нь бас асуудал юм. OLTP-д урт хугацааны гүйлгээ хийхэд хоёр асуудал байдаг: цоож, автовакуум. Хэрэв та хуулбар дээр халуун зогсолтын санал хүсэлтийг идэвхжүүлсэн бол мастер дээр автомат вакуум түгжээг хүлээн авах болно, энэ нь хуулбараас ирэх болно. Гэхдээ наад зах нь цоож байхгүй болно. Мөн локууд байх болно. Бид өгөгдлийн өөрчлөлтийн талаар ярьж байгаа тул түгжээ нь энд чухал зүйл юм. Хэрэв энэ бүхэн удаан, удаан үргэлжилбэл улам олон гүйлгээ түгжигдэнэ. Тэд бусдыг хулгайлж чадна. Мөн лок моднууд гарч ирнэ. Би хэсэгчилсэн холбоосыг өгсөн. Мөн энэ асуудал нь зөвхөн хуримтлагдах боломжтой автовакуумтай холбоотой асуудлаас илүү хурдан мэдэгдэхүйц болдог.
Мэдээлэл өгсөнд баярлалаа! Та шалгалтаа буруу хийсэн гэж тайлангаа эхлүүлсэн. Бид ижил тоног төхөөрөмж, суурьтай нь адилхан авах хэрэгтэй гэсэн санаагаа үргэлжлүүлэв. Бид хөгжүүлэгчийг суурь болгосон гэж бодъё. Тэгээд тэр хүсэлтийг биелүүлсэн. Тэгээд тэр зүгээр байгаа бололтой. Гэхдээ тэр амьд эсэхийг шалгадаггүй, харин амьдаар нь, жишээ нь, манайд 60-70 хувийн ачаалалтай байдаг. Мөн бид энэ тохируулгыг ашигласан ч тийм ч сайн ажиллахгүй.
Багийн бүрэлдэхүүнд мэргэжилтэнтэй байх, бодит суурь ачаалалтай үед юу болохыг урьдчилан таамаглаж чадах DBA мэргэжилтнүүдийг ашиглах нь чухал юм. Бид зүгээр л цэвэр өөрчлөлтүүдээ жолоодох үед бид зургийг харж байна. Гэхдээ илүү дэвшилтэт арга, бид ижил зүйлийг дахин хийх үед, гэхдээ үйлдвэрлэлийн дуурайлган ачаалалтай. Энэ их дажгүй. Тэр болтол та томрох хэрэгтэй. Энэ нь насанд хүрсэн хүн шиг юм. Бид байгаа зүйлээ л харлаа, бас хангалттай нөөц байгаа эсэхээ ч харлаа. Сайхан асуулт байна.
Бид аль хэдийн хог хаягдлыг сонгохдоо хийж байгаа бөгөөд жишээ нь устгасан туг байна
Энэ нь Postgres-д автоматаар автомат вакуум хийдэг зүйл юм.
Өө, тэр үүнийг хийдэг үү?
Автовакуум бол хог цуглуулагч юм.
Баярлалаа!
Мэдээлэл өгсөнд баярлалаа! Бүх хог хаягдал үндсэн ширээнээс хаа нэгтээ хажуу тийшээ бохирддог байдлаар хуваалттай мэдээллийн санг нэн даруй төлөвлөх сонголт бий юу?
Мэдээж надад байгаа.
Ашиглах ёсгүй ширээг түгжсэн бол өөрсдийгөө хамгаалах боломжтой юу?
Мэдээж байгаа. Гэхдээ энэ нь тахиа, өндөгний асуулт шиг юм. Ирээдүйд юу болохыг бид бүгд мэдэж байгаа бол мэдээжийн хэрэг бид бүх зүйлийг сайхан хийх болно. Гэхдээ бизнес өөрчлөгдөж, шинэ багана, шинэ хүсэлтүүд гарч байна. Тэгээд дараа нь - Өө, бид үүнийг арилгахыг хүсч байна. Гэхдээ энэ нь хамгийн тохиромжтой нөхцөл байдал, амьдралд тохиолддог, гэхдээ үргэлж биш юм. Гэхдээ ерөнхийдөө энэ бол сайн санаа. Зүгээр л тайр, тэгээд л болоо.
Эх сурвалж: www.habr.com