Solr 建索引的速度一直不太令人满意，自己根据网上的一些资料的翻译和自己的体会总结这篇文章。
1.关于内存
1.1 堆外内存重要性
内存对Solr来说非常重要，主要是利用Java堆外内存保存索引文件。
Solr默认利用MMapDirectory来加载索引文件到磁盘缓存，然后把它映射到Solr的进程虚拟内存。所以再次强调下，Java的堆外内存对Solr很重要。
Solr需要内存保存不同的东西：
1、Java堆内存。
2、那些“空闲”的为磁盘做缓存的内存。
索引的更新，Solr依赖快速的批量的随机读写，对查询来说，快速的随机读写是不可缺少的，所以保存大容量的磁盘缓存是重要的。当然Solr的索引如果可以保存在SSD盘上，对性能提高有很大帮助。
1.2 多大堆内存更合适
多大的堆内存对Solr来说合适那，其实没有统一的标准，可以通过查看Solr的GC日志来进行合适设置，比如可以首次设置为2G，如果设置的内存过大，将增大GC的时间，所以这个必须实践来调整。
2.关于Schema
Schema设计对Solr来说非常重要，主要涉及几个方面。
2.1 Indexed字段
Indexed的字段会在几个方面产生影响
1、索引时候内存的使用。
2、段合并时间。
3、优化索引时间。
4、索引的大小。
可以通过 omitNorms="true" 减少点这些影响。
2.2 Stored字段
搜索查询结果中的存储字段会是个重大的费用， 这个成本主要受到每个文档存储的字节数的影响 - 更高的字节计数，文档将分散在磁盘上的稀疏，更多的I / O检索字段（通常这是在存储大字段 ，像文档的整个内容）。
考虑在solr之外存储大 字段，如果你倾向于这么做，可以考虑压缩字段，这增加了存储和检索字段的CPU成本，但降低了I / O负担和CPU使用率。
如果你不总是使用所有存储的字段，那么启用延迟字段加载可能是一个巨大的福音，特别是如果使用压缩字段。
3.配置注意事项
mergeFactor
mergeFactor粗略地确定段的数量。mergeFactor值告诉Lucene在将它们合并到单个段之前要构建多少相等大小的段。 它可以被认为是数字系统的基础。
例如，如果将mergeFactor设置为10，则将为添加到索引的每1000（或maxBufferedDocs）个文档在磁盘上创建一个新段。 当添加大小为1000的第10个分段时，所有10个分段将合并为大小为10,000的单个分段。 当添加了10个大小为10,000的这样的段时，它们将被合并成包含100,000个文档的单个段，等等。 因此，在任何时候，在每个索引大小中将不超过9个段。
这些值在solrConfig.xml中的主索引部分设置。
mergeFactor 设置取舍
高的mergeFactor值（比如25）：
Pro：通常提高索引速度。
Con：较不频繁的合并，导致收集更多的索引文件，可能会减慢搜索。
低的mergeFactor值（比如2）：
Pro：索引文件数量较少，加快了搜索速度。
Can：更多的段合并减慢索引。
HashDocSet设置建议
hashDocSet是在solrconfig.xml中指定的优化，它在集合中的项数小于maxSize时启用过滤器（docSets）的int哈希表示。 对于较小的集合，此表示更高的内存效率，更高效的迭代，以及更快的交叉。（不懂？？）
hashDocSet最大大小应基于集合中文档数量的主要原因 - 文档数量越大，hashDocSet最大大小越大。 您将必须做一些尝试和错误，以达到最佳的数字：
1.计算要存储总量的*0.005
2.尝试在该值的任一“侧”的值以达到最佳查询时间。
3.当查询时间似乎处于高位时，性能在较高的数字和较低的数之间没有显示出很大的差别，使用较高的数字。
autoWarm缓存数量设置
当新的搜索器被打开时，其高速缓存可以利用来自旧搜索器中的高速缓存的高速缓存的对象来预填充或“自动加热”。 autowarmCount是将被复制到新搜索器的缓存项目的数量。 您可能希望将autowarmCount设置为自动唤醒所需的时间。 你必须考虑权衡 - 时间自动唤醒与你想要缓存的热度（即autowarmCount）。 solrconfig.xml中的缓存设置了autowarm参数。
缓存命中率
监视Solr的管理员的缓存统计信息！ 提高Solr的缓存大小通常是提高性能的最佳方法，尤其是如果您注意到特定缓存类型的许多逐出。 要特别注意filterCache，这也是Solr内部使用的facetting。 另请参阅SolrCaching和此常见问题条目。
排序字段的显式加温
如果您进行大量基于字段的排序，则有利的是向solrconfig中的“newSearcher”和“firstSearcher”事件侦听器添加显式加温查询，对这些字段排序，因此在执行任何查询之前填充FieldCache 您的用户。
4.优化注意事项
您可能想在某些情况下优化索引 - 即：如果您构建索引一次，然后从不修改它。
如果你有一个快速变化的索引，而不是优化，你可能只是想使用一个较低的合并因子。 优化是非常昂贵的，如果指数不断变化，轻微的性能提升不会持续很长时间。 这种折衷通常不值得为非静态索引。
在主从设置中，有时您可能还想在主设备上进行优化，以便从单个段索引服务。 这将大大增加复制索引的时间，所以这通常是不可取的。
更新和提交频率折衷
如果从服务器太频繁地收到新集合，他们的表现将受到影响。 为了避免这种类型的退化，你必须了解从属如何收到集合更新，以便你可以知道如何最好地调整相关的参数（提交，snappullers和自动温度/自动计数的数量/频率），使新的集合不 从服务器上安装太频繁。
1.每次客户端运行提交时都会收集集合的快照，或者根据在主服务器上是否使用postCommit或post Optimize挂钩来运行优化。
2.在克隆的基础上运行的从服务器上的快照提取器检查主服务器的新快照。 如果snappullers找到一个新的集合版本，奴隶把它下拉并snapinstall它。
3.每次打开一个新的索引搜索器时，缓存的一些自动加热发生在Solr对这个集合的版本进行查询之前。 查询具有加热的缓存的单独查询延迟是至关重要的。
三个相关参数：
1.快照的数量/频率完全取决于索引客户端。 因此，集合的版本数由客户端的活动确定。
2.snappullers是cron'd。 他们可以每秒运行一次，每天一次，或者之间的任何事情。 当它们运行时，它们将仅检索他们没有的最近的集合。
3.在solrconfig.xml中为每个缓存配置缓存自动升级。
如果您希望频繁添加新集合，以使最近的更改显示为“在线”，则必须同时具有频繁提交/快照和频繁snappull。 最常见的情况是，您可以分配索引更改并保持良好的性能，大概在1到5分钟的范围内，这取决于您对缓存的依赖性，查询时间是否良好，以及自动重新启动这些缓存所需的时间。
缓存自动温度对性能至关重要。 一方面，新的缓存版本必须填充足够的条目，以便在系统切换到集合的新版本之后，从缓存提供后续查询。 另一方面，自动加热（填充）新集合可能需要很多时间，特别是因为它只使用一个线程和一个CPU。 如果您的设置太频繁地关闭了快照安装程序，则Solr从设备可能处于将查询切换到一个（旧的）集合的不期望的状态，并且在加热新集合时，可以捕获第二个“新” 变暖！
如果我们试图解决这种情况，我们必须使第一个“新”集合无效，以便使用第二个集合，然后当“第三个”新集合被捕获和加热时，我们必须使“第二个” “新的收藏，等等广告无限。 一个完全温暖的集合永远不会完全中断之前，它被中止。 这可以通过适当调整的配置来防止，因此新集合不会被太快地安装。
