① solrcloud jetty与tomcat哪个性能高

Jetty可以同时处理大量连接而且可以长时间保持连接，适合于web聊天应用等等。
版Jetty的架构简单，因此作为权服务器，Jetty可以按需加载组件，减少不需要的组件，减少了服务器内存开销，从而提高服务器性能。
Jetty默认采用NIO结束在处理I/O请求上更占优势，在处理静态资源时，性能较高
Tomcat适合处理少数非常繁忙的链接，也就是说链接生命周期短的话，Tomcat的总体性能更高。
Tomcat默认采用BIO处理I/O请求，在处理静态资源时，性能较差。

② 怎么提高solr搜索引擎的搜索效率

做好你的站内优化和你的站外优化，这两个弄好啦，搜索排名自然提升了

③ solr存在哪些问题

最近搭建一个全文检索平台。最初考虑只采用lucene，然后自己写索引构建程序、检索框架等，类似osc @红薯 的方案，以前也做过比较熟悉。但有两个问题，1.比较复杂，工作量和维护量都比较大。2. 检索会有一定的延时。
看了看Solr决定采用solr，可以节省很大一部分开发时间。但有几个问题想请教下 osc 里的全文检索高手，希望大家不吝赐教：
1.第一种方案，solr配置数据库，自动处理建索引。这样会不会延时很大，无法做到实时检索看
2.第二种方案，通过solrj客户端在应用端 处理建索引问题，比如在发布一篇文章的时候，通过http 提交到solr 服务端上同时建索引，这样能不能达到实时检索看而且同时这个时候 应用端也会通过 http 检索 solr， 建索引检索同时进行，这样访问量大的时候会不会导致 内存泄露、索引文件磁盘I/O负载不了的问题看
有经验的同学能不能讨论下?那种方案较好点，对实时性要求高点。或者配置上怎么优化看
当然这个项目是企业内部应用，访问量不会太大，服务器资源有限，所以无法用到solr的分布式特性，比如索引复制、多核来解决这些问题。而且由于可能会部署在 windows下，排除了以前做过的sphinx、nlpbamboo 基于Postgresql数据库的方案。

④ 淘宝和京东的搜索是用solr实现的么

居然刷到一个一周前的问题……
不是。不清楚京东用的啥。
淘宝用的是自己优化的mysql分布式集群实现的。

⑤ Solr 查询速度优化

优化数据访问
查询性能低下的最基本的原因是访问的数据太多，对于低效的查询，可以从下面两个步骤来分析：
（1）确认应用程序是否在检索大量超过需要的行，这通常意味着访问了太多的行，但有时候也有可能访问了太多的列。
（2）确认MySQL服务器层是否在分析大量超过需要的数据行。
一些典型的情况：
（1） 查询不需要的记录。这样的查询上应该加上LIMIT
（2） 多表关联时返回了全部列。应该只取需要的列。
（3） 总是取出全部的列：SELECT *
（4） 重复查询需要的数据。较好的解决方案是使用数据缓存。
确认MySQL只返回了需要的数据之后，接下来应该看看查询是否扫描了过多的数据，最简单的衡量查询开销的三个指标如下：
（1）响应时间
（2）扫描的行数
（3）返回的行数
响应时间=排队时间+服务时间
理性情况下的扫描的行数和返回的行数应该是相等的。
访问类型：MySQL有好几种方式可以查找并返回一行结果，Explain的type列反应了访问类型，访问类型有全表扫描、索引扫描、范围扫描、唯一索引查询、常数引用等，这些速度从慢到块，扫描的行数从大到小。Using Where表示MySQL将通过Where条件来筛选存储引擎返回的数据。MySQL能够以三种方式应用Where条件，从好到坏依次是：
（1）、在索引中使用Where来过滤数据，这是在存储引擎层实现的
（2）、使用了索引覆盖扫描（Extra列中Using index）来返回记录，直接从索引中过滤不需要的记录并返回命中的结果，这是在MySQL服务器层实现的，但是无需回表查询记录。
（3）、从数据表中返回数据，然后过滤不满足条件的记录，这是在MySQL服务器层实现的，MySQL需要先从数据库中读取记录然后过滤。
如果一个查询需要扫描大量的数据但是只返回少数的行，那么通常可以尝试下面的技巧去优化：
（1）、使用索引覆盖扫描，即把所有需要的列都放到索引中，这样存储引擎无需回表获取对应行就可以返回结果了。
（2）、该表库表结构，使用单独的汇总表
（3）、重写整个复杂的查询，让MySQL优化器能够以最优化的方式执行整个查询。
重构查询的方式
确定一个复杂查询还是多个简单查询更加有效
切分查询：
将一个完整的查询分散到多次小查询中（例如通过Limit）
查询执行的基础
MySQL执行查询的过程：
（1）客户端发送一条查询给服务器
（2）服务器先检查查询缓存，如果命中了缓存，则立即返回存储在缓存中的结果，否则进入下一个阶段。
（3）服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划
（4）将结果返回给客户端。

⑥ javaweb中redis和solr哪个性能高，感觉这两个留一个就可以了

这2个不是一类的东西啊。主要看你的需求。

  1. redis是非关系型，在内存中以Key-Value形式存储的数据库。特点是速度非常非常快。

  2. solr是一个搜索引擎。一般用来作为网站内的搜索功能。

⑦ elasticsearch，solr对比各自有哪些优缺点

从两个方面对ElasticSearch和Solr进行对比，从关系型数据库中的导入速度和模糊查询的速度。

单机对比

1. Solr 发布了4.0-alpha，试了一下，发现需要自己修改schema，好处是它自带一个data importer。在自己的计算机上测试了一下，导入的性能大概是：14分钟导入 3092730 条记录，约合 3682条/秒。

2. 3百万条记录的情况下，模糊查询和排序基本都在1秒内返回

3. 刚才的测试，是每个field单独存储，现在修改了一下配置文件，增加了一个Field，所有的field都拷贝一份到text这个field里面去，导入的性能大概是：19分钟导入了3092730 条记录，约合 2713条/秒

4. 3百万条记录的情况下，针对text的模糊查询基本在1秒内返回，但是针对所有记录的排序，大概要2~3秒

5. 使用 elasticsearch 0.19.8，缺省配置，用单任务导入，导入性能是：20分钟导入了3092730 条记录，约合2577条/秒

6. 3百万条记录的情况下，查询基本上在1秒内返回，但是模糊查询比较慢，第一次要10秒，后来大概要1~3秒。加上排序大概需要5秒，整体排序基本100ms

查询及排序的指令：

{

"query": {

"query_string": {

"query": "*999*"

}

},

"sort": [

{

"TIME_UP": {

"order": "asc"

}

}

]

}

7. Es0.19.8，用两个任务导入，导入性能是：13分钟导入了3092730 条记录，约合3965条/秒

8. Solr全部建好索引后，占用磁盘空间是1.2G，es占用磁盘空间是4G

单机对比2

在一台Intel i7，32G内存的机器上，重新跑这两个的对比。不过有个重大的区别在于，Solr是在这台性能很好的机器上跑，而es的导入进程则是在一台Intel 四核 2.5G，4G内存的机器上跑的，也许会有性能的差异。ES版本0.19.8，Solr版本4.0-ALPHA。

1. Solr的导入性能：3400万条记录，用时62分钟，平均9140条/秒，占用空间12.75G

2. 使用 *999* 这样的模糊查询，3秒以内返回，稍长一点的查询条件 *00100014*，也是2~3秒返回

3. Es的导入性能（设置Xmx为10G）：3400万条记录，用时40分钟，平均14167条/秒，占用空间33.26G，客户端采用4个并发。

4. 使用 *999* 这样的模糊查询，9秒返回，稍长一点的查询条件 *00100014*，11.8秒返回

5. 如果不是针对所有字段查询，而是针对某个特定字段，比如 SAM_CODE: *00100014*，那么也是1秒以内返回。

6. 结论：es的查询效率也可以很高，只是我们还不会用。

7. 结论2：es有个设置是把所有字段放一块的那个，缺省是放一起，但是不知道为什么没起到应有的作用。

备注：

1. Solr第一次的那个内存使用的是缺省设置，这次改为10G，结果导入性能反而变差了，400万条记录，用了8分钟，平均8333条/秒，不知道为什么。

2. 改回缺省的内存配置，导入速度仍然慢。

3. 重启Linux，用10G的内存配置，再导入，5030万条记录，用时92分，约9112条/秒，说明导入速度和内存配置没有大差别

4. 在10G配置的情况下，检索速度也差别不大。

5. 为了搞清楚lucene4.0和solr4.0的进步有多大，下载了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起来进行测试，导入性能为：3400万条记录，用时55分钟，约10303条/秒，占用空间13.85G。查询性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的结果（5000万结果当中，*999*第一次2.6s，*00100014*第一次2.5s）来说，慢了很多，与es的性能差不多，因此，也许lucene4.0真的对性能有大幅提升？

集群对比：

采用4台同样配置（Intel i7，32G内存）的Centos 6.3组成的集群，进行对比。

1. 首先是es，很方便的就组成了一个Cluster，等上一个3400万条的Index全部均衡负载之后进行测试，导入到另外一个Index当中。

2. 导入性能：8500万条记录，用时72分钟，约为19676条/秒。在前5千万条记录导入时的速度在2万/条以上，初始的速度在2.2万/条。占用空间78.6G（由于有冗余，实际占用空间为157.2G）

3. 查询性能：

*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒

*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒

SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s

SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s

4. Solr4.0-ALPHA，SolrCloud的配置还算简单，启动一个ZooKeeper，然后其他三台机器访问这个地址，就可以组成一个Cloud：

机器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &

其他机器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &

但是在执行 data import 的时候，频繁出现 OutOfMemoryError: unable to create new native thread。查了很多资料，把Linux的ulimit当中的nproc改成10240，把Xss改成256K，都解决不了问题。暂时没有办法进行。

结论

1. 导入性能，es更强

2. 查询性能，solr 4.0最好，es与solr 3.6持平，可以乐观的认为，等es采用了lucene4之后，性能会有质的提升

3. Es采用SAM_CODE这样的查询性能很好，但是用_all性能就很差，而且差别非常大，因此，个人认为在目前的es情况下，仍然有性能提升的空间，只是现在还没找到方法。

⑧ 如何大幅优化solr的查询性能

提升软件性能，通常喜欢去调整各种启动参数，这没有多大意义，小伎俩。 性能优化要从架构和策略入手，才有可能得到较大的收益 Solr的查询是基于Field的，以Field为基本单元，例如一个文章站要索引 classArticle { String title; String content; String tags; } 查询参数: 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中使用 Field 上述的Article Schema可以写成如下这种格式，就能达到效果 <fieldname="title"type="text_general"indexed="true"stored="true"/> <fieldname="content"type="text_general"indexed="true"stored="true"/> <fieldname="tags"type="text_general"indexed="true"stored="true"/> <fieldname="text"type="text_general"indexed="true"stored="false"multiValued="true"/> <Fieldsource="title"dest="text"/> <Fieldsource="content"dest="text"/> <Fieldsource="tags"dest="text"/> 这种schema定义方式，既可以对单个field指定查询权重，也可以在泛查询的时候提升性能，同时生成索引数据的时候不需要多写任何代码