DBA boti Jo. Anatoliy Stansler (Postgres.ai)

Backend dasturchisi SQL so'rovi "mahsulot" da yaxshi ishlashini qanday tushunadi? Yirik yoki tez rivojlanayotgan kompaniyalarda hamma ham “mahsulot”dan foydalanish imkoniyatiga ega emas. Va kirish bilan, barcha so'rovlarni og'riqsiz tekshirish mumkin emas va ma'lumotlar bazasi nusxasini yaratish ko'pincha bir necha soat davom etadi. Ushbu muammolarni hal qilish uchun biz sun'iy DBA - Joe yaratdik. U allaqachon bir nechta kompaniyalarda muvaffaqiyatli amalga oshirilgan va o'ndan ortiq ishlab chiquvchilarga yordam beradi.

Video:

Hammaga salom! Mening ismim Anatoliy Stansler. Men kompaniyada ishlayman postgres.ai. Biz ishlab chiquvchilar, DBA va QAlardan Postgres ishi bilan bog'liq kechikishlarni olib tashlash orqali ishlab chiqish jarayonini tezlashtirishga intilamiz.

Bizning ajoyib mijozlarimiz bor va bugun hisobotning bir qismi biz ular bilan ishlashda uchrashgan holatlarga bag'ishlanadi. Men ularga jiddiy muammolarni hal qilishda qanday yordam berganimiz haqida gapiraman.

Murakkab yuqori yuk ko'chishlarini ishlab chiqish va amalga oshirishda biz o'zimizga savol beramiz: "Bu migratsiya boshlanadimi?". Biz ko'rib chiqishdan foydalanamiz, biz ko'proq tajribali hamkasblar, DBA mutaxassislari bilimlaridan foydalanamiz. Va u uchadimi yoki yo'qmi, aytishlari mumkin.

Lekin, ehtimol, to'liq o'lchamdagi nusxalarda o'zimizni sinab ko'rsak yaxshi bo'lar edi. Va bugun biz hozirda testga qanday yondashuvlar borligi va uni qanday qilib yaxshiroq va qanday vositalar yordamida amalga oshirish mumkinligi haqida gaplashamiz. Shuningdek, biz bunday yondashuvlarning ijobiy va salbiy tomonlari va bu erda nimani tuzatishimiz mumkinligi haqida gaplashamiz.

Kim hech qachon to'g'ridan-to'g'ri mahsulotda indekslar yaratgan yoki biron bir o'zgartirish kiritgan? Anchagina. Va bu kim uchun ma'lumotlar yo'qolishi yoki ishlamay qolishiga olib keldi? Keyin bu og'riqni bilasiz. Xudoga shukur, zaxiralar bor.

Birinchi yondashuv - bu mahsulotda sinov. Yoki ishlab chiquvchi mahalliy mashinada o'tirganda, u sinov ma'lumotlariga ega, qandaydir cheklangan tanlov mavjud. Va biz ishlab chiqarishga chiqamiz va biz bu vaziyatga erishamiz.

Og'riyapti, qimmat. Bu qilmaslik yaxshiroqdir.

Va buni qilishning eng yaxshi usuli qanday?

Keling, sahnalashtirishni olaylik va u erda mahsulotning bir qismini tanlaymiz. Yoki eng yaxshi holatda, keling, haqiqiy mahsulot, barcha ma'lumotlarni olaylik. Va biz uni mahalliy darajada ishlab chiqqanimizdan so'ng, biz qo'shimcha ravishda sahnalashtirishni tekshiramiz.

Bu bizga ba'zi xatolarni olib tashlash imkonini beradi, ya'ni ularni ishlab chiqarishda bo'lishining oldini oladi.

Qanday muammolar bor?

• Muammo shundaki, biz ushbu sahnalashtirishni hamkasblar bilan baham ko'ramiz. Va juda tez-tez shunday bo'ladiki, siz qandaydir o'zgarishlar qilasiz, bam - va hech qanday ma'lumot yo'q, ish asta-sekin. Sahnalash ko'p terabayt edi. Va yana ko'tarilishi uchun siz uzoq vaqt kutishingiz kerak. Va biz buni ertaga yakunlashga qaror qildik. Mana, bizda rivojlanish bor.
• Va, albatta, u erda ko'plab hamkasblarimiz, ko'plab jamoalarimiz ishlaydi. Va buni qo'lda qilish kerak. Va bu noqulay.

Va shuni aytish kerakki, bizda faqat bitta urinish, bitta zarba bor, agar biz ma'lumotlar bazasiga qandaydir o'zgartirishlar kiritmoqchi bo'lsak, ma'lumotlarga tegizamiz, tuzilmani o'zgartiramiz. Va agar biror narsa noto'g'ri bo'lsa, migratsiyada xatolik yuz bergan bo'lsa, biz tezda orqaga qaytmaymiz.

Bu avvalgi yondashuvga qaraganda yaxshiroq, ammo ishlab chiqarishda qandaydir xatolik yuzaga kelishi ehtimoli hali ham yuqori.

Har bir ishlab chiquvchiga test dastgohi, to'liq o'lchamli nusxasini berishimizga nima xalaqit beradi? Menimcha, nima to'sqinlik qilayotgani aniq.

Kimda terabaytdan kattaroq ma'lumotlar bazasi bor? Xonaning yarmidan ko'pi.

Va shunisi aniqki, har bir ishlab chiquvchi uchun mashinalarni saqlash, bunday katta ishlab chiqarish mavjud bo'lganda, juda qimmatga tushadi va bundan tashqari, bu uzoq vaqt talab etadi.

Bizda barcha o'zgarishlarni to'liq o'lchamli nusxalarda sinab ko'rish juda muhimligini tushungan mijozlarimiz bor, ammo ularning ma'lumotlar bazasi terabaytdan kamroq va har bir ishlab chiquvchi uchun test stolini saqlash uchun resurslar yo'q. Shuning uchun ular axlatxonalarni mahalliy ravishda o'z mashinalariga yuklab olishlari va shu tarzda sinab ko'rishlari kerak. Bu juda ko'p vaqt oladi.

Agar siz buni infratuzilma ichida qilsangiz ham, soatiga bir terabayt ma'lumotni yuklab olish allaqachon juda yaxshi. Lekin ular mantiqiy axlatxonalardan foydalanadilar, ular mahalliy ravishda bulutdan yuklab olishadi. Ular uchun tezlik soatiga taxminan 200 gigabaytni tashkil qiladi. Va mantiqiy axlatdan qaytish, indekslarni yig'ish va hokazo uchun hali ham vaqt kerak.

Ammo ular ushbu yondashuvdan foydalanadilar, chunki bu ularga mahsulotning ishonchliligini saqlashga imkon beradi.

Bu yerda nima qila olamiz? Keling, test dastgohlarini arzonlashtiraylik va har bir ishlab chiquvchiga o'z sinov stolini beraylik.

Va bu mumkin.

Va bu yondashuvda, biz har bir ishlab chiquvchi uchun nozik klonlarni yaratganimizda, uni bitta mashinada baham ko'rishimiz mumkin. Misol uchun, agar sizda 10TB maʼlumotlar bazasi boʻlsa va uni 10 ta dasturchiga bermoqchi boʻlsangiz, sizda XNUMX x XNUMXTB maʼlumotlar bazalariga ega boʻlishingiz shart emas. Bitta mashinadan foydalangan holda har bir ishlab chiquvchi uchun nozik izolyatsiyalangan nusxalarni yaratish uchun sizga faqat bitta mashina kerak bo'ladi. Bu qanday ishlashini birozdan keyin aytib beraman.

Haqiqiy misol:

• JB - 4,5 terabayt.

• Biz mustaqil nusxalarni 30 soniyada olishimiz mumkin.

Siz sinov stendini kutishingiz shart emas va uning qanchalik kattaligiga bog'liq. Siz uni bir necha soniya ichida olishingiz mumkin. Bu butunlay izolyatsiya qilingan, ammo ma'lumotlarni o'zaro almashadigan muhitlar bo'ladi.

Bu ajoyib. Bu erda biz sehr va parallel koinot haqida gapiramiz.

Bizning holatda, bu OpenZFS tizimi yordamida ishlaydi.

OpenZFS - nusxa ko'chirish va yozish fayl tizimi bo'lib, u oniy tasvirlar va klonlarni qutidan tashqarida qo'llab-quvvatlaydi. Bu ishonchli va kengaytiriladigan. Uni boshqarish juda oson. U tom ma'noda ikkita jamoada joylashtirilishi mumkin.

Boshqa variantlar mavjud:

• lvm,

• Saqlash (masalan, Pure Storage).

Men aytayotgan ma'lumotlar bazasi laboratoriyasi modulli. Ushbu variantlar yordamida amalga oshirilishi mumkin. Ammo hozircha biz OpenZFS-ga e'tibor qaratdik, chunki LVM bilan bog'liq muammolar mavjud edi.

U qanday ishlaydi? Maʼlumotlarni har safar oʻzgartirganimizda qayta yozish oʻrniga, biz bu yangi maʼlumotlar vaqtning yangi nuqtasi, yangi surat ekanligini belgilash orqali uni saqlaymiz.

Kelajakda, biz orqaga qaytmoqchi bo'lganimizda yoki eski versiyadan yangi klon yaratmoqchi bo'lganimizda, biz shunchaki aytamiz: "Yaxshi, bizga shunday belgilangan ma'lumotlar bloklarini bering."

Va bu foydalanuvchi bunday ma'lumotlar to'plami bilan ishlaydi. U ularni asta-sekin o'zgartiradi, o'z suratlarini yaratadi.

Va biz filial qilamiz. Bizning holatlarimizda har bir ishlab chiquvchi o'zi tahrir qiladigan o'z kloniga ega bo'lish imkoniyatiga ega bo'ladi va baham ko'rilgan ma'lumotlar hamma o'rtasida almashiladi.

Bunday tizimni uyda o'rnatish uchun siz ikkita muammoni hal qilishingiz kerak:

• Birinchisi, ma'lumotlar manbai, siz uni qaerdan olasiz. Ishlab chiqarish bilan replikatsiyani o'rnatishingiz mumkin. Umid qilamanki, siz allaqachon sozlagan zaxira nusxalaridan foydalanishingiz mumkin. WAL-E, WAL-G yoki Barman. Va agar siz RDS yoki Cloud SQL kabi bulutli yechimlardan foydalansangiz ham, mantiqiy axlatlardan foydalanishingiz mumkin. Ammo biz sizga hali ham zaxira nusxalaridan foydalanishni maslahat beramiz, chunki bu yondashuv bilan siz fayllarning jismoniy tuzilishini ham saqlab qolasiz, bu esa mavjud muammolarni hal qilish uchun ishlab chiqarishda ko'radigan ko'rsatkichlarga yanada yaqinroq bo'lishga imkon beradi.

• Ikkinchisi, ma'lumotlar bazasi laboratoriyasini joylashtirmoqchi bo'lgan joy. Bu Bulut bo'lishi mumkin, u On-premise bo'lishi mumkin. Bu erda ZFS ma'lumotlarni siqishni qo'llab-quvvatlashini aytish muhimdir. Va u buni juda yaxshi bajaradi.

Tasavvur qiling-a, har bir bunday klon uchun biz baza bilan bajaradigan operatsiyalarga qarab, qandaydir dev o'sadi. Buning uchun ishlab chiqaruvchiga ham joy kerak bo'ladi. Ammo biz 4,5 terabaytlik bazani olganimiz sababli, ZFS uni 3,5 terabaytgacha siqib chiqaradi. Bu sozlamalarga qarab farq qilishi mumkin. Va bizda hali ishlab chiquvchilar uchun joy bor.

Bunday tizim turli holatlar uchun ishlatilishi mumkin.

• Bular ishlab chiquvchilar, so'rovlarni tekshirish, optimallashtirish uchun DBAlar.

• Bu QA testida ma'lum bir migratsiyani ishlab chiqarishga chiqarishdan oldin sinab ko'rish uchun ishlatilishi mumkin. Shuningdek, biz haqiqiy ma'lumotlarga ega QA uchun maxsus muhitlarni yaratishimiz mumkin, ularda ular yangi funksiyalarni sinab ko'rishlari mumkin. Kutish soatlari o'rniga soniyalar va yupqa nusxalar ishlatilmaydigan boshqa hollarda kunlar kerak bo'ladi.

• Va yana bir holat. Agar kompaniyada analitik tizim o'rnatilmagan bo'lsa, biz mahsulot bazasining yupqa klonini ajratib, uni uzoq so'rovlarga yoki analitikada qo'llanilishi mumkin bo'lgan maxsus indekslarga berishimiz mumkin.

Ushbu yondashuv bilan:

1. "Mahsulot" da xatolik ehtimoli past, chunki biz barcha o'zgarishlarni to'liq o'lchamli ma'lumotlarda sinab ko'rdik.

2. Bizda test o'tkazish madaniyati bor, chunki endi siz o'z stendingizni soatlab kutishingiz shart emas.

3. Va hech qanday to'siq yo'q, testlar orasida kutish ham yo'q. Siz haqiqatan ham borib, tekshirishingiz mumkin. Rivojlanishni tezlashtirsak, bu yaxshi bo'ladi.

• Refaktoring kamroq bo'ladi. Kamroq xatolar mahsulotda tugaydi. Biz ularni keyinroq kamroq qayta ko'rib chiqamiz.

• Biz qaytarib bo'lmaydigan o'zgarishlarni qaytarishimiz mumkin. Bu standart yondashuv emas.

1. Bu foydali, chunki biz test skameykalarining resurslarini baham ko'ramiz.

Allaqachon yaxshi, lekin yana nimani tezlashtirish mumkin?

Bunday tizim tufayli biz bunday testga kirish chegarasini sezilarli darajada kamaytirishimiz mumkin.

Haqiqiy to'liq o'lchamli ma'lumotlarga kirish uchun ishlab chiquvchi mutaxassis bo'lishi kerak bo'lgan shafqatsiz doira mavjud. Unga bunday kirishga ishonish kerak.

Ammo u erda bo'lmasa, qanday qilib o'sadi. Agar sizda juda kichik test ma'lumotlari mavjud bo'lsa-chi? Shunda siz haqiqiy tajribaga ega bo'lmaysiz.

Bu doiradan qanday chiqish mumkin? Har qanday darajadagi ishlab chiquvchilar uchun qulay bo'lgan birinchi interfeys sifatida biz Slack botini tanladik. Lekin bu har qanday boshqa interfeys bo'lishi mumkin.

Bu sizga nima qilish imkonini beradi? Siz ma'lum bir so'rovni qabul qilishingiz va uni ma'lumotlar bazasi uchun maxsus kanalga yuborishingiz mumkin. Biz bir necha soniya ichida avtomatik ravishda yupqa klonni joylashtiramiz. Keling, ushbu so'rovni bajaraylik. Biz ko'rsatkichlar va tavsiyalarni yig'amiz. Keling, vizualizatsiyani ko'rsatamiz. Va keyin bu klon qoladi, bu so'rovni qandaydir tarzda optimallashtirish, indekslarni qo'shish va hokazo.

Shuningdek, Slack bizga qutidan tashqari hamkorlik qilish imkoniyatini beradi. Bu shunchaki kanal bo'lganligi sababli, siz ushbu so'rovni aynan shunday so'rov uchun mavzu bo'limida muhokama qilishni boshlashingiz, kompaniya ichidagi hamkasblaringizga, DBAlarga ping yuborishingiz mumkin.

Lekin, albatta, muammolar mavjud. Bu haqiqiy dunyo va biz bir vaqtning o'zida ko'plab klonlarni joylashtiradigan serverdan foydalanayotganimiz sababli, biz klonlar uchun mavjud bo'lgan xotira miqdori va protsessor quvvatini siqishimiz kerak.

Ammo bu testlar ishonchli bo'lishi uchun siz qandaydir tarzda bu muammoni hal qilishingiz kerak.

Muhim nuqta bir xil ma'lumotlar ekanligi aniq. Ammo bizda allaqachon mavjud. Va biz bir xil konfiguratsiyaga erishmoqchimiz. Va biz bunday deyarli bir xil konfiguratsiyani bera olamiz.

Ishlab chiqarishdagi kabi bir xil uskunaga ega bo'lish ajoyib bo'lar edi, lekin u farq qilishi mumkin.

Keling, Postgres xotira bilan qanday ishlashini eslaylik. Bizda ikkita kesh bor. Bitta fayl tizimi va bitta mahalliy Postgres, ya'ni umumiy bufer keshi.

Shuni ta'kidlash kerakki, umumiy bufer keshi Postgres ishga tushganda, konfiguratsiyada qaysi o'lchamda ko'rsatganingizga qarab ajratiladi.

Va ikkinchi kesh barcha mavjud bo'sh joydan foydalanadi.

Va bitta mashinada bir nechta klonlarni yaratganimizda, biz asta-sekin xotirani to'ldiramiz. Yaxshi ma'noda, umumiy bufer keshi mashinada mavjud bo'lgan umumiy xotira hajmining 25% ni tashkil qiladi.

Va ma'lum bo'lishicha, agar biz ushbu parametrni o'zgartirmasak, biz bitta mashinada faqat 4 ta misolni, ya'ni jami 4 ta yupqa klonni ishga tushirishimiz mumkin. Va bu, albatta, yomon, chunki biz ulardan ko'proq bo'lishni xohlaymiz.

Ammo boshqa tomondan, bufer keshi indekslar uchun so'rovlarni bajarish uchun ishlatiladi, ya'ni reja bizning keshlarimiz qanchalik kattaligiga bog'liq. Va agar biz ushbu parametrni olib, uni kamaytirsak, unda bizning rejalarimiz juda ko'p o'zgarishi mumkin.

Misol uchun, agar mahsulotda katta kesh mavjud bo'lsa, Postgres indeksdan foydalanishni afzal ko'radi. Agar yo'q bo'lsa, SeqScan bo'ladi. Va agar bizning rejalarimiz bir-biriga mos kelmasa, nima bo'lar edi?

Ammo bu erda biz shunday xulosaga keldikki, aslida Postgresdagi reja rejadagi Umumiy buferda ko'rsatilgan o'ziga xos o'lchamga bog'liq emas, u samarali_kesh_sizega bog'liq.

Effektiv_kesh_sizi - biz uchun mavjud bo'lgan keshning taxminiy miqdori, ya'ni bufer keshi va fayl tizimi keshi yig'indisi. Bu konfiguratsiya tomonidan o'rnatiladi. Va bu xotira ajratilmagan.

Va bu parametr tufayli biz Postgresni aldashimiz mumkin, bizda bu ma'lumotlar bo'lmasa ham, aslida juda ko'p ma'lumotlar mavjud. Shunday qilib, rejalar ishlab chiqarish bilan to'liq mos keladi.

Ammo bu vaqtga ta'sir qilishi mumkin. Va biz so'rovlarni vaqt bo'yicha optimallashtiramiz, ammo vaqt ko'p omillarga bog'liq bo'lishi muhim:

• Bu hozirda ishlab chiqarilgan yukga bog'liq.

• Bu mashinaning o'ziga xos xususiyatlariga bog'liq.

Va bu bilvosita parametr, lekin aslida biz natijani olish uchun ushbu so'rov o'qiydigan ma'lumotlar miqdori bo'yicha optimallashtirishimiz mumkin.

Va agar siz ishlab chiqarishda ko'radigan vaqtga yaqin bo'lishini istasangiz, barcha klonlar mos kelishi uchun biz eng o'xshash uskunani va, ehtimol, undan ham ko'proq narsani olishimiz kerak. Ammo bu murosaga kelish, ya'ni siz bir xil rejalarga ega bo'lasiz, siz ma'lum bir so'rov qancha ma'lumotlarni o'qishini ko'rasiz va bu so'rov yaxshi (yoki ko'chish) yoki yomonmi degan xulosaga kelishingiz mumkin, uni hali ham optimallashtirish kerak. .

Keling, Joning qanday qilib optimallashtirilganligini ko'rib chiqaylik.

Haqiqiy tizimdan so'rovni olaylik. Bunday holda, ma'lumotlar bazasi 1 terabaytni tashkil qiladi. Va biz 10 dan ortiq yoqtirgan yangi postlar sonini hisoblamoqchimiz.

Biz kanalga xabar yozyapmiz, biz uchun klon o'rnatildi. Va biz bunday so'rov 2,5 daqiqada yakunlanishini ko'ramiz. Bu biz e'tibor beradigan birinchi narsa.

B Jou sizga reja va ko'rsatkichlar asosida avtomatik tavsiyalarni ko'rsatadi.

Nisbatan kam sonli qatorlarni olish uchun so'rov juda ko'p ma'lumotlarni qayta ishlashini ko'ramiz. Va qandaydir ixtisoslashtirilgan indeks kerak, chunki biz so'rovda juda ko'p filtrlangan qatorlar borligini payqadik.

Keling, nima bo'lganini batafsil ko'rib chiqaylik. Haqiqatan ham, biz fayl keshidan yoki hatto diskdan deyarli bir yarim gigabayt ma'lumotni o'qiganimizni ko'ramiz. Va bu yaxshi emas, chunki bizda atigi 142 qator bor.

Aftidan, bu yerda bizda indeks skanerlashi bor va tezda ishlab chiqilishi kerak edi, lekin biz juda ko'p qatorlarni filtrlaganimiz uchun (biz ularni sanashimiz kerak edi), so'rov asta-sekin bajarildi.

Va bu rejada so'rovdagi shartlar va indeksdagi shartlar qisman mos kelmasligi sababli sodir bo'ldi.

Keling, indeksni aniqroq qilishga harakat qilaylik va undan keyin so'rovning bajarilishi qanday o'zgarishini ko'raylik.

Indeksni yaratish juda uzoq vaqt talab qildi, ammo endi biz so'rovni tekshirib ko'ramiz va 2,5 daqiqa o'rniga vaqt bor-yo'g'i 156 millisekundni tashkil etadi, bu etarli darajada yaxshi. Va biz faqat 6 megabayt ma'lumotni o'qiymiz.

Va endi biz faqat indeksni skanerlashdan foydalanamiz.

Yana bir muhim voqea shundaki, biz rejani tushunarliroq tarzda taqdim qilmoqchimiz. Biz Flame Graphs yordamida vizualizatsiyani amalga oshirdik.

Bu boshqa so'rov, yanada qizg'in. Va biz Flame Grafiklarini ikkita parametrga ko'ra quramiz: bu ma'lum bir tugun reja va vaqtni hisobga olgan holda ma'lumotlar miqdori, ya'ni tugunning bajarilish vaqti.

Bu erda biz aniq tugunlarni bir-biri bilan solishtirishimiz mumkin. Va ularning qaysi biri ko'proq yoki kamroq olishi aniq bo'ladi, bu odatda boshqa ko'rsatish usullarida qilish qiyin.

Albatta, hamma tushuntiradi.depesz.com saytini biladi. Ushbu vizualizatsiyaning yaxshi xususiyati shundaki, biz matn rejasini saqlaymiz va tartiblashimiz uchun ba'zi asosiy parametrlarni jadvalga joylashtiramiz.

Va bu mavzuni hali o'rganmagan ishlab chiquvchilar, shuningdek, tushuntirish.depesz.com dan foydalanadilar, chunki ular uchun qaysi ko'rsatkichlar muhim va qaysi biri muhim emasligini aniqlash osonroq.

Vizualizatsiyaga yangi yondashuv mavjud - bu tushuntirish.dalibo.com. Ular daraxt vizualizatsiyasini amalga oshiradilar, lekin tugunlarni bir-biri bilan solishtirish juda qiyin. Bu erda siz strukturani yaxshi tushunishingiz mumkin, ammo agar katta so'rov bo'lsa, unda siz oldinga va orqaga o'tishingiz kerak bo'ladi, lekin ayni paytda variant.

hamkorlik

Va aytganimdek, Slack bizga hamkorlik qilish imkoniyatini beradi. Misol uchun, agar biz qanday qilib optimallashtirishni aniq bo'lmagan murakkab so'rovga duch kelsak, biz Slack-dagi mavzuda hamkasblarimiz bilan bu masalani aniqlashtirishimiz mumkin.

Bizningcha, to'liq o'lchamli ma'lumotlarni sinab ko'rish juda muhim. Buning uchun biz ochiq manbada mavjud bo'lgan yangilash ma'lumotlar bazasi laboratoriyasini yaratdik. Joe botidan ham foydalanishingiz mumkin. Siz uni hoziroq olib, o'zingizning joyingizda amalga oshirishingiz mumkin. U erda barcha yo'riqnomalar mavjud.

Shuni ham ta'kidlash kerakki, yechimning o'zi inqilobiy emas, chunki Delphix mavjud, ammo u korporativ yechimdir. U butunlay yopiq, bu juda qimmat. Biz ayniqsa Postgresga ixtisoslashganmiz. Bularning barchasi ochiq kodli mahsulotlardir. Bizga qo'shiling!

Mana shu yerda tugataman. Rahmat!

Sizning savollaringiz

Salom! Hisobot uchun rahmat! Juda qiziq, ayniqsa men uchun, chunki men bir muncha vaqt oldin xuddi shu muammoni hal qilganman. Va shuning uchun menda bir nechta savollar bor. Umid qilamanki, men hech bo'lmaganda bir qismini olaman.

Qiziq, bu muhit uchun joyni qanday hisoblaysiz? Texnologiya ma'lum sharoitlarda sizning klonlaringiz maksimal hajmgacha o'sishi mumkinligini anglatadi. Taxminan aytganda, agar sizda o'n terabayt ma'lumotlar bazasi va 10 klon bo'lsa, unda har bir klon 10 ta noyob ma'lumotni o'z ichiga olgan vaziyatni taqlid qilish oson. Bu yerni, ya'ni siz aytgan deltani, bu klonlar yashaydigan joyni qanday hisoblaysiz?

Yaxshi savol. Bu erda aniq klonlarni kuzatib borish muhimdir. Va agar klonda juda katta o'zgarishlar bo'lsa, u o'sishni boshlasa, biz birinchi navbatda foydalanuvchiga bu haqda ogohlantirish berishimiz yoki muvaffaqiyatsiz vaziyatga duch kelmaslik uchun darhol ushbu klonni to'xtatishimiz mumkin.

Ha, mening savolim bor. Ya'ni, ushbu modullarning hayot aylanishini qanday ta'minlaysiz? Bizda bu muammo va butunlay alohida hikoya bor. Bu qanday sodir bo'ladi?

Har bir klon uchun bir oz ttl mavjud. Asosan, bizda belgilangan ttl bor.

Agar sir bo'lmasa-chi?

1 soat, ya'ni bo'sh - 1 soat. Agar u ishlatilmasa, biz uni portlatamiz. Ammo bu erda ajablanarli joyi yo'q, chunki biz bir necha soniya ichida klonni ko'tarishimiz mumkin. Va agar sizga yana kerak bo'lsa, iltimos.

Men texnologiyalarni tanlashga ham qiziqaman, chunki, masalan, biz u yoki bu sabablarga ko'ra parallel ravishda bir nechta usullardan foydalanamiz. Nima uchun ZFS? Nega LVM dan foydalanmadingiz? LVM bilan bog'liq muammolar borligini aytdingiz. Qanday muammolar bor edi? Menimcha, ishlash jihatidan eng maqbul variant saqlash bilan.

ZFS bilan bog'liq asosiy muammo nima? Siz bitta xostda ishlashingiz kerakligi, ya'ni barcha misollar bir xil OS ichida yashaydi. Va saqlash holatida siz turli xil uskunalarni ulashingiz mumkin. Va muammo faqat saqlash tizimidagi bloklardir. Va texnologiyalarni tanlash masalasi qiziq. Nega LVM emas?

Xususan, biz LVMni uchrashuvda muhokama qilishimiz mumkin. Saqlash haqida - bu shunchaki qimmat. Biz ZFS tizimini istalgan joyda amalga oshirishimiz mumkin. Siz uni kompyuteringizga joylashtirishingiz mumkin. Siz shunchaki omborni yuklab olishingiz va uni joylashtirishingiz mumkin. Agar Linux haqida gapiradigan bo'lsak, ZFS deyarli hamma joyda o'rnatilgan. Ya'ni, biz juda moslashuvchan yechimga ega bo'lamiz. Va qutidan tashqari, ZFS juda ko'p narsalarni beradi. Siz xohlagancha ko'p ma'lumotlarni yuklashingiz, ko'p sonli disklarni ulashingiz mumkin, oniy tasvirlar mavjud. Va aytganimdek, uni boshqarish oson. Ya'ni, foydalanish juda yoqimli ko'rinadi. U sinovdan o'tgan, u ko'p yoshda. U o'sib borayotgan juda katta jamoaga ega. ZFS juda ishonchli yechimdir.

Nikolay Samoxvalov: Yana izoh bera olamanmi? Mening ismim Nikolay, biz Anatoliy bilan birga ishlaymiz. Saqlash juda yaxshi ekanligiga qo'shilaman. Va ba'zi mijozlarimiz Pure Storage va boshqalarga ega.

Anatoliy biz modullikka e'tibor qaratganimizni to'g'ri ta'kidladi. Va kelajakda siz bitta interfeysni amalga oshirishingiz mumkin - suratga olish, klon qilish, klonni yo'q qilish. Hammasi oson. Va agar shunday bo'lsa, saqlash juda yaxshi.

Ammo ZFS hamma uchun mavjud. DelPhix allaqachon yetarli, ularning 300 ta mijozi bor. Ulardan Fortune 100 ning 50 ta mijozi bor, ya'ni ular NASA ga yo'naltirilgan va hokazo. Hammaga bu texnologiyani olish vaqti keldi. Va shuning uchun bizda ochiq kodli Core mavjud. Bizda ochiq manba bo'lmagan interfeys qismi mavjud. Bu biz ko'rsatadigan platforma. Lekin biz hamma uchun ochiq bo'lishini istaymiz. Biz inqilob qilishni xohlaymiz, shunda barcha testerlar noutbuklarda taxmin qilishni to'xtatadilar. Biz SELECT yozishimiz va darhol uning sekin ekanligini ko'rishimiz kerak. DBA sizga bu haqda aytib berishini kutishni to'xtating. Mana asosiy maqsad. Va o'ylaymanki, biz hammamiz bunga erishamiz. Va biz buni hamma uchun tayyorlaymiz. Shuning uchun ZFS, chunki u hamma joyda mavjud bo'ladi. Muammolarni hal qilgani va ochiq kodli litsenziyaga ega bo'lgani uchun hamjamiyatga rahmat*.

Salom! Hisobot uchun rahmat! Mening ismim Maksim. Biz bir xil masalalarni hal qildik. Ular o'zlari qaror qildilar. Ushbu klonlar o'rtasida resurslarni qanday almashasiz? Har bir klon istalgan vaqtda o'z ishini qila oladi: biri bir narsani sinab ko'radi, boshqasi boshqa, kimdir indeks tuzadi, kimdir og'ir ish bilan shug'ullanadi. Va agar siz hali ham CPU bo'yicha, keyin esa IO bo'yicha bo'lishingiz mumkin bo'lsa, qanday qilib bo'linasiz? Bu birinchi savol.

Ikkinchi savol esa tribunalarning bir-biriga o'xshamasligi haqida. Aytaylik, menda ZFS bor va hammasi zo'r, lekin mahsulotdagi mijozda ZFS yo'q, masalan, ext4. Bu holatda qanday?

Savollar juda yaxshi. Men bu muammoni biz resurslarni baham ko'rishimiz bilan bir oz eslatib o'tdim. Va yechim bu. Tasavvur qiling-a, siz sahnalashtirishda sinovdan o'tmoqdasiz. Siz ham bir vaqtning o'zida shunday vaziyatga ega bo'lishingiz mumkin, kimdir bitta yukni, boshqasini beradi. Va natijada siz tushunarsiz ko'rsatkichlarni ko'rasiz. Hatto bir xil muammo mahsulot bilan bo'lishi mumkin. Ba'zi so'rovlarni tekshirmoqchi bo'lganingizda va u bilan qandaydir muammo borligini ko'rsangiz - u sekin ishlaydi, demak, aslida muammo so'rovda emas, balki qandaydir parallel yuk borligida edi.

Va shuning uchun bu erda reja qanday bo'lishi, rejada qanday qadamlar qo'yishimiz va buning uchun qancha ma'lumot to'plashimizga e'tibor qaratish muhimdir. Bizning disklarimiz, masalan, biror narsa bilan yuklanishi, bu vaqtni belgilashga ta'sir qiladi. Ammo biz ushbu so'rov qanchalik yuklanganligini ma'lumotlar miqdori bo'yicha taxmin qilishimiz mumkin. Bir vaqtning o'zida qandaydir qatl bo'lishi unchalik muhim emas.

Menda ikkita savol bor. Bu juda ajoyib narsa. Kredit karta raqamlari kabi ishlab chiqarish ma'lumotlari muhim bo'lgan holatlar bo'lganmi? Tayyor narsa bormi yoki bu alohida vazifami? Va ikkinchi savol - MySQL uchun shunga o'xshash narsa bormi?

Ma'lumotlar haqida. Biz buni qilmagunimizcha chalkashliklarni qilamiz. Ammo agar siz aynan Joni joylashtirsangiz, ishlab chiquvchilarga ruxsat bermasangiz, ma'lumotlarga kirish imkoni bo'lmaydi. Nega? Chunki Jo ma'lumotlarni ko'rsatmaydi. U faqat ko'rsatkichlarni, rejalarni ko'rsatadi va hammasi. Bu ataylab qilingan, chunki bu bizning mijozimiz talablaridan biridir. Ular hammaga ruxsat bermasdan optimallashtirishni xohlashdi.

MySQL haqida. Ushbu tizim diskdagi holatni saqlaydigan barcha narsalar uchun ishlatilishi mumkin. Va biz Postgres bilan shug'ullanayotganimiz sababli, biz hozir Postgres uchun barcha avtomatlashtirishni amalga oshirmoqdamiz. Biz zaxiradan ma'lumotlarni olishni avtomatlashtirmoqchimiz. Biz Postgres-ni to'g'ri sozlaymiz. Biz rejalarni qanday qilib moslashtirishni bilamiz va hokazo.

Ammo tizim kengaytiriladigan bo'lgani uchun uni MySQL uchun ham ishlatish mumkin. Va bunday misollar mavjud. Yandex-da shunga o'xshash narsa bor, lekin ular uni hech qanday joyda nashr etmaydilar. Ular Yandex.Metrica ichida foydalanadilar. Va MySQL haqida faqat bir hikoya bor. Ammo texnologiyalar bir xil, ZFS.

Hisobot uchun rahmat! Menda ham bir nechta savol bor. Siz klonlashni tahlil qilish uchun, masalan, u erda qo'shimcha indekslarni yaratish uchun foydalanish mumkinligini ta'kidladingiz. Bu qanday ishlashi haqida bir oz ko'proq ma'lumot bera olasizmi?

Va men darhol ikkinchi savolni stendlarning o'xshashligi, rejalarning o'xshashligi haqida so'rayman. Reja Postgres tomonidan to'plangan statistik ma'lumotlarga ham bog'liq. Bu muammoni qanday hal qilasiz?

Tahlillarga ko'ra, aniq holatlar yo'q, chunki biz undan hali foydalanmadik, ammo bunday imkoniyat mavjud. Agar biz indekslar haqida gapiradigan bo'lsak, so'rov yuz millionlab yozuvlar va odatda mahsulotda indekslanmagan ustunga ega jadvalni ta'qib qilayotganini tasavvur qiling. Va biz u erda ba'zi ma'lumotlarni hisoblashni xohlaymiz. Agar bu so'rov prodga yuborilsa, u ishlab chiqarishda oddiy bo'lishi ehtimoli bor, chunki so'rov u erda bir daqiqa davomida qayta ishlanadi.

OK, keling, bir necha daqiqa davomida to'xtash qo'rqinchli bo'lmagan nozik bir klon qilaylik. Va tahliliy ma'lumotlarni o'qishni qulayroq qilish uchun biz ma'lumotlarga qiziqqan ustunlar uchun indekslarni qo'shamiz.

Indeks har safar yaratiladimi?

Siz buni shunday qilishingiz mumkinki, biz maʼlumotlarga tegib, oniy suratlar yaratamiz, keyin biz bu suratdan tiklanamiz va yangi soʻrovlarni yuboramiz. Ya'ni, siz allaqachon biriktirilgan indekslar bilan yangi klonlarni yaratishingiz mumkin.

Statistikaga oid savolga kelsak, agar biz zaxiradan tiklasak, replikatsiya qilsak, bizning statistikamiz aynan bir xil bo'ladi. Chunki bizda butun jismoniy ma'lumotlar tuzilmasi mavjud, ya'ni biz ma'lumotlarni barcha statistik ko'rsatkichlar bilan birga keltiramiz.

Mana yana bir muammo. Agar siz bulutli yechimdan foydalansangiz, u erda faqat mantiqiy axlatxonalar mavjud, chunki Google, Amazon jismoniy nusxani olishga ruxsat bermaydi. Muammo bo'ladi.

Hisobot uchun rahmat. Bu yerda MySQL va manbalarni almashish haqida ikkita yaxshi savol bor edi. Lekin, aslida, bularning barchasi ma'lum bir DBMS mavzusi emas, balki butun fayl tizimi mavzusi ekanligiga bog'liq. Va shunga ko'ra, resurslarni almashish masalalari ham u erdan hal qilinishi kerak, bu Postgres emas, balki fayl tizimida, masalan, serverda.

Mening savolim biroz boshqacha. U ko'p qatlamli ma'lumotlar bazasiga yaqinroq bo'lib, u erda bir nechta qatlamlar mavjud. Misol uchun, biz o'n terabaytli tasvirni yangilashni o'rnatdik, biz takrorlaymiz. Va biz ushbu yechimdan ma'lumotlar bazalari uchun maxsus foydalanamiz. Replikatsiya davom etmoqda, ma'lumotlar yangilanmoqda. Bu yerda 100 nafar xodim parallel ravishda ishlaydi, ular doimiy ravishda turli xil kadrlarni ishga tushirishadi. Nima qilish kerak? Hech qanday mojaro yo'qligiga, ular birini ishga tushirganiga, keyin fayl tizimi o'zgarganiga va bu rasmlarning hammasi ketganiga qanday ishonch hosil qilish mumkin?

Ular borishmaydi, chunki ZFS shunday ishlaydi. Replikatsiya tufayli kelib chiqadigan fayl tizimi o'zgarishlarini alohida-alohida bitta oqimda saqlashimiz mumkin. Va ishlab chiquvchilar ma'lumotlarning eski versiyalarida foydalanadigan klonlarni saqlang. Va bu biz uchun ishlaydi, bu bilan hamma narsa tartibda.

Ma'lum bo'lishicha, yangilanish qo'shimcha qatlam sifatida amalga oshiriladi va barcha yangi rasmlar allaqachon ushbu qatlamga asoslanib ketadi, shunday emasmi?

Oldingi replikatsiyalardan oldingi qatlamlardan.

Oldingi qatlamlar tushib ketadi, lekin ular eski qatlamga murojaat qiladi va yangilanishda olingan oxirgi qatlamdan yangi tasvirlarni oladimi?

Umuman olganda, ha.

Natijada, biz bir anjirgacha qatlamlarga ega bo'lamiz. Va vaqt o'tishi bilan ular siqilishi kerakmi?

Ha hammasi to `g` ri. Bir oz oyna bor. Biz haftalik suratlarni saqlaymiz. Bu sizda qanday resurs borligiga bog'liq. Agar siz juda ko'p ma'lumotlarni saqlash qobiliyatiga ega bo'lsangiz, oniy tasvirlarni uzoq vaqt saqlashingiz mumkin. Ular o'z-o'zidan ketmaydi. Ma'lumotlarning buzilishi bo'lmaydi. Agar oniy tasvirlar eskirgan bo'lsa, biz uchun ko'rinib turibdiki, ya'ni kompaniyadagi siyosatga bog'liq bo'lsa, biz ularni shunchaki o'chirib tashlashimiz va joy bo'shatishimiz mumkin.

Salom, hisobot uchun rahmat! Jo haqida savol. Siz mijoz barchaga ma'lumotlarga kirish huquqini berishni xohlamasligini aytdingiz. To'g'ridan-to'g'ri aytganda, agar biror kishi Explain Analyze natijasiga ega bo'lsa, u ma'lumotlarni ko'rib chiqishi mumkin.

Xuddi shunday. Masalan, biz yozishimiz mumkin: "SELECT FROM WHERE email = to that". Ya'ni, biz ma'lumotlarning o'zini ko'rmaymiz, lekin ba'zi bilvosita belgilarni ko'rishimiz mumkin. Buni tushunish kerak. Ammo boshqa tomondan, hamma narsa bor. Bizda jurnal auditi bor, bizda ishlab chiquvchilar nima qilayotganini ko'radigan boshqa hamkasblar nazorati mavjud. Va agar kimdir buni qilishga harakat qilsa, xavfsizlik xizmati ularga kelib, bu masala bo'yicha ishlaydi.

Hayrli kun! Hisobot uchun rahmat! Menda qisqa savol bor. Agar kompaniya Slack-dan foydalanmasa, hozirda unga bog'liqlik bormi yoki ishlab chiquvchilar sinov ilovasini ma'lumotlar bazalariga ulash uchun namunalarni o'rnatishlari mumkinmi?

Endi Slack-ga havola bor, ya'ni boshqa messenjer yo'q, lekin men boshqa messenjerlarni ham qo'llab-quvvatlamoqchiman. Siz nima qila olasiz? Siz DB Lab-ni Jousiz o'rnatishingiz, REST API yordamida yoki bizning platformamiz yordamida o'tishingiz va klonlar yaratishingiz va PSQL bilan bog'lanishingiz mumkin. Ammo, agar siz ishlab chiquvchilaringizga ma'lumotlarga kirish huquqini berishga tayyor bo'lsangiz, buni qilish mumkin, chunki endi ekran bo'lmaydi.

Menga bu qatlam kerak emas, lekin menga bunday imkoniyat kerak.

Keyin, ha, buni qilish mumkin.

Manba: www.habr.com