Za posledných niekoľko rokov sa databázy časových radov zmenili z bizarnej veci (vysoko špecializovanej používanej buď v otvorených monitorovacích systémoch (a viazaných na konkrétne riešenia) alebo v projektoch veľkých dát) na „spotrebný produkt“. Na území Ruskej federácie za to treba osobitne poďakovať spoločnostiam Yandex a ClickHouse. Až do tohto momentu, ak ste potrebovali uložiť veľké množstvo časových sérií dát, museli ste sa buď vyrovnať s potrebou vybudovať monštruózny Hadoop stack a udržiavať ho, alebo komunikovať s protokolmi individuálnymi pre každý systém.
Môže sa zdať, že v roku 2019 bude článok o tom, ktorý TSDB sa oplatí používať, pozostávať iba z jednej vety: „stačí použiť ClickHouse“. Ale... sú tu nuansy.
ClickHouse sa skutočne aktívne rozvíja, používateľská základňa rastie a podpora je veľmi aktívna, no stali sme sa rukojemníkmi verejného úspechu ClickHouse, ktorý zatienil iné, možno efektívnejšie/spoľahlivejšie riešenia?
Začiatkom minulého roka sme začali prerábať vlastný monitorovací systém, počas ktorého vyvstala otázka výberu vhodnej databázy na ukladanie dát. Chcem tu hovoriť o histórii tohto výberu.
Vyhlásenie o probléme
V prvom rade nevyhnutný predslov. Prečo vôbec potrebujeme vlastný monitorovací systém a ako bol navrhnutý?
Podporné služby sme začali poskytovať v roku 2008 a v roku 2010 sa ukázalo, že je ťažké agregovať údaje o procesoch vyskytujúcich sa v klientskej infraštruktúre s riešeniami, ktoré v tom čase existovali (hovoríme o, Bože odpusť, Kaktusy, Zabbix a vznikajúci grafit).
Naše hlavné požiadavky boli:
- podpora (v tom čase - desiatky av budúcnosti - stovky) klientov v rámci jedného systému a súčasne prítomnosť centralizovaného systému správy výstrah;
- flexibilita pri správe výstražného systému (eskalácia upozornení medzi služobnými dôstojníkmi, plánovanie, vedomostná základňa);
- schopnosť grafov do hĺbky (Zabbix v tom čase vykresľoval grafy vo forme obrázkov);
- dlhodobé uchovávanie veľkého množstva dát (rok a viac) a možnosť ich rýchleho obnovenia.
V tomto článku nás zaujíma posledný bod.
Keď už hovoríme o skladovaní, požiadavky boli nasledovné:
- systém musí fungovať rýchlo;
- je žiaduce, aby systém mal rozhranie SQL;
- systém musí byť stabilný a mať aktívnu užívateľskú základňu a podporu (raz sme čelili potrebe podporovať systémy ako MemcacheDB, ktorý už nebol vyvíjaný, alebo distribuované úložisko MooseFS, ktorého bug tracker bol vedený v čínštine: opakujeme tento príbeh pre náš projekt nechcel);
- súlad s teorémom CAP: Konzistentnosť (povinné) - údaje musia byť aktuálne, nechceme, aby systém správy upozornení neprijímal nové údaje a chrlil upozornenia na neprichádzanie údajov pre všetky projekty; Partition Tolerance (povinné) – nechceme získať systém Split Brain; Dostupnosť (nie je kritická, ak existuje aktívna replika) - na záložný systém môžeme prejsť sami v prípade nehody pomocou kódu.
Napodiv, v tom čase sa pre nás ukázalo ako ideálne riešenie MySQL. Naša dátová štruktúra bola mimoriadne jednoduchá: ID servera, ID počítadla, časová pečiatka a hodnota; rýchle vzorkovanie horúcich dát bolo zabezpečené veľkým buffer poolom a vzorkovanie historických dát SSD.
Takto sme dosiahli vzorku čerstvých dvojtýždňových údajov s detailmi až na sekundu 200 ms pred úplným vykreslením údajov a žili sme v tomto systéme pomerne dlho.
Medzitým čas plynul a množstvo dát rástlo. Do roku 2016 objemy dát dosiahli desiatky terabajtov, čo bol v kontexte prenajatého SSD úložiska nemalý náklad.
Do tejto doby sa stĺpcové databázy aktívne rozšírili, o čom sme začali aktívne uvažovať: v stĺpcových databázach sú údaje uložené, ako viete, v stĺpcoch, a ak sa pozriete na naše údaje, je ľahké vidieť veľký počet duplikátov, ktoré by mohli v Ak používate stĺpcovú databázu, komprimovať ju pomocou kompresie.
Kľúčový systém spoločnosti však naďalej fungoval stabilne a nechcel som experimentovať s prechodom na niečo iné.
V roku 2017, na konferencii Percona Live v San Jose, sa vývojári Clickhouse pravdepodobne prvýkrát ohlásili. Na prvý pohľad bol systém pripravený na výrobu (no, Yandex.Metrica je drsný výrobný systém), podpora bola rýchla a jednoduchá, a čo je najdôležitejšie, obsluha jednoduchá. Od roku 2018 sme začali proces prechodu. V tom čase však existovalo veľa „dospelých“ a časom overených systémov TSDB a rozhodli sme sa venovať veľa času a porovnávať alternatívy, aby sme sa uistili, že neexistujú žiadne alternatívne riešenia pre Clickhouse podľa našich požiadaviek.
Okrem už špecifikovaných požiadaviek na skladovanie sa objavili nové:
- nový systém by mal poskytovať aspoň rovnaký výkon ako MySQL na rovnakom množstve hardvéru;
- skladovanie nového systému by malo zaberať podstatne menej miesta;
- DBMS musí byť stále ľahko spravovateľný;
- Pri zmene DBMS som chcel aplikáciu zmeniť minimálne.
Aké systémy sme začali uvažovať?
Apache Hive/Apache Impala
Starý, bitkami testovaný zásobník Hadoop. V podstate ide o rozhranie SQL postavené na ukladaní údajov v natívnych formátoch na HDFS.
Pros.
- Vďaka stabilnej prevádzke je veľmi jednoduché škálovať dáta.
- Existujú stĺpcové riešenia na ukladanie dát (menej miesta).
- Veľmi rýchle vykonávanie paralelných úloh, keď sú dostupné zdroje.
Zápory.
- Je to Hadoop a je ťažké ho používať. Ak nie sme pripravení vziať hotové riešenie v cloude (a nie sme pripravení z hľadiska nákladov), celý zásobník bude musieť byť zostavený a podporovaný rukami administrátorov, a to naozaj nechceme toto.
- Údaje sú agregované .
Možno však použiť:
Rýchlosť sa dosahuje škálovaním počtu výpočtových serverov. Jednoducho povedané, ak sme veľká spoločnosť zaoberajúca sa analytikou a pre firmu je dôležité čo najrýchlejšie agregovať informácie (aj za cenu použitia veľkého množstva výpočtových zdrojov), môže to byť naša voľba. Neboli sme však pripravení znásobiť hardvérovú flotilu, aby sme urýchlili úlohy.
Druid/Pinot
Konkrétne o TSDB je toho oveľa viac, ale opäť o zásobníku Hadoop.
K dispozícii je .
Niekoľkými slovami: Druid/Pinot vyzerá lepšie ako Clickhouse v prípadoch, keď:
- Máte heterogénnu povahu údajov (v našom prípade zaznamenávame iba časové rady serverových metrík a v skutočnosti ide o jednu tabuľku. Môžu však nastať aj iné prípady: časový rad zariadení, ekonomický časový rad atď. – každý s vlastnú štruktúru, ktorú je potrebné agregovať a spracovať).
- Okrem toho existuje veľa týchto údajov.
- Tabuľky a údaje s časovými radmi sa objavujú a miznú (to znamená, že nejaký súbor údajov prišiel, bol analyzovaný a vymazaný).
- Neexistuje jasné kritérium, podľa ktorého je možné údaje rozdeliť.
V opačných prípadoch funguje ClickHouse lepšie a toto je náš prípad.
clickhouse
- ako SQL
- Jednoduchá obsluha.
- Ľudia hovoria, že to funguje.
Dostane sa do užšieho výberu na testovanie.
InfluxDB
Zahraničná alternatíva ClickHouse. Z mínusov: Vysoká dostupnosť je prítomná iba v komerčnej verzii, ale treba ju porovnať.
Dostane sa do užšieho výberu na testovanie.
Cassandra
Na jednej strane vieme, že ho používajú na ukladanie metrických časových radov také monitorovacie systémy ako napr. alebo OkMeter. Existujú však špecifiká.
Cassandra nie je stĺpcová databáza v tradičnom zmysle. Vyzerá to skôr ako zobrazenie riadkov, ale každý riadok môže mať iný počet stĺpcov, čo uľahčuje usporiadanie stĺpcového zobrazenia. V tomto zmysle je zrejmé, že pri limite 2 miliárd stĺpcov je možné ukladať niektoré údaje do stĺpcov (a rovnakých časových radov). Napríklad v MySQL je limit 4096 stĺpcov a ak sa pokúsite urobiť to isté, je ľahké naraziť na chybu s kódom 1117.
Engine Cassandra je zameraný na ukladanie veľkého množstva dát v distribuovanom systéme bez mastera a vyššie spomínaná Cassandra CAP teoréma je skôr o AP, teda o dostupnosti dát a odolnosti voči deleniu. Tento nástroj teda môže byť skvelý, ak potrebujete do tejto databázy iba zapisovať a len zriedka z nej čítať. A tu je logické použiť Cassandru ako „studené“ úložisko. Teda ako dlhodobé a spoľahlivé miesto na ukladanie veľkého množstva historických údajov, ktoré sú zriedka potrebné, ale v prípade potreby sa dajú získať. Pre úplnosť si ho však otestujeme aj my. Ale, ako som už povedal, nie je túžba aktívne prepisovať kód pre vybrané databázové riešenie, takže ho otestujeme trochu obmedzene - bez prispôsobenia štruktúry databázy špecifikám Cassandry.
Prometheus
No, zo zvedavosti sme sa rozhodli otestovať výkon úložiska Prometheus – len aby sme pochopili, či sme rýchlejší alebo pomalší ako súčasné riešenia a o koľko.
Metodika a výsledky testovania
Testovali sme teda 5 databáz v nasledujúcich 6 konfiguráciách: ClickHouse (1 uzol), ClickHouse (distribuovaná tabuľka pre 3 uzly), InfluxDB, Mysql 8, Cassandra (3 uzly) a Prometheus. Plán testu je nasledovný:
- nahrať historické údaje za týždeň (840 miliónov hodnôt za deň; 208 tisíc metrík);
- vygenerujeme záznamovú záťaž (uvažovalo sa 6 režimov záťaže, pozri nižšie);
- Súbežne s nahrávaním pravidelne robíme výbery, ktoré napodobňujú požiadavky používateľa pracujúceho s grafmi. Aby sme to príliš nekomplikovali, vybrali sme dáta pre 10 metrík (presne toľko ich je na grafe CPU) na týždeň.
Načítavame emuláciou správania nášho monitorovacieho agenta, ktorý odosiela hodnoty do každej metriky raz za 15 sekúnd. Zároveň máme záujem meniť:
- celkový počet metrík, do ktorých sa zapisujú údaje;
- interval odosielania hodnôt do jednej metriky;
- veľkosť dávky.
O veľkosti dávky. Keďže sa neodporúča načítať takmer všetky naše experimentálne databázy jednotlivými vložkami, budeme potrebovať relé, ktoré zbiera prichádzajúce metriky a zoskupuje ich do skupín a zapisuje ich do databázy ako dávkové vloženie.
Aby sme lepšie pochopili, ako potom interpretovať prijaté údaje, predstavme si, že neposielame len veľa metrík, ale metriky sú usporiadané do serverov – 125 metrík na server. Server je tu jednoducho virtuálna entita – len pre pochopenie, že napríklad 10000 80 metrík zodpovedá približne XNUMX serverom.
A tu, berúc do úvahy toto všetko, je našich 6 režimov načítania databázy:
Sú tu dva body. Po prvé, pre Cassandru sa tieto veľkosti dávok ukázali ako príliš veľké, tam sme použili hodnoty 50 alebo 100. A po druhé, keďže Prometheus funguje striktne v režime ťahania, t.j. sám ide a zhromažďuje údaje zo zdrojov metrík (a dokonca ani pushgateway, napriek názvu, zásadne nemení situáciu), zodpovedajúce zaťaženia boli implementované pomocou kombinácie statických konfigurácií.
Výsledky testu sú nasledovné:
Čo stojí za povšimnutie: fantasticky rýchle vzorky z Prometheus, strašne pomalé vzorky z Cassandry, neprijateľne pomalé vzorky z InfluxDB; Čo sa týka rýchlosti nahrávania, ClickHouse si získal každého a Prometheus sa do súťaže nezapája, pretože si vložky vyrába sám a nič nemeriame.
V dôsledku toho,: ClickHouse a InfluxDB sa ukázali ako najlepšie, ale cluster od Influxu sa dá postaviť len na báze Enterprise verzie, ktorá stojí peniaze, kým ClickHouse nestojí nič a je vyrobený v Rusku. Je logické, že v USA je voľba zrejme v prospech inInfluxDB a u nás v prospech ClickHouse.
Zdroj: hab.com