HighLoad++ Moskva 2018, Konqres Zalı. 9 noyabr, saat 15:00
Abstrakt və təqdimat:
Yuri Nasretdinov (VKontakte): hesabatda ClickHouse-un şirkətimizdə tətbiqi təcrübəsindən danışılacaq - niyə bizə lazımdır, nə qədər məlumat saxlayırıq, onu necə yazırıq və s.
Əlavə materiallar:
Yuri Nasretdinov: - Hamıya salam! Mənim adım Yuri Nəsretdinovdur, çünki məni artıq tanış ediblər. Mən VKontakte-də işləyirəm. Mən server parkımızdan (on minlərlə) ClickHouse-a məlumatları necə daxil etdiyimizdən danışacağam.
Günlüklər nədir və niyə onları toplayır?
Sizə nə deyəcəyik: nə etdik, nə üçün "ClickHouse" lazım idi, müvafiq olaraq niyə onu seçdik, xüsusi bir şey konfiqurasiya etmədən təxminən hansı performansı əldə edə bilərsiniz. Mən sizə bufer cədvəlləri, onlarla qarşılaşdığımız problemlər və açıq mənbədən - KittenHouse və Lighthouse-dan hazırladığımız həllər haqqında daha çox məlumat verəcəyəm.
Niyə ümumiyyətlə bir şey etməli olduq (VKontakte-də hər şey həmişə yaxşıdır, elə deyilmi?). Sazlama jurnallarını toplamaq istədik (və orada yüzlərlə terabayt məlumat var idi), bəlkə də statistikanı hesablamaq daha rahat olardı; və on minlərlə serverdən ibarət donanmamız var və bütün bunları etmək lazımdır.
Niyə qərar verdik? Yəqin ki, qeydləri saxlamaq üçün həll yollarımız var idi. Budur - belə bir ictimai "Backend VK" var. Mən ona abunə olmağı çox tövsiyə edirəm.
Günlüklər nədir? Bu boş massivləri qaytaran mühərrikdir. VK-dakı mühərriklər başqalarının mikroservislər adlandırdıqlarıdır. Və burada gülümsəyən bir stiker var (çox bəyənmə). Necə? Yaxşı, daha çox qulaq asın!
Günlükləri saxlamaq üçün nə istifadə edilə bilər? Hadupun adını çəkməmək mümkün deyil. Sonra, məsələn, Rsyslog (bu qeydləri fayllarda saxlamaq). LSD. LSD-nin nə olduğunu kim bilir? Xeyr, bu LSD deyil. Faylları da müvafiq olaraq saxlayın. Yaxşı, ClickHouse qəribə bir seçimdir.
Clickhouse və rəqiblər: tələblər və imkanlar
biz nə istəyirik? Əməliyyatla bağlı çox narahat olmamağımızı təmin etmək istəyirik ki, o, qutudan kənarda, tercihen minimal konfiqurasiya ilə işləsin. Çox yazmaq, tez yazmaq istəyirik. Biz isə onu hər cür aylar, illər, yəni uzun müddət saxlamaq istəyirik. Onların bizə gəlib “burada bir şey işləmir” dedikləri problemi başa düşmək istəyə bilərik və bu 3 ay əvvəl idi) və 3 ay əvvəl baş verənləri görmək istəyirik " Məlumatların sıxılması - bunun nə üçün bir artı olacağı aydındır - çünki tutduğu yerin miqdarını azaldır.
Və belə bir maraqlı tələbimiz var: biz bəzən bəzi əmrlərin (məsələn, jurnalların) çıxışını yazırıq, o, 4 kilobaytdan çox ola bilər. Və əgər bu şey UDP üzərində işləyirsə, o zaman xərcləməyə ehtiyac yoxdur... onun qoşulma üçün heç bir “əlavə xərci” olmayacaq və çoxlu sayda serverlər üçün bu, bir artı olacaq.
Gəlin görək açıq mənbə bizə nə təklif edir. Birincisi, bizdə Logs Engine var - bu bizim mühərrikimizdir; Prinsipcə, o, hər şeyi edə bilər, hətta uzun sətirlər də yaza bilər. Yaxşı, o, məlumatları şəffaf şəkildə sıxışdırmır - istəsək, böyük sütunları özümüz sıxışdıra bilərik... biz, əlbəttə ki, istəmirik (mümkünsə). Yeganə problem odur ki, o, ancaq yaddaşına uyğun gələni verə bilir; Qalanını oxumaq üçün bu mühərrikin binlogunu əldə etməlisiniz və buna görə də kifayət qədər uzun müddət tələb olunur.
Başqa hansı variantlar var? Məsələn, "Hadup". İstismar rahatlığı... Hadup-un qurulmasının asan olduğunu kim düşünür? Təbii ki, çəkilişdə heç bir problem yoxdur. Oxuyanda bəzən suallar yaranır. Prinsipcə, mən deyərdim ki, yox, xüsusən də loglar üçün. Uzunmüddətli saxlama - əlbəttə ki, bəli, məlumatların sıxılması - bəli, uzun sətirlər - qeyd edə biləcəyiniz aydındır. Amma çoxlu sayda serverdən qeyd... Siz hələ də özünüz bir şey etməlisiniz!
Rsyslog. Əslində, biz onu ehtiyat variant kimi istifadə etdik ki, onu binlogu boşaltmadan oxuya bilək, lakin o, uzun sətirlər yaza bilməz; prinsipcə, 4 kilobaytdan çox yaza bilməz. Məlumatların sıxılmasını özünüz də eyni şəkildə etməlisiniz. Oxumaq fayllardan gələcək.
Sonra LSD-nin "badushka" inkişafı var. Əslində "Rsyslog" ilə eynidir: uzun sətirləri dəstəkləyir, lakin UDP vasitəsilə işləyə bilməz və əslində buna görə təəssüf ki, orada çox şey yenidən yazılmalıdır. On minlərlə serverdən qeyd edə bilmək üçün LSD yenidən dizayn edilməlidir.
Və burada! Gülməli seçim ElasticSearch-dir. Necə deməli? Oxumaqla yaxşı gedir, yəni tez oxuyur, amma yazı ilə çox yaxşı deyil. Birincisi, məlumatları sıxırsa, çox zəifdir. Çox güman ki, tam axtarış orijinal həcmdən daha böyük məlumat strukturları tələb edir. Əməliyyat etmək çətindir və onunla tez-tez problemlər yaranır. Və yenə də Elastikdə qeyd - hər şeyi özümüz etməliyik.
Burada ClickHouse, əlbəttə ki, ideal seçimdir. Yeganə odur ki, on minlərlə serverdən qeyd etmək problemdir. Ancaq ən azı bir problem var, onu bir şəkildə həll etməyə çalışa bilərik. Və hesabatın qalan hissəsi bu problem haqqındadır. ClickHouse-dan hansı performansı gözləmək olar?
Onu necə daxil edəcəyik? MergeTree
Aranızda kim "ClickHouse" haqqında eşitməyib və ya bilmir? Mən sizə deməliyəm, elə deyilmi? Çox sürətli. Orada daxiletmə - saniyədə 1-2 giqabit, saniyədə 10 giqabitə qədər partlayışlar əslində bu konfiqurasiyaya tab gətirə bilər - iki 6 nüvəli Xeon (yəni, hətta ən güclü deyil), 256 giqabayt operativ yaddaş, 20 terabayt var. RAID-də (heç kim konfiqurasiya edilməyib, standart parametrlər). ClickHouse-un tərtibatçısı Aleksey Milovidov, yəqin ki, heç nə konfiqurasiya etmədiyimiz üçün orada oturub ağlayır (hər şey bizim üçün belə işləyirdi). Müvafiq olaraq, məlumat yaxşı sıxılırsa, məsələn, saniyədə təxminən 6 milyard sətir tarama sürəti əldə edilə bilər. Əgər mətn sətirində % bəyənirsinizsə - saniyədə 100 milyon sətir, yəni kifayət qədər sürətli görünür.
Onu necə daxil edəcəyik? VK-nın PHP-dən istifadə etdiyini bilirsiniz. Biz hər bir PHP işçisindən HTTP vasitəsilə “ClickHouse”a, hər qeyd üçün MergeTree cədvəlinə daxil edəcəyik. Kim bu sxemdə problem görür? Nədənsə hamı əl qaldırmadı. Mən sizə deyim.
Birincisi, bir çox server var - müvafiq olaraq, çoxlu bağlantılar (pis) olacaq. Sonra MergeTree-ə saniyədə bir dəfədən çox olmayan məlumatları daxil etmək daha yaxşıdır. Və kim bilir niyə? tamam, tamam. Bu barədə sizə bir az daha məlumat verəcəyəm. Başqa bir maraqlı sual ondan ibarətdir ki, biz analitika etmirik, məlumatları zənginləşdirməyə ehtiyacımız yoxdur, aralıq serverlərə ehtiyacımız yoxdur, biz birbaşa “ClickHouse”a daxil etmək istəyirik (tercihen – nə qədər birbaşa olsa, bir o qədər yaxşıdır).
Müvafiq olaraq, MergeTree-də daxiletmə necə həyata keçirilir? Niyə onu saniyədə bir dəfədən çox və ya daha az daxil etmək daha yaxşıdır? Fakt budur ki, "ClickHouse" sütunlu verilənlər bazasıdır və məlumatları əsas açarın artan sırası ilə çeşidləyir və daxil etdiyiniz zaman ən azı verilənlərin çeşidləndiyi sütunların sayına bərabər sayda fayl yaradılır. əsas açarın artan sırası ilə (ayrıca bir kataloq yaradılır, hər bir daxiletmə üçün diskdə fayl dəsti). Sonra növbəti əlavə gəlir və arxa planda onlar daha böyük "arakəsmələrə" birləşdirilir. Məlumat çeşidləndiyi üçün çox yaddaş sərf etmədən iki çeşidlənmiş faylı “birləşdirmək” mümkündür.
Ancaq təxmin etdiyiniz kimi, hər bir daxiletmə üçün 10 fayl yazsanız, ClickHouse (və ya serveriniz) tez bitəcək, ona görə də böyük partiyalarda daxil etmək tövsiyə olunur. Müvafiq olaraq, biz heç vaxt ilk sxemi istehsala başlamamışıq. Biz dərhal birini işə saldıq, burada №2-də var:
Təsəvvür edin ki, işə saldığımız minə yaxın server var, sadəcə PHP var. Və hər bir serverdə “Kittenhouse” adlandırdığımız yerli agentimiz var ki, bu da “ClickHouse” ilə bir əlaqə saxlayır və bir neçə saniyədən bir məlumat daxil edir. Məlumatı MergeTree-ə deyil, dərhal MergeTree-ə daxil etməmək üçün dəqiq xidmət edən bufer cədvəlinə daxil edir.
Bufer cədvəlləri ilə işləmək
Bu nədir? Bufer cədvəlləri parçalanmış yaddaş parçasıdır (yəni onu tez-tez daxil etmək olar). Onlar bir neçə hissədən ibarətdir və parçaların hər biri müstəqil tampon kimi işləyir və onlar müstəqil olaraq yuyulur (əgər buferdə bir çox parça varsa, saniyədə çoxlu əlavələr olacaq). Bu cədvəllərdən oxumaq mümkündür - sonra buferin və ana cədvəlin məzmununun birləşməsini oxuyursunuz, lakin bu anda yazma bloklanır, ona görə də oradan oxumamaq daha yaxşıdır. Və bufer cədvəlləri çox yaxşı QPS göstərir, yəni 3 min QPS-ə qədər daxil edərkən heç bir probleminiz olmayacaq. Aydındır ki, əgər server gücünü itirirsə, o zaman məlumatlar itirilə bilər, çünki o, yalnız yaddaşda saxlanılıb.
Eyni zamanda, buferli sxem ALTER-i çətinləşdirir, çünki əvvəlcə köhnə bufer cədvəlini köhnə sxemlə atmaq lazımdır (məlumatlar heç yerdə yox olmayacaq, çünki cədvəl silinməzdən əvvəl yuyulacaq). Sonra sizə lazım olan cədvəli "dəyişdirirsiniz" və yenidən bufer cədvəlini yaradırsınız. Müvafiq olaraq, heç bir bufer cədvəli olmadığı halda, məlumatlarınız heç bir yerə axmayacaq, ancaq ən azı yerli olaraq diskdə ola bilərsiniz.
Kittenhouse nədir və necə işləyir?
KittenHouse nədir? Bu proxydir. Təxmin et, hansı dildə? Hesabatımda ən çox şırınga mövzuları topladım - "Clickhouse", Get, bəlkə başqa bir şey xatırlayacağam. Bəli, bu Go-da yazılıb, çünki mən C-də necə yazacağımı bilmirəm, istəmirəm.
Müvafiq olaraq, hər bir serverlə əlaqə saxlayır və yaddaşa yaza bilir. Məsələn, Clickhouse-a səhv qeydləri yazsaq, onda Clickhouse-un məlumat daxil etməyə vaxtı yoxdursa (əgər çox yazılıbsa), onda yaddaşı şişirtmirik - qalanını sadəcə atırıq. Çünki saniyədə bir neçə gigabit səhv yazsaq, yəqin ki, bəzilərini kənara ata bilərik. Kittenhouse bunu edə bilər. Üstəlik, o, etibarlı çatdırılmanı həyata keçirə bilər, yəni yerli maşında diskə yaza bilər və hər dəfə (orada, hər iki saniyədə bir dəfə) bu fayldan məlumatları çatdırmağa çalışır. Və əvvəlcə adi Dəyərlər formatından istifadə etdik - bəzi ikili format deyil, mətn formatı (adi SQL-də olduğu kimi).
Amma sonra bu baş verdi. Etibarlı çatdırılmadan istifadə etdik, jurnallar yazdıq, sonra qərar verdik (bu, şərti test klasteri idi)... O, bir neçə saat söndürüldü və yenidən işə salındı və min serverdən daxiletmə başladı - məlum oldu ki, Clickhouse hələ də "Bağlantıda mövzu" - müvafiq olaraq, min bağlantıda aktiv daxiletmə serverdə orta hesabla bir yarım min yükə səbəb olur. Təəccüblüdür ki, server sorğuları qəbul etdi, lakin bir müddət sonra məlumatlar hələ də daxil edildi; lakin serverin ona xidmət etməsi çox çətin idi...
nginx əlavə edin
Bağlantı modelinə görə Thread üçün belə bir həll nginx-dir. Biz Clickhouse-un qarşısında nginx quraşdırdıq, eyni zamanda iki replika üçün balanslaşdırma qurduq (daxiletmə sürətimiz 2 dəfə artdı, baxmayaraq ki, belə olması faktı deyil) və Clickhouse-a qoşulmaların sayını məhdudlaşdırdıq. upstream və müvafiq olaraq daha çox , 50 əlaqədən daha çox, deyəsən daxil etməyin mənası yoxdur.
Sonra başa düşdük ki, bu sxem ümumiyyətlə çatışmazlıqlara malikdir, çünki burada yalnız bir nginx var. Müvafiq olaraq, əgər bu nginx qəzaya uğrayarsa, replikaların olmasına baxmayaraq, biz məlumatları itiririk və ya heç olmasa heç bir yerə yazmırıq. Buna görə də biz öz yük balansımızı etdik. Biz də başa düşdük ki, "Clickhouse" hələ də loglar üçün uyğundur və "cin" də qeydlərini "Clickhouse" da yazmağa başladı - düzünü desəm, çox rahatdır. Biz hələ də digər “cinlər” üçün istifadə edirik.
Sonra biz bu maraqlı problemi aşkar etdik: SQL rejimində qeyri-standart daxiletmə metodundan istifadə etsəniz, o, tam hüquqlu AST əsaslı SQL analizatorunu məcbur edir ki, bu da kifayət qədər yavaşdır. Müvafiq olaraq, bunun heç vaxt baş verməməsini təmin etmək üçün parametrlər əlavə etdik. Yük balansını, sağlamlıq yoxlamalarını etdik ki, əgər biri ölürsə, biz hələ də məlumatları buraxırıq. İndi bizim müxtəlif Clickhouse klasterlərimizə sahib olmaq üçün kifayət qədər çoxlu masalarımız var. Və biz digər istifadələr haqqında da düşünməyə başladıq - məsələn, biz nginx modullarından qeydlər yazmaq istədik, lakin onlar RPC-dən istifadə edərək necə ünsiyyət quracağını bilmirlər. Yaxşı, mən onlara ən azı bir şəkildə necə göndərməyi öyrətmək istərdim - məsələn, UDP vasitəsilə localhost-da hadisələri qəbul etməyi və sonra onları Clickhouse-a yönləndirməyi.
Həlldən bir addım uzaqda
Yekun sxem belə görünməyə başladı (bu sxemin dördüncü versiyası): Clickhouse-un qarşısındakı hər bir serverdə nginx (eyni serverdə) var və o, sadəcə olaraq 50 bağlantı sayına məhdudiyyət qoyaraq localhost-a sorğuları göndərir. ədəd. Və bu sxem artıq olduqca işləyirdi, onunla hər şey olduqca yaxşı idi.
Bir aya yaxın belə yaşadıq. Hamı sevindi, cədvəllər əlavə etdilər, əlavə etdilər, əlavə etdilər... Ümumiyyətlə, bufer cədvəllərini əlavə etməyimiz çox da optimal deyil (belə deyək). Hər masada 16 parça və bir neçə saniyəlik bir flaş intervalı etdik; bizdə 20 cədvəl var idi və hər masa saniyədə 8 əlavə alırdı - və bu anda “Clickhouse” başladı... qeydlər yavaşlamağa başladı. Hətta keçmədilər... Nginx-in standart olaraq o qədər maraqlı bir xüsusiyyəti var idi ki, əgər bağlantılar yuxarı axınla bitərsə, o, bütün yeni sorğulara sadəcə “502” qaytarırdı.
Və burada (mən sadəcə Clickhouse-un özündə olan qeydlərə baxdım) sorğuların təxminən yarısı uğursuz oldu. Müvafiq olaraq, diskdən istifadə yüksək idi, çoxlu birləşmələr var idi. Yaxşı, mən nə etdim? Təbii ki, əlaqənin və yuxarı axının niyə tam olaraq bitdiyini anlamağa çalışmadım.
Nginx-in əks proxy ilə əvəz edilməsi
Qərara gəldim ki, bunu özümüz idarə etməliyik, onu nginx-ə buraxmaq lazım deyil - nginx Clickhouse-da hansı cədvəllərin olduğunu bilmir və mən nginx-i özüm də yazdığım tərs proxy ilə əvəz etdim.
O nə edir? O, “goshnoy” fasthttp kitabxanası əsasında işləyir, yəni sürətli, demək olar ki, nginx qədər sürətli. Bağışlayın, İqor, əgər buradasınızsa (qeyd: İqor Sısoev nginx veb serverini yaradan rus proqramçısıdır). O, bunların hansı sorğular olduğunu başa düşə bilər – INSERT və ya SELECT – müvafiq olaraq, müxtəlif sorğu növləri üçün müxtəlif əlaqə hovuzlarını saxlayır.
Müvafiq olaraq, daxiletmə sorğularını tamamlamağa vaxtımız olmasa belə, "seçmələr" keçəcək və əksinə. Və o, məlumatları bufer cədvəllərində qruplaşdırır - kiçik bir bufer ilə: əgər hər hansı bir səhv, sintaksis səhvləri və s. varsa - onlar qalan məlumatlara çox təsir göstərməsin, çünki biz sadəcə bufer cədvəllərinə daxil etdikdə, biz kiçik "bachi" idi və bütün sintaksis səhvləri yalnız bu kiçik parçaya təsir etdi; və burada onlar artıq böyük bir tampona təsir edəcəklər. Kiçik 1 meqabaytdır, yəni o qədər də kiçik deyil.
Sinxronizasiyanın daxil edilməsi və mahiyyətcə nginx-in dəyişdirilməsi nginx-in əvvəllər etdiyi kimi eyni şeyi edir – bunun üçün yerli “Kittenhouse”u dəyişməyə ehtiyac yoxdur. Və fasthttp istifadə etdiyi üçün çox sürətlidir - əks proxy vasitəsilə tək əlavələr üçün saniyədə 100 mindən çox sorğu edə bilərsiniz. Teorik olaraq, pişik evinin tərs proxy-yə hər dəfə bir sətir əlavə edə bilərsiniz, lakin əlbəttə ki, biz bunu etmirik.
Sxem belə görünməyə başladı: "Kittenhouse", əks proxy bir çox sorğuları cədvəllərə qruplaşdırır və öz növbəsində bufer cədvəlləri onları əsas olanlara daxil edir.
Qatil müvəqqəti həlldir, Kitten qalıcıdır
Bu maraqlı problemdir... aranızda fasthttp istifadə edən varmı? POST sorğuları ilə fasthttp istifadə edən kimdir? Yəqin ki, bu, həqiqətən edilməməli idi, çünki o, standart olaraq sorğu orqanını bufer edir və bufer ölçüsü 16 meqabayta təyin edilmişdir. Daxiletmə bir anda davam etməyi dayandırdı və on minlərlə serverdən 16 meqabaytlıq hissələr gəlməyə başladı və hamısı Clickhouse-a göndərilməzdən əvvəl yaddaşda bufer edildi. Müvafiq olaraq, yaddaş tükəndi, Yaddaşdan Çıxmış Qatil gəldi və əks proxy-ni (və ya nəzəri olaraq əks proksidən daha çox "yeyə" bilən "Clickhouse") öldürdü. Dövr özünü təkrarladı. Çox xoş problem deyil. Baxmayaraq ki, biz buna yalnız bir neçə aylıq əməliyyatdan sonra rast gəldik.
Mən nə etmişəm? Yenə deyirəm, mən tam olaraq nə baş verdiyini başa düşməyi sevmirəm. Düşünürəm ki, yaddaşa bufer daxil etməməyiniz çox açıqdır. Mən cəhd etsəm də fasthttp-i yamaq edə bilmədim. Amma mən bunu düzəltməyin bir yolunu tapdım ki, heç nəyi yamağa ehtiyac qalmasın və mən HTTP-də öz metodumu tapdım - mən onu KİTTEN adlandırdım. Yaxşı, məntiqlidir - “VK”, “Kitten”... Başqa nə?..
Kitten metodu ilə serverə sorğu gəlirsə, server məntiqi olaraq “miyov” cavabını verməlidir. Əgər o, buna cavab verirsə, o zaman bu protokolu başa düşdüyü hesab edilir, sonra mən əlaqəni kəsirəm (fasthttp-də belə bir üsul var) və əlaqə “raw” rejiminə keçir. Mənə niyə lazımdır? TCP bağlantılarından oxumaların necə baş verdiyinə nəzarət etmək istəyirəm. TCP-nin gözəl bir xüsusiyyəti var: heç kim qarşı tərəfdən oxumursa, yazı gözləməyə başlayır və yaddaş buna xüsusilə sərf edilmir.
Və beləliklə mən bir anda 50-yə yaxın müştəridən oxudum (əllidən çünki əlli mütləq kifayət olmalıdır, hətta tarif başqa bir DC-dən gəlsə belə)... Bu yanaşma ilə istehlak ən azı 20 dəfə azaldı, amma düzünü desəm mən , mən dəqiq nə vaxt ölçə bilmədim, çünki artıq mənasızdır (artıq xəta səviyyəsinə çatıb). Protokol binardır, yəni cədvəlin adını və verilənlərini ehtiva edir; http başlıqları yoxdur, buna görə veb rozetkadan istifadə etmədim (brauzerlərlə əlaqə saxlamağa ehtiyacım yoxdur - ehtiyaclarımıza uyğun bir protokol hazırladım). Və onunla hər şey yaxşılaşdı.
Bufer masası kədərlidir
Bu yaxınlarda bufer cədvəllərinin daha bir maraqlı xüsusiyyəti ilə rastlaşdıq. Və bu problem artıq digərlərindən qat-qat ağrılıdır. Bu vəziyyəti təsəvvür edək: siz artıq Clickhouse-dan aktiv şəkildə istifadə edirsiniz, onlarla Clickhouse serveriniz var və oxumaq üçün çox uzun vaxt aparan bəzi sorğularınız var (tutaq ki, 60 saniyədən çox); və siz bu dəqiqə gəlib Alter edirsiniz... Bu vaxt “Alter”dən əvvəl başlayan “seçmələr” bu cədvələ daxil edilməyəcək, “Dəyişdirmə” başlamaz – yəqin ki, “Clickhouse”un işləməsinin bəzi xüsusiyyətləri bu yer. Bəlkə bu düzəldilə bilər? Yoxsa mümkün deyil?
Ümumiyyətlə, aydındır ki, əslində bu o qədər də böyük problem deyil, amma bufer masaları ilə daha ağrılı olur. Çünki əgər, deyək ki, sizin “Dəyişdirmə” vaxtı bitibsə (və o, başqa hostda – sizinkində deyil, məsələn, replikada vaxt keçə bilər), onda... Siz bufer cədvəlini silmisiniz, “Dəyişdirmə” ( və ya başqa bir host) vaxtı bitdi. sonra "Dəyişdirmə" xətası baş verdi) - hələ də məlumatların yazılmağa davam etdiyinə əmin olmalısınız: bufer cədvəllərini geri yaradırsınız (ana cədvəllə eyni sxemə uyğun olaraq), sonra "Dəyişdirmək" keçir, axırda başa çatır və cədvəlin buferi anadan sxemdə fərqlənməyə başlayır. "Dəyişdirmə" nin nə olduğundan asılı olaraq, əlavə artıq bu bufer cədvəlinə getməyə bilər - bu çox kədərlidir.
Belə bir işarə də var (bəlkə kimsə bunu fərq etdi) - bu, Clickhouse-un yeni versiyalarında query_thread_log adlanır. Varsayılan olaraq, bəzi versiyalarda biri var idi. Burada bir neçə ay ərzində (840 gigabayt) 100 milyon qeyd topladıq. Bu, orada "əlavələrin" yazılması ilə əlaqədardır (bəlkə də indi, yeri gəlmişkən, yazılmayıb). Sizə dediyim kimi, bizim "dəxiletmələrimiz" kiçikdir - bufer cədvəllərinə çoxlu "daxiletmə"lərimiz var idi. Bunun əlil olduğu aydındır - mən sadəcə serverimizdə gördüklərimi sizə deyirəm. Niyə? Bu bufer cədvəllərindən istifadəyə qarşı başqa bir arqumentdir! Spotty çox kədərlidir.
Bu adamın adının Spotty olduğunu kim bilirdi? VK işçiləri əllərini qaldırdılar. TAMAM.
“KitttenHouse” planları haqqında
Planlar adətən paylaşılmır, elə deyilmi? Birdən siz onları yerinə yetirməyəcəksiniz və başqalarının gözündə çox yaxşı görünməyəcəksiniz. Amma risk edəcəm! Biz aşağıdakıları etmək istəyirik: bufer cədvəlləri, mənə elə gəlir ki, hələ də qoltuqağacıdır və biz daxiletməni özümüz bufer etməliyik. Amma biz hələ də onu diskdə bufer etmək istəmirik, ona görə də yaddaşa daxil edilməsini bufer edəcəyik.
Müvafiq olaraq, "insert" edildikdə, o, artıq sinxron olmayacaq - o, artıq bufer cədvəli kimi işləyəcək, əsas cədvələ daxil ediləcək (yaxşı, bir gün sonra) və əlavələrin keçdiyi və hansı əlavələr edildiyini ayrıca bir kanal vasitəsilə hesabat verəcəkdir. yoxdur.
Niyə sinxron əlavəni tərk edə bilmirəm? Çox daha rahatdır. Fakt budur ki, 10 min hostdan daxil etsəniz, hər şey yaxşıdır - hər hostdan bir az alacaqsınız, saniyədə bir dəfə ora daxil edirsiniz, hər şey yaxşıdır. Ancaq bu sxemin, məsələn, iki maşından işləməsini istərdim ki, yüksək sürətlə yükləyə biləsiniz - bəlkə Clickhouse-dan maksimum nəticə əldə edə bilməyəcəksiniz, ancaq əks proxy vasitəsilə bir maşından saniyədə ən azı 100 meqabayt yazın - bu, sxem həm böyük, həm də kiçik kəmiyyətlər üçün miqyaslı olmalıdır, ona görə də hər daxiletmə üçün bir saniyə gözləyə bilmərik, ona görə də asinxron olmalıdır. Eyni şəkildə, asinxron təsdiqləmələr daxiletmə tamamlandıqdan sonra gəlməlidir. Keçib-keçmədiyini biləcəyik.
Ən əsası odur ki, bu sxemdə biz dəqiq bilirik ki, yerləşdirmə olub, ya yox. Bu vəziyyəti təsəvvür edin: bufer cədvəliniz var, ona bir şey yazdınız və sonra, deyək ki, cədvəl yalnız oxunmaq rejiminə keçdi və buferi təmizləməyə çalışdı. Məlumatlar hara gedəcək? Onlar buferdə qalacaqlar. Amma biz buna əmin ola bilmərik - əgər başqa bir səhv olarsa, buna görə məlumat buferdə qalmayacaqsa... (Ünvanlar Aleksey Milovidov, Yandex, ClickHouse tərtibatçısı) Yoxsa qalacaq? Həmişə? Aleksey bizi hər şeyin yaxşı olacağına inandırır. Ona inanmamaq üçün heç bir səbəbimiz yoxdur. Ancaq yenə də: bufer cədvəllərindən istifadə etməsək, onlarla heç bir problem olmayacaq. İki dəfə çox masa yaratmaq da əlverişsizdir, baxmayaraq ki, prinsipcə böyük problemlər yoxdur. Plan budur.
Gəlin oxumaq haqqında danışaq
İndi oxumaq haqqında danışaq. Biz də burada öz alətimizi yazdıq. Deyəsən, yaxşı, niyə öz alətinizi bura yazın?.. Bəs Tabixdən kim istifadə edirdi? Nə isə, az adam əl qaldırdı... Bəs Tabixin ifası kimləri qane edir? Yaxşı, biz bundan məmnun deyilik və məlumatlara baxmaq üçün çox rahat deyil. Bu, analitika üçün yaxşıdır, lakin sadəcə baxmaq üçün optimallaşdırılmadığı aydındır. Beləliklə, mən öz interfeysimi yazdım.
Bu, çox sadədir - o, yalnız məlumatları oxuya bilər. Qrafik göstərməyi bilmir, heç nə etməyi bilmir. Amma o, bizə nə lazım olduğunu göstərə bilər: məsələn, cədvəldə neçə sıra var, nə qədər yer tutur (sütunlara bölmədən), yəni çox sadə interfeys bizə lazım olan şeydir.
Və Sequel Pro-ya çox bənzəyir, lakin yalnız Twitter-in Bootstrap-da və ikinci versiyada hazırlanmışdır. Soruşursan: "Yuri, niyə ikinci versiyada?" Hansı il? 2018? Ümumiyyətlə, mən bunu çoxdan “Muscle” (MySQL) üçün etdim və oradakı sorğularda sadəcə bir neçə sətir dəyişdim və o, “Clickhouse” üçün işləməyə başladı, buna görə xüsusi təşəkkürlər! Çünki təhlilçi "əzələ" ilə çox oxşardır və sorğular çox oxşardır - xüsusilə əvvəlcə çox rahatdır.
Yaxşı, o, cədvəlləri süzgəcdən keçirə bilər, cədvəlin strukturunu və məzmununu göstərə bilər, sıralamağa, sütunlar üzrə süzgəcdən keçirməyə imkan verir, nəticə ilə nəticələnən sorğunu, təsirə məruz qalan sətirləri (nəticədə nə qədər) göstərir, yəni verilənlərə baxmaq üçün əsas şeylər. Olduqca sürətli.
Redaktoru da var. Düzünü desəm, bütün redaktoru Tabix-dən oğurlamağa çalışdım, amma bacarmadım. Amma nədənsə işləyir. Prinsipcə, hamısı budur.
"Clickhouse" yuvalar üçün uyğundur
Sizə demək istəyirəm ki, Clickhouse, təsvir edilən bütün problemlərə baxmayaraq, loglar üçün çox uyğundur. Ən əsası, problemimizi həll edir - bu, çox sürətlidir və logları sütunlar üzrə süzgəcdən keçirməyə imkan verir. Prinsipcə, bufer masaları yaxşı performans göstərmədi, lakin ümumiyyətlə heç kim niyə bilmir ... Bəlkə indi harada probleminiz olacağını daha yaxşı bilirsiniz.
TCP? Ümumiyyətlə, VK-da UDP-dən istifadə etmək adətdir. TCP-dən istifadə edəndə isə... Təbii ki, heç kim mənə demədi: “Yuri, nə danışırsan! Siz edə bilməzsiniz, sizə UDP lazımdır." Məlum oldu ki, TCP o qədər də qorxulu deyil. Yeganə odur ki, yazdığınız on minlərlə aktiv birləşmələr varsa, onu bir az diqqətlə hazırlamaq lazımdır; lakin mümkündür və olduqca asandır.
Əgər hamı bizim ictimai “VK backend”imizə abunə olsa, “Kittenhouse” və “Mayak”ı HighLoad Siberia-da yerləşdirəcəyimə söz vermişdim... Bilirsiniz, hamı abunə deyildi... Əlbəttə, sizdən bizim kanalımıza abunə olmağı tələb etməyəcəyəm. ictimai. Hələ çoxunuz var, kimsə hətta inciyə bilər, amma yenə də abunə olun (və burada mən pişik gözləri kimi gözlər etməliyəm). budur . Çox sağ olun! Github bizimdir . Clickhouse ilə saçlarınız yumşaq və ipək kimi olacaq.
Qurğuşun: - Dostlar, indi suallara. Təşəkkür sertifikatını və VHS haqqında hesabatınızı təqdim etdikdən dərhal sonra.
Yuri Nasretdinov (bundan sonra YN): – Əgər yenicə başa çatsaydı, VHS ilə bağlı hesabatımı necə qeyd edə bildiniz?
Qurğuşun: – Siz “Clickhouse” un necə işləyəcəyini də tam müəyyən edə bilməzsiniz! Dostlar, suallara 5 dəqiqə!
Suallar
Tamaşaçıların sualı (bundan sonra Q adlandırılacaq): - Günortanız Xeyir. Hesabata görə çox sağ olun. Mənim iki sualım var. Mən qeyri-ciddi bir şeylə başlayacağam: diaqramlarda (3, 4, 7...) "Kittenhouse" adında t hərflərinin sayı pişiklərin məmnunluğuna təsir edirmi?
YN: - Nəyin miqdarı?
Z: - T hərfi. Üç t, haradasa üç t var.
YN: - Düzəltməmişəm? Yaxşı, əlbəttə ki, edir! Bunlar fərqli məhsullardır - bütün bu müddət ərzində sizi aldadırdım. Yaxşı, zarafat edirəm - fərqi yoxdur. Ah, burada! Xeyr, eyni şeydir, mən hərf səhvi etmişəm.
Z: - Çox sağ ol. İkinci sual ciddidir. Mən başa düşdüyüm qədər, Clickhouse-da bufer cədvəlləri yalnız yaddaşda yaşayır, diskə buferlənmir və buna görə də davamlı deyil.
YN: - Bəli.
Z: – Eyni zamanda, müştəriniz diskə tampon edir ki, bu da həmin qeydlərin çatdırılmasına müəyyən zəmanət verir. Lakin Clickhouse-da buna heç bir zəmanət verilmir. Zəmanətin necə, nəyə görə həyata keçirildiyini izah edin?.. Bu mexanizm daha ətraflı buradadır
YN: – Bəli, nəzəri cəhətdən burada heç bir ziddiyyət yoxdur, çünki Clickhouse yıxıldıqda, onu milyonlarla fərqli şəkildə aşkar edə bilərsiniz. Clickhouse qəzaya uğrayarsa (səhv bitərsə), siz, kobud desək, yazdığınız jurnalın bir azını geri çəkə və hər şeyin tam qaydasında olduğu andan başlaya bilərsiniz. Tutaq ki, siz bir dəqiqə geri çəkirsiniz, yəni bir dəqiqə ərzində hər şeyi qızartdığınız hesab olunur.
Z: – Yəni, “Kittenhouse” pəncərəni daha uzun saxlayır və yıxıldıqda onu tanıyıb geri sara bilirmi?
YN: - Amma bu nəzəri cəhətdən belədir. Praktikada biz bunu etmirik və etibarlı çatdırılma sıfırdan sonsuzluğa qədərdir. Ancaq orta hesabla bir. Biz razıyıq ki, əgər Clickhouse nədənsə qəzaya uğrayarsa və ya serverlər “yenidən işə salınsa”, bir az itiririk. Bütün digər hallarda heç nə olmayacaq.
Z: - Salam. Əvvəldən mənə elə gəldi ki, siz hesabatın əvvəlindən həqiqətən də UDP-dən istifadə edəcəksiniz. Sizdə http var, bütün bunlar... Və təsvir etdiyiniz problemlərin əksəriyyəti, mənim başa düşdüyüm kimi, məhz bu həll yolu ilə yaranıb...
YN: - TCP-dən nə istifadə edirik?
Z: - Əslində bəli.
YN: -No.
Z: – Məhz fasthttp ilə probleminiz oldu, bağlantıda probleminiz oldu. Əgər siz indicə UDP-dən istifadə etsəydiniz, özünüzə bir qədər vaxt qənaət edərdiniz. Yaxşı, uzun mesajlarla və ya başqa bir şeylə bağlı problemlər olacaq ...
YN: - Nə ilə?
Z: – Uzun mesajlarla, ola bilsin ki, MTU-ya uyğun gəlmir, başqa bir şey... Yaxşı, öz problemləri ola bilər. Sual budur: niyə UDP olmasın?
YN: – İnanıram ki, TCP/IP-ni inkişaf etdirən müəlliflər məndən daha ağıllıdırlar və paketləri necə seriallaşdırmağı (onların getməsi üçün) məndən yaxşı bilirlər, eyni zamanda göndərmə pəncərəsini tənzimləyirlər, şəbəkəni həddən artıq yükləməzlər, nə ilə bağlı rəy verirlər. oxunmur, qarşı tərəflə hesablaşmır... Bütün bu problemlər, məncə, UDP-də mövcud olardı, yalnız mən özüm və çox güman ki, eyni şeyi həyata keçirmək üçün yazdığımdan daha çox kod yazmalı idim. pis. C-də yazmağı heç sevmirəm, qoy orada...
Z: - Sadəcə rahatdır! Yaxşı göndərildi və heç nə gözləməyin - bu, tamamilə asinxrondur. Hər şeyin yaxşı olduğu barədə bildiriş gəldi - bu, gəldi; Əgər gəlmirsə, deməli, pisdir.
YN: – Mənə hər ikisi lazımdır – həm çatdırılma zəmanəti ilə, həm də çatdırılma zəmanəti olmadan göndərə bilməliyəm. Bunlar iki fərqli ssenaridir. Mən bəzi qeydləri itirməməliyəm və ya səbəblə onları itirməməliyəm.
Z: - Vaxt itirməyəcəyəm. Bunu daha çox müzakirə etmək lazımdır. Çox sağ ol.
Qurğuşun: – Kimin sualı var – əllər göyə!
Z: - Salam, mən Saşayam. Hesabatın ortasında bir yerdə belə bir hiss yarandı ki, TCP-dən əlavə, hazır bir həlldən - bir növ Kafkadan istifadə etmək olar.
YN: – Yaxşı... Mən sizə dedim ki, ara serverlərdən istifadə etmək istəmirəm, çünki... Kafkada belə çıxır ki, on min hostumuz var; əslində bizim daha çox - on minlərlə hostumuz var. Kafka ilə heç bir etibarnamə olmadan etmək də ağrılı ola bilər. Bundan əlavə, ən əsası, hələ də "gecikmə" verir, ehtiyacınız olan əlavə hostlar verir. Ancaq mən onlara sahib olmaq istəmirəm - istəyirəm ...
Z: "Ancaq sonda hər halda belə oldu."
YN: - Xeyr, ev sahibləri yoxdur! Bütün bunlar Clickhouse hostlarında işləyir.
Z: - Yaxşı, və əksinə olan "Kittenhouse" - harada yaşayır?
YN: – Clickhouse hostunda diskə heç nə yazmır.
Z: - Tutaq ki.
Qurğuşun: - Razısınız? Sizə maaş verə bilərik?
Z: - Bəli sən bacararsan. Əslində, eyni şeyi əldə etmək üçün bir çox balta var və indi - TCP mövzusunda əvvəlki cavab, mənim fikrimcə, bu vəziyyətə ziddir. Mənə elə gəlir ki, hər şeyi dizlərim üzərində çox az vaxtda etmək olardı.
YN: – Həm də niyə Kafkadan istifadə etmək istəmədim, çünki Clickhouse Telegram çatında kifayət qədər çox şikayətlər var idi ki, məsələn, Kafkadan gələn mesajlar itib. Kafkanın özündən deyil, Kafka və Klikhausun inteqrasiyasında; ya da bir şey oraya qoşulmadı. Kobud desək, o zaman Kafkaya müştəri yazmaq lazım gələcəkdi. Düşünmürəm ki, daha sadə və ya daha etibarlı bir həll ola bilər.
Z: – Mənə deyin, niyə növbələri və ya bir növ ümumi avtobusu sınamadınız? Asinxroniya ilə qeydləri növbə ilə göndərə və cavabı növbə vasitəsilə asinxron şəkildə ala biləcəyinizi söylədiyiniz üçün?
YN: – Zəhmət olmasa təklif edin, hansı növbələrdən istifadə etmək olar?
Z: – İstənilən, hətta onların qaydasında olduğuna zəmanət olmasa da. Bir növ Redis, RMQ...
YN: – Mənə elə gəlir ki, Redis çox güman ki, Clickhouse-u çıxaran bir hostda (bir neçə server mənasında) belə bir əlavə həcmini çəkə bilməyəcək. Mən bunu heç bir sübutla dəstəkləyə bilmərəm (mən bunu müqayisə etməmişəm), amma mənə elə gəlir ki, Redis burada ən yaxşı həll yolu deyil. Prinsipcə, bu sistem improvizə edilmiş mesaj növbəsi hesab edilə bilər, lakin bu, yalnız "Clickhouse" üçün hazırlanmışdır.
Qurğuşun: - Yuri, çox sağ olun. Sual-cavabları burada bitirməyi və sual verənlərdən hansına kitabı verəcəyimizi deməyi təklif edirəm.
YN: – İlk sual verənə kitab vermək istərdim.
Qurğuşun: - Əla! Əla! Əla! Çox sağ olun!
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com