I have been using TimescaleDB for quite some time and everything is going great! No problems so far even when at scale. So, should be great to use for you as well.
On Sunday, October 4, 2020 at 9:05:22 PM UTC+5:30 [email protected] wrote: > We did do alot of compare/contrasts of different solutions. The real > question is what do you "desire". Our timescale was because someone felt > that there was a need for SQL. We did make the argument that yes, SQL is > nice but there are alot of different ways to get data out. > > Timescale: yes it is row based and the storage requirements were larger > for this than "other solutions" If you are just using it to store data > then take a look at the following. It might be a better solution. > > Of the 2 that we did begin to look at were VictoriaMetrics ,Thanos, and > M3. > > > On Sunday, October 4, 2020 at 8:24:05 AM UTC-4 [email protected] wrote: > >> On Sunday, 4 October 2020 11:10:39 UTC+1, sreehari M V wrote: >>> >>> In fact I am looking for scalability and a high available monitoring >>> setup and planning to implement timescale DB for this. Currently there are >>> node, process and JMX exporters are installed in nodes and expect nodes >>> count to be increased to 500+. >>> >>> And currently prometheus storage re-tension is 30 days. Can you please >>> suggest a best solution for this. If timescale db is the best solution , >>> can you please share the implementation ideas ? Below issues are facing >>> with time scale DB. >>> >>> 1. Storage size is huge. >>> 2. Not able fetch the data from timescale DB through prometheus. >>> >>> >> I think the storage size problem is fundamental to timescale DB; it's a >> row-based storage engine, and hence will use much more storage than a >> column-based system, as well as being much slower to query for typical use >> cases. However, you *should* be able to read and write to it via >> prometheus: the postgres/timescale adapter supports both remote read and >> remote write. If you can't, then it's probably just a configuration issue. >> >> If you're looking for a more scalable solution, I'd recommend you look at >> VictoriaMetrics, because it can start as a simple single-process system, >> which may be all you need, but you can change to a horizontally-scalable >> distributed system later if you need. There are some benchmarks here (from >> author of VictoriaMetrics): >> >> https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae >> >> Thanos/Cortex are other well-known big players in this space. >> > -- You received this message because you are subscribed to the Google Groups "Prometheus Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-users/f54bbb4f-d980-44ce-adb4-49645bbf3950n%40googlegroups.com.
