本文從兩個方面對ElasticSearch和Solr進行對比,從關係型數據庫中的導入速度和模糊查詢的速度。
單機對比
1. Solr 發佈了4.0-alpha,試了一下,發現需要自己修改schema,好處是它自帶一個data importer。在自己的計算機上測試了一下,導入的性能大概是:14分鐘導入 3092730 條記錄,約合 3682條/秒。
2. 3百萬條記錄的情況下,模糊查詢和排序基本都在1秒內返回
3. 剛纔的測試,是每個field單獨存儲,現在修改了一下配置文件,增加了一個copyField,所有的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的OOM錯誤,是一個尚未解決的issue: https://issues.apache.org/jira/browse/SOLR-3658
http://www.myexception.cn/open-source/731001.html