Ni rigardos kiel Zabbix funkcias kun la datumbazo TimescaleDB kiel la backend. Ni montros al vi kiel komenci de nulo kaj kiel migri de PostgreSQL. Ni ankaŭ provizos komparajn agadotestojn de la du agordoj.
HighLoad++ Siberio 2019. Tomsk Hall. 24 junio, 16:00. Tezoj kaj . La sekva HighLoad++-konferenco okazos la 6-an kaj 7-an de aprilo 2020 en Sankt-Peterburgo. Detaloj kaj biletoj .
Andrey Gushchin (ĉi-poste - AG): – Mi estas ZABBIX-teknika subtena inĝeniero (ĉi-poste nomata "Zabbix"), trejnisto. Mi laboras en teknika subteno dum pli ol 6 jaroj kaj havis rektan sperton pri agado. Hodiaŭ mi parolos pri la agado, kiun TimescaleDB povas provizi kompare kun regula PostgreSQL 10. Ankaŭ, iu enkonduka parto pri kiel ĝi funkcias ĝenerale.
Plej bonaj produktivecaj defioj: de datumkolektado ĝis datumpurigado
Komence, ekzistas certaj agado-defioj, kiujn ĉiu monitora sistemo alfrontas. La unua produktiveca defio estas kolektado kaj prilaborado de datumoj rapide.
Bona monitora sistemo devus rapide, ĝustatempe ricevi ĉiujn datumojn, prilabori ĝin laŭ ellasaj esprimoj, tio estas, prilabori ĝin laŭ iuj kriterioj (ĉi tio estas malsama en malsamaj sistemoj) kaj konservi ĝin en datumbazo por uzi ĉi tiujn datumojn en la estonteco.
La dua agado-defio estas historia stokado. Stoku en datumbazo ofte kaj havu rapidan kaj oportunan aliron al ĉi tiuj metrikoj, kiuj estis kolektitaj dum tempodaŭro. La plej grava afero estas, ke ĉi tiuj datumoj estas oportune akiri, uzi ĝin en raportoj, grafikaĵoj, ellasiloj, en iuj sojlaj valoroj, por atentigoj ktp.
La tria agado-defio estas historia malplenigo, tio estas, kiam vi atingas la punkton, kie vi ne bezonas konservi iujn detalajn metrikojn, kiuj estis kolektitaj dum 5 jaroj (eĉ monatoj aŭ du monatoj). Kelkaj retaj nodoj estis forigitaj, aŭ iuj gastigantoj, la metrikoj ne plu estas bezonataj ĉar ili jam estas malmodernaj kaj ne plu kolektitaj. Ĉio ĉi devas esti purigita por ke via datumbazo ne kresku tro granda. Ĝenerale, purigado de historio estas plej ofte serioza provo por la stokado - ĝi ofte havas tre fortan efikon al agado.
Kiel solvi problemojn pri kaŝmemoro?
Mi nun parolos specife pri Zabbix. En Zabbix, la unua kaj dua vokoj estas solvitaj uzante kaŝmemoron.
Kolekto kaj prilaborado de datumoj - Ni uzas RAM por konservi ĉiujn ĉi tiujn datumojn. Ĉi tiuj datumoj nun estos diskutitaj pli detale.
Ankaŭ ĉe la datumbazo estas iom da kaŝmemoro por ĉefaj elektoj - por grafikaĵoj kaj aliaj aferoj.
Kaŝmemoro flanke de la servilo Zabbix mem: ni havas ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Kio ĝi estas?
ConfigurationCache estas la ĉefa kaŝmemoro en kiu ni stokas metrikojn, gastigantojn, datumaĵojn, ellasilon; ĉion, kion vi bezonas por prilabori antaŭtraktadon, kolekti datumojn, de kiuj gastigantoj kolekti, kun kia ofteco. Ĉio ĉi estas konservita en ConfigurationCache por ne iri al la datumbazo kaj krei nenecesajn demandojn. Post kiam la servilo komenciĝas, ni ĝisdatigas ĉi tiun kaŝmemoron (kreas ĝin) kaj ĝisdatigas ĝin periode (depende de la agordaj agordoj).
Kaŝmemoro en Zabbix. Kolekto de datumoj
Ĉi tie la diagramo estas sufiĉe granda:
La ĉefaj en la skemo estas ĉi tiuj kolektantoj:
Ĉi tiuj estas la asembleaj procezoj mem, diversaj "pollers", kiuj respondecas pri malsamaj specoj de asembleoj. Ili kolektas datumojn per icmp, ipmi kaj diversaj protokoloj kaj transdonas ĉion al antaŭprilaborado.
Antaŭprocesanta Historikaŝmemoro
Ankaŭ, se ni havas kalkulitajn datumelementojn (tiuj kiuj konas Zabbix scias), tio estas, kalkulitaj, agregaciaj datumelementoj, ni prenas ilin rekte de ValueCache. Mi rakontos al vi kiel ĝi estas plenigita poste. Ĉiuj ĉi tiuj kolektantoj uzas ConfigurationCache por ricevi siajn laborojn kaj poste transdoni ilin al antaŭpretigo.
Antaŭprilaborado ankaŭ uzas ConfigurationCache por akiri antaŭpretigajn paŝojn kaj prilaboras ĉi tiujn datumojn diversmaniere. Komencante de versio 4.2, ni movis ĝin al prokurilo. Ĉi tio estas tre oportuna, ĉar antaŭprilaborado mem estas sufiĉe malfacila operacio. Kaj se vi havas tre grandan Zabbix, kun granda nombro da datumelementoj kaj alta kolekto ofteco, tiam ĉi tio multe simpligas la laboron.
Sekve, post kiam ni iel prilaboris ĉi tiujn datumojn uzante antaŭtraktadon, ni konservas ĝin en HistoryCache por prilabori ĝin plu. Ĉi tio finas la datumkolekton. Ni transiru al la ĉefa procezo.
La laboro de History Syncer
La ĉefa procezo en Zabbix (ĉar ĝi estas monolita arkitekturo) estas History syncer. Ĉi tiu estas la ĉefa procezo, kiu traktas specife la atoman prilaboradon de ĉiu datenelemento, tio estas, ĉiu valoro:
- la valoro venas (ĝi prenas ĝin el HistoryCache);
- kontrolas en Configuration syncer: ĉu ekzistas iuj ellasiloj por kalkulo - kalkulas ilin;
if there is - kreas eventojn, kreas eskaladon por krei alarmon, se necese laŭ la agordo; - registras ellasilon por posta prilaborado, agregado; se vi agregas dum la lasta horo kaj tiel plu, ĉi tiu valoro estas memorita de ValueCache por ne iri al la historia tabelo; Tiel, la ValueCache estas plenigita kun la necesaj datumoj, kiuj estas necesaj por kalkuli ellasilon, kalkulitajn elementojn, ktp.;
- tiam History syncer skribas ĉiujn datumojn al la datumbazo;
- la datumbazo skribas ilin al disko - ĉi tie finiĝas la prilaborado.
Datumbazo. Kaŝmemoro
En la datumbazo, kiam vi volas vidi grafikaĵojn aŭ iujn raportojn pri eventoj, estas diversaj kaŝmemoroj. Sed en ĉi tiu raporto mi ne parolos pri ili.
Por MySQL ekzistas Innodb_buffer_pool, kaj amaso da malsamaj kaŝmemoroj, kiuj ankaŭ povas esti agorditaj.
Sed ĉi tiuj estas la ĉefaj:
- dividitaj_bufferoj;
- efektiva_cache_grandeco;
- shared_pool.
Por ĉiuj datumbazoj, mi diris, ke ekzistas certaj kaŝmemoroj, kiuj permesas vin konservi en RAM la datumojn, kiujn oni ofte bezonas por demandoj. Ili havas siajn proprajn teknologiojn por tio.
Pri Database Performance
Sekve, ekzistas konkurenciva medio, tio estas, la servilo Zabbix kolektas datumojn kaj registras ĝin. Kiam rekomencita, ĝi ankaŭ legas el historio por plenigi la ValueCache kaj tiel plu. Ĉi tie vi povas havi skriptojn kaj raportojn kiuj uzas la Zabbix API, kiu estas konstruita sur interreta interfaco. Zabbix API eniras la datumbazon kaj ricevas la necesajn datumojn por akiri grafikaĵojn, raportojn aŭ ian liston de eventoj, lastatempajn problemojn.
Ankaŭ tre populara bildiga solvo estas Grafana, kiun niaj uzantoj uzas. Kapabla rekte ensaluti ambaŭ per la Zabbix API kaj per la datumbazo. Ĝi ankaŭ kreas certan konkuradon por akiri datumojn: pli fajna, pli bona agordado de la datumbazo estas necesa por plenumi la rapidan liveron de rezultoj kaj testado.
Purigante historion. Zabbix havas Domservistinon
La tria alvoko, kiu estas uzata en Zabbix, purigas historion per Domservisto. Domservisto sekvas ĉiujn agordojn, tio estas, niaj datenelementoj indikas kiom longe stoki (en tagoj), kiom longe stoki tendencojn, kaj la dinamikon de ŝanĝoj.
Mi ne parolis pri TrendCache, kiun ni surflue kalkulas: datumoj alvenas, ni agregas ĝin dum unu horo (plejparte temas pri nombroj por la lasta horo), la kvanto estas meza/minimuma kaj ni registras ĝin unufoje hore en la tabelo de la dinamiko de ŝanĝoj ("Tendencoj"). "Housekeeper" komencas kaj forigas datumojn de la datumbazo per regulaj elektoj, kio ne ĉiam efikas.
Kiel kompreni, ke ĝi estas neefika? Vi povas vidi la sekvan bildon sur la agado-grafikoj de internaj procezoj:
Via Historia sinkronilo estas konstante okupata (ruĝa grafikaĵo). Kaj la "ruĝa" grafikaĵo, kiu iras supre. Ĉi tio estas "Mastrumisto" kiu komenciĝas kaj atendas ke la datumbazo forigu ĉiujn vicojn, kiujn ĝi specifis.
Ni prenu iom da Item ID: vi devas forigi la lastajn 5 mil; kompreneble, per indeksoj. Sed kutime la datumaro estas sufiĉe granda - la datumbazo ankoraŭ legas ĝin el disko kaj metas ĝin en la kaŝmemoron, kaj ĉi tio estas tre multekosta operacio por la datumbazo. Depende de ĝia grandeco, ĉi tio povas konduki al certaj rendimentaj problemoj.
Vi povas malŝalti Dommastruiston en simpla maniero - ni havas konatan retan interfacon. Agordoj en Administrado ĝenerala (agordoj por "Mastrumisto") ni malŝaltas internan mastrumado por interna historio kaj tendencoj. Sekve, Domzorgisto ne plu kontrolas ĉi tion:
Kion vi povas fari poste? Vi malŝaltis ĝin, viaj grafikaĵoj ebeniĝis... Kio pliaj problemoj povus aperi ĉi-kaze? Kio povas helpi?
Dispartigo (sekcio)
Tipe ĉi tio estas agordita alimaniere en ĉiu rilata datumbazo, kiun mi listigis. MySQL havas sian propran teknologion. Sed ĝenerale ili estas tre similaj kiam temas pri PostgreSQL 10 kaj MySQL. Kompreneble, ekzistas multaj internaj diferencoj pri kiel ĉio estas efektivigita kaj kiel ĉio influas rendimenton. Sed ĝenerale, la kreado de nova sekcio ofte ankaŭ kondukas al certaj problemoj.
Depende de via agordo (kiom da datumoj vi kreas en unu tago), ili kutime starigas la minimumon - ĉi tio estas 1 tago / aro, kaj por "tendencoj", dinamiko de ŝanĝoj - 1 monato / nova aro. Ĉi tio povas ŝanĝiĝi se vi havas tre grandan aranĝon.
Ni diru tuj pri la grandeco de la agordo: ĝis 5 mil novaj valoroj por sekundo (tiel nomataj nvps) - ĉi tio estos konsiderata malgranda "aranĝo". Mezumo - de 5 ĝis 25 mil valoroj por sekundo. Ĉio, kio estas supre, estas jam grandaj kaj tre grandaj instalaĵoj, kiuj postulas tre zorgan agordon de la datumbazo.
Ĉe tre grandaj instalaĵoj, 1 tago eble ne estas optimuma. Mi persone vidis subdiskojn sur MySQL de 40 gigabajtoj ĉiutage (kaj eble estas pli). Ĉi tio estas tre granda kvanto da datumoj, kio povas konduki al iuj problemoj. Ĝi devas esti reduktita.
Kial vi bezonas dispartigo?
Kion Dispartigo provizas, mi pensas, ke ĉiuj scias, estas tabeldispartigo. Ofte ĉi tiuj estas apartaj dosieroj sur disko kaj span petoj. Ĝi elektas unu subdiskon pli optimume se ĝi estas parto de normala dispartigo.
Por Zabbix, precipe, ĝi estas uzata laŭ intervalo, laŭ intervalo, tio estas, ni uzas tempmarkon (regula nombro, tempo ekde la komenco de la epoko). Vi specifas la komencon de la tago/fino de la tago, kaj ĉi tio estas la sekcio. Sekve, se vi petas datumojn aĝajn du tagojn, ĉio estas prenita el la datumbazo pli rapide, ĉar vi bezonas nur ŝargi unu dosieron en la kaŝmemoron kaj redoni ĝin (prefere ol granda tablo).
Multaj datumbazoj ankaŭ akcelas enmeton (enmeton en unu infanan tabelon). Mi parolas abstrakte nuntempe, sed ankaŭ tio eblas. Dispartigo ofte helpas.
Elasticsearch por NoSQL
Lastatempe, en 3.4, ni efektivigis NoSQL-solvon. Aldonis la kapablon skribi en Elasticsearch. Oni povas skribi certajn tipojn: oni elektas - aŭ skribu nombrojn aŭ kelkajn signojn; ni havas ĉentekston, vi povas skribi protokolojn al Elasticsearch... Sekve, la retinterfaco ankaŭ aliros Elasticsearch. Ĉi tio funkcias bonege en iuj kazoj, sed nuntempe ĝi povas esti uzata.
TimecaleDB. Hipertabuloj
Por 4.4.2 ni atentis unu aferon kiel TimescaleDB. Kio ĝi estas? Ĉi tio estas etendo por PostgreSQL, tio estas, ĝi havas denaskan PostgreSQL-interfacon. Krome, ĉi tiu etendaĵo permesas vin multe pli efike labori kun temposerio-datumoj kaj havi aŭtomatan sekcion. Kiel ĝi aspektas:
Ĉi tio estas hipertabla - ekzistas tia koncepto en Tempskalo. Ĉi tio estas hipertabelo, kiun vi kreas, kaj ĝi enhavas pecojn. Pecoj estas sekcioj, ĉi tiuj estas infanaj tabeloj, se mi ne eraras. Ĝi estas vere efika.
TimescaleDB kaj PostgreSQL
Kiel certigas la fabrikantoj de TimescaleDB, ili uzas pli ĝustan algoritmon por prilabori demandojn, precipe enmetojn, kio ebligas al ili havi proksimume konstantan agadon kun kreskanta grandeco de la datumaro. Tio estas, post 200 milionoj da vicoj de Postgres, la kutima komencas tre multe malkreski kaj perdas rendimenton laŭvorte al nulo, dum Timescale permesas enmeti enmetojn kiel eble plej efike kun ajna kvanto da datumoj.
Kiel instali TimescaleDB? Ĝi estas simpla!
Ĝi estas en la dokumentado, ĝi estas priskribita - vi povas instali ĝin el pakoj por iu ajn... Ĝi dependas de la oficialaj pakaĵoj de Postgres. Povas esti kompilita permane. Okazis, ke mi devis kompili por la datumbazo.
Sur Zabbix ni simple aktivigas Extension. Mi pensas, ke tiuj, kiuj uzis Extention en Postgres... Vi simple aktivigas Extention, kreas ĝin por la Zabbix-datumbazo, kiun vi uzas.
Kaj la lasta paŝo...
TimecaleDB. Migrado de historiaj tabeloj
Vi devas krei hipertabelon. Estas speciala funkcio por ĉi tio - Krei hipertabelon. En ĝi, la unua parametro estas la tabelo, kiu estas bezonata en ĉi tiu datumbazo (por kiu vi bezonas krei hipertabelon).
La kampo per kiu krei, kaj chunk_time_interval (ĉi tiu estas la intervalo de pecoj (sekcioj kiuj devas esti uzataj). 86 estas unu tago.
Parametro Migrate_data: Se vi enigas al vera, tiam ĉi tio migras ĉiujn aktualajn datumojn al antaŭkreitaj pecoj.
Mi mem uzis migrate_data - ĝi bezonas sufiĉe da tempo, depende de kiom granda estas via datumbazo. Mi havis pli ol terabajton - necesis pli ol unu horo por krei. En kelkaj kazoj, dum testado, mi forigis historiajn datumojn por teksto (history_text) kaj ĉeno (history_str) por ne transdoni ilin - ili ne estis vere interesaj por mi.
Kaj ni faras la lastan ĝisdatigon en nia db_extention: ni instalas timescaledb por ke la datumbazo kaj, precipe, nia Zabbix komprenu, ke ekzistas db_extention. Li aktivigas ĝin kaj uzas la ĝustan sintakson kaj demandojn al la datumbazo, uzante tiujn "funkciojn", kiuj estas necesaj por TimescaleDB.
Servila agordo
Mi uzis du servilojn. La unua servilo estas sufiĉe malgranda virtuala maŝino, 20 procesoroj, 16 gigabajtoj da RAM. Mi agordis Postgres 10.8 sur ĝi:
La operaciumo estis Debian, la dosiersistemo estis xfs. Mi faris minimumajn agordojn por uzi ĉi tiun apartan datumbazon, minus kion Zabbix mem uzos. Sur la sama maŝino estis Zabbix-servilo, PostgreSQL kaj ŝarĝaj agentoj.
Mi uzis 50 aktivajn agentojn, kiuj uzas LoadableModule por rapide generi malsamajn rezultojn. Ili estas tiuj, kiuj generis la ŝnurojn, nombrojn, ktp. Mi plenigis la datumbazon per multaj datumoj. Komence, la agordo enhavis 5 mil datumelementojn per gastiganto, kaj proksimume ĉiu datumelemento enhavis ellasilon - por ke ĉi tio estu vera aranĝo. Kelkfoje vi eĉ bezonas pli ol unu ellasilon por uzi.
Mi reguligis la ĝisdatigan intervalon kaj la ŝarĝon mem ne nur uzante 50 agentojn (aldonante pli), sed ankaŭ uzante dinamikajn datumajn elementojn kaj reduktante la ĝisdatigan intervalon al 4 sekundoj.
Testo de rendimento. PostgreSQL: 36 mil NVP-oj
La unua lanĉo, la unua aranĝo, kiun mi havis, estis sur pura PostreSQL 10 sur ĉi tiu aparataro (35 mil valoroj por sekundo). Ĝenerale, kiel vi povas vidi sur la ekrano, enmeti datumojn prenas frakciojn de sekundo - ĉio estas bona kaj rapida, SSD-diskoj (200 gigabajtoj). La sola afero estas, ke 20 GB pleniĝas sufiĉe rapide.
Estos sufiĉe multe da tiaj grafikaĵoj estonte. Ĉi tio estas norma Zabbix-servila rendimentopanelo.
La unua grafikaĵo estas la nombro da valoroj por sekundo (blua, supre maldekstre), 35 mil valoroj en ĉi tiu kazo. Ĉi tio (supra centro) estas la ŝarĝo de konstruprocezoj, kaj ĉi tio (supre dekstre) estas la ŝarĝo de internaj procezoj: historiaj sinkroniloj kaj mastrumisto, kiu ĉi tie (malsupra centro) funkcias de sufiĉe da tempo.
Ĉi tiu grafikaĵo (malsupra centro) montras uzadon de ValueCache - kiom da ValueCache-trafoj por ellasiloj (kelkaj miloj da valoroj por sekundo). Alia grava grafikaĵo estas la kvara (malsupre maldekstre), kiu montras la uzon de HistoryCache, pri kiu mi parolis, kiu estas bufro antaŭ ol enmeti en la datumbazon.
Testo de rendimento. PostgreSQL: 50 mil NVP-oj
Poste, mi pliigis la ŝarĝon al 50 mil valoroj por sekundo sur la sama aparataro. Kiam ŝarĝita de Domservisto, 10 mil valoroj estis registritaj en 2-3 sekundoj kun kalkulo. Kio, fakte, estas montrita en la sekva ekrankopio:
"Domzorgisto" jam komencas malhelpi laboron, sed ĝenerale, la ŝarĝo sur historia-sinker-kaptistoj ankoraŭ estas je la nivelo de 60% (tria grafikaĵo, supre dekstre). HistoryCache jam komencas pleniĝi aktive dum Housekeeper funkcias (malsupre maldekstre). Ĝi estis ĉirkaŭ duona gigabajto, 20% plena.
Testo de rendimento. PostgreSQL: 80 mil NVP-oj
Tiam mi pliigis ĝin al 80 mil valoroj por sekundo:
Ĝi estis proksimume 400 mil datumelementoj, 280 mil ellasiloj. La enmetaĵo, kiel vi povas vidi, laŭ la ŝarĝo de historiaj sinkeroj (estis 30 da ili) estis jam sufiĉe alta. Tiam mi pliigis diversajn parametrojn: historiaj sinkers, kaŝmemoro... Sur ĉi tiu aparataro, la ŝarĝo sur historiaj sinkers komencis pliiĝi al la maksimumo, preskaŭ "sur la breto" - sekve, HistoryCache eniris tre altan ŝarĝon:
Dum ĉi tiu tempo mi monitoris ĉiujn sistemajn parametrojn (kiel la procesoro estas uzata, RAM) kaj malkovris, ke la uzado de disko estis maksimuma - mi atingis la maksimuman kapablon de ĉi tiu disko sur ĉi tiu aparataro, sur ĉi tiu virtuala maŝino. "Postgres" komencis forĵeti datumojn sufiĉe aktive je tia intenseco, kaj la disko ne plu havis tempon por skribi, legi...
Mi prenis alian servilon kiu jam havis 48 procesorojn kaj 128 gigabajtojn da RAM:
Mi ankaŭ "agordis" ĝin - instalis History syncer (60 pecoj) kaj atingis akcepteblan agadon. Fakte, ni ne estas "sur la breto", sed ĉi tio verŝajne estas la limo de produktiveco, kie jam necesas fari ion pri ĝi.
Testo de rendimento. TimescaleDB: 80 mil NVP-oj
Mia ĉefa tasko estis uzi TimescaleDB. Ĉiu grafikaĵo montras trempiĝon:
Ĉi tiuj fiaskoj estas ĝuste migrado de datumoj. Post tio, en la servilo Zabbix, la ŝarĝa profilo de historiaj sinkeroj, kiel vi povas vidi, multe ŝanĝiĝis. Ĝi permesas vin enmeti datumojn preskaŭ 3 fojojn pli rapide kaj uzi malpli HistoryCache - sekve, vi havos datumojn liveritaj ĝustatempe. Denove, 80 mil valoroj por sekundo estas sufiĉe alta indico (kompreneble, ne por Yandex). Ĝenerale ĉi tio estas sufiĉe granda aranĝo, kun unu servilo.
Testo de rendimento de PostgreSQL: 120 mil NVP-oj
Poste, mi pliigis la valoron de la nombro da datumelementoj al duona miliono kaj ricevis kalkulitan valoron de 125 mil sekundo:
Kaj mi ricevis ĉi tiujn grafikaĵojn:
En principo, ĉi tio estas funkcianta aranĝo, ĝi povas funkcii dum sufiĉe longa tempo. Sed ĉar mi havis nur 1,5 terabajtan diskon, mi uzis ĝin post kelkaj tagoj. La plej grava afero estas, ke samtempe novaj sekcioj estis kreitaj sur TimescaleDB, kaj tio estis tute nerimarkita por agado, kio ne povas esti dirita pri MySQL.
Tipe, sekcioj estas kreitaj nokte, ĉar tio ĝenerale blokas enmeton kaj labori kun tabloj kaj povas konduki al degenero de la servo. En ĉi tiu kazo tio ne estas la kazo! La ĉefa tasko estis testi la kapablojn de TimescaleDB. La rezulto estis la sekva figuro: 120 mil valoroj por sekundo.
Ekzistas ankaŭ ekzemploj en la komunumo:
La persono ankaŭ ŝaltis TimescaleDB kaj la ŝarĝo uzi io.weight falis sur la procesoro; kaj la uzo de internaj procezelementoj ankaŭ malpliiĝis pro la inkludo de TimescaleDB. Plie, ĉi tiuj estas ordinaraj patkukaj diskoj, tio estas, ordinara virtuala maŝino sur ordinaraj diskoj (ne SSD-oj)!
Por kelkaj malgrandaj aranĝoj, kiuj estas limigitaj de disko-efikeco, TimescaleDB, laŭ mi, estas tre bona solvo. Ĝi permesos al vi daŭrigi labori antaŭ ol migri al pli rapida aparataro por la datumbazo.
Mi invitas vin ĉiujn al niaj aranĝoj: Konferenco en Moskvo, Pintkunveno en Rigo. Uzu niajn kanalojn - Telegramo, forumo, IRC. Se vi havas demandojn, venu al nia skribotablo, ni povas paroli pri ĉio.
Spektantaro-Demandoj
Demando de la spektantaro (ĉi-poste - A): - Se TimescaleDB estas tiel facile agordebla, kaj ĝi donas tian rendimentan akcelon, tiam eble ĉi tio estu uzata kiel plej bona praktiko por agordi Zabbix kun Postgres? Kaj ĉu ekzistas malfacilaĵoj kaj malavantaĝoj de ĉi tiu solvo, aŭ finfine, se mi decidis fari Zabbix por mi mem, mi povas facile preni Postgres, instali Timescale tie tuj, uzi ĝin kaj ne pensi pri iuj problemoj?
AG: – Jes, mi dirus, ke ĉi tio estas bona rekomendo: uzu Postgres tuj kun la etendaĵo TimescaleDB. Kiel mi jam diris, multaj bonaj recenzoj, malgraŭ la fakto, ke ĉi tiu "trajto" estas eksperimenta. Sed efektive testoj montras, ke ĉi tio estas bonega solvo (kun TimescaleDB) kaj mi pensas, ke ĝi evoluos! Ni kontrolas kiel ĉi tiu etendo evoluas kaj faros ŝanĝojn laŭbezone.
Eĉ dum evoluo, ni fidis je unu el iliaj konataj "trajtoj": eblis labori kun pecoj iomete malsame. Sed tiam ili tranĉis ĝin en la sekva eldono, kaj ni devis ĉesi fidi je ĉi tiu kodo. Mi rekomendus uzi ĉi tiun solvon en multaj aranĝoj. Se vi uzas MySQL... Por averaĝaj agordoj, ajna solvo funkcias bone.
A: – Sur la lastaj grafikaĵoj de la komunumo, estis grafikaĵo kun "Domzorgisto":
Li daŭre laboris. Kion faras Housekeeper kun TimescaleDB?
AG: – Nun mi ne povas diri certe – mi rigardos la kodon kaj rakontos al vi pli detale. Ĝi uzas TimescaleDB-demandojn ne por forigi pecojn, sed por iel kunigi ilin. Mi ankoraŭ ne pretas respondi ĉi tiun teknikan demandon. Ni ekscios pli ĉe la stando hodiaŭ aŭ morgaŭ.
A: – Mi havas similan demandon – pri la agado de la foriga operacio en Timecale.
A (respondo de la spektantaro): – Kiam vi forigas datumojn de tabelo, se vi faras ĝin per forigo, tiam vi devas trairi la tabelon - forigi, purigi, marki ĉion por estonta vakuo. En Tempskalo, ĉar vi havas pecojn, vi povas faligi. Proksimume, vi simple diras al la dosiero, kiu estas en grandaj datumoj: "Forigi!"
Tempskalo simple komprenas, ke tia peco ne plu ekzistas. Kaj ĉar ĝi estas integrita en la konsultplanilon, ĝi uzas hokojn por kapti viajn kondiĉojn en elektitaj aŭ aliaj operacioj kaj tuj komprenas, ke ĉi tiu peco ne plu ekzistas - "Mi ne plu iros tien!" (datenoj ne haveblaj). Tio estas ĉio! Tio estas, tablo-skanado estas anstataŭigita per binara dosiera forigo, do ĝi estas rapida.
A: – Ni jam tuŝis la temon de ne-SQL. Laŭ mia kompreno, Zabbix ne vere bezonas modifi la datumojn, kaj ĉio ĉi estas io kiel protokolo. Ĉu eblas uzi specialajn datumbazojn, kiuj ne povas ŝanĝi siajn datumojn, sed samtempe multe pli rapide ŝpari, amasigi kaj disdoni - Clickhouse, ekzemple, io kafka-simila?... Kafka ankaŭ estas ŝtipo! Ĉu eblas iel integri ilin?
AG: - Malŝarĝo povas esti farita. Ni havas certan "trajton" ekde versio 3.4: vi povas skribi ĉiujn historiajn dosierojn, eventojn, ĉion alian al dosieroj; kaj poste sendu ĝin al iu ajn alia datumbazo uzante iun pritraktilon. Fakte, multaj homoj reverkas kaj skribas rekte al la datumbazo. Sur la flugo, historiaj sinkers skribas ĉion ĉi en dosierojn, turnas ĉi tiujn dosierojn, kaj tiel plu, kaj vi povas transdoni ĉi tion al Clickhouse. Mi ne povas diri pri planoj, sed eble plia subteno por NoSQL-solvoj (kiel ekzemple Clickhouse) daŭros.
A: – Ĝenerale, montriĝas, ke oni povas tute forigi postgres?
AG: – Kompreneble, la plej malfacila parto en Zabbix estas la historiaj tabeloj, kiuj kreas la plej multajn problemojn kaj eventojn. En ĉi tiu kazo, se vi ne konservas eventojn dum longa tempo kaj konservas la historion kun tendencoj en iu alia rapida stokado, tiam ĝenerale, mi pensas, ne estos problemoj.
A: – Ĉu vi povas taksi kiom pli rapide ĉio funkcios se vi ŝanĝas al Clickhouse, ekzemple?
AG: – Mi ne provis ĝin. Mi pensas, ke almenaŭ la samaj nombroj povas esti atingitaj tute simple, ĉar Clickhouse havas sian propran interfacon, sed mi ne povas diri certe. Estas pli bone testi. Ĉio dependas de la agordo: kiom da gastigantoj vi havas, ktp. Enmeti estas unu afero, sed vi ankaŭ devas preni ĉi tiujn datumojn - Grafana aŭ io alia.
A: – Do ni parolas pri egala batalo, kaj ne pri la granda avantaĝo de tiuj rapidaj datumbazoj?
AG: – Mi pensas, kiam ni integriĝos, estos pli precizaj testoj.
A: – Kien iris bona maljuna RRD? Kio igis vin ŝanĝi al SQL-datumbazoj? Komence, ĉiuj metrikoj estis kolektitaj sur RRD.
AG: – Zabbix havis RRD, eble en tre antikva versio. Ĉiam ekzistis SQL-datumbazoj - klasika aliro. La klasika aliro estas MySQL, PostgreSQL (ili ekzistas de tre longa tempo). Ni preskaŭ neniam uzis komunan interfacon por SQL kaj RRD-datumbazoj.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com