HighLoad++ Moskva 2018, Kongress-xoll. 9-noyabr, soat 15:00
Annotatsiya va taqdimot:
Yuriy Nasretdinov (VKontakte): hisobot kompaniyamizda ClickHouse-ni joriy etish tajribasi haqida gapiradi - bu bizga nima uchun kerak, biz qancha ma'lumot saqlaymiz, uni qanday yozamiz va hokazo.
Dopolnitelnye materiallar:
Юрий Насретдинов: - Hammaga salom! Mening ismim Yuriy Nasretdinov, chunki men allaqachon tanishganman. Men VKontakte da ishlayman. Men bizning server parkimizdan (o'n minglab) ClickHouse-ga ma'lumotlarni qanday kiritishimiz haqida gapiraman.
Jurnallar nima va nima uchun ularni yig'ish kerak?
Sizga nima deymiz: biz nima qildik, nima uchun bizga "ClickHouse" kerak edi, mos ravishda nima uchun biz uni tanladik, maxsus hech narsa sozlamasdan taxminan qanday ishlashni olishingiz mumkin. Men sizga bufer jadvallari, ular bilan bog'liq muammolar va ochiq manbalardan - KittenHouse va Lighthouse-dan ishlab chiqqan yechimlarimiz haqida batafsil aytib beraman.
Nima uchun biz umuman biror narsa qilishimiz kerak edi (VKontakte-da hamma narsa har doim yaxshi, to'g'rimi?). Biz disk raskadrovka jurnallarini to'plashni xohladik (va u erda yuzlab terabayt ma'lumotlar bor edi), ehtimol qandaydir tarzda statistikani hisoblash qulayroq bo'lar edi; va bizda bularning barchasi bajarilishi kerak bo'lgan o'n minglab serverlar parki bor.
Nega qaror qildik? Ehtimol, jurnallarni saqlash uchun bizda echimlar bor edi. Mana - bunday ommaviy "Backend VK" mavjud. Men unga obuna bo'lishni tavsiya qilaman.
Loglar nima? Bu bo'sh massivlarni qaytaradigan vosita. VK-dagi dvigatellarni boshqalar mikroservislar deb atashadi. Va mana jilmayuvchi stiker (juda ko'p yoqtirishlar). Qanaqasiga? Xo'sh, ko'proq tinglang!
Jurnallarni saqlash uchun nima ishlatilishi mumkin? Hadupni tilga olmaslik mumkin emas. Keyin, masalan, Rsyslog (bu jurnallarni fayllarda saqlash). LSD. LSD nima ekanligini kim biladi? Yo'q, bu LSD emas. Fayllarni ham mos ravishda saqlang. ClickHouse - bu g'alati variant.
Clickhouse va raqobatchilar: talablar va imkoniyatlar
Biz nimani xohlaymiz? Biz operatsiya haqida juda ko'p tashvishlanmasligimizni ta'minlashni xohlaymiz, shunda u qutidan tashqarida ishlaydi, yaxshisi minimal konfiguratsiya bilan. Biz ko'p yozishni va tez yozishni xohlaymiz. Va biz uni har xil oylar, yillar, ya'ni uzoq vaqt davomida saqlamoqchimiz. Biz ular bizga kelib, "Bu erda nimadir ishlamayapti" degan muammoni tushunishni xohlashimiz mumkin va bu 3 oy oldin edi) va biz 3 oy oldin nima bo'lganini ko'rishni xohlaymiz " Ma'lumotni siqish - bu nima uchun ortiqcha bo'lishi aniq - chunki u egallagan joyni kamaytiradi.
Va bizda shunday qiziqarli talab bor: biz ba'zan ba'zi buyruqlar (masalan, jurnallar) chiqishini yozamiz, u 4 kilobaytdan oshib ketishi mumkin. Va agar bu narsa UDP orqali ishlayotgan bo'lsa, unda uni sarflash kerak emas ... ulanish uchun hech qanday "qo'shimcha xarajatlar" bo'lmaydi va ko'p sonli serverlar uchun bu ortiqcha bo'ladi.
Keling, ochiq manba bizga nimani taklif qilishini ko'rib chiqaylik. Birinchidan, bizda Logs Engine bor - bu bizning dvigatelimiz; Printsipial jihatdan u hamma narsani qila oladi, hatto uzun satrlarni ham yoza oladi. Xo'sh, bu ma'lumotlarni shaffof tarzda siqmaydi - agar xohlasak, biz katta ustunlarni o'zimiz siqamiz ... biz, albatta, xohlamaymiz (agar iloji bo'lsa). Faqatgina muammo shundaki, u faqat xotirasiga mos keladigan narsani berishi mumkin; Qolganlarini o'qish uchun siz ushbu dvigatelning binlogini olishingiz kerak va shunga mos ravishda bu juda uzoq vaqt talab etadi.
Yana qanday variantlar bor? Masalan, "Hadup". Ishlash qulayligi... Kim Hadupni o'rnatish oson deb o'ylaydi? Albatta, yozib olishda hech qanday muammo yo'q. O'qish paytida ba'zida savollar tug'iladi. Printsipial jihatdan, men, ayniqsa, jurnallar uchun, ehtimol yo'q, deb aytaman. Uzoq muddatli saqlash - albatta, ha, ma'lumotlarni siqish - ha, uzoq satrlar - yozib olishingiz mumkinligi aniq. Lekin ko'p sonli serverlardan yozib olish ... Siz hali ham o'zingiz biror narsa qilishingiz kerak!
Rsyslog. Aslida, biz uni binlogni tashlamasdan o'qishimiz uchun zaxira varianti sifatida foydalanganmiz, lekin u uzoq satrlarni yoza olmaydi; printsipial jihatdan u 4 kilobaytdan ortiq yoza olmaydi. Xuddi shu tarzda ma'lumotlarni siqishni o'zingiz qilishingiz kerak. O'qish fayllardan keladi.
Keyin LSD ning "badushka" rivojlanishi mavjud. Aslida "Rsyslog" bilan bir xil: u uzun satrlarni qo'llab-quvvatlaydi, lekin u UDP orqali ishlay olmaydi va aslida shu sababli, afsuski, u erda juda ko'p narsalarni qayta yozish kerak. LSD o'n minglab serverlardan yozib olish uchun qayta ishlab chiqilishi kerak.
Va bu erda! Kulgili variant - ElasticSearch. Qanday aytish kerak? U o'qishni yaxshi o'qiydi, ya'ni tez o'qiydi, lekin yozishda unchalik yaxshi emas. Birinchidan, agar u ma'lumotlarni siqsa, u juda zaif. Katta ehtimol bilan, to'liq qidiruv asl hajmga qaraganda kattaroq ma'lumotlar tuzilmalarini talab qiladi. Operatsiya qilish qiyin va u bilan ko'pincha muammolar paydo bo'ladi. Va yana, Elastik-da yozish - biz hamma narsani o'zimiz qilishimiz kerak.
Bu erda ClickHouse ideal variant, albatta. Bitta narsa shundaki, o'n minglab serverlardan yozib olish muammodir. Lekin hech bo'lmaganda bitta muammo bor, uni qandaydir tarzda hal qilishga harakat qilishimiz mumkin. Va hisobotning qolgan qismi bu muammo haqida. ClickHouse-dan qanday ishlashni kutish mumkin?
Uni qanday kiritamiz? MergeTree
Кто из вас про «ClickHouse» не слышал, не знает? Нужно рассказать, не нужно? Очень быстро. Вставка там – 1-2 гигабита в секунду, всплесками до 10 гигабит в секунду на самом деле может выдерживать на вот такой конфигурации – там два 6-ядерных «Ксеона» (то есть даже не самые мощные), 256 гигов оперативы, 20 терабайтов в RAID (никто не настраивал, дефолтные настройки). Алексей Миловидов, разработчик ClickHouse, наверное, плачет сидит, что мы ничего не настраивали (у нас всё работало так). Соответственно, скорость сканирования, допустим, порядка 6 миллиардов строк в секунду можно получить, если данные хорошо сжимаются. Если вы like % по текстовой строке делаете – 100 миллионов строк в секунду, то есть кажется, что весьма быстро.
Uni qanday kiritamiz? Bilasizmi, VK PHP dan foydalanadi. Biz har bir PHP ishchisidan HTTP orqali “ClickHouse”ga, har bir yozuv uchun MergeTree jadvaliga kiritamiz. Ushbu sxema bilan kim muammoni ko'radi? Negadir hamma ham qo‘l ko‘tarmasdi. Sizga aytaman.
Birinchidan, juda ko'p serverlar mavjud - shunga ko'ra, juda ko'p ulanishlar bo'ladi (yomon). Keyin MergeTree-ga sekundiga bir martadan ko'p bo'lmagan ma'lumotlarni kiritish yaxshiroqdir. Va nima uchun kim biladi? Mayli, mayli. Men sizga bu haqda bir oz ko'proq gapirib beraman. Yana bir qiziq savol shundaki, biz tahlil qilmayapmiz, ma'lumotlarni boyitishimiz shart emas, bizga oraliq serverlar kerak emas, biz to'g'ridan-to'g'ri "ClickHouse" ga kiritmoqchimiz (afzalroq - qanchalik to'g'ridan-to'g'ri bo'lsa, shuncha yaxshi).
Shunga ko'ra, MergeTree-ga kiritish qanday amalga oshiriladi? Nega uni bir soniyada bir martadan ko'proq yoki kamroq kiritish yaxshiroq? Gap shundaki, "ClickHouse" ustunli ma'lumotlar bazasi bo'lib, ma'lumotlarni asosiy kalitning o'sish tartibida saralaydi va siz qo'shsangiz, hech bo'lmaganda ma'lumotlar saralangan ustunlar soniga teng bo'lgan bir qator fayllar yaratiladi. asosiy kalitning o'sish tartibida (alohida katalog yaratiladi, har bir qo'shimcha uchun diskdagi fayllar to'plami). Keyin keyingi kiritish keladi va fonda ular kattaroq "bo'limlarga" birlashtiriladi. Ma'lumotlar saralanganligi sababli, ko'p xotira sarflamasdan ikkita tartiblangan faylni "birlashtirish" mumkin.
Ammo, siz taxmin qilganingizdek, agar siz har bir qo'shimcha uchun 10 ta fayl yozsangiz, ClickHouse (yoki serveringiz) tezda tugaydi, shuning uchun katta partiyalarda kiritish tavsiya etiladi. Shunga ko'ra, biz hech qachon birinchi sxemani ishlab chiqarishga kiritmaganmiz. Biz darhol birini ishga tushirdik, bu erda № 2:
Tasavvur qiling-a, biz ishga tushirgan mingga yaqin serverlar bor, faqat PHP mavjud. Va har bir serverda bizning mahalliy agentimiz mavjud bo'lib, biz uni "Kittenhouse" deb ataymiz, u "ClickHouse" bilan bitta ulanishni ta'minlaydi va har bir necha soniyada ma'lumotlarni kiritadi. Ma'lumotlarni MergeTree-ga emas, balki MergeTree-ga to'g'ridan-to'g'ri kiritishni oldini olish uchun aniq xizmat qiladigan bufer jadvaliga kiritadi.
Bufer jadvallar bilan ishlash
Bu nima? Bufer jadvallari parchalangan xotira qismidir (ya'ni, uni tez-tez kiritish mumkin). Ular bir nechta bo'laklardan iborat bo'lib, qismlarning har biri mustaqil bufer sifatida ishlaydi va ular mustaqil ravishda yuviladi (agar buferda ko'plab bo'laklar bo'lsa, u holda soniyada ko'p qo'shimchalar bo'ladi). Ushbu jadvallardan o'qish mumkin - keyin siz bufer va ota-jadval tarkibining birlashuvini o'qiysiz, ammo hozirda yozish bloklangan, shuning uchun u erdan o'qimagan ma'qul. Va bufer jadvallari juda yaxshi QPS-ni ko'rsatadi, ya'ni 3 ming QPSgacha siz kiritishda hech qanday muammoga duch kelmaysiz. Agar server quvvatni yo'qotsa, u holda ma'lumotlar yo'qolishi mumkinligi aniq, chunki u faqat xotirada saqlangan.
При этом схему с буфером усложняет ALTER, потому что вам нужно сначала дропнуть старую буферную таблицу со старой схемой (данные никуда не пропадут при этом, потому что они зафлашатся перед тем, как таблица удалится). Потом вы «альтерите» нужную вам таблицу и создаёте буферную таблицу заново. Соответственно, пока нет буферной таблицы, у вас данные никуда не льются, но вы можете их на диске хотя бы локально.
Kittenhouse nima va u qanday ishlaydi?
KittenHouse nima? Bu proksi-server. Tasavvur qiling, qaysi til? Men hisobotimda eng shov-shuvli mavzularni to'pladim - "Clickhouse", Go, ehtimol yana bir narsani eslayman. Ha, bu Go-da yozilgan, chunki men C-da qanday yozishni bilmayman, xohlamayman.
Shunga ko'ra, u har bir server bilan aloqani saqlab turadi va xotiraga yozishi mumkin. Misol uchun, agar biz Clickhouse-ga xato jurnallarini yozsak, agar Clickhouse-da ma'lumotlarni kiritish uchun vaqt bo'lmasa (agar juda ko'p yozilgan bo'lsa), biz xotirani shishirmaymiz - qolganlarini tashlaymiz. Chunki biz soniyasiga bir necha gigabit xatoliklarni yozsak, ba'zilarini chiqarib tashlashimiz mumkin. Kittenhouse buni qila oladi. Bundan tashqari, u ishonchli etkazib berishni amalga oshirishi mumkin, ya'ni mahalliy kompyuterda diskka yozish va har safar (u erda, har ikki soniyada bir marta) ushbu fayldan ma'lumotlarni etkazib berishga harakat qiladi. Va dastlab biz oddiy Values formatidan foydalandik - qandaydir ikkilik format emas, matn formati (oddiy SQLda bo'lgani kabi).
Ammo keyin bu sodir bo'ldi. Biz ishonchli yetkazib berishdan foydalandik, jurnallar yozdik, keyin qaror qildik (bu shartli sinov klasteri edi)... U bir necha soat davomida o‘chirildi va qayta tiklandi va minglab serverlardan kiritish boshlandi – ma’lum bo‘lishicha, Clickhouse hanuzgacha "Ulanishdagi mavzu" - shunga ko'ra, mingta ulanishda faol kiritish serverda o'rtacha bir yarim ming yuklanishga olib keladi. Ajablanarlisi shundaki, server so'rovlarni qabul qildi, ammo ma'lumotlar bir muncha vaqt o'tgach ham kiritildi; lekin serverga unga xizmat qilish juda qiyin edi...
nginx qo'shing
Har bir ulanish modeli uchun Thread uchun bunday yechim nginx hisoblanadi. Biz Clickhouse oldida nginx-ni o'rnatdik, bir vaqtning o'zida ikkita replika uchun muvozanatni o'rnatdik (qo'shish tezligimiz 2 baravar oshdi, garchi bu shunday bo'lishi kerakligi haqiqat emas) va Clickhouse-ga ulanishlar sonini cheklab qo'ydik. yuqori oqim va shunga mos ravishda ko'proq , 50 ta ulanishdan ko'ra, kiritishning ma'nosi yo'qdek tuyuladi.
Keyin biz ushbu sxemaning odatda kamchiliklari borligini tushundik, chunki bizda faqat bitta nginx bor. Shunga ko'ra, agar bu nginx ishlamay qolsa, nusxalar mavjudligiga qaramay, biz ma'lumotlarni yo'qotamiz yoki hech bo'lmaganda hech qanday joyga yozmaymiz. Shuning uchun biz yuk balansini o'zimiz yaratdik. Shuningdek, biz "Clickhouse" hali ham jurnallar uchun mos ekanligini angladik va "jin" ham o'z jurnallarini "Clickhouse" da yozishni boshladi - rostini aytsam, juda qulay. Biz hali ham uni boshqa "jinlar" uchun ishlatamiz.
Keyin biz ushbu qiziqarli muammoni topdik: agar siz SQL rejimiga kiritishning nostandart usulidan foydalansangiz, u AST-ga asoslangan to'liq huquqli SQL tahlilchisini majbur qiladi, bu juda sekin. Shunga ko'ra, biz bu hech qachon sodir bo'lmasligini ta'minlash uchun sozlamalarni qo'shdik. Biz yuklarni muvozanatlash, sog'lig'ini tekshirishni amalga oshirdik, shunda kimdir vafot etsa, biz hali ham ma'lumotlarni qoldiramiz. Endi bizda juda ko'p jadvallar mavjud bo'lib, ular turli xil Clickhouse klasterlariga ega bo'lishimiz kerak. Shuningdek, biz boshqa foydalanish haqida o'ylay boshladik - masalan, biz nginx modullaridan jurnallar yozmoqchi edik, lekin ular bizning RPC-dan qanday foydalanishni bilishmaydi. Xo'sh, men ularga hech bo'lmaganda qandaydir tarzda yuborishni o'rgatmoqchiman - masalan, UDP orqali localhost-da voqealarni qabul qilish va keyin ularni Clickhouse-ga yuborish.
Yechimdan bir qadam uzoqda
Yakuniy sxema quyidagicha ko'rinishni boshladi (ushbu sxemaning to'rtinchi versiyasi): Clickhouse oldidagi har bir serverda nginx (xuddi shu serverda) mavjud va u 50 ta ulanishlar soniga cheklov bilan localhost so'rovlarini proksi yuboradi. dona. Va bu sxema allaqachon ishlayotgan edi, u bilan hamma narsa juda yaxshi edi.
Taxminan bir oy shunday yashadik. Hamma xursand bo'ldi, jadval qo'shdi, qo'shdi, qo'shdi... Umuman olganda, bufer jadvallarini qo'shish usuli unchalik maqbul emasligi ma'lum bo'ldi (bunday qilib qo'yaylik). Biz har bir stolda 16 ta bo'lak qildik va bir necha soniya chaqnash oralig'i; bizda 20 ta jadval bor edi va har bir jadval sekundiga 8 ta qo'shimchani oldi - va bu vaqtda "Clickhouse" boshlandi ... yozuvlar sekinlasha boshladi. Ular hatto o'tishmadi ... Nginx sukut bo'yicha shunday qiziqarli narsaga ega ediki, agar ulanishlar yuqori oqimda tugasa, u barcha yangi so'rovlarga shunchaki "502" ni qaytardi.
Va bizda (men hozirgina Clickhouse-dagi jurnallarni ko'rib chiqdim) so'rovlarning taxminan yarmi bajarilmadi. Shunga ko'ra, diskdan foydalanish yuqori edi, birlashmalar ko'p edi. Xo'sh, men nima qildim? Tabiiyki, men nima uchun aynan ulanish va yuqori oqim tugaganini tushunishga qiynalmadim.
Nginx-ni teskari proksi-server bilan almashtirish
Men buni o'zimiz boshqarishimiz kerak, deb qaror qildim, uni nginx-ga qoldirishimiz shart emas - nginx Clickhouse-da qanday jadvallar borligini bilmaydi va men nginx-ni teskari proksi-server bilan almashtirdim, uni ham o'zim yozganman.
U nima qilyapti? U "goshnoy" fasthttp kutubxonasi asosida ishlaydi, ya'ni tez, deyarli nginx kabi tez. Kechirasiz, Igor, agar siz shu yerda bo'lsangiz (eslatma: Igor Sysoev nginx veb-serverini yaratgan rus dasturchisi). Bu qanday so'rovlar ekanligini tushunishi mumkin - INSERT yoki SELECT - shunga ko'ra, u har xil turdagi so'rovlar uchun turli xil ulanish hovuzlarini o'z ichiga oladi.
Shunga ko'ra, qo'shish so'rovlarini bajarishga vaqtimiz bo'lmasa ham, "tanlanganlar" o'tib ketadi va aksincha. Va u ma'lumotlarni bufer jadvallariga guruhlaydi - kichik bufer bilan: agar biron bir xatolik, sintaksis xatolari va boshqalar bo'lsa - ular qolgan ma'lumotlarga katta ta'sir qilmasligi uchun, chunki biz shunchaki bufer jadvallariga kiritganimizda, biz kichik "bachi" bor edi va barcha sintaktik xatolar faqat bu kichik qismga ta'sir qildi; va bu erda ular allaqachon katta buferga ta'sir qiladi. Kichik 1 megabayt, ya'ni unchalik kichik emas.
Sinxronizatsiyani kiritish va asosan nginx-ni almashtirish nginx ilgari qilgan ishni bajaradi - buning uchun mahalliy "Kittenhouse" ni o'zgartirishingiz shart emas. Fasthttp-dan foydalanganligi sababli, u juda tez - teskari proksi-server orqali bitta qo'shimchalar uchun soniyada 100 mingdan ortiq so'rovlarni amalga oshirishingiz mumkin. Nazariy jihatdan, siz mushukchalar uyining teskari proksi-serveriga bir vaqtning o'zida bir qatorni kiritishingiz mumkin, lekin, albatta, biz buni qilmaymiz.
Sxema quyidagicha ko'rinishni boshladi: "Kittenhouse", teskari proksi-server ko'plab so'rovlarni jadvallarga guruhlaydi va o'z navbatida bufer jadvallari ularni asosiylariga kiritadi.
Qotil vaqtinchalik yechim, mushukcha doimiy
Bu qiziq muammo... Sizlardan kimdir fasthttp dan foydalanganmi? POST so'rovlari bilan fasthttp-dan kim foydalangan? Ehtimol, bu haqiqatan ham qilinmasligi kerak edi, chunki u sukut bo'yicha so'rov tanasini buferlaydi va bizning bufer hajmi 16 megabaytga o'rnatildi. Qo'shish bir nuqtada davom etishni to'xtatdi va 16 megabaytlik bo'laklar barcha o'n minglab serverlardan kela boshladi va ularning barchasi Clickhouse-ga yuborilgunga qadar xotirada buferlandi. Shunga ko'ra, xotira tugadi, Xotiradan tashqari qotil keldi va teskari proksi-serverni o'ldirdi (yoki nazariy jihatdan teskari proksi-serverdan ko'ra ko'proq "eyish" mumkin bo'lgan "Clickhouse"). Tsikl yana takrorlandi. Juda yoqimli muammo emas. Garchi biz bunga bir necha oylik operatsiyadan keyin qoqilgan bo'lsak ham.
Men nima qildim? Shunga qaramay, men aniq nima bo'lganini tushunishni yoqtirmayman. Menimcha, siz xotiraga bufer qilmasligingiz aniq. Men urinib ko'rgan bo'lsam ham, fasthttp-ni tuzata olmadim. Lekin men buni qilishning yo'lini topdim, shunda hech narsani tuzatishga hojat qolmaydi va men HTTPda o'zimning usulimni o'ylab topdim - men uni KITTEN deb nomladim. Xo'sh, bu mantiqiy - "VK", "Kitten" ... Yana nima?..
Если приходит запрос на сервер с методом Kitten, то сервер должен ответить «мяу» (meow) – логично. Если он на это отвечает, то считается, что он понимает этот протокол, и дальше я перехватываю соединение (в fasthttp такой метод есть), и соединение переходит в «сырой» режим. Зачем мне это нужно? Я хочу управлять тем, как происходит чтение из TCP-соединений. У TCP есть замечательное свойство: если никто не читает с той стороны, то запись начинает ждать, и память особо не расходуется на это.
Va shuning uchun men bir vaqtning o'zida 50 ga yaqin mijozdan o'qiyman (ellikdan, chunki ellik albatta etarli bo'lishi kerak, hatto stavka boshqa shahardan kelgan bo'lsa ham) ... Bu yondashuv bilan iste'mol kamida 20 marta kamaydi, lekin men, rostini aytsam , Men aniq qaysi vaqtni o'lchay olmadim, chunki bu allaqachon ma'nosiz (u allaqachon xatolik darajasiga etgan). Protokol ikkilikdir, ya'ni u jadval nomi va ma'lumotlarni o'z ichiga oladi; http sarlavhalari yo'q, shuning uchun men veb-rozetkadan foydalanmadim (brauzerlar bilan aloqa qilishim shart emas - men ehtiyojlarimizga mos keladigan protokol tuzdim). Va u bilan hamma narsa yaxshi bo'ldi.
Bufer jadvali achinarli
Yaqinda biz bufer jadvallarining yana bir qiziqarli xususiyatiga duch keldik. Va bu muammo allaqachon boshqalarga qaraganda ancha og'riqli. Keling, ushbu vaziyatni tasavvur qilaylik: siz allaqachon Clickhouse-dan faol foydalanmoqdasiz, sizda o'nlab Clickhouse serverlari mavjud va sizda o'qish uchun juda uzoq vaqt talab qilinadigan so'rovlar mavjud (aytaylik, 60 soniyadan ko'proq); va siz shu lahzada kelib Alter qilasiz... Ayni paytda “Alter”dan oldin boshlangan “tanlovlar” bu jadvalga kiritilmaydi, “Alter” boshlanmaydi – ehtimol “Clickhouse” qanday ishlashining ayrim xususiyatlari bu joy. Balki buni tuzatish mumkinmi? Yoki imkonsizmi?
Umuman olganda, aslida bu unchalik katta muammo emasligi aniq, ammo bufer jadvallari bilan u yanada og'riqli bo'ladi. Chunki, aytaylik, sizning “Alter” vaqtingiz tugasa (va boshqa xostda vaqt tugashi mumkin - siznikida emas, masalan, replikada), u holda... Siz bufer jadvalini o‘chirib tashladingiz, “O‘zgartirish” ( yoki boshqa xost) vaqti tugadi. keyin "O'zgartirish" xatosi yuz berdi) - siz hali ham ma'lumotlar yozilishini ta'minlashingiz kerak: siz bufer jadvallarini qayta yaratasiz (ota-jadval bilan bir xil sxema bo'yicha), keyin "O'zgartirish" o'tadi, oxir-oqibat tugaydi va jadvalning buferi sxemada ota-onadan farq qila boshlaydi. "O'zgartirish" nima bo'lganiga qarab, qo'shimcha endi bu bufer jadvaliga kirmasligi mumkin - bu juda achinarli.
Bunday belgi ham bor (balki kimdir buni payqagan) - bu Clickhouse-ning yangi versiyalarida query_thread_log deb ataladi. Odatiy bo'lib, ba'zi versiyalarda bittasi bor edi. Bu erda biz bir necha oy ichida 840 million yozuvni (100 gigabayt) to'pladik. Buning sababi u erda "qo'shimchalar" yozilganligi (ehtimol, hozir, aytmoqchi, ular yozilmagan). Sizga aytganimdek, bizning "qo'shimchalarimiz" kichik - bizda bufer jadvallariga juda ko'p "qo'shimchalar" bor edi. Bu o'chirilganligi aniq - men sizga serverimizda ko'rganlarimni aytib beraman. Nega? Bu bufer jadvallarini ishlatishga qarshi yana bir dalil! Spotty juda achinarli.
Bu yigitning ismi Dog'li ekanligini kim bilar edi? VK xodimlari qo'llarini ko'tarishdi. Ha mayli.
"KitttenHouse" rejalari haqida
Rejalar odatda baham ko'rilmaydi, to'g'rimi? To'satdan siz ularni bajarmaysiz va boshqa odamlarning ko'ziga juda yaxshi ko'rinmaysiz. Lekin men tavakkal qilaman! Biz quyidagilarni qilishni xohlaymiz: bufer jadvallari, menimcha, hali ham qo'ltiq tayoqchalari va biz kiritishni o'zimiz buferlashimiz kerak. Lekin biz hali ham uni diskda buferlashni xohlamaymiz, shuning uchun biz xotiraga qo'shishni buferlaymiz.
Shunga ko'ra, "qo'shish" amalga oshirilganda, u endi sinxron bo'lmaydi - u allaqachon bufer jadvali sifatida ishlaydi, ota-jadvalga kiritiladi (yaxshi, bir kun o'tib) va qo'shimchalar o'tgan va qaysi biri alohida kanal orqali hisobot beradi. egalik qila olmaslik.
Почему нельзя оставить синхронную вставку? Она же намного удобнее. Дело в том, что, если вставляете с 10 тысяч хостов, то всё хорошо – у вас с каждого хоста будет литься по чуть-чуть, вы там раз в секунду вставляете, всё прекрасно. Но хочется, чтобы эта схема работала, например, и с двух машин, чтобы вы могли лить на большой скорости – может, не выжимать максимум из «Кликхауса», но хотя бы 100 мегабайт в секунду писать с одной машины через реверс-прокси – эта схема должна масштабироваться и на большое количество, и на маленькое, поэтому мы не можем ждать на каждую вставку по секунде, поэтому она должна быть асинхронной. И точно так же асинхронные подтверждения должны приходить после того, как вставка совершилась. Мы будем знать о том, прошла она или нет.
Eng muhimi, ushbu sxemada biz kiritish amalga oshirilganmi yoki yo'qmi, aniq bilamiz. Bunday vaziyatni tasavvur qiling: sizda bufer jadvali bor, siz unga biror narsa yozdingiz va keyin, aytaylik, jadval faqat o'qish rejimiga o'tdi va buferni tozalashga harakat qildi. Ma'lumotlar qayerga ketadi? Ular buferda qoladilar. Ammo biz bunga ishonchimiz komil emas - agar boshqa xato bo'lsa, nima qilish kerak, buning natijasida ma'lumotlar buferda qolmaydi... (Manzillar Aleksey Milovidov, Yandex, ClickHouse dasturchisi) Yoki qoladimi? Har doimmi? Aleksey bizni hamma narsa yaxshi bo'lishiga ishontirdi. Bizda unga ishonmaslik uchun asos yo'q. Ammo baribir: agar biz bufer jadvallarini ishlatmasak, ular bilan hech qanday muammo bo'lmaydi. Ikki barobar ko'p jadvallarni yaratish ham noqulay, garchi printsipial jihatdan katta muammolar yo'q. Bu reja.
Keling, o'qish haqida gapiraylik
Endi o'qish haqida gapiraylik. Biz bu erda o'z vositamizni ham yozdik. Ko'rinib turibdiki, nega bu erda o'z asbobingizni yozasiz?.. Tabixdan kim foydalangan? Negadir kam odam qo‘l ko‘tardi... Tabixning ijrosi esa kimni qoniqtirdi? Xo'sh, biz bundan mamnun emasmiz va ma'lumotlarni ko'rish uchun juda qulay emas. Bu analitika uchun yaxshi, lekin faqat ko'rish uchun optimallashtirilmaganligi aniq. Shunday qilib, men o'zimning interfeysimni yozdim.
Bu juda oddiy - u faqat ma'lumotlarni o'qiy oladi. U grafikani qanday ko'rsatishni bilmaydi, hech narsa qilishni bilmaydi. Lekin u bizga kerak bo'lgan narsani ko'rsatishi mumkin: masalan, jadvalda qancha qator bor, qancha joy egallaydi (ustunlarga bo'lmasdan), ya'ni juda oddiy interfeys bizga kerak.
Va u Sequel Pro-ga juda o'xshaydi, lekin faqat Twitter-ning Bootstrap-da va ikkinchi versiyada yaratilgan. Siz so'raysiz: "Yuriy, nega ikkinchi versiyada?" Qaysi yil? 2018? Umuman olganda, men buni "Muscle" (MySQL) uchun ancha oldin qilganman va u yerdagi so'rovlardagi bir nechta qatorni o'zgartirdim va u "Clickhouse" uchun ishlay boshladi, buning uchun alohida rahmat! Chunki tahlil qiluvchi "mushak" ga juda o'xshaydi va so'rovlar juda o'xshash - juda qulay, ayniqsa boshida.
Xo'sh, u jadvallarni filtrlashi mumkin, jadvalning tuzilishi va tarkibini ko'rsatishi mumkin, saralash, ustunlar bo'yicha filtrlash imkonini beradi, natijaga olib kelgan so'rovni, ta'sirlangan qatorlarni (natijada qancha) ko'rsatadi, ya'ni ma'lumotlarni ko'rish uchun asosiy narsalar. Juda tez.
Shuningdek, muharrir ham bor. Rostini aytsam, men Tabix-dan butun muharrirni o'g'irlamoqchi bo'ldim, lekin qila olmadim. Lekin qandaydir tarzda ishlaydi. Aslida, hammasi shu.
"Clickhouse" uyalar uchun javob beradi
Men sizga aytmoqchimanki, Clickhouse, tavsiflangan barcha muammolarga qaramay, jurnallar uchun juda mos keladi. Eng muhimi, u bizning muammomizni hal qiladi - bu juda tez va jurnallarni ustunlar bo'yicha filtrlash imkonini beradi. Printsipial jihatdan, bufer jadvallari yaxshi ishlamadi, lekin odatda nima uchun hech kim bilmaydi ... Balki endi siz qayerda muammolarga duch kelishingizni yaxshiroq bilasiz.
TCP? Umuman olganda, VK-da UDP-dan foydalanish odatiy holdir. Va men TCP dan foydalanganimda ... Albatta, hech kim menga aytmadi: “Yuriy, nima haqida gapiryapsan! Siz qila olmaysiz, sizga UDP kerak." TCP unchalik qo'rqinchli emasligi ma'lum bo'ldi. Bitta narsa, agar siz yozadigan o'n minglab faol birikmalaringiz bo'lsa, uni biroz ehtiyotkorlik bilan tayyorlashingiz kerak; lekin bu mumkin va juda oson.
“Kittenhouse” va “Lighthouse”ni HighLoad Siberia-ga hamma ommaviy “VK backend”imizga obuna bo‘lsa, joylashtirishga va’da bergandim... Bilasizmi, hamma ham obuna bo‘lmagan... Albatta, men sizdan bizning kanalimizga obuna bo‘lishingizni talab qilmayman. ommaviy. Sizlar hali ham juda ko'p, kimdir xafa bo'lishi mumkin, lekin baribir obuna bo'ling (va bu erda men mushukning ko'zlari kabi ko'rishim kerak). Bu . Katta rahmat! Github bizniki . Clickhouse yordamida sochlaringiz yumshoq va ipakdek bo'ladi.
Moderator: - Do'stlar, endi savollar uchun. Biz minnatdorchilik sertifikatini va VHS bo'yicha hisobotingizni taqdim etganimizdan so'ng darhol.
Yuriy Nasretdinov (keyingi o'rinlarda YN): - Agar VHS haqidagi hisobotim endigina tugagan bo'lsa, qanday qilib yozib olishga muvaffaq bo'ldingiz?
Moderator: - Shuningdek, "Clickhouse" qanday ishlashini yoki yo'qligini to'liq aniqlay olmaysiz! Do'stlar, savollar uchun 5 daqiqa!
Sizning savollaringiz
Tomoshabinlar savoli (keyingi o'rinlarda Q deb yuritiladi): – Добрый день. Спасибо большое за доклад. У меня два вопроса. Начну с несерьёзного: влияет ли количество букв t в названии «Киттенхаус» на схемах (3, 4, 7…) на удовлетворённость котиков?
YN: - Nima miqdori?
Z: - T harfi. Uchta t bor, qaerdadir uch t atrofida.
YN: - Men tuzatmadimmi? Xo'sh, albatta shunday qiladi! Bu turli xil mahsulotlar - men sizni shu vaqtgacha aldadim. Mayli, hazillashyapman - bu muhim emas. Oh, shu yerda! Yo'q, xuddi shunday, men matn terish xatosini tuzdim.
Z: - Rahmat. Ikkinchi savol jiddiy. Men tushunganimdek, Clickhouse-da bufer jadvallari faqat xotirada yashaydi, diskda bufer qilinmaydi va shunga mos ravishda doimiy emas.
YN: - Ha.
Z: – Va shu bilan birga, sizning mijozingiz diskka buferlanadi, bu xuddi shu jurnallarni etkazib berish kafolatini anglatadi. Lekin bu Clickhouse-da hech qanday kafolatlanmagan. Kafolat qanday amalga oshirilayotganini tushuntiring, nima tufayli?.. Mana bu mexanizm batafsilroq
YN: - Ha, nazariy jihatdan bu erda hech qanday qarama-qarshiliklar yo'q, chunki Clickhouse tushganda, siz uni millionlab turli yo'llar bilan aniqlay olasiz. Agar Clickhouse ishlamay qolsa (agar u noto'g'ri tugasa), siz, qo'pol qilib aytganda, o'zingiz yozgan jurnalingizning bir qismini orqaga qaytarishingiz va hamma narsa yaxshi bo'lgan paytdan boshlashingiz mumkin. Aytaylik, siz bir daqiqa orqaga o'tkazdingiz, ya'ni bir daqiqada hamma narsani yuvib tashlagan deb hisoblanadi.
Z: - Ya'ni, "Kittenhouse" derazani uzoqroq ushlab turadi va yiqilgan taqdirda uni tanib, orqaga o'ra oladimi?
YN: – Но это в теории. На практике мы этого не делаем, и надёжная доставка – это от нуля до бесконечности раз. Но в среднем один. Нас устраивает, что, если «Кликхаус» падает по какой-то причине или серверы «ребутают», то мы немножко теряем. Во всех остальных случаях ничего не будет происходить.
Z: - Salom. Menga boshidanoq siz hisobotning boshidanoq UDP dan foydalanasiz deb tuyulardi. Sizda http bor, bularning barchasi... Va siz tasvirlagan muammolarning aksariyati, men tushunganimdek, aynan shu yechimdan kelib chiqqan...
YN: - Biz TCP nimadan foydalanamiz?
Z: - Aslida ha.
YN: Yo'q.
Z: - Fasthttp bilan bog'liq muammolaringiz bor edi, ulanishda muammolaringiz bor edi. Agar siz hozirgina UDP dan foydalangan bo'lsangiz, o'zingizni biroz vaqt tejagan bo'lar edingiz. Xo'sh, uzoq xabarlar yoki boshqa narsalar bilan bog'liq muammolar bo'lar edi ...
YN: - Nima bilan?
Z: – Uzoq xabarlar bilan, chunki u MTUga mos kelmasligi mumkin, boshqa narsa... Xo'sh, o'z muammolari bo'lishi mumkin. Savol: nega UDP emas?
YN: - Men ishonamanki, TCP/IP-ni ishlab chiqqan mualliflar mendan ancha aqlli va paketlarni qanday ketma-ketlashtirishni (ular ketishi uchun) mendan yaxshiroq bilishadi, shu bilan birga yuborish oynasini sozlash, tarmoqni ortiqcha yuklamaslik, nima haqida fikr bildirish. o'qilmaydi, boshqa tomondan hisoblanmaydi ... Bu muammolarning barchasi, mening fikrimcha, UDPda mavjud bo'lar edi, faqat men xuddi shu narsani o'zim va katta ehtimol bilan amalga oshirish uchun yozganimdan ham ko'proq kod yozishim kerak edi. yomon. Men hatto C tilida yozishni ham yoqtirmayman, u yerda...
Z: - Faqat qulay! Yaxshi yuborildi va hech narsa kutmang - bu butunlay asinxron. Hammasi yaxshi ekanligi haqida bildirishnoma keldi - bu kelganligini anglatadi; Agar u kelmasa, bu yomon degan ma'noni anglatadi.
YN: – Menga ikkalasi ham kerak – men yetkazib berish kafolati bilan ham, yetkazib berish kafolatisiz ham jo‘natishim kerak. Bu ikki xil stsenariy. Men ba'zi jurnallarni yo'qotmasligim yoki ularni sabab bilan yo'qotmasligim kerak.
Z: - Vaqtni behuda sarflamayman. Buni ko'proq muhokama qilish kerak. Rahmat.
Moderator: - Kimning savollari bor - qo'llar osmonga!
Z: - Salom, men Sashaman. Hisobotning o'rtasida bir joyda, TCP-dan tashqari, tayyor echimdan - qandaydir Kafkadan foydalanish mumkin degan tuyg'u paydo bo'ldi.
YN: – Xo‘sh... Men sizga oraliq serverlardan foydalanishni xohlamasligimni aytdim, chunki... Kafkada bizda o‘n mingta xost bor ekan; Aslida, bizda ko'proq - o'n minglab xostlar bor. Kafka bilan hech qanday proksisiz qilish ham og'riqli bo'lishi mumkin. Bundan tashqari, eng muhimi, u hali ham "kechikish" beradi, u sizga kerak bo'lgan qo'shimcha xostlarni beradi. Ammo men ularga ega bo'lishni xohlamayman - men xohlayman ...
Z: "Ammo oxir-oqibat hammasi shunday bo'ldi."
YN: - Yo'q, mezbonlar yo'q! Bularning barchasi Clickhouse xostlarida ishlaydi.
Z: - Xo'sh, va "Kittenhouse", ya'ni teskari - u qaerda yashaydi?
YN: – Clickhouse xostida u diskka hech narsa yozmaydi.
Z: - Faraz qilaylik.
Moderator: - Ko'nglingiz to'ldimi? Sizga maosh bera olamizmi?
Z: - Ha sen qila olasan. Aslida, xuddi shu narsani olish uchun juda ko'p tayoqchalar mavjud va hozir - TCP mavzusidagi oldingi javob, mening fikrimcha, bu holatga zid keladi. Hamma narsa mening tizzamda ancha qisqa vaqt ichida bajarilishi mumkin edi.
YN: – Shuningdek, nega men Kafkadan foydalanishni xohlamadim, chunki Clickhouse Telegram chatida, masalan, Kafkadan kelgan xabarlar yo‘qolganligi haqida juda ko‘p shikoyatlar bo‘lgan. Kafkaning o'zidan emas, balki Kafka va Clickhaus integratsiyasida; yoki u erda biror narsa ulanmagan. Qo'pol qilib aytganda, o'shanda Kafkaga mijoz yozish kerak bo'lardi. Menimcha, oddiyroq yoki ishonchliroq yechim bo'lishi mumkin emas.
Z: - Ayting-chi, nima uchun navbat yoki oddiy avtobusni sinab ko'rmadingiz? Asinxroniya bilan siz jurnallarni navbat orqali yuborishingiz va javobni navbat orqali asinxron qabul qilishingiz mumkin deb aytganingiz uchun?
YN: – Iltimos, qanday navbatlardan foydalanish mumkinligini ayting?
Z: – Har qanday, hatto ularning tartibda ekanligiga kafolatsiz ham. Qandaydir Redis, RMQ...
YN: – Menimcha, Redis hatto Clickhouse’ni chiqarib yuboradigan bitta xostda ham (bir nechta serverlar ma’nosida) bunday hajmni qo‘shishga qodir emas. Men buni hech qanday dalil bilan tasdiqlay olmayman (men uni taqqoslamaganman), lekin menga Redis bu erda eng yaxshi yechim emasdek tuyuladi. Aslida, ushbu tizimni improvizatsiya qilingan xabarlar navbati deb hisoblash mumkin, ammo u faqat "Clickhouse" uchun mo'ljallangan.
Moderator: - Yuriy, katta rahmat. Savol-javoblarni shu yerda yakunlashni va savol berganlarning qaysi biriga kitobni berishimizni aytishni taklif qilaman.
YN: – Birinchi savol bergan odamga kitob bermoqchiman.
Moderator: - Ajoyib! Ajoyib! Ajoyib! Katta raxmat!
Ba'zi reklamalar 🙂
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com