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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don’t Scale

26 点作者 DivineTraube将近 8 年前

2 条评论

dkarapetyan将近 8 年前
If the problem you are solving doesn&#x27;t map to being embarrassingly parallel then you will indeed have problems. This is not restricted to just &quot;real-time&quot;, or more technically streaming DBs. Coordination has high overhead no matter what DB you are using.<p>Also, I don&#x27;t see how their design avoids hot keyspace issues. Traditionally this is the main problem with partitioned designs because you move the problem one level up to properly designing the key that will be used to distribute the load across partitions.
voidmain将近 8 年前
This approach is &quot;scalable&quot; in the sense of partitionable, but it&#x27;s still O(N^2)! Needing 9x the servers for 3x the users is not really &quot;scalable&quot; in the colloquial sense.<p>An often more attractive approach is to partition over the keys of each database index.