Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gauged: a time series database

github.com

Post reply on HN
Print view View original

1–5 of 5 posts

Re: gauged: a time series database

#2

Post by otterley »

Interesting storage method; I like it. Some notes:

- A MySQL backend should be very fast, but scaling it into multiple shards will have to be an exercise for the user. Perhaps CitusDB (PostgreSQL compatible) could be useful here.

- Metrics cannot be tagged. This will make it useless for any sort of rollups or breakdowns ("give me the sum of requests over my servers in the XYZ data center"; "give me the requests for each server in the XYZ data center by hostname").

The second issue in particular needs attention before it can complete with enterprise-grade metrics solutions such as Datadog.

Re: gauged: a time series database

#3

Post by chrisohara »

otterley wrote: post #2

Interesting storage method; I like it. Some notes: - A MySQL backend should be very fast, but scaling it into multiple shards will have to be an exercise for the user. Perhaps CitusDB (PostgreSQL compatible) could be useful here. - Metrics cannot be tagged. This will make it useless for any sort of rollups or breakdowns ("give me the sum of requests over my servers in the XYZ data center"; "give me the requests for e…

Tagging would be the next addition. I added the ability to search for keys by prefix quite efficiently, so provided one stored keys like "requests:server1", "requests:server2", one could easily run the following

    requests = 0
    for key in gauged.keys('requests:'):
        requests += gauged.aggregate(key, Gauged.SUM, start=-Gauged.WEEK)

Re: gauged: a time series database

#4

Post by rlpb »

I'd love to see an honest comparison against RRDtool. You mention it once in "Support for sparse data (unlike the fixed-size RRDtool)".

What are the other advantages, disadvantages and trade-offs?

Re: gauged: a time series database

#5

Post by otterley »

chrisohara wrote: post #3
otterley wrote: post #2

Interesting storage method; I like it. Some notes: - A MySQL backend should be very fast, but scaling it into multiple shards will have to be an exercise for the user. Perhaps CitusDB (PostgreSQL compatible) could be useful here. - Metrics cannot be tagged. This will make it useless for any sort of rollups or breakdowns ("give me the sum of requests over my servers in the XYZ data center"; "give me the requests for e…

Tagging would be the next addition. I added the ability to search for keys by prefix quite efficiently, so provided one stored keys like "requests:server1", "requests:server2", one could easily run the following requests = 0 for key in gauged.keys('requests:'): requests += gauged.aggregate(key, Gauged.SUM, start=-Gauged.WEEK)

Tagging needs to be multi-dimensional to be effective (e.g., host=X, device=Y, interface=Z, etc.)
Post reply on HN