Negli ultimi anni, i database di serie temporali si sono trasformati da qualcosa di bizzarro (altamente specializzato utilizzato in sistemi di monitoraggio aperti (e legati a soluzioni specifiche) o in progetti Big Data) in un “prodotto di consumo”. Sul territorio della Federazione Russa per questo bisogna ringraziare in modo speciale Yandex e ClickHouse. Fino a quel momento, se avevi bisogno di archiviare una grande quantità di dati di serie temporali, dovevi fare i conti con la necessità di costruire un mostruoso stack Hadoop e mantenerlo, oppure comunicare con protocolli individuali per ciascun sistema.
Potrebbe sembrare che nel 2019 un articolo su quale vale la pena utilizzare TSDB sarà composto da una sola frase: "usa semplicemente ClickHouse". Ma... ci sono delle sfumature.
In effetti, ClickHouse si sta sviluppando attivamente, la base di utenti sta crescendo e il supporto è molto attivo, ma siamo diventati ostaggi del successo pubblico di ClickHouse, che ha messo in ombra altre soluzioni, forse più efficaci/affidabili?
All'inizio dello scorso anno abbiamo iniziato a rielaborare il nostro sistema di monitoraggio, durante il quale è sorta la questione della scelta di un database adatto per l'archiviazione dei dati. Voglio parlare qui della storia di questa scelta.
Formulazione del problema
Innanzitutto una doverosa prefazione. Perché abbiamo bisogno del nostro sistema di monitoraggio e come è stato progettato?
Abbiamo iniziato a fornire servizi di supporto nel 2008 e nel 2010 è diventato chiaro che era diventato difficile aggregare i dati sui processi che si verificano nell'infrastruttura del cliente con le soluzioni esistenti in quel momento (stiamo parlando di, Dio mi perdoni, Cacti, Zabbix e la emergente Grafite).
I nostri requisiti principali erano:
- supporto (a quel tempo - dozzine e in futuro - centinaia) di clienti all'interno di un sistema e allo stesso tempo presenza di un sistema centralizzato di gestione degli allarmi;
- flessibilità nella gestione del sistema di allerta (escalation di allerte tra operatori di turno, programmazione, knowledge base);
- la capacità di dettagliare profondamente i grafici (Zabbix a quel tempo rendeva i grafici sotto forma di immagini);
- archiviazione a lungo termine di una grande quantità di dati (un anno o più) e possibilità di recuperarli rapidamente.
In questo articolo ci interessa l’ultimo punto.
Parlando di spazio di archiviazione, i requisiti erano i seguenti:
- il sistema deve funzionare velocemente;
- è auspicabile che il sistema abbia un'interfaccia SQL;
- il sistema deve essere stabile e avere una base utenti attiva e supporto (una volta ci siamo trovati di fronte alla necessità di supportare sistemi come MemcacheDB, che non era più sviluppato, o lo storage distribuito MooseFS, il cui bug tracker era mantenuto in cinese: ripetiamo questa storia perché il nostro progetto non la voleva);
- rispetto del teorema CAP: Coerenza (richiesto) - i dati devono essere aggiornati, non vogliamo che il sistema di gestione degli alert non riceva nuovi dati e emetta avvisi sul mancato arrivo dei dati per tutti i progetti; Tolleranza alla partizione (richiesto): non vogliamo ottenere un sistema Split Brain; Disponibilità (non critica, se è presente una replica attiva): possiamo passare noi stessi al sistema di backup in caso di incidente, utilizzando il codice.
Stranamente, in quel momento MySQL si è rivelata la soluzione ideale per noi. La nostra struttura dei dati era estremamente semplice: ID server, ID contatore, timestamp e valore; il campionamento rapido dei dati caldi è stato assicurato da un ampio buffer pool e il campionamento dei dati storici è stato assicurato dall'SSD.
Pertanto, abbiamo ottenuto un campione di nuovi dati di due settimane, con dettagli fino a un secondo 200 ms prima che i dati fossero completamente renderizzati, e abbiamo vissuto in questo sistema per un periodo piuttosto lungo.
Nel frattempo il tempo passava e la quantità di dati cresceva. Nel 2016 il volume dei dati ha raggiunto le decine di terabyte, una spesa significativa nel contesto dello spazio di archiviazione SSD noleggiato.
A questo punto, i database a colonne si erano diffusi attivamente, a cui abbiamo iniziato a pensare attivamente: nei database a colonne, i dati sono archiviati, come puoi capire, in colonne e se guardi i nostri dati, è facile vedere un grande numero di duplicati che potrebbero, Se si utilizza un database a colonne, comprimerlo utilizzando la compressione.
Tuttavia, il sistema chiave dell’azienda ha continuato a funzionare stabilmente e non volevo sperimentare il passaggio a qualcos’altro.
Nel 2017, alla conferenza Percona Live a San Jose, gli sviluppatori di Clickhouse si sono probabilmente annunciati per la prima volta. A prima vista, il sistema era pronto per la produzione (beh, Yandex.Metrica è un sistema di produzione difficile), il supporto era veloce e semplice e, soprattutto, il funzionamento era semplice. Dal 2018 abbiamo avviato il processo di transizione. Ma a quel tempo c'erano molti sistemi TSDB "adulti" e testati nel tempo e abbiamo deciso di dedicare molto tempo e confrontare le alternative per assicurarci che non esistessero soluzioni alternative a Clickhouse, secondo le nostre esigenze.
Oltre ai requisiti di archiviazione già specificati, ne sono comparsi di nuovi:
- il nuovo sistema dovrebbe fornire almeno le stesse prestazioni di MySQL sulla stessa quantità di hardware;
- lo stoccaggio del nuovo sistema dovrebbe occupare molto meno spazio;
- Il DBMS deve essere comunque facile da gestire;
- Volevo modificare minimamente l'applicazione quando si cambiava il DBMS.
Quali sistemi abbiamo iniziato a considerare?
Apache Hive/Apache Impala
Un vecchio stack Hadoop testato in battaglia. Essenzialmente, si tratta di un'interfaccia SQL costruita sulla memorizzazione dei dati in formati nativi su HDFS.
Pro.
- Con un funzionamento stabile, è molto semplice ridimensionare i dati.
- Esistono soluzioni a colonna per l'archiviazione dei dati (meno spazio).
- Esecuzione molto rapida di attività parallele quando le risorse sono disponibili.
Cons.
- È Hadoop ed è difficile da usare. Se non siamo pronti ad adottare una soluzione già pronta nel cloud (e non siamo pronti in termini di costi), l'intero stack dovrà essere assemblato e supportato dalle mani degli amministratori, e davvero non vogliamo Questo.
- I dati sono aggregati .
Tuttavia:
La velocità si ottiene ridimensionando il numero di server informatici. In poche parole, se siamo una grande azienda impegnata nell'analisi ed è fondamentale per l'azienda aggregare le informazioni il più rapidamente possibile (anche a costo di utilizzare una grande quantità di risorse informatiche), questa potrebbe essere la nostra scelta. Ma non eravamo pronti a moltiplicare il parco hardware per velocizzare le attività.
Druido/Pinot
C'è molto di più nello specifico su TSDB, ma ancora una volta, sullo stack Hadoop.
C'è .
In poche parole: Druid/Pinot appaiono migliori di Clickhouse nei casi in cui:
- I tuoi dati sono di natura eterogenea (nel nostro caso registriamo solo serie temporali di parametri del server e, in effetti, questa è una tabella. Ma potrebbero esserci altri casi: serie temporali di apparecchiature, serie temporali economiche, ecc., ciascuna con propria struttura, che necessitano di essere aggregati ed elaborati).
- Inoltre, ci sono molti di questi dati.
- Tabelle e dati con serie temporali compaiono e scompaiono (ovvero, alcuni insiemi di dati sono arrivati, sono stati analizzati ed eliminati).
- Non esiste un criterio chiaro in base al quale i dati possono essere partizionati.
In casi opposti, ClickHouse ha prestazioni migliori, e questo è il nostro caso.
CliccaCasa
- Simile a SQL
- Facile da gestire.
- La gente dice che funziona.
Viene selezionato per il test.
InflussoDB
Un'alternativa straniera a ClickHouse. Tra gli svantaggi: l'alta disponibilità è presente solo nella versione commerciale, ma deve essere confrontata.
Viene selezionato per il test.
Cassandra
Da un lato sappiamo che viene utilizzato per memorizzare serie temporali metriche da parte di sistemi di monitoraggio come, ad esempio, o OkMeter. Tuttavia, ci sono dettagli.
Cassandra non è un database a colonne nel senso tradizionale. Assomiglia più a una visualizzazione a righe, ma ogni riga può avere un numero diverso di colonne, semplificando l'organizzazione di una visualizzazione a colonne. In questo senso è chiaro che con un limite di 2 miliardi di colonne è possibile memorizzare alcuni dati in colonne (e nelle stesse serie temporali). Ad esempio, in MySQL esiste un limite di 4096 colonne ed è facile imbattersi in un errore con il codice 1117 se provi a fare lo stesso.
Il motore Cassandra è focalizzato sull'archiviazione di grandi quantità di dati in un sistema distribuito senza master, e il summenzionato teorema Cassandra CAP riguarda più l'AP, ovvero la disponibilità dei dati e la resistenza al partizionamento. Pertanto, questo strumento può essere ottimo se hai solo bisogno di scrivere su questo database e raramente di leggere da esso. E qui è logico utilizzare Cassandra come cella frigorifera. Si tratta di un luogo affidabile a lungo termine in cui archiviare grandi quantità di dati storici raramente necessari, ma che possono essere recuperati se necessario. Tuttavia, per ragioni di completezza, lo testeremo anche noi. Ma, come ho detto prima, non c'è alcun desiderio di riscrivere attivamente il codice per la soluzione di database selezionata, quindi lo testeremo in modo piuttosto limitato, senza adattare la struttura del database alle specificità di Cassandra.
Prometeo
Ebbene, per curiosità, abbiamo deciso di testare le prestazioni dello storage Prometheus, giusto per capire se siamo più veloci o più lenti delle soluzioni attuali e di quanto.
Metodologia e risultati dei test
Quindi, abbiamo testato 5 database nelle seguenti 6 configurazioni: ClickHouse (1 nodo), ClickHouse (tabella distribuita per 3 nodi), InfluxDB, Mysql 8, Cassandra (3 nodi) e Prometheus. Il piano di prova è il seguente:
- caricare dati storici per una settimana (840 milioni di valori al giorno; 208mila metriche);
- generiamo un carico di registrazione (sono state considerate 6 modalità di carico, vedi sotto);
- Parallelamente alla registrazione, effettuiamo periodicamente delle selezioni, emulando le richieste di un utente che lavora con i grafici. Per non complicare troppo le cose, abbiamo selezionato i dati per 10 parametri (che sono esattamente quanti ce ne sono nel grafico della CPU) per una settimana.
Carichiamo emulando il comportamento del nostro agente di monitoraggio, che invia valori a ciascuna metrica una volta ogni 15 secondi. Allo stesso tempo, siamo interessati a variare:
- il numero totale di metriche in cui vengono scritti i dati;
- intervallo per l'invio di valori a una metrica;
- dimensione del lotto.
Informazioni sulla dimensione del lotto. Poiché non è consigliabile caricare quasi tutti i nostri database sperimentali con inserimenti singoli, avremo bisogno di un relè che raccolga le metriche in entrata, le raggruppi in gruppi e le scriva nel database come inserimento batch.
Inoltre, per capire meglio come interpretare i dati ricevuti, immaginiamo di non inviare solo un insieme di metriche, ma che le metriche siano organizzate in server: 125 metriche per server. Qui il server è semplicemente un'entità virtuale, basti pensare che, ad esempio, 10000 metriche corrispondono a circa 80 server.
Ed ecco, tenendo conto di tutto ciò, ci sono le nostre 6 modalità di caricamento in scrittura del database:
Ci sono due punti qui. In primo luogo, per Cassandra queste dimensioni batch si sono rivelate troppo grandi, abbiamo utilizzato valori 50 o 100. E in secondo luogo, poiché Prometheus funziona rigorosamente in modalità pull, ad es. esso stesso va e raccoglie dati da fonti di metriche (e anche pushgateway, nonostante il nome, non cambia radicalmente la situazione), i carichi corrispondenti sono stati implementati utilizzando una combinazione di configurazioni statiche.
I risultati del test sono i seguenti:
Cosa vale la pena notare: campioni incredibilmente veloci da Prometheus, campioni terribilmente lenti da Cassandra, campioni inaccettabilmente lenti da InfluxDB; In termini di velocità di registrazione, ClickHouse ha vinto tutti e Prometheus non partecipa al concorso, perché si inserisce da solo e non misuriamo nulla.
Come risultato,: ClickHouse e InfluxDB si sono rivelati i migliori, ma un cluster di Influx può essere costruito solo sulla base della versione Enterprise, che costa denaro, mentre ClickHouse non costa nulla ed è prodotto in Russia. È logico che negli Stati Uniti la scelta sia probabilmente a favore di inInfluxDB, mentre nel nostro paese sia a favore di ClickHouse.
Fonte: habr.com