Kuring nyarankeun anjeun maca transkrip laporan ahir 2019 ku Alexander Valyalkin "Go optimizations in VictoriaMetrics"
- DBMS anu gancang sareng scalable pikeun nyimpen sareng ngolah data dina bentuk séri waktos (catetan ngabentuk waktos sareng sakumpulan nilai anu cocog sareng waktos ieu, contona, dicandak ku polling périodik ngeunaan status sensor atanapi koleksi métrik).
Ieu tautan kana pidéo laporan ieu -
Ngabejaan urang ngeunaan diri. Abdi Alexander Valyalkin. Ieuh . Abdi gairah ngeunaan Go sareng optimasi kinerja. Kuring nulis loba perpustakaan mangpaat jeung teu pisan mangpaat. Aranjeunna mimitian ku boh fast, atawa jeung quick awalan.
Abdi nuju damel di VictoriaMetrics. Naon éta sareng naon anu kuring lakukeun di dinya? Kuring bakal ngobrol ngeunaan ieu dina presentasi ieu.
Outline laporan nyaéta kieu:
- Mimiti, kuring bakal nyarioskeun ka anjeun naon VictoriaMetrics.
- Lajeng abdi gé ngabejaan Anjeun naon runtuyan waktu.
- Lajeng abdi gé ngabejaan Anjeun kumaha database runtuyan waktu jalan.
- Salajengna, abdi bakal ngabejaan Anjeun tentang arsitektur database: naon eta diwangun ku.
- Teras hayu urang teraskeun kana optimasi anu dipiboga VictoriaMetrics. Ieu mangrupikeun optimasi pikeun indéks inverted sareng optimasi pikeun palaksanaan bitset di Go.
Naha saha waé anu terang naon VictoriaMetrics? Wah, seueur anu terang. Ieu warta alus. Pikeun anu henteu terang, ieu mangrupikeun database séri waktos. Hal ieu dumasar kana arsitéktur ClickHouse, dina sababaraha rinci ngeunaan palaksanaan ClickHouse. Contona, dina kayaning: MergeTree, itungan paralel dina sagala cores processor sadia tur optimasi kinerja ku gawé dina blok data nu disimpen dina cache processor.
VictoriaMetrics nyayogikeun komprési data anu langkung saé tibatan database séri waktos anu sanés.
Éta skala vertikal - nyaéta, anjeun tiasa nambihan langkung seueur prosesor, langkung seueur RAM dina hiji komputer. VictoriaMetrics bakal suksés ngagunakeun sumber daya anu sayogi ieu sareng bakal ningkatkeun produktivitas linier.
VictoriaMetrics ogé skala sacara horisontal - nyaéta, anjeun tiasa nambihan titik tambahan kana klaster VictoriaMetrics, sareng kinerjana bakal ningkat ampir sacara linier.
Sakumaha anjeun duga, VictoriaMetrics mangrupikeun database gancang, sabab kuring henteu tiasa nyerat anu sanés. Sareng diserat dina Go, janten kuring nyarioskeun éta dina rapat ieu.
Saha anu terang naon séri waktos? Anjeunna ogé terang seueur jalma. Runtuyan waktu nyaéta runtuyan pasangan (timestamp, значение), dimana pasangan ieu diurutkeun dumasar kana waktu. Nilaina mangrupikeun angka floating point - float64.
Unggal runtuyan waktu dicirikeun uniquely ku konci. Naon eusi konci ieu? Ieu diwangun ku set non-kosong tina pasangan konci-nilai.
Ieu conto runtuyan waktu. Konci séri ieu nyaéta daptar pasangan: __name__="cpu_usage" nyaéta ngaran métrik, instance="my-server" - ieu komputer dimana métrik ieu dikumpulkeun, datacenter="us-east" - ieu pusat data dimana komputer ieu lokasina.
Urang réngsé kalawan ngaran runtuyan waktu diwangun ku tilu pasangan konci-nilai. Konci ieu pakait sareng daptar pasangan (timestamp, value). t1, t3, t3, ..., tN - ieu téh cap waktu, 10, 20, 12, ..., 15 - nilai pakait. Ieu mangrupikeun pamakean CPU dina waktos anu ditangtukeun pikeun séri anu dipasihkeun.
Dimana séri waktos tiasa dianggo? Dupi saha gaduh ide?
- Dina DevOps, anjeun tiasa ngukur CPU, RAM, jaringan, rps, jumlah kasalahan, jsb.
- IoT - urang tiasa ngukur suhu, tekanan, koordinat geo sareng anu sanésna.
- Ogé ngabiayaan - urang tiasa ngawas harga pikeun sagala jinis saham sareng mata uang.
- Salaku tambahan, séri waktos tiasa dianggo dina ngawaskeun prosés produksi di pabrik. Kami gaduh pangguna anu nganggo VictoriaMetrics pikeun ngawas turbin angin, pikeun robot.
- Runtuyan waktos ogé kapaké pikeun ngumpulkeun inpormasi tina sénsor tina sababaraha alat. Contona, pikeun mesin; pikeun ngukur tekanan ban; pikeun ngukur laju, jarak; pikeun ngukur konsumsi béngsin, jsb.
- Runtuyan waktos ogé tiasa dianggo pikeun ngawas pesawat. Unggal pesawat boga kotak hideung nu ngumpulkeun runtuyan waktu pikeun sagala rupa parameter kaséhatan pesawat urang. Runtuyan waktu ogé dipaké dina industri aerospace.
- Kaséhatan nyaéta tekanan darah, pulsa, jsb.
Panginten aya seueur aplikasi anu kuring hilap, tapi kuring ngarepkeun anjeun ngartos yén séri waktos aktip dianggo di dunya modéren. Jeung volume pamakéan maranéhanana tumuwuh unggal taun.
Naha anjeun peryogi database séri waktos? Naha anjeun teu tiasa nganggo database relational biasa pikeun nyimpen séri waktos?
Kusabab runtuyan waktu biasana ngandung jumlah badag informasi, nu hese pikeun nyimpen jeung ngolah dina database konvensional. Ku alatan éta, database husus pikeun runtuyan waktu mucunghul. Dasar ieu sacara efektif nyimpen titik (timestamp, value) kalawan konci dibikeun. Aranjeunna nyayogikeun API pikeun maca data anu disimpen ku konci, ku pasangan konci-nilai tunggal, atanapi ku sababaraha pasangan nilai konci, atanapi ku regexp. Salaku conto, anjeun hoyong milarian beban CPU sadaya jasa anjeun dina pusat data di Amérika, teras anjeun kedah nganggo pseudo-query ieu.
Biasana pangkalan data séri waktos nyayogikeun basa pamundut khusus sabab SQL séri waktos henteu cocog pisan. Sanaos aya pangkalan data anu ngadukung SQL, éta henteu cocog pisan. Basa patarosan sapertos , , , . Kuring miharep yén batur geus uninga sahenteuna salah sahiji basa ieu. Loba jalma meureun geus uninga ngeunaan PromQL. Ieu mangrupikeun basa pamundut Prometheus.
Ieu mangrupikeun arsitéktur database séri waktos modern sapertos nganggo VictoriaMetrics salaku conto.
Ieu diwangun ku dua bagian. Ieu gudang keur indéks inverted jeung neundeun nilai runtuyan waktu. Repositories ieu dipisahkeun.
Nalika rékaman anyar sumping dina pangkalan data, urang mimiti ngaksés indéks inverted pikeun milarian identifier séri waktos pikeun set anu dipasihkeun. label=value pikeun métrik dibikeun. Urang manggihan identifier ieu sareng nyimpen nilai dina toko data.
Lamun pamundut datang pikeun meunangkeun data ti TSDB, urang mimiti buka indéks inverted. Hayu urang meunang sagalana timeseries_ids rékaman nu cocog set ieu label=value. Teras kami nampi sadaya data anu diperyogikeun tina gudang data, diindeks ku timeseries_ids.
Hayu urang tingali conto kumaha database séri waktos ngolah pamundut pilih anu asup.
- Mimitina manéhna meunang sagalana
timeseries_idsti indéks inverted nu ngandung pasangan dibikeunlabel=value, atawa nyugemakeun ekspresi biasa nu dibikeun. - Lajeng retrieves sakabeh titik data ti gudang data dina interval waktu nu tangtu pikeun leuwih kapanggih
timeseries_ids. - Saatos ieu, pangkalan data ngalakukeun sababaraha itungan dina titik data ieu, dumasar kana pamundut pangguna. Sarta sanggeus éta mulih jawaban.
Dina presentasi ieu kuring bakal ngabejaan Anjeun tentang bagian kahiji. Ieu pilarian timeseries_ids ku indéks inverted. Anjeun tiasa nonton ngeunaan bagian kadua jeung bagian katilu engké , atanapi antosan dugi ka kuring nyiapkeun laporan anu sanés :)
Hayu urang ngaléngkah ka indéks inverted. Seueur anu panginten ieu saderhana. Saha anu terang naon indéks inverted sareng kumaha jalanna? Oh, teu jadi loba jalma deui. Hayu urang coba ngartos naon éta.
Ieu sabenerna basajan. Éta ngan saukur kamus anu peta konci pikeun nilai. Naon konci? pasangan ieu label=valuedimana label и value - ieu garis. Sareng nilaina mangrupikeun set timeseries_ids, nu ngawengku pasangan dibikeun label=value.
Inverted indéks ngidinan Anjeun pikeun gancang manggihan sagalana timeseries_ids, nu geus dibikeun label=value.
Ogé ngidinan Anjeun pikeun gancang manggihan timeseries_ids runtuyan waktu pikeun sababaraha pasang label=value, atawa pikeun pasangan label=regexp. Kumaha ieu kajadian? Ku manggihan simpang set timeseries_ids pikeun unggal pasangan label=value.
Hayu urang nempo rupa-rupa palaksanaan tina indéks inverted. Hayu urang mimitian ku palaksanaan naif pangbasajanna. Manehna siga kieu.
fungsi getMetricIDs meunang daptar string. Unggal baris ngandung label=value. Pungsi ieu mulih daptar metricIDs.
Kumaha gawéna? Di dieu urang boga variabel global disebut invertedIndex. Ieu kamus biasa (map), anu bakal peta senar pikeun nyiksikan ints. garis ngandung label=value.
palaksanaan fungsi: meunang metricIDs pikeun kahiji label=value, lajeng urang ngaliwatan sagalana sejenna label=value, urang meunang eta metricIDs keur maranehna. Jeung nelepon fungsi intersectInts, anu bakal dibahas di handap. Jeung fungsi ieu mulih simpang daptar ieu.
Sakumaha anjeun tiasa tingali, ngalaksanakeun hiji indéks inverted teu pisan pajeulit. Tapi ieu palaksanaan naif. Naon kakuranganana? Karugian utama palaksanaan naif nyaéta yén indéks inverted sapertos disimpen dina RAM. Saatos restarting aplikasi urang leungit indéks ieu. Teu aya nyimpen indéks ieu kana disk. Indéks anu terbalik sapertos kitu sigana henteu cocog pikeun pangkalan data.
The aral kadua ogé patali jeung memori. Indéks inverted kedah pas kana RAM. Lamun ngaleuwihan ukuran RAM, mangka écés urang bakal meunang - kaluar tina kasalahan memori. Sareng programna moal jalan.
Masalah ieu tiasa direngsekeun nganggo solusi anu siap-siap sapertos atawa .
Pondokna, urang peryogi database anu ngamungkinkeun urang pikeun ngalakukeun tilu operasi gancang.
- Operasi munggaran nyaéta ngarékam
ключ-значениеkana database ieu. Manehna ngalakukeun ieu pisan gancang, dimanaключ-значениеari sawenang-wenang. - Operasi kadua mangrupa pilarian rusuh pikeun nilai ngagunakeun konci dibikeun.
- Sareng operasi katilu nyaéta milarian gancang pikeun sadaya nilai ku awalan anu dipasihkeun.
LevelDB sareng RocksDB - pangkalan data ieu dikembangkeun ku Google sareng Facebook. Mimiti sumping LevelDB. Lajeng guys ti Facebook nyandak LevelDB tur mimitian ngaronjatkeun eta, aranjeunna dijieun RocksDB. Ayeuna ampir sadaya basis data internal dianggo dina RocksDB di jero Facebook, kalebet anu parantos dialihkeun ka RocksDB sareng MySQL. Aranjeunna ngaranna anjeunna .
Indéks inverted tiasa dilaksanakeun nganggo LevelDB. Kumaha cara ngalakukeunana? Urang nyimpen salaku konci label=value. Sareng nilaina mangrupikeun identifier tina séri waktos dimana pasangan éta hadir label=value.
Upami urang gaduh seueur séri waktos sareng pasangan anu dipasihkeun label=value, teras bakal aya seueur barisan dina database ieu sareng konci anu sami sareng béda timeseries_ids. Pikeun meunangkeun daptar sadaya timeseries_ids, nu dimimitian ku ieu label=prefix, urang ngalakukeun scan rentang nu database ieu dioptimalkeun. Nyaéta, urang milih sadaya garis anu dimimitian ku label=prefix jeung meunang nu diperlukeun timeseries_ids.
Ieu conto palaksanaan kumaha éta bakal katingali dina Go. Simkuring gaduh indéks inverted. Ieu LevelDB.
Fungsina sami sareng pikeun palaksanaan naif. Ieu repeats palaksanaan naif ampir baris ku garis. Hijina titik éta tinimbang ngahurungkeun ka map urang ngakses indéks inverted. Kami nampi sadaya nilai pikeun anu munggaran label=value. Teras we ngaliwat sadaya pasangan sésana label=value sareng kéngingkeun set metricIDs anu cocog pikeun aranjeunna. Lajeng urang manggihan simpang.
Sagalana sigana rupa, tapi aya drawbacks kana solusi ieu. VictoriaMetrics mimitina ngalaksanakeun indéks inverted dumasar kana LevelDB. Tapi tungtungna kuring kudu nyerah.
Naha? Kusabab LevelDB langkung laun tibatan palaksanaan naif. Dina palaksanaan naif, dibéré konci dibikeun, urang geuwat nimba sakabéh nyiksikan metricIDs. Ieu mangrupikeun operasi anu gancang pisan - sadaya potongan siap dianggo.
Dina LevelDB, unggal waktos fungsi disebut GetValues Anjeun kudu ngaliwatan sagala garis nu dimimitian ku label=value. Sareng kéngingkeun nilai pikeun unggal garis timeseries_ids. Sapertos kitu timeseries_ids kumpulkeun nyiksikan ieu timeseries_ids. Jelas, ieu langkung laun tibatan ngan ukur ngaksés peta biasa ku konci.
Kelemahan kadua nyaéta LevelDB ditulis dina C. Nyauran fungsi C tina Go henteu gancang pisan. Butuh ratusan nanodetik. Ieu teu pisan gancang, sabab dibandingkeun jeung panggero fungsi biasa ditulis dina lebet, nu nyokot 1-5 nanoseconds, bédana dina kinerja puluhan kali. Pikeun VictoriaMetrics ieu cacad fatal :)
Ku kituna kuring wrote palaksanaan sorangan tina indéks inverted. Sarta anjeunna disebut dirina .
Mergeset dumasar kana struktur data MergeTree. Struktur data ieu diinjeum ti ClickHouse. Jelas, mergeset kedah dioptimalkeun pikeun milarian gancang timeseries_ids nurutkeun konci dibikeun. Mergeset ditulis sagemblengna dina Go. Anjeun tiasa ningali . Palaksanaan mergeset aya dina polder . Anjeun tiasa nyobian ngartos naon anu lumangsung di dinya.
The mergeset API pisan sarupa LevelDB na RocksDB. Hartina, ngamungkinkeun anjeun gancang nyimpen rékaman anyar di dinya sareng gancang milih rékaman ku awalan anu dipasihkeun.
Urang bakal ngobrol ngeunaan kalemahan mergeset engké. Ayeuna hayu urang ngobrol ngeunaan naon masalah anu timbul dina produksi VictoriaMetrics nalika nerapkeun indéks inverted.
Naha maranéhna timbul?
Alesan kahiji nyaéta laju churn tinggi. Ditarjamahkeun kana basa Rusia, ieu mangrupikeun parobahan anu sering dina séri waktos. Ieu nalika séri waktos réngsé sareng séri énggal dimimitian, atanapi seueur séri waktos énggal dimimitian. Sareng ieu sering kajantenan.
Alesan kadua nyaéta jumlah badag runtuyan waktu. Dina awalna, nalika ngawaskeun popularitasnya, jumlah séri waktos sakedik. Salaku conto, pikeun unggal komputer anjeun kedah ngawas CPU, mémori, jaringan sareng beban disk. 4 séri waktos per komputer. Anggap anjeun gaduh 100 komputer sareng 400 séri waktos. Ieu saeutik pisan.
Kana waktu, jalma ilahar kaluar yén maranéhna bisa ngukur informasi leuwih granular. Contona, ngukur beban teu sakabéh processor, tapi misah unggal core processor. Upami Anjeun gaduh 40 cores processor, mangka anjeun boga 40 kali leuwih runtuyan waktu pikeun ngukur beban processor.
Tapi éta henteu sadayana. Unggal inti prosesor tiasa gaduh sababaraha kaayaan, sapertos dianggurkeun, nalika dianggurkeun. Sareng ogé damel di rohangan pangguna, damel di rohangan kernel sareng nagara-nagara sanés. Sareng unggal kaayaan sapertos kitu ogé tiasa diukur salaku séri waktos anu misah. Ieu ogé nambahan jumlah barisan ku 7-8 kali.
Tina hiji métrik kami ngagaduhan 40 x 8 = 320 métrik pikeun ngan hiji komputer. Kalikeun ku 100, urang meunang 32 tinimbang 000.
Lajeng Kubernetes sumping sapanjang. Sareng parah sabab Kubernetes tiasa janten host seueur jasa anu béda. Unggal layanan dina Kubernetes diwangun ku loba pods. Sareng sadaya ieu kedah diawaskeun. Salaku tambahan, kami gaduh panyebaran konstan tina versi anyar jasa anjeun. Pikeun unggal vérsi énggal, séri waktos énggal kedah didamel. Hasilna, jumlah runtuyan waktu tumuwuh éksponénsial sarta kami Nyanghareupan masalah angka nu gede ngarupakeun runtuyan waktu, nu disebut tinggi-cardinality. VictoriaMetrics parantos suksés dibandingkeun sareng database séri waktos anu sanés.
Hayu urang nempo leuwih deukeut laju churn tinggi. Naon anu nyababkeun tingkat churn anu luhur dina produksi? Kusabab sababaraha hartos labél sareng tag terus robih.
Contona, nyandak Kubernetes, nu boga konsep deployment, nyaéta nalika versi anyar aplikasi anjeun digulung. Kanggo sababaraha alesan, pamekar Kubernetes mutuskeun pikeun nambihan id penyebaran kana labél.
Naon ieu ngakibatkeun? Sumawona, sareng unggal panyebaran énggal, sadaya séri waktos lami diganggu, sareng tibatan éta, séri waktos énggal dimimitian ku nilai labél énggal. deployment_id. Aya tiasa ratusan rébu malah jutaan baris sapertos.
Hal penting ngeunaan sakabéh ieu nyaéta jumlah total runtuyan waktu tumuwuh, tapi jumlah runtuyan waktu nu ayeuna aktip sarta narima data tetep konstan. kaayaan ieu disebut laju churn tinggi.
Masalah utama laju churn anu luhur nyaéta pikeun mastikeun laju milarian konstan pikeun sadaya séri waktos pikeun set labél anu dipasihkeun dina interval waktos anu tangtu. Biasana ieu mangrupikeun interval waktos kanggo jam terakhir atanapi dinten terakhir.
Kumaha carana ngajawab masalah ieu? Ieu pilihan kahiji. Ieu pikeun ngabagi indéks inverted kana bagian bebas kana waktu. Nyaéta, sababaraha interval waktos pas, urang réngsé damel sareng indéks inverted ayeuna. Jeung nyieun indéks inverted anyar. interval waktu sejen pas, urang nyieun sejen tur sejen.
Sareng nalika sampling tina indéks inverted ieu, urang mendakan sakumpulan indéks inverted anu aya dina interval anu ditangtukeun. Sareng, sasuai, urang milih id tina séri waktos ti dinya.
Ieu ngaheéat sumberdaya sabab urang teu kudu kasampak di bagian nu teu digolongkeun dina interval dibikeun. Nyaéta, biasana, upami urang milih data kanggo sajam terakhir, teras pikeun interval waktos sateuacana urang ngalangkungan pamundut.
Aya pilihan séjén pikeun ngajawab masalah ieu. Ieu pikeun nyimpen pikeun unggal dinten daptar misah tina id runtuyan waktu anu lumangsung dina poé éta.
Kauntungannana leyuran ieu leuwih solusi saméméhna nyaéta yén urang teu duplikat informasi runtuyan waktu nu teu leungit ngaliwatan waktu. Aranjeunna terus hadir tur teu robah.
Karugianna nyaéta solusi sapertos kitu langkung hese dilaksanakeun sareng langkung hese pikeun debug. Sareng VictoriaMetrics milih solusi ieu. Ieu kumaha kajadian sajarahna. Solusi ieu ogé ngalaksanakeun saé dibandingkeun sareng anu sateuacana. Kusabab solusi ieu teu dilaksanakeun alatan kanyataan yén éta téh perlu duplikat data dina unggal partisi pikeun runtuyan waktu nu teu robah, i.e. nu teu ngaleungit kana waktu. VictoriaMetrics ieu utamana dioptimalkeun pikeun konsumsi spasi disk, sarta palaksanaan saméméhna ngajadikeun konsumsi spasi disk goréng. Tapi palaksanaan ieu langkung cocog pikeun ngaminimalkeun konsumsi rohangan disk, janten dipilih.
Kuring kungsi ngalawan manehna. Perjuangan éta yén dina palaksanaan ieu anjeun masih kedah milih jumlah anu langkung ageung timeseries_ids pikeun data ti nalika indéks inverted waktos partitioned.
Kumaha urang ngajawab masalah ieu? Urang ngajawab eta dina cara aslina - ku nyimpen sababaraha identifiers runtuyan waktu dina unggal éntri indéks inverted tinimbang hiji identifier. Hartina, urang boga konci label=value, nu lumangsung dina unggal runtuyan waktu. Tur ayeuna urang simpen sababaraha timeseries_ids dina hiji entri.
Ieu conto. Saméméhna urang ngagaduhan N éntri, tapi ayeuna urang gaduh hiji éntri anu awalanna sami sareng sadayana anu sanés. Pikeun éntri saméméhna, nilai ngandung sakabéh id runtuyan waktu.
Ieu ngamungkinkeun pikeun ningkatkeun laju scanning indéks inverted misalna nepi ka 10 kali. Sarta eta diwenangkeun urang ngurangan konsumsi memori pikeun cache, sabab ayeuna urang nyimpen string label=value ngan sakali dina cache babarengan N kali. Sareng garis ieu tiasa ageung upami anjeun nyimpen garis panjang dina tag sareng labél anjeun, anu ku Kubernetes resep nyorong di dinya.
Pilihan séjén pikeun nyepetkeun milarian dina indéks inverted nyaéta sharding. Nyieun sababaraha indéks inverted tinimbang hiji jeung sharding data antara aranjeunna ku konci. Ieu susunan key=value uap. Hartina, urang meunang sababaraha indéks inverted bebas, nu urang bisa query paralel dina sababaraha prosesor. Palaksanaan saméméhna ngan ukur ngamungkinkeun operasi dina modeu prosesor tunggal, nyaéta, nyeken data dina ngan hiji inti. Leyuran ieu ngidinan Anjeun pikeun nyeken data dina sababaraha cores sakaligus, sakumaha ClickHouse diaku ngalakukeun. Ieu naon urang rencanana pikeun nerapkeun.
Ayeuna hayu urang uih deui ka domba urang - kana fungsi simpang timeseries_ids. Hayu urang nganggap naon palaksanaan meureun aya. Pungsi ieu ngidinan Anjeun pikeun manggihan timeseries_ids pikeun set dibikeun label=value.
Pilihan kahiji nyaéta palaksanaan naif. Dua puteran bersarang. Di dieu urang meunang input fungsi intersectInts dua potong - a и b. Dina kaluaran, sakuduna balik deui ka kami simpang keureut ieu.
A palaksanaan naif Sigana mah ieu. Urang iterate leuwih sakabéh nilai tina irisan a, di jero loop ieu urang ngaliwat sadaya nilai slice b. Sarta kami ngabandingkeun aranjeunna. Upami aranjeunna cocog, maka kami parantos mendakan simpang. Sareng simpen dina result.
Naon kalemahanana? Pajeulitna kuadrat nyaéta kalemahan utama. Contona, upami diménsi anjeun nyiksikan a и b hiji juta dina hiji waktu, lajeng fungsi ieu moal balik jawaban ka anjeun. Sabab bakal perlu nyieun hiji triliun iterasi, nu loba komo pikeun komputer modern.
Palaksanaan kadua dumasar kana peta. Urang nyieun peta. Kami nempatkeun sadaya nilai tina potongan kana peta ieu a. Teras we ngaliwatan nyiksikan dina loop misah b. Sarta kami pariksa naha nilai ieu ti keureutan b dina peta. Upami aya, teras tambahkeun kana hasilna.
Naon mangpaatna? Kauntungannana nyaeta ngan aya pajeulitna linier. Hartina, fungsina bakal ngaéksekusi langkung gancang pikeun irisan anu langkung ageung. Pikeun potongan sajuta ukuran, fungsi ieu bakal dijalankeun dina 2 juta iterasi, sabalikna tina triliun iterasi fungsi saméméhna.
downside nyaeta fungsi ieu merlukeun leuwih memori pikeun nyieun peta ieu.
Kelemahan kadua nyaéta overhead ageung pikeun hashing. aral ieu teu pisan atra. Sareng pikeun urang éta ogé henteu écés pisan, janten mimitina di VictoriaMetrics palaksanaan simpang ngalangkungan peta. Tapi lajeng Profil némbongkeun yén waktu processor utama spent nulis kana peta tur mariksa ayana nilai dina peta ieu.
Naha waktos CPU dibuang di tempat-tempat ieu? Kusabab Go ngalakukeun operasi hashing dina garis ieu. Nyaéta, éta ngitung hash konci supados teras ngaksés éta dina indéks anu dipasihkeun dina HashMap. Operasi itungan hash réngsé dina puluhan nanodetik. Ieu slow pikeun VictoriaMetrics.
Kuring mutuskeun pikeun nerapkeun bitset dioptimalkeun husus pikeun hal ieu. Ieu naon simpang dua keureut ayeuna kasampak kawas. Di dieu urang nyieun bitset a. Urang nambahkeun elemen ti keureut munggaran ka dinya. Teras we pariksa ayana elemen ieu dina keureutan kadua. Sareng tambahkeun kana hasilna. Hartina, méh teu béda jeung conto saméméhna. Hiji-hijina hal di dieu nyaeta urang ngaganti aksés ka peta ku fungsi custom add и has.
Dina glance kahiji, sigana nu ieu kedah dianggo laun, lamun saméméhna dipaké peta baku, lajeng sababaraha pungsi séjén disebut, tapi profil nunjukeun yen hal ieu jalan 10 kali leuwih gancang ti peta baku dina kasus VictoriaMetrics.
Sajaba ti éta, ngagunakeun memori teuing kirang dibandingkeun palaksanaan peta. Kusabab urang nyimpen bit di dieu tinimbang nilai dalapan bait.
The disadvantage palaksanaan ieu téh nya éta teu jadi atra, teu trivial.
Kelemahan anu sanés anu seueur anu henteu perhatikeun nyaéta palaksanaan ieu tiasa henteu tiasa dianggo dina sababaraha kasus. Hartina, éta dioptimalkeun pikeun pasualan husus, pikeun hal ieu simpang id runtuyan waktu VictoriaMetrics. Ieu henteu hartosna yén éta cocog pikeun sagala kasus. Lamun dipaké teu bener, urang moal meunang kanaékan kinerja, tapi hiji kaluar kasalahan memori sarta slowdown dina kinerja.
Hayu urang nganggap palaksanaan struktur ieu. Upami anjeun hoyong ningali, lokasina di sumber VictoriaMetrics, dina folder . Éta dioptimalkeun khusus pikeun kasus VictoriaMetrics, dimana timeseries_id mangrupakeun nilai 64-bit, dimana 32 bit kahiji dasarna konstan sarta ngan robah 32 bit panungtungan.
Struktur data ieu henteu disimpen dina disk, éta ngan ukur dianggo dina mémori.
Ieu API na. Teu pajeulit pisan. API ieu tailored husus ka conto husus tina ngagunakeun VictoriaMetrics. Hartina, teu aya fungsi anu teu dipikabutuh di dieu. Ieu mangrupikeun fungsi anu sacara eksplisit dianggo ku VictoriaMetrics.
Aya fungsi add, nu nambahkeun nilai anyar. Aya fungsi has, nu mariksa nilai anyar. Sareng aya fungsi del, anu ngaleungitkeun nilai. Aya fungsi nulungan len, nu mulih ukuran set. Fungsi clone klon pisan. Jeung fungsi appendto ngarobah set ieu keur nyiksikan timeseries_ids.
Ieu naon palaksanaan struktur data ieu Sigana mah. set ngabogaan dua elemen:
-
ItemsCountmangrupakeun widang helper pikeun gancang balik jumlah elemen dina susunan. Ieu bakal mungkin mun ngalakukeun tanpa widang bantu ieu, tapi kudu ditambahkeun dieu sabab VictoriaMetrics mindeng queries panjang bitset dina algoritma na. -
Widang kadua nyaéta
buckets. Ieu potongan tina strukturbucket32. Unggal struktur nyimpenhisawah. Ieu mangrupikeun 32 bit luhur. Jeung dua keureut -b16hisиbucketstibucket16struktur.
16 bit luhur bagian kadua tina struktur 64-bit disimpen di dieu. Sarta di dieu bitsets disimpen pikeun handap 16 bit unggal bait.
Bucket64 diwangun ku hiji Asép Sunandar Sunarya uint64. Panjangna diitung ngagunakeun konstanta ieu. Dina hiji bucket16 maksimum bisa disimpen 2^16=65536 bit. Upami anjeun ngabagi ieu ku 8, éta mangrupikeun 8 kilobyte. Lamun dibagi 8 deui, éta 1000 uint64 hartina. nyaeta Bucket16 - ieu struktur 8-kilobyte urang.
Hayu urang tingali kumaha salah sahiji metodeu struktur ieu pikeun nambahkeun nilai anyar dilaksanakeun.
Eta sadayana dimimitian ku uint64 hartina. Urang ngitung 32 bit luhur, urang ngitung 32 bit handap. Hayu urang ngaliwatan sagalana buckets. Urang ngabandingkeun luhureun 32 bit dina unggal LIPI jeung nilai ditambahkeun. Tur upami aranjeunna cocog, lajeng urang nelepon fungsi add dina struktur b32 buckets. Jeung tambahkeun handap 32 bit dinya. Tur upami eta balik true, lajeng ieu ngandung harti yén urang ditambahkeun nilai misalna aya na urang teu boga nilai misalna hiji. Lamun balik false, mangka harti kitu geus aya. Teras we nambahan jumlah elemen dina struktur.
Upami urang teu acan mendakan anu anjeun peryogikeun bucket kalawan hi-nilai diperlukeun, lajeng urang nelepon fungsi addAlloc, nu bakal ngahasilkeun nu anyar bucket, nambahkeun kana struktur LIPI.
Ieu palaksanaan fungsi b32.add. Éta sami sareng palaksanaan sateuacana. Urang ngitung paling signifikan 16 bit, sahenteuna signifikan 16 bit.
Teras we ngaliwat sadaya 16 bit luhur. Urang manggihan patandingan. Tur upami aya hiji patandingan, urang nelepon metoda nambahkeun, nu urang bakal mertimbangkeun dina kaca hareup pikeun bucket16.
Sareng ieu mangrupikeun tingkat panghandapna, anu kedah dioptimalkeun saloba mungkin. Urang ngitung keur uint64 nilai id dina nyiksikan bit sarta ogé bitmask. Ieu topeng pikeun nilai 64-bit dibikeun, nu bisa dipaké pikeun pariksa ayana bit ieu, atawa nyetel eta. Urang pariksa ningali lamun bit ieu diatur tur nyetel eta, sarta balik ayana. Ieu mangrupikeun palaksanaan kami, anu ngamungkinkeun urang nyepetkeun operasi intersecting id tina séri waktos ku 10 kali dibandingkeun sareng peta konvensional.
Salian optimasi ieu, VictoriaMetrics boga loba optimizations séjén. Kalolobaan optimizations ieu ditambahkeun pikeun alesan, tapi sanggeus profil kode dina produksi.
Ieu aturan utama optimasi - ulah nambahkeun optimasi asumsina bakal aya bottleneck di dieu, sabab bisa ngahurungkeun kaluar aya moal bottleneck dinya. Optimasi biasana nurunkeun kualitas kode. Ku alatan éta, sia optimizing ngan sanggeus profil na preferably dina produksi, ku kituna ieu data nyata. Upami aya anu kabetot, anjeun tiasa ningali kode sumber VictoriaMetrics sareng ngajalajah optimasi sanés anu aya.
Abdi gaduh patarosan ngeunaan bitset. Sarupa pisan jeung palaksanaan bool vektor C ++, bitset dioptimalkeun. Naha anjeun nyandak palaksanaan ti dinya?
Henteu, sanés ti dinya. Nalika ngalaksanakeun bitset ieu, kuring dipandu ku pangaweruh ngeunaan struktur timeseries ids ieu, anu dianggo dina VictoriaMetrics. Jeung struktur maranéhanana nyaéta saperti nu luhur 32 bit dasarna konstan. The 32 bit handap bisa dirobah. Nu handap bit, beuki sering eta bisa robah. Ku alatan éta, palaksanaan ieu husus dioptimalkeun pikeun struktur data ieu. Palaksanaan C ++, sajauh kuring terang, dioptimalkeun pikeun kasus umum. Upami anjeun ngaoptimalkeun pikeun kasus umum, ieu hartosna éta moal janten anu paling optimal pikeun kasus khusus.
Kuring ogé mamatahan anjeun ningali laporan Alexey Milovid. Ngeunaan sabulan katukang, anjeunna dikaitkeun optimasi di ClickHouse pikeun specializations husus. Anjeunna ngan ukur nyarios yén dina kasus umum, palaksanaan C ++ atanapi sababaraha palaksanaan sanésna disaluyukeun pikeun dianggo rata-rata di rumah sakit. Éta tiasa langkung parah tibatan palaksanaan khusus pangaweruh sapertos urang, dimana urang terang yén 32 bit anu paling luhur biasana konstan.
Abdi gaduh patarosan kadua. Naon bédana dasar tina InfluxDB?
Aya seueur bédana dasar. Dina watesan kinerja sarta konsumsi memori, InfluxDB dina tés nembongkeun 10 kali leuwih konsumsi memori pikeun cardinality tinggi runtuyan waktu, mun anjeun boga loba di antarana, Contona, jutaan. Contona, VictoriaMetrics meakeun 1 GB per juta baris aktip, bari InfluxDB meakeun 10 GB. Sareng éta bédana ageung.
Beda dasar kadua nyaéta InfluxDB gaduh basa query aneh - Flux sareng InfluxQL. Aranjeunna teu pisan merenah pikeun gawé bareng time series dibandingkeun , anu dirojong ku VictoriaMetrics. PromQL mangrupikeun basa pamundut ti Prometheus.
Sareng hiji deui bédana nyaéta InfluxDB gaduh modél data anu rada anéh, dimana unggal baris tiasa nyimpen sababaraha widang kalayan set tag anu béda. garis ieu salajengna dibagi kana rupa tabel. Komplikasi tambahan ieu ngahesekeun padamelan saterasna sareng pangkalan data ieu. Hese ngadukung sareng ngartos.
Dina VictoriaMetrics sadayana langkung saderhana. Di dinya, unggal séri waktos mangrupikeun nilai konci. Nilaina mangrupikeun sakumpulan titik- (timestamp, value), sareng koncina nyaéta set label=value. Henteu aya pamisahan antara widang sareng pangukuran. Eta ngidinan Anjeun pikeun milih data nu mana wae nu lajeng ngagabungkeun, nambahkeun, ngurangan, kalikeun, ngabagi, kawas InfluxDB dimana itungan antara baris béda masih teu dilaksanakeun sajauh kuring nyaho. Malah lamun aranjeunna dilaksanakeun, hese, anjeun kudu nulis loba kode.
Kuring boga patarosan clarifying. Naha kuring ngartos leres yén aya sababaraha masalah anu anjeun nyarioskeun, yén indéks inverted ieu henteu pas kana mémori, janten aya partisi?
Mimiti, kuring nunjukkeun palaksanaan naif tina indéks inverted dina peta Go standar. Palaksanaan ieu teu cocog pikeun basis data sabab indéks inverted ieu teu disimpen kana disk, sarta database kudu nyimpen kana disk ambéh data ieu tetep sadia sanggeus restart. Dina palaksanaan ieu, nalika anjeun ngabalikan deui aplikasi, indéks inverted anjeun bakal ngaleungit. Sareng anjeun bakal leungit aksés ka sadaya data sabab anjeun moal tiasa mendakanana.
Halo! Hatur nuhun laporan! Ngaran abdi Pavel. Abdi ti Wildberries. Kuring boga sababaraha patarosan pikeun anjeun. Patarosan hiji. Naha anjeun nyangka yén upami anjeun milih prinsip anu béda nalika ngawangun arsitéktur aplikasi anjeun sareng ngabagi data kana waktosna, maka panginten anjeun bakal tiasa motong data nalika milarian, ngan ukur dumasar kana kanyataan yén hiji partisi ngandung data pikeun hiji période waktos, nyaéta, dina hiji interval waktos sareng anjeun henteu kedah hariwang ngeunaan kanyataan yén potongan anjeun sumebar sacara béda? Patarosan nomer 2 - saprak anjeun ngalaksanakeun algoritma anu sami sareng bitset sareng anu sanés, teras panginten anjeun nyobian nganggo paréntah prosesor? Meureun anjeun geus diusahakeun optimizations misalna?
Kuring bakal ngajawab anu kadua langsung. Kami henteu acan dugi ka titik éta. Tapi lamun perlu, urang bakal ka dinya. Sareng anu kahiji, naon patarosanana?
Anjeun ngabahas dua skenario. Sareng aranjeunna nyarios yén aranjeunna milih anu kadua kalayan palaksanaan anu langkung kompleks. Sareng aranjeunna henteu resep anu pangheulana, dimana datana dibagi ku waktos.
Sumuhun. Dina kasus nu pertama, total volume indéks bakal leuwih badag, sabab dina unggal partisi urang kudu nyimpen duplikat data pikeun maranéhanana runtuyan waktu nu terus ngaliwatan sakabéh partisi ieu. Sareng upami laju churn séri waktos anjeun leutik, nyaéta séri anu sami terus dianggo, maka dina kasus anu kahiji urang bakal kaleungitan langkung seueur dina jumlah rohangan disk anu dijajah dibandingkeun sareng kasus kadua.
Janten - leres, ngabagi waktos mangrupikeun pilihan anu saé. Prometheus ngagunakeun éta. Tapi Prometheus boga aral sejen. Nalika ngahijikeun potongan data ieu, éta kedah nyimpen inpormasi meta mémori pikeun sadaya labél sareng séri waktos. Ku alatan éta, lamun potongan data nu merges badag, konsumsi memori naek pisan salila merging, teu kawas VictoriaMetrics. Nalika ngahiji, VictoriaMetrics henteu nganggo mémori sadayana; ngan ukur sababaraha kilobyte anu dikonsumsi, henteu paduli ukuran potongan data anu dihijikeun.
Algoritma anu anjeun anggo nganggo mémori. Éta nandaan tag timeseries anu ngandung nilai. Sareng ku cara ieu anjeun mariksa ayana dipasangkeun dina hiji susunan data sareng anu sanés. Sareng anjeun ngartos naha intersect lumangsung atanapi henteu. Biasana, basis data nerapkeun kursor sareng iterator anu nyimpen eusina ayeuna sareng ngajalankeun data anu diurutkeun kusabab pajeulitna operasi ieu.
Naha urang henteu nganggo kursor pikeun ngaliwat data?
Sumuhun.
Urang nyimpen baris diurutkeun dina LevelDB atanapi mergeset. Urang bisa mindahkeun kursor jeung manggihan simpang. Naha urang henteu nganggo éta? Sabab lalaunan. Kusabab kursor ngandung harti yén anjeun kudu nelepon hiji fungsi pikeun tiap garis. Sauran fungsi nyaéta 5 nanodetik. Tur upami Anjeun salah boga 100 garis, tétéla yén urang méakkeun satengah detik ngan nelepon fungsi.
Aya kitu, enya. Jeung patarosan panungtungan kuring. Patarosanna sigana rada anéh. Naha teu mungkin maca sadaya agrégat anu diperyogikeun dina waktos data sumping sareng simpen dina bentuk anu diperyogikeun? Naha ngahemat jilid ageung dina sababaraha sistem sapertos VictoriaMetrics, ClickHouse, sareng sajabana, teras nyéépkeun waktosna?
Abdi badé masihan conto supados langkung jelas. Hayu urang nyebutkeun kumaha spedometer kaulinan leutik jalan? Éta ngarékam jarak anu anjeun angkat, sadaya waktos nambihan kana hiji nilai, sareng anu kadua kalina. Jeung ngabagi. Jeung meunang laju rata. Anjeun tiasa ngalakukeun ngeunaan hal anu sarua. Tambahkeun up sagala fakta diperlukeun dina laleur nu.
Oké, abdi ngartos patarosan. Conto anjeun ngagaduhan tempatna. Upami anjeun terang naon agrégat anu anjeun peryogikeun, maka ieu mangrupikeun palaksanaan anu pangsaéna. Tapi masalahna nyaeta jalma ngahemat metrics ieu, sababaraha data dina ClickHouse sarta aranjeunna henteu acan terang kumaha maranéhna bakal agrégat sarta nyaring aranjeunna dina mangsa nu bakal datang, ngarah kudu nyimpen sakabéh data atah. Tapi upami anjeun terang yén anjeun kedah ngitung rata-rata, naha henteu ngitung éta tibatan nyimpen sakumpulan nilai atah di dinya? Tapi ieu ngan upami anjeun terang naon anu anjeun peryogikeun.
Ku jalan kitu, basis data pikeun nyimpen runtuyan waktu ngarojong cacah aggregates. Contona, Prometheus ngarojong . Nyaéta, ieu tiasa dilakukeun upami anjeun terang unit naon anu anjeun peryogikeun. VictoriaMetrics teu acan gaduh ieu, tapi biasana dimimitian ku Prometheus, dimana ieu tiasa dilakukeun dina aturan recoding.
Contona, dina pakasaban saméméhna kuring diperlukeun keur ngitung jumlah acara dina jandela ngageser leuwih jam panungtungan. Masalahna nyaeta kuring kungsi nyieun palaksanaan custom di Go, nyaéta layanan pikeun cacah hal ieu. jasa ieu pamustunganana non-trivial, sabab hese ngitung. Palaksanaan tiasa saderhana upami anjeun kedah ngitung sababaraha agrégat dina interval waktos anu tetep. Upami anjeun hoyong ngitung acara dina jandela ngageser, maka éta henteu saderhana sigana. Jigana ieu teu acan dilaksanakeun di ClickHouse atanapi di timeseries database, sabab hese dilaksanakeun.
Sareng hiji deui patarosan. Kami ngan ukur ngobrol ngeunaan rata-rata, sareng kuring émut yén sakali aya anu sapertos Graphite sareng backend Carbon. Sarta anjeunna terang kumaha ipis kaluar data heubeul, nyaeta, ninggalkeun hiji titik per menit, hiji titik per jam, jsb Sacara prinsip, ieu téh rada merenah lamun urang butuh data atah, rélatif diomongkeun, salila sabulan, sarta sagalana sejenna bisa. ditipiskeun. Tapi Prometheus sareng VictoriaMetrics henteu ngadukung fungsi ieu. Naha rencanana pikeun ngadukung éta? Lamun henteu, naha henteu?
Hatur nuhun kana patarosan. Pamaké kami naroskeun patarosan ieu sacara périodik. Aranjeunna naroskeun nalika kami bakal nambihan dukungan pikeun downsampling. Aya sababaraha masalah di dieu. Anu mimiti, unggal pangguna ngartos downsampling hal béda: batur hayang meunang sagala titik sawenang dina interval tinangtu, batur hayang maksimum, minimum, nilai rata. Upami seueur sistem nyerat data kana pangkalan data anjeun, maka anjeun moal tiasa ngahijikeun sadayana. Bisa jadi unggal sistem merlukeun thinning béda. Sareng ieu sesah dilaksanakeun.
Sareng anu kadua nyaéta yén VictoriaMetrics, sapertos ClickHouse, dioptimalkeun pikeun damel sareng volume data atah anu ageung, ku kituna tiasa nyéépkeun samilyar garis dina waktos kirang ti sadetik upami anjeun gaduh seueur inti dina sistem anjeun. Nyeken titik runtuyan waktu di VictoriaMetrics - 50 titik per detik per inti. Jeung kinerja ieu skala kana cores aya. Nyaéta, upami anjeun gaduh 000 inti, contona, anjeun bakal nyeken samilyar poin per detik. Jeung sipat ieu VictoriaMetrics na ClickHouse ngurangan kabutuhan downsamling.
Fitur anu sanésna nyaéta VictoriaMetrics sacara efektif ngompres data ieu. Komprési rata-rata dina produksi nyaéta ti 0,4 dugi ka 0,8 bait per titik. Unggal titik mangrupakeun timestamp + nilai. Sarta eta dikomprés kana kirang ti hiji bait rata-rata.
Sergey. Abdi gaduh patarosan. Naon kuantum waktos rékaman minimum?
Hiji milidetik. Kami nembe ngobrol sareng pamekar database séri waktos sanés. Nyiksikan waktos minimum maranéhanana nyaéta sadetik. Sareng dina grafit, contona, éta ogé sadetik. Dina OpenTSDB ogé sadetik. InfluxDB gaduh akurasi nanodetik. Dina VictoriaMetrics éta hiji milidetik, sabab dina Prometheus éta hiji milidetik. Sareng VictoriaMetrics mimitina dikembangkeun salaku panyimpenan jauh pikeun Prometheus. Tapi ayeuna éta tiasa nyimpen data tina sistem anu sanés.
Jalma anu kuring nyarios nyarios yén aranjeunna gaduh akurasi kadua-ka-detik - éta cekap pikeun aranjeunna sabab gumantung kana jinis data anu disimpen dina database séri waktos. Upami ieu mangrupikeun data DevOps atanapi data tina infrastruktur, dimana anjeun ngumpulkeun éta dina interval 30 detik, per menit, maka akurasi kadua cekap, anjeun henteu peryogi anu kirang. Sareng upami anjeun ngumpulkeun data ieu tina sistem perdagangan frekuensi tinggi, maka anjeun peryogi akurasi nanosecond.
Akurasi Millisecond di VictoriaMetrics ogé cocog pikeun kasus DevOps, sareng tiasa cocog pikeun kalolobaan kasus anu kuring nyarios dina awal laporan. Hiji-hijina hal anu henteu cocog nyaéta sistem perdagangan frekuensi tinggi.
Hatur nuhun! Sareng patarosan sanésna. Naon kasaluyuan dina PromQL?
kasaluyuan ka tukang pinuh. VictoriaMetrics ngarojong pinuh PromQL. Salaku tambahan, éta nambihan fungsionalitas canggih tambahan dina PromQL, anu disebut . Aya ceramah dina YouTube ngeunaan fungsionalitas nambahan ieu. Kuring spoke di Monitoring Meetup di cinyusu di St.
Saluran telegram .
Ngan pamaké nu kadaptar bisa ilubiung dina survey. , Punten.
Naon anu nyegah anjeun ngalih ka VictoriaMetrics salaku panyimpenan jangka panjang anjeun pikeun Prometheus? (Tulis dina komentar, kuring bakal nambahan kana polling))
-
71,4%Abdi henteu nganggo Prometheus5
-
28,6%Henteu terang ngeunaan VictoriaMetrics2
7 pamaké milih. 12 pamaké abstained.
sumber: www.habr.com