我想通过创建一个twitter克隆来学习数据库设计。我想知道创建好友时间轴功能的最有效方式是什么。我正在谷歌App Engine中使用Big Table来存储数据。 IIRC，这意味着非常快的读取速度（获取），但页面查询速度相当慢，这也意味着写入速度相当慢。目前我脑海中有两种方法，每种都有其挫折：如何实现twitter的'朋友'时间轴'功能
对于每个用户，都有一个列表结构，这是他们朋友的时间表。每当有人发布推文时，该结构都会针对其每个追随者进行更新。这种方法使用了很多写操作，但是对于每个检索列表的用户来说，它看起来都非常快。
或
对于每个用户，动态地得到他下面的人所有的鸣叫时间线，并完成所有的鸣叫的合并得到朋友的计算朋友时间表（因为对于每个个人推文按时间顺序排序）。如果这个人跟随很多人，这可能会很慢。
有没有其他方法我不知道？这两种方法似乎都会在用户数量增加时使系统窒息。
您需要关注练习的对象，您说的是学习数据库设计的对象。所以不要挂在可扩展性上。设计一个适合你和你的伴侣使用的数据库。几乎你选择的任何设计都能够处理这种负载。除此之外，如果您甚至开始接触Twitter风格的点击率，GAE许可证将开始向您收取大笔费用。
问题是，Twitter和Facebook等玩家的可扩展性是他们主张的主要部分。因此，他们花费大量精力来构建自己的应用程序。他们通过大量优化来实现这一点，包括针对不同类型数据的不同存储架构，分布式服务器和缓存以及大量缓存。换句话说，它是在基础架构和架构下完成的，而不是数据库设计。
高可伸缩性是相关信息的一个很好的来源。例如，this summary of a presentation by Twitter's Evan Weaver last year是非常中肯：
“[E]在RAM verything现在，数据库是 备份; 每鸣叫之后平均126 人;在300次鸣叫/秒的峰值鸣叫的矢量缓存标识;排 缓存;片段缓存，页面缓存; 保持独立的缓存，GC，使红宝石 优化耐所以就跟着 斯卡拉;节俭和HTTP使用 内部; 100S内部请求 每个外部请求;重写了MQ但 保持接口相同; 3个队列是用于平衡请求的; 广泛的A/B测试向后 能力;切换到C memcached 客户端的速度;优化关键路径 ;更快地获得来自网络存储缓存的结果 不是在本地重新计算 他们。”
嗯，‘数据库是一个后备’而已。可怕的东西（像我这样的数据库的家伙）。