基于Java的全文索引引擎

基于Java的全文索引引擎
基于Java的全文索引引擎

在应用中加入全文检索功能

——基于Java的全文索引引擎Lucene简介

作者:车东 Email: https://www.360docs.net/doc/6b222707.html,/https://www.360docs.net/doc/6b222707.html,

写于:2002/08 最后更新:09/09/2006 17:09:05

Feed Back >> (Read this before you ask question)

版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本声明

https://www.360docs.net/doc/6b222707.html,/tech/lucene.html

关键词:Lucene java full-text search engine Chinese word segment

内容摘要:

Lucene是一个基于Java的全文索引工具包。

1.基于Java的全文索引引擎Lucene简介:关于作者和Lucene的历史

2.全文检索的实现:Luene全文索引和数据库索引的比较

3.中文切分词机制简介:基于词库和自动切分词算法的比较

4.具体的安装和使用简介:系统结构介绍和演示

5.Hacking Lucene:简化的查询分析器,删除的实现,定制的排序,应用

接口的扩展

6.从Lucene我们还可以学到什么

基于Java的全文索引/检索引擎——Lucene

Lucene不是一个完整的全文索引应用,而是是一个用Java写的全文索引引擎工具包,它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。

Lucene的作者:Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家,曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者,后在Excite担任高级系统架构设计师,目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。

Lucene的发展历程:早先发布在作者自己的https://www.360docs.net/doc/6b222707.html,,后来发布在SourceForge,2001年年底成为APACHE基金会jakarta的一个子项目:https://www.360docs.net/doc/6b222707.html,/lucene/

已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎,比较著名的有:

Jive:WEB论坛系统;

?Eyebrows:邮件列表HTML归档/浏览/查询系统,本文的主要参考文档“TheLucene search engine: Powerful, flexible, and free”作者

就是EyeBrows系统的主要开发者之一,而EyeBrows已经成为目前

APACHE项目的主要邮件列表归档系统。

?Cocoon:基于XML的web发布框架,全文检索部分使用了Lucene

?Eclipse:基于Java的开放开发平台,帮助部分的全文索引使用了Lucene

对于中文用户来说,最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene的结构的介绍,你会了解到由于Lucene良好架构设计,对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。

全文检索的实现机制

Lucene的API接口设计的比较通用,输入输出结构都很像数据库的表==>记录==>字段,所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。总体上看:可以先把Lucene

当成一个支持全文索引的数据库系统。

比较一下Lucene和数据库:

全文检索≠ like "%keyword%"

通常比较厚的书籍后面常常附关键词索引表(比如:北京:12, 34页,上海:3,77页……),它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样,想像一下通过

书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高,另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。

由于数据库索引不是为全文索引设计的,因此,使用like "%keyword%"时,数据库索引是不起作用的,在使用like查询时,搜索过程又变成类似于一页页翻书的遍历过程了,所以对于含有模糊查询的数据库服务来说,LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配:like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。

所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制,将数据源(比如多篇文章)排序顺序存储的同时,有另外一个排好序的关键词列表,用于存储关键词==>文章映射关系,利用这样的映射关系索引:[关键词==>出现关键词的文章编号,出现次数(甚至包括位置:起始偏移量,结束偏移量),出现频率],检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率,所以,全文检索问题归结到最后是一个排序问题。

由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题,这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制,并提供了扩展接口,以方便针对不同应用的定制。

可以通过一下表格对比一下数据库的模糊查询:

全文检索和数据库应用最大的不同在于:让最相关的头100条结果满足98%以上用户的需求

Lucene的创新之处:

大部分的搜索(数据库)引擎都是用B树结构来维护索引,索引的更新会导致大量的IO操作,Lucene在实现中,对此稍微有所改进:不是维护一个索引文件,而是在扩展索引的时候不断创建新的索引文件,然后定期的把这些新的小索引文件合并到原先的大索引中(针对不同的更新策略,批次的大小可以调整),这样在不影响检索的效率的前提下,提高了索引的效率。

Lucene和其他一些全文检索系统/应用的比较:

关于亚洲语言的的切分词问题(Word Segment)

对于中文来说,全文索引首先还要解决一个语言分析的问题,对于英文来说,语句中单词之间是天然通过空格分开的,但亚洲语言的中日韩文语句中的字是一个字挨一个,所有,首先要把语句中按“词”进行索引的话,这个词如何切分出来就是一个很大的问题。

首先,肯定不能用单个字符作(si-gram)为索引单元,否则查“上海”时,不能让含有“海上”也匹配。

但一句话:“北京天安门”,计算机如何按照中文的语言习惯进行切分呢?

“北京天安门” 还是“北京天安门”?让计算机能够按照语言习惯进行切分,往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。

另外一个解决的办法是采用自动切分算法:将单词按照2元语法(bigram)方式切分出来,比如:

"北京天安门" ==> "北京京天天安安门"。

这样,在查询的时候,无论是查询"北京" 还是查询"天安门",将查询词组按同样的规则进行切分:"北京","天安安门",多个关键词之间按与"and"的关系组合,同样能够正确地映射到相应的索引中。这种方式对于其他亚洲语言:韩文,日文都是通用的。

基于自动切分的最大优点是没有词表维护成本,实现简单,缺点是索引效率低,但对于中小型应用来说,基于2元语法的切分还是够用的。基于2元切分后的索引一般大小和源文件差不多,而对于英文,索引文件一般只有原文件的30%-40%不同,

目前比较大的搜索引擎的语言分析算法一般是基于以上2个机制的结合。关于中文的语言分析算法,大家可以在Google查关键词"wordsegment search"能找到更多相关的资料。

安装和使用

下载:https://www.360docs.net/doc/6b222707.html,/lucene/

注意:Lucene中的一些比较复杂的词法分析是用JavaCC生成的(JavaCC:JavaCompilerCompiler,纯Java 的词法分析生成器),所以如果从源代码编译或需要修改其中的QueryParser、定制自己的词法分析器,还需要从https://https://www.360docs.net/doc/6b222707.html,/下载javacc。

lucene的组成结构:对于外部应用来说索引模块(index)和检索模块(search)是主要的外部应用入口

简单的例子演示一下Lucene的使用方法:

索引过程:从命令行读取文件名(多个),将文件分路径(path字段)和内容(body 字段)2个字段进行存储,并对内容进行全文索引:索引的单位是Document对象,每个Document对象包含多个字段Field对象,针对不同的字段属性和数据输出

//使用方法:: IndexFiles [索引输出目录] [索引的文件列表] ...

public static void main(String[] args) throws Exception {

String indexPath = args[0];

IndexWriter writer;

//用指定的语言分析器构造一个新的写索引器(第3个参数表示是否为追加索引)

writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);

for (int i=1; i

System.out.println("Indexing file " + args[i]);

InputStream is = new FileInputStream(args[i]);

//构造包含2个字段Field的Document对象

//一个是路径path字段,不索引,只存储

//一个是内容body字段,进行全文索引,并存储

Document doc = new Document();

doc.add(Field.UnIndexed("path", args[i]));

doc.add(Field.Text("body", (Reader) new InputStreamReader(is))); //将文档写入索引

writer.addDocument(doc);

is.close();

};

//关闭写索引器

writer.close();

}

}

索引过程中可以看到:

?语言分析器提供了抽象的接口,因此语言分析(Analyser)是可以定制的,虽然lucene缺省提供了2个比较通用的分析器SimpleAnalyser和

StandardAnalyser,这2个分析器缺省都不支持中文,所以要加入对中

文语言的切分规则,需要修改这2个分析器。

?Lucene并没有规定数据源的格式,而只提供了一个通用的结构(Document 对象)来接受索引的输入,因此输入的数据源可以是:数据库,WORD文

档,PDF文档,HTML文档……只要能够设计相应的解析转换器将数据源

构造成成Docuement对象即可进行索引。

?对于大批量的数据索引,还可以通过调整IndexerWrite的文件合并频率属性(mergeFactor)来提高批量索引的效率。

检索过程和结果显示:

搜索结果返回的是Hits对象,可以通过它再访问Document==>Field中的内容。

假设根据body字段进行全文检索,可以将查询结果的path字段和相应查询的匹配度(score)打印出来,

public class Search {

public static void main(String[] args) throws Exception {

String indexPath = args[0], queryString = args[1];

//指向索引目录的搜索器

Searcher searcher = new IndexSearcher(indexPath);

//查询解析器:使用和索引同样的语言分析器

Query query = QueryParser.parse(queryString, "body",

new SimpleAnalyzer());

//搜索结果使用Hits存储

Hits hits = searcher.search(query);

//通过hits可以访问到相应字段的数据和查询的匹配度

for (int i=0; i

System.out.println(hits.doc(i).get("path") + "; Score: " +

hits.score(i));

};

}

}

在整个检索过程中,语言分析器,查询分析器,甚至搜索器(Searcher)都是提供了抽象的接口,可以根据需要进行定制。

Hacking Lucene

简化的查询分析器

个人感觉lucene成为JAKARTA项目后,画在了太多的时间用于调试日趋复杂QueryParser,而其中大部分是大多数用户并不很熟悉的,目前LUCENE支持的语法:

Query ::= ( Clause )*

Clause ::= ["+", "-"] [ ":"] ( | "(" Query ")")

中间的逻辑包括:and or + - &&||等符号,而且还有"短语查询"和针对西文的前缀/模糊查询等,个人感觉对于一般应用来说,这些功能有一些华而不实,其实能够实现目前类似于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以,Lucene早期版本的QueryParser仍是比较好的选择。

添加修改删除指定记录(Document)

Lucene提供了索引的扩展机制,因此索引的动态扩展应该是没有问题的,而指定记录的修改也似乎只能通过记录的删除,然后重新加入实现。如何删除指定的记录呢?删除的方法也很简单,只是需要在索引时根据数据源中的记录ID专门另建索引,然后利用IndexReader.delete(Termterm)方法通过这个记录ID删除相应的Document。

根据某个字段值的排序功能

lucene缺省是按照自己的相关度算法(score)进行结果排序的,但能够根据其他字段进行结果排序是一个在LUCENE的开发邮件列表中经常提到的问题,很多原先基于数据库应用都需要除了基于匹配度(score)

以外的排序功能。而从全文检索的原理我们可以了解到,任何不基于索引的搜索过程效率都会导致效率非常的低,如果基于其他字段的排序需要在搜索过程中访问存储字段,速度回大大降低,因此非常是不可取的。

但这里也有一个折中的解决方法:在搜索过程中能够影响排序结果的只有索引中已经存储的docID和score 这2个参数,所以,基于score以外的排序,其实可以通过将数据源预先排好序,然后根据docID进行排序来实现。这样就避免了在LUCENE搜索结果外对结果再次进行排序和在搜索过程中访问不在索引中的某个字段值。

这里需要修改的是IndexSearcher中的HitCollector过程:

...

scorer.score(new HitCollector() {

private float minScore = 0.0f;

public final void collect(int doc, float score) {

if (score > 0.0f && // ignore zeroed buckets

(bits==null || bits.get(doc))) { // skip docs not in bits

totalHits[0]++;

if (score >= minScore) {

/* 原先:Lucene将docID和相应的匹配度score例入结果命中列表中:

* hq.put(new ScoreDoc(doc, score)); // update hit queue

* 如果用doc 或 1/doc 代替 score,就实现了根据docID顺排或逆排

* 假设数据源索引时已经按照某个字段排好了序,而结果根据docID排序也就实现了

* 针对某个字段的排序,甚至可以实现更复杂的score和docID 的拟合。

*/

hq.put(new ScoreDoc(doc, (float) 1/doc ));

if (hq.size() > nDocs) { // if hit queue overfull

hq.pop(); // remove lowest in hit queue

minScore = ((ScoreDoc)hq.top()).score; // reset minScore }

}

}

}

}, reader.maxDoc());

更通用的输入输出接口

虽然lucene没有定义一个确定的输入文档格式,但越来越多的人想到使用一个标准的中间格式作为Lucene 的数据导入接口,然后其他数据,比如PDF只需要通过解析器转换成标准的中间格式就可以进行数据索引了。这个中间格式主要以XML为主,类似实现已经不下4,5个:

数据源: WORD PDF HTML DB other

\ | | | /

XML中间格式

|

Lucene INDEX

目前还没有针对MSWord文档的解析器,因为Word文档和基于ASCII的RTF文档不同,需要使用COM对象机制解析。这个是我在Google上查的相关资料:

https://www.360docs.net/doc/6b222707.html,/products/enterprise_applications.asp

另外一个办法就是把Word文档转换成text:http://www.winfield.demon.nl/index.html

索引过程优化

索引一般分2种情况,一种是小批量的索引扩展,一种是大批量的索引重建。在索引过程中,并不是每次新的DOC加入进去索引都重新进行一次索引文件的写入操作(文件I/O是一件非常消耗资源的事情)。

Lucene先在内存中进行索引操作,并根据一定的批量进行文件的写入。这个批次的间隔越大,文件的写入次数越少,但占用内存会很多。反之占用内存少,但文件IO操作频繁,索引速度会很慢。在IndexWriter 中有一个MERGE_FACTOR参数可以帮助你在构造索引器后根据应用环境的情况充分利用内存减少文件的操作。根据我的使用经验:缺省Indexer是每20条记录索引后写入一次,每将MERGE_FACTOR增加50倍,索引速度可以提高1倍左右。

搜索过程优化

lucene支持内存索引:这样的搜索比基于文件的I/O有数量级的速度提升。

https://www.360docs.net/doc/6b222707.html,/lpt/a/3273

而尽可能减少IndexSearcher的创建和对搜索结果的前台的缓存也是必要的。

Lucene面向全文检索的优化在于首次索引检索后,并不把所有的记录(Document)具体内容读取出来,而起只将所有结果中匹配度最高的头100条结果(TopDocs)的ID放到结果集缓存中并返回,这里可以比较一下数据库检索:如果是一个10,000条的数据库检索结果集,数据库是一定要把所有记录内容都取得以后再开始返回给应用结果集的。所以即使检索匹配总数很多,Lucene的结果集占用的内存空间也不会很多。对于一般的模糊检索应用是用不到这么多的结果的,头100条已经可以满足90%以上的检索需求。

如果首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次的搜索缓存数大1倍的缓存,并再重新向后抓取。所以如果构造一个Searcher去查1-120条结果,Searcher其实是进行了2次搜索过程:头100条取完后,缓存结果用完,Searcher重新检索再构造一个200条的结果缓存,依此类推,400条缓存,800条缓存。由于每次Searcher对象消失后,这些缓存也访问那不到了,你有可能想将结果记录缓存下来,缓存数尽量保证在100以下以充分利用首次的结果缓存,不让Lucene浪费多次检索,而且可以分级进行结果缓存。

Lucene的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和数据库应用需要将搜索的结果全部返回不同之处。

我的一些尝试:

?支持中文的Tokenizer:这里有2个版本,一个是通过JavaCC生成的,对CJK部分按一个字符一个TOKEN索引,另外一个是从SimpleTokenizer

改写的,对英文支持数字和字母TOKEN,对中文按迭代索引。

?基于XML数据源的索引器:XMLIndexer,因此所有数据源只要能够按照DTD转换成指定的XML,就可以用XMLIndxer进行索引了。

?根据某个字段排序:按记录索引顺序排序结果的搜索器:

IndexOrderSearcher,因此如果需要让搜索结果根据某个字段排序,可

以让数据源先按某个字段排好序(比如:PriceField),这样索引后,

然后在利用这个按记录的ID顺序检索的搜索器,结果就是相当于是那

个字段排序的结果了。

从Lucene学到更多

Luene的确是一个面对对象设计的典范

?所有的问题都通过一个额外抽象层来方便以后的扩展和重用:你可以通过重新实现来达到自己的目的,而对其他模块而不需要;

?简单的应用入口Searcher, Indexer,并调用底层一系列组件协同的完成搜索任务;

?所有的对象的任务都非常专一:比如搜索过程:QueryParser分析将查询语句转换成一系列的精确查询的组合(Query),通过底层的索引读取结

构IndexReader进行索引的读取,并用相应的打分器给搜索结果进行打

分/排序等。所有的功能模块原子化程度非常高,因此可以通过重新实

现而不需要修改其他模块。

?除了灵活的应用接口设计,Lucene还提供了一些适合大多数应用的语言分析器实现(SimpleAnalyser,StandardAnalyser),这也是新用户能

够很快上手的重要原因之一。

这些优点都是非常值得在以后的开发中学习借鉴的。作为一个通用工具包,Lunece的确给予了需要将全文检索功能嵌入到应用中的开发者很多的便利。

此外,通过对Lucene的学习和使用,我也更深刻地理解了为什么很多数据库优化设计中要求,比如:

?尽可能对字段进行索引来提高查询速度,但过多的索引会对数据库表的更新操作变慢,而对结果过多的排序条件,实际上往往也是性能的杀手之

一。

?很多商业数据库对大批量的数据插入操作会提供一些优化参数,这个作用和索引器的merge_factor的作用是类似的,

?20%/80%原则:查的结果多并不等于质量好,尤其对于返回结果集很大,如何优化这头几十条结果的质量往往才是最重要的。

尽可能让应用从数据库中获得比较小的结果集,因为即使对于大型数据库,对结果集的随机访问也是一个非常消耗资源的操作。

参考资料:

Apache: Lucene Project

https://www.360docs.net/doc/6b222707.html,/lucene/

Lucene开发/用户邮件列表归档

Lucene-dev@https://www.360docs.net/doc/6b222707.html,

Lucene-user@https://www.360docs.net/doc/6b222707.html,

The Lucene search engine: Powerful, flexible, and free

https://www.360docs.net/doc/6b222707.html,/javaworld/jw-09-2000/jw-0915-Lucene_p.html

Lucene Tutorial

https://www.360docs.net/doc/6b222707.html,/puff/lucene/lucene.html

Notes on distributed searching with Lucene

https://www.360docs.net/doc/6b222707.html,/markharwood/lucene/

中文语言的切分词

https://www.360docs.net/doc/6b222707.html,/search?sourceid=navclient&hl=zh-CN&q=chinese+word+segment

搜索引擎工具介绍

https://www.360docs.net/doc/6b222707.html,/

Lucene作者Cutting的几篇论文和专利

https://www.360docs.net/doc/6b222707.html,/publications.html

Lucene的.NET实现:dotLucene

https://www.360docs.net/doc/6b222707.html,/projects/dotlucene/

Lucene作者Cutting的另外一个项目:基于Java的搜索引擎Nutch

https://www.360docs.net/doc/6b222707.html,/https://www.360docs.net/doc/6b222707.html,/projects/nutch/

关于基于词表和N-Gram的切分词比较

http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html

2005-01-08 Cutting在Pisa大学做的关于Lucene的讲座:非常详细的Lucene架构解说

特别感谢:

前网易CTO许良杰(Jack Xu)给我的指导:是您将我带入了搜索引擎这个行业。

原文出处:

http://www.chedong.c om/tech/lucene.html

<<返回

<<返回首页

主流三维引擎对比分析说明书

主流三维引擎对比分析 随着计算机可视化、虚拟现实技术的飞速发展,人们对实时真实感渲染以及场景复杂度提出了更高的要求。传统的直接使用底层图形接口如OpenGL、DirectX开发图形应用的模式越来越暴露出开发复杂性大、周期性长、维护困难的缺陷。为此国外出现了许多优秀的三维渲染引擎,比如Delta3D,OGRE,OSG,Unity3d,VTK等。渲染引擎的作用就是要优化遍历与显示三维模型。本文主要对OGRE与OSG这两个三维图形渲染引擎做个简单的比较,介绍她们在运行效率、场景管理、功能支持、可扩展性等方面的异同。通过了解两者差异后,可以根据不同的项目需求,选择合适的渲染引擎。 ogre OGRE(Object-Oriented Graphics Rendering Engine,面向对象图形渲染引擎) 又叫做OGRE 3D。OGRE就是面向场景的、灵活的图像引擎。OGRE仍然在发展中,如果就功能与商业游戏引擎还有一定差距。在OGRE的论坛网站上您可以得到更多的信息,里面谈论到OGRE的一些格外的插件,如声音,UI ,物理检测,还有网络应用。采用C++开发,以MIT许可证发布,可以在Windows、Linux、Mac上运行。OGRE自己也说明本身不就是游戏引擎。 其主要特征如下: 面向对象,插件扩展架构,具有文档支持。 支持脚本。可以通过脚本管理材质资产并进行多路渲染。 支持物理碰撞检测。 支持顶点灯光、像素灯光、灯光映射。 支持阴影映射、三维阴影。 支持多纹理、凹凸贴图、多重材质贴图、立体投影。 支持顶点、像素、高级着色。 支持场景管理,具有多种数据结构。 支持逆向运动动画、骨架动画、变形动画、混合动画及姿态动画。 支持网格加载、皮肤、渐进网格。 支持环境映射、镜头眩光、公告牌、粒子、运动模糊、天空、水、雾、丝带轨迹、透明对象。支持XML文件转换。 引擎特性全面( ),稳定性好( ),支持全面( ),不容易上手与使用( )。

法规标准库及全文检索系统

法规标准库及全文检索系统 一、产品研发背景 为了使电力企业相关人员更方便的查询到国家、行业发布的各种法律、法规及行业标准,避免企业自己搜索各种文件时,不能保证文件信息、版本的正确性和及时性,提高工作效率。开发法规标准库及全文检索系统。 二、产品特点 内容齐全 由中电方大上传和管理软件数据库中文件,上传文件包括电力行业的法律、法规、行业标准和各企业集团规定,还包含一些对这些法律、法规解读的文章或论文,对法律、法规进行更深层次的挖掘理解。企业在生产、培训时使用该软件可以更方便的查询到需要的文件。 文件实时更新 系统中的文件由中电方大进行管理,对每一个文件的过期或作废等,中电方大都保持实时更新,保持系统的与时俱进,保证文件为实时适用的最新版本。 文件查询方便 文件的查询搜索功能,即能输入文件名或关键字在数据库中全部搜索,又能按照法律、法规、标准或是生效年份等不同条件进行查询搜索。 全文所搜功能 此功能是系统的一大亮点。为了便于查询文件及对应文件内容的搜索,系统支持全文搜索功能。如在搜索界面输入“压力容器”,在结果列表中即会显示相关文件的名称,也会显示部分带有关键字的内容。

三、产品功能 系统支持相关法律法规的全面搜索及预览功能。 四、产品解决问题 系统解决了企业在需要获取相关法规文件时不能确定文件的准确性、最新性等问题。 五、提供的产品服务 ◆提供本产品终身更新服务 ◆提供功能个性化开发服务 六、产品适用范围 产品适用于各类企业 七、公司简介 北京中电方大科技股份有限公司,成立于2004年,新三板挂牌上市公司(证券代码430411,简称:中电方大)。 本公司是处于软件和信息技术服务业的安全与应急服务提供商,为电力企业用户提供安全与应急管理及信息化及对应的整体解决方案。公司于2012年获得国家电监会(现国家能源局)颁发的电力安全生产标准化一级评审机构资质,从事发电企业、电力建设企业的安全生产标准化评审业务。于2014年获得国家能源局指定的电力安全培训机构资质,为发电企业、电网企业相关负责人和安全生

工作流系统技术可行性分析v1.1

关于工作流系统技术选型可行性分析 1系统背景 医院的运作过程本质上是人、财、物等资源的优化和配置,形式上无一不体现为信息流、资金流、物流、价值流等合理的流动;随着医院不同科室、部门分工的日益具体化,合作已成为主题,合作的体现形式必然是一个完整而高效的工作流程;有管理的医院的活动过程必然是有序的,这种有序性体现为合理的工作流程。因而工作流(workflow)无处不在。 2系统建设目标 1)隔离workflow系统的控制逻辑和医院业务系统的业务逻辑,使得业务逻辑 的变更对于控制逻辑透明。 2)利用该引擎开发的业务信息系统可以根据具体业务需求量身定制个性化的 业务流程,而不用修改控制逻辑,甚至无需修改源代码。 3)业务人员、开发人员、实施人员可以共同参与流程制定、流程、节点维护 4)提供灵活、丰富的标准开发接口,使得开发人员能采用自己习惯的开发工 具在该平台上定制和扩充模块。 5)采用多层分布式组件技术,力求技术先进性和应用的健壮性。 6)工作流自动化和医院应用积木化。 3工作流技术选型方案 3.1 技术选型目标 1)较好的流程定义工具。 2)工作流技术架构与业务系统之间解耦性较强。

3)工作流系统定位为嵌入式系统,并进行嵌入式部署。 4)业务人员、开发人员、部署实施人员均可参与对流程定义做可视化管理 5)业务人员、开发人员、部署实施人员均可参与流程走向做可视化管理。 6)可从容应对较常使用的工作流场景 7)架构开源程度——100% 8)开源社区活跃度较高 9)架构文档较为齐全 10)监控、管理功能支持 11)有较好其他工作流引擎整合方案 3.2 开源工作流选型 当前开源工作流种类繁多,现对目前国内较活跃的三种工作流(jBPM4,jBPM5,Activiti5)做简要介绍与分析,供参考: 3.2.1jBPM4 3.2.1.1架构简介 jBPM4 全称java Businuess Process Management 第四版(最后一个修订版本jBPM4.4发布于2010-07-19 ),是一种基于javaEE 的轻量级工作流管理软件包。jBPM 项目由Tom Baeyens 2002年发起,并与2004加入到JBoss组织,至今jBPM 发展至今有九年时间,在国内外均有大量的社区与商业支持。jBPM3、jBPM4拥有极度活跃的用户论坛和开发者论坛。

数据库中全文搜索与Like的差别

数据库中全文搜索与Like的差别 在SQL Server中,Like关键字可以实现模糊查询,即确定特定字符串是否与制定模式相匹配。这里的模式可以指包含常规字符和通配符。在模式匹配过程中,常规字符必须与字符串中指定的字符完全匹配。不过通过使用通配符可以改变这个规则,如使用?等通配符可以与字符串的任意部分相匹配。故Like关键字可以在数据库中实现模糊查询。 另外数据库库管理员也可以利用全文搜索功能对SQL Server数据表进行查询。在可以对给定的标进行全文查询之前,数据库管理元必须对这个数据表建立全文索引。全文索引也可以实现类似Like的模糊查询功能。如在一张人才简历表中查找符合特定字符串的信息等等。虽然说Like关键字与全文搜索在功能上大同小异,但是在实现细节上有比较大的差异。作为数据库管理员需要了解这个差异,并选择合适的实现模式。 一、查询效率上的差异。 通常情况下,Like关键字的查询效率还是比较快的。特别是对于结构化的数据,Like的查询效率、灵活性方面是值得称道的。但是对于一些非机构化的文本数据,如果通过Like 关键字来进行模糊查询的话,则其执行效率并不是很理想。特别是对于全文查询来说,其速度要慢得多。而且随着记录数量的增多,类似的差异更明显。如在一张表中,有三百万行左右的文本数据,此时如果利用Like关键字来查找相关的内容,则可能需要几分钟的时间才能够返回正确的结果。相反,对于同样的数据通过采用全文搜索功能的话,则可能只需要1分钟不到甚至更多的时间及可以返回结果。故当文本数据的行数比较多时,如在一万行以上,则此时数据库管理员若采用全文搜索功能的话,则可以比较明显的改善数据库的查询效率。 二、对空格字符的敏感性。 在数据库中如果采用Like关键字进行模糊查询,则在这个关键字后面的所有字符都有意义。如现在用户使用like “abcd ”(带有两个空格)查询时,则后面的空格字符对于Like 关键字也是敏感的。也就是说,如果用户利用上面这条语句进行查询时,则被查询的内容必须也是“abcd ”(带有两个空格)这种类型的数据才会被返回。如果被查询的内容是“abcd ”(不带空格或者带有一个空格)则数据库系统会认为这与查询条件不相符合,故不会返回相关的记录。故Like关键字对于空格是比较敏感的。为此在使用Like关键字时候需要特别注意这个问题。如果用户或者程序开发人员不能够确定abcd后面到底是否有空格,则可以通过通配符拉实现。即可以利用”%abcd%”为条件语句。如此的话,无论abcd前面或者后面是否有空格,则都会被查询出来。但是全文搜索的话,通常情况下系统会把空格忽略掉。即在全文搜索功能中,系统会先对查询条件语句进行优化。如果发现空格的话,则往往会实现把空格过滤掉。故全文搜索的话,对于空格等特殊字符往往是不敏感的。 三、对于一些特殊字符的处理要求。 由于数据类型不同,其数据存储方式也不同。为此某些特殊的数据类型可能无法通过Like关键字来实现模糊查询。如对于办好char和varchar数据的模式的字符串比较可能无法通过Like关键字来实现。也就是说,Like关键字后面带的条件语句仅对字符模式有效,不能够使用Like条件语句来查询格式化的二进制数据等等。为此如果数据库管理元要采用Like 关键字,则其必须了解每种数据类型的存储方式以及导致Like关键字比较失败的原因。知己知彼,百战百胜。只有如此数据库管理员才能够避免因为在不恰当的地方采用了Like关键字而造成查询的错误。不过值得高兴的是,Like关键字支持ASCII模式匹配与Unicode模式匹配。如果Like关键字的所有参数都为ASCII字符数据类型,则Like关键字会自动采用ASCII 模式匹配。如果其中任何一个参数为Unicode数据类型,则系统会把所有的参数都转换为Unicode数据类型,并执行Unicode模式匹配。另外需要注意的是,如果Like关键字加上Unicode的数据类型则后面条件语句的空格是有效的,即比较时会考虑到后面出现的空格。

2015 Bossie评选:最佳开源大数据工具

2015 Bossie评选:最佳开源大数据工具 大数据分布式计算数据存储数据分析开源 摘要:Bossie奖是知名英文IT网站InfoWorld针对开源软件颁发的年度奖项,根据这些软件对开源界的贡献,以及在业界的影响力评判获奖对象。本次InfoWorld评选出了22款最佳的开源大数据工具,像Spark、Storm都名列榜单之上。 InfoWorld在分布式数据处理、流式数据分析、机器学习以及大规模数据分析领域精选出了2015年的开源工具获奖者,下面我们来简单介绍下这些获奖的技术工具。 1. Spark

在Apache的大数据项目中,Spark是最火的一个,特别是像IBM这样的重量级贡献者的深入参与,使得Spark的发展和进步速度飞快。 与Spark产生最甜蜜的火花点仍然是在机器学习领域。去年以来DataFrames API取代SchemaRDD API,类似于R和Pandas的发现,使数据访问比原始RDD接口更简单。 Spark的新发展中也有新的为建立可重复的机器学习的工作流程,可扩展和可优化的支持各种存储格式,更简单的接口来访问机器学习算法,改进的集群资源的监控和任务跟踪。 在Spark1.5的默认情况下,TungSten内存管理器通过微调在内存中的数据结构布局提供了更快速的处理能力。最后,新的https://www.360docs.net/doc/6b222707.html,网站上有超过100个第三方贡献的链接库扩展,增加了许多有用的功能。 2. Storm

Storm是Apache项目中的一个分布式计算框架项目,主要应用于流式数据实时处理领域。他基于低延时交互模式理念,以应对复杂的事件处理需求。和Spark不同,Storm可以进行单点随机处理,而不仅仅是微批量任务,并且对内存的需求更低。在我的经验中,他对于流式数据处理更有优势,特别是当两个数据源之间的数据快速传输过程中,需要对数据进行快速处理的场景。 Spark掩盖了很多Storm的光芒,但其实Spark在很多流失数据处理的应用场景中并不适合。Storm经常和Apache Kafka一起配合使用。 3. H2O

如何用C#实现数据库全文检索

如何用C#实现数据库全文检索 目前行业网站的全文检索的方式主要有两种 方式一:通过数据库自带的全文索引 方式二:通过程序来自建全文索引系统 以Sql Server 2005为例 2005本身就自带全文索引功能,你可以先对数据库表建立索引,具体如何建索引网上搜索一下,建立完索引之后,你就可以用SQL来实现检索功能,例如:select * from ytbxw where contaiins(字段,' 中国');多个查询值之间可以用and 或or来实现,在单表以及单表视图上建全文索引对2005来说根本不是问题,但在多表视图建全文索引2005目前还无法实现这个功能,拿https://www.360docs.net/doc/6b222707.html,为例,其每个栏目的信息都是分开存放的,所以在检索上就无法用该方法来解决这个问题. 下面重点说一下如何用程序来实现检索功能 如果你想自己开发一个全文检索系统,我想这是相当复杂事情,要想实现也不是那么容易的事情,所以在这里我推荐一套开源程序,那就是 DotLucene,我想大家可能都听过这个东东吧,那我就讲讲如何来实现多表情况下的全文检索. 1、新建winform项目,把https://www.360docs.net/doc/6b222707.html,.dll添加到该项目中来 2、创建一个类,类名可以自己取 public class Indexer { private IndexWriter writer; //在指定路径下创建索引文件 public Indexer(string directory) { writer = new IndexWriter(directory, new StandardAnalyzer(), true); writer.SetUseCompoundFile(true); }

开源ERP系统比较

开源ERP系统比较 https://www.360docs.net/doc/6b222707.html,/zhanghaooy/blog/item/9a144f017114dadd277fb5d0.html 现在有许多企业将ERP项目,在企业中没有实施好,都归咎于软件产品不好。其实,这只是你们的借口。若想要将ERP软件真正与企业融合一体,首先得考虑企业的自身情况,再去选择适合的ERP软件。 如果你的企业是高速发展的中小企业,希望用IT给管理带来提升,对国内主流ERP产品几万元到几十万元的投入觉得风险过大,还恐惧购买成品ERP。你还有另外一种选择,选择免费且开放的开源ERP软件进行二次开发,根据自己的要求设定适合你企业的ERP。下载开源ERP的产品十分方便,在各大知名的开源网站上都可免费下载它们。注意哦!开源所有的产品都是对外开放的,且源代码都可任意查看,若您在实施ERP时遇到问题,可在开源社区上进行咨询讨论,当然,您也可以请软件开发商进行二次开发。 开源ERP和其它ERP软件比较,如图所示 下面介绍有哪些开源ERP? Compiere Compiere ERP&CRM为全球范围内的中小型企业提供综合型解决方案,覆盖从客户管理、供应链到财务管理的全部领域,支持多组织、多币种、多会计模式、多成本计算、多语种、多税制等国际化特性。

Compiere ERP & CRM 通过申购 - 采购 - 发票 - 付款、报价 - 订单 - 发票 - 收款、产品与定价、资产管理、客户关系、供应商关系、员工关系、经营业绩分析等功能,将企业内部运营与外部客户相关的业务进行规范和优化,将企业由“ 人治” 转变为“ 法治” 的境界。 更好地管理您的业务 * 优化您的库存 * 输入销售订单 * 从 Web 接收订单 * 创建发票并记录发货单 * 收集收货单并与银行对账单核对 * 自动生成或手工输入采购订单 * 记录供应商收货和发票 * 供应商付款 * 输入手工日记帐 * 打印报表和对账单 Compiere ERP 的特色 报价至收款:为潜在客户或客户创建报价单;订单管理;发票;现金收据。它与供应链管理、客户管理高度集成。 申购至付款:创建申购单、采购订单、发票收据;付款处理。它与供应链管理高度集成。 客户关系管理:是所有客户与潜在客户相关活动的逻辑视图。它构成了全部业务流程的一分。 伙伴关系管理:将不同的实体相互链接起来,允许它们管理线索分发、服务请求、渠道以及营销费用。它允许您提供集中式服务。 供应链管理:包括有物料管理的活动,包括库存收货、发货,以及从实体、它的组织到供货商、客户之间的移库和盘存。 绩效分析:覆盖了应用程序的成本计算与会计维度。 网上商店 / 自助服务:提供了您运行 Web 业务所需的一切。信息通过标准的应用程序共享,因此无需同步或特别的集成工作。 Compiere 网上商店组件可被定制为与您的网站相一致的外观和感受。 管理仪表板:提供了一目了然的关键绩效指标( KPI )视图,它能够互动、实时地展现公司的总体经营业绩。仪表板使得高层管理者能够更有效地实现关键性业务战略,追踪公司与销售指标,达成公司的业绩目标。

(工作分析)国内外主流工作流引擎及规则引擎分析

国内外主流工作流引擎及规则引擎分析2013年2月创新研发部

目录 国内外主流工作流引擎及规则引擎分析 (1) 一.背景 (4) 二.原则 (4) 三.工作流功能分析点 (6) 4.1.标准类 (6) 3.1.1BPMN2.0标准支持 (6) 4.2.开发类 (7) 3.1.1业务模型建模工具 (7) 3.1.2工作流建模工具 (7) 3.1.3人工页面生成工具 (8) 3.1.4仿真工具 (9) 4.3.功能类 (9) 4.1.1流程引擎 (9) 4.1.2规则引擎 (10) 4.1.3组织模型与日期 (10) 4.1.4对外API的提供 (11) 4.1.5后端集成/SOA (11) 4.1.6监控功能 (12) 四.中心已有系统工作流功能点分析 (13) 4.1.备付金系统工作流分析 (13) 4.1.1联社备付金调出流程 (13)

4.1.2联社备付金调入流程 (16) 4.1.3资金划入孝感农信通备付金账户业务流程 (18) 4.1.4备付金运用账户开立流程 (20) 4.1.5备付金沉淀资金运用流程 (23) 4.1.6备付金沉淀资金支取流程 (26) 4.2.多介质项目工作流分析 (28) 4.1.1开卡审批流程 (28) 4.3.新一代农信银资金清算系统工作流分析 (29) 4.4.电子商票系统工作流分析 (29) 4.5.OA系统工作流分析 (32) 五.工作流产品分析 (32) 六.分析结论 (44) 4.4.对比 (44) 4.5.建议 (45)

一.背景 目前中心建成的“一大核心系统,七大共享平台”以及OA系统,对工作流应用程度高,但各系统实现工作流程管理没有建立在统一的工作流平台上,导致流程割裂、重复开发、不易于管理等问题。 备付金管控项目涉及多个岗位之间工作的审核步骤,同时还要与多个系统进行交互,因此,为了提高管理效率,降低业务流转时间,同时还要结合农信银中心的总体IT战略规划,备付金管控项目技术组决定选择一款先进的工作流引擎和一款规则引擎,作为备付金管控项目的核心技术架构。 二.原则 备付金管控项目组通过梳理各信息系统流程现状和未来需求,形成农信银中心工作流平台的发展规划,从而更全面的满足农信银各项关键业务、更好的支撑现有和未来的信息系统建设。项目组充分研究国内外领先的工作流产品和案例,同厂商交流。从用户界面生成、流程建模、流程引擎、规则引擎、组织模型、模拟仿真、后端集成/SOA、变更及版本管理、移动设备解决方案、监控分析能力等多方面考察工作流产品,进行工作流产品选型。 目前国内外的工作流引擎层出不穷,行业标准多种多样,通过对比不同工作流公司产品,本次工作流技术选型决定分析商业工作流引擎4款,开源工作流引擎2款。其中国际知名厂商的商业工作流引擎2款,本土厂商的商业工作流引擎2款。由于本次技术选型是以工作流引擎为主,选型工作将不再单独分析规则

全文检索工具

通过从互联网上提取的各个网站的信息(以网页文字为主)而建立的数据库中,检索与用户查询条件匹配的相关记录,然后按一定的排列顺序将结果返回给用户。 尤其是中文全文检索技术的研究始于1987年左右,已经有一些商品化的软件。Internet 的普及使得全文检索技术日益成熟起来,其应用已突破传统的情报部门和信息中心的局限性,使该技术的最广大用户变成互联网的用户和桌面用户,而不再仅局限于情报检索专家。 全文检索技术以各类数据如文本、声音、图像等为对象,提供按数据的内容而不是外在特征来进行的信息检索,其特点是能对海量的数据进行有效管理和快速检索。它是搜索引擎的核心技术,同时也是电子商务网站的支撑技术。全文检索技术可应用于企业信息网站、媒体网站、政府站点、商业网站、数字图书馆和搜索引擎中。我们知道,企业信息化是电子商务的基础,企业建立自己的商务站点,构建企业内部信息发布平台,并与其他网站间建立安全的信息发布通道和交换通道,建立电子商务的应用并以数据为中心建立应用平台等方面都离不开全文检索。该检索技术可跨越所有的数据源,支持多种数据和信息格式,对检索结果可按商业分类规则进行排列,也能满足用户特定的知识检索请求,将所有不同信息查询中的命中结果按相关性或分类排列,提供不同格式的信息浏览功能。 [1] 从搜索结果来源的角度,全文搜索工具又可细分为两种,一种是拥有自己的检索程序(Indexer),俗称“蜘蛛”(Spider)程序或“机器人”(Robot)程序,并自建网页数据库,搜索结果直接从自身的数据库中调用,如Google、Fast/AllThe Web、AltaVista、Inktomi、Teoma、WiseNut、百度等;另一种则是租用其他引擎的数据库,并按自定的格式排列搜索结果,如Lycos引擎。 “网络机器人”或“网络蜘蛛”是一种网络上的软件,它遍历Web空间,能够扫描一定IP地址范围内的网站,并沿着网络上的链接从一个网页到另一个网页,从一个网站到

中石油 软件工程课程设计 在线考试

2009 软件工程设计实验 软件项目开发题目和完成内容要求 【本文主要对此课程的授课目的、内容、授课形式和考核条件进行了叙述, 并提供给学生一些可选题目,供学生选择完成。学生也可根据文中提供的 选题评分依据自拟自己喜欢的题目。】 鲁强 中国石油大学计算机系

1.课程目的 在完成软件工程课程后,需要应用软件工程开发方法从需求分析、体系结构设计、详细设计、测试等相关环节来实践软件系统开发过程。本课程提供了相关完成相关环节报告的模版,需要学生在完成相关软件题目开发过程中,按照软件工程学到的方法,在各个阶段撰写相关内容。 2.课程内容 2.1.课程要求 开发题目将按照高中低三个档次来进行布置,每个题目的起评分依照项目难度的不同分别为90、85和80。如完成基本题目要求的功能为以上分数,如缺少部分功能将减少5~10,如不能完成(缺少大部分功能)将减少20分,如提供比较完备的功能将在此基础上增加5~10分。 提交的作业需包含以下内容: 1.选择以下题目或自拟一个题目,并提交与此题目对应的可执行代码和源代码。 (20~30分) 2.提交四个文档,即产品需求规格说明书、体系结构设计说明书、模块设计说明书、 测试用例说明书(70~80分,以论文来替代此部分报告,将给零分) 3.将完成的文档以压缩包的格式上传,不能上传多个doc、docx 文档,以免造成文件的丢失。 2.2.开发题目及其验收内容 2.2.1.P2P分布式存储 ●难度 高 ●实现内容 使用Java下JXTA或自己设计P2P协议完成多个客户机下的资源共享。此系统具有 以下功能,每个用户能够配置自己的硬盘空间来供全网络的用户使用,每个用户能 够看到全网络下唯一的文件视图(即能够看到唯一文件目录,此文件目录下存储着 全网络的共享文件),用户能够在此文件视图下创建文件目录、上传文件和下载文 件。其中上传文件指的是将本地文件上传到P2P文件存储系统中,下载文件指的是 将P2P文件存储系统中的文件内容下载到本地机。

三大中文期刊全文数据库的比较

三大中文期刊全文数据库的比较研究 摘要从论文收录情况、检索功能、检索结果、检索界面、用户服务等五个方面对国内三种期刊全文数据库——《中国期刊网全文数据库》、《维普中文科技期刊数据库》和《万方数据资源系统数字化期刊》进行了比较与分析,力图对图书情报机构在数据库选择方面有所指导,同时,对读者有针对性地使用这些数据库有所帮助。 关键词中国期刊网全文数据库维普中文科技期刊数据库万方数据资源系统数字化期刊全文数据库比较电子期刊 《中国期刊网全文数据库》、《维普中文科技期刊数据库》和《万方数据库资源系统数字化期刊》是国内影响力和利用率很高的综合性中文电子期刊全文数据库,这三个数据库已经成为大多数高等院校、公共图书馆和科研机构文献信息保障系统的重要组成部分。在互联网中,这三大数据库也成为中文学术信息的重要代表,体现了我国现有的中文电子文献数据库的建设水平。 笔者结合工作和学习中的实践,就上述三大数据库的收录情况、检索功能、检索结果、检索界面、用户服务等方面进行全面的比较,并通过检索实践举例进行比较分析,以供参考。 1 收录情况 收录范围与数量 《中国期刊网全文数据库》(本文中简称“清华”)是由清华同方光盘股份有限公司、光盘国家工程研究中心和中国学术期刊(光盘版)电子杂志社共同研制出版的综合性全文数据库。该数据库收录自从1994年来公开出版发行的6600余种国内核心期刊和一些具有专业特色的中英文期刊全文,累积全文文献618万多篇(最新数据大于1600万篇),题录1500万余条,按学科分为理工A(数理科学)、理工B(化学化工能源与材料)、理工C(工业技术)、农业、医药卫生、文史哲、经济政治与法律、教育与社会科学、电子技术与信息科学九大类,126个专题文献数据库。 《中文科技期刊数据库》(本文中简称“维普”)由科技部西南信息中心主办,重庆维普资讯有限公司制作。其前身为《中文科技期刊篇名数据库》。该数据库收录了自1989年以来国内出版发行的12000种期刊,其中全文收录8000余种,按学科分为经济管理、教育科学、图书情报、自然科学、农业科学、医药卫生、工程技术等7大类,27个专辑,200个专题,按《中图法》编制了树型分类导航和刊名导航系统,基本覆盖了国内公开出版的具有学术价值的期刊,同时还收录了中国港台地区出版的108种学术期刊,积累700余万篇全文文献(最新数据大于1300万篇),数据量以每年100万篇的速度递增。 《万方数据资源系统数字化期刊》(本文中简称“万方”)是万方数据库资源系统三大组成部分之一,由中国科技信息研究所属下的北京万方数据股份有限公司创办。万方期刊收录了我国自然科学的大量期刊以及社会科学的部分期刊,范围包括基础科学、医药卫生、农业科学、

开源工作流框架对比.

开源工作流框架对比 工作流是基于业务流程的一种模型,它可以把业务流程组织成一个具有逻辑和规则的模型,从而指导业务工作的进行。开源工作流把工作流进行了合理化、科学化的设计与组织,使其更能够满足现在的业务需求。开源工作流可以帮助实现业务目标,通过计算机进行文档的传递,其使用非常广泛。目前国内主要有几种开源工作流框架,下面我们简单地对比一下,帮助大家更深刻地了解开源工作流: 1.JBPM:要想了解JBPM,首先要了解JBPM的简单定义,JBPM是指业务流程管理,它包含了整个业务流程管理过程中的工作流与服务协作,是一种灵活的、开源的管理模式。JBPM可以把一些复杂的业务流畅简单化,让系统更加灵活运行,同时也很方便业务的跟踪、监控和管理,是一种很好的业务工作流框架模式。 2.OSWORKFLOW:这种框架是用java语言编写出来的,简单地说就是一种工作流引擎,其技术性非常强,它能满足用户多方面的需求。用户可以根据自己的需要来设计一些简单或者是复杂的工作流,为企业业务流程管理服务。这种工作流最大的优点是灵活简单,比较容易实现,能够满足当前市场对开源工作流的需求。 3.oa办公软件系统:这种工作流是符合相关标准的系统管理工作流软件,它也是由java编写出来的,其扩展性比较强,功能也多,还具有通用性的特点,可以用于完整的工作流管理系统中。要说这种软件最大的特点,就是其功能模块比较多,比如说动态表单、可视化工作表、智能报表等等,不同的功能表可以帮助用户实现不同的功能,受到了用户的好评。 以上就是现在市场上比较常见的几种开源工作流管理模式,由此可见,不同的工作流模式其优势特点是不同的,不过这些工作流都能给企业业务流程管理起到一个很好的效果,受到了很多企业的欢迎。在这几种工作流模式中,最值得一提的是JBPM,这种工作流是目前比较先进的,已经收到了很多企业的信赖。

全文检索原理

全?文检索 我们?生活中的数据总体分为两种:结构化数据和?非结构化数据。 ?结构化数据:指具有固定格式或有限长度的数据,如数据库,元数据 等。 ??非结构化数据:指不定长或?无固定格式的数据,如邮件,word?文档等。当然有的地?方还会提到第三种,半结构化数据,如XML,HTML等,当根据需要可按结构化数据来处理,也可抽取出纯?文本按?非结构化数据来处理。 ?非结构化数据又?一种叫法叫全?文数据。 按照数据的分类,搜索也分为两种: ?对结构化数据的搜索:如对数据库的搜索,?用SQL语句。再如对元数据 的搜索,如利?用windows搜索对?文件名,类型,修改时间进?行搜索等。 ?对?非结构化数据的搜索:如利?用windows的搜索也可以搜索?文件内容,Linux下的grep命令,再如?用Google和百度可以搜索?大量内容数据。 对?非结构化数据也即对全?文数据的搜索主要有两种?方法: ?一种是顺序扫描法(Serial Scanning):所谓顺序扫描,?比如要找内容包含某?一个字符串的?文件,就是?一个?文档?一个?文档的看,对于每?一个?文档,从头看到尾,如果此?文档包含此字符串,则此?文档为我们要找的?文件,接着看下?一个?文件,直到扫描完所有的?文件。如利?用windows的搜索也可以搜索?文件内容,只是相当的慢。如果你有?一个80G硬盘,如果想在上?面找到?一个内容包含某字符串的?文件,不花他?几个?小时,怕是做不到。Linux下的grep命令也是这?一种?方式。?大家可能觉得这种?方法?比较原始,但对于?小数据量的?文件,这种?方法还是最直接,最?方便的。但是对于?大量的?文件,这种?方法就很慢了。 有?人可能会说,对?非结构化数据顺序扫描很慢,对结构化数据的搜索却相对较快(由于结构化数据有?一定的结构可以采取?一定的搜索算法加快速度),那么把我们的?非结构化数据想办法弄得有?一定结构不就?行了吗? 这种想法很天然,却构成了全?文检索的基本思路,也即将?非结构化数据中的?一部分信息提取出来,重新组织,使其变得有?一定结构,然后对此有?一定结构的数据进?行搜索,从?而达到搜索相对较快的?目的。 这部分从?非结构化数据中提取出的然后重新组织的信息,我们称之索引。 这种说法?比较抽象,举?几个例?子就很容易明?白,?比如字典,字典的拼?音表和部?首检字表就相当于字典的索引,对每?一个字的解释是?非结构化的,如果字典没有?音节表和部?首检字表,在茫茫辞海中找?一个字只能顺序扫描。然?而字的某些信息可以提取出来进?行结构化处理,?比如读?音,就?比较结构化,分声母和韵母,分别只有?几种可以?一?一列举,于是将读?音拿出来按?一定的顺序排列,每?一项读?音都指向此字的详细解释的页数。我们搜索时按结构化的拼?音搜到读?音,然后按其指向的页数,便可找到我们的?非结构化数据——也即对字的解释。

shark工作流引擎表结构分析

SHARK工作流引擎的表结构 背景: Shark作为一个满足XPDL规范的开源工作流引擎,由于有JAWE作为定义工具,现有的很多流程表达,接口的定义都比较丰富。在数据库的数 据结构表达和代码结构上也有很多优点。 当然,Shark 还是在传统的关系数据库的基础上,提出了一个适用于关键业务开发的基于关系结构的工作流引擎的表结构。 关键词:表结构、工作流引擎、shark、数据结构 1数据库表的关系图 Shark中共含有44个表,分别表达不同的数据结构,对应表数据内容和功能的对应关系,分为用户管理、事件管理、包管理、流程流转的控制数据管理等部分。 1.1用户管理 系统的用户和用户组的基本信息 1.2事件管理 在流程运转过程中,针对流程启动和结束,上下文数据,状态数据的改变,任务结束等事件,都记录了变化的前后过程。

1.3包管理 1.4.1在流程定义的参与者和系统真正用户之间有对应关系

1.4.2应用和调用工具类之间的映射 1.5辅助表

1.6流程流转控制数据管理

2Shark持久层对表的封装

class=" usergroup.HibernateUser" table="usertable" hibernate.participantmappin g.cfg.xml HibernateParticipant.hbm.xml class =" partmappersistence.data.HibernateParticipant" table="participant" HibernateGroupUser.hbm.xml class =" partmappersistence.data.HibernateGroupUser" table="groupuser" HibernateNormalUser.hbm.xml class=" partmappersistence.data.HibernateNormalUser" table="normaluser" HibernateProcessPartMap.hbm.xml" class=" partmappersistence.data.HibernateProcessPartMap" table="process" HibernatePackage.hbm.xml class="partmappersistence.data.HibernatePackage" table="package" hibernate.applicationmappin g.cfg.xml HibernateApplicationMapping.hbm.xml class="com.cs3.workflow.appmappersistence.HibernateApplicationMap" table="applicationmappings" hibernate.processlocking.cf g.xml HibernateLockEntry.hbm.xml class=" processlocking.HibernateLockEntry" table="locktable" 表三、独立的*.hbm.xml文件

国内主要工作流厂商分析

国内主要工作流厂商分析 作者荣浩发布于 2011年2月28日上午12时0分 尽管在企业应用中工作流应用的越来越多,但对国内的工作流厂商们来说,这并没有给他们带来期望中的快速增长,这并不奇怪,因为国内工作流产品基本上全部面向开发者和系统集成商,解决的是编程问题,旨在简化对流程进行支撑的软件创建,这个定位决定了当越来越多的系统集成商开始自己研发工作流和越来越多的开发者采用开源工作流时,原有的工作流厂商发现生存日益艰难。 在这篇文章里,我们将一起回顾一下国内主要工作流厂商的产品以及发展策略,接着讨论他们当前所面临的困难以及未来的机会。这里分析的工作流厂商包括了东方易维、西安协同、普元、炎黄动力、有生博大、华创动力、携创、天翎、博汇数码、中创、浪潮以及台湾的华芩。 一、现状 大部分的工作流产品都实现了WFMC工作流参考模型(参见附录)的接口1、接口2、接口3和接口5: ?接口1,流程设计器:包括了两种类型的设计器,一种是基于Web的设计器,实现技术包括了Swing和Flex,一种是基于Eclipse插件的本地应 用实现。除去普元之外,大部分工作流产品都选择实现了一种类型的设计器。Web设计器的好处在于对最终用户友好,基于Eclipse的设计器的好处在于对开发人员友好,能够比较容易的进行单元测试和流程测试,缺点则是基本上隔绝了最终用户对工作流的使用,将工作流死死限制在开发者的层次上。普元同时实现了两种类型的设计器,是做得最好的厂商,东方易维和西安协同实现了基于Web的设计器,通过流程仿真来弥补测试的不足。 ?接口2,工作项客户端接口:通过API暴露调用和交互接口,完成工作项的列表展现、拾取、退回和提交。 ?接口3,外部应用调用接口:基本上都没有对主流ERP、企业管理软件和财务软件进行集成的专有支持,这和国内工作流产品应用的场景有关系,工作流多作为支持单个应用的嵌入式使用,在这一点上天翎提供有与SAP 的集成接口。大部分通过支持Web服务调用进行支持。 ?接口5,管理控制台:包括两部分,一部分是对运行中的案例进行监控和干预,包括了案例的中止、挂起与恢复,任务的中止、跳过、挂起与恢复,参与者的重新指定和催办,工作流变量的修改查看等;一部分是对案例的

TRS全文检索系统文档

1.1.1 全文检索系统结构 根据全文检索技术和实现方法,结合需求,检索系统由以下三个部分组成:TRS全文数据库系统(TRS Database Server) TRS 全文检索网关(TRS Gateway) TRS信息发布应用服务器系统(TRS W AS) TRS全文数据库系统(TRS Database Server)采用TRS具有国际领先水平的信息检索和中文自然语言处理研究成果,具有傲视群雄的检索效果和查询性能,核心功能是对结构化和非结构化信息提供全文检索功能。 主要特点包括: ●异构海量数据统一管理,非结构化和结构化数据联合检索 ●Native XML内核,实现全息检索 ●智能辅助检索,支持知识挖掘 ●精确计算,检索速度和准确性共达最优 ●动态索引实时更新,面向事务处理 ●支持Unicode编码,提供多语种查询引擎 ●多级机制保障,信息采集和检索高度安全 ●集群检索,保证高可靠性,随需轻松扩展规模 TRS全文数据库系统(TRS Database Server)通过TRS全文检索网关,可以实现对关系数据库中文本对象字段的全文检索。 TRS内容分发服务器系统提供将数据库中的信息动态发布到Web服务器上,以为平台用户检索使用。 全文检索系统架构图如下所示:

TRS信息发布应用 服务器系统 全文检索系统架构图 1.1.2 全文检索网关 TRS 全文检索系统采用开放的三层体系架构设计,整个系统基于主流的操作系统。 数据层主要为关系型数据库和TRS全文数据库,关系型数据库主要进行存储和管理,而全文数据库实现检索,利用TRS Gateway可以将关系型数据库的数据在TRS全文数据库中建立全文索引,以实现结构化和非结构化数据的全文检索。TRS全文数据库是TRS 公司自主研发的具有知识产权的产品,为了能够更好的提供全文检索和智能检索等应用功能,它其中包括多种词典支持:分词词典、主题词典、停用词典等。 应用层主要依据TRS全文数据库提供的全文检索功能实现平台所需的检索

Activiti5基于jBPM4的开源工作流系统10分钟入门指南

https://www.360docs.net/doc/6b222707.html, 觉得activiti设计得简单而强大,尝试翻译一下他的10分钟入门指南: 10分钟入门指南 通过一个(非常简单的)业务流程,介绍一些基本的Activiti工作流感念和API接口。 使用案例 这个用例叫干脆(straightfoward):有一个公司,暂且叫它BPMCorp。在BPMCorp内部,会计部门每个月都要写一份财务报告给公司的股东。但在发送给所有股东之前必须经过上级部门的批准。下面涉及的所有文件及代码片段均可以通过Activiti分发的examples范例包中找到,请查看包 https://www.360docs.net/doc/6b222707.html,ertask的内容。 流程图 如上所述的业务流程可以使用Activiti的可视化流程编辑器 Activiti Modeler查看及编辑。使用BPMN2.0的标准符号则如下图所示: 这里没有什么特殊的东西,图中看到的是一个none start event(左边的圆圈),其次是两个user tasks:"撰写财务报告"和”批准财务报告",以 none end event (右边边框加粗型的圆圈)结束。XML表示 上述业务流程的XML表示形式如下所示(FinancialReportProcess.bpmn20.xml). 流程中包含一些主要的元素(通过点击链接可以查看更详细的BPMN 2.0 元素的说明): ?none start event 让我们认识到要开始一个流程。 ?user tasks声明一个基于用户操作的流程任务. 注意第一个任务是分派用户组accountancy的, 而第二个任务是分派到用户组management的. 查看分派用户任务章节可以得到更多怎样分派任务到用户或组的信息。

相关文档
最新文档