Solr：文档大小莫名其妙地大
Solr: Document size inexplicably large
我在测试服务器上更新到 Solr 8.4.0（从 6.x）并重建索引（这是一个复杂的 Moodle 系统的索引，主要是很多非常小的文档）。它最初有效，但后来 运行 超出磁盘 space 所以我删除了所有内容并尝试索引数据的较小子集，但它仍然 运行 超出磁盘 space。
查看段信息图表，第一个段似乎合理：
段 _2a1u：
#文档：603,564
#删除：1
大小：5,275,671,226 字节
年龄：2020-11-25T22:10:05.023Z
来源：合并
每个文档 8,740 字节 - 有点高但还算不错。
段 _28ow：
#docs：241,082
#删除：31
大小：5,251,034,504 字节
年龄：2020-11-25T18:33:59.636Z
来源：合并
每个文档 21,781 字节
段 _2ajc：
#文档：50,159
#删除：1
大小：5,222,429,424 字节
年龄：2020-11-25T23:29:35.391Z
来源：合并
每个文档 104,117 字节！
而且情况变得更糟，看看接近尾声的小片段：
段 _2bff：
#文档：2
#删除：0
size:23,605,447 字节
年龄：2020-11-26T01:36:02.130Z
来源：flush
None 我们的搜索文档中的任何地方都会有那么多文本。
在我们的生产 Solr 6.6 服务器上，它具有类似但稍大的数据（出于隐私原因，其中一些在测试服务器中被替换为短占位符文本）5GB 左右的大段包含 180 万到 500 万文件。
有谁知道这里可能出了什么问题？我们正在使用 Solr Cell/Tika，我想知道它是否以某种方式开始存储整个文件而不仅仅是提取的文本？
事实证明，一个 10MB 的英语 PowerPoint 文件被编入索引，其中大部分是图片，整个文件中只有大约 50 个单词的文本，被编入索引（元数据已关闭）将近 50 万个术语，其中大部分是汉字。据推测，Tika 错误地提取了 PowerPoint 文件的某些二进制内容，就好像它是文本一样。
我只能通过反复试验减少索引，直到其中只有少数文档（3 个文档，但使用 13MB 磁盘 space），然后是 Luke 'Overview' 选项卡让我看到包含索引 Tika 结果的一个字段（在我的架构中称为 solr_filecontent）有 451,029 个术语。然后，点击'Show top terms'显示一堆汉字
我不确定是否有比反复试验更省力的方法来找到这个问题，例如是否有任何方法可以找到具有大量相关术语的文档。 （显然，它可能是一个非常大的 PDF 文件或合法包含那么多术语的文件，但在这种情况下，它不是。）这将很有用，因为即使我们的系统中只有几个这样的实例，它们也可以对整体索引大小贡献很大。
关于解决问题：
1 - 我可以破解一些东西来阻止它索引这个单独的文档（它在我们的测试数据中重复使用，否则我可能不会注意到）但在其他情况下可能也会出现这个问题。
2 - 我考虑过以某种方式排除条款，但我们的索引中确实有一小部分各种语言的内容，包括中文，所以即使有办法将其配置为仅使用 ASCII 文本或东西，这没用。
3 - 我的下一步是尝试不同的版本，看看同一个文件会发生什么，以防它是特定 Tika 版本中的错误。但是，我测试了一系列 Solr 版本 - 6.6.2、8.4.0、8.6.3 和 8.7.0 - 并且所有版本都出现了相同的行为。
所以我从这一切得出的结论是：
与我最初认为这与版本升级有关的假设相反，它现在实际上并不比旧 Solr 版本更糟。
为了让这个现在工作，我可能不得不做一个 hack 来阻止它索引特定的 PowerPoint 文件（这在我们的测试数据集上经常出现）。大概真实的数据集不会有太多这样的文件，否则它已经有 运行 磁盘 space 那里...
我在测试服务器上更新到 Solr 8.4.0（从 6.x）并重建索引（这是一个复杂的 Moodle 系统的索引，主要是很多非常小的文档）。它最初有效，但后来 运行 超出磁盘 space 所以我删除了所有内容并尝试索引数据的较小子集，但它仍然 运行 超出磁盘 space。
查看段信息图表，第一个段似乎合理：
段 _2a1u： #文档：603,564 #删除：1 大小：5,275,671,226 字节 年龄：2020-11-25T22:10:05.023Z 来源：合并
每个文档 8,740 字节 - 有点高但还算不错。
段 _28ow： #docs：241,082 #删除：31 大小：5,251,034,504 字节 年龄：2020-11-25T18:33:59.636Z 来源：合并
每个文档 21,781 字节
段 _2ajc： #文档：50,159 #删除：1 大小：5,222,429,424 字节 年龄：2020-11-25T23:29:35.391Z 来源：合并
每个文档 104,117 字节！
而且情况变得更糟，看看接近尾声的小片段：
段 _2bff： #文档：2 #删除：0 size:23,605,447 字节 年龄：2020-11-26T01:36:02.130Z 来源：flush
None 我们的搜索文档中的任何地方都会有那么多文本。
在我们的生产 Solr 6.6 服务器上，它具有类似但稍大的数据（出于隐私原因，其中一些在测试服务器中被替换为短占位符文本）5GB 左右的大段包含 180 万到 500 万文件。
有谁知道这里可能出了什么问题？我们正在使用 Solr Cell/Tika，我想知道它是否以某种方式开始存储整个文件而不仅仅是提取的文本？
事实证明，一个 10MB 的英语 PowerPoint 文件被编入索引，其中大部分是图片，整个文件中只有大约 50 个单词的文本，被编入索引（元数据已关闭）将近 50 万个术语，其中大部分是汉字。据推测，Tika 错误地提取了 PowerPoint 文件的某些二进制内容，就好像它是文本一样。
我只能通过反复试验减少索引，直到其中只有少数文档（3 个文档，但使用 13MB 磁盘 space），然后是 Luke 'Overview' 选项卡让我看到包含索引 Tika 结果的一个字段（在我的架构中称为 solr_filecontent）有 451,029 个术语。然后，点击'Show top terms'显示一堆汉字
我不确定是否有比反复试验更省力的方法来找到这个问题，例如是否有任何方法可以找到具有大量相关术语的文档。 （显然，它可能是一个非常大的 PDF 文件或合法包含那么多术语的文件，但在这种情况下，它不是。）这将很有用，因为即使我们的系统中只有几个这样的实例，它们也可以对整体索引大小贡献很大。
关于解决问题：
1 - 我可以破解一些东西来阻止它索引这个单独的文档（它在我们的测试数据中重复使用，否则我可能不会注意到）但在其他情况下可能也会出现这个问题。
2 - 我考虑过以某种方式排除条款，但我们的索引中确实有一小部分各种语言的内容，包括中文，所以即使有办法将其配置为仅使用 ASCII 文本或东西，这没用。
3 - 我的下一步是尝试不同的版本，看看同一个文件会发生什么，以防它是特定 Tika 版本中的错误。但是，我测试了一系列 Solr 版本 - 6.6.2、8.4.0、8.6.3 和 8.7.0 - 并且所有版本都出现了相同的行为。
所以我从这一切得出的结论是：
与我最初认为这与版本升级有关的假设相反，它现在实际上并不比旧 Solr 版本更糟。
为了让这个现在工作，我可能不得不做一个 hack 来阻止它索引特定的 PowerPoint 文件（这在我们的测试数据集上经常出现）。大概真实的数据集不会有太多这样的文件，否则它已经有 运行 磁盘 space 那里...