🥇ClickHouse-a keçid: 3 il sonra

Üç il əvvəl Viktor Tarnavski və Yandex-dən Aleksey Milovidov səhnədə Yüksək Yük ++ deyə danışdı, hansı ClickHouse yaxşıdır və necə yavaşlamır. Və növbəti mərhələdə idi Alexander Zaitsev с hesabat köçmək haqqında Basın Evi başqa analitik DBMS-dən və nəticə ilə ki Basın Evi, əlbəttə, yaxşı, lakin çox rahat deyil. 2016-cı ildə şirkət Həyat Küçəsi, o zaman İskəndərin işlədiyi yerdə çoxbaytlıq analitik sistemi tərcümə etdi Basın Evi, bu, naməlum təhlükələrlə dolu füsunkar "sarı kərpic yol" idi - Basın Evi sonra minalanmış sahəyə bənzəyirdi.

Üç il sonra Basın Evi daha yaxşı oldu - bu müddət ərzində Alexander Altinity şirkətini qurdu, bu da yalnız köçməyə kömək etmir Basın Evi onlarla layihə, həm də Yandex-dən olan həmkarları ilə birlikdə məhsulun özünü təkmilləşdirir. İndi Basın Evi hələ də qayğısız bir gəzinti deyil, amma artıq mina sahəsi deyil.

Alexander 2003-cü ildən bəri paylanmış sistemlərdə iştirak edir, böyük layihələr hazırlayır MySQL, Oracle и Vertika. Sonda HighLoad++ 2019 İskəndər, istifadənin qabaqcıllarından biridir Basın Evi, bu DBMS-nin indi nə olduğunu söylədi. Əsas xüsusiyyətlərini öyrənəcəyik Basın Evi: digər sistemlərdən nə ilə fərqlənir və hansı hallarda ondan istifadə etmək daha effektivdir. Nümunələrdən istifadə edərək, əsaslanan sistemlərin qurulması üçün təzə və layihədə sübut edilmiş təcrübələri nəzərdən keçirək Basın Evi.

Retrospektiv: 3 il əvvəl baş verənlər

Üç il əvvəl biz şirkəti köçürdük Həyat Küçəsi haqqında Basın Evi fərqli analitik verilənlər bazasından və reklam şəbəkəsi analitik miqrasiyası belə görünürdü:

İyun 2016. In Açıq mənbə çıxdı Basın Evi və layihəmizə başladıq;
Avqust. Konsepsiya sübutu: böyük reklam şəbəkəsi, infrastruktur və 200-300 terabayt məlumat;
Oktyabr. İlk istehsal məlumatları;
dekabr. Tam məhsul yükü - gündə 10-50 milyard hadisə.
İyun 2017. İstifadəçilərin uğurlu miqrasiyası Basın Evi, 2,5 serverdən ibarət klasterdə 60 petabayt məlumat.

Miqrasiya irəlilədikcə, anlayış daha da böyüdü Basın Evi işləmək xoş olan yaxşı bir sistemdir, lakin bu Yandex-in daxili layihəsidir. Buna görə də, nüanslar var: Yandex əvvəlcə öz daxili müştəriləri ilə və yalnız bundan sonra icma və xarici istifadəçilərin ehtiyacları ilə məşğul olacaq, ClickHouse isə o zaman bir çox funksional sahələrdə müəssisə səviyyəsinə çata bilmədi. Beləliklə, 2017-ci ilin mart ayında biz etmək üçün Altinity-ni qurduq Basın Evi yalnız Yandex üçün deyil, həm də digər istifadəçilər üçün daha sürətli və daha rahatdır. İndi biz:

Biz məşq edirik və onlara əsaslanan həllərin yaradılmasına kömək edirik Basın Evi müştərilərin qabarları doldurmaması və həllin nəticədə işləməsi üçün;
24/7 dəstək veririk Basın Evi- qurğular;
Biz öz ekosistem layihələrimizi inkişaf etdiririk;
Özümü aktiv şəkildə öhdəsinə götür Basın Evi, müəyyən funksiyaları görmək istəyən istifadəçilərin sorğularına cavab verir.

Və əlbəttə ki, köçməkdə kömək edirik Basın Evi с MySQL, Vertika, Kahin, Yaşıl gavalı, Redshift və digər sistemlər. Biz müxtəlif köçürmələrdə iştirak etmişik və onların hamısı uğurlu olmuşdur.

Niyə hətta köçmək Basın Evi

Yavaşlamır! Əsas səbəb budur. Basın Evi - müxtəlif ssenarilər üçün çox sürətli verilənlər bazası:

Birlikdə işləyən insanlardan təsadüfi sitatlar Basın Evi.

Ölçeklenebilirlik. Bəzi digər verilənlər bazasında, bir cihazda yaxşı performans əldə edə bilərsiniz, lakin Basın Evi sadəcə serverlər əlavə etməklə yalnız şaquli deyil, həm də üfüqi olaraq miqyaslaya bilərsiniz. Hər şey istədiyimiz kimi rəvan işləmir, amma işləyir. Biznesiniz böyüdükcə sistemi inkişaf etdirə bilərsiniz. İndi qərarla məhdudlaşmamağımız vacibdir və inkişaf üçün hər zaman potensial var.

daşınma qabiliyyəti. Bir şeyə bağlılıq yoxdur. Məsələn, ilə Amazon RedShift harasa hərəkət etmək çətindir. A Basın Evi onu laptopunuza, serverinizə yerləşdirə, buludda yerləşdirə, gedə bilərsiniz Kubernetes - infrastrukturun fəaliyyətinə heç bir məhdudiyyət yoxdur. Bu, hər kəs üçün əlverişlidir və bu, bir çox digər oxşar verilənlər bazalarının öyünə bilməyəcəyi böyük bir üstünlükdür.

Esneklik. Basın Evi bir şeylə dayanmır, məsələn, Yandex.Metrica, lakin getdikcə daha çox müxtəlif layihələrdə və sənayelərdə hazırlanır və istifadə olunur. Yeni problemləri həll etmək üçün yeni funksiyalar əlavə etməklə genişləndirilə bilər. Məsələn, verilənlər bazasında qeydlərin saxlanmasının pis davranış olduğuna inanılır, buna görə də bunun üçün fikirləşdilər. Elasticsearch. Amma çeviklik sayəsində Basın Evi, siz həmçinin logları orada saxlaya bilərsiniz və çox vaxt bu, ondan daha yaxşıdır Elasticsearch - in Basın Evi 10 dəfə az dəmir tələb edir.

Pulsuz Open Source. Heç bir şey üçün pul ödəməli deyilsiniz. Sistemi laptopunuza və ya serverinizə yerləşdirmək üçün razılığa gəlməyə ehtiyac yoxdur. Gizli ödənişlər yoxdur. Eyni zamanda, heç bir başqa Open Source verilənlər bazası texnologiyası sürət baxımından rəqabət edə bilməz Basın Evi. MySQL, MariaDB, Greenplum - onların hamısı daha yavaşdır.

İcma, sürücü və əyləncə. Ilə Basın Evi böyük icma: görüşlər, söhbətlər və hamımızı enerjisi və nikbinliyi ilə dolduran Aleksey Milovidov.

ClickHouse-a keçin

Keçmək üçün Basın Evi bir şeylə yalnız üç şeyə ehtiyacınız var:

Məhdudiyyətləri anlayın Basın Evi və nə üçün uyğun deyil.
Faydalardan istifadə edin texnologiya və onun ən güclü tərəfləri.
Təcrübə. Hətta bunun necə işlədiyini bilmək Basın Evi, nə vaxt daha sürətli, nə vaxt daha yavaş, nə vaxt daha yaxşı və nə vaxt daha pis olacağını təxmin etmək həmişə mümkün deyil. Beləliklə, cəhd edin.

Hərəkət problemi

Yalnız bir "amma" var: köçsəniz Basın Evi başqa bir şeylə, adətən bir şey səhv gedir. Biz sevimli verilənlər bazamızda işləyən bəzi təcrübələrə və şeylərə öyrəşmişik. Məsələn, işləyən hər kəs SQL-verilənlər bazaları, aşağıdakı funksiyalar toplusunu məcburi hesab edir:

əməliyyatlar;
məhdudiyyətlər;
ardıcıllıq;
indekslər;
YENİLƏNİN/SİLİN;
NULL;
millisaniyələr;
avtomatik tip çevrilmələri;
çoxsaylı birləşmələr;
ixtiyari arakəsmələr;
klaster idarəetmə vasitələri.

İşə qəbul məcburidir, lakin üç il əvvəl Basın Evi bu xüsusiyyətlərin heç biri yox idi! İndi reallaşdırılmamışların yarısından azı qalır: əməliyyatlar, məhdudiyyətlər, Ardıcıllıq, millisaniyələr və tip tökmə.

Və əsas odur ki, içəridə Basın Evi bəzi standart təcrübələr və yanaşmalar işləmir və ya bizim öyrəşdiyimiz kimi işləmir. Görünən hər şey Basın Evi, uyğundur "ev yolunu basın”, yəni. funksiyaları digər verilənlər bazalarından fərqlidir. Misal üçün:

İndekslər seçilmir, lakin atlanır.
YENİLƏNİN/SİLİN sinxron deyil, asinxrondur.
Bir neçə qoşulma var, lakin sorğu planlayıcısı yoxdur. Onların daha sonra necə icra edildiyi verilənlər bazası dünyasından olan insanlar üçün ümumiyyətlə çox aydın deyil.

ClickHouse Ssenariləri

1960-cı ildə macar əsilli Amerika riyaziyyatçısı WignerEP məqalə yazdıTəbiət elmlərində riyaziyyatın əsassız effektivliyi”(“Təbiət elmlərində riyaziyyatın anlaşılmaz effektivliyi”) ətrafımızdakı dünya nədənsə riyazi qanunlarla yaxşı təsvir edilmişdir. Riyaziyyat mücərrəd bir elmdir və riyazi formada ifadə olunan fiziki qanunlar əhəmiyyətsiz deyil və WignerEP Bunun çox qəribə olduğunu vurğuladı.

Mənim baxışımdan, Basın Evi - eyni qəribəlik. Wigner-i yenidən formalaşdırmaq üçün bunu deyə bilərik: heyrətamiz effektivlik ağlasığmazdır Basın Evi geniş çeşiddə analitik tətbiqlərdə!

Məsələn, götürək Real-Time Məlumat Anbarı, məlumatların demək olar ki, davamlı olaraq yükləndiyi. Biz ondan ikinci gecikmə ilə müraciətlər almaq istəyirik. Zəhmət olmasa istifadə edin Basın Eviçünki bu ssenari üçün nəzərdə tutulmuşdur. Basın Evi yalnız internetdə deyil, marketinq və maliyyə analitikasında belə istifadə olunur, AdTech, eləcə də in Fırıldaqların aşkarlanmasın. IN Real vaxt məlumat anbarı "ulduz" və ya "qar dənəciyi" kimi mürəkkəb strukturlaşdırılmış sxemdən istifadə olunur, çoxlu cədvəllər OL (bəzən çoxlu) və məlumatlar adətən bəzi sistemlərdə saxlanılır və dəyişdirilir.

Başqa bir ssenari götürək - Zaman seriyası: monitorinq cihazları, şəbəkələr, istifadə statistikası, əşyaların interneti. Burada vaxtında sifariş edilmiş kifayət qədər sadə hadisələrlə qarşılaşırıq. Basın Evi əvvəlcə bunun üçün inkişaf etdirilməmişdi, lakin özünü yaxşı göstərmişdir, ona görə də böyük şirkətlər istifadə edirlər Basın Evi monitorinq məlumatlarının deposu kimi. Uyğun olub olmadığını görmək üçün Basın Evi zaman seriyası üçün biz yanaşma və nəticələrə əsaslanaraq etalon hazırladıq InfluxDB и Zaman Ölçümü DB - ixtisaslaşmış zaman seriyası verilənlər bazaları. Məlum olduO Basın Evi, hətta bu cür tapşırıqlar üçün optimallaşdırma olmadan, xarici sahədə də qalib gəlir:

В zaman seriyası adətən dar bir cədvəl istifadə olunur - bir neçə kiçik sütun. Monitorinqdən çoxlu məlumat əldə edilə bilər - saniyədə milyonlarla qeyd - və onlar adətən kiçik əlavələrlə gəlir (real-vaxt axın). Buna görə də, bizə fərqli bir daxiletmə skripti və sorğuların özləri lazımdır - bəzi xüsusiyyətləri ilə.

Log Management. Verilənlər bazasında qeydlərin toplanması adətən pisdir, lakin Basın Evi bu, yuxarıda göstərildiyi kimi bəzi şərhlərlə edilə bilər. Bir çox şirkət istifadə edir Basın Evi sırf bunun üçün. Bu vəziyyətdə, bütün logları saxladığımız düz geniş bir masa istifadə olunur (məsələn, formada JSON) və ya parçalara kəsin. Məlumatlar adətən böyük partiyalarda (fayllar) yüklənir və biz hansısa sahə axtarırıq.

Bu funksiyaların hər biri üçün adətən xüsusi verilənlər bazalarından istifadə olunur. Basın Evi hər şeyin öhdəsindən o qədər yaxşı gələ bilər ki, performans baxımından onları qabaqlayır. İndi daha yaxından nəzər salaq zaman seriyası skript və necə "bişirmək" Basın Evi bu ssenari üzrə.

Zaman seriyası

Bu, hazırda əsas ssenaridir Basın Evi standart həll yolu hesab olunur. Zaman seriyası zamanla hansısa prosesdə dəyişiklikləri əks etdirən zaman sıralı hadisələr toplusudur. Məsələn, bu, gündə ürək dərəcəsi və ya sistemdəki proseslərin sayı ola bilər. Zamanı müəyyən ölçülərlə işarələyən hər şeydir zaman seriyası:

Bu hadisələrin əksəriyyəti monitorinqdən qaynaqlanır. Bu, yalnız veb monitorinqi deyil, həm də real cihazlar ola bilər: avtomobillər, sənaye sistemləri, IOT, sənaye və ya pilotsuz taksilər, artıq Yandex-in baqajına yerləşdirir Basın Evi-server.

Məsələn, gəmilərdən məlumat toplayan şirkətlər var. Bir neçə saniyədən bir konteyner gəmisindən gələn sensorlar yüzlərlə müxtəlif ölçmələr göndərir. Mühəndislər onları öyrənir, modellər qurur və gəminin nə qədər səmərəli istifadə edildiyini anlamağa çalışırlar, çünki konteyner gəmisi bir saniyə belə boş dayanmamalıdır. İstənilən fasilə pul itkisidir, ona görə də parkın minimal olması üçün marşrutu proqnozlaşdırmaq vacibdir.

İndi ölçən ixtisaslaşmış verilənlər bazalarının böyüməsi var zaman seriyası. Onlayn DB-Mühərriklər bir şəkildə müxtəlif verilənlər bazaları sıralanır və onlara növə görə baxmaq olar:

Ən sürətli böyüyən növ zaman seriyasıs. Qrafik verilənlər bazaları da böyüyür, lakin zaman seriyasıs son bir neçə ildə daha sürətlə böyüyür. Bu verilənlər bazası ailəsinin tipik nümayəndələridir InfluxDB, Prometey, KDB, Zaman Ölçümü DB (inşa edilmişdir PostgreSQL), həlləri Amazon. Basın Evi burada da istifadə edilə bilər və istifadə olunur. Sizə bir neçə ictimai nümunə verim.

Pionerlərdən biri şirkətdir CloudFlare (CDNprovayder). Onlara nəzarət edirlər CDN vasitəsilə Basın Evi (DNS-istək, HTTP-istəklər) böyük yüklə - saniyədə 6 milyon hadisə. Hər şey keçir Kafka, gedir Basın Evi, sistemdə hadisələrin real vaxt rejimində idarə panellərini görmək imkanı verir.

Comcast - ABŞ-da telekommunikasiya sahəsində liderlərdən biri: İnternet, rəqəmsal televiziya, telefoniya. Bənzər bir nəzarət sistemi yaratdılar CDN daxilində Open Source Layihə Apache Traffic Control onların nəhəng məlumatları ilə işləmək. Basın Evi analitika üçün backend kimi istifadə olunur.

Perkona tikilmişdir Basın Evi sənin içində PMMmüxtəlif monitorinq davam etmək MySQL.

Xüsusi Tələblər

Zaman seriyası verilənlər bazalarının öz xüsusi tələbləri var.

Bir çox agentdən sürətli daxiletmə. Bir çox axınlardan məlumatları çox tez daxil etməliyik. Basın Evi bunu yaxşı edir, çünki bütün bloklanmayan əlavələrə malikdir. Hər hansı taxmaq diskdəki yeni fayldır və kiçik əlavələr bu və ya digər şəkildə bufer edilə bilər. IN Basın Evi verilənləri hər dəfə bir sətirdən çox, böyük partiyalarla daxil etmək daha yaxşıdır.
Çevik dövrə. Ilə zaman seriyası biz adətən verilənlərin strukturunu tam bilmirik. Müəyyən bir tətbiq üçün monitorinq sistemi qurmaq mümkündür, lakin sonra onu başqa bir tətbiq üçün istifadə etmək çətindir. Bu daha çevik sxem tələb edir. Basın Evi, güclü tipli baza olmasına baxmayaraq, bunu etməyə imkan verir.
Effektiv saxlama və məlumatların "unudulması". Adətən içində zaman seriyası böyük miqdarda məlumatdır, buna görə də onlar mümkün qədər səmərəli şəkildə saxlanılmalıdır. Məsələn, at InfluxDB yaxşı sıxılma onun əsas xüsusiyyətidir. Ancaq yaddaşdan əlavə, köhnə məlumatları "unutmaq" və bəzi işləri də bacarmalısınız aşağı seçmə — aqreqatların avtomatik hesablanması.
Birləşdirilmiş məlumatlar üzrə sürətli sorğular. Bəzən son 5 dəqiqəyə millisaniyəlik dəqiqliklə baxmaq maraqlıdır, lakin aylıq məlumatlarda dəqiqə və ya ikinci qranularlığa ehtiyac olmaya bilər - ümumi statistika kifayətdir. Bu cür dəstək lazımdır, əks halda 3 aylıq bir sorğu hətta çox uzun müddətə icra ediləcəkdir. Basın Evi.
kimi sorğularson nöqtə, etibarilə». Bunlar üçün xarakterikdir zaman seriyası sorğular: son ölçmə və ya bir anda sistemin vəziyyətinə baxın t. Verilənlər bazası üçün bunlar çox xoşagəlməz sorğular deyil, həm də icra etməyi bacarmalıdırlar.
"yapışdırmaq" zaman seriyası. Zaman seriyası zaman seriyasıdır. İki zaman seriyası varsa, onda onlar tez-tez bir-birinə bağlanmalı və əlaqələndirilməlidir. Bunu bütün verilənlər bazalarında, xüsusən də düzülməmiş zaman sıraları ilə etmək rahat deyil: burada bəzi vaxt işarələri var, başqaları da var. Orta hesab edə bilərsiniz, amma birdən hələ də bir çuxur olacaq, buna görə də aydın deyil.

Gəlin görək bu tələblər necə yerinə yetirilir Basın Evi.

Sxem

В Basın Evi üçün sxem zaman seriyası verilənlərin qanunauyğunluq dərəcəsindən asılı olaraq müxtəlif üsullarla həyata keçirilə bilər. Bütün ölçüləri əvvəlcədən bildiyimiz zaman müntəzəm verilənlər üzərində sistem qurmaq mümkündür. Məsələn, etdi CloudFlare monitorinqi ilə CDN yaxşı optimallaşdırılmış sistemdir. Bütün infrastrukturu, müxtəlif xidmətləri izləyən daha ümumi bir sistem qura bilərsiniz. Qeyri-müntəzəm məlumatlar vəziyyətində biz nəyi izlədiyimizi əvvəlcədən bilmirik - və bu, yəqin ki, ən çox yayılmış haldır.

müntəzəm məlumatlar. Sütunlar. Sxem sadədir - lazımi növlərə malik sütunlar:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Bu, bir növ sistemin açılış fəaliyyətinə nəzarət edən adi cədvəldir (istifadəçi, sistem, bikar, gözəl). Sadə və rahat, lakin çevik deyil. Daha çevik bir sxem istəyiriksə, o zaman massivlərdən istifadə edə bilərik.

Düzensiz məlumatlar. Massivlər:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Struktur İç içə iki massivdir: metrics.name и ölçülər.dəyər. Burada siz hər bir hadisə üçün bir sıra adlar və ölçmələr massivi kimi ixtiyari monitorinq məlumatlarını saxlaya bilərsiniz. Əlavə optimallaşdırma üçün birinin əvəzinə bir neçə belə struktur hazırlana bilər. Məsələn, biri üçün axıtma-dəyər, başqa - üçün int-məna, çünki int Mən daha səmərəli saxlamaq istəyirəm.

Ancaq belə bir quruluşa daxil olmaq daha çətindir. Əvvəlcə indeksin, sonra isə massivin dəyərlərini çıxarmaq üçün xüsusi funksiyalardan istifadə edərək xüsusi konstruksiyadan istifadə etməli olacaqsınız:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Ancaq yenə də kifayət qədər sürətli işləyir. Qeyri-müntəzəm məlumatları saxlamağın başqa bir yolu satırlardır.

Düzensiz məlumatlar. Simlər. Bu ənənəvi şəkildə, massivlər olmadan, adlar və dəyərlər bir anda saxlanılır. Bir cihazdan eyni anda 5 ölçmə alınırsa, verilənlər bazasında 000 sıra yaradılır:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

Basın Evi bunun öhdəsindən gəlir - onun xüsusi uzantıları var Basın Evi SQL. Məsələn, maxIf - bəzi şərt yerinə yetirildikdə metrik ilə maksimumu hesablayan xüsusi funksiya. Bir sorğuda bir neçə belə ifadə yaza və dərhal bir neçə ölçü üçün dəyəri hesablaya bilərsiniz.

Üç yanaşmanı müqayisə edək:

Детали

Burada bəzi test verilənlər bazası üçün "Diskdə məlumat ölçüsü" əlavə etdim. Sütunlar vəziyyətində, ən kiçik məlumat ölçüsünə sahibik: maksimum sıxılma, maksimum sorğu sürəti, lakin hər şeyi bir anda düzəltmək məcburiyyətindəyik.

Massivlərdə işlər bir az daha pisdir. Məlumat hələ də yaxşı sıxılır və qeyri-müntəzəm nümunəni saxlamaq mümkündür. Amma Basın Evi - sütun verilənlər bazası və biz hər şeyi massivdə saxlamağa başlayanda o, simli verilənlər bazasına çevrilir və biz çevikliyi səmərəliliklə ödəyirik. Hər hansı bir əməliyyat üçün bütün massivi yaddaşa oxumalı, sonra orada istədiyiniz elementi tapmalı olacaqsınız - və əgər massiv böyüyərsə, sürət azalır.

Bu yanaşmadan istifadə edən şirkətlərdən birində (məsələn, Über), massivlər 128 elementdən ibarət parçalara kəsilir. Gündə 200 TB məlumat həcmi olan bir neçə min metrikdən ibarət məlumatlar bir massivdə deyil, xüsusi saxlama məntiqi ilə 10 və ya 30 massivdə saxlanılır.

Ən sadə yanaşma stringsdir. Lakin məlumatlar zəif sıxılır, cədvəlin ölçüsü böyükdür və sorğular bir neçə ölçüyə əsaslandıqda belə, ClickHouse optimal şəkildə işləmir.

hibrid sxem

Tutaq ki, biz massiv sxemini seçmişik. Lakin biz bilsək ki, tablosumuzun əksəriyyəti yalnız istifadəçi və sistem göstəricilərini göstərir, biz əlavə olaraq bu ölçüləri cədvəl səviyyəsində bir massivdən sütunlara bu şəkildə maddiləşdirə bilərik:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Yapışdırıldıqda Basın Evi onları avtomatik hesablayacaq. Beləliklə, biznesi məmnuniyyətlə birləşdirə bilərsiniz: sxem çevik və ümumidir, lakin biz ən çox istifadə olunan sütunları çıxardıq. Qeyd edim ki, bu əlavənin dəyişdirilməsini tələb etmir və ETL, Massivləri cədvələ daxil etməyə davam edir. Sadəcə etdik ALTER TABLE, bir neçə dinamik əlavə etdi və dərhal istifadə etməyə başlaya biləcəyiniz hibrid və daha sürətli sxem əldə etdi.

Kodeklər və sıxılma

Uğrunda zaman seriyası məlumatı nə qədər yaxşı yığmağınız vacibdir, çünki məlumat massivi çox böyük ola bilər. IN Basın Evi sıxılma 1:10, 1:20 və bəzən daha çox təsirə nail olmaq üçün bir sıra alətlər var. Bu o deməkdir ki, diskdə sıxılmamış 1 TB məlumat 50-100 GB yer tutur. Daha kiçik ölçü yaxşıdır, məlumatlar daha sürətli oxuna və emal edilə bilər.

Yüksək sıxılma səviyyəsinə nail olmaq üçün, Basın Evi aşağıdakı kodekləri dəstəkləyir:

Cədvəl nümunəsi:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Burada kodek təyin edirik DoubleDelta bir halda, ikinci halda Qorilla, və daha çox əlavə etməyinizə əmin olun LZ4 sıxılma. Nəticədə, diskdəki məlumatların ölçüsü xeyli azalır:

Bu, eyni məlumatın nə qədər yer tutduğunu, lakin fərqli kodeklərdən və sıxılmalardan istifadə etdiyini göstərir:

diskdəki GZIP faylında;
ClickHouse-da kodeklər olmadan, lakin ZSTD sıxılma ilə;
LZ4 və ZSTD kodekləri və sıxılma ilə ClickHouse-da.

Kodekləri olan cədvəllərin daha az yer tutduğunu görmək olar.

Məsələlərin ölçüsü

Daha az vacib deyil выбрать düzgün məlumat növü:

Yuxarıdakı bütün nümunələrdə istifadə etdim 64. Amma seçsək 32onda bu daha yaxşı olardı. Bunu yuxarıdakı linkdəki məqalədə Perkonadan olan uşaqlar yaxşı nümayiş etdirdilər. Tapşırığa uyğun gələn ən yığcam tipdən istifadə etmək vacibdir: diskdəki ölçüyə görə sorğu sürətindən daha azdır. Basın Evi çox həssasdır.

İstifadə edə bilsəniz Int32 əvəzinə Int64, sonra performansın demək olar ki, iki qat artımını gözləyin. Məlumatlar daha az yaddaş tutur və bütün "arifmetika" çox daha sürətli işləyir. Basın Evi onun daxilində çox ciddi tipli sistemdir, müasir sistemlərin təmin etdiyi bütün imkanlardan maksimum istifadə edir.

Toplama və Maddi baxışlar

Toplama və maddiləşdirilmiş görünüşlər müxtəlif hallar üçün aqreqatlar yaratmağa imkan verir:

Məsələn, sizdə ümumiləşdirilməmiş mənbə məlumatınız ola bilər və xüsusi mühərrik vasitəsilə avtomatik toplama ilə müxtəlif maddiləşdirilmiş görünüşlər asa bilərsiniz. SummingMergeTree (SMT). SMT aqreqatları avtomatik olaraq sayan xüsusi ümumiləşdirici məlumat strukturudur. Xam məlumatlar verilənlər bazasına daxil edilir, avtomatik olaraq birləşdirilir və idarə panelləri dərhal istifadə edilə bilər.

TTL - köhnə məlumatları "unut"

Artıq lazım olmayan məlumatları necə "unutmaq" olar? Basın Evi necə edəcəyini bilir. Cədvəllər yaratarkən müəyyən edə bilərsiniz TTL ifadələr: məsələn, biz bir gün ərzində dəqiqə məlumatları, 30 gün ərzində gündəlik məlumatları saxlayırıq və heç vaxt həftəlik və ya aylıq məlumatlara toxunmuruq:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

çoxpilləli - verilənləri disklər arasında bölmək

Bu ideyanı inkişaf etdirərək, məlumatlar saxlanıla bilər Basın Evi müxtəlif yerlərdə. Tutaq ki, biz son həftə üçün çox sürətli yerli məlumatı saxlamaq istəyirik SSD, və biz başqa yerə daha çox tarixi məlumat əlavə edirik. IN Basın Evi indi mümkündür:

Siz saxlama siyasətini konfiqurasiya edə bilərsiniz (saxlama siyasəti) Belə ki Basın Evi müəyyən şərtlər yerinə yetirildikdə məlumatları avtomatik olaraq başqa yaddaşa köçürür.

Ancaq bu, hamısı deyil. Müəyyən bir cədvəl səviyyəsində məlumatların tam olaraq soyuq anbara köçürülməsi üçün qaydaları müəyyən edə bilərsiniz. Məsələn, 7 günlük məlumat çox sürətli bir diskdə yatır və köhnə olan hər şey yavaş bir diskə köçürülür. Bu yaxşıdır, çünki o, xərclərə nəzarət edərkən və soyuq məlumatlara pul xərcləməyərək sistemin maksimum performansını saxlamağa imkan verir:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Unikal Xüsusiyyətlər Basın Evi

Demək olar ki, hər şey Basın Evi belə "vurğulananlar" var, lakin onlar eksklüziv tərəfindən düzəldilir - digər verilənlər bazalarında olmayanlar. Məsələn, burada bəzi unikal xüsusiyyətlər var Basın Evi:

Diziler. Ilə Basın Evi massivlər üçün çox yaxşı dəstək, həmçinin onlar üzərində mürəkkəb hesablamalar aparmaq imkanı.
Məlumat Strukturlarının Birləşdirilməsi. Bu, "qatil xüsusiyyətlərindən" biridir. Basın Evi. Yandex-dən olan uşaqlar məlumat toplamaq istəmədiyimizi söyləmələrinə baxmayaraq, hər şey birləşdirilmişdir. Basın Eviçünki sürətli və rahatdır.
Materiallaşdırılmış Baxışlar. Məlumat strukturlarının toplanması ilə birlikdə maddiləşdirilmiş görünüşlər sizə rahatlıq yaratmağa imkan verir real-vaxt aqreqasiya.
ClickHouse SQL. Bu dil genişlənməsidir SQL yalnız mövcud olan bəzi əlavə və eksklüziv xüsusiyyətlərlə Basın Evi. Əvvəllər bu, sanki bir tərəfdən uzadılma, digər tərəfdən isə çatışmazlıq idi. İndi demək olar ki, bütün çatışmazlıqlar ilə müqayisədə SQL 92 biz onu çıxardıq, indi sadəcə bir uzantıdır.
Lambda-ifadələri. Onlar hələ də bəzi verilənlər bazasındadırlar?
ML-dəstək. Bu, müxtəlif verilənlər bazalarındadır, bəziləri daha yaxşıdır, bəziləri daha pisdir.
açıq mənbə. genişləndirə bilərik Basın Evi birlikdə. İndi daxil Basın Evi təxminən 500 ianəçi var və bu say daim artır.

Çətin Sorğular

В Basın Evi eyni şeyi etmək üçün bir çox müxtəlif yollar var. Məsələn, cədvəldən sonuncu dəyəri qaytarmağın üç müxtəlif yolu var CPU (dördüncü də var, amma daha ekzotikdir).

Birincisi bunun nə qədər rahat olduğunu göstərir Basın Evi Bunu yoxlamaq istədiyiniz zaman soruşun tüpürmək alt sorğuda yer alır. Bu, mənim şəxsən digər verilənlər bazalarında çatışmayan bir şeydir. Əgər mən bir şeyi alt sorğu ilə müqayisə etmək istəyirəmsə, onda digər verilənlər bazalarında onunla yalnız skaler müqayisə edilə bilər və bir neçə sütun üçün yazmalıyam. OL. Ilə Basın Evi tuple istifadə edə bilərsiniz:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

İkinci yol eyni şeyi edir, lakin ümumi funksiyadan istifadə edir argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu

В Basın Evi bir neçə onlarla məcmu funksiya var və kombinatorlardan istifadə etsəniz, kombinatorika qanunlarına görə, onlardan minə yaxınını alırsınız. ArgMax - maksimum dəyəri hesablayan funksiyalardan biri: sorğu dəyəri qaytarır istifadə_istifadəçisi, maksimum dəyərə çatdıqda yaradılmış_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF QOŞULUN - müxtəlif vaxtları olan sıraların "yapışdırılması". Bu verilənlər bazası üçün unikal xüsusiyyətdir və yalnız burada mövcuddur kdb+. Fərqli vaxtlara malik iki zaman seriyası varsa, ASOF QOŞULUN onları bir sorğuda dəyişdirməyə və yapışdırmağa imkan verir. Bir zaman seriyasındakı hər bir dəyər üçün digərində ən yaxın dəyər tapılır və onlar eyni sətirdə qaytarılır:

Analitik funksiyalar

Standartda SQL-2003 belə yaza bilərsiniz:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В Basın Evi bu mümkün deyil - standartı dəstəkləmir SQL-2003 və yəqin ki, heç vaxt olmayacaq. Bunun əvəzinə, in Basın Evi belə yazmaq adətdir:

Mən lambdalara söz verdim - buradadırlar!

Bu, standartda analitik sorğunun analoqudur SQL-2003: ikisi arasındakı fərqi hesablayır vaxt damğası, müddət, ordinal - adətən analitik funksiyalar hesab etdiyimiz hər şey. IN Basın Evi biz onları massivlər vasitəsilə hesablayırıq: əvvəlcə verilənləri massivə yığırıq, bundan sonra massivdə istədiyimizi edirik, sonra isə onu yenidən genişləndiririk. Bu, çox rahat deyil, ən azı funksional proqramlaşdırma sevgisi tələb edir, lakin çox çevikdir.

Xüsusi funksiyalar

Bundan başqa, in Basın Evi bir çox xüsusi xüsusiyyətlər. Məsələn, eyni anda neçə sessiyanın işlədiyini necə müəyyən etmək olar? Monitorinq üçün tipik vəzifə bir sorğuda maksimum yükü müəyyən etməkdir. IN Basın Evi Bunun üçün xüsusi bir funksiya var:

Ümumiyyətlə, ClickHouse bir çox məqsədlər üçün xüsusi funksiyalara malikdir:

çalışanFərq, qaçışAkkumulyasiya, qonşu;
sumMap(açar, dəyər);
timeSeriesGroupSum(uid, zaman damgası, dəyər);
timeSeriesGroupRateSum(uid, zaman damgası, dəyər);
skewPop, skewSamp, kurtPop, kurtSamp;
DOLDURMA İLƏ / BAĞLAMALARLA;
sadəLinearRegression, stoxastikLinearRegression.

Bu funksiyaların tam siyahısı deyil, onlardan cəmi 500-600-ü var. İpucu: bütün funksiyalar Basın Evi sistem cədvəlindədir (hamısı sənədləşdirilməyib, lakin hamısı maraqlıdır):

select * from system.functions order by name

Basın Evi daxil olmaqla, özü haqqında çoxlu məlumat saxlayır log masaları, query_log, izləmə jurnalı, məlumat blokları ilə əməliyyat jurnalı (part_log), ölçülər jurnalı və adətən diskə yazdığı sistem jurnalı. Metrik jurnalı belədir zaman seriyası в Basın Evi faktiki olaraq Basın Evi: verilənlər bazası özü rol oynaya bilər zaman seriyası verilənlər bazası, beləliklə, özünü "yeyir".

Bu da unikal bir şeydir - çünki biz yaxşı iş görürük zaman seriyasıniyə ehtiyacımız olan hər şeyi özümüzdə saxlaya bilmirik? Bizə lazım deyil Prometey, biz hər şeyi özümüzdə saxlayırıq. Əlaqədar Qrafana və özümüzə nəzarət edirik. Lakin, əgər Basın Evi düşür, biz görməyəcəyik - niyə - buna görə də adətən bunu etmirlər.

Böyük klaster və ya bir çox kiçik Basın Evi

Hansı daha yaxşıdır - bir böyük klaster və ya bir çox kiçik ClickHouse? Ənənəvi yanaşma DWH hər bir tətbiq üçün sxemlərin ayrıldığı böyük bir klasterdir. Verilənlər bazası administratoruna gəldik - bizə bir sxem verin və bizə verildi:

В Basın Evi fərqli şəkildə edə bilərsiniz. Hər bir proqram özünü yarada bilər Basın Evi:

Bizə artıq böyük bir canavar lazım deyil DWH və əməkdaşlıq etməyən adminlər. Hər bir tətbiqin özünəməxsusluğunu verə bilərik Basın Evi, və tərtibatçı özü bunu edə bilər, çünki Basın Evi quraşdırmaq çox asandır və mürəkkəb idarəetmə tələb etmir:

Amma bizdə çox olsa Basın Evi, və siz onu tez-tez təyin etməlisiniz, sonra bu prosesi avtomatlaşdırmaq istəyirsiniz. Bunun üçün, məsələn, istifadə edə bilərik Kubernetes и klik evi-operator. IN Kubernetes ClickHouse siz "on klik" qoya bilərsiniz: Mən düyməni basa bilərəm, manifesti işə sala bilərəm və verilənlər bazası hazırdır. Dərhal bir sxem yarada, metrikləri orada yükləməyə başlaya bilərsiniz və 5 dəqiqədən sonra hazır tablosuna sahibəm. Qrafana. Bu qədər sadədir!

Nəticədə?

Belə ki, Basın Evi - bu:

Быстро. Bunu hamı bilir.
Sadəcə. Bir az mübahisəlidir, amma məncə bunu öyrənmək çətindir, mübarizə aparmaq asandır. Necə başa düşsən Basın Evi işləyir, hər şey çox sadədir.
Ümumiyyətlə. Müxtəlif ssenarilər üçün uyğundur: DWH, Time Series, Log Storage. Amma elə deyil OLTP verilənlər bazası, buna görə də orada qısa əlavələr və oxumağa çalışmayın.
Maraqlı. Yəqin ki, onunla işləyən biri Basın Evi, yaxşı və pis mənada çox maraqlı dəqiqələr yaşadı. Məsələn, yeni bir buraxılış çıxdı, hər şey işləməyi dayandırdı. Və ya iki gün bir tapşırıqla mübarizə apardığınız zaman, ancaq Telegram çatında bir sualdan sonra tapşırıq iki dəqiqə ərzində həll edildi. Və ya Lesha Milovidovun məruzəsindəki konfransda olduğu kimi, ekran görüntüsü Basın Evi yayımı pozdu Yüksək Yük ++. Bu cür şeylər hər zaman baş verir və həyatımızı yaradır Basın Evi parlaq və maraqlı!

Təqdimata baxmaq olar burada.

Yüksək yüklü sistemlərin tərtibatçılarının çoxdan gözlənilən görüşü Yüksək Yük ++ 9 və 10 noyabrda Skolkovoda baş tutacaq. Nəhayət, bu, oflayn konfrans olacaq (bütün ehtiyat tədbirləri olsa da), çünki HighLoad++ enerjisini onlayn paketləmək mümkün deyil.

Konfrans üçün biz sizə texnologiyanın maksimum imkanları ilə bağlı keysləri tapıb göstəririk: HighLoad ++ Facebook, Yandex, VKontakte, Google və Amazon-un necə işlədiyini iki gün ərzində öyrənə biləcəyiniz yeganə yer idi, indi və olacaq.

2007-ci ildən iclaslarımızı fasiləsiz keçirmişik, bu il 14-cü dəfə görüşəcəyik. Bu müddət ərzində konfrans 10 dəfə artıb, keçən il sənayenin əsas hadisəsi 3339 iştirakçını, 165 məruzəçi və görüşlərin məruzəçisini toplayıb və 16 trek eyni vaxtda ifa olunub.
Ötən il sizin üçün 20 avtobus, 5280 litr çay və kofe, 1650 litr meyvə içkisi və 10200 butulka su olub. Və daha 2640 kiloqram yemək, 16 000 boşqab və 25 000 fincan. Yeri gəlmişkən, təkrar emal olunmuş kağızdan toplanan pulla 100 palıd tingi əkdik 🙂

Biletləri almaq olar burada, konfrans haqqında xəbərlər almaq — burada, və bütün sosial şəbəkələrdə danışın: Teleqram, Facebook, Vkontakte и Twitter.

Mənbə: www.habr.com

ClickHouse-a keçid: 3 il sonra