Aprel ayında Avito mühəndisləri ClickHouse-un əsas tərtibatçısı Aleksey Milovidov və Integros-dan Golang tərtibatçısı Kirill Şvakov ilə onlayn görüşlər keçirdilər. Biz verilənlər bazası idarəetmə sistemindən necə istifadə etdiyimizi və hansı çətinliklərlə üzləşdiyimizi müzakirə etdik.
Görüşə əsaslanaraq, ehtiyat nüsxələri, məlumatların yenidən bölüşdürülməsi, xarici lüğətlər, Golanq sürücüsü və ClickHouse versiyasının yeniləmələri ilə bağlı bizim və auditoriyamızın suallarına ekspertlərin cavabları ilə bir məqalə hazırladıq. Artıq Yandex DBMS ilə fəal işləyən və onun indisi və gələcəyi ilə maraqlanan tərtibatçılar üçün faydalı ola bilər. Başqa cür qeyd edilmədiyi təqdirdə, Aleksey Milovidovun cavabları standartdır.
Diqqət edin, kəsik altında çoxlu mətn var. Ümid edirik ki, sualları olan məzmun naviqasiyanıza kömək edəcək.
Məzmun
Mətni oxumaq istəmirsinizsə, yığıncaqların səs yazısına baxa bilərsiniz . Vaxt ştampları videonun altındakı ilk şərhdədir.
ClickHouse daim yenilənir, lakin məlumatlarımız yenilənmir. Bununla nə etməli?
ClickHouse daim yenilənir və optimize final tərəfindən işlənmiş məlumatlarımız yenilənmir və ehtiyat nüsxədədir.
Tutaq ki, bir növ problemimiz oldu və məlumatlar itirildi. Biz bərpa etmək qərarına gəldik və məlum oldu ki, ehtiyat serverlərdə saxlanılan köhnə arakəsmələr hazırda istifadə olunan ClickHouse versiyasından çox fərqlidir. Belə bir vəziyyətdə nə etməli və bu mümkündürmü?
Köhnə formatda bir ehtiyat nüsxədən məlumatları bərpa etdiyiniz, lakin yeni versiyada onların bağlı olmadığı vəziyyət mümkün deyil. Biz əmin edirik ki, ClickHouse-da məlumat formatı həmişə geriyə uyğun olaraq qalır. Nadir hallarda istifadə edilən bəzi funksiyaların davranışı dəyişibsə, bu, funksionallıqda geriyə uyğunluqdan daha vacibdir. Diskdə saxlanılan məlumatları, ClickHouse-un yeni versiyasını həmişə oxuya bilmək lazımdır. Bu qanundur.
ClickHouse-dan məlumatların ehtiyat nüsxəsini çıxarmaq üçün cari ən yaxşı təcrübələr hansılardır?
Son əməliyyatları optimallaşdırdığımızı, nəhəng terabayt məlumat bazasına malik olduğumuzu və tutaq ki, son üç gündə yenilənən məlumatların olduğunu və sonra onlarla heç bir prosedurun baş vermədiyini nəzərə alaraq ehtiyat nüsxələrini necə etmək olar?
Biz öz həllimizi yığıb başımıza yaza bilərik: bu ehtiyat nüsxələri filan və belə bir şəkildə toplayın. Bəlkə heç nəyə ehtiyacınız yoxdur və velosiped çoxdan icad edilib?
Ən yaxşı təcrübələrdən başlayaq. Həmkarlarım həmişə ehtiyat nüsxələri ilə bağlı suallara cavab olaraq bu vəzifənin artıq həll olunduğu Yandex.Cloud xidməti haqqında xatırlatmağı məsləhət görürlər. Buna görə də mümkünsə istifadə edin.
Yedəkləmələr üçün ClickHouse-da yüz faiz qurulmuş tam həll yoxdur. İstifadə edə biləcəyiniz bəzi boşluqlar var. Tam bir həll əldə etmək üçün ya bir az əl ilə işləməli olacaqsınız, ya da skriptlər şəklində sarğılar hazırlamalısınız.
Mən məlumatların miqdarından və klaster ölçüsündən asılı olaraq ən sadə həllərdən başlayacağam və ən mürəkkəb həllərlə bitirəcəyəm. Qrup nə qədər böyük olarsa, həll yolu bir o qədər çətinləşir.
Məlumat cədvəli yalnız bir neçə gigabayt tutursa, ehtiyat nüsxəsini bu şəkildə etmək olar:
- Cədvəllərin tərifini, yəni metadata - saxla cədvəl yaratmağı göstərin.
- ClickHouse müştərisindən istifadə edərək boşluq yaradın - seçmək * masadan sənədləşdirmək. Varsayılan olaraq, TabSeparated formatında bir fayl alacaqsınız. Daha səmərəli olmaq istəyirsinizsə, Native formatından istifadə edə bilərsiniz.
Məlumatın miqdarı daha böyükdürsə, ehtiyat nüsxə daha çox vaxt və çox yer tutacaq. Buna məntiqi ehtiyat nüsxə deyilir, o, ClickHouse məlumat formatına bağlı deyil. Əgər belədirsə, onda bir çimdiklə ehtiyat nüsxəsini götürüb bərpa etmək üçün MySQL-ə yükləyə bilərsiniz.
Daha təkmil hallar üçün ClickHouse yerli fayl sistemində bölmələrin anlıq görüntüsünü yaratmaq üçün daxili imkana malikdir. Bu xüsusiyyət sorğu kimi mövcuddur. masanın dondurulması bölməsini dəyişdirin. Və ya sadəcə masanın dondurulmasını dəyişdirin bütün cədvəlin şəklidir.
Snapshot bir parça üzərində bir cədvəl üçün ardıcıl yaradılacaq, yəni bu şəkildə bütün klasterin ardıcıl snapshotını yaratmaq mümkün deyil. Ancaq əksər tapşırıqlar üçün belə bir ehtiyac yoxdur və hər bir parça üçün sorğu yerinə yetirmək və ardıcıl bir görüntü əldə etmək kifayətdir. O, sərt bağlantılar şəklində yaradılmışdır və buna görə də əlavə yer tutmur. Sonra bu snapshotı ehtiyat serverə və ya ehtiyat nüsxələri üçün istifadə etdiyiniz yaddaşa kopyalayırsınız.
Belə bir ehtiyat nüsxəsini bərpa etmək olduqca asandır. Əvvəlcə mövcud cədvəl təriflərinə uyğun olaraq cədvəllər yaradırsınız. Sonra, bu cədvəllər üçün saxlanılan bölmə snapshotlarını Directory-Detached-ə kopyalayın və sorğunu yerinə yetirin. bölmə əlavə edin. Bu həll ən ciddi məlumat miqdarı üçün olduqca uyğundur.
Bəzən daha sərin bir şeyə ehtiyacınız var - hər bir serverdə onlarla, hətta yüzlərlə terabayt və yüzlərlə server olan hallarda. Burada Yandex.Metrica-dan həmkarlarımdan casusluq etdiyim bir həll var. Hər kəsə tövsiyə etməzdim - oxuyun və uyğun olub-olmadığını özünüz qərar verin.
Əvvəlcə böyük disk rəfləri olan bir neçə server yaratmalısınız. Sonra, bu serverlərdə bir neçə ClickHouse serverini qaldırın və onları konfiqurasiya edin ki, onlar eyni parçalar üçün başqa replika kimi işləsinlər. Və sonra bu serverlərdə fayl sistemindən və ya anlıq görüntülər yaratmağa imkan verən bəzi vasitələrdən istifadə edin. Burada iki variant var. Birinci seçim LVM snapshots, ikinci seçim Linux-da ZFS-dir.
Bundan sonra, hər gün bir snapshot yaratmalısınız, o, yalan danışacaq və bir az yer tutacaq. Təbii ki, məlumatlar dəyişirsə, zaman keçdikcə yerin miqdarı artacaq. İstənilən vaxt bu snapshot əldə edə və məlumatları bərpa edə bilərsiniz, belə qəribə bir qərar. Üstəlik, siz hələ də konfiqurasiyada bu replikaları məhdudlaşdırmalısınız ki, onlar lider olmağa çalışmasınlar.
Vallardakı replikaların idarə olunan geriliyini təşkil etmək mümkün olacaqmı?
Bu il ClickHouse-da şaftlar düzəltməyi planlaşdırırsınız. Onlarda replikaların idarə olunan geriliyini təşkil etmək mümkün olacaqmı? Dəyişikliklər və digər dəyişikliklərlə özümüzü mənfi ssenarilərdən qorumaq üçün ondan istifadə etmək istərdik.
Dəyişikliklər üçün bir növ geri döndərmək mümkündürmü? Məsələn, mövcud bir şaftda götürün və deyin ki, bu ana qədər dəyişiklikləri tətbiq edin və bu andan etibarən dəyişiklikləri tətbiq etməyi dayandırın?
Əgər klasterimizə bir komanda gəlib onu pozubsa, onda bir saat gecikmə ilə şərti replikamız var, burada deyə bilərik ki, indi ondan istifadə edək, amma son on dəqiqə ərzində onda olan dəyişiklikləri tətbiq etməyəcəyik?
Başlamaq üçün, replikaların idarə olunan geriliyi haqqında. İstifadəçilərdən belə bir sorğu gəldi və biz Github-da belə bir sorğu yaratdıq: “Kiməsə bu lazımdırsa, bəyənin, ürək qoyun”. Heç kim mərc etmədi və məsələ bağlandı. Bununla belə, ClickHouse-u quraraq bu fürsəti artıq əldə edə bilərsiniz. Düzdür, yalnız 20.3 versiyasından başlayaraq.
ClickHouse daim arxa planda məlumatları birləşdirir - birləşdirin. Birləşmə həyata keçirildikdə, bəzi məlumat hissələri dəsti daha böyük bir hissə ilə əvəz olunur. Eyni zamanda, əvvəllər olan məlumat parçaları bir müddət diskdə qalmağa davam edir.
Birincisi, bloklanmayan əməliyyatı təmin etmək üçün onlardan istifadə edən seçilmiş sorğular olduğu müddətcə onlar saxlanmağa davam edir. Seçilmiş sorğular köhnə parçalardan səssizcə oxunur.
İkincisi, bir vaxt həddi də var - köhnə məlumat parçaları diskdə səkkiz dəqiqə qalır. Bu səkkiz dəqiqə fərdiləşdirilə və hətta bir günə çevrilə bilər. Bu, disk sahəsinə baha başa gələcək: məlumat axınından asılı olaraq, məlum olacaq ki, son gün ərzində məlumatlar nəinki ikiqat artacaq, beş dəfə çox ola bilər. Ancaq ciddi bir problem olarsa, ClickHouse serverini dayandırıb hər şeylə məşğul ola bilərsiniz.
İndi sual budur ki, bu dəyişikliklərdən necə qoruyur. Buraya daha dərindən baxmağa dəyər, çünki ClickHouse-un köhnə versiyalarında dəyişdirmə elə işləyirdi ki, sadəcə olaraq parçaları dəyişdirdi. Bəzi faylları olan bir məlumat parçası var və biz, məsələn, düşmə sütununu dəyişdirin. Sonra bu sütun fiziki olaraq bütün parçalardan çıxarılır.
Lakin 20.3 versiyasından bəri dəyişdirmə mexanizmi tamamilə dəyişdirildi və indi məlumat parçaları həmişə dəyişməzdir. Onlar heç də dəyişmir - dəyişdiricilər indi birləşmələrlə eyni şəkildə işləyirlər. Bir parçanı yerində dəyişmək əvəzinə yenisini yaradırıq. Yeni yığında dəyişdirilməmiş fayllar sərt bağlantılara çevrilir və sütunu silsək, o, sadəcə olaraq yeni yığında yox olacaq. Köhnə parça səkkiz dəqiqədən sonra standart olaraq silinəcək və burada yuxarıda qeyd olunan parametrləri düzəldə bilərsiniz.
Eyni şey mutasiyalar kimi dəyişikliklərə də aiddir. Siz etdiyiniz zaman dəyişdirmək silmək və ya yeniləməni dəyişdirin, parçanı dəyişmir, lakin yenisini yaradır. Və sonra köhnəsini silir.
Cədvəlin strukturu dəyişsə nə etməli?
Köhnə sxemlə hazırlanmış ehtiyat nüsxəsini necə qaldırmaq olar? İkinci sual isə anlıq görüntülər və fayl sistemi alətləri ilə əlaqədardır. Linux LVM-də ZFS əvəzinə Btrfs burada uyğundurmu?
Əgər etsən bölmə əlavə edin fərqli bir quruluşa malik arakəsmələr, sonra ClickHouse bunun mümkün olmadığını sizə xəbər verəcəkdir. Həll yolu budur. Birincisi, köhnə strukturu ilə MergeTree tipli müvəqqəti cədvəl yaratmaq, əlavədən istifadə edərək oraya məlumatları əlavə etmək və dəyişdirmə sorğusu verməkdir. Sonra siz bu məlumatları köçürə və ya köçürə və yenidən əlavə edə və ya sorğudan istifadə edə bilərsiniz masanın hərəkət bölməsini dəyişdirin.
İndi ikinci sual Btrfs istifadə etmək mümkün olub-olmamasıdır. Başlayanlar üçün LVM-iniz varsa, LVM anlıq görüntüləri kifayətdir və fayl sistemi ext4 ola bilər, fərq etməz. Btrts ilə hər şey onunla təcrübənizdən asılıdır. Bu, yetkin bir fayl sistemidir, lakin müəyyən bir ssenaridə hər şeyin praktikada necə işləyəcəyinə dair bəzi şübhələr hələ də var. İstehsalda Btrfs yoxdursa, bundan istifadə etməyi tövsiyə etməzdim.
Məlumatların yenidən bölüşdürülməsi üçün cari ən yaxşı təcrübələr hansılardır?
Yenidən parçalanma məsələsi mürəkkəb və çoxşaxəlidir. Burada eyni anda bir neçə varianta cavab verə bilərsiniz. Siz bir tərəfdən girib bunu deyə bilərsiniz - ClickHouse-da daxili yenidən bölmə seçimi yoxdur. Amma qorxuram ki, bu cavab heç kimə yaraşmayacaq. Buna görə də, digər tərəfdən gedib deyə bilərsiniz ki, ClickHouse-da məlumatları yenidən dəyişdirmək üçün bir çox yol var.
Əgər klasterdə yer tükənirsə və ya yükü öhdəsindən gələ bilmirsə, siz yeni serverlər əlavə edirsiniz. Ancaq bu serverlər standart olaraq boşdur, onlar haqqında məlumat yoxdur, yük yoxdur. Siz məlumatları elə köçürməlisiniz ki, onlar yeni, daha böyük klasterə bərabər şəkildə yayılsın.
Bunun ilk yolu, sorğudan istifadə edərək bölmələrin bir hissəsini yeni serverlərə köçürməkdir masa gətirmə bölməsini dəyişdirin. Məsələn, aylar üzrə bölmələriniz var idi və siz 2017-ci ilin ilk ayını götürüb yeni serverə köçürür, sonra üçüncü ayı başqa bir yeni serverə köçürürsünüz. Və az və ya çox bərabər olana qədər belə edirsiniz.
Miqrasiya yalnız qeyd zamanı dəyişməyən bölmələr üçün həyata keçirilə bilər. Təzə bölmələr üçün yazı deaktiv edilməlidir, çünki onların ötürülməsi atom deyil. Əks halda, məlumatlarda dublikat və ya boşluqlarla nəticələnəcəksiniz. Ancaq bu üsul praktikdir və kifayət qədər effektiv işləyir. Hazır sıxılmış arakəsmələr şəbəkə üzərindən ötürülür, yəni məlumatlar sıxılmır və ya yenidən kodlaşdırılmır.
Bu metodun bir çatışmazlığı var və bu, parçalanma sxemindən, bu parçalanma sxeminə girov verib-vermədiyinizdən, hansı parçalanma açarınızdan asılıdır. Ölçülər ilə bağlı nümunənizdə, parçalanma açarı yolun hashıdır. Paylanmış cədvəli seçdiyiniz zaman o, bir anda klasterin bütün hissələrinə keçir və oradan məlumatları götürür.
Bu o deməkdir ki, hansı məlumatın hansı parçada bitməsinin sizin üçün heç bir əhəmiyyəti yoxdur. Əsas odur ki, bir yoldakı məlumatlar bir parça üzərində başa çatır, lakin hansının əhəmiyyəti yoxdur. Bu halda, hazır arakəsmələrin ötürülməsi mükəmməldir, çünki seçilmiş sorğularla siz həm də tam məlumat alacaqsınız - həm yenidən bölüşdürülməzdən əvvəl, həm də sonra, sxem həqiqətən əhəmiyyət kəsb etmir.
Ancaq daha mürəkkəb olan hallar var. Tətbiq məntiqi səviyyəsində bu müştərinin belə və ya belə bir parça üzərində yerləşdiyinə və sorğunun Paylanmış cədvələ deyil, dərhal oraya göndərilə biləcəyinə xüsusi bir parçalanma sxeminə etibar edirsinizsə. Yoxsa ClickHouse-un kifayət qədər yeni versiyasından istifadə edirsiniz və bu parametri aktivləşdirmisiniz istifadə olunmamış qırıntıları optimallaşdırın. Bu halda, seçim sorğusu zamanı harada bölməsindəki ifadə təhlil ediləcək və parçalanma sxeminə uyğun olaraq hansı fraqmentlərə gedəcəyi hesablanacaq. Bu, məlumatların tam olaraq bu parçalanma sxeminə uyğun olaraq parçalanması şərtilə işləyir. Onları əl ilə köçürsəniz, yazışmalar dəyişə bilər.
Beləliklə, bu, bir nömrəli yoldur. Mən cavabınızı gözləyirəm, metod uyğundur, yoxsa davam edin.
Vladimir Kolobaev, Avito-da aparıcı sistem administratoru: Aleksey, oxu da daxil olmaqla, yükü yaymaq lazım olanda qeyd etdiyiniz üsul o qədər də uyğun gəlmir. Aylıq olan bölməni götürə bilərik və əvvəlki ayı başqa bir node-a keçirə bilərik, lakin bu məlumat üçün sorğu gələndə biz onu yalnız yükləyəcəyik. Ancaq mən bütün klasteri yükləmək istərdim, çünki əks halda bir müddət bütün oxu yükü iki parça ilə işlənəcək.
Aleksey Milovidov: Burada cavab qəribədir - bəli, pisdir, amma işləyə bilər. Mən dəqiq necə izah edəcəyəm. Məlumatlarınızla birlikdə gələn yükləmə ssenarisinə baxmağa dəyər. Əgər bu monitorinq məlumatlarıdırsa, demək olar ki, sorğuların böyük əksəriyyəti təzə məlumatlar üçündür.
Siz yeni serverlər quraşdırdınız, köhnə arakəsmələri köçürdünüz, həm də təzə məlumatların necə yazıldığını dəyişdiniz. Və təzə məlumatlar bütün klasterə yayılacaq. Beləliklə, beş dəqiqədən sonra son beş dəqiqəlik sorğular klasteri bərabər yükləyəcək, bir gün sonra isə bir günlük sorğular klasteri bərabər yükləyəcək. Və əvvəlki ay üçün sorğular, təəssüf ki, klaster serverlərinin yalnız bir hissəsinə gedəcək.
Ancaq çox vaxt 2019-cu ilin fevral ayı üçün sorğularınız olmayacaq. Çox güman ki, sorğular 2019-cu ilə gedirsə, o zaman onlar bütün 2019-cu il üçün olacaq - bəzi kiçik diapazon üçün deyil, böyük bir zaman intervalı üçün. Və bu cür sorğular da klasteri bərabər şəkildə yükləyə biləcək. Ancaq ümumiyyətlə, qeydiniz tamamilə düzgündür ki, bu, məlumatları tamamilə bərabər şəkildə yaymayan xüsusi bir həlldir.
Suala cavab vermək üçün daha bir neçə məqamım var. Onlardan biri ilkin olaraq parçalanma sxemini necə düzəltməkdir ki, yenidən parçalanma zamanı ağrı daha az olsun. Bu həmişə mümkün olmur.
Məsələn, monitorinq məlumatlarınız var. Monitorinq məlumatları üç səbəbə görə artır. Birincisi, tarixi məlumatların toplanmasıdır. İkincisi, trafikin artmasıdır. Üçüncüsü, monitorinqə məruz qalan şeylərin sayının artmasıdır. Yadda saxlanmalı olan yeni mikroservislər və ölçülər var.
Ola bilər ki, bunlardan ən böyük artım üçüncü səbəblə bağlıdır - bu, monitorinqdən istifadənin artmasıdır. Və bu vəziyyətdə, yükün təbiətinə baxmağa dəyər, seçim üçün əsas istəklər nələrdir. Əsas seçim sorğuları çox güman ki, metriklərin bəzi alt dəstlərinə əməl edəcək.
Məsələn, bəzi xidmətlər tərəfindən bəzi serverlərdə CPU istifadəsi. Məlum oldu ki, bu məlumatları əldə edən bəzi açarlar var. Və bu məlumat üçün sorğunun özü çox güman ki, olduqca sadədir və onlarla millisaniyə ərzində işləyir. Monitorinq xidmətləri, panellər üçün istifadə olunur. Ümid edirəm ki, bunu düzgün başa düşürəm.
Vladimir Kolobayev: Fakt budur ki, biz çox vaxt tarixi məlumatlara müraciət edirik, çünki indiki vəziyyəti real vaxtda tarixi ilə müqayisə edirik. Böyük miqdarda məlumatlara sürətli çıxış əldə etmək bizim üçün vacibdir və ClickHouse bununla əla iş görür.
Tamamilə haqlısınız, hər hansı bir monitorinq sistemi kimi son gündə qarşılaşdığımız oxunma sorğularının əksəriyyəti. Ancaq eyni zamanda, tarixi məlumatların yükü də kifayət qədər böyükdür. Bu, əsasən, hər otuz saniyədən bir gedən və ClickHouse-a “Son altı həftənin məlumatlarını mənə ver” deyən bir xəbərdarlıq sistemindəndir. İndi mənə onlardan bəzi hərəkətli ortalama qurun və indiki dəyəri tarixi dəyərlə müqayisə edək.
Demək istərdim ki, belə çox təzə istəklər üçün bizdə cəmi iki günlük məlumatları saxladığımız başqa bir kiçik cədvəlimiz var və əsas sorğular ona daxil olur. Böyük bir parçalanmış cədvələ yalnız böyük tarixi sorğular göndəririk.
Aleksey Milovidov: Təəssüf ki, bu, ssenariniz üçün zəif tətbiq oluna bilər, lakin mən istifadə edilməsinə ehtiyac olmayan, lakin dostlarımın xidmətində istifadə olunan iki pis və mürəkkəb parçalanma sxemini təsvir edəcəyəm.
Yandex.Metrics hadisələri ilə əsas çoxluq var. Hadisələr səhifə baxışları, kliklər və keçidlərdir. Müraciətlərin çoxu müəyyən bir vebsayta gedir. Siz Yandex.Metrica xidmətini açırsınız, bir veb saytınız var - avito.ru, hesabata keçin və veb saytınız üçün sorğu verilir.
Ancaq daxili analitiklər tərəfindən edilən analitik və qlobal tələblər də var. Hər halda, qeyd edirəm ki, daxili analitiklər yalnız Yandex xidmətlərinə müraciət edirlər. Ancaq buna baxmayaraq, hətta Yandex xidmətləri bütün məlumatların əhəmiyyətli bir hissəsini tutur. Bunlar xüsusi sayğaclar üçün deyil, daha geniş filtrasiya üçün sorğulardır.
Məlumatları elə bir şəkildə təşkil etmək olar ki, hər şey bir sayğac və qlobal sorğular üçün səmərəli işləsin? Digər bir çətinlik, Metriklər klasteri üçün ClickHouse-da sorğuların sayının saniyədə bir neçə min olmasıdır. Eyni zamanda, bir ClickHouse serveri qeyri-trivial sorğuları idarə etmir, məsələn, saniyədə bir neçə min.
Klaster ölçüsü altı yüz və bir şey serverdir. Əgər siz sadəcə olaraq bu klasterin üzərinə Paylanmış cədvəli uzatsanız və ora bir neçə min sorğu göndərsəniz, bu, onları bir serverə göndərməkdən daha pis olacaq. Digər tərəfdən, məlumatların bərabər şəkildə yayılması və biz gedib bütün serverlərdən tələb etdiyimiz seçim dərhal rədd edilir.
Diametral olaraq əks variant var. Təsəvvür edin ki, biz məlumatları sayta görə bölsək və bir sayt üçün sorğu bir parçaya gedir. İndi klaster saniyədə on min sorğu çıxara biləcək, lakin bir parça üzərində bir sorğu çox yavaş işləyəcək. O, artıq bant genişliyində ölçülənməyəcək. Xüsusilə avito.ru saytıdırsa. Avito Runetdə ən çox ziyarət edilən saytlardan biridir desəm, sirr açmayacağam. Və onu bir parça üzərində emal etmək dəlilik olardı.
Buna görə də, parçalanma sxemi daha çətin bir şəkildə təşkil edilmişdir. Bütün klaster bir sıra klasterlərə bölünür, biz onları təbəqələr adlandırırıq. Hər klasterin içərisində ondan bir neçə onlarla parça var. Ümumilikdə otuz doqquz belə klaster var.
Bütün bunlar necə ölçülür? Klasterlərin sayı dəyişmir - otuz doqquz il əvvəl olduğu kimi, eyni qalır. Lakin onların hər birinin daxilində məlumatlar toplandıqca biz qəlpələrin sayını tədricən artırırıq. Və bütövlükdə parçalanma sxemi belədir - bu klasterlərə bölünmə vebsaytlar tərəfindən aparılır və hansı saytın hansı klasterdə olduğunu anlamaq üçün ümumiyyətlə MySQL-də ayrıca metabaza istifadə olunur. Bir sayt - bir klasterdə. Və onun daxilində, ziyarətçilərin identifikatorlarına uyğun olaraq parçalanma baş verir.
Qeydiyyat zamanı biz onları ziyarətçi identifikatorunun qalan hissəsinə bölürük. Ancaq yeni bir parça əlavə edildikdə, parçalanma sxemi dəyişir, biz bölməyə davam edirik, lakin qalan hissəni başqa nömrəyə bölmək olar. Bu o deməkdir ki, bir ziyarətçi artıq bir neçə serverdə yerləşir və siz ona mərc edə bilməzsiniz. Bu, yalnız məlumatların daha yaxşı sıxılmasını təmin etmək üçün edilir. Sorğu zamanı isə klasterə baxan və onlarla serverə daxil olan Paylanmış cədvələ keçirik. Bu belə axmaq bir sxemdir.
Amma bu sxemdən əl çəkdiyimizi deməsəm hekayəm yarımçıq olacaq. Yeni sxemdə biz hər şeyi dəyişdirdik və klikxana-kopiyerdən istifadə edərək bütün məlumatları kopyaladıq.
Yeni sxemdə bütün saytlar iki kateqoriyaya bölünür - böyük və kiçik. Orada həddin necə seçildiyini bilmirəm, amma nəticədə məlum oldu ki, böyük saytlar bir klasterdə qeyd olunur, burada hər birində üç replikası olan 120 parça, yəni 360 server var. Və parçalanma sxemi elədir ki, istənilən sorğu bir anda bütün şərqlərə gedir. İndi Yandex.Metrica-da avito.ru üçün hər hansı hesabat səhifəsini açsanız, sorğu 120 serverə gedəcək. Runet-də bir neçə böyük sayt var. İstəklər isə saniyədə min deyil, hətta yüzdən də azdır. Bütün bunlar hər biri 120 serveri emal edən Paylanmış cədvəl tərəfindən sakitcə çeynənir.
İkinci klaster isə kiçik saytlar üçündür. Budur sayt identifikatoru ilə parçalanma sxemi və hər sorğu tam olaraq bir parçaya gedir.
ClickHouse-da klikxana-kopiya proqramı var. Onun haqqında məlumat verə bilərsinizmi?
Dərhal deməliyəm ki, bu həll daha çətin və bir qədər az məhsuldardır. Üstünlük ondadır ki, o, göstərdiyiniz sxemə uyğun olaraq məlumatları tamamilə ləkələyir. Lakin kommunalın dezavantajı odur ki, o, ümumiyyətlə yenidən parçalanmır. O, məlumatları bir klaster sxemindən digər klaster sxeminə köçürür.
Bu o deməkdir ki, onun işləməsi üçün iki klasteriniz olmalıdır. Onlar eyni serverlərdə yerləşdirilə bilər, lakin buna baxmayaraq, məlumatlar tədricən köçürülməyəcək, lakin kopyalanacaq.
Məsələn, dörd server var idi, indi səkkizdir. Siz bütün serverlərdə yeni Paylanmış cədvəl, yeni yerli cədvəllər yaradırsınız və oradan oxumalı olduğu iş sxemini göstərərək klikxana-kopiyerini işə salırsınız, yeni parçalanma sxemini qəbul edirsiniz və məlumatları ora köçürürsünüz. Və köhnə serverlərdə indi olduğundan bir yarım dəfə çox yerə ehtiyacınız olacaq, çünki köhnə məlumatlar onlarda qalmalıdır və eyni köhnə məlumatların yarısı onların üstünə gələcək. Əvvəlcədən məlumatların yenidən dəyişdirilməsinin lazım olduğunu düşünsəniz və boş yer varsa, bu üsul uyğundur.
Klikxana-kopiya maşını içəridə necə işləyir? O, bütün işləri bir masanın bir hissəsini bir parça üzərində işləmək üçün tapşırıqlar toplusuna bölür. Bütün bu tapşırıqlar paralel olaraq işləyə bilər və klikxana-kopiyer müxtəlif maşınlarda birdən çox nümunəni işlədə bilər, lakin onun bir bölmə üçün etdiyi şey əlavə seçimindən başqa bir şey deyil. Verilənlər oxunur, açılır, yenidən bölmələrə bölünür, sonra yenidən sıxılır, haradasa yazılır, yenidən çeşidlənir. Bu daha çətin bir qərardır.
Sizin reshading adlı pilot işiniz var idi. Bəs onunla?
Hələ 2017-ci ildə resharing adlı bir pilot işiniz var idi. ClickHouse-da hətta bir seçim var. Başa düşmədim. Bunun niyə baş verdiyini deyə bilərsinizmi? Çox aktual görünür.
Bütün problem ondadır ki, əgər məlumatları yerində dəyişdirmək lazımdırsa, bunu atomik şəkildə etmək üçün çox mürəkkəb sinxronizasiya tələb olunur. Bu sinxronizasiyanın necə işlədiyinə baxmağa başlayanda aydın oldu ki, fundamental problemlər var. Və bu fundamental problemlər təkcə nəzəri xarakter daşımır, həm də dərhal praktikada özünü çox sadə izah edilə bilən bir şey şəklində göstərməyə başladı - heç bir şey işləmir.
Yavaş disklərə keçməzdən əvvəl məlumatların bütün hissələrini birləşdirmək mümkündürmü?
Birləşmə kontekstində yavaş disk seçimi ilə TTL ilə bağlı sual. Yavaş disklərə keçməzdən əvvəl bütün hissələri birləşdirmək üçün crondan başqa bir yol varmı?
Bütün parçaları köçürməzdən əvvəl avtomatik olaraq birinə yapışdırmağın mümkün olub-olmadığı sualına cavab yoxdur. Mənə elə gəlir ki, bu lazım deyil. Bütün hissələri bir yerə birləşdirə bilməzsiniz, sadəcə olaraq onların avtomatik olaraq yavaş disklərə köçürüləcəyinə etibar edin.
Transfer qaydaları ilə bağlı iki meyarımız var. Birincisi, dolduğu kimidir. Cari yaddaş səviyyəsində boş yerin müəyyən faizindən az olarsa, biz bir parça seçib onu daha yavaş yaddaşa köçürürük. Daha doğrusu, daha yavaş deyil, aşağıdakılar - onu necə qurduğunuz.
İkinci meyar ölçüdür. Böyük parçaların transferindən danışır. Sürətli diskdə boş yerə əsaslanaraq həddi tənzimləyə bilərsiniz və məlumatlar avtomatik olaraq köçürüləcək.
Uyğunluğu əvvəlcədən yoxlamaq üçün bir yol yoxdursa, ClickHouse-un yeni versiyalarına necə keçmək olar?
Bu mövzu müntəzəm olaraq müzakirə olunur müxtəlif versiyaları nəzərə alaraq və hələ. 19.11-dən 19.16-ya və məsələn, 19.16-dan 20.3-ə yüksəltmək nə qədər təhlükəsizdir. Sandbox-da uyğunluğu əvvəlcədən yoxlamadan yeni versiyalara keçməyin ən yaxşı yolu nədir?
Burada bir neçə qızıl qaydalar var. Birinci - . Bu, böyükdür, lakin geriyə uyğun olmayan dəyişikliklərlə bağlı ayrıca məqamlar var. Bu maddələrə qırmızı bayraq kimi yanaşmayın. Bunlar adətən istifadə etmədiyiniz bəzi kənar funksiyalarla əlaqəli kiçik uyğunsuzluqlardır.
İkincisi, qum qutusunda uyğunluğu yoxlamaq üçün heç bir yol yoxdursa və istehsalda dərhal təkmilləşdirmək istəyirsinizsə, tövsiyə budur ki, bunu etməyə ehtiyac yoxdur. Əvvəlcə sandbox yaradın və sınaqdan keçirin. Test mühiti yoxdursa, çox güman ki, çox böyük bir şirkətiniz yoxdur, yəni məlumatların bir hissəsini laptopunuza köçürə və hər şeyin düzgün işlədiyinə əmin ola bilərsiniz. Siz hətta maşınınızda yerli olaraq bir neçə replika gətirə bilərsiniz. Və ya yaxınlıqda bir yerdə yeni bir versiya qaldıra və bəzi məlumatları ora yükləyə bilərsiniz - yəni ekspromt sınaq mühiti yarada bilərsiniz.
Başqa bir qayda, versiyanın buraxılmasından sonra bir həftə ərzində istehsalda səhvləri tutmaq və sonrakı sürətli düzəlişlər səbəbindən yeniləməməkdir. Çaşqın olmamaq üçün ClickHouse versiyasının nömrələnməsini anlayaq.
20.3.4 versiyası var. 20 rəqəmi istehsal ilini göstərir - 2020. İçəridə olanlar baxımından bunun əhəmiyyəti yoxdur, ona görə də buna əhəmiyyət verməyəcəyik. Əlavə - 20.3. İkinci rəqəm - bu halda 3 - biz hər dəfə bəzi yeni funksionallığı olan buraxılış buraxdıqda artırırıq. ClickHouse-a hansısa xüsusiyyət əlavə etmək istəyiriksə, bu rəqəmi artırmalıyıq. Yəni 20.4 ClickHouse versiyasında daha yaxşı işləyəcək. Üçüncü rəqəm 20.3.4-dür. Burada 4 yeni funksiyalar əlavə etmədiyimiz, lakin bəzi səhvləri düzəltdiyimiz yamaq buraxılışlarının sayıdır. 4 isə o deməkdir ki, biz bunu dörd dəfə etmişik.
Bunun dəhşətli bir şey olduğunu düşünməyin. Adətən istifadəçi ən son versiyanı quraşdıra bilər və o, ildə iş vaxtı ilə heç bir problem olmadan işləyəcək. Ancaq təsəvvür edin ki, çinli yoldaşlarımızın əlavə etdiyi bitmapların işlənməsi üçün bəzi funksiyalarda səhv arqumentlər ötürülən zaman server çökür. Biz bunu düzəltməliyik. Yeni yamaq versiyasını buraxacağıq və ClickHouse daha stabil olacaq.
Əgər sizdə ClickHouse istehsalda işləyirsə və əlavə funksiyaları olan ClickHouse-un yeni versiyası buraxılıbsa - məsələn, 20.4.1 ən birincisidirsə, onu ilk gün istehsala qoymağa tələsməyin. O, ümumiyyətlə niyə lazımdır? Hələ ClickHouse istifadə etmirsinizsə, onu quraşdıra bilərsiniz və çox güman ki, hər şey yaxşı olacaq. Ancaq ClickHouse artıq stabil işləyirsə, yamaqlar və yeniləmələr üçün bizi izləyin - hansı problemləri həll edirik.
Kirill Şvakov: Test mühitləri haqqında bir az əlavə etmək istəyirəm. Hər kəs test mühitlərindən çox qorxur və nədənsə hesab edir ki, əgər sizin çox böyük bir ClickHouse klasteriniz varsa, o zaman test mühiti heç də kiçik və ya ən azı on dəfə kiçik olmamalıdır. Bu heç də belə deyil.
Mən öz nümunəmlə deyə bilərəm. Mənim bir layihəm var və ClickHouse var. Onun üçün sınaq mühitimiz Hetzner-də iyirmi avroya kiçik bir virtual maşındır, burada tamamilə hər şey yerləşdirilir. Bunu etmək üçün biz Ansible-da tam avtomatlaşdırmaya sahibik və buna görə də, prinsipcə, harada yuvarlanacağımız fərqi yoxdur - dəmir serverlərdə və ya sadəcə virtual maşınlarda yerləşdirmək.
Nə etmək olar? ClickHouse sənədlərində kiçik bir klasteri öz başınıza necə yerləşdirməyinizə dair bir nümunə göstərmək yaxşı olardı - Docker-də, LXC-də, bəlkə də Ansible oyun kitabını yarada bilərsiniz, çünki müxtəlif insanların müxtəlif yerləşdirmələri var. Bu, çox şeyi asanlaşdıracaq. Beş dəqiqə ərzində bir klaster götürüb yerləşdirdiyiniz zaman nəyisə anlamağa çalışmaq daha asandır. Bu, daha rahatdır, çünki istehsalda sınaqdan keçirmədiyiniz versiyanı yaymaq heç bir yerə aparan bir yol deyil. Bəzən işləyir, bəzən isə yox. Və buna görə də uğura ümid etmək pisdir.
Maksim Kotyakov, baş mühəndis Avito: Böyük şirkətlər üçün bir sıra problemlərdən test mühitləri haqqında bir az əlavə edəcəyəm. Məlumat sxemlərinə və parametrlərinə uyğun olaraq istehsalda olanların dəqiq surəti olan tam hüquqlu ClickHouse qəbul klasterimiz var. Bu klaster minimum resursla kifayət qədər çürük konteynerlərdə yerləşdirilib. Kafkada axını təkrarlamaq imkanı olduğu üçün istehsal məlumatlarının müəyyən faizini ora yazırıq. Orada hər şey sinxronlaşdırılır və miqyaslanır - həm tutum, həm axın baxımından, həm də nəzəri olaraq, bütün digər şeylər bərabər olduqda, o, ölçü baxımından istehsal kimi davranmalıdır. Potensial partlayıcı olan hər şey əvvəlcə bu stendə yuvarlanır və hazır olana qədər bir neçə gün orada infuziya edilir. Ancaq əlbəttə ki, bu həll bahalı, ağır və sıfırdan fərqli dəstək xərcləri ilə.
Aleksey Milovidov: Yandex.Metrica-dan dostlarımızın test mühitinin necə olduğunu sizə xəbər verəcəyəm. Bir klaster 600-dən çox server üçün, digəri 360 üçün idi və üçüncü və bir neçə klaster var. Onlardan biri üçün sınaq mühiti hər birində iki replikası olan iki parçadır. Niyə iki parça? Tək olmamaq üçün. Və replikaları da olmalıdır. Sadəcə ödəyə biləcəyiniz minimum məbləğ.
Bu test mühiti sorğuların sağlamlığını və nəyinsə böyük şəkildə pozulduğunu yoxlamağa imkan verir. Ancaq tez-tez problemlər tamamilə fərqli bir təbiətdə yaranır, hər şey işləyir, lakin yüklə bəzi kiçik dəyişikliklər olur.
Mən sizə bir nümunə verim. ClickHouse-un yeni versiyasını quraşdırmaq qərarına gəldik. O, sınaq mühitində qurulmuşdur, Yandex.Metrica-nın özündə avtomatlaşdırılmış testlər keçirilir ki, bu da bütün boru kəmərini işlədən köhnə versiya və yeni versiyadakı məlumatları müqayisə edir. Və əlbəttə ki, CI-nin yaşıl testləri. Əks halda, biz bu versiyanı belə təklif etməzdik.
Hər şey yaxşıdır. İstehsalata başlayırıq. Qrafiklərdə yükün bir neçə dəfə artdığı barədə mesaj alıram. Versiyanı geri qaytarırıq. Qrafikə baxıram və görürəm: yüklənmə zamanı həqiqətən bir neçə dəfə artdı və yuvarlananda geri azaldı. Sonra versiyanı geri qaytarmağa başladıq. Və yük eyni şəkildə artdı və eyni şəkildə geri düşdü. Beləliklə, nəticə budur - hesablama ilə əlaqədar yük artdı, təəccüblü bir şey yoxdur.
Sonra həmkarlarını yeni versiyanı quraşdırmağa inandırmaq çətin idi. Deyirəm: “Eybi yoxdur, çölə çıx. Barmaqlarınızı çarpaz saxlayın, hər şey işləyəcək. İndi qrafiklərdə yük artıb, amma hər şey qaydasındadır. Gözlə." Ümumiyyətlə, biz bunu etdik və bu qədər - versiya istehsal saytında yerləşdirilib. Amma demək olar ki, hər hesablama ilə oxşar problemlər ortaya çıxır.
Öldürmə sorğusu sorğuları öldürməli idi, lakin yox. Niyə?
Bir istifadəçi mənə gəldi, bir növ analitik və mənim ClickHouse klasterimi qoyan müəyyən bir sorğu yaratdı. Sorğunun hansı replikaya və ya parçaya daxil olmasından asılı olaraq bəzi node və ya bütöv klaster. Mən görürəm ki, bu serverdəki bütün CPU resursları rəfdədir, hər şey qırmızıdır. Eyni zamanda, ClickHouse özü müraciətlərə cavab verir. Mən də yazıram: "Zəhmət olmasa, bu çılğınlığı yaradan proses siyahısını mənə göstərin."
Mən bu sorğunu tapıram və ona kill yazıram. Və görürəm ki, heç nə baş vermir. Mənim serverim rəfdədir, ClickHouse sonra mənə bəzi əmrlər verir, serverin canlı olduğunu göstərir və hər şey qaydasındadır. Amma mənim bütün istifadəçi sorğularında deqradasiya var, ClickHouse-a girişlə deqradasiya başlayır və öldürmə sorğum işləmir. Niyə? Düşündüm ki, öldürmə sorğusu sorğuları öldürməli idi, amma yox.
İndi olduqca qəribə bir cavab olacaq. Məsələ ondadır ki, öldürmə sorğusu sorğuları öldürmür.
Kill sorğusu "Mən bu sorğunun öldürülməsini istəyirəm" adlı kiçik bir onay qutusu qoyur. Və sorğunun özü hər bloku emal edərkən bu bayrağa baxır. Quraşdırılıbsa, sorğu işləməyi dayandırır. Belə çıxır ki, xahişi heç kim öldürmür, özü hər şeyi yoxlayıb dayanmalıdır. Və bu, sorğunun blok emal vəziyyətində olduğu bütün hallarda işləməlidir. O, növbəti məlumat blokunu emal edəcək, bayrağı yoxlayacaq və dayanacaq.
Bu, sorğunun bəzi əməliyyatlarda bloklandığı hallarda işləmir. Düzdür, bu, çox güman ki, sizin işiniz deyil, çünki sizə görə, bir dəstə server resurslarından istifadə edir. Ola bilər ki, bu, xarici çeşidləmə və bəzi digər detallarda işləmir. Ancaq ümumiyyətlə, bu olmamalıdır, bu bir səhvdir. Məsləhət verə biləcəyim yeganə şey ClickHouse-u yeniləməkdir.
Oxuma yükü altında cavab müddətini necə hesablamaq olar?
Maddə aqreqatlarını - müxtəlif sayğacları saxlayan bir cədvəl var. Sətirlərin sayı yüz milyona yaxındır. 1K elementə 1K RPS töksəniz, proqnozlaşdırıla bilən cavab müddətinə inanmaq mümkündürmü?
Kontekstdən danışsaq, biz oxu yükündən danışırıq, çünki yazı ilə bağlı heç bir problem yoxdur - ən azı min, ən azı yüz min, bəzən də bir neçə milyon sətir daxil edilə bilər.
Oxuma tələbləri çox fərqlidir. Seçim 1-də ClickHouse saniyədə on minlərlə sorğu yerinə yetirə bilər, belə ki, hətta bir açar üçün sorğular artıq bəzi resurslar tələb edəcək. Və belə nöqtə sorğuları bəzi açar-dəyər verilənlər bazalarından daha çətin olacaq, çünki hər oxumaq üçün verilənlər blokunu indekslə oxumaq lazımdır. İndeksimiz hər rekorda deyil, hər aralığa müraciət edir. Yəni, bütün diapazonu oxumalısınız - bunlar standart olaraq 8192 sətirdir. Və sıxılmış məlumat blokunu 64 KB-dan 1 MB-a qədər açmalısınız. Tipik olaraq, bu cür nöqtə sorğuları bir neçə millisaniyədən başlayır. Ancaq bu ən asan seçimdir.
Bir az sadə hesab etməyə çalışaq. Bir neçə millisaniyəni minə vursanız, bir neçə saniyə əldə edirsiniz. Sanki saniyədə min sorğu saxlamaq mümkün deyil, əslində isə mümkündür, çünki bizdə bir neçə prosessor nüvəsi var. Beləliklə, prinsipcə, 1000 RPS ClickHouse bəzən saxlaya bilər, lakin qısa istəklər, yəni nöqtə sorğuları.
Əgər ClickHouse klasterini sadə sorğuların sayına görə ölçmək lazımdırsa, onda mən ən sadə şeyi məsləhət görürəm - replikaların sayını artırın və sorğuları təsadüfi replikaya göndərin. Bir replika saniyədə beş yüz sorğuya malikdirsə, bu tamamilə realdır, onda üç replika bir yarım min tutacaq.
Bəzən, əlbəttə ki, siz ClickHouse-u maksimum nöqtə oxunuşu üçün konfiqurasiya edə bilərsiniz. Bunun üçün nə lazımdır? Birincisi, indeksin qranulyarlığını azaltmaqdır. Eyni zamanda, onu birinə azaltmaq deyil, indeksdəki qeydlərin sayının bir serverə bir neçə milyon və ya on milyonlarla olacağına əsaslanmalıdır. Cədvəldə yüz milyon cərgə varsa, o zaman 64 dənəvərlik kimi təyin edilə bilər.
Sıxılmış blokun ölçüsünü azalda bilərsiniz. Bunun üçün parametrlər var. min kompres blok ölçüsü, maksimum kompres blok ölçüsü. Onları azalda, məlumatları yenidən yükləyə bilərsiniz və sonra nöqtə sorğuları daha sürətli olacaq. Ancaq yenə də ClickHouse əsas dəyər verilənlər bazası deyil. Çox sayda kiçik sorğu yük əleyhinə nümunədir.
Kirill Şvakov: Adi mühasiblər olsa məsləhət verəcəm. Bu, ClickHouse-da bir növ sayğac saxlandıqda kifayət qədər standart bir vəziyyətdir. Mənim bir istifadəçim var, filan ölkədəndir, filan başqa üçüncü sahədəndir, getdikcə nəyisə artırmaq lazımdır. MySQL-i götürün, unikal açar yaradın - MySQL-də o, dublikat açardır, PostgreSQL-də isə münaqişədir - və əlavə işarəsi əlavə edin. Bu, daha yaxşı işləyəcək.
Kiçik məlumatınız olduqda, ClickHouse istifadə etməyin çox mənası yoxdur. Müntəzəm məlumat bazaları var və onlar bununla yaxşı işləyirlər.
Daha çox məlumatın keşdə olması üçün ClickHouse-da nəyi dəyişmək lazımdır?
Vəziyyəti təsəvvür edək - serverlərdə 256 GB RAM var, gündəlik rejimdə ClickHouse təxminən 60-80 GB, pikdə - 130-a qədər tutur. Nəyi aktivləşdirmək və tənzimləmək olar ki, daha çox məlumat önbellekdə olsun və müvafiq olaraq. , diskə daha az səfər var?
Bir qayda olaraq, əməliyyat sisteminin səhifə önbelleği bu vəzifəni yaxşı yerinə yetirir. Əgər siz sadəcə yuxarını açsanız, orada keşlənmiş və ya pulsuz baxın - bu da nə qədər yaddaşda saxlandığını göstərir - onda siz bütün boş yaddaşın keş üçün istifadə olunduğunu görə bilərsiniz. Və bu məlumatları oxuyarkən diskdən deyil, RAM-dan oxunacaq. Eyni zamanda qeyd edə bilərəm ki, keş yaddaşdan səmərəli istifadə olunur, çünki keş saxlanılan sıxılmış məlumatlardır.
Bununla belə, bəzi sadə sorğuları daha da sürətləndirmək istəyirsinizsə, ClickHouse daxilində sıxılmış məlumatlarda keşi aktivləşdirmək mümkündür. Bu adlanır sıxılmamış önbellek. config.xml konfiqurasiya faylında, sıxılmamış önbellek ölçüsünü sizə lazım olan dəyərə təyin edin - pulsuz RAM-in yarısından çoxunu məsləhət görmürəm, çünki qalan hissəsi səhifə önbelleğinin altına düşəcək.
Bundan əlavə, iki sorğu səviyyəsi parametrləri var. İlk parametr - sıxılmamış önbelleği istifadə edin - onun istifadəsi daxildir. Bütün məlumatları oxuya bilən və bu keşi təmizləyə bilən ağır olanlar istisna olmaqla, bütün sorğular üçün onu aktivləşdirmək tövsiyə olunur. İkinci parametr, önbelleği istifadə etmək üçün maksimum xətlərin sayı kimi bir şeydir. Böyük sorğuları avtomatik olaraq məhdudlaşdırır ki, onlar keşdən keçsinlər.
RAM-da saxlama üçün saxlama_konfiqurasiyasını necə konfiqurasiya edə bilərəm?
Yeni ClickHouse sənədlərində mən əlaqəli bölməni oxudum . Təsvirdə sürətli SSD ilə bir nümunə var.
Maraqlıdır, eyni şeyi həcmi isti yaddaşla necə konfiqurasiya edə bilərsiniz. Və daha bir sual. Seçmə bu məlumat təşkilatı ilə necə işləyir, o, bütün dəsti oxuyacaq, yoxsa sadəcə diskdə olanı və bu məlumat yaddaşda sıxılıbmı? Bəs prewhere bölməsi belə bir məlumat təşkilatında necə işləyir?
Bu parametr məlumat hissələrinin saxlanmasına təsir göstərir və onların formatı heç bir şəkildə dəyişmir.
Gəlin daha yaxından nəzər salaq.
RAM-da məlumatların saxlanmasını təyin edə bilərsiniz. Disk üçün konfiqurasiya edilən hər şey onun yoludur. Siz fayl sistemində hansısa yola quraşdırılmış tmpfs bölməsi yaradırsınız. Bu yolu ən isti bölmə üçün məlumat saxlama yolu kimi göstərin, məlumat parçaları gəlməyə və ora yazılmağa başlayır, hər şey qaydasındadır.
Ancaq aşağı etibarlılıq səbəbindən bunu etməyi məsləhət görmürəm, baxmayaraq ki, müxtəlif məlumat mərkəzlərində ən azı üç replikanız varsa, edə bilərsiniz. Əgər belədirsə, məlumatlar bərpa olunacaq. Təsəvvür edin ki, server qəfil söndürüldü və yenidən işə salındı. Bölmə yenidən quraşdırıldı, ancaq boşluq var. Başlanğıcda ClickHouse serveri bu parçaların əskik olduğunu görür, baxmayaraq ki, ZooKeeper metadatasına görə, onlar olmalıdır. Onların hansı replikalarda olduğuna baxır, onları tələb edir və yükləyir. Beləliklə, məlumatlar bərpa olunacaq.
Bu mənada məlumatların RAM-da saxlanması onların diskdə saxlanmasından prinsipial olaraq fərqlənmir, çünki verilənlər diskə yazılan zaman onlar da əvvəlcə səhifənin ön yaddaşına düşür və sonra fiziki olaraq yazılır. Bu, fayl sisteminin necə qurulduğundan asılıdır. Ancaq hər halda deyəcəm ki, ClickHouse insertdə fsync etmir.
Bu halda, RAM-dakı məlumatlar diskdə olduğu kimi tam olaraq eyni formatda saxlanılır. Seçmə sorğusu eyni şəkildə oxunacaq parçaları seçir, hissələrdə tələb olunan məlumat diapazonlarını seçir və onları oxuyur. Məlumatların RAM-da və ya diskdə olmasından asılı olmayaraq, prewhere tam olaraq eyni işləyir.
Aşağı Kardinallıq neçə unikal dəyərə qədər effektivdir?
Aşağı Kardinallıq çətin məsələdir. O, məlumat lüğətlərini tərtib edir, lakin onlar yerlidir. Birincisi, lüğətlər hər bir parça üçün fərqlidir, ikincisi, hətta bir parça daxilində onlar hər bir diapazon üçün fərqli ola bilər. Unikal dəyərlərin sayı həddi - bir milyona çatdıqda, məncə, lüğət sadəcə kənara qoyulur və yenisi yaradılır.
Cavab ümumidir: hər bir yerli diapazon üçün - deyək ki, hər gün üçün - haradasa bir milyona qədər unikal dəyər, Aşağı Kardinallıq effektivdir. Bundan sonra, yalnız bir deyil, çoxlu müxtəlif lüğətlərin istifadə ediləcəyi bir geri dönüş olacaq. O, simli tipli adi sütunla eyni şəkildə işləyəcək, ola bilsin ki, bir az daha az səmərəli olacaq, lakin performansda ciddi azalma olmayacaq.
Beş milyard cərgədən ibarət cədvəldə tam mətn axtarışı üçün ən yaxşı təcrübələr hansılardır?
Müxtəlif cavablar var. Birincisi, ClickHouse-un tam mətnli axtarış motoru olmadığını söyləməkdir. Bunun üçün xüsusi sistemlər var, məsələn, и . Bununla belə, Elasticsearch-dən ClickHouse-a keçdiyini söyləyən getdikcə daha çox insan görürəm.
Bu niyə baş verir? Bunu Elasticsearch-in indekslərin qurulmasından başlayaraq bəzi cildlərdəki yükün öhdəsindən gəlməyi dayandırması ilə izah edirlər. İndekslər çox çətin olur və sadəcə olaraq məlumatları ClickHouse-a köçürsəniz, onların həcm baxımından bir neçə dəfə daha səmərəli saxlanıldığı ortaya çıxır. Eyni zamanda, axtarış sorğuları çox vaxt elə deyildi ki, morfologiyanı nəzərə alaraq bütün məlumat həcmində bəzi ifadələri tapmaq lazım idi, lakin tamamilə fərqlidir. Məsələn, baytların bəzi ardıcıllığı üçün qeydlərdə son bir neçə saatı tapmaq.
Bu halda, siz ClickHouse-da bir indeks yaradırsınız, ilk sahə zamanla tarix olacaq. Və məlumatların ən böyük kəsilməsi məhz tarix diapazonu üçün olacaqdır. Seçilmiş tarix diapazonu daxilində, bir qayda olaraq, like istifadə edərək, hətta brute-force metodundan istifadə etməklə tam mətn axtarışını həyata keçirmək artıq mümkündür. ClickHouse-da oxşar ifadə tapa biləcəyiniz ən təsirli bəyənmə ifadəsidir. Daha yaxşısını tapsan, mənə de.
Ancaq yenə də tam bir tarama kimi. Və tam tarama yalnız CPU-da deyil, həm də diskdə yavaş ola bilər. Birdən gündə bir terabayt məlumatınız varsa və bir gündə bir söz axtarırsınızsa, bir terabayt skan etməli olacaqsınız. Və yəqin ki, adi sərt disklərdədir və nəticədə onlar elə yüklənəcəklər ki, SSH vasitəsilə bu serverə daxil olmayacaqsınız.
Bu halda mən daha bir kiçik hiylə təklif etməyə hazıram. Bu, eksperimental kateqoriyadandır - işləyə bilər, olmaya da bilər. ClickHouse-da triqram çiçəkləmə filtrləri şəklində tam mətn indeksləri var. Arenadata-dakı həmkarlarımız artıq bu indeksləri sınayıblar və çox vaxt onlar tam nəzərdə tutulduğu kimi işləyirlər.
Onları düzgün istifadə etmək üçün onların necə işlədiyini yaxşı başa düşməlisiniz: triqram çiçək filtri nədir və ölçüsünü necə seçmək olar. Deyə bilərəm ki, bəzi nadir ifadələr, məlumatlarda nadir hallarda rast gəlinən alt sətirlər üzrə sorğulara kömək edəcəklər. Bu halda, alt diapazonlar indekslər tərəfindən seçiləcək və daha az məlumat oxunacaq.
ClickHouse bu yaxınlarda tam mətn axtarışı üçün daha təkmil funksiyalar əlavə etdi. Bu, birincisi, hərflərə həssas, hərflərə həssas olmayan, UTF-8-də dəstəklənən və ya yalnız ASCII variantları daxil olmaqla, bir keçiddə birdən-birə bir dəstə alt sətirlərin axtarışıdır. Sizə lazım olan ən səmərəlisini seçin.
Bir keçiddə bir neçə müntəzəm ifadənin axtarışı da var idi. Bir alt sətir kimi X və ya digər alt sətir kimi X yazmağa ehtiyac yoxdur. Dərhal yazın və hər şey mümkün qədər səmərəli şəkildə edilir.
Üçüncüsü, indi regexps üçün təxmini axtarış və alt sətirlər üçün təxmini axtarış var. Əgər kimsə hərf səhvi olan bir söz yazıbsa, o, maksimum uyğunluq üçün axtarılacaq.
Çox sayda istifadəçi üçün ClickHouse-a girişi təşkil etməyin ən yaxşı yolu nədir?
Çox sayda istehlakçı və analitik üçün girişi ən yaxşı şəkildə necə təşkil edəcəyimizi bizə deyin. Necə növbə yaratmaq, maksimum paralel sorğulara üstünlük vermək və hansı alətlərlə?
Əgər klaster kifayət qədər böyükdürsə, o zaman yaxşı həll yolu analitiklər üçün giriş nöqtəsi olacaq daha iki serverin artırılması olardı. Yəni, analitikləri xüsusi klaster parçalarına buraxmayın, sadəcə məlumat olmadan iki boş server yaradın və artıq onlara giriş hüquqlarını təyin edin. Eyni zamanda, paylanmış sorğular zamanı istifadəçi parametrləri uzaq serverlərə ötürülür. Yəni siz bu iki serverdə hər şeyi konfiqurasiya edirsiniz və parametrlər bütün klasterə təsir edir.
Prinsipcə, bu serverlər məlumatsızdır, lakin onlarda RAM miqdarı sorğuların yerinə yetirilməsi üçün çox vacibdir. Xarici toplama və ya xarici çeşidləmə aktiv olduqda, disk müvəqqəti məlumat üçün də istifadə edilə bilər.
Bütün mümkün məhdudiyyətlərlə əlaqəli olan parametrlərə baxmaq vacibdir. İndi analitik olaraq Yandex.Metrics klasterinə girib sorğu təyin etsəm hitlərdən sayı seçin, onda mənə dərhal bir istisna veriləcək ki, mən sorğunu yerinə yetirə bilmirəm. Skan etməyə icazə verilən sətirlərin maksimum sayı yüz milyarddır və bir cədvəldəki klasterdə cəmi əlli trilyon var. Bu, ilk məhdudiyyətdir.
Tutaq ki, sətirlərin sayına məhdudiyyəti aradan qaldırdım və sorğunu yenidən işə saldım. Sonra aşağıdakı istisnanı görəcəyəm - parametr aktivləşdirildi tarixə görə qüvvə indeksi. Tarix diapazonu göstərməsəm, sorğunu icra edə bilmərəm. Onu əl ilə daxil etmək üçün analitiklərə etibar etmək lazım deyil. Tipik bir hal - bir tarix diapazonu, hadisənin bir həftə arasında olduğu yerdə yazılır. Və sonra orada sadəcə mötərizə göstərmədilər və bunun əvəzinə və ya - və ya URL uyğunluğu olduğu ortaya çıxdı. Heç bir məhdudiyyət yoxdursa, o, URL sütununu tarayacaq və bir ton resurs sərf edəcək.
Bundan əlavə, ClickHouse-un iki prioritet parametri var. Təəssüf ki, onlar çox primitivdirlər. Biri sadəcə olaraq adlandırılır prioritet. Prioritet ≠ 0 olarsa və bəzi prioritetlərə malik sorğular yerinə yetirilirsə, lakin prioritet dəyəri daha aşağı olan sorğu yerinə yetirilirsə, bu, daha yüksək prioritet deməkdir, o zaman prioritet dəyərindən daha yüksək olan sorğu daha aşağı prioritet deməkdir. sadəcə dayandırılıb və bu müddət ərzində heç işləməyəcək.
Bu, çox kobud bir parametrdir və klasterdə daimi yükün olduğu vəziyyətlər üçün uyğun deyil. Ancaq vacib olan qısa, impuls sorğularınız varsa və klaster əsasən boşdursa, bu parametr uyğun olacaq.
Növbəti prioritet parametr çağırılır OS mövzu prioriteti. O, sadəcə olaraq bütün sorğu icrası mövzularını Linux planlaşdırıcısı üçün gözəl dəyərə məruz qoyur. Bu belə işləyir, amma yenə də işləyir. Minimum gözəl dəyər təyin etsəniz - bu, ən böyük dəyərdir və buna görə də ən aşağı prioritetdir - və yüksək prioritet sorğular üçün -19 təyin etsəniz, CPU aşağı prioritetli sorğuları yüksək prioritetlərdən təxminən dörd dəfə az istehlak edəcəkdir.
Siz həmçinin maksimum sorğunun icra müddətini təyin etməlisiniz - deyək ki, beş dəqiqə. Minimum sorğunun icra sürəti ən maraqlı şeydir. Bu parametr uzun müddətdir mövcuddur və yalnız ClickHouse-un yavaşlamadığını təsdiqləmək deyil, onu məcbur etmək tələb olunur.
Təsəvvür edin ki, siz quraşdırırsınız: sorğu saniyədə bir milyondan az sətir emal edirsə, bunu edə bilməzsiniz. Bu, bizim yaxşı adımıza, yaxşı məlumat bazamıza hörmətsizlik edir. Gəlin bunu qadağan edək. Əslində iki parametr var. Biri deyilir min icra sürəti - saniyədə sətirlərdə, ikincisi isə minimum icra sürətini yoxlamadan əvvəl vaxt aşımı adlanır - standart olaraq on beş saniyə. Yəni, on beş saniyə mümkündür və sonra yavaş-yavaş, onda sadəcə bir istisna atın - sorğunu dayandırın.
Siz həmçinin kvota təyin etməlisiniz. ClickHouse resurs istehlakını hesablayan daxili kvota xüsusiyyətinə malikdir. Ancaq təəssüf ki, CPU, disklər kimi dəmir resursları deyil, məntiqi olanlar - işlənmiş sorğuların, oxunan sətirlərin və baytların sayı. Və siz, məsələn, beş dəqiqə ərzində maksimum yüz sorğu və saatda min sorğu qura bilərsiniz.
Niyə vacibdir? Çünki bəzi analitik sorğular birbaşa ClickHouse müştərisindən əl ilə yerinə yetiriləcək. Və hər şey yaxşı olacaq. Amma şirkətinizdə qabaqcıl analitikləriniz varsa, onlar ssenari yazacaqlar və skriptdə xəta ola bilər. Və bu xəta sorğunun sonsuz döngədə yerinə yetirilməsinə səbəb olacaq. Qorunmaq lazım olan budur.
Bir sorğunun nəticəsini on müştəriyə vermək olarmı?
Eyni zamanda çox böyük sorğularla daxil olmağı xoşlayan bir neçə istifadəçimiz var. Müraciət böyükdür, prinsipcə tez icra olunur, lakin eyni vaxtda belə müraciətlərin çox olması səbəbindən çox ağrılı olur. Ardıcıl olaraq on dəfə gələn eyni sorğunu bir dəfə icra edib on müştəriyə nəticəsini vermək olarmı?
Problem ondadır ki, bizdə keş nəticələri və ya aralıq məlumat keşi yoxdur. Əməliyyat sisteminin səhifə önbelleği var, bu, diskdən məlumatları yenidən oxumamağa imkan verəcək, lakin təəssüf ki, məlumatlar hələ də sıxılmış, seriyadan çıxarılacaq və yenidən işlənəcəkdir.
Ya aralıq məlumatları keşləməklə, ya da oxşar sorğuları bir növ növbəyə düzmək və nəticələrin keşini əlavə etməklə birtəhər bunun qarşısını almaq istərdim. İndi inkişafda bir sorğu keşi əlavə edən bir çəkmə sorğumuz var, lakin yalnız daxil və qoşulma bölmələrindəki alt sorğular üçün - yəni həll daha aşağıdır.
Halbuki bizdə də belə bir vəziyyət var. Xüsusilə kanonik nümunə səhifələşdirmə ilə sorğulardır. Hesabat var, onun bir neçə səhifəsi var və 10 limit tələbi var.Sonra eyni şey, lakin limit 10,10. Sonra başqa səhifə. Və sual budur ki, niyə biz hər dəfə hamısını hesablayırıq? Ancaq indi bunun həlli yoxdur və bundan qaçmaq üçün heç bir yol yoxdur.
ClickHouse-un yanında yan araba kimi yerləşdirilən alternativ bir həll var - .
Kirill Şvakov: ClickHouse Proxy-də daxili sürət məhdudlaşdırıcısı və daxili nəticələr keşi var. Orada bir çox parametrlər edildi, çünki oxşar tapşırıq həll edildi. Proksi sizə sorğuları növbəyə qoymaqla məhdudlaşdırmağa və sorğu keşinin nə qədər müddətə qaldığını konfiqurasiya etməyə imkan verir. Əgər sorğular həqiqətən eyni olsaydı, Proksi onları dəfələrlə verəcək və ClickHouse-a yalnız bir dəfə gedəcək.
Nginx-in pulsuz versiyasında da bir önbellek var və bu da işləyəcək. Nginx hətta parametrlərə malikdir ki, sorğular eyni vaxtda daxil olarsa, biri tamamlanana qədər digərlərini dayandıracaq. Ancaq ClickHouse Proxy-də parametrlər daha yaxşı edilir. Xüsusilə ClickHouse üçün, xüsusi olaraq bu sorğular üçün hazırlanmışdır, ona görə də daha uyğundur. Yaxşı, qurmaq asandır.
Asinxron əməliyyatlar və maddiləşdirilmiş görünüşlər haqqında nə demək olar?
Belə bir problem var ki, əvəzedici mühərriklə əməliyyatlar asinxrondur - məlumatlar əvvəlcə yazılır, sonra çökür. Planşetin altında bəzi aqreqatları olan materiallaşdırılmış planşet yaşayırsa, ona dublikatlar yazılacaq. Əgər mürəkkəb məntiq yoxdursa, o zaman məlumatlar təkrarlanacaq. Bununla bağlı nə etmək olar?
Aşkar bir həll var - asinxron çökmə əməliyyatı zamanı müəyyən bir matview sinifində bir tətik tətbiq etmək. Belə funksionallığı həyata keçirmək üçün hər hansı "gümüş güllə" planları varmı?
Deuplikasiyanın necə işlədiyini başa düşməyə dəyər. Deyəcəklərim sualla bağlı deyil, amma hər ehtimala qarşı xatırlamağa dəyər.
Təkrarlanan cədvələ daxil edərkən bütün daxil edilmiş blokların təkmilləşməsi baş verir. Eyni sıradakı eyni sıraları ehtiva edən eyni bloku yenidən daxil etsəniz, məlumat təkrarlanır. Siz əlavəyə cavab olaraq "Ok" alacaqsınız, lakin məlumatların bir toplusu faktiki olaraq yazılacaq və onlar təkrarlanmayacaq.
Bu, əminlik üçün lazımdır. Daxil edərkən "Ok" alsanız, məlumatlarınız daxil edilmişdir. ClickHouse-dan xəta alsanız, onlar daxil edilməyib və siz daxil etməyi təkrarlamalısınız. Ancaq daxiletmə zamanı əlaqə pozulubsa, o zaman məlumatların daxil edilib-edilmədiyini bilmirsiniz. Yeganə seçim əlavəni yenidən təkrarlamaqdır. Əgər verilənlər həqiqətən daxil edilibsə və siz onu yenidən daxil etmisinizsə, blok təkmilləşdirmə var. Dublikatların qarşısını almaq üçün lazımdır.
Və onun maddiləşdirilmiş baxışlar üçün necə işlədiyi də vacibdir. Əgər verilənlər əsas cədvələ daxil edilərkən təkmilləşdirilibsə, o zaman onlar da maddiləşdirilmiş görünüşə keçməyəcəklər.
İndi sual haqqında. Fərdi sətirlərin dublikatlarını yazdığınız üçün vəziyyətiniz daha mürəkkəbdir. Yəni bütün paket deyil, konkret xətlər təkrarlanır və onlar arxa planda çökür. Həqiqətən də, verilənlər əsas cədvəldə dağılacaq, dağılmayanlar isə maddiləşdirilmiş görünüşə keçəcək və birləşmə zamanı maddiləşdirilmiş görünüşlərə heç nə olmayacaq. Çünki maddiləşdirilmiş görünüş insertdəki tətikdən başqa bir şey deyil. Digər əməliyyatlar zamanı ona başqa heç nə baş vermir.
Və mən burada xoşbəxt ola bilmirəm. Yalnız bu iş üçün xüsusi bir həll axtarmaq lazımdır. Məsələn, onu maddiləşdirilmiş bir görünüşdə əvəz etmək mümkündürmü və deduplikasiya üsulu, bəlkə də, eyni şəkildə işləyəcək. Amma təəssüf ki, həmişə deyil. Əgər toplanırsa, o zaman işləməyəcək.
Kirill Şvakov: Bizdə də bir vaxtlar sümük quruluşu olub. Problem var idi ki, reklam təəssüratları var və real vaxtda göstərə biləcəyimiz bəzi məlumatlar var - bunlar sadəcə təəssüratlardır. Nadir hallarda təkrarlanırlar, lakin əgər təkrarlanırsa, onsuz da sonra onları məhv edəcəyik. Və təkrarlana bilməyən şeylər var idi - kliklər və bütün bu hekayə. Amma mən də onları demək olar ki, dərhal göstərmək istədim.
Maddiləşdirilmiş fikirlər necə yarandı? Birbaşa yazılan baxışlar var idi - xam məlumatlarda rekord var, baxışlarda da yazılır. Orada, müəyyən bir nöqtədə, məlumatlar çox düzgün deyil, onlar təkrarlanır və s. Cədvəlin ikinci hissəsi də var ki, burada onlar maddiləşmiş görünüşlərlə tam eyni görünür, yəni quruluşca tam eynidir. Bir dəfə biz məlumatları yenidən hesablayırıq, məlumatları dublikatsız sayırıq, həmin cədvəllərə yazırıq.
API-dən keçdik - bu, ClickHouse-da əl ilə işləməyəcək. Və API görünür: cədvələ sonuncu əlavənin tarixi olduğu zaman, düzgün məlumatların artıq hesablandığına zəmanət verilir və o, bir cədvələ və digər cədvələ sorğu verir. Bir sorğudan müəyyən bir müddətə qədər seçir, digərindən isə hələ hesablanmamış şeyi alır. Və işləyir, lakin bir ClickHouse vasitəsilə deyil.
Əgər bir növ API-niz varsa - analitiklər üçün, istifadəçilər üçün - o zaman, prinsipcə, bu bir seçimdir. Həmişə sayarsan, həmişə sayarsan. Bu gündə bir dəfə və ya başqa vaxt edilə bilər. Siz özünüz üçün sizə lazım olmayan və kritik olmayan çeşidi seçirsiniz.
ClickHouse-da çoxlu qeydlər var. Bir anda serverdə baş verən hər şeyi necə görə bilərəm?
ClickHouse-da çoxlu sayda müxtəlif qeydlər var və bu say artır. Yeni versiyalarda onlardan bəziləri hətta standart olaraq aktivləşdirilir, köhnə versiyalarda yenilənərkən aktivləşdirilməlidir. Bununla belə, onların sayı getdikcə daha çoxdur. Nəhayət, indi serverimlə nə baş verdiyini görmək istərdim, bəlkə də bəzi xülasə tablosunda.
ClickHouse komandasında və ya dostlarınızın komandalarında bu qeydləri hazır məhsul kimi göstərən hazır tablosunun bəzi funksionallığını dəstəkləyən varmı? Nəhayət, sadəcə ClickHouse-da qeydlərə baxmaq əladır. Ancaq artıq bir tablosunda hazırlanmış olsaydı, çox gözəl olardı. Mən bunu yüksək qiymətləndirərdim.
Standartlaşdırılmasa da, tablolar var. Şirkətimizdə ClickHouse-dan istifadə edən 60-a yaxın komandamız var və ən qəribəsi odur ki, onların bir çoxunun özləri hazırladıqları və bir az fərqli idarə panelləri var. Bəzi komandalar Yandex.Cloud-un daxili quraşdırılmasından istifadə edirlər. Lazım olanların hamısı olmasa da, bəzi hazır hesabatlar var. Başqalarının da öz var.
Metrica-dan olan həmkarlarımın Grafana-da öz panelləri var, mənim isə öz klasterim var. Mən serif keşi üçün keş hit kimi şeylərə baxıram. Və daha da çətin ki, biz müxtəlif vasitələrdən istifadə edirik. İdarə panelimi Graphite-web adlı çox köhnə alətdə yaratdım. O, tamamilə çirkindir. Və mən hələ də bu şəkildə istifadə edirəm, baxmayaraq ki, Grafana yəqin ki, daha rahat və daha gözəl olardı.
Tablolardakı əsas şey eynidir. Bunlar klaster üçün sistem ölçüləridir: CPU, yaddaş, disk, şəbəkə. Digərləri eyni vaxtda edilən sorğuların sayı, eyni vaxtda birləşmələrin sayı, saniyədə edilən sorğuların sayı, MergeTree cədvəlinin bölmələri üçün maksimum parça sayı, təkrarlama gecikməsi, təkrarlama növbəsinin ölçüsü, saniyədə daxil edilən sətirlərin sayı, saniyədə daxil edilən blokların sayı. Bu, jurnallardan deyil, ölçülərdən əldə edilənlərin hamısıdır.
Vladimir Kolobayev: Aleksey, bir az düzəltmək istərdim. Qrafana var. Grafana-da ClickHouse məlumat mənbəyi var. Yəni mən Grafana-dan birbaşa ClickHouse-a sorğu verə bilərəm. ClickHouse-un qeydləri olan bir cədvəli var, hamı üçün eynidir. Nəticədə mən Grafana-da bu jurnal cədvəlinə daxil olmaq və serverimin tətbiq etdiyi sorğuları görmək istəyirəm. Belə bir tablosunun olması əla olardı.
Mən özüm velosiped sürdüm. Ancaq bir sualım var - əgər hamısı standartlaşdırılıbsa və Grafana hamı tərəfindən istifadə olunursa, niyə Yandex-də belə bir rəsmi idarə paneli yoxdur?
Kirill Şvakov: Əslində, ClickHouse-un məlumat mənbəyi indi Altinity-ni dəstəkləyir. Və mən sadəcə harada qazmağın və kimin itələyəcəyinin vektorunu vermək istəyirəm. Onlardan soruşa bilərsiniz, çünki Yandex hələ də ətrafdakı hekayəni deyil, ClickHouse edir. Altinity hazırda ClickHouse-u təşviq edən əsas şirkətdir. Onu tərk etməyəcəklər, əksinə, dəstəkləyəcəklər. Çünki Prinsipcə, Grafana veb saytına tablosunu yükləmək üçün sadəcə qeydiyyatdan keçmək və yükləmək lazımdır - heç bir xüsusi problem yoxdur.
Aleksey Milovidov: Keçən il ərzində ClickHouse bir çox sorğu profili xüsusiyyətləri əlavə etdi. Hər bir resurs istifadəsi sorğusu üçün ölçülər var. Və bu yaxınlarda sorğunun hər millisaniyəni hara sərf etdiyini görmək üçün daha aşağı səviyyəli sorğu profili əlavə edildi. Amma bu funksionallıqdan istifadə etmək üçün mən konsol müştərisini açmalı və unutduğum sorğunu yazmalıyam. Mən onu bir yerdə saxladım və həmişə dəqiq harada unuduram.
Kaş ki, sadəcə deyən bir alət olsaydı - burada sorğu sinifinə görə qruplaşdırılmış ağır sorğularınız var. Birinə klik etdim, mənə deyəcəklər ki, ona görə də ağırdır. İndi belə bir həll yoxdur. Və həqiqətən çox qəribədir ki, insanlar məndən soruşduqda: "Mənə deyin, Qrafana üçün hazır tablolar varmı?" Kostyandan. Nə olduğunu bilmirəm, özüm də istifadə etməmişəm”.
Serverin OOM-a düşməməsi üçün merdzhi-yə necə təsir etmək olar?
Mənim cədvəlim var, cədvəldə yalnız bir bölmə var, bu ReplacingMergeTree-dir. Mən dörd ildir ki, ona məlumat yazıram. Orada dəyişiklik etməli və bəzi məlumatları silməli oldum.
Mən bunu etdim və bu sorğunun işlənməsi zamanı klasterdəki bütün serverlərdəki bütün yaddaş yeyildi və klasterdəki bütün serverlər birlikdə OOM-a keçdi. Sonra hamısı birlikdə ayağa qalxdılar, eyni əməliyyatı, bu məlumat blokunu birləşdirməyə başladılar və yenidən OOM-a düşdülər. Sonra yenə ayağa qalxdılar və yenə yıxıldılar. Və bu iş dayanmadı.
Sonra məlum oldu ki, bu, əslində uşaqların düzəltdiyi bir səhvdir. Bu çox gözəldir, çox sağ olun. Ancaq qalıq qaldı. İndi isə cədvəldə müəyyən birləşmənin aparılması zərurəti barədə düşünəndə məndə belə bir sual yaranır – niyə mən bu birləşmələri götürə bilmirəm və hansısa şəkildə onlara təsir edə bilmirəm? Məsələn, onları tələb olunan RAM miqdarı ilə və ya prinsipcə, bu xüsusi cədvəli emal edəcək onların sayı ilə məhdudlaşdırın.
Mənim "Metriklər" adlı cədvəlim var, lütfən, onu mənim üçün iki axınla emal edin. Paralel olaraq on və ya beş birləşmə istehsal etməyə ehtiyac yoxdur, bunu ikidə edin. Düşünürəm ki, ikidə kifayət qədər yaddaşım var, amma on işləməyə kifayət etməyə bilər. Niyə qorxu qalır? Çünki cədvəl böyüyür və bir gün mən bir vəziyyətlə qarşılaşacağam ki, bu, prinsipcə, artıq bir səhvə görə deyil, məlumatların o qədər böyük miqdarda dəyişəcəyinə görə, sadəcə yaddaşımda kifayət deyil. server. Və sonra birləşmə zamanı server OOM-a düşəcək. Üstəlik, mutasiyanı ləğv edə bilərəm, amma birləşmə getdi.
Bilirsiniz, birləşmə zamanı server OOM-a düşməyəcək, çünki birləşmə zamanı RAM miqdarı yalnız bir kiçik məlumat diapazonu üçün istifadə olunur. Beləliklə, məlumatların miqdarından asılı olmayaraq hər şey yaxşı olacaq.
Vladimir Kolobayev: Yaxşı. Budur, an belədir ki, səhvləri düzəltdikdən sonra özüm üçün yeni bir versiya yüklədim və çox sayda bölmənin olduğu daha kiçik bir masada oxşar əməliyyat etdim. Və birləşmə zamanı serverdə təxminən 100 GB RAM yandırıldı. 150 məşğul idim, 100 yedim və 50 GB pəncərə qaldı, ona görə də OOM-a düşmədim.
Həqiqətən 100 GB RAM istehlak edərsə, məni hazırda OOM-a düşməkdən nə qoruyur? Birdən merdzh-də RAM bitərsə, bir vəziyyətdə nə etməli?
Aleksey Milovidov: Belə bir problem var ki, RAM istehlakı merdzhi ilə məhdudlaşmır. İkinci problem odur ki, əgər birləşmə təyin edilibsə, o zaman icra edilməlidir, çünki replikasiya jurnalına yazılır. Replikasiya jurnalı replikanı ardıcıl vəziyyətə gətirmək üçün lazım olan hərəkətlərdir. Bu təkrarlama jurnalının geri dönəcəyinə dair əl ilə manipulyasiyalar etməsəniz, birləşmə bu və ya digər şəkildə yerinə yetirilməli olacaq.
Əlbətdə ki, OOM-dan "hər halda" qoruyan RAM-da məhdudiyyətin olması artıq olmazdı. Birləşməyə kömək etməyəcək, yenidən başlayacaq, müəyyən bir həddə çatacaq, istisna atacaq və sonra yenidən başlayacaq - bundan yaxşı bir şey olmayacaq. Amma prinsipcə, bu məhdudiyyəti tətbiq etmək faydalı olardı.
ClickHouse üçün Golang sürücüsünün inkişafı necə baş verəcək?
Kirill Şvakov tərəfindən yazılmış Qolanq sürücüsü indi rəsmi olaraq ClickHouse komandası tərəfindən dəstəklənir. O , o, indi böyük və realdır.
Kiçik bir qeyd. Sonsuz nizamın normal formalarının gözəl və sevimli anbarı var - bu Vertica. Onların həmçinin Vertica tərtibatçıları tərəfindən idarə olunan öz rəsmi python sürücüsü var. Və bir neçə dəfə belə oldu ki, yaddaşın versiyaları və sürücünün versiyaları kəskin şəkildə ayrıldı və sürücü bir anda işləməyi dayandırdı. Və ikinci an. Bu rəsmi sürücüyə dəstək, mənə elə gəlir ki, "məmə" sistemi tərəfindən təmin edilir - siz onlara bir məsələ yazırsınız və o, əbədi olaraq qalır.
Mənim iki sualım var. İndi Kirill-in Golang sürücüsü Golang-dan ClickHouse ilə ünsiyyət üçün demək olar ki, standart bir yoldur. Kimsə hələ də http interfeysi ilə ünsiyyət qurmasa, çünki onu çox sevir. Bu sürücü necə inkişaf etdiriləcək? O, anbarın özündə bəzi qırılma dəyişiklikləri ilə sinxronlaşdırılacaqmı? Və məsələyə baxılması proseduru necədir?
Kirill Şvakov: Birincisi, hər şeyin bürokratik şəkildə necə qurulduğudur. Bu məqam müzakirə olunmayıb, ona görə də cavab verəcək heç nəyim yoxdur.
Məsələ ilə bağlı suala cavab vermək üçün sürücünün bir az tarixinə ehtiyacımız var. Çox məlumatı olan bir şirkətdə işlədim. Bu, bir yerdə saxlanması lazım olan çoxlu sayda hadisələrə malik bir reklam əyiricisi idi. Və bir anda ClickHouse göründü. Biz ona məlumat tökdük və əvvəlcə hər şey yaxşı idi, lakin sonra ClickHouse düşdü. O zaman qərara gəldik ki, bizə lazım deyil.
Bir il sonra biz ClickHouse-dan istifadə fikrinə qayıtdıq və birtəhər orada məlumat yazmaq lazım idi. Giriş belə idi - dəmir çox zəifdir, resurslar azdır. Amma biz həmişə belə işləmişik və ona görə də doğma protokola baxmışıq.
Go üzərində işlədiyimiz üçün Go sürücüsünə ehtiyacımız olduğu aydın idi. Mən bunu demək olar ki, tam vaxtda etdim - bu mənim iş tapşırığım idi. Müəyyən bir nöqtəyə qədər bunu gündəmə gətirdik və prinsipcə, bizdən başqasının istifadə edəcəyini heç kim gözləmirdi. Sonra CloudFlare eyni problemlə gəldi və bir müddət onlarla çox rəvan işlədik, çünki onların eyni vəzifələri var idi. Və biz bunu həm ClickHouse-un özündə, həm də sürücüdə etdik.
Nə vaxtsa mən bunu etməyi dayandırdım, çünki ClickHouse və iş baxımından fəaliyyətim bir az dəyişdi. Ona görə də məsələlər bağlanmır. Vaxtaşırı nəyəsə ehtiyacı olan insanlar özləri depoya müraciət edirlər. Sonra çəkmə sorğusuna baxıram və bəzən özüm də nəyisə redaktə edirəm, lakin bu nadir hallarda olur.
Mən sürücüyə qayıtmaq istəyirəm. Bir neçə il əvvəl, hər şey başlayanda, ClickHouse da fərqli və fərqli xüsusiyyətlərə malik idi. İndi sürücünün yaxşı olması üçün necə yenidən düzəltmək barədə bir anlayış var. Bu baş verərsə, onda yığılmış qoltuqağa görə versiya 2 onsuz da uyğun gəlməyəcək.
Bunu necə təşkil edəcəyimi bilmirəm. Mənim özüm də çox vaxtım yoxdur. Bəzi adamlar sürücünü bitirsə, onlara kömək edib, nə etməli olduqlarını deyə bilərəm. Lakin layihənin inkişafında Yandex-in fəal iştirakı hələ heç bir şəkildə müzakirə olunmayıb.
Aleksey Milovidov: Əslində bu sürücülərlə bağlı hələlik bürokratiya yoxdur. Yeganə odur ki, onlar rəsmi bir təşkilata köçürülür, yəni bu sürücü Go üçün rəsmi standart həll kimi tanınır. Başqa sürücülər də var, amma onlar ayrı-ayrılıqda gəlirlər.
İçəridə bu sürücülər üçün heç bir inkişafımız yoxdur. Sual ondan ibarətdir ki, biz konkret olaraq bu sürücü üçün deyil, bütün icma sürücülərinin inkişafı üçün fərdi işə götürə bilərikmi, yoxsa kənarda kimsə tapa bilərikmi?
Xarici lüğət lazy_load aktivləşdirildikdən sonra yenidən yükləndikdən sonra qaldırılmır. Nə etməli?
Bizdə lazy_load parametri aktivləşdirilib və server yenidən işə salındıqdan sonra lüğət özü qalxmır. O, yalnız istifadəçi bu lüğətə daxil olduqdan sonra qaldırılır. Və ilk zəngdə xəta verir. ClickHouse-dan istifadə edərək lüğətləri hər hansı bir şəkildə avtomatik yükləmək mümkündürmü, yoxsa istifadəçilərin səhvləri almaması üçün onların hazırlığına həmişə özünüz nəzarət etməlisiniz?
Yəqin ki, bizdə ClickHouse-un köhnə versiyası var, ona görə də lüğət avtomatik yüklənməyib. Ola bilər?
Birincisi, lüğətlər sorğudan istifadə edərək məcburi yüklənə bilər sistem lüğətləri yenidən yükləyin. İkincisi, səhv haqqında - əgər lüğət artıq yüklənibsə, sorğular yüklənmiş məlumatlar üzərində işləyəcək. Lüğət hələ yüklənməyibsə, o zaman birbaşa sorğu zamanı yüklənəcək.
Ağır lüğətlər üçün bu çox rahat deyil. Məsələn, MySQL-dən bir milyon sətir götürməlisiniz. Kimsə sadə seçim edir, lakin bu seçim eyni milyon sıra gözləyəcək. Burada iki həll yolu var. Birincisi, lazy_load-u söndürməkdir. İkincisi, server yüksəldikdə, yükü açmadan əvvəl edin sistemi yenidən yükləmək lüğəti və ya sadəcə lüğətdən istifadə edən sorğunu yerinə yetirin. Sonra lüğət yüklənəcək. Lüğətlərin mövcudluğuna lazy_load parametrini aktivləşdirərək nəzarət etməlisiniz, çünki ClickHouse onları avtomatik olaraq yuxarı çəkmir.
Son sualın cavabı odur ki, ya versiya köhnədir, ya da onu aradan qaldırmaq lazımdır.
Ən azı biri xəta ilə qəzaya uğrayarsa, sistemin yenidən yükləndiyi lüğətlərin çoxlu lüğətlərdən heç birini yükləməməsi haqqında nə demək olar?
Sistemin yenidən yüklənməsi lüğətləri ilə bağlı başqa bir sual var. İki lüğətimiz var - biri yüklənmir, ikincisi yüklənir. Sistemin yenidən yüklənməsi lüğətləri bu halda heç bir lüğəti yükləmir və siz sistem yenidən yükləmə lüğətindən istifadə edərək konkret birini adı ilə nöqtədən nöqtəyə yükləməlisiniz. Bunun ClickHouse versiyası ilə də əlaqəsi varmı?
xahiş edirəm. Bu davranış dəyişdi. Beləliklə, ClickHouse-u yeniləsəniz, o da dəyişəcək. Mövcud davranışınız sizi qane etmirsə sistem lüğətləri yenidən yükləyin, yeniləyin və ümid edək ki, o, yaxşılığa doğru dəyişəcək.
ClickHouse konfiqurasiyasında təfərrüatları konfiqurasiya etmək, lakin onları səhvlər üzərində işıqlandırmaq üçün bir yol varmı?
Növbəti sual lüğətlə bağlı səhvlər, yəni təfərrüatlar haqqındadır. Biz əlaqə təfərrüatlarını ClickHouse konfiqurasiyasında lüğətdə qeydiyyatdan keçirmişik və xəta baş verərsə, cavab olaraq bu detalları və parolu alırıq.
ODBC sürücü konfiqurasiyasına təfərrüatlar əlavə etməklə bu səhvi həll etdik. ClickHouse konfiqurasiyasında təfərrüatları konfiqurasiya etmək üçün bir yol var, lakin bu təfərrüatları səhvlərdə göstərməyin?
Burada həll həqiqətən budur - bu etimadnamələri odbc.ini-də və ClickHouse-un özündə müəyyən etmək üçün yalnız ODBC Məlumat Mənbəsinin Adını göstərin. Bu, digər lüğət mənbələri üçün baş verməyəcək - nə MySQL ilə lüğət üçün, nə də qalanları üçün səhv mesajında parolu görməməlisiniz. ODBC üçün mən də baxacağam - əgər belə bir şey varsa, sadəcə onu çıxarmaq lazımdır.
Bonus: görüşlərdən Zuma üçün fonlar
Ən israrlı oxucular üçün şəkilə klikləməklə, toplantılardan bonus fonları açılacaq. Avitonun texnologiya maskotları ilə birlikdə yanğını söndürmək, sistem administratorunun otağından və ya köhnə məktəb kompüter klubundan olan həmkarları ilə məsləhətləşmək və qraffiti fonunda körpünün altında gündəlik keçirmək.
Mənbə: www.habr.com