— bu, Yandex tərəfindən yaradılmış, analitik sorğuları onlayn emal etmək üçün açıq mənbəli sütun əsaslı məlumat bazası sistemidir (OLAP). Bunu Yandex, CloudFlare, VK.com, Badoo və dünyanın digər xidmətləri həqiqətən böyük məlumat həcmlərini saxlamaq üçün istifadə edir (saniyədə minlərlə sətir daxil etmə və ya diskdə petabaytlarla məlumat saxlama).
Tipik «sətir» məlumat bazası sistemlərində, məsələn, MySQL, Postgres, MS SQL Server ilə, məlumatlar aşağıdakı kimi saxlanılır:
Bu zaman bir sətirə aid olan dəyərlər fiziki olaraq yan-yana saxlanılır. Sütun əsaslı məlumat bazası sistemlərində fərqli sütunlardan olan dəyərlər ayrı-ayrılıqda saxlanılır, bir sütunun məlumatları isə bir yerdədir:
Sütun əsaslı məlumat bazası sistemlərinə Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+ aiddir.
Şirkət – mail-продакшн 2018-ci ildən Clickhouse-u hesabatlar hazırlamaq üçün istifadə etməyə başlamış və onun sadəliyi, genişləndirilə bilməsi, SQL dəstəyi və sürəti ilə çox heyran qalmışdır. Bu məlumat bazasının iş sürəti sehrə bənzəyirdi.
Kolaylık
Clickhouse, Ubuntu-da yalnız bir əmrlə quraşdırılır. Əgər siz SQL bilirsinizsə, Clickhouse-u dərhal ehtiyaclarınız üçün istifadə etməyə başlaya bilərsiniz. Lakin, bu «show create table» əməlini MySQL-də yerinə yetirib SQL-i Clickhouse-a kopyalayacağınız anlamına gəlmir.
MySQL ilə müqayisədə, bu məlumat bazasında cədvəl sxemlərinin təriflərində mühim fərqlər var, buna görə də rahat işləmək üçün cədvəl sxemlərinin təriflərini dəyişdirmək və cədvəl mühərriklərini öyrənmək üçün bir qədər zamana ehtiyacınız olacaq.
Clickhouse əlavə proqram təminatı olmadan mükəmməl işləyir, lakin əgər siz replikasiyanı istifadə etmək istəyirsinizsə, ZooKeeper-i quraşdırmalısınız. Sorğu performansının analizi mükəmməl nəticələr göstərir — sistem cədvəlləri bütün məlumatları ehtiva edir və bütün məlumatlar köhnə və darıxdırıcı SQL vasitəsilə əldə edilə bilər.
Performans
- Clickhouse-un Vertica və MySQL ilə müqayisəsi, konfiqurasiyalı serverdə: iki Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; 8 6TB SATA HDD, ext4 üzərində md RAID-5.
- Clickhouse-un Amazon RedShift bulud məlumat anbarı ilə müqayisəsi.
- Blogdan çıxarışlar :
ClickHouse verilənlər bazası çox sadə dizayna malikdir - klasterdə bütün düyünlər eyni funksionallığa malikdir və yalnız ZooKeeper-dən istifadə edərək koordinasiya olunur. Biz bir neçə düyündən ibarət kiçik bir klaster qurduq və test etmə zamanı sistemin analitik DB-lərin benchmarklarında göstərilən üstünlüklərə uyğun olduqca təsir edici bir performansa sahib olduğunu aşkar etdik. ClickHouse-un əsasında duran konsepsiyanı daha yaxından araşdırmağa qərar verdik. Araşdırmalar üçün ilk maneə, alətlərin olmaması və ClickHouse icmasının azlığı oldu, buna görə də bu verilənlər bazasının dizaynına dərinləşdik ki, onun necə işlədiyini başa düşək.
ClickHouse, məlumatları birbaşa Kafka-dan qəbul etmir, çünki bu sadəcə bir verilənlər bazasıdır, buna görə də biz Go dilində öz adapter xidmətimizi yazdıq. O, Kafka-da kodlaşdırılmış mesajları oxuyur, onları TSV-yə çevirir və ClickHouse-a HTTP interfeysi vasitəsilə paketlər şəklində göndərir. Sonra biz bu xidməti yenidən yazdıq ki, Go kitabxanasını ClickHouse-un öz interfeysi ilə birlikdə istifadə edək və performansı artırdıq. Paketlərin qəbul performansını dəyərləndirdikdə, ClickHouse-un bu performansının paket ölçüsündən, yəni eyni anda daxil edilən sətir sayından çox asılı olduğunu aşkar etdik. Bunun niyə baş verdiyini anlamaq üçün ClickHouse-un məlumatları necə saxladığını araşdırdıq.
ClickHouse-un məlumatları saxlamaq üçün istifadə etdiyi əsas mühərrik, daha doğrusu, cədvəllər üçün mühərriklər ailəsi MergeTree-dir. Bu mühərrik, Google BigTable və ya Apache Cassandra-da tətbiq olunan LSM algoritminə konseptual olaraq bənzəyir, lakin aralıq yaddaş cədvəlini yaratmır və məlumatları birbaşa diskinə yazır. Bu, yazma üçün əla keçid xüusiyyətinə malikdir, çünki daxil edilən hər paket yalnız “birincil açar” (primary key) ilə sıralanır, sıxılır və diskə yazılır ki, seqment yaradılsın.
Yaddaş cədvəlinin olmaması və ya məlumatların “təzəliyi” anlayışının olmaması, onların yalnız əlavə edilə biləcəyini, dəyişdirilməsi və ya silinməsi sistem tərəfindən dəstəklənmədiyini də bildirir. Bu gün məlumatları silmək üçün yeganə yol, onları təqvim ayları üzrə silməkdir, çünki seqmentlər heç vaxt ayın sərhədini keçmir. ClickHouse komandası bu funksiyanı konfiqurasiya oluna bilən etmək üzərində fəal çalışır. Digər tərəfdən, bu, seqmentlərin yazılmasını və birləşməsini mübahisəsiz edir, buna görə də qəbulun keçid xüusiyyəti paralel daxil edilənlər sayının artması ilə xətt üzrə genişlənir, I/O və nüvələrin doyma vəziyyətinə çatdığına qədər.
Ancaq bu hal sistemin kiçik paketlər üçün uyğun olmadığını göstərir, buna görə də Kafka xidmətləri və inserterlər istifadə olunur. Daha sonra ClickHouse arxa planda daima seqmentlərin birləşdirilməsini həyata keçirir, beləliklə, bir çox kiçik məlumat hissələri birləşdirilərək daha çox sayda yazılır, bu da yazma intensivliyini artırır. Bu zaman çox sayda bağlı olmayan hissə, birləşmə davam edərkən insertlərin aqressiv şəkildə tıxanmasına səbəb olacaq. Bizim tapdığımız ən yaxşı kompromis, real vaxtda məlumat qəbul etmə ilə qəbulun performansı arasında, saniyədə məhdud sayda insertləri cədvələ qəbul etməkdir.
Cədvəllərin oxuma performansının açarı indeksləşdirmə və məlumatın diskdəki yerləşimidir. İstənilən qədər sürətli emal olsa da, motorun disklə terabaytlarla məlumatı taraması və yalnız bir qismini istifadə etməsi zaman alır. ClickHouse sütun əsaslı bir anbar olduğu üçün hər seqment, hər sətir üçün sıralanmış dəyərləri olan hər sütun üçün bir fayl saxlayır. Bu səbəbdən, sorğuda olmayan bütün sütunlar əvvəlcə atlanıla bilər və daha sonra bir neçə hüceyrə paralel şəkildə vektorlaşdırılmış icra ilə emal oluna bilər. Tam skan etmənin qarşısını almaq üçün, hər seqmentin kiçik bir indeks faylı var.
Bütün sütunlar "birinci açar" üzrə sıralandığı üçün, indeks faylı yalnız hər N-ci sətrin etiketlərini (tutulan sətirlər) saxlayır və çox böyük cədvəllər üçün bunları yaddaşda saxlamağa imkan verir. Məsələn, "hər 8192-ci sətri etiketləmək" üçün standart parametrləri quraşdırmalısınız, beləliklə, yaddaşa asanlıqla yerləşə bilən 1 trilyon sətirli cədvəlin "sade" indeksləşməsi yalnız 122070 xarakter tələb edəcəkdir.
Sisteminin inkişafı
Clickhouse-un inkişafı və təkmilləşdirilməsi məlumatların "böyümə" prosesinin heyrətamiz sürətlə gedildiyini və sübut etməyə imkan verir.
Populyarlıq
Görünür ki, Clickhouse-un populyarlığı getdikcə artır, xüsusilə da rus dilli icmada. Keçən ilki High load 2018 konfransı (Moskva, 8-9 noyabr 2018) göstərdi ki, vk.com və Badoo kimi nəhənglər Clickhouse-dan istifadə edir, burada məlumatlar (məsələn, jurnallar) on minlərlə serverdən eyni anda daxil edilir. 40 dəqiqəlik videoda . Tezliklə materialla işləmək üçün Habrda transkripti paylaşacağıq.
Tətbiq sahələri
Araşdırmalara bir müddət sərf etdikdən sonra, ClickHouse-un MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot və Druid kimi daha ənənəvi və populyar həlləri tamamilə əvəz edə biləcəyi və ya faydalı ola biləcəyi sahələr mövcud olduğunu düşünürəm. Aşağıda ClickHouse-un qeyd olunan DBMS-lərin müasirləşdirilməsi və ya tam əvəz edilməsi üçün istifadə olunması haqqında məlumat verilmişdir.
MySQL və PostgreSQL-in imkanlarını genişləndirmək
Tezliklə Mautic e-poçt bülletenləri üçün MySQL-i ClickHouse ilə qismən əvəz etdik . Problemin kökü, MySQL-in düşüncəsiz dizaynı səbəbindən göndərilmiş hər bir e-poçtu və həmin e-poçtdakı hər bir keçidi base64 hash-ı ilə qeydə alması idi ki, bu da MySQL cədvəlinin (email_stats) böyüməsinə səbəb oldu. Bu xidmətdən 10 milyon e-poçt göndərdikdən sonra, bu cədvəl 150 GB fayl sahəsi tuturdu və MySQL sadə sorğularda "yavaşlayırdı". Fayl sahəsi problemini həll etmək üçün, İnnodb cədvəlinin sıxılmasından uğurla istifadə etdik ki, bu da onu 4 dəfə kiçilməsinə səbəb oldu. Lakin sadə sorğuların hansısa bir səbəbdən tam tarama icra etməli olduğu halda, 20-30 milyon e-poçtu yalnız tarixçəyə baxmaq üçün MySQL-də saxlamağın heç bir mənası yoxdur, çünki bu, swap-a və I/O-yə böyük yükə səbəb olur və bu barədə müntəzəm olaraq Zabbix xəbərdarlıqları alırdıq.
Clickhouse iki sıxılma alqoritmindən istifadə edir ki, bu da məlumatların həcmini təxminən , lakin bu konkret halda verilənlər xüsusilə "sıxılmağa meylli" idi.
ELK-nin əvəzlənməsi
Öz təcrübəmizdən, ELK (ElasticSearch, Logstash və Kibana, bu konkret halda ElasticSearch) dəsti loqların saxlanması üçün lazım olan resurslardan daha çoxunu tələb edir. ElasticSearch, loqlarda yaxşı tam mətni axtarmaq üçün əla bir mühərrikdir (amma məncə bu sizə realda lazım deyil), lakin niyə də-fakto jurnal aparmaq üçün standart mühərrik olduğunu maraq edirəm. Onun qəbul etmə performansı Logstash ilə birləşərək, bizə hətta nisbətən az yük altında belə problemlər yaradırdı və daha çox RAM və disk sahəsi tələb edirdi. DB olaraq, Clickhouse aşağıdakı səbəblərdən ElasticSearch-dən üstündür:
- SQL dialektinin dəstəyi;
- Saxlanılan məlumatların daha yaxşı sıxılması;
- Tam mətni axtarmaq əvəzinə Regex ilə müntəzəm ifadələr üzrə axtarışın dəstəyi;
- Sorğu planlamasının yaxşılaşdırılması və ümumi performansın artırılması.
Hazırda ClickHouse ilə ELK arasında müqayisə edərkən ən böyük problem logların transferi üçün həllərin olmaması və bu mövzuda sənədin və dərsliklərin çatışmazlığıdır. Bu baxımdan, hər bir istifadəçi ELK-ni Digital Ocean rəhbərliyi ilə quraşdıra bilər ki, bu da belə texnologiyaların sürətli tətbiqi üçün çox vacibdir. Burada bir verilənlər bazası mühərriki mövcuddur, lakin hələ ClickHouse üçün Filebeat yoxdur. Bəli, orada var və loglarla işləmə üçün sistem , bir alət mövcuddur log fayllarını ClickHouse-a daxil etmək üçün, lakin bunlar daha çox vaxt tələb edir. Lakin ClickHouse, sadəliyi sayəsində hələ də liderdir, buna görə də yeni başlayanlar belə onu asanlıqla quraşdırır və tam funksional istifadəyə cəmi 10 dəqiqə içində başlayır.
Minimalist həlləri üstün tutaraq, ClickHouse ilə birlikdə Kafka istifadə etmədən logların ötürülməsi üçün çox az yaddaş sərf edən FluentBit alətini istifadə etməyə çalışdım. Lakin, FluentBit-dan ClickHouse-a verilənlərin çevrilməsini təmin edən bir proxy qatını olmadan bunu etmək üçün kiçik uyğunsuzluqlar, məsələn , aradan qaldırılmalıdır.
Kibana alternativi olaraq ClickHouse-u backend kimi istifadə etmək mümkündür . Bildiyimə görə, burada çox sayda məlumat nöqtəsinin renderlənməsi ilə bağlı performans problemləri yarana bilər, xüsusilə köhnə versiyaları ilə Grafana. Qwintry-də biz bunu indiyə qədər sınamamışıq, lakin zaman-zaman ClickHouse dəstək kanalında bunu haqqında şikayətlər gəlir.
Google Big Query və Amazon RedShift-in (böyük şirkətlər üçün həll) əvəzlənməsi
BigQuery üçün ideal istifadə variantı 1 TB JSON məlumatını yükləmək və onun üzərində analitik sorğular yerinə yetirməkdir. Big Query - ölçməmi çətin qiymətləndirilən mükəmməl bir məhsuldur. Bu, ClickHouse-dan daha mürəkkəb bir proqramdır, daxili klasterdə işləyir, lakin müştəri baxımından ClickHouse ilə çox şeydə ortaqdır. BigQuery, hər bir SELECT üçün ödəməyə başladığınız zaman tez
ClickHouse, hesablama baxımından daha baha başa gələn sorğular yerinə yetirdiyiniz zaman ən yaxşı seçimdir. Hər gün yerinə yetirdiyiniz SELECT sorğularının sayı nə qədər çoxdursa, Big Query-ni ClickHouse-a dəyişməkdə mənası o qədər artır, çünki belə bir dəyişiklik sizə çoxsaylı terabaytların emalında minlərlə dollar qənaət etməyə kömək edə bilər. Bu, Big Query-də emalı nisbətən ucuz olan saxlanılan verilənlər üçün keçərli deyil.
Altinity şirkətinin təsisçilərindən Aleksandr Zaytsev-in məqaləsində bu tip bazaların migrasiyasının üstünlükləri haqqında danışılır.
TimescaleDB-nin əvəzlənməsi
TimescaleDB, PostgreSQL genişlənməsi, adətən verilənlər bazasında zaman seriyaları ilə işləməyi optimallaşdırır., ).
Hətta ClickHouse zaman seriyaları sahəsində ciddi rəqib olmasa da, onun sütun strukturuna və vektor icrasına görə analitik sorğuların bir çox hallarda emalını TimescaleDB-dən daha sürətli edir. Eyni zamanda, ClickHouse’un partiya məlumatlarının qəbulu performansı təxminən 3 dəfə üstündür və 20 dəfə daha az disk sahəsi istifadə edir, bu da böyük həcmli tarixi məlumatların emalı üçün olduqca əhəmiyyətlidir..
ClickHouse'dan fərqli olaraq, TimescaleDB-də bir az disk sahəsinin qənaət edilməsinin yeganə yolu ZFS və ya oxşar fayl sistemlərinin istifadəsidir.
Gələcək ClickHouse yeniləmələri ehtimal ki, delta sıxlaşdırma funksiyasını keçirəcək ki, bu da onu zaman seriyaları məlumatlarının emalı və saxlanması üçün daha əlverişli edəcək. TimescaleDB, «çıplaq» ClickHouse-dan daha yaxşı seçim ola bilər, aşağıdakı hallarda:
- çox az əməliyyat xərci (<3 GB);
- böyük fraksiyalara yığmaq istəmədiyiniz çoxlu kiçik INSERT;
- daha yaxşı uyum, vahidlik və ACID tələbləri;
- PostGIS dəstəyi;
- mövcud PostgreSQL cədvəlləri ilə inteqrasiya, çünki TimescaleDB, əslində, PostgreSQL-dir.
Hadoop və MapReduce sistemləri ilə rəqabət
Hadoop və digər MapReduce məhsulları çoxsaylı mürəkkəb hesablamalar edə bilər, lakin adətən böyük gecikmələrlə işləyirlər. ClickHouse bu problemi yarım-terabayt məlumatları emal etməklə və demək olar ki, ani nəticə verməklə düzəldir. Beləliklə, ClickHouse hızlı, interaktiv analitik tədqiqatlar üçün daha səmərəli bir seçimdir ki, bu da məlumat emalı mütəxəssislərinin marağını cəlb etməlidir.
Pinot və Druid ilə rəqabət
ClickHouse'un ən yaxın rəqibləri sütun strukturuna görə düz miqyaslanan açıq mənbəli məhsul olan Pinot və Druid-dir. Bu sistemlərin müqayisəsinə dair əla bir iş, məqalədə dərc edilmişdir. 2018-ci ilin 1 fevralında.
Bu məqalə yeniləməyə ehtiyac duyur – burada ClickHouse-un UPDATE və DELETE əməliyyatlarını dəstəkləmədiyi qeyd edilir ki, bu da son versiyalara tamamilə uyğun deyil.
Bu DB-lərlə işləyəcək qədər təcrübəmiz yoxdur, ancaq Druid və Pinot'un işə salınması üçün tələb olunan infrastrukturun mürəkkəbliyini bəyənmirəm – bu, hər tərəfdən Java ilə əhatə olunmuş çox sayda «hərəkətli hissə»dir.
Druid və Pinot, inkişafı Apache'nin GitHub layihələrinin səhifələrində ətraflı işıqlandırılan Apache'nin inkubator layihələridir. Pinot, 2018-ci ilin oktyabrında inkubatora daxil olmuş, Druid isə 8 ay əvvəldir - fevralda yaranmışdır.
AFS-in necə işlədiyinə dair məlumatın olmaması məndə müəyyən, bəlkə də, gülünc suallar yaradır. Maraqlıdır, Pinot-un müəllifləri Apache Fondunun Druid-ə daha meylli olduğunu görüb-görmədilər və bu rəqibə münasibət, qısqanclıq hissi doğurubmu? Əgər ilkini dəstəkləyən sponsorlar birdən-birə ikincini maraqlandırmağa başlasa, Druid-in inkişafı ləngiyəcəkmi və Pinot-un inkişafı sürətlənəcəkmi?
ClickHouse-un çatışmazlıqları
Könüllü olmayışı: görünür ki, bu hələ də maraqlı bir texnologiyadır, amma hər halda, digər sütunlu DB-lərdə belə bir şey yoxdur.
Kiçik daxil etmələr yüksək sürətlə pis işləyir: daxil etmələr böyük hissələrə bölünməlidir, çünki kiçik daxil etmələrin performansı hər sətirdəki sütunların sayına mütənasib olaraq azalır. ClickHouse-da verilənlər disklərdə belə saxlanılır - hər sütun 1 fayl və ya daha çoxunu göstərir, ona görə də 100 sütun olan 1 sətri daxil etmək üçün ən azı 100 faylı açıb yazmaq lazımdır. Daxil etmələri tamponlaşdırmaq üçün vasitəçi tələb olunur (əgər müştəri özü tamponlaşdırma təmin etmirsə) - bu adətən Kafka və ya hər hansı bir sıra idarəetmə sistemidir. Həmçinin, daha sonra böyük məlumat hissələrini MergeTree cədvəllərinə köçürmək üçün Buffer table mühərriki istifadə edilə bilər.
Cədvədlərin birləşmələri serverin əməliyyat yaddaşı ilə məhdudlaşır, amma ən azından onların var! Məsələn, Druid və Pinot-da ümumiyyətlə belə birləşmələr yoxdur, çünki bölüşdürülmüş sistemlərdə böyük məlumat hissələrinin düyünlər arasında hərəkətini həyata keçirmək çətindir.
Sonuçlar
Gələcək illərdə ClickHouse-u Qwintry-də geniş tətbiq etməyi planlaşdırırıq, çünki bu DB mükəmməl performans, aşağı xərc, miqyaslanma və sadəlik balansını təmin edir. Deyərdim ki, ClickHouse icması onu kiçik və orta sistemlərdə daha çox istifadə etmək üçün yollar tapdıqca tez yayımlanmağa başlayacaq.
Bir az reklam 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Bizim məqalələrimizi bəyənirsiniz? Daha maraqlı materiallar görmək istəyirsiniz? Bizi dəstəkləyin, sifariş verərək və ya tanışlarınıza tövsiyə edərək. , Sizin üçün icad etdiyimiz bənzərsiz entry-level serverlərin analoqu: (RAID1 və RAID10 ilə variantlar, 24 nüvəyə qədər və 40GB DDR4-a qədər mövcuddur).
Dell R730xd, Amsterdamdakı Equinix Tier IV data mərkəzində iki dəfə ucuz? Yalnız bizdə Niderlandda! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 $-dan! Bunun haqqında oxuyun
Mənbə: habr.com
