Kita akan melihat bagaimana Zabbix bekerja dengan database TimescaleDB sebagai backend. Kami akan menunjukkan cara memulai dari awal dan cara bermigrasi dari PostgreSQL. Kami juga akan memberikan uji kinerja komparatif dari kedua konfigurasi tersebut.
HighLoad++ Siberia 2019. Balai Tomsk. 24 Juni, 16:00. Tesis dan . Konferensi HighLoad++ berikutnya akan diadakan pada tanggal 6 dan 7 April 2020 di St. Detail dan tiket .
Andrey Gushchin (selanjutnya – AG): – Saya seorang insinyur dukungan teknis ZABBIX (selanjutnya disebut “Zabbix”), seorang pelatih. Saya telah bekerja di bagian dukungan teknis selama lebih dari 6 tahun dan memiliki pengalaman langsung dengan kinerja. Hari ini saya akan berbicara tentang kinerja yang dapat diberikan TimescaleDB jika dibandingkan dengan PostgreSQL 10 biasa. Juga, beberapa bagian pengantar tentang cara kerjanya secara umum.
Tantangan produktivitas teratas: mulai dari pengumpulan data hingga pembersihan data
Pertama-tama, ada tantangan kinerja tertentu yang dihadapi setiap sistem pemantauan. Tantangan produktivitas yang pertama adalah mengumpulkan dan memproses data dengan cepat.
Sistem pemantauan yang baik harus menerima semua data dengan cepat dan tepat waktu, memprosesnya sesuai dengan ekspresi pemicu, yaitu memprosesnya berdasarkan beberapa kriteria (hal ini berbeda pada sistem yang berbeda) dan menyimpannya dalam database untuk menggunakan data ini dalam masa depan.
Tantangan kinerja kedua adalah penyimpanan riwayat. Simpan dalam database sesering mungkin dan dapatkan akses cepat dan nyaman ke metrik ini yang dikumpulkan selama periode waktu tertentu. Yang paling penting adalah data ini mudah diperoleh, digunakan dalam laporan, grafik, pemicu, dalam beberapa nilai ambang batas, untuk peringatan, dll.
Tantangan kinerja ketiga adalah pembersihan riwayat, yaitu ketika Anda sampai pada titik di mana Anda tidak perlu menyimpan metrik terperinci apa pun yang telah dikumpulkan selama 5 tahun (bahkan berbulan-bulan atau dua bulan). Beberapa node jaringan telah dihapus, atau beberapa host, metriknya tidak lagi diperlukan karena sudah usang dan tidak lagi dikumpulkan. Semua ini perlu dibersihkan agar database Anda tidak bertambah terlalu besar. Secara umum, menghapus riwayat sering kali merupakan ujian serius bagi penyimpanan - sering kali hal ini berdampak sangat kuat pada kinerja.
Bagaimana cara mengatasi masalah cache?
Sekarang saya akan berbicara secara khusus tentang Zabbix. Di Zabbix, panggilan pertama dan kedua diselesaikan menggunakan caching.
Pengumpulan dan pemrosesan data - Kami menggunakan RAM untuk menyimpan semua data ini. Data ini sekarang akan dibahas lebih rinci.
Juga di sisi database ada beberapa caching untuk pilihan utama - untuk grafik dan hal lainnya.
Caching di sisi server Zabbix itu sendiri: kami memiliki ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Apa itu?
ConfigurationCache adalah cache utama tempat kami menyimpan metrik, host, item data, pemicu; semua yang Anda perlukan untuk memproses pra-pemrosesan, mengumpulkan data, dari host mana yang dikumpulkan, dengan frekuensi berapa. Semua ini disimpan di ConfigurationCache agar tidak masuk ke database dan membuat pertanyaan yang tidak perlu. Setelah server dimulai, kami memperbarui cache ini (membuatnya) dan memperbaruinya secara berkala (tergantung pada pengaturan konfigurasi).
Menyimpan cache di Zabbix. Pengumpulan data
Di sini diagramnya cukup besar:
Yang utama dalam skema ini adalah kolektor berikut:
Ini adalah proses perakitan itu sendiri, berbagai “pemeriksa” yang bertanggung jawab atas berbagai jenis pertemuan. Mereka mengumpulkan data melalui icmp, ipmi, dan berbagai protokol dan mentransfer semuanya ke prapemrosesan.
Cache Riwayat Pra-Pemrosesan
Selain itu, jika kita telah menghitung elemen data (mereka yang akrab dengan Zabbix tahu), yaitu elemen data agregasi terhitung, kita mengambilnya langsung dari ValueCache. Saya akan memberi tahu Anda cara mengisinya nanti. Semua kolektor ini menggunakan ConfigurationCache untuk menerima pekerjaannya dan kemudian meneruskannya ke prapemrosesan.
Prapemrosesan juga menggunakan ConfigurationCache untuk mendapatkan langkah prapemrosesan dan memproses data ini dengan berbagai cara. Mulai dari versi 4.2, kami telah memindahkannya ke proxy. Ini sangat mudah, karena pra-pemrosesan itu sendiri adalah operasi yang agak sulit. Dan jika Anda memiliki Zabbix yang sangat besar, dengan sejumlah besar elemen data dan frekuensi pengumpulan yang tinggi, ini sangat menyederhanakan pekerjaan.
Oleh karena itu, setelah kami memproses data ini dengan cara tertentu menggunakan prapemrosesan, kami menyimpannya di HistoryCache untuk diproses lebih lanjut. Ini menyimpulkan pengumpulan data. Kami beralih ke proses utama.
Pekerjaan sinkronisasi sejarah
Proses utama di Zabbix (karena merupakan arsitektur monolitik) adalah sinkronisasi Sejarah. Ini adalah proses utama yang secara khusus berhubungan dengan pemrosesan atom setiap elemen data, yaitu setiap nilai:
- nilainya berasal (diambil dari HistoryCache);
- memeriksa sinkronisasi Konfigurasi: apakah ada pemicu untuk perhitungan - menghitungnya;
jika ada - membuat acara, membuat eskalasi untuk membuat peringatan, jika perlu sesuai dengan konfigurasi; - catatan memicu untuk pemrosesan selanjutnya, agregasi; jika Anda menggabungkan selama satu jam terakhir dan seterusnya, nilai ini diingat oleh ValueCache agar tidak masuk ke tabel riwayat; Dengan demikian, ValueCache diisi dengan data penting yang diperlukan untuk menghitung pemicu, elemen terhitung, dll.;
- kemudian sinkronisasi Riwayat menulis semua data ke database;
- database menuliskannya ke disk - di sinilah proses pemrosesan berakhir.
Basis data. cache
Di sisi database, ketika Anda ingin melihat grafik atau beberapa laporan peristiwa, terdapat berbagai cache. Namun dalam laporan ini saya tidak akan membicarakannya.
Untuk MySQL ada Innodb_buffer_pool, dan banyak cache berbeda yang juga dapat dikonfigurasi.
Tapi ini yang utama:
- shared_buffer;
- ukuran_cache_efektif;
- shared_pool.
Untuk semua database, saya katakan bahwa ada cache tertentu yang memungkinkan Anda menyimpan data dalam RAM yang sering diperlukan untuk kueri. Mereka punya teknologi sendiri untuk ini.
Tentang Kinerja Basis Data
Oleh karena itu, terdapat lingkungan yang kompetitif, yaitu server Zabbix mengumpulkan data dan mencatatnya. Saat dimulai ulang, ia juga membaca riwayat untuk mengisi ValueCache dan seterusnya. Di sini Anda dapat memiliki skrip dan laporan yang menggunakan Zabbix API, yang dibangun pada antarmuka web. Zabbix API memasuki database dan menerima data yang diperlukan untuk mendapatkan grafik, laporan, atau semacam daftar kejadian, masalah terkini.
Solusi visualisasi yang juga sangat populer adalah Grafana, yang digunakan pengguna kami. Bisa langsung login baik melalui Zabbix API maupun melalui database. Hal ini juga menciptakan persaingan tertentu untuk mendapatkan data: diperlukan penyetelan database yang lebih baik dan lebih baik agar dapat memenuhi pengiriman hasil dan pengujian yang cepat.
Menghapus riwayat. Zabbix memiliki Pengurus Rumah Tangga
Panggilan ketiga yang digunakan di Zabbix adalah membersihkan history menggunakan Housekeeper. Pengurus rumah tangga mengikuti semua pengaturan, yaitu elemen data kami menunjukkan berapa lama untuk menyimpan (dalam hari), berapa lama untuk menyimpan tren, dan dinamika perubahan.
Saya tidak berbicara tentang TrendCache, yang kami hitung dengan cepat: data tiba, kami menggabungkannya selama satu jam (kebanyakan ini adalah angka untuk satu jam terakhir), jumlahnya rata-rata/minimum dan kami mencatatnya sekali dalam satu jam di tabel dinamika perubahan (“Tren”) . “Pengurus Rumah Tangga” memulai dan menghapus data dari database menggunakan pemilihan biasa, yang tidak selalu efektif.
Bagaimana memahami bahwa ini tidak efektif? Anda dapat melihat gambar berikut pada grafik kinerja proses internal:
Sinkronisasi Riwayat Anda selalu sibuk (grafik merah). Dan grafik “merah” di atas. Ini adalah "Pengurus Rumah Tangga" yang memulai dan menunggu database menghapus semua baris yang telah ditentukan.
Mari kita ambil beberapa ID Item: Anda perlu menghapus 5 ribu yang terakhir; tentu saja, berdasarkan indeks. Namun biasanya kumpulan datanya cukup besar - database masih membacanya dari disk dan menyimpannya ke dalam cache, dan ini adalah operasi yang sangat mahal untuk database. Tergantung pada ukurannya, hal ini dapat menyebabkan masalah kinerja tertentu.
Anda dapat menonaktifkan Housekeeper dengan cara sederhana - kami memiliki antarmuka web yang familier. Pengaturan di Administrasi umum (pengaturan untuk “Pengurus Rumah Tangga”) kami menonaktifkan tata graha internal untuk riwayat dan tren internal. Oleh karena itu, Pengurus Rumah Tangga tidak lagi mengontrol hal ini:
Apa yang dapat Anda lakukan selanjutnya? Anda mematikannya, grafik Anda sudah rata... Masalah apa lagi yang mungkin timbul dalam kasus ini? Apa yang bisa membantu?
Partisi (pembagian)
Biasanya ini dikonfigurasi dengan cara berbeda pada setiap database relasional yang saya daftarkan. MySQL memiliki teknologinya sendiri. Namun secara keseluruhan keduanya sangat mirip dalam hal PostgreSQL 10 dan MySQL. Tentu saja, terdapat banyak perbedaan internal dalam cara penerapannya dan pengaruhnya terhadap kinerja. Namun secara umum, pembuatan partisi baru seringkali juga menimbulkan masalah tertentu.
Bergantung pada pengaturan Anda (berapa banyak data yang Anda buat dalam satu hari), mereka biasanya menetapkan minimum - ini adalah 1 hari / kumpulan, dan untuk "tren", dinamika perubahan - 1 bulan / kumpulan baru. Ini mungkin berubah jika Anda memiliki pengaturan yang sangat besar.
Katakanlah langsung tentang ukuran penyiapan: hingga 5 ribu nilai baru per detik (disebut nvps) - ini akan dianggap sebagai "penyiapan" kecil. Rata-rata – dari 5 hingga 25 ribu nilai per detik. Semua yang diatas sudah merupakan instalasi yang besar dan sangat besar sehingga memerlukan konfigurasi database yang sangat hati-hati.
Pada instalasi yang sangat besar, 1 hari mungkin tidak optimal. Saya pribadi telah melihat partisi di MySQL sebesar 40 gigabyte per hari (dan mungkin lebih banyak lagi). Ini adalah jumlah data yang sangat besar, yang dapat menimbulkan beberapa masalah. Itu perlu dikurangi.
Mengapa Anda perlu mempartisi?
Apa yang disediakan oleh Partisi, saya rasa semua orang tahu, adalah partisi tabel. Seringkali ini adalah file terpisah pada permintaan disk dan span. Ia memilih satu partisi secara lebih optimal jika itu adalah bagian dari partisi normal.
Khususnya untuk Zabbix, digunakan berdasarkan rentang, berdasarkan rentang, yaitu kami menggunakan stempel waktu (angka biasa, waktu sejak awal epoch). Anda menentukan awal hari/akhir hari, dan ini adalah partisinya. Oleh karena itu, jika Anda meminta data yang berumur dua hari, semuanya akan diambil dari database lebih cepat, karena Anda hanya perlu memuat satu file ke dalam cache dan mengembalikannya (bukan tabel besar).
Banyak database juga mempercepat penyisipan (penyisipan ke dalam satu tabel anak). Saya berbicara secara abstrak untuk saat ini, tetapi ini juga mungkin. Mempartisi sering kali membantu.
Pencarian elastis untuk NoSQL
Baru-baru ini, di versi 3.4, kami menerapkan solusi NoSQL. Menambahkan kemampuan menulis di Elasticsearch. Anda dapat menulis jenis tertentu: Anda memilih - menulis angka atau beberapa tanda; kami memiliki teks string, Anda dapat menulis log ke Elasticsearch... Oleh karena itu, antarmuka web juga akan mengakses Elasticsearch. Ini berfungsi dengan baik dalam beberapa kasus, tetapi saat ini dapat digunakan.
Skala waktuDB. Hipertabel
Untuk 4.4.2 kami memperhatikan satu hal seperti TimescaleDB. Apa itu? Ini adalah ekstensi untuk PostgreSQL, yaitu memiliki antarmuka asli PostgreSQL. Selain itu, ekstensi ini memungkinkan Anda bekerja lebih efisien dengan data deret waktu dan memiliki partisi otomatis. Seperti apa rupanya:
Ini hypertable - ada konsep seperti itu di Timescale. Ini adalah hypertable yang Anda buat, dan berisi potongan. Potongan itu partisi, ini tabel anak kalau tidak salah. Ini sangat efektif.
TimescaleDB dan PostgreSQL
Seperti yang dipastikan oleh produsen TimescaleDB, mereka menggunakan algoritme yang lebih tepat untuk memproses kueri, khususnya penyisipan, yang memungkinkan mereka memiliki kinerja yang kira-kira konstan dengan bertambahnya ukuran penyisipan kumpulan data. Artinya, setelah 200 juta baris Postgres, yang biasa mulai melorot dan kehilangan kinerja hingga nol, sementara Timescale memungkinkan Anda memasukkan sisipan seefisien mungkin dengan jumlah data berapa pun.
Bagaimana cara menginstal TimescaleDB? Itu mudah!
Ada di dokumentasi, dijelaskan - Anda dapat menginstalnya dari paket untuk apa pun... Itu tergantung pada paket resmi Postgres. Dapat dikompilasi secara manual. Kebetulan saya harus mengkompilasi untuk database.
Di Zabbix kita cukup mengaktifkan Extention. Saya pikir mereka yang menggunakan Extention di Postgres... Anda cukup mengaktifkan Extention, buat untuk database Zabbix yang Anda gunakan.
Dan langkah terakhir...
Skala waktuDB. Migrasi tabel riwayat
Anda perlu membuat hypertable. Ada fungsi khusus untuk ini – Buat hypertable. Di dalamnya, parameter pertama adalah tabel yang diperlukan dalam database ini (untuk itu Anda perlu membuat hypertable).
Bidang yang akan digunakan untuk membuat, dan chunk_time_interval (ini adalah interval potongan (partisi yang perlu digunakan). 86 adalah satu hari.
Parameter Migrate_data: Jika Anda memasukkan ke true, maka ini akan memigrasikan semua data saat ini ke potongan yang telah dibuat sebelumnya.
Saya sendiri telah menggunakan migrasi_data - ini memerlukan waktu yang cukup lama, bergantung pada seberapa besar database Anda. Saya memiliki lebih dari satu terabyte - butuh lebih dari satu jam untuk membuatnya. Dalam beberapa kasus, selama pengujian, saya menghapus data historis untuk teks (history_text) dan string (history_str) agar tidak mentransfernya - mereka tidak terlalu menarik bagi saya.
Dan kami melakukan pembaruan terakhir di db_extention kami: kami menginstal timescaledb sehingga database dan, khususnya, Zabbix kami memahami bahwa ada db_extention. Dia mengaktifkannya dan menggunakan sintaks dan kueri yang benar ke database, menggunakan “fitur” yang diperlukan untuk TimescaleDB.
Konfigurasi server
Saya menggunakan dua server. Server pertama adalah mesin virtual yang cukup kecil, 20 prosesor, RAM 16 gigabyte. Saya mengkonfigurasi Postgres 10.8 di atasnya:
Sistem operasinya adalah Debian, sistem filenya adalah xfs. Saya membuat pengaturan minimal untuk menggunakan database khusus ini, kecuali apa yang akan digunakan Zabbix sendiri. Di mesin yang sama terdapat server Zabbix, PostgreSQL dan agen beban.
Saya telah menggunakan 50 agen aktif yang menggunakan LoadableModule untuk menghasilkan hasil yang berbeda dengan cepat. Merekalah yang menghasilkan string, angka, dan sebagainya. Saya mengisi database dengan banyak data. Awalnya, konfigurasi berisi 5 ribu elemen data per host, dan kira-kira setiap elemen data berisi pemicu - agar ini menjadi pengaturan yang sebenarnya. Terkadang Anda bahkan memerlukan lebih dari satu pemicu untuk digunakan.
Saya mengatur interval pembaruan dan pemuatannya sendiri dengan tidak hanya menggunakan 50 agen (menambahkan lebih banyak), tetapi juga menggunakan elemen data dinamis dan mengurangi interval pembaruan menjadi 4 detik.
Uji kinerja. PostgreSQL: 36 ribu NVP
Peluncuran pertama, pengaturan pertama yang saya lakukan adalah pada PostreSQL 10 murni pada perangkat keras ini (nilai 35 ribu per detik). Secara umum, seperti yang Anda lihat di layar, memasukkan data membutuhkan waktu sepersekian detik - semuanya baik dan cepat, drive SSD (200 gigabyte). Satu-satunya hal adalah 20 GB terisi cukup cepat.
Akan ada cukup banyak grafik seperti itu di masa depan. Ini adalah dasbor kinerja server Zabbix standar.
Grafik pertama adalah jumlah nilai per detik (biru, kiri atas), dalam hal ini 35 ribu nilai. Ini (tengah atas) adalah pemuatan proses pembangunan, dan ini (kanan atas) adalah pemuatan proses internal: sinkronisasi riwayat dan pengurus rumah tangga, yang di sini (tengah bawah) telah berjalan cukup lama.
Grafik ini (tengah bawah) menunjukkan penggunaan ValueCache - berapa banyak ValueCache yang terkena pemicu (beberapa ribu nilai per detik). Grafik penting lainnya adalah grafik keempat (kiri bawah), yang menunjukkan penggunaan HistoryCache yang saya bicarakan, yaitu buffer sebelum dimasukkan ke dalam database.
Uji kinerja. PostgreSQL: 50 ribu NVP
Selanjutnya, saya meningkatkan beban menjadi 50 ribu nilai per detik pada perangkat keras yang sama. Saat dimuat oleh Housekeeper, 10 ribu nilai dicatat dalam 2-3 detik dengan perhitungan. Apa sebenarnya yang ditunjukkan pada tangkapan layar berikut:
“Pengurus rumah tangga” sudah mulai mengganggu pekerjaan, namun secara umum beban penjebak penyerap sejarah masih di level 60% (grafik ketiga, kanan atas). HistoryCache sudah mulai terisi secara aktif saat Housekeeper sedang berjalan (kiri bawah). Itu sekitar setengah gigabyte, 20% penuh.
Uji kinerja. PostgreSQL: 80 ribu NVP
Lalu saya tingkatkan menjadi 80 ribu nilai per detik:
Itu sekitar 400 ribu elemen data, 280 ribu pemicu. Sisipannya, seperti yang Anda lihat, dalam hal beban pemberat sejarah (ada 30 di antaranya) sudah cukup tinggi. Kemudian saya meningkatkan berbagai parameter: penyerap riwayat, cache... Pada perangkat keras ini, beban pada penyerap riwayat mulai meningkat hingga maksimum, hampir "di rak" - oleh karena itu, HistoryCache mengalami beban yang sangat tinggi:
Selama ini saya memantau semua parameter sistem (bagaimana prosesor digunakan, RAM) dan menemukan bahwa pemanfaatan disk sudah maksimal - saya mencapai kapasitas maksimum disk ini pada perangkat keras ini, pada mesin virtual ini. "Postgres" mulai membuang data dengan cukup aktif pada intensitas seperti itu, dan disk tidak lagi punya waktu untuk menulis, membaca...
Saya mengambil server lain yang sudah memiliki 48 prosesor dan 128 gigabyte RAM:
Saya juga "menyetelnya" - menginstal sinkronisasi History (60 buah) dan mencapai kinerja yang dapat diterima. Faktanya, kita tidak “berada di rak”, tetapi ini mungkin merupakan batas produktivitas, di mana kita perlu melakukan sesuatu untuk mengatasinya.
Uji kinerja. TimescaleDB: 80 ribu NVP
Tugas utama saya adalah menggunakan TimescaleDB. Setiap grafik menunjukkan penurunan:
Kegagalan ini tepatnya adalah migrasi data. Setelah itu, di server Zabbix, profil pemuatan penyerap riwayat, seperti yang Anda lihat, banyak berubah. Ini memungkinkan Anda memasukkan data hampir 3 kali lebih cepat dan menggunakan lebih sedikit HistoryCache - karenanya, data Anda akan dikirimkan tepat waktu. Sekali lagi, 80 ribu nilai per detik adalah angka yang cukup tinggi (tentu saja, bukan untuk Yandex). Secara keseluruhan ini adalah setup yang cukup besar, dengan satu server.
Tes kinerja PostgreSQL: 120 ribu NVP
Selanjutnya, saya meningkatkan nilai jumlah elemen data menjadi setengah juta dan mendapatkan nilai terhitung 125 ribu per detik:
Dan saya mendapatkan grafik ini:
Pada prinsipnya, ini adalah pengaturan yang berfungsi, dapat bekerja untuk waktu yang cukup lama. Namun karena saya hanya mempunyai disk berukuran 1,5 terabyte, saya menggunakannya dalam beberapa hari. Hal yang paling penting adalah pada saat yang sama partisi baru dibuat di TimescaleDB, dan hal ini sama sekali tidak diperhatikan dalam hal kinerja, yang tidak dapat dikatakan tentang MySQL.
Biasanya, partisi dibuat pada malam hari, karena hal ini biasanya menghalangi penyisipan dan bekerja dengan tabel dan dapat menyebabkan penurunan layanan. Dalam hal ini tidak demikian! Tugas utamanya adalah menguji kemampuan TimescaleDB. Hasilnya adalah angka berikut: 120 ribu nilai per detik.
Ada juga contoh di masyarakat:
Orang tersebut juga mengaktifkan TimescaleDB dan beban penggunaan io.weight turun pada prosesor; dan penggunaan elemen proses internal juga berkurang karena dimasukkannya TimescaleDB. Selain itu, ini adalah disk pancake biasa, yaitu mesin virtual biasa pada disk biasa (bukan SSD)!
Untuk beberapa pengaturan kecil yang dibatasi oleh kinerja disk, TimescaleDB menurut saya adalah solusi yang sangat baik. Ini akan memungkinkan Anda untuk terus bekerja sebelum bermigrasi ke perangkat keras yang lebih cepat untuk database.
Saya mengundang Anda semua ke acara kami: Konferensi di Moskow, Konferensi Tingkat Tinggi di Riga. Gunakan saluran kami - Telegram, forum, IRC. Jika Anda memiliki pertanyaan, datanglah ke meja kami, kami dapat membicarakan segalanya.
Pertanyaan Audiens
Pertanyaan dari penonton (selanjutnya - A): - Jika TimescaleDB sangat mudah dikonfigurasi, dan memberikan peningkatan kinerja, mungkin ini harus digunakan sebagai praktik terbaik untuk mengonfigurasi Zabbix dengan Postgres? Dan apakah ada jebakan dan kerugian dari solusi ini, atau lagi pula, jika saya memutuskan untuk membuat Zabbix sendiri, saya dapat dengan mudah menggunakan Postgres, segera menginstal Timescale di sana, menggunakannya dan tidak memikirkan masalah apa pun?
AG: – Ya, menurut saya ini adalah rekomendasi yang bagus: segera gunakan Postgres dengan ekstensi TimescaleDB. Seperti yang sudah saya katakan, banyak ulasan bagus, meskipun faktanya “fitur” ini bersifat eksperimental. Namun sebenarnya pengujian menunjukkan bahwa ini adalah solusi hebat (dengan TimescaleDB) dan menurut saya ini akan berkembang! Kami memantau bagaimana ekstensi ini berkembang dan akan melakukan perubahan jika diperlukan.
Bahkan selama pengembangan, kami mengandalkan salah satu “fitur” mereka yang terkenal: potongan dapat digunakan dengan cara yang sedikit berbeda. Namun kemudian mereka menghentikannya pada rilis berikutnya, dan kami harus berhenti mengandalkan kode ini. Saya akan merekomendasikan menggunakan solusi ini pada banyak pengaturan. Jika Anda menggunakan MySQL... Untuk pengaturan rata-rata, solusi apa pun berfungsi dengan baik.
A: – Pada grafik terakhir dari komunitas, terdapat grafik dengan “Pengurus Rumah Tangga”:
Dia terus bekerja. Apa yang dilakukan Pengurus Rumah Tangga dengan TimescaleDB?
AG: – Sekarang saya tidak bisa memastikannya – Saya akan melihat kodenya dan memberi tahu Anda lebih detail. Ia menggunakan kueri TimescaleDB bukan untuk menghapus potongan, tetapi untuk menggabungkannya. Saya belum siap menjawab pertanyaan teknis ini. Kita akan mengetahui lebih lanjut di stand hari ini atau besok.
A: – Saya memiliki pertanyaan serupa – tentang kinerja operasi penghapusan di Skala Waktu.
A (jawaban dari hadirin): – Saat Anda menghapus data dari tabel, jika Anda melakukannya melalui penghapusan, maka Anda harus menelusuri tabel - hapus, bersihkan, tandai semuanya untuk vakum di masa mendatang. Di Timescale, karena Anda memiliki potongan, Anda dapat menjatuhkannya. Secara kasar, Anda cukup memberi tahu file yang ada di big data: “Hapus!”
Skala waktu hanya memahami bahwa potongan seperti itu sudah tidak ada lagi. Dan karena terintegrasi ke dalam perencana kueri, ia menggunakan kait untuk menangkap kondisi Anda dalam operasi pemilihan atau lainnya dan segera memahami bahwa potongan ini tidak ada lagi - "Saya tidak akan pergi ke sana lagi!" (data tidak tersedia). Itu saja! Artinya, pemindaian tabel digantikan dengan penghapusan file biner, sehingga cepat.
A: – Kami telah menyentuh topik non-SQL. Sejauh yang saya pahami, Zabbix tidak terlalu perlu mengubah data, dan semua ini seperti log. Apakah mungkin untuk menggunakan database khusus yang tidak dapat mengubah datanya, namun pada saat yang sama menyimpan, mengumpulkan, dan mendistribusikan lebih cepat - Clickhouse, misalnya, sesuatu yang mirip Kafka?.. Kafka juga merupakan log! Apakah mungkin untuk mengintegrasikannya?
AG: - Bongkar muat dapat dilakukan. Kami memiliki “fitur” tertentu sejak versi 3.4: Anda dapat menulis semua file historis, peristiwa, dan lainnya ke file; dan kemudian mengirimkannya ke database lain menggunakan beberapa penangan. Faktanya, banyak orang yang mengerjakan ulang dan menulis langsung ke database. Dengan cepat, penyerap sejarah menulis semua ini ke dalam file, memutar file-file ini, dan seterusnya, dan Anda dapat mentransfernya ke Clickhouse. Saya tidak bisa mengatakan tentang rencananya, tapi mungkin dukungan lebih lanjut untuk solusi NoSQL (seperti Clickhouse) akan terus berlanjut.
A: – Secara umum, ternyata postgres bisa dihilangkan sepenuhnya?
AG: – Tentu saja, bagian tersulit di Zabbix adalah tabel sejarah, yang paling banyak menimbulkan masalah, dan peristiwa. Dalam hal ini, jika Anda tidak menyimpan acara untuk waktu yang lama dan menyimpan riwayat dengan tren di beberapa penyimpanan cepat lainnya, maka secara umum, menurut saya, tidak akan ada masalah.
A: – Bisakah Anda memperkirakan seberapa cepat semuanya akan bekerja jika Anda beralih ke Clickhouse, misalnya?
AG: – Saya belum mengujinya. Saya pikir setidaknya angka yang sama dapat dicapai dengan cukup sederhana, mengingat Clickhouse memiliki antarmuka sendiri, tapi saya tidak bisa memastikannya. Lebih baik untuk menguji. Itu semua tergantung pada konfigurasi: berapa banyak host yang Anda miliki, dan seterusnya. Memasukkan adalah satu hal, tetapi Anda juga perlu mengambil data ini - Grafana atau yang lainnya.
A: – Jadi kita berbicara tentang pertarungan yang setara, dan bukan tentang keuntungan besar dari database cepat ini?
AG: – Saya pikir ketika kita berintegrasi, akan ada tes yang lebih akurat.
A: – Kemana perginya RRD lama yang bagus? Apa yang membuat Anda beralih ke database SQL? Awalnya, semua metrik dikumpulkan di RRD.
AG: – Zabbix memiliki RRD, mungkin dalam versi yang sangat kuno. Selalu ada database SQL - pendekatan klasik. Pendekatan klasiknya adalah MySQL, PostgreSQL (sudah ada sejak lama). Kami hampir tidak pernah menggunakan antarmuka umum untuk database SQL dan RRD.
Beberapa iklan 🙂
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com