Během několika posledních let se databáze časových řad proměnily z výstřední věci (vysoce specializované používané buď v otevřených monitorovacích systémech (a vázaných na konkrétní řešení) nebo v projektech velkých dat) ve „spotřebitelský produkt“. Na území Ruské federace je za to třeba poděkovat společnostem Yandex a ClickHouse. Až do této chvíle, pokud jste potřebovali uložit velké množství dat časových řad, museli jste se buď smířit s nutností vybudovat monstrózní Hadoop stack a udržovat jej, nebo komunikovat s protokoly individuálními pro každý systém.
Může se zdát, že v roce 2019 bude článek o tom, který TSDB stojí za použití, sestávat z jediné věty: „stačí používat ClickHouse“. Ale... jsou tam nuance.
ClickHouse se skutečně aktivně vyvíjí, uživatelská základna roste a podpora je velmi aktivní, ale stali jsme se rukojmími veřejného úspěchu ClickHouse, který zastínil jiná, možná efektivnější/spolehlivější řešení?
Začátkem loňského roku jsme začali předělávat vlastní monitorovací systém, při kterém vyvstala otázka výběru vhodné databáze pro ukládání dat. Chci zde mluvit o historii této volby.
Formulace problému
Nejprve nezbytná předmluva. Proč vůbec potřebujeme vlastní monitorovací systém a jak byl navržen?
Služby podpory jsme začali poskytovat v roce 2008 a v roce 2010 se ukázalo, že je obtížné agregovat data o procesech probíhajících v klientské infrastruktuře s řešeními, která v té době existovala (hovoříme o, Bůh mi odpusť, Cacti, Zabbix a vznikající grafit).
Naše hlavní požadavky byly:
- podpora (v té době - desítky a v budoucnu - stovky) klientů v rámci jednoho systému a zároveň přítomnost centralizovaného systému správy výstrah;
- flexibilita ve správě výstražného systému (eskalace výstrah mezi důstojníky, plánování, znalostní báze);
- schopnost hluboce detailovat grafy (Zabbix v té době vykresloval grafy ve formě obrázků);
- dlouhodobé uchovávání velkého množství dat (rok a více) a možnost jejich rychlého načtení.
V tomto článku nás zajímá poslední bod.
Pokud jde o úložiště, požadavky byly následující:
- systém musí fungovat rychle;
- je žádoucí, aby systém měl rozhraní SQL;
- systém musí být stabilní a mít aktivní uživatelskou základnu a podporu (jakmile jsme byli konfrontováni s potřebou podporovat systémy jako MemcacheDB, který již nebyl vyvíjen, nebo distribuované úložiště MooseFS, jehož bug tracker byl udržován v čínštině: opakujeme tento příběh pro náš projekt nechtěl);
- soulad s teorémem CAP: Konzistentnost (vyžadováno) - data musí být aktuální, nechceme, aby systém správy výstrah nedostával nová data a chrlil upozornění na nedoručení dat u všech projektů; Partition Tolerance (vyžadováno) – nechceme získat systém Split Brain; Dostupnost (není kritická, pokud existuje aktivní replika) - na záložní systém se můžeme v případě nehody přepnout sami pomocí kódu.
Kupodivu se pro nás v té době ukázalo jako ideální řešení MySQL. Naše datová struktura byla extrémně jednoduchá: ID serveru, ID čítače, časové razítko a hodnota; rychlé vzorkování horkých dat zajistil velký buffer pool a vzorkování historických dat SSD.
Získali jsme tak vzorek čerstvých dvoutýdenních dat s podrobnostmi až na sekundu 200 ms před úplným vykreslením dat a žili jsme v tomto systému poměrně dlouho.
Mezitím čas plynul a množství dat rostlo. Do roku 2016 dosáhly objemy dat desítek terabajtů, což byl v souvislosti s pronajatým SSD úložištěm značný náklad.
Do této doby se sloupcové databáze aktivně rozšířily, o čemž jsme začali aktivně přemýšlet: ve sloupcových databázích jsou data uložena, jak jistě chápete, ve sloupcích, a když se podíváte na naše data, je snadné vidět velké počet duplikátů, které by mohly v Pokud používáte sloupcovou databázi, komprimovat ji pomocí komprese.
Klíčový systém společnosti však nadále fungoval stabilně a nechtěl jsem experimentovat s přechodem na něco jiného.
V roce 2017 se na konferenci Percona Live v San Jose pravděpodobně poprvé ohlásili vývojáři Clickhouse. Na první pohled byl systém připraven k výrobě (no, Yandex.Metrica je drsný produkční systém), podpora byla rychlá a jednoduchá a hlavně obsluha jednoduchá. Od roku 2018 jsme zahájili proces přechodu. V té době však existovalo mnoho „dospělých“ a časem prověřených systémů TSDB a my jsme se rozhodli věnovat hodně času a porovnávat alternativy, abychom se ujistili, že neexistují alternativní řešení pro Clickhouse podle našich požadavků.
Kromě již specifikovaných požadavků na úložiště se objevily nové:
- nový systém by měl poskytovat minimálně stejný výkon jako MySQL na stejném množství hardwaru;
- úložiště nového systému by mělo zabírat výrazně méně místa;
- Správa DBMS musí být stále snadná;
- Při změně DBMS jsem chtěl aplikaci změnit minimálně.
Jaké systémy jsme začali uvažovat?
Apache Hive/Apache Impala
Starý, bitvami testovaný zásobník Hadoopů. V podstatě se jedná o SQL rozhraní postavené na ukládání dat v nativních formátech na HDFS.
Pros.
- Díky stabilnímu provozu je velmi snadné škálovat data.
- Existují sloupcová řešení pro ukládání dat (méně místa).
- Velmi rychlé provádění paralelních úloh, když jsou dostupné zdroje.
Nevýhody.
- Je to Hadoop a je obtížné ho používat. Pokud nejsme připraveni vzít hotové řešení v cloudu (a nejsme připraveni z hlediska nákladů), celý stack bude muset sestavit a podepřít rukama adminů, a to opravdu nechceme tento.
- Data jsou agregována .
Nicméně:
Rychlosti je dosaženo škálováním počtu výpočetních serverů. Jednoduše řečeno, pokud jsme velká společnost zabývající se analytikou a pro firmu je důležité co nejrychleji agregovat informace (i za cenu použití velkého množství výpočetních zdrojů), může to být naše volba. Nebyli jsme však připraveni znásobit hardwarovou flotilu, abychom urychlili úkoly.
Druid/Pinot
Konkrétně o TSDB je toho mnohem více, ale opět o zásobníku Hadoop.
K dispozici je .
Stručně řečeno: Druid/Pinot vypadají lépe než Clickhouse v případech, kdy:
- Máte heterogenní povahu dat (v našem případě zaznamenáváme pouze časové řady serverových metrik a ve skutečnosti se jedná o jednu tabulku. Mohou však existovat i jiné případy: časová řada zařízení, ekonomická časová řada atd. – každá s vlastní strukturu, kterou je třeba agregovat a zpracovat).
- Navíc těchto dat je hodně.
- Tabulky a data s časovou řadou se objevují a mizí (to znamená, že nějaká sada dat dorazila, byla analyzována a odstraněna).
- Neexistuje žádné jasné kritérium, podle kterého lze data rozdělit.
V opačných případech si ClickHouse vede lépe, a to je náš případ.
clickhouse
- jako SQL
- Snadná obsluha.
- Lidé říkají, že to funguje.
Dostane se do užšího výběru pro testování.
InfluxDB
Zahraniční alternativa ClickHouse. Z mínusů: Vysoká dostupnost je přítomna pouze v komerční verzi, ale je třeba ji porovnat.
Dostane se do užšího výběru pro testování.
Cassandra
Na jedné straně víme, že jej používají k ukládání metrických časových řad takové monitorovací systémy, jako jsou např. nebo OkMeter. Existují však specifika.
Cassandra není sloupcová databáze v tradičním slova smyslu. Vypadá to spíše jako zobrazení řádků, ale každý řádek může mít jiný počet sloupců, což usnadňuje uspořádání sloupcového zobrazení. V tomto smyslu je zřejmé, že při limitu 2 miliard sloupců je možné ukládat některá data do sloupců (a stejné časové řady). Například v MySQL je limit 4096 sloupců a pokud se pokusíte udělat totéž, je snadné narazit na chybu s kódem 1117.
Engine Cassandra je zaměřen na ukládání velkého množství dat v distribuovaném systému bez masteru a výše zmíněný teorém Cassandra CAP je spíše o AP, tedy o dostupnosti dat a odolnosti vůči dělení. Tento nástroj tedy může být skvělý, pokud potřebujete do této databáze pouze zapisovat a jen zřídka z ní číst. A zde je logické používat Cassandru jako „studené“ úložiště. Tedy jako dlouhodobé a spolehlivé místo pro ukládání velkého množství historických dat, která jsou zřídka potřebná, ale v případě potřeby je lze získat. Přesto si ho pro úplnost také otestujeme. Ale, jak jsem řekl dříve, není touha aktivně přepisovat kód pro vybrané databázové řešení, takže jej budeme testovat poněkud omezeně - bez přizpůsobení struktury databáze specifikům Cassandry.
Prometheus
No, ze zvědavosti jsme se rozhodli otestovat výkon úložiště Prometheus – jen abychom pochopili, zda jsme rychlejší nebo pomalejší než současná řešení a o kolik.
Metodika a výsledky testování
Testovali jsme tedy 5 databází v následujících 6 konfiguracích: ClickHouse (1 uzel), ClickHouse (distribuovaná tabulka pro 3 uzly), InfluxDB, Mysql 8, Cassandra (3 uzly) a Prometheus. Plán testování je následující:
- nahrát historická data za týden (840 milionů hodnot za den; 208 tisíc metrik);
- vygenerujeme záznamovou zátěž (bylo uvažováno 6 režimů zátěže, viz níže);
- Paralelně s nahráváním provádíme periodicky výběry, napodobující požadavky uživatele pracujícího s grafy. Aby to nebylo příliš komplikované, vybrali jsme data pro 10 metrik (přesně tolik jich je na grafu CPU) na týden.
Načítáme pomocí emulace chování našeho monitorovacího agenta, který odesílá hodnoty do každé metriky každých 15 sekund. Zároveň nás zajímá variace:
- celkový počet metrik, do kterých se zapisují data;
- interval pro odesílání hodnot do jedné metriky;
- objem várky.
O velikosti šarže. Protože se nedoporučuje načítat téměř všechny naše experimentální databáze jednotlivými vložkami, budeme potřebovat relé, které shromažďuje příchozí metriky a seskupuje je do skupin a zapisuje je do databáze jako dávkové vložení.
Abychom lépe porozuměli tomu, jak následně interpretovat přijatá data, představme si, že neposíláme jen hromadu metrik, ale metriky jsou organizovány do serverů – 125 metrik na server. Zde je server jednoduše virtuální entita - jen pro pochopení, že například 10000 80 metrik odpovídá asi XNUMX serverům.
A zde, vezmeme-li v úvahu toto vše, je našich 6 režimů zatížení zápisu do databáze:
Jsou zde dva body. Za prvé, pro Cassandru se tyto velikosti dávek ukázaly jako příliš velké, tam jsme použili hodnoty 50 nebo 100. A za druhé, protože Prometheus funguje striktně v pull módu, tzn. sám jde a sbírá data ze zdrojů metrik (a ani pushgateway, navzdory názvu, situaci zásadně nemění), odpovídající zátěže byly implementovány pomocí kombinace statických konfigurací.
Výsledky testu jsou následující:
Co stojí za povšimnutí: fantasticky rychlé vzorky od Promethea, strašně pomalé vzorky od Cassandry, nepřijatelně pomalé vzorky od InfluxDB; Co se týče rychlosti záznamu, ClickHouse si získal všechny a Prometheus se soutěže neúčastní, protože si vložky vyrábí sám a nic neměříme.
V důsledku toho,: ClickHouse a InfluxDB se ukázaly jako nejlepší, ale cluster od Influxu lze postavit pouze na bázi Enterprise verze, která stojí peníze, zatímco ClickHouse nestojí nic a vyrábí se v Rusku. Je logické, že v USA je volba pravděpodobně ve prospěch inInfluxDB a u nás ve prospěch ClickHouse.
Zdroj: www.habr.com