本文主要讨论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) {
- ...................................................................
- <span style="color: #ff0000;"> Map<String, Object> arow = entityProcessor.nextRow();
- if (arow == null)
- break;
- }</span>
- } 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" />
- lt;/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方法,扩展它的功能,也是一种可以尝试的选择。