Yandex tərəfindən yaradılmış onlayn analitik sorğuların emalı (OLAP) üçün açıq mənbəli sütunlu verilənlər bazası idarəetmə sistemidir. O, Yandex, CloudFlare, VK.com, Badoo və dünya üzrə digər xidmətlər tərəfindən həqiqətən böyük həcmdə məlumatların (saniyədə minlərlə cərgənin və ya diskdə saxlanılan petabaytların daxil edilməsi) saxlanması üçün istifadə olunur.
Nümunələri MySQL, Postgres, MS SQL Server olan normal, "sətirli" DBMS-də məlumatlar bu ardıcıllıqla saxlanılır:
Bu halda, bir sıra ilə əlaqəli dəyərlər fiziki olaraq yan-yana saxlanılır. Sütunlu DBMS-də müxtəlif sütunlardan olan dəyərlər ayrıca saxlanılır və bir sütunun məlumatları birlikdə saxlanılır:
Sütunlu DBMS nümunələri Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Şirkət poçt ekspeditorudur Hesabat üçün 2018-ci ildə Clickhouse-dan istifadə etməyə başladım və onun sadəliyi, genişlənməsi, SQL dəstəyi və sürəti ilə çox heyran oldum. Bu DBMS-nin sürəti sehrlə həmsərhəddir.
Sadəlik
Clickhouse bir əmrlə Ubuntu-da quraşdırır. SQL-i bilirsinizsə, ehtiyaclarınız üçün dərhal Clickhouse istifadə etməyə başlaya bilərsiniz. Lakin bu o demək deyil ki, siz MySQL-də “cədvəl yaratmağı göstərə” və SQL-i Clickhouse-da kopyalayıb yapışdıra bilərsiniz.
MySQL ilə müqayisədə, bu DBMS-də cədvəl sxem təriflərində mühüm məlumat növü fərqləri var, ona görə də rahat olmaq üçün cədvəl sxeminin təriflərini dəyişdirmək və cədvəl mühərriklərini öyrənmək üçün hələ bir az vaxt lazımdır.
Clickhouse heç bir əlavə proqram olmadan əla işləyir, lakin replikasiyadan istifadə etmək istəyirsinizsə, ZooKeeper quraşdırmalı olacaqsınız. Sorğu performansının təhlili əla 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 istifadə edərək əldə etmək olar.
Məhsuldarlıq
- Konfiqurasiya serverində Clickhouse və Vertica və MySQL müqayisələri: iki yuva Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB RAM; md RAID-5 8 6TB SATA HDD, ext4.
- Clickhouse-un Amazon RedShift bulud yaddaşı ilə müqayisəsi.
- Bloqdan çıxarışlar :
ClickHouse verilənlər bazası çox sadə dizayna malikdir - klasterdəki bütün qovşaqlar eyni funksionallığa malikdir və koordinasiya üçün yalnız ZooKeeper-dən istifadə edir. Biz bir neçə qovşaqdan ibarət kiçik bir klaster qurduq və sınaq keçirdik, bu müddət ərzində sistemin kifayət qədər təsir edici performansa malik olduğunu gördük ki, bu da analitik DBMS benchmarklarında iddia edilən üstünlüklərə uyğundur. ClickHouse-un arxasında duran konsepsiyaya daha yaxından nəzər salmaq qərarına gəldik. Tədqiqat üçün ilk maneə alətlərin olmaması və ClickHouse-un kiçik icması idi, ona görə də biz onun necə işlədiyini başa düşmək üçün bu DBMS-nin dizaynını araşdırdıq.
ClickHouse birbaşa Kafkadan məlumat qəbul etməyi dəstəkləmir, çünki o, sadəcə verilənlər bazasıdır, ona görə də Go-da öz adapter xidmətimizi yazdıq. O, Cap'n Proto ilə Kafkadan gələn kodlanmış mesajları oxudu, onları TSV-yə çevirdi və HTTP interfeysi vasitəsilə toplu olaraq ClickHouse-a daxil etdi. Biz daha sonra performansı yaxşılaşdırmaq üçün öz ClickHouse interfeysimizlə birlikdə Go kitabxanasından istifadə etmək üçün bu xidməti yenidən yazdıq. Qəbul paketlərinin performansını qiymətləndirərkən biz vacib bir şeyi kəşf etdik - məlum oldu ki, ClickHouse üçün bu performans paketin ölçüsündən, yəni eyni vaxtda daxil edilən sıraların sayından çox asılıdır. Bunun niyə baş verdiyini anlamaq üçün biz ClickHouse-un məlumatları necə saxladığını öyrəndik.
Əsas mühərrik, daha doğrusu, məlumatların saxlanması üçün ClickHouse tərəfindən istifadə edilən cədvəl mühərrikləri ailəsi MergeTree-dir. Bu mühərrik konseptual olaraq Google BigTable və ya Apache Cassandra-da istifadə olunan LSM alqoritminə bənzəyir, lakin aralıq yaddaş cədvəli qurmaqdan yayınır və məlumatları birbaşa diskə yazır. Bu, ona əla yazma qabiliyyəti verir, çünki hər bir daxil edilmiş paket yalnız "əsas açar" əsas açarı ilə çeşidlənir, sıxılır və seqment yaratmaq üçün diskə yazılır.
Yaddaş cədvəlinin və ya məlumatların hər hansı "təzəliyi" anlayışının olmaması da onların yalnız əlavə edilə biləcəyini, sistemin dəyişdirilməsini və ya silinməsini dəstəkləmədiyini bildirir. Bu gündən etibarən məlumatları silməyin yeganə yolu onu təqvim ayı ilə silməkdir, çünki seqmentlər heç vaxt ay sərhədini keçmir. ClickHouse komandası bu funksiyanı fərdiləşdirilə bilən etmək üzərində fəal işləyir. Digər tərəfdən, bu, seqmentlərin yazılmasını və birləşdirilməsini mübahisəsiz edir, beləliklə, I/O və ya nüvələr doyana qədər paralel daxiletmələrin sayı ilə xətti olaraq ötürücülük şkalalarını qəbul edin.
Bununla belə, bu vəziyyət həm də sistemin kiçik paketlər üçün uyğun olmadığını bildirir, ona görə də buferləşdirmə üçün Kafka xidmətləri və yerləşdiricilərdən istifadə olunur. Bundan əlavə, arxa planda olan ClickHouse davamlı olaraq seqmentləri birləşdirməyə davam edir, beləliklə, bir çox kiçik məlumat parçaları birləşdiriləcək və daha çox dəfə qeydə alınacaq, beləliklə qeyd intensivliyi artır. Bununla belə, bir-biri ilə əlaqəsi olmayan hissələrin çoxu birləşmənin davam etdiyi müddətdə əlavələrin aqressiv tıxanmasına səbəb olacaq. Biz aşkar etdik ki, real vaxt rejimində məlumat qəbulu və qəbul performansı arasında ən yaxşı kompromis cədvələ saniyədə məhdud sayda əlavələri qəbul etməkdir.
Cədvəl oxuma performansının açarı diskdəki məlumatların indeksləşdirilməsi və yeridir. Emal nə qədər sürətli olsa da, mühərrik diskdən terabaytlarla məlumatı skan etməli və onun yalnız bir hissəsini istifadə etməli olduqda, bu, vaxt aparacaq. ClickHouse bir sütun anbarıdır, buna görə də hər seqmentdə hər bir sütun (sütun) üçün hər bir sıra üçün çeşidlənmiş dəyərləri olan bir fayl var. Beləliklə, sorğuda olmayan bütün sütunlar əvvəlcə atlana bilər, sonra isə vektorlaşdırılmış icra ilə paralel olaraq çoxlu xanalar işlənə bilər. Tam skan etməmək üçün hər bir seqmentdə kiçik bir indeks faylı var.
Bütün sütunların "əsas açar" əsasında çeşidləndiyini nəzərə alsaq, indeks faylı hətta çox böyük cədvəllər üçün belə yaddaşda saxlamaq üçün hər N-ci sıranın etiketlərini (tutulmuş sətirləri) ehtiva edir. Məsələn, standart parametrləri "hər 8192-ci cərgəni qeyd etmək", sonra 1 trilyonla cədvəlin "cüzi" indeksləşdirməsini təyin edə bilərsiniz. yaddaşa asanlıqla uyğun gələn sətirlər yalnız 122 simvol tutacaq.
Sistem inkişafı
Clickhouse-un inkişafı və təkmilləşdirilməsi izlənilə bilər və "böyümə" prosesinin təsirli bir sürətlə baş verdiyinə əmin olun.
Şöhrət
Görünür, Clickhouse-un populyarlığı, xüsusən də rusdilli cəmiyyətdə eksponent olaraq artır. Keçən ilki High load 2018 konfransı (Moskva, 8-9 noyabr 2018-ci il) göstərdi ki, vk.com və Badoo kimi canavarlar eyni vaxtda on minlərlə serverdən məlumatları (məsələn, qeydlər) daxil edən Clickhouse-dan istifadə edir. 40 dəqiqəlik videoda . Tezliklə materialla işləmək rahatlığı üçün stenoqramı Habr-da yerləşdirəcəyik.
Proqramlar
Tədqiqata bir qədər vaxt sərf etdikdən sonra düşünürəm ki, ClickHouse faydalı ola bilər və ya MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot və digər ənənəvi və populyar həlləri tamamilə əvəz edə bilər. Druid. Yuxarıdakı DBMS-ni təkmilləşdirmək və ya tamamilə əvəz etmək üçün ClickHouse-dan istifadənin təfərrüatları aşağıda verilmişdir.
MySQL və PostgreSQL-in genişləndirilməsi
Bu yaxınlarda biz bülleten platforması üçün MySQL-i ClickHouse ilə qismən əvəz etdik . Problem onda idi ki, səhv düşünülmüş dizayn sayəsində MySQL göndərilən hər bir e-poçtu və bu e-poçtdakı hər bir linki base64 hash ilə daxil edərək böyük MySQL cədvəli (email_stats) yaratdı. Xidmətin abunəçilərinə cəmi 10 milyon e-poçt göndərdikdən sonra bu cədvəl 150 GB fayl sahəsi tutdu və MySQL sadə sorğularda “axmaq” olmağa başladı. Fayl sahəsi problemini həll etmək üçün biz InnoDB cədvəlinin sıxılmasından uğurla istifadə etdik, bu da onu 4 dəfə azaldıb. Bununla belə, sırf tarixi oxumaq üçün MySQL-də 20-30 milyondan çox e-poçt saxlamaq hələ də mənasızdır, çünki nədənsə tam skan etməli olan hər hansı sadə sorğu dəyişdirmə və ağır I/O ilə nəticələnir. mütəmadi olaraq Zabbix xəbərdarlıqlarını aldığımız yerüstü yük.
Clickhouse məlumatların miqdarını təxminən azaldan iki sıxılma alqoritmindən istifadə edir , lakin bu xüsusi halda, məlumatlar xüsusilə "sıxılmış" idi.
ELK dəyişdirilməsi
Öz təcrübəmə əsaslanaraq, ELK yığını (ElasticSearch, Logstash və Kibana, bu xüsusi halda ElasticSearch) jurnalların saxlanması üçün lazım olduğundan daha çox resurs tələb edir. ElasticSearch yaxşı tam mətn jurnal axtarışı istəyirsinizsə (və məncə, buna həqiqətən ehtiyacınız olmadığını düşünürəm) əla mühərrikdir, lakin onun niyə faktiki standart giriş mühərrikinə çevrildiyini düşünürəm. Logstash ilə birlikdə onun qəbulu performansı bizə kifayət qədər yüngül iş yüklərində belə problemlər yaratdı və getdikcə daha çox RAM və disk sahəsinin əlavə edilməsini tələb etdi. Verilənlər bazası olaraq, Clickhouse aşağıdakı səbəblərə görə ElasticSearch-dən daha yaxşıdır:
- SQL dialekt dəstəyi;
- Saxlanılan məlumatların ən yaxşı sıxılma dərəcəsi;
- Tam mətn axtarışı əvəzinə Regex axtarışına dəstək;
- Təkmilləşdirilmiş sorğu planlaması və daha yaxşı ümumi performans.
Hal-hazırda, ClickHouse-u ELK ilə müqayisə edərkən ortaya çıxan ən böyük problem, qeydlərin yüklənməsi üçün həllərin olmaması, həmçinin bu mövzuda sənədlərin və dərsliklərin olmamasıdır. Eyni zamanda, hər bir istifadəçi bu cür texnologiyaların sürətli tətbiqi üçün çox vacib olan Digital Ocean təlimatından istifadə edərək ELK-nı qura bilər. Burada verilənlər bazası mühərriki var, lakin hələ ClickHouse üçün Filebeat yoxdur. Bəli var və loglarla işləmək üçün sistem , aləti var log faylı məlumatlarını ClickHouse-a daxil etmək, lakin bütün bunlar daha çox vaxt tələb edir. Bununla belə, ClickHouse hələ də sadəliyinə görə öndədir, belə ki, hətta yeni başlayanlar onu asanlıqla quraşdıra və cəmi 10 dəqiqə ərzində tam funksional istifadəyə başlaya bilərlər.
Minimalist həllərə üstünlük verərək, Kafkadan istifadə etməməyə çalışarkən ClickHouse ilə çox az yaddaş jurnalı yükləmə aləti olan FluentBit-dən istifadə etməyə çalışdım. Bununla belə, kiçik uyğunsuzluqları aradan qaldırmaq lazımdır, məsələn məlumatları FluentBit-dən ClickHouse-a çevirən proksi qatı olmadan həyata keçirilməzdən əvvəl.
Kibana alternativ olaraq, Backend kimi ClickHouse-dan istifadə edə bilərsiniz . Başa düşdüyüm qədər, bu, çoxlu sayda məlumat nöqtələrini göstərərkən, xüsusən Grafana'nın köhnə versiyalarında performans problemlərinə səbəb ola bilər. Qwintry-də biz bunu hələ sınamamışıq, lakin bununla bağlı şikayətlər vaxtaşırı Telegram-dakı ClickHouse dəstək kanalında görünür.
Google Big Query və Amazon RedShift-in dəyişdirilməsi (böyük şirkətlər üçün həll)
BigQuery üçün ideal istifadə halı 1TB JSON məlumatını yükləmək və ona analitik sorğular aparmaqdır. Big Query, genişlənmə qabiliyyətini qiymətləndirmək çətin olan əla məhsuldur. Bu, daxili klasterdə işləyən ClickHouse-dan daha mürəkkəb proqramdır, lakin müştərinin nöqteyi-nəzərindən onun ClickHouse ilə ümumi cəhətləri çoxdur. Hər SEÇİM üçün ödəniş etməyə başladıqdan sonra BigQuery sürətlə "qiyməti artıra" bilər, ona görə də bütün müsbət və mənfi cəhətləri ilə real SaaS həllidir.
Bir çox hesablama baxımından bahalı sorğular işlətdiyiniz zaman ClickHouse ən yaxşı seçimdir. Hər gün nə qədər çox SEÇİM sorğusu işlədirsinizsə, Big Query-ni ClickHouse ilə əvəz etmək bir o qədər çox əhəmiyyət kəsb edir, çünki belə bir dəyişdirmə işlənən çoxlu terabayt məlumatlara gəldikdə minlərlə dollara qənaət edəcək. Bu, Big Query-də emal etmək olduqca ucuz olan saxlanılan məlumatlara aid edilmir.
Altinity-nin həmtəsisçisi Aleksandr Zaitsevin məqaləsində belə bir DBMS miqrasiyasının faydalarını təsvir edir.
TimescaleDB dəyişdirilməsi
TimescaleDB adi verilənlər bazasında vaxt seriyaları ilə işləməyi optimallaşdıran PostgreSQL uzantısıdır (, ).
Baxmayaraq ki, ClickHouse zaman seriyası nişində ciddi rəqib olmasa da, sütunlu struktur və vektor sorğularının icrası baxımından analitik sorğuların işlənməsinin əksər hallarda TimescaleDB-dən xeyli sürətlidir. Eyni zamanda, ClickHouse paket məlumatlarının qəbulu performansı təxminən 3 dəfə yüksəkdir, əlavə olaraq, böyük həcmdə tarixi məlumatların işlənməsi üçün həqiqətən vacib olan 20 dəfə az disk sahəsi istifadə edir: .
ClickHouse-dan fərqli olaraq, TimescaleDB-də disk sahəsinə qənaət etməyin yeganə yolu ZFS və ya oxşar fayl sistemlərindən istifadə etməkdir.
ClickHouse-a gələcək yeniləmələr, ehtimal ki, delta sıxılma tətbiq edəcək, bu da onu vaxt seriyası məlumatlarının işlənməsi və saxlanması üçün daha da uyğunlaşdıracaq. TimescaleDB aşağıdakı hallarda çılpaq ClickHouse-dan daha yaxşı seçim ola bilər:
- çox az RAM (<3 GB) olan kiçik qurğular;
- böyük fraqmentlərə bufer etmək istəmədiyiniz çoxlu sayda kiçik INSERT-lər;
- daha yaxşı ardıcıllıq, vahidlik və ACID tələbləri;
- PostGIS dəstəyi;
- mövcud PostgreSQL cədvəlləri ilə birləşdirin, çünki Timescale DB əsasən PostgreSQL-dir.
Hadoop və MapReduce sistemləri ilə rəqabət
Hadoop və digər MapReduce məhsulları bir çox mürəkkəb hesablamalar apara bilər, lakin onlar böyük gecikmə ilə işləyirlər.ClickHouse terabaytlarla məlumatı emal etməklə və demək olar ki, dərhal nəticə çıxarmaqla bu problemi həll edir. Beləliklə, ClickHouse məlumat alimlərinin marağına səbəb olan sürətli, interaktiv analitik tədqiqatların aparılması üçün daha səmərəlidir.
Pinot və Druid ilə rəqabət
ClickHouse-un ən yaxın rəqibləri sütunlu, xətti miqyaslı açıq mənbə məhsulları Pinot və Druiddir. Bu sistemləri müqayisə edən əla iş məqalədə dərc olunur 1 fevral 2018-ci il
Bu məqaləni yeniləmək lazımdır - burada deyilir ki, ClickHouse YENİLƏNMƏ və SİL əməliyyatlarını dəstəkləmir, bu son versiyalara münasibətdə tamamilə doğru deyil.
Bu DBMS-lərlə çox təcrübəmiz yoxdur, lakin Druid və Pinot-u idarə etmək üçün tələb olunan əsas infrastrukturun mürəkkəbliyini bəyənmirəm - bu, hər tərəfdən Java ilə əhatə olunmuş "hərəkət edən hissələr" bütöv bir dəstəsidir.
Druid və Pinot, GitHub layihə səhifələrində Apache tərəfindən ətraflı şəkildə əhatə olunan Apache inkubator layihələridir. Pinot 2018-ci ilin oktyabrında inkubatorda göründü və Druid 8 ay əvvəl - fevralda anadan olub.
AFS-nin necə işlədiyi barədə məlumatın olmaması mənim üçün bəzi və bəlkə də axmaq suallar doğurur. Maraqlıdır, Pinot müəllifləri Apaçi Fondunun Druidlərə daha çox meylli olduğunu görüblərmi və rəqibə qarşı belə münasibət paxıllıq hissi doğurubmu? Birincini dəstəkləyən sponsorlar birdən-birə ikinci ilə maraqlansa, Druidin inkişafı ləngiyəcək və Pinotun inkişafı sürətlənəcəkmi?
ClickHouse-un çatışmazlıqları
Yetişməmişlik: Aydındır ki, bu, hələ də darıxdırıcı bir texnologiyadır, lakin hər halda, digər sütunlu DBMS-də belə bir şey görünmür.
Kiçik əlavələr yüksək sürətlə yaxşı işləmir: əlavələr böyük parçalara bölünməlidir, çünki kiçik əlavələrin performansı hər cərgədəki sütunların sayına mütənasib olaraq pisləşir. ClickHouse məlumatları diskdə belə saxlayır - hər sütun 1 və ya daha çox fayl deməkdir, ona görə də 1 sütundan ibarət 100 sıra daxil etmək üçün ən azı 100 faylı açıb yazmalısınız. Buna görə də daxiletmə buferləməsi vasitəçi tələb edir (müştəri özü buferləşdirməni təmin etmirsə) - adətən Kafka və ya bir növ növbə sistemi. Daha sonra MergeTree cədvəllərinə böyük məlumat hissələrini köçürmək üçün Bufer cədvəli mühərrikindən də istifadə edə bilərsiniz.
Cədvəl birləşmələri server RAM ilə məhdudlaşır, lakin heç olmasa oradadırlar! Məsələn, Druid və Pinotun belə əlaqələri ümumiyyətlə yoxdur, çünki onları qovşaqlar arasında böyük məlumat hissələrinin hərəkətini dəstəkləməyən paylanmış sistemlərdə birbaşa həyata keçirmək çətindir.
Tapıntılar
Növbəti illərdə biz Qwintry-də ClickHouse-dan geniş istifadə etməyi planlaşdırırıq, çünki bu DBMS əla performans balansını, aşağı yükü, miqyaslılığı və sadəliyi təmin edir. Əminəm ki, ClickHouse icması onu kiçik və orta qurğularda istifadə etmək üçün daha çox yol tapdıqdan sonra onun sürətlə yayılacağına əminəm.
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com