亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

ElasticSearch 與 Solr 的對比測試

系統 2169 0

ElasticSearch 與 Solr 的對比測試

本文從兩個方面對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情況下,仍然有性能提升的空間,只是現在還沒找到方法。

ElasticSearch 與 Solr 的對比測試


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 亚洲一片 | 欧美视频在线观在线看 | 成人免费a视频 | 成年女人午夜毛片免费看 | 国产真实强j视频在线观看 国产真实偷乱视频在线观看 | 91精品国产综合久久久久久 | 日韩成| 黄色色片| 色爱区综合激月婷婷激情五月 | 国内欧美一区二区三区 | 免费a视频在线观看 | 日本护士一级毛片在线播放 | 超清中文乱码字幕在线观看 | 亚洲综合视频 | 狠狠操天天操 | 日本老年人精品久久中文字幕 | 亚洲精品一区二区三区婷婷 | 男女性高清爱潮视频免费观看 | 老司机精品99在线播放 | 四虎影视永久在线精品免费播放 | 亚洲精品99久久久久久 | 国产探花视频在线观看 | 日本在线三级 | 中文字暮文字暮 | 亚洲欧美日韩激情在线观看 | 激情免费网站 | 九九精品视频在线免费观看 | 精品日产一区二区 | 欧美日韩高清一区二区三区 | 久久精品国产亚洲高清 | 国产激情在线 | 日日添日日摸 | 夜夜爽www| 国产三级不卡 | 欧美特黄a级高清免费大片 欧美特黄a级猛片a级 | 天天看天天爽 | 老外黑人欧美一级毛片 | 97在线看| 久草视频免费在线播放 | 曰曰啪天天拍视频在线 | 日本夜夜夜 |