3 ms·

For comparison librrd is a 0.4MB .so; the entire rrdtool userspace is about 1MB. Yes, I realize librrd is much simpler and less featureful than Prometheus. But

For comparison librrd is a 0.4MB .so; the entire rrdtool userspace is about 1MB. Yes, I realize librrd is much simpler and less featureful than Prometheus. But it's an interesting comparable for what a small, old utility that does something similar could be.

wejick 5y ago
I just knew about this, good stuff. Many projects I used are using this one.
petre 5y ago
Yet RRD databases are awfully big but often compress to single digit percentages. We use them to store one time graph data, so they do not ever get updated after the report job finishes. I'm looking for an alternative and it better not be a huge json array of arrays plus a header dictionary. It also should be an on disk something, not Influx or Prometheus.
- simonmales 5y ago
  I only know RRD from Munin graphs, and now have a toy idea to used it directly to render a SVG. If disk space is an issue, do you or have you considered decompressing on the fly ?
  - chrismorgan 5y ago
    Or use a file system that supports transparent compression (e.g. btrfs).
- SuperQue 5y ago
  You can use the Prometheus TSDB package, it's easy to import and use. Plus it's designed around mmap, so the kernel deals with the caching. You don't have to use a whole Prometheus server to make something like this work.
SuperQue 5y ago
Yup, it's tiny and simple. But the goals are wildly different. The same Prometheus binary you can run on a Pi scales to millions of series and millions of samples per second. The Prometheus TSDB itself is only one part of a the larger system. But, compared to librrd, it's vastly more functional. Besides the scaling I mentioned * It's ACID compliant. * It has WAL for reliability. * It has CPU and memory efficient compression. * It has an efficient mmap-based data loader. RRDtool, while efficient from a '90s perspective, is a toy by comparison. And yes, I've used rrdtool. Back in old-school days when Cacti was the new hot shit compared to MRTG.

wejick 5y ago

I just knew about this, good stuff. Many projects I used are using this one.

petre 5y ago

Yet RRD databases are awfully big but often compress to single digit percentages. We use them to store one time graph data, so they do not ever get updated after the report job finishes. I'm looking for an alternative and it better not be a huge json array of arrays plus a header dictionary. It also should be an on disk something, not Influx or Prometheus.

simonmales 5y ago
I only know RRD from Munin graphs, and now have a toy idea to used it directly to render a SVG. If disk space is an issue, do you or have you considered decompressing on the fly ?
- chrismorgan 5y ago
  Or use a file system that supports transparent compression (e.g. btrfs).
SuperQue 5y ago
You can use the Prometheus TSDB package, it's easy to import and use. Plus it's designed around mmap, so the kernel deals with the caching. You don't have to use a whole Prometheus server to make something like this work.

SuperQue 5y ago

Yup, it's tiny and simple. But the goals are wildly different. The same Prometheus binary you can run on a Pi scales to millions of series and millions of samples per second. The Prometheus TSDB itself is only one part of a the larger system. But, compared to librrd, it's vastly more functional. Besides the scaling I mentioned * It's ACID compliant. * It has WAL for reliability. * It has CPU and memory efficient compression. * It has an efficient mmap-based data loader. RRDtool, while efficient from a '90s perspective, is a toy by comparison. And yes, I've used rrdtool. Back in old-school days when Cacti was the new hot shit compared to MRTG.