The answer to your question was deleted, so I'll post it again:
Vertically on a single machine, the two are quite similar, both fan work out across all CPU cores.
The different is on scaling out.
ClickHouse scales by making you describe the cluster yourself. You decide how many shards to split the data into, how many copies (replicas) each shard keeps, which row goes to which shard.
The copies are kept in sync by a consensus system ClickHouse Keeper. This is flexible but also more works on operators.
VictoriaLogs takes the opposite bet. When logs come in, the inserter just spreads them across all storage nodes on its own, so there is no sharding key for you to design.
When a query runs, the selector asks every storage node in parallel and merges the results. There is no consensus system at all. If you want high availability, you run 2 independent clusters and send your logs to both, rather than having the database copy data internally. So this is simpler and less learning curve.
See more here https://victoriametrics.com/blog/victorialogs-architecture-b...
I read somewhere that the owners have ties to russia, but the most important thing is that they’re marketing very aggressively through posts that slander GraphenOS.
Meh, I don't get it—what's stopping you from running the same benchmark on a Kubernetes cluster and sharing your own benchmark results, instead of just claiming that this benchmark is crap?
This article discusses why TiDB, a distributed SQL database, migrated its observability platform from Prometheus to VictoriaMetrics.
The Problem with Prometheus
At scale, Prometheus started showing limitations, especially for large enterprise customers like Pinterest.The main issues were:
- High resource consumption: Prometheus used a lot of CPU and memory, leading to frequent out-of-memory (OOM) crashes.
- Long recovery times: After a crash, Prometheus needed a long time to recover, sometimes failing altogether.
- Limited query performance: Large queries would often fail or be very slow.
The Solution: VictoriaMetrics
TiDB switched to VictoriaMetrics and saw significant improvements:
- Better resource utilization: CPU and memory usage dropped significantly, eliminating OOM crashes.
- Improved query performance: Large queries that previously failed in Prometheus now run efficiently in VictoriaMetrics.
- Lower costs: Reduced resource consumption and better storage efficiency led to lower operational costs.
What is the reason to choose gohttpd? I mean there are a lot of non standard libraries for go that are pretty fast or faster then gohttpd - https://github.com/valyala/fasthttp/ as example
Vertically on a single machine, the two are quite similar, both fan work out across all CPU cores. The different is on scaling out.
ClickHouse scales by making you describe the cluster yourself. You decide how many shards to split the data into, how many copies (replicas) each shard keeps, which row goes to which shard. The copies are kept in sync by a consensus system ClickHouse Keeper. This is flexible but also more works on operators.
VictoriaLogs takes the opposite bet. When logs come in, the inserter just spreads them across all storage nodes on its own, so there is no sharding key for you to design. When a query runs, the selector asks every storage node in parallel and merges the results. There is no consensus system at all. If you want high availability, you run 2 independent clusters and send your logs to both, rather than having the database copy data internally. So this is simpler and less learning curve. See more here https://victoriametrics.com/blog/victorialogs-architecture-b...