Сайн байна уу
Намайг Ваня гэдэг, би Java хөгжүүлэгч. Тиймээс би PostgreSQL-тэй маш их ажилладаг - мэдээллийн баазыг тохируулах, бүтэц, гүйцэтгэлийг оновчтой болгох, амралтын өдрүүдэд бага зэрэг DBA тоглох.
Саяхан би микро үйлчилгээнийхээ хэд хэдэн мэдээллийн санг цэгцэлж, java номын сан бичсэн , энэ нь энэ ажлыг хөнгөвчлөх нь миний цагийг хэмнэж, хөгжүүлэгчдийн гаргадаг нийтлэг алдаанаас зайлсхийхэд тусалдаг. Энэ номын сангийн тухай бид өнөөдөр ярих болно.
Disclaimer
Миний ажилладаг PostgreSQL-ийн үндсэн хувилбар бол 10. Миний ашигладаг бүх SQL асуулга 11-р хувилбар дээр бас шалгагдсан. Хамгийн бага дэмжигдсэн хувилбар нь 9.6.
Эрьт урьдын түүх
Энэ бүхэн бараг жилийн өмнө надад хачирхалтай байсан нөхцөл байдлаас эхэлсэн: өрсөлдөөнт индексийг гэнэт бий болгох нь алдаагаар дууссан. Индекс өөрөө ердийнх шигээ мэдээллийн санд хүчингүй байдалд байсан. Бүртгэлийн шинжилгээ дутагдалтай байгааг харуулсан . Тэгээд бид явлаа... Гүн ухаж, би мэдээллийн сангийн тохиргоонд бүхэл бүтэн асуудал байгааг олж мэдээд, ханцуй шамлан нүдээ гялалзуулан засаж эхлэв.
Асуудал нэг - анхдагч тохиргоо
Кофе чанагч дээр ажиллуулж болох Postgres-ийн тухай зүйрлэлээс хүн бүр нэлээд залхсан байх, гэхдээ ... анхдагч тохиргоо нь үнэхээр олон асуултыг төрүүлдэг. Наад зах нь анхаарлаа хандуулах нь зүйтэй засвар үйлчилгээний_ажлын_сан, temp_file_limit, мэдэгдэл_хугацаа и түгжих_хугацаа.
Манай тохиолдолд засвар үйлчилгээний_ажлын_сан анхдагч байсан 64 MB, болон temp_file_limit 2 ГБ орчим ямар нэг зүйл - бидэнд том ширээн дээр индекс үүсгэх хангалттай санах ой байхгүй байсан.
Тиймээс, онд pg-индекс-эрүүл мэнд Би цуврал цуглуулсан , миний бодлоор өгөгдлийн сан бүрийн хувьд тохируулах ёстой параметрүүд.
Хоёр дахь асуудал - давхардсан индексүүд
Манай мэдээллийн сан SSD хөтчүүд дээр амьдардаг бөгөөд бид ашигладаг HA-олон дата төв, мастер хост болон тохиргоо n- хуулбарын тоо. Дискний зай нь бидний хувьд маш үнэ цэнэтэй нөөц юм; Энэ нь гүйцэтгэл, CPU-ийн хэрэглээнээс дутахгүй чухал юм. Тиймээс, нэг талаас, хурдан уншихад индекс хэрэгтэй, нөгөө талаас бид мэдээллийн санд шаардлагагүй индексүүдийг харахыг хүсэхгүй байна, учир нь тэдгээр нь зай эзэлдэг, мэдээлэл шинэчлэх ажлыг удаашруулдаг.
Тэгээд одоо бүх зүйлийг сэргээсэн бас хангалттай үзсэн , Би "агуу" цэвэрлэгээ зохион байгуулахаар шийдсэн. Хөгжүүлэгчид мэдээллийн сангийн баримт бичгийг унших дургүй байдаг нь тогтоогдсон. Тэд тийм ч их дургүй байдаг. Үүнээс болж хоёр ердийн алдаа гарч ирдэг - үндсэн түлхүүр дээр гараар үүсгэсэн индекс ба өвөрмөц багана дээрх ижил төстэй "гарын авлагын" индекс. Үнэн хэрэгтээ тэд шаардлагагүй - Postgres бүх зүйлийг өөрөө хийх болно. Ийм индексийг аюулгүйгээр устгаж болох бөгөөд энэ зорилгоор оношилгоо гарч ирэв .
Гурав дахь асуудал - огтлолцох индекс
Ихэнх шинэхэн хөгжүүлэгчид нэг баганад индекс үүсгэдэг. Аажмаар, энэ бизнесийг сайтар туршиж үзсэнийхээ дараа хүмүүс асуулгаа оновчтой болгож, хэд хэдэн багана агуулсан илүү төвөгтэй индексүүдийг нэмж эхэлдэг. Баганууд дээрх индексүүд ингэж гарч ирдэг A, A + B, A+B+C гэх мэт. Эдгээр индексүүдийн эхний хоёр нь гурав дахь индексийн угтвар тул аюулгүйгээр хаяж болно. Энэ нь мөн дискний зайг их хэмжээгээр хэмнэдэг бөгөөд үүнд зориулсан оношлогоо байдаг .
Дөрөв дэх асуудал - индексгүй гадаад түлхүүрүүд
Postgres нь танд туслах индексийг заахгүйгээр гадаад түлхүүрийн хязгаарлалт үүсгэх боломжийг олгодог. Олон тохиолдолд энэ нь асуудал биш, бүр өөрийгөө илэрхийлэхгүй ч байж магадгүй ... Одоогоор...
Бидэнд ч мөн адил байсан: яг л цагийн хуваарийн дагуу ажиллаж, туршилтын захиалгын мэдээллийн санг цэвэрлэж байсан ажлыг мастер хост бидэнд "нэмж" эхэлсэн. CPU болон IO дэмий хоосон болж, хүсэлтүүд удааширч, хугацаа нь дууссан, үйлчилгээ таван зуун болсон. Шуурхай шинжилгээ гэсэн асуултууд дараах байдалтай байгааг харуулсан.
delete from <table> where id in (…)Энэ тохиолдолд мэдээж зорилтот хүснэгтэд id-ийн индекс байсан бөгөөд нөхцөл байдлын дагуу маш цөөхөн бичлэг устгагдсан. Бүх зүйл ажиллах ёстой юм шиг санагдаж байсан ч, харамсалтай нь, тэгсэнгүй.
Гайхалтай нь аврахаар ирэв дүн шинжилгээ хийж тайлбарлах Зорилтот хүснэгтийн бүртгэлийг устгахаас гадна лавлагааны бүрэн бүтэн байдлын шалгалт байдаг бөгөөд холбогдох хүснэгтүүдийн аль нэгэнд энэ шалгалт амжилтгүй болсон гэж хэлсэн. дараалсан сканнердах тохирох индекс байхгүйгээс шалтгаална. Ийнхүү оношилгоо үүссэн .
Асуулт тав – индекс дэх тэг утга
Анхдагч байдлаар Postgres нь btree индекс дэх хоосон утгыг агуулдаг боловч тэдгээр нь ихэвчлэн шаардлагагүй байдаг. Тиймээс, би эдгээр тоонуудыг арилгахыг хичээнгүйлэн хичээдэг (оношлогоо ), төрлөөр нь тэглэх баганууд дээр хэсэгчилсэн индекс үүсгэх where <A> is not null. Ийм байдлаар би нэг индексийнхээ хэмжээг 1877 МБ-аас 16 КБ болгон бууруулж чадсан. Мөн нэг үйлчилгээнд индексээс тэг утгыг хассанаас болж мэдээллийн сангийн хэмжээ нийтдээ 16% (үнэмлэхүй тоогоор 4.3 ГБ) буурсан байна. Маш энгийн өөрчлөлтүүдээр дискний зайг асар их хэмнэнэ. 🙂
Асуудал зургаа - үндсэн түлхүүр байхгүй
Механизмын шинж чанараас шалтгаалан ийм нөхцөл байдал үүсэх боломжтой олон тооны үхсэн бичлэгийн улмаас таны хүснэгтийн хэмжээ хурдацтай өсч байгаа үед. Энэ нь бидэнд аюул занал учруулахгүй, манай баазад ийм зүйл тохиолдохгүй гэж би гэнэн итгэсэн, учир нь бид, хөөх!!!, жирийн хөгжүүлэгчид... Би ямар тэнэг, гэнэн байсан бэ...
Нэгэн өдөр нэгэн гайхалтай нүүдэл нь том, идэвхтэй ашиглагддаг хүснэгтийн бүх бүртгэлийг авч, шинэчилсэн юм. Бид санамсаргүйгээр ширээний хэмжээнээс +100 ГБ авсан. Энэ нь үнэхээр ичмээр байсан ч бидний золгүй явдал үүгээр дууссангүй. Энэ ширээн дээрх автовакуум 15 цагийн дараа дууссаны дараа физик байрлал буцаж ирэхгүй нь тодорхой болсон. Бид үйлчилгээгээ зогсоож, ВАКУМ БҮТЭН болгож чадаагүй тул ашиглахаар шийдсэн . Тэгээд тэр нь тодорхой болсон pg_repack нь үндсэн түлхүүр болон бусад өвөрмөц байдлын хязгаарлалтгүйгээр хүснэгтүүдийг хэрхэн боловсруулахаа мэддэггүй бөгөөд манай хүснэгтэд үндсэн түлхүүр байхгүй байсан. Ийнхүү оношилгоо үүссэн .
Номын сангийн хувилбарт 0.1.5 Хүснэгт, индексээс мэдээлэл цуглуулж, цаг тухайд нь хариу өгөх чадварыг нэмсэн.
Долоо, найм дахь асуудал - индекс хангалтгүй, ашиглагдаагүй индекс
Дараах хоёр оношлогоо нь: и - харьцангуй саяхан эцсийн хэлбэрээр гарч ирэв. Гол нь тэдгээрийг зүгээр л авч, нэмэх боломжгүй юм.
Би аль хэдийн бичсэнчлэн бид хэд хэдэн хуулбартай тохиргоог ашигладаг бөгөөд өөр өөр хостууд дээрх унших ачаалал үндсэндээ өөр байна. Үүний үр дүнд зарим хостууд дээрх зарим хүснэгт, индексүүд бараг ашиглагдаагүй байгаа тул дүн шинжилгээ хийхийн тулд кластер дахь бүх хостуудаас статистик мэдээллийг цуглуулах шаардлагатай болж байна. Энэ нь кластер дахь бүх хост дээр шаардлагатай бөгөөд та үүнийг зөвхөн мастер дээр хийх боломжгүй.
Энэ арга нь хэзээ ч ашиглагдаагүй индексүүдийг устгах, мөн ховор хэрэглэгддэг хүснэгтүүдэд дутуу индекс нэмэх замаар хэдэн арван гигабайт хэмнэх боломжийг бидэнд олгосон.
Дүгнэлт
Мэдээжийн хэрэг, бараг бүх оношлогооны хувьд та тохируулж болно . Ингэснээр та шинэ алдаа гарч ирэхээс сэргийлж, програмдаа шалгалтыг хурдан хийж, хуучин алдааг аажмаар засах боломжтой.
Өгөгдлийн сангийн шилжилт хөдөлгөөнийг нэвтрүүлсний дараа функциональ тестээр зарим оношийг нэн даруй хийж болно. Энэ нь магадгүй миний номын сангийн хамгийн хүчирхэг шинж чанаруудын нэг юм. Хэрэглэх жишээг эндээс олж болно .
Зөвхөн бодит мэдээллийн сан дээр ашиглагдаагүй эсвэл дутуу индекс, мөн хавдсан эсэхийг шалгах нь утга учиртай юм. Цуглуулсан утгыг бүртгэж болно эсвэл хяналтын систем рүү илгээнэ.
Би үүнд үнэхээр найдаж байна pg-индекс-эрүүл мэнд ашигтай, эрэлт хэрэгцээтэй байх болно. Мөн та олсон асуудлаа мэдээлж, шинэ оношилгоо санал болгосноор номын сангийн хөгжилд хувь нэмрээ оруулах боломжтой.
Эх сурвалж: www.habr.com