Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Tha mi a’ moladh gun leugh thu an tar-sgrìobhadh den aithisg deireadh 2019 le Alexander Valyalkin “Go optimizations in VictoriaMetrics”

VictoriaMetrics - DBMS luath agus so-ruigsinneach airson a bhith a’ stòradh agus a’ giullachd dàta ann an cruth sreath ùine (bidh an clàr a’ cruthachadh ùine agus seata de luachan a tha co-chosmhail ris an ùine seo, mar eisimpleir, a gheibhear tro sgrùdadh bho àm gu àm air inbhe luchd-mothachaidh no cruinneachadh de meatrach).

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Seo ceangal dhan bhidio den aithisg seo - https://youtu.be/MZ5P21j_HLE

Sleamhnagan

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Inns dhuinn mu do dheidhinn fhèin. Is mise Alasdair Valyalkin. Seo mo chunntas GitHub. Tha mi dìoghrasach mu Go agus optimization coileanaidh. Sgrìobh mi tòrr leabharlannan feumail agus nach robh cho feumail. Bidh iad a’ tòiseachadh leis an dàrna cuid fast, no le quick ro-leasachan.

Tha mi ag obair air VictoriaMetrics an-dràsta. Dè a th’ ann agus dè tha mi a’ dèanamh an sin? Bruidhnidh mi mu dheidhinn seo san taisbeanadh seo.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Tha geàrr-chunntas na h-aithisg mar a leanas:

  • An toiseach, innsidh mi dhut dè a th’ ann am VictoriaMetrics.
  • An uairsin innsidh mi dhut dè an t-sreath ùine a th’ ann.
  • An uairsin innsidh mi dhut mar a tha stòr-dàta sreath ùine ag obair.
  • An ath rud, innsidh mi dhut mu ailtireachd an stòr-dàta: na tha ann.
  • Agus an uairsin gluaisidh sinn air adhart gu na optimizations a tha aig VictoriaMetrics. Is e seo optimization airson a’ chlàr inverted agus optimization airson buileachadh bitset ann an Go.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

A bheil fios aig duine san luchd-èisteachd dè a th’ ann am VictoriaMetrics? Wow, tha fios aig mòran dhaoine mu thràth. 'S e deagh naidheachd a th' ann. Dhaibhsan aig nach eil fios, is e stòr-dàta sreath ùine a tha seo. Tha e stèidhichte air ailtireachd ClickHouse, air cuid de mhion-fhiosrachadh mu bhuileachadh ClickHouse. Mar eisimpleir, air leithid: MergeTree, àireamhachadh co-shìnte air a h-uile cores pròiseasar a tha rim faighinn agus optimization coileanaidh le bhith ag obair air blocaichean dàta a tha air an cur ann an tasgadan a’ phròiseasar.

Tha VictoriaMetrics a’ toirt seachad teannachadh dàta nas fheàrr na stòran-dàta sreath ùine eile.

Bidh e a ’sgèileadh gu dìreach - is e sin, faodaidh tu barrachd phròiseasan a chuir ris, barrachd RAM air aon choimpiutair. Cleachdaidh VictoriaMetrics na goireasan sin a tha rim faighinn gu soirbheachail agus leasaichidh iad cinneasachd sreathach.

Bidh VictoriaMetrics cuideachd a ’sgèileadh gu còmhnard - is e sin, faodaidh tu nodan a bharrachd a chuir ris a’ bhuidheann VictoriaMetrics, agus àrdaichidh a choileanadh cha mhòr a rèir coltais.

Mar a shaoileadh tu, tha VictoriaMetrics na stòr-dàta luath, oir chan urrainn dhomh feadhainn eile a sgrìobhadh. Agus tha e sgrìobhte ann an Go, agus mar sin tha mi a’ bruidhinn mu dheidhinn aig a’ choinneamh seo.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Cò aig tha fios dè a th’ ann an sreath ùine? Tha e cuideachd eòlach air mòran dhaoine. Is e sreath ùine sreath de chàraidean (timestamp, значение), far a bheil na paidhrichean sin air an rèiteachadh a rèir ùine. Is e an luach àireamh puing-fleòdraidh - fleòdradh64.

Tha gach sreath uair air a chomharrachadh gu sònraichte le iuchair. Dè a tha san iuchair seo? Tha e air a dhèanamh suas de sheata de chàraidean prìomh luach nach eil falamh.

Seo eisimpleir de shreath ùine. Is e prìomh amas an t-sreath seo liosta de chàraidean: __name__="cpu_usage" 's e ainm a' mheatair, instance="my-server" - is e seo an coimpiutair air a bheil an meatrach seo air a chruinneachadh, datacenter="us-east" - is e seo an ionad dàta far a bheil an coimpiutair seo suidhichte.

Chrìochnaich sinn le ainm sreath ùine air a dhèanamh suas de thrì paidhrichean prìomh luach. Tha an iuchair seo a 'freagairt ri liosta de chàraidean (timestamp, value). t1, t3, t3, ..., tN - is iad seo clàran-ama, 10, 20, 12, ..., 15 - na luachan co-fhreagarrach. Is e seo an cpu-chleachdadh aig àm sònraichte airson sreath sònraichte.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Càite an tèid sreath ùine a chleachdadh? A bheil beachd sam bith aig duine?

  • Ann an DevOps, faodaidh tu CPU, RAM, lìonra, rps, àireamh mhearachdan, msaa a thomhas.
  • IoT - is urrainn dhuinn teòthachd, cuideam, geo-chomharran agus rudeigin eile a thomhas.
  • Cuideachd ionmhas - is urrainn dhuinn sùil a chumail air prìsean airson gach seòrsa stoc agus airgead.
  • A bharrachd air an sin, faodar sreath ùine a chleachdadh ann a bhith a’ cumail sùil air pròiseasan toraidh ann am factaraidhean. Tha luchd-cleachdaidh againn a bhios a’ cleachdadh VictoriaMetrics gus sùil a chumail air rothan-gaoithe, airson innealan-fuadain.
  • Tha sreath ùine cuideachd feumail airson fiosrachadh a chruinneachadh bho luchd-mothachaidh diofar innealan. Mar eisimpleir, airson einnsean; airson cuideam taidhrichean a thomhas; airson astar a thomhas, astar; airson a bhith a 'tomhas caitheamh gasoline, msaa.
  • Faodar sreath ùine a chleachdadh cuideachd airson sùil a chumail air itealain. Tha bogsa dubh aig gach itealan a bhios a 'tional sreath ùine airson diofar pharaimearan de shlàinte an itealain. Thathas cuideachd a’ cleachdadh sreath ùine anns a’ ghnìomhachas aerospace.
  • Is e cùram slàinte cuideam fala, cuisle, msaa.

Is dòcha gu bheil barrachd thagraidhean ann a dhìochuimhnich mi, ach tha mi an dòchas gu bheil thu a’ tuigsinn gu bheil sreathan ùine air an cleachdadh gu gnìomhach ann an saoghal an latha an-diugh. Agus tha an àireamh de chleachdadh aca a 'fàs gach bliadhna.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Carson a tha feum agad air stòr-dàta sreath ùine? Carson nach urrainn dhut stòr-dàta dàimh àbhaisteach a chleachdadh gus sreath ùine a stòradh?

Leis gu bheil sreath ùine mar as trice a’ toirt a-steach tòrr fiosrachaidh, a tha duilich a stòradh agus a phròiseasadh ann an stòran-dàta gnàthach. Mar sin, nochd stòran-dàta sònraichte airson sreathan ùine. Bidh na bunaitean sin gu h-èifeachdach a’ stòradh phuingean (timestamp, value) leis an iuchair a chaidh a thoirt seachad. Bidh iad a’ toirt seachad API airson dàta a tha air a stòradh a leughadh le iuchair, le aon phaidhir le luach iuchrach, no le grunn phaidhrichean luach-iuchrach, no le regexp. Mar eisimpleir, tha thu airson an luchd CPU de na seirbheisean agad gu lèir a lorg ann an ionad dàta ann an Ameireagaidh, feumaidh tu an ceist meallta seo a chleachdadh.

Mar as trice bidh stòran-dàta sreath ùine a’ toirt seachad cànanan ceist sònraichte leis nach eil sreath ùine SQL gu math freagarrach. Ged a tha stòran-dàta ann a tha a 'toirt taic do SQL, chan eil e gu math freagarrach. Cànanan ceist mar PromQL, InfluxQL, sruthadh, Q. Tha mi an dòchas gu bheil cuideigin air co-dhiù aon de na cànanan sin a chluinntinn. Is dòcha gu bheil mòran dhaoine air cluinntinn mu PromQL. Is e seo cànan ceist Prometheus.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Seo mar a tha ailtireachd stòr-dàta sreath ùr-nodha coltach a’ cleachdadh VictoriaMetrics mar eisimpleir.

Tha e air a dhèanamh suas de dhà phàirt. Is e seo stòradh airson a’ chlàr inverted agus stòradh airson luachan sreath ùine. Tha na stòran sin air an sgaradh.

Nuair a ruigeas clàr ùr an stòr-dàta, gheibh sinn cothrom air a’ chlàr inverted an-toiseach gus an aithnichear sreath ùine airson seata sònraichte a lorg label=value airson tomhas-tomhais sònraichte. Lorgaidh sinn an aithnichear seo agus sàbhailidh sinn an luach anns a’ bhùth dàta.

Nuair a thig iarrtas airson dàta fhaighinn air ais bho TSDB, thèid sinn an toiseach chun chlàr-amais neo-dhìreach. Gheibh sinn a h-uile càil timeseries_ids clàran a tha a rèir an t-seata seo label=value. Agus an uairsin gheibh sinn a h-uile dàta riatanach bhon taigh-bathair dàta, air a chlàradh le timeseries_ids.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Bheir sinn sùil air eisimpleir air mar a bhios stòr-dàta sreath ùine a’ pròiseasadh ceist taghte a tha a’ tighinn a-steach.

  • An toiseach gheibh i a h-uile dad timeseries_ids bho chlàr-amais neo-dhìreach anns a bheil na paidhrichean a chaidh a thoirt seachad label=value, no a' sàsachadh abairt riaghailteach ainmichte.
  • An uairsin bidh e a 'toirt air ais a h-uile puing dàta bhon stòradh dàta aig àm sònraichte airson an fheadhainn a chaidh a lorg timeseries_ids.
  • Às deidh seo, bidh an stòr-dàta a ’dèanamh cuid de àireamhachadh air na puingean dàta sin, a rèir iarrtas an neach-cleachdaidh. Agus às deidh sin tillidh e am freagairt.

Anns an taisbeanadh seo innsidh mi dhut mun chiad phàirt. Is e lorg a tha seo timeseries_ids le inverted index. Faodaidh tu coimhead air an dàrna pàirt agus an treas pàirt nas fhaide air adhart Stòran VictoriaMetrics, no feitheamh gus an ullaich mi aithisgean eile :)

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Gluaisidh sinn air adhart chun chlàr-amais neo-dhìreach. Is dòcha gu bheil mòran den bheachd gu bheil seo sìmplidh. Cò aig tha fios dè a th’ ann an clàr-amais neo-dhìreach agus mar a tha e ag obair? O, chan eil uimhir de dhaoine ann tuilleadh. Feuchaidh sinn ri tuigsinn dè a th’ ann.

Tha e gu math sìmplidh. Is e dìreach faclair a th’ ann a tha a’ mapadh iuchair gu luach. Dè th' ann an iuchair? A' chàraid seo label=valuecàite label и value - is iad sin loidhnichean. Agus tha na luachan mar sheata timeseries_ids, a tha a’ toirt a-steach a’ chàraid a chaidh a thoirt seachad label=value.

Leigidh clàr-amais inverted leat a h-uile dad a lorg gu sgiobalta timeseries_ids, a thug label=value.

Tha e cuideachd a 'toirt cothrom dhut a lorg gu luath timeseries_ids sreath ùine airson grunn chàraidean label=value, no airson chàraidean label=regexp. Ciamar a tha seo a’ tachairt? Le bhith a 'lorg eadar-ghearradh an t-seata timeseries_ids airson gach paidhir label=value.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Bheir sinn sùil air diofar ghnìomhachadh den chlàr inverted. Feuch an tòisich sinn leis a’ bhuileachadh as sìmplidh naive. Tha i a’ coimhead mar seo.

gnìomh getMetricIDs a 'faighinn liosta de shreathan. Anns gach loidhne tha label=value. Tillidh an gnìomh seo liosta metricIDs.

Ciamar a tha e ag obair? An seo tha caochladair cruinne againn ris an canar invertedIndex. 'S e faclair cunbhalach a tha seo (map), a mhapadh an t-sreang gus ints a ghearradh. Tha an loidhne a’ toirt a-steach label=value.

Cur an gnìomh gnìomh: faigh metricIDs airson a’ chiad label=value, an uairsin thèid sinn tro gach nì eile label=value, gheibh sinn e metricIDs dhaibh. Agus gairm an gnìomh intersectInts, a thèid a dheasbad gu h-ìosal. Agus tha an gnìomh seo a 'tilleadh eadar-ghearradh nan liostaichean sin.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Mar a chì thu, chan eil buileachadh clàr-amais neo-dhìreach gu math toinnte. Ach is e gnìomh naive a tha seo. Dè na h-eas-bhuannachdan a th’ ann? Is e am prìomh ana-cothrom a thaobh buileachadh naive gu bheil clàr-amais mar sin air a stòradh ann an RAM. Às deidh dhuinn an tagradh ath-thòiseachadh bidh sinn a’ call a ’chlàr-amais seo. Chan eil an clàr-amais seo air a shàbhaladh gu diosg. Chan eil e coltach gum bi clàr-amais neo-dhìreach mar seo freagarrach airson stòr-dàta.

Tha an dàrna tarraing air ais cuideachd co-cheangailte ri cuimhne. Feumaidh an clàr-amais neo-dhìreach a bhith a 'freagairt a-steach do RAM. Ma tha e nas àirde na meud RAM, an uairsin gu follaiseach gheibh sinn - mearachd cuimhne. Agus chan obraich am prògram.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Faodar an duilgheadas seo fhuasgladh le bhith a’ cleachdadh fuasglaidhean deiseil leithid ÌreDB, no Creag DB.

Ann an ùine ghoirid, feumaidh sinn stòr-dàta a leigeas leinn trì obrachaidhean a dhèanamh gu sgiobalta.

  • Tha a 'chiad obrachadh - clàradh ключ-значение dhan stòr-dàta seo. Bidh i a’ dèanamh seo gu math luath, càite ключ-значение tha iad nan sreathan neo-riaghailteach.
  • Is e an dàrna gnìomhachd sgrùdadh sgiobalta airson luach a’ cleachdadh iuchair shònraichte.
  • Agus is e an treas gnìomhachd sgrùdadh sgiobalta airson a h-uile luach le ro-leasachan sònraichte.

LevelDB agus RocksDB - chaidh na stòran-dàta sin a leasachadh le Google agus Facebook. Thàinig LevelDB an toiseach. An uairsin ghabh na balaich bho Facebook LevelDB agus thòisich iad ga leasachadh, rinn iad RocksDB. A-nis tha cha mhòr a h-uile stòr-dàta a-staigh ag obair air RocksDB taobh a-staigh Facebook, a’ toirt a-steach an fheadhainn a chaidh a ghluasad gu RocksDB agus MySQL. Thug iad ainm air MyRocks.

Faodar clàr-amais neo-dhìreach a chuir an gnìomh a’ cleachdadh LevelDB. Ciamar a dhèanamh? Bidh sinn a 'sàbhaladh mar iuchair label=value. Agus is e an luach an aithnichear den t-sreath ùine far a bheil am paidhir an làthair label=value.

Ma tha iomadh sreath ùine againn le paidhir sònraichte label=value, an uairsin bidh iomadh sreath san stòr-dàta seo leis an aon iuchair agus eadar-dhealaichte timeseries_ids. Gus liosta fhaighinn de na h-uile timeseries_ids, a thòisicheas le seo label=prefix, bidh sinn a’ dèanamh sgan raon airson a bheil an stòr-dàta seo air a mheudachadh. Is e sin, bidh sinn a’ taghadh a h-uile loidhne a thòisicheas label=prefix agus faigh am feum timeseries_ids.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Seo eisimpleir de bhuileachadh air cò ris a bhiodh e coltach ann an Go. Tha clàr-amais neo-dhìreach againn. Is e seo LevelDB.

Tha an gnìomh an aon rud ri buileachadh naive. Bidh e ag ath-aithris buileachadh naive cha mhòr loidhne air loidhne. Is e an aon phuing a tha sin an àite tionndadh gu map gheibh sinn cothrom air an inverted index. Tha sinn a 'faighinn a h-uile luachan airson a' chiad label=value. An uairsin bidh sinn a 'dol tro na paidhrichean a tha air fhàgail label=value agus faigh na seataichean co-fhreagarrach de metricIDs dhaibh. An uairsin lorg sinn an eadar-ghearradh.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Tha e coltach gu bheil a h-uile dad gu math, ach tha eas-bhuannachdan ann don fhuasgladh seo. Chuir VictoriaMetrics an gnìomh clàr-amais neo-dhìreach stèidhichte air LevelDB. Ach aig a’ cheann thall b’ fheudar dhomh a leigeil seachad.

Carson? Leis gu bheil LevelDB nas slaodaiche na buileachadh naive. Ann am buileachadh naive, le iuchair shònraichte, gheibh sinn air ais an t-sreath gu lèir sa bhad metricIDs. Is e obrachadh gu math luath a tha seo - tha an sliseag gu lèir deiseil airson a chleachdadh.

Ann an LevelDB, a h-uile uair a thèid gnìomh a ghairm GetValues feumaidh tu a dhol tro na loidhnichean gu lèir a thòisicheas le label=value. Agus faigh an luach airson gach loidhne timeseries_ids. De leithid timeseries_ids cruinnich sliseag dhiubh so timeseries_ids. Gu dearbh, tha seo tòrr nas slaodaiche na dìreach faighinn gu mapa cunbhalach le iuchair.

Is e an dàrna tarraing air ais gu bheil LevelDB sgrìobhte ann an C. Chan eil gairm gnìomhan C bho Go glè luath. Bidh e a 'toirt ceudan de nanoseconds. Chan eil seo gu math luath, oir an taca ri gairm gnìomh cunbhalach sgrìobhte a-steach, a bheir 1-5 nanoseconds, tha an eadar-dhealachadh ann an coileanadh deichean de thursan. Dha VictoriaMetrics bha seo na locht marbhtach :)

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Mar sin sgrìobh mi mo bhuileachadh fhèin den chlàr inverted. Agus ghairm e i aonadh.

Tha Mergeset stèidhichte air structar dàta MergeTree. Tha an structar dàta seo air iasad bho ClickHouse. Gu dearbh, bu chòir mergeset a bhith air a bharrrachadh airson sgrùdadh luath timeseries_ids a rèir an iuchair a chaidh a thoirt seachad. Tha Mergeset sgrìobhte gu tur ann an Go. Chì thu Stòran VictoriaMetrics air GitHub. Tha buileachadh mergeset sa phasgan /lib/mergeset. Faodaidh tu feuchainn ri faighinn a-mach dè a tha a’ dol an sin.

Tha an API mergeset glè choltach ri LevelDB agus RocksDB. Is e sin, leigidh e leat clàran ùra a shàbhaladh gu sgiobalta an sin agus clàran a thaghadh gu sgiobalta le ro-leasachan sònraichte.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Bruidhnidh sinn mu na h-eas-bhuannachdan a tha an lùib mergeset nas fhaide air adhart. A-nis bruidhnidh sinn mu na duilgheadasan a dh ’èirich le VictoriaMetrics ann an cinneasachadh nuair a chuir sinn an gnìomh clàr-amais neo-dhìreach.

Carson a dh'èirich iad?

Is e a’ chiad adhbhar an ìre maistreadh àrd. Air eadar-theangachadh gu Ruiseanach, is e atharrachadh tric a tha seo ann an sreath ùine. Seo nuair a thig sreath ùine gu crìch agus sreath ùr a’ tòiseachadh, no nuair a thòisicheas iomadh sreath ùine ùr. Agus tha seo a 'tachairt gu tric.

Is e an dàrna adhbhar an àireamh mhòr de shreath ùine. Aig an toiseach, nuair a bha sgrùdadh a 'fàs mòr-chòrdte, bha an àireamh de shreath ùine beag. Mar eisimpleir, airson gach coimpiutair feumaidh tu sùil a chumail air CPU, cuimhne, lìonra agus luchd diosc. 4 sreath ùine airson a 'choimpiutair. Canaidh sinn gu bheil 100 coimpiutair agad agus 400 sreath ùine. Is e glè bheag a tha seo.

Thar ùine, bha daoine air faighinn a-mach gum b’ urrainn dhaibh barrachd fiosrachaidh gràin-ghràin a thomhas. Mar eisimpleir, tomhais an luchd chan ann bhon phròiseasar gu lèir, ach fa leth bho chridhe gach pròiseasar. Ma tha 40 cores pròiseasar agad, bidh 40 uair a bharrachd de shreath ùine agad airson luchd pròiseasar a thomhas.

Ach chan e sin uile. Faodaidh grunn stàitean a bhith aig gach cridhe pròiseasar, leithid leisg, nuair a tha e leisg. Agus cuideachd ag obair ann an àite luchd-cleachdaidh, ag obair ann an àite kernel agus stàitean eile. Agus faodar gach stàit den leithid a thomhas cuideachd mar shreath ùine air leth. Bidh seo cuideachd a 'meudachadh an àireamh de shreathan le 7-8 tursan.

Bho aon mheatrach fhuair sinn 40 x 8 = 320 metrics airson dìreach aon choimpiutair. Dèan iomadachadh le 100, gheibh sinn 32 an àite 000.

An uairsin thàinig Kubernetes air adhart. Agus dh’ fhàs e na bu mhiosa leis gum faod Kubernetes aoigheachd a thoirt do dh’ iomadh seirbheis eadar-dhealaichte. Tha mòran pods anns gach seirbheis ann an Kubernetes. Agus feumar sùil a chumail air seo uile. A bharrachd air an sin, tha sinn an-còmhnaidh a’ cleachdadh dreachan ùra de na seirbheisean agad. Airson gach dreach ùr, feumar sreath ùine ùr a chruthachadh. Mar thoradh air an sin, tha an àireamh de shreathan ùine a 'fàs gu h-iongantach agus tha sinn a' toirt aghaidh air duilgheadas àireamh mhòr de shreathan ùine, ris an canar àrd-chàrdanachd. Bidh VictoriaMetrics a’ dèiligeadh ris gu soirbheachail an taca ri stòran-dàta sreath ùine eile.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Bheir sinn sùil nas mionaidiche air ìre àrd maistreadh. Dè a tha ag adhbhrachadh ìre àrd maistreadh ann an cinneasachadh? Leis gu bheil cuid de bhrìgh air bileagan is tagaichean an-còmhnaidh ag atharrachadh.

Mar eisimpleir, gabh Kubernetes, aig a bheil a 'bhun-bheachd deployment, i.e. nuair a thèid dreach ùr den tagradh agad a sgaoileadh. Air adhbhar air choireigin, cho-dhùin luchd-leasachaidh Kubernetes an id cleachdadh a chuir ris an leubail.

Dè a dh'adhbhraich seo? A bharrachd air an sin, le gach cleachdadh ùr, thèid stad a chuir air an t-seann shreath ùine, agus an àite sin, bidh sreathan ùine ùr a’ tòiseachadh le luach leubail ùr deployment_id. Faodaidh ceudan de mhìltean agus eadhon milleanan de shreathan mar sin a bhith ann.

Is e an rud cudthromach mu dheidhinn seo uile gu bheil an àireamh iomlan de shreath ùine a 'fàs, ach tha an àireamh de shreathan ùine a tha gnìomhach an-dràsta agus a' faighinn dàta fhathast seasmhach. Canar ìre maistreadh àrd ris an stàit seo.

Is e am prìomh dhuilgheadas a thaobh ìre maistreadh àrd dèanamh cinnteach gu bheil astar sgrùdaidh cunbhalach ann airson a h-uile sreath ùine airson seata sònraichte de bhileagan thar ùine sònraichte. Mar as trice is e seo an ùine airson an uair mu dheireadh no an latha mu dheireadh.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Ciamar a fuasgladh air an duilgheadas seo? Seo a’ chiad roghainn. Tha seo airson an clàr-amais neo-dhìreach a roinn ann am pàirtean neo-eisimeileach thar ùine. Is e sin, beagan ùine seachad, bidh sinn a’ crìochnachadh a bhith ag obair leis a’ chlàr-amais inverted gnàthach. Agus cruthaich clàr-amais neo-dhìreach ùr. Bidh eadar-ama eile a 'dol seachad, bidh sinn a' cruthachadh fear eile agus fear eile.

Agus nuair a nì sinn samplachadh bho na clàran-amais neo-dhìreach sin, lorg sinn seata de chlàran-amais neo-dhìreach a tha taobh a-staigh na h-ùine ainmichte. Agus, a rèir sin, bidh sinn a’ taghadh id an t-sreath ùine às an sin.

Bidh seo a’ sàbhaladh ghoireasan oir chan fheum sinn coimhead air pàirtean nach eil taobh a-staigh na h-ùine ainmichte. Is e sin, mar as trice, ma thaghas sinn dàta airson an uair mu dheireadh, an uairsin airson amannan roimhe sin bidh sinn a’ leum air iarrtasan.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Tha roghainn eile ann airson an duilgheadas seo fhuasgladh. Tha seo airson liosta fa leth a stòradh airson gach latha de shreathan ùine a thachair air an latha sin.

Is e buannachd an fhuasglaidh seo thairis air an fhuasgladh a bh’ ann roimhe nach bi sinn a’ dùblachadh fiosrachadh sreath ùine nach tèid à bith thar ùine. Tha iad an-còmhnaidh an làthair agus chan eil iad ag atharrachadh.

Is e an ana-cothrom gu bheil fuasgladh mar seo nas duilghe a bhuileachadh agus nas duilghe a dheasbad. Agus thagh VictoriaMetrics am fuasgladh seo. Seo mar a thachair e gu h-eachdraidheil. Bidh am fuasgladh seo cuideachd a’ coileanadh gu math an taca ris an fhear roimhe. Leis nach deach am fuasgladh seo a chuir an gnìomh leis gu bheil feum air dàta a dhùblachadh anns gach sgaradh airson sreath ùine nach atharraich, ie nach tèid à bith thar ùine. Bha VictoriaMetrics air a mheudachadh gu sònraichte airson caitheamh àite diosc, agus rinn am buileachadh roimhe seo caitheamh àite diosc nas miosa. Ach tha am buileachadh seo nas freagarraiche airson a bhith a’ lughdachadh caitheamh àite diosc, agus mar sin chaidh a thaghadh.

Bha agam ri sabaid rithe. B 'e an strì gum feum thu fhathast àireamh mòran nas motha a thaghadh anns a' bhuileachadh seo timeseries_ids airson dàta na nuair a tha an clàr-amais inverted air a sgaradh ùine.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Ciamar a fhuair sinn fuasgladh air an duilgheadas seo? Dh’ fhuasgail sinn e ann an dòigh thùsail - le bhith a’ stòradh grunn aithnichearan sreath ùine anns gach inntrigeadh clàr-amais neo-dhìreach an àite aon aithnichear. Is e sin, tha iuchair againn label=value, a tha a 'tachairt anns a h-uile sreath ùine. Agus a-nis tha sinn a shàbhaladh grunn timeseries_ids ann an aon inntrigeadh.

Seo eisimpleir. Roimhe sin bha N inntrigidhean againn, ach a-nis tha aon inntrig againn aig a bheil ro-leasachan an aon rud ris a h-uile gin eile. Airson an inntrig roimhe, tha an luach a’ toirt a-steach ids sreath ùine gu lèir.

Rinn seo e comasach astar sganaidh clàr-amais mar sin àrdachadh suas ri 10 tursan. Agus leig e leinn caitheamh cuimhne a lughdachadh airson an tasgadan, oir a-nis tha sinn a’ stòradh an t-sreang label=value dìreach aon turas san tasgadan còmhla N amannan. Agus faodaidh an loidhne seo a bhith mòr ma tha thu a 'stòradh loidhnichean fada anns na tagaichean agus na bileagan agad, a tha Kubernetes dèidheil air a bhith a' gluasad an sin.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Is e roghainn eile airson rannsachadh a dhèanamh nas luaithe air clàr-amais neo-dhìreach a bhith a 'sgoltadh. A’ cruthachadh grunn chlàran-amais neo-dhìreach an àite aon agus a’ roinneadh dàta eatorra le iuchair. Is e seo seata key=value smùid. Is e sin, gheibh sinn grunn chlàran-amais neo-eisimeileach neo-eisimeileach, as urrainn dhuinn ceasnachadh aig an aon àm air grunn phròiseasan. Cha robh buileachadh roimhe seo a’ ceadachadh obrachadh ach ann am modh aon phròiseasar, ie, a’ sganadh dàta air dìreach aon chridhe. Leigidh am fuasgladh seo leat dàta a sganadh air grunn choraichean aig an aon àm, mar as toil le ClickHouse a dhèanamh. Is e seo a tha sinn an dùil a chuir an gnìomh.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

A-nis tillidh sinn chun na caoraich againn - chun obair eadar-ghearraidh timeseries_ids. Beachdaichidh sinn air dè na gnìomhan a dh'fhaodadh a bhith ann. Leigidh an gnìomh seo leat lorg timeseries_ids airson seata sònraichte label=value.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Is e a’ chiad roghainn buileachadh naive. Dà lùban neadachaidh. An seo gheibh sinn an cuir a-steach gnìomh intersectInts dà phìos - a и b. Aig an toradh, bu chòir dha tilleadh thugainn eadar-ghearradh nan sliseagan sin.

Tha buileachadh naive coltach ri seo. Bidh sinn ag aithris thairis air a h-uile luach bho sliseag a, taobh a-staigh an lùb seo bidh sinn a 'dol tro na luachan sliseag gu lèir b. Agus bidh sinn gan coimeas. Ma tha iad co-ionnan, tha sinn air eadar-ghearradh a lorg. Agus sàbhail a-steach e result.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Dè na h-eas-bhuannachdan a th’ ann? Is e iom-fhillteachd ceithir-cheàrnach am prìomh dhuilgheadas aige. Mar eisimpleir, ma tha na tomhasan agad sliseag a и b millean aig aon àm, an uairsin cha till an gnìomh seo gu bràth freagairt thugad. Leis gum feum e aon trillean ath-aithris a dhèanamh, a tha tòrr eadhon airson coimpiutairean an latha an-diugh.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Tha an dàrna buileachadh stèidhichte air mapa. Bidh sinn a’ cruthachadh mapa. Chuir sinn na luachan uile bho sliseagan a-steach don mhapa seo a. An uairsin bidh sinn a 'dol tro shligean ann an lùb air leth b. Agus nì sinn sgrùdadh a bheil an luach seo bho sliseagan b ann am mapa. Ma tha e ann, cuir ris an toradh e.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Dè na buannachdan a th’ ann? Is e a 'bhuannachd a th' ann nach eil ann ach iom-fhillteachd sreathach. Is e sin, cuiridh an gnìomh an gnìomh mòran nas luaithe airson sliseagan nas motha. Airson sliseag de mhillean-mheud, cuiridh an gnìomh seo an gnìomh ann an 2 mhillean ath-aithris, an taca ris na trillean tionndadh den ghnìomh roimhe.

Is e an ana-cothrom gum feum an gnìomh seo barrachd cuimhne gus am mapa seo a chruthachadh.

Is e an dàrna eas-bhuannachd an àrdachadh mòr airson hashing. Chan eil an eas-bhuannachd seo gu math follaiseach. Agus dhuinne cuideachd cha robh e gu math follaiseach, agus mar sin an toiseach ann an VictoriaMetrics bha buileachadh eadar-ghearradh tro mhapa. Ach an uairsin sheall pròifil gu bheil am prìomh phròiseasar air a chaitheamh a’ sgrìobhadh chun mhapa agus a’ dèanamh cinnteach gu bheil luach air a’ mhapa seo.

Carson a tha ùine CPU air a chaitheamh anns na h-àiteachan sin? Leis gu bheil Go a’ dèanamh gnìomhachd hashing air na loidhnichean sin. Is e sin, bidh e a’ tomhas hash na h-iuchrach gus faighinn thuige aig clàr-amais sònraichte anns an HashMap. Tha an obrachadh àireamhachaidh hash air a chrìochnachadh ann an deichean de nanoseconds. Tha seo slaodach airson VictoriaMetrics.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Cho-dhùin mi bitset a chuir an gnìomh gu sònraichte airson a’ chùis seo. Is e seo cò ris a tha eadar-ghearradh dà shliseag coltach a-nis. An seo bidh sinn a 'cruthachadh bitset. Bidh sinn a 'cur eileamaidean bhon chiad phìos ris. An uairsin nì sinn sgrùdadh air làthaireachd nan eileamaidean sin anns an dàrna slice. Agus cuir iad ris an toradh. Is e sin, cha mhòr nach eil e eadar-dhealaichte bhon eisimpleir roimhe. Is e an aon rud an seo gun do chuir sinn gnìomhan àbhaisteach an àite ruigsinneachd air mapa add и has.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Aig a ’chiad sealladh, tha e coltach gum bu chòir seo obrachadh nas slaodaiche, nam biodh mapa àbhaisteach air a chleachdadh an sin roimhe, agus an uairsin canar cuid de ghnìomhan eile, ach tha pròifil a’ sealltainn gu bheil an rud seo ag obair 10 tursan nas luaithe na am mapa àbhaisteach ann an cùis VictoriaMetrics.

A bharrachd air an sin, bidh e a’ cleachdadh mòran nas lugha de chuimhne an taca ri buileachadh a’ mhapa. Leis gu bheil sinn a’ stòradh pìosan an seo an àite luachan ochd-baidht.

Is e ana-cothrom a’ bhuileachadh seo nach eil e cho follaiseach, gun a bhith beag.

Is e ana-cothrom eile a dh’ fhaodadh nach toir mòran an aire gur dòcha nach obraich am buileachadh seo gu math ann an cuid de chùisean. Is e sin, tha e air a bharrrachadh airson cùis shònraichte, airson a’ chùis seo de eadar-ghearradh de ids sreath ùine VictoriaMetrics. Chan eil seo a 'ciallachadh gu bheil e freagarrach airson a h-uile cùis. Ma thèid a chleachdadh gu ceàrr, chan fhaigh sinn àrdachadh coileanaidh, ach mearachd a-mach à cuimhne agus slaodachadh ann an coileanadh.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Beachdaichidh sinn air buileachadh an structair seo. Ma tha thu airson coimhead, tha e suidhichte anns na stòran VictoriaMetrics, sa phasgan lib/uint64set. Tha e air a bharrrachadh gu sònraichte airson cùis VictoriaMetrics, far a bheil timeseries_id Is e luach 64-bit a th’ ann, far a bheil a’ chiad 32 bit gu bunaiteach seasmhach agus nach eil ach na 32 pìosan mu dheireadh ag atharrachadh.

Chan eil an structar dàta seo air a stòradh air diosc, chan eil e ag obair ach mar chuimhne.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Seo an API aige. Chan eil e gu math toinnte. Tha an API air a dhealbhadh gu sònraichte airson eisimpleir sònraichte de bhith a’ cleachdadh VictoriaMetrics. Is e sin, chan eil gnìomhan neo-riatanach an seo. Seo na gnìomhan a tha gu sònraichte air an cleachdadh le VictoriaMetrics.

Tha gnìomhan ann add, a chuireas luachan ùra ris. Tha gnìomh ann has, a nì sgrùdadh airson luachan ùra. Agus tha gnìomh ann del, a bheir air falbh luachan. Tha gnìomh neach-cuideachaidh ann len, a thilleas meud an t-seata. Gnìomh clone clones gu mòr. Agus gnìomh appendto tionndaidh an seata seo gu sliseag timeseries_ids.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Seo mar a tha buileachadh an structair dàta seo coltach. Tha dà eileamaid aig an t-seata:

  • ItemsCount na raon cuideachaidh gus an àireamh de eileamaidean ann an seata a thilleadh gu sgiobalta. Bhiodh e comasach sin a dhèanamh às aonais an raon taiceil seo, ach dh'fheumadh a bhith air a chur ris an seo oir bidh VictoriaMetrics gu tric a 'ceasnachadh fad bitset anns na h-algorithms aige.

  • Tha an dàrna raon buckets. Is e seo sgaradh bhon structar bucket32. Bidh gach structar a’ stòradh hi achadh. Is iad seo na 32 pìosan as àirde. Agus dà phìos - b16his и buckets bho bucket16 structaran.

Tha na 16 pìosan as àirde den dàrna pàirt den structar 64-bit air an stòradh an seo. Agus an seo tha bitsets air an stòradh airson na pìosan 16 as ìsle de gach byte.

Bucket64 air a dhèanamh suas de shreath uint64. Tha an fhaid air a thomhas a’ cleachdadh nan cunntachail sin. Ann an aon bucket16 faodar an ìre as àirde a stòradh 2^16=65536 beagan. Ma roinneadh tu seo le 8, is e 8 kilobytes a th’ ann. Ma roinneadh tu le 8 a-rithist, is e 1000 a th’ ann uint64 brìgh. S e sin Bucket16 - is e seo an structar 8-kilobyte againn.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Bheir sinn sùil air mar a tha aon de na dòighean anns an structar seo airson luach ùr a chur ris.

Tha e uile a’ tòiseachadh le uint64 brìgh. Bidh sinn ag obrachadh a-mach na 32 pìosan as àirde, bidh sinn a’ tomhas na 32 pìosan as ìsle. Rachamaid tro gach nì buckets. Bidh sinn a’ dèanamh coimeas eadar na 32 pìosan as àirde anns gach bucaid leis an luach ga chur ris. Agus ma tha iad co-ionnan, is e an gnìomh a chanas sinn ris add ann an structar b32 buckets. Agus cuir ris na 32 pìosan as ìsle an sin. Agus ma thill e true, an uairsin tha seo a 'ciallachadh gun do chuir sinn a leithid de luach an sin agus nach robh a leithid de luach againn. Ma thilleas e false, an uairsin bha a leithid de bhrìgh ann mu thràth. An uairsin bidh sinn a 'meudachadh an àireamh de eileamaidean san structar.

Mura h-eil sinn air am fear a tha a dhìth ort a lorg bucket leis an àrd-luach a tha a dhìth, an uairsin canar an gnìomh ris addAlloc, a bheir a mach fear ùr bucket, ga chur ris an structar bucaid.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Is e seo buileachadh na gnìomh b32.add. Tha e coltach ris a’ bhuileachadh roimhe. Bidh sinn ag obrachadh a-mach na 16 pìosan as cudromaiche, na 16 pìosan as cudromaiche.

An uairsin bidh sinn a 'dol tro na 16 pìosan gu h-àrd. Tha sinn a 'lorg maidsean. Agus ma tha maids ann, canaidh sinn an dòigh cuir ris, air am beachdaich sinn air an ath dhuilleig bucket16.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Agus seo an ìre as ìsle, a bu chòir a bhith air a mheudachadh cho mòr 'sa ghabhas. Bidh sinn a 'cunntadh airson uint64 luach id ann am pìos slice agus cuideachd bitmask. Is e seo masg airson luach sònraichte 64-bit, a dh'fhaodar a chleachdadh gus sgrùdadh a dhèanamh air làthaireachd a’ bhìosa seo, no a shuidheachadh. Nì sinn sgrùdadh feuch a bheil am pìos seo air a shuidheachadh agus air a shuidheachadh, agus a’ tilleadh làthaireachd. Is e seo ar buileachadh, a leig leinn gnìomhachd ids eadar-dhealaichte de shreath ùine a luathachadh 10 tursan an taca ri mapaichean àbhaisteach.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

A bharrachd air an optimization seo, tha mòran optimizations eile aig VictoriaMetrics. Chaidh a ’mhòr-chuid de na optimizations sin a chuir ris airson adhbhar, ach às deidh dhaibh cunntas a thoirt air a’ chòd ann an cinneasachadh.

Is e seo am prìomh riaghailt airson optimization - na cuir a-steach optimization a’ gabhail ris gum bi cnap-starra an seo, oir is dòcha gun tionndaidh e a-mach nach bi cnap-starra ann. Mar as trice bidh optimization a ’lughdachadh càileachd a’ chòd. Mar sin, is fhiach a bhith nas fheàrr a-mhàin às deidh pròifil agus ann an cinneasachadh mas fheàrr, gus am bi seo fìor dàta. Ma tha ùidh aig duine sam bith, faodaidh tu coimhead air còd stòr VictoriaMetrics agus sgrùdadh a dhèanamh air optimizations eile a tha ann.

Rach gu optimizations ann an VictoriaMetrics. Alasdair Valyalkin

Tha ceist agam mu dheidhinn bitset. Gu math coltach ri buileachadh bool vector C ++, bitset làn-leasaichte. An tug thu am buileachadh às an sin?

Chan e, chan ann às a sin. Nuair a bhios mi a’ cur an gnìomh am bitset seo, bha mi air mo threòrachadh le eòlas air structar nan amannan ids sin, a thathas a’ cleachdadh ann an VictoriaMetrics. Agus tha an structar aca cho mòr is gu bheil na 32 pìosan àrd gu bunaiteach seasmhach. Faodaidh na pìosan 32 as ìsle atharrachadh. Mar as ìsle am pìos, is ann as trice a dh’ atharraicheas e. Mar sin, tha am buileachadh seo air a bharrrachadh gu sònraichte airson an structair dàta seo. Tha buileachadh C ++, cho fad ‘s as aithne dhomh, air a mheudachadh airson a’ chùis choitcheann. Ma nì thu an fheum as fheàrr airson a ’chùis choitcheann, tha seo a’ ciallachadh nach bi e cho math airson cùis shònraichte.

Tha mi cuideachd a’ toirt comhairle dhut sùil a thoirt air aithisg Alexey Milovid. Mu mhìos air ais, bhruidhinn e mu dheidhinn optimization ann an ClickHouse airson speisealaichean sònraichte. Tha e dìreach ag ràdh, sa chùis choitcheann, gu bheil buileachadh C ++ no buileachadh eile air a dhealbhadh gus obrachadh gu math gu cuibheasach ann an ospadal. Is dòcha gun dèan e nas miosa na buileachadh a tha sònraichte do eòlas mar an fheadhainn againn, far a bheil fios againn gu bheil na 32 pìosan as àirde seasmhach sa mhòr-chuid.

Tha an dàrna ceist agam. Dè an diofar bunaiteach a th’ ann bho InfluxDB?

Tha mòran eadar-dhealachaidhean bunaiteach ann. A thaobh coileanadh agus caitheamh cuimhne, tha InfluxDB ann an deuchainnean a ’sealltainn 10 tursan nas motha de chaitheamh cuimhne airson sreath ùine àrd cardinality, nuair a tha tòrr dhiubh agad, mar eisimpleir, milleanan. Mar eisimpleir, bidh VictoriaMetrics ag ithe 1 GB gach millean sreath gnìomhach, fhad ‘s a bhios InfluxDB ag ithe 10 GB. Agus ’s e diofar mòr a tha sin.

Is e an dàrna eadar-dhealachadh bunaiteach gu bheil cànanan ceist neònach aig InfluxDB - Flux agus InfluxQL. Chan eil iad gu math goireasach airson a bhith ag obair le sreath ùine an taca ri PromQL, a tha a’ faighinn taic bho VictoriaMetrics. Tha PromQL na chànan ceist bho Prometheus.

Agus is e aon eadar-dhealachadh eile gu bheil modal dàta beagan neònach aig InfluxDB, far am faod gach loidhne grunn raointean a stòradh le seata tagaichean eadar-dhealaichte. Tha na sreathan sin air an roinn ann an diofar chlàran. Tha na duilgheadasan a bharrachd seo a’ dèanamh obair nas duilghe leis an stòr-dàta seo às deidh sin. Tha e duilich taic agus tuigse fhaighinn.

Ann an VictoriaMetrics tha a h-uile dad tòrr nas sìmplidh. An sin, tha prìomh luach aig gach sreath uair. Is e an luach seata de phuingean - (timestamp, value), agus is e an iuchair an seata label=value. Chan eil sgaradh eadar raointean agus tomhasan. Leigidh e leat dàta sam bith a thaghadh agus an uairsin cuir ri chèile, cuir ris, thoir air falbh, iomadachadh, roinneadh, eu-coltach ri InfluxDB far nach eil àireamhachadh eadar diofar shreathan fhathast air an cur an gnìomh cho fada ‘s as aithne dhomh. Fiù ma tha iad air an cur an gnìomh, tha e doirbh, feumaidh tu tòrr còd a sgrìobhadh.

Tha ceist soilleireachaidh agam. An robh mi a 'tuigsinn gu ceart gu robh duilgheadas de sheòrsa air choreigin air an do bhruidhinn thu, nach eil an clàr-amais neo-dhìreach seo a' freagairt air cuimhne, agus mar sin tha sgaradh ann?

An toiseach, sheall mi buileachadh naive de chlàr-amais neo-dhìreach air mapa àbhaisteach Go. Chan eil am buileachadh seo freagarrach airson stòran-dàta a chionn 's nach eil an clàr-amais inverted seo air a shàbhaladh gu diosc, agus feumaidh an stòr-dàta a shàbhaladh gu diosc gus am bi an dàta seo ri fhaighinn nuair a thèid ath-thòiseachadh. Anns a’ bhuileachadh seo, nuair a nì thu ath-thòiseachadh air an tagradh, falbhaidh an clàr-amais neo-dhìreach agad. Agus caillidh tu cothrom air an dàta gu lèir oir cha bhith e comasach dhut a lorg.

Halò! Tapadh leibh airson an aithris! 'S e Pavel an t-ainm a th' orm. Tha mi à Wildberries. Tha beagan cheistean agam dhut. Ceist a h-aon. A bheil thu a’ smaoineachadh nan robh thu air prionnsapal eadar-dhealaichte a thaghadh nuair a bha thu a’ togail ailtireachd an tagraidh agad agus a’ roinn an dàta thar ùine, is dòcha gum biodh tu air a bhith comasach air dàta eadar-ghearradh nuair a bha thu a’ rannsachadh, stèidhichte a-mhàin air gu bheil dàta ann an aon sgaradh airson aon ùine, is e sin, ann an aon àm agus cha bhiodh agad ri dragh a ghabhail leis gu bheil na pìosan agad sgapte ann an dòigh eadar-dhealaichte? Ceist àireamh 2 - leis gu bheil thu a ’cur an gnìomh algorithm coltach ris le bitset agus a h-uile càil eile, is dòcha gun do dh’ fheuch thu ri stiùireadh pròiseasar a chleachdadh? Is dòcha gu bheil thu air a leithid de optimizations fheuchainn?

Freagraidh mi an dàrna fear sa bhad. Chan eil sinn air faighinn chun na h-ìre sin fhathast. Ach ma bhios feum air, gheibh sinn ann. Agus a’ chiad fhear, dè a’ cheist a bh’ ann?

Bhruidhinn thu air dà shuidheachadh. Agus thuirt iad gun do thagh iad an dàrna fear le buileachadh nas iom-fhillte. Agus cha b 'fheàrr leotha a' chiad fhear, far a bheil an dàta air a sgaradh le ùine.

Tha. Anns a 'chiad chùis, bhiodh meud iomlan a' chlàr-amais nas motha, oir anns gach sgaradh dh'fheumadh sinn dàta dùblaichte a stòradh airson an t-sreath ùine sin a tha a 'leantainn tro na pàirtean sin uile. Agus ma tha an ìre maistreadh sreath ùine agad beag, ie tha an aon shreath air a chleachdadh gu cunbhalach, an uairsin anns a ’chiad chùis bhiodh sinn a’ call tòrr a bharrachd anns na tha de dh ’àite diosc ann an taca ris an dàrna cùis.

Agus mar sin - tha, tha sgaradh ùine na dheagh roghainn. Bidh Prometheus ga chleachdadh. Ach tha eas-bhuannachd eile aig Prometheus. Nuair a thèid na pìosan dàta sin a chur còmhla, feumaidh e fiosrachadh meta cuimhne a chumail airson a h-uile bileag agus sreath ùine. Mar sin, ma tha na pìosan dàta a bhios e a’ tighinn còmhla mòr, bidh caitheamh cuimhne a’ dol am meud gu mòr aig àm aonachadh, eu-coltach ri VictoriaMetrics. Nuair a thèid iad còmhla, cha bhith VictoriaMetrics ag ithe cuimhne idir; chan eil ach beagan kilobytes air an caitheamh, ge bith dè cho mòr sa tha na pìosan dàta aonaichte.

Bidh an algairim a tha thu a’ cleachdadh a’ cleachdadh cuimhne. Bidh e a’ comharrachadh tagaichean sreath-ama anns a bheil luachan. Agus mar seo nì thu sgrùdadh airson làthaireachd càraideach ann an aon raon dàta agus ann an tè eile. Agus tuigidh tu an do thachair eadar-ghearradh no nach do thachair. Mar as trice, bidh stòran-dàta a’ cur an gnìomh cursors agus iterators a bhios a’ stòradh an t-susbaint a th’ aca an-dràsta agus a’ ruith tron ​​dàta a chaidh a sheòrsachadh air sgàth cho iom-fhillte ‘s a tha na h-obraichean sin.

Carson nach cleachd sinn cursors airson a dhol thairis air dàta?

Tha.

Bidh sinn a’ stòradh sreathan rèitichte ann an LevelDB no mergeset. Is urrainn dhuinn an cursair a ghluasad agus an eadar-ghearradh a lorg. Carson nach cleachd sinn e? A chionn 's gu bheil e slaodach. Leis gu bheil cursors a’ ciallachadh gum feum thu gnìomh a ghairm airson gach loidhne. Is e gairm gnìomh 5 nanoseconds. Agus ma tha 100 loidhne agad, tha e a 'tionndadh a-mach gu bheil sinn a' caitheamh leth diog dìreach a 'gairm a' ghnìomh.

Tha leithid de rud ann, tha. Agus mo cheist mu dheireadh. Is dòcha gu bheil a’ cheist beagan neònach. Carson nach eil e comasach na co-chruinneachaidhean riatanach uile a leughadh aig an àm a ruigeas an dàta agus a shàbhaladh san fhoirm a tha a dhìth? Carson a shàbhaileas tu meudan mòra ann an cuid de shiostaman leithid VictoriaMetrics, ClickHouse, msaa, agus an uairsin caith tòrr ùine orra?

Bheir mi eisimpleir airson a dhèanamh nas soilleire. Canaidh sinn ciamar a tha speedometer dèideag beag ag obair? Bidh e a 'clàradh an astar a shiubhail thu, fad na h-ùine ga chur ri aon luach, agus an dàrna fear - ùine. Agus a 'roinn. Agus a 'faighinn astar cuibheasach. Faodaidh tu a dhèanamh mun aon rud. Cuir ris na fìrinnean riatanach uile air an itealan.

Ceart gu leòr, tha mi a’ tuigsinn a’ cheist. Tha àite aig an eisimpleir agad. Ma tha fios agad dè na co-chruinneachaidhean a tha a dhìth ort, is e seo am buileachadh as fheàrr. Ach is e an duilgheadas a th ’ann gum bi daoine a’ sàbhaladh na meatrach sin, cuid de dhàta ann an ClickHouse agus chan eil fios aca fhathast ciamar a chruinnicheas iad agus a shìoladh iad san àm ri teachd, agus mar sin feumaidh iad an dàta amh gu lèir a shàbhaladh. Ach ma tha fios agad gum feum thu rudeigin obrachadh a-mach gu cuibheasach, carson nach obraich thu a-mach an àite a bhith a’ stòradh dòrlach de luachan amh an sin? Ach chan eil seo ach ma tha fios agad dè dìreach a tha a dhìth ort.

Co-dhiù, tha stòran-dàta airson sreath ùine a stòradh a’ toirt taic do chunntadh cruinneachaidhean. Mar eisimpleir, tha Prometheus a 'toirt taic riaghailtean clàraidh. Is e sin, faodar seo a dhèanamh ma tha fios agad dè na h-aonadan a dh’ fheumas tu. Chan eil seo aig VictoriaMetrics fhathast, ach mar as trice tha Prometheus air thoiseach air, anns am faodar seo a dhèanamh anns na riaghailtean ath-chlàraidh.

Mar eisimpleir, anns an obair a bh 'agam roimhe dh'fheumadh mi an àireamh de thachartasan a chunntadh ann an uinneag sleamhnachaidh thairis air an uair mu dheireadh. Is e an duilgheadas a th’ ann gum feumadh mi buileachadh àbhaisteach a dhèanamh ann an Go, i.e. seirbheis airson an rud seo a chunntadh. Bha an t-seirbheis seo mu dheireadh neo-bheag, oir tha e duilich obrachadh a-mach. Faodaidh buileachadh a bhith sìmplidh ma dh’ fheumas tu cuid de cho-chruinneachaidhean a chunntadh aig amannan stèidhichte. Ma tha thu airson tachartasan a chunntadh ann an uinneag sleamhnachaidh, chan eil e cho sìmplidh sa tha e coltach. Tha mi a’ smaoineachadh nach deach seo a chuir an gnìomh fhathast ann an ClickHouse no ann an stòran-dàta amannan, oir tha e duilich a chuir an gnìomh.

Agus aon cheist eile. Cha robh sinn ach a’ bruidhinn air cuibheasachd, agus chuimhnich mi gu robh a leithid de rud ann uaireigin ri Graphite le backend Carbon. Agus bha fios aige mar a dhèiligeas e seann dàta, is e sin, fàg aon phuing gach mionaid, aon phuing san uair, msaa. bhi air a theannachadh. Ach chan eil Prometheus agus VictoriaMetrics a’ toirt taic don ghnìomhachd seo. A bheil e san amharc taic a thoirt dha? Mura h-eil, carson?

Tapadh leibh airson a' cheist. Bidh ar luchd-cleachdaidh a’ faighneachd na ceist seo bho àm gu àm. Bidh iad a’ faighneachd cuin a chuireas sinn taic ris airson downsampling. Tha grunn dhuilgheadasan an seo. An toiseach, tha gach neach-cleachdaidh a 'tuigsinn downsampling rudeigin eadar-dhealaichte: tha cuideigin ag iarraidh puing neo-riaghailteach sam bith fhaighinn aig àm sònraichte, tha cuideigin ag iarraidh luachan cuibheasach, as àirde, as àirde. Ma sgrìobhas mòran shiostaman dàta chun stòr-dàta agad, chan urrainn dhut a h-uile càil a chuir còmhla. Is dòcha gu bheil feum aig gach siostam air tanachadh eadar-dhealaichte. Agus tha seo duilich a bhuileachadh.

Agus is e an dàrna rud gu bheil VictoriaMetrics, mar ClickHouse, air a bharrrachadh airson a bhith ag obair air tòrr dàta amh, gus an urrainn dha billean loidhne a shluasaid ann an nas lugha na diog ma tha mòran choraichean agad san t-siostam agad. Puingean sreath ùine sganaidh ann an VictoriaMetrics - 50 puingean gach diog gach cridhe. Agus tha an coileanadh seo a’ dol gu coraichean a th’ ann mar-thà. Is e sin, ma tha 000 cores agad, mar eisimpleir, sganaidh tu billean puing gach diog. Agus tha an togalach seo de VictoriaMetrics agus ClickHouse a’ lughdachadh an fheum air downsamling.

Is e feart eile gu bheil VictoriaMetrics gu h-èifeachdach a’ teannachadh an dàta seo. Tha teannachadh cuibheasach ann an cinneasachadh bho 0,4 gu 0,8 bytes gach puing. Tha gach puing na chlàr-ama + luach. Agus tha e air a dhlùthadh ann an nas lugha na aon byte gu cuibheasach.

Sergey. Tha ceist agam. Dè an ìre as lugha de ùine clàraidh?

Aon millisecond. O chionn ghoirid bha còmhradh againn le luchd-leasachaidh stòr-dàta sreath ùine eile. Is e an ùine as lugha aca diog. Agus ann an Graphite, mar eisimpleir, tha e cuideachd aon diog. Ann an OpenTSDB tha e cuideachd aon diog. Tha mionaideachd nanosecond aig InfluxDB. Ann am VictoriaMetrics is e aon mhillean-mhìle-second a th’ ann, oir ann am Prometheus tha e aon mhillean-mhìle-second. Agus chaidh VictoriaMetrics a leasachadh an toiseach mar stòradh iomallach airson Prometheus. Ach a-nis faodaidh e dàta a shàbhaladh bho shiostaman eile.

Tha an neach ris an do bhruidhinn mi ag ràdh gu bheil cruinneas dàrna-gu-diog aca - tha sin gu leòr dhaibh leis gu bheil e an urra ris an t-seòrsa dàta a thathas a’ stòradh san stòr-dàta sreath ùine. Mas e seo dàta DevOps no dàta bho bhun-structar, far am bi thu ga chruinneachadh aig amannan 30 diog, gach mionaid, tha an dàrna cruinneas gu leòr, chan fheum thu dad nas lugha. Agus ma chruinnicheas tu an dàta seo bho shiostaman malairt àrd-tricead, feumaidh tu cruinneas nanosecond.

Tha cruinneas millisecond ann an VictoriaMetrics cuideachd freagarrach airson cùis DevOps, agus faodaidh e a bhith freagarrach airson a ’mhòr-chuid de na cùisean air an tug mi iomradh aig toiseach na h-aithisg. Is e an aon rud a dh ’fhaodadh nach eil e iomchaidh siostaman malairt tricead àrd.

Tapadh leat! Agus ceist eile. Dè a th ’ann an co-chòrdalachd ann am PromQL?

Co-fhreagarrachd iomlan air ais. Tha VictoriaMetrics a’ toirt làn thaic do PromQL. A bharrachd air an sin, bidh e a’ cur comas-gnìomh adhartach a bharrachd ann am PromQL, ris an canar MetricsQL. Tha còmhradh air YouTube mun ghnìomhachd leudaichte seo. Bhruidhinn mi aig a 'Choinneamh Sgrùdaidh as t-earrach ann an St Petersburg.

Sianal teileagram VictoriaMetrics.

Chan fhaod ach luchd-cleachdaidh clàraichte pàirt a ghabhail san sgrùdadh. Soidhnig a-steach, mas e do thoil e.

Dè a tha gad stad bho bhith ag atharrachadh gu VictoriaMetrics mar an stòradh fad-ùine agad airson Prometheus? (Sgrìobh anns na beachdan, cuiridh mi ris a’ bhòt e))

  • 71,4%Cha bhith mi a’ cleachdadh Prometheus5

  • 28,6%Cha robh fios agam mu VictoriaMetrics2

Bhòt 7 neach-cleachdaidh. Sheall 12 neach-cleachdaidh.

Source: www.habr.com

Cuir beachd ann