Aprel oyida Avito muhandislari ClickHouse-ning asosiy ishlab chiqaruvchisi Aleksey Milovidov va Integrosdan Golang dasturchisi Kirill Shvakov bilan onlayn uchrashuvlar uchun yig'ilishdi. Biz ma'lumotlar bazasini boshqarish tizimidan qanday foydalanishimiz va qanday qiyinchiliklarga duch kelayotganimizni muhokama qildik.
Uchrashuvga asoslanib, biz mutaxassislarning o'zimizning va tomoshabinlarning zaxira nusxalari, ma'lumotlarni qayta taqsimlash, tashqi lug'atlar, Golang drayverlari va ClickHouse versiyalarini yangilash haqidagi savollariga javoblari bilan maqola tuzdik. Bu Yandex DBMS bilan faol ishlayotgan va uning hozirgi va kelajagi bilan qiziqqan ishlab chiquvchilar uchun foydali bo'lishi mumkin. Odatiy bo'lib, agar boshqacha yozilmagan bo'lsa, javoblar Aleksey Milovidov tomonidan berilgan.
Ehtiyot bo'ling, kesim ostida juda ko'p matn bor. Umid qilamizki, savollarga ega bo'lgan tarkib sizga navigatsiya qilishga yordam beradi.
Mundarija
Agar siz matnni o'qishni xohlamasangiz, yig'ilishlar yozuvini tomosha qilishingiz mumkin . Vaqt kodlari video ostidagi birinchi izohda.
ClickHouse doimiy ravishda yangilanadi, ammo bizning ma'lumotlarimiz yo'q. Bu haqda nima qilish kerak?
ClickHouse doimiy ravishda yangilanadi va yakuniy qayta ishlangan optimallashtirilgan ma'lumotlarimiz yangilanmaydi va zaxira nusxada.
Aytaylik, muammoga duch keldik va ma'lumotlar yo'qoldi. Biz qayta tiklashga qaror qildik va ma'lum bo'ldiki, zaxira serverlarida saqlanadigan eski bo'limlar hozirda ishlatiladigan ClickHouse versiyasidan juda farq qiladi. Bunday vaziyatda nima qilish kerak va bu mumkinmi?
Eski formatdagi zaxiradan ma'lumotlarni qayta tiklagan, ammo yangi versiyaga ulanmagan vaziyat mumkin emas. Biz ClickHouse-dagi ma'lumotlar formati har doim orqaga qarab mos kelishiga ishonch hosil qilamiz. Bu, agar ba'zi kamdan-kam ishlatiladigan funksiyalarning xatti-harakati o'zgargan bo'lsa, funksionallikdagi orqaga qarab muvofiqlikdan ko'ra muhimroqdir. ClickHouse-ning yangi versiyasi har doim diskda saqlangan ma'lumotlarni o'qiy olishi kerak. Bu qonun.
ClickHouse-dan ma'lumotlarni zaxiralashning hozirgi eng yaxshi amaliyotlari qanday?
Bizda yakuniy operatsiyalarni optimallashtirish, katta terabayt ma'lumotlar bazasi va so'nggi uch kun ichida yangilanadigan ma'lumotlar mavjudligini va keyin hech qanday protsedura sodir bo'lmasligini hisobga olgan holda zaxira nusxalarini qanday qilish kerak?
Biz o'z yechimimizni yaratib, bash-ga yozishimiz mumkin: bu zaxira nusxalarini shunday va shunga o'xshash tarzda to'plang. Ehtimol, hech narsani qo'ltiqlab qo'yishning hojati yo'q va velosiped allaqachon ixtiro qilinganmi?
Keling, eng yaxshi amaliyotlardan boshlaylik. Mening hamkasblarim har doim zaxira nusxalari haqidagi savollarga javoban, bu muammo allaqachon hal qilingan Yandex.Cloud xizmati haqida eslatib turishni maslahat beradi. Shuning uchun iloji bo'lsa, undan foydalaning.
Zaxiralash uchun to'liq yechim yo'q, yuz foiz ClickHouse-ga o'rnatilgan. Foydalanish mumkin bo'lgan ba'zi blanklar mavjud. To'liq echimga ega bo'lish uchun siz qo'lda ozgina ishlov berishingiz yoki skriptlar ko'rinishidagi o'ramlarni yaratishingiz kerak bo'ladi.
Men eng oddiy echimlardan boshlayman va ma'lumotlar hajmi va klaster hajmiga qarab eng murakkablari bilan yakunlayman. Klaster qanchalik katta bo'lsa, yechim shunchalik murakkab bo'ladi.
Agar ma'lumotlarga ega jadval bir necha gigabaytni egallasa, zaxira nusxasini quyidagicha amalga oshirish mumkin:
- Jadval ta'rifini, ya'ni metama'lumotlarni saqlash - Jadval yaratishni ko'rsatish.
- ClickHouse mijozi yordamida dump qiling - tanlash * stoldan faylga. Odatiy bo'lib, siz TabSeparated formatida faylni olasiz. Agar siz samaraliroq bo'lishni istasangiz, buni Native formatda qilishingiz mumkin.
Agar ma'lumotlar miqdori kattaroq bo'lsa, unda zaxiralash ko'proq vaqt va ko'p joy oladi. Bu mantiqiy zaxira deb ataladi; u ClickHouse ma'lumotlar formatiga bog'liq emas. Agar shunday bo'lsa, oxirgi chora sifatida siz zaxira nusxasini olishingiz va tiklash uchun MySQL-ga yuklashingiz mumkin.
Keyinchalik rivojlangan holatlar uchun ClickHouse mahalliy fayl tizimida bo'limlarning suratini yaratish uchun o'rnatilgan qobiliyatga ega. Bu xususiyat so'rov sifatida mavjud jadvalni muzlatish bo'limini o'zgartiring. Yoki oddiygina stol muzlashini o'zgartiring - bu butun jadvalning surati.
Surat bitta parchada bitta jadval uchun izchil yaratiladi, ya'ni bu tarzda butun klasterning izchil suratini yaratish mumkin emas. Ammo ko'pgina vazifalar uchun bunday ehtiyoj yo'q va har bir parcha bo'yicha so'rovni bajarish va izchil suratga olish kifoya. U qattiq havolalar shaklida yaratilgan va shuning uchun qo'shimcha joy egallamaydi. Keyinchalik, siz ushbu suratni zaxira serveriga yoki zaxiralash uchun foydalanadigan xotiraga nusxalaysiz.
Bunday zaxirani tiklash juda oson. Birinchidan, mavjud jadval ta'riflari yordamida jadvallar yarating. Keyin, bo'limlarning saqlangan suratlarini ushbu jadvallar uchun katalogdan ajratilganga nusxalang va so'rovni bajaring. bo'limni biriktiring. Ushbu yechim eng jiddiy ma'lumotlar hajmi uchun juda mos keladi.
Ba'zan sizga yanada salqinroq narsa kerak bo'ladi - har bir serverda o'nlab yoki hatto yuzlab terabaytlar va yuzlab serverlar bo'lgan hollarda. Bu erda men Yandex.Metrica'dagi hamkasblarimdan olgan yechim bor. Men buni hammaga tavsiya qilmayman - o'qing va mos keladimi yoki yo'qligini o'zingiz hal qiling.
Avval siz katta disk javonlari bo'lgan bir nechta serverlarni yaratishingiz kerak. Keyinchalik, ushbu serverlarda bir nechta ClickHouse serverlarini ko'taring va ularni bir xil parchalar uchun boshqa replika sifatida ishlashi uchun sozlang. Va keyin ushbu serverlarda oniy tasvirlarni yaratishga imkon beruvchi fayl tizimi yoki ba'zi vositadan foydalaning. Bu erda ikkita variant mavjud. Birinchi variant - LVM snapshotlari, ikkinchi variant - Linuxda ZFS.
Shundan so'ng, har kuni siz suratni yaratishingiz kerak, u yolg'on gapiradi va bir oz joy egallaydi. Tabiiyki, agar ma'lumotlar o'zgarsa, vaqt o'tishi bilan bo'sh joy miqdori ortadi. Ushbu suratni istalgan vaqtda olib tashlash mumkin va ma'lumotlar qayta tiklanadi, bunday g'alati yechim. Bundan tashqari, biz konfiguratsiyada ushbu replikalarni ham cheklashimiz kerak, shunda ular yetakchi bo'lishga harakat qilmaydi.
Millarda replikalarning boshqariladigan kechikishini tashkil qilish mumkinmi?
Bu yil siz ClickHouse-da shaftlar yasashni rejalashtirmoqdasiz. Ularda replikalarning boshqariladigan kechikishini tashkil qilish mumkinmi? Biz undan o'zimizni o'zgartirishlar va boshqa o'zgarishlar bilan salbiy stsenariylardan himoya qilish uchun foydalanmoqchimiz.
O'zgartirishlar uchun qandaydir orqaga qaytarish mumkinmi? Misol uchun, mavjud shaftda, oling va aytingki, siz shu paytgacha o'zgarishlarni qo'llaysiz va shu paytdan boshlab o'zgarishlarni qo'llashni to'xtatasizmi?
Agar buyruq bizning klasterimizga kelib, uni buzgan bo'lsa, unda bizda bir soatlik kechikish bilan shartli nusxa bor, bu erda biz hozir uni ishlatamiz, deb aytishimiz mumkin, lekin oxirgi o'n daqiqada unga o'zgartirishlar kiritmaymizmi?
Birinchidan, replikalarning boshqariladigan kechikishi haqida. Foydalanuvchilardan shunday so‘rov bo‘ldi va biz Github’da “Agar kimgadir bu kerak bo‘lsa, layk qo‘ying, yurak qo‘ying” degan so‘rov bilan muammo yaratdik. Hech kim yetkazib bermadi va masala yopildi. Biroq, ClickHouse-ni o'rnatish orqali allaqachon ushbu imkoniyatga ega bo'lishingiz mumkin. To'g'ri, faqat 20.3 versiyasidan boshlab.
ClickHouse doimiy ravishda fonda ma'lumotlarni birlashtirishni amalga oshiradi. Birlashtirish tugallangandan so'ng, ma'lum bir ma'lumotlar to'plami kattaroq bo'lak bilan almashtiriladi. Shu bilan birga, ilgari mavjud bo'lgan ma'lumotlar bo'laklari diskda bir muncha vaqt qolishda davom etadi.
Birinchidan, bloklanmasdan ishlashni ta'minlash uchun ulardan foydalanadigan tanlangan so'rovlar mavjud ekan, ular saqlanishda davom etadi. Tanlangan so'rovlar eski bo'laklardan osongina o'qiladi.
Ikkinchidan, vaqt chegarasi ham mavjud - eski ma'lumotlar diskda sakkiz daqiqa davomida yotadi. Ushbu sakkiz daqiqani sozlash va hatto bir kunga aylantirish mumkin. Bu diskdagi bo'sh joyni xarajat qiladi: ma'lumotlar oqimiga qarab, ma'lum bo'lishicha, oxirgi kunda ma'lumotlar nafaqat ikki barobar, balki besh baravar ko'payishi mumkin. Ammo jiddiy muammo bo'lsa, ClickHouse serverini to'xtatib, hamma narsani tartibga solishingiz mumkin.
Endi bu o'zgarishlardan qanday himoya qiladi degan savol tug'iladi. Bu erda chuqurroq ko'rib chiqishga arziydi, chunki ClickHouse-ning eski versiyalarida o'zgartirish shunday ishlaganki, u to'g'ridan-to'g'ri qismlarni o'zgartirgan. Ba'zi fayllar bilan ma'lumotlarning bir qismi bor va biz, masalan, tushirish ustunini o'zgartiring. Keyin bu ustun barcha qismlardan jismonan olib tashlanadi.
Ammo 20.3 versiyasidan boshlab o'zgartirish mexanizmi butunlay o'zgartirildi va endi ma'lumotlar qismlari har doim o'zgarmasdir. Ular umuman o'zgarmaydi - o'zgartirishlar endi birlashmalar bilan bir xil ishlaydi. Bir parchani joyida almashtirish o'rniga, biz yangisini yaratamiz. Yangi bo'limda o'zgarmagan fayllar qattiq havolalarga aylanadi va agar biz ustunni o'chirsak, u shunchaki yangi bo'lakda yo'qoladi. Eski qism sakkiz daqiqadan so'ng sukut bo'yicha o'chiriladi va bu erda siz yuqorida aytib o'tilgan sozlamalarni o'zgartirishingiz mumkin.
Xuddi shu narsa mutatsiyalar kabi o'zgarishlarga ham tegishli. Qachonki o'zgartirish o'chirish yoki yangilashni o'zgartiring, u parchani o'zgartirmaydi, balki yangisini yaratadi. Va keyin eskisini o'chiradi.
Jadval tuzilishi o'zgargan bo'lsa-chi?
Eski sxema bo'yicha qilingan zaxira nusxasini qanday tiklash mumkin? Ikkinchi savol esa oniy tasvirlar va fayl tizimi vositalari bilan bog'liq. Linux LVM da ZFS o'rniga Btrfs yaxshimi?
Agar shunday qilsangiz bo'limni biriktiring boshqa tuzilishga ega bo'limlar, keyin ClickHouse sizga bu mumkin emasligini aytadi. Bu yechim. Birinchisi, eski tuzilishga ega MergeTree tipidagi vaqtinchalik jadval yaratish, biriktirma yordamida ma'lumotlarni u erga biriktirish va o'zgartirish so'rovini qilish. Keyin siz ushbu ma'lumotlarni nusxalashingiz yoki uzatishingiz va qayta biriktirishingiz yoki so'rovdan foydalanishingiz mumkin jadvalning harakatlanish qismini o'zgartiring.
Endi ikkinchi savol - Btrfs dan foydalanish mumkinmi. Boshlash uchun, agar sizda LVM bo'lsa, unda LVM snapshotlari etarli va fayl tizimi ext4 bo'lishi mumkin, bu muhim emas. Btrts bilan hamma narsa uni ishlatish tajribangizga bog'liq. Bu etuk fayl tizimi, ammo ma'lum bir stsenariyda hamma narsa amalda qanday ishlashi haqida ba'zi shubhalar mavjud. Agar ishlab chiqarishda Btrfs bo'lmasa, men buni ishlatishni tavsiya etmayman.
Ma'lumotlarni qayta taqsimlashning hozirgi eng yaxshi amaliyotlari qanday?
Qayta taqsimlash masalasi murakkab va ko'p qirrali. Bu erda bir nechta mumkin bo'lgan javoblar mavjud. Siz bir tomondan borib, buni aytishingiz mumkin - ClickHouse o'rnatilgan qayta taqsimlash xususiyatiga ega emas. Lekin bu javob hech kimga mos kelmasligidan qo'rqaman. Shuning uchun, siz boshqa tomondan borib, ClickHouse-da ma'lumotlarni qayta ishlashning ko'p usullari borligini aytishingiz mumkin.
Agar klasterda bo'sh joy qolmasa yoki u yukni ko'tara olmasa, siz yangi serverlarni qo'shasiz. Ammo bu serverlar sukut bo'yicha bo'sh, ularda hech qanday ma'lumot yo'q, yuk yo'q. Siz ma'lumotlarni yangi, kattaroq klaster bo'ylab bir tekis taqsimlanishi uchun qayta tartiblashingiz kerak.
Buni amalga oshirishning birinchi usuli - so'rov yordamida bo'limlarning bir qismini yangi serverlarga nusxalash jadvalni olish bo'limini o'zgartirish. Misol uchun, sizda oylar bo'yicha bo'limlar bor edi va siz 2017 yilning birinchi oyini olib, uni yangi serverga ko'chirasiz, keyin uchinchi oyni boshqa yangi serverga ko'chirasiz. Va siz buni ko'proq yoki kamroq tekislashguncha qilasiz.
O'tkazish faqat yozib olish paytida o'zgarmaydigan qismlar uchun amalga oshirilishi mumkin. Yangi bo'limlar uchun yozishni o'chirib qo'yish kerak, chunki ularning uzatilishi atomik emas. Aks holda, siz ma'lumotlarning dublikatlari yoki bo'shliqlari bilan yakunlanasiz. Biroq, bu usul amaliy va juda samarali ishlaydi. Tayyor siqilgan bo'limlar tarmoq orqali uzatiladi, ya'ni ma'lumotlar siqilmaydi yoki qayta kodlanmaydi.
Ushbu usulning bitta kamchiligi bor va bu sharding sxemasiga, siz ushbu sharding sxemasiga garov berganmisiz, qanday sharding kalitiga ega ekanligingizga bog'liq. Ko'rsatkichlar bilan bog'liq misolingizda sharding kaliti yo'lning xeshidir. Taqsimlangan jadvalni tanlaganingizda, u bir vaqtning o'zida klasterdagi barcha qismlarga o'tadi va u yerdan ma'lumotlarni oladi.
Bu shuni anglatadiki, qaysi ma'lumotlar qaysi parchada tugashi siz uchun muhim emas. Asosiysi, bitta yo'l bo'ylab ma'lumotlar bitta bo'lakda tugaydi, ammo qaysi biri muhim emas. Bunday holda, tayyor bo'limlarni uzatish juda yaxshi, chunki tanlangan so'rovlar bilan siz to'liq ma'lumotlarni ham olasiz - qayta taqsimlashdan oldin yoki keyin, sxema muhim emas.
Ammo murakkabroq holatlar mavjud. Agar dastur mantig'i darajasida siz maxsus sharding sxemasiga tayansangiz, bu mijoz falon parchada joylashgan va so'rov Taqsimlangan jadvalga emas, balki to'g'ridan-to'g'ri u erga yuborilishi mumkin. Yoki siz ClickHouse-ning eng so'nggi versiyasidan foydalanyapsiz va sozlamani yoqdingiz foydalanilmagan parchalarni o'tkazib yuborishni optimallashtirish. Bunday holda, tanlash so'rovi paytida, qaerda bo'limidagi ifoda tahlil qilinadi va sharding sxemasiga ko'ra qaysi parchalardan foydalanish kerakligi hisoblab chiqiladi. Bu ma'lumotlar aynan shu sharding sxemasiga muvofiq bo'lingan bo'lsa ishlaydi. Agar siz ularni qo'lda qayta tashkil qilsangiz, yozishmalar o'zgarishi mumkin.
Shunday qilib, bu birinchi raqamli usul. Va javobingizni kutaman, usul mos keladimi yoki davom etaylik.
Vladimir Kolobaev, Avito kompaniyasining yetakchi tizim administratori: Aleksey, siz aytgan usul yukni, jumladan, o'qishni tarqatish kerak bo'lganda juda yaxshi ishlamaydi. Biz har oy bo'lgan va oldingi oyni boshqa tugunga o'tkazishimiz mumkin bo'lgan bo'limni olishimiz mumkin, ammo bu ma'lumotlar uchun so'rov kelganda, biz uni faqat yuklaymiz. Ammo biz butun klasterni yuklamoqchimiz, chunki aks holda, bir muncha vaqt davomida butun o'qish yuki ikkita parcha tomonidan qayta ishlanadi.
Aleksey Milovidov: Bu erda javob g'alati - ha, bu yomon, lekin u ishlashi mumkin. Qanday qilib men aniq tushuntiraman. Ma'lumotlaringiz orqasida keladigan yuk stsenariysini ko'rib chiqishga arziydi. Agar bu kuzatuv ma'lumotlari bo'lsa, unda so'rovlarning katta qismi yangi ma'lumotlarga qaratilgan deb aytishimiz mumkin.
Siz yangi serverlarni o'rnatdingiz, eski bo'limlarni ko'chirdingiz, lekin yangi ma'lumotlarning qanday yozilishini ham o'zgartirdingiz. Va yangi ma'lumotlar klaster bo'ylab tarqaladi. Shunday qilib, atigi besh daqiqadan so'ng, so'nggi besh daqiqalik so'rovlar klasterni bir tekis yuklaydi; bir kundan keyin XNUMX soatlik so'rovlar klasterni teng ravishda yuklaydi. Va oldingi oy uchun so'rovlar, afsuski, klaster serverlarining faqat bir qismiga o'tadi.
Ammo ko'pincha sizda 2019 yil fevral uchun maxsus so'rovlar bo'lmaydi. Katta ehtimol bilan, agar so'rovlar 2019 yilga to'g'ri keladigan bo'lsa, unda ular butun 2019 yil uchun bo'ladi - ba'zi bir kichik diapazon uchun emas, balki katta vaqt uchun. Va bunday so'rovlar klasterni teng ravishda yuklashi mumkin. Ammo umuman olganda, sizning fikringiz mutlaqo to'g'ri, bu ma'lumotlarni to'liq bir tekis taqsimlamaydigan maxsus yechim.
Savolga javob berish uchun yana bir nechta fikrlarim bor. Ulardan biri, qayta parchalanish kamroq og'riq keltirishi uchun dastlab parchalanish sxemasini qanday loyihalash haqida. Bu har doim ham mumkin emas.
Masalan, sizda monitoring ma'lumotlari mavjud. Monitoring ma'lumotlari uchta sababga ko'ra o'sib bormoqda. Birinchisi, tarixiy ma'lumotlarning to'planishi. Ikkinchisi - trafikning o'sishi. Uchinchisi esa kuzatilishi kerak bo'lgan narsalar sonining ko'payishi. Saqlanishi kerak bo'lgan yangi mikroservislar va ko'rsatkichlar mavjud.
Ehtimol, bularning ichida eng katta o'sish uchinchi sabab - monitoringdan foydalanishning ortishi bilan bog'liq. Va bu holda, yukning tabiatiga qarashga arziydi, asosiy tanlash so'rovlari nima. Asosiy tanlash soʻrovlari, ehtimol, ayrim koʻrsatkichlar toʻplamiga asoslanadi.
Masalan, ba'zi serverlarda protsessordan foydalanish. Ma'lum bo'lishicha, siz ushbu ma'lumotlarni oladigan kalitlarning ma'lum bir to'plami mavjud. Va bu ma'lumotlar uchun so'rovning o'zi juda oddiy va o'nlab millisekundlarda bajariladi. Monitoring xizmatlari va asboblar paneli uchun ishlatiladi. Umid qilamanki, men buni to'g'ri tushunaman.
Vladimir Kolobaev: Gap shundaki, biz ko'pincha tarixiy ma'lumotlarga murojaat qilamiz, chunki biz hozirgi vaziyatni real vaqtda tarixiy holat bilan taqqoslaymiz. Va biz uchun katta hajmdagi ma'lumotlarga tezkor kirish imkoniyatiga ega bo'lish juda muhim va ClickHouse bu bilan juda yaxshi ishlaydi.
Siz mutlaqo haqsiz, biz har qanday monitoring tizimi kabi o'qish so'rovlarining ko'pini oxirgi kunda boshdan kechiramiz. Shu bilan birga, tarixiy ma'lumotlarga yuk ham juda katta. Bu, asosan, har o'ttiz soniyada aylanib yuradigan va ClickHouse-ga aytadigan ogohlantirish tizimidan: “Menga so'nggi olti haftalik ma'lumotlarni bering. Endi menga ulardan qandaydir harakatlanuvchi o'rtachani yarating va keling, hozirgi qiymatni tarixiy qiymat bilan taqqoslaylik.
Aytmoqchimanki, bunday so'nggi so'rovlar uchun bizda faqat ikki kunlik ma'lumotlarni saqlaydigan yana bir kichik jadval mavjud va asosiy so'rovlar unga kiradi. Biz faqat katta tarixiy so'rovlarni katta bo'lakli jadvalga yuboramiz.
Aleksey Milovidov: Afsuski, bu sizning stsenariyingiz uchun juda kam qo'llaniladi, lekin men sizga foydalanish shart bo'lmagan, lekin do'stlarim xizmatida ishlatiladigan ikkita yomon va murakkab parchalanish sxemalarining tavsifini aytib beraman.
Yandex.Metrica hodisalari bilan asosiy klaster mavjud. Voqealar sahifani ko'rish, bosish va konvertatsiya qilishdir. Ko'pgina so'rovlar ma'lum bir veb-saytga tushadi. Siz Yandex.Metrica xizmatini ochasiz, veb-saytingiz bor - avito.ru, hisobotga o'ting va veb-saytingizga so'rov yuboriladi.
Ammo boshqa so'rovlar ham bor - analitik va global - ular ichki tahlilchilar tomonidan amalga oshiriladi. Har holda, shuni ta'kidlaymanki, ichki tahlilchilar faqat Yandex xizmatlari uchun so'rovlar qilishadi. Shunga qaramay, hatto Yandex xizmatlari ham barcha ma'lumotlarning katta qismini egallaydi. Bu maxsus hisoblagichlar uchun emas, balki kengroq filtrlash uchun so'rovlar.
Hammasi bitta hisoblagich va global so'rovlar uchun samarali ishlashi uchun ma'lumotlarni qanday tashkil qilish kerak? Yana bir qiyinchilik shundaki, Metrics klasteri uchun ClickHouse-da so'rovlar soni soniyada bir necha mingni tashkil qiladi. Shu bilan birga, bitta ClickHouse serveri ahamiyatsiz so'rovlarni bajara olmaydi, masalan, soniyada bir necha ming.
Klaster hajmi olti yuzga yaqin serverdir. Agar siz ushbu klaster ustiga oddiygina taqsimlangan jadvalni tortsangiz va u erga bir necha ming so'rov yuborsangiz, bu ularni bitta serverga yuborishdan ham yomonroq bo'ladi. Boshqa tomondan, ma'lumotlar bir tekis taqsimlanadi va biz borib, barcha serverlardan so'raymiz, degan variant darhol bekor qilinadi.
Diametral ravishda qarama-qarshi bo'lgan variant mavjud. Tasavvur qiling-a, biz ma'lumotlarni saytlar bo'ylab taqsimlaymiz va bitta sayt uchun so'rov bitta parchaga tushadi. Endi klaster sekundiga o'n ming so'rovni bajara oladi, lekin bitta parchada har qanday so'rov juda sekin ishlaydi. U endi o'tkazish qobiliyati bo'yicha miqyosda bo'lmaydi. Ayniqsa, bu avito.ru sayti bo'lsa. Avito RuNetda eng ko'p tashrif buyuriladigan saytlardan biri desam, sirni oshkor qilmayman. Va uni bitta bo'lakda qayta ishlash jinnilik bo'lar edi.
Shuning uchun, sharding sxemasi yanada ayyor tarzda ishlab chiqilgan. Butun klaster bir qancha klasterlarga bo'linadi, biz ularni qatlamlar deb ataymiz. Har bir klaster o'ndan bir necha o'nlab parchalarni o'z ichiga oladi. Hammasi bo'lib o'ttiz to'qqizta shunday klaster mavjud.
Bularning barchasi qanday miqyosda? Klasterlar soni o'zgarmaydi - bir necha yil oldin o'ttiz to'qqizta bo'lganidek, shundayligicha qolmoqda. Ammo ularning har birida biz ma'lumotlarni to'plashda asta-sekin parchalar sonini oshiramiz. Va umuman sharding sxemasi shunday: bu klasterlar veb-saytlarga bo'lingan va qaysi veb-sayt qaysi klasterda ekanligini tushunish uchun MySQL-da alohida metabaza ishlatiladi. Bitta sayt - bitta klasterda. Va uning ichida sharding tashrif buyuruvchi identifikatorlariga ko'ra sodir bo'ladi.
Yozishda biz ularni tashrif buyuruvchi identifikatorining qolgan qismiga ajratamiz. Ammo yangi parcha qo'shganda, parchalanish sxemasi o'zgaradi; biz bo'linishda davom etamiz, ammo bo'linishning qolgan qismi bilan boshqa raqamga. Bu shuni anglatadiki, bitta tashrifchi allaqachon bir nechta serverlarda joylashgan va siz bunga tayanolmaysiz. Bu faqat ma'lumotlarning yaxshiroq siqilganligini ta'minlash uchun amalga oshiriladi. Va so'rovlarni amalga oshirayotganda, biz klasterni ko'rib chiqadigan va o'nlab serverlarga kiradigan Taqsimlangan jadvalga o'tamiz. Bu shunday ahmoqona sxema.
Ammo bu sxemadan voz kechganimizni aytmasam, mening hikoyam to'liq bo'lmaydi. Yangi sxemada biz hamma narsani o'zgartirdik va barcha ma'lumotlarni clickhouse-copier yordamida nusxalashtirdik.
Yangi sxemada barcha saytlar ikkita toifaga bo'lingan - katta va kichik. Eshik qanday tanlanganini bilmayman, lekin natijada katta saytlar bitta klasterda qayd etilgan, bu erda har birida uchta replikadan iborat 120 ta shard, ya'ni 360 ta server mavjud. Sharding sxemasi shundayki, har qanday so'rov bir vaqtning o'zida barcha shardlarga o'tadi. Agar siz hozir Yandex.Metrica-da avito.ru uchun har qanday hisobot sahifasini ochsangiz, so'rov 120 ta serverga o'tadi. RuNet-da bir nechta yirik saytlar mavjud. Va so'rovlar sekundiga ming emas, balki yuzdan ham kam. Bularning barchasi Taqsimlangan jadval tomonidan jimgina chaynalgan, ularning har biri 120 ta server bilan ishlaydi.
Ikkinchi klaster esa kichik saytlar uchun. Mana sayt identifikatoriga asoslangan sharding sxemasi va har bir so'rov aynan bitta parchaga o'tadi.
ClickHouse-da clickhouse-nusxa ko'chirish yordam dasturi mavjud. Bizga u haqida gapirib bera olasizmi?
Men darhol aytamanki, bu yechim yanada og'irroq va biroz unumdor emas. Afzalligi shundaki, u siz ko'rsatgan naqshga muvofiq ma'lumotlarni to'liq surtadi. Ammo yordamchi dasturning kamchiliklari shundaki, u umuman qayta ishlamaydi. U ma'lumotlarni bir klaster sxemasidan boshqa klaster sxemasiga ko'chiradi.
Bu shuni anglatadiki, u ishlashi uchun sizda ikkita klaster bo'lishi kerak. Ular bir xil serverlarda joylashgan bo'lishi mumkin, ammo shunga qaramay, ma'lumotlar bosqichma-bosqich ko'chirilmaydi, balki nusxalanadi.
Misol uchun, to'rtta server bor edi, hozir sakkizta. Siz barcha serverlarda yangi Taqsimlangan jadvalni, yangi mahalliy jadvallarni yaratasiz va u erdan o'qishi kerak bo'lgan ish sxemasini ko'rsatib, yangi mahalliy jadvallarni ishga tushirasiz, yangi sharding sxemasini qabul qilasiz va ma'lumotlarni u erga o'tkazasiz. Va eski serverlarda sizga hozirgidan bir yarim baravar ko'proq joy kerak bo'ladi, chunki eski ma'lumotlar ularda qolishi kerak va bir xil eski ma'lumotlarning yarmi ularning ustiga tushadi. Agar siz ma'lumotlarni qayta taqsimlash kerakligini oldindan o'ylagan bo'lsangiz va bo'sh joy mavjud bo'lsa, unda bu usul mos keladi.
Clickhouse-nusxa mashinasi ichida qanday ishlaydi? U barcha ishni bitta jadvalning bir qismini bitta parchada qayta ishlash uchun vazifalar to'plamiga ajratadi. Bu vazifalarning barchasi parallel ravishda bajarilishi mumkin va nusxa ko'chirish mashinasi turli xil mashinalarda bir nechta hollarda ishga tushirilishi mumkin, ammo uning bitta bo'lim uchun qiladigan ishi qo'shishni tanlashdan boshqa narsa emas. Ma'lumotlar o'qiladi, ochiladi, qayta bo'linadi, keyin yana siqiladi, biror joyga yoziladi va qayta tartiblanadi. Bu qattiqroq qaror.
Sizda reharding deb nomlangan uchuvchi narsa bor edi. Unga-chi?
2017-yilda sizda qayta ishlash deb nomlangan uchuvchi narsa bor edi. ClickHouse-da hatto variant ham mavjud. Men tushunganimdek, u uchmadi. Nima uchun bu sodir bo'lganini ayta olasizmi? Bu juda dolzarb bo'lib tuyuladi.
Muammo shundaki, agar ma'lumotni joyida qayta taqsimlash zarur bo'lsa, buni atomik tarzda amalga oshirish uchun juda murakkab sinxronizatsiya talab qilinadi. Ushbu sinxronizatsiya qanday ishlashini ko'rib chiqa boshlaganimizda, asosiy muammolar mavjudligi aniq bo'ldi. Va bu fundamental muammolar nafaqat nazariy, balki darhol o'zlarini amalda juda oddiy tushuntirilishi mumkin bo'lgan narsa shaklida ko'rsata boshladi - hech narsa ishlamaydi.
Sekin disklarga o'tkazishdan oldin barcha ma'lumotlarni birlashtirish mumkinmi?
Birlashtirish kontekstida sekin disk variantiga o'tish bilan TTL haqida savol. Barcha qismlarni sekin disklarga o'tkazishdan oldin ularni birlashtirish uchun cron orqali boshqa yo'l bormi?
Savolga javob shundaki, ularni o'tkazishdan oldin barcha qismlarni avtomatik ravishda bittaga yopishtirish mumkin - yo'q. Menimcha, bu kerak emas. Siz barcha qismlarni bittaga birlashtirishingiz shart emas, lekin ular avtomatik ravishda sekin disklarga o'tkazilishiga ishonishingiz kerak.
Transfer qoidalari uchun ikkita mezonimiz bor. Birinchisi to'ldirilganidek. Agar joriy saqlash darajasida bo'sh joyning ma'lum foizidan kam bo'lsa, biz bitta bo'lakni tanlaymiz va uni sekinroq saqlashga o'tkazamiz. To'g'rirog'i, sekinroq emas, balki keyingisi - siz sozlaganingizdek.
Ikkinchi mezon - bu o'lcham. Bu katta qismlarni ko'chirish haqida. Tez diskdagi bo'sh joyga qarab chegarani sozlashingiz mumkin va ma'lumotlar avtomatik ravishda uzatiladi.
Muvofiqlikni oldindan tekshirishning imkoni bo'lmasa, ClickHouse-ning yangi versiyalariga qanday o'tish mumkin?
Ushbu mavzu muntazam ravishda muhokama qilinadi turli versiyalarni hisobga olgan holda va hali ham. 19.11-dan 19.16-ga va, masalan, 19.16-dan 20.3-ga yangilash qanchalik xavfsiz. Sinov muhitida muvofiqlikni oldindan tekshirmasdan yangi versiyalarga o'tishning eng yaxshi usuli qanday?
Bu erda bir nechta "oltin" qoidalar mavjud. Birinchi - . Bu katta, lekin orqaga mos kelmaydigan o'zgarishlar haqida alohida paragraflar mavjud. Bu nuqtalarga qizil bayroq sifatida qaramang. Bular odatda kichik nomuvofiqliklar bo‘lib, siz foydalanmayotgan ba’zi bir chekka funksiyalarni o‘z ichiga oladi.
Ikkinchidan, agar sandboxda muvofiqlikni tekshirishning hech qanday usuli bo'lmasa va siz darhol ishlab chiqarishda yangilashni xohlasangiz, buni qilish kerak emasligi tavsiya etiladi. Avval qum qutisini yarating va sinab ko'ring. Agar sinov muhiti bo'lmasa, unda sizda juda katta kompaniya yo'q, ya'ni siz ma'lumotlarning bir qismini noutbukingizga nusxalashingiz va unda hamma narsa to'g'ri ishlashiga ishonch hosil qilishingiz mumkin. Siz hatto kompyuteringizda mahalliy ravishda bir nechta nusxalarni ko'tarishingiz mumkin. Yoki siz yaqin atrofdagi biron bir joydan yangi versiyani olishingiz va ma'lumotlarning bir qismini u erga yuklashingiz mumkin - ya'ni improvizatsiya qilingan sinov muhitini yaratishingiz mumkin.
Yana bir qoida - ishlab chiqarishdagi xatolar va keyingi tezkor tuzatishlar tufayli versiya chiqarilgandan keyin bir hafta davomida yangilanmaslik. Adashib qolmaslik uchun ClickHouse versiyalarining raqamlanishini aniqlaylik.
20.3.4 versiyasi mavjud. 20 raqami ishlab chiqarilgan yilni ko'rsatadi - 2020. Ichkaridagi narsa nuqtai nazaridan, bu muhim emas, shuning uchun biz bunga e'tibor bermaymiz. Keyingi - 20.3. Biz ikkinchi raqamni ko'paytiramiz - bu holda 3 - har safar biz ba'zi yangi funksiyalarga ega relizni chiqarganimizda. Agar biz ClickHouse-ga biron bir xususiyat qo'shmoqchi bo'lsak, bu raqamni oshirishimiz kerak. Ya'ni, ClickHouse 20.4 versiyasida yanada yaxshi ishlaydi. Uchinchi raqam 20.3.4. Bu erda 4 ta yamoq relizlar soni bo'lib, ularda biz yangi funksiyalarni qo'shmaganmiz, lekin ba'zi xatolarni tuzatdik. Va 4, biz buni to'rt marta qildik degan ma'noni anglatadi.
Bu dahshatli narsa deb o'ylamang. Odatda foydalanuvchi so'nggi versiyani o'rnatishi mumkin va u yiliga ish vaqti bilan hech qanday muammosiz ishlaydi. Ammo tasavvur qiling-a, bizning xitoylik o'rtoqlarimiz tomonidan qo'shilgan bitmaplarni qayta ishlash uchun ba'zi bir funksiyada noto'g'ri argumentlarni uzatishda server ishdan chiqadi. Biz buni tuzatishga mas'ulmiz. Biz yangi yamoq versiyasini chiqaramiz va ClickHouse yanada barqaror bo'ladi.
Agar sizda ClickHouse ishlab chiqarishda ishlayotgan bo'lsa va ClickHouse-ning yangi versiyasi qo'shimcha funktsiyalar bilan chiqsa - masalan, 20.4.1 eng birinchisi bo'lsa, uni birinchi kuniyoq ishlab chiqarishga qo'yishga shoshilmang. Nega u hatto kerak? Agar siz hali ClickHouse-dan foydalanmasangiz, uni o'rnatishingiz mumkin va ehtimol hamma narsa yaxshi bo'ladi. Ammo agar ClickHouse allaqachon barqaror ishlayotgan bo'lsa, qanday muammolarni hal qilayotganimizni bilish uchun yamoqlar va yangilanishlarni kuzatib boring.
Kirill Shvakov: Sinov muhitlari haqida bir oz qo'shmoqchiman. Har bir inson sinov muhitidan juda qo'rqadi va negadir ular juda katta ClickHouse klasteriga ega bo'lsangiz, sinov muhiti kam yoki kamida o'n baravar kichik bo'lishi kerak deb hisoblashadi. Bu umuman bunday emas.
Men o'zimning misolimdan ayta olaman. Mening loyiham bor va ClickHouse bor. Bizning sinov muhitimiz aynan u uchun - bu Hetznerdagi yigirma evroga mo'ljallangan kichik virtual mashina, u erda mutlaqo hamma narsa joylashtirilgan. Buni amalga oshirish uchun bizda Ansible-da to'liq avtomatlashtirish mavjud va shuning uchun, printsipial jihatdan, qaerga borish - apparat serverlariga yoki shunchaki virtual mashinalarda joylashtirishning farqi yo'q.
Nima qilish mumkin? ClickHouse hujjatlarida kichik klasterni o'z uyingizda qanday joylashtirish haqida misol keltirsangiz yaxshi bo'lardi - Docker-da, LXC-da, ehtimol Ansible o'yin kitobini yaratishingiz mumkin, chunki turli odamlar turli xil joylashtirishga ega. Bu ko'p narsani soddalashtiradi. Besh daqiqada klasterni olib, joylashtirganingizda, biror narsani aniqlashga harakat qilish osonroq bo'ladi. Bu ancha qulayroq, chunki siz sinab ko'rmagan ishlab chiqarish versiyasiga o'tish hech qaerga yo'ldir. Ba'zida u ishlaydi, ba'zida esa yo'q. Va shuning uchun muvaffaqiyatga umid qilish yomon.
Maksim Kotyakov, Avitoning katta muhandisi: Men yirik kompaniyalar duch keladigan bir qator muammolardan sinov muhiti haqida bir oz qo'shaman. Bizda to'liq huquqli ClickHouse qabul qilish klasteri mavjud; ma'lumotlar sxemalari va sozlamalari nuqtai nazaridan, bu ishlab chiqarishdagi narsalarning aniq nusxasi. Ushbu klaster minimal resurslarga ega bo'lgan juda qisqa konteynerlarda joylashtirilgan. Biz ishlab chiqarish ma'lumotlarining ma'lum bir foizini u erda yozamiz, xayriyatki, Kafkadagi oqimni takrorlash mumkin. U erda hamma narsa sinxronlashtiriladi va miqyosda - sig'im va oqim jihatidan ham, nazariy jihatdan, boshqa barcha narsalar teng bo'lsa, u o'lchovlar bo'yicha ishlab chiqarish kabi harakat qilishi kerak. Potentsial portlovchi bo'lishi mumkin bo'lgan hamma narsa avval ushbu stendga o'raladi va tayyor bo'lgunga qadar u erda bir necha kun qoldiriladi. Lekin tabiiyki, bu yechim qimmat, qiyin va nolga teng bo'lmagan qo'llab-quvvatlash xarajatlariga ega.
Aleksey Milovidov: Men sizga Yandex.Metrica-dan do'stlarimizning sinov muhiti qanday ekanligini aytib beraman. Bir klasterda 600 ta, boshqasida 360 ta, uchinchi va bir nechta klasterlar mavjud edi. Ulardan biri uchun sinov muhiti har birida ikkita nusxaga ega bo'lgan ikkita parchadir. Nega ikkita bo'lak? Shunday qilib, siz yolg'iz emassiz. Va nusxalar ham bo'lishi kerak. Siz ko'tara oladigan ma'lum bir minimal miqdor.
Ushbu test muhiti so'rovlaringiz ishlayotganligini va biror muhim narsa buzilganligini tekshirish imkonini beradi. Ammo ko'pincha muammolar butunlay boshqacha tabiatda paydo bo'ladi, hamma narsa ishlayotganda, lekin yukda ba'zi kichik o'zgarishlar mavjud.
Sizga bir misol keltiraman. Biz ClickHouse-ning yangi versiyasini o'rnatishga qaror qildik. U sinov muhitiga joylashtirildi, Yandex.Metrica-ning o'zida avtomatlashtirilgan testlar yakunlandi, ular eski va yangi versiyadagi ma'lumotlarni taqqoslaydi, butun quvur liniyasini boshqaradi. Va, albatta, bizning CI ning yashil testlari. Aks holda, biz bu versiyani taklif qilmagan bo'lardik.
Hammasi ajoyib. Biz ishlab chiqarishga o'tishni boshlaymiz. Men grafiklardagi yuk bir necha bor ortganligi haqida xabar olaman. Biz versiyani orqaga qaytaramiz. Men grafikaga qarayman va ko'raman: ishlab chiqarish paytida yuk aslida bir necha bor oshdi va ular chiqarilganda yana kamaydi. Keyin biz versiyani orqaga qaytarishni boshladik. Va yuk xuddi shu tarzda ortib, xuddi shu tarzda orqaga tushdi. Xulosa shunday: tartib tufayli yuk ortdi, ajablanarli narsa yo'q.
Keyin hamkasblarni yangi versiyani o'rnatishga ishontirish qiyin edi. Men aytaman: “Hech narsa yo'q, chiqib keting. Barmoqlaringizni kesib o'ting, hamma narsa ishlaydi. Endi grafiklardagi yuk ortdi, lekin hamma narsa yaxshi. Shu yerda turing." Umuman olganda, biz buni qildik va tamom - versiya ishlab chiqarish uchun chiqarildi. Ammo deyarli har bir tartib bilan shunga o'xshash muammolar paydo bo'ladi.
O'ldirish so'rovi so'rovlarni o'ldirishi kerak, lekin u emas. Nega?
Bir foydalanuvchi, qandaydir tahlilchi, menga kelib, mening ClickHouse klasterimni qo'yish uchun so'rov yaratdi. So'rov qaysi replika yoki parchaga o'tganiga qarab, ba'zi tugun yoki butun klaster. Ko'ryapmanki, ushbu serverdagi barcha CPU resurslari javonda, hammasi qizil. Shu bilan birga, ClickHouse o'zi so'rovlarga javob beradi. Va men yozaman: "Iltimos, menga ko'rsating, ro'yxatni qayta ishlang, bu jinnilik qanday so'rovni keltirib chiqardi."
Men bu so'rovni topaman va unga kill deb yozaman. Va men hech narsa sodir bo'lmaganini ko'raman. Mening serverim javonda, ClickHouse keyin menga ba'zi buyruqlar beradi, server tirik ekanligini ko'rsatadi va hamma narsa ajoyib. Lekin barcha foydalanuvchi so'rovlarida degradatsiya bor, degradatsiya ClickHouse-dagi yozuvlar bilan boshlanadi va mening o'ldirish so'rovim ishlamaydi. Nega? Men kill so'rovi so'rovlarni o'ldirishi kerak deb o'yladim, lekin unday emas.
Endi juda g'alati javob bo'ladi. Gap shundaki, o'ldirish so'rovi so'rovlarni o'chirmaydi.
O'ldirish so'rovi "Men bu so'rovni o'ldirishni xohlayman" deb nomlangan kichik katakchani tekshiradi. Va har bir blokni qayta ishlashda so'rovning o'zi ushbu bayroqqa qaraydi. Agar u o'rnatilgan bo'lsa, so'rov ishlashni to'xtatadi. Ma'lum bo'lishicha, so'rovni hech kim o'ldirmaydi, uning o'zi hamma narsani tekshirib, to'xtatishi kerak. Va bu so'rov ma'lumotlar bloklarini qayta ishlash holatida bo'lgan barcha holatlarda ishlashi kerak. U keyingi ma'lumotlar blokini qayta ishlaydi, bayroqni tekshiradi va to'xtaydi.
Bu so'rov ba'zi operatsiyalarda bloklangan hollarda ishlamaydi. To'g'ri, bu sizning holatingiz emas, chunki sizning fikringizcha, u bir tonna server resurslaridan foydalanadi. Bu tashqi saralashda va boshqa tafsilotlarda ishlamasligi mumkin. Ammo umuman olganda, bu sodir bo'lmasligi kerak, bu xato. Va men tavsiya qiladigan yagona narsa - ClickHouse-ni yangilash.
O'qish yuki ostida javob vaqtini qanday hisoblash mumkin?
Element agregatlarini - turli xil hisoblagichlarni saqlaydigan jadval mavjud. Chiziqlar soni taxminan yuz million. Agar siz 1K element uchun 1K RPS quysangiz, bashorat qilinadigan javob vaqtiga ishonish mumkinmi?
Kontekstga qarab, biz o'qish yuki haqida gapiramiz, chunki yozishda hech qanday muammo yo'q - hatto ming, hatto yuz ming va ba'zan bir necha million qatorlarni kiritish mumkin.
O'qish so'rovlari juda boshqacha. 1-tanlovda ClickHouse soniyada o'n minglab so'rovlarni bajarishi mumkin, shuning uchun hatto bitta kalit so'rovlari allaqachon ba'zi resurslarni talab qiladi. Va bunday nuqta so'rovlari ba'zi kalit-qiymatli ma'lumotlar bazalariga qaraganda qiyinroq bo'ladi, chunki har bir o'qish uchun ma'lumotlar blokini indeks bo'yicha o'qish kerak. Bizning indeksimiz har bir yozuvga emas, balki har bir diapazonga murojaat qiladi. Ya'ni, siz butun diapazonni o'qishingiz kerak bo'ladi - bu sukut bo'yicha 8192 satr. Va siz siqilgan ma'lumotlar blokini 64 KB dan 1 MB gacha ochishingiz kerak bo'ladi. Odatda, bunday maqsadli so'rovlarni bajarish uchun bir necha millisekund vaqt ketadi. Ammo bu eng oddiy variant.
Keling, oddiy arifmetikani sinab ko'raylik. Agar siz bir necha millisekundni mingga ko'paytirsangiz, siz bir necha soniya olasiz. Go'yo sekundiga mingta so'rovni bajarib bo'lmaydi, lekin aslida bu mumkin, chunki bizda bir nechta protsessor yadrolari mavjud. Shunday qilib, printsipial jihatdan, ClickHouse ba'zan 1000 RPSni ushlab turishi mumkin, ammo qisqa so'rovlar uchun, ayniqsa maqsadli.
Agar siz ClickHouse klasterini oddiy so'rovlar soni bo'yicha o'lchashingiz kerak bo'lsa, men eng oddiy narsani tavsiya qilaman - replikalar sonini ko'paytiring va so'rovlarni tasodifiy nusxaga yuboring. Agar bitta replika sekundiga besh yuzta so'rovni o'z ichiga olsa, bu mutlaqo real bo'lsa, uchta replika bir yarim ming so'rovni bajaradi.
Ba'zan, albatta, siz ClickHouse-ni maksimal nuqta o'qishlari uchun sozlashingiz mumkin. Buning uchun nima kerak? Birinchisi, indeksning granularligini kamaytirishdir. Bunday holda, uni bittaga kamaytirmaslik kerak, lekin indeksdagi yozuvlar soni har bir server uchun bir necha million yoki o'n millionlab bo'ladi. Agar jadvalda yuz million satr bo'lsa, unda granularlik 64 ga o'rnatilishi mumkin.
Siqilgan blokning hajmini kamaytirishingiz mumkin. Buning uchun sozlamalar mavjud min kompressor blokining o'lchami, maksimal kompressor blokining o'lchami. Ularni qisqartirish, ma'lumotlar bilan to'ldirish mumkin, keyin esa maqsadli so'rovlar tezroq bo'ladi. Shunga qaramay, ClickHouse kalit-qiymat ma'lumotlar bazasi emas. Ko'p sonli kichik so'rovlar yuk antipattern hisoblanadi.
Kirill Shvakov: Agar u erda oddiy hisoblar bo'lsa, men maslahat beraman. ClickHouse qandaydir hisoblagichni saqlaganida, bu juda standart holat. Mening foydalanuvchim bor, u falon davlatdan va qaysidir uchinchi sohadan, men asta-sekin nimanidir oshirishim kerak. MySQL-ni oling, noyob kalit yarating - MySQLda u dublikat kalit, PostgreSQLda esa ziddiyat - va ortiqcha belgisini qo'shing. Bu ancha yaxshi ishlaydi.
Agar sizda ko'p ma'lumotlar bo'lmasa, ClickHouse-dan foydalanishning ma'nosi yo'q. Muntazam ma'lumotlar bazalari mavjud va ular buni yaxshi bajaradilar.
Ko'proq ma'lumotlar keshda bo'lishi uchun ClickHouse-da nimani o'zgartirishim mumkin?
Vaziyatni tasavvur qilaylik - serverlar 256 GB operativ xotiraga ega, kundalik rejimda ClickHouse taxminan 60-80 GB, eng yuqori cho'qqisida - 130 gacha. Nimani yoqish va sozlash mumkin, shunda ko'proq ma'lumotlar keshda va shunga mos ravishda, diskka kamroq sayohatlar bormi?
Odatda, operatsion tizimning sahifa keshi bu ishni yaxshi bajaradi. Agar siz shunchaki yuqori qismini ochsangiz, u erda keshlangan yoki bo'sh joyga qarang - u qancha keshlanganligini ham ko'rsatadi - keyin barcha bo'sh xotira kesh uchun ishlatilishini sezasiz. Va bu ma'lumotni o'qiyotganda, u diskdan emas, balki operativ xotiradan o'qiladi. Shu bilan birga, keshdan samarali foydalanilganligini aytishim mumkin, chunki u keshlangan siqilgan ma'lumotlardir.
Biroq, agar siz oddiy so'rovlarni yanada tezlashtirmoqchi bo'lsangiz, ClickHouse ichidagi siqilgan ma'lumotlarda keshni yoqishingiz mumkin. U deyiladi siqilmagan kesh. config.xml konfiguratsiya faylida siqilmagan kesh hajmini kerakli qiymatga o'rnating - men bepul RAMning yarmidan ko'pini tavsiya etmayman, chunki qolgan qismi sahifa keshi ostida qoladi.
Bundan tashqari, ikkita so'rov darajasi sozlamalari mavjud. Birinchi sozlash - siqilmagan keshdan foydalaning - undan foydalanishni o'z ichiga oladi. Uni barcha ma'lumotlarni o'qiy oladigan va keshni tozalashi mumkin bo'lgan og'ir so'rovlardan tashqari barcha so'rovlar uchun yoqish tavsiya etiladi. Va ikkinchi sozlama keshdan foydalanish uchun maksimal qatorlar soniga o'xshaydi. U avtomatik ravishda katta so'rovlarni cheklaydi, shunda ular keshni chetlab o'tadi.
RAMda saqlash uchun storage_configuration ni qanday sozlashim mumkin?
Yangi ClickHouse hujjatlarida men tegishli bo'limni o'qib chiqdim . Tavsifda tezkor SSD bilan misol mavjud.
Qizig'i shundaki, xuddi shu narsani hajmli issiq xotira bilan qanday sozlash mumkin. Va yana bir savol. Tanlash ushbu ma'lumotlar tashkiloti bilan qanday ishlaydi, u butun to'plamni yoki faqat diskdagini o'qiy oladimi va bu ma'lumotlar xotirada siqilganmi? Va prewhere bo'limi bunday ma'lumotlar tashkiloti bilan qanday ishlaydi?
Ushbu sozlama ma'lumotlar bo'laklarini saqlashga ta'sir qiladi va ularning formati hech qanday tarzda o'zgarmaydi.
Keling, batafsil ko'rib chiqaylik.
RAMda ma'lumotlarni saqlashni sozlashingiz mumkin. Disk uchun sozlangan barcha narsa uning yo'li. Siz fayl tizimidagi ba'zi yo'lga o'rnatilgan tmpfs bo'limini yaratasiz. Siz ushbu yo'lni eng issiq bo'lim uchun ma'lumotlarni saqlash yo'li sifatida belgilaysiz, ma'lumotlar bo'laklari kela boshlaydi va u erda yoziladi, hamma narsa yaxshi.
Ammo ishonchliligi pastligi sababli buni qilishni tavsiya etmayman, garchi turli ma'lumotlar markazlarida kamida uchta nusxangiz bo'lsa, bu mumkin. Agar biror narsa sodir bo'lsa, ma'lumotlar qayta tiklanadi. Tasavvur qilaylik, server to'satdan o'chirildi va qayta yoqildi. Bo'lim yana o'rnatildi, lekin u erda hech narsa yo'q edi. ClickHouse serveri ishga tushganda, u bu qismlarga ega emasligini ko'radi, ammo ZooKeeper metama'lumotlariga ko'ra, ular o'sha erda bo'lishi kerak. U qaysi nusxalar borligini ko'rib chiqadi, ularni so'raydi va yuklab oladi. Shu tarzda ma'lumotlar qayta tiklanadi.
Shu ma'noda, operativ xotirada ma'lumotlarni saqlash uni diskda saqlashdan tubdan farq qilmaydi, chunki ma'lumotlar diskka yozilsa, u ham avval sahifa keshida tugaydi va keyinchalik jismoniy yoziladi. Bu fayl tizimini o'rnatish variantiga bog'liq. Ammo har qanday holatda, ClickHouse qo'yish paytida fsynclanmasligini aytaman.
Bunday holda, operativ xotiradagi ma'lumotlar diskdagi kabi bir xil formatda saqlanadi. Tanlash so'rovi xuddi shu tarzda o'qilishi kerak bo'lgan qismlarni tanlaydi, bo'laklarda kerakli ma'lumotlar diapazonlarini tanlaydi va ularni o'qiydi. Va prewhere, ma'lumotlar RAMda yoki diskda bo'lishidan qat'i nazar, xuddi shunday ishlaydi.
Past Kardinallik qancha noyob qiymatlar soniga qadar samarali?
Past Kardinallik aqlli tarzda ishlab chiqilgan. U ma'lumotlar lug'atlarini tuzadi, lekin ular mahalliydir. Birinchidan, har bir bo'lak uchun turli xil lug'atlar mavjud, ikkinchidan, hatto bir parcha ichida ham ular har bir diapazon uchun har xil bo'lishi mumkin. Noyob qiymatlar soni chegaraviy raqamga yetganda - bir million, menimcha - lug'at shunchaki to'xtatiladi va yangisi yaratiladi.
Javob umuman: har bir mahalliy diapazon uchun - aytaylik, har bir kun uchun - bir joyda milliongacha noyob qiymatlar Past Kardinallik samarali. Keyinchalik, faqat bitta emas, balki ko'plab turli xil lug'atlar qo'llaniladigan zaxira bo'ladi. U odatdagi satr ustuni bilan bir xil ishlaydi, ehtimol unchalik samarali emas, lekin unumdorlikning jiddiy pasayishi bo'lmaydi.
Besh milliard qatorli jadvalni toʻliq matnli qidirishning eng yaxshi amaliyotlari qanday?
Turli xil javoblar mavjud. Birinchisi, ClickHouse to'liq matnli qidiruv tizimi emasligini aytishdir. Buning uchun maxsus tizimlar mavjud, masalan, и . Biroq, odamlar Elasticsearch-dan ClickHouse-ga o'tishayotganini aytishayotganini tobora ko'proq ko'raman.
Nima uchun bu sodir bo'ladi? Ular buni Elasticsearch indekslarni qurishdan boshlab, ba'zi hajmlarda yukni engishni to'xtatganligi bilan izohlashadi. Indekslar juda og'ir bo'lib qoladi va agar siz shunchaki ma'lumotlarni ClickHouse-ga o'tkazsangiz, ular hajm jihatidan bir necha barobar samaraliroq saqlanadi. Shu bilan birga, qidiruv so'rovlari ko'pincha shunday emas ediki, morfologiyani hisobga olgan holda ma'lumotlarning butun hajmida ba'zi bir iboralarni topish kerak edi, lekin butunlay boshqacha. Misol uchun, so'nggi bir necha soat ichida jurnallarda baytlarning bir nechta ketma-ketligini toping.
Bunday holda, siz ClickHouse-da indeks yaratasiz, uning birinchi maydoni sana va vaqt bo'ladi. Va eng katta ma'lumotlarni kesish sana oralig'iga asoslanadi. Tanlangan sana oralig'ida, qoida tariqasida, "like" dan foydalanib, hatto qo'pol kuch usulidan foydalangan holda ham to'liq matnli qidiruvni amalga oshirish mumkin. ClickHouse-dagi o'xshash operator siz topishingiz mumkin bo'lgan eng samarali o'xshash operatordir. Agar yaxshiroq narsani topsangiz, menga ayting.
Lekin shunga qaramay, to'liq skanerlash kabi. Va to'liq skanerlash nafaqat protsessorda, balki diskda ham sekin bo'lishi mumkin. Agar to'satdan kuniga bir terabayt ma'lumotga ega bo'lsangiz va siz kun davomida so'zni qidirsangiz, u holda siz terabaytni skanerlashingiz kerak bo'ladi. Va bu, ehtimol, oddiy qattiq disklarda bo'ladi va oxirida ular SSH orqali ushbu serverga kira olmaslik uchun yuklanadi.
Bunday holda, men yana bir kichik hiylani taklif qilishga tayyorman. Bu eksperimental - ishlashi mumkin, bo'lmasligi mumkin. ClickHouse trigram Bloom filtrlari ko'rinishidagi to'liq matnli indekslarga ega. Arenadatadagi hamkasblarimiz allaqachon ushbu indekslarni sinab ko'rishgan va ular ko'pincha mo'ljallangandek ishlaydi.
Ulardan to'g'ri foydalanish uchun siz ularning qanday ishlashini yaxshi tushunishingiz kerak: Bloom trigramma filtri nima va uning hajmini qanday tanlash kerak. Aytishim mumkinki, ular ba'zi noyob iboralar, ma'lumotlarda kam uchraydigan pastki qatorlar bo'yicha so'rovlar uchun yordam beradi. Bunday holda, pastki diapazonlar indekslar bo'yicha tanlanadi va kamroq ma'lumotlar o'qiladi.
Yaqinda ClickHouse toʻliq matnli qidiruv uchun yanada rivojlangan funksiyalarni qoʻshdi. Bu, birinchidan, bir vaqtning o'zida bir nechta kichik satrlarni qidirish, jumladan, katta-kichik harflarga sezgir, katta-kichik harflarga sezgir bo'lmagan, UTF-8 yoki faqat ASCII uchun qo'llab-quvvatlanadigan variantlar. Sizga kerak bo'lgan eng samaralisini tanlang.
Bir o'tishda bir nechta oddiy iboralarni qidirish ham paydo bo'ldi. X ni bitta pastki qator kabi yoki X ni boshqa pastki qator kabi yozishingiz shart emas. Siz darhol yozasiz va hamma narsa iloji boricha samarali amalga oshiriladi.
Uchinchidan, endi regexps uchun taxminiy qidiruv va pastki satrlarni taxminiy qidirish mavjud. Agar kimdir so'zni noto'g'ri yozgan bo'lsa, u maksimal moslik uchun qidiriladi.
Ko'p sonli foydalanuvchilar uchun ClickHouse-ga kirishni tashkil qilishning eng yaxshi usuli qanday?
Ko'p sonli iste'molchilar va tahlilchilar uchun kirishni qanday tashkil qilish kerakligini ayting. Navbatni qanday shakllantirish, bir vaqtning o'zida maksimal so'rovlarga ustuvorlik berish va qanday vositalar yordamida?
Agar klaster etarlicha katta bo'lsa, tahlilchilar uchun kirish nuqtasi bo'ladigan yana ikkita serverni ko'tarish yaxshi echim bo'ladi. Ya'ni, tahlilchilarga klasterdagi ma'lum qismlarga kirishga ruxsat bermang, shunchaki ikkita bo'sh serverni ma'lumotlarsiz yarating va ularga kirish huquqlarini sozlang. Bunday holda, taqsimlangan so'rovlar uchun foydalanuvchi sozlamalari uzoq serverlarga o'tkaziladi. Ya'ni, siz ushbu ikkita serverda hamma narsani sozlaysiz va sozlamalar butun klasterga ta'sir qiladi.
Aslida, bu serverlarda ma'lumotlar yo'q, ammo ulardagi RAM miqdori so'rovlarni bajarish uchun juda muhimdir. Diskdan tashqi yig'ish yoki tashqi saralash yoqilgan bo'lsa, vaqtinchalik ma'lumotlar uchun ham foydalanish mumkin.
Barcha mumkin bo'lgan cheklovlar bilan bog'liq sozlamalarni ko'rib chiqish muhimdir. Agar men hozir tahlilchi sifatida Yandex.Metrica klasteriga borib, so'rov so'rasam Xitlardan sonni tanlang, keyin menga darhol so'rovni bajara olmaydigan istisno beriladi. Men skanerlashim mumkin bo'lgan maksimal qatorlar soni yuz milliardni tashkil etadi va jami klasterdagi bitta jadvalda ularning ellik trillioni mavjud. Bu birinchi cheklov.
Aytaylik, qator chegarasini olib tashladim va so'rovni qayta ishga tushirdim. Keyin men quyidagi istisnoni ko'raman - sozlash yoqilgan sana bo'yicha kuch indeksi. Agar sana oralig‘ini ko‘rsatmagan bo‘lsam, so‘rovni yakunlay olmayman. Uni qo'lda belgilash uchun tahlilchilarga ishonishingiz shart emas. Odatdagi holat sana oralig'i haftalar orasidagi voqea sanasi yozilishidir. Va keyin ular shunchaki noto'g'ri joyda qavsni ko'rsatdilar va va o'rniga u yoki - yoki URL mosligi chiqdi. Agar chegara bo'lmasa, u URL ustunini ko'zdan kechiradi va faqat bir tonna resurslarni behuda sarflaydi.
Bundan tashqari, ClickHouse ikkita ustuvor sozlamalarga ega. Afsuski, ular juda ibtidoiy. Biri oddiygina deyiladi ustunlik. Agar ustuvorlik ≠ 0 bo'lsa va qandaydir ustuvorlikka ega bo'lgan so'rovlar bajarilayotgan bo'lsa-da, lekin ustuvorlik qiymati undan past bo'lgan so'rov bajarilayotgan bo'lsa, bu yuqori ustuvorlikni bildiradi, u holda ustuvorlik qiymati kattaroq bo'lgan so'rov bajariladi, bu pastroq ustuvorlikni bildiradi. , oddiygina to'xtatiladi va bu vaqt davomida umuman ishlamaydi.
Bu juda qo'pol sozlama va klaster doimiy yukga ega bo'lgan holatlar uchun mos emas. Ammo agar sizda muhim bo'lgan qisqa, tez so'rovlar bo'lsa va klaster asosan bo'sh bo'lsa, bu sozlash mos keladi.
Keyingi ustuvor sozlama chaqiriladi Operatsion tizimning ustuvorligi. Bu shunchaki Linux rejalashtiruvchisi uchun barcha so'rovlarni bajarish mavzulari uchun yoqimli qiymatni o'rnatadi. Bu shunday ishlaydi, lekin u hali ham ishlaydi. Agar siz minimal yoqimli qiymatni o'rnatsangiz - bu qiymat bo'yicha eng katta va shuning uchun eng past ustuvorlik - va yuqori ustuvorlikdagi so'rovlar uchun -19 ni o'rnatsangiz, protsessor past ustuvor so'rovlarni yuqori ustuvorliklarga qaraganda taxminan to'rt baravar kamroq iste'mol qiladi.
Shuningdek, so'rovni bajarishning maksimal vaqtini sozlashingiz kerak - aytaylik, besh daqiqa. So'rovni bajarishning minimal tezligi eng zo'r narsadir. Ushbu sozlama uzoq vaqtdan beri mavjud bo'lib, nafaqat ClickHouse sekinlashmasligini ta'kidlash, balki uni majburlash kerak.
Tasavvur qiling-a, siz sozladingiz: agar ba'zi so'rovlar soniyasiga bir million satrdan kamroq ishlov bersa, buni qila olmaysiz. Bu bizning yaxshi nomimizni, yaxshi ma'lumotlar bazasini sharmanda qiladi. Keling, buni taqiqlaylik. Aslida ikkita sozlamalar mavjud. Biri deyiladi minimal bajarish tezligi - soniyada satrlarda, ikkinchisi esa minimal bajarilish tezligini tekshirishdan oldin kutish vaqti deb ataladi - sukut bo'yicha o'n besh soniya. Ya'ni, o'n besh soniya mumkin va keyin, agar u sekin bo'lsa, faqat istisno qiling va so'rovni bekor qiling.
Shuningdek, siz kvotalar o'rnatishingiz kerak. ClickHouse-da resurslar sarfini hisoblaydigan o'rnatilgan kvota xususiyati mavjud. Ammo, afsuski, protsessor, disklar kabi apparat resurslari emas, balki mantiqiy bo'lganlar - qayta ishlangan so'rovlar, satrlar va o'qilgan baytlar soni. Va siz, masalan, besh daqiqa ichida maksimal yuzta so'rovni va soatiga mingta so'rovni sozlashingiz mumkin.
Nima uchun bu muhim? Chunki ba'zi tahliliy so'rovlar to'g'ridan-to'g'ri ClickHouse mijozidan qo'lda amalga oshiriladi. Va hammasi yaxshi bo'ladi. Ammo kompaniyangizda ilg'or tahlilchilar bo'lsa, ular skript yozadilar va skriptda xatolik bo'lishi mumkin. Va bu xato so'rovning cheksiz tsiklda bajarilishiga olib keladi. Bu biz o'zimizni himoya qilishimiz kerak bo'lgan narsadir.
Bitta so'rov natijalarini o'nta mijozga berish mumkinmi?
Bizda bir vaqtning o'zida juda katta so'rovlar bilan kirishni yoqtiradigan bir nechta foydalanuvchi bor. So'rov katta va, qoida tariqasida, tezda bajariladi, lekin bir vaqtning o'zida bunday so'rovlar ko'p bo'lganligi sababli, u juda og'riqli bo'ladi. Ketma-ket o'n marta kelgan bir xil so'rovni bir marta bajarib, natijasini o'nta mijozga berish mumkinmi?
Muammo shundaki, bizda oraliq ma'lumotlarning kesh yoki kesh natijalari yo'q. Operatsion tizimning sahifa keshi mavjud bo'lib, bu sizni diskdan ma'lumotlarni qayta o'qishga to'sqinlik qiladi, ammo, afsuski, ma'lumotlar hali ham siqilgan, seriyasizlashtiriladi va qayta ishlanadi.
Men oraliq ma'lumotlarni keshlash yoki shunga o'xshash so'rovlarni qandaydir navbatga qo'yish va natijalar keshini qo'shish orqali qandaydir tarzda buning oldini olishni xohlayman. Hozirda bizda soʻrov keshini qoʻshadigan bitta tortishish soʻrovi mavjud, lekin faqat kirish va qoʻshilish boʻlimlaridagi quyi soʻrovlar uchun, yaʼni yechim toʻliq emas.
Biroq, biz ham shunday holatga duch kelamiz. Ayniqsa, kanonik misol - sahifalangan so'rovlar. Hisobot bor, u bir necha sahifaga ega va 10 chegarasi uchun so'rov bor. Keyin bir xil narsa, lekin 10,10 chegarasi. Keyin yana keyingi sahifa. Va savol shundaki, nega biz bularning barchasini har safar hisoblaymiz? Ammo hozir hech qanday yechim yo'q va undan qochishning iloji yo'q.
ClickHouse-ning yonidagi vagon sifatida joylashtirilgan muqobil yechim mavjud - .
Kirill Shvakov: ClickHouse Proksi-da o'rnatilgan tezlikni cheklovchi va o'rnatilgan natijalar keshi mavjud. U erda juda ko'p sozlamalar o'rnatildi, chunki shunga o'xshash muammo hal qilinmoqda. Proksi-server so'rovlarni navbatga qo'yish orqali cheklash va so'rov keshi qancha vaqt ishlashni sozlash imkonini beradi. Agar so'rovlar haqiqatan ham bir xil bo'lsa, Proksi ularni ko'p marta yuboradi, lekin ClickHouse-ga faqat bir marta boradi.
Nginx ham bepul versiyada keshga ega va bu ham ishlaydi. Nginx-da hatto so'rovlar bir vaqtning o'zida kelib tushsa, u tugaguniga qadar boshqalarni sekinlashtiradigan sozlamalarga ega. Lekin ClickHouse proksi-serverida sozlash ancha yaxshi bajarilgan. Bu maxsus ClickHouse uchun, xususan, ushbu so'rovlar uchun yaratilgan, shuning uchun u ko'proq mos keladi. Xo'sh, o'rnatish oson.
Asinxron operatsiyalar va moddiylashtirilgan ko'rinishlar haqida nima deyish mumkin?
Takrorlash mexanizmi bilan operatsiyalar asinxron bo'lishi bilan bog'liq muammo bor - avval ma'lumotlar yoziladi, keyin u qulab tushadi. Agar ba'zi agregatlarga ega materiallashtirilgan planshet belgi ostida yashasa, unga dublikatlar yoziladi. Va agar murakkab mantiq bo'lmasa, unda ma'lumotlar takrorlanadi. Bu haqda nima qila olasiz?
Aniq yechim bor - asinxron kollaps operatsiyasi paytida ma'lum bir matviewlar sinfida triggerni amalga oshirish. Kumush o'qlar yoki shunga o'xshash funksiyalarni amalga oshirish rejalari bormi?
Deuplikatsiya qanday ishlashini tushunishga arziydi. Men hozir aytadiganlarim savolga taalluqli emas, lekin eslash kerak bo'lsa.
Replikatsiya qilingan jadvalga qo'shganda, kiritilgan barcha bloklarning takrorlanishi sodir bo'ladi. Agar siz bir xil qatorlar soni bir xil bo'lgan bir xil blokni bir xil tartibda qayta kiritsangiz, ma'lumotlar takrorlanadi. Qo'shishga javoban siz "OK" ni olasiz, lekin aslida bitta ma'lumot paketi yoziladi va ular takrorlanmaydi.
Bu ishonch uchun zarur. Agar siz kiritish paytida "OK" ni olsangiz, ma'lumotlaringiz kiritilgan. Agar siz ClickHouse-dan xatoga yo'l qo'ysangiz, demak ular kiritilmagan va siz kiritishni takrorlashingiz kerak. Agar ulanish paytida ulanish buzilgan bo'lsa, unda siz ma'lumotlar kiritilganmi yoki yo'qligini bilmaysiz. Yagona variant - kiritishni yana takrorlash. Agar ma'lumotlar haqiqatan ham kiritilgan bo'lsa va siz uni qayta kiritgan bo'lsangiz, bloklangan deuplikatsiya mavjud. Bu dublikatlarni oldini olish uchun kerak.
Shuningdek, u moddiylashtirilgan ko'rinishlar uchun qanday ishlashi ham muhimdir. Agar ma'lumotlar asosiy jadvalga kiritilganda dekuplikatsiya qilingan bo'lsa, u holda u moddiylashtirilgan ko'rinishga ham kirmaydi.
Endi savol haqida. Sizning vaziyatingiz murakkabroq, chunki siz alohida satrlarning dublikatlarini yozyapsiz. Ya'ni, butun to'plam emas, balki aniq chiziqlar takrorlanadi va ular fonda qulab tushadi. Haqiqatan ham, ma'lumotlar asosiy jadvalda qulab tushadi, lekin yig'ilmagan ma'lumotlar materiallashtirilgan ko'rinishga o'tadi va birlashtirish paytida materiallashtirilgan ko'rinishlarga hech narsa bo'lmaydi. Chunki moddiylashtirilgan ko'rinish qo'shish tetikidan boshqa narsa emas. Boshqa operatsiyalar paytida unga qo'shimcha hech narsa bo'lmaydi.
Va men sizni bu erda baxtli qila olmayman. Siz faqat bu ish uchun maxsus echim izlashingiz kerak. Misol uchun, uni moddiylashtirilgan ko'rinishda takrorlash mumkinmi va deuplikatsiya usuli xuddi shunday ishlashi mumkin. Ammo, afsuski, har doim ham emas. Agar u yig'ilsa, u ishlamaydi.
Kirill Shvakov: Bizda ham o'sha paytda qo'ltiq tayoq qurilishi bor edi. Reklama taassurotlari bilan bog'liq muammo yuzaga keldi va biz real vaqtda ko'rsatishimiz mumkin bo'lgan ba'zi ma'lumotlar bor - bu shunchaki taassurotlar. Ular kamdan-kam hollarda takrorlanadi, lekin agar bu sodir bo'lsa, baribir ularni keyinroq yo'q qilamiz. Va takrorlash mumkin bo'lmagan narsalar bor edi - bosish va bu butun voqea. Lekin men ham ularni deyarli darhol ko'rsatmoqchi edim.
Moddiylashtirilgan qarashlar qanday amalga oshirildi? To'g'ridan-to'g'ri yozilgan ko'rinishlar bor edi - u xom ma'lumotlarga yozilgan va ko'rinishlarga yozilgan. U erda, bir nuqtada ma'lumotlar juda to'g'ri emas, u takrorlanadi va hokazo. Jadvalning ikkinchi qismi ham bor, u erda ular moddiylashtirilgan ko'rinishlar bilan bir xil ko'rinadi, ya'ni ular tuzilishi jihatidan mutlaqo bir xil. Vaqti-vaqti bilan biz ma'lumotlarni qayta hisoblaymiz, ma'lumotlarni dublikatsiz hisoblaymiz, o'sha jadvallarga yozamiz.
Biz API orqali o'tdik - bu ClickHouse-da qo'lda ishlamaydi. Va API ko'rinadi: jadvalga oxirgi qo'shilish sanasi bo'lsa, u erda to'g'ri ma'lumotlar allaqachon hisoblanganligi kafolatlanadi va u bitta jadvalga va boshqa jadvalga so'rov yuboradi. Biridan so'rov ma'lum bir vaqtni tanlaydi, ikkinchisidan esa hali hisoblanmagan narsalarni oladi. Va u ishlaydi, lekin faqat ClickHouse orqali emas.
Agar sizda qandaydir API mavjud bo'lsa - tahlilchilar uchun, foydalanuvchilar uchun - demak, printsipial jihatdan, bu variant. Siz doimo hisoblaysiz, har doim hisoblaysiz. Bu kuniga bir marta yoki boshqa vaqtda amalga oshirilishi mumkin. Siz o'zingiz uchun kerak bo'lmagan va muhim bo'lmagan diapazonni tanlaysiz.
ClickHouse-da juda ko'p jurnallar mavjud. Bir qarashda server bilan sodir bo'lgan hamma narsani qanday ko'rishim mumkin?
ClickHouse juda ko'p sonli turli xil jurnallarga ega va bu raqam ortib bormoqda. Yangi versiyalarda ularning ba'zilari hatto sukut bo'yicha yoqilgan; eski versiyalarda ular yangilashda yoqilishi kerak. Biroq, ularning soni tobora ko'payib bormoqda. Oxir-oqibat, men hozir serverim bilan nima sodir bo'layotganini ko'rishni xohlayman, ehtimol qandaydir xulosalar panelida.
Sizda ushbu jurnallarni tayyor mahsulot sifatida ko'rsatadigan tayyor asboblar panelining ba'zi funksiyalarini qo'llab-quvvatlaydigan ClickHouse jamoasi yoki do'stlaringiz jamoalari bormi? Oxir-oqibat, ClickHouse-dagi jurnallarga qarash juda yaxshi. Lekin u allaqachon asboblar paneli shaklida tayyorlangan bo'lsa, juda zo'r bo'lardi. Men undan bir zarba olardim.
Standartlashtirilmagan bo'lsa-da, asboblar paneli mavjud. Bizning kompaniyamizda 60 ga yaqin jamoa ClickHouse-dan foydalanadi va eng g'alati tomoni shundaki, ularning ko'pchiligida o'zlari uchun yaratgan asboblar paneli bor va biroz boshqacha. Ba'zi jamoalar ichki Yandex.Cloud o'rnatilishidan foydalanadilar. Barcha kerakli hisobotlar bo'lmasa-da, ba'zi tayyor hisobotlar mavjud. Boshqalar o'zlariga ega.
Metrica'dagi hamkasblarim Grafana'da o'zlarining asboblar paneliga ega, men esa ularning klasteri uchun o'zimniki bor. Men serif keshi uchun kesh hit kabi narsalarni ko'rib chiqyapman. Va bundan ham qiyinroq, biz turli xil vositalardan foydalanamiz. Men asboblar panelini Graphite-web deb nomlangan juda eski vosita yordamida yaratdim. U butunlay xunuk. Va men buni hali ham shunday ishlataman, garchi Grafana qulayroq va chiroyli bo'lsa ham.
Boshqaruv panelidagi asosiy narsa bir xil. Bular klaster uchun tizim ko'rsatkichlari: CPU, xotira, disk, tarmoq. Boshqalar - bir vaqtning o'zida so'rovlar soni, bir vaqtning o'zida birlashmalar soni, soniyada so'rovlar soni, MergeTree jadvali bo'limlari uchun maksimal bo'laklar soni, replikatsiya kechikishi, replikatsiya navbatining o'lchami, soniyada kiritilgan qatorlar soni, soniyada kiritilgan bloklar soni. Bu jurnallardan emas, balki o'lchovlardan olinadigan narsadir.
Vladimir Kolobaev: Aleksey, men buni biroz tuzatmoqchiman. Grafana bor. Grafana ma'lumotlar manbasiga ega, ya'ni ClickHouse. Ya'ni, men Grafana-dan to'g'ridan-to'g'ri ClickHouse-ga so'rov yuborishim mumkin. ClickHouse-da jurnallar bilan jadval mavjud, u hamma uchun bir xil. Natijada, men Grafana-dagi ushbu jurnallar jadvaliga kirishni va serverim so'rovlarini ko'rishni xohlayman. Bunday boshqaruv paneli bo'lsa juda yaxshi bo'lardi.
Men o'zim velosipedda yurdim. Ammo menda savol bor - agar hamma narsa standartlashtirilgan bo'lsa va Grafana hamma tomonidan ishlatilsa, nega Yandexda bunday rasmiy boshqaruv paneli yo'q?
Kirill Shvakov: Aslida, ClickHouse-ga kiradigan ma'lumotlar manbai endi Altinity-ni qo'llab-quvvatlaydi. Va men faqat qaerga qazish va kimni itarish vektorini bermoqchiman. Siz ulardan so'rashingiz mumkin, chunki Yandex hali ham uning atrofidagi voqeani emas, balki ClickHouse-ni yaratadi. Altinity hozirda ClickHouse-ni targ'ib qiluvchi asosiy kompaniya hisoblanadi. Ular uni tashlab ketmaydilar, balki uni qo'llab-quvvatlaydilar. Chunki, qoida tariqasida, Grafana veb-saytiga asboblar panelini yuklash uchun siz faqat ro'yxatdan o'tishingiz va uni yuklashingiz kerak - hech qanday maxsus muammolar yo'q.
Aleksey Milovidov: O'tgan yil davomida ClickHouse ko'plab so'rovlar profilini yaratish imkoniyatlarini qo'shdi. Resursdan foydalanish bo'yicha har bir so'rov uchun ko'rsatkichlar mavjud. Va yaqinda biz so'rov har millisekundda qayerga sarflanishini ko'rish uchun undan ham past darajadagi so'rov profilini qo'shdik. Ammo bu funksiyadan foydalanish uchun men konsol mijozini ochishim va har doim unutib qo'yadigan so'rovni yozishim kerak. Men uni qayergadir saqladim va aniq qaerdaligini unutib qo'yaman.
Bu yerda sizning og‘ir so‘rovlaringiz, so‘rovlar sinfi bo‘yicha guruhlangan, degan vosita bo‘lishini istardim. Men bittasini bosdim va ular menga bu og'ir ekanligini aytishdi. Hozirda bunday yechim yo'q. Odamlar mendan: "Ayting-chi, Grafana uchun tayyor asboblar paneli bormi?" Deb so'rashganda, men: "Grafana veb-saytiga o'ting, u erda "Boshqaruv paneli" hamjamiyati va asboblar paneli borligi juda g'alati. Dimkadan, Kostyandan asboblar paneli mavjud. Bu nima ekanligini bilmayman, men o'zim foydalanmaganman."
Server OOMga tushib ketmasligi uchun birlashmalarga qanday ta'sir qilish kerak?
Menda jadval bor, jadvalda faqat bitta bo'lim bor, bu ReplacingMergeTree. Men unga to'rt yildan beri ma'lumot yozyapman. Men unga o'zgartirish kiritishim va ba'zi ma'lumotlarni o'chirishim kerak edi.
Men buni qildim va ushbu so'rovni qayta ishlash jarayonida klasterdagi barcha serverlardagi barcha xotira iste'mol qilindi va klasterdagi barcha serverlar OOMga o'tdi. Keyin ularning hammasi birga turishdi, xuddi shu operatsiyani, ma'lumotlar blokini birlashtira boshladilar va yana OOMga tushdilar. Keyin ular yana o'rnidan turdilar va yana yiqildilar. Va bu narsa to'xtamadi.
Keyin bu yigitlar tuzatgan xato ekani ma'lum bo'ldi. Bu juda zo'r, sizga katta rahmat. Ammo qoldiq qoldi. Va endi, jadvalda qandaydir birlashma qilish haqida o'ylaganimda, menda savol tug'iladi - nega men bu birlashmalarga qandaydir tarzda ta'sir qila olmayman? Misol uchun, ularni kerakli RAM miqdori bilan cheklang yoki, qoida tariqasida, ushbu maxsus jadvalni qayta ishlaydigan miqdor bilan cheklang.
Menda "Metrics" deb nomlangan jadval bor, iltimos, men uchun ikkita mavzuda qayta ishlang. Parallel ravishda o'n yoki beshta birlashma yaratishning hojati yo'q, uni ikkita qilib bajaring. Menimcha, menda ikkita xotira yetarli, lekin o'nta xotirani qayta ishlash uchun etarli bo'lmasligi mumkin. Nima uchun qo'rquv saqlanib qoladi? Jadval o'sib borayotgani va bir kun kelib men xato tufayli emas, balki ma'lumotlar shunchalik katta hajmda o'zgarishi sababli menda etarli xotiraga ega bo'lmagan vaziyatga duch kelaman. server. Va keyin server birlashayotganda OOMga tushib qoladi. Bundan tashqari, men mutatsiyani bekor qila olaman, lekin Merji endi yo'q.
Bilasizmi, birlashganda server OOM ga tushmaydi, chunki birlashganda operativ xotira miqdori faqat bitta kichik ma'lumotlar diapazoni uchun ishlatiladi. Shunday qilib, ma'lumotlar miqdoridan qat'i nazar, hamma narsa yaxshi bo'ladi.
Vladimir Kolobaev: Yaxshi. Bu erda xatolik tuzatilgandan so'ng, men o'zim uchun yangi versiyani yuklab oldim va boshqa stolda, ko'p bo'limlar mavjud bo'lgan kichikroq stolda men shunga o'xshash operatsiyani bajardim. Va birlashma paytida serverda taxminan 100 Gb operativ xotira yoqildi. Menda 150 ta band, 100 ta yegan va 50 Gb oyna qoldi, shuning uchun men OOMga tushmadim.
Agar u 100 GB operativ xotirani iste'mol qilsa, hozirda meni OOMga tushib qolishdan nima himoya qiladi? Agar to'satdan birlashmadagi RAM tugasa nima qilish kerak?
Aleksey Milovidov: Bunday muammo borki, birlashish uchun maxsus RAM iste'moli cheklanmaydi. Va ikkinchi muammo shundaki, agar qandaydir birlashma tayinlangan bo'lsa, uni bajarish kerak, chunki u replikatsiya jurnalida qayd etilgan. Replikatsiya jurnali - bu replikatsiyani izchil holatga keltirish uchun zarur bo'lgan harakatlar. Agar siz ushbu replikatsiya jurnalini orqaga qaytaradigan qo'lda manipulyatsiya qilmasangiz, birlashtirish u yoki bu tarzda bajarilishi kerak bo'ladi.
Albatta, "har holda" OOM dan himoya qiladigan RAM chekloviga ega bo'lish ortiqcha bo'lmaydi. Bu birlashishni yakunlashga yordam bermaydi, u yana boshlanadi, biron bir chegaraga etadi, istisno qiladi va keyin yana boshlanadi - bundan hech qanday yaxshi narsa bo'lmaydi. Ammo printsipial jihatdan bu cheklovni joriy qilish foydali bo'ladi.
ClickHouse uchun Golang drayveri qanday ishlab chiqiladi?
Kirill Shvakov tomonidan yozilgan Golang haydovchisi endi ClickHouse jamoasi tomonidan rasman qo'llab-quvvatlanadi. U , u endi katta va haqiqiy.
Kichik eslatma. Cheksiz tartibning oddiy shakllarining ajoyib va sevimli ombori mavjud - bu Vertica. Shuningdek, ular Vertica ishlab chiquvchilari tomonidan qo'llab-quvvatlanadigan o'zlarining rasmiy python drayverlariga ega. Va bir necha bor shunday bo'ldiki, saqlash versiyalari va drayver versiyalari keskin ravishda ajralib chiqdi va haydovchi bir nuqtada ishlashni to'xtatdi. Va ikkinchi nuqta. Ushbu rasmiy haydovchini qo'llab-quvvatlash, menimcha, "nipel" tizimi tomonidan amalga oshiriladi - siz ularga muammo yozasiz va u abadiy osilib turadi.
Menda ikkita savol bor. Endi Kirillning Golang drayveri Golangdan ClickHouse bilan muloqot qilishning deyarli standart usuli hisoblanadi. Agar kimdir hali ham http interfeysi orqali muloqot qilmasa, chunki unga shunday yoqadi. Ushbu haydovchining rivojlanishi qanday davom etadi? U ombordagi har qanday buzilish o'zgarishlari bilan sinxronlashtiriladimi? Va masalani ko'rib chiqish tartibi qanday?
Kirill Shvakov: Birinchisi, hamma narsa byurokratik tarzda qanday tashkil etilgan. Bu masala muhokama qilinmadi, shuning uchun javob beradigan hech narsam yo'q.
Muammo haqidagi savolga javob berish uchun bizga haydovchining bir oz tarixi kerak. Men juda ko'p ma'lumotlarga ega bo'lgan kompaniyada ishladim. Bu bir joyda saqlanishi kerak bo'lgan juda ko'p voqealarga ega bo'lgan reklama spinner edi. Va bir nuqtada ClickHouse paydo bo'ldi. Biz uni ma'lumotlar bilan to'ldirdik va dastlab hamma narsa yaxshi edi, lekin keyin ClickHouse qulab tushdi. O'sha paytda biz bunga muhtoj emasmiz deb qaror qildik.
Bir yil o'tgach, biz ClickHouse-dan foydalanish g'oyasiga qaytdik va u erda qandaydir tarzda ma'lumotlarni yozishimiz kerak edi. Kirish xabari shunday edi: apparat juda zaif, resurslar kam. Ammo biz har doim shunday ishlaganmiz va shuning uchun biz mahalliy protokolga qaradik.
Go'da ishlaganimiz uchun bizga Go haydovchisi kerakligi aniq edi. Men buni deyarli to'la vaqtli qildim - bu mening ish vazifam edi. Biz uni ma'lum bir nuqtaga olib keldik va printsipial jihatdan bizdan boshqa hech kim undan foydalanishini taxmin qilmadi. Keyin CloudFlare aynan bir xil muammoga duch keldi va bir muncha vaqt biz ular bilan juda muammosiz ishladik, chunki ularning vazifalari bir xil edi. Bundan tashqari, biz buni ClickHouse-da ham o'zimiz, ham haydovchida qildik.
Bir payt men buni qilishni to'xtatdim, chunki ClickHouse va ish bo'yicha faoliyatim biroz o'zgardi. Shuning uchun masalalar yopiq emas. Vaqti-vaqti bilan biror narsaga muhtoj bo'lgan odamlar o'zlari omborga kirishadi. Keyin men tortishish so'roviga qarayman va ba'zida o'zim ham biror narsani tahrir qilaman, lekin bu kamdan-kam hollarda bo'ladi.
Men haydovchiga qaytmoqchiman. Bir necha yil oldin, bularning barchasi boshlanganda, ClickHouse ham boshqacha va har xil imkoniyatlarga ega edi. Endi biz drayverni yaxshi ishlashi uchun qanday qilib qayta tiklashni tushunamiz. Agar bu sodir bo'lsa, unda to'plangan tayoqchalar tufayli 2-versiya har qanday holatda mos kelmaydi.
Men bu masalani qanday tashkil qilishni bilmayman. Mening o'zim ham ko'p vaqtim yo'q. Agar kimdir haydovchini tugatsa, men ularga yordam berishim va nima qilish kerakligini aytishim mumkin. Lekin loyihani ishlab chiqishda Yandeksning faol ishtiroki hali muhokama qilinmagan.
Aleksey Milovidov: Aslida, bu haydovchilarda hali byurokratiya yo‘q. Bitta narsa shundaki, ular rasmiy tashkilotga topshiriladi, ya'ni bu drayver Go uchun rasmiy standart yechim sifatida tan olingan. Boshqa haydovchilar ham bor, lekin ular alohida keladi.
Bizda bu drayverlar uchun ichki ishlanma yo'q. Gap shundaki, biz alohida shaxsni aynan mana shu haydovchiga emas, balki barcha jamoa haydovchilarini rivojlantirish uchun ishga olamizmi yoki chetdan kimnidir topa olamizmi?
lazy_load sozlamasi yoqilgan holda qayta ishga tushirilgandan so'ng tashqi lug'at yuklanmaydi. Nima qilish kerak?
Bizda lazy_load sozlamasi yoqilgan va server qayta ishga tushirilgandan so‘ng lug‘at o‘z-o‘zidan yuklanmaydi. U foydalanuvchi ushbu lug'atga kirgandan keyingina ko'tariladi. Va birinchi marta unga kirganimda, u xato beradi. ClickHouse-dan foydalanib, qandaydir tarzda lug'atlarni avtomatik ravishda yuklash mumkinmi yoki foydalanuvchilar xatolikka yo'l qo'ymasliklari uchun ularning tayyorligini har doim o'zingiz nazorat qilishingiz kerakmi?
Ehtimol, bizda ClickHouse-ning eski versiyasi bor, shuning uchun lug'at avtomatik ravishda yuklanmadi. Bu shunday bo'lishi mumkinmi?
Birinchidan, so'rov yordamida lug'atlarni majburiy yuklash mumkin lug'atlarni tizimni qayta yuklash. Ikkinchidan, xato haqida - agar lug'at allaqachon yuklangan bo'lsa, so'rovlar yuklangan ma'lumotlar asosida ishlaydi. Agar lug'at hali yuklanmagan bo'lsa, u so'rov paytida to'g'ridan-to'g'ri yuklanadi.
Bu og'ir lug'atlar uchun juda qulay emas. Misol uchun, siz MySQL-dan bir million qatorni olishingiz kerak. Kimdir oddiy tanlov qiladi, lekin bu tanlov bir xil million qatorlarni kutadi. Bu erda ikkita yechim bor. Birinchisi, lazy_load-ni o'chirish. Ikkinchidan, server ishga tushganda, yukni yuklashdan oldin, bajaring tizimni qayta yuklash lug'ati yoki shunchaki lug'atdan foydalanadigan so'rovni bajaring. Keyin lug'at yuklanadi. Siz lazy_load sozlamasi yoqilgan holda lug'atlar mavjudligini nazorat qilishingiz kerak, chunki ClickHouse ularni avtomatik ravishda yuklamaydi.
Oxirgi savolga javob shundaki, versiya eski yoki uni tuzatish kerak.
Tizimni qayta yuklash lug'atlari ko'p lug'atlarning hech birini yuklamaydi, agar ulardan kamida bittasi xato bilan ishlamay qolsa, nima qilish kerak?
Tizimni qayta yuklash lug'atlari haqida yana bir savol bor. Bizda ikkita lug'at bor - biri yuklanmagan, ikkinchisi yuklangan. Bunday holda, tizimni qayta yuklash lug'atlari hech qanday lug'atni yuklamaydi va tizimni qayta yuklash lug'atidan foydalanib, ma'lum bir lug'atni uning nomi bo'yicha nuqtama-nuqta yuklashingiz kerak bo'ladi. Bu ClickHouse versiyasi bilan ham bog'liqmi?
Men sizni xursand qilmoqchiman. Bu xatti-harakat o'zgarib borardi. Bu shuni anglatadiki, agar siz ClickHouse-ni yangilasangiz, u ham o'zgaradi. Agar hozirgi xatti-harakatlaringizdan mamnun bo'lmasangiz lug'atlarni tizimni qayta yuklash, yangilang va u yaxshi tomonga o'zgarishiga umid qilaylik.
ClickHouse konfiguratsiyasida tafsilotlarni sozlashning bir usuli bormi, lekin xatolik yuz berganda ularni ko'rsatmaslik kerakmi?
Keyingi savol lug'at bilan bog'liq xatolar, ya'ni tafsilotlar haqida. Biz lug'at uchun ClickHouse konfiguratsiyasida ulanish tafsilotlarini ko'rsatdik va agar xato bo'lsa, biz javob sifatida ushbu ma'lumotlarni va parolni olamiz.
Biz bu xatoni ODBC drayver konfiguratsiyasiga ma'lumotlarni qo'shish orqali hal qildik. ClickHouse konfiguratsiyasidagi tafsilotlarni sozlashning biron bir usuli bormi, lekin xatolar bo'lsa, bu ma'lumotlarni ko'rsatmaydi?
Bu erda haqiqiy yechim bu hisob ma'lumotlarini odbc.ini da ko'rsatish va ClickHouse'ning o'zida faqat ODBC ma'lumotlar manbasi nomini ko'rsatishdir. Bu boshqa lug'at manbalarida sodir bo'lmaydi - na MySQL lug'atida, na boshqalarda xato xabari kelganda parolni ko'rmasligingiz kerak. ODBC uchun men ham qarayman - agar u mavjud bo'lsa, uni olib tashlashingiz kerak.
Bonus: yig'ilishlardan Zoom uchun fon rasmlari
Rasmni bosish orqali yig'ilishlarning bonus fonlari eng qat'iy o'quvchilar uchun ochiladi. Biz Avito texnologiyasi maskotlari bilan yong'inni o'chiramiz, tizim ma'muri xonasi yoki eski maktab kompyuter klubidagi hamkasblar bilan maslahatlashamiz va graffiti fonida ko'prik ostida har kuni uchrashuvlar o'tkazamiz.
Manba: www.habr.com