Azken urteotan, denbora-serieen datu-baseak gauza bitxi izatetik (oso espezializatua monitorizazio sistema irekietan (eta irtenbide zehatzei lotuta) edo Big Data proiektuetan erabiltzen dena) "kontsumo-produktu" bihurtu dira. Errusiar Federazioko lurraldean, eskerrak bereziak eman behar zaizkie Yandex eta ClickHouse-ri. Une honetara arte, denbora-serieko datu kopuru handia gorde behar bazenuen, Hadoop pila ikaragarri bat eraiki eta mantentzearen beharraz jabetu behar zenuten, edo sistema bakoitzerako banakako protokoloekin komunikatu behar zenuen.
Badirudi 2019an TSDB erabiltzea merezi duen artikulu batek esaldi bakarra izango duela: "besterik gabe, erabili ClickHouse". Baina... Γ±abardurak daude.
Izan ere, ClickHouse aktiboki garatzen ari da, erabiltzaile-basea hazten ari da eta laguntza oso aktiboa da, baina ClickHouse-ren arrakasta publikoaren bahitu bihurtu al gara, beste irtenbide batzuk, agian eraginkorragoak/fidagarriagoak, itzal egin dituena?
Iazko urte hasieran, gure jarraipen-sistema berregiten hasi ginen, eta bertan datuak gordetzeko datu-base egoki bat aukeratzeko galdera sortu zen. Aukera honen historiari buruz hitz egin nahi dut hemen.
Arazoaren formulazioa
Lehenik eta behin, beharrezko hitzaurrea. Zergatik behar dugu gure monitorizazio sistema eta nola diseinatu zen?
2008an hasi ginen laguntza-zerbitzuak ematen, eta 2010erako argi geratu zen zaila zela bezeroaren azpiegituran gertatzen ziren prozesuei buruzko datuak batzea garai hartan zeuden soluzioekin (hori buruz ari gara, Jainkoak barka nazazu, Cacti, Zabbix). eta sortzen ari den Grafitoa).
Gure eskakizun nagusiak hauek ziren:
- laguntza (garai hartan - dozenaka, eta etorkizunean - ehunka) bezero sistema baten barruan eta, aldi berean, alertak kudeatzeko sistema zentralizatu baten presentzia;
- alerta-sistema kudeatzeko malgutasuna (laneko funtzionarioen arteko alertak handitzea, programazioa, ezagutza-basea);
- grafikoak sakonki xehetzeko gaitasuna (Zabbixek garai hartan grafikoak irudi moduan errendatzen zituen);
- datu-kopuru handi baten epe luzerako biltegiratzea (urtebete edo gehiago) eta azkar berreskuratzeko gaitasuna.
Artikulu honetan azken puntua interesatzen zaigu.
Biltegiratzeari dagokionez, baldintzak hauek ziren:
- sistemak azkar funtzionatu behar du;
- komeni da sistemak SQL interfazea izatea;
- sistemak egonkorra izan behar du eta erabiltzaile-base aktiboa eta euskarria izan (behinean MemcacheDB bezalako sistemak onartzeko beharraren aurrean geunden, jada garatu gabe zegoena, edo MooseFS biltegiratze banatua, zeinaren akatsen jarraipena txineraz gordeta zegoena: istorio hau errepikatzen dugu gure proiektuak nahi ez);
- CAP teorema betetzea: Koherentzia (beharrezkoa) - datuek eguneratuta egon behar dute, ez dugu nahi alertak kudeatzeko sistemak datu berririk jaso ez dezan eta proiektu guztietarako datuak ez iristearen inguruko alertak ipintzea; Partition Tolerance (beharrezkoa) - ez dugu Split Brain sistemarik lortu nahi; Eskuragarritasuna (ez da kritikoa, erreplika aktibo bat badago) - istripu bat gertatuz gero geuk alda dezakegu segurtasun-kopia sistemara, kodea erabiliz.
Bitxia bada ere, garai hartan MySQL irtenbide ezin hobea izan zen guretzat. Gure datuen egitura oso erraza zen: zerbitzariaren IDa, kontagailuaren IDa, denbora-zigilua eta balioa; Datu beroen laginketa azkarra buffer multzo handi batek bermatu zuen, eta datu historikoen laginketa SSD bidez bermatu zen.
Horrela, bi asteko datu freskoen lagin bat lortu genuen, datuak guztiz errendatu baino 200 ms-ko segundora arte, eta sistema honetan denbora luzez bizi izan ginen.
Bien bitartean, denbora pasa eta datu kopurua hazi egin zen. 2016rako, datu-bolumenak hamarnaka terabyteraino iritsi ziren, eta hori gastu garrantzitsua izan zen alokatutako SSD biltegiratzearen testuinguruan.
Ordurako, zutabe-datu-baseak aktiboki hedatu ziren, eta hori modu aktiboan pentsatzen hasi ginen: zutabe-datu-baseetan, datuak zutabeetan gordetzen dira, uler dezakezun bezala, eta gure datuak begiratuz gero, erraza da handi bat ikustea. litekeen bikoiztu kopurua, zutabe-datu-base bat erabiltzen baduzu, konprimitu konpresioa erabiliz.
Hala ere, konpainiaren gako-sistemak egonkor funtzionatzen jarraitu zuen, eta ez nuen beste zerbaitetara aldatzearekin esperimentatu nahi.
2017an, San Joseko Percona Live konferentzian, Clickhouse garatzaileek ziurrenik euren burua iragarri zuten lehen aldiz. Lehen begiratuan, sistema ekoizpenerako prest zegoen (beno, Yandex.Metrica ekoizpen sistema gogorra da), laguntza azkarra eta sinplea zen eta, batez ere, funtzionamendua erraza zen. 2018az geroztik, trantsizio prozesuari ekin diogu. Baina ordurako, TSDB sistema "heldu" eta denboran probatutako asko zeuden, eta denbora dezente eskaintzea eta alternatibak alderatzea erabaki genuen, Clickhouse-ren irtenbide alternatiborik ez zegoela ziurtatzeko, gure eskakizunen arabera.
Dagoeneko zehaztutako biltegiratze eskakizunez gain, berriak agertu dira:
- sistema berriak gutxienez MySQL-ren errendimendu bera eman beharko luke hardware kopuru berean;
- sistema berriaren biltegiratzeak espazio nabarmen gutxiago hartu beharko luke;
- DBMSak kudeatzeko erraza izan behar du oraindik;
- Aplikazioa gutxieneko aldatu nahi nuen DBMSa aldatzean.
Zein sistemak hartzen hasi ginen kontuan?
Apache Hive/Apache Impala
Borrokan probatutako Hadoop pila zahar bat. Funtsean, SQL interfaze bat da HDFS-en jatorrizko formatuetan datuak gordetzeko.
Aldekoak.
- Funtzionamendu egonkorrarekin, oso erraza da datuak eskalatzea.
- Datuak biltegiratzeko zutabe-soluzioak daude (espazio gutxiago).
- Baliabideak eskuragarri daudenean zeregin paraleloen exekuzio oso azkarra.
Eragozpenak.
- Hadoop da, eta zaila da erabiltzea. Hodeian prestatutako soluzio bat hartzeko prest ez bagaude (eta kostu aldetik ez gaude prest), pila osoa administratzaileen eskuekin muntatu eta lagundu beharko da, eta ez dugu nahi. hau.
- Datuak batu egiten dira .
Hala ere:
Abiadura informatika zerbitzarien kopurua eskalatuz lortzen da. Besterik gabe, enpresa handi bat bagara, analisietan dihardugun eta negozioarentzat ezinbestekoa bada informazioa ahalik eta azkarren batzea (nahiz eta baliabide informatiko kopuru handia erabiltzearen kostua izan), hau izan daiteke gure aukera. Baina ez geunden prest hardware flota biderkatzeko zereginak bizkortzeko.
Druida/Pinot
TSDBri buruz askoz gehiago dago zehazki, baina berriro ere, Hadoop pila.
Ez dago .
Hitz gutxitan: Druid/Pinotek Clickhouse-k baino itxura hobea du:
- Datuen izaera heterogeneoa duzu (gure kasuan, zerbitzariaren neurketen denbora-serieak bakarrik erregistratzen ditugu, eta, hain zuzen ere, hau taula bat da. Baina beste kasu batzuk egon daitezke: ekipoen denbora-serieak, denbora-serie ekonomikoak, etab. - bakoitzarekin. bere egitura, batu eta prozesatu behar direnak).
- Gainera, datu asko dago.
- Denbora-serieak dituzten taulak eta datuak agertzen eta desagertzen dira (hau da, datu multzo batzuk iritsi, aztertu eta ezabatu egin dira).
- Ez dago datuak zatitzeko irizpide argirik.
Kontrako kasuetan, ClickHouse-k hobeto funtzionatzen du, eta hau da gure kasua.
clickhouse
- SQL antzekoa
- Kudeatzeko erraza.
- Jendeak dio funtzionatzen duela.
Probetarako zerrendan sartzen da.
InfluxDB
ClickHouseren alternatiba arrotza. Eragozpenetatik: High Availability bertsio komertzialean bakarrik dago, baina konparatu egin behar da.
Probetarako zerrendan sartzen da.
Cassandra
Alde batetik, badakigu denbora-serie metrikoak gordetzeko erabiltzen dela monitorizazio-sistemek, adibidez, edo OkMeter. Hala ere, badaude berezitasunak.
Cassandra ez da zutabe datu-base bat zentzu tradizionalean. Errenkada-ikuspegiaren itxura gehiago du, baina lerro bakoitzak zutabe-kopuru desberdina izan dezake, zutabe-ikuspegia antolatzea erraztuz. Zentzu honetan, argi dago 2 milioi zutabeko mugarekin datu batzuk zutabetan (eta denbora-serie berberak) gorde daitezkeela. Esate baterako, MySQL-n 4096 zutabeko muga dago eta erraza da 1117 kodearekin errore bat topatzea berdin egiten saiatzen bazara.
Cassandra motorra maisurik gabeko sistema banatu batean datu kopuru handiak biltegiratzera bideratzen da, eta goian aipatutako Cassandra CAP teorema APri buruzkoa da gehiago, hau da, datuen erabilgarritasunari eta partizioaren aurkako erresistentziari buruzkoa. Horrela, tresna hau bikaina izan daiteke datu-base honetan idatzi eta gutxitan irakurri behar baduzu. Eta hemen logikoa da Cassandra biltegiratze "hotz" gisa erabiltzea. Hau da, epe luzerako leku fidagarri gisa, oso gutxitan beharrezkoak diren, baina behar izanez gero berreskura daitezkeen datu historiko kopuru handiak gordetzeko. Hala ere, osotasunaren mesedetan, guk ere probatuko dugu. Baina, lehen esan dudan bezala, ez dago aukeratutako datu-basearen konponbiderako kodea aktiboki berridazteko asmorik, beraz, modu mugatuan probatuko dugu, datu-basearen egitura Cassandraren berezitasunetara egokitu gabe.
Prometeo
Bada, jakin-minagatik, Prometheus biltegiratze-ren errendimendua probatzea erabaki genuen, egungo soluzioak baino azkarragoak edo motelagoak garen eta zenbaterainokoa garen ulertzeko.
Proba metodologia eta emaitzak
Beraz, 5 datu-base probatu ditugu 6 konfigurazio hauetan: ClickHouse (1 nodo), ClickHouse (banatutako taula 3 nodo), InfluxDB, Mysql 8, Cassandra (3 nodo) eta Prometheus. Proba plana honako hau da:
- igo datu historikoak aste baterako (840 milioi balio eguneko; 208 mila metrika);
- grabazio-karga bat sortzen dugu (6 karga-modu kontuan hartu ziren, ikus behean);
- Grabaketarekin batera, aldian-aldian hautaketak egiten ditugu, grafikoekin lan egiten duen erabiltzaile baten eskaerak imitatuz. Gauzak gehiegi ez zailtzeko, 10 metrikoko datuak (hori da zehazki CPU grafikoan zenbat dauden) astebetez hautatu ditugu.
Gure monitorizazio-agentearen portaera emulatuz kargatzen dugu, zeinak 15 segundoro balioak bidaltzen dizkio metrika bakoitzari. Aldi berean, interesatzen zaigu aldatzea:
- datuak idazten diren neurketa kopuru osoa;
- balioak metrika batera bidaltzeko tartea;
- lotearen tamaina.
Lotearen tamainari buruz. Gure datu-base esperimental guztiak txertatze bakarrez kargatzea gomendatzen ez denez, sarrerako neurketak bildu eta taldeetan taldekatu eta datu-basean batch txertatze gisa idazten dituen errelebo bat beharko dugu.
Gainera, ondoren jasotako datuak nola interpretatu hobeto ulertzeko, pentsa dezagun ez garela metrika mordo bat bidaltzen, baizik eta metrikak zerbitzarietan antolatuta daudela - 125 metrika zerbitzari bakoitzeko. Hemen zerbitzaria entitate birtual bat besterik ez da, esate baterako, 10000 metrika 80 zerbitzari ingururi dagozkiola ulertzeko.
Eta hona hemen, hau guztia kontuan hartuta, gure datu-baseko 6 idazketa-karga moduak:
Hemen bi puntu daude. Lehenik eta behin, Cassandrarentzat lote-tamaina hauek handiegiak suertatu ziren, bertan 50 edo 100 balioak erabili genituen. Eta bigarrenik, Prometheus-ek tira moduan zorrozki lan egiten duenez, hau da. bera doa eta datuak biltzen ditu metrika iturrietatik (eta pushgateway-k ere, izena izan arren, ez du egoera aldatzen funtsean), dagozkien kargak konfigurazio estatikoen konbinazio bat erabiliz ezarri ziren.
Proben emaitzak honako hauek dira:
Azpimarratzekoa dena: Prometheus-en lagin izugarri azkarrak, Cassandraren lagin izugarri motelak, InfluxDBren lagin onartezin motelak; Grabaketa abiadurari dagokionez, ClickHousek denak irabazi zituen, eta Prometheus-ek ez du lehiaketan parte hartzen, berak txertaketak egiten dituelako eta ez dugulako ezer neurtzen.
Baten ondorioz,: ClickHouse eta InfluxDB hoberenak zirela erakutsi zuten, baina Influx-eko kluster bat Enterprise bertsioan oinarrituta soilik eraiki daiteke, dirua balio duena, ClickHouse-k ez du ezer kostatzen eta Errusian egiten den bitartean. Logikoa da AEBetan hautua ziurrenik inInfluxDBren aldekoa izatea, eta gurean ClickHouseren alde egitea.
Iturria: www.habr.com