Kiu/VictoriaMetrics
Kiu/VictoriaMetrics
1
0
Fork 0
mirror of https://github.com/VictoriaMetrics/VictoriaMetrics.git synced 2025-01-20 15:29:24 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Updated FAQ (markdown)

Aliaksandr Valialkin 2018-10-06 22:53:01 +03:00
parent 5feda756aa
commit 517731a06f
1 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
FAQ.md

@ -2,20 +2,34 @@
A: Providing the best remote storage solution for Prometheus.
* Q: _How does VictoriaMetrics compare to other clustered TSDBs with [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/) support such as [M3 from Uber](https://eng.uber.com/m3/), [Thanos](https://github.com/improbable-eng/thanos), [Cortex](https://github.com/cortexproject/cortex), etc.?_
A: VictoriaMetrics is simpler, faster and provides [useful extensions for PromQL](ExtendedPromQL). The simplicity is twofold:
- It is simpler for our clients - just copy-n-paste [the provided URLs](Quick-Start) for [Prometheus remote_write API](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cremote_write%3E) and [Grafana datasource for Prometheus](http://docs.grafana.org/features/datasources/prometheus/) and that's it! There is no more headache about management, replication, backups, scalability and capacity planning for Prometheus local storage or third-party [sidecars](https://github.com/improbable-eng/thanos/blob/master/docs/components/sidecar.md).
- VictoriaMetrics has simpler architecture, which means less bugs and more useful features in a long run comparing to competing TSDBs.
* Q: _How does VictoriaMetrics compare to [InfluxDB](https://www.influxdata.com/time-series-platform/influxdb/)?_
A: VictoriaMetrics doesn't eat your RAM and data. Additionally it is much simpler and provides much better query language - [extended PromQL](ExtendedPromQL).
* Q: _How does VictoriaMetrics compare to [TimescaleDB](https://www.timescale.com/)?_
A: TimescaleDB insists on using SQL as a query language. While SQL is more powerful than the [extended PromQL](ExtendedPromQL), this power is rarely required during typical TSDB usage. Real-world queries usually look simpler when written in PromQL than in SQL.
* Q: _Does VictoriaMetrics use Prometheus technologies underneath like other clustered TSDBs with [PromQL](https://prometheus.io/docs/prometheus/latest/querying/basics/) support such as [M3 from Uber](https://eng.uber.com/m3/), [Thanos](https://github.com/improbable-eng/thanos), [Cortex](https://github.com/cortexproject/cortex)?_
A: No. VictoriaMetrics core is written from scratch in Go by [fasthttp](https://github.com/valyala/fasthttp) author - [valyala](https://github.com/valyala). Its' core doesn't use third-party technologies and libraries. The architecture is optimized for storing and querying large amounts of timeseries data with high cardinality. VictoriaMetrics storage uses [certain ideas from ClickHouse](https://clickhouse.yandex/docs/en/development/architecture/). Special thanks to [Alexey Milovidov](https://github.com/alexey-milovidov).
* Q: _How to report bugs and feature requests?_
A: Report bugs and feature requests [here](https://github.com/VictoriaMetrics/VictoriaMetrics/issues/new).
* Q: _Where is the source code of VictoriaMetrics?_
A: It is in a private repository. We are planning to open source VictoriaMetrics core in the future.