① 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指定查詢權重，也可以在泛查詢的時候提升性能，同時生成索引數據的時候不需要多寫任何代碼