solr查詢結果過濾
⑴ 從solr庫中查詢，返回的response是什麼格式數據
點擊net
work中的一個請求在右側的
preview中會自動的將格式以json的折疊形式呈現，便於查看
再看看別人怎麼說的。
⑵ SolrCloud怎麼模糊查詢
從兩個方面對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做搜索的時候，用"我們"來搜有結果，用"我"搜就沒有，請教大神什麼原因，怎麼改正
首先搜索引擎有來兩個階段：創建源索引，和搜索
舉個例子：1.『我們搞基吧』被分詞為『我們，搞基，吧』被存儲到索引里
2.『我們搞基吧』被分詞為『我，們，搞基，吧』被存儲到索引里
那麼在搜索的時候，你搜『我們』的時候，只有第一種分詞的方式才會被搜到；如果你搜『我』的時候，只有第二種分詞的方式才會被搜索到；如果你搜『搞基』的時候，兩種分詞方式的結果才都會被搜索到。
所以你搜『我們』有結果，是因為你建索引的時候『我們』分詞被分成了『我們』，而不是『我』『們』，你搜『我』肯定不會有結果啊，所以搜索和簡歷索引的時候要一致，或者存儲索引的分詞結果一定要包含搜索分詞的結果，當然這是理想情況，總值，原因就是搜索和索引的分詞的方式不一致導致的
⑸ solr怎麼設置才能像資料庫中的like模糊查詢
可以試試：
使用SolrQuery對象，
SolrQuery solrQuery = new SolrQuery();
//組裝查詢條件
solrQuery.setQuery("*:*");
String key = "java3";
solrQuery.addFilterQuery("content:" + "*"+key+"*" ）;試試吧
⑹ solr 搜索數據不精準，有么辦法使其精準
如何查詢SOLR為空欄位？ 資料庫database lucene solr 我有一個大的Solr索引，我注意到欄位沒有被正確更新（該指數是動態的）。 這就造成了有一個空的「ID」欄位的欄位。 我嘗試了這些疑問，但他們沒有工作： id:'' id:NULL id:null id:"" id: id:
⑺ 使用solr查詢，庫中存在，但是查詢結果沒有
看一下給的條件全形半形大小寫有沒有差錯