我正忙于创建文档搜索。主要思想是读取文档（使用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的实际String之外，另一个建议是为该特定字段创建自定义分析器。因此我试图创建一个这样的分析器，但由于我是ES的新手，我无法弄清楚如何。遗憾的是，文档对此没有多大帮助。
我不需要特定的分析器（除非你有一个很好的大字符串），但只有一些帮助如何将这个自定义分析器分配到特定的字段。
答案 0 :(得分：0)
现在已经有一段时间了，所以我不记得所有事情，但是这里有。
我遇到的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，我不知道。
选择您实际要解析的文件。例如，解析XML文件可能没有任何用处。
扫描大量文档需要很长时间。最好将流程拆分为更新和索引。这样，您可以通过检查文档是否已编入索引来限制每天扫描的文档数量。如果没有，请将其编入索引。如果已更改，请更新它。我发现在我们的案例中，大约需要4个小时来扫描~80000个文档。这是通过一个CPU和大约2 GB RAM完成的。
希望这有点帮助。