You're a fucking low life beyond. No wonder you can't find a women.
Sent: Thursday, March 12, 2020 at 8:26 AM
From: "Guillem Jover" <gjo...@sipwise.com>
To: sub...@bugs.debian.org
Subject: Bug#953666: RFP: victoria-metrics -- fast, cost-effective and scalable time series database
From: "Guillem Jover" <gjo...@sipwise.com>
To: sub...@bugs.debian.org
Subject: Bug#953666: RFP: victoria-metrics -- fast, cost-effective and scalable time series database
Package: wnpp
Severity: wishlist
Tags: patch
* Package name : victoria-metrics
Version : 1.34.2
Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/VictoriaMetrics
* License : Apache-2.0
Programming Lang: Go
Description : fast, cost-effective and scalable time series database
VictoriaMetrics is a fast, cost-effective and scalable time-series database.
It can be used as long-term remote storage for Prometheus.
.
Prominent features:
* Supports Prometheus querying API, so it can be used as Prometheus
drop-in replacement in Grafana. VictoriaMetrics implements MetricsQL
query language, which is inspired by PromQL.
* Supports global query view. Multiple Prometheus instances may write
data into VictoriaMetrics. Later this data may be used in a single query.
* High performance and good scalability for both inserts and selects.
Outperforms InfluxDB and TimescaleDB by up to 20x.
* Uses 10x less RAM than InfluxDB when working with millions of unique time
series (aka high cardinality).
* Optimized for time series with high churn rate. Think about
prometheus-operator metrics from frequent deployments in Kubernetes.
* High data compression, so up to 70x more data points may be crammed into
limited storage comparing to TimescaleDB.
* Optimized for storage with high-latency IO and low IOPS (HDD and network
storage in AWS, Google Cloud, Microsoft Azure, etc).
* A single-node VictoriaMetrics may substitute moderately sized clusters
built with competing solutions such as Thanos, M3DB, Cortex, InfluxDB or
TimescaleDB.
* Easy operation:
- VictoriaMetrics consists of a single small executable without external
dependencies.
- All the configuration is done via explicit command-line flags with
reasonable defaults.
- All the data is stored in a single directory pointed by
-storageDataPath flag.
- Easy and fast backups from instant snapshots to S3 or GCS with
vmbackup / vmrestore.
* Storage is protectedfrom corruption on unclean shutdown (i.e. OOM,
hardware reset or kill -9) thanks to the storage architecture.
* Supports metrics' scraping, ingestion and backfilling (#backfilling)
via the following protocols:
- Metrics from Prometheus exporters such as node_exporter.
- Prometheus remote write API
- InfluxDB line protocol
- Graphite plaintext protocol with tags if -graphiteListenAddr is set.
- OpenTSDB put message if -opentsdbListenAddr is set.
- HTTP OpenTSDB /api/put requests if -opentsdbHTTPListenAddr is set.
- /api/v1/import.
* Ideally works with big amounts of time series data from Kubernetes, IoT
sensors, connected cars, industrial telemetry, financial data and
various Enterprise workloads.
* Has open source cluster version.
Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.
Thanks,
Guillem
Severity: wishlist
Tags: patch
* Package name : victoria-metrics
Version : 1.34.2
Upstream Author : VictoriaMetrics
* URL : https://github.com/VictoriaMetrics/VictoriaMetrics
* License : Apache-2.0
Programming Lang: Go
Description : fast, cost-effective and scalable time series database
VictoriaMetrics is a fast, cost-effective and scalable time-series database.
It can be used as long-term remote storage for Prometheus.
.
Prominent features:
* Supports Prometheus querying API, so it can be used as Prometheus
drop-in replacement in Grafana. VictoriaMetrics implements MetricsQL
query language, which is inspired by PromQL.
* Supports global query view. Multiple Prometheus instances may write
data into VictoriaMetrics. Later this data may be used in a single query.
* High performance and good scalability for both inserts and selects.
Outperforms InfluxDB and TimescaleDB by up to 20x.
* Uses 10x less RAM than InfluxDB when working with millions of unique time
series (aka high cardinality).
* Optimized for time series with high churn rate. Think about
prometheus-operator metrics from frequent deployments in Kubernetes.
* High data compression, so up to 70x more data points may be crammed into
limited storage comparing to TimescaleDB.
* Optimized for storage with high-latency IO and low IOPS (HDD and network
storage in AWS, Google Cloud, Microsoft Azure, etc).
* A single-node VictoriaMetrics may substitute moderately sized clusters
built with competing solutions such as Thanos, M3DB, Cortex, InfluxDB or
TimescaleDB.
* Easy operation:
- VictoriaMetrics consists of a single small executable without external
dependencies.
- All the configuration is done via explicit command-line flags with
reasonable defaults.
- All the data is stored in a single directory pointed by
-storageDataPath flag.
- Easy and fast backups from instant snapshots to S3 or GCS with
vmbackup / vmrestore.
* Storage is protectedfrom corruption on unclean shutdown (i.e. OOM,
hardware reset or kill -9) thanks to the storage architecture.
* Supports metrics' scraping, ingestion and backfilling (#backfilling)
via the following protocols:
- Metrics from Prometheus exporters such as node_exporter.
- Prometheus remote write API
- InfluxDB line protocol
- Graphite plaintext protocol with tags if -graphiteListenAddr is set.
- OpenTSDB put message if -opentsdbListenAddr is set.
- HTTP OpenTSDB /api/put requests if -opentsdbHTTPListenAddr is set.
- /api/v1/import.
* Ideally works with big amounts of time series data from Kubernetes, IoT
sensors, connected cars, industrial telemetry, financial data and
various Enterprise workloads.
* Has open source cluster version.
Attached a tested and working packaging, where only the Uploaders, and
ITP bug need to be filled, and the packaging imported into git.
Thanks,
Guillem
