Zabbix-in TimescaleDB verilənlər bazası ilə backend kimi necə işlədiyinə baxacağıq. Biz sizə sıfırdan necə başlayacağınızı və PostgreSQL-dən necə köçəcəyinizi göstərəcəyik. Biz həmçinin iki konfiqurasiyanın müqayisəli performans testlərini təqdim edirik.
HighLoad++ Sibir 2019. Tomsk Zalı. 24 iyun, saat 16:00. Abstraktlar və . Növbəti HighLoad++ konfransı 6 və 7 aprel 2020-ci il tarixlərində Sankt-Peterburqda baş tutacaq. Təfərrüatlar və biletlər .
Andrey Quşçin (bundan sonra - AG): – Mən ZABBIX texniki dəstək mühəndisiyəm (bundan sonra “Zabbix” adlandırılacaq), təlimçiyəm. Mən 6 ildən artıqdır ki, texniki dəstək sahəsində işləyirəm və performansla birbaşa təcrübəm var. Bu gün mən TimescaleDB-nin adi PostgreSQL 10 ilə müqayisədə verə biləcəyi performansdan danışacağam. Həmçinin onun ümumi necə işlədiyinə dair bir neçə giriş hissəsi.
Ən yüksək performans problemləri: məlumatların toplanmasından məlumatların təmizlənməsinə qədər
Başlamaq üçün, hər bir monitorinq sisteminin qarşılaşdığı müəyyən performans problemləri var. İlk performans problemi məlumatların sürətli toplanması və işlənməsidir.
Yaxşı bir monitorinq sistemi bütün məlumatları operativ və vaxtında qəbul etməli, onları tetikleyici ifadələrə əsasən emal etməli, yəni bəzi meyarlara uyğun olaraq emal etməlidir (müxtəlif sistemlərdə bu fərqlidir) və bu məlumatlardan istifadə etmək üçün verilənlər bazasında saxlamalıdır. gələcək.
İkinci performans problemi tarix yaddaşıdır. Tez-tez verilənlər bazasında saxlayın və müəyyən müddət ərzində toplanmış bu göstəricilərə tez və asan giriş əldə edin. Ən əsası odur ki, bu məlumatların qəbulu, hesabatlarda, qrafiklərdə, tetikleyicilərdə, bir növ hədd dəyərlərində, xəbərdarlıqlarda və s. istifadə etmək üçün əlverişli olmalıdır.
Üçüncü performans problemi tarixin təmizlənməsidir, yəni 5 il ərzində (hətta aylar və ya iki ay) toplanmış bəzi təfərrüatlı ölçüləri saxlamağa ehtiyac olmayan bir gününüz olduqda. Bəzi şəbəkə qovşaqları silinib və ya bəzi hostlar, ölçülərə ehtiyac yoxdur, çünki onlar artıq köhnəlib və artıq yığılmır. Bütün bunları təmizləmək lazımdır ki, verilənlər bazanız böyük ölçülərə çatmasın. Və ümumiyyətlə, tarixi təmizləmək çox vaxt saxlama üçün ciddi bir sınaqdır - bu, çox vaxt performansa çox təsir edir.
Keşləmə problemlərini necə həll etmək olar?
İndi xüsusi olaraq Zabbix haqqında danışacağam. Zabbix-də birinci və ikinci zənglər caching istifadə edərək həll edilir.
Məlumatların toplanması və emalı - bütün bu məlumatları saxlamaq üçün RAM-dan istifadə edirik. İndi bu məlumatlar daha ətraflı müzakirə olunacaq.
Həmçinin verilənlər bazası tərəfində əsas seçimlər üçün - qrafiklər və digər şeylər üçün müəyyən bir keşləmə var.
Zabbix serverinin yan tərəfində keşləmə: bizdə ConfigurationCache, ValueCache, HistoryCache, TrendsCache var. Bu nədir?
ConfigurationCache ölçüləri, hostları, elementləri, triggerləri saxladığımız əsas keşdir; əvvəlcədən emal etmək, məlumat toplamaq, hansı hostlardan, hansı tezlikdə toplamaq üçün lazım olan hər şey. Bütün bunlar verilənlər bazasına getməmək, lazımsız sorğular yaratmamaq üçün ConfigurationCache-də saxlanılır. Server işə salındıqdan sonra biz bu keşi yeniləyirik (yaratırıq) və vaxtaşırı yeniləyirik (konfiqurasiya parametrlərindən asılı olaraq).
Zabbix-də keşləmə. Məlumatların toplanması
Burada diaqram olduqca böyükdür:
Sxemdə əsas olanlar bu montajçılardır:
Bunlar tikinti proseslərinin özləri, müxtəlif tipli tikintilərə cavabdeh olan müxtəlif “pollerlər”dir. Onlar müxtəlif protokollardan istifadə edərək icmp, ipmi vasitəsilə məlumatları toplayır və hamısını əvvəlcədən emala ötürürlər.
Öncədən işlənmə tarixçəsi
Həmçinin, hesablanmış məlumat elementlərimiz varsa (Zabbix ilə tanış olanlar bilir), yəni hesablanmış, aqreqasiya məlumat elementləri, biz onları birbaşa ValueCache-dən götürürük. Necə doldurulur, sonra deyəcəyəm. Bütün bu kollektorlar işlərini qəbul etmək üçün ConfigurationCache-dən istifadə edir və sonra onları əvvəlcədən emala ötürürlər.
Əvvəlcədən emal, həmçinin əvvəlcədən emal addımlarını əldə etmək üçün ConfigurationCache-dən istifadə edir və bu məlumatları fərqli şəkildə emal edir. 4.2 versiyasından başlayaraq biz onu proksiyə köçürdük. Bu, çox rahatdır, çünki əvvəlcədən emal özü olduqca ağır bir əməliyyatdır. Çox sayda məlumat elementi və yüksək toplama tezliyi olan çox böyük bir Zabbixiniz varsa, bu işi xeyli asanlaşdırır.
Müvafiq olaraq, biz bu məlumatları əvvəlcədən emaldan istifadə edərək hansısa şəkildə emal etdikdən sonra onu daha da emal etmək üçün HistoryCache-də saxlayırıq. Bununla məlumatların toplanması tamamlanır. Əsas prosesə keçirik.
Tarix sinxronizasiyası əməliyyatı
Zabbix-də əsas proses (monolit arxitektura olduğundan) Tarix sinxronlaşdırıcısıdır. Bu, hər bir məlumat elementinin, yəni hər bir dəyərin atomik emalı ilə məşğul olan əsas prosesdir:
- dəyər gəlir (o HistoryCache-dən götürür);
- Konfiqurasiya sinxronlaşdırıcısında yoxlayır: hesablama üçün hər hansı bir tetikleyici varsa - onları hesablayır;
əgər varsa, konfiqurasiya ilə zəruri hallarda xəbərdarlıq yaratmaq üçün hadisələr yaradır, eskalasiya yaradır; - sonrakı emal, aqreqasiya üçün triggerləri yazır; son bir saat ərzində və s. üzərində cəmləşdirirsinizsə, bu dəyər tarix cədvəlinə getməməsi üçün ValueCache tərəfindən yadda saxlanılır; beləliklə, ValueCache tetikleyiciləri, hesablanmış elementləri və s. qiymətləndirmək üçün lazım olan zəruri məlumatlarla doldurulur;
- sonra History syncer bütün məlumatları verilənlər bazasına yazır;
- verilənlər bazası onları diskə yazır - bununla emal tamamlanır.
Verilənlər bazası. önbelleğe alma
Verilənlər bazası tərəfində, qrafiklərə və ya bir növ hadisə hesabatlarına baxmaq istədiyiniz zaman müxtəlif keşlər var. Amma bu hesabat çərçivəsində mən onlar haqqında danışmayacağam.
MySQL üçün Innodb_buffer_pool və konfiqurasiya edilə bilən bir çox müxtəlif keşlər var.
Ancaq bunlar əsas olanlardır:
- paylaşılan_buferlər;
- effektiv_kesh_ölçüsü;
- paylaşılan_hovuz.
Bütün verilənlər bazaları üçün gətirdim ki, sorğular üçün tez-tez lazım olan məlumatları RAM-da saxlamağa imkan verən müəyyən keşlər var. Bunun üçün onların öz texnologiyaları var.
Verilənlər bazası performansı haqqında
Müvafiq olaraq, rəqabət mühiti var, yəni Zabbix server məlumatları toplayır və yazır. Yenidən işə salındıqda, o, həmçinin ValueCache-ni doldurmaq üçün tarixdən oxuyur və s. Orada veb interfeys əsasında qurulmuş Zabbix-API-dən istifadə edən skript və hesabatlara sahib ola bilərsiniz. "Zabbix"-API verilənlər bazasına daxil olur və qrafiklər, hesabatlar və ya bir növ hadisələrin siyahısını, son problemləri əldə etmək üçün lazımi məlumatları alır.
Digər çox populyar vizuallaşdırma həlli istifadəçilərimiz tərəfindən istifadə edilən Grafanadır. Həm "Zabbix" -API, həm də verilənlər bazası vasitəsilə birbaşa daxil ola bilir. O, həmçinin məlumat əldə etmək üçün müəyyən rəqabət yaradır: nəticələrin və testlərin sürətli çatdırılması üçün daha incə, daha yaxşı verilənlər bazası sazlanması lazımdır.
Tarixin təmizlənməsi. Zabbixin xadiməsi var
Zabbix-də istifadə edilən üçüncü zəng, Housekeeper ilə tarixi təmizləməkdir. Ev işçisi bütün parametrlərə hörmət edir, yəni məlumat elementlərimizdə nə qədər saxlanacağı (günlərlə), tendensiyaların nə qədər saxlanacağı və dəyişikliklərin dinamikası göstərilir.
Mən tez hesabladığımız TrendCash haqqında danışmadım: məlumatlar daxil olur, biz onu bir saat ərzində (əsasən son saat üçün rəqəmlər), orta/minimum məbləği ümumiləşdiririk və saatda bir dəfə trend cədvəlinə yazırıq. (“Trendlər”). Ev işçisi adi seçimlərlə verilənlər bazasından məlumatları işə salır və silir, bu da həmişə effektiv olmur.
Bunun təsirsiz olduğunu necə başa düşmək olar? Daxili proseslərin performans qrafiklərində aşağıdakı şəkli görə bilərsiniz:
Tarixçə sinxronlaşdırıcınız daim məşğuldur (qırmızı diaqram). Və yuxarıdakı "qırmızı" qrafik. Bu, işləyən və verilənlər bazasının təyin etdiyi bütün sətirləri silməsini gözləyən "Evdar"dır.
Bəzi Element ID-sini götürək: son 5 mini silmək lazımdır; əlbəttə ki, indekslər üzrə. Amma adətən verilənlər bazası kifayət qədər böyük olur - verilənlər bazası hələ də onu diskdən oxuyur və keş-belləyə yerləşdirir və bu verilənlər bazası üçün çox bahalı əməliyyatdır. Ölçüsündən asılı olaraq, bu, müəyyən performans problemlərinə səbəb ola bilər.
Siz sadə üsulla Housekeeper-i söndürə bilərsiniz - bizdə hər kəs üçün tanış veb interfeysimiz var. Ümumi İdarəetmədə ("Tədbirçi" üçün Parametrlər) parametrlər daxili tarix və tendensiyalar üçün daxili ev işlərini deaktiv edirik. Müvafiq olaraq, Housekeeper artıq bunu idarə etmir:
Bundan sonra nə etmək olar? Onu söndürdünüz, qrafikləriniz düzləndi... Bu halda hansı problemlər yarana bilər? Nə kömək edə bilər?
Bölmə (bölmə)
Bu, adətən sadaladığım hər bir əlaqəli verilənlər bazasında fərqli şəkildə konfiqurasiya edilir. MySQL-in öz texnologiyası var. Ancaq ümumiyyətlə PostgreSQL 10 və MySQL-ə gəldikdə, onlar çox oxşardırlar. Əlbəttə ki, bir çox daxili fərqlər var, bunların hamısı necə həyata keçirilir və hamısı performansa necə təsir edir. Ancaq ümumiyyətlə, yeni bir bölmə yaratmaq çox vaxt müəyyən problemlərə də gətirib çıxarır.
Quraşdırmağınızdan (bir gündə nə qədər məlumat yaratdığınızdan) asılı olaraq, onlar adətən ən minimalı təyin edirlər - bu, 1 gün / bölmə, "trendlər" üçün isə dəyişikliklərin dinamikası 1 ay / yeni bölmədir. Çox böyük bir quraşdırmanız varsa, bu dəyişə bilər.
Dərhal quraşdırmanın ölçüsü haqqında danışaq: saniyədə 5 minə qədər yeni dəyər (sözdə nvps) - bu kiçik bir "quraşdırma" hesab olunacaq. Orta - saniyədə 5 ilə 25 min dəyər arasında. Yuxarıdakı hər şey artıq verilənlər bazasının özünün çox diqqətli tənzimlənməsini tələb edən böyük və çox böyük qurğulardır.
Çox böyük qurğularda 1 gün optimal olmaya bilər. Mən şəxsən MySQL-də gündə 40 giqabaytlıq arakəsmələr gördüm (və daha çox ola bilər). Bu, bəzi problemlərə səbəb ola biləcək çox böyük həcmli məlumatdır. Onu azaltmaq lazımdır.
Bölmə niyə lazımdır?
Bölmənin etdiyi şey, məncə, hər kəs bilir, masa bölməsidir. Çox vaxt bunlar diskdə və span sorğularında ayrı fayllardır. Normal bölməyə daxil edilərsə, bir bölməni daha optimal şəkildə seçir.
Xüsusilə Zabbix üçün diapazona görə, diapazona görə istifadə olunur, yəni biz vaxt damğasından (adi nömrə, dövrün əvvəlindən bəri vaxt) istifadə edirik. Siz günün başlanğıcını/günün sonunu təyin edirsiniz və bu bölmədir. Müvafiq olaraq, iki gün əvvəlki məlumatlara daxil olursunuzsa, hamısı verilənlər bazasından daha sürətli seçilir, çünki önbelleğe yükləmək və göstərmək üçün yalnız bir fayl lazımdır (böyük cədvəldən daha çox).
Bir çox verilənlər bazası da daxiletməni sürətləndirir (bir uşaq cədvəlinə daxil etməklə). Mən mücərrəd danışarkən, amma bu da mümkündür. Parçalanma tez-tez kömək edir.
NoSQL üçün Elasticsearch
Bu yaxınlarda, 3.4-də biz NoSQL üçün bir həll tətbiq etdik. Elasticsearch-a yazmaq imkanı əlavə edildi. Siz ayrı-ayrı növlər yaza bilərsiniz: seçin - ya rəqəmləri, ya da bəzi işarələri yazın; sətirli mətnimiz var, siz Elasticsearch-də loglar yaza bilərsiniz... Buna uyğun olaraq veb-interfeys Elasticsearch-ə də daxil olacaq. Bu, bəzi hallarda yaxşı işləyir, lakin hazırda istifadə edilə bilər.
vaxt miqyasıb. Hipertables
4.4.2 üçün TimescaleDB kimi bir şeyə diqqət yetirdik. Bu nədir? Bu Postgres üçün bir uzantıdır, yəni doğma PostgreSQL interfeysinə malikdir. Üstəlik, bu genişləndirmə vaxt seriyası məlumatları ilə daha səmərəli işləməyə və avtomatik bölməyə imkan verir. Nə kimi görünür:
Bu hipertabledir - Timescale-də belə bir şey var. Bu, yaratdığınız hipertabledir və o, parçaları ehtiva edir. Parçalar arakəsmələrdir, səhv etmirəmsə, uşaq masalardır. Bu, həqiqətən təsirlidir.
TimescaleDB və PostgreSQL
TimescaleDB istehsalçılarının əmin olduğu kimi, onlar daha düzgün sorğuların işlənməsi alqoritmindən, xüsusən əlavələrdən istifadə edirlər ki, bu da artan verilənlər bazası daxiletmə ölçüsü ilə təxminən sabit performans əldə etməyə imkan verir. Yəni, 200 milyon sətirdən sonra Postgres çox pis əyilməyə başlayır və performansını sözün əsl mənasında sıfıra endirir, Timescale isə istənilən miqdarda məlumatla əlavələri mümkün qədər səmərəli şəkildə daxil etməyə imkan verir.
TimescaleDB-ni necə quraşdırmaq olar? Hər şey sadədir!
Onun sənədlərində var, təsvir edilmişdir - onu istənilən paketlərdən quraşdıra bilərsiniz ... Bu, rəsmi Postgres paketlərindən asılıdır. Əl ilə tərtib edilə bilər. Elə oldu ki, mən DB üçün tərtib etməli oldum.
Zabbix-də biz sadəcə Genişləndirməni aktivləşdiririk. Düşünürəm ki, Postgres-də Extension-dan istifadə edənlər... Siz sadəcə olaraq Extension-u aktivləşdirirsiniz, onu istifadə etdiyiniz Zabbix verilənlər bazası üçün yaradırsınız.
Və son addım...
vaxt miqyasıb. Köçürülən Tarix Cədvəlləri
Hipertable yaratmaq lazımdır. Bunun üçün xüsusi funksiya var - Hipertable yaradın. Orada, ilk parametr olaraq, bu verilənlər bazasında lazım olan cədvəli göstərin (bunun üçün hipertable yaratmalısınız).
Yaradılacaq sahə və yığın_zaman_intervalı (bu, parçaların intervalıdır (istifadə ediləcək bölmələr). 86 bir gündür.
migrate_data parametri: Əgər doğruya yapışdırsanız, bu, bütün cari məlumatları əvvəlcədən yaradılmış parçalara köçürür.
Mən özüm migrate_data istifadə etmişəm - bu, verilənlər bazanızın nə qədər böyük olmasından asılı olaraq kifayət qədər vaxt aparır. Məndə bir terabaytdan çox vaxt var idi - onu yaratmaq üçün bir saatdan çox vaxt lazım idi. Bəzi hallarda, test edərkən, köçürməmək üçün mətn (history_text) və string (history_str) üçün tarixi məlumatları sildim - onlar mənim üçün həqiqətən maraqlı deyildi.
Və son yeniləməni db_extention-da edirik: biz timescaledb-ni elə təyin etdik ki, verilənlər bazası və xüsusən də Zabbiximiz db_extension olduğunu başa düşsün. Onu aktivləşdirir və TimescaleDB üçün lazım olan "xüsusiyyətlərdən" istifadə edərək verilənlər bazası üçün düzgün sintaksis və sorğulardan istifadə edir.
Server Konfiqurasiyası
İki serverdən istifadə etdim. Birinci server kifayət qədər kiçik virtual maşın, 20 prosessor, 16 giqabayt operativ yaddaşdır. Bunun üzərinə Postgres 10.8 qurun:
Əməliyyat sistemi Debian, fayl sistemi xfs idi. Zabbix-in özünün istifadə edəcəyini çıxmaqla, bu xüsusi verilənlər bazasından istifadə etmək üçün minimum parametrləri etdim. Eyni maşında Zabbix serveri, PostgreSQL və yükləmə agentləri var idi.
Mən tez müxtəlif nəticələr yaratmaq üçün LoadableModule istifadə edən 50 aktiv agentdən istifadə etdim. Simləri, rəqəmləri və s. yaradanlar onlar idi. Verilənlər bazasını çoxlu məlumatlarla doldurdum. Əvvəlcə konfiqurasiya hər bir host üçün 5 min məlumat elementindən ibarət idi və hər bir məlumat elementində bir tətik var idi - bunun real quraşdırma olması üçün. Bəzən hətta istifadə etmək üçün birdən çox tətik tələb olunur.
Mən yeniləmə intervalını, yükün özünü təkcə 50 agentdən istifadə etməklə (daha çox əlavə etməklə) deyil, həm də dinamik məlumat elementlərindən istifadə etməklə və yeniləmə intervalını 4 saniyəyə endirməklə tənzimlədim.
Performans testi. PostgreSQL: 36k NVP
İlk qaçış, ilk quraşdırma bu aparatda (saniyədə 10 min dəyər) təmiz PostreSQL 35-da idi. Ümumiyyətlə, ekranda gördüyünüz kimi, məlumatların daxil edilməsi saniyənin bir hissəsini çəkir - hər şey yaxşı və sürətlidir, SSD diskləri (200 gigabayt). Yeganə odur ki, 20 GB kifayət qədər tez doldurulur.
Gələcəkdə belə qrafiklər çox olacaq. Bu Zabbix serverinin standart performans tablosudur.
Birinci qrafik saniyədə dəyərlərin sayıdır (mavi, yuxarı sol), bu halda 35 min dəyər. Bu (yuxarı mərkəz) tikinti proseslərini yükləyir və bu (yuxarı sağda) tam olaraq daxili prosesləri yükləyir: tarix sinxronlaşdırıcıları və burada (aşağı mərkəz) xeyli müddətdir işləyən ev işçisi.
Bu qrafik (aşağı mərkəz) ValueCache istifadəsini göstərir - tetikleyiciler üçün neçə ValueCache vurur (saniyədə bir neçə min dəyər). Digər mühüm qrafik dördüncüdür (aşağı solda), bu da haqqında danışdığım HistoryCache-in istifadəsini göstərir, hansı ki, verilənlər bazasına daxil edilməzdən əvvəl buferdir.
Performans testi. PostgreSQL: 50k NVP
Sonra, eyni aparatda yükü saniyədə 50 min dəyərə qədər artırdım. Təmizləyici tərəfindən yükləndikdə, hesablama ilə 10-2 saniyə ərzində artıq 3 min dəyər qeyd edildi. Hansı ki, əslində aşağıdakı ekran görüntüsündə göstərilir:
Ev işçisi artıq yola çıxmağa başlayır, lakin ümumi tarixdə sinker trapper istifadəsi hələ də 60% səviyyəsindədir (üçüncü diaqram, yuxarı sağda). HistoryCache artıq "Housekeeper" əməliyyatı zamanı aktiv şəkildə doldurulmağa başlayır (aşağı solda). Təxminən yarım gigabayt, 20% dolu idi.
Performans testi. PostgreSQL: 80k NVP
Daha sonra saniyədə 80 min dəyərə yüksəldi:
Bu, təxminən 400 min məlumat elementi, 280 min tetikleyici idi. Giriş, gördüyünüz kimi, tarix sinkerlərinin yüklənməsi baxımından (onlardan 30-u var idi) artıq kifayət qədər yüksək idi. Sonra mən müxtəlif parametrləri artırdım: tarix yaddaşı, önbellek... Bu aparatda tarix yuvalarının yüklənməsi maksimuma, demək olar ki, “rəfə” qədər artmağa başladı - müvafiq olaraq, HistoryCache çox yüksək yükə keçdi:
Bütün bu müddət ərzində sistemin bütün parametrlərini (prosessordan necə istifadə olunur, RAM) izləyirəm və diskdən istifadənin maksimum olduğunu aşkar etdim - bu hardware, bu virtual maşında bu diskin maksimum tutumuna nail oldum. Postgres belə bir intensivliklə məlumatları olduqca aktiv şəkildə atmağa başladı və diskin artıq yazmağa, oxumağa vaxtı yox idi ...
Artıq 48 prosessoru 128 giqabayt RAM olan başqa bir server götürdüm:
Mən də onu “tənzimlədim” - Tarix sinxronlaşdırıcısını (60 ədəd) quraşdırdım və məqbul performansa nail oldum. Əslində, biz "rəfdə" deyilik, amma bu, yəqin ki, məhsuldarlığın həddidir, burada artıq bununla bağlı nəsə etmək lazımdır.
Performans testi. Vaxt şkalasıDB: 80K NVP
Mənim əsas vəzifəm TimescaleDB-dən istifadə etmək idi. Hər bir qrafik bir eniş göstərir:
Bu uğursuzluqlar sadəcə məlumat köçürməsidir. Bundan sonra Zabbix serverində tarixçilərin yükləmə profili, gördüyünüz kimi, çox dəyişdi. Bu, məlumatı demək olar ki, 3 dəfə daha sürətli daxil etməyə və daha az HistoryCache istifadə etməyə imkan verir - müvafiq olaraq, siz məlumatları vaxtında alacaqsınız. Yenə saniyədə 80 min dəyər kifayət qədər yüksək göstəricidir (əlbəttə ki, Yandex üçün deyil). Ümumiyyətlə, bu, bir server ilə kifayət qədər böyük bir quraşdırmadır.
PostgreSQL Benchmark: 120k NVP
Sonra, məlumat elementlərinin sayının dəyərini yarım milyona qədər artırdım və saniyədə 125 min hesablanmış dəyər aldım:
Və bu qrafikləri əldə etdim:
Prinsipcə, bu işləyən bir quraşdırmadır, kifayət qədər uzun müddət işləyə bilər. Amma cəmi 1,5 terabaytlıq diskim olduğu üçün onu bir-iki günə xərclədim. Ən əsası, TimescaleDB-də eyni vaxtda yeni arakəsmələr yaradıldı və bu, MySQL haqqında demək mümkün olmayan performans üçün tamamilə nəzərə çarpmırdı.
Arakəsmələr adətən gecə saatlarında yaradılır, çünki bu, ümumiyyətlə cədvəllərin daxil edilməsini və işləməsini bloklayır və xidmətin deqradasiyasına səbəb ola bilər. Bu halda, belə deyil! Əsas vəzifə TimescaleDB-nin imkanlarını sınaqdan keçirmək idi. Belə bir rəqəm ortaya çıxdı: saniyədə 120 min dəyər.
“Cəmiyyət”də də nümunələr var:
Şəxs həmçinin TimescaleDB-ni işə saldı və io.weight-dan istifadə yükü prosessorun üzərinə düşdü; və daxili proses elementlərinin istifadəsi də TimescaleDB-nin daxil edilməsi ilə azaldılıb. Və bunlar adi pancake diskləridir, yəni adi disklərdə (SSD deyil) adi virtual maşındır!
Disk performansı ilə məhdudlaşan bəzi kiçik quraşdırmalar üçün TimescaleDB mənə çox yaxşı bir həll kimi görünür. Daha sürətli verilənlər bazası aparatına keçməzdən əvvəl işləməyə davam etmək yaxşı fikirdir.
Mən hamınızı tədbirlərimizə dəvət edirəm: Konfrans - Moskvada, Sammit - Riqada. Kanallarımızdan istifadə edin - Telegram, forum, IRC. Hər hansı bir sualınız varsa, bizim piştaxtamıza gəlin, hər şeyi danışa bilərik.
Tamaşaçı sualları
Tamaşaçılardan sual (bundan sonra - A): - Əgər TimescaleDB qurmaq çox asandırsa və o, belə bir performans təkan verirsə, bəlkə bundan Postgres ilə Zabbix qurmaq üçün ən yaxşı təcrübə kimi istifadə edilməlidir? Və bu həllin hər hansı tələləri və çatışmazlıqları varmı, yoxsa yenə də Zabbix-i özüm üçün etmək qərarına gəlsəm, Postgres-i təhlükəsiz götürə bilərəm, dərhal Timescale-i ora qoya, istifadə edə və heç bir problem barədə düşünməyəcəm?
AG: - Bəli, deyərdim ki, Postgres-dən dərhal TimescaleDB genişləndirilməsi ilə istifadə etmək yaxşı tövsiyədir. Dediyim kimi, bu "xüsusiyyət" eksperimental olmasına baxmayaraq, bir çox yaxşı rəylər. Ancaq əslində testlər bunun əla bir həll olduğunu göstərir (TimescaleDB ilə) və məncə, inkişaf edəcək! Bu genişlənmənin necə inkişaf etdiyini izləyirik və lazım olanı düzəldəcəyik.
Biz hətta inkişaf zamanı onların tanınmış "xüsusiyyətlərindən" birinə güvəndik: orada parçalarla bir az fərqli işləmək mümkün idi. Ancaq sonra növbəti buraxılışda onu kəsdilər və biz artıq bu koda etibar etməməli olduq. Bu həlli bir çox quraşdırmada istifadə etməyi tövsiyə edərdim. MySQL istifadə edirsinizsə... Orta quraşdırmalar üçün hər iki həll yaxşı işləyir.
A: - İcmadan olan ən son qrafiklərdə "Evdar" ilə bir diaqram var idi:
İşinə davam etdi. Housekeeper TimescaleDB ilə nə edir?
AG: - İndi dəqiq deyə bilmərəm - koda baxıb sizə daha ətraflı məlumat verəcəyəm. O, parçaları silmək üçün deyil, bir növ aqreqatları silmək üçün TimescaleDB sorğularından istifadə edir. Bu texniki suala cavab verməyə hazır deyiləm. Bu gün və ya sabah stenddə dəqiqləşdirəcəyik.
A: - Oxşar sualım var - Timescale-də silmə əməliyyatının icrası ilə bağlı.
A (tamaşaçıların cavabı): - Cədvəldən məlumatları sildiyiniz zaman, əgər bunu silməklə edirsinizsə, o zaman cədvəldən keçmək lazımdır - silin, təmizləyin, gələcək vakuum üçün hər şeyi qeyd edin. Timescale-də, parçaların olduğu üçün, siz ata bilərsiniz. Kobud desək, sadəcə böyük məlumatda olan fayla deyirsiniz: "Sil!"
Zaman şkalası sadəcə başa düşür ki, artıq belə bir parça yoxdur. Sorğu planlayıcısına inteqrasiya etdiyi üçün o, seçimdə və ya digər əməliyyatlarda sizin şərtlərinizi bağlayır və dərhal başa düşür ki, bu hissə artıq yoxdur - "Mən ora bir daha getməyəcəyəm!" (məlumat mövcud deyil). Hamısı budur! Yəni, cədvəl taraması ikili faylın silinməsi ilə əvəz olunur, buna görə də sürətlidir.
A: - Artıq SQL yox, mövzuya toxunmuşuq. Anladığım qədər, Zabbix həqiqətən məlumatları dəyişdirməyə ehtiyac duymur və bütün bunlar log kimi bir şeydir. Məlumatlarını dəyişdirə bilməyən, lakin eyni zamanda daha sürətli saxlaya, toplaya, geri qaytara bilən ixtisaslaşmış verilənlər bazalarından istifadə etmək mümkündürmü - Clickhouse, məsələn, Kafka formalı bir şey? .. Kafka həm də jurnaldır! Onları bir şəkildə inteqrasiya etmək mümkündürmü?
AG: - Boşaltma edilə bilər. 3.4 versiyasından bəri müəyyən bir "xüsusiyyətimiz" var: bütün tarixi faylları, hadisələri, qalan hər şeyi fayllara yaza bilərsiniz; və sonra hər hansı digər verilənlər bazasına bəzi işləyici göndərin. Əslində, bir çox insanlar yenidən işləyir və birbaşa verilənlər bazasına yazırlar. Tezliklə, tarix sinkerləri bütün bunları fayllara yazır, bu faylları döndərirlər və s. və siz bunu Clickhouse-a köçürə bilərsiniz. Planların nə olduğunu deyə bilmərəm, lakin ola bilsin ki, NoSQL həlləri (məsələn, Clickhouse) üçün əlavə dəstək davam edəcək.
A: – Ümumiyyətlə, belə çıxır ki, siz postqresdən tamamilə qurtula bilərsiniz?
AG: - Əlbəttə, Zabbix-də ən çətin hissə ən çox problem və hadisələr yaradan tarixi cədvəllərdir. Bu vəziyyətdə, hadisələri uzun müddət saxlamasanız və tarixi trendlərlə başqa bir sürətli saxlamada saxlasanız, ümumiyyətlə, heç bir problem olmayacağını düşünürəm.
A: - Məsələn, Clickhouse-a keçsəniz, hər şeyin nə qədər sürətlə işləyəcəyini təxmin edə bilərsinizmi?
AG: - Sınamamışam. Düşünürəm ki, Clickhouse-un öz interfeysi olduğunu nəzərə alsaq, ən azı eyni rəqəmləri olduqca sadə şəkildə əldə etmək olar, amma dəqiq deyə bilmərəm. Test etmək daha yaxşıdır. Hamısı konfiqurasiyadan asılıdır: neçə hostunuz var və s. Daxil etmək bir şeydir, ancaq bu məlumatları da götürməlisiniz - Grafana və ya başqa bir şey.
A: - Yəni, söhbət bu sürətli məlumat bazalarının böyük üstünlüyündən yox, bərabər mübarizədən gedir?
AG: - Düşünürəm ki, biz inteqrasiya etdikdə daha dəqiq testlər olacaq.
A: Yaxşı köhnə RRD hara getdi? SQL verilənlər bazasına keçməyinizə nə səbəb oldu? Əvvəlcə bütün göstəricilər RRD-də toplanırdı.
AG: - "Zabbix" RRD-də, bəlkə də çox qədim versiyada. SQL verilənlər bazası həmişə olub - klassik yanaşma. Klassik yanaşma MySQL, PostgreSQL-dir (onlar çoxdan mövcuddur). Biz demək olar ki, heç vaxt SQL və RRD verilənlər bazaları üçün ümumi interfeysdən istifadə etməmişik.
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