java - 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 编码长于最大长度 32766 问题是由于已设置的标志引起的。这导致整个字符串根本无法被分析，因此 ElasticSearch 将其视为一个术语。 Apache Lucene(ElasticSearch 下的引擎)的最大术语长度为 32766。如果您给出的单个术语比这个长，它将抛出此错误。

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

其他体验

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

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

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

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

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

希望这能有所帮助。