Tokom proteklih nekoliko godina, baze podataka vremenskih serija pretvorile su se iz neobične stvari (visoko specijalizovane koja se koristi ili u otvorenim sistemima za praćenje (i vezana za specifična rješenja) ili u Big Data projektima) u „potrošački proizvod“. Na teritoriji Ruske Federacije, posebna zahvalnost se mora zahvaliti Yandexu i ClickHouseu za ovo. Do ove tačke, ako ste morali da pohranite veliku količinu podataka vremenske serije, morali ste da se pomirite sa potrebom da napravite monstruozni Hadoop stek i da ga održavate, ili da komunicirate sa protokolima pojedinačnim za svaki sistem.
Može se činiti da će se 2019. članak o tome koji TSDB vrijedi koristiti sastojati od samo jedne rečenice: „samo koristite ClickHouse“. Ali... postoje nijanse.
Zaista, ClickHouse se aktivno razvija, baza korisnika raste, a podrška je vrlo aktivna, ali jesmo li postali taoci javnog uspjeha ClickHousea, koji je zasjenio druga, možda učinkovitija/pouzdanija rješenja?
Početkom prošle godine započeli smo preradu vlastitog monitoring sistema, pri čemu se postavilo pitanje odabira odgovarajuće baze podataka za pohranjivanje podataka. Želim da pričam o istoriji ovog izbora ovde.
Izjava o problemu
Prije svega, neophodan predgovor. Zašto nam je uopće potreban vlastiti sistem praćenja i kako je dizajniran?
Počeli smo pružati usluge podrške 2008. godine, a do 2010. godine postalo je jasno da je postalo teško agregirati podatke o procesima koji se dešavaju u klijentskoj infrastrukturi sa rješenjima koja su postojala u to vrijeme (govorimo o, Bože oprosti mi, Cactusima, Zabbixu i grafit u nastajanju).
Naši glavni zahtjevi su bili:
- podrška (u to vrijeme - desetine, a u budućnosti - stotine) klijenata unutar jednog sistema i istovremeno prisustvo centraliziranog sistema za upravljanje upozorenjima;
- fleksibilnost u upravljanju sistemom uzbunjivanja (eskalacija uzbuna između dežurnih, zakazivanje, baza znanja);
- mogućnost dubokog detaljiranja grafova (Zabbix je u to vrijeme prikazivao grafikone u obliku slika);
- dugotrajno skladištenje velike količine podataka (godina ili više) i mogućnost brzog preuzimanja.
U ovom članku nas zanima posljednja točka.
Kada je riječ o skladištenju, zahtjevi su bili sljedeći:
- sistem mora raditi brzo;
- poželjno je da sistem ima SQL interfejs;
- sistem mora biti stabilan i imati aktivnu korisničku bazu i podršku (jednom smo se suočili s potrebom da podržimo sisteme kao što je MemcacheDB, koji više nije razvijen, ili MooseFS distribuirano skladište, čiji se program za praćenje grešaka čuvao na kineskom: ponavljamo ovu priču za naš projekat nismo htjeli);
- usklađenost sa teoremom CAP-a: Konzistentnost (obavezno) - podaci moraju biti ažurni, ne želimo da sistem upravljanja upozorenjima ne prima nove podatke i ispljuva upozorenja o nepristizanju podataka za sve projekte; Tolerancija particije (obavezna) - ne želimo da dobijemo Split Brain sistem; Dostupnost (nije kritično, ako postoji aktivna replika) - možemo sami preći na rezervni sistem u slučaju nesreće, koristeći kod.
Začudo, u to vrijeme se MySQL pokazao kao idealno rješenje za nas. Naša struktura podataka bila je izuzetno jednostavna: id servera, id brojača, vremenska oznaka i vrijednost; brzo uzorkovanje vrućih podataka osigurano je velikim puferom bafera, a uzorkovanje povijesnih podataka osigurano je SSD-om.
Tako smo postigli uzorak svježih dvonedjeljnih podataka, sa detaljima do sekunde 200 ms prije nego što su podaci u potpunosti renderirani, i živjeli smo u ovom sistemu prilično dugo.
U međuvremenu je vrijeme prolazilo i količina podataka je rasla. Do 2016. količine podataka dostigle su desetine terabajta, što je bio značajan trošak u kontekstu iznajmljenih SSD memorija.
Do tog vremena, stupaste baze podataka postale su aktivno raširene, o čemu smo počeli aktivno razmišljati: u stupčastim bazama podataka podaci se pohranjuju, kao što možete razumjeti, u stupcima, a ako pogledate naše podatke, lako je uočiti veliki broj duplikata koji bi mogli, u Ako koristite stupastu bazu podataka, komprimirati je pomoću kompresije.
Međutim, ključni sistem kompanije je nastavio da radi stabilno i nisam želeo da eksperimentišem sa prelaskom na nešto drugo.
2017. godine, na Percona Live konferenciji u San Joseu, Clickhouse programeri su se vjerovatno prvi put oglasili. Na prvi pogled, sistem je bio spreman za proizvodnju (pa, Yandex.Metrica je oštar proizvodni sistem), podrška je bila brza i jednostavna i, što je najvažnije, rad je bio jednostavan. Od 2018. godine započeli smo proces tranzicije. Ali do tada je bilo puno „odraslih“ i vremenski testiranih TSDB sistema i odlučili smo da posvetimo dosta vremena i uporedimo alternative kako bismo se uverili da nema alternativnih rešenja za Clickhouse, prema našim zahtevima.
Pored već navedenih zahtjeva za skladištenje, pojavili su se i novi:
- novi sistem treba da obezbedi barem iste performanse kao MySQL na istoj količini hardvera;
- skladištenje novog sistema trebalo bi da zauzme znatno manje prostora;
- DBMS mora i dalje biti lak za upravljanje;
- Želio sam minimalno promijeniti aplikaciju kada mijenjam DBMS.
Koje smo sisteme počeli da razmatramo?
Apache Hive/Apache Impala
Stari, testirani Hadoop stek. U suštini, to je SQL interfejs izgrađen na vrhu skladištenja podataka u izvornim formatima na HDFS.
Pros.
- Uz stabilan rad, vrlo je lako skalirati podatke.
- Postoje stupna rješenja za pohranu podataka (manje prostora).
- Vrlo brzo izvršavanje paralelnih zadataka kada su resursi dostupni.
Cons
- To je Hadoop i teško ga je koristiti. Ako nismo spremni da preuzmemo gotova rješenja u oblaku (a nismo spremni ni po pitanju troškova), cijeli stack će morati da se sastavi i podrži od strane administratora, a mi zaista ne želimo ovo.
- Podaci su agregirani .
Ali:
Brzina se postiže skaliranjem broja računarskih servera. Jednostavno, ako smo velika kompanija, bavi se analitikom, a za poslovanje je ključno da agregira informacije što je brže moguće (čak i po cijenu korištenja velike količine računarskih resursa), ovo može biti naš izbor. Ali nismo bili spremni da umnožimo hardversku flotu da bismo ubrzali zadatke.
Druid/Pinot
Ima mnogo više konkretno o TSDB-u, ali opet, o Hadoop steku.
Postoje .
U nekoliko riječi: Druid/Pinot izgleda bolje od Clickhouse u slučajevima kada:
- Imate heterogenu prirodu podataka (u našem slučaju bilježimo samo vremenske serije metrike servera, i, zapravo, ovo je jedna tabela. Ali mogu postojati i drugi slučajevi: vremenske serije opreme, ekonomske vremenske serije, itd. - svaki sa vlastitu strukturu, koju treba agregirati i obraditi).
- Štaviše, ovih podataka ima mnogo.
- Pojavljuju se i nestaju tabele i podaci sa vremenskim serijama (tj. neki skup podataka je stigao, analiziran i obrisan).
- Ne postoji jasan kriterij prema kojem se podaci mogu podijeliti.
U suprotnim slučajevima, ClickHouse radi bolje, a ovo je naš slučaj.
clickhouse
- SQL-like
- Jednostavan za rukovanje.
- Ljudi kažu da radi.
Dolazi u uži izbor za testiranje.
InfluxDB
Strana alternativa ClickHouseu. Od minusa: visoka dostupnost je prisutna samo u komercijalnoj verziji, ali je treba uporediti.
Dolazi u uži izbor za testiranje.
Cassandra
S jedne strane, znamo da se koristi za pohranjivanje metričkih vremenskih serija od strane sistema za praćenje kao što je npr. ili OkMeter. Međutim, postoje specifičnosti.
Cassandra nije kolonarna baza podataka u tradicionalnom smislu. Više liči na prikaz reda, ali svaki red može imati različit broj kolona, što olakšava organiziranje stupnog prikaza. U tom smislu je jasno da je uz ograničenje od 2 milijarde kolona moguće pohraniti neke podatke u kolone (i iste vremenske serije). Na primjer, u MySQL-u postoji ograničenje od 4096 stupaca i lako je naići na grešku s kodom 1117 ako pokušate učiniti isto.
Cassandra engine je fokusiran na pohranjivanje velikih količina podataka u distribuirani sistem bez mastera, a gore spomenuta Cassandra CAP teorema je više o AP-u, odnosno o dostupnosti podataka i otpornosti na particioniranje. Stoga ovaj alat može biti odličan ako samo trebate pisati u ovu bazu podataka i rijetko čitati iz nje. I ovdje je logično koristiti Cassandru kao “hladno” skladište. Odnosno, kao dugoročno, pouzdano mjesto za pohranjivanje velikih količina historijskih podataka koji su rijetko potrebni, ali se mogu dohvatiti ako je potrebno. Ipak, radi kompletnosti, i mi ćemo ga testirati. Ali, kao što sam ranije rekao, ne postoji želja za aktivnim prepisivanjem koda za odabrano rješenje baze podataka, pa ćemo ga testirati donekle ograničeno - bez prilagođavanja strukture baze podataka specifičnostima Cassandre.
Prometej
Pa, iz radoznalosti, odlučili smo da testiramo performanse Prometheus pohrane - samo da shvatimo da li smo brži ili sporiji od trenutnih rješenja i za koliko.
Metodologija i rezultati ispitivanja
Dakle, testirali smo 5 baza podataka u sljedećih 6 konfiguracija: ClickHouse (1 čvor), ClickHouse (distribuirana tabela za 3 čvora), InfluxDB, Mysql 8, Cassandra (3 čvora) i Prometheus. Plan testiranja je sljedeći:
- prenesite istorijske podatke za nedelju dana (840 miliona vrednosti dnevno; 208 hiljada metrika);
- generiramo opterećenje snimanja (razmotreno je 6 načina učitavanja, vidi dolje);
- Paralelno sa snimanjem, povremeno vršimo selekcije, oponašajući zahtjeve korisnika koji radi sa grafikonima. Kako ne bismo previše komplicirali, odabrali smo podatke za 10 metrika (toliko ih ima na CPU grafu) za tjedan dana.
Učitavamo emulirajući ponašanje našeg agenta za praćenje, koji šalje vrijednosti svakoj metrici svakih 15 sekundi. Istovremeno, zainteresovani smo za različite:
- ukupan broj metrika u koje se upisuju podaci;
- interval za slanje vrijednosti u jednu metriku;
- veličina serije.
O veličini serije. Budući da se ne preporučuje učitavanje gotovo svih naših eksperimentalnih baza podataka pojedinačnim umetcima, trebat će nam relej koji prikuplja dolazne metrike i grupiše ih u grupe i upisuje ih u bazu podataka kao batch insert.
Također, da bismo bolje razumjeli kako onda interpretirati primljene podatke, zamislimo da ne šaljemo samo gomilu metrika, već su metrike organizirane u servere - 125 metrika po serveru. Ovdje je server jednostavno virtuelni entitet - samo da shvatimo da, na primjer, 10000 metrika odgovara oko 80 servera.
A evo, uzimajući sve ovo u obzir, naših 6 načina učitavanja učitavanja baze podataka:
Ovdje postoje dvije tačke. Prvo, za Cassandru su se ove veličine serije pokazale prevelike, tu smo koristili vrijednosti od 50 ili 100. I drugo, pošto Prometheus radi striktno u načinu povlačenja, tj. on sam ide i prikuplja podatke iz metričkih izvora (pa čak i pushgateway, uprkos imenu, ne mijenja suštinski situaciju), odgovarajuća opterećenja su implementirana pomoću kombinacije statičkih konfiguracija.
Rezultati testa su sljedeći:
Šta vredi napomenuti: fantastično brzi uzorci iz Prometheusa, užasno spori uzorci iz Cassandre, neprihvatljivo spori uzorci iz InfluxDB-a; Po brzini snimanja ClickHouse je osvojio sve, a Prometheus ne učestvuje u takmičenju, jer sam pravi umetke i ništa ne merimo.
Kao rezultat toga,: Najbolji su se pokazali ClickHouse i InfluxDB, ali se klaster iz Influxa može napraviti samo na bazi Enterprise verzije koja košta, dok ClickHouse ništa ne košta i proizvodi se u Rusiji. Logično je da je u SAD izbor vjerovatno u korist inInfluxDB-a, a kod nas u korist ClickHousea.
izvor: www.habr.com