InfluxDB v produkci (nebo jiná time-series DB)

Ahoj, je tady někdo, kdo nasadil InfluxDB do produkce?Pro nový projekt hledám vhodnou databázi na ukládání hodnoty (integer) v čase, tak jsem se logicky poohlížel po time-series databázi a celkem se mi líbí InfluxDB.Mé plánované využití je zápis cca 7000 záznamů/s, čtení pak v jednotkách queries/s. Líbí se mi snadné využití clusteru (zvažuji 3 lokality) a continuous queries. Čtení z Influx není nyní optimální, ale četl jsem, že se plánuje možnost volby storage a RocksDB vypadá jako perfektní kompromis čtení/zápisu.Zajímalo by mě, jestli ji někdo má nasazenou v produkci, případně s čím se potýkal? Klidně si nechám doporučit i alternativu...Díky

v produkci zatím ne a rozhodně nedoporučuji. Testujeme již asi půl roku na devu, ale žádná sláva to není.Hlavní nevýhody:- složitý a chybový upgrade mezi verzemi- poměrně dost bugů- občas to chytne CPU na 100 % a je nutný restart se ztrátou dat- špatně funguje failover- komprimaci nasadili až v poslední verzi a ještě očekávám pár oprav- lehce zlobí TCP stack s GC, pár vteřinové záseky při ukládání nejsou dobréNaše nasazení je teda větší, testujeme na 3-clusteru, 500M/s, 30GB disk. Každopádně sleduji, klidně si za pár měsíců napiš o nové zkušenosti nebo pokud chceš další podrobnosti.O kolik metrik se jedná? Pokud to jsou jednotky, není špatné to nechávat na disku v rrd. Nejjednodušší řešení je pak ELK (elasticsearch jako databáze, logstash pro ukládání , kibana pro vizualizaci). Dá se použít i mongo, ale tam budou query velice dlouho a je nutné si je ručně agregovat. Doporučil bych i další věci, ale vše je spíše pro pokročilé a může lehce přijít o data.Chceš-li mít live data (dashboard, monitoring, alerting), klidně si to bokem agreguj do redis, kde budeš data i analyzovat, tam stačí data retention klidně jeden den. Pokud potřebuješ vidět grafy, agregovat a další volovinu, bez chytré cache se nevyhneš. Teď jsem četl třeba hezkej článek http://developers.socialbakers.com/2016/02/01/usage-and-performance-monitoring-with-graphite/Obecné rady na ukládání metrik:- nic nechceš mít ukládáné na věčnost, už dopředu přemýšlej jak dlouho chceš mít data a správně nastav indexy, data-retention (ttl), klidně třeba na rok. Nebo to rozgranuluj, raw data měsíc, minutové půl roku, denní na věčnost- databáze na metriky musí být vždy na samostatném stroji, předejdeš tím hooodně moc problémům a vyhneš se ztrátě dat- komunikace na UDP má dlouhodobě ztrátovost klidně 5 %, pro statistiky to nevadí, průtoknost dat je o řád vyšší než TCP- mysli na to, že občas bude zlobit síť (ať už velká fronta, moc požadavků, výpadky spojení), na každém serveru, který loguje by měl posílání zajišťovat lokální daemon s vlastní in-memory cache pro podobné výpadky (logstash např.)- posílání dat do databáze bulkuj třeba po s, 10s (logstash to tak dělá), tím řádově posuneš výkonnost celého řešení a snížíš režii- dobře si rozmysli dopředu kolik budeš mít metrik a jak budou vydat. Vhodné je všechny názvy psát pouze s použitím , rozhodně nevymýšlej žádné speciálnosti. Řada technologií toho moc nepodporuje a v budoucnu si můžeš zkomplikovat nějaký upgrade- pravidelně databáze upgraduj, upgrade mezi malými verzemi často jde bez problémů a jsou k němu návody, upgrade po roce je porod a pak ti to zůstane v legacy verze věčněKlidně napiš, budeš-li potřebovat ještě nějaké informace, daty se živím.

Super, díky moc za vyčerpávající info i odkaz, ještě to prostuduji. Na ES jsem taky myslel a stejně tak jak má L+K, má zase influx Telegraf, Chronograf a Kapacitor.Docela mě zamrzel chybový upgrade, to jsem samozřejmě nemohl otestovat, koukám na to pár dní. Já zatím o produkci neuvažuji, ptal jsem se spíše kdo to řádně otestoval a trošku jsem spoléhal na nějaké pozitivní info s tím, že alší verze s možnou volbou storage to povýší na dokonalost :-)))No škoda.. Asi to zatím nechám běžet, ale hodím vedle ještě Elastic a pak to nějak vyhodnotím najednou. Live data rozhodně chci, ostatně kvůli tomu to dělám, akorát to teď nebyla priorita, chtěl jsem cvičně zatím ukládat a nad nějakým smysluplným výstupem dumat později. Redis používám nyní, ale jelikož mi jde prakticky jen o min/max/median v časové ose, přšel mi na to tento typ DB vhodnější.Data ukládám poměrně svižně hlavně kvůli průběhu, ale metrik je pár a z těch dat se pak počítá výstup pro minutu/hodinu/den, to je bokem, "stará" data můžu zahazovat. Celkem se mi právě líbilo zneužít k tomu continuous queries, takže si vyzobávat co potřebuji pravidelně. Jinak app jsou malé NodeJS workery na různých serverech (je to privátní vnitřní síť), takže nějaký logstash na každém asi být nemůže. Nicméně to zvládnu ošetřit nějak v nodu a případně rozumnou část dat "pozdržet" při nedostupnosti DB, ale nejsou nijak kritická. Šlo mi teď fakt jen o to ukládání na centrálním serveru.Díky za rady, ještě to promyslím a kdyžtak se ozvu ;)

Ano, ekosystém kolem influxdb vypadá pěkně, mysli na to, že to je venku jeden měsíc a vše v proof of concept stavu. Počítej ještě tak rok než to bude produkčně nasaditelné. upgrade je bolestný, přechod na poslední minor verzi u 30GB databáze trval 12 hodin, celou tu dobu nebyl schopný cluster nic logovat, nemluvě o několika OOM.continuous queries jsou mocné, ale bohužel potřebuji mít k dispozici primární data. Reálná situace je takové, že primární data sampluješ po 5s, přes continuous queries agreguješ na 30s, 1m, 15m ... 1d atd., primární data chceš zachovat třeba měsíc, zatímco agregovaná různě. V podání influxdb musíš sám načíst přes query agregovaná a znovu je zpátky uložit do jiné db. Stejně tak zatím není dobře vyřešený data retention, při velkém množství klíčů zamrzává celý proces a je to nestabilní, mazání přes range query je přijatelnější.V případě posílání dat rovnou z nodu je nutné používat pouze udp protokol, jinak budou vznikat divné bugy při hodně vytížených workerech (node si tcp režije řeší sám). Nemusíš mít přímo logstash, existuje řada podobných kompatibilních řešení, ať už mnou používaný collectd nebo logstash přepsaný do nodu či jiné lehčí varianty. Jde ale o to, jak máš postavenou infrastrukturu, pokud ti na jednom stroji běží jedna node.js aplikace, posílej si to přímo, pokud ale na jednom stroji ti běží desítky aplikací, lokální kolektor je jediné správné řešení nebo si budeš dosovat vlastní databázi a ani nemusí zvládat tvých potřebných 7000/s.Pokud potřebuješ HA řešení, klasicky máš v clusteru třeba 3 elasticy (minimální počet pro HA) a před nimi load balancer třeba s round robinem, který zajistí, že pokud bude jeden z elasticů offline, data dorazí na další a o nic nepříjdeš, v opačném případě bys musel tuhle logiku složitě řešit v každém workeru, což není dobré. A ano, tímhle vytvoříš úzké hrdlo v podobě load balanceru, ten jde ale také clusterovat nebo holt s jeho jedinečností budeš morálně počítat.Pokud ale chceš testovat influxdb, není nic jednoduššího než si data z elasticu ještě přeposílat na influxdb a tam si s tím hrát bez rizika ztráty, výpadku nebo ad-hoc problémů.

Ano, udělám to tak. Jinak co se týče continuous queries, tak jsem to právě chtěl a jelikož agregovaná data nepotřebuji hned, tak naopak ukládání do jiné databáze beru jako výhodu. Ona ta NodeJS appka je vlastně už sama kolektorem, protože sbírá data z cca 20-40 sond a posílá je na ten cílový server.Jelikož mi vše běží v 1 serverovně i když na rozdílných strojích, asi pro mne nemá smysl ta data někde cestou sbírat do jednoho místa a rád bych je cpal do DB rovnou, protože onen další kolektor by stejně mohl být až na tom cílovém stroji. Vše ostatní se dělá post-process, primární je mít data uložená :-)Díky :)---------- Příspěvek doplněn 04.02.2016 v 20:00 ----------Tak je venku 0.10 a řekl bych, že je za tím kus práce :-))) Video má sice půl hodinky, ale hezky srovnává 0.8, 0.9 a 0.10. https://vimeo.com/153802549

ano ;), jako firma patříme mezi přispěvovatele a máme jeden z větších clusterů, takže jim hodně věcí testujeme rovnou za tepla :).K těm continuoues queries, nejde o to, že bys z nich dat nemohl používat hned, ale že pokud smaže ty primární, smažou se i z nich. Prakticky nikdy nemáš prostor pro ukládání raw dat a musíš agregovat s různou data retention.Přečti si ten článek, jak jsem odkazoval, tam je zmíněno právě proč se používá jeden kolektor. Sleduj velikost paketů, které ti tečou do db. Pokud budeš posílat v paketu 100 bitů dat, je to mrhání, když za stejné náklady na cpu můžeš poslat desetkrát tolik. Další výhoda je, že lokální kolektor bude přebírat data na UDP od všech appek, ale do db je už bude posílat přes TCP a dojde k menší ztrátě.Node.js má nevýhodu, že pokud dělá synchronní operaci nebo je přetížený, všechna tcp/udp spojení běží ve stejném threadu a nic nepošleš, proto je cíl, aby se data odesílala jednorázově a levně, udp je jasná volba. Čím rychleji budeš data odesílat, tím méně jich stihneš nasbírat a tím menší bude velikost paketu. To ti začne vadit při růstu a zvedání počtu sond.Firemně do toho logujeme všechno co se šustne na našich serverech a těch je opravdu hodně. Soukromě ale pracuji právě na řešení sběru data z malých senzorů, sond, asi něco podobného jako ty. První verze mi běžela na rasberry v node.js, současná mi běží na fpga v c/rust/erlang. U node.js jsem narážel na situaci, kdy jsem chtěl data sbírat po 10ms a nahodit novou verzi sběrače bez výpadku. Node.js appka odebírala data z kernelu a ukládala do sdílené paměti (konkrétně http://whitedb.org), jiná node.js zase kontrolovala data sdílené paměti a odesílala pryč. Pokud jsem restartoval appku na tcp, kernel pár vteřin udržel data ve své cache, pokud jsem restartoval appku na odesílání, jen se plnila fronta. K tomu mi tam běžel checker na velikost těhle front a v případě problémů notifikoval. Jsem ochoten kód zopensourcovat, pokud bys měl zájem.