ClickHouse ixtisoslashtirilgan tizim bo'lgani uchun uni ishlatishda uning arxitekturasining xususiyatlarini hisobga olish kerak. Ushbu hisobotda Aleksey ClickHouse-dan foydalanishda samarasiz ishlashga olib keladigan keng tarqalgan xatolar misollari haqida gapiradi. Amaliy misollar ma'lumotlarni qayta ishlashning u yoki bu sxemasini tanlash unumdorlikni kattalik tartibiga ko'ra qanday o'zgartirishi mumkinligini ko'rsatadi.
Hammaga salom! Mening ismim Aleksey, men ClickHouse qilaman.
Birinchidan, men sizni darhol xursand qilishga shoshilaman, bugun men sizga ClickHouse nima ekanligini aytmayman. Rostini aytsam, men bundan charchadim. Har safar men sizga nima ekanligini aytaman. Va, ehtimol, hamma allaqachon biladi.
Buning o'rniga men sizga qanday xatolar bo'lishi mumkinligini aytaman, ya'ni ClickHouse-dan qanday qilib noto'g'ri foydalanishingiz mumkin. Darhaqiqat, qo'rqishning hojati yo'q, chunki biz ClickHouse-ni oddiy, qulay va qutidan tashqarida ishlaydigan tizim sifatida ishlab chiqmoqdamiz. Men uni o'rnatdim, muammo yo'q.
Ammo siz hali ham ushbu tizim ixtisoslashganligini hisobga olishingiz kerak va siz ushbu tizimni qulaylik zonasidan chiqarib yuboradigan noodatiy foydalanish holatiga osongina duch kelishingiz mumkin.
Xo'sh, qanday rake bor? Ko'pincha men aniq narsalar haqida gapiraman. Hamma narsa hamma uchun ravshan, hamma hamma narsani tushunadi va juda aqlli ekanligidan xursand bo'lishi mumkin, tushunmaydiganlar esa yangi narsalarni o'rganishadi.
Birinchi va eng oddiy misol, afsuski, tez-tez uchraydi, bu kichik partiyalar bilan ko'p sonli qo'shimchalar, ya'ni ko'p sonli kichik qo'shimchalar.
Agar ClickHouse insertni qanday bajarishini ko'rib chiqsak, unda siz bitta so'rovda kamida terabayt ma'lumot yuborishingiz mumkin. Bu muammo emas.
Keling, odatiy ishlash qanday bo'lishini ko'rib chiqaylik. Misol uchun, bizda Yandex.Metrica ma'lumotlaridan jadval mavjud. Xitlar. 105 ba'zi ustunlar. 700 bayt siqilmagan. Va biz bir million qatorli to'plamlarga yaxshi tarzda kiritamiz.
Biz MergeTree-ni jadvalga joylashtiramiz, u soniyada yarim million qatorga aylanadi. Ajoyib. Replikatsiya qilingan jadvalda u biroz kichikroq bo'ladi, soniyada taxminan 400 000 qator.
Va agar siz kvorum kiritishni yoqsangiz, siz soniyasiga 250 000 atamani bir oz kamroq, lekin baribir yaxshi ishlashga ega bo'lasiz. Kvorum kiritish ClickHouse* da hujjatsiz xususiyatdir.
* 2020 yildan boshlab, .
Agar yomon ish qilsangiz nima bo'ladi? MergeTree jadvaliga bitta qatorni kiritamiz va soniyada 59 qatorni olamiz. Bu 10 000 marta sekinroq. ReplicatedMergeTree-da - soniyada 6 qator. Va agar kvorum yoqilgan bo'lsa, u sekundiga 2 qatorni chiqaradi. Menimcha, bu qandaydir mutlaq axmoqlik. Qanday qilib shunday sekinlashtira olasiz? Hatto mening futbolkamda ClickHouse sekinlashmasligi kerakligi haqida yozilgan. Ammo shunga qaramay, bu ba'zida sodir bo'ladi.
Aslida bu bizning kamchiligimiz. Biz hamma narsani osonlik bilan yaxshi qilishimiz mumkin edi, lekin biz buni qilmadik. Va biz buni qilmadik, chunki bizning skriptimiz buni talab qilmagan. Bizda allaqachon burmalar bor edi. Biz faqat kirish joyida to'plamlarni oldik va hech qanday muammo yo'q. Biz uni joylashtiramiz va hamma narsa yaxshi ishlaydi. Lekin, albatta, har xil stsenariylar mumkin. Misol uchun, sizda ma'lumotlar yaratilgan bir qator serverlar mavjud bo'lganda. Va ular tez-tez ma'lumotlarni kiritmaydilar, lekin ular tez-tez qo'shimchalar bilan yakunlanadi. Va biz qandaydir tarzda bundan qochishimiz kerak.
Texnik nuqtai nazardan, gap shundaki, siz ClickHouse-ga qo'shishni amalga oshirganingizda, ma'lumotlar hech qanday xotira jadvalida tugamaydi. Bizda MergeTree jurnalining haqiqiy tuzilmasi ham yo'q, faqat MergeTree, chunki u erda na jurnal, na memTable. Biz ma'lumotlarni darhol ustunlarga joylashtirilgan fayl tizimiga yozamiz. Va agar sizda 100 ta ustun bo'lsa, unda 200 dan ortiq fayl alohida katalogga yozilishi kerak bo'ladi. Bularning barchasi juda mashaqqatli.
Va savol tug'iladi: "Qanday qilib buni to'g'ri qilish kerak?" Agar vaziyat shunday bo'lsa, siz hali ham qandaydir tarzda ClickHouse-da ma'lumotlarni yozib olishingiz kerak.
Usul 1. Bu eng oson yo'li. Qandaydir taqsimlangan navbatdan foydalaning. Masalan, Kafka. Siz shunchaki Kafkadan ma'lumotlarni chiqarib olasiz va uni soniyada bir marta to'playsiz. Va hamma narsa yaxshi bo'ladi, siz yozasiz, hamma narsa yaxshi ishlaydi.
Kamchiliklari shundaki, Kafka yana bir yirik taqsimlangan tizimdir. Sizning kompaniyangizda allaqachon Kafka borligini ham tushunaman. Bu yaxshi, qulay. Ammo agar u mavjud bo'lmasa, loyihangizga boshqa taqsimlangan tizimni jalb qilishdan oldin uch marta o'ylab ko'rishingiz kerak. Va shuning uchun muqobil variantlarni ko'rib chiqishga arziydi.
Usul 2. Bu eski maktab muqobil va ayni paytda juda oddiy. Sizning jurnallaringizni yaratadigan qandaydir serveringiz bormi? Va u faqat sizning jurnallaringizni faylga yozadi. Va soniyada bir marta, masalan, biz ushbu fayl nomini o'zgartiramiz va yangisini yirtib tashlaymiz. Va alohida skript, cron yoki ba'zi bir demon orqali, eng eski faylni oladi va uni ClickHouse-ga yozadi. Agar siz soniyada bir marta jurnallarni yozsangiz, unda hamma narsa yaxshi bo'ladi.
Ammo bu usulning kamchiliklari shundaki, agar jurnallar yaratilgan serveringiz biron bir joyda yo'qolib qolsa, u holda ma'lumotlar ham yo'qoladi.
Usul 3. Vaqtinchalik fayllarni umuman talab qilmaydigan yana bir qiziqarli usul mavjud. Misol uchun, sizda qandaydir reklama spinneri yoki ma'lumotlarni ishlab chiqaradigan boshqa qiziqarli daemon mavjud. Va siz to'g'ridan-to'g'ri operativ xotirada, buferda bir qancha ma'lumotlarni to'plashingiz mumkin. Va etarli vaqt o'tgandan so'ng, siz bu buferni chetga surib, yangisini yaratasiz va alohida mavzuga allaqachon to'plangan narsalarni ClickHouse-ga kiritasiz.
Boshqa tomondan, ma'lumotlar kill -9 bilan ham yo'qoladi. Agar serveringiz ishlamay qolsa, siz ushbu ma'lumotlarni yo'qotasiz. Va yana bir muammo shundaki, agar siz ma'lumotlar bazasiga yoza olmasangiz, ma'lumotlaringiz RAMda to'planadi. Va yo RAM tugaydi yoki siz shunchaki ma'lumotlarni yo'qotasiz.
Usul 4. Yana bir qiziqarli usul. Sizda qandaydir server jarayoni bormi. Va u darhol ClickHouse-ga ma'lumotlarni yuborishi mumkin, lekin uni bitta ulanishda bajaring. Misol uchun, men http so'rovini uzatish-kodlash bilan yubordim: qo'shish bilan bo'laklangan. Va u juda kamdan-kam bo'laklarni hosil qiladi, siz har bir satrni yuborishingiz mumkin, garchi bu ma'lumotlarni ramkalash uchun qo'shimcha xarajatlar bo'ladi.
Biroq, bu holda ma'lumotlar darhol ClickHouse-ga yuboriladi. Va ClickHouse ularni o'zi bufer qiladi.
Ammo muammolar ham paydo bo'ladi. Endi siz ma'lumotlarni yo'qotasiz, shu jumladan jarayoningiz o'ldirilganda va agar ClickHouse jarayoni o'ldirilgan bo'lsa, chunki u to'liq bo'lmagan qo'shimcha bo'ladi. ClickHouse-da qo'shimchalar qatorlar o'lchamida ma'lum bir chegaragacha atomikdir. Aslida, bu qiziqarli usul. Foydalanish ham mumkin.
Usul 5. Mana yana bir qiziqarli usul. Bu ma'lumotlarni to'plash uchun hamjamiyat tomonidan ishlab chiqilgan serverning bir turi. Men buni o'zim ko'rmaganman, shuning uchun hech narsaga kafolat bera olmayman. Biroq, ClickHouse-ning o'zi uchun hech qanday kafolatlar berilmaydi. Bu ham ochiq manba, lekin boshqa tomondan, siz biz taqdim etishga harakat qiladigan sifat standartlariga o'rganib qolgan bo'lishingiz mumkin. Ammo buning uchun - bilmayman, GitHub-ga o'ting, kodga qarang. Ehtimol, ular oddiy narsa yozishgan.
* 2020 yil holatiga ko'ra ham e'tiborga olinishi kerak .
Usul 6. Yana bir usul Bufer jadvallarini ishlatishdir. Ushbu usulning afzalligi shundaki, uni ishlatishni boshlash juda oson. Bufer jadvalini yarating va unga joylashtiring.
Kamchilik shundaki, muammo to'liq hal etilmagan. Agar MergeTree kabi tezlikda ma'lumotlarni sekundiga bitta to'plam bo'yicha guruhlashingiz kerak bo'lsa, bufer jadvalidagi tezlikda siz soniyasiga kamida bir necha minggacha guruhlashingiz kerak. Agar soniyada 10 000 dan ortiq bo'lsa, u hali ham yomon bo'ladi. Va agar siz uni to'plamlarga qo'shsangiz, u soniyada yuz ming satr bo'lib chiqishini ko'rdingiz. Va bu allaqachon juda og'ir ma'lumotlarda.
Shuningdek, bufer jadvallarida jurnal yo'q. Va agar serveringizda biror narsa noto'g'ri bo'lsa, ma'lumotlar yo'qoladi.
Bonus sifatida biz yaqinda ClickHouse-da Kafkadan ma'lumotlarni olish imkoniyatiga ega bo'ldik. Stol dvigateli bor - Kafka. Siz shunchaki yaratasiz. Va siz unga moddiylashtirilgan tasvirlarni osib qo'yishingiz mumkin. Bunday holda, u o'zi Kafkadan ma'lumotlarni ajratib oladi va kerakli jadvallarga kiritadi.
Va bu imkoniyatning ayniqsa quvonarli tomoni shundaki, buni biz qilganimiz yo'q. Bu hamjamiyat xususiyati. Va men "jamoaviy xususiyat" deganda, men buni hech qanday hurmatsiz nazarda tutaman. Biz kodni o'qib chiqdik, ko'rib chiqdik, u yaxshi ishlashi kerak.
* 2020 yildan boshlab shunga o'xshash qo'llab-quvvatlash paydo bo'ldi .
Ma'lumotlarni kiritishda yana nima noqulay yoki kutilmagan bo'lishi mumkin? Agar siz qiymatlarni kiritish so'rovini qilsangiz va qiymatlarda ba'zi hisoblangan ifodalarni yozsangiz. Masalan, now() ham hisoblangan ifodadir. Va bu holda, ClickHouse har bir satrda ushbu iboralarning tarjimonini ishga tushirishga majbur bo'ladi va unumdorlik kattalik darajasida pasayadi. Buning oldini olish yaxshiroqdir.
* hozirda muammo toʻliq hal qilingan, VALUES dagi ifodalardan foydalanishda unumdorlik regressiyasi endi yoʻq.
Yana bir misol, bo'limlar to'plamiga tegishli bo'lgan bitta to'plamda ma'lumotlarga ega bo'lganingizda ba'zi muammolar paydo bo'lishi mumkin. Odatiy bo'lib, ClickHouse bo'limlari oy bo'yicha. Va agar siz million qatorlar to'plamini qo'shsangiz va bir necha yil davomida ma'lumotlar mavjud bo'lsa, u erda sizda bir necha o'nlab bo'limlar bo'ladi. Va bu bir necha o'nlab marta kichikroq partiyalar bo'lishiga teng, chunki ular ichkarida har doim birinchi bo'limlarga bo'linadi.
* Yaqinda, eksperimental rejimda ClickHouse RAMdagi bo'laklar va qismlarning ixcham formatini oldindan yozish jurnali bilan qo'llab-quvvatladi, bu muammoni deyarli butunlay hal qiladi.
Endi muammoning ikkinchi turini - ma'lumotlarni yozishni ko'rib chiqamiz.
Ma'lumotlarni yozish qat'iy yoki qatorli bo'lishi mumkin. String - bu siz uni olib, barcha maydonlaringiz string turiga tegishli ekanligini e'lon qilganingizda. Bu yomon. Buni qilishning hojati yo'q.
Keling, buni qanday qilib to'g'ri bajarishni aniqlaylik, agar siz bizda qandaydir maydon, string bor deb aytmoqchi bo'lsangiz va ClickHouse buni o'z-o'zidan hal qilsin va men bezovta qilmayman. Ammo baribir biroz harakat qilishga arziydi.
Masalan, bizda IP manzil mavjud. Bir holatda, biz uni satr sifatida saqladik. Masalan, 192.168.1.1. Va boshqa holatda, u UInt32 * tipidagi bir qator bo'ladi. IPv32 manzili uchun 4 bit yetarli.
Birinchidan, g'alati, ma'lumotlar taxminan teng siqiladi. Albatta, farq bo'ladi, lekin unchalik katta emas. Shunday qilib, disk kiritish-chiqarish bilan bog'liq maxsus muammolar yo'q.
Ammo protsessor vaqti va so'rovni bajarish vaqtida jiddiy farq bor.
Noyob IP-manzillar sonini hisoblaylik, agar ular raqamlar sifatida saqlangan bo'lsa. Bu soniyada 137 million qatorni tashkil qiladi. Agar xuddi shunday satrlar shaklida bo'lsa, soniyada 37 million satr. Nima uchun bu tasodif sodir bo'lganini bilmayman. Bu iltimoslarni o'zim bajardim. Ammo baribir taxminan 4 marta sekinroq.
Va agar siz disk maydonidagi farqni hisoblasangiz, unda farq ham bor. Va farq taxminan chorak, chunki noyob IP-manzillar juda ko'p. Va agar oz sonli turli xil ma'nolarga ega bo'lgan chiziqlar bo'lsa, ular lug'atga ko'ra osongina taxminan bir xil hajmga siqiladi.
Va to'rt barobar vaqt farqi yo'lda yotmaydi. Balki parvo qilmassiz, albatta, lekin bunday farqni ko'rganimda, xafa bo'ladi.
Keling, turli xil holatlarni ko'rib chiqaylik.
1. Sizda bir nechta noyob qiymatlarga ega bo'lgan bir holat. Bunday holda, biz siz bilgan va har qanday DBMS uchun ishlatishingiz mumkin bo'lgan oddiy amaliyotdan foydalanamiz. Bularning barchasi nafaqat ClickHouse uchun mantiqiy. Faqatgina ma'lumotlar bazasiga raqamli identifikatorlarni yozing. Va siz ilovangizning yon tomonidagi satrlarga va orqaga aylantirishingiz mumkin.
Masalan, sizda mintaqa bor. Va siz uni satr sifatida saqlashga harakat qilyapsiz. Va u erda yoziladi: Moskva va Moskva viloyati. Va men "Moskva" deb yozilganini ko'rganimda, bu hech narsa emas, lekin Moskva bo'lganda, u qandaydir tarzda g'amgin bo'ladi. Bu qancha bayt.
Buning o'rniga biz shunchaki Ulnt32 va 250 raqamini yozamiz. Bizda Yandex-da 250 bor, lekin sizniki boshqacha bo'lishi mumkin. Har holda, ClickHouse-da geobaza bilan ishlash uchun o'rnatilgan qobiliyat borligini aytaman. Siz shunchaki mintaqalar, jumladan, ierarxik katalogni yozasiz, ya'ni Moskva, Moskva viloyati va sizga kerak bo'lgan hamma narsa bo'ladi. Va siz so'rov darajasida konvertatsiya qilishingiz mumkin.
Ikkinchi variant taxminan bir xil, ammo ClickHouse ichida qo'llab-quvvatlanadi. Bu Enum ma'lumotlar turi. Siz shunchaki Enum ichiga kerak bo'lgan barcha qiymatlarni yozasiz. Masalan, qurilma turi va u erda yozing: ish stoli, mobil, planshet, televizor. Hammasi bo'lib 4 ta variant mavjud.
Kamchilik shundaki, siz uni vaqti-vaqti bilan o'zgartirishingiz kerak. Faqat bitta variant qo'shildi. Keling, jadvalni o'zgartiraylik. Darhaqiqat, ClickHouse-da jadvalni o'zgartirish bepul. Ayniqsa, Enum uchun bepul, chunki diskdagi ma'lumotlar o'zgarmaydi. Ammo shunga qaramay, alter stolda qulfni oladi* va barcha tanlovlar bajarilguncha kutish kerak. Va shundan keyingina o'zgartirish amalga oshiriladi, ya'ni hali ham ba'zi noqulayliklar mavjud.
* ClickHouse-ning so'nggi versiyalarida ALTER butunlay bloklanmaydi.
ClickHouse uchun juda noyob bo'lgan yana bir variant tashqi lug'atlarni ulashdir. ClickHouse-da raqamlarni yozishingiz va kataloglaringizni o'zingiz uchun qulay bo'lgan istalgan tizimda saqlashingiz mumkin. Masalan, siz foydalanishingiz mumkin: MySQL, Mongo, Postgres. Siz hatto ushbu ma'lumotlarni http orqali yuboradigan o'z mikroservisingizni yaratishingiz mumkin. Va ClickHouse darajasida siz ushbu ma'lumotlarni raqamlardan satrlarga aylantiradigan funktsiyani yozasiz.
Bu tashqi stolda birlashishni amalga oshirishning ixtisoslashgan, ammo juda samarali usuli. Va ikkita variant bor. Bitta versiyada ushbu ma'lumotlar to'liq keshlanadi, operativ xotirada to'liq mavjud va ma'lum chastotalar bilan yangilanadi. Va boshqa variantda, agar bu ma'lumotlar RAMga mos kelmasa, uni qisman keshlash mumkin.
Mana bir misol. Yandex.Direct mavjud. Va reklama kompaniyasi va bannerlar mavjud. Ehtimol, o'n millionlab reklama kompaniyalari mavjud. Va ular taxminan RAMga mos keladi. Va milliardlab bannerlar mavjud, ular mos kelmaydi. Va biz MySQL-dan keshlangan lug'atdan foydalanamiz.
Bitta muammo shundaki, agar urish tezligi 100% ga yaqin bo'lsa, keshlangan lug'at yaxshi ishlaydi. Agar u kichikroq bo'lsa, har bir ma'lumot to'plami uchun so'rovlarni qayta ishlashda siz etishmayotgan kalitlarni olishingiz va MySQL-dan ma'lumotlarni olishingiz kerak bo'ladi. ClickHouse haqida men hali ham kafolat bera olaman - ha, u sekinlashmaydi, men boshqa tizimlar haqida gapirmayman.
Bonus sifatida lug'atlar ClickHouse-da ma'lumotlarni qayta tiklashning juda oson usuli hisoblanadi. Ya'ni, sizda reklama kompaniyalari haqida hisobot bor edi, foydalanuvchi shunchaki reklama kompaniyasini o'zgartirdi va barcha eski ma'lumotlarda, barcha hisobotlarda bu ma'lumotlar ham o'zgardi. Agar siz to'g'ridan-to'g'ri jadvalga satrlarni yozsangiz, ularni yangilab bo'lmaydi.
Satrlaringiz uchun identifikatorlarni qayerdan olishni bilmasangiz, boshqa usul. siz shunchaki hash qilishingiz mumkin. Bundan tashqari, eng oddiy variant 64 bitli xeshni olishdir.
Bitta muammo shundaki, agar xesh 64-bit bo'lsa, sizda deyarli to'qnashuvlar bo'ladi. Chunki u erda bir milliard satr bo'lsa, ehtimollik allaqachon sezilarli bo'ladi.
Va bu tarzda reklama kompaniyalari nomlarini xeshlash unchalik yaxshi bo'lmaydi. Agar turli kompaniyalarning reklama kampaniyalari aralashib ketgan bo'lsa, unda tushunarsiz narsa bo'ladi.
Va oddiy hiyla bor. To'g'ri, bu jiddiy ma'lumotlar uchun juda mos emas, lekin agar biror narsa juda jiddiy bo'lmasa, mijoz identifikatorini lug'at kalitiga qo'shing. Va keyin sizda to'qnashuvlar bo'ladi, lekin faqat bitta mijoz ichida. Va biz bu usulni Yandex.Metrica-dagi havola xaritalari uchun ishlatamiz. Bizda URL manzillar bor, biz xeshlarni saqlaymiz. Va biz bilamizki, albatta, to'qnashuvlar mavjud. Ammo sahifa ko'rsatilganda, bitta foydalanuvchining bir sahifasida ba'zi URL-lar bir-biriga yopishib qolganligi va buni sezish ehtimoli e'tibordan chetda qolishi mumkin.
Bonus sifatida, ko'pgina operatsiyalar uchun faqat xeshlar etarli va satrlarning o'zi hech qanday joyda saqlanishi shart emas.
Yana bir misol, agar satrlar qisqa bo'lsa, masalan, veb-sayt domenlari. Ular xuddi shunday saqlanishi mumkin. Yoki, masalan, ru brauzer tili 2 bayt. Albatta, men baytlarga achinaman, lekin tashvishlanmang, 2 bayt achinarli emas. Iltimos, uni avvalgidek saqlang, xavotir olmang.
Yana bir holat, aksincha, juda ko'p chiziqlar mavjud va ularda juda ko'p noyoblar mavjud va hatto to'plam potentsial cheksizdir. Oddiy misol - qidiruv iboralari yoki URL manzillari. Qidiruv iboralari, jumladan, matn terish xatolari. Keling, kuniga qancha noyob qidiruv iboralari mavjudligini ko'rib chiqaylik. Va ular barcha voqealarning deyarli yarmi ekanligi ma'lum bo'ldi. Va bu holatda, siz ma'lumotlarni normallashtirishingiz, identifikatorlarni hisoblashingiz va uni alohida jadvalga qo'yishingiz kerak deb o'ylashingiz mumkin. Lekin buni qilish kerak emas. Shu qatorlarni xuddi shunday saqlang.
Hech narsa ixtiro qilmaslik yaxshiroqdir, chunki uni alohida saqlasangiz, siz birlashma qilishingiz kerak bo'ladi. Va bu qo'shilish, eng yaxshi holatda, xotiraga tasodifiy kirish, agar u hali ham xotiraga mos tushsa. Agar u mos kelmasa, unda muammolar bo'ladi.
Va agar ma'lumotlar joyida saqlangan bo'lsa, u holda fayl tizimidan kerakli tartibda o'qiladi va hamma narsa yaxshi.
Agar sizda URL-manzillar yoki boshqa murakkab uzun satrlar bo'lsa, unda siz qandaydir ekstraktni oldindan hisoblashingiz va uni alohida ustunga yozishingiz mumkinligini hisobga olishingiz kerak.
Masalan, URL manzillari uchun domenni alohida saqlashingiz mumkin. Va agar sizga haqiqatan ham domen kerak bo'lsa, shunchaki ushbu ustundan foydalaning va URL manzillar u erda yotadi va siz ularga tegmaysiz.
Keling, qanday farq borligini ko'rib chiqaylik. ClickHouse domenni hisoblaydigan maxsus funksiyaga ega. Bu juda tez, biz uni optimallashtirdik. Rostini aytsam, u hatto RFCga ham mos kelmaydi, lekin shunga qaramay, u bizga kerak bo'lgan hamma narsani hisobga oladi.
Va bir holatda biz shunchaki URL manzillarini olamiz va domenni hisoblaymiz. Bu 166 millisekundgacha ishlaydi. Va agar siz tayyor domenni olsangiz, u atigi 67 millisekundga aylanadi, ya'ni deyarli uch baravar tezroq. Va bu biz ba'zi hisob-kitoblarni amalga oshirishimiz kerakligi sababli emas, balki kamroq ma'lumotlarni o'qiganimiz uchun tezroq.
Shuning uchun sekinroq bo'lgan bitta so'rov soniyasiga gigabayt tezligi yuqori. Chunki u ko'proq gigabayt o'qiydi. Bu mutlaqo keraksiz ma'lumotlar. So‘rov tezroq bajarilayotganga o‘xshaydi, lekin bajarish uchun ko‘proq vaqt ketadi.
Va agar siz diskdagi ma'lumotlar miqdoriga qarasangiz, URL manzili 126 megabayt, domen esa atigi 5 megabayt ekanligi ma'lum bo'ladi. Bu 25 barobar kamroq bo'lib chiqadi. Ammo shunga qaramay, so'rov atigi 4 baravar tezroq bajariladi. Lekin bu ma'lumotlarning issiq bo'lgani uchun. Va agar sovuq bo'lsa, u diskni kiritish-chiqarish tufayli 25 barobar tezroq bo'lar edi.
Aytgancha, agar siz domen URL manzilidan qanchalik kichikligini hisoblasangiz, u taxminan 4 barobar kichikroq bo'lib chiqadi.Lekin negadir ma'lumotlar diskda 25 marta kamroq joy oladi. Nega? Siqish tufayli. Va URL siqilgan va domen siqilgan. Lekin ko'pincha URL ko'p axlatni o'z ichiga oladi.
Va, albatta, kerakli qiymatlar uchun maxsus ishlab chiqilgan yoki mos keladigan to'g'ri ma'lumotlar turlaridan foydalanish to'lanadi. Agar siz IPv4 da bo'lsangiz, UInt32 * ni saqlang. Agar IPv6 bo'lsa, u holda FixedString(16), chunki IPv6 manzili 128 bit, ya'ni to'g'ridan-to'g'ri ikkilik formatda saqlanadi.
Lekin sizda ba'zan IPv4 manzillari va ba'zan IPv6 bo'lsa-chi? Ha, ikkalasini ham saqlashingiz mumkin. IPv4 uchun bitta ustun, IPv6 uchun boshqa. Albatta, IPv4-da IPv6-ni ko'rsatish imkoniyati mavjud. Bu ham ishlaydi, lekin agar sizga tez-tez so'rovlarda IPv4 manzili kerak bo'lsa, uni alohida ustunga qo'yish yaxshi bo'lar edi.
* ClickHouse endi alohida IPv4, IPv6 ma'lumotlar turlariga ega bo'lib, ular ma'lumotlarni raqamlar kabi samarali saqlaydi, lekin ularni satrlar kabi qulay tarzda ifodalaydi.
Shuni ham ta'kidlash kerakki, ma'lumotlarni oldindan qayta ishlashga arziydi. Misol uchun, siz ba'zi xom jurnallarni olasiz. Va, ehtimol, siz ularni darhol ClickHouse-ga qo'ymasligingiz kerak, garchi bu hech narsa qilmaslik juda jozibali va hamma narsa ishlaydi. Ammo baribir mumkin bo'lgan hisob-kitoblarni bajarishga arziydi.
Masalan, brauzer versiyasi. Men barmog'imni ko'rsatmoqchi bo'lmagan yaqin atrofdagi bo'limda brauzer versiyasi shunday saqlanadi, ya'ni satr sifatida: 12.3. Va keyin hisobot tuzish uchun ular ushbu satrni olib, uni massivga, keyin esa massivning birinchi elementiga bo'lishadi. Tabiiyki, hamma narsa sekinlashadi. Men nima uchun bunday qilishlarini so'radim. Ular menga muddatidan oldin optimallashtirishni yoqtirmasliklarini aytishdi. Va men erta pessimizatsiyani yoqtirmayman.
Shunday qilib, bu holda 4 ta ustunga bo'linish to'g'riroq bo'ladi. Bu erda qo'rqmang, chunki bu ClickHouse. ClickHouse - bu ustunli ma'lumotlar bazasi. Va qanchalik chiroyli kichik ustunlar bo'lsa, shuncha yaxshi. 5 ta brauzer versiyasi bo'ladi, 5 ta ustun hosil qiling. Bu odatiy.
Endi sizda juda uzun satrlar, juda uzun massivlar bo'lsa, nima qilish kerakligini ko'rib chiqamiz. Ular ClickHouse-da umuman saqlanishi shart emas. Buning o'rniga identifikatorni faqat ClickHouse-da saqlashingiz mumkin. Va bu uzun chiziqlarni boshqa tizimga qo'ying.
Misol uchun, bizning tahlil xizmatlarimizdan birida hodisa parametrlari mavjud. Va agar voqealar uchun ko'p parametrlar bo'lsa, biz shunchaki birinchi kelgan 512 ni saqlab qolamiz, chunki 512 afsuslanmaydi.
Va agar siz ma'lumotlar turlari haqida qaror qabul qila olmasangiz, u holda ma'lumotlarni ClickHouse-da ham yozib olishingiz mumkin, lekin vaqtinchalik ma'lumotlar uchun maxsus jurnal turidagi vaqtinchalik jadvalda. Shundan so'ng, siz u erda qanday qadriyatlar taqsimoti borligini, umuman nima borligini tahlil qilishingiz va to'g'ri turlarni yaratishingiz mumkin.
*ClickHouse endi ma'lumotlar turiga ega bu sizga kamroq harakat bilan torlarni samarali saqlash imkonini beradi.
Endi yana bir qiziqarli ishni ko'rib chiqamiz. Ba'zida narsalar odamlar uchun g'alati ishlaydi. Men kirib, buni ko'raman. Va darhol buni MySQL 3.23 versiyasini o'rnatishda katta tajribaga ega bo'lgan juda tajribali, aqlli administrator amalga oshirganga o'xshaydi.
Bu erda biz mingta jadvalni ko'ramiz, ularning har biri kim nimani mingga bo'lishning qolgan qismini yozadi.
Asosan, men boshqa odamlarning tajribasini, shu jumladan, ushbu tajriba orqali erishish mumkin bo'lgan azob-uqubatlarni tushunishni hurmat qilaman.
Va sabablari ko'proq yoki kamroq aniq. Bu boshqa tizimlar bilan ishlashda to'plangan bo'lishi mumkin bo'lgan eski stereotiplar. Masalan, MyISAM jadvallarida klasterli asosiy kalit mavjud emas. Va ma'lumotlarni bo'lishning bu usuli bir xil funktsiyani olish uchun umidsiz urinish bo'lishi mumkin.
Yana bir sabab shundaki, katta jadvallarda har qanday o'zgartirish operatsiyalarini bajarish qiyin. Hammasi bloklanadi. MySQL-ning zamonaviy versiyalarida bu muammo endi unchalik jiddiy emas.
Yoki, masalan, microsharding, lekin bu haqda keyinroq.
ClickHouse-da buni qilishning hojati yo'q, chunki birinchidan, asosiy kalit klasterlangan, ma'lumotlar asosiy kalit bo'yicha tartiblangan.
Va ba'zida odamlar mendan so'rashadi: "ClickHouse-dagi diapazon so'rovlarining ishlashi jadval o'lchamiga qarab qanday o'zgaradi?" Men aytamanki, u umuman o'zgarmaydi. Misol uchun, sizda milliard qatorli jadval mavjud va siz bir million qatorni o'qiysiz. Hammasi yaxshi. Agar jadvalda trillion qator bo'lsa va siz bir million qatorni o'qisangiz, u deyarli bir xil bo'ladi.
Va, ikkinchidan, qo'lda bo'limlar kabi barcha turdagi narsalar talab qilinmaydi. Agar siz kirsangiz va fayl tizimida nima borligini ko'rsangiz, jadval juda katta shartnoma ekanligini ko'rasiz. Va ichida bo'limlarga o'xshash narsa bor. Ya'ni, ClickHouse siz uchun hamma narsani qiladi va siz azob chekishingiz shart emas.
Agar ustun qo'shish/qo'yish bo'lsa, ClickHouse-da o'zgartirish bepul.
Va siz kichik jadvallar tuzmasligingiz kerak, chunki agar jadvalda 10 qator yoki 10 000 qator bo'lsa, unda bu hech qanday ahamiyatga ega emas. ClickHouse - kechikish emas, balki o'tkazish qobiliyatini optimallashtiradigan tizim, shuning uchun 10 qatorni qayta ishlash mantiqiy emas.
Bitta katta stoldan foydalanish to'g'ri. Eski stereotiplardan xalos bo'ling, hamma narsa yaxshi bo'ladi.
Va bonus sifatida, so'nggi versiyada biz endi alohida bo'limlarda barcha turdagi texnik operatsiyalarni bajarish uchun o'zboshimchalik bilan bo'linish kalitini yaratish imkoniyatiga egamiz.
Masalan, sizga ko'plab kichik jadvallar kerak bo'ladi, masalan, ba'zi oraliq ma'lumotlarni qayta ishlash zarurati tug'ilganda, siz bo'laklarni olasiz va yakuniy jadvalga yozishdan oldin ularni o'zgartirishni amalga oshirishingiz kerak. Bu holda, ajoyib stol dvigateli - StripeLog mavjud. Bu TinyLogga o'xshaydi, faqat yaxshiroq.
* Endi ClickHouse-da ham bor .
Yana bir antipattern - bu microsharding. Misol uchun, siz ma'lumotlarni parchalashingiz kerak va sizda 5 ta server bor, ertaga esa 6 ta server bo'ladi. Va siz bu ma'lumotlarni qanday qilib qayta muvozanatlash haqida o'ylaysiz. Va buning o'rniga siz 5 ta bo'lakka emas, balki 1 ta bo'lakka bo'lasiz. Va keyin siz ushbu microshardlarning har birini alohida serverga moslashtirasiz. Va siz, masalan, bitta serverda 000 ClickHouse olasiz. Alohida portlarda yoki alohida ma'lumotlar bazalarida alohida misollar.
Lekin bu ClickHouse-da unchalik yaxshi emas. Chunki bitta ClickHouse misoli bitta so'rovni qayta ishlash uchun barcha mavjud server resurslaridan foydalanishga harakat qiladi. Ya'ni, sizda qandaydir server bor va u, masalan, 56 ta protsessor yadrosiga ega. Siz bajarish uchun bir soniya davom etadigan so'rovni bajaryapsiz va u 56 yadrodan foydalanadi. Va agar siz u erda bitta serverga 200 ta ClickHouse joylashtirsangiz, 10 000 ta mavzu boshlanadi. Umuman olganda, hamma narsa juda yomon bo'ladi.
Yana bir sabab shundaki, ushbu misollar bo'yicha ishlarni taqsimlash notekis bo'ladi. Ba'zilar erta tugaydi, ba'zilari keyinroq tugaydi. Agar bularning barchasi bitta holatda sodir bo'lgan bo'lsa, unda ClickHouse-ning o'zi ma'lumotlarni iplar orasida qanday qilib to'g'ri taqsimlashni aniqlaydi.
Va yana bir sabab shundaki, siz TCP orqali protsessorlararo aloqaga ega bo'lasiz. Ma'lumotlarni ketma-ketlashtirish, seriyadan chiqarish kerak bo'ladi va bu juda ko'p mikroshardlardir. Bu shunchaki samarali ishlamaydi.
Yana bir antipattern, garchi uni antipattern deb atash qiyin. Bu oldindan yig'ishning katta miqdori.
Umuman olganda, oldindan yig'ish yaxshi. Sizda milliard qator bor edi, siz uni jamladingiz va u 1 qatorga aylandi va endi so'rov bir zumda bajariladi. Hammasi ajoyib. Siz buni qila olasiz. Va buning uchun, hatto ClickHouse-da ham ma'lumotlar kiritilganda qo'shimcha yig'ishni amalga oshiradigan AggregatingMergeTree maxsus jadval turi mavjud.
Ammo shunday paytlar shunday ma’lumotlarni jamlaymiz va shunga o‘xshash ma’lumotlarni jamlaymiz, deb o‘ylaysiz. Va ba'zi qo'shni bo'limlarda men qaysi birini aytishni istamayman, ular asosiy kalit bo'yicha umumlashtirish uchun SummingMergeTree jadvallaridan foydalanadilar va 20 ga yaqin ustunlar asosiy kalit sifatida ishlatiladi. Har holda, men ba'zi ustunlarning nomlarini maxfiylik uchun o'zgartirdim, lekin bu juda ko'p.
Va bunday muammolar paydo bo'ladi. Birinchidan, ma'lumotlar hajmi juda kamaymaydi. Misol uchun, u uch barobar kamayadi. Agar sizning ma'lumotlaringiz yig'ilmagan bo'lsa, paydo bo'ladigan cheksiz tahlil imkoniyatlarini ta'minlash uchun uch marta yaxshi narx bo'ladi. Agar ma'lumotlar jamlangan bo'lsa, siz tahlil o'rniga faqat achinarli statistikani olasiz.
Va buning o'ziga xos xususiyati nimada? Gap shundaki, qo'shni bo'limdan bu odamlar ba'zan borib, asosiy kalitga boshqa ustun qo'shishni so'rashadi. Ya'ni, biz ma'lumotlarni shunday jamladik, lekin endi biz biroz ko'proq narsani xohlaymiz. Ammo ClickHouse-da asosiy kalit kaliti yo'q. Shuning uchun biz C++ da ba'zi skriptlarni yozishimiz kerak. Va men skriptlarni yoqtirmayman, hatto ular C++ da bo'lsa ham.
Va agar siz ClickHouse nima uchun yaratilganiga qarasangiz, unda yig'ilmagan ma'lumotlar aynan u tug'ilgan stsenariydir. Agar siz birlashtirilmagan ma'lumotlar uchun ClickHouse-dan foydalanayotgan bo'lsangiz, unda siz buni to'g'ri qilyapsiz. Agar jamlasangiz, bu ba'zan kechirilishi mumkin.
Yana bir qiziqarli holat - cheksiz tsikldagi so'rovlar. Ba'zan men ishlab chiqarish serveriga boraman va u erda ko'rsatuvlar ro'yxatiga qarayman. Va har safar dahshatli narsa sodir bo'layotganini bilaman.
Masalan, bu kabi. Hamma narsani bitta so'rovda bajarish mumkinligi darhol aniq bo'ladi. Shunchaki urlni va u yerdagi ro'yxatni yozing.
Nega cheksiz tsikldagi bunday so'rovlar yomon? Agar indeks ishlatilmasa, sizda bir xil ma'lumotlarga ko'p o'tishlar bo'ladi. Ammo agar indeks ishlatilsa, masalan, sizda ru uchun asosiy kalit bor va u erda url = biror narsa yozasiz. Va agar jadvaldan faqat bitta URL o'qilsa, hamma narsa yaxshi bo'ladi deb o'ylaysiz. Lekin aslida yo'q. Chunki ClickHouse hamma narsani paketlarda bajaradi.
U ma'lum bir qator ma'lumotlarni o'qishi kerak bo'lganda, u biroz ko'proq o'qiydi, chunki ClickHouse-dagi indeks siyrak. Ushbu indeks jadvalda bitta alohida qatorni topishga imkon bermaydi, faqat qandaydir diapazon. Va ma'lumotlar bloklarda siqiladi. Bitta qatorni o'qish uchun siz butun blokni olishingiz va uni ochishingiz kerak. Agar siz ko‘plab so‘rovlarni bajarayotgan bo‘lsangiz, sizda ko‘p o‘xshashliklar bo‘ladi va qayta-qayta bajarishingiz kerak bo‘lgan ish ko‘p bo‘ladi.
Bonus sifatida shuni ta'kidlashingiz mumkinki, ClickHouse-da siz hatto megabayt va hatto yuzlab megabaytlarni IN bo'limiga o'tkazishdan qo'rqmasligingiz kerak. Amaliyotimizdan eslaymanki, agar MySQL-da biz IN bo'limiga bir qancha qiymatlarni o'tkazsak, masalan, u erda ba'zi raqamlarning 100 megabaytini o'tkazsak, MySQL 10 gigabayt xotirani egallaydi va unga boshqa hech narsa bo'lmaydi, hamma narsa yomon ishlaydi.
Va ikkinchisi, ClickHouse-da, agar sizning so'rovlaringiz indeksdan foydalansa, u har doim to'liq skanerlashdan sekin emas, ya'ni deyarli butun jadvalni o'qish kerak bo'lsa, u ketma-ket ketadi va butun jadvalni o'qiydi. Umuman olganda, u buni o'zi hal qiladi.
Ammo shunga qaramay, ba'zi qiyinchiliklar mavjud. Masalan, pastki so'rovli IN indeksdan foydalanmasligi. Ammo bu bizning muammomiz va biz uni tuzatishimiz kerak. Bu erda asosiy narsa yo'q. Biz tuzatamiz*.
Va yana bir qiziq jihat shundaki, agar sizda juda uzoq so'rov bo'lsa va taqsimlangan so'rovni qayta ishlash davom etayotgan bo'lsa, bu juda uzoq so'rov har bir serverga siqilmasdan yuboriladi. Masalan, 100 megabayt va 500 server. Va shunga ko'ra, siz tarmoq orqali uzatiladigan 50 gigabaytga ega bo'lasiz. U uzatiladi va keyin hamma narsa muvaffaqiyatli yakunlanadi.
* allaqachon foydalanmoqda; Hammasi va'da qilinganidek tuzatildi.
So'rovlar API'dan kelganida juda keng tarqalgan holat. Masalan, siz o'zingizning xizmat turini yaratdingiz. Va agar kimdir sizning xizmatingizga muhtoj bo'lsa, siz API-ni ochasiz va ikki kundan keyin tushunarsiz narsa yuz berayotganini ko'rasiz. Hamma narsa haddan tashqari yuklangan va hech qachon sodir bo'lmasligi kerak bo'lgan dahshatli so'rovlar keladi.
Va faqat bitta yechim bor. Agar siz API-ni ochgan bo'lsangiz, uni kesishingiz kerak bo'ladi. Misol uchun, qandaydir kvotalar kiriting. Boshqa oddiy variantlar yo'q. Aks holda, ular darhol skript yozadilar va muammolar paydo bo'ladi.
Va ClickHouse-ning o'ziga xos xususiyati bor - kvotani hisoblash. Bundan tashqari, siz kvota kalitini o'tkazishingiz mumkin. Bu, masalan, ichki foydalanuvchi identifikatori. Va ularning har biri uchun kvotalar mustaqil ravishda hisoblab chiqiladi.
Endi yana bir qiziq narsa. Bu qo'lda takrorlash.
Men ClickHouse-da o'rnatilgan replikatsiya yordamiga ega bo'lishiga qaramay, odamlar ClickHouse-ni qo'lda takrorlaydigan ko'plab holatlarni bilaman.
Prinsip nima? Sizda ma'lumotlarni qayta ishlash quvuri mavjud. Va u mustaqil ravishda ishlaydi, masalan, turli ma'lumotlar markazlarida. Xuddi shu ma'lumotlarni ClickHouse-da xuddi shu tarzda yozasiz. To'g'ri, amaliyot shuni ko'rsatadiki, sizning kodingizdagi ba'zi xususiyatlar tufayli ma'lumotlar hali ham farqlanadi. Umid qilamanki, bu siznikidir.
Va vaqti-vaqti bilan siz hali ham qo'lda sinxronlashtirishingiz kerak bo'ladi. Masalan, har oyda bir marta adminlar rsync qiladi.
Aslida, ClickHouse-ga o'rnatilgan replikatsiyadan foydalanish ancha oson. Ammo ba'zi kontrendikatsiyalar bo'lishi mumkin, chunki buning uchun siz ZooKeeper-dan foydalanishingiz kerak. ZooKeeper haqida yomon narsa demayman, printsipial ravishda tizim ishlaydi, lekin odamlar java-fobiya tufayli undan foydalanmaydilar, chunki ClickHouse juda yaxshi tizim bo'lib, C++ tilida yozilgan, siz undan foydalanishingiz mumkin. Hammasi yaxshi bo'ladi . ZooKeeper esa javada. Va qandaydir tarzda siz hatto qarashni xohlamaysiz, lekin keyin qo'lda replikatsiyadan foydalanishingiz mumkin.
ClickHouse amaliy tizimdir. U sizning ehtiyojlaringizni hisobga oladi. Agar sizda qo'lda replikatsiya bo'lsa, siz qo'lda nusxalaringizni ko'rib chiqadigan va ular o'rtasida o'zgartirishni amalga oshiradigan Taqsimlangan jadvalni yaratishingiz mumkin. Va hatto sizning chiziqlaringiz muntazam ravishda ajralib tursa ham, floplardan qochishga imkon beradigan maxsus variant mavjud.
Agar siz ibtidoiy jadval dvigatellaridan foydalansangiz, boshqa muammolar paydo bo'lishi mumkin. ClickHouse - bu turli xil jadval dvigatellariga ega bo'lgan konstruktor. Hujjatlarda yozilganidek, barcha jiddiy holatlar uchun MergeTree oilasi jadvallaridan foydalaning. Va qolganlari - bu alohida holatlar yoki testlar uchun shunday.
MergeTree jadvalida sizda hech qanday sana va vaqt bo'lishi shart emas. Siz hali ham undan foydalanishingiz mumkin. Agar sana va vaqt bo'lmasa, standart 2000 ekanligini yozing. Bu ishlaydi va resurslarni talab qilmaydi.
Va serverning yangi versiyasida siz hatto bo'lim kalitisiz maxsus bo'limga ega ekanligingizni ham belgilashingiz mumkin. Xuddi shunday bo'ladi.
Boshqa tomondan, siz ibtidoiy stol dvigatellaridan foydalanishingiz mumkin. Misol uchun, ma'lumotlarni bir marta to'ldiring va qarang, burish va o'chirish. Log-dan foydalanishingiz mumkin.
Yoki oraliq ishlov berish uchun kichik hajmlarni saqlash StripeLog yoki TinyLog hisoblanadi.
Agar ma'lumotlar hajmi kichik bo'lsa va siz RAMda biron bir narsani o'zgartirishingiz mumkin bo'lsa, xotiradan foydalanish mumkin.
ClickHouse qayta normallashtirilgan ma'lumotlarni yoqtirmaydi.
Oddiy misol. Bu juda ko'p sonli URL manzillari. Siz ularni keyingi jadvalga qo'yasiz. Va keyin ular ular bilan JOIN qilishga qaror qilishdi, lekin bu, qoida tariqasida, ishlamaydi, chunki ClickHouse faqat Hash JOIN-ni qo'llab-quvvatlaydi. Agar ulanishi kerak bo'lgan juda ko'p ma'lumotlar uchun RAM etarli bo'lmasa, JOIN ishlamaydi*.
Agar ma'lumotlar yuqori darajadagi bo'lsa, tashvishlanmang, uni denormalizatsiyalangan shaklda saqlang, URL manzillari to'g'ridan-to'g'ri asosiy jadvalda joylashgan.
* va endi ClickHouse-da birlashma mavjud va u oraliq ma'lumotlar RAMga mos kelmaydigan sharoitlarda ishlaydi. Ammo bu samarasiz va tavsiya kuchda qoladi.
Yana bir nechta misollar, lekin ular naqshga qarshi yoki yo'qligiga shubha qilaman.
ClickHouse-da bitta ma'lum kamchilik bor. U qanday yangilashni bilmaydi*. Qaysidir ma'noda, bu hatto yaxshi. Agar sizda ba'zi muhim ma'lumotlar, masalan, buxgalteriya hisobi bo'lsa, unda hech kim uni yubora olmaydi, chunki yangilanishlar yo'q.
* ommaviy rejimda yangilash va o'chirishni qo'llab-quvvatlash uzoq vaqt oldin qo'shilgan.
Ammo yangilanishlarga fonda bo'lgani kabi ruxsat beruvchi ba'zi maxsus usullar mavjud. Masalan, ReplaceMergeTree kabi jadvallar. Ular fonni birlashtirish paytida yangilanishlarni amalga oshiradilar. Buni optimallashtirish jadvali yordamida majburlashingiz mumkin. Lekin buni tez-tez qilmang, chunki u bo'limni butunlay qayta yozadi.
ClickHouse-dagi taqsimlangan JOINlar ham so'rovlarni rejalashtiruvchi tomonidan yomon ishlanadi.
Yomon, lekin ba'zida yaxshi.
Select* yordamida ma'lumotlarni qayta o'qish uchun faqat ClickHouse-dan foydalaning.
Qiyin hisoblar uchun ClickHouse-dan foydalanishni tavsiya etmayman. Ammo bu mutlaqo to'g'ri emas, chunki biz allaqachon bu tavsiyadan uzoqlashyapmiz. Va yaqinda biz ClickHouse - Catboost-da mashinani o'rganish modellarini qo'llash qobiliyatini qo'shdik. Va bu meni bezovta qiladi, chunki men o'ylayman: “Qanday dahshat. Bitta baytda qancha tsikl chiqadi! Men soatlarni baytlarga sarflashni juda yomon ko'raman.
Lekin qo'rqmang, ClickHouse-ni o'rnating, hamma narsa yaxshi bo'ladi. Agar biror narsa bo'lsa, bizda jamiyat bor. Aytgancha, jamiyat sizsiz. Va agar sizda biron bir muammo bo'lsa, hech bo'lmaganda bizning chatimizga kirishingiz mumkin va umid qilamanki, ular sizga yordam berishadi.
Sizning savollaringiz
Hisobot uchun rahmat! ClickHouse ishdan chiqishi haqida qayerga shikoyat qilishim mumkin?
Siz hozir shaxsan menga shikoyat qilishingiz mumkin.
Men yaqinda ClickHouse-dan foydalanishni boshladim. Men darhol cli interfeysini tashladim.
Qanday ball.
Biroz vaqt o'tgach, men kichik tanlov bilan serverni buzdim.
Sizda iste'dod bor.
Men GitHub xatosini ochdim, lekin u e'tiborga olinmadi.
Biz ko'rib turamiz.
Aleksey meni aldab, hisobotga kirishim uchun ichkaridagi ma'lumotlarga qanday kirishingizni aytib berishni va'da qildi.
Juda oddiy.
Men buni kecha angladim. Batafsil maʼlumotlar.
U erda hech qanday dahshatli fokuslar yo'q. Faqat blok-blok siqish mavjud. Standart LZ4, siz ZSTD*ni yoqishingiz mumkin. 64 kilobaytdan 1 megabaytgacha bo'lgan bloklar.
* shuningdek, boshqa algoritmlar bilan zanjirda ishlatilishi mumkin bo'lgan maxsus siqish kodeklarini qo'llab-quvvatlash mavjud.
Bloklar shunchaki xom ma'lumotmi?
To'liq xom emas. Massivlar mavjud. Agar sizda raqamli ustun bo'lsa, u holda qatordagi raqamlar massivga joylashtiriladi.
Tushunarli.
Aleksey, IP-lar orqali uniqExact bilan bo'lgan misol, ya'ni uniqExact-ni raqamlardan ko'ra chiziqlar bo'yicha hisoblash ko'proq vaqt talab qilishi va hokazo. Agar biz korrektoriya vaqtida quloqlarimiz va gips bilan nayrang ishlatsak nima bo'ladi? Ya'ni, siz bizning diskimizda unchalik farq qilmasligini aytdingiz shekilli. Agar biz diskdan va castdan satrlarni o'qisak, agregatlarimiz tezroq bo'ladimi yoki yo'qmi? Yoki biz bu erda hali ham ozgina foyda olamizmi? Menimcha, siz buni sinab ko'rgansiz, lekin negadir uni benchmarkda ko'rsatmadingiz.
Menimcha, bu kastingsiz qaraganda sekinroq bo'ladi. Bunday holda, IP-manzil satrdan ajratilishi kerak. Albatta, ClickHouse-da bizning IP-manzilni tahlil qilish ham optimallashtirilgan. Biz juda ko'p harakat qildik, lekin u erda sizda o'n minginchi shaklda yozilgan raqamlar bor. Juda noqulay. Boshqa tomondan, uniqExact funksiyasi satrlarda sekinroq ishlaydi, chunki ular nafaqat satrlar, balki algoritmning boshqa ixtisoslashuvi tanlangani uchun ham. Stringlar oddiygina boshqacha tarzda qayta ishlanadi.
Agar biz oddiyroq ma'lumotlar turini olsak nima bo'ladi? Misol uchun, biz o'zimizda mavjud bo'lgan foydalanuvchi identifikatorini yozib oldik, uni satr qilib yozdik va keyin shifrladik, bu qiziqroq bo'ladimi yoki yo'qmi?
Bunday deb o'ylamayman. O'ylaymanki, bu yanada achinarli bo'ladi, chunki raqamlarni tahlil qilish jiddiy muammodir. Menimcha, bu hamkasb hatto o'n minginchi shaklda raqamlarni tahlil qilish qanchalik qiyinligi haqida hisobot bergan, lekin ehtimol yo'q.
Aleksey, hisobot uchun katta rahmat! ClickHouse uchun sizga katta rahmat! Rejalar haqida savolim bor. Lug'atlarni to'liq yangilash xususiyati uchun rejalar bormi?
Ya'ni, qisman qayta ishga tushirishmi?
Ha ha. U erda MySQL maydonini o'rnatish qobiliyati kabi, ya'ni lug'at juda katta bo'lsa, faqat ushbu ma'lumotlar yuklanishi uchun yangilang.
Juda qiziq xususiyat. Va menimcha, kimdir bizning suhbatimizda buni taklif qildi. Balki bu siz ham bo'lgandirsiz.
Men bunday deb o‘ylamayman.
Ajoyib, endi ikkita so'rov borligi ma'lum bo'ldi. Va asta-sekin buni boshlashingiz mumkin. Ammo men sizni darhol ogohlantirmoqchimanki, bu xususiyatni amalga oshirish juda oddiy. Ya'ni, nazariy jihatdan, siz shunchaki jadvalga versiya raqamini yozishingiz kerak va keyin yozishingiz kerak: bunday va shunga o'xshash versiyadan kamroq versiya. Bu shuni anglatadiki, biz buni ishqibozlarga taklif qilamiz. Siz ishqibozmisiz?
Ha, lekin, afsuski, C++ da emas.
Sizning hamkasblaringiz C++ da yozishni bilishadimi?
Men birovni topaman.
Ajoyib*.
* xususiyat hisobotdan ikki oy o'tgach qo'shildi - savol muallifi uni ishlab chiqdi va uni yubordi .
Rahmat!
Salom! Hisobot uchun rahmat! Siz ClickHouse o'zi uchun mavjud bo'lgan barcha resurslarni iste'mol qilishda juda yaxshi ekanligini ta'kidladingiz. Va Luxoftning yonidagi ma'ruzachi "Rossiya pochtasi" uchun o'zining yechimi haqida gapirdi. Uning so'zlariga ko'ra, ular ClickHouse-ni juda yaxshi ko'rishadi, lekin ular uni asosiy raqobatchisi o'rniga ishlatmaganlar, chunki u butun CPUni yeb qo'ygan. Va ular uni o'zlarining arxitekturasiga, dokerlar bilan ZooKeeper-ga ulay olmadilar. ClickHouse-ni unga mavjud bo'lgan hamma narsani iste'mol qilmasligi uchun qandaydir tarzda cheklash mumkinmi?
Ha, bu mumkin va juda oson. Agar siz kamroq yadrolarni iste'mol qilmoqchi bo'lsangiz, shunchaki yozing set max_threads = 1. Va bu so'rovni bitta yadroda bajaradi. Bundan tashqari, siz turli xil foydalanuvchilar uchun turli xil sozlamalarni belgilashingiz mumkin. Demak, muammo yo'q. Va Luxoft'dagi hamkasblaringizga aytingki, ular ushbu sozlamani hujjatlarda topa olmaganlari yaxshi emas.
Aleksey, salom! Men bu savol haqida so'ramoqchiman. Bu ko'p odamlar ClickHouse-dan jurnallar uchun saqlash sifatida foydalanishni boshlaganini birinchi marta eshitayotganim yo'q. Hisobotda siz buni qilmaslikni aytdingiz, ya'ni siz uzoq satrlarni saqlashingiz shart emas. Bu haqda qanday fikrdasiz?
Birinchidan, jurnallar, qoida tariqasida, uzun satrlar emas. Albatta, istisnolar mavjud. Misol uchun, java-da yozilgan ba'zi xizmatlar istisno qiladi, u qayd qilinadi. Va shunga o'xshash cheksiz tsiklda va qattiq diskdagi bo'sh joy tugaydi. Yechim juda oddiy. Agar chiziqlar juda uzun bo'lsa, ularni kesib tashlang. Uzoq nimani anglatadi? O'nlab kilobaytlar yomon*.
* ClickHouse-ning so'nggi versiyalarida "moslashuvchan indeksning granularligi" yoqilgan, bu ko'pincha uzun qatorlarni saqlash muammosini bartaraf etadi.
Kilobayt normalmi?
Yaxshi.
Salom! Hisobot uchun rahmat! Men bu haqda allaqachon suhbatda so'radim, lekin javob olganimni eslay olmayman. WITH bo'limini qandaydir tarzda CTE uslubida kengaytirish rejalari bormi?
Hali emas. BILAN bo'limimiz biroz beparvo. Bu biz uchun kichik xususiyatga o'xshaydi.
Tushundim. Rahmat!
Hisobot uchun rahmat! Juda qiziq! Global savol. Ma'lumotlarni o'chirishni o'zgartirish rejalari bormi, ehtimol qandaydir stublar ko'rinishida?
Majburiy. Bu bizning navbatdagi birinchi vazifamiz. Endi biz hamma narsani qanday qilib to'g'ri bajarish haqida faol o'ylaymiz. Va siz klaviaturani bosishni boshlashingiz kerak*.
* klaviaturadagi tugmalarni bosdi va hamma narsani qildi.
Bu qandaydir tarzda tizimning ishlashiga ta'sir qiladimi yoki yo'qmi? Kiritish hozirgidek tez bo'ladimi?
Ehtimol, o'chirishning o'zi va yangilanishlarning o'zi juda og'ir bo'ladi, ammo bu tanlanganlarning ishlashiga yoki qo'shimchalarning ishlashiga ta'sir qilmaydi.
Va yana bir kichik savol. Taqdimotda siz asosiy kalit haqida gapirdingiz. Shunga ko'ra, bizda sukut bo'yicha har oy bo'ladigan bo'linish mavjud, to'g'rimi? Va biz bir oyga to'g'ri keladigan sana oralig'ini o'rnatganimizda, faqat ushbu bo'lim o'qiladi, to'g'rimi?
Ha.
Savol. Agar biz biron bir asosiy kalitni tanlay olmasak, uni "Sana" maydoniga ko'ra bajarish to'g'rimi, fonda bu ma'lumotlar tartibliroq bo'lishi uchun kamroq qayta tartiblanadi? Agar sizda diapazon bo'yicha so'rovlar bo'lmasa va siz hatto biron bir asosiy kalitni tanlay olmasangiz, asosiy kalitga sana qo'yishga arziydimi?
Ha.
Ehtimol, birlamchi kalitga ushbu maydon bo'yicha tartiblangan bo'lsa, ma'lumotlarni yaxshiroq siqib chiqaradigan maydonni qo'yish mantiqiydir. Masalan, foydalanuvchi identifikatori. Masalan, foydalanuvchi xuddi shu saytga kiradi. Bunday holda, foydalanuvchi identifikatorini va vaqtini qo'ying. Va keyin ma'lumotlaringiz yaxshiroq siqiladi. Sana haqida gapiradigan bo'lsak, agar sizda sanalar bo'yicha so'rovlar bo'lmasa va hech qachon bo'lmasa, unda asosiy kalitga sanani qo'yish shart emas.
OK, katta rahmat!
Manba: www.habr.com