Við munum skoða hvernig Zabbix vinnur með TimescaleDB gagnagrunninn sem bakenda. Við munum sýna þér hvernig á að byrja frá grunni og hvernig á að flytja frá PostgreSQL. Við munum einnig bjóða upp á samanburðarpróf á frammistöðu þessara tveggja stillinga.
HighLoad++ Síbería 2019. Tomsk Hall. 24. júní, 16:00. Ritgerðir og . Næsta HighLoad++ ráðstefna verður haldin 6. og 7. apríl 2020 í St. Pétursborg. Upplýsingar og miðar .
Andrey Gushchin (hér eftir – AG): – Ég er ZABBIX tækniaðstoðarverkfræðingur (hér á eftir nefnt „Zabbix“), þjálfari. Ég hef starfað við tækniaðstoð í meira en 6 ár og hef haft beina reynslu af frammistöðu. Í dag mun ég tala um frammistöðuna sem TimescaleDB getur veitt í samanburði við venjulegan PostgreSQL 10. Einnig nokkur inngangshluti um hvernig það virkar almennt.
Helstu áskoranir um framleiðni: frá gagnasöfnun til gagnahreinsunar
Til að byrja með eru ákveðnar frammistöðuáskoranir sem hvert eftirlitskerfi stendur frammi fyrir. Fyrsta framleiðniáskorunin er að safna og vinna gögn hratt.
Gott vöktunarkerfi ætti að taka við öllum gögnum fljótt, tímanlega, vinna úr þeim í samræmi við kveikjutjáningu, það er að vinna úr þeim samkvæmt einhverjum forsendum (þetta er mismunandi í mismunandi kerfum) og vista þau í gagnagrunni til að nota þessi gögn í framtíð.
Önnur frammistöðuáskorunin er sögugeymsla. Geymdu oft í gagnagrunni og hafðu skjótan og þægilegan aðgang að þessum mælingum sem safnað var á tímabili. Það mikilvægasta er að þægilegt sé að nálgast þessi gögn, nota þau í skýrslur, línurit, kveikjur, í sumum þröskuldsgildum, fyrir viðvaranir o.s.frv.
Þriðja frammistöðuáskorunin er söguhreinsun, það er að segja þegar þú kemst á þann stað að þú þarft ekki að geyma neinar nákvæmar mælingar sem hafa verið safnað á 5 árum (jafnvel mánuði eða tvo mánuði). Sumum nethnútum var eytt, eða sumum vélum, mæligildunum er ekki lengur þörf vegna þess að þær eru þegar gamaldags og ekki lengur safnað. Allt þetta þarf að hreinsa út svo gagnagrunnurinn þinn verði ekki of stór. Almennt séð er hreinsunarferill oftast alvarlegt próf fyrir geymsluna - það hefur oft mjög mikil áhrif á frammistöðu.
Hvernig á að leysa skyndiminni vandamál?
Ég mun nú tala sérstaklega um Zabbix. Í Zabbix er fyrsta og annað símtal leyst með því að nota skyndiminni.
Gagnasöfnun og vinnsla - Við notum vinnsluminni til að geyma öll þessi gögn. Verður nú fjallað nánar um þessi gögn.
Einnig á gagnagrunnshliðinni er nokkur skyndiminni fyrir aðalval - fyrir línurit og annað.
Skyndiminni á hlið Zabbix netþjónsins sjálfs: við höfum ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Hvað það er?
ConfigurationCache er aðal skyndiminni þar sem við geymum mælikvarða, vélar, gagnaatriði, kveikjur; allt sem þú þarft til að vinna úr forvinnslu, safna gögnum, frá hvaða vélum á að safna, með hvaða tíðni. Allt þetta er geymt í ConfigurationCache til að fara ekki í gagnagrunninn og búa til óþarfa fyrirspurnir. Eftir að þjónninn byrjar uppfærum við þetta skyndiminni (búum það til) og uppfærum það reglulega (fer eftir stillingum).
Skyndiminni í Zabbix. Gagnasafn
Hér er skýringarmyndin nokkuð stór:
Þeir helstu í kerfinu eru þessir safnarar:
Þetta eru samsetningarferlarnir sjálfir, ýmsir „kjósendur“ sem bera ábyrgð á mismunandi gerðum samsetningar. Þeir safna gögnum með icmp, ipmi og ýmsum samskiptareglum og flytja þau öll í forvinnslu.
PreProcessing HistoryCache
Einnig, ef við höfum reiknað gagnaþætti (þeir sem þekkja til Zabbix vita), það er að segja útreiknaða, samansafnaða gagnaþætti, þá tökum við þá beint úr ValueCache. Ég skal segja þér hvernig það er fyllt síðar. Allir þessir safnarar nota ConfigurationCache til að taka á móti störfum sínum og senda þau síðan í forvinnslu.
Forvinnsla notar einnig ConfigurationCache til að fá forvinnsluskref og vinnur úr þessum gögnum á ýmsan hátt. Frá og með útgáfu 4.2 höfum við fært það yfir í proxy. Þetta er mjög þægilegt, vegna þess að forvinnslan sjálf er frekar erfið aðgerð. Og ef þú ert með mjög stóran Zabbix, með miklum fjölda gagnaþátta og mikilli söfnunartíðni, þá einfaldar þetta verkið mjög.
Í samræmi við það, eftir að við höfum unnið úr þessum gögnum á einhvern hátt með forvinnslu, vistum við þau í HistoryCache til að vinna þau frekar. Þar með er gagnasöfnuninni lokið. Við förum yfir í aðalferlið.
Saga samstillingarverk
Aðalferlið í Zabbix (þar sem það er einhæfur arkitektúr) er History syncer. Þetta er aðalferlið sem fjallar sérstaklega um frumeindavinnslu hvers gagnaþáttar, það er hvert gildi:
- gildið kemur (það tekur það frá HistoryCache);
- athugar í Configuration syncer: hvort það séu einhverjar kveikjur til útreiknings - reiknar þær út;
ef það er - býr til atburði, skapar stigmögnun til að búa til viðvörun, ef nauðsyn krefur í samræmi við uppsetninguna; - skráir kveikjur fyrir síðari vinnslu, samsöfnun; ef þú safnar saman síðustu klukkustund og svo framvegis, mun ValueCache þetta gildi til að fara ekki í sögutöfluna; Þannig er ValueCache fyllt með nauðsynlegum gögnum sem eru nauðsynleg til að reikna út kveikjur, reiknaða þætti osfrv.;
- þá skrifar History syncer öll gögn í gagnagrunninn;
- gagnagrunnurinn skrifar þær á diskinn - þetta er þar sem vinnsluferlið endar.
Gagnagrunnur. Skyndiminni
Á gagnagrunnsmegin, þegar þú vilt skoða línurit eða einhverjar skýrslur um atburði, eru ýmis skyndiminni. En í þessari skýrslu mun ég ekki tala um þau.
Fyrir MySQL er Innodb_buffer_pool, og fullt af mismunandi skyndiminni sem einnig er hægt að stilla.
En þetta eru þær helstu:
- sameiginlegir_buffarar;
- áhrifarík_skyndiminni_stærð;
- sameiginleg_laug.
Fyrir alla gagnagrunna sagði ég að það eru ákveðin skyndiminni sem gerir þér kleift að geyma í vinnsluminni þau gögn sem oft þarf fyrir fyrirspurnir. Þeir hafa sína eigin tækni fyrir þetta.
Um árangur gagnagrunns
Í samræmi við það er samkeppnisumhverfi, það er að Zabbix þjónninn safnar gögnum og skráir þau. Þegar það er endurræst les það einnig úr sögunni til að fylla ValueCache og svo framvegis. Hér er hægt að hafa forskriftir og skýrslur sem nota Zabbix API sem er byggt á vefviðmóti. Zabbix API fer inn í gagnagrunninn og fær nauðsynleg gögn til að fá línurit, skýrslur eða einhvers konar lista yfir atburði, nýleg vandamál.
Einnig er mjög vinsæl sjónmyndarlausn Grafana, sem notendur okkar nota. Geta skráð þig beint inn bæði í gegnum Zabbix API og í gegnum gagnagrunninn. Það skapar líka ákveðna samkeppni um að afla gagna: það þarf fínni og betri stillingu á gagnagrunninum til að uppfylla hraða afhendingu niðurstaðna og prófana.
Hreinsar feril. Zabbix er með húsvörð
Þriðja símtalið sem er notað í Zabbix er að hreinsa sögu með Housekeeper. Húsvörður fylgir öllum stillingum, það er að gagnaþættirnir okkar gefa til kynna hversu lengi á að geyma (í dögum), hversu lengi á að geyma þróun og gangverki breytinga.
Ég talaði ekki um TrendCache, sem við reiknum út á flugi: gögn berast, við tökum þau saman í eina klukkustund (aðallega eru þetta tölur fyrir síðustu klukkustund), magnið er meðaltal/lágmark og við skráum það einu sinni á klukkustund í tafla yfir gangverki breytinga ("Trends") . „Housekeeper“ byrjar og eyðir gögnum úr gagnagrunninum með því að nota reglulega val, sem er ekki alltaf áhrifaríkt.
Hvernig á að skilja að það er árangurslaust? Þú getur séð eftirfarandi mynd á frammistöðuritum innri ferla:
Sögusamstillirinn þinn er stöðugt upptekinn (rautt graf). Og „rauða“ línuritið sem fer ofan á. Þetta er „Housekeeper“ sem byrjar og bíður eftir að gagnagrunnurinn eyði öllum línum sem hann hefur tilgreint.
Við skulum taka nokkur atriðisauðkenni: þú þarft að eyða síðustu 5 þúsund; auðvitað eftir vísitölum. En venjulega er gagnasafnið frekar stórt - gagnagrunnurinn les það samt af diski og setur það í skyndiminni og þetta er mjög dýr aðgerð fyrir gagnagrunninn. Það fer eftir stærð þess, þetta getur leitt til ákveðinna frammistöðuvandamála.
Þú getur slökkt á Housekeeper á einfaldan hátt - við erum með kunnuglegt vefviðmót. Stillingar í stjórnun almennt (stillingar fyrir „Rússhaldari“) við slökkva á innri ræstingu fyrir innri sögu og þróun. Í samræmi við það ræður húsvörður þessu ekki lengur:
Hvað getur þú gert næst? Þú slökktir á því, línuritin þín hafa jafnast út... Hvaða frekari vandamál gætu komið upp í þessu tilfelli? Hvað getur hjálpað?
Skipting (sneiðing)
Venjulega er þetta stillt á annan hátt á hverjum venslagagnagrunni sem ég hef skráð. MySQL hefur sína eigin tækni. En í heildina eru þeir mjög svipaðir þegar kemur að PostgreSQL 10 og MySQL. Auðvitað er mikill innri munur á því hvernig þetta er allt útfært og hvernig það hefur áhrif á frammistöðu. En almennt leiðir stofnun nýs skiptingar oft einnig til ákveðinna vandamála.
Það fer eftir uppsetningunni þinni (hversu mikið af gögnum þú býrð til á einum degi), þeir setja venjulega lágmarkið - þetta er 1 dagur / lotu, og fyrir "strauma", gangverki breytinga - 1 mánuður / ný lota. Þetta gæti breyst ef þú ert með mjög stóra uppsetningu.
Segjum strax um stærð uppsetningarinnar: allt að 5 þúsund ný gildi á sekúndu (svokölluð nvps) - þetta verður talið lítið „uppsetning“. Meðaltal - frá 5 til 25 þúsund gildi á sekúndu. Allt sem er að ofan er nú þegar stórar og mjög stórar uppsetningar sem krefjast mjög vandlegrar uppsetningar á gagnagrunninum.
Á mjög stórum uppsetningum gæti 1 dagur ekki verið ákjósanlegur. Ég persónulega hef séð skipting á MySQL upp á 40 gígabæta á dag (og það gæti verið meira). Þetta er mjög mikið magn af gögnum, sem getur leitt til nokkurra vandamála. Það þarf að minnka.
Af hverju þarftu skipting?
Það sem Partitioning veitir, held ég að allir viti, er borðskipting. Oft eru þetta aðskildar skrár á diski og span beiðnir. Það velur eina skiptingu betur ef það er hluti af venjulegri skiptingu.
Sérstaklega fyrir Zabbix er það notað eftir svið, eftir svið, það er, við notum tímastimpil (venjuleg tala, tími frá upphafi tímabils). Þú tilgreinir upphaf dags/lok dags, og þetta er skiptingin. Í samræmi við það, ef þú ert að biðja um gögn sem eru tveggja daga gömul, er allt sótt úr gagnagrunninum hraðar, því þú þarft aðeins að hlaða einni skrá inn í skyndiminni og skila henni (frekar en stóra töflu).
Margir gagnagrunnar flýta einnig fyrir innsetningu (innsetning í eina barnatöflu). Ég er að tala abstrakt í bili, en þetta er líka mögulegt. Skipting hjálpar oft.
Elasticsearch fyrir NoSQL
Nýlega, í 3.4, innleiddum við NoSQL lausn. Bætti við hæfileikanum til að skrifa í Elasticsearch. Þú getur skrifað ákveðnar gerðir: þú velur - annað hvort skrifaðu tölur eða einhver tákn; við erum með strengjatexta, þú getur skrifað logs í Elasticsearch... Í samræmi við það mun vefviðmótið einnig fá aðgang að Elasticsearch. Þetta virkar frábærlega í sumum tilfellum, en í augnablikinu er hægt að nota það.
TimescaleDB. Ofurtöflur
Fyrir 4.4.2 veittum við athygli einu eins og TimescaleDB. Hvað það er? Þetta er viðbót fyrir PostgreSQL, það er að segja að það er með innbyggt PostgreSQL viðmót. Auk þess gerir þessi viðbót þér kleift að vinna mun skilvirkari með tímaröðgögn og hafa sjálfvirka skiptingu. Hvernig það lítur út:
Þetta er hypertable - það er svona hugtak í Timescale. Þetta er ofurtöflu sem þú býrð til og hún inniheldur klumpur. Klumpar eru skipting, þetta eru barnatöflur, ef mér skjátlast ekki. Það er virkilega áhrifaríkt.
TimescaleDB og PostgreSQL
Eins og TimescaleDB framleiðendur tryggja, nota þeir réttara reiknirit til að vinna úr fyrirspurnum, sérstaklega innskotum, sem gerir þeim kleift að hafa um það bil stöðuga afköst með vaxandi stærð gagnasafnsins. Það er, eftir 200 milljón raðir af Postgres, byrjar sá venjulegi að síga mjög mikið og missir afköst bókstaflega niður í núll, á meðan Timescale gerir þér kleift að setja inn innlegg eins skilvirkt og mögulegt er með hvaða gagnamagni sem er.
Hvernig á að setja upp TimescaleDB? Það er einfalt!
Það er í skjölunum, það er lýst - þú getur sett það upp úr pökkum fyrir hvaða... Það fer eftir opinberu Postgres pakkanum. Hægt að setja saman handvirkt. Það gerðist svo að ég þurfti að safna saman fyrir gagnagrunninn.
Á Zabbix virkjum við einfaldlega Extention. Ég held að þeir sem notuðu Extention í Postgres... Þú einfaldlega virkjar Extention, býrð til fyrir Zabbix gagnagrunninn sem þú ert að nota.
Og síðasta skrefið...
TímakvarðiDB. Flutningur á sögutöflum
Þú þarft að búa til ofurtöflu. Það er sérstök aðgerð fyrir þetta - Búa til hátöflu. Í henni er fyrsta færibreytan taflan sem þarf í þessum gagnagrunni (sem þú þarft að búa til hátöflu fyrir).
Reiturinn sem á að búa til, og chunk_time_interval (þetta er bil klumpa (skilrúm sem þarf að nota). 86 er einn dagur.
Migrate_data færibreyta: Ef þú setur inn í true, þá mun þetta flytja öll núverandi gögn í fyrirfram búna bita.
Ég hef sjálfur notað migrate_data - það tekur töluverðan tíma, eftir því hversu stór gagnagrunnurinn þinn er. Ég var með meira en terabæt - það tók rúman klukkutíma að búa til. Í sumum tilfellum, meðan á prófun stóð, eyddi ég sögulegum gögnum fyrir texta (history_text) og streng (history_str) til að flytja þau ekki - þau voru ekki áhugaverð fyrir mig.
Og við gerum síðustu uppfærsluna í db_extention okkar: við setjum upp timescaledb þannig að gagnagrunnurinn og sérstaklega Zabbix okkar skilji að það er db_extention. Hann virkjar það og notar rétta setningafræði og fyrirspurnir í gagnagrunninn, með því að nota þá „eiginleika“ sem eru nauðsynlegir fyrir TimescaleDB.
Stilling netþjóns
Ég notaði tvo netþjóna. Fyrsti þjónninn er frekar lítil sýndarvél, 20 örgjörvar, 16 gígabæta af vinnsluminni. Ég stillti Postgres 10.8 á það:
Stýrikerfið var Debian, skráarkerfið var xfs. Ég gerði lágmarksstillingar til að nota þennan tiltekna gagnagrunn, að frádregnum því sem Zabbix sjálft mun nota. Á sömu vél var Zabbix server, PostgreSQL og load agents.
Ég hef notað 50 virka efni sem nota LoadableModule til að búa til mismunandi niðurstöður fljótt. Það eru þeir sem bjuggu til strengina, tölurnar og svo framvegis. Ég fyllti gagnagrunninn með fullt af gögnum. Upphaflega innihélt uppsetningin 5 þúsund gagnaeiningar á hvern hýsil og um það bil hver gagnaþáttur innihélt kveikju - til að þetta væri raunveruleg uppsetning. Stundum þarftu jafnvel fleiri en eina kveikju til að nota.
Ég stjórnaði uppfærslubilinu og álaginu sjálfu með því að nota ekki aðeins 50 umboðsmenn (bæta við fleiri), heldur einnig með því að nota kraftmikla gagnaþætti og minnka uppfærslubilið í 4 sekúndur.
Frammistöðupróf. PostgreSQL: 36 þúsund NVP
Fyrsta ræsingin, fyrsta uppsetningin sem ég hafði var á hreinu PostreSQL 10 á þessum vélbúnaði (35 þúsund gildi á sekúndu). Almennt séð, eins og þú sérð á skjánum, tekur það brot af sekúndu að setja inn gögn - allt er gott og hratt, SSD drif (200 gígabæt). Málið er bara að 20 GB fyllist nokkuð fljótt.
Það verður töluvert mikið af slíkum línuritum í framtíðinni. Þetta er venjulegt afköst Zabbix miðlara mælaborð.
Fyrsta línuritið er fjöldi gilda á sekúndu (blár, efst til vinstri), 35 þúsund gildi í þessu tilfelli. Þetta (efst fyrir miðju) er hleðsla byggingarferla, og þetta (efst til hægri) er hleðsla innri ferla: sögusamstillir og húsvörður, sem hér (neðst fyrir miðju) hefur verið í gangi í nokkuð langan tíma.
Þetta línurit (neðst fyrir miðju) sýnir ValueCache notkun - hversu mörg ValueCache hits fyrir kallar (nokkrir þúsund gildi á sekúndu). Annað mikilvægt graf er það fjórða (neðst til vinstri), sem sýnir notkun HistoryCache, sem ég talaði um, sem er biðminni áður en það er sett inn í gagnagrunninn.
Frammistöðupróf. PostgreSQL: 50 þúsund NVP
Næst jók ég álagið í 50 þúsund gildi á sekúndu á sama vélbúnaði. Við hleðslu af húshjálp voru 10 þúsund gildi skráð á 2-3 sekúndum með útreikningi. Hvað er í raun og veru sýnt á eftirfarandi skjáskoti:
„Rússnarmaður“ er þegar farinn að trufla vinnuna, en almennt er álagið á veiðimenn sem eru í sögunni enn um 60% (þriðja línurit, efst til hægri). HistoryCache byrjar nú þegar að fyllast á meðan Housekeeper er í gangi (neðst til vinstri). Það var um hálft gígabæt, 20% fullt.
Frammistöðupróf. PostgreSQL: 80 þúsund NVP
Svo hækkaði ég það í 80 þúsund gildi á sekúndu:
Það voru um það bil 400 þúsund gagnaeiningar, 280 þúsund kveikjur. Innskotið, eins og þú sérð, með tilliti til álags á sögusökkva (þau voru 30 talsins) var þegar nokkuð hátt. Síðan jók ég ýmsar færibreytur: sögusökkva, skyndiminni... Á þessum vélbúnaði byrjaði álagið á sögusökkva að aukast í hámark, næstum „á hillunni“ - í samræmi við það fór HistoryCache í mjög mikið álag:
Allan þennan tíma fylgdist ég með öllum kerfisbreytum (hvernig örgjörvinn er notaður, vinnsluminni) og uppgötvaði að nýting disksins var hámark - ég náði hámarksgetu þessa disks á þessum vélbúnaði, á þessari sýndarvél. "Postgres" byrjaði að dumpa gögnum nokkuð virkan á slíkum styrkleika og diskurinn hafði ekki lengur tíma til að skrifa, lesa ...
Ég tók annan netþjón sem var þegar með 48 örgjörva og 128 gígabæta af vinnsluminni:
Ég „stillti“ það líka - setti upp History syncer (60 stykki) og náði viðunandi árangri. Reyndar erum við ekki „á hillunni“, en þetta eru líklega takmörk framleiðni, þar sem nú þegar er nauðsynlegt að gera eitthvað í málinu.
Frammistöðupróf. TimescaleDB: 80 þúsund NVPs
Aðalverkefni mitt var að nota TimescaleDB. Hvert graf sýnir dýfu:
Þessar bilanir eru einmitt gagnaflutningur. Eftir það, á Zabbix netþjóninum, breyttist hleðslusnið sagnálfa, eins og þú sérð, mikið. Það gerir þér kleift að setja inn gögn næstum 3 sinnum hraðar og nota minna HistoryCache - í samræmi við það færðu gögn afhent á réttum tíma. Aftur, 80 þúsund gildi á sekúndu er frekar hátt hlutfall (að sjálfsögðu ekki fyrir Yandex). Á heildina litið er þetta frekar stórt skipulag, með einum netþjóni.
PostgreSQL árangurspróf: 120 þúsund NVP
Næst jók ég gildi fjölda gagnaþátta í hálfa milljón og fékk reiknað gildi upp á 125 þúsund á sekúndu:
Og ég fékk þessi línurit:
Í grundvallaratriðum er þetta vinnandi uppsetning, það getur virkað í nokkuð langan tíma. En þar sem ég átti bara 1,5 terabæta disk, þá notaði ég hann á nokkrum dögum. Það sem skiptir mestu máli er að á sama tíma voru búnar til nýjar skiptingar á TimescaleDB og það var algjörlega óséður fyrir frammistöðu, sem ekki er hægt að segja um MySQL.
Venjulega eru skipting búnar til á nóttunni, vegna þess að þetta hindrar almennt innsetningu og vinnu með töflum og getur leitt til rýrnunar á þjónustunni. Í þessu tilfelli er þetta ekki raunin! Aðalverkefnið var að prófa getu TimescaleDB. Niðurstaðan var eftirfarandi tala: 120 þúsund gildi á sekúndu.
Það eru líka dæmi í samfélaginu:
Viðkomandi kveikti líka á TimescaleDB og álagið á að nota io.weight lækkaði á örgjörvanum; og notkun innri ferliþátta hefur einnig minnkað vegna innkomu TimescaleDB. Þar að auki eru þetta venjulegir pönnukökudiskar, það er venjuleg sýndarvél á venjulegum diskum (ekki SSD)!
Fyrir sumar litlar uppsetningar sem takmarkast af afköstum disksins er TimescaleDB, að mínu mati, mjög góð lausn. Það gerir þér kleift að halda áfram að vinna áður en þú ferð yfir í hraðari vélbúnað fyrir gagnagrunninn.
Ég býð ykkur öllum á viðburði okkar: Ráðstefnu í Moskvu, leiðtogafundur í Riga. Notaðu rásirnar okkar - Telegram, spjallborð, IRC. Ef þú hefur einhverjar spurningar, komdu að borðinu okkar, við getum talað um allt.
Spurningar áhorfenda
Spurning frá áhorfendum (hér á eftir - A): - Ef TimescaleDB er svo auðvelt að stilla og það gefur slíka frammistöðuaukningu, þá ætti þetta kannski að vera notað sem besta aðferð til að stilla Zabbix með Postgres? Og eru einhverjar gildrur og ókostir við þessa lausn, eða þegar allt kemur til alls, ef ég ákvað að búa til Zabbix fyrir sjálfan mig, get ég auðveldlega tekið Postgres, sett upp Timescale þar strax, notað það og ekki hugsað um nein vandamál?
AG: – Já, ég myndi segja að þetta séu góð meðmæli: notaðu Postgres strax með TimescaleDB viðbótinni. Eins og ég sagði þegar, mikið af góðum dómum, þrátt fyrir að þessi „eiginleiki“ sé tilraunastarfsemi. En reyndar sýna prófanir að þetta er frábær lausn (með TimescaleDB) og ég held að hún muni þróast! Við fylgjumst með hvernig þessi framlenging þróast og munum gera breytingar eftir þörfum.
Jafnvel meðan á þróun stóð, treystum við á einn af þekktum „eiginleikum“ þeirra: það var hægt að vinna með bita svolítið öðruvísi. En svo klipptu þeir það út í næstu útgáfu og við urðum að hætta að treysta á þennan kóða. Ég myndi mæla með því að nota þessa lausn á mörgum uppsetningum. Ef þú notar MySQL... Fyrir meðaluppsetningar virkar hvaða lausn sem er.
A: – Á síðustu línuritum frá samfélaginu var línurit með „Housekeeper“:
Hann hélt áfram að vinna. Hvað gerir húsvörður með TimescaleDB?
AG: - Nú get ég ekki sagt það með vissu - ég mun skoða kóðann og segja þér nánar. Það notar TimescaleDB fyrirspurnir ekki til að eyða klumpum, heldur til að safna þeim einhvern veginn saman. Ég er ekki tilbúinn að svara þessari tæknilegu spurningu ennþá. Við fáum að vita meira á básnum í dag eða á morgun.
A: – Ég er með svipaða spurningu – um frammistöðu eyðingaraðgerðarinnar í Timescale.
A (svar frá áhorfendum): – Þegar þú eyðir gögnum úr töflu, ef þú gerir það með því að eyða, þá þarftu að fara í gegnum töfluna - eyða, þrífa, merkja allt fyrir framtíðar tómarúm. Í Timescale, þar sem þú ert með klumpur, geturðu sleppt. Í grófum dráttum segirðu einfaldlega við skrána sem er í stórum gögnum: „Eyða!
Timescale skilur einfaldlega að slíkur klumpur er ekki lengur til. Og þar sem það er samþætt í fyrirspurnaskipuleggjarann, notar það króka til að ná skilyrðum þínum í vali eða öðrum aðgerðum og skilur strax að þessi hluti er ekki lengur til - "Ég mun ekki fara þangað lengur!" (gögn ekki tiltæk). Það er allt og sumt! Það er, töfluskönnun er skipt út fyrir eyðingu tvíundarskráa, svo það er hratt.
A: - Við höfum þegar komið inn á efnið sem er ekki SQL. Eftir því sem ég skil þá þarf Zabbix ekki að breyta gögnunum og allt er þetta eitthvað eins og log. Er hægt að nota sérhæfða gagnagrunna sem geta ekki breytt gögnum sínum, en á sama tíma vistað, safnað og dreift miklu hraðar - Clickhouse, til dæmis eitthvað Kafka-líkt?.. Kafka er líka log! Er hægt að samþætta þau einhvern veginn?
AG: - Hægt er að afferma. Við höfum ákveðinn „eiginleika“ frá útgáfu 3.4: þú getur skrifað allar sögulegar skrár, atburði, allt annað í skrár; og sendu það síðan í einhvern annan gagnagrunn með því að nota einhvern meðhöndlun. Reyndar endurvinna margir og skrifa beint í gagnagrunninn. Í fljótu bragði skrifa sagnhafar allt þetta í skrár, snúa þessum skrám og svo framvegis og þú getur flutt þetta yfir á Clickhouse. Ég get ekki sagt um áætlanir, en kannski mun frekari stuðningur við NoSQL lausnir (eins og Clickhouse) halda áfram.
A: – Almennt séð kemur í ljós að þú getur alveg losað þig við postgres?
AG: - Auðvitað er erfiðasti hlutinn í Zabbix sögulegu töflurnar, sem skapa flest vandamál og atburði. Í þessu tilviki, ef þú geymir ekki viðburði í langan tíma og geymir söguna með þróun í einhverri annarri hraðgeymslu, þá held ég að það verði almennt engin vandamál.
A: – Geturðu áætlað hversu miklu hraðar allt virkar ef þú skiptir til dæmis yfir í Clickhouse?
AG: — Ég hef ekki prófað það. Ég held að hægt sé að ná að minnsta kosti sömu tölum á einfaldan hátt, í ljósi þess að Clickhouse hefur sitt eigið viðmót, en ég get ekki sagt það með vissu. Það er betra að prófa. Það veltur allt á uppsetningunni: hversu marga gestgjafa þú hefur og svo framvegis. Að setja inn er eitt, en þú þarft líka að sækja þessi gögn - Grafana eða eitthvað annað.
A: – Þannig að við erum að tala um jafna baráttu, en ekki um mikla kosti þessara hraðvirku gagnagrunna?
AG: - Ég held að þegar við samþættum þá verði nákvæmari próf.
A: – Hvert fór gamla góða RRD? Hvað varð til þess að þú skipti yfir í SQL gagnagrunna? Upphaflega var öllum mælingum safnað á RRD.
AG: – Zabbix var með RRD, kannski í mjög fornri útgáfu. Það hafa alltaf verið til SQL gagnagrunnar - klassísk nálgun. Klassíska nálgunin er MySQL, PostgreSQL (þau hafa verið til í mjög langan tíma). Við notuðum næstum aldrei sameiginlegt viðmót fyrir SQL og RRD gagnagrunna.
Nokkrar auglýsingar 🙂
Þakka þér fyrir að vera hjá okkur. Líkar þér við greinarnar okkar? Viltu sjá meira áhugavert efni? Styðjið okkur með því að leggja inn pöntun eða mæla með því við vini, , einstök hliðstæða upphafsþjóna, sem var fundið upp af okkur fyrir þig: (fáanlegt með RAID1 og RAID10, allt að 24 kjarna og allt að 40GB DDR4).
Dell R730xd 2x ódýrari í Equinix Tier IV gagnaveri í Amsterdam? Aðeins hér í Hollandi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - frá $99! Lestu um
Heimild: www.habr.com