Negli ultimi anni, le banche dati per serie temporali (Time-series databases) sono passate da una soluzione di nicchia, utilizzata principalmente in sistemi di monitoraggio aperti (e vincolata a soluzioni specifiche) o in progetti Big Data, a un "prodotto di consumo pubblico". In Russia, un grande ringraziamento va a Yandex e ClickHouse per questo. Fino a quel momento, se avevate bisogno di conservare un grande volume di dati time-series, dovevate accontentarvi di un mostruoso stack Hadoop e gestirlo, oppure interagire con protocolli specifici per ogni sistema.
Potrebbe sembrare che nel 2019 un articolo su quale TSDB utilizzare si possa riassumere in una sola frase: "utilizzate semplicemente ClickHouse". Ma… ci sono delle sfumature.
In effetti, ClickHouse si sta sviluppando attivamente, la base utenti cresce e il supporto è molto attivo, ma non siamo diventati prigionieri del successo pubblico di ClickHouse, che ha oscurato altre soluzioni, forse più efficaci o affidabili?
All'inizio dello scorso anno abbiamo iniziato a rielaborare il nostro sistema di monitoraggio, nel corso del quale è sorto il problema della scelta della banca dati adatta per la conservazione dei dati. È di questa scelta che voglio parlare qui.
Definizione del compito
Prima di tutto, è necessaria una premessa. Perché abbiamo bisogno di un nostro sistema di monitoraggio e come era strutturato?
Abbiamo iniziato a offrire servizi di supporto nel 2008 e nel 2010 è diventato chiaro che aggregare i dati sui processi che avvenivano nell'infrastruttura dei clienti con le soluzioni disponibili all'epoca era diventato complesso (stiamo parlando, per sfortuna, di Cacti, Zabbix e del nascente Graphite).
I nostri principali requisiti erano:
- supporto (all'epoca - decine, e in prospettiva - centinaia) di clienti all'interno di un unico sistema e, nel contempo, la presenza di un sistema centrale di gestione delle notifiche;
- flessibilità nella gestione del sistema di notifiche (escalation delle notifiche tra i turnisti, gestione dei turni, knowledge base);
- possibilità di una profonda dettagliabilità nei grafici (Zabbix all'epoca generava grafici in formato immagine);
- memorizzazione a lungo termine di un grande volume di dati (un anno o più) e possibilità di accesso rapido ad essi.
In questo articolo ci interessa l'ultimo punto.
Parlando di archiviazione, i requisiti erano i seguenti:
- il sistema deve funzionare rapidamente;
- è preferibile 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 ha smesso di essere sviluppato, o l'archivio distribuito MooseFS, il cui bug tracker era in cinese: non volevamo ripetere questa storia per il nostro progetto);
- conformità al teorema CAP: Consistenza (necessaria) — i dati devono essere aggiornati, non vogliamo che il sistema di gestione degli avvisi non riceva nuovi dati e lanci allarmi su tutti i progetti in merito alla mancata ricezione di dati; Tolleranza alle ripartizioni (necessaria) — non vogliamo avere un sistema in Split Brain; Disponibilità (non critica, nel caso esista una replica attiva) — possiamo passare manualmente a un sistema di riserva in caso di emergenza, tramite codice.
Stranamente, a quel tempo la soluzione ideale per noi si è rivelata MySQL. La nostra struttura dati era estremamente semplice: id del server, id del contatore, timestamp e valore; l'estrazione rapida dei dati recenti era garantita da una grande dimensione del buffer pool, mentre l'estrazione dei dati storici avveniva tramite SSD.
In questo modo, siamo riusciti ad estrarre dati freschi di due settimane, con una risoluzione fino al secondo, in 200 ms prima del momento di rendering completo dei dati, e abbiamo vissuto in questo sistema per parecchio tempo.
Nel frattempo, il tempo passava e la quantità di dati cresceva. Nel 2016, i volumi di dati raggiungevano decine di terabyte, il che rappresentava un notevole costo per gli SSD in affitto.
A questo punto, i database column-oriented stavano guadagnando popolarità, e abbiamo iniziato a considerarli attivamente: nei database column-oriented i dati vengono archiviati, come suggerisce il termine, in colonne, e se si guarda ai nostri dati, è facile vedere una grande quantità di duplicati che potrebbero essere compressi utilizzando un database column-oriented.
Tuttavia, il sistema chiave per il funzionamento dell'azienda continuava a funzionare in modo stabile, e non volevamo sperimentare una transizione verso qualcos'altro.
Nel 2017 alla conferenza Percona Live di San Jose, gli sviluppatori di Clickhouse si sono presentati probabilmente per la prima volta. A prima vista, il sistema era pronto per la produzione (dopotutto, Yandex.Metrica è un ambiente di produzione rigoroso), il supporto era rapido e semplice e, soprattutto, l'operatività era facile. Dal 2018 abbiamo avviato il processo di transizione. Ma a quel punto, c'erano già molte soluzioni TSDB 'mature' e collaudate, e abbiamo deciso di dedicare un tempo significativo per confrontare le alternative, per assicurarci che non esistessero soluzioni alternative a Clickhouse che soddisfacessero i nostri requisiti.
In aggiunta ai requisiti già elencati per il database, sono emerse nuove esigenze:
- il nuovo sistema deve garantire almeno le stesse prestazioni di MySQL, sulla stessa quantità di hardware;
- l'archiviazione del nuovo sistema deve occupare significativamente meno spazio;
- Il DBMS deve comunque essere facile da gestire;
- si desiderava modificare il meno possibile l'applicazione durante il cambio del DBMS.
Quali sistemi abbiamo iniziato a considerare
Apache Hive/Apache Impala
Un vecchio stack Hadoop collaudato. Fondamentalmente è un'interfaccia SQL costruita sopra la memorizzazione dei dati in formati proprietari su HDFS.
Vantaggi.
- Con un funzionamento stabile, è molto semplice scalare i dati.
- Ci sono soluzioni colonnari per l'archiviazione dei dati (meno spazio).
- Esecuzione molto rapida di compiti paralleli quando ci sono risorse disponibili.
Contro.
- È Hadoop ed è complesso da gestire. Se non siamo pronti a prendere una soluzione pronta nel cloud (e non lo siamo per quanto riguarda i costi), l'intero stack dovrà essere assemblato e mantenuto a mano dagli amministratori, e questo non è desiderabile.
- I dati vengono aggregati .
Tuttavia:
La velocità viene raggiunta aumentando il numero di server di calcolo. In altre parole, se siamo una grande azienda, ci occupiamo di analisi e per il business è cruciale aggregare informazioni il più rapidamente possibile (anche a costo di utilizzare molte risorse computazionali), - questo potrebbe essere la nostra scelta. Ma non eravamo pronti a raddoppiare il parco macchine per aumentare la velocità delle operazioni.
Druid/Pinot
Già molto più specifico per i TSDB, ma ancora una volta - stack Hadoop.
C'è .
In poche parole: Druid/Pinot sembrano migliori di Clickhouse nei casi in cui:
- Hai un carattere eterogeneo dei dati (nel nostro caso registriamo solo le serie temporali delle metriche dei server, e, in sostanza, questa è una sola tabella. Ma possono esserci anche altri casi: serie temporali di attrezzature, serie temporali economiche, ecc. — ciascuna con la propria struttura, che devono essere aggregate e elaborate).
- Tuttavia, ci sono molte di queste informazioni.
- Le tabelle e i dati con le serie temporali appaiono e scompaiono (cioè, un certo insieme di dati arriva, viene analizzato e poi rimosso).
- Non c'è un criterio chiaro secondo cui i dati possono essere partizionati.
Nei casi opposti, ClickHouse si comporta meglio, ed è questo il nostro caso.
ClickHouse
- Simile a SQL.
- Facile da gestire.
- La gente dice che funziona.
Entrano nella short list per i test.
InfluxDB
Alternativa straniera a ClickHouse. Tra i difetti: l'High Availability è presente solo nella versione commerciale, ma è necessario confrontare.
Entrano nella short list per i test.
Cassandra
Da un lato, sappiamo che è utilizzato per memorizzare serie temporali metriche in sistemi di monitoraggio come, ad esempio, o OkMeter. Tuttavia, ci sono delle specificità.
Cassandra non è un database a colonne nella sua accezione tradizionale. Si presenta più come un database a righe, ma in ogni riga può esserci un numero diverso di colonne, il che consente di organizzare facilmente una visualizzazione a colonne. In questo senso, è chiaro che con un limite di 2 miliardi di colonne è possibile memorizzare alcuni dati proprio nelle colonne (come le serie temporali). Ad esempio, in MySQL c'è un limite di 4096 colonne e lì è facile imbattersi nell'errore con codice 1117 se si prova a fare la stessa cosa.
Il motore Cassandra è orientato alla memorizzazione di grandi volumi di dati in un sistema distribuito senza master, e nella menzionata teoria CAP, Cassandra è più orientata all'AP, ovvero all'affidabilità dei dati e alla resilienza alla partizione. Pertanto, questo strumento può essere particolarmente utile se è necessario solo scrivere su questo database e leggerlo raramente. È quindi logico utilizzare Cassandra come deposito "freddo", ovvero come un luogo di archiviazione affidabile a lungo termine per grandi volumi di dati storici che sono raramente richiesti, ma che possono essere estratti se necessario. Tuttavia, per completezza, testeremo anche essa. Ma, come ho già detto in precedenza, non ho voglia di riscrivere attivamente il codice per l'opzione di database scelta, quindi lo testeremo in modo piuttosto limitato, senza adattare la struttura del database alle specifiche di Cassandra.
Prometheus
E, per curiosità, abbiamo deciso di testare le prestazioni dello storage Prometheus, giusto per capire se siamo più veloci delle soluzioni attuali o più lenti e di quanto.
Metodologia e risultati dei test
Quindi, abbiamo testato 5 database nelle seguenti 6 configurazioni: ClickHouse (1 nodo), ClickHouse (tabella distribuita su 3 nodi), InfluxDB, Mysql 8, Cassandra (3 nodi) e Prometheus. Il piano di test è il seguente:
- carichiamo i dati storici di una settimana (840 milioni di valori al giorno; 208 mila metriche);
- generiamo carico di scrittura (abbiamo considerato 6 modalità di carico, vedere sotto);
- parallelamente alla scrittura, facciamo periodicamente delle estrazioni, emulando le richieste di un utente che lavora con grafici. Per non complicare troppo, abbiamo scelto i dati di 10 metriche (esattamente quante ce ne sono nel grafico CPU) per una settimana.
Carichiamo, emulando il comportamento del nostro agente di monitoraggio, che invia a ogni metrica valori ogni 15 secondi. Siamo interessati a variare:
- il numero totale di metriche in cui vengono scritti i dati;
- l'intervallo di invio valori in una metrica;
- la dimensione del batch.
Sulla dimensione del batch. Poiché quasi tutti i nostri database sperimentali non raccomandano di essere caricati con singole inserzioni, avremo bisogno di un relay che raccoglie le metriche in arrivo e le raggruppa per un certo numero e le scrive nel database in inserimento di batch.
Inoltre, per capire meglio come interpretare i dati ricevuti, immaginiamo che non inviamo semplicemente una serie di metriche, ma che le metriche siano organizzate in server - con 125 metriche per server. Qui il server è solo un'entità virtuale - giusto per capire che, ad esempio, 10000 metriche corrispondono a circa 80 server.
Ecco, tenendo conto di tutto questo, i nostri 6 regimi di carico del database per la scrittura:
Ci sono due aspetti. In primo luogo, per Cassandra, queste dimensioni dei batch si sono rivelate troppo grandi; lì abbiamo utilizzato valori di 50 o 100. In secondo luogo, poiché Prometheus funziona rigorosamente in modalità pull, cioè raccoglie da solo i dati dalle fonti delle metriche (e persino pushgateway, nonostante il nome, non cambia radicalmente la situazione), i carichi corrispondenti sono stati realizzati tramite una combinazione di configurazioni statiche.
I risultati del test sono i seguenti:
Cosa vale la pena notare: estrazioni fantastico veloci da Prometheus, estrazioni incredibilmente lente da Cassandra, estrazioni inaccettabilmente lente da InfluxDB; per velocità di scrittura, ClickHouse ha vinto in assoluto, mentre Prometheus non partecipa alla competizione perché esegue gli inserimenti da solo e noi non misuriamo nulla.
In definitiva: ClickHouse e InfluxDB hanno mostrato le migliori performance, ma un cluster di Influx può essere costruito solo sulla versione Enterprise, che costa dei soldi, mentre ClickHouse è gratuito e sviluppato in Russia. È logico che negli USA si opti per InfluxDB, mentre qui da noi si preferisca ClickHouse.
Fonte: habr.com
