?

單機(jī)對(duì)比

1.?Solr?發(fā)布了4.0-alpha，試了一下，發(fā)現(xiàn)需要自己修改schema，好處是它自帶一個(gè)data?importer。在自己的計(jì)算機(jī)上測(cè)試了一下，導(dǎo)入的性能大概是：14分鐘導(dǎo)入? 3092730 ? ?條記錄，約合?3682條/秒。

2.?3百萬(wàn)條記錄的情況下，模糊查詢(xún)和排序基本都在1秒內(nèi)返回

3.?剛才的測(cè)試，是每個(gè)field單獨(dú)存儲(chǔ)，現(xiàn)在修改了一下配置文件，增加了一個(gè)copyField，所有的field都拷貝一份到text這個(gè)field里面去，導(dǎo)入的性能大概是：19分鐘導(dǎo)入了 3092730 ? 條記錄，約合?2713條/秒

4.?3百萬(wàn)條記錄的情況下，針對(duì)text的模糊查詢(xún)基本在1秒內(nèi)返回，但是針對(duì)所有記錄的排序，大概要2~3秒

5.?使用?elasticsearch?0.19.8，缺省配置，用單任務(wù)導(dǎo)入，導(dǎo)入性能是：20分鐘導(dǎo)入了 3092730 ? 條記錄，約合2577條/秒

6.?3百萬(wàn)條記錄的情況下，查詢(xún)基本上在1秒內(nèi)返回，但是模糊查詢(xún)比較慢，第一次要10秒，后來(lái)大概要1~3秒。加上排序大概需要5秒，整體排序基本100ms

查詢(xún)及排序的指令：

{

??"query":?{

????"query_string":?{

??????"query":?"*999*"

????}

??},

??"sort":?[

????{

??????"TIME_UP":?{

????????"order":?"asc"

??????}

????}

??]

}

?

7.?Es0.19.8，用兩個(gè)任務(wù)導(dǎo)入，導(dǎo)入性能是：13分鐘導(dǎo)入了 3092730 ? 條記錄，約合3965條/秒

8.?Solr全部建好索引后，占用磁盤(pán)空間是1.2G，es占用磁盤(pán)空間是4G

?

單機(jī)對(duì)比2

在一臺(tái)Intel?i7，32G內(nèi)存的機(jī)器上，重新跑這兩個(gè)的對(duì)比。不過(guò)有個(gè)重大的區(qū)別在于，Solr是在這臺(tái)性能很好的機(jī)器上跑，而es的導(dǎo)入進(jìn)程則是在一臺(tái)Intel?四核?2.5G，4G內(nèi)存的機(jī)器上跑的，也許會(huì)有性能的差異。ES版本0.19.8，Solr版本4.0-ALPHA。

1.?Solr的導(dǎo)入性能：3400萬(wàn)條記錄，用時(shí)62分鐘，平均9140條/秒，占用空間12.75G

2.?使用?*999*?這樣的模糊查詢(xún)，3秒以?xún)?nèi)返回，稍長(zhǎng)一點(diǎn)的查詢(xún)條件?*00100014*，也是2~3秒返回

3.?Es的導(dǎo)入性能（設(shè)置Xmx為10G）：3400萬(wàn)條記錄，用時(shí)40分鐘，平均14167條/秒，占用空間33.26G，客戶(hù)端采用4個(gè)并發(fā)。

4.?使用?*999*?這樣的模糊查詢(xún)，9秒返回，稍長(zhǎng)一點(diǎn)的查詢(xún)條件?*00100014*，11.8秒返回

5.?如果不是針對(duì)所有字段查詢(xún)，而是針對(duì)某個(gè)特定字段，比如?SAM_CODE:?*00100014*，那么也是1秒以?xún)?nèi)返回。

6.?結(jié)論：es的查詢(xún)效率也可以很高，只是我們還不會(huì)用。

7.?結(jié)論2：es有個(gè)設(shè)置是把所有字段放一塊的那個(gè)，缺省是放一起，但是不知道為什么沒(méi)起到應(yīng)有的作用。

?

備注：

1.?Solr第一次的那個(gè)內(nèi)存使用的是缺省設(shè)置，這次改為10G，結(jié)果導(dǎo)入性能反而變差了，400萬(wàn)條記錄，用了8分鐘，平均8333條/秒，不知道為什么。

2.?改回缺省的內(nèi)存配置，導(dǎo)入速度仍然慢。

3.?重啟Linux，用10G的內(nèi)存配置，再導(dǎo)入，5030萬(wàn)條記錄，用時(shí)92分，約9112條/秒，說(shuō)明導(dǎo)入速度和內(nèi)存配置沒(méi)有大差別

4.?在10G配置的情況下，檢索速度也差別不大。

5.?為了搞清楚lucene4.0和solr4.0的進(jìn)步有多大，下載了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起來(lái)進(jìn)行測(cè)試，導(dǎo)入性能為：3400萬(wàn)條記錄，用時(shí)55分鐘，約10303條/秒，占用空間13.85G。查詢(xún)性能：*999*第一次11.6s，*00100014*??27.3s，相比4.0ALPHA的結(jié)果（5000萬(wàn)結(jié)果當(dāng)中，*999*第一次2.6s，*00100014*第一次2.5s）來(lái)說(shuō)，慢了很多，與es的性能差不多，因此，也許lucene4.0真的對(duì)性能有大幅提升？

?

集群對(duì)比：

采用4臺(tái)同樣配置（Intel?i7，32G內(nèi)存）的Centos?6.3組成的集群，進(jìn)行對(duì)比。

1.?首先是es，很方便的就組成了一個(gè)Cluster，等上一個(gè)3400萬(wàn)條的Index全部均衡負(fù)載之后進(jìn)行測(cè)試，導(dǎo)入到另外一個(gè)Index當(dāng)中。

2.?導(dǎo)入性能：8500萬(wàn)條記錄，用時(shí)72分鐘，約為19676條/秒。在前5千萬(wàn)條記錄導(dǎo)入時(shí)的速度在2萬(wàn)/條以上，初始的速度在2.2萬(wàn)/條。占用空間78.6G（由于有冗余，實(shí)際占用空間為157.2G）

3.?查詢(xún)性能：

*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的配置還算簡(jiǎn)單，啟動(dòng)一個(gè)ZooKeeper，然后其他三臺(tái)機(jī)器訪問(wèn)這個(gè)地址，就可以組成一個(gè)Cloud：

機(jī)器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?&

其他機(jī)器：nohup?java?-Xms10G?-Xmx10G?-Dsolr.solr.home="./example-DIH/solr/"?-DzkHost=192.168.2.11:9983?-jar?start.jar?&

?

但是在執(zhí)行?data?import?的時(shí)候，頻繁出現(xiàn)?OutOfMemoryError:?unable?to?create?new?native?thread。查了很多資料，把Linux的ulimit當(dāng)中的nproc改成10240，把Xss改成256K，都解決不了問(wèn)題。暫時(shí)沒(méi)有辦法進(jìn)行。

?

?

結(jié)論

1.?導(dǎo)入性能，es更強(qiáng)

2.?查詢(xún)性能，solr?4.0最好，es與solr?3.6持平，可以樂(lè)觀的認(rèn)為，等es采用了lucene4之后，性能會(huì)有質(zhì)的提升

3.?Es采用SAM_CODE這樣的查詢(xún)性能很好，但是用_all性能就很差，而且差別非常大，因此，個(gè)人認(rèn)為在目前的es情況下，仍然有性能提升的空間，只是現(xiàn)在還沒(méi)找到方法。