Yandeksning quyidagi ma'lumotlar bazalariga qo'shgan hissasi ko'rib chiqiladi.
- ClickHouse
- Odyssey
- Vaqt o'tishi bilan tiklanish (WAL-G)
- PostgreSQL (jumladan, login xatolar, Amcheck, heapcheck)
- Yashil olxo'ri
Video:
Salom Dunyo! Mening ismim Andrey Borodin. Va Yandex.Cloud-da qiladigan ishim Yandex.Cloud va Yandex.Cloud mijozlari manfaatlari uchun ochiq relyatsion ma'lumotlar bazalarini ishlab chiqishdir.
Ushbu nutqda biz keng miqyosda ochiq ma'lumotlar bazalari oldida turgan muammolar haqida gapiramiz. Nima uchun bu muhim? Chunki chivinlar kabi, keyin filga aylanadigan kichik, kichik muammolar. Ko'p klasterlaringiz bo'lsa, ular kattalashadi.
Lekin bu asosiy narsa emas. Aql bovar qilmaydigan narsalar sodir bo'ladi. Bir million holatda sodir bo'ladigan narsalar. Va bulutli muhitda siz bunga tayyor bo'lishingiz kerak, chunki miqyosda biror narsa mavjud bo'lganda aql bovar qilmaydigan narsalar yuqori ehtimolga aylanadi.
Lekin! Ochiq ma'lumotlar bazalarining afzalligi nimada? Gap shundaki, sizda har qanday muammoni hal qilish uchun nazariy imkoniyat bor. Sizda manba kodingiz bor, dasturlash bilimingiz bor. Biz uni birlashtiramiz va u ishlaydi.
Ochiq kodli dasturiy ta'minot ustida ishlashda qanday yondashuvlar mavjud?
- Eng oddiy yondashuv dasturiy ta'minotdan foydalanishdir. Agar siz protokollardan foydalansangiz, standartlardan foydalansangiz, formatlardan foydalansangiz, ochiq kodli dasturiy ta'minotda so'rovlarni yozsangiz, uni allaqachon qo'llab-quvvatlaysiz.
- Siz uning ekotizimini kattalashtiryapsiz. Siz xatoni erta aniqlash ehtimolini oshirasiz. Siz ushbu tizimning ishonchliligini oshirasiz. Siz bozorda ishlab chiquvchilarning mavjudligini oshirasiz. Siz ushbu dasturni yaxshilaysiz. Agar siz shunchaki uslubga ega bo'lsangiz va u erda biror narsa bilan shug'ullansangiz, siz allaqachon hissa qo'shgansiz.
- Yana bir tushunarli yondashuv ochiq kodli dasturiy ta'minotga homiylik qilishdir. Masalan, taniqli Google Summer of Code dasturi, Google butun dunyo bo'ylab ko'p sonli talabalarga ma'lum litsenziyalash talablariga javob beradigan ochiq dasturiy ta'minot loyihalarini ishlab chiqishlari uchun tushunarli pul to'laydi.
- Bu juda qiziqarli yondashuv, chunki u diqqatni jamiyatdan uzoqlashtirmasdan dasturiy ta'minotni rivojlantirishga imkon beradi. Google, texnologiya giganti sifatida, biz bu xususiyatni xohlayotganimizni aytmaydi, biz bu xatoni tuzatmoqchimiz va bu erda biz qazishimiz kerak. Google shunday deydi: “Qilayotgan ishni qiling. Qanday ishlagan bo'lsangiz, shunday ishlashda davom eting va hammasi yaxshi bo'ladi."
- Ochiq manbada ishtirok etishning keyingi yondashuvi bu ishtirok etishdir. Ochiq kodli dasturiy ta'minotda muammo yuzaga kelganda va ishlab chiquvchilar mavjud bo'lganda, ishlab chiquvchilaringiz muammolarni hal qilishni boshlaydilar. Ular sizning infratuzilmangizni samaraliroq, dasturlaringizni tezroq va ishonchliroq qila boshlaydi.
Ochiq kodli dasturiy ta'minot sohasidagi eng mashhur Yandex loyihalaridan biri bu ClickHouse. Bu Yandex.Metrica oldida turgan muammolarga javob sifatida tug'ilgan ma'lumotlar bazasi.
Va ma'lumotlar bazasi sifatida u ekotizimni yaratish va uni boshqa ishlab chiquvchilar bilan birgalikda rivojlantirish uchun ochiq manbada yaratilgan (faqat Yandex ichida emas). Va endi bu juda ko'p turli kompaniyalar ishtirok etadigan katta loyiha.
Yandex.Cloud-da biz ClickHouse-ni Yandex Object Storage-ning tepasida, ya'ni bulutli saqlashning tepasida yaratdik.
Nega bu bulutda muhim? Chunki har qanday ma'lumotlar bazasi mana shu uchburchakda, shu piramidada, xotira turlarining mana shu ierarxiyasida ishlaydi. Sizda tez, lekin kichik registrlar va arzon katta, ammo sekin SSD-lar, qattiq disklar va boshqa blokli qurilmalar mavjud. Va agar siz piramidaning yuqori qismida samarali bo'lsangiz, unda sizda tezkor ma'lumotlar bazasi mavjud. Agar siz ushbu piramidaning pastki qismida samarali bo'lsangiz, unda sizda miqyosli ma'lumotlar bazasi mavjud. Va shu nuqtai nazardan, pastdan boshqa qatlamni qo'shish ma'lumotlar bazasining miqyosliligini oshirishning mantiqiy yondashuvidir.
Buni qanday qilish mumkin edi? Bu hisobotdagi muhim nuqta.
- Biz MDS orqali ClickHouse-ni qo'llashimiz mumkin. MDS - bu Yandex bulutli saqlashning ichki interfeysi. Bu umumiy S3 protokolidan ko'ra murakkabroq, lekin u blokli qurilma uchun ko'proq mos keladi. Bu ma'lumotlarni yozib olish uchun yaxshiroqdir. Bu ko'proq dasturlashni talab qiladi. Dasturchilar dasturlashadi, bu hatto yaxshi, qiziqarli.
- S3 - bu ma'lum turdagi ish yuklariga kamroq moslashish hisobiga interfeysni soddalashtiradigan keng tarqalgan yondashuv.
Tabiiyki, butun ClickHouse ekotizimini funksionallik bilan ta'minlash va Yandex.Cloud ichida zarur bo'lgan vazifani bajarishni istab, biz butun ClickHouse hamjamiyatining bundan foyda olishiga ishonch hosil qilishga qaror qildik. Biz ClickHouse-ni MDS orqali emas, balki S3 orqali ClickHouse-ni amalga oshirdik. Va bu juda ko'p ish.
Manbalar:
"Fayl tizimining abstraktsiya qatlami"
"AWS SDK S3 integratsiyasi"
"S3 uchun IDisk interfeysining asosiy amalga oshirilishi"
"Jurnallarni saqlash mexanizmlarini IDisk interfeysi bilan integratsiya qilish"
"S3 va SeekableReadBuffer uchun tizimni qo'llab-quvvatlash jurnali"
"Storage Stripe Log S3-ni qo'llab-quvvatlash"
"S3 uchun Storage MergeTree-ni dastlabki qo'llab-quvvatlash"
"MergeTree S3 uchun to'liq qo'llab-quvvatlash"
"ReplicatedMergeTree-ni S3 orqali qo'llab-quvvatlash"
"S3 xotirasi uchun standart hisob ma'lumotlari va maxsus sarlavhalarni qo'shing"
"Dinamik proksi-server konfiguratsiyasi bilan S3"
"S3 proksi-resoler bilan"
Bu ClickHouse-da virtual fayl tizimini joriy qilish uchun tortishish so'rovlari ro'yxati. Bu tortishish so'rovlarining katta soni.
Manbalar:
"DiskS3 qattiq ulanishlarni optimal amalga oshirish"
"S3 HTTP mijozi - javob oqimini xotiraga nusxalashdan saqlaning"
“S3 HTTP-da butun javob oqimini xotiraga nusxalashdan saqlaning
mijoz"
"S3 disk uchun belgilar va indeks fayllarini keshlash qobiliyati"
"Qismlarni DiskLocal-dan DiskS3-ga parallel ravishda ko'chiring"
Ammo ish shu bilan tugamadi. Xususiyat yaratilgandan so'ng, ushbu funksiyani optimallashtirish uchun biroz ko'proq ishlash kerak bo'ldi.
Manbalar:
"SelectedRows va SelectedBytes hodisalarini qo'shish"
"S3 so'rovidan system.events-ga profil yaratish hodisalarini qo'shing"
"QueryTimeMicroseconds, SelectQueryTimeMicroseconds va InsertQueryTimeMicroseconds qo'shing"
Va keyin uni diagnostika qilish, monitoringni o'rnatish va uni boshqarish mumkin bo'lishi kerak edi.
Va bularning barchasi butun jamoa, butun ClickHouse ekotizimlari ushbu ish natijasini olishlari uchun amalga oshirildi.
Keling, tranzaktsion ma'lumotlar bazalariga, shaxsan menga yaqinroq bo'lgan OLTP ma'lumotlar bazalariga o'tamiz.
Bu ochiq manbali DBMS ishlab chiqish bo'limi. Bu bolalar tranzaktsion ochiq ma'lumotlar bazalarini yaxshilash uchun ko'cha sehrini qilmoqdalar.
Qanday qilib va nima qilishimiz haqida gapirishimiz mumkin bo'lgan loyihalardan biri bu Postgresdagi Connection Pooler.
Postgres - bu jarayon ma'lumotlar bazasi. Bu shuni anglatadiki, ma'lumotlar bazasi tranzaktsiyalarni amalga oshiradigan imkon qadar kamroq tarmoq ulanishiga ega bo'lishi kerak.
Boshqa tomondan, bulutli muhitda mingta ulanish bir vaqtning o'zida bir klasterga kelganda odatiy holat. Va ulanish hovuzchisining vazifasi mingta ulanishni oz sonli server ulanishlariga to'plashdir.
Aytishimiz mumkinki, ulanish hovuzchisi - bu baytlarni ma'lumotlar bazasiga samarali kirishi uchun qayta tartibga soluvchi telefon operatori.
Afsuski, ulanish hovuzchisi uchun yaxshi ruscha so'z yo'q. Ba'zan u multipleksorli ulanishlar deb ataladi. Agar siz ulanish hovuzchisini nima deb atashni bilsangiz, menga ayting, men to'g'ri rus texnik tilida gapirishdan juda xursand bo'laman.
Biz boshqariladigan postgres klasteri uchun mos bo'lgan ulanish hovuzlarini tekshirdik. Va PgBouncer biz uchun eng yaxshi tanlov edi. Ammo biz PgBouncer bilan bir qator muammolarga duch keldik. Ko'p yillar oldin Volodya Borodin biz PgBouncer-dan foydalanayotganimiz haqida xabar bergan edi, bizga hamma narsa yoqadi, ammo nuanslar bor, ustida ishlash kerak bo'lgan narsa bor.
Va biz ishladik. Biz duch kelgan muammolarni tuzatdik, Bouncer-ni tuzatdik va pull so'rovlarini yuqoriga ko'tarishga harakat qildik. Ammo fundamental bir torli bilan ishlash qiyin edi.
Biz yamalgan Bouncers dan kaskadlarni yig'ishimiz kerak edi. Agar bizda ko'plab bitta ipli Bouncers mavjud bo'lsa, yuqori qatlamdagi ulanishlar Bouncersning ichki qatlamiga o'tkaziladi. Bu yomon boshqariladigan tizim bo'lib, uni qurish va oldinga va orqaga kengaytirish qiyin.
Biz Odyssey deb nomlangan o'z ulanish pulerimizni yaratdik degan xulosaga keldik. Biz uni boshidan yozdik.
2019 yilda PgCon konferentsiyasida men ushbu hovuzni ishlab chiquvchilar hamjamiyatiga taqdim etdim. Endi bizda GitHub-da 2 dan bir oz kamroq yulduz bor, ya'ni loyiha tirik, loyiha mashhur.
Va agar siz Yandex.Cloud-da Postgres klasterini yaratsangiz, u klasterni oldinga yoki orqaga o'tkazishda o'rnatilgan Odyssey-ga ega klaster bo'ladi.
Ushbu loyihadan nimani o'rgandik? Raqobatbardosh loyihani ishga tushirish har doim tajovuzkor qadam bo'lib, biz etarlicha tez hal etilmagan, bizga mos keladigan vaqt oralig'ida hal etilmagan muammolar borligini aytganda, bu ekstremal choradir. Ammo bu samarali chora.
PgBouncer tezroq rivojlana boshladi.
Va endi boshqa loyihalar paydo bo'ldi. Masalan, Red Hat ishlab chiquvchilari tomonidan ishlab chiqilgan pgagroal. Ular o'xshash maqsadlarni ko'zlaydilar va shunga o'xshash g'oyalarni amalga oshiradilar, lekin, albatta, pgagroal ishlab chiqaruvchilariga yaqinroq bo'lgan o'ziga xos xususiyatlarga ega.
Postgres hamjamiyati bilan ishlashning yana bir holati - bu vaqtni tiklash. Bu nosozlikdan keyin tiklanish, bu zaxiradan tiklash.
Ko'p zaxira nusxalari mavjud va ularning barchasi boshqacha. Deyarli har bir Postgres sotuvchisi o'zining zaxira echimiga ega.
Agar siz barcha zaxira tizimlarini olsangiz, xususiyat matritsasini yaratsangiz va ushbu matritsadagi determinantni hazil bilan hisoblasangiz, u nolga teng bo'ladi. Bu nimani anglatadi? Agar siz ma'lum bir zaxira faylini olsangiz, uni boshqa barcha qismlardan yig'ib bo'lmaydi. Amalga oshirishda ham, maqsadda ham, unda mujassamlangan g‘oyalar ham o‘ziga xosdir. Va ularning barchasi o'ziga xosdir.
Biz ushbu masala ustida ishlayotganimizda, CitusData WAL-G loyihasini ishga tushirdi. Bu bulutli muhitni hisobga olgan holda yaratilgan zaxira tizimi. Endi CitusData allaqachon Microsoft-ning bir qismidir. Va o'sha paytda bizga WAL-G ning dastlabki nashrlarida keltirilgan g'oyalar juda yoqdi. Va biz ushbu loyihaga o'z hissamizni qo'shishni boshladik.
Hozirda ushbu loyihada o'nlab ishlab chiquvchilar mavjud, ammo WAL-G-ning eng yaxshi 10 ta ishtirokchisiga 6 ta Yandexoid kiradi. U yerga ko‘plab g‘oyalarimizni olib keldik. Va, albatta, biz ularni o'zimiz amalga oshirdik, o'zimiz sinab ko'rdik, ularni o'zimiz ishlab chiqardik, biz ulardan o'zimiz foydalanamiz, katta WAL-G hamjamiyati bilan o'zaro aloqada bo'lgan holda keyingi qayerga borishni o'zimiz aniqlaymiz.
Va bizning nuqtai nazarimizdan, endi bu zaxira tizimi, shu jumladan bizning sa'y-harakatlarimizni hisobga olgan holda, bulutli muhit uchun maqbul bo'ldi. Bu bulutda Postgres-ni zaxiralashning eng yaxshi xarajati.
Bu nima degani? Biz juda katta g'oyani ilgari surgan edik: zaxira xavfsiz bo'lishi, ishlatish uchun arzon va iloji boricha tezroq tiklanishi kerak.
Nima uchun operatsiya qilish arzon bo'lishi kerak? Hech narsa buzilmaganda, sizda zaxirangiz borligini bilmasligingiz kerak. Hammasi yaxshi ishlaydi, siz imkon qadar kamroq protsessorni behuda sarflaysiz, disk resurslaridan imkon qadar kamroq foydalanasiz va qimmatli xizmatlaringizning foydali yukiga xalaqit bermaslik uchun tarmoqqa imkon qadar kamroq bayt yuborasiz.
Va hamma narsa buzilganda, masalan, administrator ma'lumotlarni tashlab qo'ydi, nimadir noto'g'ri ketdi va siz zudlik bilan o'tmishga qaytishingiz kerak, siz barcha pul bilan tiklanasiz, chunki siz ma'lumotlaringizni tez va buzilmagan holda qaytarib olishni xohlaysiz.
Va biz bu oddiy g'oyani ilgari surdik. Va, bizningcha, biz buni amalga oshirishga muvaffaq bo'ldik.
Lekin bu hammasi emas. Biz yana bir kichik narsani xohladik. Biz turli xil ma'lumotlar bazalarini xohladik. Bizning barcha mijozlarimiz Postgres-dan foydalanmaydi. Ba'zi odamlar MySQL, MongoDB dan foydalanadilar. Jamiyatda boshqa ishlab chiquvchilar FoundationDB-ni qo'llab-quvvatladilar. Va bu ro'yxat doimiy ravishda kengayib bormoqda.
Hamjamiyat ma'lumotlar bazasini bulutda boshqariladigan muhitda ishga tushirish g'oyasini yoqtiradi. Va ishlab chiquvchilar o'zlarining ma'lumotlar bazalarini saqlab turishadi, ular bizning zaxira tizimimiz bilan Postgres bilan bir xilda zaxiralanishi mumkin.
Bu hikoyadan nimani o'rgandik? Bizning mahsulotimiz rivojlanish bo'limi sifatida kod satrlari emas, bayonotlar emas, bu fayllar emas. Bizning mahsulotimiz tortishish talablari emas. Bu biz jamiyatga yetkazadigan g‘oyalardir. Bu texnologik tajriba va texnologiyaning bulutli muhitga harakati.
Postgres kabi ma'lumotlar bazasi mavjud. Menga eng ko'p Postgres yadrosi yoqadi. Men jamiyat bilan Postgres yadrosini rivojlantirishga ko'p vaqt sarflayman.
Ammo bu erda shuni aytish kerakki, Yandex.Cloud boshqariladigan ma'lumotlar bazalarining ichki o'rnatilishiga ega. Va bu Yandex.Mail-da uzoq vaqt oldin boshlangan. Postgres-ni boshqarishga olib kelgan tajriba pochta Postgres-ga o'tishni xohlaganida to'plangan.
Pochta bulutga juda o'xshash talablarga ega. Bu sizning ma'lumotlaringizning istalgan nuqtasida kutilmagan eksponensial o'sishga o'tish imkoniyatiga ega bo'lishingiz kerak. Pochta allaqachon ko'plab so'rovlarni yuboradigan juda ko'p sonli foydalanuvchilarning yuz millionlab pochta qutilariga yuklangan.
Va bu Postgresni ishlab chiqayotgan jamoa uchun juda jiddiy muammo edi. O‘shanda biz duch kelgan har qanday muammolar haqida jamiyatga xabar qilinardi. Va bu muammolar tuzatildi va ba'zi joylarda hamjamiyat tomonidan tuzatildi, hatto ba'zi boshqa ma'lumotlar bazalari uchun pullik yordam darajasida va undan ham yaxshiroq. Ya'ni, siz PgSQL xakeriga xat yuborishingiz va 40 daqiqa ichida javob olishingiz mumkin. Ba'zi ma'lumotlar bazalarida pullik yordam sizning xatoingizdan ko'ra ko'proq ustuvor narsalar bor deb o'ylashi mumkin.
Endi Postgres-ning ichki o'rnatilishi bir necha petabayt ma'lumotlardan iborat. Bu soniyada millionlab so'rovlar. Bular minglab klasterlar. Bu juda keng ko'lamli.
Ammo bir nuance bor. U ajoyib tarmoq drayverlarida emas, balki juda oddiy apparatda yashaydi. Va qiziqarli yangi narsalar uchun maxsus sinov muhiti mavjud.
Va test muhitida ma'lum bir vaqtda biz ma'lumotlar bazasi indekslarining ichki invariantlari buzilganligini ko'rsatadigan xabarni oldik.
Invariant - bu biz doimo ushlab turishni kutgan munosabatlarning bir turi.
Biz uchun juda og'ir vaziyat. Bu ba'zi ma'lumotlar yo'qolgan bo'lishi mumkinligini ko'rsatadi. Va ma'lumotlarning yo'qolishi - bu mutlaqo halokatli narsa.
Boshqariladigan ma'lumotlar bazalarida biz amal qiladigan umumiy g'oya shundan iboratki, hatto harakat qilsak ham, ma'lumotlarni yo'qotish qiyin bo'ladi. Agar siz ularni ataylab olib tashlasangiz ham, uzoq vaqt davomida ularning yo'qligiga e'tibor bermasligingiz kerak bo'ladi. Ma'lumotlar xavfsizligi - bu biz juda astoydil amal qiladigan din.
Va bu erda biz tayyor bo'lmasligimiz mumkin bo'lgan vaziyat bo'lishi mumkinligini ko'rsatadigan vaziyat yuzaga keladi. Va biz bu vaziyatga tayyorlana boshladik.
Biz qilgan birinchi narsa bu minglab klasterlarning loglarini ko'mib tashlash edi. Klasterlarning qaysi biri ma'lumotlar sahifasi yangilanishini yo'qotayotgan muammoli proshivkali disklarda joylashganligini aniqladik. Barcha Postgres ma'lumotlar kodini belgiladi. Va biz ichki invariantlarning buzilishini ko'rsatadigan xabarlarni ma'lumotlarning buzilishini aniqlash uchun mo'ljallangan kod bilan belgiladik.
Ushbu yamoq amalda ko'p muhokamalarsiz hamjamiyat tomonidan qabul qilindi, chunki har bir alohida holatda biron bir yomon narsa sodir bo'lganligi va jurnalga xabar berilishi kerakligi aniq edi.
Shundan so'ng, biz jurnallarni skanerlaydigan monitoringimiz borligiga keldik. Va shubhali xabarlar bo'lsa, u navbatchini uyg'otadi va navbatchi uni tuzatadi.
Lekin! Jurnallarni skanerlash - bu bitta klasterda arzon operatsiya va mingta klaster uchun halokatli darajada qimmat.
deb nomlangan kengaytmani yozdik . U ma'lumotlar bazasi ko'rinishini yaratadi, unda siz o'tgan xatolar bo'yicha statistik ma'lumotlarni arzon va tez tanlashingiz mumkin. Va agar biz navbatchini uyg'otishimiz kerak bo'lsa, biz bu haqda gigabaytli fayllarni skanerlamasdan, lekin xesh jadvalidan bir necha baytni ajratib olish orqali bilib olamiz.
Ushbu kengaytma, masalan, uchun omborda qabul qilingan . Agar siz undan foydalanmoqchi bo'lsangiz, uni o'zingiz o'rnatishingiz mumkin. Albatta, bu ochiq manba.
Lekin bu hammasi emas. Biz indekslardagi o'zgarmas qoidabuzarliklarni aniqlash uchun Amcheck kengaytmasidan foydalanishni boshladik.
Va agar siz uni miqyosda ishlatsangiz, xatolar borligini aniqladik. Biz ularni tuzatishni boshladik. Bizning tuzatishlarimiz qabul qilindi.
Ushbu kengaytma GiST va GIT indekslarini tahlil qila olmasligini aniqladik. Biz ularni qo'llab-quvvatladik. Ammo bu qo'llab-quvvatlash hali ham jamiyat tomonidan muhokama qilinmoqda, chunki bu nisbatan yangi funksionallik va u erda juda ko'p tafsilotlar mavjud.
Shuningdek, biz replikatsiya yetakchisida, masterda indekslarni buzilishlar uchun tekshirishda hamma narsa yaxshi ishlayotganini, lekin replikalarda, izdoshda korruptsiyani qidirish unchalik samarali emasligini aniqladik. Hamma invariantlar tekshirilmaydi. Va bitta invariant bizni juda bezovta qildi. Replikalarni tekshirishni yoqish uchun biz bir yarim yil davomida hamjamiyat bilan muloqot qildik.
Biz barcha can... protokollariga amal qilishi kerak bo'lgan kodni yozdik. Biz ushbu yamoqni Crunchy Data-dan Piter Gagan bilan ancha vaqt muhokama qildik. Ushbu yamoqni qabul qilish uchun u Postgresdagi mavjud B-daraxtni biroz o'zgartirishi kerak edi. U qabul qilindi. Va endi replikalardagi indekslarni tekshirish ham biz duch kelgan qoidabuzarliklarni aniqlash uchun samarali bo'ldi. Ya'ni, bu disk mikrodasturidagi xatolar, Postgres-dagi xatolar, Linux yadrosidagi xatolar va apparat muammolari tufayli yuzaga kelishi mumkin bo'lgan buzilishlar. Biz tayyorlayotgan muammolar manbalarining juda keng ro'yxati.
Ammo indekslardan tashqari, yig'ish kabi qism ham mavjud, ya'ni ma'lumotlar saqlanadigan joy. Va tekshirilishi mumkin bo'lgan ko'p invariantlar mavjud emas.
Bizda Heapcheck deb nomlangan kengaytma mavjud. Biz uni rivojlantirishni boshladik. Va parallel ravishda, biz bilan birgalikda EnterpriseDB kompaniyasi ham xuddi shu tarzda Heapcheck deb nomlangan modul yozishni boshladilar. Faqat biz uni PgHeapcheck deb atashdik, ular esa uni Heapcheck deb atashdi. Ular shunga o'xshash funktsiyalarga ega, biroz boshqacha imzo, lekin bir xil g'oyalar bilan. Ular ba'zi joylarda ularni biroz yaxshiroq amalga oshirdilar. Va ular buni oldin ochiq manbaga joylashtirdilar.
Va endi biz ularning kengayishini rivojlantirmoqdamiz, chunki bu endi ularning kengayishi emas, balki jamiyatning kengayishi. Va kelajakda bu yadroning bir qismi bo'lib, u kelajakdagi muammolar haqida oldindan bilishi uchun har bir kishiga beriladi.
Ba'zi joylarda biz hatto monitoring tizimlarimizda noto'g'ri pozitivlar bor degan xulosaga keldik. Masalan, 1C tizimi. Ma'lumotlar bazasidan foydalanganda, Postgres ba'zan unga o'qiy oladigan ma'lumotlarni yozadi, lekin pg_dump o'qiy olmaydi.
Bu holat bizning muammolarni aniqlash tizimimiz uchun korruptsiyaga o'xshardi. Navbatchi uyg‘ondi. Navbatchi nima bo'layotganiga qaradi. Biroz vaqt o'tgach, mijoz kelib, menda muammolar borligini aytdi. Xizmatchi muammo nimada ekanligini tushuntirdi. Ammo muammo Postgres yadrosida.
Men bu xususiyat haqida munozara topdim. Va u biz bu xususiyatga duch kelganimizni va bu yoqimsiz ekanligini yozdi, bir kishi nima ekanligini tushunish uchun kechasi uyg'ondi.
Jamiyat: "Oh, biz buni tuzatishimiz kerak", deb javob berishdi.
Menda oddiy o'xshashlik bor. Agar siz qum donasi bo'lgan poyafzalda yursangiz, unda, qoida tariqasida, siz harakat qilishingiz mumkin - muammo yo'q. Agar siz minglab odamlarga etik sotsangiz, unda umuman qumsiz etik yasaylik. Va agar sizning poyabzalingiz foydalanuvchilaridan biri marafonda qatnashmoqchi bo'lsa, unda siz juda yaxshi poyabzal yasashni xohlaysiz va keyin ularni barcha foydalanuvchilaringiz uchun kengaytirmoqchisiz. Va bunday kutilmagan foydalanuvchilar doimo bulutli muhitda. Klasterdan har doim o'ziga xos tarzda foydalanadigan foydalanuvchilar bor. Bunga doimo tayyorgarlik ko'rishingiz kerak.
Biz bu erda nimani o'rgandik? Biz oddiy narsani bilib oldik: eng muhimi, jamiyatga muammo borligini tushuntirish. Agar jamiyat muammoni tan olgan bo'lsa, muammoni hal qilish uchun tabiiy raqobat paydo bo'ladi. Chunki hamma muhim muammoni hal qilishni xohlaydi. Barcha sotuvchilar, barcha xakerlar o'zlari bu rakega qadam qo'yishlari mumkinligini tushunishadi, shuning uchun ularni yo'q qilishni xohlashadi.
Agar siz muammo ustida ishlayotgan bo'lsangiz, lekin u sizdan boshqa hech kimni bezovta qilmasa, lekin siz tizimli ravishda ishlasangiz va u oxir-oqibat muammo deb hisoblansa, sizning tortishish so'rovingiz albatta qabul qilinadi. Sizning yamoqingiz qabul qilinadi, yaxshilanishlaringiz yoki hatto yaxshilash bo'yicha so'rovlaringiz hamjamiyat tomonidan ko'rib chiqiladi. Oxir-oqibat, biz ma'lumotlar bazasini bir-birimiz uchun yaxshiroq qilamiz.
Qiziqarli ma'lumotlar bazasi Greenplum. Bu men juda yaxshi tanish bo'lgan Postgres kod bazasiga asoslangan juda parallel ma'lumotlar bazasi.
Va Greenplum qiziqarli funksiyalarga ega - optimallashtirilgan jadvallarni qo'shing. Bu siz tezda qo'shishingiz mumkin bo'lgan jadvallar. Ular ustunli yoki qatorli bo'lishi mumkin.
Ammo klasterlash yo'q edi, ya'ni jadvalda joylashgan ma'lumotlarni indekslardan birida joylashgan tartibda joylashtirishingiz mumkin bo'lgan funksionallik yo'q edi.
Taksidagi yigitlar mening oldimga kelib: “Andrey, siz Postgresni bilasiz. Va bu erda deyarli bir xil. 20 daqiqaga o'ting. Oling va bajaring”. Men ha, men Postgresni bilaman, 20 daqiqaga almashtiraman deb o'yladim - buni qilishim kerak.
Lekin yo'q, bu 20 daqiqa emas edi, men buni oylar davomida yozdim. PgConf.Russia konferentsiyasida men Pivotal kompaniyasidan Heikki Linakangasga murojaat qildim va so'radim: “Bu bilan bog'liq muammolar bormi? Nima uchun qo'shimcha optimallashtirilgan jadval klasteri mavjud emas? U shunday deydi: "Siz ma'lumotlarni olasiz. Siz tartiblaysiz, qayta tashkil qilasiz. Bu shunchaki ish”. Men: "Oh, ha, siz uni olib, qilishingiz kerak." U shunday deydi: "Ha, buning uchun bizga qo'llar bo'sh kerak." Men buni albatta qilishim kerak deb o'yladim.
Va bir necha oy o'tgach, men ushbu funktsiyani amalga oshiradigan tortishish so'rovini yubordim. Bu tortishish soʻrovi Pivotal tomonidan hamjamiyat bilan birgalikda koʻrib chiqildi. Albatta, xatolar bor edi.
Ammo eng qizig'i shundaki, bu tortishish so'rovi birlashtirilganda, xatolar Greenplumning o'zida topilgan. Biz topdik jadvallar ba'zan klasterlashganda tranzaksiyani buzadi. Va bu tuzatish kerak bo'lgan narsa. Va u men tegingan joyda. Va mening tabiiy munosabatim shunday bo'ldi - mayli, menga ham buni qilishga ruxsat bering.
Men bu xatolikni tuzatdim. Tuzatuvchilarga tortish so'rovi yuborildi. U o'ldirilgan.
Shundan so'ng, bu funksiyani PostgreSQL 12 uchun Greenplum versiyasida olish kerakligi ma'lum bo'ldi. Ya'ni, 20 daqiqalik sarguzasht yangi qiziqarli sarguzashtlar bilan davom etadi. Jamiyat yangi va eng muhim xususiyatlarni kesib tashlaydigan hozirgi rivojlanishga tegish qiziq edi. Muzlab qolgan.
Lekin bu bilan tugamadi. Hamma narsadan so'ng, bularning barchasi uchun hujjatlarni yozishimiz kerak bo'ldi.
Men hujjatlar yozishni boshladim. Yaxshiyamki, Pivotal'dan hujjatli rassomlar kelishdi. Ingliz tili ularning ona tilidir. Ular menga hujjatlarni rasmiylashtirishda yordam berishdi. Aslida, ular o'zlari men taklif qilgan narsalarni haqiqiy ingliz tiliga qayta yozishdi.
Mana, sarguzasht tugadi shekilli. Va keyin nima bo'lganini bilasizmi? Taksidagi yigitlar yonimga kelib: "Hali ikkita sarguzasht bor, har biri 10 daqiqadan", - deyishdi. Va ularga nima deyishim kerak? Men hozir miqyosda hisobot beraman, keyin sizning sarguzashtlaringizni ko'ramiz, chunki bu qiziqarli ish ekanligini aytdim.
Biz bu holatdan nimani o'rgandik? Chunki ochiq manba bilan ishlash har doim ma'lum bir shaxs bilan ishlaydi, u doimo jamiyat bilan ishlaydi. Chunki har bir bosqichda men ishlab chiquvchi, tester, xaker, hujjatchi, me'mor bilan ishladim. Men Greenplum bilan ishlamadim, Greenplum atrofidagi odamlar bilan ishladim.
Lekin! Yana bir muhim jihat bor - bu shunchaki ish. Ya'ni, kelasiz, qahva ichasiz, kod yozasiz. Barcha turdagi oddiy invariantlar ishlaydi. Buni odatdagidek bajaring - hammasi yaxshi bo'ladi! Va bu juda qiziq ish. Ushbu ish uchun Yandex.Cloud mijozlaridan, Yandex ichida ham, tashqarisida ham bizning klasterlarimiz foydalanuvchilaridan so'rov mavjud. O‘ylaymanki, biz ishtirok etayotgan loyihalar soni ortib, ishtirokimiz chuqurligi ham ortadi.
Ana xolos. Keling, savollarga o'tamiz.
Savollar sessiyasi
Salom! Bizda yana bir savol-javob bor. Va Andrey Borodin studiyasida. Bu sizga Yandex.Cloud va Yandex-ning ochiq manbaga qo'shgan hissasi haqida gapirgan odam. Hozir bizning hisobotimiz butunlay Bulut haqida emas, lekin shu bilan birga biz bunday texnologiyalarga asoslanganmiz. Yandex ichida nima qilgansiz, Yandex.Cloud-da hech qanday xizmat bo'lmaydi, shuning uchun shaxsan mendan rahmat. Va eshittirishning birinchi savoli: "Siz aytib o'tgan loyihalarning har biri nimada yozilgan?"
WAL-G-dagi zaxira tizimi Go-da yozilgan. Bu biz ishlagan yangi loyihalardan biri. U tom ma'noda atigi 3 yoshda. Va ma'lumotlar bazasi ko'pincha ishonchlilik bilan bog'liq. Va bu shuni anglatadiki, ma'lumotlar bazalari ancha eski va ular odatda C tilida yozilgan. Postgres loyihasi taxminan 30 yil oldin boshlangan. Keyin C89 to'g'ri tanlov edi. Unda Postgres yozilgan. ClickHouse kabi zamonaviyroq ma'lumotlar bazalari odatda C++ da yoziladi. Barcha tizim rivojlanishi C va C++ atrofida asoslanadi.
Cloud xarajatlari uchun javobgar bo'lgan moliyaviy menejerimizdan savol: "Nega Cloud ochiq manbani qo'llab-quvvatlash uchun pul sarflaydi?"
Bu erda moliyaviy menejer uchun oddiy javob bor. Biz buni xizmatlarimizni yaxshilash uchun qilamiz. Qaysi yo'llar bilan biz yaxshiroq ish qila olamiz? Biz ishlarni yanada samaraliroq, tezroq bajarishimiz va ishlarni yanada kengroq qilishimiz mumkin. Ammo biz uchun bu hikoya birinchi navbatda ishonchlilik bilan bog'liq. Misol uchun, zaxira tizimida biz unga tegishli bo'lgan yamoqlarning 100% ni ko'rib chiqamiz. Kod nima ekanligini bilamiz. Va biz ishlab chiqarishga yangi versiyalarni chiqarish qulayroqdir. Ya'ni, birinchi navbatda, bu ishonch, rivojlanishga tayyorlik va ishonchlilik haqida
Yana bir savol: "Yandeks.Cloud-da yashovchi tashqi foydalanuvchilarning talablari ichki bulutda yashovchi ichki foydalanuvchilardan farq qiladimi?"
Yuklash profili, albatta, boshqacha. Lekin mening bo'lim nuqtai nazaridan, barcha maxsus va qiziqarli holatlar nostandart yukda yaratilgan. Tasavvurga ega ishlab chiquvchilar, kutilmagan narsalarni qiladigan ishlab chiquvchilar, ham ichki, ham tashqi tomondan topiladi. Shu nuqtai nazardan, biz hammamiz taxminan bir xilmiz. Va, ehtimol, Yandex ma'lumotlar bazalari bilan ishlashning yagona muhim xususiyati shundaki, Yandex ichida bizda ta'lim mavjud. Bir nuqtada, ba'zi mavjudlik zonalari butunlay soyaga kiradi va shunga qaramay, barcha Yandex xizmatlari qandaydir tarzda ishlashda davom etishi kerak. Bu kichik farq. Ammo bu ma'lumotlar bazasi va tarmoq stekining interfeysida ko'plab tadqiqot ishlanmalarini yaratadi. Aks holda, tashqi va ichki o'rnatishlar ishonchlilik va unumdorlikni oshirish uchun xususiyatlar va shunga o'xshash so'rovlar uchun bir xil so'rovlarni yaratadi.
Keyingi savol: "Shaxsan siz qilayotgan ishlarning aksariyati boshqa bulutlar tomonidan ishlatilishiga qanday qaraysiz?" Biz aniqlarini nomlamaymiz, lekin Yandex.Cloud-da amalga oshirilgan ko'plab loyihalar boshqa odamlarning bulutlarida qo'llaniladi.
Bu ajoyib. Birinchidan, bu biz to'g'ri ish qilganimizdan dalolatdir. Va bu egoni tirnaydi. Va biz to'g'ri qaror qabul qilganimizga ishonchimiz ko'proq. Boshqa tomondan, bu kelajakda bizga yangi g'oyalar, uchinchi tomon foydalanuvchilarining yangi so'rovlarini olib keladi degan umiddir. GitHub-dagi aksariyat masalalar alohida tizim ma'murlari, individual DBA'lar, individual arxitektorlar, individual muhandislar tomonidan yaratilgan, lekin ba'zida tizimli tajribaga ega odamlar kelib, ma'lum holatlarning 30 foizida bizda bu muammo borligini aytishadi va keling, uni qanday hal qilish haqida o'ylab ko'raylik. Bu biz eng ko'p kutayotgan narsadir. Biz boshqa bulutli platformalar bilan tajriba almashishni orziqib kutamiz.
Siz marafon haqida ko'p gapirdingiz. Siz Moskvada marafonda yugurganingizni bilaman. Natijada? PostgreSQL yigitlarini ortda qoldirdingizmi?
Yo'q, Oleg Bartunov juda tez yuguradi. U mendan bir soat oldin tugatdi. Umuman olganda, men qanchalik uzoqqa erishganimdan mamnunman. Men uchun shunchaki tugatish yutuq edi. Umuman olganda, postgres hamjamiyatida juda ko'p yuguruvchilar borligi ajablanarli. Menimcha, aerobik sport va tizimni dasturlash istagi o'rtasida qandaydir bog'liqlik bor.
ClickHouse-da yuguruvchilar yo'qligini aytyapsizmi?
Men ular borligini aniq bilaman. ClickHouse ham ma'lumotlar bazasi hisoblanadi. Aytgancha, Oleg hozir menga yozmoqda: "Hisobotdan keyin yuguramizmi?" Bu ajoyib fikr.
Nikitadan yana bir savol: "Nega Greenplum-dagi xatoni o'zingiz tuzatdingiz va uni yoshlarga bermadingiz?" To'g'ri, xato nima va qaysi xizmatda ekanligi unchalik aniq emas, lekin bu siz gapirgan narsani anglatadi.
Ha, printsipial jihatdan, kimgadir berilishi mumkin edi. Bu faqat men o'zgartirgan kod edi. Va buni darhol davom ettirish tabiiy edi. Asosan, jamoa bilan tajriba almashish g'oyasi yaxshi fikr. Biz Greenplum vazifalarini bo'linmamizning barcha a'zolari orasida baham ko'ramiz.
Biz o'smirlar haqida gapirayotganimiz sababli, bu erda bir savol. Odam Postgresda birinchi majburiyatni yaratishga qaror qildi. Birinchi majburiyatni bajarish uchun u nima qilishi kerak?
Bu qiziq savol: "Qaerdan boshlash kerak?" Odatda yadrodagi biror narsadan boshlash juda qiyin. Masalan, Postgres-da qilinadigan ishlar ro'yxati mavjud. Ammo, aslida, bu ular harakat qilgan, ammo muvaffaqiyatga erisha olmagan narsalarning varag'i. Bu murakkab narsalar. Va odatda siz ekotizimda ba'zi yordamchi dasturlarni topishingiz mumkin, ba'zi yaxshilanishi mumkin bo'lgan kengaytmalar yadro ishlab chiquvchilarning e'tiborini kamroq jalb qiladi. Va shunga ko'ra, u erda o'sish uchun ko'proq nuqtalar mavjud. Google Summer of code dasturida har yili postgres hamjamiyati ko'rib chiqilishi mumkin bo'lgan turli mavzularni ilgari suradi. Bu yil, menimcha, bizda uchta talaba bor edi. Hatto biri WAL-G da Yandex uchun muhim bo'lgan mavzularda yozgan. Greenplum-da hamma narsa Postgres hamjamiyatiga qaraganda sodda, chunki Greenplum xakerlari tortishish so'rovlariga juda yaxshi munosabatda bo'lishadi va darhol ko'rib chiqishni boshlaydilar. Postgres-ga yamoq yuborish bir necha oylik masala, ammo Greenplum bir kundan keyin keladi va nima qilganingizni ko'radi. Yana bir narsa shundaki, Greenplum hozirgi muammolarni hal qilishi kerak. Greenplum keng qo'llanilmaydi, shuning uchun muammoingizni topish juda qiyin. Va birinchi navbatda, biz muammolarni hal qilishimiz kerak, albatta.
Manba: www.habr.com