RSS

Monthly Archives: 十月 2011

Some tips about crawling large external data with bcs connector

为了让SharePoint的搜索组件能够检索外部内容源(外部的数据库、业务系统、二进制文件等等等等),通常需要创建一个自定义的Indexing Connector。Indexing Connector是一种基于SharePoint 2010中的Business Connectivity ServicesSearch Connector Framework的组件,它替代了以前的Protocol Handler,成为了SharePoint 2010(和FAST Search for SharePoint 2010)所支持的主要的外部数据爬网扩展方式。(SharePoint 2010仍然支持自定义的Protocol Handler。)

在通过BCS的方式创建一个Connector之后,可能面临的问题之一,就是需要使用它去爬非常大的数据量。比如,几百万甚至上千万的数据项。如果Connector需要面对这样的挑战,那么就需要小心的设计Connector。

首先,Connector需要能够良好的支持增量爬网。你肯定不希望在增量爬网的速度和完全爬网一样。

Connector可以以两种方式来支持增量爬网:基于最后修改时间(Timestamp-based),和基于修改日志(Changelog-based)。基于最后修改时间也就是你需要指定一个日期时间字段,Crawler会将此字段作为数据项的最后修改时间,当增量爬网时,Crawler会通过比对这个数据,来知道自己是否需要对一个数据项重新进行处理。基于修改日志则是专门通过额外的方法,直接将某个时间之后新增、被修改、被删除的数据项,返回给搜索引擎,这样搜索引擎就直接知道了从上次爬网到现在,有哪些数据项需要重新处理。

如果外部内容源的数据量非常庞大,即使是第一次的完全爬网,也可能导致Crawler不能正常工作,或者导致外部内容源在短时间内承受过大的压力。

首先,慎重考虑是否直接使用一个Finder方法,来一次性的从外部内容源返回所有所需要的数据(类似于select * from db_table操作)。在小数据量的情况下,这样做很方便,但是如果数据量太大,这么做很可能是不合适的。

比较谨慎的做法,是仅仅使用IdEnumerator方法和SpecificFinder方法获取数据。IdEnumerator方法(类似于select id from db_table)可以返回数据项的ID,然后使用这些ID,重复调用SpecificFinder方法(类似于select * from db_table where id=@id),来一个一个的获取数据项。这时,你需要告诉Connector,这个IdEnumerator方法才是整个Entity的RootFinder。在大部分情况下,你甚至不需要去定义一个Finder方法,因为Crawler根本就不应该一次从外部内容源获取过多的数据。

image

如果数据量超大,甚至IdEnumerator方法的执行可能也是有问题的。想象一下,一次性从外部数据源返回所有几千万个数据项的ID。这个时候就需要更进一步,让IdEnumerator方法每次只返回特定数量(比如1000)的数据项ID。

我们可以为IdEnumerator方法定义一个类型为LastId的筛选器和对应的输入参数(即方向为In的Parameter),这样Crawler会尝试重复调用IdEnumerator方法,每次都将上一次调用后所得到的最后一个ID,作为参数传入。在IdEnumerator方法的实现代码中,就可以根据这个传入的参数,仅从外部内容源检索此ID之后的数据项ID。

image

image

Crawler会尝试以下面这种方式,来重复调用IdEnumerator方法,直到它返回0个结果项为止。(每次调用返回多少数据项,只取决于我们在IdEnumerator方法的实现代码里面返回了多少项。)

image

搜索引擎的Crawler有可能会多次调用SpecificFinder方法来获取同一个数据项(具体原因未知…),所以在Connector里面,可以考虑使用一些cache的技巧,来减少向外部内容源请求数据的次数。如果内容源的数据量很大,将所有数据都一股脑保存到内存里面并不是一个好主意。可以考虑使用HttpRuntime.Cache,虽然看起来它仅能用于Web程序,但实际上只需要在程序中引用System.Web这个程序集,在你的Connector里面使用它是没有问题的(注:微软MSDN文档中注明了它在非ASP.NET程序中可能无法正常工作,但似乎并不存在无法正常工作的情况,但我并不担保…)。这个Cache的实现已经内置了诸如自动清除、优先级设置、缓存时间设置等等功能,比自己写一个要方便很多。另外EntLib里面也有一个可以用于任意类型程序的Cache实现。

除了上面所说的这些之外,Eric Wang还贡献过一个idea。那就是,(按照他的观点,)一次性获取大量数据是没有问题的,如果真的碰到超大规模的数据,可以在搜索管理中创建多个内容源,每个内容源针对外部数据的一部分进行爬网。比如,如果外部数据有200万项,可以考虑创建4个内容源,每个内容源根据某种划分规则,获取并爬网其中的50万项数据。

 

Posted by on 2011/10/19 in 未分类

Leave a comment