指数线性增长-性能下降。

4
我们有4个分片,每个分片都有14GB的索引。 每个分片都有一个主节点和3个从节点(每个从节点配备32GB RAM)。
我们预计在不久的将来索引大小会增长一倍或三倍。 因此,我们考虑将我们的索引合并为28GB的索引,以便每个分片具有28GB的索引,并将每个从节点的RAM增加到48GB。
我们在本地进行了这些更改,并通过向具有14GB和28GB索引的每个服务器发送相同的10K实际查询来测试服务器,我们发现
  1. 对于具有14GB索引(48GB RAM)的服务器:搜索时间为480ms,索引命中数:3.8G

  2. 对于具有28GB索引(48GB RAM)的服务器:搜索时间为900ms,索引命中数:7.2G

所以我们看到,把整个索引放进内存中无法在搜索时间方面保持性能表现。当索引大小增加一倍时,搜索时间呈线性上升。
我们考虑只保留4个分片配置,但现在似乎必须向每个分片添加另一个分片或另一个从节点。
是否有其他方法可以配置我们的服务器,使得即使索引大小增加一倍或三倍,性能也不受影响?

1
你给JVM分配了多少内存?如果你给JVM分配了超过20G的内存,这意味着第一次测试时索引完全在操作系统缓存中,但第二次测试时不是,而将所有索引放入缓存中在性能方面会有很大的差异... - jpountz
1
当索引大小增长时,性能下降是正常的,但由于Zipf定律,我希望它是次线性的,所以你的结果对我来说有点令人惊讶。 - jpountz
1个回答

8

我不想说这取决于情况,但是...确实取决于情况。

每个索引的总大小为14GB,这对SOLR基本上没有什么意义。要真正了解性能,索引的唯一性是什么?如果一个14GB的索引中只有“cat”一词,那么它会非常快。

此外,您确认需要以下功能吗?禁用它们可以大幅提高性能:

模式

存储字段

您需要存储的字段吗?删除此内容可大大提高性能(您可以安全地拥有完全没有任何存储字段的整个索引,并且完全依靠Solr中的聚合、透视和其他功能来驱动UX)。

omitNorms

在某些情况下,您可以将此标志设置为false以减少内存并提高性能。

omitTermFreqAndPositions

可以关闭,总体减少内存并提高性能。

系统

优化核心/索引(段数)

当处理较大的索引大小时,索引优化非常重要。确保每个核心都被优化,并且在查看核心时,它应该显示段计数= 1。我发现随着索引大小的增加,这起着更重要的作用(这涉及到操作系统级文件缓存以及事实上读取一个大文件比读取多个小文件更容易)是的,那确实是171万+个文档。

术语索引间隔/频率

如果您有包含非常唯一值(例如GUID / UUID或一般唯一标识符)的字段或多个字段,则可能需要配置术语索引间隔(默认情况下为256)。通常,TIF越低,需要的内存就越多,TIF越高,需要的内存就越少,但磁盘寻道次数可能更多。

分配过多的RAM

Solr在进行聚合时最好在操作系统级磁盘缓存和使用的RAM之间有很好的平衡,您会惊讶地发现通过调整降低所需的RAM使用量并释放磁盘资源可以获得更好的性能。


如果您支持高亮显示,那么存储字段是必需的,这是任何搜索的重要组成部分。 - Ethan

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接