Son bir neçə il ərzində vaxt seriyası verilənlər bazaları qeyri-adi bir şeydən (açıq monitorinq sistemlərində (və xüsusi həllər ilə əlaqəli) və ya Big Data layihələrində istifadə olunan yüksək ixtisaslaşmış) "istehlakçı məhsuluna" çevrildi. Rusiya Federasiyasının ərazisində bunun üçün Yandex və ClickHouse-a xüsusi təşəkkür edilməlidir. Bu nöqtəyə qədər, böyük miqdarda zaman seriyası məlumatlarını saxlamaq lazım idisə, ya dəhşətli bir Hadoop yığını qurmaq və onu saxlamaq ehtiyacı ilə barışmalı, ya da hər bir sistem üçün fərdi protokollarla əlaqə saxlamalı idiniz.
Görünə bilər ki, 2019-cu ildə TSDB-nin istifadə etməyə dəyər olduğu məqalə yalnız bir cümlədən ibarət olacaq: "yalnız ClickHouse istifadə edin." Amma... nüanslar var.
Həqiqətən, ClickHouse fəal şəkildə inkişaf edir, istifadəçi bazası artır və dəstək çox aktivdir, lakin biz digər, bəlkə də daha effektiv/etibarlı həlləri kölgədə qoyan ClickHouse-un ictimai uğurunun girovuna çevrilmişikmi?
Keçən ilin əvvəlində biz öz monitorinq sistemimizi yenidən işləməyə başladıq, bu zaman məlumatların saxlanması üçün uyğun verilənlər bazasını seçmək sualı yarandı. Mən burada bu seçimin tarixindən danışmaq istəyirəm.
Problem problemi
Hər şeydən əvvəl lazımlı ön söz. Nə üçün bizim öz monitorinq sistemimizə ehtiyacımız var və o, necə qurulub?
Biz 2008-ci ildə dəstək xidmətləri göstərməyə başladıq və 2010-cu ilə qədər məlum oldu ki, müştəri infrastrukturunda baş verən proseslər haqqında məlumatları o dövrdə mövcud olan həllərlə birləşdirmək çətinləşdi (söhbət Allah məni bağışlasın, Cacti, Zabbix-dən gedir) və yaranan Qrafit).
Əsas tələblərimiz bunlar idi:
- bir sistem daxilində müştəriyə dəstək (o vaxt onlarla, gələcəkdə isə yüzlərlə) və eyni zamanda mərkəzləşdirilmiş xəbərdarlıq idarəetmə sisteminin olması;
- xəbərdarlıq sisteminin idarə edilməsində çeviklik (növbətçi zabitlər arasında xəbərdarlıqların artırılması, iş qrafiki, bilik bazası);
- qrafikləri dərindən təfərrüatlandırmaq bacarığı (o vaxt Zabbix qrafikləri şəkillər şəklində göstərirdi);
- böyük miqdarda məlumatın uzunmüddətli saxlanması (bir il və ya daha çox) və onu tez bir zamanda əldə etmək imkanı.
Bu yazıda son məqamla maraqlanırıq.
Saxlama haqqında danışarkən, tələblər belə idi:
- sistem tez işləməlidir;
- sistemin SQL interfeysinə malik olması arzuolunandır;
- sistem sabit olmalı və aktiv istifadəçi bazasına və dəstəyinə malik olmalıdır (bir dəfə artıq işlənməmiş MemcacheDB və ya səhv izləyicisi Çin dilində saxlanılan MooseFS paylanmış yaddaş kimi sistemləri dəstəkləmək ehtiyacı ilə üzləşdik: biz istəmədiyimiz layihə üçün bu hekayəni təkrar edirik);
- CAP teoreminə uyğunluq: Ardıcıllıq (tələb olunur) - məlumatlar aktual olmalıdır, biz xəbərdarlıq idarəetmə sisteminin yeni məlumatlar almamasını və bütün layihələr üçün məlumatların gəlməməsi ilə bağlı xəbərdarlıqları tüpürməsini istəmirik; Bölmə Dözümlülük (tələb olunur) - biz Split Brain sistemi əldə etmək istəmirik; Mövcudluq (kritik deyil, aktiv replika varsa) - koddan istifadə edərək qəza zamanı özümüz ehtiyat sisteminə keçə bilərik.
Qəribədir ki, o zaman MySQL bizim üçün ideal həll oldu. Bizim məlumat strukturumuz olduqca sadə idi: server id, sayğac id, vaxt damğası və dəyər; isti məlumatların sürətli seçilməsi böyük bufer hovuzu ilə, tarixi məlumatların seçilməsi isə SSD tərəfindən təmin edilmişdir.
Beləliklə, biz iki həftəlik təzə məlumat nümunəsinə nail olduq, təfərrüatları məlumat tamamilə göstərilməzdən əvvəl ikinci 200 ms-ə qədər azaldı və bu sistemdə kifayət qədər uzun müddət yaşadıq.
Bu vaxt vaxt keçdi və məlumatların miqdarı artdı. 2016-cı ilə qədər məlumatların həcmi onlarla terabata çatdı ki, bu da icarəyə götürülmüş SSD yaddaşı kontekstində əhəmiyyətli xərc idi.
Bu vaxta qədər sütunlu verilənlər bazaları fəal şəkildə geniş yayılmışdı, biz bu barədə fəal şəkildə düşünməyə başladıq: sütunlu verilənlər bazalarında məlumatlar, başa düşdüyünüz kimi, sütunlarda saxlanılır və məlumatlarımıza baxsanız, böyük bir məlumat bazası görmək asandır. Sütunlu verilənlər bazasından istifadə edirsinizsə, onu sıxışdırmaqla sıxışdıra bilən dublikatların sayı.
Bununla belə, şirkətin əsas sistemi stabil işləməyə davam etdi və mən başqa bir şeyə keçidlə təcrübə etmək istəmədim.
2017-ci ildə San Xosedə keçirilən Percona Live konfransında Clickhouse tərtibatçıları yəqin ki, ilk dəfə özlərini elan etdilər. İlk baxışdan sistem istehsala hazır idi (yaxşı, Yandex.Metrica sərt istehsal sistemidir), dəstək sürətli və sadə idi və ən əsası, əməliyyat sadə idi. 2018-ci ildən biz keçid prosesinə başlamışıq. Lakin o vaxta qədər çoxlu “böyüklər” və zamanla sınaqdan keçirilmiş TSDB sistemləri var idi və biz tələblərimizə uyğun olaraq Clickhouse-a alternativ həll yollarının olmadığından əmin olmaq üçün xeyli vaxt ayırmağa və alternativləri müqayisə etməyə qərar verdik.
Artıq müəyyən edilmiş saxlama tələblərinə əlavə olaraq, yeniləri ortaya çıxdı:
- yeni sistem eyni miqdarda aparatda MySQL ilə eyni performansı təmin etməlidir;
- yeni sistemin saxlanması əhəmiyyətli dərəcədə az yer tutmalıdır;
- DBMS hələ də idarə etmək asan olmalıdır;
- DBMS dəyişdirərkən tətbiqi minimal şəkildə dəyişmək istədim.
Hansı sistemləri nəzərdən keçirməyə başladıq?
Apache Hive/Apache Impala
Köhnə, döyüşdə sınaqdan keçirilmiş Hadoop yığını. Əslində, HDFS-də yerli formatlarda məlumatların saxlanması üzərində qurulmuş SQL interfeysidir.
Artıq.
- Stabil işləmə ilə məlumatları miqyaslaşdırmaq çox asandır.
- Məlumatların saxlanması üçün sütun həlləri var (daha az yer).
- Resurslar mövcud olduqda paralel tapşırıqların çox sürətli icrası.
Cons.
- Bu Hadoopdur və istifadəsi çətindir. Buludda hazır həlli qəbul etməyə hazır deyiliksə (və biz qiymət baxımından hazır deyilik), bütün yığın yığılmalı və adminlərin əlləri ilə dəstəklənməlidir və biz həqiqətən istəmirik. bu.
- Məlumatlar yığılmışdır .
Lakin:
Sürət hesablama serverlərinin sayını artırmaqla əldə edilir. Sadə dillə desək, əgər biz analitika ilə məşğul olan böyük bir şirkətiksə və biznes üçün məlumatı mümkün qədər tez toplamaq vacibdirsə (hətta böyük miqdarda hesablama resurslarından istifadə bahasına da olsa), bu bizim seçimimiz ola bilər. Amma biz tapşırıqları sürətləndirmək üçün aparat donanmasını çoxaltmağa hazır deyildik.
Druid/Pinot
Xüsusilə TSDB haqqında daha çox şey var, lakin yenə də Hadoop yığını.
Yoxdur .
Bir neçə sözlə: Druid/Pinot aşağıdakı hallarda Clickhouse-dan daha yaxşı görünür:
- Sizin məlumatların heterojen təbiəti var (bizim vəziyyətimizdə biz yalnız server ölçülərinin vaxt seriyasını qeyd edirik və əslində bu bir cədvəldir. Amma başqa hallar da ola bilər: avadanlıqların zaman seriyası, iqtisadi zaman seriyası və s. - hər biri birləşdirilməsi və emal edilməli olan öz strukturu).
- Üstəlik, bu məlumatların çoxu var.
- Zaman seriyası olan cədvəllər və məlumatlar görünür və yox olur (yəni bəzi məlumatlar toplusu gəlib, təhlil edilib və silinib).
- Verilənlərin bölünə biləcəyi aydın meyar yoxdur.
Əks hallarda, ClickHouse daha yaxşı işləyir və bu bizim vəziyyətimizdir.
Basın Evi
- SQL kimi
- İdarə etmək asandır.
- İnsanlar deyirlər ki, işləyir.
Test üçün qısa siyahıya düşür.
InfluxDB
ClickHouse-a xarici alternativ. Minuslardan: Yüksək Əlçatımlılıq yalnız kommersiya versiyasında mövcuddur, lakin onu müqayisə etmək lazımdır.
Test üçün qısa siyahıya düşür.
Cassandra
Bir tərəfdən, bilirik ki, o, məsələn, monitorinq sistemləri tərəfindən metrik vaxt seriyalarını saxlamaq üçün istifadə olunur. və ya OkMeter. Bununla belə, spesifik xüsusiyyətlər var.
Cassandra ənənəvi mənada sütunlu verilənlər bazası deyil. O, daha çox sıra görünüşünə bənzəyir, lakin hər bir sətirdə fərqli sayda sütun ola bilər ki, bu da sütunlu görünüşü təşkil etməyi asanlaşdırır. Bu mənada aydındır ki, 2 milyard sütun limiti ilə bəzi məlumatları sütunlarda (və eyni vaxt seriyasında) saxlamaq mümkündür. Məsələn, MySQL-də 4096 sütun limiti var və eyni şeyi etməyə cəhd etsəniz, 1117 kodu ilə səhvə rast gəlmək asandır.
Cassandra mühərriki master olmadan paylanmış sistemdə böyük həcmdə məlumatların saxlanmasına yönəlib və yuxarıda qeyd olunan Cassandra CAP teoremi daha çox AP-yə, yəni məlumatların mövcudluğu və bölmələrə qarşı müqavimətə aiddir. Beləliklə, yalnız bu verilənlər bazasına yazmaq və nadir hallarda ondan oxumaq lazımdırsa, bu alət əla ola bilər. Və burada Cassandra'yı "soyuq" anbar kimi istifadə etmək məntiqlidir. Yəni, nadir hallarda ehtiyac duyulan, lakin lazım olduqda geri götürülə bilən böyük miqdarda tarixi məlumatların saxlanması üçün uzunmüddətli, etibarlı yer kimi. Buna baxmayaraq, tamlıq naminə onu da sınaqdan keçirəcəyik. Ancaq əvvəllər dediyim kimi, seçilmiş verilənlər bazası həlli üçün kodu aktiv şəkildə yenidən yazmaq istəyi yoxdur, ona görə də biz onu bir qədər məhdud şəkildə - verilənlər bazası strukturunu Cassandra-nın xüsusiyyətlərinə uyğunlaşdırmadan sınaqdan keçirəcəyik.
Prometey
Maraq üçün biz Prometheus yaddaşının işini yoxlamaq qərarına gəldik - sadəcə olaraq cari həllərdən daha sürətli və ya yavaş olduğumuzu və nə qədər olduğunu anlamaq üçün.
Test metodologiyası və nəticələri
Beləliklə, biz 5 verilənlər bazasını aşağıdakı 6 konfiqurasiyada sınaqdan keçirdik: ClickHouse (1 qovşaq), ClickHouse (3 qovşaq üçün paylanmış cədvəl), InfluxDB, Mysql 8, Cassandra (3 qovşaq) və Prometheus. Test planı aşağıdakı kimidir:
- bir həftə ərzində tarixi məlumatları yükləyin (gündə 840 milyon dəyər; 208 min metrik);
- bir qeyd yükü yaradırıq (6 yükləmə rejimi nəzərə alındı, aşağıya baxın);
- Qeydə paralel olaraq, qrafiklərlə işləyən istifadəçinin istəklərini təqlid edərək vaxtaşırı seçimlər edirik. İşləri çox çətinləşdirməmək üçün bir həftə ərzində 10 metrik (CPU qrafikində tam olaraq nə qədər var) üçün məlumat seçdik.
Biz monitorinq agentimizin davranışını təqlid edərək yükləyirik, hansı ki, hər metrikaya hər 15 saniyədə bir dəfə dəyər göndərir. Eyni zamanda, biz müxtəlif maraqlıyıq:
- məlumatların yazıldığı metriklərin ümumi sayı;
- dəyərləri bir metrikaya göndərmək üçün interval;
- partiyanın ölçüsü.
Partiya ölçüsü haqqında. Demək olar ki, bütün eksperimental verilənlər bazalarımızı tək əlavələrlə yükləmək tövsiyə olunmadığı üçün bizə daxil olan ölçüləri toplayan və onları qruplara qruplaşdıran və toplu əlavə kimi verilənlər bazasına yazan rele lazımdır.
Həmçinin, alınan məlumatları daha sonra necə şərh edəcəyimizi daha yaxşı başa düşmək üçün təsəvvür edək ki, biz sadəcə bir dəstə metrik göndərmirik, lakin ölçülər serverlərdə təşkil olunur - hər serverə 125 metrik. Burada server sadəcə virtual varlıqdır - sadəcə başa düşmək üçün ki, məsələn, 10000 ölçü təxminən 80 serverə uyğun gəlir.
Və burada, bütün bunları nəzərə alaraq, 6 verilənlər bazası yazma yükləmə rejimimiz var:
Burada iki məqam var. Birincisi, Cassandra üçün bu partiya ölçüləri çox böyük oldu, orada biz 50 və ya 100 dəyərlərindən istifadə etdik. İkincisi, Prometey ciddi şəkildə çəkmə rejimində işlədiyi üçün, yəni. özü gedir və metrik mənbələrdən məlumat toplayır (və hətta pushgateway, adına baxmayaraq, vəziyyəti kökündən dəyişdirmir), müvafiq yüklər statik konfiqurasiyaların birləşməsindən istifadə edərək həyata keçirilirdi.
Test nəticələri aşağıdakı kimidir:
Nəyi qeyd etməyə dəyər: Prometheus-dan fantastik sürətli nümunələr, Cassandra-dan olduqca yavaş nümunələr, InfluxDB-dən qəbuledilməz dərəcədə yavaş nümunələr; Qeyd sürəti baxımından ClickHouse hamını qazandı və Prometheus müsabiqədə iştirak etmir, çünki o, əlavələri özü edir və biz heç nə ölçmürük.
Nəticədə,: ClickHouse və InfluxDB özlərini ən yaxşısı kimi göstərdilər, lakin Influx-dan klaster yalnız pula başa gələn Enterprise versiyası əsasında qurula bilər, ClickHouse isə heç bir xərc tələb etmir və Rusiyada istehsal olunur. Məntiqlidir ki, ABŞ-da seçim inInfluxDB-nin, bizdə isə ClickHouse-un xeyrinədir.
Mənbə: www.habr.com