虽然网上现成的wiki一大票，不过对需要进行定制开发的时候这些wiki就未必适合了。由于只是想整个最基本的wiki功能，因此打算自己整一整。 也许是有些厌倦了java，也许是想更深入的体会一下脚本语言的魅力，我决定采用django来进行开发。而且使用django有个好处，支持python的虚拟主机比支持java的好找。
    虽然是重新开始整，但如果有现成的轮子当然是最好了。既然决定使用django，当然要到django的code目录去找找。diamanda，一个论坛+wiki的程序。功能很简单，但作为一个轮子还是一个不错的选择。wiki最大的特色就是版本控制，因此我对wiki的版本控制算法比较关心。看了一下版本控制部分，居然是每个版本都全部保存（我一直认为wiki应当是增量保存的）。这意味着即使是一个很小的改动也得重新保存一份。对于一篇很长的文章来说，冗余实在是大得惊人。想来也许是这个程序的问题，于是考虑去找些其他的wiki程序作为参考。除去django的项目，其他的python wiki项目也不错。反正算法什么的都可以直接用。（中途还down了个java的wiki，不过没耐心看）
    又去溜达了一圈，看中了moin，python里最知名的wiki项目之一。不熟悉moin的web处理模型，看得我似懂非懂。不过基本上可以确定，他也是每个版本保存一份。
    最后想想还是去看看mediawiki吧，世界上最大的wiki“基维”用的就是他。有些晕，这个也是使用全部保存的方式。想来“基维”有好几百w的数据，加上每条纪录都有多个版本，“基维”的数据库压力定是N大。不过到此我也不用去想搞啥增量算法了。众多wiki程序都是使用的全部保存模式，定是有些道理。增量算法即使有，也必定会有不少难点有待解决。
    下面看看mediawikiwiki的设计吧。
    mediawiki使用数据库来存储wiki数据。一张page信息表用于保存每个wiki页面的信息。可能是考虑到性能问题，真正的页面内容却没有保存在该表中，而是单独保存在text表中。表里的数据都是以blod方式保存，为什么这样做俺就不太清楚了，难道是效率更高？只有最新版本的数据才是需要索引的数据，因此单独出一张索引表，用来进行索引查询。文本内容在被索引前实现要进行一次过滤，过滤掉wiki标签等。
    由于加入了版本控制，数据库中数据表中的纪录数将是实际主题的好几倍。而且随着wiki内容的丰富和完善，数据库中纪录大小将迅速膨胀。数据库的压力不言而喻。
    为了减轻数据库的压力，有些wiki选用使用了更高效的办法，使用文件的形式存储wiki内容。其中moin就是这样做的。moin使用一定的规则将wiki纪录以文件的形式保存，并使用lupy（1）对文件进行索引，提供查询的支持。
    为了减少每个版本都全部保存一遍所带来的巨大冗余，不少wiki都支持分段编辑。即可以对每段进行单独的编辑，在保存的时候只保存做修改那部分的内容。

(1)lupy 一个lucene的python移植版。与pylucene使用gcj移植不同的是，lupy完全使用python对lucene改写。lupy的问题是支持lucene版本比较低，只支持到1.2。