Dros yr ychydig flynyddoedd diwethaf, mae cronfeydd data cyfres amser wedi troi o fod yn beth anarferol (a ddefnyddir yn hynod arbenigol naill ai mewn systemau monitro agored (ac yn gysylltiedig ag atebion penodol) neu mewn prosiectau Data Mawr) yn “gynnyrch defnyddwyr”. Ar diriogaeth Ffederasiwn Rwsia, rhaid diolch yn arbennig i Yandex a ClickHouse. Hyd at y pwynt hwn, pe bai angen i chi storio llawer iawn o ddata cyfres amser, roedd yn rhaid i chi naill ai ddod i delerau â'r angen i adeiladu pentwr Hadoop gwrthun a'i gynnal, neu gyfathrebu â phrotocolau unigol ar gyfer pob system.
Gall ymddangos yn 2019 y bydd erthygl am ba TSDB yn werth ei defnyddio yn cynnwys un frawddeg yn unig: “defnyddiwch ClickHouse.” Ond... mae yna arlliwiau.
Yn wir, mae ClickHouse wrthi’n datblygu, mae’r sylfaen defnyddwyr yn tyfu, ac mae’r gefnogaeth yn weithgar iawn, ond a ydym wedi dod yn wystlon i lwyddiant cyhoeddus ClickHouse, sydd wedi cysgodi atebion eraill, efallai’n fwy effeithiol/dibynadwy?
Ar ddechrau'r flwyddyn ddiwethaf, fe ddechreuon ni ail-weithio ein system fonitro ein hunain, ac yn ystod y cyfnod hwnnw cododd y cwestiwn o ddewis cronfa ddata addas ar gyfer storio data. Rwyf am siarad am hanes y dewis hwn yma.
Datganiad o'r broblem
Yn gyntaf oll, rhagymadrodd angenrheidiol. Pam fod angen ein system fonitro ein hunain o gwbl a sut y cafodd ei dylunio?
Dechreuon ni ddarparu gwasanaethau cymorth yn 2008, ac erbyn 2010 daeth yn amlwg ei bod hi'n anodd agregu data am y prosesau sy'n digwydd yn y seilwaith cleientiaid gyda'r atebion a oedd yn bodoli bryd hynny (rydym yn siarad am, Duw maddau i mi, Cacti, Zabbix a'r Graffit sy'n dod i'r amlwg).
Ein prif ofynion oedd:
- cefnogaeth (ar y pryd - dwsinau, ac yn y dyfodol - cannoedd) o gleientiaid o fewn un system ac ar yr un pryd presenoldeb system rheoli rhybuddio ganolog;
- hyblygrwydd wrth reoli'r system rybuddio (uwchgyfeirio rhybuddion rhwng swyddogion ar ddyletswydd, amserlennu, sylfaen wybodaeth);
- y gallu i fanylu'n ddwfn ar graffiau (graffiau wedi'u rendro gan Zabbix ar y pryd ar ffurf lluniau);
- storio llawer iawn o ddata yn y tymor hir (blwyddyn neu fwy) a'r gallu i'w adfer yn gyflym.
Yn yr erthygl hon mae gennym ddiddordeb yn y pwynt olaf.
Wrth siarad am storio, roedd y gofynion fel a ganlyn:
- rhaid i'r system weithio'n gyflym;
- mae'n ddymunol bod gan y system ryngwyneb SQL;
- rhaid i'r system fod yn sefydlog a bod â sylfaen defnyddwyr gweithredol a chefnogaeth (unwaith yr oeddem yn wynebu'r angen i gefnogi systemau fel MemcacheDB, nad oedd wedi'i datblygu mwyach, neu storfa ddosbarthedig MooseFS, y cadwyd y traciwr namau yn Tsieineaidd: rydym yn ailadrodd y stori hon am nad oedd ein prosiect yn dymuno);
- cydymffurfio â theorem y PAC: Cysondeb (gofynnol) - rhaid i'r data fod yn gyfredol, nid ydym am i'r system rheoli rhybuddion beidio â derbyn data newydd a phoeri rhybuddion am ddiffyg data ar gyfer pob prosiect; Goddefgarwch Rhaniad (gofynnol) - nid ydym am gael system Brain Hollti; Argaeledd (ddim yn hanfodol, os oes replica gweithredol) - gallwn newid i'r system wrth gefn ein hunain os bydd damwain, gan ddefnyddio cod.
Yn rhyfedd ddigon, bryd hynny daeth MySQL allan i fod yr ateb delfrydol i ni. Roedd ein strwythur data yn hynod o syml: id gweinydd, id cownter, stamp amser a gwerth; sicrhawyd samplu cyflym o ddata poeth gan gronfa glustogi fawr, a sicrhawyd samplo data hanesyddol gan SSD.
Felly, cawsom sampl o ddata pythefnos ffres, gyda manylion i lawr i eiliad 200 ms cyn i'r data gael ei rendro'n llwyr, a buom yn byw yn y system hon am amser eithaf hir.
Yn y cyfamser, aeth amser heibio a thyfodd swm y data. Erbyn 2016, cyrhaeddodd cyfeintiau data ddegau o terabytes, a oedd yn draul sylweddol yng nghyd-destun storio SSD ar rent.
Erbyn hyn, roedd cronfeydd data colofnol wedi dod yn eang, y dechreuon ni feddwl yn weithredol amdanynt: mewn cronfeydd data colofnol, mae data'n cael ei storio, fel y gallwch chi ei ddeall, mewn colofnau, ac os edrychwch ar ein data, mae'n hawdd gweld nifer fawr. nifer y dyblygiadau a allai, yn Os ydych yn defnyddio cronfa ddata golofnog, cywasgu'r gan ddefnyddio cywasgu.
Fodd bynnag, parhaodd system allweddol y cwmni i weithio'n sefydlog, a doeddwn i ddim eisiau arbrofi gyda newid i rywbeth arall.
Yn 2017, yng nghynhadledd Percona Live yn San Jose, mae'n debyg y cyhoeddodd datblygwyr Clickhouse eu hunain am y tro cyntaf. Ar yr olwg gyntaf, roedd y system yn barod ar gyfer cynhyrchu (wel, mae Yandex.Metrica yn system gynhyrchu llym), roedd y gefnogaeth yn gyflym ac yn syml, ac, yn bwysicaf oll, roedd y llawdriniaeth yn syml. Ers 2018, rydym wedi dechrau’r broses bontio. Ond erbyn hynny, roedd llawer o systemau TSDB “oedolyn” a phrawf amser, a phenderfynwyd neilltuo cryn dipyn o amser a chymharu dewisiadau eraill er mwyn sicrhau nad oedd unrhyw atebion amgen i Clickhouse, yn unol â'n gofynion.
Yn ogystal â'r gofynion storio a nodwyd eisoes, mae rhai newydd wedi ymddangos:
- dylai'r system newydd ddarparu o leiaf yr un perfformiad â MySQL ar yr un faint o galedwedd;
- dylai storio'r system newydd gymryd llawer llai o le;
- Rhaid i'r DBMS fod yn hawdd i'w reoli o hyd;
- Roeddwn i eisiau newid y cais cyn lleied â phosibl wrth newid y DBMS.
Pa systemau y dechreuon ni eu hystyried?
Apache Hive/Apache Impala
Hen gorn Hadoop wedi'i brofi gan frwydr. Yn y bôn, rhyngwyneb SQL ydyw wedi'i adeiladu ar ben storio data mewn fformatau brodorol ar HDFS.
Manteision.
- Gyda gweithrediad sefydlog, mae'n hawdd iawn graddio data.
- Mae yna atebion colofn ar gyfer storio data (llai o le).
- Cyflawni tasgau cyfochrog yn gyflym iawn pan fydd adnoddau ar gael.
Anfanteision.
- Hadoop ydyw, ac mae'n anodd ei ddefnyddio. Os nad ydym yn barod i gymryd datrysiad parod yn y cwmwl (ac nid ydym yn barod o ran cost), bydd yn rhaid i'r pentwr cyfan gael ei gydosod a'i gefnogi gan ddwylo gweinyddwyr, ac nid ydym wir eisiau hwn.
- Mae data'n cael ei agregu .
Fodd bynnag:
Cyflawnir cyflymder trwy raddio nifer y gweinyddwyr cyfrifiadurol. Yn syml, os ydym yn gwmni mawr, sy'n ymwneud â dadansoddeg, a'i bod yn hanfodol i'r busnes agregu gwybodaeth cyn gynted â phosibl (hyd yn oed ar gost defnyddio llawer iawn o adnoddau cyfrifiadurol), efallai mai dyma ein dewis ni. Ond nid oeddem yn barod i luosi'r fflyd caledwedd i gyflymu tasgau.
Derwydd / Pinot
Mae llawer mwy am TSDB yn benodol, ond eto, stac Hadoop.
Mae .
Mewn ychydig eiriau: mae Druid/Pinot yn edrych yn well na Clickhouse mewn achosion lle:
- Mae gennych chi natur heterogenaidd o ddata (yn ein hachos ni, rydym yn cofnodi cyfresi amser o fetrigau gweinydd yn unig, ac, mewn gwirionedd, un tabl yw hwn. Ond efallai y bydd achosion eraill: cyfres amser offer, cyfres amser economaidd, ac ati - pob un â ei strwythur ei hun, y mae angen ei agregu a'i brosesu).
- Ar ben hynny, mae llawer o'r data hwn.
- Mae tablau a data gyda chyfresi amser yn ymddangos ac yn diflannu (hynny yw, cyrhaeddodd rhai set o ddata, ei ddadansoddi a'i ddileu).
- Nid oes unrhyw faen prawf clir ar gyfer rhannu data.
Mewn achosion cyferbyniol, mae ClickHouse yn perfformio'n well, a dyma ein hachos ni.
CliciwchHouse
- tebyg i SQL
- Hawdd i'w reoli.
- Mae pobl yn dweud ei fod yn gweithio.
Cyrraedd y rhestr fer ar gyfer profi.
MewnlifDB
Dewis arall tramor yn lle ClickHouse. O'r anfanteision: Dim ond yn y fersiwn fasnachol y mae Argaeledd Uchel yn bresennol, ond mae angen ei gymharu.
Cyrraedd y rhestr fer ar gyfer profi.
Cassandra
Ar y naill law, gwyddom ei fod yn cael ei ddefnyddio i storio amserlenni metrig gan systemau monitro fel, er enghraifft, neu OkMeter. Fodd bynnag, mae yna fanylion penodol.
Nid cronfa ddata golofnog yn yr ystyr draddodiadol mo Cassandra. Mae'n edrych yn debycach i olygfa rhes, ond gall pob llinell gael nifer wahanol o golofnau, gan ei gwneud hi'n hawdd trefnu golygfa golofnog. Yn yr ystyr hwn, mae'n amlwg, gyda therfyn o 2 biliwn o golofnau, ei bod hi'n bosibl storio rhywfaint o ddata mewn colofnau (a'r un gyfres amser). Er enghraifft, yn MySQL mae terfyn o 4096 o golofnau ac mae'n hawdd baglu ar wall gyda chod 1117 os ceisiwch wneud yr un peth.
Mae injan Cassandra yn canolbwyntio ar storio llawer iawn o ddata mewn system ddosbarthedig heb feistr, ac mae theorem CAP Cassandra uchod yn ymwneud yn fwy ag AP, hynny yw, am argaeledd data a gwrthsefyll rhaniad. Felly, gall yr offeryn hwn fod yn wych os mai dim ond angen i chi ysgrifennu at y gronfa ddata hon ac anaml y byddwch yn darllen ohoni. Ac yma mae'n rhesymegol defnyddio Cassandra fel storfa "oer". Hynny yw, fel lle dibynadwy, hirdymor i storio symiau mawr o ddata hanesyddol nad oes eu hangen yn aml, ond y gellir eu hadalw os oes angen. Serch hynny, er mwyn cyflawnder, byddwn yn ei brofi hefyd. Ond, fel y dywedais yn gynharach, nid oes unrhyw awydd i ailysgrifennu'r cod ar gyfer y datrysiad cronfa ddata a ddewiswyd yn weithredol, felly byddwn yn ei brofi braidd yn gyfyngedig - heb addasu strwythur y gronfa ddata i fanylion Cassandra.
Prometheus
Wel, allan o chwilfrydedd, fe benderfynon ni brofi perfformiad storio Prometheus - dim ond i ddeall a ydym yn gyflymach neu'n arafach na'r atebion cyfredol ac o faint.
Profi methodoleg a chanlyniadau
Felly, gwnaethom brofi 5 cronfa ddata yn y 6 ffurfweddiad canlynol: ClickHouse (1 nod), ClickHouse (tabl wedi'i ddosbarthu ar gyfer 3 nod), InfluxDB, Mysql 8, Cassandra (3 nod) a Prometheus. Mae'r cynllun prawf fel a ganlyn:
- lanlwytho data hanesyddol am wythnos (840 miliwn o werthoedd y dydd; 208 mil metrig);
- rydym yn cynhyrchu llwyth recordio (ystyriwyd 6 dull llwyth, gweler isod);
- Ochr yn ochr â chofnodi, rydym o bryd i'w gilydd yn gwneud dewisiadau, gan efelychu ceisiadau defnyddiwr sy'n gweithio gyda siartiau. Er mwyn peidio â chymhlethu pethau'n ormodol, fe wnaethom ddewis data ar gyfer 10 metrig (dyna'n union faint sydd ar y graff CPU) am wythnos.
Rydym yn llwytho trwy efelychu ymddygiad ein hasiant monitro, sy'n anfon gwerthoedd i bob metrig unwaith bob 15 eiliad. Ar yr un pryd, mae gennym ddiddordeb mewn amrywio:
- cyfanswm nifer y metrigau yr ysgrifennir data iddynt;
- egwyl ar gyfer anfon gwerthoedd i un metrig;
- maint swp.
Ynglŷn â maint y swp. Gan na argymhellir llwytho bron pob un o'n cronfeydd data arbrofol gyda mewnosodiadau sengl, bydd angen ras gyfnewid sy'n casglu metrigau sy'n dod i mewn ac yn eu grwpio'n grwpiau ac yn eu hysgrifennu i'r gronfa ddata fel mewnosodiad swp.
Hefyd, i ddeall yn well sut i ddehongli'r data a dderbyniwyd wedyn, gadewch i ni ddychmygu nad ydym yn anfon criw o fetrigau yn unig, ond mae'r metrigau wedi'u trefnu'n weinyddion - metrigau 125 fesul gweinydd. Yma yn syml, endid rhithwir yw'r gweinydd - dim ond i ddeall, er enghraifft, bod 10000 o fetrigau yn cyfateb i tua 80 o weinyddion.
Ac yma, gan gymryd hyn i gyd i ystyriaeth, yw ein 6 dull llwytho ysgrifennu cronfa ddata:
Mae dau bwynt yma. Yn gyntaf, i Cassandra trodd y meintiau swp hyn yn rhy fawr, yno defnyddiwyd gwerthoedd o 50 neu 100. Ac yn ail, gan fod Prometheus yn gweithio'n llym yn y modd tynnu, h.y. mae ei hun yn mynd ac yn casglu data o ffynonellau metrigau (ac nid yw hyd yn oed pushgateway, er gwaethaf yr enw, yn newid y sefyllfa yn sylfaenol), gweithredwyd y llwythi cyfatebol gan ddefnyddio cyfuniad o gyfluniadau statig.
Mae canlyniadau'r profion fel a ganlyn:
Beth sy'n werth ei nodi: samplau hynod o gyflym o Prometheus, samplau ofnadwy o araf o Cassandra, samplau annerbyniol o araf gan InfluxDB; O ran cyflymder cofnodi, enillodd ClickHouse bawb, ac nid yw Prometheus yn cymryd rhan yn y gystadleuaeth, oherwydd ei fod yn gwneud mewnosodiadau ei hun ac nid ydym yn mesur unrhyw beth.
O ganlyniad,: Perfformiodd ClickHouse ac InfluxDB y gorau, ond dim ond ar sail y fersiwn Menter y gellir adeiladu clwstwr o Influx, sy'n costio arian, tra bod ClickHouse yn costio dim ac yn cael ei wneud yn Rwsia. Mae'n rhesymegol bod y dewis yn UDA yn ôl pob tebyg o blaid inInfluxDB, ac yn ein gwlad mae o blaid ClickHouse.
Ffynhonnell: hab.com