Solr numDocs 溢出

Question

我们正在运行 Solr 来索引大量数据，但遇到了一个非常有趣的问题，我无法在任何地方找到任何帮助。

似乎 Solr 使用带符号的 32 位整数来计算索引中当前的文档数。我们刚刚达到了这个数字，我们的 Solr 统计页面显示如下:

numDocs : -2116382092
maxDoc : -2114669444 

Solr 似乎仍然能够很好地索引传入的数据，但是当我们搜索时，我们得到一个 NegativeArraySizeException(请参阅下面的堆栈跟踪)

我们假设错误和溢出是相关的(我相信这是一个合理的假设)。Solr 文档中没有任何内容，到目前为止我还没有找到关于该主题的任何相关帮助。该问题的解决方案很可能是删除索引 block 以将大小减小到 MAX_INT 以下，但我们不确定这是否有效，因为 Solr 很可能必须执行搜索才能找到要删除的文档。

我想这与其说是一个问题，不如说是在陈述事实，但我想知道是否还有其他人遇到过这个问题，如果遇到过，您是如何解决的？

 java.lang.NegativeArraySizeException
    at org.apache.solr.search.DocSetCollector.<init>(DocSetHitCollector.java:47)
    at org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:627)
    at org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:563)
    at org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:592)
    at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:903)
    at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:884)
    at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341)
    at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:182)
    at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
    at    org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
    at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
    at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
    at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
    at     org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
    at     org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:662)

Answer 1

经过一番努力，我们设法解决了这个问题。

我们做了什么以及我们如何解决它

首先，我们运行 CheckIndex 来验证所有段及其自身的索引是否处于良好状态并且没有损坏。这也让我们知道我们有足够的 RAM 可以稍后在更大的段上做一些真正的工作。正如所料，CheckIndex 的结果没有问题。 CheckIndex 在 Lucene 库中可用。

第二步是将索引分成两部分(而不是一半)。在我们的例子中，我们有一个由大约 17 亿个文档组成的巨大片段，我们只是将该片段从源索引中分离出来并创建了两个新索引，一个是大片段，另一个是我们拥有的其余 20 多个片段之一。为此，我们使用了同样来自 Lucene 库的 IndexSplitter。

拆分索引需要 Lucene 3.0.x，而我们只安装了 Lucene 2.9.3(与 Solr 1.4.1 捆绑在一起)。我们下载了一个单独的 Lucene 3.0.3 实例来使用 IndexSplitter。创建的两个新索引与我们的 Lucene 版本不兼容，因此我们最终不得不将 Solr 安装中的 Lucene 升级到 2.9.4，它可以读取 3.0.x 索引。

然后我们引导 Solr 指向每个新索引，一次一个。这次 numDocs 低于 MAX_INT，我们可以运行删除语句。在对两个新索引执行此操作后，我们简单地使用 IndexMerge 工具将它们合并在一起，同样在 Lucene 库中，剩下的内容最终得到一个健康的 15 亿文档索引，这将持续我们另外一对几个月:)这里吸取的教训是在我们达到上限之前运行删除查询。

所有 Lucene 专家的问题:

如果您在达到 MAX_INT 后继续索引，实际会发生什么？我们要覆盖数据吗？如果是，哪些数据最有可能被覆盖？