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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Why Not to Build a Time-Series Database (2018)

31 点作者 aberoham将近 6 年前

4 条评论

dang将近 6 年前
<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18402890" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18402890</a>
kwillets将近 6 年前
Most OLAP has that exponential falloff in data use with time. I once extracted all the date strings from recent queries on a data warehouse and found the same distribution.<p>Zynga once built a kind of time-series database with very similar metric namespace issues: about 24M metrics&#x2F;minute reducing to about 1M unique names with heavy skew. They did almost everything wrong in implementing it; I was considering blogging about it once but let it go.<p>It turned out that the basic aggregation (they were in a hierarchy, so they needed to rollup to each level with counts and uniques) could be done in a few seconds with a string sort. But nothing could solve the problem of middle management.
rightbyte将近 6 年前
I have this great idea for dealing with their scaling problems. Send each client a binary blob and let the client execute it. The only thing your service need to do is act as a liscense server.<p>I call it &quot;edge computing&quot;.
评论 #20024749 未加载
mluggy将近 6 年前
is there a reason why you can&#x27;t have a deployment&#x2F;set of pods per client? the article keeps mentioning every solution failed when the whole dataset hit a certain limit.
评论 #20024775 未加载
评论 #20026098 未加载