我们有 4 个分片，每个分片都有 14GB 索引每个分片有一个主分片和 3 个从属分片（每个分片都有 32GB 内存）
我们预计指数规模将在不久的将来增长一倍或三倍。所以我们考虑将我们的索引合并为 28GB 索引，这样每个分片就有 28GB 的索引，并将每个从属服务器上的 RAM 增加到 48GB。
我们在本地进行了更改，并通过向每个具有 14GB 和 28GB 索引的服务器发送相同的 10K 实际查询来测试服务器，我们发现
对于具有 14GB 索引（48GB RAM）的服务器：搜索时间为 480 毫秒，索引命中数：3.8G
对于具有 28GB 索引（48GB RAM）的服务器：搜索时间为 900 毫秒，索引命中数：7.2G
所以我们看到，在 RAM 中拥有整个索引并不能帮助维持搜索时间方面的性能。当索引大小翻倍时，搜索时间线性增加一倍。
我们原本考虑只保留 4 个分片配置，但看起来现在我们必须为每个分片添加另一个分片或另一个从属。
有没有其他方法可以配置我们的服务器，以便即使索引大小增加一倍或三倍，性能也不会受到影响？
我不想说这取决于，但它...取决于。
每个索引的总大小为 14GB，这对 SOLR 基本上没有什么意义。要真正了解性能，索引术语的独特性是什么？一次又一次地包含一个单词“cat”的 14GB 数据索引将非常快。
您还确认您需要以下功能，禁用它们可以大大提高性能：
您需要存储字段吗？删除它可以大大提高性能（您可以安全地拥有一个没有任何存储字段的整个索引，并完全依赖 solr 中的 facets、pivot 和其他功能来驱动 UX）。
在某些情况下，您可以将此标志设置为 false 以总体上减少内存并提高性能。
可以关闭，一般会减少内存并提高性能。
在处理较大的索引大小时，索引优化很重要。确保每个核心都经过优化，并且当您查看核心时，它会显示段数 = 1。我发现，当您增加索引大小时，这会发挥更重要的作用（这会影响操作系统级别的文件缓存和事实读取一个大文件比读取多个小文件更容易）是的，确实有 1.71 亿多个文档。
如果您有一个或多个字段包含非常独特的值（例如 GUID/UUID 或通常的唯一 ID），则可能需要配置术语索引间隔（默认为 256）。通常，TIF 越低，您需要的内存越多，TIF 越高，您需要的内存越少，但您可能拥有的磁盘寻道次数越多。
Solr 最好在 OS 级别磁盘缓存和分面时使用的 RAM 之间进行良好分割，您会惊讶地发现，您实际上可以通过调整其他参数来获得更好的性能，从而降低所需的 ram 使用率并释放磁盘资源。