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