Fighjemu cumu Zabbix travaglia cù a basa di dati TimescaleDB cum'è u backend. Vi mustraremu cumu cumincià da zero è cumu migrate da PostgreSQL. Puderemu ancu prove di rendiment comparativu di e duie cunfigurazioni.
HighLoad++ Siberia 2019. Tomsk Hall. 24 ghjugnu, 16 ore. Tesi è . A prossima cunferenza HighLoad++ si terrà u 6 è u 7 d'aprile di u 2020 in San Pietroburgo. Dettagli è biglietti .
Andrey Gushchin (in seguitu - AG): - Sò un ingegnere di supportu tecnicu ZABBIX (in seguitu chjamatu "Zabbix"), un trainer. Aghju travagliatu in supportu tecnicu per più di 6 anni è aghju avutu una sperienza diretta cù u rendiment. Oghje parraraghju di u funziunamentu chì TimescaleDB pò furnisce quandu paragunatu cù PostgreSQL regularmente 10. Inoltre, qualchì parte introduttiva nantu à cumu si travaglia in generale.
Principali sfide di produttività: da a raccolta di dati à a pulizia di dati
Per principià, ci sò certe sfide di rendiment chì ogni sistema di monitoraghju face. U primu sfida di produtividade hè di cullà è di trasfurmà e dati rapidamente.
Un bon sistema di surviglianza deve riceve rapidamente, in tempu puntuale tutte e dati, processà secondu l'espressioni di attivazione, vale à dì, processà secondu certi criterii (questu hè diversu in diversi sistemi) è salvà in una basa di dati per aduprà sta dati in u futuru.
A seconda sfida di rendiment hè u almacenamentu di a storia. Stoccate in una basa di dati spessu è avete un accessu rapidu è convenientu à queste metriche chì sò state cullate per un periudu di tempu. A più impurtante hè chì sta dati hè cunvenutu per ottene, l'utilizanu in rapporti, gràfiche, triggers, in certi valori di soglia, per alerti, etc.
A terza sfida di u rendiment hè a storia di clarificazione, vale à dì, quandu avete ghjuntu à u puntu induve ùn avete micca bisognu di guardà alcuna metrica dettagliata chì hè stata cullata annantu à 5 anni (ancu mesi o dui mesi). Certi nodi di a rete sò stati sguassati, o certi òspiti, i metrichi ùn sò più necessarii perchè sò digià obsoleti è ùn sò più raccolti. Tuttu chistu deve esse puliti per chì a vostra basa di dati ùn cresce micca troppu grande. In generale, a storia di sguassà hè più spessu una prova seria per l'almacenamiento - spessu influenza assai u rendiment.
Cumu risolve i prublemi di cache?
Ora parleraghju specificamente di Zabbix. In Zabbix, a prima è a seconda chjama sò risolte cù u caching.
Raccolta di dati è trasfurmazioni - Utilizemu RAM per almacenà tutte queste dati. Questi dati seranu avà discututi in più detail.
Ancu in u latu di a basa di dati ci hè qualchì caching per e selezioni principali - per i grafici è altre cose.
Caching in u latu di u servitore Zabbix stessu: avemu ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Chì ghjè ?
ConfigurationCache hè a cache principale in quale guardemu metriche, hosts, data items, triggers; tuttu ciò chì avete bisognu di processà preprocessing, cullà dati, da quale l'ospiti per cullà, cù quale frequenza. Tuttu chistu hè guardatu in ConfigurationCache per ùn andà in a basa di dati è creà dumande innecessarii. Dopu chì u servitore principia, aghjurnà sta cache (create) è aghjurnà periòdicamenti (secondu i paràmetri di cunfigurazione).
Caching in Zabbix. Raccolta di dati
Quì u diagramma hè abbastanza grande:
I principali in u schema sò sti cullettori:
Quessi sò i prucessi di assemblea stessi, diversi "pollers" chì sò rispunsevuli di diversi tipi di assemblee. Raccoglienu dati via icmp, ipmi è diversi protokolli è trasfirìanu tuttu à preprocessing.
Preprocessing HistoryCache
Inoltre, s'è no avemu calculatu elementi di dati (quelli chì sò pràticu cù Zabbix cunnosce), vale à dì, calculate, elementi di dati aggregation, avemu pigliatu direttamente da ValueCache. Vi dicu cumu si riempie dopu. Tutti questi cullettori utilizanu ConfigurationCache per riceve u so travagliu è poi trasmettenu à u preprocessing.
U preprocessing usa ancu ConfigurationCache per ottene passi di preprocessing è processa sta dati in diversi modi. Partendu da a versione 4.2, l'avemu trasladatu à un proxy. Questu hè assai cunvenutu, perchè u preprocessing stessu hè una operazione piuttostu difficiule. È s'è vo avete un Zabbix assai grande, cù un gran numaru di elementi di dati è una freccia di cullizzioni alta, allura stu simplificheghja assai u travagliu.
In cunsiquenza, dopu avè trattatu sta dati in qualchì modu utilizendu preprocessing, salvemu in HistoryCache per processà più. Questu cuncludi a cullizzioni di dati. Passemu à u prucessu principale.
U travagliu di u Syncer di Storia
U prucessu principale in Zabbix (poi ch'ellu hè una architettura monolitica) hè Syncer Storia. Questu hè u prucessu principale chì tratta specificamente di u processu atomicu di ogni elementu di dati, vale à dì ogni valore:
- u valore vene (piglia da HistoryCache);
- cuntrolla in u Configurazione syncer: s'ellu ci hè qualchì trigger per u calculu - li calcula;
s'ellu ci hè - crea avvenimenti, crea escalation per creà una alerta, se ne necessariu secondu a cunfigurazione; - registra triggers per u processu, aggregazione sussegwenti; se aggregate annantu à l'ultima ora è cusì, stu valore hè ricurdatu da ValueCache per ùn andà à a tavula di a storia; Cusì, u ValueCache hè chinu di e dati necessarii chì hè necessariu per calculà triggers, elementi calculati, etc.;
- tandu History syncer scrive tutti i dati à a basa di dati;
- a basa di dati li scrive nantu à u discu - questu hè induve u prucessu di trasfurmazioni finisci.
basa di dati. Caching
In u latu di a basa di dati, quandu vulete vede gràfiche o qualchi rapporti nantu à l'avvenimenti, ci sò diversi cache. Ma in questu rapportu ùn ne parleraghju micca.
Per MySQL ci hè Innodb_buffer_pool, è una mansa di diverse cache chì ponu ancu esse cunfigurate.
Ma questi sò i principali:
- shared_buffers;
- effettiva_cache_size;
- pool_spartitu.
Per tutte e basa di dati, aghju dettu chì ci sò certi cache chì permettenu di almacenà in RAM a dati chì hè spessu necessariu per e dumande. Hanu a so propria tecnulugia per questu.
À propositu di u rendiment di a basa di dati
In cunsiquenza, ci hè un ambiente cumpetitivu, vale à dì, u servitore Zabbix raccoglie dati è registra. Quandu si riavvia, leghje ancu da a storia per riempie u ValueCache è cusì. Quì pudete avè scripts è rapporti chì utilizanu l'API Zabbix, chì hè custruitu nantu à una interfaccia web. Zabbix API entra in a basa di dati è riceve i dati necessarii per ottene grafici, rapporti, o qualchì tipu di lista di avvenimenti, prublemi recenti.
Ancu una suluzione di visualizazione assai populari hè Grafana, chì i nostri utilizatori utilizanu. Capace di accede direttamente sia attraversu l'API Zabbix sia attraversu a basa di dati. Crea ancu una certa cumpetizione per l'ottene di dati: una sintonizazione più fina è megliu di a basa di dati hè necessariu per rispettà a consegna rapida di risultati è teste.
Storia di sguassà. Zabbix hà una governante
A terza chjama chì hè aduprata in Zabbix hè di sguassà a storia cù Housekeeper. Housekeeper seguita tutti i paràmetri, vale à dì, i nostri elementi di dati indicanu quantu tempu per almacenà (in ghjorni), quantu tempu per almacenà e tendenzi, è a dinamica di i cambiamenti.
Ùn aghju micca parlatu di TrendCache, chì calculemu à a mosca: i dati arrivanu, l'avemu aggregatu per una ora (per suprattuttu questi sò numeri per l'ultima ora), a quantità hè media / minima è l'arregistremu una volta à l'ora in u tabella di a dinamica di i cambiamenti ("Trends"). "Housekeeper" principia è sguassate e dati da a basa di dati utilizendu selezzione regulare, chì ùn hè micca sempre efficace.
Cumu capisce chì hè inefficace? Pudete vede a seguente stampa nantu à i grafici di rendiment di i prucessi interni:
U vostru sincronizatore di Storia hè constantemente occupatu (graficu rossu). È u graficu "rossu" chì và in cima. Questu hè un "Housekeeper" chì principia è aspetta chì a basa di dati per sguassà tutte e fila chì hà specificatu.
Pigliemu qualchi Item ID: avete bisognu di sguassà l'ultimi 5 mila; di sicuru, per indici. Ma di solitu u dataset hè abbastanza grande - a basa di dati sempre leghje da u discu è u mette in a cache, è questu hè una operazione assai caru per a basa di dati. Sicondu a so dimensione, questu pò purtà à certi prublemi di rendiment.
Pudete disattivà Housekeeper in una manera simplice - avemu una interfaccia web familiar. Paràmetri in Amministrazione generale (parametri per "Housekeeper") disattivemu a pulizia interna per a storia interna è e tendenze. Dunque, Housekeeper ùn cuntrolla più questu:
Chì pudete fà dopu? L'avete disattivatu, i vostri gràfici sò sbulicati... Chì altri prublemi puderanu nasce in questu casu ? Chì pò aiutà?
spartizione (sectioning)
Di genere, questu hè cunfiguratu in una manera diversa nantu à ogni basa di dati relazionale chì aghju listatu. MySQL hà a so propria tecnulugia. Ma in generale sò assai simili quandu si tratta di PostgreSQL 10 è MySQL. Di sicuru, ci sò assai differenze interne in quantu hè implementatu è cumu tuttu affetta u rendiment. Ma in generale, a creazione di una nova partizione spessu porta ancu à certi prublemi.
Sicondu a vostra cunfigurazione (quantu dati create in un ghjornu), sò generalmente stabilitu u minimu - questu hè 1 ghjornu / batch, è per "tendenze", dinamica di cambiamenti - 1 mese / novu batch. Questu pò cambià se avete una configurazione assai grande.
Dicemu subitu nantu à a dimensione di a cunfigurazione: finu à 5 mila novi valori per seconda (i cosiddetti nvps) - questu serà cunsideratu un picculu "setup". Media - da 5 à 25 mila valori per seconda. Tuttu ciò chì hè sopra hè digià stallazione grande è assai grande chì richiede una cunfigurazione assai attenta di a basa di dati.
In installazioni assai grande, 1 ghjornu pò esse micca ottimali. Personalmente aghju vistu partizioni in MySQL di 40 gigabytes per ghjornu (è pò esse più). Quissa hè una quantità assai grande di dati, chì pò purtà à qualchi prublemi. Hè bisognu à esse ridutta.
Perchè avete bisognu di partizioni?
Ciò chì u Partitioning furnisce, pensu chì tutti sanu, hè a particionazione di a tavola. Spessu si tratta di schedarii separati nantu à e dumande di discu è span. Selezziunate una partizione più ottimali s'ellu face parte di a partizione normale.
Per Zabbix, in particulare, hè utilizatu per range, by range, vale à dì, avemu usatu un timestamp (un numeru regulare, tempu da u principiu di l'epica). Specificate l'iniziu di u ghjornu / a fine di u ghjornu, è questu hè a partizione. In cunsiquenza, s'è vo dumandate dati chì sò dui ghjorni, tuttu hè ritruvatu da a basa di dati più veloce, perchè solu bisognu di carricà un schedariu in a cache è rinvià (invece di una grande tavola).
Parechje basa di dati acceleranu ancu l'inserimentu (inserimentu in una tabella di u zitellu). Parlu in astrattu per avà, ma questu hè ancu pussibule. A partitura spessu aiuta.
Elasticsearch per NoSQL
Ricertamenti, in 3.4, avemu implementatu una suluzione NoSQL. Aggiunta a capacità di scrive in Elasticsearch. Pudete scrive certi tipi: sceglite - sia scrivite numeri o qualchi segni; avemu un testu di stringa, pudete scrive logs à Elasticsearch... Per quessa, l'interfaccia web accede ancu à Elasticsearch. Questu travaglia assai in certi casi, ma in u mumentu pò esse usatu.
TimecaleDB. Hypertables
Per 4.4.2 avemu attentu à una cosa cum'è TimescaleDB. Chì ghjè ? Questa hè una estensione per PostgreSQL, vale à dì, hà una interfaccia PostgreSQL nativa. In più, sta estensione permette di travaglià in modu assai più efficau cù dati di serie temporale è avè un particionamentu automaticu. Ciò chì pare:
Questu hè hypertable - ci hè un tali cuncettu in Timescale. Questa hè una ipertavule chì create, è cuntene chunks. Chunks sò partizioni, queste sò tavule di zitelli, se ùn sò micca sbagliatu. Hè veramente efficace.
TimescaleDB è PostgreSQL
Cum'è i pruduttori di TimescaleDB assicuranu, utilizanu un algoritmu più currettu per processà e dumande, in particulare inseriti, chì permette un rendimentu apprussimatamente constantu cù una dimensione crescente di l'inseritu di dataset. Questu hè, dopu à 200 milioni di fila di Postgres, u solitu cumencia à sag assai è perde a prestazione literalmente à zero, mentre chì Timescale permette di inserisce inserisce in modu efficacimente pussibule cù qualsiasi quantità di dati.
Cumu installà TimescaleDB? Hè simplice!
Hè in a documentazione, hè discrittu - pudete installà da i pacchetti per qualsiasi ... Dipende da i pacchetti ufficiali di Postgres. Pò esse compilatu manualmente. Hè accadutu chì aghju avutu a compilazione per a basa di dati.
Nantu à Zabbix, avemu solu attivà Extension. Pensu chì quelli chì anu utilizatu Extension in Postgres ... Simply attivate Extension, creanu per a basa di dati Zabbix chì avete aduprà.
È l'ultimu passu...
TimecaleDB. Migrazione di tavule di storia
Avete bisognu di creà un hypertable. Ci hè una funzione speciale per questu - Crea hypertable. In questu, u primu paràmetru hè a tavola chì hè necessariu in questa basa di dati (per quale avete bisognu di creà un hypertable).
U campu da quale creà, è chunk_time_interval (questu hè l'intervallu di chunks (partizioni chì deve esse usatu). 86 hè un ghjornu.
Migrate_data paràmetru: Se inserite à veru, allora questu migrarà tutte e dati attuali in pezzi pre-creati.
Aghju utilizatu migrate_data stessu - ci vole una bona quantità di tempu, secondu quantu hè grande a vostra basa di dati. Aghju avutu più di un terabyte - hà pigliatu più di una ora per creà. In certi casi, durante a prova, aghju sguassatu i dati storichi per u testu (history_text) è string (history_str) per ùn trasfirili - ùn eranu micca veramente interessanti per mè.
E facemu l'ultima aghjurnazione in a nostra db_extention: installemu timescaledb per chì a basa di dati è, in particulare, u nostru Zabbix capisce chì ci hè db_extention. L'attiva è usa a sintassi curretta è e dumande à a basa di dati, utilizendu quelli "caratteristiche" chì sò necessarii per TimescaleDB.
Cunfigurazione di u servitore
Aghju utilizatu dui servitori. U primu servitore hè una macchina virtuale abbastanza chjuca, 20 processori, 16 gigabytes di RAM. Aghju cunfiguratu Postgres 10.8 nantu à questu:
U sistema operatore era Debian, u sistema di fugliale era xfs. Aghju fattu paràmetri minimi per utilizà sta basa di dati particulari, minus chì Zabbix stessu aduprà. Nant'à a stessa macchina ci era un servitore Zabbix, PostgreSQL è agenti di carica.
Aghju utilizatu 50 agenti attivi chì utilizanu LoadableModule per generà rapidamente risultati diffirenti. Sò quelli chì generanu e corde, numeri, è cusì. Aghju pienu a basa di dati cù assai dati. Inizialmente, a cunfigurazione cuntene 5 mila elementi di dati per host, è apprussimatamente ogni elementu di dati cuntene un trigger - per esse una vera configurazione. Calchì volta avete ancu bisognu di più di un trigger per aduprà.
Aghju regulatu l'intervallu di l'aghjurnamentu è a carica stessu micca solu cù l'agenti 50 (aghjunghjendu più), ma ancu cù elementi di dati dinamichi è riducendu l'intervallu d'aghjurnamentu à 4 seconde.
Test di rendiment. PostgreSQL: 36 mila NVP
U primu lanciu, a prima installazione chì aghju avutu era in pura PostreSQL 10 nantu à questu hardware (35 mila valori per seconda). In generale, cum'è pudete vede nantu à u screnu, l'inserimentu di dati piglia frazioni di un secondu - tuttu hè bonu è veloce, unità SSD (200 gigabytes). L'unica cosa hè chì 20 GB si riempie abbastanza rapidamente.
Ci sarà assai di tali grafici in u futuru. Questu hè un dashboard standard di prestazione di u servitore Zabbix.
U primu graficu hè u numeru di valori per seconda (blu, cima left), 35 mila valori in questu casu. Questu (in cima à u centru) hè a carica di i prucessi di custruzzione, è questu (in cima à a diritta) hè a carica di i prucessi internu: i sincronizatori di a storia è a domestica, chì quì (in fondu à u centru) hè in esecuzione per un bellu pezzu.
Stu graficu (in fondu in u centru) mostra l'usu di ValueCache - quanti hits ValueCache per triggers (parechji millai di valori per seconda). Un altru graficu impurtante hè u quartu (in fondu à manca), chì mostra l'usu di HistoryCache, chì aghju parlatu, chì hè un buffer prima di inserisce in a basa di dati.
Test di rendiment. PostgreSQL: 50 mila NVP
Dopu, aghju aumentatu a carica à 50 mila valori per seconda nantu à u stessu hardware. Quandu hà caricatu da Housekeeper, 10 mila valori sò stati registrati in 2-3 seconde cù u calculu. Ciò chì, in fattu, hè mostratu in a seguente screenshot:
"Housekeeper" hè digià principiatu à interferiscenu cù u travagliu, ma in generale a carica nantu à i trappers di a storia-sinker hè sempre à u livellu di 60% (terzu graficu, in cima à diritta). HistoryCache cumencia digià à riempie attivamente mentre Housekeeper hè in esecuzione (in fondu à sinistra). Era circa a mità di gigabyte, 20% pienu.
Test di rendiment. PostgreSQL: 80 mila NVP
Allora aghju aumentatu à 80 mila valori per seconda:
Era circa 400 mila elementi di dati, 280 mila triggers. L'inseritu, cum'è pudete vede, in quantu à a carica di i sinkers di a storia (ci era 30 d'elli) era digià abbastanza altu. Allora aghju aumentatu parechji paràmetri: i sinkers di storia, cache... In questu hardware, a carica nantu à i sinkers di a storia hà cuminciatu à aumentà à u massimu, quasi "nantu à a scaffale" - per quessa, HistoryCache andò in una carica assai alta:
Tuttu stu tempu aghju monitoratu tutti i paràmetri di u sistema (cumu u processatore hè utilizatu, RAM) è scupertu chì l'utilizazione di u discu era massimu - aghju ottinutu a capacità massima di stu discu nantu à questu hardware, in questa macchina virtuale. "Postgres" hà cuminciatu à dump data abbastanza attivamente à una tale intensità, è u discu ùn hà più tempu di scrive, leghje ...
Aghju pigliatu un altru servitore chì avia digià 48 processori è 128 gigabyte di RAM:
L'aghju ancu "sintonizatu" - installatu Storia syncer (60 pezzi) è ottenutu un rendiment accettabile. In fatti, ùn simu micca "nantu à a scaffale", ma questu hè probabilmente u limitu di a produtividade, induve hè digià necessariu di fà qualcosa.
Test di rendiment. TimescaleDB: 80 mila NVP
U mo compitu principale era di utilizà TimescaleDB. Ogni graficu mostra un dip:
Questi fallimenti sò precisamente migrazione di dati. Dopu à quessa, in u servore Zabbix, u prufilu di carica di i sinkers di a storia, cum'è pudete vede, hà cambiatu assai. Permette di inserisce dati guasi 3 volte più veloce è aduprà menu HistoryCache - in cunsiquenza, averete dati consegnati à tempu. In novu, 80 mila valori per seconda hè una tarifa abbastanza alta (di sicuru, micca per Yandex). In generale, questa hè una configurazione abbastanza grande, cù un servitore.
Test di rendiment PostgreSQL: 120 mila NVP
Dopu, aghju aumentatu u valore di u numeru di elementi di dati à a mità di milione è hà ricevutu un valore calculatu di 125 mila per seconda:
È aghju avutu sti grafici:
In principiu, questu hè un setup di travagliu, pò travaglià per un bellu pezzu. Ma postu ch'e aghju avutu solu un discu di 1,5 terabyte, l'aghju utilizatu in un paru di ghjorni. A più impurtante hè chì à u stessu tempu sò stati creati novi partizioni nantu à TimescaleDB, è questu era completamente inosservatu per u rendiment, chì ùn pò micca esse dettu di MySQL.
Di genere, i partizioni sò creati di notte, perchè questu generalmente blucca l'inserzione è u travagliu cù tavule è pò purtà à a degradazione di u serviziu. In questu casu ùn hè micca u casu! U compitu principale era di pruvà e capacità di TimescaleDB. U risultatu hè a seguente figura: 120 mila valori per seconda.
Ci sò ancu esempi in a cumunità:
A persona hà ancu attivatu TimescaleDB è a carica nantu à l'usu di io.weight caduta nantu à u processatore; è l'usu di elementi di prucessu internu hè ancu diminuitu per l'inclusione di TimescaleDB. Inoltre, questi sò dischi di pancake ordinariu, vale à dì una macchina virtuale ordinaria nantu à i dischi ordinali (micca SSD)!
Per certi picculi setups chì sò limitati da u rendiment di u discu, TimescaleDB, in my opinion, hè una suluzione assai bona. Vi permetterà di cuntinuà à travaglià prima di migrà à un hardware più veloce per a basa di dati.
Vi invitu tutti à i nostri avvenimenti: Conferenza in Mosca, Summit in Riga. Aduprate i nostri canali - Telegram, forum, IRC. Sì avete qualchì quistione, venite à u nostru desk, pudemu parlà di tuttu.
Domande di u publicu
Quistione da l'audienza (in seguitu - A): - Se TimescaleDB hè cusì faciule da cunfigurà, è dà un tali impulsu di rendiment, allora forse questu deve esse usatu cum'è una pratica megliu per cunfigurà Zabbix cù Postgres? E ci sò trappule è svantaghji di sta suluzione, o dopu tuttu, se decisu di fà Zabbix per mè stessu, possu facilmente piglià Postgres, installà Timescale quì subitu, l'utilizanu è ùn pensate micca à qualsiasi prublema ?
AG: - Iè, diceraghju chì questu hè una bona ricumandazione: utilizate Postgres immediatamente cù l'estensione TimescaleDB. Comu dissi, assai boni critichi, malgradu u fattu chì sta "funzione" hè sperimentale. Ma in realtà i testi mostranu chì questa hè una grande suluzione (cù TimescaleDB) è pensu chì evolverà! Monitoremu cumu si sviluppa sta estensione è faremu cambiamenti in quantu necessariu.
Ancu durante u sviluppu, avemu basatu nantu à una di e so "caratteristiche" ben cunnisciute: era pussibule di travaglià cù pezzi un pocu sfarente. Ma dopu l'anu tagliatu in a prossima versione, è avemu avutu a piantà di cunfidendu stu codice. Avissi cunsigliatu d'utilizà sta suluzione in parechje cunfigurazioni. Sè vo aduprate MySQL... Per setups mediu, ogni suluzione funziona bè.
A: - In l'ultimi grafici di a cumunità, ci era un graficu cù "Housekeeper":
Hà cuntinuatu à travaglià. Chì faci Housekeeper cù TimescaleDB?
AG: - Avà ùn possu micca dì sicuru - Fighjuleraghju u codice è vi dicu in più detail. Utilizà e dumande di TimescaleDB micca per sguassà pezzi, ma per aggregali in qualchì modu. Ùn sò micca pronta à risponde à sta quistione tecnica. Ne sapemu di più à u stand oghje o dumane.
A: - Aghju una quistione simili - nantu à u funziunamentu di l'operazione di sguassà in Timescale.
A (risposta da l'audienza): - Quandu sguassate dati da una tavula, se fate per sguassà, allora avete bisognu di passà per u tavulu - sguassate, pulite, marcate tuttu per u futuru vacuum. In Timescale, postu chì avete pezzi, pudete calà. À pocu pressu, basta à dì à u schedariu chì hè in big data: "Sguassate!"
Timecale capisce solu chì un tali pezzu ùn esiste più. E postu chì hè integratu in u pianificatore di query, usa ganci per catturà e vostre cundizioni in selezzione o altre operazioni è capisce immediatamente chì questu pezzu ùn esiste più - "Ùn ci andaraghju più!" (dati micca dispunibili). Eccu tuttu! Questu hè, una scansione di a tavula hè rimpiazzata da una eliminazione di u schedariu binariu, cusì hè veloce.
A: - Avemu digià toccu u tema di non-SQL. Quantu aghju capitu, Zabbix ùn hà micca veramente bisognu di mudificà i dati, è tuttu questu hè qualcosa cum'è un log. Hè pussibule di utilizà basa di dati specializate chì ùn ponu micca cambià i so dati, ma à u stessu tempu salvà, accumule è distribuisce assai più veloce - Clickhouse, per esempiu, qualcosa Kafka-like?... Kafka hè ancu un logu! Hè pussibule d'integralli in qualchì modu?
AG: - U scaricamentu pò esse fattu. Avemu una certa "funzione" da a versione 3.4: pudete scrive tutti i schedarii storichi, avvenimenti, tuttu u restu à i schedari; è poi mandatu à qualsiasi altra basa di dati utilizendu un gestore. In fatti, assai persone rielaboranu è scrivenu direttamente à a basa di dati. À a mosca, i sinkers di a storia scrivenu tuttu questu in i schedari, rotate questi schedari, è cusì, è pudete trasfiriri questu à Clickhouse. Ùn possu micca dì di i piani, ma forsi un supportu supplementu per i suluzioni NoSQL (cum'è Clickhouse) continuarà.
A: – In generale, si trova chì pudete sguassate cumplettamente di postgres ?
AG: – Di sicuru, a parte più difficiuli in Zabbix hè i tavule storichi, chì creanu a maiò parte di prublemi è avvenimenti. In questu casu, sè ùn avete micca guardatu avvenimenti per un bellu pezzu è guardate a storia cù tendenzi in qualchì altru almacenamentu veloce, allora in generale, pensu, ùn ci sarà micca prublemi.
A: - Pudete stimà quantu più veloce tuttu u travagliu si cambia à Clickhouse, per esempiu?
AG: - Ùn aghju micca pruvatu. Pensu chì almenu i stessi numeri ponu esse ottenuti abbastanza simplice, datu chì Clickhouse hà a so propria interfaccia, ma ùn possu micca dì sicuru. Hè megliu à pruvà. Tuttu dipende di a cunfigurazione: quanti ospiti avete, è cusì. L'inserimentu hè una cosa, ma ancu avete bisognu di ricuperà sta dati - Grafana o qualcosa altru.
A: – Allora parlemu di una lotta uguale, è micca di u grande vantaghju di sti basa di dati veloci ?
AG: - Pensu chì quandu avemu integratu, ci saranu teste più precise.
A: – Induve hè andatu u bonu vechju RRD ? Chì ci hà fattu passà à basa di dati SQL? Inizialmente, tutte e metriche sò state cullate in RRD.
AG: - Zabbix avia RRD, forsi in una versione assai antica. Ci sò sempre stati basa di dati SQL - un approcciu classicu. L'approcciu classicu hè MySQL, PostgreSQL (esistinu per un tempu assai longu). Ùn avemu quasi mai usatu una interfaccia cumuna per e basa di dati SQL è RRD.
Certi annunzii 🙂
Grazie per stà cun noi. Ti piace i nostri articuli ? Vulete vede più cuntenutu interessante? Supportaci facendu un ordine o ricumandendu à l'amichi, , un analogu unicu di servitori di livellu d'entrata, chì hè statu inventatu da noi per voi: (dispunibule cù RAID1 è RAID10, finu à 24 core è finu à 40GB DDR4).
Dell R730xd 2 volte più prezzu in u centru di dati Equinix Tier IV in Amsterdam? Solu quì in l'Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $ 99! Leghje circa
Source: www.habr.com