Kita bakal ndeleng carane Zabbix bisa digunakake karo database TimescaleDB minangka backend. Kita bakal nuduhake sampeyan carane miwiti saka ngeruk lan carane migrasi saka PostgreSQL. Kita uga bakal menehi tes kinerja komparatif saka rong konfigurasi.
HighLoad++ Siberia 2019. Tomsk Hall. 24 Juni, 16:00. Tesis lan . Konferensi HighLoad++ sabanjure bakal dianakake tanggal 6 lan 7 April 2020 ing St. Rincian lan karcis .
Andrey Gushchin (sabanjuré - AG): - Aku insinyur dhukungan teknis ZABBIX (sabanjuré diarani "Zabbix"), pelatih. Aku wis kerja ing dhukungan teknis luwih saka 6 taun lan duwe pengalaman langsung babagan kinerja. Dina iki aku bakal ngomong babagan kinerja sing bisa diwenehake TimescaleDB yen dibandhingake karo PostgreSQL biasa 10. Uga, sawetara bagean pambuka babagan cara kerjane ing umum.
Tantangan produktivitas paling dhuwur: saka koleksi data nganti ngresiki data
Kanggo miwiti, ana tantangan kinerja tartamtu sing diadhepi saben sistem pemantauan. Tantangan produktivitas pisanan yaiku ngumpulake lan ngolah data kanthi cepet.
Sistem ngawasi sing apik kudu cepet, pas wektune nampa kabeh data, proses miturut ekspresi pemicu, yaiku, proses miturut sawetara kritéria (iki beda ing sistem sing beda-beda) lan simpen ing basis data supaya bisa nggunakake data kasebut ing mangsa.
Tantangan kinerja kapindho yaiku panyimpenan riwayat. Simpen ing basis data asring lan entuk akses cepet lan trep menyang metrik kasebut sing diklumpukake sajrone sawetara wektu. Sing paling penting yaiku data iki trep kanggo entuk, digunakake ing laporan, grafik, pemicu, ing sawetara nilai ambang, kanggo tandha, lsp.
Tantangan kinerja katelu yaiku ngresiki riwayat, yaiku, nalika sampeyan tekan titik ing ngendi sampeyan ora perlu nyimpen metrik rinci sing wis diklumpukake luwih saka 5 taun (malah sasi utawa rong wulan). Sawetara simpul jaringan wis dibusak, utawa sawetara host, metrik ora dibutuhake maneh amarga wis lawas lan ora diklumpukake maneh. Kabeh iki kudu diresiki supaya database sampeyan ora dadi gedhe banget. Umumé, riwayat ngresiki paling asring minangka tes serius kanggo panyimpenan - asring duwe pengaruh sing kuat banget kanggo kinerja.
Kepiye carane ngatasi masalah cache?
Aku saiki bakal ngomong khusus babagan Zabbix. Ing Zabbix, telpon pisanan lan kaloro ditanggulangi nggunakake caching.
Koleksi lan pangolahan data - Kita nggunakake RAM kanggo nyimpen kabeh data iki. Data kasebut saiki bakal dibahas kanthi luwih rinci.
Uga ing sisih database ana sawetara caching kanggo pilihan utama - kanggo grafik lan liyane.
Caching ing sisih server Zabbix dhewe: kita duwe ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Opo iki?
ConfigurationCache minangka cache utama ing ngendi kita nyimpen metrik, host, item data, pemicu; kabeh sing perlu kanggo proses preprocessing, ngumpulake data, saka kang sarwa dumadi kanggo ngumpulake, karo frekuensi apa. Kabeh iki disimpen ing ConfigurationCache supaya ora menyang database lan nggawe pitakon sing ora perlu. Sawise server diwiwiti, kita nganyari cache iki (nggawe) lan nganyari kanthi periodik (gumantung setelan konfigurasi).
Caching ing Zabbix. Pangumpulan data
Ing kene diagram kasebut cukup gedhe:
Sing utama ing skema kasebut yaiku kolektor kasebut:
Iki minangka proses perakitan dhewe, macem-macem "pollers" sing tanggung jawab kanggo macem-macem jinis rakitan. Dheweke ngumpulake data liwat icmp, ipmi, lan macem-macem protokol lan nransfer kabeh menyang preprocessing.
PreProcessing HistoryCache
Uga, yen kita wis diwilang unsur data (sing menowo Zabbix ngerti), sing, diwilang, unsur data agregasi, kita njupuk langsung saka ValueCache. Aku bakal ngandhani sampeyan carane isine mengko. Kabeh kolektor iki nggunakake ConfigurationCache kanggo nampa proyek lan banjur pindhah menyang preprocessing.
Preprocessing uga nggunakake ConfigurationCache kanggo njupuk langkah-langkah preprocessing lan ngolah data iki kanthi macem-macem cara. Miwiti saka versi 4.2, kita wis pindhah menyang proxy. Iki trep banget, amarga preprocessing dhewe minangka operasi sing rada angel. Lan yen sampeyan duwe Zabbix sing gedhe banget, kanthi akeh unsur data lan frekuensi koleksi sing dhuwur, mula iki bakal nyederhanakake karya kasebut.
Mulane, sawise kita wis ngolah data iki ing sawetara cara nggunakake preprocessing, kita simpen ing HistoryCache kanggo proses luwih. Iki nyimpulake pangumpulan data. Kita pindhah menyang proses utama.
Karya sajarah sinkronisasi
Proses utama ing Zabbix (amarga arsitektur monolitik) yaiku sinkronisasi Sejarah. Iki minangka proses utama sing gegayutan khusus karo pangolahan atom saben unsur data, yaiku saben nilai:
- nilai rawuh (iku njupuk saka HistoryCache);
- mriksa ing sinkronisasi Konfigurasi: apa ana pemicu pitungan - ngetung;
yen ana - nggawe acara, nggawe eskalasi kanggo nggawe tandha, yen perlu miturut konfigurasi; - cathetan micu kanggo Processing sakteruse, aggregation; yen sampeyan nglumpukake sajrone jam pungkasan lan liya-liyane, nilai iki dielingi dening ValueCache supaya ora menyang tabel riwayat; Mangkono, ValueCache kapenuhan data perlu sing perlu kanggo ngetung pemicu, unsur diwilang, etc.;
- banjur History sinkronisasi nulis kabeh data menyang database;
- database nyerat menyang disk - iki ngendi proses Processing ends.
Database. Caching
Ing sisih database, yen sampeyan pengin ndeleng grafik utawa sawetara laporan babagan acara, ana macem-macem cache. Nanging ing laporan iki aku ora bakal ngomong babagan dheweke.
Kanggo MySQL ana Innodb_buffer_pool, lan akeh macem-macem cache sing uga bisa dikonfigurasi.
Nanging iki sing utama:
- shared_buffers;
- efektif_cache_size;
- shared_pool.
Kanggo kabeh database, Aku ngandika sing ana caches tartamtu sing ngijini sampeyan kanggo nyimpen ing RAM data sing asring needed kanggo pitakonan. Dheweke duwe teknologi dhewe kanggo iki.
Babagan Kinerja Database
Mulane, ana lingkungan sing kompetitif, yaiku, server Zabbix ngumpulake data lan ngrekam. Nalika diwiwiti maneh, uga diwaca saka riwayat kanggo ngisi ValueCache lan liya-liyane. Ing kene sampeyan bisa duwe skrip lan laporan sing nggunakake API Zabbix, sing dibangun ing antarmuka web. Zabbix API mlebu database lan nampa data sing dibutuhake kanggo njupuk grafik, laporan, utawa sawetara jinis dhaptar acara, masalah anyar.
Uga solusi visualisasi sing populer banget yaiku Grafana, sing digunakake pangguna. Bisa langsung mlebu liwat Zabbix API lan liwat database. Iki uga nggawe kompetisi tartamtu kanggo entuk data: tuning database sing luwih apik lan luwih apik dibutuhake kanggo tundhuk karo pangiriman asil lan tes kanthi cepet.
Mbusak riwayat. Zabbix duwe Housekeeper
Telpon kaping telu sing digunakake ing Zabbix yaiku ngresiki riwayat nggunakake Housekeeper. Housekeeper ngetutake kabeh setelan, yaiku, unsur data kita nuduhake suwene kanggo nyimpen (ing dina), suwene kanggo nyimpen tren, lan dinamika owah-owahan.
Aku ora ngomong babagan TrendCache, sing diwilang kanthi cepet: data teka, dikumpulake sajrone siji jam (biasane iki minangka angka kanggo jam pungkasan), jumlah rata-rata / minimal lan kita ngrekam sapisan jam ing tabel dinamika owah-owahan ("Tren") . "Housekeeper" miwiti lan mbusak data saka database nggunakake biasa pilih, kang ora tansah efektif.
Kepiye carane ngerti yen ora efektif? Sampeyan bisa ndeleng gambar ing ngisor iki ing grafik kinerja proses internal:
Sinkronisasi riwayat sampeyan terus sibuk (grafik abang). Lan grafik "abang" sing ana ing ndhuwur. Iki minangka "Housekeeper" sing diwiwiti lan ngenteni database mbusak kabeh baris sing wis ditemtokake.
Ayo njupuk sawetara ID Item: sampeyan kudu mbusak 5 ewu pungkasan; mesthi, dening indeks. Nanging biasane dataset cukup gedhe - database isih maca saka disk lan sijine menyang cache, lan iki operasi larang banget kanggo database. Gumantung saka ukurane, iki bisa nyebabake masalah kinerja tartamtu.
Sampeyan bisa mateni Housekeeper kanthi cara sing gampang - kita duwe antarmuka web sing akrab. Setelan ing Administrasi umum (setelan kanggo "Housekeeper") kita mateni housekeeping internal kanggo sajarah internal lan tren. Mulane, Housekeeper ora maneh ngontrol iki:
Apa sing bisa ditindakake sabanjure? Sampeyan mateni, grafik sampeyan wis leveled metu ... Apa masalah liyane bisa njedhul ing kasus iki? Apa sing bisa mbantu?
Pemisahan (sectioning)
Biasane iki dikonfigurasi kanthi cara sing beda ing saben basis data relasional sing wis dakdaftar. MySQL duwe teknologi dhewe. Nanging sakabèhé padha banget nalika nerangake PostgreSQL 10 lan MySQL. Mesthine, ana akeh bedane internal babagan carane kabeh dileksanakake lan carane kabeh mengaruhi kinerja. Nanging umume, nggawe partisi anyar asring uga nyebabake masalah tartamtu.
Gumantung saka persiyapan sampeyan (pira data sing digawe ing sedina), biasane nyetel minimal - iki 1 dina / kumpulan, lan kanggo "tren", dinamika owah-owahan - 1 wulan / kumpulan anyar. Iki bisa diganti yen sampeyan duwe persiyapan gedhe banget.
Ayo langsung ngomong babagan ukuran persiyapan: nganti 5 ewu nilai anyar per detik (disebut nvps) - iki bakal dianggep minangka "persiyapan" cilik. Rata-rata - saka 5 nganti 25 ewu nilai per detik. Kabeh sing ana ing ndhuwur iku instalasi gedhe lan gedhe banget sing mbutuhake konfigurasi database sing ati-ati.
Ing instalasi sing gedhe banget, 1 dina bisa uga ora optimal. Aku dhewe wis ndeleng partisi ing MySQL 40 gigabyte saben dina (lan bisa uga ana liyane). Iki minangka jumlah data sing akeh banget, sing bisa nyebabake sawetara masalah. Perlu dikurangi.
Napa sampeyan kudu partisi?
Apa Pemisahan nyedhiyakake, aku kabeh ngerti, yaiku pemisahan meja. Asring iki file kapisah ing panjalukan disk lan span. Iku milih siji partisi luwih optimal yen iku bagéan saka pemisahan normal.
Kanggo Zabbix, utamané, digunakake dening sawetara, dening sawetara, sing, kita nggunakake timestamp (nomer biasa, wektu wiwit awal jaman). Sampeyan nemtokake wiwitan dina / pungkasan dina, lan iki minangka partisi. Mulane, yen sampeyan njaluk data sing umure rong dina, kabeh bakal dijupuk saka database luwih cepet, amarga sampeyan mung kudu mbukak siji file menyang cache lan bali (tinimbang meja gedhe).
Akeh database uga nyepetake insert (sisipan menyang siji tabel anak). Aku ngomong abstrak saiki, nanging iki bisa uga. Partitoning asring mbantu.
Elasticsearch kanggo NoSQL
Bubar, ing 3.4, kita ngetrapake solusi NoSQL. Nambahake kemampuan kanggo nulis ing Elasticsearch. Sampeyan bisa nulis jinis tartamtu: sampeyan milih - salah siji nulis nomer utawa sawetara pratandha; kita duwe teks senar, sampeyan bisa nulis log menyang Elasticsearch ... Mulane, antarmuka web uga bakal ngakses Elasticsearch. Iki bisa digunakake ing sawetara kasus, nanging saiki bisa digunakake.
TimescaleDB. Hypertables
Kanggo 4.4.2 kita mbayar manungsa waé kanggo siji bab kaya TimescaleDB. Opo iki? Iki minangka extension kanggo PostgreSQL, yaiku, nduweni antarmuka PostgreSQL asli. Kajaba iku, ekstensi iki ngidini sampeyan bisa luwih efisien karo data timeseries lan duwe partisi otomatis. Apa sing katon:
Iki hypertable - ana konsep kaya ing Timescale. Iki minangka hypertable sing digawe, lan ngemot potongan. Potongan minangka partisi, iki minangka meja bocah, yen aku ora salah. Iku pancene efektif.
TimescaleDB lan PostgreSQL
Minangka pabrikan TimescaleDB njamin, dheweke nggunakake algoritma sing luwih bener kanggo ngolah pitakon, utamane sisipan, sing ngidini dheweke duwe kinerja sing kira-kira konstan kanthi ukuran sisipan set data sing tambah akeh. Yaiku, sawise 200 yuta larik Postgres, sing biasa wiwit mudhun banget lan ilang kinerja kanthi harfiah dadi nol, dene Timescale ngidini sampeyan nglebokake sisipan kanthi efisien kanthi jumlah data apa wae.
Kepiye carane nginstal TimescaleDB? Iku prasaja!
Iku ing dokumentasi, diterangake - sampeyan bisa nginstal saka paket kanggo maksud apa ... Iku gumantung ing paket Postgres resmi. Bisa dikompilasi kanthi manual. Kedaden aku kudu ngumpulake kanggo database.
Ing Zabbix kita mung ngaktifake Extension. Aku sing sing digunakake Extention ing Postgres ... Sampeyan mung ngaktifake Extention, nggawe kanggo database Zabbix sing digunakake.
Lan langkah pungkasan ...
TimescaleDB. Migrasi tabel sajarah
Sampeyan kudu nggawe hypertable. Ana fungsi khusus kanggo iki - Nggawe hypertable. Ing kono, parameter pisanan yaiku tabel sing dibutuhake ing database iki (sing kudu nggawe hypertable).
Kolom kanggo nggawe, lan chunk_time_interval (iki interval potongan (partisi sing kudu digunakake). 86 sedina.
Parameter Migrate_data: Yen sampeyan nglebokake menyang true, iki bakal migrasi kabeh data saiki menyang potongan sing wis digawe.
Aku wis nggunakake migrate_data dhewe - butuh wektu sing cukup, gumantung saka ukuran database sampeyan. Aku wis liwat terabyte - njupuk liwat jam kanggo nggawe. Ing sawetara kasus, sajrone testing, aku mbusak data historis kanggo teks (history_text) lan string (history_str) supaya ora nransfer - padha ora menarik banget kanggo kula.
Lan kita nggawe nganyari pungkasan ing db_extention kita: kita nginstal timescaledb supaya database lan, utamané, Zabbix kita mangertos sing ana db_extention. Dheweke ngaktifake lan nggunakake sintaks lan pitakon sing bener menyang database, nggunakake "fitur" sing perlu kanggo TimescaleDB.
Konfigurasi server
Aku digunakake loro server. Server pisanan yaiku mesin virtual sing cukup cilik, 20 prosesor, 16 gigabyte RAM. Aku ngatur Postgres 10.8 ing:
Sistem operasi yaiku Debian, sistem file yaiku xfs. Aku nggawe setelan minimal kanggo nggunakake database tartamtu iki, minus apa Zabbix dhewe bakal nggunakake. Ing mesin sing padha ana server Zabbix, PostgreSQL lan agen muatan.
Aku wis digunakake 50 agen aktif sing nggunakake LoadableModule kanggo cepet generate asil beda. Wong-wong mau sing nggawe senar, angka, lan liya-liyane. Aku ngisi database kanthi akeh data. Kaping pisanan, konfigurasi ngemot 5 ewu unsur data saben host, lan kira-kira saben unsur data ngemot pemicu - supaya iki dadi persiyapan nyata. Kadhangkala sampeyan kudu nggunakake luwih saka siji pemicu.
Aku diatur interval nganyari lan mbukak dhewe dening ora mung nggunakake 50 agen (nambah liyane), nanging uga nggunakake unsur data dinamis lan ngurangi interval nganyari kanggo 4 detik.
Tes kinerja. PostgreSQL: 36 ewu NVP
Peluncuran pisanan, persiyapan pisanan sing dakkarepake yaiku ing PostreSQL 10 murni ing hardware iki (35 ewu nilai per detik). Umumé, minangka sampeyan bisa ndeleng ing layar, masang data njupuk bagian sekedhik saka detik - kabeh iku apik lan cepet, SSD drive (200 gigabyte). Ing bab mung sing 20 GB isi munggah cukup cepet.
Bakal ana cukup akeh grafik kaya ing mangsa ngarep. Iki minangka dashboard kinerja server Zabbix standar.
Grafik pisanan yaiku jumlah nilai per detik (biru, kiwa ndhuwur), 35 ewu nilai ing kasus iki. Iki (tengah ndhuwur) minangka loading proses mbangun, lan iki (tengen ndhuwur) minangka loading proses internal: sinkronisasi sajarah lan housekeeper, sing kene (tengah ngisor) wis mlaku kanggo sawetara wektu.
Grafik iki (tengah ngisor) nuduhake panggunaan ValueCache - pira jumlah ValueCache kanggo pemicu (sawetara ewu nilai per detik). Grafik penting liyane yaiku sing kaping papat (kiwa ngisor), sing nuduhake panggunaan HistoryCache, sing dakkandhakake, yaiku buffer sadurunge dilebokake ing database.
Tes kinerja. PostgreSQL: 50 ewu NVP
Sabanjure, aku nambah beban dadi 50 ewu nilai per detik ing hardware sing padha. Nalika dimuat dening Housekeeper, 10 ewu nilai dicathet ing 2-3 detik kanthi pitungan. Apa, nyatane, ditampilake ing gambar ing ngisor iki:
"Housekeeper" wis wiwit ngganggu karya, nanging ing umum, beban ing trappers sajarah-sinker isih ing tingkat 60% (grafik katelu, tengen ndhuwur). HistoryCache wis wiwit diisi kanthi aktif nalika Housekeeper lagi mlaku (kiwa ngisor). Iku kira-kira setengah gigabyte, 20% kebak.
Tes kinerja. PostgreSQL: 80 ewu NVP
Banjur aku nambah dadi 80 ewu nilai per detik:
Iku kira-kira 400 ewu unsur data, 280 ewu pemicu. Sisipan, kaya sing sampeyan ngerteni, babagan beban sinker sejarah (ana 30 wong) wis cukup dhuwur. Banjur aku nambah macem-macem paramèter: sinkers sajarah, cache ... Ing hardware iki, beban ing sinkers sajarah wiwit nambah kanggo maksimum, meh "ing beting" - patut, HistoryCache tindak menyang mbukak dhuwur banget:
Kabeh wektu iki aku ngawasi kabeh paramèter sistem (carane prosesor digunakake, RAM) lan katutup sing pemanfaatan disk maksimum - Aku entuk kapasitas maksimum disk iki ing hardware iki, ing mesin virtual iki. "Postgres" wiwit mbucal data cukup aktif ing kakiyatan kuwi, lan disk ora ana maneh wektu kanggo nulis, maca ...
Aku njupuk server liyane sing wis 48 prosesor lan 128 gigabyte RAM:
Aku uga "nyetel" - nginstal sinkronisasi Sejarah (60 potongan) lan entuk kinerja sing bisa ditampa. Ing kasunyatan, kita ora "ing rak", nanging iki mbokmenawa watesan produktivitas, ngendi iku wis perlu kanggo nindakake soko bab iku.
Tes kinerja. TimescaleDB: 80 ewu NVP
Tugas utamaku yaiku nggunakake TimescaleDB. Saben grafik nuduhake penurunan:
Gagal iki persis migrasi data. Sawisé iku, ing server Zabbix, loading profil sinkers sajarah, minangka sampeyan bisa ndeleng, diganti kathah. Ngidini sampeyan nglebokake data meh 3 kaping luwih cepet lan nggunakake HistoryCache kurang - miturut, sampeyan bakal duwe data dikirim ing wektu. Maneh, 80 ewu nilai per detik minangka tingkat sing cukup dhuwur (mesthi, ora kanggo Yandex). Sakabèhé iki persiyapan cukup gedhe, karo siji server.
Tes kinerja PostgreSQL: 120 ewu NVP
Sabanjure, aku nambah nilai nomer unsur data dadi setengah yuta lan nampa nilai kalkulasi 125 ewu per detik:
Lan aku entuk grafik iki:
Ing asas, iki minangka persiyapan sing bisa digunakake, bisa digunakake kanggo wektu sing cukup suwe. Nanging wiwit aku mung 1,5 terabyte disk, Aku digunakake munggah ing saperangan dina. Ingkang paling penting yaiku ing wektu sing padha partisi anyar digawe ing TimescaleDB, lan iki pancen ora digatekake kanggo kinerja, sing ora bisa dikandhakake babagan MySQL.
Biasane, partisi digawe ing wayah wengi, amarga iki umume ngalangi selipan lan nggarap tabel lan bisa nyebabake degradasi layanan. Ing kasus iki ora! Tugas utama yaiku nguji kemampuan TimescaleDB. Asil ana angka ing ngisor iki: 120 ewu nilai per detik.
Ana uga conto ing masyarakat:
Wong uga nguripake TimescaleDB lan mbukak ing nggunakake io.weight dropped ing prosesor; lan panggunaan unsur proses internal uga wis suda amarga kalebu TimescaleDB. Kajaba iku, iki minangka disk pancake biasa, yaiku mesin virtual biasa ing disk biasa (dudu SSD)!
Kanggo sawetara persiyapan cilik sing diwatesi dening kinerja disk, TimescaleDB, miturut pendapatku, minangka solusi sing apik banget. Iki bakal ngidini sampeyan terus kerja sadurunge migrasi menyang hardware sing luwih cepet kanggo database.
Aku ngajak sampeyan kabeh kanggo acara kita: Konferensi ing Moscow, Summit ing Riga. Gunakake saluran kita - Telegram, forum, IRC. Yen sampeyan duwe pitakon, teka menyang meja, kita bisa ngomong babagan kabeh.
Pitakonan pamirsa
Pitakonan saka pamirsa (sabanjuré - A): - Yen TimescaleDB dadi gampang kanggo ngatur, lan menehi ngedongkrak kinerja, banjur mbok menawa iki kudu digunakake minangka laku paling apik kanggo configuring Zabbix karo Postgres? Lan ana pitfalls lan cacat saka solusi iki, utawa sawise kabeh, yen aku mutusaké kanggo nggawe Zabbix kanggo aku, aku bisa gampang njupuk Postgres, nginstal Timescale ana langsung, nggunakake lan ora mikir bab masalah ?
AG: - Ya, aku bakal ujar manawa iki minangka rekomendasi sing apik: gunakake Postgres langsung nganggo ekstensi TimescaleDB. Kaya sing wis dakkandhakake, akeh ulasan sing apik, sanajan kasunyatane "fitur" iki eksperimen. Nanging sejatine tes nuduhake yen iki minangka solusi sing apik (karo TimescaleDB) lan aku mikir bakal berkembang! Kita ngawasi kepiye extension iki berkembang lan bakal nggawe pangowahan yen dibutuhake.
Malah sajrone pangembangan, kita ngandelake salah sawijining "fitur" sing kondhang: bisa digarap potongan rada beda. Nanging banjur padha Cut metu ing release sabanjuré, lan kita kudu mungkasi gumantung ing kode iki. Aku nyaranake nggunakake solusi iki ing akeh persiyapan. Yen sampeyan nggunakake MySQL ... Kanggo persiyapan rata-rata, solusi apa wae bisa dianggo kanthi apik.
A: - Ing grafik pungkasan saka komunitas, ana grafik karo "Housekeeper":
Dheweke terus kerja. Apa sing ditindakake Housekeeper karo TimescaleDB?
AG: - Saiki aku ora bisa ngomong manawa - Aku bakal katon ing kode lan pitutur marang kowe luwih rinci. Iki nggunakake pitakon TimescaleDB supaya ora mbusak potongan, nanging kanthi cara nglumpukake. Aku durung siyap njawab pitakonan teknis iki. Kita bakal ngerteni luwih akeh ing stand dina iki utawa sesuk.
A: - Aku duwe pitakonan sing padha - babagan kinerja operasi mbusak ing Timescale.
A (jawaban saka pamirsa): - Nalika sampeyan mbusak data saka meja, yen sampeyan nindakake liwat mbusak, sampeyan kudu pindhah liwat meja - mbusak, ngresiki, tandha kabeh kanggo vakum mangsa. Ing Timescale, amarga sampeyan duwe potongan, sampeyan bisa nyelehake. Secara kasar, sampeyan mung ngandhani file sing ana ing data gedhe: "Busak!"
Timescale mung ngerti manawa potongan kasebut ora ana maneh. Lan amarga digabungake menyang perencana pitakon, nggunakake pancing kanggo nyekel kahanan sampeyan ing operasi sing dipilih utawa liyane lan langsung ngerti manawa potongan iki ora ana maneh - "Aku ora bakal lunga maneh!" (data ora kasedhiya). Iku kabeh! Tegese, pindai tabel diganti karo pambusakan file binar, dadi cepet.
A: – Kita wis ndemek topik non-SQL. Sa adoh aku ngerti, Zabbix ora perlu kanggo ngowahi data, lan kabeh iki kaya log. Apa bisa nggunakake database khusus sing ora bisa ngganti data, nanging ing wektu sing padha nyimpen, nglumpukake, lan nyebarake luwih cepet - Clickhouse, contone, kaya Kafka?.. Kafka uga log! Iku bisa kanggo piye wae nggabungake?
AG: - Unloading bisa rampung. Kita duwe "fitur" tartamtu wiwit versi 3.4: sampeyan bisa nulis kabeh file sajarah, acara, kabeh liya kanggo file; banjur ngirim menyang database liyane nggunakake sawetara handler. Nyatane, akeh wong ngolah lan nulis langsung menyang database. Ing fly, sinkers sajarah nulis kabeh iki menyang file, muter file iki, lan ing, lan sampeyan bisa nransfer iki kanggo Clickhouse. Aku ora bisa ngomong babagan rencana, nanging bisa uga dhukungan luwih lanjut kanggo solusi NoSQL (kayata Clickhouse) bakal terus.
A: – Umumé, iku dadi metu sing bisa rampung njaluk nyisihaken saka postgres?
AG: - Mesthi, bagean paling angel ing Zabbix yaiku tabel sejarah, sing nggawe masalah lan acara paling akeh. Ing kasus iki, yen sampeyan ora nyimpen acara kanggo dangu lan nyimpen sajarah karo tren ing sawetara panyimpenan cepet liyane, banjur ing umum, aku, ora bakal ana masalah.
A: - Apa sampeyan bisa ngira yen kabeh bakal luwih cepet yen sampeyan pindhah menyang Clickhouse, umpamane?
AG: - Aku durung nyoba. Aku sing paling nomer padha bisa ngrambah cukup prasaja, diwenehi sing Clickhouse wis antarmuka dhewe, nanging aku ora bisa ngomong manawa. Iku luwih apik kanggo nyoba. Iku kabeh gumantung ing konfigurasi: carane akeh host sampeyan duwe, lan ing. Nyisipake minangka salah sawijining perkara, nanging sampeyan uga kudu njupuk data iki - Grafana utawa liya-liyane.
A: – Dadi kita ngomong bab perang witjaksono, lan ora bab kauntungan gedhe saka database cepet iki?
AG: - Aku mikir yen kita nggabungake, bakal ana tes sing luwih akurat.
A: – Ing ngendi tindake RRD lawas sing apik? Apa sing nggawe sampeyan ngalih menyang database SQL? Kaping pisanan, kabeh metrik diklumpukake ing RRD.
AG: – Zabbix wis RRD, mbok menawa ing versi banget kuna. Wis mesthi ana database SQL - pendekatan klasik. Pendekatan klasik yaiku MySQL, PostgreSQL (wis suwe banget). Kita meh ora tau nggunakake antarmuka umum kanggo database SQL lan RRD.
Sawetara iklan 🙂
Matur nuwun kanggo tetep karo kita. Apa sampeyan seneng karo artikel kita? Pengin ndeleng konten sing luwih menarik? Ndhukung kita kanthi nggawe pesenan utawa menehi rekomendasi menyang kanca, , analog unik saka server level entri, sing diciptakake kanggo sampeyan: (kasedhiya karo RAID1 lan RAID10, munggah 24 intine lan nganti 40GB DDR4).
Dell R730xd 2 kaping luwih murah ing pusat data Equinix Tier IV ing Amsterdam? Mung kene ing Walanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - saka $99! Maca babagan
Source: www.habr.com