评论后可扩展性:每个用户前n个,1个更新,重读

时间:2009-07-13 21:06:08

标签: database scalability message-queue

这是情况。数百万用户网站。每个用户的页面都有一个消息部分。任何人都可以访问用户的页面,在那里他们可以留言或查看最近100条消息。

消息是带有一些额外元数据的txt的短片段。每条消息都必须永久存储,唯一必须实时快速的是消息更新和阅读(人们将其用作聊天)。将经常读取消息计数以检查更改。定期地,可以存档旧消息(那些> 100),但它们必须是可访问的。

目前所有人都在一个大型数据库表中,阅读邮件列表和发送更多更新的人之间的争用正成为一个问题。

如果您必须重新构建系统,您将使用哪种存储机制/缓存?这里可以使用什么样的计算机科学学习? (例如收藏,列表访问等)

2 个答案:

答案 0 :(得分:0)

一个简单的解决方案可能是对数据进行非规范化,并将预先计算的聚合存储在单独的表中,例如:一个MESSAGE_COUNTS表,其中包含用户ID列和消息计数列。更新主消息表后,重新计算聚合。

它只是将瓶颈从一个地方转移到另一个地方,但它可能会把它移到一个不那么负担的地方。

答案 1 :(得分:0)

一些一般性的想法,不是特定于任何特定技术:

  1. 按用户ID对数据进行分区。我们的想法是,您可以将用户空间统一划分为大致相同大小的不同分区。您可以使用适当的散列函数在分区之间划分用户。最终,每个分区都属于一台单独的机器。但是,即使在同一台机器上的不同表/数据库上,这也会消除一些争用。分区限制了争用,并为将来“线性”扩展打开了大门。这也有助于负载分配和横向扩展。

  2. 选择哈希函数来对记录进行分区时,请查找最小化在添加/删除分区时必须移动的记录数的记录。

  3. 与许多其他应用程序一样,我们可以假设服务的使用遵循幂律曲线:很少的用户页面导致大量流量,其次是长尾。缓存方案可以利用这一点。曲线越陡峭,缓存就越有效。鉴于短消息,如果每个页面显示100条消息,并且每条消息平均为100字节,则可以在1GB RAM缓存中容纳大约100,000个顶级页面。那些缓存的页面可以懒惰地写入数据库。在10个Mil用户中,有100,000个用户可以做出改变。

  4. 对Web服务器进行分区,可能使用相同的散列方案。这使您可以保持单独的RAM缓存而不会发生争用。随着用户数量的增长,潜在的好处是增加缓存大小。

  5. 如果适合您的环境,确保新消息最终写入数据库的一种方法是将它们放入RAM缓存后立即置于持久性消息队列中。队列不会受到争用,并有助于确保在机器故障时不会丢失消息。