深入浅出jackrabbit之十五 文档提取优化2.docx

/**
*author:ahuaxuan
*2009-10-22
*/

在上一篇文章中，我们讲到为什么要优化jackrabbit中的文档提取，同时也分析了进程模型和线程模型在分布式文档提取中的优劣。

在本文中，ahuaxuan将会介绍分布式文档提取的架构模型，以及它在整个非结构化数据库中的地位。 第二部分ahuaxuan将介绍几个用来提取文本的工具，然后将这些工具用在分布式文档提取中，以减轻jackrabbit的负担， 从这个角度看，本文是对上文的补充，这样从原因，到解决方案，以及所用到的技术工具基本上都涉及到了。

一， 分布式文档提取系统的结构模型。
首先来看一张文档提取系统部署的结构模型：
[img]http://dl.iteye.com/upload/attachment/159570/37563ca3-896c-3ce6-b8d4-c68757784f02.jpg[/img]
从上面一张图中可以看出每台lighttpd下面都挂着很多的flup, 之前我们讲过，文档提取系统是cpu密集型应用，而非io密集型应用，所以这里不用担心client->lighttpd->fastcgi这部分流程会出现瓶颈。

从进程模型上，我们可以得到另外一张图：

[img]http://dl.iteye.com/upload/attachment/159572/d40d309e-bed0-3b2f-96b3-fd1b1d413b6f.jpg[/img]

这个图表示，当一个提取任务发过来的时候， lighttpd会把请求交给flup处理，而flup会将这个任务分给一个子进程。这个子进程中有一些其他的字符串，比如catdoc, catppt等等，在文章的后半部分会介绍这些工具的作用。

[img]http://dl.iteye.com/upload/attachment/159574/495777cc-69c9-3284-9c11-a80ab5925317.jpg[/img]

而上面这张图是分布式文档提取系统在整个系统层次上的位置，其实它的主要功能就是分离计算，在下面这张图中，我们可以看到，index, extraction这样的高消耗cpu和内存的操作都从jackrabbit群组中分离出去了，将这些高消耗性能的非数值计算分离出去可以有效的提高主应用程序的稳定性和扩展性。


看过这三幅图之后，相信大家对分布式文档提取的在整套系统中的地位已经有了一定的了解。下面我们来看看一些常见的文档提取工具。

Xpdf(GNU General Public License (GPL), version2)
Xpdf是用来提取pdf中text的工具

pyPdf(modified BSD license)
pyPdf用来提取pdf中text的工具

Htmllib
用来提取html中的文本

UnRtf(GNU)
用来其他RTF文件中的文本

pyRtf(GPL & LGPL)
pyRTF目前只支持生成rtf文件

Catdoc(GNU Public License)
用来提取word2003的文本

Catppt(GNU Public License)
用来提取ppt2003中的文本

Xls2csv(GNU Public License)
将xls转成csv, 而csv其实就是纯文本，对于做索引来说csv和纯文本基本没有区别

others for 2003
还有就是一些收费的，就不帮他们做广告了

openxmllib(lxml)
GNU General Public License, Version 2.0 (GPL).
Openxmllib是用来提取office2007中word, excel, ppt中的纯文本的，不过需要注意的是它有一个缺陷，它提取出来的文本是无序的，也就是句子的顺序会被打乱，如果你只是做索引，那么这个特性对你来说没有影响，但是如果你想把提取之后的文档保存起来，以后作高亮只用，那么就必须扩展一下openxmllib，还好它比较简单，ahuxuan只用了个把小时就完成了改造。

说到这里分布式文档提取也就基本结束了，当然ahuaxuan并没有把一些细节全盘托出，因为考虑到在完成这项改造之前，同学们必须了解jackrabbit已有的文档提取逻辑，而如果已经了解了那些逻辑，那么我也没有必要将这些细节全盘托出了。阿弥陀佛。


TO BE CONTINUE