What does HackerNews think of VictoriaMetrics?

Did you try VictoriaMetrics [1] and vmagent [2]? It is a single self-contained binary without external dependencies. It requires relatively low amounts of CPU, RAM, disk space and disk IO, and it runs on ARM.

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/

[2] https://docs.victoriametrics.com/vmagent.html

A related database using ideas from Clickhouse:

https://github.com/VictoriaMetrics/VictoriaMetrics

Go is my primary programming language during the last 10 year. I absolutely love Go because of the following features:

* Great code readability. I can open any project in Go and instantly start reading and understanding the code. This is because of simple syntax, which doesn't provide ability to write implicitly executed code, and `go fmt` tool, which formats everybody's code to a single code style.

* Go discourages unnecessary abstractions and encourages writing essential boring code without various "smart" tricks. The end result is much shorter code base, which is easy to read and refactor.

* Fast compile times. For instance, my latest project - VictoriaMetrics [1] - contains almost 600K lines of Go code excluding "_test.go" files. Go builds the final `victoria-metrics` executable in less than a second during development. This means that I can quickly iterate on code modifications and testing without the need to wait for minutes and hours for build process to finish (hello, Rust and C++ :) ).

* Single statically linked output binary with relatively small size. For example, VictoriaMetrics is built into 19MB statically linked binary with Go 1.15.4. And this binary contains all the debug symbols. Binary size shrinks to 12MB when stripping debug symbols. Such a binary can run on any host without the need to manage external dependencies - just upload the binary and run it.

* Ability to build executable for any supported target platform by specifying GOOS and GOARCH environment variables. For example, I can build binary for FreeBSD on ARM from my x86 laptop running Ubuntu.

* Great and easy-to-use tooling for race detection and CPU/memory/locks profiling. There tools significantly simplify code optimization and allow to catch data races at much lower mental cost comparing to race-free Rust :)

P.S. I hope Go will never adopt generics. I didn't need generics during the last 10 years of active development in Go [2]. Before Go I was working with C++ and was experiencing constant pain with reading and debugging C++ templates in stl and boost libraries. I don't want to experience the same feelings with Go.

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/

[2] https://github.com/valyala/

I'm curios whether all the metrics mentioned here are exported by postgres_exporter [1]? Nowadays Prometheus becomes de-facto standard for monitoring, so it would be great if postgres_exporter could provide all these metrics to Prometheus. Moreover, there are other monitoring solutions such as VictoriaMetrics [2] or vmagent [3], which can scrape metrics from Prometheus-compatible exporters.

[1] https://github.com/wrouesnel/postgres_exporter

[2] https://github.com/VictoriaMetrics/VictoriaMetrics/

[3] https://victoriametrics.github.io/vmagent.html

There are other time series databases worth comparison with TimescaleDB:

* InfluxDB - https://www.influxdata.com/

* VictoriaMetrics - https://github.com/VictoriaMetrics/VictoriaMetrics/

* M3DB - https://github.com/m3db/m3/

Take a look at ClickHouse [1] and VictoriaMetrics [2]. Both solutions share architecture details and are optimized for high performance and low resource usage. They can handle trillons of rows (i.e. more than 10^12 rows) on a single node and can scale to multiple nodes.

[1] https://clickhouse.tech/

[2] https://github.com/VictoriaMetrics/VictoriaMetrics

This is great news! We at VictoriaMetrics [1] are happy that TimescaleDB eventually addressed high disk usage issue and implemented type-aware column-based compression. This should improve its' position and performance in TSBS benchmark [2].

One question: why do you use Gorilla compression for floating-point values? It works well for integer values, but is pretty useless for floating-point values [3].

[1] https://github.com/VictoriaMetrics/VictoriaMetrics

[2] https://medium.com/@valyala/measuring-vertical-scalability-f...

[3] https://medium.com/faun/victoriametrics-achieving-better-com...

While logs and metrics have common parts, they are quite different beasts. It is quite expensive producing and storing logs for frequently changing metrics such as requests rate or response latency on highly loaded system with millions of rps.

I'd recommend:

- Storing logs in high-performance systems such as cLoki [1], which give enough flexibility to generate arbitrary metrics from high log volumes in real time.

- Storing metrics in high-performance time series database optimized for high volumes of data points (trillions) and high number of time series (aka high cardinality). An example of such a TSDB is VictoriaMetrics [2].

Implementing dashboards with time-based correlation between metrics and logs based on shared attributes (labels) such as datacenter, cluster, instance, job, subsystem, etc [3].

[1] https://github.com/lmangani/cLoki

[2] https://github.com/VictoriaMetrics/VictoriaMetrics/

[3] https://grafana.com/blog/2019/05/06/how-loki-correlates-metr...

Go is awesome programming language, since it is simple, readable and provides good tooling - code verification (vet), code formatting, testing, benchmarking, tracing, race detector, profiling - out of the box.

Go encourages writing simple straightforward code without complex abstractions. This improves programmers' productivity, which allows writing raw practical code instead of spending time on theoretical design patterns, inheritance hierarchy, generics, fancy algorithms, monads, "zero-cost" abstractions (with high mental cost), borrow checking, etc.

That's why we could write fast time series database in Go from scratch in less than a year - https://github.com/VictoriaMetrics/VictoriaMetrics/ .