我正在使用Solr处理大量文档的搜索，我开始使用facet和过滤器进行复杂查询时出现性能问题。 这是用于获取某些数据的solr查询：
solr完整请求：http://host/solr/discovery/select?q= ＆amp; fq = domain％3Acom + OR + host％3Acom + OR + public_suffix％3Acom＆amp; fq = crawl_date％3A％5B2000-01-01T00％3A00％3A00Z + TO + 2000-12-31T23％3A59％3A59Z％5D＆安培; FQ =％7B％21tag％3Dcrawl_year％7Dcrawl_year％3A％282000％29＆安培; FQ =％7B％21tag％3Dpublic_suffix％7Dpublic_suffix％3A％28com％29＆安培;开始= 0＆安培;行数= 10安培;排序=得分+降序＆安培; FL = ％2Cscore＆安培; HL =真安培; hl.fragsize = 200安培; hl.simple.pre =％3Cstrong％3E＆安培; hl.simple.post =％ 3C％2Fstrong％3E＆安培; hl.snippets = 10安培; hl.fl =含量＆安培; hl.mergeContiguous =假安培; hl.maxAnalyzedChars = 100000＆安培; hl.usePhraseHighlighter =真安培;小面=真安培; facet.mincount = 1＆安培; facet.limit = 11安培; facet.field =％7B％21EX％3Dcrawl_year％7Dcrawl_year＆安培; facet.field =％7B％21EX％3Ddomain％7Ddomain＆安培; facet.field =％7B％21EX％3Dpublic_suffix％7Dpublic_suffix＆安培; facet.field =％7B％21EX％ 3Dcontent_language％7Dcontent_language＆安培; facet.field =％7B％21EX％3Dcontent_type_norm％7Dcontent_type_norm＆安培;碎片= shard1"
当这个查询在localy中使用大约50000个文档时，大约需要10秒钟，但是当我在拥有2亿个文档的主机上尝试它时，大约需要4分钟。我天生就知道它会在主机上花费更长的时间，但我想知道是否有人有同样的问题并且能够获得更快的结果。知道我正在使用两个碎片。
等待您的回复。
答案 0 :(得分：0)
您一次做了许多复杂的事情：日期范围，突出显示，分面和分布式搜索。 （非solrcloud，看起来像）
仍然，50k-doc索引的10秒对我来说似乎很慢。尝试有选择地删除搜索的各个方面，看看是否可以隔离哪个部分正在减慢速度，然后关注它。我希望你能找到速度更快的简单查询，即使它们与很多文档相匹配。
无论哪种方式，请查看https://wiki.apache.org/solr/SolrPerformanceProblems#RAM
那里有很多有用的提示，但＃1性能问题通常没有足够的内存，特别是对于大型索引。
答案 1 :(得分：0)
检查solr上有多少段 随着查询响应越多，段的数量越多 如果你没有在你的solrConfig.xml中设置合并因子，那么你可能会有近40个段，这对于查询响应时间是不利的 相应地设置合并因子 如果没有要添加新文件，请将其设置为2
合并因子 mergeFactor粗略地确定了段的数量。 mergeFactor值告诉Lucene在将它们合并到单个段之前要构建多少个相同大小的段。它可以被认为是数字系统的基础。 例如，如果将mergeFactor设置为10，则将在磁盘上为添加到索引的每1000个（或maxBufferedDocs）文档创建一个新段。当添加第1000个大小为1000的段时，所有10个段将合并为一个大小为10,000的段。当添加10个这样大小为10,000的段时，它们将合并为包含100,000个文档的单个段，依此类推。因此，在任何时候，每个索引大小不会超过9个段。 这些值在solrconfig.xml的 mainIndex 部分中设置（忽略indexDefaults部分）： mergeFactor权衡 高价值合并因子（例如25）： Pro：通常可以提高索引速度 Con：不太频繁的合并，导致集合中包含更多索引文件，这可能会减慢搜索速度 低值合并因子（例如，2）： Pro：索引文件数量较少，可加快搜索速度。 Con：更多细分合并减慢了索引速度。