ElasticSearch 自定义分析器大字符串字段

Question

我正忙于创建文档搜索。主要思想是读取文档（使用 Tika），然后将其添加到索引中以创建全文文档搜索。

很多文档都很大，每当我尝试索引它们时都会出错：

IllegalArgumentException[Document contains at least one immense term in field\"<field>\" (whose UTF8 encoding is larger than the max length 32766), 

与此线程相同：UTF8 encoding is longer than the max length 32766

除了限制传递给 ElasticSearch 的实际字符串之外，另一个建议是为该特定字段创建自定义分析器。因此，我试图创建一个这样的分析器，但由于我对 ES 很陌生，我不太清楚如何。可悲的是，文档对此没有多大帮助。

我不需要特定的分析器（除非您有一个很好的用于大字符串的分析器），但只需要一些关于如何将此自定义分析器分配给特定字段的帮助。

Answer 1

这已经是很久以前的事了，所以我不记得所有内容了，但是就这样吧。

我遇到的UTF8 encoding is longer than the max length 32766 问题是由设置的标志引起的。这导致整个字符串根本不被分析，因此 ElasticSearch 将其视为一个单独的术语。 Apache Lucene（ElasticSearch 下的引擎）将 32766 值作为最大术语长度。如果你给一个任期长于这个，它会抛出这个错误。

编写自定义分析绝对可以解决问题，但是使用默认分析器句柄对于我的用例来说已经足够了。通过在我们自己的代码中设置某个标志 (sort = false)，我能够为我发送的字符串重新打开默认分析器。

其他体验

您会遇到错误的 PDF。很多。这将导致 Apache Tika 出现问题，例如 Zip bomb 错误。这些通常是由 PDF 中深度嵌套的 XML 引起的。

另外，不要低估使用 OCR 创建的 PDF 的数量。尽管 PDF 通常看起来不错，但实际文本可能完全是荒谬的。一个快速的检查方法是，将 PDF 中的文本复制到记事本中，然后检查它是否正确。

为此准备足够的 RAM。某些单个文档有时可能会使程序的 RAM 使用量增加 1-2 GB。其中有多少实际在使用，而不仅仅是等待GC'd，我不知道。

选择您真正想要解析的文件。例如，解析 XML 文件可能没有任何有用的理由。

扫描大量文档需要很长时间。最好将过程拆分为更新和索引。这样，您可以通过检查文档是否已被索引来限制每天扫描的文档数量。如果没有，请对其进行索引。如果它已更改，请更新它。我发现在我们的案例中，扫描大约 80000 个文档需要大约 4 个小时。这是使用单个 CPU 和大约 2 GB RAM 完成的。

希望这能有所帮助。