创建一个实现Disqus评论模版的MySQL模型

在很长一段时间内，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开始，我们就可以使用递归查询来解决这个问题（在许多情况下我们已经自己开始这么做了，虽然会有点复杂）这个相当的简单。