提要算法+数据库：不是行太多就是检索太慢

Question

null

我这样做的方法是创建太多的行，而且看起来不是可伸缩的。例如，如果一个页面创建了一个post&有1,000,000个followers，那么我们就在feedpost表中创建了1,000,000个新行。

请救命！像facebook这样的公司是如何处理这个问题的呢？他们会根据请求生成提要吗？我的数据库关系很糟糕吗？

Answer 1

这并不是说原始模式本身会有本质上的错误，至少不是基于您提供的高级描述。缓慢的原因是您没有以应该访问关系数据库的方式访问数据库。

一般情况下，在查询关系数据库时，应该在可能的情况下使用联接和数据库内排序，而不是获取一堆数据，然后在代码中尝试连接相关对象并对其进行排序。如果让数据库为您做这一切，它会快得多，因为它可以利用索引，并且只访问那些实际需要的对象。

根据经验，如果您需要对Python代码中的queryset的结果进行排序，或者循环访问多个查询集并以某种方式组合它们，那么您很可能做错了什么，您应该弄清楚如何让数据库为您做这件事。当然，这不是每一次都是真的，但肯定是经常的。

让我试着用一段简单的代码来说明。假设您有以下模型：

class Page(models.Model):
    name = models.CharField(max_length=47)
    followers = models.ManyToManyField('auth.User', related_name='followed_pages')

class Post(models.Model):
    title = models.CharField(max_length=147)
    page = models.ForeignKey(Page, related_name='posts')
    content = models.TextField()
    time_published = models.DateTimeField(auto_now_add=True)

例如，您可以通过以下单行代码获得当前登录用户发布到页面的最近20篇文章的列表：

latest_posts = Post.objects.filter(page__followers=request.user).order_by('-time_published')[:20]

这将对数据库运行一个SQL查询，它只返回（最多）20个匹配的结果，而不返回其他结果。而且由于连接的是所有相关表的主键，它将方便地为所有连接使用索引，从而使其非常快速。事实上，这正是关系数据库被设计用来高效执行的操作。