如何大幅优化solr的查询性能(转)

2019-03-27 01:05|来源: 网路

提升软件性能,通常喜欢去调整各种启动参数,这没有多大意义,小伎俩。 性能优化要从架构和策略入手,才有可能得到较大的收益

Solr的查询是基于Field的,以Field为基本单元,例如一个文章站要索引

  1. classArticle
  2. {
  3.    String title;
  4.    String content;
  5.    String tags;
  6. }

查询参数: q=title:big && content:six

Solr会顺序执行两次 field查询 ,这个开销非常大。 实际例子 :50万条记录,一次在6,7个字段上检索,24 core的服务器也需要10-20ms

如果把title和content 合并,那只需要查询一次,性能可以提升50%

在生成索引xml的时候,把title和content填入同一个字段,就能达到这种效果,但是产生新的问问题

无法对title和content的查询分别指定权重了,一般来说,title的权重要高于content

Solr给出一种解决方法:在schema中使用 copyField

上述的Article Schema可以写成如下这种格式,就能达到效果

  1. <fieldname="title"type="text_general"indexed="true"stored="true"/>
  2. <fieldname="content"type="text_general"indexed="true"stored="true"/>
  3. <fieldname="tags"type="text_general"indexed="true"stored="true"/>
  4. <fieldname="text"type="text_general"indexed="true"stored="false"multiValued="true"/>
  5. <copyFieldsource="title"dest="text"/>
  6. <copyFieldsource="content"dest="text"/>
  7. <copyFieldsource="tags"dest="text"/>

这种schema定义方式,既可以对单个field指定查询权重,也可以在泛查询的时候提升性能,同时生成索引数据的时候不需要多写任何代码


转自:http://www.cnblogs.com/rainbowzc/p/3761487

相关问答

更多
  • 提升软件性能,通常喜欢去调整各种启动参数,这没有多大意义,小伎俩。 性能优化要从架构和策略入手,才有可能得到较大的收益 Solr的查询是基于Field的,以Field为基本单元,例如一个文章站要索引 classArticle { String title; String content; String tags; } 查询参数: q=title:big && content:six Solr会顺序执行两次 field查询 ,这个开销非常大。 实际例子 :50万条记录,一次在6,7个字段上检索,24 core ...
  • oracle性能优化[2024-02-25]

    参加过CUUG的Oracle性能优化网络公开课,网上应该有录制的视频,讲得不错。 网上也有很多oracle性能优化的技术文章啊,发不了链接,你百度一下oracle网络公开课就有了!
  • 像你说的,sql没有什么优化的可能了。 只能从数据库技术上面来优化,使用并行、提升io吞吐量、启用压缩、使用分区将表分片存放在不同硬盘上(如果没有使用raid的话)。 有些可疑,你可以进一步判断一下,是数据库这边查询比较慢,还是应用程序层处理起来比较慢。
  • 1、查列表时,尽量把要查的字段查出,select id,name from 这样比select * from 效率高点。 2、一个页面有很多List要查,而这些List又属于同一个表,只是条件不同,可以用or将所有的条件放在一个语句中,查出List,再用if根据条件判断封装不同List,这将很多个数据库链接转化成了一个数据库链接,hibernate只要创建一个sessionfactory,效率比同时查多个语句快。 3、尽量把需要的字段放在同一张表上,这和第二条类似。
  • 在WHERE子句中使用的所有列上添加索引,并使用BETWEEN...AND作为时间戳而不是DATE()函数: ALTER TABLE `behaviour` ADD INDEX `ts_IDX` (`timestamp`), ADD INDEX `hash_IDX` (`hash`); --------------------------------- ALTER TABLE `audience` ADD INDEX `hash_IDX` (`hash`); ---------------------- ...
  • 你可以试试lucene-c-boost。在C ++(通过JNI)中优化的某些Apache Lucene查询的实现,适用于从0到7.8X加速的任何地方。 请参阅https://github.com/mikemccand/lucene-c-boost 。 you may try lucene-c-boost.Optimized implementations of certain Apache Lucene queries in C++ (via JNI) for anywhere from 0 to 7.8X ...
  • 您应该尽量减少导入过程中的提交次数。 即使您在向Solr添加文档时没有定期提交,Solr也会根据solrconfig.xml自动提交设置进行自动提交: 10000 15000 false 增加maxDocs和maxTime ,看看你是否有更好的速度。 ( maxTime以毫秒为单位,因此默认设置仅为15 ...
  • 首先,我会将其重写为: SELECT payments.method, payments.amount, payments.commission FROM payments LEFT JOIN member_to_group ON payments.member_id = member_to_group.member_id LEFT JOIN member ON member.member_id = member_to_group.member_id WHERE ...
  • 似乎问题是由“hl.fl = *”引起的,这导致DefaultSolrHighlighter在找到的每个文档(在我的情况下为10 max)上迭代相对大量的字段(在我的索引中)。 这导致额外的O(n ^ 2)时间。 以下是相关的代码段: for (int i = 0; i < docs.size(); i++) { int docId = iterator.nextDoc(); Document doc = searcher.doc(docId, fset); NamedList docSumma ...
  • 时间序列数据面临的一个挑战是您最终可能会将所有数据写入单个分区,这会阻止表存储分配额外的资源来帮助您扩展。 同样,对于读取操作,您受限于潜在地将所有数据放在一个分区中,这意味着您的数据限制为2000个实体/秒 - 而如果您将数据分布到多个分区,则可以并行查询并产生更大的规模。 您是否启用了存储分析? 我会很有兴趣知道你是否受到扼杀,或者有什么其他潜在的问题可能发生。 有关详细信息,请参阅存储监视,诊断和故障排除指南。 如果你仍然无法找到你想要的信息,请发邮件给AzTableFeedback@microsof ...