Hacker News Reader

Comment by RobAtticus | Hacker News Reader

Earlier discussion about our launch (covering some of the points here): https://news.ycombinator.com/item?id=14035416

Around if there are any questions.

This may be a question as much to other prometheus users as you, sorry. :) I'm using Prometheus to record both "metric" data (temperature of CPUs, etc.) as well as "event" data (program produced result x). It's seemed awesome for metrics and poor for events. (a) Is there a way to coerce Prometheus into doing what I want? (b) Is this something fundamentally easier or harder in TimescaleDB, and why? aka - should I consider switching even though you're beta-ish, and is it a compelling reason, or just something I'm doing wrong?

(Yeah, I know, I'm asking the Internet to do my job for me... thank you, Internet!)

I personally haven't used Prometheus much, so I'm not sure I can effectively answer (a). I don't see why this would be difficult in TimescaleDB though. If it's timestamped, it should work nicely with our hypertable abstraction and is as easy as a SQL INSERT.

Maybe others can chime in on the first part of your question though.

So, if I have an event like "program observed a car at 2017-04-20 15:15:15.9939311", and I want to calculate summary statistics over time for that -- select count(*) where car_time % 86400 == foo". That's the one kind of query I've been finding problematic in Prometheus.

(Edited to add: This was answered by another reply -- Prometheus has to do a full table scan for things like this.)

Hey,

Not sure if this is part of the question but if you are querying the event data by something other than time (like a property of the event itself -- maybe the program return code in your example) than prometheus requires a full table scan since it does not have secondary indexes. With TimescaleDB you could add indexes on properties of the event data itself.

Ahh, I think this answers my question. Painful - thank you!

Reply on news.ycombinator.com