Podíváme se, jak Zabbix pracuje s databází TimescaleDB jako backendem. Ukážeme vám, jak začít od nuly a jak migrovat z PostgreSQL. Poskytneme také srovnávací testy výkonu obou konfigurací.
HighLoad++ Siberia 2019. Tomsk Hall. 24. června, 16:00. Teze a . Příští konference HighLoad++ se bude konat 6. a 7. dubna 2020 v St. Petersburgu. Podrobnosti a vstupenky .
Andrey Gushchin (dále jen AG): – Jsem technik technické podpory ZABBIX (dále jen „Zabbix“), školitel. V technické podpoře pracuji více než 6 let a mám přímou zkušenost s výkonem. Dnes budu mluvit o výkonu, který TimescaleDB může poskytnout ve srovnání s běžným PostgreSQL 10. Také nějaká úvodní část o tom, jak to funguje obecně.
Hlavní výzvy v oblasti produktivity: od sběru dat po čištění dat
Za prvé, existují určité problémy s výkonem, kterým čelí každý monitorovací systém. První výzvou produktivity je rychlé shromažďování a zpracování dat.
Dobrý monitorovací systém by měl rychle, včas přijímat všechna data, zpracovávat je podle spouštěcích výrazů, tedy zpracovávat je podle nějakých kritérií (v různých systémech se to liší) a ukládat je do databáze, aby bylo možné tato data použít v budoucnost.
Druhou výkonnostní výzvou je ukládání historie. Ukládejte často do databáze a získejte rychlý a pohodlný přístup k těmto metrikám, které byly shromážděny po určitou dobu. Nejdůležitější je, aby se tato data dala pohodlně získat, použít v reportech, grafech, triggerech, v některých prahových hodnotách, pro výstrahy atd.
Třetí výkonnostní výzvou je vymazání historie, tedy když se dostanete do bodu, kdy nepotřebujete ukládat žádné podrobné metriky, které byly shromážděny za 5 let (i měsíce nebo dva měsíce). Některé síťové uzly byly odstraněny nebo někteří hostitelé, metriky již nejsou potřeba, protože jsou již zastaralé a již se neshromažďují. To vše je potřeba vyčistit, aby se vaše databáze příliš nerozrostla. Obecně platí, že mazání historie je pro úložiště nejčastěji vážným testem – často má velmi silný dopad na výkon.
Jak vyřešit problémy s mezipamětí?
Nyní budu mluvit konkrétně o Zabbix. V Zabbixu je první a druhé volání řešeno pomocí mezipaměti.
Sběr a zpracování dat – K ukládání všech těchto dat používáme RAM. Tato data budou nyní probrána podrobněji.
Také na straně databáze je nějaké ukládání do mezipaměti pro hlavní výběry - pro grafy a další věci.
Ukládání do mezipaměti na straně samotného serveru Zabbix: máme ConfigurationCache, ValueCache, HistoryCache, TrendsCache. co to je?
ConfigurationCache je hlavní mezipaměť, do které ukládáme metriky, hostitele, datové položky, spouštěče; vše, co potřebujete ke zpracování předzpracování, sběr dat, od kterých hostitelů sbírat, s jakou frekvencí. To vše je uloženo v ConfigurationCache, aby se nedostalo do databáze a nevytvářelo zbytečné dotazy. Po spuštění serveru tuto mezipaměť aktualizujeme (vytvoříme) a pravidelně aktualizujeme (v závislosti na nastavení konfigurace).
Ukládání do mezipaměti v Zabbix. Sběr dat
Zde je diagram poměrně velký:
Hlavními ve schématu jsou tyto kolektory:
Jedná se o samotné montážní procesy, různé „pollery“, které jsou zodpovědné za různé typy montáží. Shromažďují data přes icmp, ipmi a různé protokoly a přenášejí je do předběžného zpracování.
Předzpracování HistoryCache
Také, pokud máme vypočítané datové prvky (kdo znají Zabbix, ví), tedy vypočítané agregační datové prvky, bereme je přímo z ValueCache. Jak se to naplní, vám řeknu později. Všechny tyto kolektory používají ConfigurationCache k přijímání svých úloh a poté je předávají k předběžnému zpracování.
Předzpracování také používá ConfigurationCache k získání kroků předzpracování a zpracovává tato data různými způsoby. Od verze 4.2 jsme jej přesunuli na proxy. To je velmi výhodné, protože samotné předběžné zpracování je poměrně obtížná operace. A pokud máte velmi velký Zabbix, s velkým počtem datových prvků a vysokou frekvencí sběru, pak to značně zjednodušuje práci.
Poté, co jsme tato data nějakým způsobem zpracovali pomocí předběžného zpracování, uložíme je do HistoryCache, abychom je mohli dále zpracovat. Tím sběr dat končí. Přejdeme k hlavnímu procesu.
Práce synchronizátoru historie
Hlavním procesem v Zabbix (protože se jedná o monolitickou architekturu) je History syncer. Toto je hlavní proces, který se konkrétně zabývá atomickým zpracováním každého datového prvku, tedy každé hodnoty:
- hodnota přichází (přebírá ji z HistoryCache);
- kontroluje v Configuration syncer: zda existují nějaké spouštěče pro výpočet - vypočítá je;
pokud existuje - vytváří události, vytváří eskalaci za účelem vytvoření výstrahy, v případě potřeby podle konfigurace; - zaznamenává spouštěče pro následné zpracování, agregaci; pokud provádíte agregaci za poslední hodinu a tak dále, tato hodnota si ValueCache zapamatuje, aby se nedostala do tabulky historie; ValueCache je tedy naplněna nezbytnými daty, která jsou nezbytná pro výpočet triggerů, vypočtených prvků atd.;
- poté History syncer zapíše všechna data do databáze;
- databáze je zapisuje na disk – zde proces zpracování končí.
Databáze. Ukládání do mezipaměti
Na straně databáze, když si chcete prohlédnout grafy nebo nějaké reporty o událostech, jsou různé cache. Ale v této zprávě o nich nebudu mluvit.
Pro MySQL existuje Innodb_buffer_pool a spousta různých mezipamětí, které lze také nakonfigurovat.
Ale toto jsou ty hlavní:
- sdílené_vyrovnávací paměti;
- efektivní_velikost_mezipaměti;
- sdílený_pool.
U všech databází jsem řekl, že existují určité mezipaměti, které umožňují ukládat do RAM data, která jsou často potřebná pro dotazy. Mají na to své vlastní technologie.
O výkonu databáze
V souladu s tím existuje konkurenční prostředí, to znamená, že server Zabbix shromažďuje data a zaznamenává je. Po restartu také čte z historie, aby naplnil ValueCache a tak dále. Zde můžete mít skripty a sestavy, které využívají Zabbix API, které je postaveno na webovém rozhraní. Zabbix API vstupuje do databáze a přijímá potřebná data pro získání grafů, zpráv nebo nějakého seznamu událostí, nedávných problémů.
Velmi oblíbeným vizualizačním řešením je také Grafana, kterou naši uživatelé využívají. Možnost přímého přihlášení jak přes Zabbix API, tak přes databázi. Vytváří také určitou konkurenci pro získávání dat: je zapotřebí jemnější a lepší vyladění databáze, aby bylo vyhověno rychlému poskytování výsledků a testování.
Vymazání historie. Zabbix má hospodyni
Třetí volání, které se používá v Zabbix, je vymazání historie pomocí Housekeeper. Housekeeper dodržuje všechna nastavení, to znamená, že naše datové prvky udávají, jak dlouho ukládat (ve dnech), jak dlouho ukládat trendy a dynamiku změn.
Nemluvil jsem o TrendCache, který počítáme za běhu: přijdou data, agregujeme je za jednu hodinu (většinou se jedná o čísla za poslední hodinu), množství je průměrné/minimální a zaznamenáváme je jednou za hodinu v tabulka dynamiky změn („Trendy“) . „Hospodář“ spouští a odstraňuje data z databáze pomocí pravidelných výběrů, což není vždy efektivní.
Jak pochopit, že je to neúčinné? Na grafech výkonnosti interních procesů můžete vidět následující obrázek:
Váš synchronizátor historie je neustále zaneprázdněn (červený graf). A „červený“ graf, který je nahoře. Toto je „Hospodář“, který se spustí a čeká, až databáze smaže všechny řádky, které zadala.
Vezměme si nějaké ID položky: musíte smazat posledních 5 tisíc; samozřejmě podle indexů. Obvykle je ale datový soubor poměrně velký – databáze jej stále čte z disku a ukládá do mezipaměti, což je pro databázi velmi nákladná operace. V závislosti na jeho velikosti to může vést k určitým problémům s výkonem.
Housekeeper můžete zakázat jednoduchým způsobem - máme známé webové rozhraní. Nastavení v Administraci obecné (nastavení pro „Hospodář“) zakážeme vnitřní správu vnitřní historie a trendů. V souladu s tím to Housekeeper již nekontroluje:
Co můžete dělat dál? Vypnul jste to, vaše grafy se vyrovnaly... Jaké další problémy by v tomto případě mohly nastat? Co může pomoci?
Dělení na oddíly
Obvykle je to na každé relační databázi, kterou jsem uvedl, nakonfigurováno jiným způsobem. MySQL má svou vlastní technologii. Ale celkově jsou velmi podobné, pokud jde o PostgreSQL 10 a MySQL. Samozřejmě existuje mnoho vnitřních rozdílů v tom, jak je to všechno implementováno a jak to všechno ovlivňuje výkon. Obecně ale vytvoření nového oddílu často vede také k určitým problémům.
V závislosti na vašem nastavení (kolik dat vytvoříte za jeden den) obvykle stanoví minimum - to je 1 den / dávka a pro „trendy“ dynamika změn - 1 měsíc / nová dávka. To se může změnit, pokud máte velmi rozsáhlé nastavení.
Řekněme hned o velikosti nastavení: až 5 tisíc nových hodnot za sekundu (tzv. nvps) - to bude považováno za malé „nastavení“. Průměr – od 5 do 25 tisíc hodnot za sekundu. Vše, co je uvedeno výše, jsou již velké a velmi rozsáhlé instalace, které vyžadují velmi pečlivou konfiguraci databáze.
U velmi velkých instalací nemusí být 1 den optimální. Osobně jsem viděl oddíly na MySQL o velikosti 40 gigabajtů za den (a může jich být více). Jedná se o velmi velké množství dat, což může vést k určitým problémům. Je potřeba to snížit.
Proč potřebujete rozdělení?
Myslím, že každý ví, co dělení poskytuje, je dělení tabulek. Často se jedná o samostatné soubory na disku a požadavky na rozpětí. Vybere jeden oddíl optimálněji, pokud je součástí normálního rozdělení.
Konkrétně pro Zabbix se používá podle rozsahu, podle rozsahu, to znamená, že používáme časové razítko (běžné číslo, čas od začátku epochy). Zadáte začátek dne/konec dne a toto je oddíl. Pokud tedy požadujete data stará dva dny, vše se z databáze načte rychleji, protože stačí načíst jeden soubor do mezipaměti a vrátit jej (spíše než velkou tabulku).
Mnoho databází také zrychluje insert (vkládání do jedné podřízené tabulky). Zatím mluvím abstraktně, ale i to je možné. Dělení často pomáhá.
Elasticsearch pro NoSQL
Nedávno jsme ve verzi 3.4 implementovali řešení NoSQL. Přidána možnost psát v Elasticsearch. Můžete psát určité typy: vyberete si - buď napište čísla nebo nějaké znaky; máme textový řetězec, můžete zapisovat protokoly do Elasticsearch... V souladu s tím webové rozhraní také přistoupí k Elasticsearch. V některých případech to funguje skvěle, ale v tuto chvíli to lze použít.
TimescaleDB. Hypertabulky
U 4.4.2 jsme věnovali pozornost jedné věci, jako je TimescaleDB. co to je? Toto je rozšíření pro PostgreSQL, to znamená, že má nativní rozhraní PostgreSQL. Navíc vám toto rozšíření umožňuje mnohem efektivněji pracovat s daty s časovými řadami a mít automatické dělení. Jak to vypadá:
Toto je hypertable - takový koncept existuje v Timescale. Toto je hypertabulka, kterou vytvoříte, a obsahuje kousky. Kousky jsou oddíly, toto jsou podřízené tabulky, pokud se nemýlím. Je to opravdu účinné.
TimescaleDB a PostgreSQL
Jak ujišťují výrobci TimescaleDB, používají pro zpracování dotazů, zejména insertů, přesnější algoritmus, který jim umožňuje mít přibližně konstantní výkon s rostoucí velikostí insertu datové sady. To znamená, že po 200 milionech řádků Postgres se ten obvyklý začne velmi propadat a ztrácí výkon doslova na nule, zatímco Timescale umožňuje vkládat inserty co nejefektivněji s jakýmkoli množstvím dat.
Jak nainstalovat TimescaleDB? Je to jednoduché!
Je to v dokumentaci, je to popsané - můžete to nainstalovat z balíčků pro libovolné... Záleží na oficiálních balíčcích Postgres. Lze sestavit ručně. Stalo se, že jsem musel kompilovat pro databázi.
Na Zabbix jednoduše aktivujeme Extention. Myslím, že ti, co používali Extention v Postgresu... Jednoduše si Extention aktivujete, vytvoříte pro databázi Zabbix, kterou používáte.
A poslední krok...
TimescaleDB. Migrace tabulek historie
Musíte vytvořit hypertabulku. K tomu existuje speciální funkce – Create hypertable. V něm je prvním parametrem tabulka, která je v této databázi potřeba (pro kterou je potřeba vytvořit hypertabulku).
Pole, pomocí kterého se má vytvořit, a chunk_time_interval (toto je interval chunků (oddílů, které je třeba použít). 86 400 je jeden den.
Parametr Migrate_data: Pokud vložíte na hodnotu true, budou všechna aktuální data migrována do předem vytvořených bloků.
Sám jsem použil migrate_data – trvá to poměrně dlouho, v závislosti na tom, jak velká je vaše databáze. Měl jsem přes terabajt – jeho vytvoření trvalo přes hodinu. V některých případech jsem během testování vymazal historická data pro text (history_text) a řetězec (history_str), abych je nepřenesl - opravdu mě nezajímaly.
A provádíme poslední aktualizaci v našem db_extention: nainstalujeme timescaledb, aby databáze a zejména náš Zabbix pochopily, že existuje db_extention. Aktivuje ji a použije správnou syntaxi a dotazy do databáze pomocí těch „funkcí“, které jsou pro TimescaleDB nezbytné.
Konfigurace serveru
Použil jsem dva servery. První server je poměrně malý virtuální stroj, 20 procesorů, 16 gigabajtů RAM. Nakonfiguroval jsem na něm Postgres 10.8:
Operačním systémem byl Debian, souborovým systémem byl xfs. Pro použití této konkrétní databáze jsem provedl minimální nastavení, bez toho, co bude používat samotný Zabbix. Na stejném stroji byl server Zabbix, PostgreSQL a agenti zatížení.
Použil jsem 50 aktivních agentů, kteří používají LoadableModule k rychlému generování různých výsledků. Jsou to oni, kdo vygeneroval řetězce, čísla a tak dále. Naplnil jsem databázi spoustou dat. Zpočátku konfigurace obsahovala 5 tisíc datových prvků na hostitele a přibližně každý datový prvek obsahoval spoušť - aby to bylo skutečné nastavení. Někdy dokonce potřebujete k použití více než jeden spouštěč.
Interval aktualizace a samotnou zátěž jsem reguloval nejen pomocí 50 agentů (přidání dalších), ale také pomocí dynamických datových prvků a zkrácením intervalu aktualizace na 4 sekundy.
Zkouška výkonu. PostgreSQL: 36 tisíc NVP
První spuštění, první nastavení, které jsem měl, bylo na čistém PostreSQL 10 na tomto hardwaru (35 tisíc hodnot za sekundu). Obecně, jak můžete vidět na obrazovce, vkládání dat trvá zlomky sekund - vše je dobré a rychlé, SSD disky (200 gigabajtů). Jediná věc je, že 20 GB se zaplní celkem rychle.
Takových grafů bude v budoucnu poměrně hodně. Toto je standardní řídicí panel výkonu serveru Zabbix.
První graf je počet hodnot za sekundu (modrý, vlevo nahoře), v tomto případě 35 tisíc hodnot. Toto (uprostřed nahoře) je načítání procesů sestavení a toto (vpravo nahoře) je načítání interních procesů: synchronizátorů historie a hospodyně, které zde (uprostřed dole) běží už nějakou dobu.
Tento graf (uprostřed dole) ukazuje využití ValueCache – počet zásahů ValueCache pro spouštěče (několik tisíc hodnot za sekundu). Dalším důležitým grafem je čtvrtý (vlevo dole), který ukazuje použití HistoryCache, o kterém jsem mluvil, což je buffer před vložením do databáze.
Zkouška výkonu. PostgreSQL: 50 tisíc NVP
Dále jsem zvýšil zatížení na 50 tisíc hodnot za sekundu na stejném hardwaru. Při načtení Housekeeperem bylo zaznamenáno 10 tisíc hodnot za 2-3 sekundy s výpočtem. Co je ve skutečnosti zobrazeno na následujícím snímku obrazovky:
„Housekeeper“ už začíná překážet v práci, ale obecně je zatížení lapačů historie stále na úrovni 60 % (třetí graf vpravo nahoře). HistoryCache se již začíná aktivně plnit, zatímco Housekeeper běží (vlevo dole). Bylo to asi půl gigabajtu, zaplněno z 20 %.
Zkouška výkonu. PostgreSQL: 80 tisíc NVP
Pak jsem to zvýšil na 80 tisíc hodnot za sekundu:
Jednalo se přibližně o 400 tisíc datových prvků, 280 tisíc triggerů. Vložka, jak je vidět, co se týče zátěže potápěčů historie (bylo jich 30), byla už dost vysoká. Pak jsem zvýšil různé parametry: history sinkery, cache... Na tomto hardwaru se zátěž na history sinkery začala zvyšovat na maximum, téměř „na polici“ - v souladu s tím se HistoryCache dostal do velmi vysoké zátěže:
Celou tu dobu jsem sledoval všechny systémové parametry (jak je využíván procesor, RAM) a zjistil jsem, že vytížení disku bylo maximální - dosáhl jsem maximální kapacity tohoto disku na tomto hardwaru, na tomto virtuálním stroji. "Postgres" začal v takové intenzitě celkem aktivně vyhazovat data a disk už neměl čas na zápis, čtení...
Vzal jsem další server, který již měl 48 procesorů a 128 gigabajtů RAM:
Také jsem to „vyladil“ - nainstaloval History syncer (60 kusů) a dosáhl přijatelného výkonu. Ve skutečnosti nejsme „na polici“, ale to je asi hranice produktivity, kde už je potřeba s tím něco dělat.
Zkouška výkonu. TimescaleDB: 80 tisíc NVP
Mým hlavním úkolem bylo používat TimescaleDB. Každý graf ukazuje pokles:
Tato selhání jsou přesně migrací dat. Poté se na serveru Zabbix, jak vidíte, načítací profil potápěčů historie hodně změnil. Umožňuje vám vkládat data téměř 3krát rychleji a používat méně HistoryCache – v souladu s tím budete mít data doručena včas. Opět platí, že 80 tisíc hodnot za sekundu je poměrně vysoká rychlost (samozřejmě ne pro Yandex). Celkově se jedná o poměrně velké nastavení s jedním serverem.
Test výkonu PostgreSQL: 120 tisíc NVP
Dále jsem zvýšil hodnotu počtu datových prvků na půl milionu a dostal jsem vypočítanou hodnotu 125 tisíc za sekundu:
A dostal jsem tyto grafy:
V zásadě se jedná o pracovní nastavení, může fungovat poměrně dlouho. Ale jelikož jsem měl jen 1,5 terabajtový disk, spotřeboval jsem ho za pár dní. Nejdůležitější je, že zároveň byly vytvořeny nové oddíly na TimescaleDB, a to bylo zcela bez povšimnutí pro výkon, což se o MySQL říci nedá.
Oddíly se obvykle vytvářejí v noci, protože to obecně blokuje vkládání a práci s tabulkami a může vést k degradaci služby. V tomto případě tomu tak není! Hlavním úkolem bylo otestovat schopnosti TimescaleDB. Výsledkem bylo následující číslo: 120 tisíc hodnot za sekundu.
V komunitě jsou také příklady:
Osoba také zapnula TimescaleDB a zátěž na používání io.weight klesla na procesor; a používání prvků vnitřního procesu se také snížilo kvůli zahrnutí TimescaleDB. Navíc jde o obyčejné pancake disky, tedy obyčejný virtuální stroj na obyčejných discích (ne SSD)!
Pro některá malá nastavení, která jsou omezena výkonem disku, je TimescaleDB podle mého názoru velmi dobré řešení. Umožní vám pokračovat v práci před migrací na rychlejší hardware databáze.
Zvu vás všechny na naše akce: Konference v Moskvě, Summit v Rize. Použijte naše kanály - Telegram, fórum, IRC. Máte-li nějaké dotazy, přijďte k nám na stůl, můžeme si o všem popovídat.
Otázky publika
Otázka z publika (dále - A): - Pokud je TimescaleDB tak snadno konfigurovatelný a poskytuje takové zvýšení výkonu, pak by to možná mělo být použito jako nejlepší postup pro konfiguraci Zabbix s Postgres? A má toto řešení nějaká úskalí a nevýhody, nebo když už bych se rozhodl udělat Zabbix pro sebe, klidně si vezmu Postgres, nainstaluji si tam Timescale hned, používat ho a nemyslet na problémy?
AG: – Ano, řekl bych, že je to dobré doporučení: okamžitě použijte Postgres s rozšířením TimescaleDB. Jak jsem již řekl, mnoho dobrých recenzí, navzdory skutečnosti, že tato „funkce“ je experimentální. Ale ve skutečnosti testy ukazují, že je to skvělé řešení (s TimescaleDB) a myslím, že se bude vyvíjet! Sledujeme, jak se toto rozšíření vyvíjí, a podle potřeby provedeme změny.
Už při vývoji jsme spoléhali na jednu z jejich známých „vlastností“: s kousky se dalo pracovat trochu jinak. Ale pak to v příštím vydání vystřihli a my jsme museli přestat spoléhat na tento kód. Doporučil bych použít toto řešení v mnoha nastaveních. Pokud používáte MySQL... Pro průměrná nastavení funguje každé řešení dobře.
A: – Na posledních grafech z komunity byl graf s „Hospodářkou“:
Pokračoval v práci. Co dělá Housekeeper s TimescaleDB?
AG: – Teď to nemohu s jistotou říci – podívám se na kód a řeknu vám to podrobněji. Dotazy TimescaleDB nepoužívá k odstranění kusů, ale k jejich agregaci. Na tuto technickou otázku ještě nejsem připraven odpovědět. Více se dozvíme na stánku dnes nebo zítra.
A: – Mám podobnou otázku – ohledně provedení operace odstranění v Timescale.
Odpověď (odpověď z publika): – Když mažete data z tabulky, pokud to děláte přes delete, tak je potřeba projít tabulkou – smazat, vyčistit, označit vše pro budoucí vakuování. V Timescale, protože máte kousky, můžete klesnout. Zhruba řečeno, jednoduše řeknete souboru, který je ve velkých datech: "Smazat!"
Timescale prostě chápe, že takový kus už neexistuje. A protože je integrován do plánovače dotazů, používá háčky k zachycení vašich podmínek při výběru nebo jiných operacích a okamžitě pochopí, že tento kus již neexistuje - "Už tam nebudu!" (údaje nejsou k dispozici). To je vše! To znamená, že skenování tabulky je nahrazeno smazáním binárního souboru, takže je rychlé.
A: – Tématu non-SQL jsme se již dotkli. Pokud jsem pochopil, Zabbix ve skutečnosti nepotřebuje upravovat data a to vše je něco jako protokol. Je možné používat specializované databáze, které neumí měnit svá data, ale zároveň je mnohem rychleji ukládají, kumulují a distribuují - třeba Clickhouse, něco jako Kafka?... Kafka je taky log! Je možné je nějak integrovat?
AG: - Vyložení lze provést. Od verze 3.4 máme určitou „funkci“: do souborů můžete zapisovat všechny historické soubory, události, vše ostatní; a poté jej odeslat do jakékoli jiné databáze pomocí nějakého handleru. Ve skutečnosti mnoho lidí předělává a zapisuje přímo do databáze. Za běhu to vše zapisují potápěči historie do souborů, otáčejí tyto soubory a tak dále a vy to můžete přenést do Clickhouse. Nemohu říci o plánech, ale možná bude pokračovat další podpora řešení NoSQL (jako je Clickhouse).
A: – Obecně se ukazuje, že se můžete úplně zbavit postgresů?
AG: – Samozřejmě nejobtížnější částí Zabbixu jsou historické tabulky, které vytvářejí nejvíce problémů a událostí. V tomto případě, pokud neukládáte události po dlouhou dobu a ukládáte historii s trendy v nějakém jiném rychlém úložišti, obecně si myslím, že nebudou žádné problémy.
A: – Dokážete odhadnout, o kolik rychleji bude vše fungovat, pokud přejdete například na Clickhouse?
AG: – nemám to vyzkoušeno. Myslím, že přinejmenším stejných čísel lze dosáhnout docela jednoduše, vzhledem k tomu, že Clickhouse má své vlastní rozhraní, ale nemohu to říci s jistotou. Je lepší testovat. Vše závisí na konfiguraci: kolik máte hostitelů a tak dále. Vkládání je jedna věc, ale také je potřeba tato data získat - Grafana nebo něco jiného.
A: – Mluvíme tedy o rovném boji a ne o velké výhodě těchto rychlých databází?
AG: – Myslím, že až se integrujeme, budou přesnější testy.
A: – Kam se poděl starý dobrý RRD? Co vás vedlo k přechodu na SQL databáze? Zpočátku byly všechny metriky shromažďovány na RRD.
AG: – Zabbix měl RRD, možná ve velmi staré verzi. Vždy existovaly databáze SQL – klasický přístup. Klasický přístup je MySQL, PostgreSQL (existují již velmi dlouho). Téměř nikdy jsme nepoužívali společné rozhraní pro databáze SQL a RRD.
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com