PostgreSQL-dagi indekslarning salomatligi Java dasturchisi nazarida

Salom.

Mening ismim Vanya va men Java dasturchisiman. Shunday bo'ladiki, men PostgreSQL bilan juda ko'p ishlayman - ma'lumotlar bazasini sozlash, tuzilmani, ishlashni optimallashtirish va dam olish kunlarida ozgina DBA o'ynash.

Yaqinda men mikroservislarimizdagi bir nechta ma'lumotlar bazalarini tartibga keltirdim va java kutubxonasini yozdim pg-index-salomatlik, bu ishni osonlashtiradi, vaqtimni tejaydi va ishlab chiquvchilar tomonidan yo'l qo'yiladigan ba'zi keng tarqalgan xatolardan qochishga yordam beradi. Aynan shu kutubxona haqida bugun gaplashamiz.

PostgreSQL-dagi indekslarning salomatligi Java dasturchisi nazarida

MasΚΌuliyatdan voz kechish

Men ishlayotgan PostgreSQL ning asosiy versiyasi 10 ta. Men foydalanadigan barcha SQL so'rovlari 11-versiyada ham sinovdan o'tgan. Minimal qo'llab-quvvatlanadigan versiya - 9.6.

Sana oldin

Hammasi deyarli bir yil oldin men uchun g'alati bo'lgan vaziyat bilan boshlandi: ko'kdan indeksni raqobatbardosh yaratish xato bilan yakunlandi. Indeksning o'zi, odatdagidek, ma'lumotlar bazasida yaroqsiz holatda qoldi. Jurnal tahlili etishmovchilikni ko'rsatdi temp_fayl_chegarasi. Va ketamiz... Chuqurroq qazib, maΚΌlumotlar bazasi konfiguratsiyasidagi bir qancha muammolarni topdim va yenglarimni shimarib, koΚ»zlarim chaqnab, ularni tuzatishga kirishdim.

Birinchi muammo - standart konfiguratsiya

Ehtimol, hamma allaqachon Postgres haqidagi metaforadan juda charchagan, uni qahva qaynatgichda ishlatish mumkin, lekin ... standart konfiguratsiya haqiqatan ham bir qator savollar tug'diradi. Hech bo'lmaganda, bunga e'tibor berishga arziydi texnik_ish_mem, temp_fayl_chegarasi, bayonot_vaqt tugashi ΠΈ lock_timeout.

Bizning holatda texnik_ish_mem standart bo'lgan 64 MB, va temp_fayl_chegarasi 2 GB atrofida bir narsa - bizda katta stolda indeks yaratish uchun etarli xotira yo'q edi.

Shuning uchun, in pg-index-salomatlik Men bir qator to'pladim kalit, menimcha, har bir ma'lumotlar bazasi uchun sozlanishi kerak bo'lgan parametrlar.

Ikkinchi muammo - ikki nusxadagi indekslar

Bizning ma'lumotlar bazalarimiz SSD disklarida yashaydi va biz foydalanamiz HA-konfiguratsiya bir nechta ma'lumotlar markazlari, asosiy xost va n- nusxalar soni. Disk maydoni biz uchun juda qimmatli manbadir; bu unumdorlik va CPU iste'molidan kam emas. Shuning uchun, bir tomondan, tez o'qish uchun indekslar kerak, boshqa tomondan, biz ma'lumotlar bazasida keraksiz indekslarni ko'rishni xohlamaymiz, chunki ular bo'sh joyni egallaydi va ma'lumotlarni yangilashni sekinlashtiradi.

Va endi, hamma narsani tikladi noto'g'ri indekslar va etarlicha ko'rgan Oleg Bartunov xabar beradi, Men "buyuk" tozalashni tashkil etishga qaror qildim. Ma'lum bo'lishicha, ishlab chiquvchilar ma'lumotlar bazasi hujjatlarini o'qishni yoqtirmaydilar. Ularga unchalik yoqmaydi. Shu sababli ikkita odatiy xatolik yuzaga keladi - asosiy kalitda qo'lda yaratilgan indeks va noyob ustundagi shunga o'xshash "qo'lda" indeks. Gap shundaki, ular kerak emas - Postgres hamma narsani o'zi qiladi. Bunday indekslar xavfsiz tarzda o'chirilishi mumkin va bu maqsadda diagnostika paydo bo'ldi duplicated_indexes.

Uchinchi masala - kesishgan indekslar

Ko'pgina yangi ishlab chiquvchilar indekslarni bitta ustunda yaratadilar. Asta-sekin, ushbu biznesni sinchkovlik bilan boshdan kechirgandan so'ng, odamlar o'zlarining so'rovlarini optimallashtirishni va bir nechta ustunlarni o'z ichiga olgan murakkabroq indekslarni qo'shishni boshlaydilar. Ustunlardagi indekslar shunday ko'rinadi A, A + B, A+B+C va h.k. Ushbu indekslarning dastlabki ikkitasi xavfsiz tarzda chiqarib tashlanishi mumkin, chunki ular uchinchisining prefikslaridir. Bu shuningdek, juda ko'p disk maydonini tejaydi va buning uchun diagnostika mavjud kesishgan_indekslar.

To'rtinchi muammo - indekssiz xorijiy kalitlar

Postgres sizga qo'llab-quvvatlovchi indeksni ko'rsatmasdan xorijiy kalit cheklovlarini yaratishga imkon beradi. Ko'p hollarda bu muammo emas va hatto o'zini namoyon qilmasligi mumkin ... Hozircha ...

Biz bilan ham xuddi shunday bo'ldi: shunchaki bir vaqtning o'zida jadval bo'yicha ishlaydigan va test buyurtmalari ma'lumotlar bazasini tozalaydigan ish master xost tomonidan bizga "qo'shila" boshladi. CPU va IO isrof bo'ldi, so'rovlar sekinlashdi va vaqt tugaydi, xizmat besh yuzga etdi. Tez tahlil pg_stat_activity quyidagi kabi so'rovlar ekanligini ko'rsatdi:

delete from <table> where id in (…)

Bu holatda, albatta, maqsadli jadvalda id bo'yicha indeks mavjud edi va shartga ko'ra juda kam yozuvlar o'chirildi. Hamma narsa ishlashi kerakdek tuyuldi, lekin, afsuski, bunday bo'lmadi.

Ajoyib kishi yordamga keldi tahlilini tushuntiring va maqsadli jadvaldagi yozuvlarni o'chirishdan tashqari, havolaning yaxlitligini tekshirish ham mavjudligini aytdi va tegishli jadvallardan birida bu tekshiruv muvaffaqiyatsiz tugadi. ketma-ket skanerlash tegishli indeks yo'qligi sababli. Shunday qilib, diagnostika tug'ildi xorijiy_kalitlar_indekssiz.

Beshinchi muammo - indekslardagi nol qiymat

Odatiy bo'lib, Postgres btree indekslarida null qiymatlarni o'z ichiga oladi, lekin ular odatda kerak emas. Shuning uchun men ushbu nulllarni (diagnostika null_qiymatlari bilan_indekslar), turi bo'yicha null bo'ladigan ustunlarda qisman indekslarni yaratish where <A> is not null. Shu tarzda men indekslarimizdan birining hajmini 1877 MB dan 16 KB gacha qisqartirishga muvaffaq bo'ldim. Va xizmatlardan birida ma'lumotlar bazasi hajmi indekslardan nol qiymatlar chiqarib tashlanganligi sababli jami 16% ga (mutlaq raqamlarda 4.3 GB ga) kamaydi. Juda oddiy o'zgartirishlar bilan disk maydonida katta tejash. πŸ™‚

Oltinchi muammo - asosiy kalitlarning etishmasligi

Mexanizmning tabiatiga ko'ra Postgresdagi MVCC bunday holat bo'lishi mumkin shishiradiko'p sonli o'lik yozuvlar tufayli stolingiz hajmi tez o'sib borayotganida. Bu bizga tahdid qilmasligiga va bizning bazamiz bilan bu sodir bo'lmasligiga soddalik bilan ishonardim, chunki biz, voy!!!, oddiy ishlab chiquvchilarmiz... Men qanchalik ahmoq va sodda edim...

Bir kuni ajoyib migratsiya katta va faol foydalaniladigan jadvaldagi barcha yozuvlarni olib, yangiladi. Biz stol o'lchamiga +100 GB ga ega bo'ldik. Bu juda sharmandalik edi, lekin bizning baxtsizliklarimiz shu bilan tugamadi. Ushbu stol ustidagi avtovakuum 15 soatdan keyin tugaganidan so'ng, jismoniy joylashuvi qaytib kelmasligi aniq bo'ldi. Biz xizmatni to'xtata olmadik va VACUUM FULL ni qila olmadik, shuning uchun biz foydalanishga qaror qildik pg_repack. Va keyin ma'lum bo'ldi pg_repack asosiy kalitsiz yoki boshqa noyoblik cheklovisiz jadvallarni qanday qayta ishlashni bilmaydi va bizning jadvalimizda asosiy kalit yo'q edi. Shunday qilib, diagnostika tug'ildi birlamchi_kalitsiz_jadvallar.

Kutubxona versiyasida 0.1.5 Jadvallar va indekslar to'plamidan ma'lumotlarni to'plash va ularga o'z vaqtida javob berish imkoniyati qo'shildi.

Ettinchi va sakkizinchi muammolar - indekslarning etarli emasligi va foydalanilmagan indekslar

Quyidagi ikkita diagnostika: etishmayotgan_indekslari bilan_jadvallar ΠΈ foydalanilmagan_indekslar - nisbatan yaqinda oxirgi shaklda paydo bo'ldi. Gap shundaki, ularni shunchaki olib, qo'shib bo'lmaydi.

Men allaqachon yozganimdek, biz bir nechta replikatsiyalar bilan konfiguratsiyadan foydalanamiz va turli xostlarda o'qish yuki tubdan farq qiladi. Natijada, ba'zi xostlardagi ba'zi jadvallar va indekslar amalda qo'llanilmaydi va tahlil qilish uchun siz klasterdagi barcha xostlardan statistik ma'lumotlarni to'plashingiz kerak bo'ladi. Statistikani tiklash Bu klasterdagi har bir xostda ham zarur, siz buni faqat masterda qila olmaysiz.

Bunday yondashuv bizga hech qachon foydalanilmagan indekslarni olib tashlash, shuningdek, kamdan-kam ishlatiladigan jadvallarga etishmayotgan indekslarni qo'shish orqali bir necha o'nlab gigabaytlarni tejash imkonini berdi.

Natijada

Albatta, deyarli barcha diagnostika uchun siz sozlashingiz mumkin istisnolar ro'yxati. Shunday qilib, siz yangi xatolar paydo bo'lishining oldini olgan holda ilovangizda tekshiruvlarni tezda amalga oshirishingiz va keyin asta-sekin eskilarini tuzatishingiz mumkin.

Ba'zi diagnostika ma'lumotlar bazasi migratsiyasini yo'lga qo'ygandan so'ng darhol funktsional testlarda amalga oshirilishi mumkin. Va bu, ehtimol, mening kutubxonamning eng kuchli xususiyatlaridan biridir. Foydalanish misolini maqolada topish mumkin demo.

Foydalanilmayotgan yoki etishmayotgan indekslarni, shuningdek, shishishni faqat haqiqiy ma'lumotlar bazasida tekshirish mantiqan. Yig'ilgan qiymatlarni yozib olish mumkin ClickHouse yoki monitoring tizimiga yuboriladi.

Men bunga umid qilaman pg-index-salomatlik foydali va talabga ega bo'ladi. Shuningdek, topilgan muammolar haqida xabar berish va yangi diagnostika usullarini taklif qilish orqali kutubxona rivojlanishiga hissa qo'shishingiz mumkin.

Manba: www.habr.com

a Izoh qo'shish