Dum la pasintaj kelkaj jaroj, temp-seriaj datumbazoj transformiĝis de eksterordinara afero (tre specialigita uzata ĉu en malfermaj monitoraj sistemoj (kaj ligitaj al specifaj solvoj) aŭ en projektoj de Big Data) al "konsuma produkto". Sur la teritorio de Rusa Federacio, specialan dankon devas esti donita al Yandex kaj ClickHouse pro tio. Ĝis ĉi tiu punkto, se vi bezonis stoki grandan kvanton da tempo-serio-datumoj, vi aŭ devis ekkonsenti kun la bezono konstrui monstran Hadoop-stakon kaj konservi ĝin, aŭ komuniki kun protokoloj individuaj por ĉiu sistemo.
Povas ŝajni, ke en 2019 artikolo pri kiu TSDB indas uzi konsistos el nur unu frazo: "nur uzu ClickHouse." Sed... estas nuancoj.
Efektive, ClickHouse aktive disvolviĝas, la uzantbazo kreskas, kaj subteno estas tre aktiva, sed ĉu ni fariĝis ostaĝoj de la publika sukceso de ClickHouse, kiu ombris aliajn, eble pli efikajn/fidindajn solvojn?
Komence de la pasinta jaro, ni komencis relabori nian propran monitoran sistemon, dum kiu aperis la demando elekti taŭgan datumbazon por konservi datumojn. Mi volas paroli pri la historio de ĉi tiu elekto ĉi tie.
Formulado de la problemo
Antaŭ ĉio, necesa antaŭparolo. Kial ni bezonas nian propran monitoran sistemon kaj kiel ĝi estis desegnita?
Ni komencis provizi subtenajn servojn en 2008, kaj antaŭ 2010 evidentiĝis, ke iĝis malfacile kunigi datumojn pri la procezoj okazantaj en la klienta infrastrukturo kun la solvoj, kiuj ekzistis en tiu tempo (ni parolas pri, Dio pardonu min, Cacti, Zabbix). kaj la emerĝanta Grafito).
Niaj ĉefaj postuloj estis:
- subteno (tiutempe - dekoj, kaj estonte - centoj) da klientoj ene de unu sistemo kaj samtempe la ĉeesto de centralizita atentiga administradsistemo;
- fleksebleco en administrado de la alarmsistemo (pligrandigo de alarmoj inter deĵoroficiroj, planado, sciobazo);
- la kapablo profunde detali grafeojn (Zabbix tiutempe faris grafeojn en la formo de bildoj);
- longdaŭra konservado de granda kvanto da datumoj (jaro aŭ pli) kaj la kapablo rapide retrovi ĝin.
En ĉi tiu artikolo ni interesiĝas pri la lasta punkto.
Parolante pri stokado, la postuloj estis jenaj:
- la sistemo devas funkcii rapide;
- estas dezirinde, ke la sistemo havas SQL-interfacon;
- la sistemo devas esti stabila kaj havi aktivan uzantbazon kaj subtenon (iam ni alfrontis la bezonon subteni sistemojn kiel MemcacheDB, kiu ne plu estis evoluigita, aŭ la MooseFS distribuita stokado, kies cimspurilo estis konservita en la ĉina: ni ripetas ĉi tiun historion por nia projekto ne volis);
- plenumo de la CAP-teoremo: Konsekvenco (bezonata) - la datumoj devas esti ĝisdatigitaj, ni ne volas, ke la atentiga administradsistemo ne ricevu novajn datumojn kaj kraĉu atentigojn pri la nealveno de datumoj por ĉiuj projektoj; Partition Tolerance (postulata) - ni ne volas akiri Split Brain-sistemon; Havebleco (ne kritika, se estas aktiva kopio) - ni mem povas ŝanĝi al la rezerva sistemo en kazo de akcidento, uzante kodon.
Sufiĉe strange, tiutempe MySQL rezultis esti la ideala solvo por ni. Nia datumstrukturo estis ege simpla: servilo-identigilo, nombrilo, tempomarko kaj valoro; rapida specimenigo de varmaj datumoj estis certigita de granda bufro-poolo, kaj specimenigo de historiaj datumoj estis certigita de SSD.
Tiel, ni atingis specimenon de freŝaj dusemajnaj datumoj, kun detalo ĝis sekundo 200 ms antaŭ ol la datumoj estis tute prezentitaj, kaj vivis en ĉi tiu sistemo dum sufiĉe longa tempo.
Dume, la tempo pasis kaj la kvanto da datumoj kreskis. Antaŭ 2016, datumvolumoj atingis dekojn da terabajtoj, kio estis grava elspezo en la kunteksto de luita SSD-stokado.
Ĝis tiu tempo, kolonaj datumbazoj fariĝis aktive disvastigitaj, pri kiuj ni komencis aktive pensi: en kolonaj datumbazoj, datumoj estas konservitaj, kiel vi povas kompreni, en kolumnoj, kaj se vi rigardas niajn datumojn, estas facile vidi grandan nombro da duplikatoj kiuj povus, en Se vi uzas kolonan datumbazon, kunpremi ĝin uzante kunpremadon.
Tamen, la ŝlosila sistemo de la firmao daŭre funkciis stabile, kaj mi ne volis eksperimenti kun ŝanĝado al io alia.
En 2017, ĉe la Percona Live-konferenco en San Jose, la programistoj de Clickhouse verŝajne anoncis sin por la unua fojo. Unuavide, la sistemo estis preta por produktado (nu, Yandex.Metrica estas severa produktadsistemo), subteno estis rapida kaj simpla, kaj, plej grave, operacio estis simpla. Ekde 2018, ni komencis la transiran procezon. Sed antaŭ tiu tempo, estis multaj "plenkreskaj" kaj temp-testitaj TSDB-sistemoj, kaj ni decidis dediĉi konsiderindan tempon kaj kompari alternativojn por certigi, ke ne ekzistas alternativaj solvoj al Clickhouse, laŭ niaj postuloj.
Krom la jam specifitaj konservaj postuloj, aperis novaj:
- la nova sistemo devus provizi almenaŭ la saman agadon kiel MySQL sur la sama kvanto de aparataro;
- la stokado de la nova sistemo devus okupi signife malpli da spaco;
- La DBMS ankoraŭ devas esti facile administrebla;
- Mi volis ŝanĝi la aplikaĵon minimume ŝanĝante la DBMS.
Kiajn sistemojn ni komencis konsideri?
Apache Hive/Apache Impala
Malnova, batal-provita Hadoop-stako. Esence, ĝi estas SQL-interfaco konstruita aldone al stokado de datumoj en indiĝenaj formatoj sur HDFS.
Avantaĝoj.
- Kun stabila operacio, estas tre facile skali datumojn.
- Estas kolumnsolvoj por datumstokado (malpli spaco).
- Tre rapida ekzekuto de paralelaj taskoj kiam rimedoj estas disponeblaj.
Cons
- Ĝi estas Hadoop, kaj ĝi estas malfacile uzebla. Se ni ne estas pretaj preni pretan solvon en la nubo (kaj ni ne estas pretaj laŭ kosto), la tuta stako devos esti kunvenita kaj subtenata de la manoj de administrantoj, kaj ni vere ne volas ĉi tio.
- Datumoj estas kunigitaj .
Sed:
Rapideco estas atingita per skalado de la nombro da komputikaj serviloj. Simple dirite, se ni estas granda firmao, okupiĝanta pri analizo, kaj estas kritike por la komerco aldoni informojn kiel eble plej rapide (eĉ koste de uzado de granda kvanto da komputikresursoj), ĉi tio povas esti nia elekto. Sed ni ne estis pretaj multobligi la aparataron por akceli taskojn.
Druido/Pinoto
Estas multe pli pri TSDB specife, sed denove, la Hadoop-stako.
Ekzistas .
En kelkaj vortoj: Druid/Pinot aspektas pli bone ol Clickhouse en kazoj kie:
- Vi havas heterogenan naturon de datumoj (en nia kazo, ni registras nur temposerion de servilaj metrikoj, kaj, fakte, ĉi tio estas unu tabelo. Sed povas esti aliaj kazoj: ekipaĵo temposerio, ekonomia temposerio, ktp. - ĉiu kun sian propran strukturon, kiuj devas esti kunigitaj kaj prilaboritaj).
- Krome, estas multaj ĉi tiuj datumoj.
- Tabeloj kaj datumoj kun temposerio aperas kaj malaperas (tio estas, iu aro da datumoj alvenis, estis analizitaj kaj forigitaj).
- Ne ekzistas klara kriterio per kiu datumoj povas esti dividitaj.
En kontraŭaj kazoj, ClickHouse funkcias pli bone, kaj ĉi tio estas nia kazo.
KlakuDomo
- SQL-simila
- Facila administrebla.
- Homoj diras, ke ĝi funkcias.
Estas prioritatita por testado.
InfluxDB
Eksterlanda alternativo al ClickHouse. El la minusoj: Alta Havebleco nur ĉeestas en la komerca versio, sed ĝi devas esti komparita.
Estas prioritatita por testado.
Cassandra
Unuflanke, ni scias, ke ĝi estas uzata por stoki metrikajn temposerion per tiaj monitoraj sistemoj kiel ekzemple, aŭ OkMeter. Tamen, estas specifaĵoj.
Kasandra ne estas kolumna datumbazo en la tradicia signifo. Ĝi aspektas pli kiel vicvido, sed ĉiu linio povas havi malsaman nombron da kolumnoj, faciligante organizi kolonan vidon. En ĉi tiu senco, estas klare, ke kun limo de 2 miliardoj da kolumnoj, eblas konservi iujn datumojn en kolumnoj (kaj la sama temposerio). Ekzemple, en MySQL estas limo de 4096 kolumnoj kaj estas facile renkonti eraron kun kodo 1117 se vi provas fari la samon.
La Cassandra motoro koncentriĝas pri stokado de grandaj kvantoj da datumoj en distribuita sistemo sen majstro, kaj la supre menciita Cassandra CAP-teoremo temas pli pri AP, tio estas, pri datumhavebleco kaj rezisto al dispartigo. Tiel, ĉi tiu ilo povas esti bonega se vi nur bezonas skribi al ĉi tiu datumbazo kaj malofte legi de ĝi. Kaj ĉi tie estas logike uzi Cassandra kiel "malvarma" stokado. Tio estas, kiel longdaŭra, fidinda loko por stoki grandajn kvantojn da historiaj datumoj, kiuj malofte estas bezonataj, sed povas esti prenitaj se necese. Tamen, por kompleteco, ni ankaŭ provos ĝin. Sed, kiel mi diris pli frue, ne estas deziro aktive reverki la kodon por la elektita datumbaza solvo, do ni testos ĝin iom limige - sen adapti la datumbazan strukturon al la specifaĵoj de Kasandra.
Prometeo
Nu, pro scivolemo, ni decidis testi la rendimenton de Prometheus-stokado - nur por kompreni ĉu ni estas pli rapidaj aŭ pli malrapidaj ol nunaj solvoj kaj kiom.
Testo-metodaro kaj rezultoj
Do, ni testis 5 datumbazojn en la sekvaj 6 agordoj: ClickHouse (1 nodo), ClickHouse (distribuita tablo por 3 nodoj), InfluxDB, Mysql 8, Cassandra (3 nodoj) kaj Prometheus. La testoplano estas kiel sekvas:
- alŝutu historiajn datumojn dum semajno (840 milionoj da valoroj tage; 208 mil metrikoj);
- ni generas registradan ŝarĝon (6 ŝarĝreĝimoj estis konsiderataj, vidu sube);
- Paralele kun registrado, ni periode faras elektojn, imitante la petojn de uzanto laboranta kun furorlisto. Por ne tro kompliki aferojn, ni elektis datumojn por 10 metrikoj (ĝuste kiom estas sur la CPU-grafiko) dum semajno.
Ni ŝarĝas imitante la konduton de nia monitora agento, kiu sendas valorojn al ĉiu metriko unufoje ĉiujn 15 sekundojn. Samtempe, ni interesiĝas pri vario:
- la tutsumo de metrikoj en kiuj datumoj estas skribitaj;
- intervalo por sendi valorojn al unu metriko;
- aro grandeco.
Pri la aro grandeco. Ĉar ne rekomendas ŝarĝi preskaŭ ĉiujn niajn eksperimentajn datumbazojn per unuopaj enmetoj, ni bezonos relajson, kiu kolektas envenantajn metrikojn kaj grupigas ilin en grupojn kaj skribas ilin al la datumbazo kiel bata enmeto.
Ankaŭ, por pli bone kompreni kiel tiam interpreti la ricevitajn datumojn, ni imagu, ke ni ne nur sendas amason da metrikoj, sed la metrikoj estas organizitaj en servilojn - 125 metrikoj per servilo. Ĉi tie la servilo estas simple virtuala ento - nur por kompreni, ke ekzemple 10000 80 metrikoj respondas al ĉirkaŭ XNUMX serviloj.
Kaj jen, konsiderante ĉion ĉi, niaj 6 datumbazaj skribaj ŝarĝaj reĝimoj:
Estas du punktoj ĉi tie. Unue, por Cassandra ĉi tiuj aroj montriĝis tro grandaj, tie ni uzis valorojn de 50 aŭ 100. Kaj due, ĉar Prometeo funkcias strikte en tirreĝimo, t.e. ĝi mem iras kaj kolektas datumojn de metrikaj fontoj (kaj eĉ pushgateway, malgraŭ la nomo, ne esence ŝanĝas la situacion), la respondaj ŝarĝoj estis efektivigitaj uzante kombinaĵon de senmovaj agordoj.
La testrezultoj estas kiel sekvas:
Kio estas rimarkinda: fantazie rapidaj specimenoj de Prometeo, terure malrapidaj specimenoj de Kasandra, neakcepteble malrapidaj specimenoj de InfluxDB; Koncerne al rapido de registrado, ClickHouse gajnis ĉiujn, kaj Prometheus ne partoprenas en la konkurso, ĉar ĝi faras enmetojn mem kaj ni nenion mezuras.
En la fino: ClickHouse kaj InfluxDB montris sin kiel la plej bonaj, sed areto de Influx povas esti konstruita nur surbaze de la Enterprise versio, kiu kostas monon, dum ClickHouse kostas nenion kaj estas farita en Rusio. Estas logike, ke en Usono la elekto verŝajne estas favora al inInfluxDB, kaj en nia lando ĝi estas favora al ClickHouse.
fonto: www.habr.com