4 ms·

While influx is pretty bad overall it's super simple to deploy and configure unlike timescale. It's the main reason we decided to use influx in our small team

by jimaek 6y ago

While influx is pretty bad overall it's super simple to deploy and configure unlike timescale. It's the main reason we decided to use influx in our small team with simple enough timeseries needs

avthar 6y ago
Curious what you found difficult to deploy/ configure? Is this in a self-managed context?
- samstave 6y ago
  I found this to be a funny, subtle insult. :-) "Why is it difficult, because you're self managed?"
  - avthar 6y ago
    No intention to insult - just trying to get more context :)
    - samstave 6y ago
      I know - I just read it as such and chuckled.
  - znpy 6y ago
    I think it's a honest question. Maybe they want to find out if setting up needs a bit of us work or simplifying.
- themgt 6y ago
  I was testing out both TimescaleDB/InfluxDB recently, including maybe using with Prometheus/Grafana. I was leaning towards Timescale, but InfluxDB was indeed a lot easier to quickly boot a "batteries included" setup and start working with live data. I eventually spent a while reading about Timescale 1 vs 2, and testing the pg_prometheus[1] adapter and started thinking through integrating its schema to our other needs then realizing it's "sunsetted" and then reading about the new timescale-prometheus[2] adapter and reading through its ongoing design doc[3] with updated schema that I'm less a fan of. I finally wound up mostly-settling on Timescale although I've put the Prometheus extension question on hold, just pulling in metrics data and outputting with ChartJS and some basic queries got me a lot closer to done for now. Our use case may be a little odd regardless, but I think a timescale-prometheus extension with a some ability to customize how the data is persisted would be quite useful. [1] https://github.com/timescale/pg_prometheus https://github.com/timescale/pg_prometheus [2] https://github.com/timescale/timescale-prometheus https://github.com/timescale/timescale-prometheus [3] https://docs.google.com/document/d/1e3mAN3eHUpQ2JHDvnmkmn_9rFyqyYisIgdtgd3D1MHA/edit#heading=h.hv9q074m6qpz https://docs.google.com/document/d/1e3mAN3eHUpQ2JHDvnmkmn_9r...
  - cevian 6y ago
    (TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.
    - themgt 6y ago
      Thanks, as I say our use case may be too odd to be worth supporting, but effectively we're trying to add a basic metrics (prom/ad-hoc) feature to an existing product (using Postgres) with an existing sort of opinionated "ORM"/toolkit for inserting/querying data. Because of that and the small scale required, the choice of table-per-metric would be a tough fit and I think a single table with JSONB and maybe some partial indexes is going to work a lot better for us. It would just be nice if we could somehow code in our schema mapping and use the supported extension, but I get it may be too baked-into the implementation. Anyway, overall we're quite happy with TimescaleDB!
      - cevian 6y ago
        I see, that makes a whole lot of sense. This is an interesting use-case. It actually may be possible to use some of the aggregates provided by the extension even with a different schema. If you are interested in exploring further, my username on slack is `mat` and my email is the same @timescale.com
souldeux 6y ago
What's wrong with influx? I use it and like it, albeit for hobby-level projects.
- mhall119 6y ago
  As with any technology, the right tool for the job is highly dependent on what the job is.
- chucky_z 6y ago
  Influx is so good for hobby-level projects. So good!! For serious applications, it doesn't cut it. Trying to do more than a few TB a day is a waste of time outside of enterprise, which ain't cheap. I plopped VictoriaMetrics in place of Influx for my cases and haven't even had a single hiccup.
- valyala 6y ago
  InfluxDB may have slightly big RAM requirements when working with high number of time series [1]. [1] https://medium.com/@valyala/insert-benchmarks-with-inch-influxdb-vs-victoriametrics-e31a41ae2893 https://medium.com/@valyala/insert-benchmarks-with-inch-infl...
heliodor 6y ago
For small and medium needs, InfluxDB is a delight to use. On top of that, the data exploration tool within Chronograf is one-of-a-kind when it comes to exploring your metrics. If you are looking for a vendor to host, manage, and provide attentive engineering support, check out my company: https://HostedMetrics.com https://HostedMetrics.com
valyala 6y ago
If you want the best of both worlds, then try VictoriaMetrics. It is simple to deploy and operate and it is more resource-efficient comparing to InfluxDB. More on this, it supports data ingestion over Influx line protocol [1]. [1] https://victoriametrics.github.io/#how-to-send-data-from-influxdb-compatible-agents-such-as-telegraf https://victoriametrics.github.io/#how-to-send-data-from-inf...

by jimaek 6y ago

While influx is pretty bad overall it's super simple to deploy and configure unlike timescale. It's the main reason we decided to use influx in our small team with simple enough timeseries needs

avthar 6y ago

Curious what you found difficult to deploy/ configure? Is this in a self-managed context?

samstave 6y ago
I found this to be a funny, subtle insult. :-) "Why is it difficult, because you're self managed?"
- avthar 6y ago
  No intention to insult - just trying to get more context :)
  - samstave 6y ago
    I know - I just read it as such and chuckled.
- znpy 6y ago
  I think it's a honest question. Maybe they want to find out if setting up needs a bit of us work or simplifying.
themgt 6y ago
I was testing out both TimescaleDB/InfluxDB recently, including maybe using with Prometheus/Grafana. I was leaning towards Timescale, but InfluxDB was indeed a lot easier to quickly boot a "batteries included" setup and start working with live data. I eventually spent a while reading about Timescale 1 vs 2, and testing the pg_prometheus[1] adapter and started thinking through integrating its schema to our other needs then realizing it's "sunsetted" and then reading about the new timescale-prometheus[2] adapter and reading through its ongoing design doc[3] with updated schema that I'm less a fan of. I finally wound up mostly-settling on Timescale although I've put the Prometheus extension question on hold, just pulling in metrics data and outputting with ChartJS and some basic queries got me a lot closer to done for now. Our use case may be a little odd regardless, but I think a timescale-prometheus extension with a some ability to customize how the data is persisted would be quite useful. [1] https://github.com/timescale/pg_prometheus https://github.com/timescale/pg_prometheus [2] https://github.com/timescale/timescale-prometheus https://github.com/timescale/timescale-prometheus [3] https://docs.google.com/document/d/1e3mAN3eHUpQ2JHDvnmkmn_9rFyqyYisIgdtgd3D1MHA/edit#heading=h.hv9q074m6qpz https://docs.google.com/document/d/1e3mAN3eHUpQ2JHDvnmkmn_9r...
- cevian 6y ago
  (TimescaleDB engineer) Really curious about finding out more about your reservations about the updated schema. All criticisms welcome.
  - themgt 6y ago
    Thanks, as I say our use case may be too odd to be worth supporting, but effectively we're trying to add a basic metrics (prom/ad-hoc) feature to an existing product (using Postgres) with an existing sort of opinionated "ORM"/toolkit for inserting/querying data. Because of that and the small scale required, the choice of table-per-metric would be a tough fit and I think a single table with JSONB and maybe some partial indexes is going to work a lot better for us. It would just be nice if we could somehow code in our schema mapping and use the supported extension, but I get it may be too baked-into the implementation. Anyway, overall we're quite happy with TimescaleDB!
    - cevian 6y ago
      I see, that makes a whole lot of sense. This is an interesting use-case. It actually may be possible to use some of the aggregates provided by the extension even with a different schema. If you are interested in exploring further, my username on slack is `mat` and my email is the same @timescale.com

souldeux 6y ago

What's wrong with influx? I use it and like it, albeit for hobby-level projects.

mhall119 6y ago
As with any technology, the right tool for the job is highly dependent on what the job is.
chucky_z 6y ago
Influx is so good for hobby-level projects. So good!! For serious applications, it doesn't cut it. Trying to do more than a few TB a day is a waste of time outside of enterprise, which ain't cheap. I plopped VictoriaMetrics in place of Influx for my cases and haven't even had a single hiccup.
valyala 6y ago
InfluxDB may have slightly big RAM requirements when working with high number of time series [1]. [1] https://medium.com/@valyala/insert-benchmarks-with-inch-influxdb-vs-victoriametrics-e31a41ae2893 https://medium.com/@valyala/insert-benchmarks-with-inch-infl...

heliodor 6y ago

For small and medium needs, InfluxDB is a delight to use. On top of that, the data exploration tool within Chronograf is one-of-a-kind when it comes to exploring your metrics. If you are looking for a vendor to host, manage, and provide attentive engineering support, check out my company: https://HostedMetrics.com https://HostedMetrics.com

valyala 6y ago

If you want the best of both worlds, then try VictoriaMetrics. It is simple to deploy and operate and it is more resource-efficient comparing to InfluxDB. More on this, it supports data ingestion over Influx line protocol [1]. [1] https://victoriametrics.github.io/#how-to-send-data-from-influxdb-compatible-agents-such-as-telegraf https://victoriametrics.github.io/#how-to-send-data-from-inf...