Question

我们有一个Web服务方法，它接受一些数据并将其放入Lucene索引中。我们使用它来从我们的asp.net Web应用程序索引新的和更新的条目。

这些条目存储在一个大的SQL Server表中（20M行并且还在增长），如果当前索引被删除或损坏，我需要一种能够重新索引整个表的方法。我不确定从大表中检索数据块的最佳方法是什么。目前，我们使用的事实是该表具有自动增量的PK，因此我们得到1000行的块，直到它开始什么都不返回。有点像（伪语言）：

i = 0
while (true)
{
    SELECT col1, col2, col3 FROM mytable WHERE pk between i and i + 1000
    .... if result is empty 20 times in a row, break ....
    .... otherwise send result to web service to reindex ....
    i = i + 1000
}

这样，我们不需要SELECT COUNT（*）这将是一个很大的性能杀手，我们只是提升pk值直到我们停止获得任何结果。这有它的意思：如果我们在表中的某个地方有一个超过20,000个值的漏洞，它会在假设它到达终点时停止索引，但这是我们现在必须要做的权衡。

有人能建议一种更有效的方法将数据从表格转换为索引吗？我认为我们不是第一个面临这个问题的人 - 现在搜索引擎被广泛使用：）

Answer 1

对于我们使用Lucene所做的事情，我们很少需要重新索引所有内容。我不记得在所有索引都被破坏的情况下遇到任何情况（Lucene实际上非常安全/擅长这个），但是由于某种原因需要重新索引单个项目已经很多次了。我会说最常用的重建索引模式是：

按给定的ID（或一组ID）重新索引项目
在给定的时间段内重新索引项目

当然，后者需要在相关日期字段上单独使用db索引，这对于20M +记录来说应该有点贵，但我们决定采用它（我们最大的部署有多达10M记录）作为磁盘空间这些天来很便宜。

编辑：根据问题作者的评论添加了一些解释。

如果源数据结构发生变化，需要重新索引所有记录，我们的方法是推出新代码，确保所有新数据都正确（从此刻开始基本形成正确的Lucene Document）。然后我们可以通过提供相关的期间范围来批量重新索引（手动或手动）。这在某种程度上也适用于Lucene版本更改。

Answer 2

为什么COUNT（*）是性能杀手？ MAX（id）怎么样？我认为索引会提供这些查询所需的信息。您的主键上有索引，对吗？

Answer 3

我实际上只是弄明白了 - 我可以使用IDENT_CURRENT（table_name）来获取最后生成的id，并使用它而不是MAX（）或Count（） - 这个方法应该吹掉另外两个：）

将大型SQL Server数据库重新索引到Lucene

3 个答案: