Disqus 评论设计

osdba

转自：开源中国社区
英文原文：Scaling Threaded Comments on Django at Disqus
参与翻译(2人)：nightknight, postdep

众所周知，我上个月加入了Disqus公司。对我来说，这是一个很大（真的很大）的改变。他们那里有许多吸引人的问题，另外还有许多愿意一起解决他们的人。

我一直是MySQL的提倡者：不仅仅是因为他是最好的关系数据库，也是因为他的可行性，而且工作的很好。然而，跳到Disqus后，我需要做一个很大的改变，因为他们使用PostgreSQL.不仅如此，他们的数据库中的数据是我上个公司的三倍还多（这还仅仅是纯数据）。

因此，在这儿工作了一个月后，我学到了许多关于PGSQL方面比较好玩的地方。接下来让我们好好地讨论一下这几个地方吧。

首先，在规模上，它更大一点。在很长一段时间内，PostgreSQL都被认为是MySQL的替代品。但是，在那段时间里，根本没有办法使他达到MySQL所能达到的水平。最近几年里，这些问题都无法解决，并且产生了许多有趣的工具来弥补PG。我们在Disqus中使用了两个Slony和pgbouncer。Slony让我们可以复制数据（有时候也可以分区），而pgbouncer为我们解决了保持链接和连接池的问题。

另外，让我们看看他们的语言：我这个星期很高兴能够学会如何在PGSQL8.4中使用递归查询，他们实在太强大了。这就是我这篇文章所真正想要和大家讨论的东西。MySQL让我们可以工作，并且工作的很好，但你只能在引擎的结构内完成。虽然在PG中依然如此，但你有了更多的选择。因此，我想讲讲树的线索化的问题。

大家都知道Disqus不仅仅是最大的Django网站（我们每个月有近100万的访问量），同时，他也是他也是一个最大的网上评论系统。我们为上千个网站提供了许多功能，最基本的就是评论作为树状结构的线索化。

PostgreSQL提供了许多个关于线索化的解决方案。最常用的（也是最高效的）方法就是改良版的前序遍历。简单的说，他增加了一个左序，一个右序，他们会在你添加评论时被更新。我们还有另一个标准的方法（Reddit使用的很欢乐），那就是“取出所有的东西，然后在内存中完成操作”。实际上，不仅仅只有Reddit这样做。

继续看看PGSQL为我们提供的东西，我们还可以找到两个选项（最低在8.4版本）。其中一个是使用PG的内建模块称为ltree。他允许你将一个节点的完整路径（所有父结点）存储下来，同时允许你通过标准的sql语句查询他们。当你需要按照“最早发布”排序的时候，它会非常有用，因为这样以来，就变为了简单的按照“ltree——column”排序。然而，和大部分时候一样，Disqus的情况没有这么简单。

我们的第二个解决方案就是递归查询。他花了我很长一段时间来理解他是怎么工作的，但是当我理解后，我被他的能力深深的吸引了。Postgre提供了许多MySQL所没有的特性，比如over()修饰符。他们真的表现的非常好。

让我们继续深入我们的问题，这会是一个大问题。现在，Disqus和Reddit处理多线程的方法一样，都是和网上其他的解决方案一样，非常的简陋。我说的是简陋不是说代码写的不好，而是他的优化没有做到他应该做到的。直到某些人（就是你，Obama同学）开始使用这个程序，并且所有人都想回复他的话，我们才发现出问题了。我们再一次想到了Django（即使他们越来越大）并且通过业务逻辑将他们分组。

自从8.4开始，我们就可以使用递归查询来解决这个问题（在许多情况下我们已经自己开始这么做了，虽然会有点复杂）这个相当的简单。

因此，让我们一个基本的例子。我们有一个的评论模型，它看起来有点像这样：

1. create table comments (
   
2.     id SERIAL PRIMARY KEY,
   
3.     message VARCHAR,
   
4.     author VARCHAR,
   
5.     parent_id INTEGER REFERENCES comments(id)
   
6. );
   
7. insert into comments (message, author, parent_id)
   
8.     values ('This thread is really cool!', 'David', NULL), ('Ya David, we love it!', 'Jason', 1), ('I agree David!', 'Daniel', 1), ('gift Jason', 'Anton', 2),
   
9.     ('Very interesting post!', 'thedz', NULL), ('You sir, are wrong', 'Chris', 5), ('Agreed', 'G', 5), ('Fo sho, Yall', 'Mac', 5);

复制代码

我们现在所做的，是建立一个基本的评价模型。我们的消息，笔者父评论（这是可选的）。现在，让我们来学习如何使用递归查询可以轻松地重新订购本datd中，由id升序排序。

1. WITH RECURSIVE cte (id, message, author, path, parent_id, depth)  AS (
   
2.     SELECT  id,
   
3.         message,
   
4.         author,
   
5.         array[id] AS path,
   
6.         parent_id,
   
7.         1 AS depth
   
8.     FROM    comments
   
9.     WHERE   parent_id IS NULL
   
10. 
    
11.     UNION ALL
    
12. 
    
13.     SELECT  comments.id,
    
14.         comments.message,
    
15.         comments.author,
    
16.         cte.path || comments.id,
    
17.         comments.parent_id,
    
18.         cte.depth + 1 AS depth
    
19.     FROM    comments
    
20.     JOIN cte ON comments.parent_id = cte.id
    
21.     )
    
22.     SELECT id, message, author, path, depth FROM cte
    
23. ORDER BY path;

复制代码

很甜蜜吧？哦，等等，有困惑？所以我一直在寻找的查询更复杂的是一大堆惊人的bug.
pgexperts为我们指向正确的道路。

现在，我不会钻到太多，因为有更好的教程，在此模式中处理递归查询，但我们完成了我们的结果。

我们要处理一个巨大信息集，并且有些评论有将近几千个回复。如果99%的评论都只有100个回复，那么将他们放入内存中并不是什么问题，但当他们开始增加时，我们最终会浪费很多时间。PGSQL中的递归查询可以让我们很简单的把这项工作交给数据库（有时候他们处理的比我们快的多），并且给我们节省了很多花费在网络传播和web处理的时间和资源。有一个例子可以让你更直观的理解他是多么的高效，我们曾经见过仅在大型数据库的SQL处理时间这一项上（返回25个结果，而不是1000个）就将近节省了500%的时间。这甚至没有包括我们在程序级上的花费。是的，没错，这些SQL语句仅在数据库层上就比其他数据库快5倍

总而言之，作为一个MySQL的拥护者，我对Disqus使用PostgreSQL所达到的性能，规模，以及灵活性表示十分震惊。我十分期待去发现通过这个平台我们还能做什么，去寻找还在等待我们的挑战。（是的，我回来了，并且会继续记录一些发生在我们身上的随笔/特别的/疯狂的/禁止的事情

zhuomingliang

递归查询是好东西，就是不知道性能怎么样。