本文主要讨论solr中的dataImportHandler机制,对这个不熟的朋友,可以先看下。solr wiki中的dataimporthandler这篇文章,笔者也对dataimporthandler进行了一些翻译,不过效果不是很好,有兴趣的朋友也可以参考一下。 http://mxsfengg.blog.163.com/blog/static/26370218200810250524813/。
想对比较多的数据建立索引,当然要考虑一个量的问题。之前怀疑sqlEntityProcessor是一条条的去数据库中取数据的,因为还有个CachedSqlEntityProcessor,这个类的名字看起来更像是一个能够批量去数据的家伙。
当然事实证明,笔者之前的想法是错的。
对于完全导入、即是full-import,来说,我们只需要关注nextRow() 方法的实现。
public Map<String, Object> nextRow() {
//从缓存中取(在sqlEntityProcessor中这个应该是null,因为在设计上,sqlEntityPorcessor并没有实现缓存。)
if (rowcache != null) {
return getFromRowCache();
}
// 这个只是为了防止rowIterator==null的出现吧
if (rowIterator == null) {
String q = getQuery();
initQuery(resolver.replaceTokens(q));
}
while (true) {
Map<String, Object> r = getNext();
if (r == null) {
return null;
}
// 使用转化器
r = applyTransformer(r);
if (r != null) {
return r;
}
}
}
我们可以看到,nextRow一开始去检测 rowcache,这应该是一个缓存的机制,目前,还没有遇到rowcache!=null的情况。我们发现nextRow实际上调用的是getNext(),
protected Map<String, Object> getNext() {
try {
if (rowIterator == null) {
return null;
}
if (rowIterator.hasNext()) {
return rowIterator.next();
}
//如果一个批次结束了,那么就将这个rowIterator,query置为null。
rowIterator = null;
query = null;
return null;
} catch (Exception e) {
LOG.log(Level.SEVERE, "getNext() failed for query '" + query + "'", e);
rowIterator = null;
query = null;
throw new DataImportHandlerException(DataImportHandlerException.WARN, e);
}
}
而getNext(),又是简单的调用了,rowIterator的next,我们可以这么认为,nextRow()其实就是返回rowIterator的next()。
SqlEntityProcessor一次性的从数据库中将数据取出来放在了rowIterator中,供DocBuilder调用。
粗略的看一下 Docbuilder中的buildDocument这个方法。
@SuppressWarnings("unchecked")
private void buildDocument(VariableResolverImpl vr, SolrWriter.SolrDoc doc,
Map<String, Object> pk, DataConfig.Entity entity, boolean isRoot,
ContextImpl parentCtx) {
.............................................
try {
while (true) {
...................................................................
Map<String, Object> arow = entityProcessor.nextRow();
if (arow == null)
break;
}
} catch (DataImportHandlerException e) {
if (verboseDebug) {
writer.log(SolrWriter.ENTITY_EXCEPTION, entity.name, e);
}
if (isRoot) {
if (e.getErrCode() == DataImportHandlerException.SKIP) {
importStatistics.skipDocCount.getAndIncrement();
} else {
LOG.log(Level.SEVERE, "Exception while processing: "
+ entity.name + " document : " + doc, e);
}
if (e.getErrCode() == DataImportHandlerException.SEVERE)
throw e;
} else
throw e;
} finally {
if (verboseDebug) {
writer.log(SolrWriter.ROW_END, entity.name, null);
if (entity.isDocRoot)
writer.log(SolrWriter.END_DOC, null, null);
}
}
}
} finally {
if (verboseDebug) {
writer.log(SolrWriter.END_ENTITY, null, null);
}
}
}
这个方法使用while循环一直调用nextrow()方法,直到nextRow返回null值,仔细观察getNext(),我们会发现当rowIterator取完的时候,就会返回null了,而这时候,也就跳出了while这个循环。
那就是说,sqlEntity会将执行query语句,并将所有的结果一次取回放到rowIterator中。
现在的问题在于,如果数据库的数量够大,一次取完所有的数据就变得不现实了,那么要怎样才能够实现批次取数据?
以下是笔者实现的一个例子,当然这个例子有很多纰漏,需要去改进,放在这里当作抛砖引玉吧。
这是要索引的表:
people CREATE TABLE `people` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(20) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
一般情况下,相应的dataConfig.xml文件,我们可以这么写:
<entity name="y" query="select * from people "> <field column="id" name="id" /> <field column="name" name="name" /> </entity>
这个结构就会一次性从数据库中取完所有的数据,放在rowIterator中,但现在我们并不想这样去实现,以适应更多的数据量。笔者增加了一个表。下面是这个表的数据。
+-----+---------+
| id | item |
+-----+---------+
| 1 | 0 |
| 5 | 10000 |
| 6 | 50000 |
| 7 | 60000 |
| 8 | 70000 |
| 9 | 80000 |
| 10 | 90000 |
| 11 | 100000 |
| 12 | 110000 |
| 13 | 120000 |
| 14 | 130000 |
| 15 | 140000 |
| 16 | 150000 |
修改dataconfig.xml文件
<entity name="x" query="select * from item" rootEntity="false"> <entity name="y" query="select * from people where id between ${x.item} and ${x.item}+1000"> <field column="id" name="id" /> <field column="name" name="name" /> </entity> </entity>
显而易见,笔者是通过增加一个表的方式来达到控制批量存取的效果的。虽然这不失为问题的解决方法,不过增加一个表来这个步骤实在让人觉得有点繁琐,且通用性不强。
当然我们也可以使用xml来代替数据库中的表,不过这只是一种换汤不换药的方式罢了。
或许,通过继承SqlEntityProcessor,覆盖nextRow方法,扩展它的功能,也是一种可以尝试的选择。