我正在尝试通过创建一个推特克隆来学习数据库设计。我想知道创建朋友时间轴功能的最有效方法是什么。我在Google App Engine中实现了这一点，它使用Big Table来存储数据。 IIRC，这意味着非常快的读取速度（获取），但页面查询速度相当慢，这也意味着写入速度相当慢。目前在我看来有两种方法，每种方法都有其挫折：
对于每个用户，都有一个列表结构，这是他们朋友的时间表。每当有人发推文时，这个结构都会针对每个关注者进行更新。这种方法使用了大量的写操作，但对于检索列表的每个用户来说，它看起来都非常快。
或
对于每个用户，通过获取他所关注的人的所有推文动态计算朋友的时间轴，并合并所有推文以获得朋友的时间线（因为对于每个人，推文按时间顺序排序） 。如果这个人跟随很多人，这可能会很慢。
还有其他一些我不知道的方法吗？当用户数量增加时，这两种方法似乎都会使系统窒息。
答案 0 :(得分：2)
您需要关注练习的对象，您说这是在学习数据库设计。所以不要挂断可扩展性。设计一个适合您和您的配偶使用的数据库。几乎任何你选择的设计都能够处理这种负载。除了其他任何事情之外，如果你甚至开始接近Twitter风格的点击量，那么GAE许可将开始向你收取大笔费用。
事实上，Twitter和Facebook等玩家的可扩展性是他们提议的主要部分。因此，他们花费了大量精力来构建可扩展的应用程序。他们通过大量优化来实现这一目标，包括针对不同类型数据的不同存储架构，分布式服务器和缓存，以及大量缓存。换句话说，它完成了基础设施和架构，而不是数据库设计
高可伸缩性是相关信息的非常好的来源。例如，this summary of a presentation by Twitter's Evan Weaver last year非常相关：
“[E]现在在RAM中，数据库是 备份;峰值为300推文/秒; 每条推文的平均值为126 人;向量缓存的推文ID;行 缓存;片段缓存;页面缓存; 保持单独的缓存; GC制作Ruby 优化抗性所以顺其自然 斯卡拉;使用Thrift和HTTP 内部; 100s内部请求 每个外部请求;重写了MQ但是 保持界面相同; 3个队列 用于加载余额请求; 针对向后的广泛A / B测试 能力;切换到C memcached 客户的速度;优化关键 路径;更快地获得缓存的结果 从网络内存比重新计算 他们在当地。“
嗯，“数据库只是一个备用”。可怕的东西（像我这样的数据库人）。