TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Zabbix, Time Series Data and TimescaleDB

121 点作者 RobAtticus大约 6 年前

6 条评论

boomskats大约 6 年前
Every time TimescaleDB is brought up, I feel the need to point people to their shadily worded proprietary licence[0], and pg_partman[1].<p>Do the same benchmarks against a pg_partman managed partitioned db and you&#x27;ll get the exact same performance. We do, at least - 150k or so metrics per second, 10 columns per metric.<p>Not trying to crap on the TimescaleDB guys, I&#x27;ve found a lot of their writeups extremely useful and can totally see how their commercially supported product fits. However, I like to see pg_partman at least mentioned somewhere in the article&#x2F;comments. It&#x27;s awesome and does the same job.<p>[0]<a href="https:&#x2F;&#x2F;github.com&#x2F;timescale&#x2F;timescaledb&#x2F;blob&#x2F;master&#x2F;LICENSE" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;timescale&#x2F;timescaledb&#x2F;blob&#x2F;master&#x2F;LICENSE</a><p>[1]<a href="https:&#x2F;&#x2F;github.com&#x2F;pgpartman&#x2F;pg_partman" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pgpartman&#x2F;pg_partman</a>
评论 #19851871 未加载
评论 #19851949 未加载
评论 #19851734 未加载
lima大约 6 年前
TimescaleDB confuses me. Postgres is an OLTP database and their disk storage format is uncompressed and not particularly effective.<p>By clever sharding, you can work around the performance issues somewhat but it&#x27;ll never be as efficient as an OLAP column store like ClickHouse or MemSQL:<p>- Timestamps and metric values compress very nicely using delta-of-delta encoding.<p>- Compression dramatically improves scan performance.<p>- Aligning data by columns means much faster aggregation. A typical time series query does min&#x2F;max&#x2F;avg aggregations by timestamp. You can load data straight from disk into memory, use SSE&#x2F;AVX instructions and only the small subset of data you aggregate on will have to be read from disk.<p>So what&#x27;s the use case for TimescaleDB? Complex queries that OLAP databases can&#x27;t handle? Small amounts of metrics where storage cost is irrelevant, but PostgreSQL compatibility matters?<p>Storing time series data in TimescaleDB takes at least 10x (if not more) space compared to, say, ClickHouse or the Prometheus TSDB.
评论 #19851660 未加载
评论 #19852336 未加载
评论 #19851320 未加载
评论 #19857438 未加载
评论 #19851371 未加载
评论 #19851494 未加载
linsomniac大约 6 年前
Experiences with Zabbix? I tried it back around a decade ago and wanted to like it, but didn&#x27;t find it very reliable. And now the details are escaping me. I ended up sticking with Nagios and Opsview. Around 5 years ago I switched to a templated Icinga2 config and have been pretty happy with that, but it&#x27;s pretty low level.
评论 #19852194 未加载
评论 #19850967 未加载
评论 #19850927 未加载
评论 #19852277 未加载
评论 #19851146 未加载
评论 #19850902 未加载
评论 #19852067 未加载
评论 #19851514 未加载
评论 #19851074 未加载
techntoke大约 6 年前
Zabbix is like a step up from Nagios. I don&#x27;t know how they can even stay relevant with Prometheus.
sreeramb93大约 6 年前
My experience with timescaledb is - it does not support gorilla encoding. So the storage needs for it is very high.
评论 #19852263 未加载
marknadal大约 6 年前
The biggest problem I&#x27;ve had with timescale systems is managing the SSDs&#x2F;HDDs underneath.<p>Having to resize&#x2F;grow&#x2F;stripe&#x2F;etc. them is a pain.<p>So we came up with a clever solution that batches chunks to S3:<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=x_WqBuEA7s8" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=x_WqBuEA7s8</a><p>$10&#x2F;day for 100M records (100GB data), all costs!<p>And best yet, reduced DevOps! Very practical, super simple.
评论 #19857512 未加载
评论 #19891019 未加载
评论 #19851516 未加载