创建一个实现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开始，我们就可以使用递归查询来解决这个问题（在许多情况下我们已经自己开始这么做了，虽然会有点复杂）这个相当的简单。
因此，让我们一个基本的例子。我们有一个的评论模型，它看起来有点像这样：
createtablecomments(
idSERIALPRIMARYKEY,
messageVARCHAR,
authorVARCHAR,
parent_idINTEGERREFERENCEScomments(id)
);
insertintocomments(message,author,parent_id)
values('Thisthreadisreallycool!','David',NULL),('YaDavid,weloveit!','Jason',1),('IagreeDavid!','Daniel',1),('giftJason','Anton',2),
('Veryinterestingpost!','thedz',NULL),('Yousir,arewrong','Chris',5),('Agreed','G',5),('Fosho,Yall','Mac',5);
我们现在所做的，是建立一个基本的评价模型。我们的消息，笔者父评论（这是可选的）。现在，让我们来学习如何使用递归查询可以轻松地重新订购本datd中，由id升序排序。
WITHRECURSIVEcte(id,message,author,path,parent_id,depth)AS( SELECTid, message, author, array[id]ASpath, parent_id, 1ASdepth FROMcomments WHEREparent_idISNULL UNIONALL SELECTcomments.id, comments.message, comments.author, cte.path||comments.id, comments.parent_id, cte.depth+1ASdepth FROMcomments JOINcteONcomments.parent_id=cte.id ) SELECTid,message,author,path,depthFROMcte ORDERBYpath;
很甜蜜吧？哦，等等，有困惑？所以我一直在寻找的查询更复杂的是一大堆惊人的bug.
pgexperts为我们指向正确的道路。
现在，我不会钻到太多，因为有更好的教程，在此模式中处理递归查询，但我们完成了我们的结果。
我们要处理一个巨大信息集，并且有些评论有将近几千个回复。如果99%的评论都只有100个回复，那么将他们放入内存中并不是什么问题，但当他们开始增加时，我们最终会浪费很多时间。PGSQL中的递归查询可以让我们很简单的把这项工作交给数据库（有时候他们处理的比我们快的多），并且给我们节省了很多花费在网络传播和web处理的时间和资源。
有一个例子可以让你更直观的理解他是多么的高效，我们曾经见过仅在大型数据库的SQL处理时间这一项上（返回25个结果，而不是1000个）就将近节省了500%的时间。这甚至没有包括我们在程序级上的花费。是的，没错，这些SQL语句仅在数据库层上就比其他数据库快5倍
总而言之，作为一个MySQL的拥护者，我对Disqus使用PostgreSQL所达到的性能，规模，以及灵活性表示十分震惊。我十分期待去发现通过这个平台我们还能做什么，去寻找还在等待我们的挑战。