我正在尝试通过创建 twitter 克隆来学习数据库设计。我想知道创建朋友时间轴功能的最有效方法是什么。我在 Google App Engine 中实现这个，它使用 Big Table 来存储数据。 IIRC，这意味着非常快的读取速度（获取），但页面查询要慢得多，这也意味着写入速度要慢得多。目前在我看来有两种方法，每一种都有它的挫折：
对于每个用户，都有一个列表结构，即他们朋友的时间线。每当有人发布推文时，该结构就会针对其每个关注者进行更新。这种方法使用了大量的写入操作，但是对于每个用户检索列表来说，它看起来会非常快。
或
对于每个用户，通过获取他关注的人的所有推文来动态计算朋友的时间线，并将所有推文合并以获得朋友的时间线（因为对于每个人，推文都是按时间顺序排序的） .如果此人关注很多人，这可能会很慢。
还有其他一些我不知道的方法吗？这两种方法似乎都会随着用户数量的增加而使系统阻塞。
【问题讨论】：
标签： database-design optimization twitter algorithm
您需要专注于练习的对象，即您所说的学习数据库设计。所以不要纠结于可扩展性。设计一个适合您和您的伙伴使用的数据库。几乎您选择的任何设计都能够处理这种负载。除此之外，如果您甚至开始接近 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 客户追求速度；优化关键 小路;更快地获得缓存的结果 从网络内存而不是重新计算 他们在本地。”
嗯，“数据库只是备份”。可怕的东西（对于像我这样的数据库人）。
【讨论】：