Ing sawetara taun kepungkur, basis data seri wektu wis owah saka barang aneh (spesialisasi banget digunakake ing sistem ngawasi mbukak (lan disambungake karo solusi tartamtu) utawa ing proyek Big Data) dadi "produk konsumen". Ing tlatah Federasi Rusia, matur nuwun khusus kudu diwenehake marang Yandex lan ClickHouse kanggo iki. Nganti titik iki, yen sampeyan perlu kanggo nyimpen jumlah akeh data-seri wektu, sampeyan uga kudu teka kanggo syarat kanggo mbangun tumpukan Hadoop monstrous lan njaga, utawa komunikasi karo protokol individu kanggo saben sistem.
Kayane ing 2019 artikel babagan TSDB sing kudu digunakake mung kalebu siji ukara: "mung gunakake ClickHouse." Nanging ... ana nuansa.
Pancen, ClickHouse aktif berkembang, basis pangguna saya tambah akeh, lan dhukungan aktif banget, nanging apa kita wis dadi sandera kanggo sukses umum ClickHouse, sing wis ngatasi solusi liyane, mbok menawa luwih efektif / dipercaya?
Ing wiwitan taun kepungkur, kita wiwit ngerjakake maneh sistem ngawasi dhewe, nalika ana pitakonan babagan milih database sing cocog kanggo nyimpen data. Aku pengin ngomong babagan sejarah pilihan iki ing kene.
Formulasi masalah
Kaping pisanan, prakata sing perlu. Napa kita butuh sistem pemantauan dhewe lan kepiye carane dirancang?
Kita wiwit nyedhiyakake layanan dhukungan ing taun 2008, lan ing taun 2010 dadi cetha yen dadi angel kanggo nggabungake data babagan proses sing kedadeyan ing infrastruktur klien kanthi solusi sing ana ing wektu kasebut (kita ngomong babagan, Gusti ngapura aku, Cacti, Zabbix lan grafit sing muncul).
Syarat utama kita yaiku:
- dhukungan (ing wektu kasebut - puluhan, lan ing mangsa ngarep - atusan) klien ing siji sistem lan ing wektu sing padha ana sistem manajemen tandha terpusat;
- keluwesan ngatur sistem tandha (eskalasi tandha antarane petugas tugas, jadwal, basis pengetahuan);
- kemampuan kanggo rinci rinci grafik (Zabbix ing wektu iku render grafik ing wangun gambar);
- panyimpenan long-term saka jumlah gedhe saka data (setaun utawa luwih) lan kemampuan kanggo cepet nompo.
Ing artikel iki kita kasengsem ing titik pungkasan.
Ngomong babagan panyimpenan, syarat kasebut yaiku:
- sistem kudu bisa cepet;
- iku seng di pengeni sing sistem wis antarmuka SQL;
- sistem kudu stabil lan duwe basis pangguna aktif lan dhukungan (nalika kita padha ngadhepi karo perlu kanggo ndhukung sistem kayata MemcacheDB, kang wis ora dikembangaké maneh, utawa panyimpenan disebaraké MooseFS, bug tracker kang disimpen ing Cina: kita mbaleni crita iki kanggo proyek kita ora pengin);
- selaras karo teorema CAP: Consitency (dibutuhake) - data kudu up-to-date, kita ora pengin sistem manajemen tandha ora nampa data anyar lan muntahake tandha babagan data sing ora teka kanggo kabeh proyek; Toleransi Partisi (dibutuhake) - kita ora pengin njaluk sistem Split Brain; Kasedhiyan (ora kritis, yen ana replika aktif) - kita bisa ngalih menyang sistem serep dhewe yen ana kacilakan, nggunakake kode.
Anehe, nalika iku MySQL dadi solusi sing cocog kanggo kita. Struktur data kita prasaja banget: id server, counter id, timestamp lan nilai; sampling cepet data panas iki mesthekake dening blumbang buffer gedhe, lan sampling data sajarah iki menthekake dening SSD.
Mangkono, kita entuk conto data rong minggu sing anyar, kanthi rinci nganti 200 ms kapindho sadurunge data kasebut rampung, lan urip ing sistem iki cukup suwe.
Kangge, wektu liwati lan jumlah data saya tambah. Ing taun 2016, volume data tekan puluhan terabyte, sing dadi biaya sing signifikan ing konteks panyimpenan SSD sing disewa.
Ing wektu iki, database columnar wis aktif nyebar, kang kita wiwit aktif mikir bab: ing database columnar, data disimpen, minangka sampeyan bisa ngerti, ing kolom, lan yen katon ing data kita, iku gampang kanggo ndeleng gedhe. nomer duplikat sing bisa, ing Yen sampeyan nggunakake database columnar, compress nggunakake komprèsi.
Nanging, sistem tombol perusahaan terus bisa stabil, lan aku ora pengin eksprimen karo ngalih menyang mergo.
Ing 2017, ing konferensi Percona Live ing San Jose, pangembang Clickhouse mbokmenawa ngumumake dhewe kanggo pisanan. Sepisanan, sistem kasebut siap produksi (uga, Yandex.Metrica minangka sistem produksi sing atos), dhukungan cepet lan prasaja, lan sing paling penting, operasi kasebut prasaja. Wiwit 2018, kita wis miwiti proses transisi. Nanging ing wektu iku, ana akeh "diwasa" lan sistem TSDB wektu-dites, lan kita mutusaké kanggo nyawisake wektu owahan lan mbandhingaké alternatif kanggo mesthekake yen ora ana solusi alternatif kanggo Clickhouse, miturut syarat kita.
Saliyane syarat panyimpenan sing wis ditemtokake, sing anyar wis katon:
- sistem anyar kudu nyedhiyani paling kinerja padha MySQL ing jumlah padha hardware;
- panyimpenan saka sistem anyar kudu njupuk munggah Ngartekno kurang papan;
- DBMS kudu gampang diatur;
- Aku pengin ngganti aplikasi minimal nalika ngganti DBMS.
Sistem apa sing kita wiwiti nimbang?
Apache Hive/Apache Impala
Tumpukan Hadoop lawas sing wis diuji perang. Intine, iki minangka antarmuka SQL sing dibangun ing ndhuwur kanggo nyimpen data ing format asli ing HDFS.
Pros.
- Kanthi operasi sing stabil, gampang banget kanggo skala data.
- Ana solusi kolom kanggo panyimpenan data (kurang spasi).
- Cepet banget eksekusi tugas paralel nalika sumber daya kasedhiya.
Cons
- Iku Hadoop, lan angel digunakake. Yen kita ora siyap njupuk solusi sing wis siap ing awan (lan kita ora siap babagan biaya), kabeh tumpukan kudu dirakit lan didhukung dening tangan admin, lan kita pancene ora pengin. iki.
- Data dikumpulake .
Nanging:
Kacepetan digayuh kanthi skala jumlah server komputasi. Cukup, yen kita minangka perusahaan gedhe, melu analytics, lan penting kanggo bisnis nglumpukake informasi kanthi cepet (sanajan kanthi biaya nggunakake sumber daya komputasi sing akeh), iki bisa dadi pilihan kita. Nanging kita padha ora siap kanggo Multiply armada hardware kanggo nyepetake tugas.
Druid / Pinot
Ana luwih akeh babagan TSDB khusus, nanging maneh, tumpukan Hadoop.
Ana .
Ing sawetara tembung: Druid / Pinot katon luwih apik tinimbang Clickhouse ing kasus:
- Sampeyan duwe sifat heterogen saka data (ing kasus kita, kita mung ngrekam timeseries saka metrik server, lan, nyatane, iki siji tabel. Nanging bisa uga ana kasus liyane: seri wektu peralatan, seri wektu ekonomi, etc. - saben karo struktur dhewe, sing kudu dikumpulake lan diproses).
- Kajaba iku, ana akeh data iki.
- Tabel lan data kanthi seri wektu katon lan ilang (yaiku, sawetara set data teka, dianalisis lan dibusak).
- Ora ana kritéria sing jelas sing bisa dipérang dadi data.
Ing kasus ngelawan, ClickHouse nindakake luwih apik, lan iki kasus kita.
clickhouse
- kaya SQL
- Gampang kanggo ngatur.
- Wong ngomong iku bisa.
Njaluk shortlisted kanggo testing.
InfluxDB
Alternatif manca kanggo ClickHouse. Saka minus: Kasedhiyan Dhuwur mung ana ing versi komersial, nanging kudu dibandhingake.
Njaluk shortlisted kanggo testing.
Cassandra
Ing tangan siji, kita ngerti yen digunakake kanggo nyimpen timeseries metrik dening sistem ngawasi kayata, contone, utawa OkMeter. Nanging, ana spesifik.
Cassandra ora database columnar ing pangertèn tradisional. Iku katon luwih kaya tampilan baris, nanging saben baris bisa duwe nomer kolom beda, nggawe gampang kanggo ngatur tampilan columnar. Ing pangertèn iki, cetha yen kanthi watesan 2 milyar kolom, bisa nyimpen sawetara data ing kolom (lan seri wektu sing padha). Contone, ing MySQL ana watesan saka 4096 kolom lan iku gampang kanggo kesandhung ing kesalahan karo kode 1117 yen nyoba kanggo nindakake padha.
Mesin Cassandra fokus ing nyimpen jumlah gedhe saka data ing sistem mbagekke tanpa master, lan téorema Cassandra CAP ndhuwur-kasebut luwih babagan AP, sing kasedhiyan data lan resistance kanggo partisi. Mangkono, alat iki bisa dadi apik yen sampeyan mung kudu nulis menyang database iki lan arang maca saka iku. Lan ing kene logis nggunakake Cassandra minangka panyimpenan "kadhemen". Sing, minangka long-term, Panggonan dipercaya kanggo nyimpen jumlah gedhe saka data sajarah sing arang needed, nanging bisa dijupuk yen perlu. Nanging, kanggo jangkep, kita uga bakal nyoba. Nanging, kaya sing dakkandhakake sadurunge, ora ana kepinginan kanggo nulis ulang kode kanthi aktif kanggo solusi database sing dipilih, mula kita bakal nyoba rada winates - tanpa ngganti struktur database menyang spesifik Cassandra.
Prometheus
Ya, amarga penasaran, kita mutusake kanggo nyoba kinerja panyimpenan Prometheus - mung kanggo ngerti apa kita luwih cepet utawa luwih alon tinimbang solusi saiki lan pira.
Metodologi lan asil tes
Dadi, kita nguji database 5 ing konfigurasi 6 ing ngisor iki: ClickHouse (1 simpul), ClickHouse (tabel sing disebarake kanggo 3 node), InfluxDB, Mysql 8, Cassandra (3 node) lan Prometheus. Rencana tes kaya ing ngisor iki:
- upload data historis sajrone seminggu (840 yuta nilai saben dina; 208 ewu metrik);
- kita ngasilake beban rekaman (6 mode beban dianggep, deleng ing ngisor iki);
- Sejajar karo rekaman, kita nggawe pilihan kanthi periodik, niru panjaluk pangguna sing nggarap grafik. Supaya ora rumit banget, kita milih data kanggo 10 metrik (iku persis jumlah sing ana ing grafik CPU) sajrone seminggu.
Kita mbukak kanthi niru prilaku agen pemantauan, sing ngirim nilai menyang saben metrik saben 15 detik. Ing wektu sing padha, kita kasengsem ing macem-macem:
- jumlah total metrik sing data ditulis;
- interval kanggo ngirim nilai menyang siji metrik;
- ukuran batch.
Babagan ukuran batch. Amarga ora dianjurake kanggo ngemot meh kabeh database eksperimen kanthi sisipan siji, kita butuh relay sing nglumpukake metrik sing mlebu lan nglumpukake menyang klompok lan nulis menyang database minangka sisipan batch.
Uga, kanggo luwih ngerti carane banjur napsirake data sing ditampa, ayo bayangake yen kita ora mung ngirim akeh metrik, nanging metrik diatur dadi server - 125 metrics per server. Ing kene server mung minangka entitas virtual - mung kanggo mangerteni manawa, contone, 10000 metrik cocog karo 80 server.
Lan ing kene, njupuk kabeh iki, yaiku 6 mode beban nulis database:
Ana rong titik ing kene. Kaping pisanan, kanggo Cassandra, ukuran batch kasebut dadi gedhe banget, ing kana kita nggunakake nilai 50 utawa 100. Lan kaping pindho, amarga Prometheus dianggo kanthi ketat ing mode tarik, yaiku. iku dhewe dadi lan ngumpulake data saka sumber metrik (lan malah pushgateway, senadyan jeneng, ora dhasar ngganti kahanan), kathah cocog padha dipun ginakaken nggunakake kombinasi configs statis.
Asil tes kaya ing ngisor iki:
Apa sing kudu digatekake: conto Fantastic cepet saka Prometheus, sampel banget alon saka Cassandra, unacceptably alon conto saka InfluxDB; Ing babagan kacepetan rekaman, ClickHouse menang kabeh, lan Prometheus ora melu kompetisi, amarga nggawe sisipan ing awake dhewe lan kita ora ngukur apa-apa.
Ing pungkasan: ClickHouse lan InfluxDB nuduhake awake dhewe dadi sing paling apik, nanging kluster saka Influx mung bisa dibangun ing basis versi Enterprise, sing biaya dhuwit, nalika ClickHouse ora ana biaya lan digawe ing Rusia. Logis yen ing AS, pilihan kasebut bisa uga milih inInfluxDB, lan ing negara kita milih ClickHouse.
Source: www.habr.com