Durant els darrers anys, les bases de dades de sèries temporals s'han convertit d'una cosa estranya (altament especialitzada utilitzada ja sigui en sistemes de monitoratge oberts (i vinculades a solucions específiques) o en projectes de Big Data) a un "producte de consum". Al territori de la Federació Russa, cal donar un agraïment especial a Yandex i ClickHouse. Fins a aquest punt, si calia emmagatzemar una gran quantitat de dades de sèries temporals, calia acceptar la necessitat de construir una pila Hadoop monstruosa i mantenir-la, o bé comunicar-se amb protocols individuals per a cada sistema.
Pot semblar que el 2019 un article sobre el qual val la pena utilitzar TSDB constarà d'una sola frase: "només utilitza ClickHouse". Però... hi ha matisos.
De fet, ClickHouse s'està desenvolupant activament, la base d'usuaris està creixent i el suport és molt actiu, però ens hem convertit en ostatges de l'èxit públic de ClickHouse, que ha eclipsat altres solucions, potser més efectives/fiables?
A principis de l'any passat vam començar a reelaborar el nostre propi sistema de seguiment, durant el qual va sorgir la qüestió d'escollir una base de dades adequada per emmagatzemar les dades. Vull parlar de la història d'aquesta elecció aquí.
Declaració de problemes
En primer lloc, un prefaci necessari. Per què necessitem el nostre propi sistema de monitorització i com es va dissenyar?
Vam començar a prestar serveis de suport l'any 2008, i l'any 2010 va quedar clar que es va fer difícil agregar dades sobre els processos que es produïen a la infraestructura del client amb les solucions que hi havia en aquell moment (estem parlant de, Déu em perdoni, Cacti, Zabbix). i el grafit emergent).
Els nostres principals requisits eren:
- suport (en aquell moment - desenes, i en el futur - centenars) de clients dins d'un sistema i al mateix temps la presència d'un sistema de gestió d'alertes centralitzat;
- flexibilitat en la gestió del sistema d'alerta (escalada d'alertes entre els agents de servei, programació, base de coneixement);
- la capacitat de detallar gràfics amb profunditat (Zabbix en aquell moment representava gràfics en forma d'imatges);
- emmagatzematge a llarg termini d'una gran quantitat de dades (un any o més) i la capacitat de recuperar-les ràpidament.
En aquest article ens interessa l'últim punt.
Parlant d'emmagatzematge, els requisits eren els següents:
- el sistema ha de funcionar ràpidament;
- és desitjable que el sistema tingui una interfície SQL;
- el sistema ha de ser estable i tenir una base d'usuaris i suport actius (un cop ens vam trobar davant de la necessitat de donar suport a sistemes com MemcacheDB, que ja no estava desenvolupat, o l'emmagatzematge distribuït MooseFS, el rastrejador d'errors del qual es guardava en xinès: repetim aquesta història perquè el nostre projecte no volia);
- compliment del teorema CAP: Coherència (obligatori) - les dades han d'estar actualitzades, no volem que el sistema de gestió d'alertes no rebi dades noves i escupi alertes sobre la no arribada de dades per a tots els projectes; Partition Tolerance (obligatori): no volem obtenir un sistema de Split Brain; Disponibilitat (no crítica, si hi ha una rèplica activa): podem canviar nosaltres mateixos al sistema de còpia de seguretat en cas d'accident mitjançant codi.
Curiosament, en aquell moment MySQL va resultar ser la solució ideal per a nosaltres. La nostra estructura de dades era extremadament senzilla: identificador del servidor, identificador del comptador, marca de temps i valor; El mostreig ràpid de dades calentes es va assegurar per un gran grup de memòria intermèdia i el mostreig de dades històriques es va assegurar amb SSD.
Així, vam aconseguir una mostra de dades noves de dues setmanes, amb detalls fins a un segon 200 ms abans que les dades es representessin completament, i vam viure en aquest sistema durant força temps.
Mentrestant, el temps passava i la quantitat de dades augmentava. El 2016, els volums de dades van assolir desenes de terabytes, la qual cosa va suposar una despesa important en el context de l'emmagatzematge SSD llogat.
En aquest moment, les bases de dades en columna s'havien generalitzat activament, cosa que vam començar a pensar activament: a les bases de dades en columna, les dades s'emmagatzemen, com podeu entendre, en columnes, i si mireu les nostres dades, és fàcil veure una gran nombre de duplicats que podria, a Si utilitzeu una base de dades columnar, comprimir-la mitjançant la compressió.
Tanmateix, el sistema clau de l'empresa va continuar funcionant de manera estable i no volia experimentar amb el canvi a una altra cosa.
El 2017, a la conferència de Percona Live a San Jose, probablement els desenvolupadors de Clickhouse es van anunciar per primera vegada. A primera vista, el sistema estava llest per a la producció (bé, Yandex.Metrica és un sistema de producció dur), el suport era ràpid i senzill i, el més important, el funcionament era senzill. Des del 2018, hem iniciat el procés de transició. Però en aquell moment, hi havia molts sistemes TSDB "adults" i provats amb el temps, i vam decidir dedicar un temps considerable i comparar alternatives per assegurar-nos que no hi havia solucions alternatives a Clickhouse, segons els nostres requisits.
A més dels requisits d'emmagatzematge ja especificats, n'han aparegut de nous:
- el nou sistema hauria de proporcionar almenys el mateix rendiment que MySQL amb la mateixa quantitat de maquinari;
- l'emmagatzematge del nou sistema hauria d'ocupar molt menys espai;
- El SGBD encara ha de ser fàcil de gestionar;
- Volia canviar l'aplicació mínimament quan canviava el SGBD.
Quins sistemes vam començar a considerar?
Apache Hive/Apache Impala
Una pila de Hadoop antiga i provada a la batalla. Essencialment, és una interfície SQL construïda per emmagatzemar dades en formats natius a HDFS.
Pros.
- Amb un funcionament estable, és molt fàcil escalar les dades.
- Hi ha solucions de columna per a l'emmagatzematge de dades (menys espai).
- Execució molt ràpida de tasques paral·leles quan hi ha recursos disponibles.
Contres.
- És Hadoop i és difícil d'utilitzar. Si no estem preparats per prendre una solució ja feta al núvol (i no estem preparats en termes de cost), tota la pila haurà de ser muntada i suportada per mans dels administradors, i realment no volem això.
- Les dades s'agreguen .
Tanmateix:
La velocitat s'aconsegueix escalant el nombre de servidors informàtics. En poques paraules, si som una empresa gran, dedicada a l'anàlisi i és fonamental per a l'empresa agregar informació el més ràpidament possible (fins i tot a costa d'utilitzar una gran quantitat de recursos informàtics), aquesta pot ser la nostra elecció. Però no estàvem preparats per multiplicar la flota de maquinari per accelerar les tasques.
Druida/Pinot
Hi ha molt més sobre TSDB específicament, però de nou, la pila Hadoop.
Hi .
En poques paraules: Druid/Pinot es veu millor que Clickhouse en els casos en què:
- Teniu una naturalesa heterogènia de dades (en el nostre cas, registrem només sèries temporals de mètriques del servidor i, de fet, aquesta és una taula. Però hi pot haver altres casos: sèries temporals d'equips, sèries temporals econòmiques, etc., cadascun amb la seva pròpia estructura, que s'han d'agregar i processar).
- A més, hi ha moltes d'aquestes dades.
- Apareixen i desapareixen taules i dades amb sèries temporals (és a dir, va arribar algun conjunt de dades, es va analitzar i es va eliminar).
- No hi ha un criteri clar pel qual es puguin dividir les dades.
En casos oposats, ClickHouse funciona millor, i aquest és el nostre cas.
Feu clic a Casa
- semblant a SQL
- Fàcil de gestionar.
- La gent diu que funciona.
És preseleccionat per a la prova.
InfluxDB
Una alternativa estrangera a ClickHouse. Dels inconvenients: l'alta disponibilitat només està present a la versió comercial, però cal comparar-la.
És preseleccionat per a la prova.
Cassandra
D'una banda, sabem que s'utilitza per emmagatzemar sèries temporals mètriques mitjançant sistemes de monitoratge com, per exemple, o OkMeter. Tanmateix, hi ha especificitats.
Cassandra no és una base de dades columnar en el sentit tradicional. S'assembla més a una vista de fila, però cada línia pot tenir un nombre diferent de columnes, de manera que és fàcil organitzar una vista de columna. En aquest sentit, és evident que amb un límit de 2 milions de columnes, és possible emmagatzemar algunes dades en columnes (i la mateixa sèrie temporal). Per exemple, a MySQL hi ha un límit de 4096 columnes i és fàcil trobar un error amb el codi 1117 si intenteu fer el mateix.
El motor Cassandra se centra a emmagatzemar grans quantitats de dades en un sistema distribuït sense un mestre, i el teorema Cassandra CAP esmentat més amunt tracta més sobre AP, és a dir, sobre la disponibilitat de dades i la resistència a la partició. Per tant, aquesta eina pot ser fantàstica si només cal escriure en aquesta base de dades i rarament llegir-ne. I aquí és lògic utilitzar Cassandra com a magatzem "fred". És a dir, com a lloc fiable a llarg termini per emmagatzemar grans quantitats de dades històriques que poques vegades es necessiten, però que es poden recuperar si cal. No obstant això, per tal de ser complet, també ho provarem. Però, com he dit anteriorment, no hi ha cap voluntat de reescriure activament el codi de la solució de base de dades seleccionada, de manera que la provarem de manera una mica limitada, sense adaptar l'estructura de la base de dades a les especificitats de Cassandra.
Prometeu
Bé, per curiositat, vam decidir provar el rendiment de l'emmagatzematge de Prometheus, només per entendre si som més ràpids o més lents que les solucions actuals i en quant.
Metodologia de prova i resultats
Així doncs, vam provar 5 bases de dades en les 6 configuracions següents: ClickHouse (1 node), ClickHouse (taula distribuïda per a 3 nodes), InfluxDB, Mysql 8, Cassandra (3 nodes) i Prometheus. El pla de proves és el següent:
- penjar dades històriques durant una setmana (840 milions de valors per dia; 208 mil mètriques);
- generem una càrrega de gravació (es van considerar 6 modes de càrrega, vegeu més avall);
- Paral·lelament a l'enregistrament, fem seleccions periòdicament, emulant les peticions d'un usuari que treballa amb gràfics. Per no complicar massa les coses, hem seleccionat dades per a 10 mètriques (això és exactament quants n'hi ha al gràfic de la CPU) durant una setmana.
Ens carreguem emulant el comportament del nostre agent de monitoratge, que envia valors a cada mètrica un cop cada 15 segons. Al mateix temps, ens interessa variar:
- el nombre total de mètriques en què s'escriuen les dades;
- interval per enviar valors a una mètrica;
- Mida del lot.
Sobre la mida del lot. Com que no es recomana carregar gairebé totes les nostres bases de dades experimentals amb insercions individuals, necessitarem un relé que reculli mètriques entrants i les agrupi en grups i les escrigui a la base de dades com a inserció per lots.
A més, per entendre millor com interpretar les dades rebudes, imaginem que no només enviem un munt de mètriques, sinó que les mètriques estan organitzades en servidors: 125 mètriques per servidor. Aquí el servidor és simplement una entitat virtual, només per entendre que, per exemple, 10000 mètriques corresponen a uns 80 servidors.
I aquí, tenint en compte tot això, els nostres 6 modes de càrrega d'escriptura de bases de dades:
Aquí hi ha dos punts. En primer lloc, per a Cassandra aquestes mides de lot van resultar ser massa grans, allà vam utilitzar valors de 50 o 100. I en segon lloc, ja que Prometheus funciona estrictament en mode d'extracció, és a dir. ell mateix va i recull dades de fonts de mètriques (i fins i tot pushgateway, malgrat el nom, no canvia fonamentalment la situació), les càrregues corresponents es van implementar mitjançant una combinació de configuracions estàtiques.
Els resultats de la prova són els següents:
El que val la pena destacar: mostres fantàsticament ràpides de Prometheus, mostres terriblement lentes de Cassandra, mostres inacceptablement lentes d'InfluxDB; Pel que fa a la velocitat d'enregistrament, ClickHouse va guanyar tothom, i Prometheus no participa en el concurs, perquè fa insercions per si mateix i no mesurem res.
Com a resultat, els: ClickHouse i InfluxDB van tenir el millor rendiment, però un clúster d'Influx només es pot construir a partir de la versió Enterprise, que costa diners, mentre que ClickHouse no costa res i es fa a Rússia. És lògic que als EUA l'elecció sigui probablement a favor d'inInfluxDB, i al nostre país sigui a favor de ClickHouse.
Font: www.habr.com