ClickHouse ixtisaslaşmış sistem olduğundan istifadə edərkən onun arxitekturasının xüsusiyyətlərini nəzərə almaq vacibdir. Bu hesabatda Aleksey ClickHouse istifadə edərkən səmərəsiz işə səbəb ola biləcək tipik səhvlərin nümunələri haqqında danışacaq. Praktik nümunələrdən istifadə edərək, bu və ya digər məlumatların işlənməsi sxeminin seçilməsinin performansı böyüklük sırasına görə necə dəyişə biləcəyini göstərəcəyik.
Hamıya salam! Mənim adım Aleksey, mən ClickHouse-u edirəm.
Birincisi, sizi dərhal razı salmağa tələsirəm, bu gün sizə ClickHouse-un nə olduğunu deməyəcəyəm. Düzünü desəm, bundan bezmişəm. Bunun nə olduğunu hər dəfə sizə deyirəm. Və yəqin ki, hər kəs artıq bilir.
Bunun əvəzinə sizə mümkün rakenin nə olduğunu, yəni ClickHouse-dan necə sui-istifadə edilə biləcəyini söyləyəcəyəm. Əslində, qorxmamalısınız, çünki biz ClickHouse-u sadə, rahat və qutudan kənar işləyən bir sistem kimi inkişaf etdiririk. Hər şeyi quraşdırılıb, heç bir problemi yoxdur.
Ancaq yenə də nəzərə almaq lazımdır ki, bu sistem ixtisaslaşmışdır və bu sistemi rahatlıq zonasından çıxaracaq qeyri-adi istifadə vəziyyətinə asanlıqla rast gələ bilərsiniz.
Beləliklə, dırmıqlar nədir? Əsasən açıq-aşkar şeylər haqqında danışacağam. Hər şey hər kəsə aydındır, hər kəs hər şeyi başa düşür və belə ağıllı olduqlarına sevinə bilər, başa düşməyənlər isə yeni bir şey öyrənəcəklər.
Təəssüf ki, tez-tez baş verən ilk ən sadə nümunə kiçik partiyalarla çox sayda əlavələr, yəni çox sayda kiçik əlavələrdir.
ClickHouse-un əlavəni necə yerinə yetirdiyini nəzərə alsaq, bir sorğuda ən azı bir terabayt məlumat göndərə bilərsiniz. Problem deyil.
Və gəlin görək tipik performans nə olacaq. Məsələn, Yandex.Metrics məlumatları olan bir cədvəlimiz var. Xitlər. 105 bəzi sütunlar. 700 bayt sıxılmamış. Və bir milyon sətirdən ibarət partiyaları yaxşı şəkildə daxil edəcəyik.
MergeTree cədvəlinə daxil edirik, saniyədə yarım milyon sıra əldə edilir. Əla. Təkrarlanan cədvəldə - bir az daha az olacaq, saniyədə təxminən 400 sıra.
Əgər kvorum əlavəsini yandırsanız, saniyədə 250 dəfə bir az daha az, lakin yenə də layiqli performans əldə edəcəksiniz. Kvorumun daxil edilməsi ClickHouse*-da sənədləşdirilməmiş xüsusiyyətdir.
* 2020-ci ildən, .
Səhv etsəniz nə olar? MergeTree cədvəlinə bir sıra daxil edirik və saniyədə 59 sıra alırıq. Bu, 10 dəfə yavaşdır. ReplicatedMergeTree-də - saniyədə 000 sıra. Və kvorum açılırsa, saniyədə 6 sətir əldə edilir. Mənim fikrimcə, bu, bir növ tam axmaqlıqdır. Necə belə yavaşlaya bilərsən? Hətta köynəyimdə belə yazılıb ki, ClickHouse sürətini azaltmamalıdır. Ancaq buna baxmayaraq, bəzən olur.
Əslində, bu, bizim çatışmazlığımızdır. Biz bunu yaxşı işlədə bilərdik, amma etmədik. Biz isə bunu etmədik, çünki ssenarimizə ehtiyac yox idi. Artıq dəstələrimiz var idi. Biz yalnız girişdə partiyalar aldıq və heç bir problem yoxdur. Onu qoşun və hər şey yaxşı işləyir. Ancaq təbii ki, hər cür ssenarilər mümkündür. Məsələn, məlumatların yaradıldığı bir dəstə serveriniz olduqda. Və onlar məlumatları tez-tez daxil etmirlər, lakin yenə də tez-tez əlavələr alırlar. Və birtəhər bunun qarşısını almaq lazımdır.
Texniki nöqteyi-nəzərdən, nəticə ondan ibarətdir ki, ClickHouse-a daxil etdiyiniz zaman məlumatlar heç bir memtable-ə daxil olmur. Bizim real MergeTree log strukturumuz belə yoxdur, sadəcə MergeTree var, çünki orada nə log, nə də memTable var. Biz dərhal məlumatları artıq sütunlara parçalanmış fayl sisteminə yazırıq. Əgər 100 sütununuz varsa, 200-dən çox faylın ayrı bir kataloqa yazılması lazımdır. Bütün bunlar çox ağırdır.
Və sual yaranır: "Bunu necə düzgün etmək olar?" Belə bir vəziyyət varsa, hələ də bir şəkildə ClickHouse-a məlumat yazmalısınız.
Metod 1. Bu, ən asan yoldur. Bir növ paylanmış növbədən istifadə edin. Məsələn, Kafka. Siz sadəcə məlumatları Kafkadan çıxarırsınız, biz onu saniyədə bir dəfə yığırıq. Və hər şey yaxşı olacaq, qeyd edirsən, hər şey yaxşı işləyir.
Dezavantajlar Kafkanın başqa bir çətin paylanmış sistem olmasıdır. Şirkətinizdə artıq Kafka varsa, onu da başa düşürəm. Yaxşıdır, rahatdır. Ancaq orada deyilsə, başqa bir paylanmış sistemi layihənizə sürükləməzdən əvvəl üç dəfə düşünməlisiniz. Və buna görə də alternativləri nəzərdən keçirməyə dəyər.
Metod 2. Burada belə köhnə məktəb alternativi və eyni zamanda çox sadədir. Günlüklərinizi yaradan bir növ serveriniz varmı? Və o, sadəcə qeydlərinizi bir fayla yazır. Və saniyədə bir dəfə, məsələn, bu faylın adını dəyişdiririk, yenisini açırıq. Və ya cron və ya hansısa demon tərəfindən ayrıca skript ən köhnə faylı götürür və ClickHouse-a yazır. Əgər saniyədə bir dəfə loglar yazsanız, onda hər şey yaxşı olacaq.
Lakin bu metodun dezavantajı ondan ibarətdir ki, əgər logların yaradıldığı serveriniz hardasa yoxa çıxıbsa, o zaman məlumatlar da yox olacaq.
Metod 3. Başqa bir maraqlı yol var ki, o da ümumiyyətlə müvəqqəti fayllar olmadan. Məsələn, sizin bir növ reklam əyiriciniz və ya məlumat yaradan başqa maraqlı demonunuz var. Və bir dəstə məlumatı birbaşa RAM-da, buferdə toplaya bilərsiniz. Kifayət qədər vaxt keçdikdə siz bu buferi kənara qoyursunuz, yenisini yaradırsınız və artıq yığılmışları ClickHouse-a ayrı bir mövzuya daxil edirsiniz.
Digər tərəfdən, məlumat da kill -9 ilə yox olur. Serveriniz sıradan çıxsa, bu məlumatları itirəcəksiniz. Və başqa bir problem odur ki, verilənlər bazasına yaza bilməsəniz, məlumatlarınız RAM-da toplanacaq. Və ya RAM tükənir, ya da sadəcə məlumatları itirirsiniz.
Metod 4. Başqa bir maraqlı üsul. Hər hansı bir server prosesiniz varmı. Və o, məlumatları bir anda ClickHouse-a göndərə bilər, lakin bunu bir əlaqədə edə bilər. Məsələn, mən köçürmə kodlaşdırması ilə http sorğusu göndərdim: əlavə ilə parçalanmış. Və o, çox nadir hallarda parçalar yaradır, hər bir sətri göndərə bilərsiniz, baxmayaraq ki, bu məlumatların çərçivəyə salınması üçün əlavə xərc olacaq.
Lakin bu halda məlumatlar dərhal ClickHouse-a göndəriləcək. Və ClickHouse özü onları bufer edəcək.
Amma problemlər də var. İndi siz məlumatlarınızı itirəcəksiniz, o cümlədən prosesinizin nə vaxt öldürülməsi və ClickHouse prosesinin öldürülməsi, çünki bu, natamam əlavə olacaq. Və ClickHouse-da əlavələr cərgələrin ölçüsündə müəyyən edilmiş həddə qədər atomikdir. Prinsipcə, bu maraqlı bir yoldur. Həmçinin istifadə oluna bilər.
Metod 5. Burada başqa bir maraqlı üsul var. Bu, məlumatların yığılması üçün icma tərəfindən hazırlanmış bir növ serverdir. Mən özüm baxmamışam, ona görə də heç nəyə zəmanət verə bilmərəm. Bununla belə, ClickHouse-un özü üçün heç bir zəmanət yoxdur. Bu, həm də açıq mənbədir, lakin digər tərəfdən, təmin etməyə çalışdığımız bəzi keyfiyyət standartlarına alışa bilərsiniz. Amma bunun üçün - bilmirəm, GitHub-a gedin, koda baxın. Bəlkə də yaxşı bir şey yazıblar.
*2020-ci ildən etibarən də nəzərə alınmalıdır .
Metod 6. Digər üsul Bufer cədvəllərindən istifadə etməkdir. Bu metodun üstünlüyü ondan ibarətdir ki, istifadə etməyə başlamaq çox asandır. Bufer cədvəli yaradın və ona daxil edin.
Ancaq çatışmazlıq problemin tam həll edilməməsidir. MergeTree tipli bir sürətdə məlumatları saniyədə bir toplu ilə qruplaşdırmalısınızsa, bufer cədvəlindəki sürətlə, saniyədə ən azı bir neçə minə qədər qruplaşdırmalısınız. Saniyədə 10-dən çox olsa, yenə də pis olacaq. Partiyalara daxil etsəniz, orada saniyədə yüz min sətir əldə edildiyini gördünüz. Və bu, artıq kifayət qədər ağır məlumatlar üzərindədir.
Həm də bufer cədvəllərində jurnal yoxdur. Və serverinizdə bir şey səhv olarsa, məlumatlar itiriləcəkdir.
Bir bonus olaraq bu yaxınlarda ClickHouse-da Kafkadan məlumat toplamaq imkanımız oldu. Masa mühərriki var - Kafka. Siz sadəcə olaraq yaradırsınız. Və ona maddiləşdirilmiş görünüşlər asmaq olar. Bu zaman o, məlumatları Kafkadan çıxaracaq və sizə lazım olan cədvəllərə daxil edəcək.
Bu fürsətdə xüsusilə sevindirici olan odur ki, biz buna nail ola bilmədik. Bu icma xüsusiyyətidir. “İcma xüsusiyyəti” deyəndə isə heç bir nifrət etmədən deyirəm. Kodu oxuduq, nəzərdən keçirdik, yaxşı işləməlidir.
* 2020-ci ildən etibarən oxşar dəstək var .
Məlumat daxil edərkən başqa nə əlverişsiz və ya gözlənilməz ola bilər? Dəyərlər daxil etsəniz və dəyərlərə bəzi hesablanmış ifadələr yazsanız. Məsələn, now() da qiymətləndirilmiş ifadədir. Və bu halda, ClickHouse hər bir sətir üçün bu ifadələrin tərcüməçisini işə salmağa məcbur olur və performans böyük ölçüdə azalacaq. Bunun qarşısını almaq daha yaxşıdır.
* hazırda problem tam həll olunub, VALUES-də ifadələrdən istifadə edərkən daha performans reqressiyası yoxdur.
Bəzi problemlərin ola biləcəyi başqa bir nümunə, bir partiyadakı məlumatlarınızın bir dəstə bölməyə aid olmasıdır. Varsayılan olaraq, aya görə ClickHouse bölmələri. Bir milyon cərgədən ibarət bir dəstə daxil etsəniz və bir neçə il ərzində məlumat varsa, orada bir neçə onlarla bölməniz olacaq. Və bu, bir neçə on dəfə daha kiçik partiyaların olacağına bərabərdir, çünki içəridə həmişə əvvəlcə arakəsmələrə bölünürlər.
* bu yaxınlarda ClickHouse-da eksperimental rejimdə, problemi demək olar ki, tamamilə həll edən qabaqcadan yazma jurnalı ilə RAM-da parçaların və parçaların kompakt formatı üçün dəstək əlavə edildi.
İndi problemin ikinci növünü - məlumatların yazılmasını nəzərdən keçirin.
Məlumatların yazılması sərt, bəzən isə sətirli ola bilər. String - bu, indicə götürdüyünüz və string tipli bütün sahələrin olduğunu bildirdiyiniz zamandır. Bu pisdir. Bunu etməli deyilsən.
Gəlin bunu necə düzgün edəcəyimizi anlayaq ki, siz bizim bəzi sahəmiz, sətirimiz var və qoy ClickHouse bunu öz-özünə başa düşsün, amma mən buxar vannası qəbul etməyəcəyəm. Ancaq yenə də bir az səy göstərməyə dəyər.
Məsələn, bizim bir IP ünvanımız var. Bir halda biz onu sətir kimi saxladıq. Məsələn, 192.168.1.1. Əks halda, UInt32* tipli bir sıra olacaq. IPv32 ünvanı üçün 4 bit kifayətdir.
Birincisi, qəribə də olsa, məlumatlar təxminən eyni şəkildə sıxılacaq. Fərq olacaq, əlbəttə, amma o qədər də böyük deyil. Beləliklə, diskin giriş/çıxışı ilə bağlı heç bir xüsusi problem yoxdur.
Lakin CPU vaxtı və sorğunun icra müddətində ciddi fərq var.
Nömrələr kimi saxlanılırsa, unikal IP ünvanlarının sayını hesablayaq. Saniyədə 137 milyon sətir çıxır. Xətlərlə eynidirsə, saniyədə 37 milyon sətir. Bu təsadüfün niyə baş verdiyini bilmirəm. Bu xahişləri mən özüm etmişəm. Ancaq buna baxmayaraq, təxminən 4 dəfə yavaş.
Və disk sahəsindəki fərqi hesablasanız, fərq də var. Fərq təxminən dörddə birdir, çünki unikal IP ünvanları olduqca çoxdur. Əgər az sayda fərqli dəyərə malik sətirlər olsaydı, onlar lüğətdə sakitcə təxminən eyni həcmdə sıxılmış olardı.
Dörd dəfə vaxt fərqi isə yolda yatmaq deyil. Ola bilsin ki, siz, əlbəttə, vecinə deyilsiniz, amma belə bir fərq görəndə ürəyim sıxılır.
Fərqli halları nəzərdən keçirək.
1. Bir neçə fərqli unikal dəyərə malik olduğunuz bir hal. Bu halda, yəqin ki, bildiyiniz və istənilən DBMS üçün istifadə edə biləcəyiniz sadə təcrübədən istifadə edirik. Bütün bunlar təkcə ClickHouse üçün deyil. Sadəcə rəqəmsal identifikatorları verilənlər bazasına yazın. Və siz tətbiqinizin tərəfində sətirlərə və geriyə çevirə bilərsiniz.
Məsələn, sizin bir bölgəniz var. Və siz onu sətir kimi saxlamağa çalışırsınız. Və orada yazılacaq: Moskva və Moskva vilayəti. Orada "Moskva" yazıldığını görəndə, bu hələ heç nə deyil və MO olanda birtəhər kədərlənir. Bu, neçə baytdır.
Bunun əvəzinə biz sadəcə olaraq Ulnt32 nömrəsini və 250-ni yazırıq. Yandex-də bizdə 250 var, lakin sizinki fərqli ola bilər. Hər halda, deyim ki, ClickHouse-un geobaza ilə işləmək üçün daxili qabiliyyəti var. Siz sadəcə olaraq iyerarxik daxil olmaqla, bölgələri olan bir kataloq yazırsınız, yəni Moskva, Moskva vilayəti və sizə lazım olan hər şey olacaq. Və sorğu səviyyəsində çevirə bilərsiniz.
İkinci seçim təxminən eynidir, lakin ClickHouse daxilində dəstəyi ilə. Bu Enum məlumat növüdür. Siz sadəcə olaraq Enum daxilində lazım olan bütün dəyərləri yazırsınız. Məsələn, cihazın növü və orada yazın: masa üstü, mobil, planşet, televizor. Yalnız 4 seçim.
Dezavantaj odur ki, vaxtaşırı dəyişdirmək lazımdır. Yalnız bir seçim əlavə edildi. Dəyişən masa düzəldirik. Əslində, ClickHouse-da cədvəli dəyişdirmək pulsuzdur. Xüsusilə Enum üçün pulsuzdur, çünki diskdəki məlumatlar dəyişmir. Ancaq buna baxmayaraq, dəyişdirmə masada * kilidini əldə edir və bütün seçimlər tamamlanana qədər gözləməlidir. Və yalnız bu dəyişiklik həyata keçirildikdən sonra, yəni hələ də bəzi narahatlıqlar var.
* ClickHouse-un son versiyalarında ALTER tamamilə bloklanmır.
ClickHouse üçün olduqca unikal başqa bir seçim xarici lüğətlərin əlaqəsidir. Siz ClickHouse-da nömrələr yaza və qovluqlarınızı sizin üçün əlverişli olan istənilən sistemdə saxlaya bilərsiniz. Məsələn, istifadə edə bilərsiniz: MySQL, Mongo, Postgres. Siz hətta bu məlumatları http vasitəsilə göndərəcək öz mikroservisinizi yarada bilərsiniz. ClickHouse səviyyəsində isə bu məlumatları rəqəmlərdən sətirlərə çevirəcək funksiya yazırsınız.
Bu, xarici masada birləşməni yerinə yetirmək üçün ixtisaslaşmış, lakin çox səmərəli üsuldur. Və iki variant var. Seçimlərdən birində bu məlumatlar tam yaddaşda saxlanılacaq, RAM-da tam olaraq mövcud olacaq və müəyyən fasilələrlə yenilənəcək. Və başqa bir seçimdə, bu məlumat RAM-a uyğun gəlmirsə, onu qismən keşləyə bilərsiniz.
Budur bir nümunə. Yandex.Direct var. Bir də reklam şirkəti və bannerlər var. Yəqin ki, on milyonlarla reklam şirkəti var. Və təxminən RAM-a uyğundur. Və milyardlarla bannerlər var, onlar uyğun gəlmir. Və biz MySQL-dən keşlənmiş lüğətdən istifadə edirik.
Yeganə problem ondadır ki, hit dərəcəsi 100%-ə yaxın olarsa, keşlənmiş lüğət yaxşı işləyəcək. Daha kiçikdirsə, hər bir məlumat paketi üçün sorğuları emal edərkən, əslində çatışmayan açarları götürmək və MySQL-dən məlumat götürmək üçün getmək lazımdır. ClickHouse haqqında, mən hələ də zəmanət verə bilərəm - bəli, yavaşlamır, digər sistemlər haqqında danışmayacağam.
Bir bonus olaraq, lüğətlər ClickHouse-da məlumatları geriyə doğru yeniləmək üçün çox asan bir yoldur. Yəni, reklam şirkətləri haqqında hesabatınız var idi, istifadəçi sadəcə olaraq reklam şirkətini dəyişdi və bütün köhnə məlumatlarda, bütün hesabatlarda bu məlumatlar da dəyişdi. Sətirləri birbaşa cədvələ yazsanız, onları yeniləyə bilməyəcəksiniz.
Sətirləriniz üçün identifikatorları haradan əldə edəcəyinizi bilmədiyiniz zaman başqa bir yol. sadəcə hash edə bilərsiniz. Və ən asan seçim 64 bitlik hash götürməkdir.
Yeganə problem odur ki, əgər hash 64 bitdirsə, demək olar ki, toqquşmalarınız olacaq. Çünki bir milyard sətir varsa, onda ehtimal artıq hiss olunur.
Və reklam şirkətlərinin adını belə həşləmək çox yaxşı olmazdı. Fərqli şirkətlərin reklam kampaniyaları bir-birinə qarışsa, o zaman anlaşılmaz bir şey olacaq.
Və sadə bir hiylə var. Düzdür, bu, ciddi məlumatlar üçün də çox uyğun deyil, lakin bir şey çox ciddi deyilsə, sadəcə lüğət açarına başqa bir müştəri identifikatoru əlavə edin. Və sonra toqquşmalarınız olacaq, ancaq bir müştəri daxilində. Biz Yandex.Metrica-da link xəritəsi üçün bu üsuldan istifadə edirik. Orada url-lərimiz var, hashları saxlayırıq. Və biz bilirik ki, münaqişələr var, əlbəttə. Ancaq bir səhifə göstərildikdə, bir istifadəçi üçün bir səhifədə bəzi url-lərin bir-birinə yapışması ehtimalı və bunun fərq ediləcəyi ehtimalı, o zaman buna laqeyd yanaşmaq olar.
Bonus olaraq, bir çox əməliyyatlar üçün yalnız hashlər kifayətdir və strings özləri heç bir yerdə saxlanıla bilməz.
Sətirlər qısadırsa, veb sayt domenləri kimi başqa bir nümunə. Onlar olduğu kimi saxlanıla bilər. Və ya, məsələn, brauzer dili ru 2 baytdır. Təbii ki, baytlara yazığım gəlir, amma narahat olmayın, 2 bayt heyf deyil. Xahiş edirəm olduğu kimi saxlayın, narahat olmayın.
Başqa bir hal, əksinə, çoxlu simlərin olması və eyni zamanda onların içərisində çoxlu unikalların olması və hətta dəstin potensial olaraq qeyri-məhdud olmasıdır. Tipik bir nümunə axtarış ifadələri və ya URL-lərdir. Axtarış ifadələri, o cümlədən yazı səhvlərinə görə. Gəlin görək gündə neçə unikal axtarış ifadəsi var. Və belə çıxır ki, onlar bütün hadisələrin demək olar ki, yarısıdır. Və bu vəziyyətdə, məlumatları normallaşdırmaq, identifikatorları saymaq, ayrı bir cədvələ qoymaq lazım olduğunu düşünə bilərsiniz. Amma bunu etməli deyilsən. Sadəcə bu xətləri olduğu kimi saxlayın.
Daha yaxşı - heç bir şey icad etməyin, çünki onu ayrıca saxlasanız, birləşməni etməlisiniz. Və bu birləşmə ən yaxşı halda yaddaşa təsadüfi girişdir, əgər hələ də yaddaşa uyğun gəlirsə. Əgər uyğun gəlmirsə, deməli, ümumiyyətlə problemlər olacaq.
Məlumatlar yerində saxlanılırsa, o zaman fayl sistemindən sadəcə düzgün qaydada oxunur və hər şey qaydasındadır.
URL-ləriniz və ya başqa bir mürəkkəb uzun sətiriniz varsa, əvvəlcədən bir az sıxmağı hesablaya və ayrı bir sütuna yaza biləcəyinizi düşünməlisiniz.
Məsələn, URL-lər üçün domeni ayrıca saxlaya bilərsiniz. Əgər həqiqətən domenə ehtiyacınız varsa, sadəcə bu sütundan istifadə edin və url-lər yalan olacaq və siz onlara toxunmayacaqsınız.
Gəlin görək fərq nədir. ClickHouse domeni hesablayan xüsusi funksiyaya malikdir. Çox sürətlidir, biz onu optimallaşdırmışıq. Düzünü desəm, hətta RFC-yə uyğun gəlmir, amma buna baxmayaraq, ehtiyacımız olan hər şeyi nəzərə alır.
Və bir halda, biz sadəcə URL-ləri əldə edəcəyik və domeni hesablayacağıq. 166 millisaniyə çıxır. Hazır bir domen götürsəniz, bu, cəmi 67 millisaniyə, yəni demək olar ki, üç dəfə daha sürətli olur. Və daha sürətli, bəzi hesablamalar aparmalı olduğumuz üçün deyil, daha az məlumat oxuduğumuz üçün.
Nədənsə, daha yavaş olan bir sorğu saniyədə gigabaytlarda daha çox sürət alır. Çünki daha çox gigabayt oxuyur. Bu, tamamilə lazımsız məlumatlardır. Sorğu daha sürətli işləyir, lakin tamamlanması daha uzun çəkir.
Və diskdəki məlumatların miqdarına baxsanız, URL-nin 126 meqabayt, domenin isə cəmi 5 meqabayt olduğu ortaya çıxır. 25 dəfə az olur. Bununla belə, sorğu hələ də cəmi 4 dəfə sürətlidir. Ancaq bunun səbəbi məlumatların isti olmasıdır. Və soyuq olsaydı, diskin giriş/çıxışı səbəbindən yəqin ki, 25 dəfə daha sürətli olardı.
Yeri gəlmişkən, əgər domenin URL-dən nə qədər az olduğunu qiymətləndirsəniz, təxminən 4 dəfə olduğu ortaya çıxır.Amma nədənsə diskdəki məlumatlar 25 dəfə azdır. Niyə? Sıxılma səbəbiylə. Və url sıxılır və domen sıxılır. Ancaq tez-tez url bir dəstə zibil ehtiva edir.
Və əlbəttə ki, düzgün dəyərlər və ya uyğunluq üçün xüsusi olaraq hazırlanmış düzgün məlumat növlərindən istifadə etməyə dəyər. Əgər siz IPv4-dəsinizsə, UInt32*-ni saxlayın. Əgər IPv6 varsa, onda FixedString(16), çünki IPv6 ünvanı 128 bitdir, yəni birbaşa ikili formatda saxlayın.
Bəs bəzən IPv4, bəzən isə IPv6 ünvanlarınız varsa nə olacaq? Bəli, hər ikisini saxlaya bilərsiniz. IPv4 üçün bir sütun, IPv6 üçün başqa. Əlbəttə ki, IPv4-ü IPv6 ilə əlaqələndirmək imkanı var. Bu da işləyəcək, lakin sorğularınızda tez-tez IPv4 ünvanına ehtiyacınız varsa, onu ayrı bir sütunda yerləşdirmək yaxşı olardı.
* ClickHouse indi məlumatları rəqəmlər qədər səmərəli saxlayan, lakin onları sətirlər kimi rahat şəkildə təmsil edən ayrıca IPv4, IPv6 məlumat növlərinə malikdir.
Məlumatları əvvəlcədən emal etməyə dəyər olduğunu da qeyd etmək vacibdir. Məsələn, bəzi xam loglar sizə gəlir. Və bəlkə də onları dərhal ClickHouse-a qoymamalısınız, baxmayaraq ki, heç bir şey etmək çox cəlbedicidir və hər şey işləyəcək. Ancaq hələ də mümkün olan hesablamaları aparmağa dəyər.
Məsələn, brauzer versiyası. Barmağımı göstərmək istəmədiyim bəzi qonşu şöbədə brauzer versiyası orada belə, yəni sətir kimi saxlanılır: 12.3. Və sonra hesabat hazırlamaq üçün bu sətri götürüb massivə, sonra isə massivin birinci elementinə bölürlər. Təbii ki, hər şey yavaşlayır. Soruşdum ki, niyə belə edirlər. Mənə dedilər ki, vaxtından əvvəl optimallaşdırmanı sevmirlər. Mən isə vaxtından əvvəl pessimizmi sevmirəm.
Beləliklə, bu halda 4 sütuna bölmək daha düzgün olardı. Burada qorxmayın, çünki bu ClickHouse-dur. ClickHouse sütun verilənlər bazasıdır. Və nə qədər səliqəli kiçik sütunlar, bir o qədər yaxşıdır. 5 BrowserVersion olacaq, 5 sütun düzəldin. Bu yaxşıdır.
İndi çox uzun sətirləriniz, çox uzun massivləriniz varsa nə edəcəyinizi düşünün. Onların ümumiyyətlə ClickHouse-da saxlanmasına ehtiyac yoxdur. Bunun əvəzinə, ClickHouse-da yalnız bəzi identifikatorları saxlaya bilərsiniz. Və bu uzun xətlər onları başqa bir sistemə itələyir.
Məsələn, analitik xidmətlərimizdən birinin bəzi hadisə parametrləri var. Əgər hadisələrə çoxlu parametrlər gəlirsə, biz sadəcə olaraq rastlaşdığımız ilk 512-ni saxlayırıq.Çünki 512 heyif deyil.
Əgər məlumat növlərinizə qərar verə bilmirsinizsə, o zaman məlumatları ClickHouse-a da yaza bilərsiniz, ancaq müvəqqəti məlumatlar üçün xüsusi olan Log tipli müvəqqəti cədvələ. Bundan sonra, orada hansı dəyərlərin paylanmasına sahib olduğunuzu, ümumiyyətlə orada nə olduğunu təhlil edə və düzgün növləri təşkil edə bilərsiniz.
* İndi ClickHouse məlumat növünə malikdir bu, daha az səylə sətirləri səmərəli şəkildə saxlamağa imkan verir.
İndi başqa bir maraqlı hadisəyə nəzər salın. Bəzən insanlar üçün işlər qəribə şəkildə işləyir. Mən gedib bunu görürəm. Və dərhal görünür ki, bunu MySQL 3.23 versiyasını qurmaqda böyük təcrübəsi olan çox təcrübəli, ağıllı admin edib.
Burada min cədvəl görürük, bunların hər birinin minə bölünməsinin qalan hissəsi aydın deyil.
Prinsipcə, mən başqalarının təcrübəsinə, o cümlədən bu təcrübənin hansı əzabın qazana biləcəyini başa düşməyə hörmət edirəm.
Və səbəblər az-çox aydındır. Bunlar digər sistemlərlə işləyərkən yığılmış köhnə stereotiplərdir. Məsələn, MyISAM cədvəllərində qruplaşdırılmış əsas açar yoxdur. Və məlumat mübadiləsinin bu yolu eyni funksionallığı əldə etmək üçün ümidsiz bir cəhd ola bilər.
Başqa bir səbəb, böyük masalarda hər hansı dəyişdirmə əməliyyatının aparılmasının çətin olmasıdır. Hər şey bloklanacaq. Baxmayaraq ki, MySQL-in müasir versiyalarında bu problem artıq o qədər də ciddi deyil.
Və ya, məsələn, microsharding, lakin bu barədə daha sonra.
ClickHouse-da bunu etmək lazım deyil, çünki birincisi, əsas açar qruplaşdırılıb, məlumatlar əsas açar tərəfindən sıralanır.
Bəzən insanlar məndən soruşurlar: "ClickHouse-da diapazon sorğularının performansı cədvəlin ölçüsü ilə necə dəyişir?". Deyirəm heç dəyişmir. Məsələn, bir milyard cərgədən ibarət bir cədvəliniz var və bir milyon cərgə oxuyursunuz. Hər şey yaxşıdır. Cədvəldə bir trilyon sıra varsa və siz bir milyon sətir oxuyursunuzsa, demək olar ki, eyni olacaq.
İkincisi, əl bölmələri kimi hər hansı bir hissə tələb olunmur. İçəri girib fayl sistemində olanlara baxsanız, görərsiniz ki, cədvəl olduqca ciddi bir şeydir. Və içəridə arakəsmələr kimi bir şey var. Yəni ClickHouse sizin üçün hər şeyi edir və əziyyət çəkməyə ehtiyac yoxdur.
Əlavə etmək/buraxmaq sütununu dəyişdirsəniz, ClickHouse-da dəyişiklik pulsuzdur.
Və siz kiçik cədvəllər hazırlamamalısınız, çünki sizin cədvəlinizdə 10 və ya 10 cərgə varsa, o zaman heç bir əhəmiyyəti yoxdur. ClickHouse gecikməni deyil, ötürmə qabiliyyətini optimallaşdıran bir sistemdir, ona görə də 000 sətir emal etməyin mənası yoxdur.
Bir böyük masadan istifadə etmək düzgündür. Köhnə stereotiplərdən qurtulun, hər şey yaxşı olacaq.
Bir bonus olaraq, ən son versiyada fərdi arakəsmələrdə hər cür texniki xidmət əməliyyatlarını yerinə yetirmək üçün ixtiyari bölmə açarı etmək imkanımız var.
Məsələn, sizə çoxlu kiçik cədvəllər lazımdır, məsələn, bəzi aralıq məlumatları emal etmək lazım olduqda, siz parçalar alırsınız və yekun cədvələ yazmadan əvvəl onlar üzərində transformasiya etməlisiniz. Bu iş üçün gözəl bir masa mühərriki var - StripeLog. Bu, TinyLog kimi, yalnız daha yaxşıdır.
* İndi ClickHouse-da daha çox şey var .
Başqa bir anti-naxış microshardingdir. Məsələn, məlumatları parçalamalısınız və 5 serveriniz var, sabah isə 6 server olacaq. Və bu məlumatları necə balanslaşdıracağınızı düşünürsünüz. Və əvəzində siz 5 parçaya deyil, 1 parçaya bölünürsünüz. Və sonra siz bu microshardların hər birini ayrıca serverə köçürürsünüz. Və bir serverdə uğur qazanacaqsınız, məsələn, 000 ClickHouse, məsələn. Ayrı-ayrı portlarda və ya ayrı verilənlər bazalarında ayrı nümunə.
Lakin ClickHouse-da bu çox yaxşı deyil. Çünki ClickHouse-un hətta bir nümunəsi bir sorğunu emal etmək üçün bütün mövcud server resurslarından istifadə etməyə çalışır. Yəni, bir növ serveriniz var və orada, məsələn, 56 prosessor nüvəsi var. Siz bir saniyə çəkən sorğu işlədirsiniz və o, 56 nüvədən istifadə edəcək. Və orada bir serverə 200 ClickHouse yerləşdirsəniz, onda 10 mövzunun başlayacağı ortaya çıxır. Ümumiyyətlə, hər şey çox pis olacaq.
Başqa bir səbəb, işin bu hallar üzrə paylanmasının qeyri-bərabər olmasıdır. Bəziləri daha tez, bəziləri isə gec bitirəcək. Bütün bunlar bir halda baş versəydi, ClickHouse özü məlumatların axınlar arasında necə düzgün paylanacağını anlayardı.
Başqa bir səbəb isə TCP üzərindən prosessorlararası əlaqənin olmasıdır. Məlumatlar seriyalaşdırılmalı, seriyadan çıxarılmalı və bu çox sayda mikroşarddır. Sadəcə işləməyəcək.
Başqa bir antipattern, baxmayaraq ki, onu antipattern adlandırmaq çətindir. Bu, böyük məbləğdə qabaqcadan yığılmadır.
Ümumiyyətlə, preagregatsiya yaxşıdır. Bir milyard cərgəniz var idi, siz onu birləşdirdiniz və 1 sıra oldu və indi sorğu dərhal icra olunur. Hər şey əladır. Siz bunu necə edə bilərsiniz. Və bunun üçün hətta ClickHouse-da məlumatlar daxil edildikdə artımlı aqreqasiya edən xüsusi AggregatingMergeTree cədvəl növü var.
Amma elə vaxtlar olur ki, biz bu kimi məlumatları birləşdirəcəyik və bu kimi məlumatları birləşdirəcəyik. Bəzi qonşu departamentlərdə hansını da demək istəmirəm, onlar əsas açarla yekunlaşdırmaq üçün SummingMergeTree cədvəllərindən istifadə edirlər və əsas açar kimi 20 sütun istifadə olunur. Hər ehtimala qarşı sui-qəsd üçün bəzi sütunların adını dəyişdim, amma bu qədər.
Və belə problemlər yaranır. Birincisi, əldə etdiyiniz məlumatların miqdarı çox da azalmır. Məsələn, üç dəfə azaldılır. Qeyri-məhdud məlumatlara malik olmaqdan irəli gələn limitsiz analitikanı ödəmək üçün üç dəfə yaxşı qiymət olardı. Məlumatlar ümumiləşdirilirsə, analitika əvəzinə yalnız acınacaqlı statistika əldə edirsiniz.
Və xüsusilə yaxşı nədir? Növbəti şöbədən olan bu adamlar gedin və bəzən əsas açara daha bir sütun əlavə etməyi xahiş etsinlər. Yəni biz məlumatları belə cəmləmişik və indi bir az daha çox istəyirik. Lakin ClickHouse-da dəyişdirmə əsas açarı yoxdur. Buna görə də C++ dilində bəzi skriptlər yazmalısınız. Və mən skriptləri sevmirəm, hətta onlar C++ dilində olsalar belə.
Əgər ClickHouse-un nə üçün yaradıldığına baxsanız, o zaman ümumiləşdirilməmiş məlumatlar məhz onun doğulduğu ssenaridir. Əgər siz ümumiləşdirilməmiş məlumatlar üçün ClickHouse istifadə edirsinizsə, deməli hər şeyi düzgün edirsiniz. Əgər toplayırsansa, bu bəzən bağışlana bilər.
Başqa bir maraqlı hal sonsuz döngədə sorğulardır. Mən bəzən hansısa istehsal serverinə gedirəm və oradakı şou proses siyahısına baxıram. Və hər dəfə dəhşətli bir şeyin baş verdiyini kəşf edirəm.
Məsələn, budur. Dərhal aydın olur ki, bir sorğuda hər şeyi etmək mümkün idi. Sadəcə olaraq url-i və siyahını ora yazın.
Niyə sonsuz döngədə bu cür sorğuların çoxu pisdir? İndeks istifadə edilmədikdə, eyni məlumat üzərində çoxlu keçidiniz olacaq. Amma əgər indeks istifadə olunursa, məsələn, ru-da əsas açarınız var və orada url = nəsə yazırsınız. Və bir url-nin cədvəldən oxunacağını düşünürsən, hər şey yaxşı olacaq. Amma həqiqətən yox. Çünki ClickHouse hər şeyi qrup halında edir.
Bir sıra məlumatları oxumaq lazım olduqda, o, bir az daha oxuyur, çünki ClickHouse-da indeks seyrəkdir. Bu indeks cədvəldə bir fərdi sıra tapmağa imkan vermir, yalnız bir növ diapazon. Və məlumatlar bloklarda sıxılır. Bir sətri oxumaq üçün bütün bloku götürüb onu açmaq lazımdır. Bir dəstə sorğu işlətsəniz, onların çoxlu kəsişmə nöqtələri olacaq və təkrar-təkrar görülən çox işiniz olacaq.
Bir bonus olaraq görə bilərsiniz ki, ClickHouse-da hətta meqabaytları və hətta yüzlərlə meqabaytı IN bölməsinə köçürməkdən qorxmamalısınız. Təcrübəmizdən xatırlayıram ki, MySQL-də IN bölməsində bir dəstə dəyər ötürsək, məsələn, orada bəzi nömrələrin 100 meqabaytını keçirsək, MySQL 10 giqabayt yaddaş yeyir və başqa heç nə olmur. bu, hər şey pis işləyir.
İkincisi budur ki, ClickHouse-da, əgər sorğularınız indeksdən istifadə edirsə, o, həmişə tam skandan daha yavaş deyil, yəni demək olar ki, bütün cədvəli oxumaq lazımdırsa, o, ardıcıl olaraq gedəcək və bütün cədvəli oxuyacaq. Ümumiyyətlə, o, bunu başa düşəcək.
Bununla belə, bəzi çətinliklər var. Məsələn, alt sorğulu IN indeksdən istifadə etmir. Ancaq bu, bizim problemimizdir və biz bunu həll etməliyik. Burada fundamental heç nə yoxdur. Gəl edək*.
Və başqa bir maraqlı şey odur ki, əgər çox uzun sorğunuz varsa və paylanmış sorğunun işlənməsi davam edirsə, bu çox uzun sorğu hər bir serverə sıxılmadan göndəriləcək. Məsələn, 100 meqabayt və 500 server. Və müvafiq olaraq, şəbəkə üzərindən 50 gigabayt ötürüləcək. Köçürüləcək və sonra hər şey uğurla yerinə yetiriləcək.
* artıq istifadə edir; hər şey söz verildiyi kimi düzəldi.
Sorğuların API-dən gəlməsi olduqca yaygındır. Məsələn, bir növ xidmət göstərmisiniz. Və kiməsə xidmətinizə ehtiyac varsa, o zaman API açdınız və sözün həqiqi mənasında iki gündən sonra başa düşülməyən bir şeyin baş verdiyini görürsünüz. Hər şey həddən artıq yüklənir və heç vaxt olmamalı olan bəzi dəhşətli sorğular gəlir.
Və yalnız bir həll var. Əgər siz API-ni açmısınızsa, onda onu kəsməli olacaqsınız. Məsələn, bəzi kvotaları daxil etmək üçün. Başqa ağlabatan variantlar yoxdur. Əks halda dərhal ssenari yazacaqlar və problemlər yaranacaq.
Və ClickHouse-un xüsusi bir xüsusiyyəti var - bu, kvotaların hesablanmasıdır. Bundan əlavə, kvota açarınızı köçürə bilərsiniz. Bu, məsələn, daxili istifadəçi ID-sidir. Və onların hər biri üçün müstəqil olaraq kvota hesablanacaq.
İndi başqa bir maraqlı şey. Bu əllə təkrarlamadır.
Mən ClickHouse-un daxili replikasiya dəstəyinə malik olmasına baxmayaraq, insanların ClickHouse-u əl ilə təkrarladığı bir çox halları bilirəm.
Prinsip nədir? Sizin məlumat emal boru kəməriniz var. Və müstəqil olaraq, məsələn, müxtəlif məlumat mərkəzlərində işləyir. Eyni məlumatları eyni şəkildə ClickHouse-a yazırsınız. Düzdür, təcrübə göstərir ki, kodunuzdakı bəzi xüsusiyyətlərə görə məlumatlar hələ də fərqli olacaq. Ümid edirəm ki, sizdə.
Və vaxtaşırı siz hələ də əl ilə sinxronizasiya etməlisiniz. Məsələn, ayda bir dəfə adminlər rsync edir.
Əslində, ClickHouse-da daxili replikasiyadan istifadə etmək daha asandır. Ancaq bəzi əks göstərişlər ola bilər, çünki bunun üçün ZooKeeper istifadə etməlisiniz. ZooKeeper haqqında pis heç nə deməyəcəyəm, prinsipcə, sistem işləyir, amma elə olur ki, insanlar java-fobiyaya görə ondan istifadə etmirlər, çünki ClickHouse C++ dilində yazılmış o qədər yaxşı sistemdir ki, ondan istifadə edə və hər şey yaxşı olacaq. Və java-da ZooKeeper. Və nədənsə baxmaq belə istəmirsiniz, amma sonra əl ilə təkrarlamadan istifadə edə bilərsiniz.
ClickHouse praktik sistemdir. Sizin ehtiyaclarınızı nəzərə alır. Əgər əl ilə təkrarlamanız varsa, onda siz əl ilə replikalarınıza baxan və onlar arasında əvəzlənməni həyata keçirən Paylanmış cədvəl yarada bilərsiniz. Və hətta xətləriniz sistematik olaraq fərqli olsa belə, floplardan qaçmağa imkan verən xüsusi bir seçim var.
Bundan əlavə, ibtidai cədvəl mühərriklərindən istifadə etsəniz, problemlər yarana bilər. ClickHouse elə bir konstruktordur ki, bir dəstə müxtəlif masa mühərrikləri var. Bütün ciddi hallar üçün, sənədlərdə yazıldığı kimi, MergeTree ailəsinin cədvəllərindən istifadə edin. Qalan hər şey - fərdi hallar və ya testlər üçün belədir.
MergeTree cədvəlində hər hansı bir tarix və vaxta ehtiyacınız yoxdur. Hələ də istifadə edə bilərsiniz. Tarix və vaxt yoxdursa, defolt 2000 olduğunu yazın. Bu işləyəcək və resurs tələb etməyəcək.
Və serverin yeni versiyasında siz hətta bölmə açarı olmadan xüsusi bölməyə malik olduğunuzu təyin edə bilərsiniz. Eyni olacaq.
Digər tərəfdən, primitiv masa mühərrikləri istifadə edilə bilər. Məsələn, məlumatları bir dəfə doldurun və baxın, bükün və silin. Log istifadə edə bilərsiniz.
Və ya aralıq emal üçün kiçik həcmləri saxlamaq StripeLog və ya TinyLog-dur.
Yaddaş az miqdarda məlumat varsa istifadə edilə bilər və sadəcə RAM-da bir şeyi bükün.
ClickHouse yenidən normallaşdırılmış məlumatları çox sevmir.
Budur tipik bir nümunə. Bu, çoxlu sayda URL-dir. Onları qonşu masaya qoyursan. Və sonra biz onlarla JOIN etmək qərarına gəldik, lakin bu, bir qayda olaraq işləməyəcək, çünki ClickHouse yalnız Hash JOIN-i dəstəkləyir. Qoşulmaq üçün çoxlu məlumat üçün kifayət qədər RAM yoxdursa, JOIN işləməyəcək *.
Əgər məlumat yüksək kardinallığa malikdirsə, narahat olmayın, onu denormallaşdırılmamış formada saxlayın, URL-lər birbaşa əsas cədvəldə yerləşdirilir.
* və indi ClickHouse-un birləşməsi də var və o, aralıq məlumatların RAM-a uyğun olmadığı şəraitdə işləyir. Lakin bu səmərəsizdir və tövsiyə qüvvədə qalır.
Daha bir neçə nümunə, amma onların anti-naxış olub-olmadığına artıq şübhə edirəm.
ClickHouse-un bir məlum çatışmazlığı var. Necə yeniləməyi bilmir *. Bu, müəyyən mənada hətta yaxşıdır. Bəzi vacib məlumatlarınız varsa, məsələn, mühasibatlıq, onda heç kim onları göndərə bilməyəcək, çünki yeniləmələr yoxdur.
* toplu rejimdə yeniləmə və silmə dəstəyi çoxdan əlavə edilmişdir.
Ancaq yeniləmələrin arxa planda görünməsinə imkan verən bəzi xüsusi yollar var. Məsələn, ReplaceMergeTree tipli cədvəllər. Fon birləşmələri zamanı yeniləmələr edirlər. Bunu optimallaşdırma cədvəli ilə məcbur edə bilərsiniz. Ancaq bunu çox tez-tez etməyin, çünki o, bölməni tamamilə yazacaq.
ClickHouse-da paylanmış JOIN-lar - bu da sorğu planlayıcısı tərəfindən zəif idarə olunur.
Pis, amma bəzən yaxşıdır.
Select* ilə məlumatları geri oxumaq üçün ClickHouse-dan istifadə edin.
Böyük hesablamalar üçün ClickHouse istifadə etməyi tövsiyə etməzdim. Ancaq bu, tamamilə doğru deyil, çünki biz artıq bu tövsiyədən uzaqlaşırıq. Və biz bu yaxınlarda ClickHouse - Catboost-da maşın öyrənmə modellərini tətbiq etmək imkanı əlavə etdik. Və bu məni narahat edir, çünki düşünürəm: “Nə dəhşətdir. Bu bayt başına neçə dövrə çıxır! Baytlarda saat dövrlərini işə salmaq mənim üçün təəssüf doğurur.
Ancaq qorxma, ClickHouse-u quraşdırın, hər şey yaxşı olacaq. Bir şey varsa, bizim bir cəmiyyətimiz var. Yeri gəlmişkən, camaat sizsiniz. Və hər hansı bir probleminiz varsa, heç olmasa bizim çatımıza müraciət edə bilərsiniz və ümid edirəm ki, sizə kömək ediləcəkdir.
Suallar
Hesabat üçün təşəkkür edirik! ClickHouse qəzasından hara şikayət etmək olar?
İndi şəxsən mənə şikayət edə bilərsiniz.
Bu yaxınlarda ClickHouse istifadə etməyə başladım. Dərhal cli interfeysini buraxdı.
Nə hesab.
Bir az sonra serveri kiçik bir seçimlə atdım.
Sizdə istedad var.
Mən GitHub səhvini açdım, lakin nəzərə alınmadı.
Görəcəyik.
Aleksey məni aldatdı ki, hesabatda iştirak edim, içəridəki məlumatları necə sıxdığınızı söyləyəcəyinizi vəd etdi.
Çox sadə.
Dünən anladığım budur. Daha ətraflı.
Dəhşətli hiylələr yoxdur. Bu, sadəcə blok-blok sıxılmadır. Defolt LZ4-dür, siz ZSTD*-ni aktivləşdirə bilərsiniz. 64 kilobaytdan 1 meqabayta qədər bloklar.
* digər alqoritmlərlə zəncirdə istifadə oluna bilən xüsusi sıxılma kodekləri üçün də dəstək var.
Bloklar sadəcə xam məlumatlardır?
Tam olaraq xam deyil. massivlər var. Rəqəmsal sütununuz varsa, o zaman bir sıradakı nömrələr bir massivdə yığılır.
Aydındır.
Alexey, IP-lər üzərində uniqExact ilə olan bir nümunə, yəni uniqExact-in sətirlərlə sayılması rəqəmlərdən daha uzun sürməsi faktı və s. Korreksiya anında qulaqlarımızla sünilik tətbiq etsək və gips töksək necə olar? Yəni, deyəsən, diskdə çox da fərqlənmədiyini demisən. Diskdən sətirləri oxusaq, cast, onda aqreqatlarımız daha sürətli olacaq, ya yox? Yoxsa biz hələ də burada marjinal qazanırıq? Mənə elə gəlir ki, siz onu sınaqdan keçirmisiniz, amma nədənsə bunu etalonda göstərməmisiniz.
Düşünürəm ki, bu, çəkilməmişdən daha yavaş olacaq. Bu halda, IP ünvanı sətirdən təhlil edilməlidir. Təbii ki, ClickHouse-da IP ünvanlarının təhlili də optimallaşdırılıb. Çox çalışdıq, amma eyni yerdə on mininci formada yazılmış rəqəmlər var. Çox narahat. Digər tərəfdən, uniqExact funksiyası yalnız sətirlər olduğuna görə deyil, həm də alqoritmin fərqli ixtisası seçildiyinə görə sətirlərdə daha yavaş işləyəcək. Simlər sadəcə fərqli şəkildə idarə olunur.
Və daha primitiv bir məlumat növü götürsək? Məsələn, bizdə olan istifadəçi identifikatorunu yazdılar, sətir kimi yazdılar, sonra da atdılar, daha əyləncəli olar, yoxsa yox?
Şübhələnirəm. Düşünürəm ki, bu, daha da kədərli olacaq, çünki axırda rəqəmlərin təhlili ciddi problemdir. Mənə elə gəlir ki, bu həmkarın hətta on mininci formada rəqəmləri təhlil etməyin nə qədər çətin olduğu barədə hesabatı var idi, amma bəlkə də yox.
Aleksey, hesabata görə çox sağ ol! Və ClickHouse üçün çox sağ olun! Planlarla bağlı sualım var. Lüğətlərin natamam yenilənməsi ilə bağlı planlarda xüsusiyyət varmı?
yəni qismən yenidən yükləmə?
Hə hə. Orada MySQL sahəsini təyin etmək bacarığı kimi, yəni lüğət çox böyükdürsə, yalnız bu məlumatın yüklənməsi üçün yeniləmədən sonra.
Çox maraqlı xüsusiyyət. Və mənə elə gəlir ki, söhbətimizdə bunu kimsə təklif edib. Bəlkə də sən idin.
Mən belə düşünmürəm.
Əla, indi iki sorğu çıxır. Və bunu yavaş-yavaş etməyə başlaya bilərsiniz. Ancaq dərhal sizə xəbərdar etmək istəyirəm ki, bu funksiyanı həyata keçirmək olduqca sadədir. Yəni nəzəri olaraq sadəcə versiya nömrəsini cədvələ yazmaq və yazmağa davam etmək lazımdır: versiya filankəsdən azdır. Bu isə o deməkdir ki, çox güman ki, biz bunu həvəskarlara təqdim edəcəyik. Siz həvəskarsınız?
Bəli, lakin təəssüf ki, C++ dilində deyil.
Sizin həmkarlarınız C++ dilində yaza bilirmi?
Birini tapacam.
Əla*.
* xüsusiyyət hesabatdan iki ay sonra əlavə edildi - sualın müəllifi tərəfindən hazırlanmış və onun tərəfindən təqdim edilmişdir .
Təşəkkür edirik!
Salam! Hesabat üçün təşəkkür edirik! Qeyd etdiniz ki, ClickHouse onun üçün mövcud olan bütün resursları çox yaxşı istehlak edir. Luxoftun yanındakı spiker isə Rusiya Postu üçün qərarından danışdı. O, ClickHouse-u çox bəyəndiklərini, lakin bütün prosessoru yediyi üçün əsas rəqiblərinin əvəzinə ondan istifadə etmədiklərini söylədi. Və bunu öz arxitekturasına, dokerləri olan ZooKeeper-ə sığışdıra bilmədilər. ClickHouse-u hər hansı bir şəkildə məhdudlaşdırmaq mümkündürmü ki, onun üçün mövcud olan hər şeyi istehlak etməsin?
Bəli, mümkündür və çox asandır. Daha az nüvə istehlak etmək istəyirsinizsə, sadəcə yazın set max_threads = 1. Və hamısı budur, sorğunu bir nüvədə yerinə yetirəcək. Bundan əlavə, müxtəlif istifadəçilər üçün müxtəlif parametrlər təyin edə bilərsiniz. Yəni problem yoxdur. Luxoft-dan olan həmkarlarınıza deyin ki, bu parametri sənədlərdə tapmamaları yaxşı deyil.
Aleksey, salam! Mən bu sualı vermək istərdim. Bu, bir çox insanın ClickHouse-u qeydlər üçün repozitoriya kimi istifadə etməyə başladığını ilk dəfə eşidirəm. Hesabatda dediniz ki, bunu etmə, yəni uzun növbə saxlamağa ehtiyac yoxdur. Siz bu barədə nə düşünürsünüz?
Birincisi, loglar adətən uzun xətlər deyil. Təbii ki, istisnalar var. Məsələn, java-da yazılmış bəzi xidmətlər istisna atır, o, qeyd olunur. Və beləliklə, sonsuz bir döngədə və sabit diskdə yer tükənir. Həll yolu çox sadədir. Xətlər çox uzundursa, onları kəsin. Uzun nə deməkdir? Onlarla kilobayt pisdir *.
* ClickHouse-un son versiyalarında uzun sətirlərin saxlanması problemini əksər hallarda aradan qaldıran "adaptiv indeks qranularlığı" aktivləşdirilib.
Kilobayt normaldır?
Normaldır.
Salam! Hesabat üçün təşəkkür edirik! Bu barədə söhbətdə artıq soruşmuşam, amma cavab alıb-almadığımı xatırlamıram. WITH bölməsini CTE üslubunda genişləndirmək planı varmı?
Hələ yox. WITH bölməsi bir qədər qeyri-ciddidir. Bu, bizim üçün kiçik bir xüsusiyyət kimidir.
Mən başa düşürəm. Çox sağ ol!
Hesabat üçün təşəkkür edirik! Çox maraqlı! qlobal sual. Bəlkə də bir növ stub şəklində məlumatların silinməsinin modifikasiyası planlaşdırılırmı?
Mütləq. Bu, növbəmizdəki ilk işimizdir. İndi hər şeyi necə düzgün etmək barədə fəal şəkildə düşünürük. Və siz klaviaturanı basmağa başlamalısınız*.
* klaviaturadakı düymələri basdı və hər şey edildi.
Bu, bir şəkildə sistemin işinə təsir edəcək, ya yox? Yerləşdirmə indiki kimi sürətli olacaqmı?
Bəlkə də silmələrin özləri, yeniləmələrin özləri çox ağır olacaq, lakin bu, seçimlərin işinə və əlavələrin işinə heç bir şəkildə təsir etməyəcək.
Və daha bir kiçik sual. Təqdimatda siz əsas açar haqqında danışdınız. Müvafiq olaraq, standart olaraq aylıq olan bölməmiz var, elə deyilmi? Bir aya uyğun bir tarix aralığı təyin etdikdə, biz yalnız bu bölməni oxuyuruq, elə deyilmi?
Bəli.
Sual. Əgər biz hər hansı əsas açarı seçə bilmiriksə, o zaman bunu "Tarix" sahəsinə uyğun olaraq etmək düzgündürmü ki, arxa planda bu məlumatların daha nizamlı şəkildə yerləşməsi üçün daha kiçik restrukturizasiya olsun? Əgər diapazon sorğularınız yoxdursa və hətta heç bir əsas açarı seçə bilmirsinizsə, əsas açara tarix qoymağa dəyərmi?
Bəli.
Ola bilsin ki, ilkin açara bu sahəyə görə çeşidlənərsə, verilənlərin daha yaxşı sıxılacağı bir sahə qoymağın mənası var. Məsələn, istifadəçi ID. İstifadəçi, məsələn, eyni sayta gedir. Bu halda, istifadəçi id və vaxtı qoyun. Və sonra məlumatlarınız daha yaxşı sıxılacaq. Tarixə gəlincə, əgər həqiqətən tarixlər üzrə diapazon sorğunuz yoxdursa və heç vaxt sorğunuz yoxdursa, onda siz tarixi əsas açara qoya bilməzsiniz.
Oldu, çox sağ olun!
Mənbə: www.habr.com