Esamineremo il funzionamento di Zabbix con il database TimescaleDB come backend. Mostreremo come avviarlo da zero e come migrare da PostgreSQL. Presenteremo inoltre test comparativi delle performance delle due configurazioni.
HighLoad++ Siberia 2019. Sala "Tomsk". 24 giugno, 16:00. Tesi e . La prossima conferenza HighLoad++ si terrà il 6 e 7 aprile 2020 a San Pietroburgo. Maggiori dettagli e biglietti .
Andrey Gushchin (di seguito – AG): – Sono un ingegnere di supporto tecnico di ZABBIX (di seguito – "Zabbix"), formatore. Lavoro da oltre 6 anni nel supporto tecnico e mi sono occupato direttamente delle performance. Oggi parlerò delle performance che TimescaleDB può fornire, in confronto con il comune PostgreSQL 10. Cuore della presentazione sarà anche una parte introduttiva – su come funziona in generale.
Le principali sfide delle performance: dalla raccolta alla pulizia dei dati
Iniziamo col dire che ci sono determinate sfide delle performance con cui ogni sistema di monitoraggio si confronta. La prima sfida delle performance è la rapida raccolta e elaborazione dei dati.
Un buon sistema di monitoraggio deve ricevere tempestivamente tutti i dati, elaborarli secondo le espressioni di trigger, cioè elaborare in base a determinati criteri (che variano da sistema a sistema) e archiviarli nel database, in modo da poterli utilizzare successivamente.
La seconda sfida delle performance è lo stoccaggio della storia. È fondamentale conservare i dati nel database e avere accesso rapido e conveniente a queste metriche raccolte in un certo periodo di tempo. L'importante è poter ottenere facilmente questi dati e utilizzarli nei report, nei grafici, nei trigger e nei valori soglia, per le notifiche, ecc.
La terza sfida delle performance è la pulizia della storia, cioè quando arriva il momento in cui non è più necessario conservare metriche dettagliate raccolte per 5 anni (anche solo per mesi o due mesi). Alcuni nodi della rete sono stati rimossi, o alcuni host, e le metriche non sono più necessarie perché sono diventate obsolete e non vengono più raccolte. Tutto questo deve essere rimosso per evitare che il database cresca eccessivamente. Inoltre, la pulizia della storia è spesso una seria prova per l'archiviazione, influenzando notevolmente le performance.
Come risolvere i problemi di caching?
Ora parlerò specificamente di «Zabbix». In «Zabbix» le prime due chiamate sono risolte tramite caching.
Raccolta e elaborazione dei dati – utilizziamo la memoria RAM per memorizzare tutti questi dati. A breve verrà fornito un approfondimento su questi dati.
C'è anche un certo caching sul lato del database per le selezioni principali – per i grafici e altre cose.
Caching sul lato del server Zabbix stesso: abbiamo ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Che cos'è?
ConfigurationCache è la cache principale in cui memorizziamo metriche, host, elementi di dati, trigger; tutto ciò che è necessario per l'elaborazione del preprocessing, la raccolta dei dati, da quali host raccogliere e con quale frequenza. Tutto questo è memorizzato in ConfigurationCache, per evitare di dover accedere al database e creare richieste inutili. Dopo l'avvio del server, aggiorniamo questa cache (creiamo) e la aggiorniamo periodicamente (in base alle impostazioni di configurazione).
Caching in Zabbix. Raccolta dei dati
Qui lo schema è abbastanza grande:
I principali nello schema sono questi raccoglitori:
Sono i processi di raccolta stessi, diversi "poller", che sono responsabili di diversi tipi di raccolta. Raccolgono dati tramite icmp, ipmi e vari protocolli e trasferiscono tutto questo al preprocessing.
PreProcessing HistoryCache
Inoltre, se abbiamo elementi di dati calcolati (chi è familiare con «Zabbix» lo sa), ci sono elementi di dati calcolati e aggregati, li preleviamo direttamente da ValueCache. Spiegherò più avanti come viene riempita. Tutti questi raccoglitori utilizzano ConfigurationCache per ottenere i propri compiti e poi trasferiscono al preprocessing.
Il preprocessing utilizza anche ConfigurationCache per ottenere i passaggi di preprocessing, elaborando questi dati in vari modi. A partire dalla versione 4.2, è stato spostato sul proxy. È molto comodo, perché il preprocessing è un'operazione piuttosto pesante. E se hai un «Zabbix» molto grande, con un elevato numero di elementi di dati e alta frequenza di raccolta, questo facilita notevolmente il lavoro.
Di conseguenza, dopo aver elaborato questi dati in un certo modo tramite il preprocessing, li salviamo in HistoryCache per ulteriori elaborazioni. Qui termina la raccolta dei dati. Passiamo al processo principale.
Funzione di sincronizzazione della cronologia
Il processo principale in «Zabbix» (dato che ha un'architettura monolitica) è l'History syncer. Questo è il processo principale che si occupa dell'elaborazione atomica di ogni singolo elemento di dati, ovvero di ogni valore:
- arriva un valore (lo prende da HistoryCache);
- controlla nel Configuration syncer: ci sono trigger per il calcolo? Li calcola;
se ci sono, crea eventi, crea un'escalation per generare una notifica se necessario in base alla configurazione; - registra i trigger per elaborazioni e aggregazioni future; se aggrega nell'ultima ora e così via, questo valore viene memorizzato in ValueCache, per non dover accedere alla tabella storica; in questo modo, ValueCache si riempie di dati necessari per il calcolo dei trigger, degli elementi calcolati, ecc.;
- successivamente, l'History syncer scrive tutti i dati nel database;
- il database li scrive su disco – a questo punto, il processo di elaborazione termina.
Database. Caching
Dalla parte del DB, quando vuoi visualizzare grafici o report sugli eventi, ci sono diversi cache. Ma nel contesto di questa relazione, non parlerò di essi.
Per MySQL c'è Innodb_buffer_pool, oltre a un mucchio di vari cache che possono anche essere configurati.
Ma questi sono i principali:
- shared_buffers;
- effective_cache_size;
- shared_pool.
Ho portato per tutti i database che ci sono certi cache, che permettono di mantenere in memoria i dati che sono frequentemente necessari per le query. Lì hanno le loro tecnologie per questo.
Sulle prestazioni del database
Di conseguenza, c'è un ambiente concorrente, cioè il server «Zabbix» raccoglie e registra dati. Al riavvio, legge anche dalla storia per riempire ValueCache e così via. Allo stesso tempo, ci possono essere script e report che utilizzano l’API di «Zabbix», costruita sulla base dell'interfaccia web. L’API di «Zabbix» accede al DB e ottiene i dati necessari per ottenere grafici, report o qualche lista di eventi e problemi recenti.
Una soluzione molto popolare per la visualizzazione è Grafana, utilizzata dai nostri utenti. È in grado di accedere direttamente sia tramite l’API di «Zabbix» che attraverso il DB. Essa crea anche una certa concorrenza per ottenere dati: è necessaria una configurazione più fine e buona del DB per garantire risultati rapidi e test.
Pulizia della cronologia. In Zabbix c'è il Housekeeper
Il terzo chiamato utilizzato in «Zabbix» è la pulizia della cronologia tramite il Housekeeper. Il «Housekeeper» rispetta tutte le impostazioni, ovvero abbiamo negli elementi dati indicato per quanto tempo conservare (in giorni), quanto conservare i trend, la dinamica delle variazioni.
Non ho parlato del TrendCache, che calcoliamo al volo: arrivano dati, li aggregiamo per un'ora (principalmente si tratta di numeri dell'ultima ora), la quantità media / minima e li registriamo un'ora in tabella della dinamica delle variazioni («Trends»). Il «Housekeeper» viene avviato e rimuove dati dal DB con semplici select, il che non è sempre efficiente.
Come capire che non è efficiente? Puoi vedere nei grafici delle prestazioni dei processi interni un quadro del genere:
Hai il History syncer costantemente occupato (grafico rosso). E il grafico «arancione» che va sopra. Questo è il «Housekeeper», che viene avviato e aspetta dal DB quando rimuoverà tutte le righe che ha specificato.
Prendiamo un qualsiasi Item ID: è necessario eliminare le ultime 5.000; certo, per gli indici. Ma di solito il dataset è piuttosto grande – il database lo legge comunque dal disco e lo carica in cache, e questa è un'operazione molto costosa per il DB. A seconda delle sue dimensioni, può portare a determinati problemi di prestazioni.
Disabilitare il «Housekeeper» può essere fatto in modo semplice – abbiamo l'interfaccia web che tutti conosciamo. Nelle impostazioni in Administration general (impostazioni per il «Housekeeper») disattiviamo il housekeeping interno per la cronologia e i trend interni. Di conseguenza, il «Housekeeper» non gestisce più questo:
Cosa si può fare dopo? Hai disabilitato, i tuoi grafici si sono allineati… Quali problemi possono sorgere dopo? Cosa può aiutare?
Partizionamento (sezionamento)
Di solito viene configurato in ogni database relazionale che ho elencato, in modi diversi. MySQL ha la sua tecnologia. Ma in generale sono molto simili, se si parla di PostgreSQL 10 e MySQL. Certo, ci sono molte differenze interne su come tutto questo è implementato e come influisce sulle prestazioni. Ma in generale, la creazione di una nuova partizione porta spesso anche a determinati problemi.
A seconda del vostro setup (quanti dati vengono creati in un giorno), di solito si imposta il minimo - 1 giorno / partizione, e per i «trend», la dinamica delle variazioni - 1 mese / nuova partizione. Questo può cambiare se avete un setup molto grande.
Fammi subito parlare delle dimensioni del setup: fino a 5.000 nuovi valori al secondo (nvps, come si dice) - questo sarà considerato un piccolo «setup». Medio - da 5 a 25.000 valori al secondo. Qualunque cosa oltre - sono già installazioni grandi e molto grandi, che richiedono una configurazione molto attenta del database.
In installazioni molto grandi, 1 giorno potrebbe non essere ottimale. Ho visto personalmente in MySQL partizioni da 40 gigabyte al giorno (e possono essere anche più grandi). Questo è un volume di dati molto grande che può portare a qualche problema. Bisogna ridurlo.
A cosa serve la partizione?
Cosa fa il Partitioning, penso che tutti lo sappiano - è la suddivisione delle tabelle. Spesso si tratta di file separati sul disco e query span. Seleziona in modo più ottimale una partizione, se rientra nella normale partizione.
Per «Zabbix», in particolare, viene utilizzato per intervallo, cioè utilizziamo il timestamp (un numero ordinario, il tempo dall'inizio dell'epoca). Imposti l'inizio della giornata / la fine della giornata e questo diventa una partizione. Dunque, se richiedi dati di un giorno fa, tutto viene estratto dal database più rapidamente, perché occorre solo caricare un file in cache e fornire (e non una tabella grande).
Molti DB accelerano anche l'inserimento (inserimento in una tabella figlia). Finora parlo in astratto, ma è possibile. La partizione spesso aiuta.
Elasticsearch per NoSQL
Recentemente, nella 3.4, abbiamo implementato una soluzione per NoSQL. Abbiamo aggiunto la possibilità di scrivere in Elasticsearch. Puoi scrivere alcuni tipi separati: scegli - o scrivi numeri, o qualche segno; abbiamo stringa-testo, puoi scrivere log in Elasticsearch… Dunque, l'interfaccia web si interfaccerà già con Elasticsearch. Questo funziona ottimamente in alcuni casi, ma al momento è utilizzabile.
TimescaleDB. I ipertabelle
Per la 4.4.2 abbiamo notato una cosa, come TimescaleDB. Cos'è? È un'estensione per PostgreSQL, quindi ha un'interfaccia nativa di PostgreSQL. Inoltre, questa estensione consente di lavorare in modo molto più efficiente con i dati di tipo timeseries e ha partizionamento automatico. Ecco come appare:
Questo è un hypertable – è un concetto in Timescale. È la tabella ibrida che crei, e dentro ci sono i chunk (chunk). I chunk sono le partizioni, sono tabelle figlio, se non erro. È davvero efficace.
TimescaleDB e PostgreSQL
Come affermano i produttori di TimescaleDB, utilizzano un algoritmo di elaborazione delle query più corretto, in particolare per gli insert, che consente di mantenere una prestazione pressoché costante con l'aumento della dimensione del dataset di inserimento. Quindi, dopo 200 milioni di righe, PostgreSQL normale inizia a calare drasticamente e perde letteralmente prestazione fino a zero, mentre Timescale consente di inserire i dati il più efficacemente possibile con qualsiasi quantità di dati.
Come installare TimescaleDB? È semplice!
È descritto nella sua documentazione – puoi installarlo dai pacchetti per qualsiasi… Dipende dai pacchetti ufficiali di PostgreSQL. Puoi compilarlo a mano. È capitato che dovessi compilarlo per il DB.
In Zabbix attiviamo semplicemente l'Extention. Penso che chi ha usato l'Extention in PostgreSQL… Attivate semplicemente l'Extention, la create per il DB di Zabbix che state utilizzando.
E l'ultimo passaggio...
TimescaleDB. Migrazione delle tabelle della cronologia
Hai bisogno di creare un hypertable. Per fare ciò, c'è una funzione speciale – Crea hypertable. Qui il primo parametro indica la tabella che è necessaria in questo DB (per la quale è necessario creare l'ibrida).
Il campo su cui deve essere creato e chunk_time_interval (questo è l'intervallo dei chunk (partizioni che devono essere utilizzate). 86 400 è un giorno.
Il parametro migrate_data: se lo imposti su true, trasferisce tutti i dati correnti nei chunk precedentemente creati.
Ho personalmente utilizzato migrate_data – ci vuole un bel po' di tempo, a seconda delle dimensioni del tuo DB. Avevo più di un terabyte – la creazione ha impiegato più di un'ora. In alcuni casi, durante i test, ho eliminato i dati storici per il testo (history_text) e la stringa (history_str), per non trasferirli – in realtà non mi interessavano.
E l'ultimo aggiornamento che facciamo nella nostra db_extention: installiamo timescaledb, in modo che il DB e, in particolare, il nostro «Zabbix» possano capire che esiste db_extention. Lo attiva e utilizza correttamente la sintassi e le query al DB, avvalendosi già delle «funzionalità» necessarie per TimescaleDB.
Configurazione del server
Ho utilizzato due server. Il primo server è una macchina virtuale piuttosto piccola, con 20 processori e 16 gigabyte di RAM. Ho configurato su di esso «Postgres» 10.8:
Il sistema operativo era Debian, il file system – xfs. Ho fatto le configurazioni minime per utilizzare proprio questo database, a parte ciò che userà «Zabbix». Su questa stessa macchina era installato il server «Zabbix», PostgreSQL e gli agenti di carico.
Ho utilizzato 50 agenti attivi, che utilizzano LoadableModule, per generare rapidamente vari risultati. Sono stati loro a generare righe, numeri e così via. Ho riempito il DB con una grande quantità di dati. Inizialmente la configurazione conteneva 5 mila elementi di dati per ogni host e circa ogni elemento di dati conteneva un trigger – per avere una configurazione reale. A volte è necessaria anche più di un trigger.
L'intervallo di aggiornamento, il carico stesso lo regolavo non solo utilizzando 50 agenti (ne aggiungevo di più), ma anche con elementi di dati dinamici e abbassavo l'intervallo di aggiornamento a 4 secondi.
Test delle prestazioni. PostgreSQL: 36 mila NVP.
Il primo avvio, la prima configurazione l'ho avuta su un PostgreSQL 10 pulito su questa macchina (35 mila valori al secondo). In generale, come si vede sullo schermo, l'inserimento dei dati richiede frazioni di secondo – tutto è buono e veloce, dischi SSD (200 gigabyte). L'unica cosa è che 20 GB si riempiono piuttosto rapidamente.
Ci saranno in seguito molti di questi grafici. Questo è il dashboard delle prestazioni standard del server «Zabbix».
Il primo grafico – il numero di valori al secondo (blu, in alto a sinistra), 35 mila valori in questo caso. Questo (in alto al centro) è il carico dei processi di raccolta, mentre questo (in alto a destra) è il carico dei processi interni: history syncers e housekeeper, che qui (in basso al centro) è stato in esecuzione per abbastanza tempo.
Questo grafico (in basso al centro) mostra l'uso di ValueCache: quante hit di ValueCache ci sono per i trigger (diverse migliaia di valori al secondo). Un altro grafico importante è il quarto (in basso a sinistra), che mostra l'uso di HistoryCache, di cui ho parlato, che funge da buffer prima dell'inserimento nel database.
Test di performance. PostgreSQL: 50 mila NVP
Successivamente ho aumentato il carico a 50 mila valori al secondo su questa stessa macchina. Durante il caricamento da parte di "Housekeeper", 10 mila valori venivano già scritti in 2-3 secondi con calcolo. Questo, in effetti, è mostrato nello screenshot successivo:
"Housekeeper" inizia già a interferire con il lavoro, ma nel complesso il carico dei trapper di history-syncer è ancora al 60% (terzo grafico, in alto a destra). HistoryCache inizia già a riempirsi attivamente durante l'operazione di "Housekeeper" (in basso a sinistra). Era di circa mezzo gigabyte e si stava riempiendo al 20%.
Test di performance. PostgreSQL: 80 mila NVP
Ho poi aumentato a 80 mila valori al secondo:
Erano circa 400 mila elementi di dati, 280 mila trigger. L'inserimento, come puoi vedere, era già abbastanza alto per il carico degli history-syncer (ce ne erano 30). Poi ho aumentato vari parametri: history-syncer, cache... Su questa macchina il carico degli history-syncer ha iniziato ad aumentare al massimo, praticamente "saturato" – di conseguenza, HistoryCache ha raggiunto un carico molto alto:
Durante tutto questo tempo ho monitorato tutti i parametri del sistema (come viene utilizzata la CPU, la memoria RAM) e ho scoperto che l'utilizzo dei dischi era massimo – ho raggiunto la capacità massima di questo disco su questa macchina, su questa macchina virtuale. "Postgres" ha iniziato a scaricare i dati in modo abbastanza attivo a tale intensità e il disco non riusciva più a scrivere, leggere...
Ho preso un altro server che aveva già 48 processori e 128 gigabyte di RAM:
L'ho anche "ottimizzato" – ho installato 60 history syncer e ho ottenuto prestazioni accettabili. Di fatto, non siamo più "saturati", ma questo è già, probabilmente, il limite di prestazione, dove è necessario intraprendere qualche azione.
Test di performance. TimescaleDB: 80 mila NVP
La mia principale sfida era utilizzare TimescaleDB. Ogni grafico mostra un calo:
Questi fallimenti rappresentano esattamente la migrazione dei dati. Dopo ciò, nel server Zabbix, il profilo di caricamento degli storici dei sincronizzatori, come vedete, è cambiato drasticamente. Consente di inserire i dati quasi tre volte più velocemente e di utilizzare meno HistoryCache; di conseguenza, i dati saranno forniti tempestivamente. Ancora una volta, 80.000 valori al secondo è un tasso abbastanza alto (certo, non per Yandex). In generale, si tratta di un setup abbastanza grande, con un solo server.
Test di prestazioni di PostgreSQL: 120.000 NVP.
Successivamente, ho aumentato il valore del numero di elementi dati a mezzo milione e ho ottenuto un valore stimato di 125.000 al secondo:
E ho ottenuto grafici come questi:
In linea di principio, questo è un setup funzionante, può operare per un tempo piuttosto lungo. Ma poiché avevo un disco di soli 1,5 terabyte, l'ho esaurito in pochi giorni. La cosa più importante è che nel frattempo si stavano creando nuove partizioni su TimescaleDB, e questo per le prestazioni è avvenuto completamente senza che se ne accorgesse, cosa che non si può dire per MySQL.
Di solito le partizioni vengono create di notte perché ciò blocca completamente l’inserimento e il lavoro con le tabelle, e può portare a una degradazione del servizio. In questo caso non è successo! L'obiettivo principale era verificare le capacità di TimescaleDB. È emersa questa cifra: 120.000 valori al secondo.
Ci sono anche esempi nella comunità:
Una persona ha anche attivato TimescaleDB e il caricamento per l’utilizzo di io.weight è diminuito sulla CPU; e l'uso degli elementi dei processi interni è diminuito grazie all'attivazione di TimescaleDB. Inoltre, si tratta di dischi normali, cioè una normale macchina virtuale su dischi convenzionali (non SSD)!
Per alcuni piccoli setup che si scontrano con le prestazioni del disco, TimescaleDB, a mio parere, è una soluzione molto buona. Permetterà di continuare a lavorare fino a quando non si migrerà su hardware più veloce per il database.
Vi invitiamo tutti ai nostri eventi: Conferenza – a Mosca, Summit – a Riga. Utilizzate i nostri canali: Telegram, forum, IRC. Se avete domande, venite al nostro stand, possiamo parlare di tutto.
Domande dal pubblico
Domanda dal pubblico (di seguito – A): – Se TimescaleDB è così semplice da configurare e offre un tale incremento delle prestazioni, forse sarebbe utile utilizzarlo come migliore pratica per configurare «Zabbix» con «Postgres»? Ci sono delle insidie e svantaggi in questa soluzione, o se ho deciso di fare «Zabbix», posso tranquillamente prendere «Postgres», installare subito «Timescale» e usarlo senza pensare a problemi?
AG: – Sì, direi che è un'ottima raccomandazione: utilizzare «Postgres» direttamente con l'estensione TimescaleDB. Come ho già detto, ci sono molte buone recensioni, nonostante questa «feature» sia sperimentale. Ma in realtà i test dimostrano che è un'ottima soluzione (con TimescaleDB) e credo che si sviluppi! Stiamo monitorando come si evolve questa estensione e apporteremo le modifiche necessarie.
Anche durante lo sviluppo ci siamo basati su una delle loro note «feature»: lì si poteva lavorare un po' diversamente con i chunk. Ma poi l'hanno rimossa nella release successiva, e abbiamo dovuto smettere di fare affidamento su quel codice. Consiglierei di utilizzare questa soluzione in molte configurazioni. Se usate MySQL… Per configurazioni medio-piccole, qualsiasi soluzione funziona abbastanza bene.
A: – Negli ultimi grafici, forniti dalla community, c'era un grafico con «Housekeeper»:
Ha continuato a funzionare. Cosa fa «Housekeeper» nel caso di TimescaleDB?
AG: – Al momento non posso dirlo con certezza – guarderò il codice e fornirò ulteriori dettagli. Utilizza le query di TimescaleDB non per eliminare i chunk, ma in qualche modo aggrega. Finora non sono pronto a rispondere a questa domanda tecnica. Su questo aspetto chiariremo oggi o domani.
A: – Ho una domanda simile – sulla performance delle operazioni di eliminazione in «Timescale».
A (risposta dal pubblico): – Quando elimini dati da una tabella, se lo fai tramite delete, devi attraversare la tabella – rimuovere, pulire, contrassegnare tutto per il futuro vacuum. In «Timescale», poiché hai dei chunk, puoi eliminarli. In sostanza, stai semplicemente dicendo al file, che si trova nei big data: «Elimina!»
«TimeScale» capisce semplicemente che quel chunk non esiste più. E poiché si integra con il pianificatore delle richieste, cattura le tue condizioni nel select o in altre operazioni e comprende immediatamente che quel chunk non è più disponibile – «Non ci andrò più!» (dati assenti). Ecco tutto! Quindi la scansione della tabella viene sostituita con la cancellazione di un file binario, quindi è veloce.
A: – Abbiamo già toccato il tema del non SQL. Da quanto ho capito, «Zabbix» non ha realmente bisogno di modificare i dati, e tutto questo è una sorta di log. È possibile utilizzare database specializzati che non possono modificare i propri dati, ma che al contempo salvano, accumulano e restituiscono molto più rapidamente – Clickhouse, ad esempio, qualcosa di simile a Kafka?.. Kafka è anch'esso un log! Possono essere integrati in qualche modo?
AG: – È possibile fare l'esportazione. Abbiamo una certa "feature" dalla versione 3.4: puoi scrivere in file tutti i file storici, eventi e tutto il resto; e successivamente, tramite qualche elaboratore, inviarli a qualsiasi altro DB. In realtà, molti ristrutturano e scrivono direttamente nel DB. I history-sinkers in tempo reale scrivono tutto questo in file, ruotano questi file e così via, e puoi trasferirli in «Clickhouse». Non posso dire nulla sui piani, ma forse il supporto futuro per le soluzioni NoSQL (come «Clickhouse») continuerà.
A: – Quindi, in effetti, è possibile eliminare completamente Postgres?
AG: – Certo, la parte più complessa di «Zabbix» sono le tabelle storiche, che creano più problemi, e gli eventi. In questo caso, se non intendi conservare a lungo gli eventi e conserverai la storia con i trend in un altro sistema di archiviazione veloce, in generale non ci saranno problemi, suppongo.
A: – Puoi valutare quanto sarà più veloce tutto se passiamo a «Clickhouse», ad esempio?
AG: – Non ho fatto test. Penso che almeno le stesse cifre possano essere raggiunte piuttosto facilmente, considerando che «Clickhouse» ha la sua interfaccia, ma non posso dire con certezza. È meglio testare. Tutto dipende dalla configurazione: quanti host hai e così via. L'inserimento è una cosa, ma bisogna anche recuperare questi dati – con Grafana o altro.
A: – Quindi stiamo parlando di una lotta equilibrata, e non di un grande vantaggio di questi DB veloci?
AG: – Penso che quando integreremo, avremo test più accurati.
A: – E dove è finito il caro vecchio RRD? Cosa ha portato al passaggio ai database SQL? Inizialmente tutte le metriche venivano raccolte su RRD.
AG: – In «Zabbix» RRD, forse, era presente in una versione molto antica. I database SQL sono sempre stati presenti – è un approccio classico. L'approccio classico è MySQL, PostgreSQL (esistono da molto tempo). Abbiamo un'interfaccia comune per i database SQL e non abbiamo praticamente mai utilizzato RRD.
Un po' di pubblicità 🙂
Grazie per rimanere con noi. Ti piacciono i nostri articoli? Vuoi vedere più contenuti interessanti? Supportaci effettuando un ordine o raccomandandoci a qualcuno. , unica alternativa ai server entry-level, concepita da noi per te: (sono disponibili opzioni con RAID1 e RAID10, fino a 24 core e fino a 40GB DDR4).
Dell R730xd a metà prezzo nel data center Equinix Tier IV ad Amsterdam? Solo da noi nei Paesi Bassi! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — a partire da $99! Leggi di
Fonte: habr.com
