4 ms·

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